当明确要求保存知识或产出决策/原因/差距分析时，用原子互链…

把值得长期保留、非显而易见的判断型知识编译成原子 Markdown 文件、[[wiki-links]] 和维护索引，避免知识随会话丢失或反复重学。

适用场景

解决思路

1. 选择存储：默认使用 agent memory，即 `.claude/.../memory/` 文件夹，以 `MEMORY.md` 作为索引；这是每 agent 的存储，重启后仍存在，并遵循系统提示中已有的 memory 规则。
2. 只有团队协作时才使用 shared wiki：项目中的 `wiki/` 文件夹，以 `wiki/index.md` 为索引；用于整个团队都受益的知识，如领域事实、研究发现、多个 agent 会重复推导的参考材料。
3. 若是单人 agent，完全跳过 shared wiki，不要为了形式制造团队协作流程。
4. 按规则选择存储：只有我会用到 → memory；团队任何人都可能用到 → shared wiki；两者相关时用 `[[slug]]` 交叉链接。
5. 如果平台有自动 consolidation pass（例如 5dive：`5dive memory consolidate`，由 heartbeat 调度），先了解它覆盖什么、只有你能做什么。
6. 自动 consolidation 负责普通事实：它把已完成 session 的 transcript 蒸馏成你自己存储中的 memory atoms，不读取 live session，写入内容不离开你的机器；因此不需要手动把普通事实从 session 中抄出来，这能防止知识随 context window 消失。
7. 判断型知识仍由你负责：wiki 页面、决策及其原因、差距分析、发现背后的 CAUSE；pipeline 只能提取 transcript 中已陈述的内容，你得出的结论不在其中。
8. 自动 pipeline 不能发布到 shared wiki，因为它没有 store selector，且 shared store 默认拒绝；发布到团队存储仍是你亲自做的 curated act。
9. 自动 pipeline 只是缩小需要编译的范围，不替代编译；判断型知识仍要在关闭任务前走完下面的流程。
10. 写入前做 hygiene gate：只编译持久且非显而易见的事实。
11. 若事实是 routine、可从 repo/git history/现有 docs 推导、只对当前对话成立、或已被现有文件覆盖，则跳过；若已被覆盖，应 UPDATE 那个文件，不要重复创建。
12. 大多数任务（部署、重启、一行修复）不产生持久知识，这没问题；不要为了“写了点什么”而制造 memory，填充物比不写更糟，会污染 recall。
13. 先搜索：查找该主题的现有文件（grep 存储 + skim 索引）；若已存在就编辑它，绝不创建近似重复文件。
14. 保持原子化：一个文件只放一个事实/一个主题；如果想加入第二个不相关事实，就创建第二个文件。
15. 命名：使用 kebab-case slug；memory 使用类型前缀（`feedback_…`、`project_…`、`reference_…`、`user_…`），wiki 使用清晰主题 slug；slug 就是链接目标。
16. 写 frontmatter：`name`（= slug）、`description`（一行，且要具体，因为 recall 时靠它匹配）、以及 `type`/category。
17. 写正文：平实陈述事实；用 `[[slug]]` 大量链接相关条目，链接到尚不存在的文件也可以作为 TODO 标记；对 `feedback`/`project`，后面补上 **Why:** 和 **How to apply:** 行。
18. 维护索引：在索引中加入或更新一行指针（memory 用 `MEMORY.md`，wiki 用 `wiki/index.md`）：`- [Title](slug.md) — hook`；控制在约 200 字符以内，细节留在文件里，绝不放在索引。
19. 如果 wiki 的 `index.md` 还不存在，就创建它，让存储保持可发现。
20. 做 hygiene：删除后来发现错误的文件；把相对日期改成绝对日期；如果索引变长，就收紧行内容，不要让它膨胀。
21. 处理生命周期：事实会腐烂；当事实有时效性、不确定、或替代旧事实时，给 envelope 打标记，让 recall 可以老化它，而不是继续展示过期真相。
22. 使用 `valid_to: YYYY-MM-DD` 表示事实过期/需要重新检查的日期；过期后，recall 保留事实但降权并标记 `⚠ expired`。
23. 使用 `supersedes: <slug>` 表示新事实替代旧事实，并指向旧 slug；旧事实在 recall 中降权为 `⤴ superseded`，而不是残留成第二个矛盾答案。
24. 当旧值仍值得查看（审计轨迹）时，优先用 `supersedes` 而不是原地编辑；当旧值不值得查看时，才原地编辑。
25. 使用 `confidence: high|medium|low`：low/medium 事实被降权，确保猜测永远不会排在已验证事实之上。
26. 使用 `provenance: “<source>”` 记录事实来源，并与 `compiled_by`（谁写的笔记）区分开。
27. 如果存储有 CLI，它可能把这些做成 flag；例如 5dive 上 `5dive memory add` 支持 `--valid-to=`、`--supersedes=`、`--confidence=`、`--provenance=`；全部可选，省略则行为不变，上面的 frontmatter 字段才是可移植部分。
28. 避免反模式：不要写一大段 wall-of-text 文档而不拆成原子文件。
29. 避免反模式：不要把研究留成孤立的 `notes.md` 且从不折叠进存储；那只是工作笔记，不是知识；应把持久部分编译进存储。
30. 避免反模式：不要同时在 memory 和 wiki 重复同一事实；选择一个主存储，然后交叉链接。
31. 避免反模式：不要让索引条目复述整个文件。
32. 避免反模式：不要为了满足习惯/检查清单而写填充内容。
33. 完成前过快速检查清单：`[ ] durable & non-obvious? [ ] right store? [ ] updated existing vs new? [ ] atomic + named + frontmatter? [ ] [[links]]? [ ] index line added?`

适用边界 · 注意事项

• 普通分析工作：回答事实问题、总结文件、解释代码、报告例行任务结果时，没有可持久编译的内容，不应触发。
• 只产生 routine/可从 repo、git history 或现有 docs 推导的内容，或只对当前对话成立的内容，或已被现有文件覆盖的内容（应更新而不是新建）。
• 大多数任务（如部署、重启、一行修复）不产生持久知识；不要为了写而写，填充物会污染 recall。