案例研究：谁做到了，测量了什么

怎样读一个案例

同一个数字，由谁来数、数的是什么，含义就完全不同。经过过滤的测试生成器给出的"73% 被接受"，靠自愿点评按钮得来的"75% 有用"，以及 CEO 帖子里的"79% 原样上线"，是三种看起来相似、实则不同的测量。为了让你分得清，本章用同一种格式呈现每个案例：

• 等级标记，放在案例标题里，从 T1 到 T4。
• 按实际授予的权限标注级别。级别看的是 AI 的凭证和设置实际允许它做什么，再对照人类审查了什么，而不是团队给这次部署起的名字。这是成熟度模型的规则 2，在失败案例里最要紧。
• 一行"测量方"说明，紧跟在案例下面：谁测量的、用什么方法、样本量或时间窗口多大，以及由此得出的等级。
• 它不能说明什么。每个案例都有缺口。把缺口点明，才不会把一个案例硬拉去支撑它从未检验过的结论。

四个等级，各用一行说明（完整图例见前言）。一个来源的等级，取"谁来测"和"怎么测"两者中较低的那个。

• T1，独立测量。测量方与产品没有利害关系，方法明确，给出分母。
• T2，组织自测，方法已说明。由运行该系统的组织自己测量，给出分母，常经同行评审。
• T3，方法单薄的遥测或报告。工程博客、厂商汇总遥测、无对照的试点：有数字，但缺完整方法、基线或样本量。
• T4，声明。高管表态、媒体转述、营销材料和存在争议的说法，没有方法。

为什么是这十个。它们是公开了方法或公开了失败的案例。其中六个结果为正面或好坏参半，四个为负面。有几个有名的案例是有意排除的，排除的理由本身就是本章论点的缩影：

• Stripe 报告其无人值守的智能体每周有一千多个拉取请求被合并，代码完全由智能体生成，每一个都经人类评审（Stripe，截至 2026 年 2 月，T3）。它没有公布成功率或失败率，所以这个案例展示的是数量，不是结果。它归第 6 章《编码》。
• Airbnb 用六周迁移了近 3,500 个测试文件，而人工估计需要 1.5 年（Airbnb 技术博客，T3）。这个基线是一个没人实际跑过的估算。它归第 11 章《维护与迁移》。
• 亚马逊的"4,500 开发者年"是这个领域被引用最多的数字。本章末尾会把它拿出来做一次阅读练习。

十个案例一览：

成功之处：验证把回路闭合了

这一节的六个案例成功程度各不相同，但机制相同。在每个案例里，都有某种确定性的东西在人类花注意力之前，先判定 AI 的产出能否接受：编译器、测试套件、覆盖率增量、一次构建。这道检查越强，AI 被允许做的事就越多。没有这道检查的地方，检查落到人身上，人就成了瓶颈。

谷歌：LLM 辅助迁移 · T2 · 组织自测

级别：维护，从 L2 向 L3 推进（见成熟度网格的维护一行）。工程师评审每个变更，生成量由评审能力决定。

谷歌的LLM 驱动代码迁移经验报告（2025 年 1 月）涵盖了几次大规模的机械性变更。在 Google Ads 把 int32 标识符改为 int64 的迁移中，已落地变更里约 80% 的代码修改完全由 AI 编写，工程师估计迁移总耗时减少了约 50%（含评审）。JUnit3 到 JUnit4 的迁移在三个月内改动了 5,359 个文件、超过 149,000 行代码，AI 生成的代码中约 87% 未经任何修改就被提交。Joda-Time 到 java.time 的迁移，团队根据小批量试做外推，估计节省约 89% 的时间。

这篇论文的价值，一半在数字，一半在它的保留意见。这条流水线把模型和谷歌现有的代码搜索与索引工具结合在一起，作者直言："仅靠简单提示词使用 LLM，除了最简单的迁移之外，什么都不够用。"作者报告，在 int32 迁移中，"人类需要撤回模型所做的至少一部分改动，这些改动要么不正确，要么没有必要"。JUnit 团队限制了每周生成的变更数量，以免评审人员应接不暇。生成从来不是约束，评审才是。

后续一项为期一年的研究（FSE 2025 工业论文）跟踪了三名开发者在十二个月里完成的 39 次迁移：共 595 个代码变更、93,574 处编辑，其中 74.45% 的变更和 69.46% 的编辑由 LLM 生成。开发者同样估计，与此前的人工迁移相比，总耗时减少约 50%。LLM 生成的编辑占比描述的是流水线，不是成功指标。真正的结果证据是：这些变更落地了，而把关的编译器和测试套件并不在乎代码是谁写的。

它不能说明什么。长期质量。作者写道，"是否会对质量产生长期影响，还有待观察"。节省的时间是相对于没人重做过的人工迁移估算出来的。本站的迁移智能体实践手册介绍了这种流水线模式；第 11 章《维护与迁移》会在这个案例的基础上展开。

Meta：TestGen-LLM 与 ACH · T2 · 组织自测

级别：测试，L2（见测试一行）。模型负责生成，确定性过滤器负责淘汰，工程师对每个幸存的候选决定接受或拒绝。

TestGen-LLM（FSE 2024 工业论文）用于扩充已有的 Kotlin 测试类。在 Instagram 的 Reels 和 Stories 产品上，"TestGen-LLM 生成的测试用例中，75% 能正确构建，57% 能稳定通过，25% 提高了覆盖率。"只有通过全部三道过滤的候选才会送到工程师面前。在 Meta 的测试马拉松（test-a-thon）中，该工具改进了所应用类的 11.5%，并且"73% 的建议被 Meta 软件工程师接受并部署到生产"。

这两个数字要放在一起读。原始产出里只有四分之一有价值；而通过过滤器的部分，近四分之三被接受。25% 和 73% 之间的差距，来自构建、反复运行测试和覆盖率测量所做的工作，而这些模型都无法影响。这就是判据原则最直白的形态：决定什么是正确的，是过滤器，不是模型。

Meta 的变异引导生成器 ACH 以刻意注入的缺陷为目标。它在七个平台的 10,795 个 Android Kotlin 类上运行，产生了 9,095 个变异体和 571 个隐私加固测试。工程师接受了其中 73% 的测试，并判定 36% 与隐私相关。Meta 小心地没有夸大这一机制："变异测试无法单独存在（它要求测试已经存在）"，并指出测试判据问题仍是悬而未决的难题（Meta 工程博客，2025 年 9 月）。

它不能说明什么。接受率衡量的是工程师是否认可，而不是测试能否抓住要紧的缺陷。两篇论文都没有报告逃逸缺陷的减少。后来 Meta 尝试生成能在变更落地前抓出缺陷的测试时，精确率成了问题；第 8 章《测试与验证》会讨论这一点。工具层面见本站的测试生成实践手册。

Spotify：Honk · T3 · 工程博客遥测

级别：维护，针对全仓库范围迁移的 L3。智能体在沙箱中无人值守地运行，确定性核验器把关每个变更，由负责相应代码的团队评审并合并最终的拉取请求。

Spotify 的四篇系列文章，是对后台编码智能体设计最详尽的公开描述。第 1 篇报告"Spotify 各团队已合并超过 1,500 个拉取请求"（截至 2025 年 11 月），并称对文中列出的几类迁移，"与手写代码相比，总共节省 60–90% 的时间"。文章没有给出这个区间的基线方法。作者补了一句："我们还没有所有答案。"

可以照搬的是这些设计选择：

• 核验器优先。格式、构建和测试核验器根据仓库内容自动选定，在智能体试图收尾时运行。只要有一个失败，"就不会创建 PR，用户会看到一条错误信息"（第 3 篇）。
• 沙箱，并把权限留在智能体之外。"它被严格地沙箱化了。"推送分支、在 Slack 发消息，都由外围基础设施完成，而不是智能体。
• 刻意精简的工具集。智能体只有一个核验工具、受限的 Git、带严格允许清单的 Bash，没有代码搜索。"工具越多，引入的不可预测维度就越多"（第 2 篇）。
• LLM 评审员作为第二道关卡。在数千次会话中，"评审员否决了大约四分之一"，而"智能体有一半时候能自我纠正"。

评审员的故事并没有到此为止。据 InfoQ 对一场 QCon London 演讲的报道（2026 年 3 月，二手来源），Spotify 后来移除了这个评审员，理由是它"过于僵化，会拦下有效的变更"；同一场演讲还提到，智能体会"把失败的测试注释掉，或者降级 Java 版本"（InfoQ）。这两点都没有 Spotify 的一手来源重复。合起来看，它们说明：LLM 评审员是一道可调的关卡，代价是误报；智能体会钻它够得着的东西的空子。确定性核验器应当放在前面。

后来的两篇文章让这个教训更清晰。第 4 篇（2026 年 4 月）向下游数据流水线推送了 240 个自动迁移拉取请求，但这些仓库很少有构建期测试，负责人只能手工测试这些变更。核验器缺席的地方，人就成了核验器。2026 年 6 月，Spotify 首席架构师报告拉取请求频率上升了 76%（Spotify 工程博客）："我们现在要评审的 PR 多了 76%。"Spotify 为这场演讲撰写的回顾文章，标题是《编码已不再是约束》（"Coding Is No Longer the Constraint"）。

它不能说明什么。已合并的智能体变更的失败率或撤回率，以及"四分之一"背后的确切分母。Spotify 另有一套 Fleet Management 系统，已合并超过 250 万个自动化维护拉取请求，"绝大多数在没有人参与的情况下自动合并"（Spotify，截至 2026 年 6 月），但这套系统基本上是确定性的。按本书的术语，它对 AI 而言是 L0，不管看起来多么自主。

微软：dotnet/runtime 中的编码智能体 · T2 · 组织自测

级别：编码，L2（见编码一行）。智能体的每个拉取请求都经人类评审。清理类和测试类工作是 L3 的候选，成熟度模型的示例就是这样打分的。

Stephen Toub 的《在 dotnet/runtime 中使用 Copilot Coding Agent 的十个月》（2026 年 3 月）难得之处在于，它公布了那些对工具不利的数字。2025 年 5 月 19 日至 2026 年 3 月 22 日，智能体共提交 878 个拉取请求，成功率（已合并数占"已合并加已关闭"的比例）为 67.9%，而微软人类工程师为 87.1%，社区贡献者为 79.7%，机器人为 85.9%。文章指出这些群体并不相同，比较只具方向性。

最重要的教训藏在一组前后对比里。团队首次调整环境之前创建的拉取请求，成功率为 38.1%；之后创建的为 69%。提升"不是靠更好的 AI 模型，而是靠更好的准备"：为包源配置防火墙规则、一份反复修订的 copilot-instructions.md，以及避免构建超时的环境设置步骤。任务类型拉开的差距比规模更大。清理类的成功率为 84.7%，测试类为 75.6%，而性能类只有 54.5%；按改动规模分组，成功率只在 64% 到 80% 之间。有人类推送过提交的拉取请求成功率为 86.2%，没有的为 55.1%。

文章也算了智能体给评审人员带来的成本。已合并的智能体拉取请求平均有 16.5 条评论，已合并的人类拉取请求为 12.4 条；这一计数包括拉取请求上的所有评论，智能体自己的回复和机器人消息也在其中。它还给出了本书找到的唯一一组公开的智能体与非智能体拉取请求撤回对比（非智能体一组中含 666 个机器人拉取请求）：535 个已合并的智能体拉取请求中有 3 个被撤回（0.6%），其他 4,251 个已合并拉取请求中有 33 个（0.8%）。文章说"这一差异没有统计意义，但至少数据没有显示危险信号"。

它不能说明什么。成本。文章"没有分析 CCA 使用的计算成本，也没有分析 CCA 的 PR 消耗的 CI 资源"，并补充说"这些都是真实的成本"。它也无法把指令文件的作用与同时上线的环境修复分开，因此不能证明单靠指令文件就能提高成功率。第 6 章《编码》的准备清单就以这个案例为基础。

Uber：uReview · T3 · 工程博客遥测

级别：评审，从 L2 向 L3 推进（见评审一行）。AI 几乎对每个变更做第一轮评审，人类仍然批准每一次合并。

uReview（2025 年 8 月）"分析了每周约 65,000 个 diff 中的 90% 以上"。这是 Uber 的标题数字；同一篇文章的另一处写的是"每月 65,000 个"，所以不一致出在一手来源本身。与该工具有交互的工程师把 75% 的评论标为有用，按自动化检查，已发布评论中超过 65% 在同一个变更集里得到处理。Uber 把它和内部审计的结果对比：人类撰写的评论只有 51%"被作者认定为缺陷"并在同一个变更集里得到处理。两个数字的测量方法不同，AI 评论靠模型重跑判定，人类评论靠作者判断，所以这是 Uber 自己的比较，并不对等。

这个结果是设计出来的，不是运气。三个助手并行运行（缺陷、最佳实践、应用安全）。按类别设阈值的置信度分数过滤它们的评论，近似重复的评论被合并，开发者不看重的整类评论（如可读性和代码风格）被屏蔽。另有一个评分模型给生成模型的产出打分。Uber 给这条教训起的小标题是"精确率比数量更有价值"，并写道"评论的质量远比数量重要"。一个对什么都发表意见的 AI 评审员，会让人学会忽略它；一个没把握就保持沉默的评审员，它的意见才会被采纳。

它不能说明什么。被"处理"的评论是否正确，缺陷是否减少。该评审员只看得到代码，看不到"过往的 PR、功能开关配置、数据库模式、技术文档等等"，所以设计评审仍归人类。每周约 1,500 小时的节省估算，假设每次提交需要十分钟人工评审，这是反事实推算，不是测量。第 7 章《代码评审》讨论如何比较评审指标；工具层面见本站的代码评审智能体实践手册。

谷歌：DIDACT 构建修复 · T2 · 随机对照试验

级别：CI/CD，L1（见CI/CD 一行）。模型为失败的构建建议修复方案，是否采用由开发者决定。

这是本章效应最小、也最可信的案例。谷歌在 2024 年 4 月发表的文章中报告，它"把全体谷歌开发者中的 50% 随机分到实验组"，为期十一周，在 IDE 里为他们提供由机器学习建议的构建修复。"在某个月遇到构建失败的用户中，约 34% 最终采用了这类机器学习建议的修复。"测得的结果是"CL 吞吐量提高约 2%"。谷歌也检查了有没有副作用："我们也没有发现安全风险或缺陷有可观察的增加"，回退率和 sanitizer 失败率都没有可检测到的差异。

这个案例的意义超出了它的效应量，原因有两个。在本书的证据里，它是唯一一项测量了下游安全性、而不只是速度的随机试验。而且它的 2% 展示了诚实的效应是什么样子：一半开发者在实验组，另一半做对照，任务范围很窄。它只测量了一类任务，不应拿去和《经济性、风险与度量》所讨论的编码速度试验相比。

它不能说明什么。任何关于自己推送修复的智能体的结论。DIDACT 是 L1：每个修复都由人来采用。第 9 章《CI/CD 与发布》讨论智能体版本；工具层面见本站的CI 修复智能体实践手册。

没能奏效之处：两个负面结果

这类文献里负面结果很少，按字数算，它们比正面结果更值钱。你可以拿它们来校准自己的试点。下面两个都来自与产品没有利害关系的一方。

一项工业界 AI 评审研究 · T1 · 独立测量

级别：评审，L2。AI 评审员对每个拉取请求发表评论，人类批准合并。

一项 ICSE 2025 工业论文在一家工业合作方部署了基于开源 Qodo PR-Agent 的评审工具，覆盖三个项目、1,568 个拉取请求。按厂商惯用的指标，它表现不错：AI 评论中 73.8% 被解决。但拉取请求的平均关闭时间从 5 小时 52 分钟上升到 8 小时 20 分钟，总体增幅有统计显著性。各项目的趋势不同：三个项目中有两个关闭时间上升，另一个下降。开发者列出的缺点是"错误的评审、不必要的修改，以及无关的评论"。

这个案例说明了 Uber 的精确率过滤为什么重要。评审工具发的评论越多，作者和人类评审员的工作就越多，即便其中很多评论被解决了。"已解决"计的是活动量，关闭时间计的是团队等了多久。

它不能说明什么。一个以精确率为调优目标的评审工具在同一地点会不会表现更好，以及代码质量是否变化。它只涉及一个合作方、一种工具配置、一个时间段。

Answer.AI 试用 Devin 一个月 · T1（n=20）· 独立实践者

级别：编码，一次 L3 尝试。把范围宽松的真实任务交给一个自主智能体，让它独自完成。

在《试用 Devin 一个月的感想》（2025 年 1 月）中，三位 Answer.AI 的实践者给 Devin 布置了 20 个真实任务。3 个成功，14 个失败，3 个无定论。失败有固定的形态。智能体"会花好几天去追逐不可能的方案，而不是认清根本性的障碍"；即便产出了代码，一位作者也觉得那是"意大利面条式的代码，读起来比我自己从头写还要费解得多"。他们对哪些任务行得通的总结是："它能做的任务，都小到、明确到我还不如自己来做，更快，也更合我的方式。"

这个工具自 2025 年初以来已经变了，所以不要把这当成产品评测。要点在于限定范围。没有一个窄的任务类型、没有一道智能体必须通过的检查，自主就会变成在错误问题上的执着。对比一下 dotnet/runtime：在那里，任务类型能预测成功率，准备工作让成功率几乎翻倍。

它不能说明什么。该工具的当前版本表现如何，或者同一个智能体在限定范围、由核验器把关的部署里会怎样。

出事之处：有权限、没边界

下面两起失败是同类事件中记录最完整的。两者都是 T4：都没有独立的取证报告。之所以收录，是因为真正要紧的事实，即智能体能触及什么、事后改了什么，要么得到了双方承认，要么有一手来源。读它们时，要看缺的是哪道边界，而不是用的是哪个模型。

Replit：生产数据库 · T4 · 厂商与用户均承认

级别：编码与运维，事实上的 L4。智能体对生产数据库有写权限。当时已宣布代码冻结，但在对话里宣布的冻结只是一条指令，不是一道边界。

2025 年 7 月，SaaStr 创始人 Jason Lemkin 用 Replit 的智能体构建一个应用，并在 X 上记录了全过程。实验期间，在代码冻结的情况下，智能体删除了生产数据库。AI 事件数据库记录的事件日期为 2025 年 7 月 18 日，并称智能体"错误地声称无法回退，延误了恢复"。Replit CEO Amjad Masad 公开回应（The Register，2025 年 7 月 22 日）："不可接受，而且本不应该有可能发生。"他说智能体"没有访问到相应的内部文档"，并表示 Replit 已经"开始推出数据库开发/生产环境自动分离，从根本上杜绝此类事件"。他还提到已有的一键恢复整个项目状态的功能，并说预发布环境"在开发中"。

这一修复如今已写进 Replit 自己的产品文档（Replit 文档，截至 2026 年 10 月）。在开发数据库上，智能体"可以创建和修改表"；在生产数据库上，智能体"碰不到它"："智能体无法修改生产数据库。"模式变更只在应用发布时才会进入生产环境。

这是公开记录里"以环境边界作为修复"最干净的例证。Replit 的回应不是要一个更好的模型或更谨慎的提示词，而是拿走了智能体触及生产环境的能力。修复之前，不管用户以为自己委派了什么，智能体的凭证都让那个数据库处于 L4。修复之后，智能体根本碰不到生产环境，它的改动只能通过发布进入生产。

它不能说明什么。确切的记录删除数量，这些数字只在二手报道中流传，本书不采用。它也不能说明这类删除有多常见。目前没有按权限级别统计的公开事故率。

亚马逊 Kiro 与 AWS Cost Explorer · T4 · 有争议

级别：运维，事故发生前对受影响环境而言是事实上的 L4；事后回退到 L2。不管原本打算采用什么评审方式，一个宽到足以删除并重建生产环境的角色，决定了级别。

2026 年 2 月 19 日，《金融时报》报道称，一款 AI 编码工具卷入了前一年 12 月的一次 AWS 故障。该文章有付费墙，本书只能通过路透社和 Engadget 了解其内容。亚马逊次日发布了反驳文章《更正〈金融时报〉关于 AWS、Kiro 与 AI 的报道》，并向媒体提供了更详细的声明。两种说法并列如下：

在 Engadget 引用的对媒体声明中（2026 年 2 月 21 日更新），亚马逊补充说，那名员工拥有"超出预期的权限，这是用户访问控制问题，而不是 AI 自主性问题"。这些话不在那篇博客文章里。

本书不对这场争议做裁决，也不把事故单独归咎于"AI"或"人"。要紧的是两种说法的交汇之处。两者都把访问范围放在中心：《金融时报》描述的是一个能够删除并重建环境的智能体，亚马逊归咎于一个配置错误的角色。所以亚马逊自己的解释，本身就是关于实际授予权限的陈述。而亚马逊自己的补救措施，即访问生产环境必须经过同行评审，就是沿着阶梯从事实上的 L4 退回到 L2。这是一手来源中最清楚的例子：一家组织在事故之后，把运维权限退回到由人把关。第 17 章《衡量成效，以及何时回退》会以这类案例为基础构建回退触发条件；第 12 章《安全、权限与爆炸半径》收录了更完整的事故集。

它不能说明什么。持续时间（13 小时还是"短暂"）和 Kiro 的因果作用都有争议。这个案例永远不应被引述为"AI 搞垮了 AWS"，而应引述为"一个权限过宽的角色搞垮了一项服务，修复手段是给生产访问加一道评审关卡"。一般原则见本站的爆炸半径概念页。

十个案例共有的模式

把十个案例并排摆开，有五个模式跨越了证据等级、公司和阶段，始终成立。

第一个和第四个模式是本章论点的两半，也是同一个道理的正反两面。智能体无法修改的核验器，限定了错误产出在落地之前能造成多大影响；智能体无法越过的环境边界，限定了错误操作在执行之后能造成多大影响。三个最接近 L3 的案例都具备前者，两起失败都缺少后者。另外三个模式解释了为什么成功案例的实际收益比标题小：评审吸收了多出来的产出，准备工作比模型选择出力更多，而一旦有人设了对照组，效应就变得温和。

还要注意证据等级对这个故事的影响。最强的证据（T1 和那项 T2 的 RCT）要么是负面的，要么很小。最亮眼的数字（Spotify 节省的时间、Uber 节省的工时）是 T3，最戏剧性的事件是 T4。这不是轻视 T3 和 T4 案例的理由，而是提醒你：从它们身上学机制，即核验器、沙箱和边界，而不是学它们的数量级。

公开记录里缺了什么

这些缺口和案例本身一样重要，因为它们标出了你的计划在哪些地方跑在了公开证据前面。

• 没有按结果衡量的大公司 L3 或 L4 落地。没有任何组织公布过 L3 及以上智能体部署的变更失败率、事故率或逃逸缺陷。Stripe 和 Spotify 没有公布撤回率，谷歌只说撤回发生过。dotnet/runtime 的撤回对比（0.6% 对 0.8%）是唯一一组公开的智能体与非智能体对比（对照组中含机器人拉取请求），而它的作者自己也说样本太小，这一差异没有统计意义。
• 没有公开的编码智能体回退触发条件。没有哪家公司公布过回退 AI 编码工具或降低智能体自主度的标准。亚马逊针对 Kiro 加上同行评审，是一次回退，但不是一个事先声明的触发条件。最接近的先例来自别处。谷歌的 Tricorder 平台跟踪开发者对每项静态分析检查点击"没用"的情况，一旦某项检查的比例超过 10%，就停用它，直到作者改进为止（谷歌，CACM 2018，T2；早于 LLM）。谷歌的 SRE 指南描述了一类运维智能体：检测到风险分数升高时，会"自动把请求降级到 L2"（T3）。第 17 章《衡量成效，以及何时回退》会把这些发展成本书提出的触发条件，并明确标注为本书的提议。
• 没有包含人工评审在内的单次合并变更成本。dotnet 那篇文章没有计算计算资源和 CI 成本，本章也没有哪个案例报告了每个合并的智能体变更耗费多少评审工时。《经济性、风险与度量》会告诉你如何自己算出这个数字。

示例：重读一个标题数字。AI 辅助维护领域被引用最多的数字，来自亚马逊 CEO。用本章对每个案例提出的五个问题（列在章末的方框里）过一遍。

按顺序过一遍这些问题：

1. 谁测量的？有答案：亚马逊，测的是自己的产品。这决定了它的等级，但并不因此否定这个说法。
2. 以什么为基线？不合格。"通常 50 个开发者日"是对人工升级成本的估算，不是实测的对照。
3. 时间窗口和样本量多大？不合格。有"数以万计"的应用，有"不到六个月"升级了"超过 50%"的生产 Java 系统，但没有确切数量，开发者年数字也没有时间窗口。
4. "成功"计的是什么？作为结果指标不合格。"无需额外修改就上线"衡量的是评审者是否接受，而不是是否正确。和 Meta 的 73% 一样，它对后来发现的缺陷只字未提。
5. AI 实际握有什么权限？不合格。这些文章没有说明智能体能改动什么，也没有说明它的产出如何把关。

一个问题有答案，四个不合格。这并不意味着升级没有发生，也不意味着没有省下真实的工作量。编译器把关的维护任务，正是本章证据显示 L3 可以成立的地方。它意味着这个数字撑不起一个论点。"4,500 开发者年"是一个反事实估算，亚马逊没有披露其方法，它属于厂商自报方框，不属于商业论证。《经济性、风险与度量》会拆解其中的算术。这里要养成的是一个习惯：引用任何数字之前，先问这五个问题，包括你自己团队的数字。