英国：公共问责怎样进入共同开发

一次政府咨询收到大量意见，工程团队可以帮助整理，决定这些意见意味着什么的责任却仍在业务机构。英国材料最有价值的部分，是把专业复核中的具体困难留下来，让下一项建设能够据此改变。

Consult：工程要留出专业判断能够回来的路

英国的 Consult 提供了另一个观察入口。它由政府的人工智能孵化团队 i.AI 开发，属于 Humphrey 工具组。英国政府2025年5月14日的说明介绍了一次真实咨询试验：苏格兰政府征集有关非手术美容项目监管的意见，Consult 协助分析两千多份反馈；当时工具仍处于试验阶段。¹

公众意见不是一列已经填好的数字。人们可能在同一段话里支持加强监督，又担心成本上升。工作人员需要识别讨论主题，再判断每份意见涉及哪些主题。这件事既有重复劳动，也有解释空间。

Consult 的评估报告署期为2025年3月20日。流程分成主题生成与回答分类两步，专家先检查主题，再复核系统给各回答分配的主题。评估中，60%的回答分类未被复核者修改；报告同时指出，确认主题很费心力，工具不善于识别遗漏的主题。²

报告还记录了这种费力怎样发生：复核者认为与 i.AI 工程师讨论的时间不足；主题签字确认后又不能编辑，使人担心必须一次做到完美。² 专家已经参与，却缺少充分交流和确认后的修订机会。一次确认因而承受了太多压力，不能只靠增加一道“人工复核”解决。

这些结果放在一起，才能看见工程问题。若只报“多数不用修改”，很容易让人以为可以直接撤掉复核者。但一个分类工具只能在它拥有的分类中挑选。如果最初的主题表遗漏了某种意见，后面的分类看似顺利，也可能没有真正听见那种声音。

本书据此建议，把专家与工程师的共同核对安排在主题确认之前，并保留根据样本分类结果重新检查主题的机会。专家负责解释需要怎样修订，工程师负责让变化进入后续处理，留下前后版本及受影响的回答。这是待建设的工作方式，并非报告证明已经具备的功能；它让专业人员能够指出“这里少了一类重要问题”，而不只是把已有分类勾成通过。

这里最值得改变的是“确认”的时点。主题先被锁住，专家就必须在尚未充分看过分类结果时承担判断；允许根据样本返回修改主题，会多一次处理，却可能减少后续大批量返工。报告记录的障碍并非模型完全不能分类，而是专业判断进入工程过程的机会不够。

这是一种客户已经有内部工程团队的情形。外部供应商若加入，应先看哪一项产品能力仍然缺失，而不是把内部开发重新包装成供应商交付。已有人承担的工作不会因为换了一个团队名称就消失。

当商业工具追上来，内部建设也可以停止

英国政府在 2025 年 10 月 16 日另行说明，Redbox 帮助人员处理文档的经验将进入后续工作，但不再继续开发该工具：商业方案已能在现有系统里提供相关能力，公告举到了 Copilot，并说明原有工程知识会用于 Humphrey、GOV.UK Chat 等工具。³

这不是宣布所有服务当日关闭，更不能称为一个已确认的 FDE 失败。它展示的是一项真实的替代决定：继续自建的价值，会随着外部产品变化而改变。已经投入的工程知识也不必随某个工具停止发展而全部作废。

把它与 Consult 并列，英国材料就不再只是“政府应该自己做 AI”的故事。需要围绕专业判断反复调整的地方，内部共同建设有作用；成熟产品已经覆盖的地方，缩小自建范围也有理由。采购和工程不是先后完成就互不相干的两道门，采购选择会在产品成熟后再次进入项目。

银行已有系统时，合作接进哪一层

公共部门的安排不能代表全部英国企业。NatWest在2025年的合作公告中，以已有的Cora+客户助手和AskArchie+员工助手为基础，说明将与OpenAI继续发展助手能力，并沿用本行的AI与数据伦理行为准则。客户服务、反欺诈和投诉处理是公告列出的发展方向，不能把计划一并记成已完成部署。⁴

这个对照使英国章不止于一种政府建设模式。银行并非等待模型供应商从空白开始搭一套系统；它已有客户入口、员工工具和内部治理。外部工程团队首先要理解哪个责任仍由银行掌握，新的能力在哪个入口工作，以及哪些复杂请求回到人员处理。

从Consult到银行助手，能够共同观察到的，是专业组织希望保留对结果的解释和处置。这是所选案例暴露的组织需求，并非“英国人比较谨慎”的民族性判断。真正影响建设的，是何时可以改分类、谁能更改客户记录、何种后果需要业务负责人再次判断。

让第二处部署接受不同答案

设想另一个公共机构准备采用咨询分析工具，这是教学判断。已有材料给它两个合理选项：购买通用文本工具，由专家手工整理主题；或者建设能够反复修订主题、重跑受影响回答的专用流程。

在一个规模较小、议题稳定的咨询中，前一种方式可能更省资源。若主题必须随着专业复核调整，而且需要回查哪些回答因调整改变分类，专用流程才有更明确的理由。作出后一项选择后，项目安排应优先给专家与工程师留出共同核对时间，并验证“主题改变以后能否继续处理”，而不是只检查初次分类速度。

这个决定由 Consult 的真实障碍启发，但不是其后来已经完成的改版。若第二个机构每周只能安排一次专家讨论，它的迭代速度就不能照搬第一处；若商业产品已经具备所需修订与回查功能，又应重做自建与采购比较。Redbox 的记录提醒我们，这种改变可以发生在项目已经投入之后。

一份适合下一客户的交付说明，应当分别列出：机构已能做的事、专业人员仍需判断的事、软件必须补上的能力，以及商业产品变化后可以停止自建的条件。若把专业人员安排在最后一次验收才出现，就很容易重演主题已经锁定、却无法放心确认的困难。

本章显示的工作理念是可修改的专业判断与可重新选择的建设方式。它需要工程师能听到复核意见，也需要组织接受某个内部产品不再值得继续投入。FDE团队的价值应落在这些具体缺口上，而不能把“共同开发”本身当作永远正确的目标。