现在用 Codex、Claude Code、Cursor 这类工具，最容易兴奋的是第一次。

你丢一个任务进去。

它会读文件、改代码、跑命令、解释错误。

看起来像是多了一个能干活的队友。

但用久了以后，另一个问题会冒出来。

很多经验没有留下来。

这次你告诉它“先写计划再动手”。

下次还要再说一遍。

这次你纠正它“不要碰无关文件”。

下次换个项目，它可能又忘了。

这次你终于摸出一套适合自己团队的 review、debug、验证流程。

结果它只停留在这一轮聊天里。

这就是今天 GitHub Trending 里 EveryInc/compound-engineering-plugin 值得看的地方。

项目地址：https://github.com/EveryInc/compound-engineering-plugin

它不是又一个模型，也不是一个单点提示词合集。

它想解决的是更底层的工程问题：怎么把 AI 编程里的好做法，沉淀成下一次也能复用的技能、命令和代理团队。

先说结论

compound-engineering-plugin 的价值，可以用一句话讲清楚：

它把 AI 编程从“每次重新聊天”推进到“把流程装进工具里复用”。

对开发者来说，真正有用的不是多背几个提示词。

而是把需求澄清、计划、执行、代码审查、文档审查、调试、复盘这些动作变成可调用的工作流。

这样每一次任务结束以后，留下来的不只是代码改动，还有下一次能继续变好的工程方法。

为什么这个项目会火

这几天 GitHub Trending 里连续出现 Claude Code、Codex、Cursor 插件、Agent Skills、subagents、harness 类项目。

这不是巧合。

AI 编程已经从“模型会不会写代码”走到了下一层：工具如何稳定参与真实工程。

真实工程最难的地方，往往不在某一段代码。

而在流程。

需求有没有先问清楚。

改动范围有没有收住。

有没有先理解现有架构。

有没有跑验证。

有没有把失败原因说清楚。

有没有把 review 里的判断沉淀下来。

如果这些都靠人每次手工提醒，AI 再强也会变成一个健忘的实习生。

compound-engineering-plugin 的火，踩中的正是这个痛点：当 AI Agent 进入开发现场以后，下一步不是让它更“自由”，而是让它有一套能复用、能审查、能迭代的工程纪律。

旧工作流的问题，是好经验不会复利

很多人第一次用 AI 编程，会从提示词开始优化。

比如：

“先读代码再改。”

“给我一个计划。”

“不要改无关文件。”

“跑测试后再告诉我结果。”

这些提醒当然有用。

但它们很快会变成新的重复劳动。

你在 A 项目里总结了一套写 bugfix 的流程，到了 B 项目还要重新说。

你在一次代码审查里发现某类问题，下一次还要手动提醒。

你让 AI 学会了怎么写项目文档，但这套经验没有变成团队可共享的能力。

这就是 AI 编程里很隐蔽的浪费。

表面上代码生成越来越快。

实际上，流程经验还在聊天记录里散落着。

compound-engineering-plugin 想做的，是把这些经验从一次性对话里捞出来，变成明确的 commands、skills、agents 和项目约定。

核心能力拆开看

1. 把“先想清楚”变成一个可调用动作

很多 AI 写代码的问题，不是执行慢，而是太快执行。

需求还没拆清楚，它就开始改文件。

边界还没确认，它就顺手重构。

compound-engineering-plugin 把计划和澄清放在很前面。

它的 README 里给出的典型流程，是先把粗略想法变成需求文档，再从文档生成计划，最后才进入执行和审查。

这个设计很朴素，但很关键。

因为真实开发里，写代码通常不是第一步。

第一步是判断“到底要改什么，为什么这么改，怎么验证它没坏”。

当这个步骤变成一个固定命令，而不是每次临时提醒，AI 才更像在参加工程流程，而不是抢着输出答案。

2. 把审查变成校准，而不是最后走过场

AI 生成代码以后，最危险的不是有 bug。

有 bug 很正常。

更危险的是它看起来很顺，让人以为可以直接合进去。

compound-engineering-plugin 里专门强调 review。

代码 review、文档 review、调试复盘、后续沉淀，都是它想覆盖的工作。

这和普通“帮我检查一下代码”不太一样。

它真正想做的是校准判断。

这次 review 发现了什么问题。

哪些规则应该以后继续遵守。

哪些流程应该写成技能。

哪些检查可以交给代理重复执行。

这样 review 就不只是给当前 diff 找问题，也是在训练下一轮工作方式。

3. Skills 让团队经验不再只存在某个人脑子里

这个项目很适合放在今天讲，一个原因是它明确围绕 Skills 和 Agents 展开。

Skills 本质上是可复用的能力包。

里面可以放说明、脚本、参考资料、模板和资产。

对个人来说，它可以沉淀自己的工作习惯。

比如怎么做前端视觉验证，怎么审查 API 改动，怎么处理数据库迁移，怎么写发布复盘。

对团队来说，它可以把“我们通常怎么做”写进工具。

比如提交前必须看哪些 diff，调试线上问题要先查哪些日志，改接口前要检查哪些消费者。

这比把经验写在一份很长的文档里更接近实际工作流。

因为 Agent 在做任务时可以直接调用这些技能，而不是等人想起来再翻文档。

4. Agents 解决的是分工，而不是制造热闹

很多项目一提 subagents，很容易变成“多开几个 AI 看起来很强”。

但真正有价值的分工不是热闹。

是边界清楚。

一个代理负责研究。

一个代理负责代码审查。

一个代理负责文档审查。

一个代理负责验证方案。

每个代理拿到的上下文、目标和退出条件都不一样。

compound-engineering-plugin 的方向，就是把这些分工组织起来。

这对复杂任务很重要。

因为一个主 Agent 很容易在执行时被上下文淹没。

如果研究、计划、执行、审查、复盘都混在同一个脑袋里，它会越来越像一场很长的聊天。

而把角色拆开以后，任务就更容易被检查。

你可以问：研究有没有覆盖关键资料？计划有没有落到文件？执行有没有偏题？review 有没有指出真实风险？

这才是 agent team 的价值。

5. 它同时面向 Claude Code、Codex、Cursor，说明趋势不再绑定单一工具

这个项目的另一个看点，是它不是只服务某一个编辑器或 CLI。

仓库说明里明确写到 Claude Code、Codex、Cursor 等工具，并提供不同平台的安装和适配说明。

这背后有一个更大的趋势。

AI 编程工作流正在变成一种跨工具资产。

今天你可能在 Claude Code 里调试。

明天在 Codex 里让代理改仓库。

后天在 Cursor 里做上下文编辑。

如果每个工具都从零配置，团队经验就会被切碎。

而插件、Skills、规则、commands、agents 这些东西，本质上是在尝试把工程方法从具体工具里抽出来。

谁能把这些方法带到不同环境里，谁就更接近真正可复用的 AI 工程系统。

6. 它也提醒我们，AI 工程化不能只靠“更强模型”

compound-engineering-plugin 有一个很直接的观点：每一次工程工作都应该让下一次更容易。

这句话听起来像口号，但放到 AI 编程里很实际。

如果一个 Agent 做完任务以后没有留下任何可复用的东西，那它只是完成了一次外包。

如果它把踩坑、检查清单、项目规则、脚本和技能沉淀下来，下一次才有复利。

这也是为什么我觉得它比很多“更会聊天”的工具更值得看。

它关注的不是一次回答有多漂亮。

而是 AI 参与工程以后，团队能力会不会变厚。

怎么试才最容易看出价值

不要一上来就把它当万能工程系统。

更好的试法，是选一个你已经重复做过很多次的流程。

比如：

把一个模糊需求整理成可执行计划
修一个有测试复现的小 bug
对一个 PR 做代码审查
把一次调试经验沉淀成团队规则
给某类项目写一个可复用 Skill

然后观察五个问题。

第一，它有没有先把任务边界问清楚。

第二，它生成的计划是否能直接落到文件和命令。

第三，它有没有把执行和审查分开。

第四，它是否能把失败经验沉淀成下一次可用的规则或技能。

第五，它是否让你减少重复提醒，而不是增加新的流程负担。

如果这五点成立，它就不是一个提示词合集。

它是在帮你搭一套 AI 工程工作台。

适合谁，不适合谁

它适合已经深度使用 Codex、Claude Code、Cursor 这类工具的人。

尤其适合那些每天都在做真实项目改动、代码审查、调试、文档维护、自动化验证的人。

如果你已经发现“每次都要重新教 AI 怎么干活”很烦，它的价值会比较明显。

它也适合团队探索 AI 编程规范。

比如把团队 review 标准写成 Skill，把常见调试流程写成命令，把项目交付检查做成固定步骤。

但它不适合所有人。

如果你只是偶尔问 AI 一个语法问题，普通聊天框足够。

如果团队还没有基本的 Git、测试、代码审查纪律，直接上复杂 agent 工作流可能只会放大混乱。

如果项目权限、密钥、生产环境边界没有想清楚，也不应该急着让 Agent 跑得太远。

AI 工程化的前提不是“更自动”，而是“更可控”。

我真正看好的是什么

我看好 compound-engineering-plugin，不是因为它提供了一组很酷的命令。

真正值得看的，是它把 AI 编程的竞争点往前推了一步。

过去大家比的是模型。

后来比的是编辑器、终端和上下文能力。

现在开始比流程资产。

谁能把人的工程经验沉淀成可复用的技能，谁能让 Agent 在计划、执行、审查、复盘之间形成闭环，谁就能让 AI 编程不只是“今天快一点”，而是“每做一次都让下一次更容易”。

这也是我觉得它适合今天写的原因。

它没有停在“AI 帮你写代码”。

它真正讨论的是：当 AI 已经能进项目干活以后，我们该怎么让它越干越像一个有工程记忆的团队成员。

欢迎关注公众号，后续每天一起看一个高质量开源项目：不堆名词，只看它解决什么问题、怎么上手、能不能用到真实工作流里。