AI 更换模型或提示词后，先核对哪几类输出？

先说明这次改动会影响什么

更新企业知识资料时，应单独核对来源版本和引用结果；本文聚焦模型、系统提示词、解析配置或工具版本的调整。原来的演示仍能运行，不代表这些配置变化后，结构化字段、限制表达、拒答方式或人工交接都仍符合任务需要。验收不是证明“新版本一定更好”，而是记录哪些行为改变、哪些关键任务仍可接受，以及出现问题时如何退回。

把变更拆开记录：改了哪个组件，为什么要改，影响哪些任务、输入类型、工具和用户；哪些行为预期保持一致，哪些行为允许变化。若同时更换模型、改写提示词并调整数据源，测试结果难以说明是哪项改变造成。能拆开验证时，一次先改一项；必须组合变更时，记录组合及其边界。

先确定通过标准，再挑代表任务

每个工作流都应有自己的验收条件。对一项只给内部人员参考的摘要，关注信息是否完整、遗漏是否可见、来源能否追溯；若结果会被写入业务系统，则还要检查字段、状态、权限和重复执行风险。不要把“读起来更自然”当成唯一标准，也不要照搬别的流程的分数线。

从已获准的任务记录中抽取一组代表样本：正常任务、缺资料任务、输入矛盾任务、少见但重要的异常任务。样本数量和覆盖面应由业务风险和实际任务频率决定。若没有可靠的历史样本，可先用经业务负责人确认的合成场景补齐，但要把它标成测试样例，不能说成真实客户数据。

在测试前写出逐项检查表。例如：关键事实是否有来源；缺失信息是否明确标未知；不应回答的内容是否停止；必需字段是否符合约定；人工接手时能否看懂上下文；下游动作是否在批准前没有发生。每项都应有可以复核的“通过/未通过/不适用”依据，避免测试者只凭整体印象给分。

用旧版本做可比的对照

尽可能让旧配置和新配置处理相同样本，并固定输入、工具权限、参考资料版本和人工评分标准。把结果并排看，记录事实正确性、遗漏、格式偏差、人工修改和异常转交。不要只挑新版本表现好的例子，也不要删掉失败记录。若某些旧任务因新流程设计而不再适用，明确写出排除原因。

可以用一张表管理结果：

表中不需要复制客户敏感文本。可使用任务编号、字段名和必要的摘要，受限数据按组织批准的测试方式处理。若测试人员不能查看原始资料，应确认评价所需依据如何由有权限的人提供。

如何定是否接受变更

先列不可退让的硬条件。例如，不能把未知值补成确定事实，不能把未授权资料传给不该访问的人，不能让未审查的外发动作自动执行。这些条件不应被平均分数抵消。其余质量变化由业务负责人按任务风险决定：新版本是否减少某类错误，是否带来另一种人工负担，是否影响需要稳定格式的下游系统。

若重要样本失败，暂停扩大使用范围，查明是模型变化、提示词、资料版本还是输入条件导致。可以调整后再测，但要保留原始失败样本，避免反复修改到“恰好通过”却没有覆盖其他场景。暂时无法解释的回归不应被包装成无影响。

评估时把问题按影响分级，而不是只做一个总分。比如“表格少了一个非关键备注”和“把不确定的型号写成已确认”，后果不同；同样一次人工修改，也可能是偏好句式，也可能是纠正事实。由业务负责人预先界定哪些错误必须立即停止、哪些可以修订后继续、哪些只需观察，避免测试完了才临时解释通过门槛。

如果新旧配置的输出差异很大，可以逐项检查输入是否一致、资料版本是否相同、工具权限是否变了、评分者是否按同一标准判断。样本不够代表真实使用时，不要通过降低门槛来“通过”。应记录还缺哪些任务类型，补充获准样本后复测，或先把适用范围缩小到已验证的部分。

对于无法在短期样本里检出的低频高影响问题，可预先设置上线后的观察责任人和停止触发条件。观察期需要与实际任务频率相匹配：任务很少时，短时间内没有异常并不能说明稳定；若影响持续扩大，也不应等到固定周期结束才处理。具体观察窗口由团队依据业务节奏确定，本文不设统一天数。

还可以将变更记录分成“已验证、待观察、暂不适用”三种状态，并给每种状态写明依据。已验证只覆盖记录中的样本与场景；待观察表示需要在实际任务中继续收集证据；暂不适用则应说明为什么该流程当前没有相应动作。状态标签不能替代证据本身，最好附上样本版本、检查日期、复核人和问题链接。这样交接给另一个团队时，对方能理解结论来自哪里，也能知道哪些内容尚未经过验证。若后续任务或资料结构发生变化，应回到影响分析阶段重看覆盖范围，而不是沿用旧状态。

发布决策记录需要包括变更范围、样本集版本、对比结果、未解决风险、批准人、观察窗口、回退方式。小范围试行只代表该范围仍处于观察中，不表示全量可用。若新配置需要更强人工复核，也要提前安排责任和容量；否则技术改动可能把负担转移给业务人员。

维护和复核边界

NIST AI RMF 1.0 把 AI 风险管理组织为 Govern、Map、Measure、Manage 四个函数，可作为团队讨论责任、场景、评估与处置的通用框架；它不是具体工作流的验收清单，也不证明某个方案已满足所有组织或行业要求。本文的样本、对比和回退步骤是编辑建议，应由实际业务负责人按任务后果制定。

如果版本更新不会改变对外输出、权限、字段或业务动作，仍应保留最小变更记录；若触及高影响判断、外部发送、客户信息或自动写入，就应提高人工确认级别。没有足够依据时，维持旧配置或缩小试点范围往往比匆忙放量更容易控制问题。

发布前核对表

NIST AI RMF 1.0 将风险管理组织为 Govern、Map、Measure、Manage 四个函数，可帮助团队讨论责任、使用情境、评估与处置；它并未替每个企业规定固定样本量或发布阈值。本文按这个通用视角整理变更清单，不把它误作认证、合规结论或模型质量背书。真正的验收口径仍需由工作流业务负责人按任务影响决定。

若更新会改变模型服务提供方、数据流转位置、账户权限或外部依赖，还应由相应负责人确认组织政策是否允许该变化。本文不假设这些变化发生，也不提供法律结论。将产品版本、流程配置和业务授权放在同一张变更记录里，可以避免技术人员只确认代码版本，却没人确认资料和责任边界。

观察期结束后再复核一遍线上实际任务，不只看预先准备的样本。记录有哪些任务被人工退回、哪些结果需要改写、是否出现原测试没覆盖的异常。即使没有观察到问题，也只能说“在这个范围和时间内没有记录到”，不要写成“没有风险”。后续如果输入类别或业务规则变化，应重新决定哪些样本需要回归。

变更回归的目标是让决策有证据，而不是在新旧版本之间制造一个看起来精确的总分。把保留什么、改变什么和仍未知什么讲清楚，团队才能决定该接受、继续试验还是回退。

相关内容：知识资料更新后怎样做回归检查专门讨论参考资料发生变化的情形；本文聚焦模型或提示配置变化。

• 变更原因、范围和预期保持项是否清楚？
• 是否有固定版本、获准的代表样本和可复核评分条件？
• 是否测试常规、缺资料、冲突和边界任务？
• 是否分别检查输出、人工返工、下游动作与异常转交？
• 不可接受的失败条件是否能阻止上线？
• 是否指定批准人、观察期和回退责任？
• 测试材料是否满足团队数据权限规则？