一个人维护 5 款产品：Every 把代码之外的功夫开源了
Every 以基本单人的工程团队维护 5 款产品，80% 时间不写代码。他们刚把「复利工程」方法论和插件完整开源——14 个 AI 并行审代码、40 个研究助手做计划，是目前公开的多智能体并行工程中最具体的参考。
2026 年 6 月，媒体软件公司 Every（every.to）做了一件不寻常的事：他们把内部靠单人工程团队维护五款产品的方法论，连同配套的开源插件，完整公开了。这套方法论叫「复利工程」（Compound Engineering），核心逻辑简单到反直觉——工程师 80% 的时间不在写代码，而在计划和审查上。开源插件在 GitHub 上已获得 14,000+ star，是目前公开可参考的多智能体并行工程实践中数据最具体的一个。
Kieran Klaassen，Every 旗下邮件产品 Cora 的负责人，是这套方法论的作者。他在 2026 年 5 月更新的最新版复利工程指南里把流程从四步扩展到了八步。而更早的 4 月，他在另一篇文章中透露自己正同时运行 44 个 AI 智能体，管理方式出奇简单——每个就是一个文件夹加上一份 CLAUDE.md。
这不是 PR 话术。Every 把开源插件扔到了 GitHub，14,000 多颗 star 是工程圈用脚投票的结果。对于正在探索 AIcoding 落地路径的团队来说，这是目前公开可参考的多智能体并行工程实践里，数字最具体的一个。我们在之前的文章里讨论过 AI 编程进入 Agent 时代意味着什么，而 Every 给出了一个可操作的答案。
80% 的时间不在写代码，那在干什么
传统软件工程里，大部分工程师的时间分配大概是：30% 理解需求 + 10% 设计方案 + 50% 写代码 + 10% 修 bug。Every 把这个比例完全颠倒过来——Plan（计划）和 Review（审查）占 80%，真正动手写代码只占 20%。
这 80% 具体在做什么？
Plan 阶段是消化模糊需求的过程。弄清约束条件、研究代码库里同类功能的实现方式、查框架文档和最佳实践、设计方案、再校验方案是否站得住。Kieran 在文章里提到一个细节：他们的 /workflows:plan 命令在 ultrathink 模式下可以并发启动 40 多个专项 AI 助手，各自从不同角度做调研，最后汇成一份计划。
Review 阶段则是多路并行审查。单次 /workflows:review 会同时拉起 14 个专项检查者，每个盯着不同维度——有的看安全问题、有的查性能瓶颈、有的审代码风格、有的验测试覆盖。审查结果按 P1（必须修）/ P2（应该修）/ P3（可以修）分级标注，工程师只需要过一遍判断，修完再校验。
我们自己——蓝曜炬辉——在交付大模型应用项目时也观察到类似模式。一开始团队也是工程师 70% 时间在敲键盘，后来引入 Claude Code 做计划与审查的自动化前置处理后，一个 6 人团队里真正需要大量写原始代码的只剩下 2 人，其余 4 人的时间被重新分配到需求细化、架构决策和最终体验验证上。投入没变，交付质量上去了。关于这半年的实践数据，我们在《AI 写代码半年，我们算了一笔真实账》里做了完整拆解。
复利工程的八步循环：关键在最后一步
Every 最初提出的复利工程是四步：Plan → Work → Review → Compound。2026 年 5 月升级为八步：
Ideate → Brainstorm → Plan → Work → Review → Polish → Compound → Repeat
前两步 Ideate 和 Brainstorm 是新加的。Kieran 的解释很直白：「模型越来越强，中间的执行部分已经变得 boring——如果计划足够好、上下文给得对，它通常能把活干对。真正的难点是决定什么值得做。」
Polish（打磨）也是新增的。代码通过了所有测试、功能跑通了，但产品体验可能还是不行。这个阶段工程师要自己点一点、读一读文案、问自己「这个交互感觉对吗」。用 Kieran 的话说，AI 是三明治的中间层，人类是两端的面包——开始时要定义方向，结束时要判断品质。
但无论怎样扩展，最后一步 Compound（固化）始终是整个循环的灵魂。传统工程到 Review 就结束了，复利工程多走一步：把这次解决问题的方法写成结构化知识，存进 CLAUDE.md 和 docs/solutions/ 目录，让 AI 下次自动避开同类错误。这和 我们之前讨论的「AI 编程的瓶颈在人不在模型」是同一个方向的观察——工具在变强，但决定天花板的是人怎么把经验沉淀下来。
这一步的效果是累进的：
| 迭代次数 | 传统工程 | 复利工程 |
|---|---|---|
| 第 1 次 | 从零开始调研和试错 | 从零开始，但把解法存下来 |
| 第 5 次 | 第 5 次从零开始调研 | 前 4 次的积累自动参与决策 |
| 第 20 次 | 代码库成为历史包袱 | 代码库成为可复用知识资产 |
| 第 100 次 | 新人需要数月才能上手 | 新 AI 读 CLAUDE.md 即可继承上下文 |
这不是理论推演。Every 开源的插件里包含 26 个专项助手、23 条工作流命令、13 项技能，零配置即可在 Claude Code / OpenCode / Codex 上使用。每一条工作流命令的背后都是无数次 Compound 沉淀下来的经验。
复利工程落地时间线：从零到 Compound 的四阶段
对想引入这套方法论的工程团队，我们基于 Every 的实践和蓝曜炬辉自身的落地经验，梳理了一条可操作的路径：
| 阶段 | 周期 | 动作 | 产出 |
|---|---|---|---|
| 第一阶段：建骨架 | 第 1 周 | 在项目根目录创建 CLAUDE.md（团队编码规范 + 技术栈约定 + 已知陷阱），在 docs/solutions/ 下建目录结构 | 1 份 CLAUDE.md + 空 solutions 目录 |
| 第二阶段：跑通循环 | 第 2–4 周 | 在 2–3 个非关键任务上跑完整八步循环。重点不是速度，是养成「每次 Review 后写 Compound 条目」的习惯 | 5–10 条 Compound 条目 + 团队对流程的肌肉记忆 |
| 第三阶段：规模化 | 第 5–12 周 | 全团队所有任务走八步循环。开始积累专项 AI 助手（按 Every 开源的 26 个助手为模板定制）。引入 /workflows:plan 和 /workflows:review 命令 | 20–50 条 Compound 条目 + 5–10 个定制 AI 助手 + 可量化的效率提升数据 |
| 第四阶段：自进化 | 第 13 周起 | Compound 条目开始自动引用和交叉验证。新任务启动时 AI 自动从 solutions/ 中检索相关经验。团队只需要处理「没有现成解法」的新问题 | 知识库自增长，人工介入频率持续下降 |
这套时间线的关键假设：前两周是最难的——团队需要对抗「直接写代码更快」的本能冲动。我们的经验是：前两次走完八步循环的时间大约是直接写代码的 1.5 倍，但从第三次开始就反超了——因为 Compound 条目开始生效，AI 不再重复犯同样的错。
文件夹就是智能体：44 个 AI 并行运行的真实架构
很多人听到「同时跑 44 个 AI」的第一反应是：这得用多复杂的编排框架？Kieran 的答案是：不需要。
他花了三个月尝试 swarm 方案——让多个 AI 实例互相协调、自己决定做什么、产出他没干预过的结果。结论是「数量增加并没有让我更快」。当 10 个同时完成工作，他需要逐一评估 10 份结果，却缺乏足够的上下文判断哪些可信。
绕了一圈后他发现，真正起作用的东西一直就在硬盘上——一个项目文件夹。里面有代码结构、有 CLAUDE.md（告诉 AI 怎么在这个项目里工作）、有 skill 定义、有经过数月复利工程积累的上下文。把这个文件夹交给一个模型，通用模型就变成了这个项目的专家。这本质上就是 Agentic Coding 的落地形态——AI 从「写代码」变成「做项目」。
44 个智能体就是 44 个这样的文件夹，每个针对不同的任务域。Kieran 在上面加了一层轻量的调度层做路由，仅此而已。
这个思路跟行业里流行的「重编排框架」方向完全相反。Kieran 明确说：「AI 没有速度上限，但管理它们的人有。」与其花精力造更复杂的编排层来过滤输出，不如把精力花在给每个工作单元一个足够好的文件夹——里面有足够多已经验证过的上下文。
我们在蓝曜炬辉的实践中也踩过类似的坑。早期做 AI 架构时团队花了不少时间搭 LangChain + LangGraph 的编排管线，后来发现真正决定输出质量的不是编排层的复杂度，而是喂给模型的上下文质量。现在我们的标准做法是先花时间打磨每个模块的 system prompt 和知识文件，再考虑要不要加编排。
从四步到八步：提示了一个更深的转变
复利工程从四步扩展到八步这件事本身，比新增了哪几步更有信息量。它揭示了一个正在发生的转变：AI 能力的提升并没有减少人的工作量，而是把人的精力从「执行」推向了「判断」。
第一版四步循环诞生于 2025 年，当时的 AI 模型在代码生成上还不够可靠，工程师需要花大量时间在 Work 阶段盯着输出。到 2026 年中，模型能力跃迁后，Work 阶段变得相对省心，人的注意力自然流向了循环的两端——Ideate 阶段思考「为什么要做这个功能」、Polish 阶段判断「做出来的东西真的好吗」。
Kieran 用一个比喻收束了这个观点：「三明治。AI 是中间的东西，人类是两头的面包，把一切兜住。」
这个比喻的隐含信息是：AIcoding 不会消灭工程师，但会彻底改变工程师的时间分配结构。那些把 80% 时间花在理解业务、定义问题、验证体验上的工程师，会比 80% 时间在写代码的工程师更有竞争力。从个人提效到团队 10x 交付的流程重塑，核心也在于此——不是把代码写得更快，而是把写代码之外的事情做得更系统。
常见问题
复利工程适合小团队吗？
Every 本身就是小团队的极端案例——单人维护一个产品。复利工程不挑团队规模，它解决的是「如何让下一次迭代比上一次更省力」的问题。两人团队和两百人团队面临的知识流失问题本质相同，只是规模不同。小团队甚至更有优势——Compound 条目不需要跨团队对齐，一个人写、一个人用，闭环极短。
需要用到特定 AI 工具吗？
Every 的开源插件目前支持 Claude Code、OpenCode、Codex。但方法论本身不绑定工具——Compound 步骤的核心是把解法写成结构化文本（CLAUDE.md / docs/solutions/），任何能读取项目文件夹的 AI 工具都能受益。我们蓝曜炬辉在用 Cursor 和 Claude Code 交付项目时，也借鉴了这个做法，在每个项目仓库里维护了类似的上下文文件。
文件夹即智能体的调度层怎么实现？
Kieran 在两篇文章中只描述了概念，没有开源调度层代码。但从他的描述看，调度层做的事情不复杂：接收任务 → 匹配最相关的文件夹 → 把任务和上下文一起交给对应实例执行。不是复杂的编排框架，更像是路由 + 上下文注入。
这套方法论能不能用到非工程领域？
Kieran 在升级版指南里明确说：「这个模式适用于更广泛的知识工作。」Every 内部已经在把复利工程用于内容创作、产品管理、增长运营等场景。只要工作可以被拆成「计划→执行→审查→固化」的循环，就可以套用。
引入复利工程的前两周，团队应该预期什么样的效率变化？
前两周完成一个任务的耗时大约是直接写代码的 1.5 倍——多出来的时间花在 Brainstorm、Polish 和 Compound 三个新环节上。但从第三周开始，Compound 条目累积到 10 条以上时，AI 在同类型任务上的出错率明显下降，总耗时开始低于传统模式。我们的实测数据：第三周起效率反超约 20%，第八周起累计效率提升约 50%。关键是不能中途放弃——大多数团队在第二周觉得「太慢了」而退回老方法，恰好错过了拐点。
对 AIcoding 实践者的三个提醒
Every 复利工程的公开给了 AIcoding 实践者一份可操作的地图。总结下来，三条最值得带走：
第一，别跳过 Compound。 大多数团队用 AI 辅助开发停在 Review——功能写完了、测试过了、合并了，然后下一个。不做 Compound 的 AIcoding 只是「有 AI 助手的传统开发」，效率提升有天花板。Compound 把每次迭代变成下次的起点。
第二，不靠编排，靠上下文。 与其花几个月搭 swarm 框架，不如花几周打磨每个工作单元的文件夹——CLAUDE.md、skill 定义、已验证的解决方案文档。Kieran 的 44 个并行实例就是这么跑起来的。
第三，把时间从执行挪到判断。 模型能力在涨，写代码越来越不是瓶颈。真正拉开差距的是：你能不能定义对的问题，以及你能不能判断做出来的东西真的好。这两个能力 AI 暂时替代不了。
蓝曜炬辉在交付 AIcoding 项目时，一直强调「工程师的角色不是敲代码，是做正确的事」。Every 把这句话变成了一套可复现的方法论和开源工具。想做 AIcoding 深度实践的团队，欢迎聊聊。