你有没有遇到过这种场景：

只是想改一个按钮颜色，结果读了十几个文件。

只是想加一个字段，结果牵出一串历史逻辑。

只是想修一个报错，结果发现整个模块没有人真正讲得清楚。

这就是很多软件系统变大之后的常态。开发不再只是创造新东西，而是理解旧代码、绕开旧依赖、和过去的决定谈判。

AI 编程工具出现以后，很多人以为这种消耗会立刻消失。现实更复杂。AI 确实能把代码写得更快，但它也会更快地放大团队原本的问题。

如果项目边界模糊，AI 会更快地跨模块乱改。

如果团队规则只靠口头记忆，AI 会更快地制造不一致。

如果原型代码没有被清理，AI 会更快地把临时方案堆成正式系统。

所以，AI 时代真正的问题不是“怎么让 AI 多写点代码”，而是：

怎么让每一次开发，都让下一次开发更容易。

这正是 Compound Engineering 值得认真看的地方。

一、旧世界为什么越写越慢

传统软件工程并不天然复利。很多时候，它是在累债。

一个功能上线，看起来是资产。但它同时也带来了新的状态、新的依赖、新的分支条件。只要这些知识没有被结构化保存，它们就会变成后续修改的隐性成本。

这就是技术债最朴素的含义：

你今天省下来的解释成本，明天会以排查成本的形式回来。

AI 加入以后，这个机制没有消失，反而被加速了。

模型擅长局部补全、模式模仿和快速扩写。如果代码库本身已经混乱，AI 读到的就是混乱。如果团队规则本身含糊，AI 放大的就是含糊。如果大家默认“先跑起来再说”，AI 会把“先跑起来”做到极致。

以前我们担心人写代码太慢。

现在更大的风险，是错误的开发路径被跑得太顺。

很多团队第一次用 AI 写原型时，感觉像开挂。第二次改动时，开始觉得别扭。第三次重构时，发现系统已经变成一团只能摸、不能拆的东西。

最开始节省的是时间。

最后损失的是可维护性。

二、Compound Engineering 到底是什么

从公开材料看，Compound Engineering 更接近 Every 团队在 2025 年到 2026 年逐步形成并产品化的一套 AI 原生工程工作法。

它不是某个模型能力，也不是一个单纯的提示词技巧。它关心的是工程劳动如何积累：

• • 用更重的计划和评审，替代人类逐行敲代码的主工作流

• • 用 CLAUDE.md、AGENTS.md、可检索文档、专用 agent 和技能，把一次任务沉淀成下一次任务的起点

• • 让“单次交付”变成“可复用能力”的积累

Every 把核心流程压缩成四步：

Plan -> Work -> Review -> Compound

前三步并不陌生。

Plan 是先把需求、边界、风险和实施路径讲清楚。

Work 是让 agent 按计划执行。

Review 是检查正确性、安全性、性能、可维护性和项目规范。

真正关键的是第四步：Compound。

大多数团队在 Review 后就结束了。功能做完，PR 合并，聊天窗口关闭，知识也跟着散了。

Compound Engineering 要求你在任务结束前，把这次任务里新增的规则、踩过的坑、最终取舍和可复用方案写回系统。

前三步交付的是功能。第四步交付的是未来。

三、代码是产物，记忆才是资产

Compound Engineering 最有价值的转变，是把“记忆”做成工程部件。

这里最常出现的两个结构，是 CLAUDE.md 和 docs/solutions/。

CLAUDE.md 可以理解成项目的长期规则卡。它记录技术栈、命名偏好、测试要求、绝对禁区、常见错误写法。它不应该写成流水账，而应该短、硬、可执行。

docs/solutions/ 更像案例库。它记录已经解决过的问题：问题是什么，哪些方案失败了，最终为什么这样修，下次再遇到类似问题要先看哪里。

这两类信息不能混在一起。

长期规则应该短，因为它会被频繁读取。

复杂案例可以长，因为它主要用于检索和复用。

如果把所有细节都塞进 CLAUDE.md，它会越来越长，最后变成模型不愿认真遵守的噪音。如果什么都不写进 CLAUDE.md，agent 每次启动又像失忆。

所以，复利不是“多写点文档”。

复利是把知识放到正确的位置，让下一次任务真的能用上。

一个最小版本的复利回路可以这样理解：

新需求
  -> 先生成实施计划
  -> 人类确认边界和风险
  -> agent 按计划执行
  -> 多角度评审
  -> 修复问题
  -> 抽取本次新增规则和案例
  -> 写回 CLAUDE.md 或 docs/solutions/
  -> 下一次任务直接复用这些经验

这套流程看起来不神秘。它只是把“下次少踩坑”制度化了。

四、为什么计划和评审会变得更贵

Every 官方材料里有一个很强的主张：工程师大量时间应该花在计划和评审上，而不是执行上。

这个说法不能简单理解成行业定律。更准确地说，它是一条 AI 原生工作原则。

原因很直接：实现正在变便宜，方向错误正在变贵。

当模型能快速完成实现时，真正烧钱的部分就会暴露出来：

• • 目标没说清

• • 边界没讲明

• • 风险没提前看

• • 测试标准不明确

• • 评审只看“能不能跑”

• • 经验没有留下来

在这种情况下，工程师的价值会从“直接写实现”上移到另一组能力：

• • 定目标

• • 设边界

• • 做取舍

• • 看风险

• • 建评审标准

• • 维护长期记忆

这不是说代码不重要。

代码仍然重要，只是代码不再是唯一的资产。

更稀缺的工程师，不一定是写得最快的人，而是能把判断写进系统的人。

这里的“品味”也不是玄学。它指的是你能不能判断：

• • 哪种结构以后会烂

• • 哪条规则应该被固化

• • 哪个边界不能跨

• • 哪个临时方案不能进入主干

• • 哪个修复应该变成团队共享经验

写代码的速度，决定今天能做多少。写进系统的判断，决定明天还能不能继续做。

五、Vibe Coding 可以快，但不能一直糊着快

谈 Compound Engineering，绕不开 Vibe Coding。

Vibe Coding 的价值很真实。它能快速把想法做成可体验的东西，特别适合原型阶段。你可以很快搭界面、跑流程、验证需求。

问题出在很多团队做完原型以后，不删。

继续加。

继续补。

继续修。

最后把本来只是探索需求的代码，养成了正式系统。

这时技术债不是一点点长出来的，而是被原型思维整批带进来的。原型阶段容忍的模糊命名、重复逻辑、松散依赖、缺失测试，都会在产品阶段变成维护成本。

AI 在这里没有犯错。

AI 只是忠实执行了你的短期目标。

所以，比较成熟的做法是：

先用 AI 快速探索。

当需求被确认后，删掉原型残骸，回到计划优先的正式建设模式。

原型的价值在于学习，不在于继承。

Compound Engineering 和 Vibe Coding 不是简单对立。前者给后者划边界：允许你先快，但不允许你一直糊着快。

六、多 reviewer 不是作秀，但也不是免费午餐

Compound Engineering 里还有一个很容易被误解的点：多 reviewer。

比如让不同角色的 agent 分别检查安全、性能、正确性、测试覆盖、可维护性和项目规范。

乍一看，这像是在给模型加人设。一个扮演安全专家，一个扮演性能专家，一个扮演架构师。

但它背后的工程思想并不虚。

单个工程师看一份 PR，很容易只盯着自己熟悉的问题。有人只看逻辑，有人只看风格，有人不查边界条件。多 reviewer 的作用，是把盲区拆开。

不过，这套做法不是免费的。

reviewer 越多，时延越高，token 成本也越高。如果团队没有明确风险模型，最后可能只是花更多钱，买到一堆重复意见。

所以，多 reviewer 只有在两个条件下才值：

第一，任务足够重要。

第二，reviewer 的职责边界足够清晰。

AI 适合扩大检查面。

人类仍然负责定义判断面。

最后的问题仍然要由人来回答：

这是不是我们想做的东西？

这个取舍是不是值得？

这段改动会不会把产品带到错误方向上？

七、普通团队怎么搭一版最小复利回路

你不一定需要 Every 的整套插件，才能实践这套思想。

普通 coding agent 加上三类文件，就能搭出一个最小版本。

第一，CLAUDE.md。

放长期规则。包括项目结构、命名偏好、禁区、测试要求、常见坑。只写会反复生效的内容。

第二，IMPLEMENTATION_PLAN.md。

放当前任务计划。先列受影响文件，再列边界条件，再列实施顺序，最后列验证方式。人类确认后，agent 再执行。

第三，docs/solutions/。

放已经解开的复杂问题。包括错误路径、最终方案、关键取舍，以及下次再改这里最该记住的一条规则。

你可以直接使用下面三个提示词骨架。

1. 先产出计划，再批准执行

我要实现 [功能/改动]。

先不要写代码。请先阅读当前项目结构，并回答下面四件事：
1. 这次改动会影响哪些文件和模块？
2. 最大的边界条件和失败风险是什么？
3. 你准备按什么顺序实施？
4. 每一步怎么验证？

然后把结果整理成 IMPLEMENTATION_PLAN.md。
在我明确批准之前，不要开始写入代码。

2. 任务结束后，强制沉淀案例

这个问题已经解决。请总结聊天记录，沉淀可复用知识。

请在 docs/solutions/ 下新增一份记录，至少包含：
1. 问题是什么
2. 错误方案或无效尝试是什么
3. 最终为什么这样修
4. 下次再改这里时最需要记住的一条规则

3. 从本次任务里抽取增量规则

基于这次任务，请提取新增的项目规则，只保留适合长期保存的内容。

请回答：
1. 这次暴露了什么新约束？
2. 哪种写法以后应该避免？
3. 哪种模式以后应该优先采用？

把结果压缩成 1 到 3 条，写入 CLAUDE.md。
要求：短、具体、可执行。

这三段提示词的重点不是格式，而是强制 agent 生产中间资产。

没有计划、规则和案例库，所谓复利很快就会断。

八、这套方法为什么不能被神化

Compound Engineering 有价值，但不能被写成万能药。

第一，公开证据目前主要来自 Every 自己的文章、播客、官方指南和仓库。它们能互相验证概念来源，但还不足以证明这是一条适用于所有团队的普适规律。

第二，它依赖基础设施。如果团队没有测试、没有文档、没有清晰目录结构、没有基本模块边界，接入 agent 后，未必得到复利，更可能得到更快的混乱。

第三，它有成本。计划要花时间，多 reviewer 要花 token，案例沉淀要维护。它不是免费午餐，更像一种再投资：牺牲一部分眼前速度，换未来更低的边际成本。

第四，它不取消工程师，只重排工程师。被削弱的不是专业性，而是“代码等于自我表达”的旧观念。

在 AI 越来越强的系统里，工程师的价值更像品味和约束的维护者。

你不只是决定写什么代码。

你还决定系统以后怎么记住这次判断。

结尾：该告别的是“写完就散”

回到开头那个场景。

你只是想改一个按钮，却牵出一串旧逻辑。

这件事真正暴露的，不只是代码复杂，而是经验没有被留下。

如果 AI 只是帮你更快写代码，你得到的是一个加速器。它会放大好的习惯，也会放大坏的习惯。

如果 AI 开始帮你把计划写清楚，把规则存下来，把案例沉淀下来，把评审拆成明确组件，你得到的就不再只是加速器，而是一种更适合长期团队的工作法。

Compound Engineering 最硬的地方就在这里。

它没有神秘感。

它只是逼你面对一个老问题：

一次开发结束后，你到底留下了什么？

代码当然会继续被写。

Agent 当然会越来越强。

但长期上限不只取决于模型这周又会了什么。

它更取决于团队有没有能力把判断变成系统。

代码会过时。被写进系统的经验，才会复利。