每踩一个坑，就少一个坑：Compound Engineering 把 AI 编程变成知识复利机器

你上一次被同一个坑绊倒是什么时候？

很多团队的回答是”上周”。或者”昨天”。或者”刚才”——代码库里某处有一个约定俗成的做法，新来的开发者不知道，AI 编程助手更不知道，所以同样的问题被重新踩了一遍。技术债务不只体现在代码里，也体现在团队不断重复的”教训”里。

EveryInc/compound-engineering-plugin 想解决的就是这个问题——不是让代码更少，而是让每一次踩坑都成为”最后一踩”。

24,660 颗星背后的方法论

这个插件的本质是一套叫”复合工程”（Compound Engineering）的工作流。它的核心哲学只有一句话：每一单位工程工作，都应该让下一单位工作更容易，而不是更难。

传统的软件开发是积累债务的过程：每加一个功能，代码库更复杂一分，上下文更膨胀一点，下一个改动变得更慢。复合工程把这个轨迹翻转过来，通过一个结构化的学习循环，让团队的知识真的”留下来”。

循环是五个阶段：构思 → 规划 → 执行 → 评审 → 复合 → 重复。

• /ce-ideate：在动手之前发散地想清楚方向，适合探索性的功能决策
• /ce-brainstorm：通过问答式对话把一个模糊想法提炼成需求文档
• /ce-plan：把需求变成详细的实施计划，包含技术路径、依赖分析和潜在坑点
• /ce-work：按计划执行，插件会创建隔离的 git worktree，在干净的分支上干活
• /ce-code-review：多 agent 并行评审，不只是找 bug，而是捕获模式层面的问题
• /ce-compound：把这次学到的教训写回代码库，作为提示词文件存在，让下一个 session 的 agent 也能读到

这五个阶段中，”复合”（Compound）步骤是这个方法论的精髓。大多数团队会在 code review 之后就结束，而复合工程要求你把这次评审里发现的东西——不是总结给人看，而是写给 AI 编程助手看。写入 .compound-engineering/ 下的提示词文件，下一次同一个问题出现，agent 会自己识别并规避。

它到底装了什么

在 Claude Code 里安装只需要两行：

/plugin marketplace add EveryInc/compound-engineering-plugin
/plugin install compound-engineering

Cursor、Codex、OpenCode、Kiro、Windsurf、Pi、Gemini CLI、GitHub Copilot 等工具都有对应的适配方式——官方提供了一个跨工具的转换 CLI bunx @every-env/compound-plugin，可以把自己的插件安装到上述任意平台。

安装完成后，插件当前版本（v3.x）包含 36 个 skill 和 51 个 agent，涵盖：策略维护、头脑风暴、计划生成、工作执行、代码评审、文档评审、调试、git 提交流程、产品 pulse 报告、PR 反馈处理等完整工程生命周期。

值得注意的是 v3.0 是一个重要节点：所有 skills 和 agents 统一改名为 ce-* 前缀（如 /ce-plan、/ce-work），并且插件架构从”独立 agents”改为了”skill-owned”模式——评审人格不再是一个独立的可安装 agent，而是作为 skill 的内部提示词资源存在。这样的设计减少了插件的表面面积，让路由逻辑更清晰，但也意味着你没法再直接编辑某个评审人格的文件。

真实的门槛

这很重要：这个插件有学习曲线，而且不短。

复合工程的核心假设是你愿意把 ~80% 的精力放在规划和评审上，只有 ~20% 在执行。对于习惯了”有想法就开始写代码”的团队或个人，这个比例在一开始会让速度变慢。

官方自己也承认了这一点：

“前几个循环会比传统开发更慢。这是正常的——你在为未来的循环建立知识基础。”

另一个真实的门槛是你需要持续维护这个知识库。随着项目发展，prompt 文件会积累，久了会过时甚至矛盾——这时候需要用 /ce-compound-refresh 做定期清理。这不是一次性设置好就完了的维护工作。

还有一个实际问题是：插件和官方指南存在不同步。官方指南里列出的”26 个 agents、23 个 workflow commands”在当前代码库里并不存在，目录结构已经大幅重构，指南里的 deep link 大量返回 404。如果你依赖文档来了解这个插件，要意识到你读到的可能不是最新版。

适合谁，不适合谁

适合用的人：

• 长期项目（3 个月以上的个人项目或持续维护的产品），有足够的循环次数让知识复合产生回报
• 团队知识传递有瓶颈的场景——senior 的经验没法高效复制给新人或 agent
• 已经在用 Claude Code / Cursor / Codex 其中之一，并且希望让 AI 编程助手不只是写代码，而是真正理解项目上下文

不适合用的人：

• 短期一次性项目或者 PoC——建立知识基础的开销还没来得及收回项目就结束了
• 处于 deadline 压力下的团队——复合步骤是最先被砍掉的那个，而没有了复合，这个工作流就退化成了一个普通的 plan-build-review 循环
• 对 git worktree、提示词工程没有任何了解的用户——插件本身不负责这些概念的科普

和 Superpowers 的关系

这两个插件经常被一起讨论，因为它们在 AI 编程工具生态里都定位为”方法论层”。但实际上设计哲学很不一样。

Superpowers 通过 SessionStart hook 在每次 session 开始时自动注入自己，是”环境音”式的存在——你不需要主动调用，它已经在上下文里了。Compound Engineering 则没有 hook，是纯粹的显式调用：你输入 /ce-plan，它才动。

更重要的区别：Compound Engineering 会把知识写回磁盘（.compound-engineering/ 下的提示词文件），这些文件在 session 之间持久化。Superpowers 是读取侧的，帮你把工程规范注入上下文，但不会主动把学到的教训写回项目。

如果你同时装两者，会有 6 个能力重叠（brainstorm、plan、work、debug、review、worktree），superpowers 的 SessionStart hook 会让它默认胜出。官方建议在 AGENTS.md 里明确指定哪个插件负责哪个能力，避免歧义。

下一步建议

如果你决定试一下，最实用的路径是：

1. 在一个中等规模（> 3 个月生命周期）的现有项目里安装，不要开新项目——复合效果依赖有足够的循环次数
2. 第一个循环不要追求完整流程，只用 /ce-brainstorm + /ce-plan，感受一下规划阶段的产出是否真的比直接动手更清晰
3. 每次用完 /ce-compound 之后，检查一下生成的文件是否真的在描述这个项目的具体问题——泛化的教训价值有限，具体到”This module’s error handling must check error.code not just error.message”这样的教训才有复合价值
4. 如果你是团队使用，确保至少有一个成员理解 git worktree 和提示词文件的概念，否则 /ce-work 的隔离执行环境会带来额外的认知负担

GitHub 仓库：https://github.com/EveryInc/compound-engineering-plugin

官方完整组件参考：https://developertoolkit.ai/en/shared-workflows/development-workflows/compound-engineering

（本文首发于 2026-08-29，工具版本为 v3.x）