老炮经验沉淀 2.0：从写给同事，到写给 agent
我们团队最资深的工程师老 W，从业 14 年。过去十年他在公司内网写过 80 多篇 wiki，里面装着无数血泪——某个老接口的边界条件、某次故障的根因、某类需求的设计陷阱。写 wiki 是过去十年工程师沉淀经验的标准动作。
直到我把这 80 篇 wiki 全量喂给一个 agent，让它跑实际的代码任务。它的表现像没读过一样。
不是 agent 笨。是这些 wiki 的格式从根上就不是给 agent 看的——它们默认读者会读上下文、会问同事、会去翻代码、会跨文档拼接信息。而 agent 一次只看一个上下文窗口，没有能力问你「你这段话指的是哪个版本」「这个『现在』是什么时候写的」。
这就是 AI 时代经验沉淀最大的失锚：读者悄悄换了，但写法没换。老 W 那 80 篇 wiki，对 2018 年的同事是宝藏，对 2026 年的 agent 是噪音。
三层沉淀架构：从规则到 harness
如果你接受「经验是写给 agent 看的」这个前提，那写什么、写在哪、写成什么格式，全部都要重做。
我把它分三层，从低到高、从高频到高杠杆：
L1 — agent 规则层（cursorrules / claude.md / agent rules）
最底层、最高频。每个项目里那个 claude.md 或 .cursorrules 文件，是 agent 执行任何任务前都会读的。它装的是那些「每次都得说一遍」的判断：
- 这个 repo 用 pnpm 不用 npm，安装请用
pnpm i - 任何 SQL 改动必须先生成 migration，禁止直接改 schema 文件
- 业务术语对照表（用户管「订单」叫 order，但内部 message bus 叫 transaction）
- 「写完先跑 tsc，再跑 test，再跑 lint，三步都过了才算完」
每条都来自一次真实踩坑。一条规则消灭一类反复出现的低质量输出。
老 W 那篇 wiki 里写过「这个接口超时是因为某中间件有 30s 上限」——这件事在 wiki 里 14 年没救过任何人，因为没人会在调用接口前去翻 wiki。但同样一句话写进 cursorrules 第一行，每次 agent 准备调用都会先看到。位置变了，价值翻了几十倍。
L2 — spec 与 kit 层（planning-level sediment）
中间层，沉淀的是「这一类问题该怎么拆」。Agent 单步执行很强，但拆任务一塌糊涂——而拆任务恰好是老炮十年积累的核心能力。
具体形态有几种：
- spec 模板：「做一个新的 dashboard 页面」拆成 7 步：数据接口 → 类型定义 → 查询层 → 视图层 → loading / empty 态 → 测试 → 文档。每步的输入输出固定。
- 任务 kit：「线上 bug 排查」打包成一个 kit：先拉日志 → 比对最近 24h commit → 在分支上复现 → 加最小修复 → 加回归测试。Agent 拿到「线上 bug」三个字就知道展开成这套流程。
- review checklist：你过去 5 年 review 别人 PR 反复挑的那些毛病（变量名 / 边界条件 / N+1 查询 / 缺失 error handling），固化成 agent 在 review 阶段必须输出的清单。
这一层最难写，因为它要求你把直觉转成有限步骤。但凡是能转的，转完之后是巨大的杠杆——一个好的 spec 模板，能让 agent 从 70 分输出稳定到 90 分，且不需要你再 review。
L3 — harness 编排层（agent of agents）
最顶层，沉淀「整个工作流应该长什么样」。
这层就是我过去一年在做的事——搭一个 multi-coding-agent harness。本质上是把团队的工作流编码成一套调度逻辑：
- 谁来负责拆任务（planner agent）
- 谁来执行（coder agent，可能多个并行）
- 谁来 review（reviewer agent，跑你 L2 里的 checklist）
- 谁来合并（merger，根据 review 决定是否需要返工）
- 出现失败时如何降级 / 回滚 / 升级到人
这层装的是你作为 TL 十年带团队的判断：什么时候并行、什么时候必须串行、哪个节点必须卡人工、什么 bug 可以让 agent 自己重试三次。这一层没法在 wiki 里写——因为它必须是一段会执行的代码。
哪些经验值得沉淀，哪些喂了也白喂
不是所有老炮经验都值得喂给 agent。有些是高 ROI 的，有些喂了等于浪费上下文。
| 经验类型 | 沉淀 ROI | 原因 |
|---|---|---|
| 反复出现的低层规则 | ★★★★★ | L1 一条搞定一类问题 |
| 任务拆分套路 | ★★★★★ | L2 杠杆最大 |
| 业务术语 / 接口边界 | ★★★★ | 给 agent context，减少猜错 |
| 历史故障根因 | ★★ | 除非能转成防御规则，否则只是知识 |
| 设计哲学 / 美学偏好 | ★ | agent 学不会，强行规则化反而伤创造力 |
| 政治 / 跨部门套路 | 0 | 这是人和人之间的事，agent 不参与 |
别犯的错：把所有 wiki 一键导进 agent context。垃圾进，垃圾出——上下文窗口被无关历史塞满，agent 反而抓不到关键。我见过的最离谱案例是把 200 页公司 onboarding 手册全塞进 system prompt，结果 agent 写 1 行代码先复述 5 段公司价值观。
正确做法是先做减法：80 篇 wiki，砍到 8 条 cursorrules + 3 个 spec 模板 + 1 个 harness 配置。剩下的 70 多篇 wiki 留着给人看（如果还有人看的话）。
沉淀对象变了，沉淀的 ROI 也变了
传统经验沉淀的 ROI 是线性的——你写 80 篇 wiki 救 80 个场景，一篇救一次。读者增长几乎是零，因为公司里愿意主动翻 wiki 的人本来就少，且越来越少。
给 agent 写沉淀的 ROI 是乘性的——你写一条 cursorrules，agent 每次任务都用，一年跑 10000 次。一条好规则的累计价值，可能等于过去十年所有 wiki 加起来。
但这件事有个隐形门槛：你得能区分「值得沉淀的」和「不值得的」。这恰好是老炮 vs 新人的核心差距。
新人写 cursorrules 会把所有他想到的都塞进去——结果文件 800 行，agent 上下文塞爆，每次还要重读，反而拖慢；更糟的是规则之间互相打架，agent 在两条矛盾规则间反复横跳，输出反而比没规则还差。
老炮的优势是知道什么不该写。这种「判断哪些经验值得固化」的能力本身也是一种经验，且没法被沉淀——你不能写一条规则说「请用我的判断力判断」。
所以会出现一个有点反直觉的局面：AI 时代，沉淀经验的人比沉淀经验本身更稀缺。一个能把团队 wiki 砍成 8 条 cursorrules 的人，价值远大于过去那个把 wiki 写到 200 篇的人。
给三类人的具体动作
给 IC 老炮：找你电脑里最常打开的那个项目，写第一版 cursorrules。规则不要超过 20 条，每条都来自一次你能复述细节的真实坑。写完跑两周，看哪些没起作用、哪些救了你，迭代。别试图一次写完。
给 TL：把团队最常重复的 3 类任务（发版 / 查 bug / 加新接口），各做成一个 spec 模板放在 repo 里。每个新人入职第一周让他用这套模板跑一次，比你拉会讲半小时有用。半年后看一下：你的 spec 模板被改动的频率，反映了你 L2 沉淀的成熟度。
给老板 / EM：别再要求工程师把经验写进公司 wiki 系统了——那东西在 AI 时代是写完就死的格式。改成「每个 repo 维护自己的 agent 规则文件」，并把这件事算进 OKR。一个团队 cursorrules 的质量，比他们写的 RFC 数量更能反映组织能力。
收尾
经验沉淀这件事，过去十年逻辑没变过：写 wiki、写 RFC、写 onboarding doc、做新人培训。读者一直是「未来的同事」。
但从某个时点开始，最频繁读你这些东西的读者，不再是人了。
你团队 80% 的 PR 由 agent 起草、agent 用的是你写的规则、agent 不读你公司 wiki——这三件事都是已经发生的事实，只是大部分老炮还没把它和「经验沉淀」这件事联系起来。
调整不复杂：把你脑子里那本「我希望新人入职第一周就懂的事」拿出来，写在 agent 会读的地方，不是公司 wiki 系统。
格式换了，对象换了，杠杆翻了几十倍。但前提是你愿意承认一件事——你十年积累下来的真正稀缺品，不是知识本身，而是「判断哪些知识值得让 agent 学」的能力。