一个人管理5款产品，80%时间不写代码？Every的复利工程 · AI HOT
小互 @xiaohu 精选 81
2026-06-30 11:23 ·2小时前
精选理由 Every把内部单人维护5款产品的方法论和插件开源了，14个AI同时审代码、40多个研究agent做计划，是目前公开的多agent并行工程里数字最具体的参考之一，做AI辅助开发的可以直接上手抄。
AI 摘要 媒体软件公司Every公开「复利工程」方法论，以单人工程团队维护5款产品。核心是四步循环：Plan→Work→Review→Compound，其中Compound将每次解决问题的解法写入CLAUDE.md和docs/solutions/，使AI下次自动避坑。工程师80%时间花在Plan和Review，仅20%用于写代码。配套开源插件支持Claude Code等，含26个专项agent、23条工作流命令、13项技能，可零配置使用。/workflows:review一次并发14个agent审查代码，/workflows:plan在ultrathink模式下可并发40多个研究agent。
智能体 教程/实践 编码 部署/工程
小互 @xiaohu · X 精选 81
2026-06-30 11:23 · 2小时前
在 X 看原推 · x.com 精选理由 Every把内部单人维护5款产品的方法论和插件开源了，14个AI同时审代码、40多个研究agent做计划，是目前公开的多agent并行工程里数字最具体的参考之一，做AI辅助开发的可以直接上手抄。
AI 摘要 媒体软件公司Every公开「复利工程」方法论，以单人工程团队维护5款产品。核心是四步循环：Plan→Work→Review→Compound，其中Compound将每次解决问题的解法写入CLAUDE.md和docs/solutions/，使AI下次自动避坑。工程师80%时间花在Plan和Review，仅20%用于写代码。配套开源插件支持Claude Code等，含26个专项agent、23条工作流命令、13项技能，可零配置使用。/workflows:review一次并发14个agent审查代码，/workflows:plan在ultrathink模式下可并发40多个研究agent。
✕「代码是自我表达」 代码从来不属于你个人，它属于团队、产品和用户。
第四步具体怎么做：把解法变成系统的记忆 前三步产出的是「一个功能」。第四步 Compound 产出的是「一个每次都能把功能做得更好的系统」。它落到地上是四个动作：
记录解法--什么管用、什么没用、可复用的点是哪个。 加元数据--用 YAML frontmatter 打标签，方便日后检索。 更新 CLAUDE.md--把新模式写进 agent 每次启动都读的文件。 复利的来源：传统开发停在第三步审查，复利工程多走这一步--把刚解决的问题写进系统。这一步不产出代码，产出的是「系统下次自动避开同类问题」的能力。效率差距就来自这里。
打个比方：CLAUDE.md 就是放在项目根目录的「AI 操作手册」，agent 每次启动都会先读它。它像新员工入职必读的 SOP：每当有人解决了一个之前没遇到的问题，就往里加一条规则，下一个人来就自动懂了，不用再踩一遍同样的坑。
下面这个对照，能直观看到这条规则攒下来之后的差别：
✕ 没有积累：agent 不知道这个坑，你和它一起调试、定位、修好。修完，Compound 把「为什么会出、怎么避开」写进 CLAUDE.md，并存一份带 YAML 标签的文档进 docs/solutions/。这一次多花了点时间记录。 ✓ 系统已经记住了：agent 一启动就读到那条规则，docs/solutions/ 里也能搜到上次那份解法。于是在 Plan 阶段它就主动绕开了同类问题，根本走不到出 bug 那一步。前面那次记录的时间，在这里连本带利赚回来。 每完成一次 Compound，CLAUDE.md 就多一条知识：迭代 1 → 1 条，迭代 3 → 3 条，迭代 5 → 8 条，系统越用越聪明。docs/solutions/ 就这样攒成一座机构知识库--Every 用 /workflows：compound 跑这一步，并发派出六个子 agent（理解问题、抽取解法、找相关旧文档互链、写「怎么避免复发」、做分类标签、排版成文档），日后任何一次会话都能自动翻到过去的解法。
14 个 AI 同时帮你审代码 一条 PR 进来，/workflows：review 会一次性派出 14 个专项 agent，同时开跑，每个只盯一个维度，最后合并成一份按 P1 / P2 / P3 排好优先级的清单。
security-sentinel（安全）- 扫 OWASP Top 10、注入攻击、认证与越权。 performance-oracle（性能）- 揪 N+1 查询、缺索引、可缓存点、算法瓶颈。 architecture-strategist（架构）- 评估系统设计、组件边界、依赖方向。 pattern-recognition-specialist（架构）- 识别设计模式、反模式、代码坏味道。 data-integrity-guardian（数据）- 校验数据库迁移、事务边界、引用完整性。 data-migration-expert（数据）- 检查 ID 映射、回滚安全、生产数据校验。 code-simplicity-reviewer（质量）- 执行 YAGNI，揪多余复杂度。 kieran-rails-reviewer（质量）- Rails 规范、模型与控制器职责。 kieran-python-reviewer（质量）- PEP 8、类型注解、Pythonic 写法。 kieran-typescript-reviewer（质量）- 类型安全、现代 ES、整洁架构。 dhh-rails-reviewer（质量）- 37signals 风格：简单优先于抽象。 deployment-verification-agent（部署）- 上线前检查单、上线后验证、回滚预案。 julik-frontend-races-reviewer（前端）- 揪 JS 和 Stimulus 里的竞态。 agent-native-reviewer（Agent-native）- 确保功能不只人能用，agent 也能用。 顺带科普 · N+1 查询：查一张 100 条的列表，写法不对就变成每条再单独查一次，一共 101 次请求。像去超市买 10 样东西却跑了 11 趟--先去看看有什么（1 趟），再每样单独取一次（10 趟）。
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 逐条决定。
插件里有什么，装上怎么用 整套流程打包成一个插件，零配置装上就能用，支持 Claude Code，也实验性支持 OpenCode 和 Codex。
26 个专项 agent：每个只精一件事--14 个 review 专家，外加研究型、设计型、自动化、文档型。 23 条工作流命令：主循环 plan / work / review / compound，加一批实用工具命令。 13 项技能：即取即用的领域知识，比如 agent-native 架构技能、风格指南技能。 四个目录各管一摊：CLAUDE.md（agent 每次启动必读的操作手册）、docs/solutions/（每个解决过的问题存成可搜索文档）、docs/plans/ 与 brainstorms/（计划产出）、todos/（review 查出的问题带优先级）。
> claude /plugin marketplace add https：//github.com/EveryInc/every-marketplace claude /plugin install compound-engineering
还有个一键到底的 /lfg：你只描述功能，它把计划 → 深化计划 → 执行 → 审查 → 修问题 → 浏览器测试 → 录功能演示 → 固化整条流水线串起来自动跑，全程派出 50 多个 agent，最后交你一个能直接合并的 PR，中途只在计划批准处停一下。
关键数字：并发规模到底有多大 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。
五款产品 Cora、Monologue、Sparkle、Spiral，加上官网 Every.to，每个产品的工程团队基本只有一个人。撑住这套规模的不是更长的工时，而是一个四步循环里被大多数团队省掉的最后一步。
◆ 为什么值得看：Every 把平时只在内部跑的东西开源了，包括 14 个 AI 同时审一段代码、计划阶段并发 40 多个研究 agent，外加 26 个专项 agent。这是目前公开的多 agent 并行工程实践里，数字最具体的开源参考之一。
代码越写越难碰，根子在哪 大多数代码库随时间越来越难维护，原因不复杂：每加一个功能，就往系统里注入一份新的复杂度，新功能要和所有旧功能「谈判」。十年下来，团队花在跟历史代码较劲上的时间，比花在造新东西上的还多，代码变得越来越难懂、难改、难信任。
复利工程把这条曲线反过来。功能不再是往系统里加负担，而是教会系统一项新本领；修一个 bug，顺手消掉未来一整类同类 bug；一个解法被固化下来，就变成下次能直接复用的工具。迭代越多，系统越好用。
四步循环：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 固化：把解法抽成可复用的知识写回系统--下面一节专门讲。 ✕「代码必须手写」 你的职责是产出可维护、解决对问题的好代码，谁敲键盘不重要。 ✕「第一版就该写好」 他们的经验里第一版 95% 是垃圾、第二版还有 50%，这是过程，目标是迭代够快让第三版落地比第一版还省时。 ✕「不亲手敲就学不到」 今天理解比肌肉记忆重要，审 10 个 AI 实现比手敲 2 个学到的模式更多。 ✕「代码是自我表达」 代码从来不属于你个人，它属于团队、产品和用户。
第四步具体怎么做：把解法变成系统的记忆 前三步产出的是「一个功能」。第四步 Compound 产出的是「一个每次都能把功能做得更好的系统」。它落到地上是四个动作：
记录解法--什么管用、什么没用、可复用的点是哪个。 加元数据--用 YAML frontmatter 打标签，方便日后检索。 更新 CLAUDE.md--把新模式写进 agent 每次启动都读的文件。 复利的来源：传统开发停在第三步审查，复利工程多走这一步--把刚解决的问题写进系统。这一步不产出代码，产出的是「系统下次自动避开同类问题」的能力。效率差距就来自这里。
打个比方：CLAUDE.md 就是放在项目根目录的「AI 操作手册」，agent 每次启动都会先读它。它像新员工入职必读的 SOP：每当有人解决了一个之前没遇到的问题，就往里加一条规则，下一个人来就自动懂了，不用再踩一遍同样的坑。
下面这个对照，能直观看到这条规则攒下来之后的差别：
✕ 没有积累：agent 不知道这个坑，你和它一起调试、定位、修好。修完，Compound 把「为什么会出、怎么避开」写进 CLAUDE.md，并存一份带 YAML 标签的文档进 docs/solutions/。这一次多花了点时间记录。 ✓ 系统已经记住了：agent 一启动就读到那条规则，docs/solutions/ 里也能搜到上次那份解法。于是在 Plan 阶段它就主动绕开了同类问题，根本走不到出 bug 那一步。前面那次记录的时间，在这里连本带利赚回来。 每完成一次 Compound，CLAUDE.md 就多一条知识：迭代 1 → 1 条，迭代 3 → 3 条，迭代 5 → 8 条，系统越用越聪明。docs/solutions/ 就这样攒成一座机构知识库--Every 用 /workflows：compound 跑这一步，并发派出六个子 agent（理解问题、抽取解法、找相关旧文档互链、写「怎么避免复发」、做分类标签、排版成文档），日后任何一次会话都能自动翻到过去的解法。
14 个 AI 同时帮你审代码 一条 PR 进来，/workflows：review 会一次性派出 14 个专项 agent，同时开跑，每个只盯一个维度，最后合并成一份按 P1 / P2 / P3 排好优先级的清单。
security-sentinel（安全）- 扫 OWASP Top 10、注入攻击、认证与越权。 performance-oracle（性能）- 揪 N+1 查询、缺索引、可缓存点、算法瓶颈。 architecture-strategist（架构）- 评估系统设计、组件边界、依赖方向。 pattern-recognition-specialist（架构）- 识别设计模式、反模式、代码坏味道。 data-integrity-guardian（数据）- 校验数据库迁移、事务边界、引用完整性。 data-migration-expert（数据）- 检查 ID 映射、回滚安全、生产数据校验。 code-simplicity-reviewer（质量）- 执行 YAGNI，揪多余复杂度。 kieran-rails-reviewer（质量）- Rails 规范、模型与控制器职责。 kieran-python-reviewer（质量）- PEP 8、类型注解、Pythonic 写法。 kieran-typescript-reviewer（质量）- 类型安全、现代 ES、整洁架构。 dhh-rails-reviewer（质量）- 37signals 风格：简单优先于抽象。 deployment-verification-agent（部署）- 上线前检查单、上线后验证、回滚预案。 julik-frontend-races-reviewer（前端）- 揪 JS 和 Stimulus 里的竞态。 agent-native-reviewer（Agent-native）- 确保功能不只人能用，agent 也能用。 顺带科普 · N+1 查询：查一张 100 条的列表，写法不对就变成每条再单独查一次，一共 101 次请求。像去超市买 10 样东西却跑了 11 趟--先去看看有什么（1 趟），再每样单独取一次（10 趟）。
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 逐条决定。
插件里有什么，装上怎么用 整套流程打包成一个插件，零配置装上就能用，支持 Claude Code，也实验性支持 OpenCode 和 Codex。
26 个专项 agent：每个只精一件事--14 个 review 专家，外加研究型、设计型、自动化、文档型。 23 条工作流命令：主循环 plan / work / review / compound，加一批实用工具命令。 13 项技能：即取即用的领域知识，比如 agent-native 架构技能、风格指南技能。 四个目录各管一摊：CLAUDE.md（agent 每次启动必读的操作手册）、docs/solutions/（每个解决过的问题存成可搜索文档）、docs/plans/ 与 brainstorms/（计划产出）、todos/（review 查出的问题带优先级）。
> claude /plugin marketplace add https：//github.com/EveryInc/every-marketplace claude /plugin install compound-engineering
还有个一键到底的 /lfg：你只描述功能，它把计划 → 深化计划 → 执行 → 审查 → 修问题 → 浏览器测试 → 录功能演示 → 固化整条流水线串起来自动跑，全程派出 50 多个 agent，最后交你一个能直接合并的 PR，中途只在计划批准处停一下。
关键数字：并发规模到底有多大 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。
小互@xiaohu · X