AI 开发提效要靠交付流程与质量检查

在一项随机试验中，使用 AI 工具的资深开发者完成任务所需的时间反而增加了 19%。研究开始前，他们预计 AI 会让自己提速 24%。研究结束后，他们仍然相信 AI 加快了自己的工作速度（METR，2025）。

同一年，还有另一组数据：Faros AI 报告称，AI 采用程度更高的团队完成的任务数量增加了 33.7%，但每位开发者产生的 bug 也增加了 54%，每个 PR 对应的事故数量增加了约 240%（Faros AI）。

所以，AI 生成代码更快，但我们不善于判断自己是否真的更快完成了工作，也不善于判断结果是否更好。这种落差正是本文的核心。如果你希望 AI 真正承担交付流程中的一部分工作，就必须像对待工厂一样对待它：明确的输入、明确的工作站，以及每个工作站上的质量检查。本文将介绍什么是软件工厂，它如何融入 AI 驱动的开发生命周期（ADLC），以及良好的 Plan、Build 和 Evaluate 循环应该是什么样。本文面向有权调整团队流水线、审查流程和权限设置的技术负责人及工程经理。

先简要说明一下术语。“ADLC”有多种含义。本文用它表示 AI-Driven Development Life Cycle，即 AWS 以 AI-DLC 之名发布的模型。也有人用 ADLC 表示“智能体式”开发生命周期。两者的理念有很多重叠，但下文引用的资料均指向 AWS 版本。

软件工厂究竟是什么？

这个术语出现得比 AI 热潮更早。美国国防部用它指代一组流水线：以尽可能少的人工干预，将源代码转化为可部署的产物。在这个版本中，流水线由人来操作。

新的智能体式含义改变了分工。Faros 将软件工厂定义为一个系统：使用“AI 智能体、工程工具、组织上下文”，结合自动化工作流、验证和人工判断，推动工作直至软件发布（Faros AI）。它包含三个部分：

任务接入与编排。一个运行控制框架（harness）决定由哪些智能体和模型接手任务、向它们提供哪些工具和上下文，以及在哪些节点必须获得人工批准。

知识与执行。上下文工程、智能体记忆和技能为智能体提供所需的信息与能力，智能体则在受控环境中工作。

验证与反馈。测试、评估、审查智能体和人工审查共同决定工作能否继续推进。反复出现的失败会反馈到系统中。

人的角色也随之改变。你编写的代码更少，而花在规格说明、验收标准、智能体上下文、评估、权限，以及需要判断的边界情况上的时间更多。

需要提醒的是：Faros 销售的正是面向这一场景的平台，而且该页面也承认，目前尚无标准定义，也没有行业基准。请将这个框架视为一个有用的视角，而非已经确立的定论。

AWS 在 2025 年 7 月的一篇文章中介绍了 ADLC（AWS DevOps Blog）。其核心理念是：AI 位于流程中心，而决策权仍由人掌握。它包含三个阶段：

有两处术语替换需要了解。Bolt 取代了 sprint，AWS 将其描述为“以小时或天衡量，而非以周衡量”的工作周期。Unit of Work 取代了 epic。

请注意，AWS 的文章没有提供任何实测结果。“从数周缩短到数天”是一项主张，而非基准测试结果。AWS 还将这套工作流开源为规则，可加载到 Amazon Q Developer 等工具中（awslabs/aidlc-workflows）。

工厂的比喻在这里很贴切。ADLC 是工厂车间的布局，软件工厂则是车间里的机器和质量控制机制。

为什么这些关卡很重要：研究怎么说

三项研究发现塑造了我对这个问题的看法。每一项都指向一个不同的关卡。

1. AI 在小而明确的任务上速度最快。这对应 Plan 关卡。在 2023 年的一项实验中，使用 GitHub Copilot 的开发者完成用 JavaScript 构建 HTTP 服务器的任务时，比对照组快了 55.8%；其 95% 置信区间较宽，为 21% 至 89%（Peng 等，arXiv:2302.06590）。这是一项从零开始、独立且规格明确的任务。提速正是在这样的条件下出现的。这里的启示不是“AI 能让所有事情都变快”，而是“输入小而清晰时，AI 很快”。在生成任何代码之前，通过关卡拒绝模糊或过大的任务，就是在有意识地创造这种条件。

2. 开发者无法凭感觉判断 AI 是否有帮助。这对应 Evaluate 关卡。METR 的试验让 16 名资深开源开发者，在他们熟悉的代码仓库中完成了 246 项任务。使用 AI 使完成时间增加了 19%，但开发者却认为 AI 让自己变快了（METR，arXiv:2507.09089）。METR 自己也指出，这只是某个时间点上的一项研究，因此不要将其解读为“AI 很慢”。应该将其理解为“你对速度的感觉并不可靠”。如果连执行任务的人都无法判断，那么唯一的判断方法，就是在流程末尾设置一个关卡，将实测结果与基线进行比较。

3. AI 会放大你现有的流程。这对应 Build 关卡。DORA 2025 报告指出，“AI 的主要作用是放大器，放大组织已有的优势和弱点”，而最大的收益来自组织系统，而非工具（DORA 2025；另见 DORA AI Capabilities Model）。脆弱的交付流程加上 AI，得到的是运行得更快的脆弱交付流程。生成代码与主分支之间的检查，例如测试、扫描、权限控制和人工审查，也是会被放大的流程组成部分。如果这些检查薄弱，AI 就会产生更多未经检查的代码。如果检查有力，AI 就会产生更多经过检查的代码。

综合来看：在某些条件下，提速确实存在；在另一些条件下，提速并未体现；而质量成本往往在后期才出现。每个阶段的关卡，都是为了创造有利条件、尽早发现这些成本，并判断整套机制是否有效。本文其余部分将逐一讨论这三个关卡：Plan、Build、Evaluate。

阶段 1：Plan（Inception，启动）

良好的状态是：在生成任何代码之前，先形成一份简短、书面且经过人工批准的计划。

在 ADLC 中，这个阶段由 AI 提问，团队回答。AWS 的文章描述了这样的流程：AI“制定工作计划、提出澄清问题”，只有在计划通过验证后才开始实施。决策由人来做，因为业务上下文掌握在他们手中。

由此可以推导出一些实用做法（这些是我基于上述资料提出的建议）：

让 AI 采访你。告诉它业务意图，请它列出尚不明确的事项。以书面形式回答。这些回答会成为后续每一步的上下文。

拆分成小的工作单元。一个单元应该能让审查者一次坐下来就完成审查。如果无法快速审查，说明这个单元太大了。

先写验收标准，再写代码。标准必须可检查：一个测试、一条查询，或一次截图对比。“运行良好”不是标准。

现在就确定关卡。为每个单元明确谁批准什么，以及智能体不得触碰哪些内容（身份认证、计费、迁移、生产环境配置）。

将上下文保存在文件中。规格说明、架构说明和编码规范应放在代码仓库里，供智能体读取。这就是工厂中的“上下文工程”部分。

常见错误：因为智能体速度快，就跳过计划。快速生成错误的东西，结果依然是错的，而且现在还有更多内容需要审查。

阶段 2：Build（Construction，构建）

良好的状态是：规模小的 bolt、受到限制的智能体，以及在人类阅读任何一行代码之前就已运行的自动化检查。

在 Construction 阶段，AI 提出架构、领域模型、代码和测试方案，团队则对重要的技术决策提供意见。以下做法有助于让这个阶段保持可控：

让每个 bolt 都保持短小、范围有限。一个工作单元、一个分支、一个 PR。小批次让审查切实可行，也让回滚成本更低。

让测试来检验实现。要求智能体先根据验收标准编写测试，再编写实现。如果测试和代码都来自同一个提示词，又没有独立检查，那么测试可能只是在为 bug 背书。

在评审之前运行自动化关卡。Lint、类型检查、测试和安全扫描应当让不合格的 PR 提前失败，避免有人为它投入时间。

限制权限。智能体只获得完成任务所需的最低权限。由执行框架决定“这个任务可以使用哪些工具”，正是工厂模型所描述的机制。

评审代码差异，而不是凭感觉判断。自动化检查能告诉你代码可以运行，只有阅读代码的人才能判断它是否做了正确的事。人类仍须为每一次合并负责。

常见错误：让评审沦为走过场。当 AI 每天生成十个 PR 时，评审就会成为瓶颈，草草浏览的压力也会越来越大。应该改进流水线，例如缩小 PR、完善自动化检查，而不是要求评审者更有耐心。

阶段 3：评估（及运行维护）

理想状态：你在系统层面衡量结果，失败会推动工厂本身的改进，而不只是修改代码。

这是团队最常跳过的阶段，而 METR 的研究结果说明了为什么不能跳过它。开发者感觉自己变快了，实际却变慢了。在这里，感觉并不可靠。

关注交付指标，而不是活动指标。包括交付前置时间、部署频率、变更失败率和恢复时间。代码行数和“接受的 AI 建议数量”只能反映使用情况，不能反映价值。

把质量与速度放在一起看。始终将缺陷和事故与吞吐量并列展示。本文开头提到的 Faros 所揭示的模式，正是你需要尽早发现的情况。

建立基线。在团队引入 AI 之前，记录各项指标。没有基线，你就和 METR 研究中的参与者一样，只能靠猜测。

评估智能体本身。保留一小组有代表性的任务，每次修改提示词、模型或规则文件时，都重新运行这些任务。

不要认为一个模型适合所有任务。Faros 报告称，整体表现最好的模型路由方案，只在 211 个任务中的 84 个任务上表现最佳。因此，一个默认模型很可能无法在所有任务上都达到最优。

将事故复盘的反馈纳入工厂。当智能体编写的变更导致故障时，要问：哪个关卡本应发现这个问题？然后改进这个关卡：增加测试、收紧规则、更新上下文文件。Faros 将其描述为把反复出现的失败反馈到系统中，以改进系统。

保留审计轨迹。ADLC 会记录每个阶段的输入、决策和响应。当生产环境出问题时，你需要知道智能体收到了哪些信息，以及是谁批准的。

常见错误：只衡量个人生产力。DORA 所说的放大效应针对的是组织。个人速度的提升如果没有体现在交付稳定性上，就算不上成功。

一个工作单元经过三个关卡

为了说得更具体，下面以一次小变更展示整个循环。这个例子用于说明流程，并非案例研究。

需求。产品团队要求对登录端点实施速率限制。来自同一来源的失败尝试过多时，应暂时阻止其继续尝试。

规划。团队将业务意图交给智能体，并要求它列出尚不明确的事项。智能体提出了以下问题：允许尝试多少次、时间窗口多长、按 IP 还是按账户限制、被阻止时客户端会看到什么，以及同样使用登录端点的管理工具是否会受到影响。团队以书面形式回答：每个 IP 在 15 分钟内允许 10 次失败尝试，超限时返回 HTTP 429 和 Retry-After 响应头，管理工具必须继续正常运行。这些回答成为验收标准：

同一 IP 在 15 分钟内的第 11 次失败尝试，返回 429 和 Retry-After。

登录成功后，重置该 IP 的计数器。

现有的管理工具集成测试仍然通过。

此时就明确关卡要求。智能体可以修改认证中间件及其测试，但不能修改会话存储、数据库迁移或生产环境配置。一名后端负责人批准了计划。这些回答和验收标准与工作单元一起保存在代码仓库中。

构建。一个 bolt、一个分支、一个 PR。智能体先根据这三项标准编写测试，评审者在实现代码出现之前先阅读测试。其中一个测试有误：它在每次登录尝试时都重置计数器，而不是仅在登录成功时重置。评审者修正了这个测试。随后，智能体编写中间件，PR 中的 lint、类型检查、测试和依赖扫描全部通过。评审者阅读了大约 80 行的代码差异，发现计数器存储在进程内存中，一旦服务运行在两个实例上，这种实现就会失效。这是计划中的缺漏，而不是代码中的缺陷，因此团队更新了计划，改用现有的 Redis 缓存。智能体进行了第二轮修改，随后 PR 被合并。

评估。变更发布了。两天后，支持团队报告：一些用户处于共用的办公网络中，当几名同事输错密码后，其他用户也被阻止登录。事故复盘的问题是：哪个关卡本应发现这种情况？答案是规划。“按 IP”对于共用网络而言是错误的限制粒度，而当时没有人询问这种场景。对工厂的改进，是在上下文文件的认证部分增加一行：“速率限制必须处理共用 IP 的情况”，并将一个澄清问题固定加入今后所有认证相关工作的流程。事故记录关联了最初的计划、问答和审批记录，形成完整的审计轨迹。在团队仪表板上，这个工作单元显示为一天的交付前置时间和一次变更失败，并与团队开始使用智能体之前记录的基线并列展示。

这就是完整的循环。注意每个关卡发挥的作用。规划将模糊的需求转化为三项可检查的标准和一份禁止操作清单。构建在合并前发现了一个错误的测试和一处设计缺漏。评估将一个漏过检查的问题转化为对规划关卡的永久改进，让下一次认证相关变更有更好的起点。

如果你只有时间先做一件事：建立基线，并将质量与速度放在一起衡量。一旦你能看清自己的工厂实际产出了什么，其他事情都会变得更容易。

我不会作出的断言

AI 会让每个团队都变快。现有证据并不一致，最知名的几项研究也因任务和开发者不同而得出了不同方向的结论。

ADLC 已经得到大规模验证。AWS 的文章提供了方法，并声称能“从数周缩短到数天”，但没有提供独立验证的结果。

上述任何指标都能说明因果关系。大多数行业数据只能反映相关性，而且部分来源是供应商。

有用的结论范围更窄，但在我看来也更经得起时间检验：AI 会放大你的流程。先让你的流程值得被放大。

Peng, S., Kalliamvakou, E., Cihon, P., Demirer, M.（2023）。《AI 对开发者生产力的影响：来自 GitHub Copilot 的证据》。arXiv:2302.06590。

METR（2025）。《衡量 2025 年初的 AI 对资深开源开发者生产力的影响》。arXiv:2507.09089。

DORA（2025）。《AI 辅助软件开发现状》。

DORA（2025）。《AI 能力模型》。

AWS DevOps & Developer Productivity Blog（2025 年 7 月）。《AI 驱动的开发生命周期》。

AWS Labs。aidlc-workflows（开源 AI-DLC 规则工作流）。

Faros AI。《什么是软件工厂？》（来源为供应商；阅读时请考虑这一点）。

如需进一步采取行动，你可以考虑屏蔽此人和／或举报滥用行为。