升格为团队的语言 — 追踪器·wiki·Git (5)

我的记忆和笔记，归根结底只有我和 AI 会读。 同事该知道的东西，唯有译成团队的语言，才算真正共享。

停在个人记录，就和团队断了联

前几篇里，我们堆起了规则、记忆、笔记。可这些全都是只有我和 AI 才读的记录。和 AI 干了半天、得出了不错的结论，若没反映到问题追踪器、wiki、代码仓库里，从同事的角度，就无从确认我到底做了什么。停在个人记录的那一刻，就和团队断了联。

于是需要 升格。把每日笔记里被反复引用的内容、同事也该知道的流程·决策·结论，往团队系统上抬。

往哪里升格

• 问题追踪器（Jira·Redmine·OpenProject 等） — 进度·负责人·期限。把会话结果作为工单评论或附件留下。但「完成」未必等于「解决」，所以要把验证结果作为评论留下。
• wiki（Confluence·Notion·Outline 等） — 流程书·设计决策·会议结论这类 正本。要写到新员工也能看懂的程度，不省略脉络。
• Git 仓库 — 不只是代码·脚本，还有技能·规则文件·配置。供多台电脑和团队成员共享，提交信息本身就成了简短的工作记录。

原则只有一条。一条信息只在一处作为原件。 同样的内容写在三处，必然对不上。升格之后，个人记忆里别复制原件，只留链接。

领先的团队早已这么做

这不是空想，而是做得好的组织实际在运转的方式。

• Toss 把 Slack 上的讨论摘要自动堆进文档仓库，再让这些文档成为公司内部文档聊天机器人的训练数据。文章标题很有代表性 — Toss 的前端开发者为何不再查文档。记录攒够了，连搜索都不再需要。
• 架构决策记录（ADR） 该放进 源码管理仓库 而非 wiki，这是 ThoughtWorks 的建议。因为记录必须和代码一起移动，才不会对不上（ThoughtWorks Technology Radar）。
• GitLab 以「手册优先」文化闻名，把公司运营方式整个写进公开手册。这份长达数千页的文档是「我们工作方式的单一真相源」，个人离开也留得下。
• Google 和 Spotify 让把文档当作代码来对待的 docs-as-code扎下了根。Google 用紧挨代码的 Markdown（g3doc）取代零散的 wiki，Spotify 用开发者门户 Backstage 的 TechDocs。国内则有 LINE 公开的案例：把开发者文档放到 GitHub、以 docs-as-code 运营。

文档化不是成本，而是放大器

有人会反驳：「有写文档的工夫，不如多干点活。」数据却说了相反的话。Google 的 DORA 研究反复证实，内部文档质量越好的团队，在同样的技术实践中能获得大得多的绩效提升。文档质量好时，达成可靠性目标的可能性高出 两倍以上，DORA 总结道「优质的文档带动了我们所研究的所有技术实践的执行」。文档会 放大 其他实践的效果。

反过来，没有记录时的损失，正如前面第 1 篇所见。知识若只捆在个人身上（在 Panopto 的调查中，有 42% 的机构知识只存在于某一个人身上），那个人一离开，就整个消失。

用一条流程来记住

整个流程可以这样归纳。

每日笔记 → 反复出现就进记忆 → 团队也该知道就进 wiki → 所有人每次都要遵守就进规则文件。

越往下，读的人越多，读的时间越久。草稿由 AI 来做，对外发布的最后一道确认由人来做。

后续内容

在最后一篇里，我们会梳理运营这套体系时必然遇到的陷阱，以及为了不至于想一口气全做完而累垮、把落地分成四周的路线图 — 陷阱与四周落地路线图。

如果你需要一张图，看清怎么把 AI 记录接到团队工具（追踪器·wiki·仓库）上，欢迎通过联系我们来联系。

---

「把 AI 当作会记忆的同事」系列

1. AI 为什么会忘记昨天 — 会话的遗忘与上下文成本
2. 规则集中一处 — AI 规则文件怎么写
3. 一个文件一个事实 — AI 自动记忆
4. 写给下一次会话的自己 — 每日笔记与交接
5. 升格为团队的语言 — 追踪器·wiki·Git（本篇）
6. 陷阱与四周落地路线图