深度 · 小互解读
被所有团队跳过的第四步，才是 AI 工程的关键
Every 单人团队运营 5 款产品，核心是每次完成功能后多做的一步：把解法存进系统，让 AI 下次自动避坑。
速览
Every 用「复利工程」（Compound Engineering）方法论，以基本单人的工程团队维护旗下 5 款产品，核心是 Plan → Work → Review → Compound 四步循环。
传统工程走到 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 团队自述其「复利工程」方法论与自家开源插件的实践，文中的并发规模、时间分配、产品数量都是官方口径。下面只讲它怎么运作、每个数字代表什么。
1 背景
一个人撑五款产品，怎么做到的
Every 团队最近公开了一套叫「复利工程」（Compound Engineering）的方法论，外加一个配套的开源插件，讲他们怎么用基本是单人配置的工程团队，同时维护旗下五款产品。
五款产品 Cora、Monologue、Sparkle、Spiral，加上官网 Every.to，每个产品的工程团队基本只有一个人。撑住这套规模的不是更长的工时，而是一个四步循环里被大多数团队省掉的最后一步。
◆
为什么值得看：Every 把平时只在内部跑的东西开源了，包括 14 个 AI 同时审一段代码 、计划阶段并发 40 多个 研究 agent，外加 26 个 专项 agent。这是目前公开的多 agent 并行工程实践里，数字最具体的开源参考之一。
2 问题
代码越写越难碰，根子在哪
大多数代码库随时间越来越难维护，原因不复杂：每加一个功能，就往系统里注入一份新的复杂度，新功能要和所有旧功能「谈判」。十年下来，团队花在跟历史代码较劲上的时间，比花在造新东西上的还多，代码变得越来越难懂、难改、难信任。
复利工程把这条曲线反过来。功能不再是往系统里加负担，而是教会系统一项新本领；修一个 bug，顺手消掉未来一整类同类 bug；一个解法被固化下来，就变成下次能直接复用的工具。迭代越多，系统越好用。
传统：越改越费劲
复利工程：越用越顺手
功能 / 迭代越来越多 →
改动一处要花的力气 →
同一条横轴（功能 / 迭代越来越多），两种走向：传统代码库改一处越来越费劲，复利工程让每次迭代都把系统垫得更顺手。
3 主循环
四步循环：80% 的时间根本不是在写代码
支撑这套规模的，是一个四步循环：Plan（计划）、Work（执行）、Review（审查）、Compound（固化），然后重复。不管你是花五分钟修个 bug，还是花几天做个功能，走的都是这四步，只是每步花的时间多少不同。
前三步任何开发者都熟，第四步 Compound 才是复利工程和普通工程的分界线。跳过它，你做的就只是「有 AI 助手的传统工程」。
Plan
计划
Work
执行
Review
审查
Compound
固化
传统工程到此为止 ✕
复利工程多走这一步
重复：下一轮自动带着上一轮固化的知识 ↻
四步在深绿轨道上依次流动。传统工程到 Review 收手，复利工程多走 Compound 一步，把这一轮学到的东西留给下一轮。
反直觉的地方：写代码只占两成时间
Plan 和 Review 加起来占工程师 80% 的时间，真正动手写（Work）加上固化（Compound）只占 20%。大部分思考发生在代码被写出来之前和之后。
四步各自在做什么 / 几个 Every 建议丢掉的旧观念
Plan 计划： 把想法变成蓝图。弄清需求和约束、研究代码库里同类功能怎么实现、查框架文档和最佳实践、设计方案、再校验方案是否站得住。
Work 执行： 先用 git worktree（你仓库的一个隔离沙盒副本，多个任务可以各开一份并行跑、互不干扰）开出隔离环境，agent 按计划逐步实现，每改一处就跑测试、linting（自动代码检查）和类型检查。
Review 审查： 多个专项 agent 并行审，把问题标成 P1（必须修）/ P2（应该修）/ P3（可以修），修完再校验，并记录这次出了什么问题。
Compound 固化： 把解法抽成可复用的知识写回系统，下面一节专门讲。
Every 还列了几条建议丢掉的旧观念：「代码必须手写」（你的职责是产出可维护、解决对问题的好代码，谁敲键盘不重要）；「第一版就该写好」（他们的经验里第一版 95% 是垃圾、第二版还有 50%，这是过程，目标是迭代够快让第三版落地比第一版还省时）；「不亲手敲就学不到」（今天理解比肌肉记忆重要，审 10 个 AI 实现比手敲 2 个学到的模式更多）；「代码是自我表达」（代码从来不属于你个人，它属于团队、产品和用户）。
4 第四步 · 核心
第四步具体怎么做：把解法变成系统的记忆
前三步（计划、执行、审查）产出的是「一个功能」。第四步 Compound 产出的是「一个每次都能把功能做得更好的系统」。它落到地上是四个动作。
① 记录解法 什么管用、什么没用、可复用的点是哪个
→
② 加元数据 用 YAML frontmatter 打标签，方便日后检索
→
③ 更新 CLAUDE.md 把新模式写进 agent 每次启动都读的文件
→
④ 验证学到了 下次它能自动接住同类问题吗
第二步里的 YAML frontmatter，是文档顶部的一段元数据标签（标题、分类、关键词），让这条解法日后能被按条件搜到、精确取回，而不是写完就埋进一堆文档里找不着。
复利的来源
传统开发停在第三步审查，复利工程多走这一步：把刚解决的问题写进系统。这一步不产出代码，产出的是「系统下次自动避开同类问题」的能力。效率差距就来自这里。
打个比方
CLAUDE.md 就是放在项目根目录的「AI 操作手册」，agent 每次启动都会先读它。它像新员工入职必读的 SOP 手册：每当有人解决了一个之前没遇到的问题，就往里加一条规则，下一个人来就自动懂了，不用再踩一遍同样的坑。
下面这个切换，能直观看到这条规则攒下来之后的差别：
每完成一次 Compound，CLAUDE.md 就多一条知识，系统越用越聪明：
docs/solutions/ 怎么攒成一座机构知识库
每个解决过的问题都被存成一份带 YAML frontmatter 的 markdown，自动归类打标签。Every 用 /workflows:compound 命令跑这一步，它会并发派出六个子 agent：理解问题的、抽取解法的、找出相关旧文档并互链的、写「怎么避免复发」的、做分类标签的、最后排版成文档的。日后任何一次会话，都能自动从这堆文档里翻到过去的解法，而不用靠某个资深工程师记在脑子里。
5 并发审查
14 个 AI 同时帮你审代码
一条 PR（代码改动提交）进来，/workflows:review 这条命令会一次性派出 14 个专项 agent，同时开跑，每个只盯一个维度：安全、性能、架构、数据、代码质量、框架规范等。它们各查各的，最后把结果合并成一份按 P1（必须修）/ P2（应该修）/ P3（可以修）排好优先级的清单。
一条
PR
14 个专项 agent 同时开跑
1
2
3
4
5
6
7
8
9
10
11
12
13
14
一条 PR 同时辐射给 14 个 agent，颜色对应下面的维度分组。它们并发跑，不是排队跑。
01 security-sentinel · 安全
扫 OWASP Top 10（公认最常被利用的十类网络安全漏洞）、注入攻击、认证与越权。
02 performance-oracle · 性能
揪 N+1 查询、缺索引、可缓存点、算法瓶颈。
03 architecture-strategist · 架构
评估系统设计、组件边界、依赖方向。
04 pattern-recognition-specialist · 架构
识别设计模式、反模式、代码坏味道。
05 data-integrity-guardian · 数据
校验数据库迁移、事务边界、引用完整性。
06 data-migration-expert · 数据
检查 ID 映射、回滚安全、生产数据校验。
07 code-simplicity-reviewer · 质量
执行 YAGNI（别为可能用到的功能提前写代码），揪多余复杂度。
08 kieran-rails-reviewer · 质量
Rails 规范、Turbo Streams、模型与控制器职责划分。
09 kieran-python-reviewer · 质量
PEP 8 规范、类型注解、Pythonic 写法。
10 kieran-typescript-reviewer · 质量
类型安全、现代 ES 写法、整洁架构。
11 dhh-rails-reviewer · 质量
37signals 风格：简单优先于抽象。
12 deployment-verification-agent · 部署
生成上线前检查单、上线后验证步骤、回滚预案。
13 julik-frontend-races-reviewer · 前端
揪 JavaScript 和 Stimulus 控制器里的竞态。
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 干。
6 插件
插件里有什么，装上怎么用
整套流程打包成一个插件，装上就能用，零配置。支持 Claude Code，也实验性支持 OpenCode 和 Codex。
26
专项 agent
每个只精一件事：14 个 review 专家，外加研究型、设计型、自动化、文档型。
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
/lfg ：你只描述功能，它把整条流水线串起来自动跑，计划 → 深化计划 → 执行 → 审查 → 修问题 → 浏览器测试 → 录功能演示 → 固化，全程派出 50 多个 agent，最后交给你一个能直接合并的 PR。中途只在计划批准处停一下。
7 数字
关键数字：并发 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。