https://www.knightli.com/tags/compound-engineering/ Recent content in Compound Engineering on KnightLi的博客 Hugo -- gohugo.io zh-cn Fri, 01 May 2026 03:15:39 +0800 https://www.knightli.com/2026/05/01/compound-engineering-plugin-ai-coding-workflow/ Fri, 01 May 2026 03:15:39 +0800 https://www.knightli.com/2026/05/01/compound-engineering-plugin-ai-coding-workflow/ <p><code>Compound Engineering Plugin</code> 是 Every Inc 开源的一个 AI 编程工作流插件。</p> <p>它关注的不是“让 AI 更快写一段代码”，而是把 AI 编程放进一个更像工程团队的循环里：先计划，再实现，再评审，再把经验沉淀下来。对经常使用 Claude Code、Codex、Cursor、Copilot 这类工具的人来说，这类插件解决的是工作流问题，而不只是提示词问题。</p> <p>AI 编程工具越来越强，但真实项目里最难的往往不是生成代码，而是让它持续按项目规则做事、理解任务边界、避免重复犯错，并在多轮迭代中积累上下文。</p> <h2 id="它解决什么问题">它解决什么问题 </h2><p>很多人使用 AI 编程助手时，流程大概是这样：</p> <ol> <li>直接描述需求</li> <li>让 AI 改代码</li> <li>看结果是否能跑</li> <li>出错后继续补充说明</li> <li>下次新任务再从头解释一遍</li> </ol> <p>这种方式能完成小任务，但在复杂项目里很容易遇到问题：</p> <ul> <li>需求没有先拆清楚，AI 直接开始改</li> <li>改完代码后缺少系统性 review</li> <li>项目规范靠用户反复提醒</li> <li>同类错误下次仍然出现</li> <li>多个 Agent 工具之间缺少统一工作方法</li> <li>经验没有沉淀成可复用规则</li> </ul> <p><code>Compound Engineering Plugin</code> 想解决的就是这类问题。它把 AI 编程拆成多个阶段，让 Agent 不只是执行命令，而是参与一个更完整的工程流程。</p> <h2 id="什么是-compound-engineering">什么是 Compound Engineering </h2><p>从项目 README 的描述看，Compound Engineering 可以理解为一种 AI 辅助软件开发方法。</p> <p>它强调一个循环：</p> <ul> <li>计划：先理解目标、拆分任务、确认路径</li> <li>执行：按计划修改代码、运行命令、处理问题</li> <li>评审：检查实现质量、风险和测试覆盖</li> <li>学习：把经验沉淀成后续可复用的规则</li> </ul> <p>这个循环很像真实工程团队的工作方式。</p> <p>一个靠谱的工程师不会拿到需求就立刻乱改，也不会改完就直接交差。他会先判断影响范围，再动手实现，之后检查风险和测试结果，最后把踩过的坑记录下来。AI Agent 也需要类似约束。</p> <h2 id="为什么需要插件">为什么需要插件 </h2><p>提示词可以告诉 AI “请先计划再执行”，但提示词本身不一定稳定。</p> <p>一旦会话变长、上下文变复杂，模型可能会跳过计划、忽略规则，或者为了完成任务而过度自信。插件的价值在于把流程固化下来，让不同 Agent 环境都能遵循类似方法。</p> <p>这类插件通常会把工作流拆成命令、规则、模板或子流程。用户不需要每次手写完整提示词，而是通过固定入口触发某个阶段。</p> <p>比如：</p> <ul> <li>先让 Agent 生成计划</li> <li>再按计划逐步实现</li> <li>改完后触发 review</li> <li>发现问题后返回修正</li> <li>把值得保留的经验写入记忆或规则</li> </ul> <p>这会让 AI 编程更像“受控协作”，而不是一次性聊天。</p> <h2 id="支持哪些-agent-环境">支持哪些 Agent 环境 </h2><p>README 中提到，项目支持多个 AI 编程环境，包括：</p> <ul> <li>Claude Code</li> <li>Codex</li> <li>Cursor</li> <li>GitHub Copilot</li> <li>Amp</li> <li>Factory</li> <li>Qwen Code</li> </ul> <p>这点值得注意。</p> <p>很多工作流工具只绑定一个客户端，换工具后规则就不能复用。<code>Compound Engineering Plugin</code> 更像一套跨 Agent 的工程方法，把类似的计划、执行、评审流程带到不同工具里。</p> <p>如果你同时使用多个 AI 编程助手，这类统一工作流会更有价值。不同工具能力不同，但项目规范、评审习惯和任务拆解方法应该尽量一致。</p> <h2 id="计划阶段有什么用">计划阶段有什么用 </h2><p>计划阶段的价值，是防止 AI 过早动手。</p> <p>复杂任务里，真正重要的问题通常是：</p> <ul> <li>要改哪些文件</li> <li>哪些模块可能受影响</li> <li>现有模式是什么</li> <li>有没有测试</li> <li>风险点在哪里</li> <li>是否需要先阅读文档</li> <li>能不能拆成更小步骤</li> </ul> <p>如果 Agent 没有先想清楚这些问题，就直接开始写代码，很容易做出看似完成、实际偏离项目结构的实现。</p> <p>计划并不一定要很长。好的计划应该短、具体、可执行。它的目的不是制造文档，而是让后续实现有边界。</p> <h2 id="执行阶段要避免什么">执行阶段要避免什么 </h2><p>AI 执行代码任务时，最容易出现几类问题：</p> <ul> <li>顺手重构无关代码</li> <li>覆盖用户已有修改</li> <li>只改 happy path</li> <li>忽略错误处理</li> <li>不按项目已有风格写</li> <li>没有运行必要验证</li> <li>遇到报错后盲目尝试</li> </ul> <p>工作流插件无法保证这些问题完全消失，但可以通过规则和阶段约束减少发生概率。</p> <p>比如，执行阶段可以要求 Agent 按计划逐步推进；遇到超出计划范围的发现时，先说明风险；修改共享模块时，补充测试或至少运行相关验证。</p> <p>这种约束对大型代码库尤其重要。AI 写代码越快，越需要流程来限制它的惯性。</p> <h2 id="评审阶段为什么重要">评审阶段为什么重要 </h2><p>很多 AI 编程失败，不是因为代码完全不能运行，而是因为细节有问题：</p> <ul> <li>边界条件没处理</li> <li>状态更新不一致</li> <li>API 合约被悄悄改了</li> <li>测试覆盖不到关键路径</li> <li>错误提示不清楚</li> <li>性能或安全风险没有被提到</li> </ul> <p>评审阶段就是把 Agent 从“作者模式”切换到“审查模式”。</p> <p>作者模式容易为自己的实现找理由；审查模式则要主动找漏洞、回归风险和遗漏测试。把这两个阶段分开，会比让同一个回复里同时完成实现和自我审查更可靠。</p> <p>对用户来说，评审输出也更有价值。它能帮助你快速判断这次修改是否值得合并，还是需要继续返工。</p> <h2 id="学习和记忆的意义">学习和记忆的意义 </h2><p>项目名字里的 “Compound” 暗示了一个重要想法：工程经验应该复利增长。</p> <p>如果 AI 每次犯错后只是当场修好，下次又犯同样错误，效率提升就很有限。更好的方式是把有价值的经验沉淀下来：</p> <ul> <li>这个项目的目录约定</li> <li>某类错误的排查方法</li> <li>测试命令和注意事项</li> <li>不要触碰的生成文件</li> <li>代码风格偏好</li> <li>常见实现模式</li> </ul> <p>这些经验可以变成规则、记忆、文档或模板。后续任务中，Agent 先读取这些沉淀，再开始工作。</p> <p>这就是 AI 编程从“单次问答”走向“长期协作”的关键。</p> <h2 id="适合什么场景">适合什么场景 </h2><p><code>Compound Engineering Plugin</code> 适合这些场景：</p> <ul> <li>长期使用 AI Agent 写代码</li> <li>一个项目会被多次、多轮修改</li> <li>希望 AI 先计划再实现</li> <li>希望改完后自动进入 review 思维</li> <li>团队想统一 AI 编程流程</li> <li>同时使用 Claude Code、Codex、Cursor 等多个工具</li> <li>希望把项目经验沉淀成可复用规则</li> </ul> <p>如果只是偶尔让 AI 写一个小脚本，完整流程可能显得偏重。</p> <p>但如果你正在把 AI 编程助手当成日常开发伙伴，计划、执行、评审、学习这套循环就会明显有用。</p> <h2 id="和普通提示词模板有什么区别">和普通提示词模板有什么区别 </h2><p>普通提示词模板通常解决的是“怎么说清楚任务”。</p> <p>比如：</p> <ul> <li>请一步步思考</li> <li>请先阅读文件</li> <li>请保持代码风格一致</li> <li>请运行测试</li> <li>请总结修改内容</li> </ul> <p>这些提示当然有用，但它们还是依赖用户每次正确使用。</p> <p><code>Compound Engineering Plugin</code> 更偏工作流层。它把这些要求组织成可重复的过程，并适配不同 Agent 工具。这样你不是每次从零写提示词，而是在一套流程里推进任务。</p> <p>简单说，提示词模板像提醒，工作流插件像制度。</p> <h2 id="使用时要注意">使用时要注意 </h2><p>第一，不要把流程变成负担。</p> <p>小任务不一定需要完整计划和长篇评审。好的工作流应该能根据任务复杂度调整，简单问题快速处理，复杂问题再走完整循环。</p> <p>第二，评审不能替代测试。</p> <p>Agent review 能发现很多问题，但它仍然可能漏掉真实运行时错误。最终判断还要看测试、类型检查、构建结果和人工审查。</p> <p>第三，规则要持续清理。</p> <p>沉淀经验很重要，但规则越积越多也会变成噪声。过时规则、重复规则、只适合某次任务的临时经验，都应该定期整理。</p> <p>第四，跨工具一致不等于完全相同。</p> <p>Claude Code、Codex、Cursor、Copilot 等工具能力和交互方式不同。统一的是工作方法，不一定是每个命令、每个配置细节都完全一样。</p> <h2 id="适合怎样的团队">适合怎样的团队 </h2><p>如果一个团队已经允许 AI Agent 修改真实代码，那么只讨论“哪个模型更强”是不够的。</p> <p>更应该关心：</p> <ul> <li>AI 修改前是否理解任务</li> <li>AI 修改中是否遵守项目边界</li> <li>AI 修改后是否主动审查风险</li> <li>AI 是否能从历史错误中学习</li> <li>团队是否有统一的 Agent 使用规范</li> </ul> <p><code>Compound Engineering Plugin</code> 这类项目的意义就在这里。它把 AI 编程从个人技巧，往团队可复用流程推进了一步。</p> <h2 id="参考">参考 </h2><ul> <li><a class="link" href="https://github.com/EveryInc/compound-engineering-plugin" target="_blank" rel="noopener" >EveryInc/compound-engineering-plugin</a></li> </ul> <h2 id="最后一句">最后一句 </h2><p><code>Compound Engineering Plugin</code> 值得关注的地方，不是多一个 AI 编程命令，而是把 AI 编程组织成可循环改进的工程流程。</p> <p>当 AI Agent 开始参与真实项目，计划、执行、评审和经验沉淀会比单次生成代码更重要。</p>