复合工程——它是什么，以及如何用AI代理上手

Q: 复合工程循环包含哪些步骤？

四个步骤，每项工作都重复一遍。计划： 代理研究代码库，写出详细的实现计划。执行： 代理逐步执行计划，并在过程中运行测试。评估（插件中称为评审）：你和评审代理用测试、linter和安全检查来核对结果。复合： 把学到的东西以规则、测试或笔记的形式记录在仓库里，让后续任务从这里出发。跳过第四步，就会把它变回普通的AI辅助编程。

什么是复合工程？

复合工程（compound engineering）是一种借助AI代理构建软件的方式，核心是让每完成一项任务，下一项任务就变得更容易。传统开发中，第一百个功能的成本和第十个差不多。复合工程则会有意识地记录每项任务带来的收获（模式、错误、项目约定、测试），让你和你的代理在开始下一项任务时，手里的上下文比上一次更多。它与传统软件工程的区别在于：学习被当作交付物的一部分，而不是顺带产生的副作用。

这个词由Every的Dan Shipper和Kieran Klaassen推广开来，他们描述了一个计划、执行、评估、复合的循环。（他们的Claude Code插件把第三步称为评审，并在最前面增加了头脑风暴一步。）代理负责计划和构建，人和评审代理检查结果，最后把经验写到未来的代理能找到的地方。最后这一步是大多数团队跳过的，也是这个名字真正指向的部分。

这篇文章是我自己的看法：它在实践中意味着什么，真正的杠杆在哪里，以及如果让我从头开始，我会先搭什么。

TL;DR

AI让写代码变便宜了，但没有让判断代码是否正确变便宜。
所以瓶颈转移到反馈上：测试、类型检查、CI、评审，以及你多快能发现自己错了。
护栏（类型、规格、项目指令）比巧妙的提示词更重要。
“复合”的部分来自把学到的东西写下来，让下一项任务比上一项更容易。
我给不出一个可靠的倍数。收益很大程度上取决于你的代码库、测试套件，以及你对现有流水线的信任程度。

如果您对复合工程感兴趣，您可能还想阅读：

Compound Engineering v3与智能体软件交付的兴起 —— Compound Engineering插件v3版本的变化，以及它对多代理工作的意义（英文）
Antfarm模式：编排专业代理团队实现复合工程 —— 多代理工作流如何使用Antfarm将复合工程从理论变为实践
复合工程与传统软件工程：为什么线性团队无法跟上 —— 复合工程与传统开发团队的深度比较
从氛围编程到智能体工程 —— 从快速原型构建转向健壮的智能体系统的思维转变
AI智能体的可靠性鸿沟 —— 构建可靠生产级智能体的挑战与解决方案
智能体AI的黎明——变革软件开发经济 —— 智能体AI如何重塑软件行业
一人Scrum团队 —— AI如何使单人开发团队成为可能
单智能体 vs 多智能体AI系统 —— 了解不同AI架构的权衡

从氛围编码到复合工程

从氛围编程到智能体工程的思维转变是复合工程的重要前提。了解如何从快速原型转向可靠系统，对于落地复合工程至关重要。

2025年，我们大多数人都习惯了在编辑器里用AI。Claude Code、Cursor和Copilot成了日常工具，最初的收益是实实在在的：样板代码消失了，陌生的API不再可怕，初稿几秒钟就能出来。

但很大程度上，这只是同一套工作流变快了。我们依然在问”怎么把这段代码写得更快”。而且很多时候全凭感觉：提个需求，扫一眼输出，祈祷它能跑，坏了再修。

复合工程从另一个问题出发：如果写代码不再是慢的那一环呢？ 一旦如此，代码周围的一切都会成为约束。你把任务说清楚了吗？你多快能知道它是否奏效？你学到的东西有没有留到这次会话之后？

为什么叫”复合”？ 这个类比来自复利。每一轮都会留下点什么，比如一个测试、一条写下来的约定、一条关于坑的笔记，让下一轮的成本降低一点。一开始这种效应很缓慢。凡是承诺精确增长率的人，我都会保持警惕。

一个粗略的思考方式：

有用的产出 ≈ 你生成得多快 × 你验证得多快 × 你迭代得多频繁

这是一个思维模型，不是公式。但它解释了为什么用同样AI工具的团队，结果却差别很大：如今生成速度大致相当，验证速度却并非如此。

工程师的思维转变

从代码编写者到系统设计者

对我们许多人来说，做工程师就意味着成为写代码的那个人。这仍然是工作的一部分，但你亲手写的代码很可能会变少。你会把更多时间花在：

搭建反馈系统。 测试、验证和部署流水线，让你能快速知道哪里出了问题。
写清晰的指令。 规格和项目指南，引导AI给出正确答案。
解读信号。 测试失败、用户反馈和指标，然后决定怎么办。
保持架构一致，尽管变更到来的速度比你习惯的更快。

我得坦白：这对每个人都不太舒服。我认识的一些最优秀的工程师热爱写代码这门手艺，而这种转变会带走其中一部分。这个取舍值得坦诚面对。

从”一次做对”到”尽快发现”

传统工程文化依赖周密的规划，因为出错代价高昂。当重新生成一次变更只需要几分钟，这种谨慎可以适当放松。你可以先试，看它失败，再试。

我提醒自己不要把这一点推得太远。重新生成很便宜，不等于出错很便宜。一个溜进生产环境的隐蔽bug，或者一个渗透到二十个文件里的设计决定，依然代价高昂。关键在于：只在反馈循环足够强、能发现问题的地方放松。

从手动检查到自动化护栏

旧的流程是：写代码，手动点一点，发现bug，修复。我现在追求的流程是：写规格，让代理实现，让测试套件和linter来评判，再把失败反馈回去。

前提是你信任你的检查。如果测试发现不了真正的问题，围绕它做自动化只会更快地产出错误代码。建立这种信任，是大部分工作所在。

反馈循环是瓶颈

当代理一分钟就能做出一个功能，真正决定你交付速度的是什么？主要是你多快能回答这些问题：

它做的是我想要的吗？
在我关心的各种场景下都能工作吗？
和系统其余部分配合得好吗？
我能不破坏任何东西地发布它吗？
它解决了用户的问题吗？

如果验证一次变更要两个小时，那么生成它只花了一分钟，其实几乎没有意义。

各阶段通常会这样变化：

阶段	传统方式	复合工程
代码生成	数小时到数天	数分钟
验证	人工评审	自动化测试加评审
集成测试	发布之前	持续进行
部署	手动步骤	自动化流水线
回滚	手动流程	一步回退
用户反馈	数天到数周	取决于你的发布节奏

注意最后一行。循环中有些部分可以大幅压缩，有些（比如等待真实用户）则不能。

让反馈更快

在合适的地方先写测试。 当测试先于实现存在，代理就有了一个客观的目标。这对定义清晰的逻辑效果很好：

describe('User authentication flow', () => {
  it('should authenticate valid credentials', async () => {
    const result = await authenticateUser('user@example.com', 'password');
    expect(result.authenticated).toBe(true);
    expect(result.token).toBeDefined();
  });

  it('should reject invalid credentials', async () => {
    const result = await authenticateUser('user@example.com', 'wrong');
    expect(result.authenticated).toBe(false);
  });
});

// 然后："实现 authenticateUser 让这些测试通过，并运行它们。"

快速、并行的测试。 跑二十分钟的测试套件最终会被人跳过。凡是能并行的，就并行。

渐进式发布。 功能开关和金丝雀发布能缩短”已上线”到”发现问题”之间的时间。

可观测性。 日志、指标和链路追踪，是你了解AI写的代码在生产环境（而不仅仅是测试里）表现如何的途径。

护栏：好的指令很重要

代码生成得越快，模糊的指令让你付出的代价就越大。面对人类同事，歧义可以在走廊闲聊中解决。代理通常会选定一种理解然后一路做下去，而你要等到之后才会发现。

对我有效的做法

用类型作为约束。 强类型系统会缩小代理能产出的范围。这是一种排除整类错误答案的低成本办法：

type UserRole = 'admin' | 'user' | 'guest';

interface AuthenticatedUser {
  id: string;
  email: string;
  role: UserRole;
  permissions: Permission[];
}

type AuthResult =
  | { success: true; user: AuthenticatedUser; token: string }
  | { success: false; error: AuthError };

把验收标准写下来。 在请求一个功能之前，花几分钟写清”完成”意味着什么。哪些情况必须能工作？失败时应该怎样？即使只是一份简短的清单，也能明显改善结果。

可复用的项目上下文。 不要每次都重新解释你的技术栈，把它放进代理会读取的文件里（比如CLAUDE.md或AGENTS.md）：

# 上下文
- 架构：Next.js + PostgreSQL
- 认证：HTTP-only Cookie 中的 JWT
- 错误：绝不向客户端暴露内部细节

# 实现功能时
- 遵循已有类似功能的模式
- 包含 TypeScript 类型并处理边界情况
- 完成前运行 `npm run test`、`npm run typecheck` 和 `npm run lint`

这个文件也是”复合”这一步所在的地方。当代理犯了错、你纠正了它，就加一行，让它不再重犯。

始终让代理有办法检查自己的工作

如果只能选一个习惯，就是这个。对比：

"实现用户认证"

与：

"实现用户认证，然后运行测试套件并修复所有失败"

第二种说法给了代理一个循环：生成、验证、改进、再验证。措辞只变了一点，结果却大不相同。

测试：关键环节

单元测试告诉你某个组件能工作。当AI快速写出大量代码时，更常见的失败不是某个函数坏了，而是各部分单独都能工作却拼不到一起，或者功能和你要求的略有出入。这正是集成测试和端到端测试发挥价值的地方。

         /\
        /  \  端到端测试（关键用户路径）
       /    \
      /------\ 集成测试
     /        \
    /----------\ 单元测试

测试金字塔依然成立，但我会对最重要的路径多依赖一点端到端覆盖，并投入精力让这些测试快到大家真的愿意运行。

我会追求的测试配置：

持续运行的快速单元测试
针对模块之间衔接处的集成测试
一小组稳定可靠、覆盖关键路径的端到端测试
每次变更都做类型检查和lint
在性能重要的地方做性能检查，因为AI写的代码可能存在不易察觉的低效

CI/CD承担重活

你的流水线是让你敢于信任代理所写变更的基础。我希望它具备：

快速反馈，最好是几分钟，而不是几十分钟
便捷回滚，通过功能开关或蓝绿部署
自动检查：lint、类型、安全扫描
可见性：能在出问题时给出提示的仪表盘和告警

如果你的CI又慢又不稳定，先把它修好，再去加更多AI工具。无论如何这都值得。

如何开始

你不需要一次性全部采用。我建议按下面的顺序来。

1. 先看看你当前的反馈循环

计时：从”我有个想法”到”已部署并且我知道它能用”要多久？找出最慢的一步。对大多数团队来说，那是测试套件、代码评审或部署。先解决它。

2. 打好验证的基础

确保测试运行得又快又可靠
如果还没有，在CI中加入类型检查和lint
找出缺少端到端覆盖的关键用户路径
开始要求代理在每项任务中运行测试

3. 把你的约定写下来

创建项目指令文件（CLAUDE.md、AGENTS.md或类似文件）
记录你的架构和模式
当代理出错时，补充规则

4. 闭合循环

每完成一项有意义的工作，问一问：我们学到了什么，是未来的任务应该知道的？ 把它记下来。可以是指令文件里的一条笔记、一个新测试、一个工具函数，或一篇简短的文档。这就是”复合”的一步，忙起来时很容易忘记。

5. 持续打磨

追踪诸如变更上线要多久、同样的错误多久重复一次这类指标。如果某件事总在出错，说明缺少一道护栏。

常见陷阱

只优化生成速度。 这是最显眼的数字，也是最不重要的。要看从想法到经过验证、已发布变更的总时间。

护栏薄弱。 模糊的提示词、宽松的类型、没有自动检查，会让代理只能靠猜，你会在评审中付出代价。

端到端测试太少。 本地全部通过，功能却不能用。

人工评审成为瓶颈。 如果代理一分钟完成而评审要两个小时，流程需要更多自动化，或者更小的变更。

信任看起来合理的代码。 AI的输出往往看上去没问题。要持续验证，并且在重要的决策上保留人的参与，尤其是安全、数据和架构。

跳过”复合”这一步。 如果你从不记录所学，那只是AI辅助开发。这完全没问题，但这不是本文要讲的内容。

代价与收益

关于速度，诚实的回答是：因情况而异。测试良好、CI健康的团队，尤其在范围明确的工作上，可能看到显著提升。构建缓慢、测试稀薄或代码库纠缠不清的团队，在解决这些问题之前，收益会小得多。我没见过一个能当作通用规则的数字，所以对任何吸引眼球的倍数我都持怀疑态度，包括我自己曾想写下的那些。

真正可靠发生变化的，是精力的流向：

花在敲代码上的时间更少
花在测试、规格和流水线质量上的时间更多
花在评审和决策上的时间更多，因为变更的数量增加了

这是一项投资，回报是逐步到来的。它也并非没有成本。评审大量AI生成的代码是实打实的工作，很容易被低估。

未来走向

与其做预测，我更愿意给出几个不成熟的预期。

测试与验证工具在处理AI生成的代码方面，可能会越来越好。
规格和项目上下文会继续成为与代码并列的一等产物。
工程角色可能会向设计、评审和判断倾斜，不过具体日常是什么样子，各团队会有所不同。
简单的架构往往和代理配合得更好。庞杂纠缠的系统，对人和代理都不友好。

这些都没有定论，随着我看到更多真实项目，我预计会不断修正自己的看法。

关键要点

复合工程的核心，是通过记录所学，让每项工作都让下一项任务更容易。
当生成代码很便宜时，反馈速度就成了瓶颈。
护栏（类型、验收标准、项目指令）通常胜过巧妙的提示词技巧。
始终让代理有办法验证自己的工作。
当变更来得很快，集成测试和端到端测试就更重要。
从你最慢的反馈环节入手，而不是从新工具入手。
对精确的生产力数字保持怀疑，测量你自己的。

结语

AI让写代码变快了。如今团队之间的差别，在于代码周围发生的事：他们多快能判断代码对不对，以及是否记住了自己学到的东西。

复合工程不是一个可以安装的工具。它是一种习惯：投入到验证和共享知识上，让每项任务都让你的项目更容易维护一点。现在还早，我也不认为有人已经完全想清楚。但它背后的想法，即学习应当累积而不是蒸发，在我看来是一个稳妥的选择。

如果这周只尝试一件事，就挑出你最慢的反馈环节，把它变快。

常见问题

什么是AI领域的复合工程？

复合工程是一种借助AI代理构建软件的方式，每完成一项任务，后续任务就更容易。它不把每个功能都当作从零开始，而是记录模式、经验、测试和约定，让团队和代理在开始下一项任务时拥有更多上下文。这种方法由Every的Dan Shipper和Kieran Klaassen推广，围绕”计划、执行、评估、复合”这一循环展开。

复合工程中的”复合”是什么意思？

这个词借自复利。每一轮工作都会留下点什么，比如一个测试、一条写下来的规则或一个可复用的模式，让下一轮的成本降低一点。这种效应是逐步累积的，而不是立竿见影的。

复合工程循环包含哪些步骤？

四个步骤，每项工作都重复一遍。计划： 代理研究代码库，写出详细的实现计划。执行： 代理逐步执行计划，并在过程中运行测试。评估（插件中称为评审）：你和评审代理用测试、linter和安全检查来核对结果。复合： 把学到的东西以规则、测试或笔记的形式记录在仓库里，让后续任务从这里出发。跳过第四步，就会把它变回普通的AI辅助编程。

“复合AI”（compound AI）是什么意思？和复合工程是一回事吗？

不是。“复合AI系统”（compound AI systems）是一个不同且更早出现的术语，指由多个相互作用的组件（如模型、检索器和工具）构成的AI应用，而不是单次模型调用。复合工程讲的是你如何构建软件，它是一种开发工作流。两者在实践中有交集，因为代理系统常常是复合AI系统，也常常用这种方式构建，但它们回答的是不同的问题。

Claude Code的Compound Engineering插件是什么？

这是Every推出的开源插件，由Kieran Klaassen和Trevin Chow维护，把这个循环打包成可以在编程代理里运行的技能。主要命令包括：梳理需求的头脑风暴（/ce-brainstorm）、制定计划（/ce-plan）、执行计划（/ce-work）、多代理评审（/ce-code-review），以及记录所学（/ce-compound）。在Claude Code中，先用/plugin marketplace add EveryInc/compound-engineering-plugin添加Every的市场，再用/plugin install compound-engineering安装。它也能在包括Cursor和Codex在内的其他代理环境中运行。想了解最新版本的变化，请看Compound Engineering v3（英文）。

复合工程技能指的是什么？

有两种东西都被叫作这个名字。在插件里，技能就是上面提到的可复用命令，比如计划和评审。对人来说，真正重要的技能是：写清晰的规格、构建快速可靠的测试、批判性地评审AI写的变更，以及记录经验以免丢失。第二类技能，才是让第一类真正发挥作用的关键。

复合工程与传统软件工程有什么区别？

在传统开发中，每个功能的投入大致恒定，团队学到的大部分东西只存在于人们的脑子里。复合工程依靠代理来实现，依靠自动化检查来验证，依靠写下来的知识在任务之间传承。它关注的是从想法到经过验证、已发布变更的整条路径，而不只是代码写得多快。更详细的比较见复合工程与传统软件工程。

复合工程如何与AI配合？

AI代理承担了大量实现工作，但这种方法依赖的是它们周围的系统：用快速的自动化测试检查输出，用清晰的规格和项目指令引导，用CI/CD安全发布，以及记录所学的习惯。AI提供速度，周围的系统决定这份速度是否有用。

复合工程只是AI编程的另一个说法吗？

不完全是。AI编程是指用AI来写代码。复合工程关注的是围绕它的工作流：计划、验证、评审，以及记录知识以便累积。没有这些你也可以做AI编程，很多人就是这样做的。这是个不错的起点，但当验证和上下文成为限制因素时，你会遇到天花板。

需要是大公司才能采用复合工程吗？

不需要。小团队和独立开发者往往觉得更容易，因为要改变的流程更少。核心实践（快速的测试套件、项目指令文件，以及记录经验的习惯）上手成本很低。

复合工程需要哪些工具？

起步时需要的很少：一个AI编程工具，比如Claude Code、Cursor或GitHub Copilot；一个运行快速的测试套件；以及一条CI流水线。其他一切，包括提示词模板、规格格式和代理编排，都可以逐步加入。最重要的资产是一个快速而可靠的反馈循环。

复合工程能配合Claude Code、Cursor或Copilot使用吗？

可以。这些实践并不绑定某个特定工具。我用得最多的是Claude Code，它对项目指令文件、命令执行以及针对测试迭代的支持，与这种方法很契合。Cursor和Copilot同样可以支撑这些习惯，因为关键在于代理拥有项目上下文，并且有办法验证自己的工作。

如何开始复合工程？

从反馈循环开始。计时从想法到经过验证并部署的变更需要多久，然后改进最慢的一步，通常是测试、评审或部署。接着添加项目指令文件，把”运行测试并修复失败”作为每项任务的标准环节。最后，每完成一项有意义的工作，就把学到的东西写下来。

生成得更快，会不会导致代码质量下降？

如果你跳过验证，就会。没有检查的速度只会更快地产出错误。当每个变更都必须通过测试、类型检查和lint，并且重要的决策由人来评审时，质量是能保住的。做得好的话，代码最终可能比以前测试得更充分，但这来自检查本身，而不是AI。

转型需要多长时间？

取决于你的起点。如果你的测试和CI已经扎实，几周内就可能看到好处。如果不是，早期的大部分精力会用在改进它们上，而这无论如何都值得。“复合”的部分要经过数月才能建立起来，随着你写下的知识和护栏不断积累。