在软件开发领域，Superpowers 是一个广为开发者熟知的 AI 辅助开发框架。今天我们来探讨另一个开源项目——复合工程（compound-engineering）。这套方法论并非凭空设计，而是 Every 团队在实际项目中逐步摸索、迭代，最终形成的一套系统化工程实践。 它与 Superpowers 最核心的差异在于对“知识积累”的重视程度。下面我们逐一拆解这套系统：内含 51 个 Agent、35 个 Skill，看看它究竟如何运作。 ### 先说说这个项目的核心理念 复合工程的核心思想很朴素：今天做的每一件事，都应该让明天的事变得更容易，而不是更困难。 众所周知，绝大多数项目都会随着时间推移变得越来越庞大，发展到后期就容易演变成业内常说的“屎山”代码。添加新功能时，修改一处往往牵动十处；代码越来越难以理解、难以改动、难以信任。 复合工程就是要反其道而行之。增加功能不是增加复杂性，而是教会系统新技能；修复 bug 不是修一个算一个，而是将同类问题一劳永逸地消除。好的做法会被固化下来，变成未来可直接调用的工具和方案。久而久之，代码库反而会变得越来越易于理解、易于修改、更加可靠。 ### 七步循环：从想法到交付的完整流程 Every 这家公司同时在开发六款产品——Cora、Monologue、Proof、Sparkle、Spiral，以及内容平台 Every.to。

这么多产品，主要依靠单人工程团队来支撑。能够做到这一点，靠的是一套七步循环流程： 想点子 → 聊清楚 → 写计划 → 动手干 → 找毛病 → 打磨好 → 记下来 → 再来一轮 这七步可分为三个阶段： - **开头**：由人来决定做什么 - **中间**：AI 负责编写代码、测试、审查、准备提交 - **结尾**：由人判断是否达到要求，系统是否学到了新内容 当然，并非每次都必须严格走完七个步骤。如果你已经明确要做什么，可以跳过“想点子”；如果 bug 很明显，直接修复即可；如果是后端改动，“打磨”环节可以适当简化。关键在于将精力集中在最重要的决策上，并让系统记住这些决策，下次直接复用。 **第一步：想点子**。当你脑中只有一个模糊的想法，不确定该做什么时，就从这里开始。AI 会帮你把想法转化为候选清单，它会检索代码库、分析用户反馈、梳理痛点，从多个角度生成一系列点子，然后协助你筛选出最值得执行的方向。 **第二步：聊清楚**。有了一个不错的点子后，下一步是把它聊透彻。AI 会像产品经理一样向你提问：这是给谁用的？要解决什么问题？有什么限制条件？边界情况有哪些？期望完成后的样子是什么？聊完之后，你会得到一份清晰的需求文档。 **第三步：写计划**。需求明确后，接下来要规划如何实施。AI 会同时启动多个“研究员”：一个研究你的代码库，一个查阅框架文档，一个寻找行业最佳实践。然后将这些信息整合成一份实施计划，明确告知你需要修改哪些文件、按照什么顺序修改、以及如何进行验证。 **第四步：动手干**。计划撰写完毕，AI 开始执行。它会创建一个隔离的工作环境（避免影响主代码库），按照计划逐步实施，每完成一步就运行测试进行验证。你无需紧盯每一行代码，只需信任计划即可。 **第五步：找毛病**。代码写完后，先别急着发布，让 AI 帮你查找问题。这一步比较特别：AI 会派出十几个“审查员”，从不同角度检查问题——安全审查员负责检查漏洞，性能审查员负责排查性能瓶颈，测试审查员负责评估测试覆盖率。它们并行工作，比单人审查全面得多。发现的问题会按严重程度排序：P1 必须修复，P2 应该修复，P3 最好修复。 **第六步：打磨迭代**。功能已经可用，但使用体验是否到位？这一步是将“能用”提升为“好用”。让 AI 启动应用，你像真实用户一样体验一遍，检查速度是否流畅、动画是否顺滑、文案是否清晰、空状态是否友好。发现任何问题都可以告诉 AI 进行修改。 **第七步：记下来——最重要的一步**。前六步完成后，你获得了一个功能。但第七步完成后，你获得的是一个能更好地开发功能的系统。这一步需要将经验记录下来：哪些方法有效、哪些地方踩过坑、下次如何避免。这些记录会被 AI 保存，下次遇到类似任务时自动调用。这就是“复合”的理念：每一次积累，都让下一次更轻松。 ### 系统全貌：51 个 Agent 和 35 个 Skill 复合工程的具体实现，是基于核心理念整理出的一整套 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 中，可以通过插件市场安装；在 Cursor 中，在聊天窗口输入 `/add-plugin compound-engineering` 即可；Codex 也有对应的安装命令。其他工具如 GitHub Copilot、Gemini、Kiro 等，可以前往项目主页查看文档。 安装完成后，插件会在你的项目中创建一些文件：`CLAUDE.md`（或 `AGENTS.md`），存放你的偏好和项目规则；`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`**：记录经验。完成一项任务后，用这个命令将经验存入知识库。 - **`/lfg`**：一步到位。如果你想省事，直接用这个命令描述你想要什么，AI 会帮你完成从计划到 PR 的全流程。例如输入“`/lfg 在设置页面添加深色模式切换`”，AI 就会自行研究、规划、编写代码、审查、修复问题，最后交给你一个 PR。 ### 与时俱进的观念 AI 时代已经到来，一些传统软件时代的观念值得重新审视。 **“代码必须自己写”**：做好一个软件，核心要求是写出好代码——干净、可维护、解决正确的问题。至于这些代码是你敲出来的还是 AI 生成的，其实并不重要。 **“每一行都得自己审”**：手动审查是保证质量的一种方式，但并非唯一方式。AI 审查系统可以发现同样的问题，而且更加全面。如果你不信任 AI 的结果，应该去改进系统，而不是把所有事情都揽在自己身上。 **“第一次就得做好”**：根据作者团队的经验，AI 第一次尝试有 **90%** 的废品率。第二次依然有 **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 工具每天使用，先让它解释代码，再编写测试和配置文件，每次都要审查结果。 - **从 1 到 2**：开启 agent 模式让 AI 能够修改文件，从小任务开始，逐步建立信任。 - **从 2 到 3 是关键**：学会投资规划，将需求、方法、边界情况都写清楚，让 AI 去实现，你只看 PR。 - **从 3 到 4**：不再写详细指令，只描述最终结果。 - **从 4 到 5**：将执行迁移到云端，实现并行运行。 ### 几个重要习惯 **把你的品味写下来**。每个代码库都带有创建者的“品味”——命名习惯、错误处理方式、测试方法。但这些品味通常只存在于优秀工程师的大脑里。解决方案：将这些偏好写下来，放到 `CLAUDE.md` 中。AI 每次启动都会读取这个文件，逐渐学会你喜欢的风格。时间长了，AI 写出的代码你一看就满意，无需反复修改。 **80% 规划，20% 动手**。听起来反直觉，但这是事实。将 80% 的时间花在规划和审查上，只花 20% 在执行上。因为好的规划能让执行变得更小、更快、更准。好的审查能发现模式问题，而不只是语法错误。 **别怕放手**。很多开发者不敢让 AI 独立工作，总觉得不放心。但放手不是放弃控制，而是将控制编码成规则、约束和审查流程。这些东西比人工盯梢具有更好的扩展性。 **计划比代码更重要**。以前是先写代码再写文档，现在应该反过来：先写计划，再让 AI 写代码。计划是 AI 生成、测试、验证代码的依据。在纸上修正想法，比在代码里修复 bug 要经济得多。 ### 与 Superpowers 的对比 说到这里，就要对比一下另一个面向编程智能体的方法论框架——**Superpowers**。两者都致力于系统化 AI 辅助开发流程，但设计思想和实现方式存在显著差异。 从核心设计思想来看，复合工程的隐喻是“复利”——每一次积累都让下一次更容易，驱动力来自经验的持续积累，知识库会随着使用不断增长。哲学底色是务实主义：能用就行，渐进改良，90% 的废品率是过程而非失败。Superpowers 的核心则是“系统化优于临时方案”，驱动力来自流程的强制执行，技能自动触发而非建议。哲学底色是工程主义：强调 TDD、证据优于声明、复杂性减少。对人的角色定位也不同：复合工程让人定方向、审 PR、点合并；Superpowers 在关键决策点保留人工监督，但更强调流程纪律。 流程设计上，复合工程的七步循环有一个独特的“复利”闭环：最后一步“记经验”会将积累写入知识库，下次自动调出。还有一个专门的“打磨好”步骤，关注从“能用”到“好用”的 UX 层面。Superpowers 的七阶段是：头脑风暴 → Git 工作树 → 编写计划 → 执行计划 → TDD → 代码审查 → 完成分支。它没有“记经验”和“打磨好”这两个环节，但强制要求 TDD，并且有明确的 Git worktree 隔离和分支完成决策流程。 在实现层面，技能触发机制完全不同。复合工程是命令驱动的——用户主动输入 `/ce-xxx` 触发，有 30 多个快捷命令，用户需要知道用哪个。Superpowers 则是自动触发——技能会自动激活，智能体在执行任何任务前都会检查相关技能，无需用户记忆命令。不过这种方式也可能因为提示词的问题导致无法触发，在日常工作中难以察觉。 代码审查方式也不一样。复合工程派出十几个“审查员”并行工作，从安全、性能、测试、架构等角度挑毛病，最后按严重程度排序。从体验角度来看，这种把具体事务都做好的感觉确实比较省心。Superpowers 采用两阶段审查：先检查规格符合性，再检查代码质量，更结构化，但审查效果完全依赖大模型的好坏，没有统一的标准，实际项目中容易走偏。 知识积累是复合工程最核心的差异化。它有专门的 `/ce-compound` 命令记录经验，存到 `docs/solutions/` 按类别归档，下次做类似事情时自动调出。Superpowers 没有对应的自动化经验积累机制。产品打磨也是复合工程独有的，第六步“打磨好”会关注从“能用”到“好用”的体验层面。Superpowers 更关注代码质量和工程正确性，不涉及 UX 层面的打磨。 **一句话总结**：复合工程是“让每次工作都为下一次铺路”的复利哲学；Superpowers 是“用流程纪律保证质量”的工程哲学。前者更软（经验、品味、打磨），后者更硬（TDD、强制、证据）。其实，两种思路并非不可调和，根据团队和项目特点灵活选择才是正解。 项目地址：https://github.com/EveryInc/compound-engineering-plugin