比 Superpowers 更贴近AI编程工程实践的51 个 Agent 和 35 个技能

大家应该都知道 Superpowers 这个开发神技能，这篇文章介绍另外一个开源的技能项目 - 复合工程（compound-engineering）。

这个项目是Every 团队做实际项目时一点点摸索出来的，直到最后形成了目前这套系统化的方法。

它和 Superpowers 最大的区别就是项目的知识积累。

下面逐项来安利这套系统 - 51个 Agent、35个 Skill。

核心想法：让下一次更容易

项目的核心理念：

今天做的每一件事，都应该让明天的事变得更容易，而不是更难。

众所周知，大多数项目是越做越大，形成行内所称“屎山”代码。

新功能改一个地方怕牵动十个地方。代码越来越看不懂、改不动、信不过。

这套复合工程就是要反过来。

加功能不是增加复杂性，而是教会系统新本事。

修 bug 不是修一个算一个，而是把同类 bug 一劳永逸地消灭掉。

将好的做法固化下来，变成了以后能直接用的工具、方案。

时间累积，代码库越来越好懂、越来越好改、越来越靠谱。

循环：从想法到交付的七步完整流程

Every 这家公司同时做六款产品——Cora、Monologue、Proof、Sparkle、Spiral，还有内容平台 Every.to。

这么多产品，主要靠单人工程团队撑着。

让他们能做到这一点的，就是这套七步循环的做法：

想点子 → 聊清楚 → 写计划 → 动手干 → 找毛病 → 打磨好 → 记下来 → 再来一轮

这七步可以分成三个阶段：

• 开头：人来决定做什么
• 中间：AI 负责写代码、测试、审查、准备提交
• 结尾：人来判断做得够不够好，系统有没有学到新东西

也不是每次都有严格走完七个步骤。

如果你已经知道要做什么，就跳过"想点子"。

如果 bug 很明显，直接去修。

如果是后端改动，"打磨"那步可以轻一点。

关键是：把你的精力花在最重要的决策上，然后让系统记住这些决策，下次直接用。

第一步：想点子

当你脑子里只有一个模糊的想法，不确定该做什么的时候，就从这一步开始。

AI 会帮你把想法变成一个候选清单。

它会翻代码库、看用户反馈、分析痛点，从不同角度生成一堆点子，然后帮你筛选出最值得做的几个。

这一步跟 Superpower 头脑风暴技能是一样的。

第二步：聊清楚

有了一个还不错的点子之后，下一步是把它聊透。

AI 会像一个产品经理一样问你：这是给谁用的？要解决什么问题？有什么限制？边界情况是什么？做完之后应该是什么样子？

聊完之后，你会得到一份清楚的需求文档。

第三步：写计划

需求清楚了，接下来要规划怎么做。

AI 会同时启动几个"研究员"：一个研究你的代码库，一个查框架文档，一个找行业最佳实践。

然后把这些信息整合成一份实施计划，告诉你该改哪些文件、按什么顺序改、怎么验证。

第四步：动手干

计划写好了，AI 就开始干活了。

它会创建一个隔离的工作环境（这样不会影响主代码库），按计划一步步实施，每改完一步就跑测试验证。你不需要盯着每一行代码看，信任计划就好。

第五步：找毛病

代码写完了，先别急着发布，让 AI 帮你找找问题。

这个步骤比较特别：AI 会派出十几个"审查员"，从不同角度挑毛病——安全审查员看有没有漏洞，性能审查员看会不会卡，测试审查员看覆盖够不够。

它们并行工作，比一个人审查全面得多。

发现的问题会按严重程度排序：P1 必须修，P2 应该修，P3 最好修。

第六步：打磨迭代

功能能用了，但用起来感觉对不对？这一步是把"能用"变成"好用"。

让 AI 启动应用，你像真实用户一样用一遍。

看看速度快不快、动画顺不顺、文案清不清楚、空状态友不友好。

感觉哪里不对，就告诉 AI 改。

第七步：记下来——最重要的一步

前面六步做完，你得到了一个功能。

但第七步做完，你得到的是一个能更好地做功能的系统。

这一步要把经验记下来：什么有效、什么踩坑了、下次怎么避免。

这些记录会被 AI 存起来，下次做类似的事情时自动调出来。

这就是"复合"（compound）的理念：每一次积累，都让下一次更容易。

系统全貌

复合工程的具体实现，是根据理念整理实践出来的一整套 Agent 和Skill，装上就能用。

都是什么

• 51 个专业 AI 角色：每个角色专门干一件事，有的审查安全，有的研究代码库，有的写文档
• 30 多个快捷命令：专用命令触发专项流程
• 35 多个技能模块：覆盖从前端设计到代码审查的各种场景

这 51 个 Agent 分为六大类：

代码审查（20 个）：正确性、安全、性能、测试、可维护性、API 契约、数据迁移、可靠性、对抗性、架构、简洁性、模式识别、Swift/iOS、前端竞态等审查员。

文档审查（7 个）：一致性、产品视角、可行性、设计视角、范围守护、安全视角、对抗性文档审查员。

研究（9 个）：代码库、框架文档、最佳实践、网络、经验、Git 历史、Issue 智能、会话历史、Slack 研究者。

设计（3 个）：设计迭代器、Figma 同步器、设计实现审查员。

工作流（2 个）：规格流分析员、PR 评论处理器。

文档（1 个）：README 编写器。

每个角色专注一个领域，并行协作。

安装

Claude Code ：

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

Cursor ：在聊天窗口里输入 /add-plugin compound-engineering，或者在插件市场搜 "compound engineering"。

Codex ：

codex plugin marketplace add EveryInc/compound-engineering-pluginbunx @every-env/compound-plugin install compound-engineering --to codex

然后启动 Codex，运行 /plugins，找到插件安装，重启。

其他工具（GitHub Copilot、Gemini、Kiro 等）的安装方式，可以去 GitHub 项目页看文档。

装完之后

插件会在你的项目里创建一些文件：

• CLAUDE.md（或 AGENTS.md）：AI 每次启动都会读这个文件，里面放你的偏好和项目规则
• docs/brainstorms/：存放需求文档
• docs/plans/：存放实施计划
• docs/solutions/：存放经验记录，按类别自动归档

常用的命令

/ce-ideate：想点子

当你不知道下一步该做什么时用这个。AI 会帮你分析代码库、看用户反馈、生成候选点子，最后给你一个值得探索的短名单。

/ce-brainstorm：聊需求

当你大概知道要做什么，但细节还不清楚时用这个。AI 会像产品经理一样问你问题，帮你把需求聊透。

/ce-plan：写计划

需求清楚了，用这个命令让 AI 帮你规划怎么实施。它会同时研究代码库、查文档、找最佳实践，然后给你一份详细的计划。

/ce-work：动手干

计划写好了，用这个命令让 AI 开始干活。它会按计划一步步实施，跑测试，创建 PR。

/ce-code-review：找毛病

代码写完了，用这个命令让十几个专业 AI 角色同时帮你审查。它们会从安全、性能、测试、架构等不同角度挑毛病。

/ce-compound：记经验

做完一件事后，用这个命令把经验记下来。AI 会分析什么有效、什么踩坑，然后存到知识库里，下次自动调出来。

/lfg：一步到位

如果你想省事，直接用这个命令描述你想要什么，AI 会帮你完成从计划到 PR 的全流程。

例如下面这样：

/lfg 在设置页面添加深色模式切换

AI 会自己研究、规划、写代码、自我审查、修问题，最后交给你一个可以直接合并的 PR。

与时俱进的观念

AI 时代来了，有些观念与传统软件时代大不一样。

"代码必须自己写"

做好一个软件，核心要求是写出好代码——干净、好维护、解决正确的问题。

至于是你打的字还是 AI 打的字，真的没那么重要。

"每一行都得自己审"

手动审查是保证质量的一种方式，但不是唯一方式。

AI 审查系统能发现同样的问题，而且更全面。

如果你不信任 AI 的结果，应该去改进系统，而不是自己把所有事情都做了。

"第一次就得做好"

根据作者团队的经验，AI 第一次尝试有 95% 的废品率。

第二次还有 50%。这不是失败，这是过程。

期望第一次就完美，就像期望一个新来的同事第一次就把复杂功能做对一样不现实。

重要的是迭代速度——让你的第三次尝试比第一次快得多。

"写代码才是正经事"

开发者的真正工作是交付价值。

代码只是手段之一。

规划、审查、教系统学习，这些同样重要。

复合工程师写的代码比以前少，但交付的更多。

"代码是自我表达"

很多开发者下意识觉得 AI 写代码是在"抢饭碗"。

但代码从来不是真正属于你的，它属于团队、产品和用户。

放下这种执念，反而能更轻松地接受反馈、更果断地重构。

AI编程的五个阶段

AI编程渗透到日常工作中不是一步到位的。

阶段 0：纯手工

完全不用 AI，靠文档和搜索引擎解决问题。

这种方式做了几十年的好软件，但在 2026 年，确实有点慢了。

阶段 1：AI 当参谋

把 AI 当成一个超级聪明的参考工具。

问它问题，拿代码片段，复制粘贴有用的部分。

你还是完全掌控，每一行都自己审。

阶段 2：AI 当助手，你当监工

让 AI 直接读你的文件、改你的代码。

但你还是守门人，AI 做的每一件事你都要批准。大多数开发者卡在这里。

阶段 3：你定方向，AI 干活

这是关键转折点。

你和 AI 一起制定计划，然后让 AI 自己去实现。

你只需要审查最终结果（PR），不用盯着过程。

复合工程从这里开始真正发挥作用，因为每次循环都在积累经验。

阶段 4：你出想法，AI 全包

你只需要说"我想要什么"，AI 自己去研究、规划、写代码、测试、审查，最后交给你一个 PR。

你只需要做三件事：想点子、审 PR、点合并。

阶段 5：并行开干

把执行搬到云端，同时开好几个任务。

你用手机启动三个功能，三个 AI 独立干活，做完了通知你审查。

你不再是干活的人，你是指挥的人。

怎么晋级

从 0 到 1： 选一个 AI 工具，每天用。先让 AI 帮你解释代码，再让它帮你写测试和配置文件。每次都要审查结果。

从 1 到 2： 开启 agent 模式，让 AI 能直接改你的文件。从小任务开始："给这个函数加个测试。"每次都要批准 AI 的操作，慢慢建立信任。

从 2 到 3（关键）： 学会投资规划。需求、方法、边界情况都写清楚。让 AI 研究代码库、建议方案。然后让 AI 自己去实现，你只看 PR。

从 3 到 4： 不写详细指令了，只描述结果。"给新评论加个邮件通知"，让 AI 自己决定怎么做。

从 4 到 5： 搬到云端，并行运行。同时开三个功能，三个 AI 同时干。

重要习惯

把你的品味写下来

每个代码库都带着创建者的"品味"——命名习惯、错误处理方式、测试方法。

但这些品味通常只存在于优秀工程师的大脑里，靠代码审查，靠总结文档。

解决方案：把这些偏好写下来，放到 CLAUDE.md 里。

AI 每次启动都读这个文件，慢慢就学会了你喜欢的风格。

时间长了，AI 写出来的代码你一看就满意，不用反复改。

80% 规划，20% 动手

听起来反直觉，但这是真的：花 80% 的时间在规划和审查上，只花 20% 在执行上。

因为好的规划让执行更小、更快、更准。

好的审查能发现模式问题，而不只是语法错误。

别怕放手

很多开发者不敢让 AI 自己干活，总觉得不放心。

但放手不是放弃控制，而是把控制编码成规则、约束和审查流程。

这些东西比人工盯梢扩展性好得多。

计划比代码更重要

以前是先写代码再写文档。

现在应该反过来：先写计划，再让 AI 写代码。计划是 AI 生成、测试、验证代码的依据。

在纸上修想法，比在代码里修 bug 便宜多了。

与 Superpowers 的对比

说到这里，就要对比一下另一个面向编程智能体的开发方法论框架：Superpowers 。

两者都试图系统化 AI 辅助开发流程，但设计思想和实现方式有显著差异。

核心设计思想差异

两个框架的底层哲学截然不同。

复合工程 Compound Engineering 的核心隐喻是"复利"——每一次积累都让下一次更容易，驱动力来自经验的持续积累，知识库会随着使用不断增长。

它的哲学底色是务实主义：能用就行，渐进改良，95%的废品率是过程而非失败。

Superpowers 的核心理念则是"系统化优于临时方案"，驱动力来自流程的强制执行——技能自动触发，不是建议而是必须。

它的哲学底色是工程主义：强调 TDD（测试驱动开发）、证据优于声明（验证后再宣告成功）、复杂性减少。

对人的角色定位也不同：Compound Engineering 让人定方向、审 PR、点合并；

Superpowers 在关键决策点保留人工监督，但更强调流程纪律。

流程设计差异

Compound Engineering 的七步循环是：想点子 → 聊清楚 → 写计划 → 动手干 → 找毛病 → 打磨好 → 记下来 → 再来一轮。

这个循环有一个独特的"复利"闭环：最后一步"记经验"会把积累写入知识库，下次自动调出来。

它还有一个专门的"打磨好"步骤，关注从"能用"到"好用"的 UX 层面。

Superpowers 的七阶段是：头脑风暴 → Git 工作树 → 编写计划 → 执行计划 → TDD → 代码审查 → 完成分支。

它没有"记经验"和"打磨好"这两个环节，但强制要求 TDD（先写失败测试，再写最小代码使测试通过，最后重构），并且有明确的 Git worktree 隔离和分支完成决策流程。

实现差异

在技能触发机制上，两者走了完全不同的路。

Compound Engineering 是命令驱动的——用户主动输入 /ce-xxx 触发，有 30 多个快捷命令，用户需要知道用哪个。

Superpowers 则是自动触发——技能会自动激活，智能体在执行任何任务前都会检查相关技能，无需用户记忆命令。

这种方式，又可能会因为提示词的问题导致无法触发，而在日常工作中无法察觉。

代码审查的方式也不一样。

Compound Engineering 派出十几个"审查员"并行工作，从安全、性能、测试、架构等不同角度挑毛病，最后按严重程度排序（P1/P2/P3）。

我比较喜欢这种帮你把具体事务都做好的感觉。

Superpowers 采用两阶段审查：先检查规格符合性（做对了事没有），再检查代码质量（事做对了没有），更结构化，先确保方向正确再打磨细节。

这种审查只依赖大模型的好坏，没有统一的标准，实际项目中容易走偏。

知识积累是 Compound Engineering 最核心的差异化。

它有专门的 /ce-compound 命令用于记录经验，存到 docs/solutions/ 按类别归档，下次做类似事情时自动调出来，"这就是复合的意思"。

Superpowers 没有对应的自动化经验积累机制，虽然有 writing-skills 元技能用于创建新技能，但那是创建新能力，不是积累经验。

产品打磨也是 Compound Engineering 独有的。

第六步"打磨好"会启动应用，让你像真实用户一样用一遍，检查速度、动画、文案、空状态，关注从"能用"到"好用"的体验层面。

Superpowers 更关注代码质量和工程正确性，不涉及 UX 层面的打磨。

一句话总结：Compound Engineering 是"让每次工作都为下一次铺路"的复利哲学；

Superpowers 是"用流程纪律保证质量"的工程哲学。

前者更软（经验、品味、打磨），后者更硬（TDD、强制、证据）。

我觉得成年人不做选择，两者都要。

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

-END-