夜雨聆风AI 写代码越快，越暴露一个尴尬事实：很多团队根本没有可复利的工程系统。
你今天让 Claude Code 修了一个 bug，明天它换个 session，又像失忆一样踩同一个坑。
你今天花 40 分钟解释项目结构，明天换一个任务，又得从“这个文件别动”“我们这里不用这个模式”“测试要这么跑”重新讲起。
这就是现在 AI 编程最真实的矛盾。
代码生成越来越便宜，上下文越来越贵。
所以 Every 最近推的 Compound Engineering（复利工程），真正有意思的地方，不是“又出了一个 Claude Code 插件”，而是它把 AI 编程的重心从“让模型写更多代码”，转到了“让每一次工程经验变成下一次的默认能力”。
我把它叫做：上下文本金。
不是让 Agent 每次都靠临场发挥赚钱，而是把你的计划、评审、踩坑、修复、偏好、架构判断，全部存成 Agent 下次能自动读取的本金。
本金越厚，下一次动手越轻。
这才是“大模型复利工程”的核心。
复利工程不是 prompt 技巧
Compound Engineering 最早不是从一个 GitHub 项目开始的，而是从 Every 自己做产品的内部经验长出来的。
Every 的 Kieran Klaassen 在官方文章里写，他们从零开始做 Cora，一个 AI 邮件助手。在这个过程中，他们把各种 agent、workflow、review 模式放进真实 PR 里反复试，最后沉淀成一套方法。
这套方法的第一原则很简单：
每一个工程单元，都应该让后面的工程单元更容易，而不是更难。
传统软件工程刚好反过来。
一个功能上线，代码多一点，边界多一点，历史包袱多一点。过几年以后，团队不是在产品上加速，而是在跟自己过去的选择谈判。
复利工程要做的是反转这个方向。
一个 bug 修完，不只是修掉眼前问题，还要把“为什么会错、以后怎么避免”存下来。一次 code review 发现了风格问题，不只是改这一行，还要把判断变成下次 review agent 会自动检查的规则。一次计划写得不清楚，不只是重新写计划，而是把“什么叫好计划”变成模板和技能。
说白了，它把工程里的隐性经验，变成 Agent 能读的显性资产。
这不是“多写文档”。
人类写文档最大的问题是，写完没人看。复利工程的关键是：这些文档、规则、skills、hooks、subagents，会进入 Agent 的工作上下文。
人类记不住没关系，Agent 下次开工前会读。
它的循环只有四步
Every 把这套流程拆成四步：
Plan → Work → Review → Compound → Repeat
前三步你都熟。
Plan，就是先想清楚要做什么。Work，就是执行。Review，就是检查结果。
真正拉开差距的是第四步：Compound。
传统 AI 编程一般停在 Review：代码能跑，测试过了，merge，下一题。
复利工程会多问一句：
这次工作里，有没有什么值得让未来的 Agent 自动知道？
如果有，就把它写到合适的位置。
可能是 CLAUDE.md 或 AGENTS.md 里的一条规则。可能是 docs/solutions/ 里的一篇解决方案。可能是一个新的 skill。可能是一个 review agent。也可能是一个测试或 eval（评估用例）。
这一步看起来像额外成本。
但 Every 的判断很狠：如果跳过 Compound，你做的只是“带 AI 的传统工程”。你这次是快了，但系统没有变聪明。
我觉得这句话非常关键。
今天很多人用 AI 写代码，只是在给自己装一个更快的外包程序员。复利工程想做的是，把这个外包程序员训练成一个越来越懂你公司的人。
为什么现在才需要它
过去工程的瓶颈是写代码。
一个需求摆在那里，最贵的是把它变成实现。工程师的价值，很大一部分体现在能不能把复杂逻辑一行行写出来。
但 Agent 出现以后，瓶颈变了。
现在模型可以读 repo，可以改文件，可以跑测试，可以修 bug，可以开 PR。真正稀缺的反而变成：
你能不能把需求讲清楚？
你能不能判断一个方案是不是适合这个代码库？
你能不能在 AI 写完以后，知道哪里危险？
你能不能把这次危险变成下次不会再发生的机制？
这也是 Every 那篇文章里最反直觉的地方。他们说，在 Every，没人手写代码已经不是特别奇怪的事。更重要的是工程师角色变了：工程师不再只是 code author（代码作者），更像 technical director（技术导演）。
写代码这件事交给 Agent。
人负责定方向、定标准、做取舍、建护栏。
这听起来有点像“躺着指挥 AI”，但实际不是。它只是把人的精力从键盘劳动挪到了系统设计。
你不是少干活了。
你是在干更难被模型替代的那部分活。
这个 GitHub 项目到底是什么
用户给的这个仓库是 EveryInc/compound-engineering-plugin。
截至我今天查到的 GitHub 页面，它已经有 16.6k stars、1.3k forks，最新 release 是 2026 年 5 月 11 日的 compound-engineering: v3.8.1。
项目 README 里给自己的定位很直接：
AI skills and agents that make each unit of engineering work easier than the last.
你可以把它理解成一整套 Claude Code / Codex / Cursor / Copilot / Droid / Qwen Code 等 AI coding 工具的工作流插件。
它现在不是只给 Claude Code 用。README 里已经列了 Claude Code、Cursor、Codex、GitHub Copilot、Factory Droid、Qwen Code、OpenCode、Pi、Gemini、Kiro 等安装路径。
插件里最核心的不是某一个神奇命令，而是一组工作流命令：
| 命令 | 用途 |
|---|---|
/ce-strategy | 写或维护产品策略锚点 STRATEGY.md |
/ce-brainstorm | 把模糊想法问清楚，变成需求草稿 |
/ce-plan | 把需求变成结构化实施计划 |
/ce-work | 按计划执行任务 |
/ce-debug | 系统性复现、定位、修复 bug |
/ce-code-review | 多 Agent 代码评审 |
/ce-compound | 把已解决问题沉淀成未来可复用知识 |
/ce-product-pulse | 按时间窗口生成产品表现和用户反馈报告 |
项目文档里还写到，当前插件包含 50+ agents 和 38+ skills。
这就是它和普通“提示词合集”的区别。
提示词合集通常解决的是一次对话怎么问。
这个插件解决的是：一个真实代码库里，需求、计划、执行、评审、沉淀，怎么形成闭环。
怎么用：不要一上来就开全自动
如果你用 Claude Code，安装大概是这样：
/plugin marketplace add EveryInc/compound-engineering-plugin
/plugin install compound-engineering装完以后，在项目里先跑：
/ce-setup它会检查环境、补齐缺的工具、初始化项目配置。
如果你用 Codex，README 里现在是三步：
codex plugin marketplace add EveryInc/compound-engineering-plugin
bunx @every-env/compound-plugin install compound-engineering --to codex然后启动 codex，进入 /plugins，在 TUI 里安装 compound-engineering 插件。
Codex 这里多一步，是因为当前 Codex 插件规范还没完全注册 custom agents，所以需要 Bun 那步把 agents 装进去。否则像 $ce-plan、$ce-work 这类需要派发 agent 的技能会缺人。
最小闭环可以这么跑：
/ce-brainstorm "make background job retries safer"
/ce-plan docs/brainstorms/background-job-retry-safety-requirements.md
/ce-work
/ce-code-review
/ce-compound如果是修 bug：
/ce-debug "the checkout webhook sometimes creates duplicate invoices"
/ce-code-review
/ce-compound这里最重要的建议是：先从小任务开始。
别一上来就让它重构核心系统。找一个你熟悉、有测试、有明确边界的问题，比如：
- • 一个已知 bug
- • 一个小功能
- • 一个文档刷新任务
- • 一个重复出现的代码评审问题
然后完整走一遍 Plan、Work、Review、Compound。
你不是为了验证“AI 能不能写代码”。这件事大概率已经能。
你是在验证：这次工作结束以后，系统有没有真的比开始时更懂你的项目。
推特上的几个效果例子
这类工具最容易被写成玄学，所以我专门找了 X/Twitter 上一些带使用细节的例子。
第一个是 Kieran 自己在 2026 年 2 月 9 日转发 Every 官方文章。Every 当时说，Compound Engineering 可以让代码库随时间变得更容易工作，而不是更难；那个时候插件已经有 7000+ GitHub stars。这条转发帖后来有 10 万多 views、560 likes、1000 bookmarks。
这说明它不是一个只在小圈子里自嗨的 workflow，至少已经被 AI 编程圈大规模看见了。
第二个更有意思，是 Kevin Rose 2026 年 1 月 19 日发在 X 上的 demo。第三方研究笔记记录说，这个 26 分钟视频展示了用 Claude Code 大约 20 分钟做出一个 Twitter/X 界面 clone。笔记里还记录了当时的数据：约 19.2 万 views、580 likes、1149 bookmarks。
这不是生产级系统的证据，但它是一个很好的“感知冲击”：当实现速度变得这么快，真正要争的就不是谁更会敲代码，而是谁能把计划、评审、上下文管理起来。
第三个是 Matt Van Horn 2026 年 3 月 23 日的长帖。他说自己现在的规则是，除非是一行改动，否则永远先有 plan.md。他还说自己已经有 70 个 plan files、263 个 commits，并且成了 Compound Engineering GitHub 项目的 #3 contributor，贡献了 21 个 commits。
他的工作流很具体：四到六个 Claude Code session 并行跑，一个写计划，一个按另一个计划实现，一个跑研究，一个修测试里发现的新 bug。计划文件成了跨 session 的检查点。
这就是复利工程最实际的地方：不是让 Agent 更像人，而是让 Agent 的中间产物变成可交接、可恢复、可复用的工程资产。
第四个是同一条长帖里的非代码案例。Matt 把一顿午餐的 Granola 会议记录丢进 Claude Code，用 /ce:plan 生成产品提案。因为 Claude Code 能访问他的代码库和历史策略 plan，这份提案不是普通会议纪要，而是带着公司已有技术和战略上下文的一份计划。
这点很值得注意。
Compound Engineering 不只适合写代码。只要你的工作有“计划、执行、评审、沉淀”这个循环，它都能用。
第五个是 Bits By Me 作者写的复盘。他用 compound engineering 做了一个 Go 写的终端计算笔记产品 CalcMark。四个月里做出 23 个 releases、Homebrew tap、多平台二进制、TUI 编辑器、live preview、undo/redo、GitHub Gist sharing、主题系统。
更关键的是他的数据：docs/solutions/ 里有 28 篇 solution docs，覆盖 UI bugs、logic errors、build errors、code organization、infrastructure、integration issues、test failures。一个 Go closure 捕获 value-type 的坑，被记录成 prevention strategy 两天后，又帮 Claude 在架构 review 里识别出同类问题。
他那句总结很准：
Speed without memory is just churn.
没有记忆的速度，只是空转。
但别把它当成银弹
我看完这些案例以后，反而觉得最该提醒的是：复利工程不是“装个插件，立刻 10x”。
它有三个前提。
第一，你得愿意计划。
很多人用 AI 的习惯是想到哪写到哪，prompt 一丢，模型开始改。这样当然爽，但它不会复利。因为你没有把意图固定下来，Agent 也没有一个可回看的判断依据。
第二，你得愿意评审。
Every 的方法里，plan 和 review 占了大头。AI 写得越快，越不能只看“它跑起来了”。你要看它有没有偏离架构，有没有过度设计，有没有引入以后难维护的隐性复杂度。
第三，你得愿意清理。
这点很少被热帖强调，但非常重要。
如果你把每一次偶发经验都写进规则，过两个月就会得到一个 200 条互相打架的 AGENTS.md。Agent 不会变聪明，只会变得更困惑。
所以复利工程的另一面是垃圾回收。
哪些规则真的稳定？哪些 solution docs 过期了？哪些 skill 已经不适合现在的架构？这些也要维护。
不然复利会变成复债。
真正的变化：工程师从写代码变成设计学习系统
我觉得 Compound Engineering 最有价值的地方，不是这套命令本身。
命令会变。Claude Code、Codex、Cursor、Droid 的能力也会变。
真正值得带走的是这个判断：
未来的软件团队，差距不在“谁更会叫 AI 写代码”，而在“谁更会让 AI 记住正确的工程经验”。
Vibe coding（氛围编程）解决的是灵感到原型。
Agentic engineering（智能体工程）解决的是人如何指挥 Agent。
Compound engineering（复利工程）解决的是下一层问题：你的 Agent 团队能不能越干越懂，越干越稳，越干越便宜。
这也是为什么我更愿意把它翻成“大模型复利工程”，而不是简单叫“复合工程”。
它的本金不是钱。
是计划、评审、测试、规则、踩坑记录、架构判断。
它的利息也不是某一次快了 30%。
而是下次不用重讲一遍，下次不再踩同一个坑，下次新同事和新 Agent 进来时，不需要靠口口相传继承团队经验。
代码会越来越便宜。
但能让经验留下来的系统，会越来越贵。
素材来源
- • Every: Compound Engineering definitive guide[1]
- • Every: Compound Engineering: How Every Codes With Agents[2]
- • EveryInc/compound-engineering-plugin GitHub README[3]
- • EveryInc/compound-engineering-plugin Releases[4]
