系统规模不大时，我们很容易相信自己“记得”。端口在某个聊天记录里，节点地址写在两份表格中，真正可用的配置则躺在服务器上。每一份都像答案，直到它们开始互相矛盾。
重复不是备份
同一条信息出现在三个地方，看起来更安全，实际上产生了三个需要同步的承诺。只要一次修改漏掉其中一份，重复就不再是冗余，而是分叉。
单一事实源并不意味着所有内容只能写一次。它意味着必须明确哪一份拥有解释权，其他位置要么引用它，要么清楚标注自己是衍生物。这样发生冲突时，不需要投票，也不需要凭更新时间猜测。
先给事实命名
很多混乱不是缺少文档，而是缺少分类。节点清单、登录凭证、部署步骤和运行中的配置看起来都在描述同一台机器，但它们回答的是不同问题。
我更愿意先写清楚入口：问“怎么登录”去哪里，问“当前有哪些节点”去哪里，问“实际部署值”又去哪里。导航规则一旦稳定，知识库不必完美，也能在真实操作中保持可用。
也把规则写给 AI
当 AI agent 开始参与运维，隐含约定会迅速变成风险。人能够从语气里猜出“这个文件只是例子”，agent 却可能把它当成部署源；人会犹豫某个私钥是否应该提交，自动化则需要一条明确的红线。
因此协作规则也应该进入仓库：先读什么、哪些值不能编造、修改哪一份后必须同步哪一份、什么操作必须停下来确认。它不是给机器的额外说明，而是把原本只存在于维护者脑中的判断公开化。
让系统重新变小
好的文档不会让系统少一个组件，却能让认知里的系统变小。你不必同时记住所有地址、例外和历史，只需要记得从哪里开始，以及哪个位置最终说了算。
这是一种很朴素的工程收益：减少猜测，保留上下文，让下一次修改可以建立在这一次之上，而不是再次考古。
如果你也在整理自己的系统，可以从一张最常被复制的表开始。给它指定唯一归属，再让其他地方只留下链接。 接着读其他札记 →