90 天试点

试点要做的决定

"我们该不该采用 AI？"不是试点能回答的问题。试点能回答的是一个更窄的问题：这个阶段里的这种任务类型，该不该上升一级？这正是成熟度模型的计分单位，也是一次 90 天试点能测量的单位。本章其余内容，都源于把问题收得这么小。如果你是在为客户做试点，而不是在自己团队内部，《最后一公里》讲的是另一面：决定试点能否转化的条款，以及怎样划定首个成果的范围。

已发表的推广记录，大多回答的是另一个问题：大家用没用这个工具？埃森哲与 GitHub 合作的推广是记录最完整的例子。81.4% 的开发者在拿到许可证的当天就装好了插件，其中 96% 当天就开始接受建议，67% 的调查受访者说自己每周至少用五天（GitHub 与埃森哲，2024 年 5 月，T3）。ZoomInfo 分四个阶段向 400 多名开发者推广，报告的平均接受率是建议的 33%、代码行的 20%，满意度 72%（ZoomInfo，2025 年 1 月，T2）。这些数字都说明不了交付是否更快、故障是否更少。ZoomInfo 的论文甚至没有给出任何节省时间的数字。

连使用都不是理所当然的。在 Cui 等人分析的三项现场实验中，共 4,867 名开发者，"大约 30% 到 40% 的工程师"连一个免费、内置于 IDE 的助手都没试过（Cui 等人，2025 年 2 月草稿，T1，混合独立性；效应大小的解读见《经济性、风险与度量》）。所以采用情况值得跟踪，但它是前提条件，不是结果。用数量来评判的试点，可能看上去很成功，实际却什么也没交付；瓶颈一章里那个看似成功的试点，拉取请求增加了 13.6%，有效产出只增加了 1%。

站不住的说法很容易认出来。GitHub 关于美客多（Mercado Libre）的客户故事，页眉写"9,000+"名开发者，正文写"超过 10,000"名，元数据写 13,300 个席位；而页眉中"约 50%"的编码时间缩减没有注明出处；正文对它的支撑，只有一位高管"只花一半时间"的个人说法，以及他提到的"我们一直在和团队做的试验"，没有给出任何设计或结果（GitHub 客户故事，页面未注日期，截至 2026 年 10 月，T4）。一份连自己的分母都说不清的试点报告，不该用来决定预算。

选任务：从维护起步

试点的任务类型应当从你的评估中选出，而不是从厂商演示中选出。《评估你的起点》提供输入：每个阶段按任务类型打分，并标明各自的核验器、凭证和风险上限。从这张清单里挑，一个好的首次试点要通过四项检验：

• 核验器已经存在，而且智能体改不了它。构建、类型检查、lint 和测试在任何人查看之前就判定通过与否。这就是判据原则；没有它，试点测的是评审者，而不是智能体。
• 一次回退就能撤销。智能体产出的任何东西都不直接触及生产状态。该任务的风险上限必须高于你要测试的级别。
• 它会反复出现。90 天里有足够多的条目可供计数。一次性项目只能给你一则轶事。
• 有人对它负责。一个具名团队评审产出，并要承担结果。

维护比任何其他阶段都更常同时通过这四项，这就是本书推荐把它作为第一级台阶的原因。《维护与迁移》说明了缘由：编译器和现有测试在智能体到来之前就写好了，它们检查的正是迁移必须保持的行为，而且不在乎差异是谁写的。在那里挑一个反复出现的变更类别，例如框架迁移、废弃 API 或失败的依赖升级，并把数据库模式迁移和数据迁移排除在外。回退撤销不了一个已被删除的列。

如果维护阶段没有合适的候选，编码阶段有一些，但要按任务类型选，而不是按规模选。在 dotnet/runtime，智能体提交的清理类拉取请求合并率为 84.7%，测试类为 75.6%，而性能类只有 54.5%（微软 .NET 团队，2026 年 3 月，T2；完整案例见《案例研究：谁做到了，测量了什么》）。清理和测试工作可以作为试点候选，性能工作不行。

要清楚被测的是哪个级别。首次试点测的是 L2：智能体产出完整的变更，每一项都经过有记录的人工评审。90 天试点无法认证 L3，因为 L3 的定义要求在暂停与回退都演练过之后，做至少 90 天的逃逸缺陷对比。一次运行良好的 L2 试点所做的，是收集这项对比的头 90 天数据。它为这种任务类型挣得了尝试 L3 的资格，但并不授予 L3。

先准备环境，再评判模型

浪费一次试点最常见的方式，是把智能体扔进一个它根本构建不了的代码库，然后给智能体打分。在 dotnet/runtime，编码智能体起初连它自己的构建所需的包源都访问不了。团队为这些包源打开了防火墙，写了一份指令文件，又加了防止构建超时的初始化步骤。这些改动之前创建的拉取请求，成功率是 38.1%；之后创建的是 69%。第一个月的成功率是 41.7%，最近一个季度约为 71%。提升"不是靠更好的 AI 模型，而是靠更好的准备"（微软 .NET 团队，T2）。

一个在第一个月后就结束的试点，会记下 41.7% 然后叫停。所以本书的提议是：把最初几周当作磨合期，不计入结论。让智能体在它真正要运行的地方运行，观察它在哪里失败，然后修好环境。亲手写一份简短的指令文件。《编码》列出了准备步骤，以及关于指令文件的好坏参半的证据。当剩下的失败都与工作本身有关、而不再与环境配置有关时，冻结配置，开始计数。

准备工作也包括权限。在智能体第一次运行之前，写下它能触及什么：它的凭证、写入范围、能合并什么，以及是否开启了任何跳过权限确认模式。然后按权限边界中 L2 一栏来设置：没有生产凭证，每次提交都由人批准，绕过模式全部关闭。用更宽的令牌跑的试点，测的是一个你并没有选择的级别。

接着要确认你的测量到底看不看得见效果。负责维护 AGENTS.md 格式的智能体 AI 基金会（Agentic AI Foundation）在一个较难的多文件任务上测试一份十二行的指令文件时，每种条件只跑一次，结果显示这份文件让速度慢了 44%；每种条件跑五次，得到的中位数却是提升 9% 到 10%（AAIF，2026 年 7 月，T3，单一代码库）。试点期间做的任何配置改动，无论是换模型、换智能体框架还是换指令文件，都要重复运行多次才能让人相信。本站的深入解析《评测方差与统计功效》和实战手册《评估编码智能体》讲了方法。

如果任务需要一份书面规格，就把规格算作成本。一个 14 名工程师参与的 Spec Kit 试点，估计每个中等规模功能的规格与计划开销为 45 到 90 分钟（Farrag，2026 年 5 月，T3，无对照）；《需求、规格与设计》讨论了这笔开销何时划算。

在智能体开工前取好基线

没有对比的试点只是演示。在规模化推广之前先做受控试点，公开记录中最清楚的例子是澳新银行（ANZ Bank）。2023 年年中，它用六周时间（两周准备、四周 Python 挑战题），把从约 5,000 名工程师中招募的 100 多名参与者分成使用 Copilot 的一组和对照组。Copilot 组完成任务"比对照组快 42.36%"，结果具有统计显著性，缺陷和代码异味也更少；安全方面的结果则没有定论（Chatterjee 等人，T2）。

值得学的是设计，不是数字。42.36% 背后那项检验的样本量只有 22，任务是练习题而不是银行自己的代码，作者也指出"各项任务的参与率波动很大"。之后 ANZ 把使用范围扩大到约 1,000 名工程师，却只报告了没有量化的"早期数据"。但顺序是对的：先做受控对比，再推广。

常见的替代做法是前后对比，它有一个已知缺陷。那个 Spec Kit 试点把采用前的两个月和采用后的两个月作比较：每月回退次数从 2–4 次降到 0–1 次，每个迭代的后期热修复从 3–5 次降到 1–2 次。作者自己列出了局限："缺少平行对照组"，以及"无法排除时间上的混杂因素（例如研究期间 AI 模型能力的提升）"（Farrag，T3）。模型在一个季度之内就会变。前后对比式的试点，分不清效果来自你的流程改变，还是来自厂商的版本更新说明。

本书对试点基线的提议包括四个部分：

• 历史数据。同一任务类型中，此前 90 天由人完成的变更：数量、前置时间、评审等待、回退、可追溯的缺陷。本站的《衡量智能体投资回报》一页说得很直白：没有反事实基线，就没有投资回报可言。
• 同期对比。同一测量窗口内同一类别中由人完成的变更，或者一个不使用智能体的第二团队。这样就去掉了限制 Spec Kit 试点的日历混杂因素。本站的《智能体的线上实验》和《影子模式与暗发布》介绍了这些设计。
• 固定配置。在测量窗口内固定模型、智能体框架和指令文件，任何改动都要记录。
• 成本一栏。每次合并变更的成本，包括评审者的分钟数和返工，按《经济性、风险与度量》中的模型计算。本书没有找到任何组织公布过包含人工评审的这一数字，所以试点正是你拿到自己数字的地方。

每个流动指标都要配一个稳定性指标：前置时间配回退，落地变更数配可追溯到它们的缺陷，评审时间配返工率。正是这种配对，让试点不会重蹈数量陷阱的覆辙。

在第一个结果出来前写好叫停规则

看到结果之后才写的叫停规则，只是事后找理由。要先写，指定由谁来执行，并商定触发后会发生什么。有两个事实决定了这条规则能是什么样子。

第一，90 天试点的规模太小，无法证明某种罕见的危害不存在。dotnet/runtime 公布了本书找到的唯一一份智能体与非智能体回退率的公开对比：535 个已合并的智能体拉取请求中有 3 个被回退（0.6%），其他 4,251 个已合并拉取请求（包括人工和机器人提交的）中有 33 个被回退（0.8%），而文章说这个差异在统计上没有意义。一次试点的变更数要少得多。下面的算术说明了这对基于回退的叫停规则意味着什么。

Illustrative arithmetic (no organisation). Binomial model.
Agent PRs merged during the measured window       150
Human revert rate in the same class (baseline)    0.8%
Expected reverts if the agent is no worse         1.2

Stop rule: "4 or more reverts in the window"
  P(rule fires) if agent revert rate = 0.8%       3%    (false alarm)
  P(rule fires) if agent revert rate = 3.0%       66%   (catches a ~4x harm)
  P(rule fires) if agent revert rate = 1.0%       6%    (misses a small harm)

试点规模的叫停规则能抓住大的危害，抓不住小的。所以规则应当是事先定好的绝对阈值，而不是显著性检验；小的危害留给 L3 准入所要求的更长期对比去发现。本站的《智能体的线上实验》完整推演了样本量算术，也讲了当你需要的实验负担不起时该怎么办。

第二，早期的流动指标可能会下滑。DORA 观察到，"实施平台工程举措，可能会在改进显现之前导致绩效暂时下降"（DORA 2024，调查，2024 年 10 月）。这个发现针对的是平台，不是智能体，但这种曲线在流程变革中很常见，dotnet 的第一个月就是如此。因为第三周变慢就叫停，会扼杀本来能成功的试点。

因此，本书的提议把触发条件分为三类：

• 硬性叫停，立即生效，针对安全。智能体修改或跳过了它的核验器；它在权限边界之外行事；它产出的变更进入生产并引发了超过你所指定严重级别的事故。任何一条都会结束测量期，并让该任务类型退回一级，直到原因修复。
• 阈值叫停，在评审节点检查，针对稳定性。回退或可追溯缺陷超过事先定好的数量，如上面的算术所示。
• 暂停攀升，在第 90 天判定，针对流动与成本。与同期对比相比，前置时间或每次合并变更的成本没有改善。暂停意味着不再往上爬，而不是回退。

《衡量成效，以及何时回退》给出了指标集和回退触发条件的已公开先例；试点的叫停规则就是它们的第一个实例。

这 90 天

下面的日程是本书的提议。没有哪个已公开的试点照此执行；它只是把上文的做法按彼此依赖的先后顺序组装起来。

测量窗口是 45 天，不是 90 天。这是有意的：把磨合期算进去的测量，评判的是防火墙；不留时间解读结果的测量，产出的是一个谁也辩护不了的决定。如果这种任务类型的量太少，45 天里凑不够可计数的变更，就换一个更繁忙的任务类型，而不是把试点拉长。

计分卡只有一页，在智能体首次运行前签署。附录 A《模板》提供空白版本；下面这份展示了它的样子。

PILOT SCORECARD (the book's proposal; sign before the first run)

Phase / task type     Maintenance / <one named change class>
Level under test      L2: every agent change human-reviewed, attributed
Verifier              build, type check, lint, tests; agent cannot edit
Credentials           own branch only; no production access; bypass off
Configuration         model, harness, instruction file: pinned on day 30
Baseline              previous 90 days, same class, human-made
Comparison            same class, same window, human-made
Flow metric           lead time; review wait vs active review time
Stability metric      reverts; defects traced within the window
Cost                  cost per merged change, incl. reviewer minutes
Hard stops            verifier edited or skipped; out-of-envelope action;
                      incident above severity <n>
Threshold stop        reverts >= <n> in the measured window
Hold                  no gain in lead time or cost vs comparison
Decider / date        <name> / day 90

解读结果

一次试点有三种诚实的结局；只要规则是事先写好的，每一种都算成功。

扩展。与同期对比相比，流动指标改善了，稳定性守住了，每次合并变更的成本也清楚了。让该任务类型保持在 L2，继续收集对比数据，直到覆盖 L3 准入所要求的 90 天。按《维护与迁移》开始为 L3 打基础：用证据包代替逐行评审，并演练暂停与回退。或者在 L2 上试点第二种任务类型。两件事不要同时做。

暂停攀升。什么都没坏，也什么都没改善。约束往往在别处：智能体的产出在评审处排队，而这正是评审限流的算术所预言的排队位置。暂停为下一次试点指明方向，它可能应该放在评审或测试，而不是生成。

降级。触发了硬性叫停或阈值叫停。把该任务类型退回到原来的级别，修复原因，再决定要不要重跑。在本书的模型里，降级是正常运维，不是失败。

两条限制适用于每一种结局。试点的数字属于你的代码库、你的任务类型和本季度的模型；它们不能迁移到其他团队，正如Airbnb 的 97% 和 Slack 的 80%彼此不能互相套用。而且试点结果不等于规模化结果：ANZ 的六周受控实验之后，是一次面向约 1,000 名工程师的推广，而它对此只报告了"早期数据"。当第二个一百名工程师到来时，从治理到权限会有哪些变化，是《向更多团队推广》的主题。