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，我们使用这种方法来：- 将生产错误转化为永久修复，通过让 AI 代理自动调查崩溃，从系统日志重现问题，并生成解决方案和测试以防止再次发生。这将每次失败转化为一次性事件。
- 从协作工作会议中提取架构决策，通过记录与队友的设计讨论，然后让 Claude 记录为什么选择某些方法——创建新团队成员在第一天就继承的一致标准。
- 构建具有不同专业知识的审查代理，通过在”Kieran 审查者”中捕获我自己的偏好来执行我的风格选择，然后添加专门的视角，如用于框架最佳实践的”Rails 专家审查者”或用于速度优化的”性能审查者”。
- 自动化视觉文档，通过部署一个自动检测界面变化的代理，捕获跨不同屏幕尺寸和主题的前后截图，并生成综合视觉文档——消除 30 分钟的手动任务，同时确保每个界面变化都为审查者正确记录。
- 并行化反馈解决，通过为每个审查者反馈创建专用代理，同时工作解决问题。这将可能需要数小时的来回过程压缩为并行工作，其中 10 个问题在过去解决一个问题的时间内得到解决。 我的自动化代码审查器：一个捕获我偏好的文件，因此 Claude 可以标记诸如”太多测试”或”过度复杂的逻辑”等问题，而无需被要求。（来源：Kieran Klaassen。） 这种工作方式标志着成为工程师意味着什么的转变。你的工作不再是敲代码，而是设计设计系统的系统。这是我发现的唯一方法，其中今天的工作使明天的工作呈指数级变得更容易，以及你做出的每一个改进都是永久的。 在我们在 Cora 上运行复合式工程工作流程的三个月中，我们的指标发生了明显的变化。我们看到功能的发布时间从超过一周平均下降到 1-3 天，生产前捕获的错误大幅增加。过去拖延数天的拉取请求审查周期现在在几小时内完成。
复合式工程操作手册
构建学习系统需要重新连接你对开发的思考方式。即使你被复合式工程所说服，你可能想知道如何开始。经过几个月的精炼——以及大量失败的实验——我将其提炼为五个步骤。步骤 1：通过工作教学
每次你做出决定时，捕获并编纂它，以阻止 AI 再次犯同样的错误。CLAUDE.md 成为你用简单语言表达的品味——你为什么喜欢保护子句而不是嵌套的 if 或以某种方式命名事物。保持简短，保持活跃。 同样，llms.txt 文件存储你的高级架构决策——当你重构单个功能时不会改变的设计原则和系统范围规则。 这些文件将你的偏好转化为 Claude 自动应用的永久系统知识。步骤 2：将失败转化为升级
有什么东西坏了？好的。那是数据。但这里是大多数工程师停下来的地方：他们修复即时问题然后继续前进。复合式工程师添加测试，更新规则，并编写评估。 举一个来自 Cora 的最近例子：一个用户报告说他们从未收到每日邮件简报——这是一个严重失败！我们编写了捕获类似交付失误的测试，更新了我们的监控规则以标记简报未发送的情况，并构建了持续验证交付管道的评估。 现在系统总是关注这类问题。从失败开始的东西已经使我们的工具永久变得更聪明。步骤 3：并行编排
与雇佣每人 15 万美元的工程师不同，AI 工作者按需扩展。唯一的限制是你的编排技能和计算成本——而不是人员数量、招聘时间线或团队协调开销。你可以以一杯咖啡的成本启动五个专门代理。 我的显示器现在看起来像任务控制：- 左车道：规划。 一个 Claude 实例读取问题，研究方法，并编写详细的实施计划。
- 中车道：委派。 另一个 Claude 接受这些计划并编写代码，创建测试，并实施功能。
- 右车道：审查。 第三个 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 上。
- 手把手教你逆向Claude Code：如何监控AI每一次’内心独白’？ - 通过技术手段逆向分析Claude Code的API交互过程，揭秘AI编程之王的多模型协作策略、精巧的系统提示词设计和智能工具调用机制。
- 是什么让 Claude Code 如此出色 - 深入分析 Claude Code 的核心设计原理，揭示如何构建出色的大语言模型编程代理