同样用 Coding Agent，为什么有人 3 倍、有人 10 倍？

工具不是变量：Amazon Stores 50 团队试点中，90%+ 团队用同一套内部工具（含 Kiro），差距照样从不到 3 倍拉开到中位 4.5 倍、部分超过 10 倍。差距来自工作方式（5 个 daily habits），不是工具。

写文档不值钱，可执行校验才值钱：ETH Zurich 与 arXiv 2604.05278 两条独立对照实验分别证明，LLM 自动生成的 context file 让任务成功率下降，完整 SDD 流程相对直接 vibe 编码只多 0.05 分，真正带来统计显著收益的是后置 validation hooks（+0.15, p<0.05）。

4.5× 应当被谨慎引用：外部最好独立证据是 2.09×（单公司 DiD），GitClear 7 万开发者年中位只有 +9%，METR RCT 是 −19%。

—— 这是来自 AWS Senior Principal Engineer Clare Liguori 在 AI Engineer 大会的演讲《From AI-Assisted to AI-Native: Building a Frontier Development Team》，结合五路并行研究、交叉称量的整合。

---

——Amazon 前沿开发（Frontier Development）深度研究

一手来源：AWS Senior Principal Engineer Clare Liguori 演讲《From AI-Assisted to AI-Native: Building a Frontier Development Team》，AI Engineer 大会，时长 20:57。

研究方法：五路并行检索（一手还原 / Context 工程 / SDD / 测试与代码库改造 / 反方验证），交叉称量后整合。

成稿日期：2026-09-15

---

0. 先给结论：三句话

其一，工具不是变量。 Amazon Stores 试点里 90% 以上的团队用同一套内部工具（含 Kiro），差距照样从不到 3 倍拉开到中位 4.5 倍、部分超过 10 倍。

其二，差距的解释不是"用得更熟"，而是"流水线有没有被重排"。 小于 3 倍的那一半，把 AI 洒在了旧工作流上；4.5 倍的那一半，把需求表达、编码委派、本地校验、自动评审、决策放行这五件事一起改了。用 Amdahl 定律的话讲：编码只占交付周期的一段，只压缩这一段，总周期几乎不动。

其三，本次整合发现的最硬一条反转：写文档不值钱，可执行的校验才值钱。 两条彼此独立的对照实验分别证明——LLM 自动生成的 context file 让任务成功率下降（ETH Zurich），完整的 SDD 流程相对直接 vibe 编码只多 0.05 分（3.51 vs 3.46），而真正带来统计显著收益的是后置 validation hooks。形式化的意图只有被编译成机器能判定红绿的那一刻，才开始产生复利。

---

1. 事实地基：Liguori 到底说了什么

1.1 三个案例，三种口径

演讲给了三个层层递进的案例。理解它们的关键在于：这三个案例的"生产力"根本不是同一个东西。

三处必须打上星号：

• 20× 的口径是 commits。 Liguori 讲完 76 天后立刻自我设限："Now they looked at commits"，并预告后文会讲别的度量方式。而且措辞是"证明了达到 20 倍是可能的（get up to 20X）"，不是"实测 20 倍"。
• Prime Video 的 24 周不是已经交付，而是根据 10 天速度重算的估算。 该冲刺还带着三重"非真实生活"的限定：无 oncall、会议极少、一位资深工程师花了前 3 周预先切好粒度极细的任务清单。Liguori 自己说"这仍然不必然是真实生活"。
• 50 团队这项的观察期只有"the better part of last year"，没有精确月数， Slides 上标注为 2025 study。

口径警告：commits、修订估算、部署速度，三个数字不可互换。任何把它们串成一条"从 20× 到 10× 的演进曲线"的说法都是错的。

1.2 "前沿开发者"的三个定义

Liguori 给前沿开发者下了三条可观测的定义，比任何倍数都更有操作的价值：

1. 手写只占 1–2% 的产出代码，其余交给自主 agent。 2. 低频交互：目标是让 coding assistant 连续自转数小时，无需人工干预。 3. 最小化空闲：在任务 backlog 上并行跑多个 agent，而不是等单个生成结果。

对照她的"babysitting"刻画很能说明问题：盯着生成结果等待、阅读、纠偏，即便单次只要30 秒到一分钟，这些碎片也把你的注意力吃光了。她说得直白——如果你整天和 agent 来回对话，你当然看不到 4 到 5 倍的提升，因为你全程都在循环里。

1.3 五个 habits 与它们的真实含义

一处术语冲突值得一提：ai.engineer 的转录把她这段记为 BDD（行为驱动开发），bestblogs 与多数中文整理稿记为 spec-driven development。Kiro 官网用后者。两者未能从原话裁定，并列存疑。

1.4 她承认的代价与新瓶颈

这部分是演讲最有价值的地方，也是多数二手转述删掉的部分：

• code review 变难，尤其对初级工程师：资深工程师花了多年练出审别人代码的本事，初级工程师还没有这块肌肉。审查 AI 的输出对他们比自己写更费劲。
• 认知负荷随并行 agent 数上升：在终端标签页之间来回切换。
• FOMAT（Fear Of Missing Agent Time）：为了让 agent 通宵干活产出第二天早上的成果，人会熬到深夜把 prompt 打磨好。
• 决策成为新瓶颈：产品实现从 9–12 个月压到 1–2 个月后，"要不要建"的决策要 2 个月、发布审批再要 2 个月，反倒成了主要延迟。她的处方是：对容易逆转的决策，加速放行。
• 管理层期望错配，包括她自己。她的原话大意是："作为领导者，我自己也犯了这个罪——模型这么强，AI 工具都配上了，你们为什么还没变快？"她给的答案是：因为要先花两个月投资代码库、摸索团队的最佳实践、做出艰难的习惯改变。她还提到每天看着社交媒体上别家公司吹嘘"一天提 20 个 PR"，这正是错误期望的来源。
• 50 → 2000 团队是 2026 年的目标，不是已实现的结果。 这一条 ai.engineer 明确标注，别当成成绩引用。

来源性质提醒：全部数字是 Amazon 内部观察 + 演讲者口述，无对照组、无置信区间。多数二次整理稿之间细节互相打架。它们是从业者观察，不是证据。下文第 7 节会拿外部天平来称。

---

2. 把"工作方式"翻译成三个可操作的变量

Liguori 说差距来自"how teams worked"，这句话太空。我们把它拆成三个变量：

Agent 的自主能力 ≈ 上下文（它知道什么） × 意图（它要什么） × 反馈（它能否自己发现自己错了）

三者中有一个接近零，乘积就塌了。而这三个变量，恰好各自都有独立文献可以对账。

---

3. 变量一：Agent Context ——写了没用，写对才有用

3.1 最重要的一条反转

如果只看官方文档，你会以为写一份详尽的 rules 文件是标准动作。但对照实验给的结果要冷得多。

ETH Zurich（arXiv:2602.11988，CTXbench，138 实例 / 12 个冷门 Python 仓库 + SWE-bench Lite 300 任务）：

三个要点：

1. LLM 自动生成的 context file 让成功率下降，成本还涨 19–23%。 论文的结论原话是"暂时不要自动生成这类文件"。 2. 出错时 LLM 生成的文件反而 +2.7% 并超过人类手写——说明它主要是在和已有 README 重复。它的价值只在于文档稀缺的仓库。 3. 开发者手写确有 +2.4pp，但边界很窄：chi-squared 后、相对 LLM 生成 +7%（p=0.038）。

另一边，效率侧的证据一致得多：

• Lulla et al.（arXiv:2601.20404，ICSE 2026 JAWs）：10 仓库 / 124 个已合并 PR，配对实验。中位耗时 98.57s → 70.34s（−28.64%），输出 token −16.58%，任务完成行为相当。
• Augment Code（厂商研究，有方法学）：最好的 AGENTS.md 带来的质量提升"≈ 从 Haiku 升到 Opus"，最差的不如不写。主文件 100–150 行 + 少量聚焦参考文档时全指标 +10–15%；超过 150 行收益开始反转。一份 6 步编号的部署流程把"漏 wiring 文件"的 PR 从 40% 压到 10%。连续 15 条以上纯禁令（不给替代方案）显著恶化。
• Khatri（arXiv:2607.27250，单作者预印本）：288 次 gold-test 运行，等效性检验把正确性效应上界框定在 ≤10pp（Claude）/ ≤15pp（Codex）。失败分诊显示 agent 输在实现能力，不是缺仓库知识。

四份研究其实不矛盾，它们的分歧点就是答案：context file 的收益主要落在效率（快 28.6%、省 token）与非标准约定上，对正确性的效应很小且不稳定。所以"3× 差距"不是靠写更长的 rules 拿到的，而是靠少写、写对、按路径加载拿到的。

3.2 长度与层级的官方红线

两个反直觉的工程细节：

• Claude Code 官方明确说 @import 不省上下文——被导入的文件在启动时就展开进 context window。
• AGENTS.md 是 agent 100% 会读的唯一文档位置，_docs/ 下未被引用文档的发现率 <10%（Augment）。文档放在哪，比写了什么更决定它能不能成为上下文。

3.3 为什么要"修剪"

Liguori 的 prune 主张在别的场合有更锋利的表述。她在 LinearB / Dev Interrupted 播客里讲：

"我们会搭一堆脚手架，然后 Sonnet 3.5 出来，我们因为上面那层脚手架，正在把模型变得更糟。" Sonnet 3.7 又重复了同一模式。

换个讲法，这叫模型驱动 vs 脚手架驱动。她的六个月内假设是——"假设半年后你改一行配置就能换上新模型"。这个假设只在没人把模型框住的前提下才成立。

证据性质：这是权威从业者证言，不是公开 A/B 数据。我未找到任何对比 heavy-scaffolding 框架与 model-driven 框架的同行评审对照。请当作观点引用。

3.4 上下文腐坏与工具数量的硬边界

Chroma《Context Rot》（2025-07-14，18 个模型）：

• 固定任务复杂度、只改输入长度，所有模型、所有实验都退化。
• 最反直觉的一条：shuffled haystack 优于 logically structured haystack，在全部 18 个模型上成立。结构连贯性反而有害。
• LongMemEval：focused ≈300 tokens vs full ≈113K tokens（377×），focused 显著更准，开启 thinking 后差距仍在。
• ⚠️ Chroma 卖检索基础设施，"retrieval beats stuffing" 对它商业有利，但代码开源。

Anthropic 官方的 context engineering 框架：

• attention budget：n 个 token 对应 n² 个成对关系，每个新 token 都在消耗预算。
• sub-agent 用几十万 token 探索，只回传 1,000–2,000 token 的蒸馏摘要。
• Just-in-time context：维护路径与链接这类轻量标识符，运行时按需 glob/grep 加载。官方直言 CLAUDE.md "是被naively 一次性塞进上下文的"。

工具数量的衰减曲线（RAG-MCP，arXiv:2505.03275）：候选 MCP 从 1 增到 11,100。N<30 成功率 >90%；31–70 开始出现失败簇；超过约 100 后失败占主导。 相应地，把"全 schema 塞 prompt"换成"检索 top-1 schema"，工具选择准确率 13.62% → 43.13%（3.17×），prompt token −49%。

这条恰恰给出了本报告中唯一一个干净地等于"3 倍"的数字——同一模型、同一任务，只改上下文组织方式。

---

4. 变量二：Spec-Driven Development —— markdown 不值钱

4.1 Kiro 的三件套与 spec-kit 的流水线

Kiro 的 spec mode 会在 .kiro/specs// 下生成三件套：

• requirements.md：用户故事 + EARS 验收标准（WHEN… THE SYSTEM SHALL… 句式）
• design.md：架构、时序图、数据流、错误与测试策略
• tasks.md：可追踪的实现任务，回指 requirement 编号

GitHub Spec Kit 的流水线几乎同构：constitution → specify → clarify → plan → analyze → tasks → implement → converge（拿代码去对账 spec，循环到报告 Converged）。

但这两者的实践被 Birgitta Böckeler（Thoughtworks Distinguished Engineer，martinfowler.com 2025-10-15）做了冷静测评，她给出了本报告最值得记住的一句吐槽：

"老实说，我宁愿 review 代码，也不愿 review 这一堆 markdown 文件。"

—— 她用 spec-kit 做一个原估 3–5 点的 story，产出大量重复 markdown 且与既有代码重合，中途放弃。

4.2 唯一有对照设计的实验，结论不太客气

arXiv:2604.05278《Spec Kit Agents》，四种配置 × 128 次运行 × 32 个 feature × 5 个仓库（FastAPI/Airflow/Dexter/Plausible/Strapi），1–5 分 LLM-as-judge 复合分：

读法很明确：SDD 的仪式本身（写三份 markdown 然后 review）只带来 +0.05，几乎等于噪声。真正统计显著的 +0.15 来自 hooks。 消融进一步显示：后置 validation hooks 的贡献大于前置 discovery hooks。

同一个方向的旁证：

• arXiv:2605.30314 SpecBench：用 Kubernetes/React/Rust/TVM/vLLM 的真实 RFC 评审记录做基准，要求 agent 找出初始提案里的遗漏、歧义、不一致。最强 agent GPT-5.4 只有 44.4% 准确率。"AI 帮你写 spec、人只负责点头"这一环，目前远未达标。

⚠️ 两篇都是预印本，未同行评审，n 小，且评判者是另一个 LLM。结论方向可信，绝对值不可引用。

4.3 Thoughtworks 与 Fowler 阵营的判断

• 三分法：spec-first（先写 spec 驱动本次任务）/ spec-anchored（spec 保留下来用于演进维护）/ spec-as-source（长期只有 spec 是人编辑的源文件）。她的判定是：所有工具都做到 spec-first，但很少说清长期维护策略。依此她判定 spec-kit 仍属 spec-first（因为它给每个 spec 开一个 git 分支，生命周期等于一次变更请求）。
• 与 MDD 的历史类比："MDD 从未在业务应用领域起飞，它处在一个尴尬的抽象层级上，制造太多开销与约束。"而 LLM 的代价是非确定性——我们丢掉了可解析结构本来的好处。"我怀疑 spec-as-source、甚至 spec-anchoring，最后会同时继承 MDD 与 LLM 两者的缺点：既僵化又非确定。"
• Technology Radar Vol.33（Nov 2025）把 SDD 放在最外圈 Assess，原话：即便在新兴实践中，也注意到"退回传统软件工程反模式"的风险，"最显著的是偏向重型 up-front specification 与 big-bang release"，以及——"我们可能在重新学一个苦涩的教训（bitter lesson）——为 AI 手工打造详细规则，终究无法扩展。"（该 blip 已不在最新一期。）
• Kent Beck 的批评最锋利："我所见到的 spec-driven development 的描述都强调在实现之前写完整个规格。这编码了一个（对我而言很奇怪的）假设：你在实现过程中不会学到任何会改变规格的东西。"

4.4 那什么才有效？把意图编译成可执行检验

Hacker News 那场 316 票的讨论里最有建设性的一条补丁是：

"先把基本 spec 写成 test suite，一旦 spec 被落实为测试，LLM 就无法再幻觉。我把这叫 grounding。"

这与 Kiro 后来的产品方向一致——它的 property-based testing 把验收标准转成 Hypothesis 属性测试，每个属性带 Validates: Requirements 2.3 做双向追溯，默认跑 100 个生成用例并 shrinking 出最小反例。必须诚实指出：Kiro 自己没有任何 bug 检出率的量化数据，也没声称能自动检测规格矛盾。

一句话回收：意图工程的产物不是文档，是判据。 好 spec 是可测试的，坏 spec 是可解释的。

---

5. 变量三：反馈回路 —— 真正的乘数

这是三个变量里唯一有大量正规文献支持的一个。

5.1 循环数是乘数，但边际递减

核心恒等式：单 agent 有效循环数 ≈ 总时长 /（推理时间 + 单次校验耗时）。延迟越低、越确定，同一段挂机时间内的纠错次数越多。

• SWE-Dev（arXiv:2506.07636，SWE-bench Verified，32B 模型）：30 回合 → 34.0%；75 回合 → 36.6%。30→45 的增益明显大于 45→75，作者称之为 diminishing returns。
• CRUST-Bench（C → safe Rust，100 个真实仓库）：给了编译器反馈后 o1 从 15% 涨到 28%；加测试失败反馈继续提升（更新版 12 模型：单次 19% → 三轮 test-repair 后 48%）。作者另一半结论同样重要：流水式 SWE-agent 只有 32%，与"朴素 LLM + 测试修复"持平——瓶颈在深度语义推理，不在工具与循环数。
• R2E-Gym（UC Berkeley）：只用基于执行的验证或只用无执行的 verifier，各自在 42–43% 就饱和，混合策略才到 51%。原因是纯测试验证器"区分度低"。只靠"快测试 + 多循环"有天花板。

别过度引用：我没找到任何公开发表的研究直接量化"测试墙钟时间 → 任务成功率"。被实证支撑的是回合数（+2.6pp，边际递减）与反馈有无（15%→28%），不是"延迟减半等于产出翻倍"。

5.2 为什么强调"确定性"

Liguori 的确定性 testing 指的是用返回确定性响应的 mock 替掉真实远程服务，让 agent 在笔记本上就能跑。

社区侧最清晰的机制分析（dev.to / recca0120）给了两条因果而非偏好的理由：

1. flaky 对 agent 是灾难——随机的红灯导致 thrash，随机的绿灯导致"假修复"。 2. 若断言绑实现（toHaveBeenCalledWith），agent 会一边改产品代码一边改测试，测试就此失去守卫作用。应断言行为。

落到工具形态，Anthropic 官方主张 check = "anything that returns a signal Claude can read"——测试套件、build exit code、linter、diff fixture 的脚本、浏览器截图；并且确定性靠 hooks 而非 CLAUDE.md（"Unlike CLAUDE.md instructions which are advisory, hooks are deterministic"），Stop hook 可以作为门禁一直阻塞到通过为止。

反面案例也现成：有开发者报告 agent 拿着真实的 Stripe / Twilio key 去"测试"集成，真的把短信发了出去。没有本地沙箱的直接损失。

5.3 错误信息是给 agent 的接口

这条初听奇怪，实则证据不少：

• INTERVENOR（arXiv:2311.09868，HumanEval/MBPP/HumanEval-X）：把编译器诊断与失败测试报告串成修复链，修复数量相对基线翻倍，且在 AssertionError（反馈最精确的一类）上增益最大。作者原话："the quality of code execution feedback is critical in repairing codes."
• Anthropic《Writing effective tools for agents》：*"you can prompt-engineer your error responses to clearly communicate specific and actionable improvements, rather than opaque error codes or tracebacks"*；并称仅仅精修工具描述就让 Sonnet 3.5 在 SWE-bench Verified 上达到当时 SOTA。concise 响应 72 tokens vs detailed 206 tokens。

但对"迁到 TypeScript / Rust 会让 agent 更强"这一条，必须泼冷水。 两个多语言基准给出的结论互相打脸：

两个基准对 Rust 的排序相反，对 JS/TS 一致偏低。 结论只能是：语言差异主要反映生态、测试设施与任务分布，没有任何公开证据显示"迁移到静态类型语言能提升 agent 的仓库级成功率"。反过来，ICSE 2026 的 Rust-SWE-bench 显示 borrowing / ownership 是 agent 的头号失败源——Rust 的严格恰恰是最大的卡点。

5.4 迁移的 ROI：Bun 这个极端案例

Bun 用 11 天把 535,496 行 Zig 迁到 Rust，峰值 64 个 Claude 实例，API 费用约 $165k，变成逾百万行 Rust。收益：2000 次并行构建内存 6.7GB→609MB、二进制约 −20%、吞吐 +2–5%。代价：新增 19 个已知问题、约 4% 仍是 unsafe Rust、目前仅实验性限 Linux x64，稳定版仍从 Zig 发布；Zig 作者 Andrew Kelley 公开称其为 "unreviewed slop"。

真正可迁移的工艺是这四条：① 测试套件与语言无关（全用 TypeScript 写，所以迁移后同一套规格继续有效——这是"不漂移的规格"的工程版）；② 先花 3 小时手工定下映射约定；③ 每个改动配 1 个实现 agent + 2 个对抗式评审 agent；④ 禁止 git stash/git reset 这类会破坏并行的命令。

⚠️ Bun 官方原文未能打开，以上均为二级转述且各源数字互相矛盾，引用前务必回核。

5.5 AI 生成测试的三个陷阱

• MutGen（arXiv:2506.02954）：观察到"某些测试套件 100% 覆盖率，但 mutation score 仅 4%"。
• ULT（arXiv:2508.00408，3,909 个真实 Python 函数）：12 个 SOTA LLM 平均准确率 41.32%、mutation score 40.21%，远低于受污染的旧基准。
• 反直觉（Konstantinou et al., arXiv:2601.09695）：换新模型重跑后，朴素 zero-shot 提示反超四个带编译/执行反馈的 2024 年工具，mutation score +20.92%。含义——很多"给 agent 加反馈框架"的优势会被更强的基础模型吃掉。

还有那条经典作伪：agent 对着失败的测试改测试，直到变绿。

---

6. 整合拍板：为什么 4.5 倍是可能的、10 倍是可疑的

现在把三份独立证据放在一起，会看到一个漂亮的收敛：

三条指向同一件事：杠杆在"让机器能自己判定对错"，不在"让人写更多说明"。 这与 Liguori 的五个 habit 完全同构——习惯 1 与 4 是在给机器喂判据，习惯 2 与 5 是在缩短判定回路，习惯 3 是让判定循环在无人值守下跑满。

至于 4.5× 与 10×： 内部自述 + 部署速度口径 + 无对照组，且与外部最好 evidence 差一个数量级。合理的读法是——"在 Kiro 重度试点中，按投产部署速度度量，少数团队达到了这个量级"，不是一条普遍规律。见下节。

---

7. 反方称量：把 4.5× 放到外部天平上

7.1 METR RCT：最强的反方证据，但常被用错

原始研究（2025-07-10）：16 名资深开源开发者、246 个真实 issue、来自平均 22k+ stars / 1M+ 行代码的他们自己维护多年的仓库。随机分配到可用/禁用 AI。结果：允许用 AI 反而慢 19%（CI +2% 到 +39%）。而事前预期是提速 24%，事后仍认为提速了 20%。

感知与现实的鸿沟是 39 个百分点。 这条比 −19% 本身更稳健、更重要——它直接摧毁了"问工程师自己"这一整类证据，包括所有自报的生产力提升。

2026-02-24 更新：第二轮 10 名回流 + 47 名新招募，800+ 任务。回流组 −18%（CI −38% ~ +9%）、新招募组 −4%（CI −15% ~ +9%），两个区间都跨 0。METR 承认存在选择效应——30–50% 的开发者故意不提交任务以免被分到无 AI 组，且多 agent 并行使工时自报失准。官方结论：新数据"gives an unreliable signal"，估计值很可能是真实效应的下界。

对 Liguori 的判定：不构成反驳，但构成边界。 METR 的 setting 是"资深维护者 + 自己熟悉的大仓库 + 2025 年初的工具"，这恰恰是 AI 边际收益最小的场景。但它锚定了一件事：不存在普遍适用的 4.5×。

7.2 DORA 2025：AI 是放大器，但效应小得意外

近 5,000 名从业者，调查窗口 2025-06-13 至 07-21。90% 使用 AI（同比 +14pp），65% 高度依赖，>80% 认为 AI 提升了自己的生产力——而这一条正在 METR 证明不可靠的那一类证据里。

核心结论原文：

"AI's primary role in software development is that of an amplifier. It magnifies the strengths of high-performing organizations and the dysfunctions of struggling ones."

标准化效应量排序：个人效能 0.17 > 交付不稳定性 0.10 > 组织绩效 0.09 > 有价值工作 0.08 > 代码质量 0.07 > 产品绩效 0.05 > 交付吞吐 0.03 > 团队绩效 0.03 > 倦怠 0.01 > friction −0.02。

三个和本文直接相关的读数：

• 吞吐效应 0.03。和 4.5× 不在同一个宇宙。
• 倦怠效应 0.01 ≈ 0。这一条削弱 Liguori 的 FOMAT 主张：AI 采用本身几乎不制造倦怠，DORA 明确说倦怠与 friction "属于组织系统的属性，而不是工位上那个人的属性"。
• flow efficiency 约 21%（约 24.5 小时有效工作 vs 92.5 小时等待）——这是支持"决策与等待成为新瓶颈"的官方数字。

7.3 交付端稀释：commit 暴涨不等于功能暴涨

这是所有数据里最扎心的一组：

外部最好的、来自真实组织的独立证据是 2.09×（单公司、无法随机分配因果，但用了 staggered DiD）。这是目前能对 4.5× 给出的最体面的外部上限。

7.4 瓶颈真的转移了，四源收敛

Faros AI 2025（10,000+ 开发者 / 1,255 团队）：高 AI 采用团队完成任务 +21%、合并 PR +98%，但 PR review 时间 +91%、平均 PR 体积 +154%、每开发者 bug +9%。公司层面："AI 采用与任何关键绩效指标的相关性蒸发。"

Faros AI 2026（22,000 开发者 / 4,000+ 团队 / 两年遥测，比较同一组织低采用期与高采用期）：

Faros 的因果解释值得单独引用：AI 生成的代码"表面上令人信服——惯用、命名得体、风格与周边代码库一致"，结构性错误藏在表面之下，评审者必须仔细读、推理意图、重建问题，这是缓慢而昂贵的认知工作，且落在资深工程师头上（senior engineer tax）。评审队列"变成了代码被完成的地方"。

LinearB 2026 基准（8.1M PR / 4,800 团队 / 163,820 贡献者）：

最大的 diff 拿到最少的评审时间，而 AI / agentic PR 的三成多最终没能合进去。另有 44.7% 的组织根本不正式度量 AI 影响，而 76.1% 的领导者凭"采用信号"而非交付数据上报收益。

代码质量侧（GitClear，2.11 亿行变更 2020-2024；6.23 亿次变更 2023-2026）：churn 从 2020-22 的 3.31% 升到 2025 的 6.87%；"moved"（复用/重构）占比从 2021 年 24% 跌到 2024 年 9.5%，2024 年复制粘贴的行数首次超过 moved 的行数；重复代码块约为 2020 年的 4 倍；重构 −70%、长期维护 −74%。

GitClear 自己也给了一句打脸式注解："4× 的生产力差距反映的是谁在用 AI（选择效应），而不是 AI 造出了谁。"

7.5 Stack Overflow 2025：信任在下滑

49,000+ 份问卷。84% 使用或计划使用 AI；但 66% 最大的挫败是"AI 给出的方案几乎对、但差一点"；33% 信任 vs 46% 不信任，仅 3.1% 高度信任，且经验越丰富越不信。 Agent 使用者中约 70% 同意减少了具体任务耗时、69% 同意提升了个人生产力，但只有 17% 同意改善了团队协作——所有影响项里最低。

---

8. 人的代价：初级工程师怎么办

Liguori 只提了问题（junior 没有评审肌肉记忆），没给答案。业界给出的答案分两半。

最有分量的实证是 Anthropic 自己做的 RCT（Shen & Tamkin，arXiv:2601.20245，n=52，OSF 预注册）：

• 参与者均有 Python 经验但都没用过 Trio 异步库，随机分 AI 组 / 手写组，做题约 35 分钟后测验。
• AI 组平均 50%，手写组 67%——差 17 个百分点，接近两个字母等级。 差距最大的是 debugging 题。AI 组只快约 2 分钟，且不显著。
• 六种交互模式：低分组（<40%）= 完全委托 AI、渐进式依赖、让 AI 迭代调试；高分组（65%+）= 生成后追问解释、要求代码与解释一并给出、只问概念性问题而自己写代码。

作者结论："AI-enhanced productivity is not a shortcut to competence." 生产力收益可能以"监督 AI 生成代码所需的调试与验证能力"为代价。

限制（必须标注）：n=52（每组 26），六种模式的定性分箱样本极小，只测即时理解不测长期技能，界面是浏览器 chat 而非 agentic 工具，且参与者知道有测验。Anthropic 亦提示其此前观察性研究发现 AI 可把某些任务提速 80%——两者并存，恰恰是"AI 可能既在已掌握技能上提速，又在新技能习得上抑制"。

神经层面的证据争议极大，引用需极度谨慎。 MIT Media Lab 的《Your Brain on ChatGPT》（arXiv:2506.08872）用 EEG 测 n=54，发现 LLM 组神经连接最弱、83% 无法准确引用自己刚写的文章。但它是预印本、未同行评审、第四轮交叉只有 18 人且为自愿参加、作者本人多次否认"LLM 让人变傻"、且广为流传的"55% 连接度下降"实为评论文章的二手数字。本报告不建议将其作为结论依据，只作为待验证线索。

业界开的处方是这样的：Microsoft Azure CTO Mark Russinovich 与 VP Hanselman 在 *Communications of the ACM*（2026-02）提出 "AI Boost"（资深工程师被 AI 放大）vs "AI Drag"（早期职业开发者被 AI 拖累），解法是 preceptorship：把早期职业开发者与资深导师按 3:1 到 5:1 配对，并把"学习"而非"吞吐"设为工程工作的显性目标。

劳动力市场侧的三份数据（均为二手转述，需再核）：SignalFire 称 12 家科技巨头应届/入门招聘较 2019 年 −65%；Stanford Digital Economy Lab 称高度 AI 暴露职业中 22–25 岁就业比反事实低约 19% 且资深员工无此缺口；IZA 讨论稿称 ChatGPT 发布后初级 vs 高级软件岗位相对下降 14–15%，且该效应仅限软件岗、机制是在同样的 junior 头衔里抬高经验门槛。

---

9. 别用错尺子：度量陷阱与替代框架

陷阱：commits / PR 数 / diffs 最容易采集，也最容易被 AI 机械性推高。Demirer 的 commit +180% → release +30% 是"活动量指标骗人"的最佳单一例证。而 LinearB 显示近半数组织压根不正式度量，四分之三的领导者凭采用信号上报收益。

替代框架：

一个可信的 ROI 参照：Booking.com 用 DX Core 4 度量 3,500 名工程师，日均活跃 AI 用户 PR 合并率高 16%，第一年省 15 万开发者小时。这才是"可辩护的 AI ROI"应有的量级——与 4.5× 相差一个数量级。

---

10. 给工程负责人的落地清单

综合五路证据，按"证据强度 × 投入产出比"排序：

第一梯队：几乎必做，证据充分

1. 把code review 当成显式瓶颈来管理。 四源独立收敛证明它会炸：Faros 2026 中位 PR review 时长 +441.5%、LinearB agentic PR 首评等待 17.6h、AI PR 30 天合并率仅 32.7%。对策：限 PR 体积、引入 AI 预审（LinearB 称最多提升 5–7 个百分点 yield）、给资深工程师的评审负荷设上限。 2. 建立本地、确定性、快速的校验回路，并写进 hooks 而非 CLAUDE.md（后者只是建议，前者是确定的）。这是唯一在对照实验中拿到统计显著收益的动作。 3. 给公开 spec 模板，但落在判据上——EARS 验收标准、正例反例、明确的 Non-Goals。别追求 markdown 的完备度。 4. context 文件：手写、短（<200 行）、按路径加载、随模型升级定期修剪。 不要用 /init 自动生成（有实验显示会让成功率下降）。

第二梯队：值得做，但要量成本

5. 改错误，让它给修复建议而非 traceback。 Anthropic 称精修工具描述就能带来显著改善。 6. 先把 mentor 机制建起来（3:1 到 5:1），再谈 AI 铺开。Anthropic RCT 显示 AI 组新手对新库的掌握比手写组差 17 个百分点。 7. 换度量口径：把 diffs/commits 降为辅助指标，加 rework rate、PR 体积分布、commit→prod lead time、mutation score。

第三梯队：谨慎，证据不足

8. 不要因为"对 AI 更友好"而迁移语言。 两个多语言基准在 Rust 上互相矛盾、在 JS/TS 上一致偏低，没有任何证据支持迁移提升 agent 成功率。 9. 不要指望 SDD 流程本身带来倍数。 对照实验显示纯 SDD 流程 vs 直接 vibe 编码只有 +0.05。 10. 留两个月。 Liguori 的经验数据是"投资代码库 + 摸索实践 + 改习惯"需要约两个月，且先经历生产力下降。给团队这段时间，别急着把工具兑换成更高的交付承诺。

---

11. 未解之谜与证据缺口（诚实清单）

1. Amazon 的原始数据从不可复现。 无方法学、无置信区间、无对照组；二级转述之间数字互相打架。50 → 2000 团队是目标不是结果。 2. SDD 只有一篇预印本做过对照，且评判者是 LLM（Claude Opus 4.6）。 3. "测试反馈延迟 → 成功率"缺乏直接度量。 被支持的是回合数与反馈有无，不是延迟比例。 4. "迁移到 Rust/TypeScript"被两个基准反驳，但它仍被反复当作最佳实践传播——建议直接忽略。 5. deskilling（技能退化）的神经证据（MIT n=54）质量过低，不足以作为判断依据。 6. parallel agent 的规模警告不属于本演讲。 Liguori 在另一处（LinearB 播客）提到 Conway's Law 与"500 个 agent 太多"，引用时应改标来源，别混进 50 团队试点的数据里。 7. 多个广为流传的数字查无出处：例如"AWS Kiro 官方案例：40 小时的功能用 spec-first 后只要不到 8 小时人工时间"——我只在 SEO 型博客上见过，找不到任何官方原文。另已识别多个内容农场（openllm.wavise 等）编造 METR 样本量（把 16 人说成 48 人）与 PR 拒绝率。凡百度百科类、无一手链接的数字，一律不采信。

---

附录 A：证据分级速查

附录 B：本报告的核心八条

1. 三种口径不可互换：Bedrock = commits，Prime Video = 修订估算，Amazon Stores = 部署速度。 2. 90% 同工具，差距仍从 <3× 到中位 4.5× → 变量是工作方式，不是工具。 3. 写 context 的正确打开方式：手写、<200 行、按路径加载、随模型升级修剪。别用 LLM 自动生成。 4. SDD 的仪式本身几乎没用（+0.05）；后置 validation hooks 有用（+0.15, p<0.05）。把意图编译成可执行检验。 5. 循环数是乘数但边际递减（30→75 回合只 +2.6pp）；纯测试验证在 42–43% 饱和。 6. 外部最好的独立证据是 2.09×（单公司 DiD），GitClear 7 万开发者年只有 +9%，METR RCT 是 −19%。4.5× 是 Amazon 内部观察，不是普遍规律。 7. 瓶颈确实转移了：review 时长 +441.5%、AI PR 30 天合并率 32.7%、每 PR 生产事故 +242.7%。 8. 新人是真问题：Anthropic RCT 显示 AI 组 50% vs 手写组 67%，debugging 差距最大，且并不更快。

---

参考来源（主要）

一手演讲与访谈

• From AI-Assisted to AI-Native — Clare Liguori, AWS（演讲逐字转录，12 段拆解）
• 同演讲要点整理（BestBlogs）
• Simplicity in model-driven agents and MCP — LinearB 访谈
• RedMonk：Clare Liguori on Kiro & AI Spec-Driven Software Development
• 从 AI 辅助到 AI 原生（中文逐段还原）

Context 工程

• Chroma：Context Rot
• Anthropic：Effective context engineering for AI agents
• arXiv 2602.11988：Evaluating AGENTS.md（ETH Zurich）
• arXiv 2601.20404：On the Impact of AGENTS.md Files（ICSE 2026 JAWs）
• arXiv 2505.03275：RAG-MCP
• Claude Code 官方：How Claude remembers your project

SDD

• Birgitta Böckeler：Understanding SDD — Kiro, spec-kit, and Tessl（martinfowler.com）
• Thoughtworks Technology Radar：Spec-driven development
• GitHub Spec Kit
• arXiv 2604.05278：Spec Kit Agents（唯一 SDD 对照实验）
• Hacker News：SDD — The Waterfall Strikes Back
• Kiro：Does your code match your spec?（PBT）

测试与代码库

• arXiv 2506.07636：SWE-Dev 回合数缩放
• CRUST-Bench：编译反馈使 o1 15%→28%
• arXiv 2311.09868：INTERVENOR（反馈质量使修复量翻倍）
• Anthropic：Writing effective tools for agents
• SWE-bench Multilingual 官方数据
• arXiv 2508.00408：ULT 真实世界单测基准
• arXiv 2601.09695：朴素提示反超反馈框架

反方与规模数据**

• METR：Measuring the Impact of Early-2025 AI（RCT）
• METR 2026-02-24 更新与选择效应承认
• DORA 2025 State of AI-assisted Software Development（官方 PDF）
• Stack Overflow 2025 Developer Survey — AI 章节
• arXiv 2607.01904：AI Writes Faster Than Humans Can Review
• Faros AI：The AI Productivity Paradox 2025
• Faros AI：The Acceleration Whiplash 2026
• LinearB：2026 Software Engineering Benchmarks
• GitClear：AI Copilot Code Quality v2025.2.5（PDF）
• Anthropic：How AI assistance impacts the formation of coding skills

---

#AI编程 #前沿开发 #SoftwareEngineering #智柴赛博前线