复合式工程：构建自我改进的开发系统

在我打开笔记本电脑之前，代码已经审查了自己。

我打开 GitHub，准备开始日常工作——标记命名不当的变量，删减过多的测试，并建议更简单的错误处理方式。相反，我发现了几条来自 Claude Code（在我终端中编写和编辑的 AI）的有力评论：

"已将变量命名更改为与 PR [拉取请求] #234 的模式匹配，根据 PR #219 的反馈删除了过多的测试覆盖，添加了类似于 PR #241 中已批准方法的错误处理。"

换句话说，Claude 从三个月的代码审查中学习，并在没有被要求的情况下应用了这些经验教训。它彻底掌握了我的品味，就像一个敏锐的新队友一样——而且有证据支撑。

这感觉像作弊，但其实不是——这是复合增长。每次我们修复什么，系统就学习。每次我们审查什么，系统就学习。每次我们以可避免的方式失败，系统就学习。这就是我们现在构建 Cora（Every 的 AI 邮件助手）的方式：创建能创建系统的系统，然后置身事外。

我将这称为复合式工程：构建自我改进的开发系统，其中每次迭代都使下一次变得更快、更安全、更好。

典型的 AI 工程关注短期收益。你提示，它编码，你发布。然后重新开始。复合式工程是关于构建具有记忆的系统，其中每个拉取请求都教导系统，每个错误都成为永久的经验教训，每次代码审查都更新默认设置。AI 工程让你今天变快。复合式工程让你明天变快，以及之后的每一天。

在 Cora 上进行三个月的复合式工程完全改变了我对代码的思考方式。我再也不能写一个函数而不思考我是在教导系统还是只是解决今天的问题。如果一个错误修复不能防止其整个类别的问题，我就觉得它只做了一半。没有可提取经验教训的代码审查似乎是浪费时间。

当你读完这篇文章时，你也会有同样的困扰。

10分钟投资，永远收益

复合式工程需要前期投资：你必须先教会你的工具，然后它们才能自学。

以下是一个实际工作中的例子：我正在为 Cora 构建一个"挫折检测器"；目标是让我们的 AI 助手注意到用户对应用行为感到恼火时，自动提交改进报告。传统方法是编写检测器，手动测试，调整，然后重复。这需要大量的专业知识和时间，其中很多时间花在用户思维和开发者思维之间的上下文切换上。如果系统能够自学就更好了。

所以我从一个表达挫折的示例对话开始——比如反复问同一个问题，语言越来越简洁。然后我把它交给 Claude，并给出一个简单的提示："这个对话显示了挫折。写一个测试来检查我们的工具是否能捕捉到它。"

Claude 编写了测试。测试失败了——这是测试驱动开发 (TDD) 的自然第一步。接下来，我告诉 Claude 编写实际的检测逻辑。一旦编写完成，它仍然无法完美工作，这也是可以预期的。现在是美妙的部分：我可以告诉 Claude 迭代挫折检测提示，直到测试通过。

不仅如此——它可以继续迭代。Claude 调整提示并再次运行测试。它读取日志，看到为什么它错过了挫折信号，然后再次调整。经过几轮后，测试通过了。

但 AI 输出不是确定性的——一次有效的提示下次可能失败。

所以我让 Claude 运行测试 10 次。当它只在 10 次中识别出 4 次挫折时，Claude 分析了为什么其他 6 次失败了。它研究了每次失败运行的思维链（Claude 在决定某人是否沮丧时显示的逐步思考），并发现了一个模式：它错过了用户可能使用的模糊语言，比如"嗯，不太对"，当与重复请求配对时，这实际上表明了挫折。然后 Claude 更新了原始挫折检测提示，专门寻找这种礼貌但沮丧的语言。

在下一次迭代中，它能够在 10 次中识别出 9 次沮丧用户。足够好可以发布了。

我们将整个工作流程——从识别挫折模式到迭代提示到验证——编入 CLAUDE.md 中，这是 Claude 在每次对话前拉取的特殊文件。下次我们需要检测用户的情绪或行为时，我们不会从零开始。我们说："使用挫折检测器的提示工作流程。"系统已经知道该怎么做。

与人类编写的代码不同，这里的"实现"是一个 Claude 可以根据测试结果无尽精炼的提示。每次失败都教导系统。每次成功都成为模式。（我们计划开源这个提示测试框架，以便其他团队可以构建自己的复合工作流程。）

从终端到任务控制

大多数工程师将 AI 视为额外的一双手。复合式工程将其转变为一个完整的团队，随着每项任务变得更快、更敏锐、更一致。

在 Cora，我们使用这种方法来：

1. 将生产错误转化为永久修复，通过让 AI 代理自动调查崩溃，从系统日志重现问题，并生成解决方案和测试以防止再次发生。这将每次失败转化为一次性事件。
2. 从协作工作会议中提取架构决策，通过记录与队友的设计讨论，然后让 Claude 记录为什么选择某些方法——创建新团队成员在第一天就继承的一致标准。
3. 构建具有不同专业知识的审查代理，通过在"Kieran 审查者"中捕获我自己的偏好来执行我的风格选择，然后添加专门的视角，如用于框架最佳实践的"Rails 专家审查者"或用于速度优化的"性能审查者"。
4. 自动化视觉文档，通过部署一个自动检测界面变化的代理，捕获跨不同屏幕尺寸和主题的前后截图，并生成综合视觉文档——消除 30 分钟的手动任务，同时确保每个界面变化都为审查者正确记录。
5. 并行化反馈解决，通过为每个审查者反馈创建专用代理，同时工作解决问题。这将可能需要数小时的来回过程压缩为并行工作，其中 10 个问题在过去解决一个问题的时间内得到解决。

我的自动化代码审查器：一个捕获我偏好的文件，因此 Claude 可以标记诸如"太多测试"或"过度复杂的逻辑"等问题，而无需被要求。（来源：Kieran Klaassen。）

这种工作方式标志着成为工程师意味着什么的转变。你的工作不再是敲代码，而是设计设计系统的系统。这是我发现的唯一方法，其中今天的工作使明天的工作呈指数级变得更容易，以及你做出的每一个改进都是永久的。

在我们在 Cora 上运行复合式工程工作流程的三个月中，我们的指标发生了明显的变化。我们看到功能的发布时间从超过一周平均下降到 1-3 天，生产前捕获的错误大幅增加。过去拖延数天的拉取请求审查周期现在在几小时内完成。

复合式工程操作手册

构建学习系统需要重新连接你对开发的思考方式。即使你被复合式工程所说服，你可能想知道如何开始。经过几个月的精炼——以及大量失败的实验——我将其提炼为五个步骤。

步骤 1：通过工作教学

每次你做出决定时，捕获并编纂它，以阻止 AI 再次犯同样的错误。CLAUDE.md 成为你用简单语言表达的品味——你为什么喜欢保护子句而不是嵌套的 if 或以某种方式命名事物。保持简短，保持活跃。

同样，llms.txt 文件存储你的高级架构决策——当你重构单个功能时不会改变的设计原则和系统范围规则。

这些文件将你的偏好转化为 Claude 自动应用的永久系统知识。

步骤 2：将失败转化为升级

有什么东西坏了？好的。那是数据。但这里是大多数工程师停下来的地方：他们修复即时问题然后继续前进。复合式工程师添加测试，更新规则，并编写评估。

举一个来自 Cora 的最近例子：一个用户报告说他们从未收到每日邮件简报——这是一个严重失败！我们编写了捕获类似交付失误的测试，更新了我们的监控规则以标记简报未发送的情况，并构建了持续验证交付管道的评估。

现在系统总是关注这类问题。从失败开始的东西已经使我们的工具永久变得更聪明。

步骤 3：并行编排

与雇佣每人 15 万美元的工程师不同，AI 工作者按需扩展。唯一的限制是你的编排技能和计算成本——而不是人员数量、招聘时间线或团队协调开销。你可以以一杯咖啡的成本启动五个专门代理。

我的显示器现在看起来像任务控制：

1. 左车道：规划。 一个 Claude 实例读取问题，研究方法，并编写详细的实施计划。
2. 中车道：委派。 另一个 Claude 接受这些计划并编写代码，创建测试，并实施功能。
3. 右车道：审查。 第三个 Claude 根据 CLAUDE.md 审查输出，建议改进，并捕获问题。

一开始感觉很笨拙——就像在学习杂耍时杂耍——但在一周内它就变得自然了。

我在 Warp 命令行界面中的显示器设置（从左到右）：在 Claude Code 中规划；在编码代理 Friday 中委派；在另一个编码代理 Amp 中审查。（来源：Kieran Klaassen。）

步骤 4：保持上下文精简但属于你的

互联网上充满了你可以复制的"终极 CLAUDE.md 文件"。不要这样做。你的上下文应该反映你的代码库、你的模式和你辛苦获得的经验教训。你遵循的十个具体规则胜过 100 个通用规则。当规则不再为你服务时，删除它们。活跃的上下文意味着修剪和增长一样多。

当我审查我的 CLAUDE.md 命令和代理文件时，感觉就像在阅读我自己的软件哲学——反映了我学到的东西、我重视的东西以及我认为代码应该如何构建。如果它不能与你个人产生共鸣，它就不会有效地指导 AI。

步骤 5：相信过程，验证输出

这是最难的步骤。你的本能会是微观管理和审查每一行。相反，相信你构建的系统——但通过测试、评估和抽样检查进行验证。这就像学习成为 CEO 或电影导演：你不能自己做所有事情，但你可以构建在问题升级之前捕获问题的系统。当有东西回来是错误的时候（它会的），教导系统为什么它是错误的。下次，它就不会了。

停止编码，开始复合

这是我知道的：公司为过去花费 40 万美元一年的东西支付每月 400 美元。一个人的初创公司正在与有资金的团队竞争。AI 不仅民主化了编码，还民主化了整个工程系统。杠杆正在转移到那些教导这些系统比他们打字更快的人。

今天开始一个实验日志。当有什么不应该失败的东西失败时，投入时间防止它再次发生——构建测试，编写规则，并捕获经验教训。打开三个终端。尝试三车道设置：在一个中规划，在另一个中构建，在第三个中审查。说"拉取请求"并观察分支开花。

然后明天再做一次，看看什么复合了。

---

感谢 Katie Parrott 的编辑支持。

Kieran Klaassen 是 Cora（Every 的邮件产品）的总经理。在 X 上关注他 @kieranklaassen 或在 LinkedIn 上。