复合工程从根本上不同于传统软件工程，因为每个完成的任务都使下一个任务更容易构建，创造指数级加速而非线性进展。虽然传统团队在孤岛中并行工作，有 handoffs 和集成开销，复合工程创建一个学习系统，其中 AI agent 从积累的知识中持续改进。
传统电商构建：6个团队，18个月
想象一个典型的企业电商平台构建。一家公司决定推出一个新的在线商店，并组建了标准结构：
团队1：店面 UI - 8 名开发人员构建面向客户的 React 应用程序。他们正等待后端团队的 API 合约。
团队2：后端 API - 6 名开发人员创建 REST/GraphQL 端点。他们被阻塞，等待数据团队的数据库模式。
团队3：数据/数据库 - 4 名开发人员设计模式和迁移。他们需要来自业务团队的产品需求。
团队4：支付与结账 - 5 名开发人员集成 Stripe、PayPal 和欺诈检测。他们需要后端团队的 API。
团队5：搜索与目录 - 4 名开发人员实现 Elasticsearch 和产品发现。他们需要首先确定数据模型。
团队6：DevOps/平台 - 3 名开发人员管理基础设施、CI/CD 和部署。他们支持其他所有人。
总计：跨 6 个团队的 30 名开发人员。
线性依赖问题
这种结构在纸面上看起来是并行的，但现实中，它深度是 sequential：
第1-4周： 需求 → 数据团队设计模式
第5-8周： 数据团队 → 后端团队构建 API
第9-14周： 后端团队 → 店面团队构建 UI
第9-14周： 后端团队 → 支付团队集成的结账
第12-18周：集成 → 所有人修复破损的合约
第18-24周：QA → 所有人修复集成中发现的 bugs隐藏成本：协调开销。 每个团队花费 30-40% 的时间在协调会议、关于 API 变更的 Slack 线程和调试集成问题上。当后端团队更改端点时，其他三个团队需要更新。当数据团队添加必填字段时，下游所有人都感受痛苦。
这就是 Steve Yegge 所谓的”大教堂”——一种精心协调、架构宇航员式的方法，看起来高效但创造了巨大的隐藏成本和返工。
复合工程构建：2 名工程师，8 周
现在想象使用复合工程原则与 AI 编码代理构建相同的电商平台。
第1周：基础冲刺
两名工程师从拆分为 150 个小型、可完成任务的清晰 PRD 开始。他们使用 Ralph Loop 模式运行自主 AI 代理——新的代理实例轮换任务，每个完成一个小片段并提交，然后下一个开始。
第一批任务关注绝对基础：
- 产品的数据库模式（30 分钟）
- 基础产品 API 端点（45 分钟）
- 单个产品卡片组件（30 分钟）
- 产品列表页面（1 小时）
每个任务都足够小，可以在一个代理上下文窗口中完成。每个完成都触发测试、类型检查和验证。
复合效应开始
这就是复合工程与传统开发不同的地方：每个任务后，代理更新 AGENTS.md 文件记录已学模式。实现产品模式后，它记录：
## 数据库约定
- 使用 UUID 主键，而非 auto-increment
- 所有表包含 created_at 和 updated_at 时间戳
- 价格存储为整数分，而非小数当下一个任务需要模式（订单、用户、库存）时，代理已经知道这些约定。它不需要询问，等待批准，或安排会议。代码库教 AI 如何与之工作。
第2-3周：功能加速
到第二周，复合效应是可测量的。第一周需要 45 分钟的任务现在需要 20 分钟，因为：
- 代理知道你的 API 模式
- 测试实用程序存在，代理知道如何使用它们
- 组件约定已记录
- 错误处理模式已建立
购物车功能基于产品模式构建。结账基于购物车模式。订单历史基于结账模式。每个功能都使下一个功能更便宜。
第4-5周：高级功能
到第四周，工程师们添加复杂功能——带过滤器的搜索、推荐引擎、库存管理——以传统团队不可能实现的速度，因为：
- 整个代码库上下文记录在 AGENTS.md 文件中
- 集成模式已建立并验证
- 测试覆盖提供即时反馈
- 无协调开销——单一代码库，无团队边界
第6-8周：完善和扩展
最后几周专注于性能优化、边缘情况和运营硬化。复合知识意味着代理理解整个系统——当优化搜索时，它们不会在结账中引入 bugs，因为它们已经学会了相互依赖。
为什么复合工程根本不同
1. 知识积累，不碎片化
在传统团队中，知识碎片化存在于人员之间。开发人员 A 知道支付集成。开发人员 B 理解搜索架构。当 A 离开，那些知识随之而去。
复合工程通过 AGENTS.md 文件、内联文档和测试套件将知识存储在代码库本身。AI 代理在每个任务开始时读取这些积累的知识。知识 compound 而不是碎片化。
2. 无交接开销
传统开发由交接主导：
- 需求 → 设计
- 设计 → 开发
- 开发 → QA
- 团队 A → 团队 B
每次交接引入延迟、沟通不畅和返工。研究表明交接消耗项目时间的 30-50%。
复合工程通过让代理在全栈上工作来消除交接。创建数据库模式的同一个代理可以创建 API、UI 组件和测试——全部按顺序，无上下文损失。
3. 错误不累积，它们被立即捕获
在传统开发中，第 2 周的错误可能在第 18 周的集成测试中才浮现。到那时，六个团队已经在该错误基础上构建，修复它需要跨每个人协调。
Ralph Loop 在每个任务后运行测试和类型检查。第 30 分钟的错误在第 35 分钟被捕获，在任何依赖代码编写之前。错误修复成本低廉，因为它们尚未传播。
4. 速度随时间增加
传统项目随时间变慢。随着复杂性增长，协调开销增长更快。添加第 50 个功能比添加第 5 个更难，因为有所有需要理解和不破坏的现有代码。
复合工程反转这条曲线。添加第 50 个功能比添加第 5 个更快，因为有所有积累的知识。AGENTS.md 文件、已建立模式和综合测试使每个功能都比上一个更便宜。
数学：为什么 30 名开发人员无法竞争
让我们模拟这种差异：
传统团队（30 名开发人员）
- 原始开发能力：30 开发人员-月/月
- 协调开销：35% → 损失 10.5 开发人员-月
- 集成返工：20% → 损失 6 开发人员-月
- 上下文切换：15% → 损失 4.5 开发人员-月
- 有效能力：~9 开发人员-月/月
复合工程（2 名工程师 + AI 代理）
- AI 代理能力：100+ 任务完成/天
- 人工监督：2 名工程师审查和指导
- 协调开销：~5%（无团队边界）
- 有效吞吐量：相当于 15-20 名开发人员
复合团队不仅更快——而且更一致，因为 AI 代理没有糟糕的日子，不会分心，不会忘记约定。
传统工程做对什么
复合工程并非普遍优越。传统团队结构擅长：
需要人类创造力的新颖问题。 AI 代理擅长模式匹配和执行已知解决方案。真正新颖的架构决策仍然受益于经验丰富的人类判断。
政治和组织导航。 大企业有需要人际关系的审批流程、安全审查和合规要求。
指导和知识转移。 传统团队为初级开发人员提供 AI 辅助开发无法自然复制的学习机会。
分布式决策。 当需求真正不清晰需要探索时，多个人类视角可能是有价值的。
如何从传统过渡到复合
团队不需要翻转开关。过渡可以是渐进的：
第1阶段：向现有仓库添加 AGENTS.md。 开始记录约定、模式和陷阱。这既帮助人类开发人员也帮助未来的 AI 代理。
第2阶段：改善反馈循环。 投资于综合类型检查、自动化测试和 CI/CD。这些是自主代理工作的先决条件。
第3阶段：将工作分解为更小的任务。 无论谁执行任务，都练习将功能分解为可在 30-60 分钟内完成的任务。
第4阶段：在独立功能上运行代理。 让 AI 代理处理新功能，同时人类团队维护现有代码。比较速度和质量。
第5阶段：扩展代理使用。 随着信心增长，将代理驱动开发扩展到更多代码库。
不舒服的真相
不舒服的真相是大多数传统团队结构存在组织原因，而非工程原因。公司雇佣 30 名开发人员，因为那是预算的工作方式、管理者建立帝国的方式以及职业阶梯运作的方式——并非因为 30 人协调比 2 人配强大工具更高效。
复合工程暴露这种低效率。当 2 名带 AI 代理的工程师超越 30 人团队时，组织必须正视他们实际在支付什么。
这并不意味着大规模裁员即将到来或人类开发人员过时。它意味着工作的性质正在转变——从敲代码到设计系统，从协调开销到创造性解决问题，从执行到判断。
结论
复合工程代表着从线性、并行团队软件开发到指数级、知识积累开发的根本转变。电商示例清楚地说明了这一点：传统团队花费数月跨边界协调，而复合工程随每个完成任务加速。
率先采用复合工程实践的团队将具有显著竞争优势——不仅在速度上，而且在质量和一致性上。其代码库中积累的知识将使它们加速，而竞争对手仍困于线性进展。
问题不是这种转变是否到来。它已经在这里。问题是你是用复合工程构建还是与那些使用它的人竞争。