上线前的最后几道门

使用者说有帮助，系统就可以正式开放了吗？

2024 年 1 月 18 日，英国政府数字服务团队（GDS）公布 GOV.UK Chat 的早期试验结果。在 157 份跟进问卷中，近七成用户认为回答有用。与此同时，专家检查表明，答案整体仍未达到这个政府网站要求的准确水平。团队还发现，一些用户因信任政府品牌，低估了错误风险。¹ 好感与可靠性，出现在同一份报告里，却没有指向同一个结论。

这里使用的是一个公开记录较多的政府 AI 项目。材料显示有模型供应商提供工程支持，但没有明确证明参与者使用 FDE 职衔。本章把它作为客户与工程团队共同验证系统的方法参照。无论岗位叫什么，负责交付的人都会面对相同的难题：一项看起来已经能用的能力，还缺什么才值得交到真正的使用者手里？

“上线”容易被说成一个日期，其实包含一组不同的允许：允许什么人做什么事，使用哪一版系统，出了问题怎样发现，又能及时停止哪些动作。测试报告可以帮助作决定，却不能替组织作完这些决定。

先决定这次究竟允许什么

一套系统可以在提供一般信息时已经有用，在替人作决定时仍然远远不够。同一个模型，同一个聊天框，承担的后果可能完全不同。

GOV.UK Chat 在 2025 年 10 月发布的算法透明记录中，说明了当时的边界：它整理政府网站的指引，提供来源链接，不替用户作决定或执行行动。记录列出了 GDS 的责任角色，也说明 Anthropic 提供建议和工程支持。² 这份文件不能证明系统从不出错，但让读者知道，当时被测试的是什么。

对一个准备上线的项目来说，这种边界应进入验收。若团队承诺的是帮助用户找到资料，检查重点包括内容是否适用、链接是否有效、缺少信息时是否说明；若承诺的是提交申请，还必须验证提交对象、授权和业务结果。不能拿前一类任务上的表现，为后一类能力提供批准。

工程师也需要知道谁能够判断边界是否兑现。业务负责人确认什么结果对用户有用，专业人员判断内容是否正确，运行负责人判断故障能否被处理。FDE 可以组织证据，解释实现和限制，但不能凭自己完成了开发，就代替所有角色宣布业务已经准备好。

这并不要求任何上线都经过一场盛大的审批会议。后果轻、容易撤回的内部辅助工具，可以有很轻的确认办法；会向公众作重要说明，或者会改变业务记录的系统，需要更清楚的依据。严谨的核心是责任与后果相称，不是签字的人越多越好。

把“答得不错”变成可以检查的任务

接下来，需要把允许的工作拆成真实可评的任务。

一个任务不应只有问题和一段看起来理想的答案。还要知道当时有哪些资料、用户处于什么条件、系统可以使用什么工具，以及怎样才算完成。否则，两次结果不同，团队很难判断究竟是能力变化、资料变化，还是评分的人换了标准。

例如，本书构造一个信息服务的教学测试：用户只问到哪里查询一项办理进度。合格回答应把他带到适当入口，而不应自行判断他是否符合申请资格。若测试只检查回答有没有包含“办理进度”几个字，一段内容很多、实际跑题的答复也可能得分。真正需要验证的是回答是否帮助用户完成所问的那一步。

普通任务只能说明普通情况下会发生什么。还应寻找会改变处理方式的情况：问题缺少必要条件，相关资料已失效，输入包含不应执行的指令，或者资料不足以支持完整回答。每一种情况都应有可解释的期待，例如先澄清、只提供有依据的部分，或说明无法处理并给出接续路径。

选择这些任务时，不必把所有稀有情况平均分配。日常出现的任务关系到实际价值，少见但后果严重的任务关系到可接受边界。两类都需要看，却不能简单混成一个总分。把它们分开，团队才知道一次进步究竟改善了大多数人的体验，还是补上了一个关键漏洞。

GOV.UK Chat 的早期试验采取逐阶段推进：前三阶段在内部，包括刻意尝试使系统出错的测试，之后才接近真实用户。¹ 这种安排的价值，不是阶段数量本身，而是让不同条件下的证据依次进入决定。内部人员能检查一些明显错误，真实使用者则可能提出团队没有想到的问题。

测试题还需要更新，但不能随意消失。某次真实失败转成新题，可以避免下次重复；旧题如果因为系统一直做不好就被删掉，分数上升便失去含义。反过来，业务范围确实改变时，也不该让旧题永久绑住新系统。保留题目为何加入、修改或退出的理由，才能看清评估在跟随什么。

同时，不宜把所有题都用于日常调试，再把同一批题上的改善当成适应新问题的证明。本书建议保留一部分不直接用于修改的任务，检查团队是否只把已知问法修好了。规模不必一开始很大，但这些任务应来自相应工作范围，具备可核实的判断依据。随意编几道陌生难题，或者故意加入无法回答的问题，不会自动使评估更严格。

还可以对同一个任务换几种自然问法，观察必要条件是否仍然被遵守。这里不是追求系统识破出题者的每个文字机关，而是区分真实需要与固定措辞：用户换一个说法，应该改变哪些处理、不应该改变哪些处理？如果团队答不上来，也许需要先澄清业务边界，而不是继续修改模型提示。

评分的人，也可能看错

把一批问题交给模型，再让另一个模型评分，很方便。但方便并不回答评分是否可靠。

有些项目可以检查明确的结果：所需文件是否存在，记录状态是否符合约定，链接是否能到达指定页面。另一些任务允许多种表述，无法用文字完全相同作为标准。此时，模型评分可以帮助快速筛查，专家仍需要检查它是否把漂亮表达误当成正确内容，或者拒绝了其实有效的另一种答案。

Anthropic 在 2026 年 1 月的评估文章中，要求把模型评分与专家判断校准。文章也记下一个实际教训：在某些内部测试里，Claude 从之前试次留下的 Git 历史获得额外线索，表现因而被抬高。³ Git 在这里保存的是文件修改历史；模型读到了本次测试不该提供的先前过程。

这个问题提醒我们，测试环境本身也是被检查的对象。如果第二次运行继承第一次的答案，它并不是一次独立的新尝试。如果几次失败都来自同一个损坏的环境，也不能把每次都算作模型判断失误。应先恢复一致的起始条件，再讨论能力是否改善。

可以把这种分歧写进三个很小的教学样本。假定“教学服务中心”的有效资料D2规定：已知办理事项与受理号时，去进度入口查询；事项不明时先澄清；本助手不判断申请资格。D1是已经停用的旧入口。这些资料、输出和裁决都是预设练习，没有让真实专家或模型执行过测试，也不是GOV.UK资料。

若想先独立判断，可先看附件的资料与三道题，写下理由后再读下表的裁决。

E2的分歧改变了评分办法：从检查入口及引用状态，扩展为同时检查事项是否已知、有没有越权资格判断、引用是否适用。不能只把这一题手动扣分后继续使用旧评分器。记录将标准G1改为G2，要求三个样本全部重评；下一版若把E2改成先问事项，还要重跑E1，防止系统对已经给足条件的人反复追问。

三题评估与专家裁决单保存完整问题、资料、预设输出、分歧理由和发布决定，并提供空表。它的作用是演示如何从错误走到下一动作，不是用三道题证明系统可靠。第三版只允许员工预览，E2、E3由人工接续；公开直出继续关闭。

专家也需要拿到合适的材料。只看一段答复，可能无法分辨它是否漏掉了用户问题中的关键条件；只看模型挑出的资料，又可能漏掉本应使用却没有找到的来源。评价内容时，应能同时查看任务、适用原件和实际回答。若条件允许，可以暂时隐藏回答来自哪个版本，减少对“新版本理应更好”的期待影响判断。这些安排增加了审查成本，所以应优先用于决定能否开放的重要问题。

尤其要保留“无法判断”的位置。有些回答是否适用，需要知道用户未提供的条件。强迫评分者只能给对或错，会把信息不足变成伪确定性。一个有用的评估结果，可以说明缺什么才可判断；相应地，被评估的系统也应学会在需要时询问，而不是把每个空格都填满。

校准并非一次工作。模型升级、资料变化或用户开始提出新类型问题，都可能使原来的评分办法不再合适。团队可以持续用明确样本检查评分者，不必每轮全部人工重评；但一旦发现评分理由与专业判断分离，就需要暂停依靠该项分数作重要决定。

一个 90 分，可以藏着两种系统

2026 年 3 月，GDS 总结后续两轮试点时，称回答准确性从早期的 76% 提升至 90%。它结合专家与自动评估，并把缺少必要内容也计入不准确。⁴ 这是团队报告的进步；读者仍需要进一步追问，哪些问题得到了改善，哪些结果被总数遮住了。

下面是一个与该项目无关的教学算例。假设测试含 80 道普通问题和 20 道后果较重的问题，且为了演示，暂把每道题都按一分计算。

两个总分完全相同，意味着的选择却不同。甲在普通问题上很好，较重问题有明显缺口；乙在这组较重问题上全部答对，却让一部分日常使用者遇到困难。不能只选一个总分较好看的阈值，就把两者视为同样准备充分。也不能因为乙在这 20 题上全对，就认定它对所有此类问题都可靠。

题目的比例还会改变总数。若实际用户的问题分布不同，测试总分并不直接等于上线后的成功率。对于关键问题，可以单独设必须检查的条件；对于日常体验，可以观察覆盖范围和常见失败。这样会失去一个数字总结全部工作的方便，却换来更能指导修改的判断。

另一个容易混淆的是，多试几次至少成功一次，与每次都稳定完成。Anthropic 的评估文章专门区分这两种目标。³ 如果使用者会查看多个候选并挑选，最好的一次可能有价值；如果用户只得到第一次答复，团队不能把后来终于成功的那次当成他的实际体验。

因此，重复运行应记录失败在哪里，而不只是挑选最好结果展示。若同一道关键问题偶尔漏掉条件，平均分可能仍然很高；但是否允许用户直接依赖它，需要结合后果和补救能力判断。稳定性不意味着措辞一字不差，而是允许变化的部分变化，必须满足的条件持续满足。

在 GOV.UK 的报告里，准确性有自身的评判标准，研究方法也涉及多种样本。它没有把所报 90% 明确绑定到一份可供读者重算的单一固定题集。⁴ 所以，本书不把这项数字转成模型的普遍能力，也不把改善全部归因于某一个工程改动。

拦住错误，也可能拦住正常工作

验证还应主动寻找误拒：系统遵守了一条规则，却因此没有帮助本来应该服务的人。

Salesforce的一份Customer Zero官方访谈提供了具体片段。Bernard Slowey回顾，团队曾要求Agent不谈竞争对手，后来发现，客户询问怎样将Microsoft Teams与Salesforce集成时，也得不到回答，尽管公司有相关资料。团队于是调整了指令。⁵ 本书采用的是这次误拒的自述；公开字幕没有标清发生日期，也没有证明调整后的全部行为都已可靠。

这个错误来自范围划分：评价竞争产品，与帮助客户连接已购买的软件，并不是同一种任务。“凡出现某个名称都不答”易于检查，却把两者放在同一边。修复后至少需要成对测试：正常集成问题应得到有依据的帮助，超出服务职责的问题仍应被适当处理。只验证原来被挡住的那一题恢复，可能看不见另一边新打开的缺口。

因此，一道防护的成绩不能只数挡住多少请求，还要看挡住的是否应被阻止、放行的能否成立，以及剩下的任务有没有接续路径。把误放、误拒和转交后的结果一起保留，业务负责人才能判断保护措施付出了什么代价。

修好一处，别把另一处重新打开

真正有用的评估，会改变设计，而不只是给版本排座次。

GDS 在 2026 年 5 月的工程总结中，把 GOV.UK Chat 的首个原型追溯到 2023 年 7 月，并说明它后来把自动评估、专家检查和在线监控结合起来。系统还安排了生成前后的两层检查，分别处理输入与生成回答的问题。⁶ 这段历程不是某个模型一经接入就获得成熟能力，而是团队不断修改整套系统。

其中一个取舍尤其具体。3 月的试点报告说，团队考虑让答案边生成边显示，以缩短用户感受到的等待；但这样做需要重新设计部分安全防护。⁴ 原来可以等完整回答生成以后再检查，提前显示则改变了检查与用户看见内容的先后关系。

从这个问题可以推得一条实用原则：体验改进也可能改变验证对象。更快显示并非只调一个界面效果，它可能使某些检查来不及阻止已经呈现的内容。团队需要重新决定哪些检查必须在显示前完成，哪些只能事后发现，以及相应风险是否可接受。这里是工程分析，不是对 GOV.UK 内部方案的补写。

同样，换一个更强模型，不能只重跑几道旧的困难题。它可能改变回答长度、对模糊问题的处理方式，甚至与原有工具的配合。真正需要比较的是这一次准备发布的组合：模型、系统指令、资料、工具和相关配置。模型厂商的通用榜单无法代替这套组合在当前任务中的表现。

测试记录因此需要绑定版本。否则，会议上看到的是昨天的结果，实际部署的却是今天临时改过的提示词；双方都可以诚实地说“测试通过”，说的却不是同一个候选。保留当时运行的配置和必要输入，是让上线决定能够被核对的最小条件之一。

这也为快速迭代提供了空间。没有改变相关行为的小调整，可以沿用仍然适用的证据；改变了内容、权限、工具或重要流程，就重新检查受影响部分及其衔接。不是每次都从零开始，也不是一次通过以后永久有效。判断依据应是变化可能影响什么。

有限开放，要能看见有限范围里的问题

离线题目做得再好，也不能覆盖真实流量的全部组合。扩大使用之前，还需要在可以控制后果的范围里观察。

AWS 在 2020 年公布的发布工程文章中，描述了先让新版本服务小部分请求，再按波次扩展的办法。文章特别指出，小范围问题可能被总体指标淹没，因此要观察新版本所服务的那部分请求；异常可以触发自动回退。⁷ 本章借用的是发布机制，不把 AWS 的具体比例或等待时间当作所有 FDE 项目的标准。

如果新版本只处理少量任务，即使其中失败很多，全站平均成功率也可能看起来变化不大。使用者分组、版本标记和任务类型因而不是统计报表的装饰；它们决定团队能否知道谁正在受到影响。所谓小范围开放，只有在这个范围能够被识别和观察时，才有相应的控制价值。

还要避免把“开放得少”当成“后果一定小”。少量真实请求仍可能包含严重错误；有些任务不能先让错误发生再观察。可以先让系统在旁边产生建议，由有能力判断的人决定是否采用，或只开放后果较轻的部分。这样会减少自动化的即时收益，也降低首次试验必须承担的承诺。

观察多久也不能只看时钟。团队至少需要遇到相应工作条件，才能判断它们是否被覆盖。一个只在白天运行过的试点，尚未说明夜间没有熟悉人员在场时会怎样；只由熟练同事使用的版本，也尚未说明普通用户是否理解提示。等待本身不会产生证据，需要知道还在等待哪一种情况。

如果真实流量太少，团队可以把未覆盖条件保留为限制，而不假装观察完整。可能的选择包括继续有限使用、扩大到另一个可控范围，或使用有针对性的模拟检查。模拟有自己的作用，但不能把模拟人数写成真实采用，也不能把实验室结果自动换成日常工作的可靠性。

发布当天，谁能把范围收回来

本章关心发布这一天：负责观察新版本的人能否辨认受影响请求，触发停止，并交出仍未完成的任务。长期怎样培养接手者，见第18章；合同退出和任务迁移见第21章。这里不必重建一整套培训体系，但不能让小范围试用成为无人看守的开放。

教学中心为第三版预览安排一名复核人员。本次演练有三种各自成立的停止条件：

• 容量不足。 假定下一小时只能处理5条待复核任务，积压达到6条就暂停接收新任务，已经接收的交回原人工渠道。这个数来自假设的可用人力，不是发布标准。
• 判断依据不可用。 复核人员无法取得或核实答复所用的来源时，也暂停新进件，将已接收任务转回原人工渠道；即使还有空闲人手，也不能继续接收。
• 越过批准范围。 任何答复绕过复核直接送给公众，就立即停用该出口，查出具体接收对象。

三种条件不能互相替代。人数充足不能补出缺失的依据，回答正确也不能补上直出公众的授权。

停止动作也要落实到本次能力。可以关闭新请求入口，保留读取既有记录；若切回旧版本，先确认新版本产生的记录仍能被旧流程理解。只让屏幕回到原样，并未处理已经收到答复的人。

AWS 的发布文章还检查新旧版本能否并存，避免新版本写出的数据让旧版本无法理解。⁷ 这说明回退不只是重新打开旧程序。若数据已经改变，或者用户已经依据错误说明采取行动，恢复软件版本也未必恢复原来的现实。此时还需要处理受影响记录，或者通知适当人员跟进。

因此，一次实际演练比一句“支持回滚”更有价值。团队可以在受控条件下暂停功能，确认监控有没有发现、谁收到信息、旧路径能否继续，以及未完成任务被怎样处理。演练中记录的是实际完成的动作；未演练的条件仍然需要保留，而不是被一个总体勾选框遮住。

允许上线，不代表验证结束

回到前面的信息服务教学任务。设团队正在测试第三版：公众不能直接收到模型答复，工作人员只能预览建议，核对后再发送。教学测试出现了这样的回答：用户没有说清办理事项，系统却猜成某个事项，并自行补上资格判断；但在限定事项的进度查询中，工作人员能依据所附的适用页面核对入口，发现跑题时也能退回人工办理。这支持的是有人复核的受限使用，尚不支持直接面向公众回答。

业务负责人据此只批准少数受训人员试用第三版，工程负责人确认配置与测试记录一致，停止与人工接续沿用上一节的安排。团队把“信息不足时猜事项”留下作为下一版必须解决的题；修好这道题以后，也要重新判断能否扩大开放。这些发现和决定都是教学设计，不是 GOV.UK 披露的内部过程。

这样的验证也可能拖慢交付。若把所有任务按最高后果审查，团队确实可能迟迟无法开放。解决办法是按实际后果和恢复能力分层，并允许先开放已经有充分依据的一小部分。不能因为存在未知，就无限推迟一切；也不能因为试点需要继续，就把未知改写成已经通过。

模型本身的进步也可能贡献大量改善。GOV.UK 的公开记录不能精确分拆模型、资料处理、界面和评估各自带来的效果，更不能证明某种岗位独自创造了可靠性。但它让一个重要过程变得可见：团队用真实问题修正系统，也用系统表现修正最初的承诺。

于是，上线不再是一场证明工程师已经做完的仪式。它是组织明确承诺，愿意在说清楚的范围内，把一部分工作交给这套系统，并持续看见它做得怎样。下一章要讨论的采用与交接，就从这份具体承诺开始。