一个部门如何在 90 天内完成 AI 落地？按发现、基线、试点、验收和扩展五阶段推进

先看结果：90天后没有“全员上线”，48份建议书请求只扩到两个受训队列，却阻止了一次缺失补充文件造成的错误投标

澄岳软件的企业销售运营部每季度处理约54份招标请求。销售把建议书请求、补充文件和邮件交给提案分析师，分析师建立要求矩阵、分配产品/安全/法务负责人，再起草内部响应包；价格、合同偏离、投标/不投标和最终提交均由有权限的人决定。团队希望AI抽取要求、建议负责人并起草内部文字，董事要求“90天落地”。项目没有把这句话解释成第90天必须让所有人自动提交，而是定义为90天内完成五个阶段、五次证据化决定。

30份历史建议书请求共含360项重大要求。旧流程首轮正确捕获312项，遗漏28项、引用错误版本12项、路由给错误负责人8项；其中15项会影响资格、数据驻留、安全承诺或报价，列为严重。每份人工处理14.8小时，端到端第90百分位为8.2天。随后24份后台并行案例含300项重大要求，系统首轮正确270项，21项在产生业务影响前由人纠正，9项为误报；24份受控建议书请求含304项，首轮正确291项、9项在签署前纠正、3项误暂停后补证、1项保持状态未知，关键遗漏为0。

关键案例RFP-218的机会清单显示应有基础文件、A1、A2三份材料，上传区却只有基础文件与A1。AI根据旧文本把“加拿大数据驻留优先”列成可以解释的偏好；文档清单放行门槛发现A2缺失并暂停。补齐A2后，条款已经改为“必须在加拿大托管”，当前产品不满足，业务负责人签署不投标，系统没有生成可外发承诺。第90天的决定，是把只读和内部草稿能力扩到两个有复核容量的队列，继续禁止发送和定价权限，而不是宣布AI项目已经完成。

所有公司、建议书请求、人员、日期、投入和结果均为虚构教学案例与教学数据，不是行业周期或成功率基准。本文讲一个部门怎样组织90天证据链，不保证任意AI项目可在90天生产化，也不代替采购、安全、隐私、合同、劳动或适用法律审查。E37另讲价值归因；本文只记录价值信号和完整成本，不用节省小时单独证明投资回报。

90天是决策时间盒，不是交付承诺：复杂度超出时可以缩范围、延长或停止

日历能制造节奏，不能消除数据授权、系统集成、专业评审和人员容量。90天计划必须先写“什么可以在90天内被证实”：本案例只验证内部要求矩阵与内部响应草稿，覆盖英文数字版建议书请求、已登记补充文件和两个产品线；不自动定价、不判断法律可接受性、不创建产品承诺，也不向客户门户提交。扫描质量差、非英语、公共部门特殊条款和跨产品包先走人工。

若第15天发现文件权利不清，第30天没有可复原基线，第60天严重漏判仍出现，第75天复核人容量不足，正确动作可能是回到人工、只保留确定性清单检查或延长验证。停止不是项目管理失败；在未知条件下强行按日历全量才是未经证据的决定。计划的每一阶段都以决策结尾，未满足证据不自动滑入下一阶段。

时间盒还要区分工作日与日历日。本案例的90天约含64个工作日，阶段交界预留节假日和负责人缺席；关键专业复核若只能每周二进行，就进入依赖账本，而不是假设随叫随到。任何阶段超期，先问证据是否不足、范围是否过大或资源是否未兑现，再选择缩小、补人或延长；不能靠跳过保留评估集、减少关键案例或让同一开发者兼任独立签署来追赶日期。

第0天先签一页项目章程：业务最终状态、边界、负责人、预算和停止权必须在第一次演示前存在

章程由销售运营负责人担任业务A，提案负责人负责日常流程，产品/安全/法务提供专业条件，AI建设团队负责系统证据，独立复核人挑战评估，运营拥有暂停入口。赞助人只能配置范围和资源，不能因为演示好看豁免关键门槛。每个角色写每周实际可用小时，避免“参与项目”只存在会议名单。

章程还记录人工回退、数据位置、供应商审查前置项、决策会议日期与关闭条件。520小时不是模型调用预算：它含观察、标注、建设、评估、复核、培训和运营交接。若专业负责人拒绝提供时间，就缩小涉及其条件的范围；不能在最后一天请对方为已经搭好的系统“盖章”。

每次阶段签署写决策 ID、选项、证据版本、未满足项、条件、负责人、期限、可撤回事件和签署人。状态只能是批准、条件、暂停或停止，不能用“原则同意”“基本可行”让团队各自解释。条件若到期未闭环自动转暂停；赞助人若改变范围，必须重算样本、风险、工时与依赖。这个决策账本是90天计划的主干，甘特图只显示时间，不证明为什么继续。

发现阶段第1—15天：先看真实工作，再把“做AI助手”改写成可验证的问题

第1—5天先跟随六份建议书请求走完全程，记录真实输入、等待、返工和外部影响

团队从不同产品、规模和复杂度选6份已关闭建议书请求，跟分析师从机会登记走到最终提交，观察文件怎样到达、补充件怎样更新、要求怎样分配、谁能承诺、哪里等待。访谈不只问“最耗时什么”，还读取版本记录、任务队列、复核评论和最终回执。销售说“文件都在一个文件夹”不算证据；团队发现两份补充件只在邮件线程，机会清单虽有记录但存储区缺文件。

六份观察只用来画实际旅程，不能当作效果基线。团队为每一步记录案件编号、输入版本、开始与结束时间、执行者、动作、输出、下一步回执和外部影响；等待时间与人工处理时间分开。结果表明，首先要建立文档清单和权威版本，而不是立刻优化提示词。若不解决文件集合，模型只会更快处理一个不完整的事实世界。

观察者不在现场替分析师纠错，否则实际流程会被观察本身改变。敏感建议书请求只在获批环境查看，笔记引用案例/字段而不复制客户机密；访谈意见标为感知，系统时间戳和最终回执标为记录，两者冲突时继续查证。六份中还选一份按时、完整的对照案例，确认低周期是否来自简单程度而非优秀操作，避免只跟随事故案例把流程描绘得过坏。

第6—10天把“做建议书请求助手”重写成一个可测问题，并比较非AI替代

问题陈述改为：“在不改变价格、法律和提交权限的前提下，怎样让分析师更早发现完整文件集、建立有来源的重大要求矩阵，并让第90百分位的完成时间不超过3.5天？”其中对象、结果、期限和边界均可观察。团队列出规则、模板、检索、流程调整和AI候选，先判断哪个环节确实需要语言判断。

非AI方案若仅靠强制清单和标准负责人映射就能达到大部分结果，应先实施。AI的增量限定为从已确认文件集中生成带原文位置的候选要求和内部草稿；确定性规则负责检查缺失文档、版本、负责人代码和禁止工具。这个分工防止项目把流程缺陷、知识缺口和权限问题都包装成模型任务。

问题卡还要写反目标：不以生成字数、用户点击率或“AI接受率”衡量，不缩短专业负责人必须作决定的时间，也不要求分析师接受候选来维护采用数字。若清单改造已经把第90百分位周期降到门槛以内，AI候选就必须用新增的准确性、容量或风险证据证明继续建设的必要；否则可在第一次放行时选择规则方案。这样，90天项目不是预先为某个模型安排验证仪式。

第11—15天按后果排序高风险假设，并用第一次放行门槛决定进入基线、改题或结束

团队把“模型会抽取”拆成可证伪假设：完整文件集可以枚举；重大要求能形成一致的参考答案；原文位置能指向有效版本；分析师有时间逐条确认；禁止外发可以由权限强制；真实案例组合能在90天内出现。风险优先级看失败后果、未知程度与试验成本，不按最容易演示的功能排序。

放行门槛 1的签署选项为停止、重新框架、基线或带条件的基线。本案例选择后者：先修清单对账，并让产品/安全共同裁决26个分歧；不批准“全建议书请求自动响应”。会议记录未解决项、负责人和日期，而不是用绿色路线图隐藏。进入下一阶段的产物是问题卡、实际旅程、假设表、数据/权限初查和限定范围。

假设表在每个放行门槛都要重新打开，而不是在第15天封存。例如，后台并行对照若发现真实补充文件比例高于历史样本，案例组合假设就从绿色转为黄色；受控试点若复核人纠正集中在同一产品，参考答案的一致性或知识维护假设要重验。每条证据记录“支持、反驳或仍未知”，未知不自动按通过处理。团队优先关闭会使整个服务不可行的假设，而不是堆积容易获得的满意度证据。

基线阶段第16—30天：先冻结样本、口径和门槛，再允许系统开发

第16—20天抽30份历史建议书请求，按复杂度分层并冻结纳入与排除规则

只选容易文件会使试点看似成功。团队从最近两个季度的84份已关闭建议书请求中按产品线、页数、补充文件、表格/正文、安全条款与结果分层抽30份；排除损坏文件但保留其数量，扫描件和非英语因当前范围排除并进入未来清单。样本清单在看系统输出前冻结，防失败后删案例。

每份案例保存原文档清单、文件摘要校验值、有效顺序、最终要求矩阵、负责人、复核评论和最终状态。抽样不能证明全部未来建议书请求，只能证明这些分层中的已知表现；新地区、扫描质量和新的采购模板会触发重新评估适用范围。排除项不进入报告分母，但要单独计数，不能写成“系统适用于所有建议书请求”。

历史材料进入评估前，由数据负责人确认用途、访问者、处理位置、供应商接收方、保留期与删除方式；若原合同不允许把文件发给候选服务，就在隔离环境或脱敏结构上验证，不能用“只是测试”绕过。标注只收集重大要求和必要的原文位置，不复制无关个人信息。数据集导出、标注工具和复核表都继承案例访问控制，项目结束后按登记处置。

第21—25天同时量正确、周期、返工、风险和容量，不用一个平均小时概括现状

两名领域复核人独立标出360项重大要求，再解决分歧形成参考答案。旧流程正确312项；28项遗漏、12项引用无效或旧版本、8项路由错误，合计48项。15项严重缺陷不是额外相加，而是48项缺陷的子集。人工处理时间由任务日志算得14.8小时；端到端周期另从状态时间戳计算，中位数为4.6天，第90百分位为8.2天。

旧流程不是完美对照：历史人员知道最终结果，记录也可能缺失。团队保留缺失日志，不为算整齐而估值；周期比较使用相同起止事件“完整包登记”到“内部包签署”，若清单不完整则另计受理 延迟。E37会处理价值归因，本篇只确保后续比较没有换口径。

参考答案评分表逐项定义重大、正确、部分、错误与状态未知：若条款存在但未改变投标或承诺，不因措辞显眼就自动算重大；若安全要求散在表格与附件中，必须合并引用而不是重复计数。两名复核人首轮一致334/360=92.78%，其余26项由第三名领域负责人裁决并保存理由。若参考答案本身无法稳定形成，模型分数就没有可靠标尺，第二次放行应该延长验证，而不是用多数意见掩盖分歧。

第26—30天把验收合同写在系统开发之前：样本、公式、绝对否决与运行证据同时确定

评估集从30份中选18份用于开发和校准，12份作为冻结保留集，并追加8个合成但业务形态真实的关键案例，覆盖缺A2、旧版本、矛盾条款、提示注入式文件文字、错误客户、无负责人、表格断行和产品能力缺口。开发者可以看18份开发案例，不能根据12份保留集的答案调整提示词。每项判定保存参考答案、来源、严重程度和允许差异。

放行门槛不是加权总分：严重漏项不能用节省时间抵消。验收合同还写明系统版本、数据集版本、运行命令、复核人、分歧处理、试点起止、日志字段和谁能签。若业务负责人在看到结果后修改阈值，记录为新决策并重新评估，不能悄悄移动球门。

负面测试不只问输出是否错误，还直接尝试跨机会读取、把旧文件标当前、伪造来源、绕过暂停、调用不存在的发送权限、重复签署和在日志失败后继续。期望不是模型礼貌拒绝，而是身份、规则或工作流返回确定状态并保存事件。恢复测试从断点启动手动通道，再核对没有漏案例、双重矩阵或孤立签署；无法对账即使文本准确也不得试点。

第30天的第二次放行，只在基线可复原、参考答案分歧已裁决、验收合同已签、数据与权限前置项成立时才能选择进入试点；否则就扩展基线、重新定义问题或停止。本案例签署带限制的试点，批准构建后台并行对照和内部草稿路径，不批准任何真实外部影响。阶段名称相同不代表自动获得下一阶段权限。

试点阶段第31—60天：从最小路径到后台对照，再进入受控使用

第31—35天只搭最小端到端路径：清单、版本、原文位置、人工决定和回执先于漂亮界面

最小路径只接收已批准存储区中的建议书请求，不允许用户把任意客户文件粘贴到公共聊天工具。材料进入系统时先核对商机、预期文件与摘要校验值；解析层保留页码、单元格和原文位置；AI输出候选需求、类型、来源和置信度；规则层检查版本、负责人映射和禁止动作；复核界面让分析师接受、编辑、拒绝或标记状态未知；最终内部响应包必须完成签署才生成回执。

系统身份只有读取限定存储区和写内部草稿的权限，没有在商机系统中报价、向客户门户提交、发送邮件或签署合同的权限。失败重试只针对没有外部副作用的解析和候选生成，并绑定防重复运行的标识；签署与任何未来外部动作都必须先查询权威状态。界面不是控制本身，身份权限、工具白名单和回执验证必须通过负面测试。

数据合同还规定原文件不由模型改写，候选项与人工决策分表保存，所有编辑保留执行前后和执行者；模型上下文只取本机会的当前批准文件，检索无结果返回状态未知。日志失败时运行不能进入待审核，防止“业务先做、以后补证”。保留和删除以原建议书请求义务为上限，项目团队不得因为未来可能训练而无限期保存整包客户材料。

第36—40天用最危险假设做原型，不追求把所有功能做完

团队先测文件集合、版本冲突、表格要求、原文位置和负责人未知，而不是生成一份流畅的封面。40个风险条款中，首个原型正确28项、遗漏5项、引用旧版本3项、原文位置错误2项、负责人错误2项；其中有2项严重遗漏，不能进入后台并行对照。修复清单门槛、版本过滤和表格解析器后，第二轮正确38项，2项保持状态未知，严重遗漏为0。

2个状态未知来自嵌套表格和引用另一附件的条款，人工可以安全定位，所以不强迫模型猜测。团队保留第一轮失败记录作为回归样本，不得只保存最终成功截图。若集成无法提供页码或单元格来源，项目就退回只做清单和负责人路由，而不是接受无法核验的生成答案。

原型评审使用“演示外测试”：提出人临时换一份结构相同但答案不同的材料，复核人要求重现运行、查看来源并手工触发缺件。第一轮的28/40不能因为画面流畅就进入后台对照，第二轮的38/40也不等于生产合格；它只证明最危险的技术假设值得继续收集无影响证据。原型代码若无法满足身份和日志要求可以丢弃，不能因为已经投入工时就带着技术债进入试点。

第41—48天进行24份后台并行对照：系统不能改变真实工作，只比较候选与人工最终状态

后台对照队列复制新到建议书请求中的已批准文件，分析师仍按旧流程完成；系统结果在分析师签署后才揭示，由独立复核人把候选结果与最终矩阵按同一评分标准比较。这样既避免用户被候选结果锚定，也不让未验收系统影响投标。24份案例共300项重大要求，首轮正确270项、能由人工路径纠正的模型缺陷21项、误报9项，三类合计300。

3项无效版本中包含一项严重缺陷，虽然后台对照没有外部影响，仍触发五日修复，不能用270/300=90%的平均分放行。后台对照还要测运行失败、解析时间、日志完整和队列需求。若人工参考答案在揭示结果后被发现错误，由两人裁决并更新数据集版本，不能为了维护模型分数而拒绝修正参考答案。

揭示结果前，锁定人工响应包与系统运行的时间戳，排除分析师偷看候选或模型读取最终矩阵；同一复核人不能同时标注参考答案、修改系统并签署表现结论。每个差异先判断输入集是否一致，再判断抽取与路由，避免把缺A2归咎于语言模型。后台对照的分母包含失败运行和人工回退，不能只统计成功解析的案例。用户反馈另存为可用性信号，不能代替要求级正确性。

第49—54天修失败链并重放冻结样本，禁止只改演示案例后直接上线

根因拆为清单缺失、版本排序、表格解析、类型定义、负责人映射和模型判断；每类选择最低层控制。A2缺失由清单阻止，旧版由版本策略排除，负责人由产品映射确定，语言歧义才交给AI生成候选。修改必须有变更记录、回归范围和回滚包。团队将24份后台并行案例与8份严重合成案例全部重放。

1个表格案例保持状态未知并手工解析，属于安全失败而非强行追到100%。回归不仅看原缺陷，也检查修复是否增加虚假暂停和周期。若版本注册表不可维护，项目应停止自动选择版本；不能把“请人工确认最新版”藏在长输出末尾。

变更按解析器、模型与上下文、规则、知识映射、身份和界面分类；每类预先对应回归子集，跨两层就运行完整关键套件。修复记录写明触发缺陷、预期机制、受影响案例、验证者和回滚点。若同一缺陷第二次出现，不能继续增加提示词例外，必须审查上游流程或组件负责人。第54天冻结试点版本，任何紧急更新都先回到后台对照，再进入受控队列。

第55—60天开放24份受控使用：限定用户、数据、动作、班次和每日停线检查

12名分析师分成两组，每组有一名当班复核人；只有数字版英文建议书请求、两个产品线、清单已完成的案例才能进入。系统先生成内部候选，分析师逐项决定，复核人在内部响应包签署前检查关键项、状态未知项和差异。任何外发、定价、法律接受与产品承诺工具都保持无权限；人工通道继续存在，并遵守同一处理时限。

受控24份含304项重大要求：291首轮正确，9项在签署前纠正，3项误暂停补证后恢复，1项状态未知转专家；291/304=95.72%，关键遗漏和未经授权外部动作均为0。试点不把“最终都被人改对”当模型全对，首轮、纠正、误报和未决分别报告。

每天16:30由运维核对已录入、就绪、已签署、转人工、暂停和未解决的案例分母；出现严重问题或尝试调用外部工具时立即停止新流量，证据缺口暂停对应案例，队列超过门槛就降低流量，而不是催复核人加快点击。用户可以拒绝系统并说明原因，不因接受率影响绩效。事件负责人在30分钟内确认遏制，业务负责人决定怎样沟通客户截止日期，构建者只负责修系统，不能单独宣布恢复。

第60天的第三次放行根据冻结试点版本、24份受控案例、失败清单、三次回退演练和未决状态未知，决定是否进入验收审核，而不是直接扩量。若严重问题不为零、日志不可复原或人工通道失效，就回到后台对照并修复；这次通过只授权独立验收复算，仍不授权新产品、新用户或新工具。

完整走例RFP-218：AI基于旧主文件给出可投建议，清单放行门槛用缺失A2把整条链停在影响之前

RFP-218在商机系统中的记录O-771列出基础文件第1版、A1、A2三项；批准存储区只有基础文件第1版与A1。基础文件第7.4条写“加拿大托管优先”，A1只修改了提交日期。若系统直接处理眼前可见的文件，AI会生成“满足偏好，可在路线图说明”，并路由给产品负责人，表面上有来源，看到的却不是完整事实。清单比较发现预期3份、实际2份，因此记录“缺失A2”，运行状态保留为“缺失文档”，所有候选项都标记为不可签署。

补齐A2后，需求不再是偏好而是资格条件；产品负责人不能用未来路线图冒充当前能力，销售也无权删掉。最终没有生成价格、承诺或门户提交。该案例证明来源引用不等于文件完整、人工复核不等于能发现看不见的附件；确定性清单和明确不投标授权共同阻断失败。

审计者可以从D-218反向重建：谁确认商机、何时发现预期与实际文件差异、A2从哪个门户和文件摘要进入、哪一版本产生R-18、产品能力依据什么注册表、谁有不投标权限。若只能看到最终“不投标”，却看不到被阻断的旧建议，组织就无法验证控制是否生效；若保留全部模型思考，却没有业务回执，同样无法证明决策。真正需要的是输入、规则、候选、人工决定和业务影响之间的最小可追溯链。

验收阶段第61—75天：独立复算质量、容量与成本，允许结论不是“上线”

第61—67天按同一冻结合同复算质量、周期、容量和恢复，不在汇报前挑好指标

团队由未参与开发的复核人对304项重新抽核，所有严重项全部检查，其余分层抽样；运行脚本记录数据集和系统版本。初稿291/304=95.72%通过，有效来源303/304=99.67%通过，1项状态未知，没有伪造来源。第90百分位周期从8.2天降到3.1天，低于3.5天门槛；复核队列的第90百分位等待时间为0.8天。三次人工回退均完成并对账。

周期改善不能证明AI单独造成，也不能抵消未来案例转移。验收同时列9次人工纠正、3次虚假暂停和1次状态未知；若把它们藏进“最终100%完成”，扩量后就无法预算专家与队列。验收包保留失败追踪、未覆盖范围、残余风险和下一次触发器。

304项不是无限精度保证。报告按产品、补充文件与复杂度展示分层结果，并为样本很小的分层写明“证据不足”；95.72%只保留到便于复算的两位，不推断未来真实率。保留评估集在正式验收前仍与开发隔离，独立复核人复现配置，而不是只接收截图。若环境、模型、解析器或知识映射与试点不同，验收结论不自动迁移，必须说明变更影响和所需回归。

第68—72天复算人工与总投入：每份少5.1小时，但90天项目仍是净投入而非即时投资回报率

旧流程人工处理时间为2.1+5.4+2.3+3.7+1.3=14.8小时。受控路径平均为清单和准备1.2小时、候选检查1.1小时、人工验证3.8小时、路由1.1小时、草稿和细化1.7小时、异常处理0.8小时，合计9.7小时，相差5.1小时。24份受控建议书请求的毛节省为122.4小时；项目发现、建设、标注、评估、治理和培训共投入310小时，所以90天净时间为122.4−310=−187.6小时。

这不等于项目失败，也不允许声称已经回本。后续是否值得取决于可持续案例量、维护成本、风险变化和机会价值，由E37的方法继续评估。第72天只确认容量模型：若每月18份合格且每份持续省5.1小时，毛释放91.8小时/月；还要扣运行复核、平台、变更和事件成本。

时间记录按角色和活动抽样，不能让AI候选生成的机器等待冒充人工节省，也不能漏掉复核人改错、维护注册表和处理暂停。24份受控量太小，91.8小时/月是按当前案例组合的条件推演，不是财务承诺。放行门槛 4同时查看现金支出、已投入不可回收成本与未来增量成本；过去投入不能成为继续扩大的唯一理由。

第73—75天举行第四次独立放行：四种合法结论是停止、延长、限量扩展和按证据扩展

会议材料提前两天冻结，业务负责人、运营、安全、产品、法务、构建者和独立复核人分别签署自己负责的条件。赞助人不能把“准时”设为额外的质量门槛。决策备忘录逐条回答目标是否达到、严重问题是否为0、证据是否可复原、人工容量是否真实、未覆盖什么，以及发生什么情况必须撤回。

本案例选择有限规模：两条队列、两个产品、英文数字文件、内部包；日流量上限从4份增到6份，但外发/报价工具仍禁。1项状态未知进入解析器积压，不阻塞当前安全范围；扫描件、非英语和新地区需要新基线/试点。会议还签30天复审日期，防“有限”悄悄变永久全量。

每个条件都绑定执行负责人：运营负责人守流量和队列，知识负责人守版本注册表，复核人守关键放行门槛，身份权限负责人守工具权限，业务负责人守范围与复审。决策备忘录若只写“团队持续监控”就退回。少数不影响当前范围的缺口可以成为有期限的条件，但任何人若想把扫描件或外发动作加入，都需要新决策，不得称作日常配置。

扩展阶段第76—90天：先准备运营能力，再逐批增加流量并完成交接

第76—82天先准备人员、队列、支持和成本，不把复制权限当扩展

扩展前用到达与服务时间计算容量。预计每月18份合格，平均每份9.7小时，其中复核人专属2.2小时，共39.6 复核人小时/月；两名复核人各预留24小时，合计48小时，表面余量8.4小时。团队再检查周峰值和休假，规定单人可用时降流量，不让队列以加班维持。

培训不是产品演示：分析师需处理缺附件、冲突版本、错误负责人和不支持的主张四个案例；严重全过后才获得分配。支持入口按案件 ID收集事实，不让用户在群聊粘客户文件。成本负责人记录工具、存储、复核、维护和训练，扩量若挤压投标主业则回退。

平均容量还要经过压力情境检验：若同一天到达5份材料，其中3份含补充文件，复核人所需时间可能由每份平均2.2小时累积到10.5小时；两人当日合计只有6小时，就必须延迟或分流到人工路径。计划记录每小时到达量、第90百分位服务时间、休假与截止日期，不能用每月平均8.4小时余量证明任何一天都安全。处理时限发生冲突时，由业务负责人缩小流量或调整客户计划，不能把跳过检查当作应急容量。

第83—87天采用分批流量和版本冻结：先25%、再50%，每一步都有回退与对账

第一批只接一条队列25%的合格流量，连续两天没有严重问题，且队列第90百分位等待时间不超过1天，才扩大到两条队列50%的流量；90天内不进入100%。每批都绑定系统版本、策略映射、产品目录和培训分配。变更窗口外不更新模型、解析器或提示词，避免验收完成后系统已经变化。

回退包含停止新路径、保留现有案例状态、导出已签矩阵、核对未签对象和通知负责人，不是只切功能标志。每次波结束做案例对账：进入多少、完成多少、人工多少、暂停多少、是否有孤儿案例。无法回答分母就不能扩下一批。

流量分配按合格商机预先随机或轮转，不能让经理把简单案例交给AI、复杂案例留给人工后再比较周期。临近客户截止日期的案例默认走人工，除非试点已经覆盖相同压力；这项排除要单独报告。第一批出现错误暂停时，先看客户截止日期是否受影响，再决定恢复或降低流量；即使没有错误外发，持续延误也可能使服务不可接受。

第88—90天完成运营交接：项目团队离场后仍有人监测、修复、暂停和退役

运营包包含服务负责人、业务负责人、系统负责人、值班人员、复核人名单、源注册表、数据集、仪表盘、变更路径、事件路由、人工回退、供应商与成本记录。交接用演练验收：模拟A2缺失、解析器不可用和错误版本三种情形，让当班人员实际暂停、切人工、查询回执并恢复；只阅读文档不算通过。

若负责人离岗、复核人容量低于门槛、关键集未运行、日志无法复原或供应商条件改变，系统就自动缩回人工路径或暂停。90天结束不能取消退出机制；反而从这一天起，系统才开始产生真实的运行债务。E40会专门讨论退役，本篇至少要求明确谁可以暂停，以及怎样保存案例最终状态。

交接验收还检查新值班人员在不求助项目建设者时能否找到仪表盘、解释一个状态未知、查询供应商状态和完成案例对账。服务级目标包含证据完整、队列和恢复，不只看可用率；模型接口在线但源注册表过期时服务仍不可用。项目成员离场前关闭临时账号与调试数据，未关闭事项进入有负责人和日期的运营积压，不能留在私人笔记。

第90天放行门槛 5由业务与运营共同签有限规模并运营，附带两队列、两个产品、50%上限和30天复审；若交接演练或容量未通过，则即使放行门槛 4质量通过也只能扩展试点。五次放行门槛分别决定是否投入下一类证据，不是五个只会签“继续”的汇报会。

最终交付不是一张路线图，而是一套五次可审计决定和一份第91天仍能运行的部门能力包

五阶段的关系不是瀑布：发现可能回到问题定义，基线会暴露流程缺陷，试点会修改控制，验收可能要求延长，扩展也能回退。但每次迭代必须保留版本、理由和旧结果，不能用“敏捷”解释无范围、无负责人和无验收。NIST的治理、映射、衡量、管理是持续风险管理功能，不是本文90天的顺序清单；GOV.UK的发现、原型和测试阶段也不是企业AI的官方固定日程。

来源边界：GOV.UK 发现指导支持在建设前理解问题、用户、约束、当前成本与是否继续，并明确发现不应开始建服务；阿尔法（测试版）指导支持用最小原型检验最高风险假设，而非完成全部功能；测试版指导支持先让有限用户使用、收集真实数据、保留旧服务并确认团队/支持容量。NIST AI RMF Core用于持续治理/映射/衡量/管理、部署前和运行中测试、独立复核、通过/不通过及资源/非AI替代；NIST 剧本只作为可选建议库。ISO/IEC 42001官方概览只支持建立、实施、维护和持续改进AI管理体系的背景。本文90天、样本、阈值、阶段名和公司数据均为教学设计，不代表这些来源规定的统一方法或认证要求。来源核验于2026-07-22；NIST页面注明AI RMF 1.0正在修订。

• GOV.UK Service Manual：How the discovery phase works
• GOV.UK Service Manual：How the alpha phase works
• GOV.UK Service Manual：How the beta phase works
• NIST AI RMF Core
• NIST AI RMF Playbook
• ISO/IEC 42001:2023：AI Management Systems

今天不要先安排90天上线庆功会。选一个部门中的单一业务最终状态，签出谁拥有结果、哪些外部动作绝不在范围、六份实际案例从哪里开始到哪里结束；在第一次演示前写下第15、30、60、75和90天分别需要什么证据，以及任何一项不满足时谁能说停。只有当日历上的里程碑都对应一份可复原的决策，90天才是在降低未知，而不是把未知推迟到生产。