模型更新的迁移清单

AI 类产品类目记录把模型能力落到真实工作流时需要的约束、评测和回退。当前工程资料没有上线 AI 产品的用户量、准确率或成本数据，文章不把假设写成结果。

先把问题变成可观察动作

同时检查提示、输出结构、拒答行为和人工复核点。 先写清输入条件、动作顺序、输出结果和异常分支，再决定是否进入下一轮。这样可以把“感觉应该更好”拆成复现任务，也能在结果不理想时回到上一个版本。文章不把示例步骤当作已经执行过的实验。

建议的验证路径

1. 建立基线：保存当前版本、设备/页面状态和一条能够重复的操作路径。
2. 只改一个主变量：例如只改配列、采样窗口、站位、提示版本或 CSS token，其他条件保持不变。
3. 记录异常：把失败、需要人工复核、无法复现和回退动作分开写，不用“基本正常”代替证据。
4. 复盘决定：保留、继续观察或撤回都写明原因；没有测到的字段标为“待补”。

交付字段

建议至少保存：样本 ID、提示/模型版本、脱敏规则、输出快照、成本和失败类别。 交付物“模型更新的迁移清单”应带建议排期对应的版本、来源和脱敏说明；尚未产生的文件写成待补，不用示例数据冒充实测。

边界与下一步

没有固定样本和实测运行记录时，不写准确率、用户量、节省时间或模型收益。 下一步只选一个最小动作：画一张图、跑一次固定流程、拍一张对照照片，或补齐一个字段。完成后再决定是否扩大范围。suggested_publish_at 是排期建议，不是项目完成时间；真实发布时应以实际写作与核对日期为准。

类目复核口径

评测要固定样本、提示/模型版本、允许访问的数据和人工复核点。无法复现的回答、价格变化和模型升级都应单独标记，避免把示例输出当成产品指标。 本篇“模型更新的迁移清单”的下一步仍应以真实记录为准。