复利工程：让每一次工作都让下一次更简单
大多数代码库随着时间推移变得越来越难以维护，因为你添加的每个功能都会注入更多复杂性。10年后，团队花费在与系统对抗的时间比构建功能的时间还多，因为每个新功能都需要与旧功能进行”谈判”。随着时间的推移，代码库变得更难理解、更难修改、更难信任。
复利工程（Compound Engineering）颠覆了这一模式。它不再让功能添加复杂性和脆弱性，而是教会系统新的能力。Bug 消除会消除整类未来的 Bug。当模式被编码后，它们成为未来工作的工具。随着时间的推移，代码库变得更容易理解、更容易修改、更容易信任。
Every 团队运营着五个产品——Cora、Monologue、Sparkle、Spiral 和 Every.to，主要依靠单人工程团队。使其成为可能的系统是一个四步循环，构成了复利工程的基础：
Plan → Work → Review → Compound → Repeat
前三步（Plan、Work、Review）对任何开发者来说都很熟悉。真正区分复利工程的是第四步——Compound。这是收益累积的地方。跳过这一步，你只是在传统工程中使用 AI 辅助。
无论你是用五分钟修复一个 Bug，还是花几天时间构建一个功能，这个循环的工作方式都是一样的。你只是在不同步骤上花费更多或更少的时间。
Plan 和 Review 步骤应该占工程师时间的 80%，Work 和 Compound 占另外的 20%。换句话说，大多数思考发生在代码编写之前和之后。
Planning 将想法转化为蓝图，更好的计划产生更好的结果。在这一步，要采取以下行动并问自己这些问题：
- 理解需求：要构建什么？为什么？存在什么约束？
- 研究代码库：类似的功能如何工作？存在什么模式？
- 研究外部资源：框架文档怎么说？有哪些既定的最佳实践？
- 设计解决方案：方法是什么？需要修改哪些文件？
- 验证计划：这是否站得住脚？是否完整？
执行遵循计划。Agent 实现时，开发者监控。在这一步中有一些较小的任务：
- 设置隔离：Git worktrees（仓库的隔离副本）或分支保持工作分离
- 执行计划：Agent 逐步实施
- 运行验证：每次更改后运行测试、Linting（自动代码检查）和类型检查
- 跟踪进度：检查已完成的工作和剩余的工作
- 处理问题：当某些东西损坏时，调整计划
如果你信任计划，就没有必要看每一行代码。
这一步在代码发布前捕获问题。更重要的是，它为下一个周期捕获学习内容，这成为复利工程的基础。Review 期间发生的行动：
- 让多个 Agent 审查输出：多个专门的审查员并行检查代码
- 优先处理发现：将发现标记为 P1（必须修复）、P2（应该修复）或 P3（修复了更好）
- 解决发现：Agent 根据审查反馈修复问题
- 验证修复：确认修复正确且完整
- 捕获模式：记录出错的地方以防止再次发生
传统开发在第三步停止，但 Compound 步骤是获得收益的地方。前三步（Plan、Work、Review）产生一个功能。第四步产生一个每次都能更好地构建功能的系统。
在这最后一步，你应该采取这些行动：
- 捕获解决方案：问自己：什么有效？什么无效？什么是可重用的洞察？
- 使其可被发现：添加 YAML frontmatter，确保用正确的元数据、标签和类别标记以便检索
- 更新系统：将新模式添加到 CLAUDE.md 中，这是 Agent 在每次会话开始时读取的文件。在必要时创建新的 Agent
- 验证学习：问自己：系统下次会自动捕获这个吗？
我们在软件开发中都被训练相信某些事情。随着 AI 工具的改进，其中一些信念现在成了障碍。以下是八个需要放弃的信念：
作为一个优秀的软件工程师，你的实际要求只是编写好的代码，这可以被定义为维护性好且解决了正确问题的代码。谁输入代码——人类还是 Agent——并不重要。
同样，成为优秀工程师的核心要求是编写质量代码。逐行手动审查是达到目的的一种方法，但能够捕获相同问题的自动化系统也是。
开发者仍然依赖手动审查的一个原因是他们不信任结果。如果你不信任结果，修复系统，而不是通过自己做一切来补偿。
当 AI 可以研究方法、分析权衡并推荐选项时，工程师的工作就变成了增加品味——知道哪个解决方案适合这个代码库、这个团队和这个上下文。
一个产生代码的系统比任何单独的代码片段更有价值。单个精彩的实现不如一个持续产生良好实现的流程有价值。
开发者的工作是交付价值。代码只是该工作中的一个输入——规划、审查和教导系统也算在内。有效的复利工程师比以前编写更少的代码，但交付更多。
根据我们的经验，第一次尝试有 95% 的垃圾率。第二次尝试仍然是 50%。这不是失败——这是过程。
期望第一次尝试就完美，就像期望初级开发人员在没有上下文的情况下搞清楚复杂功能一样。所以让你的目标是在第一次就做对。专注于快速迭代，使你的第三次尝试比第一次尝试花费的时间更少。
开发者下意识地将 AI 辅助开发视为对身份的攻击。感觉像是对自尊的打击。
但代码从来都不是真正属于你的。它属于团队、产品和用户。放弃代码作为自我表达是解放性的。没有依恋意味着你更好地接受反馈，毫不犹豫地重构，并跳过关于代码是否足够好的争论。
许多开发者担心如果不打字，就不会学习。然而，现实是理解比肌肉记忆更重要。
你通过审查、通过捕获错误和知道 AI 何时错误来学习和建立理解。审查 10 个 AI 实现的开发人员比手工输入 2 个的开发人员理解更多模式。
每个代码库都反映了构建它的开发者的品味，从命名约定到错误处理模式和测试方法。这种品味通常不会在任何地方记录。它存在于高级工程师的脑海中，并通过代码审查转移。这既不能扩展，也不能让团队中的其他人学习。
解决方案是提取和记录这些选择。将这些偏好写入 CLAUDE.md 或 AGENTS.md，以便 Agent 在每次会话时读取它们。构建专门的审查、测试和部署 Agent，以及反映你品味的技能。添加编码你首选方法的斜杠命令。指向 Agent 你现有的风格指南、架构文档和决策记录，所有这些都包含你喜欢构建方式的示例。
一旦 AI 理解你如何喜欢编写代码，它就会产生你实际批准的代码，而不是你必须修复的代码。
之前，我建议了一个 80/20 规则来构建功能：80% 的时间用于规划和审查，20% 用于工作和复利。当你作为开发者的更广泛职责来看时，你应该将 50% 的工程时间用于构建功能，50% 用于改进系统——换句话说，任何有助于构建机构知识而不是交付特定内容的工作。
在传统工程中，团队将 90% 的时间投入到功能中，10% 投入到其他所有事情。不是功能的工作感觉像是一种干扰——你有空闲时间做的事情，但你从来没有这样做。但是这个”其他所有事情”正是使未来功能变得更容易的事情：比如创建审查 Agent、记录模式和构建测试生成器。当你将该工作视为开销而不是投资时，代码库会累积债务。
花一个小时创建一个审查 Agent 可以在未来一年节省 10 小时的审查时间。你可以花时间构建一个测试生成器，节省数周的手动测试编写。系统改进使工作逐步变得更快更容易，但功能工作不会。
AI 辅助无法扩展，如果每一行都需要人工审查。你需要信任 AI。
信任并不意味着盲目信仰。它意味着设置护栏，如测试、自动审查和监控，标记问题，这样你就不必观察每一步。
当你觉得无法信任输出时，不要通过切换到手动审查代码来补偿。添加一个使该步骤值得信任的系统，例如创建一个标记问题的审查 Agent。
如果开发者可以看到或做某事，Agent 应该被允许看到或做它。
- 运行测试
- 检查生产日志
- 用截图调试
- 创建拉取请求
任何你不让 Agent 处理的事情，你必须手动自己做。目标应该是人类和 AI 开发者之间的完全环境对等。
你以前是瓶颈，因为人类注意力一次只允许一个任务。新的瓶颈是计算——你可以同时运行多少个 Agent。
同时运行多个 Agent 和多个功能。同时进行审查、测试和文档记录。当你被困在一个任务上时，开始另一个，让 Agent 工作同时规划下一步。
计划文档现在是你产生的最重要的东西。而不是传统地先编码后记录，从计划开始。这成为 Agent 用于生成、测试和验证代码的真相来源。
拥有计划有助于在决策成为 Bug 之前捕获它们。在纸上修复想法比以后修复代码更便宜。
复利工程循环——Plan、Work、Review、Compound——是流程。但你可以让 AI 拥有多少流程取决于你对 AI 的熟悉程度和天赋。开发者可以根据五个阶段来定位自己，了解他们所处的位置。
大多数在 AI 辅助开发中挣扎的开发人员不知道他们在这个梯子上的位置。他们听到多代理审查系统和并行云执行，感到不知所措，要么放弃要么试图跳到前面。跳过阶段行不通，因为你会感到不舒服和不信任工具。每个梯子都建立下一个所需的心理模型和习惯。所以慢下来，找出你在哪里，并专注于从那里构建。
在这个阶段，你正在逐行编写代码，没有任何 AI。你通过文档和 Stack Overflow 进行研究。你的调试过程通过代码阅读和打印语句进行。手动开发几十年来构建了伟大的软件，但遗憾的是在 2025 年不够快。
在这个阶段，你使用 AI 作为智能参考工具，查询 ChatGPT、Claude 或 Cursor，接收代码片段，并复制粘贴有用的内容。AI 加速你的研究和样板生成，但你仍然完全控制，审查每一行。
在这个阶段，Agent 工具——可以读取文件并直接进行更改的 AI 助手——进入工作流程：Claude Code、Cursor Composer 和 Copilot Chat。你允许 AI 根据你提供的上下文读取文件并在代码库中直接进行更改。你是守门人，批准或拒绝 Agent 提出的所有内容，这仍然是一个痛苦的过程。
大多数开发者在这里停滞不前，无法享受将更多工作交给 AI 的好处。
这是事情发生变化的阶段。你和 AI 合作制定一个详细计划，包括需求、方法和边缘情况。然后开发人员走开，允许 AI 在没有监督的情况下实施计划。输出是一个拉取请求，然后你审查它。最后，你脱离了代码的行级别，可以在 PR 审查中捕获问题，而不是在 AI 构建时看护它。
复利工程从这里开始，因为每个规划、构建和审查循环都教系统一些东西，使下一个循环更容易更快。
你提供一个想法，Agent 处理一切：代码库研究、规划、实施、测试执行、自我审查、问题解决和 PR 创建。在这个阶段，你的参与缩小到三个步骤：构思、PR 审查和合并。但是，你仍然在自己的计算机上一次运行一件事。
这是最后阶段。你将执行移动到云端并并行运行。因为你不受笔记本电脑束缚，你可以从任何地方指导你的 Agent——咖啡店、巴拿马海滩或你的手机。
你启动三个功能，三个 Agent 独立工作，你审查完成时出现的 PR。如果你进一步推动，你允许 Agent 开始监控反馈并在未被询问时提出修复。不再是个体贡献者。你正在指挥一个舰队。
复利工程代表了一种全新的软件开发思维方式。它不仅仅是工具集，更是一套完整的哲学体系。
传统工程关注”做”——编写代码、修复 Bug、添加功能。复利工程关注”教”——每次解决问题后，将解决方案编码到系统中，让下次遇到类似问题时，系统能够自动处理或提供更好的指导。
这意味着每次解决问题都在投资未来，而不是完成任务就结束。一个小时内创建的审查 Agent 可能在未来一年节省 100 小时的审查时间。
传统工程是线性的：投入 10 小时，产出 10 小时的工作。复利工程是指数的：前期投入更多时间建立系统（Agent、文档、模式），后期同样的投入会产生更多价值，因为系统本身在帮助工作。
这解释了为什么 Every 团队能够用单人工程团队运营五个产品——他们不是靠写更多代码，而是靠建立一个能够自我进化的系统。
复利工程中的工程师角色从”代码编写者”转变为”系统设计者”和”价值交付者”。代码只是价值交付链中的一个环节。真正重要的是：定义问题、规划解决方案、建立系统、验证结果。
这种转变需要放下自我——承认代码不是自我表达，而是团队和产品的资产。它也要求重新定义成功：不是看写了多少行代码，而是看解决了多少问题。
复利工程不是万能药。它最适合：
- 需要长期维护的代码库
- 有明确模式和规则的领域
- 可以通过测试验证正确性的系统
对于以下场景可能不太适合：
- 探索性项目，模式尚未形成
- 一次性脚本，复用价值低
- 对性能要求极高的系统，需要深度优化
从今天开始，你可以尝试：
- 记录你的模式：每次解决一个有趣的问题，写下你如何解决的，放入 CLAUDE.md
- 创建审查清单：将你知道容易出错的地方转化为自动检查
- 投资工具：花时间编写 Agent 和技能，而不是一遍又一遍地做相同的手动工作
- 接受不完美的首次尝试：快速迭代，第三次尝试应该比第一次尝试做得更快
- 建立信任：通过测试和自动化检查建立对 AI 的信任，而不是逐行审查
复利工程的核心是让每一单位工作都让后续工作更容易。这不仅仅是一种工程方法，更是一种可持续的工作方式。