深度 · 小互解读

一个人管理并开发5款产品，且80%的时间并不在写代码——这一切，靠的是“复利工程”中的关键一步。

被绝大多数团队跳过的第四步，才是AI工程的核心密码。

先揭晓答案：Every团队采用「复利工程」方法论，以近乎单人配置的工程团队，同时运维旗下5款产品。核心秘密并不是什么神奇工具，而是在每次完成功能之后，多执行了一件事——将解决方案存储到系统里，让AI在下次自动避开同样的坑。

速览

• Every的「复利工程」以 Plan → Work → Review → Compound 四步循环为骨架，支撑单人团队维护5款产品。
• 传统工程走到Review就停止了。第四步Compound才是真正的分水岭——它将每次解决的问题转化为系统知识，让AI下一次自动规避同类错误。
• 这套方法要求工程师80%的时间花在Plan和Review上，只有20%用于实际写代码。
• 配套插件已开源，支持 Claude Code / OpenCode / Codex，内含26个专项Agent、23条工作流命令、13项技能，零配置即可使用。
• /workflows:review 一次调用并发14个专项Agent审查代码；/workflows:plan 开启ultrathink模式可并发40多个研究Agent。

需要说明的是：本文是Every团队对其「复利工程」方法论与开源插件的自述，文中提到的并发规模、时间分配、产品数量均为官方口径。下面只讲它具体如何运作、每个数字意味着什么。

▸ 先认识下Every

Every（every.to）是一家2020年成立的媒体+软件公司，CEO Dan Shipper。它每天发布一份讲述「科技下一步」的付费newsletter，同时亲自开发软件产品——文中的Cora、Monologue、Sparkle、Spiral均出自其手，另外还提供AI课程与咨询服务。所以「复利工程」绝非纸上谈兵，而是一家既写代码又做内容、天天深耕AI的公司从实战中积累出的方法论。

01 一个人撑五款产品，怎么做到的

Every团队近期公开了一套名为「复利工程」（Compound Engineering）的方法论，并附有一个配套的开源插件，阐释了他们如何以基本单人配置的工程团队，同时维护旗下五款产品。

Cora、Monologue、Sparkle、Spiral，加上官网Every.to，每个产品的工程团队基本只有一个人。支撑这一规模的并非更长的工时，而是一个四步循环中被大多数团队省略的最后一步。

为什么值得关注——Every把平时仅在内部使用的工具开源了，包括14个AI同时审查一段代码、计划阶段并发40多个研究Agent，外加26个专项Agent。这是目前公开的多Agent并行工程实践中，数字最具体、参考价值最高的开源项目之一。

02 代码越写越难碰，根子在哪

大多数代码库随着时间推移越来越难维护，原因并不复杂：每增加一个功能，就往系统里注入一份新的复杂度，新功能必须与所有旧功能“谈判”。十年下来，团队花费在与历史代码“较劲”上的时间，远多于创造新功能的时间，代码变得难以读懂、难以修改、难以信任。

复利工程将这条曲线彻底翻转。功能不再是给系统增加负担，而是教会系统一项新本领；修复一个bug，顺便消除未来一整类同类bug；一个解法被固化下来，就变成下次可直接复用的工具。迭代越多，系统越好用。

传统：改一处越来越费劲。复利工程：越来越顺手。同一条横轴（功能/迭代越来越多），两种走向：传统代码库改一处越来越费劲，复利工程让每次迭代都把系统垫得更顺手。

03 四步循环：80%的时间根本不是在写代码

支撑这套规模的是一个四步循环：Plan（计划）、Work（执行）、Review（审查）、Compound（固化），然后重复。不论你花五分钟修复一个bug，还是花几天开发一个功能，都遵循这四步，只是每步耗时不同。

前三步任何开发者都熟悉，但第四步Compound才是复利工程与普通工程的分界线。跳过这一步，你做的只是“有AI助手的传统工程”。

传统工程到Review就收手，复利工程则多走Compound一步，把这一轮学到的东西留给下一轮。

反直觉的地方：写代码仅占两成时间

Plan和Review合计占工程师80%的时间，真正动手写（Work）加上固化（Compound）只占20%。大部分思考发生在代码被写出来之前和之后。

四步各自在做什么

Plan（计划）——将想法转化为蓝图。弄清需求与约束、研究代码库中类似功能的实现方式、查阅框架文档和最佳实践、设计方案、再校验方案是否站得住脚。

Work（执行）——先用git worktree创建隔离环境，Agent按计划逐步实现，每改一处就运行测试、Linting和类型检查。

Review（审查）——多个专项Agent并行审查，将问题标记为 P1（必须修复）/ P2（应该修复）/ P3（可以修复），修复后再次校验，并记录此次出现的问题。

Compound（固化）——将解法抽成可复用的知识写回系统，下面一节专门展开。

几个Every建议丢弃的旧观念

• ✕ 「代码必须手写」——你的职责是产出可维护、能解决正确问题的好代码，谁敲键盘并不重要。
• ✕ 「第一版就该写好」——他们的经验里，第一版95%是垃圾，第二版还有50%是垃圾，这是过程本身。目标是迭代足够快，让第三版落地比第一版还省时。
• ✕ 「不亲手敲就学不到」——在今天，理解比肌肉记忆更重要。审查10个AI实现比手敲2个学到的模式更多。
• ✕ 「代码是自我表达」——代码从来不属于个人，它属于团队、产品和用户。

04 第四步具体怎么做：把解法变成系统的记忆

前三步（计划、执行、审查）产出的是“一个功能”。第四步Compound产出的是“一个每次都能把功能做得更好的系统”。它落地为四个动作。

1. 记录解法——什么管用、什么没用、可复用的点是哪个。
2. 添加元数据——用YAML frontmatter打标签，方便日后检索。
3. 更新CLAUDE.md——把新模式写入Agent每次启动都会读取的文件。
4. 验证学习效果——下次它能自动接住同类问题吗？

顺带科普·YAML frontmatter

它是文档顶部的一段元数据标签（标题、分类、关键词），让这条解法日后能按条件被搜索、精确取回，而不是写完就埋在一堆文档里找不到。

复利的来源

传统开发停在第三步审查，复利工程多走这一步：将刚解决的问题写入系统。这一步不产出代码，产出的是“系统下次自动避开同类问题”的能力。效率差距正源于此。

打个比方·CLAUDE.md

CLAUDE.md就是放在项目根目录的“AI操作手册”，Agent每次启动都会先读它。它像新员工入职必读的SOP手册：每当有人解决了一个之前没人遇到的问题，就往里加一条规则，下一个人来就自动懂，不再需要踩同样的坑。

下面这个对照能直观地看到这条规则积累后的差别：

✕ 没有积累，纯靠现场排查——Agent不知道这个坑，你和它一起调试、定位、修复。修复后，Compound步骤将“为什么会出问题、如何避免”写入CLAUDE.md，并存一份带YAML标签的文档到docs/solutions/。这次多花了一点时间记录。

✓ 系统已经记住了——Agent一启动就读到了那条规则，docs/solutions/里也能搜到上次那份解法。于是在Plan阶段，它就主动绕开了同类问题，根本不会走到出bug那一步。前面那次记录的时间，在这里连本带利赚回来。

每完成一次Compound，CLAUDE.md就多一条知识，系统越用越聪明。

docs/solutions/如何积累成机构知识库

每个解决过的问题都被存成一份带YAML frontmatter的Markdown文件，自动归类并打标签。Every使用/workflows:compound命令完成这一步，它会并发派出六个子Agent，日后任何一次会话，都能自动从这堆文档中找到过去的解法，而无需依赖某个资深工程师的记忆。

/workflows:compound · 并发六个子Agent：1理解问题→2抽取解法→3找出相关旧文档并互链→4写“如何避免复发”→5做分类标签→6排版成文档

05 14个AI同时帮你审代码

一条PR进来，/workflows:review命令会一次性派出14个专项Agent，同时运行，每个只盯一个维度：安全、性能、架构、数据、代码质量、框架规范等。它们各查各的，最后将结果合并成一份按P1/P2/P3排好优先级的清单。

一条PR同时辐射给14个Agent，颜色对应维度分组（砖红=风险/数据完整，琥珀=性能/运维/前端，森林绿=架构/质量/Agent-native）。它们并发跑，不是排队跑。

1. 01 security-sentinel · 安全——扫描OWASP Top 10、注入攻击、认证与越权。
2. 02 performance-oracle · 性能——揪出N+1查询、缺少索引、可缓存点、算法瓶颈。
3. 03 architecture-strategist · 架构——评估系统设计、组件边界、依赖方向。
4. 04 pattern-recognition-specialist · 架构——识别设计模式、反模式、代码坏味道。
5. 05 data-integrity-guardian · 数据——校验数据库迁移、事务边界、引用完整性。
6. 06 data-migration-expert · 数据——检查ID映射、回滚安全、生产数据校验。
7. 07 code-simplicity-reviewer · 质量——执行YAGNI，揪出多余复杂度。
8. 08 kieran-rails-reviewer · 质量——Rails规范、Turbo Streams、模型与控制器职责划分。
9. 09 kieran-python-reviewer · 质量——PEP 8规范、类型注解、Pythonic写法。
10. 10 kieran-typescript-reviewer · 质量——类型安全、现代ES写法、整洁架构。
11. 11 dhh-rails-reviewer · 质量——37signals风格：简单优先于抽象。
12. 12 deployment-verification-agent · 部署——生成上线前检查清单、上线后验证步骤、回滚预案。
13. 13 julik-frontend-races-reviewer · 前端——揪出JavaScript和Stimulus控制器里的竞态。
14. 14 agent-native-reviewer · Agent-native——确保功能不仅人能用，Agent也能用。

顺带科普·N+1查询

02号Agent专盯的N+1查询，是数据库性能中的常见陷阱：查询一张100条的列表，写法不对就变成每条再单独查一次，一共101次请求。好比去超市买10样东西却跑了11趟，先去看看有什么（1趟），然后每样东西再单独去取一次（10趟）。

14路并发结果合并去重，归到一份带优先级的清单

• P1 · 必须修
  • 搜索查询有SQL注入漏洞（security-sentinel）
  • 创建用户缺少事务包裹（data-integrity-guardian）
• P2 · 应该修
  • 评论加载有N+1查询（performance-oracle）
  • 控制器里塞了业务逻辑（kieran-rails-reviewer）
• P3 · 可以修
  • 有一个未使用的变量（code-simplicity-reviewer）

清单出来之后怎么处理

/resolve_pr_parallel自动处理全部问题，先修P1再修P2，每个修复各自隔离运行，互不干扰，最后由你人工过一遍生成的改动。

如果想先筛选再修复，使用/triage：逐条让你决定批准（进入待办）、跳过（删除）或改优先级，批准的标记为status: ready，再交给/resolve_todo_parallel执行。

06 插件里有什么，装上怎么用

整套流程打包成一个插件，装上即可使用，零配置。支持Claude Code，同时实验性支持OpenCode和Codex。

• 26个专项Agent——每个只精通一件事：14个审查专家，外加研究型、设计型、自动化、文档型。
• 23条工作流命令——主循环命令（plan/work/review/compound）加一批实用工具命令。
• 13项技能——即取即用的领域知识，比如Agent-native架构技能、风格指南技能。

各个文件管什么

• CLAUDE.md — Agent每次启动必读的操作手册：偏好、约定、踩过的坑。
• docs/solutions/ — 每个解决过的问题存成可搜索文档，下次会话自动找到。
• docs/plans/ · brainstorms/ — /plan与/brainstorm的输出。
• todos/ — review查出的问题，带优先级和状态。

两行命令装好（Claude Code）

claude /plugin marketplace add https://github.com/EveryInc/every-marketplace
claude /plugin install compound-engineering

OpenCode / Codex安装命令

bunx @every-env/compound-plugin install compound-engineering –to opencode
bunx @every-env/compound-plugin install compound-engineering –to codex

一条命令跑完整条流水线

/lfg：你只需描述功能，它就把整条流水线串起来自动运行，全程派出50多个Agent，最后交给你一个可直接合并的PR。中途仅在计划批准处停一下。

计划 → 深化计划 → 执行 → 审查 → 修问题 → 浏览器测试 → 录功能演示 → 固化

07 关键数字：并发agent的规模到底有多大

将这套系统的规模落到几个具体数字上。

• 5款——Every用这套方法维护的产品数量，工程团队基本为单人配置。
• 80/20——计划+审查占工程师80%时间，执行+固化只占20%。
• 14个——/workflows:review一次调用同时运行的专项审查Agent数量。
• 40+个——/workflows:plan开ultrathink模式后派出的研究Agent数量。
• 26/23/13——插件包含的专项Agent数/工作流命令数/技能数。

「每一份工程工作，都应该让后续的工作更容易，而不是更难。」 ——Every《Compound Engineering》

本文为Every团队自述其「复利工程」方法论与开源插件实践，文中并发规模、时间分配、产品数量均为其官方口径。

原文：Every《Compound Engineering》every.to/guides/compound-engineering

插件开源地址：github.com/EveryInc/compound-engineering-plugin