20500星！这个GitHub项目说：你每天只该花20%的时间写代码

大多数人在「消耗」AI，不是「利用」AI

先说说现在的局面。

2026 年了，没人再讨论「AI 能不能写代码」。SWE-Bench 上各家模型轮番屠榜，Cursor 用户量翻了三倍，Copilot 的 Agent 模式终于能跨文件改代码了。

但有个问题没人提——你用 AI 写代码，你是越写越轻松了，还是越写越累？

我的真实体验是：越写越累。

每次给 AI 一个 prompt，它刷地生成了几百行。我 review，我测试，我修 bug，我合分支。下一轮又是同一套——重新解释项目上下文、重新描述需求、重新审核输出的代码。

AI 帮我加速了单次任务，但整体上为什么没有变轻松？

因为经验没有积累。每次都是白纸一张。

你解决过一个坑，下次 AI 继续踩。你修过一个 bug，下次 AI 生成同样的 bug。你跟 AI 说过「不要用 any」，下次它照用不误。

这就是 Compound Engineering 瞄准的问题。

不是造一个更聪明的模型，而是设计一个系统，让 AI 从每次交互中学到东西，并且下次自动用上。

80% 规划 + 20% 写代码，这个比例反直觉

Compound Engineering 的核心循环看起来简单得有点欺骗性：

Brainstorm → Plan → Work → Review → Compound → (repeat)

五个步骤，四个跟「写代码」无关。

创始人 Kieran Klaassen 在 definitive guide 里写得很直白：80% 在规划和审查，20% 在执行。

我第一次看到这个比例，想法跟你现在一样：太夸张了吧？

但其实想一想就懂了。

你想想自己平时的工作节奏——真正在「打字写代码」的时间有多少？大部分时间在看 issue、翻代码库、想方案、review PR、debug。

Compound Engineering 做的，就是把这些「看不见的工作」系统化了。

Brainstorm — 不是头脑风暴，是一个交互式 Q&A 过程，最终产出一份结构化的需求文档。AI 跟你来回对话，把模糊的想法变成可执行的 spec。

Plan — 需求文档转成实现计划。改什么文件、测什么场景、边缘情况怎么处理。AI 帮你写好，你在上面改。

Work — 真正动手改代码的阶段。注意：有了前面的 Brainstorm 和 Plan，AI 写代码时已经知道全局上下文，不太会跑偏了。

Review — 这一步值得单独说。Compound Engineering 的 review 不是 AI 自己审查自己的代码。它启动了 14 个并行审查 agent，分别看安全、性能、架构、样式……你收到的是一个综合报告，而不是一段「你这个代码写得真不错」的废话。

Compound — 最关键的一步。把这次工作的经验写成结构化的笔记，喂回系统。下次 Brainstorm 时，AI 已经知道「哦这个团队不用 any 类型」、「这个模块有历史包袱」、「类似的坑上次踩过了」。

这套流程装在一个插件里，37 个 skill、51 个 agent。GitHub 上 20500 颗星——比我预想的多，但想想也合理。

每一个被 AI 生成的 any 坑过的人，都会想要一个不让 AI 再犯同样错的机制。

做对了一件事：让「经验」成为一等公民

我真正想聊的，不是这个插件有多好用（它确实好用），而是它背后的设计哲学。

你有没有注意到一个趋势——

2025 年大家在卷模型能力。2026 年大家开始卷工具生态。但很少有人在卷经验复用。

Cursor 再强，每个会话从零开始。 Claude Code 再聪明，它不知道你团队昨天达成的共识。 Copilot 再准，它不认识你代码库里那个诡异的兼容性 hack。

Compound Engineering 做的，就是把经验变成了代码一样可管理、可版本化、可迭代的东西。

那些 compound step 产出的笔记，不是丢进 wiki 吃灰的文档。它们是下次 AI 启动时自动加载的上下文。每完成一个任务，你的 AI agent 就变聪明一点点。

不是通过微调，不是通过 RAG，就是通过一套让「记住」这件事自动发生的工作流。

这和人类学习编程的方式一模一样：你踩过的坑，下次就不会再踩了。Compound Engineering 把这个模式复制给了 AI。

装起来复杂吗？四条路，各有各的走法

到这你可能会想：说得挺好，到底怎么装？

实际情况是：安装本身不复杂，但不同平台的路径不同。 我花了半小时看完 README 做了个对照表：

推荐从 Claude Code 或 Cursor 入手，安装最方便。如果你用的是 Codex，有个小坑——装完市场后还得跑一句：

bunx @every-env/compound-plugin install

装 agent，然后重启 Codex 才能看到所有 51 个 agent。

它不只是一个插件，它是一整套工作流编排系统。装完只是一个开始，真正的关键在怎么用。

装好之后输入：

/ce-setup

这是它的环境诊断命令。它会检查你有没有装齐依赖工具（gh、jq、ffmpeg 之类的），如果缺了什么会自动引导安装。跑完 setup 你就能看到绿色的 ✅ 安装完成。

然后怎么开始？官方的建议是：不要贪心，从一条完整的循环开始。

/ce-brainstorm "优化用户列表的加载速度"
/ce-plan docs/brainstorms/xxx-requirements.md
/ce-work
/ce-code-review
/ce-compound

第一次跑的时候，你可能会觉得「好慢」——因为每个步骤都有 Q&A 交互。但慢恰恰是设计的一部分。那 80% 的规划时间就在这五个步骤里。

不一定适合所有人

说点实话。

这套东西不是银弹。

但如果你是一个中等规模的团队，每天有几十个 PR，经常遇到 AI 反复犯同样的错误，或者你们正在从传统开发往 AI-assisted 开发转型——

那这是一个你可以考虑的投资。

不一定是装这个插件。不一定是照搬这套流程。而是理解一个理念：AI 开发不是「prompt → 代码 → 收工」的循环，而是一个应该越走越快、知识不断累积的过程。

Every Inc 用这套系统养了五个产品（Cora、Monologue、Sparkle、Spiral 和 Every.to），工程团队只有几个人。算了一笔账：前期多花 80% 的时间做规划和知识沉淀，后期每次编码的边际成本不断下降，直到接近零。

不是所有人都能达到这个状态。但能靠近一点，也是赚的。

所以，对我们意味着什么？

我这两天一直在想一个问题。

以前我们觉得编程是手艺活——靠经验积累，靠踩坑成长，十年才能磨一剑。

后来 AI 来了，大家觉得编程变成了 prompt 工程——会描述需求就能写代码。

Compound Engineering 告诉你：两个都对，但都有局限。

手艺活太慢，prompt 工程太浅。 真正有价值的是——用系统化的方法把每一段经验留下， 让下一次站在上一次的肩膀上。

20500 颗星，不是一个插件的人气，是开发者们对一个方向的投票：我们想要的不是更快的代码生成器，而是能越用越聪明的开发伙伴。

这周我打算在自己团队里试一期。不一定跑全流程，先从 /ce-compound 开始——每次做完一个小功能，写一份「经验笔记」喂给系统，看看一个月后 AI 的表现有多大变化。

三个月后回来告诉大家结果。

安装和使用示意图

上图从左到右展示了完整路径：

1. 安装 → 选一个你用的平台，跑对应的安装命令
2. 核心工作流 → 五个步骤循环：Brainstorm → Plan → Work → Review → Compound，其中只有 Work 是写代码
3. 知识复利 → Compound 产出的经验笔记自动加载到下次会话，AI 越用越聪明

💡 给你一个极简入门方案

如果你跟我一样不想一上来就跑全流程，可以先只做两件事：

# 第一步：每次开始新任务前跑一下
/ce-brainstorm "说清楚你要做什么"
# 这比直接让 AI 写代码省后续 3 轮扯皮

# 第二步：做完后跑一下
/ce-compound "记录这次学到了什么"
# 这个笔记下次 Brainstorm 自动加载

只跑这两步，你就已经进入了「���识复利」的循环。剩下的 Plan、Work、Review 可以根据需要逐步接入。

这就是 Compound Engineering 的设计巧思——它不要求你一步到位，你可以从任意节点切入，每一次循环都在把系统变得更懂你的项目。

顺便一提，Every Inc 的创始人还写了一篇深度文章讲这套理念的起源，叫 Compound Engineering: How Every Codes with Agents，有兴趣可以搜来读。

就这样。不总结了。总结的话自己翻到标题上去看。