把一次解决，变成下一次不再遇见

Every 团队的工程部门基本上是单人配置：五款产品，五个工程师，每人管一个。撑住这套规模的不是更长的工时，而是一个四步循环里被大多数团队省掉的最后一步。

这个循环是：Plan → Work → Review → Compound。 前三步任何开发者都熟。Plan 是商量和划边界，Work 是写代码和让 AI 写代码，Review 是检查质量。走完这三步，一个功能上线了。然后呢？

大多数团队到这里就结束了。开始下一个功能。每周重复。

每走一圈，下一圈脚下多了一块路。

复利工程多做的那一步叫 Compound（固化）。不是多写一篇复盘文章贴在看板上，是把这次任务产生的知识写进下一次 AI 启动时默认加载的环境里。

同一个坑为什么会被反复踩

你肯定经历过这个场景：Agent 修了一个 bug，你很满意。三天后，另一个会话里，Agent 在同一个位置踩了同一个坑——因为那个 bug 被修了但修法没有被系统记住。

Plan → Work → Review 只解决了当前任务。它产出的是一个完成的功能或修好的 bug，但它不改变 Agent 下次遇到类似情况时的判断。

Compound 改变的是下一次的默认环境。

把修复的逻辑写进一条规则：修改这块代码时，先检查某个边界条件。把验证步骤固化成一条检查：PR 提交前，跑这个特定的测试。把某个容易写错的调用方式，收进一个代码生成模板里。

做一次 Compound，未来同一类问题在所有 AI 会话里都不会再出现。不做，每次都是重新踩坑——不是 AI 记性差，是你没往它默认识别的位置写进去。

不是在写文档

Compound 和”写文档”之间的区别，跟”教人钓鱼”和”给他一条鱼”一样大。

写文档是你对读者说：这里有一个坑，注意。Compound 是你往系统的食物链里插入了新的一环——下次 Agent 启动时，这条知识已经在那个它一定会读到的地方了。CLAUDE.md、项目规则文件、skill 描述、类型约束——这些都是 Agent 启动时不问你就会自己加载的位置。

你的网站项目里就有几个已经做完的 Compound 步骤。微信读书同步脚本里”人工字段永不覆盖”那条判断，不是什么技术技巧——是把一次”被自动化覆盖了人工修改”的教训写进了脚本逻辑里，让它下次启动时默认带着这个约束。CLAUDE.md 里那些文章口吻的底线——不说教、不升华、结尾一句收——是把反复改稿的经验固化成了 Agent 协作时的默认行为。

这些都是 Compound。没做 Compound 之前，每篇新文章都要在改稿阶段重改一轮。做完之后，Agent 第一版输出就避开了这些坑。

什么该固化，什么不该固

不是每一次修复都值得进入系统。临时性的 hotfix、只出现一次的环境问题、特定上下文的折中方案——这些东西固化了反而制造噪音。

每一次考虑 Compound 时，问自己一个判断标准：如果下个星期另一个 AI 会话也要改这部分代码，这条知识能让它不踩同一个坑吗？

答案”能”的才固化。答案”看情况”的暂时不固化。答案”不会”的只是笔记，不是 Compound。

固化的东西也不要永远留在那里。那条”注释规则”在上一篇关于上下文的文章里提到过——Anthropic 删掉了八成系统提示词。旧模型时代需要的规则在新模型里可能是累赘。固化的目的不是积累，是让系统保持在当前最佳状态。该删的删，该改的改。

Compound 不是复盘。它是把”我知道了”变成”系统也知道了”。 这件事不做，你每次让 AI 干活都是从零教起。做了，每一次任务都在给下一次铺路。