📌 项目地址：EveryInc/compound-engineering-plugin | ⭐ 17,732 颗星 | 🔧 TypeScript | 📜 未标注
这套插件不是让AI写更快，而是让AI写更对
18k星的项目，名字叫compound-engineering-plugin，但它的核心不是生成代码的速度。它是一套命令系统，规定AI在动手之前先想什么、问什么、输出什么。80%的资源花在规划和评审上，20%花在执行——这不是使用方法上的建议，是这套命令设计出来的结果。
理念一句话：每个工程单元应该让后续单元更容易，而不是更难。 传统开发里加功能增复杂度，修bug留上下文碎片，AI把写代码的速度提上去，技术债的积累速度也跟着上去。这套流程试图逆转：通过一系列前置思考和事后固化，让下一次改动更省力。
工作流是一条强制执行的逻辑链
核心循环是五个阶段的往复：脑暴需求 → 制定计划 → 执行 → 评审 → 固化经验。上游还有一个策略文件/ce-strategy，它创建或维护STRATEGY.md，记录产品的目标问题、方法、用户画像、关键指标和追踪方向。这个文件是后续所有步骤的锚点，/ce-brainstorm、/ce-plan会自动读取它作为上下文。
循环里的每个步骤对应一个命令：
| 命令 | 目的 |
|---|---|
/ce-strategy |
创建或维护STRATEGY.md，作为后续脑暴和计划的上下文 |
/ce-ideate |
可选的大图景创意：生成几个方向，做批判性评估，输出排序的创意文档 |
/ce-brainstorm |
交互式Q&A，产出“尺寸恰当”的需求文档 |
/ce-plan |
把需求文档转成详细的实现计划 |
/ce-work |
用git worktree隔离分支执行计划，每完成一个task自动标记 |
/ce-debug |
系统化排查（README此处被截断，但命令可用） |
/ce-code-review |
代码评审，重点不是找bug而是发现可复用的模式 |
/ce-doc-review |
文档评审，与代码评审类似的作用 |
/ce-compound |
把这次开发中产生的判断、模式写成知识单元，供下一次复用 |
注意这些命令的依赖关系：你不可能跳过/ce-brainstorm直接让AI写计划，因为/ce-plan会要求上一步的输出作为输入。这是一条强制执行的逻辑链。
三层管线：从创意到可执行
/ce-ideate → /ce-brainstorm → /ce-plan 是连续的三步。
/ce-ideate处理开放问题：先生成几个方向，再做批判性评估，输出排序的创意文档。这不等同于需求，也不是计划。它的输出被喂给/ce-brainstorm。
/ce-brainstorm接管排序最前的方向，用交互式Q&A推细节。交互意味着你可以反驳、追问、补充，AI在对话中校准理解，最终产出“尺寸恰当”的需求文档。README里的说辞是“right-sized”，意思是不要长篇大论，够用就行。
/ce-plan把需求转成实现计划。整个过程一行代码不写，但它避免了AI辅助编码最致命的问题——直接让AI写实现，写到一半发现方向错了。
执行和评审的具体设计
/ce-work做两件事：用git worktree隔离分支（避免同时改多个分支时的冲突），每完成一个task自动标记进度。/ce-debug用于系统化排查，而不是随机改代码（由于README截断，我无法给出更详细说明，但它确实存在）。
评审阶段的/ce-code-review和/ce-doc-review，README里的原话是“Good review catches the pattern, not just the bug”——不是找茬，是找到每次改动里可复用的判断标准。比如你这次处理边界条件用了某种方式，评审时识别并记录下来，下次类似场景AI可以直接复用。
最后是/ce-compound，把判断、经验、模式写成一个知识单元。下次AI做类似工作时可以读取，不需要从零学起。这相当于手动给AI喂上下文，让它从每次开发中积累“常识”。
我用下来的几个实际问题
流程重。改一个CSS颜色跑全套是浪费时间。我的做法：修小bug直接上手，涉及逻辑变更或跨模块改动才跑全套。你不能让所有场景都跑这套流程，也没有必要。
STRATEGY.md必须有人维护。我试过让AI自己写那个文件，它写得出来但缺少对产品的真实理解。团队里没人愿意写那几百字的策略文件，后面所有脑暴和计划就失去锚点。这个责任没法推给AI。
README不完整。调试命令被截断，review和compound命令没出现在命令表格里。新用户上手有断档，需要到附带的博客文章（Compound engineering: how Every codes with agents 和 The story behind compounding engineering）里补全理解。
什么团队值得试
不是官方说的。我的判断：
- 团队最少3人用AI辅助开发，代码库活跃维护超过半年
- 已经明显感觉到“AI写代码很快，但改起来越来越慢”
- 有人愿意维护
STRATEGY.md——成本极低，收益很高 - 业务逻辑有一定复杂性，不是一次性原型
如果团队连需求文档都不写，先不要上这个。如果团队已经有成熟的代码评审和知识沉淀机制，这个插件的价值会打折扣，因为它把那些手动流程自动化/半自动化了。
集成方式
npm包名@every-env/compound-plugin。安装后，支持斜杠命令的AI工具（GitHub Copilot、Cline等）就能识别。它不是独立工具，是AI代理的“技能包”。
18k星说明很多人认同这个方向。这个插件的价值不是让你写代码更快，是让你写代码的顺序更对。先想清楚，再让AI动手。