重新提问得到新答案，不代表问题已经复现
昨天 AI 给出的合同摘要漏了一条条件，今天团队用同样的文字再问，结果却正常了。资料可能已经更新，模型版本可能变化，接口返回也可能不同。若没有保存当时的输入和环境，团队无法判断昨天是偶发问题，还是系统在某个条件下必然会出错。
只保留最终答案也不够。排查需要知道它当时看到了哪份资料、用了哪套规则、调用了什么工具、员工改过什么以及最后执行了什么动作。重放不是复制一段对话，而是尽量还原一次任务的关键事实。
重放记录要保存最小但关键的事实
每条高风险或代表性任务可以保存任务编号、输入摘要、资料和规则版本、模型及工具状态、输出、人工修改、审批和最终结果。客户敏感内容按权限脱敏，普通任务不必永久保存完整原文，但要保证授权人员能够知道当时流程使用了什么。
测试样本还要标注预期结果和允许的差异。格式稍有不同不一定是错误，漏掉合同条件或把待确认内容写成事实就属于高风险问题。预期写清楚，回放时才不会只凭人的印象争论结果好不好。
- 记录任务输入、资料版本、规则、工具和最终动作。
- 保存人工修改、审批和转人工等关键节点。
- 为样本写明预期结果、允许差异和必须拦截的错误。
重放要覆盖正常路径和被打断的路径
正常任务是基础，但更有价值的是异常路径：资料缺失、工具超时、审批退回、客户改变条件、权限不足和流程中途转人工。每一种情况都要观察任务是否停在正确状态，重试是否会重复动作，恢复后是否会把旧信息带回来。
重放也可以用于版本对比。保持输入和测试条件不变，只替换一份资料或一条规则，比较结果变化并记录原因。这样企业能知道改动影响了什么，避免每次升级都把所有变化归因于模型。
业务人员要参与重放判断
技术团队可以还原请求、接口和日志，但业务人员更清楚结果是否符合岗位实际。一个字段看似格式正确，可能代表了错误的客户状态；一条提示看似礼貌，可能形成了不该有的承诺。重放时让业务和技术一起看，才能把系统事实和业务后果连起来。
重放结果要沉淀成简短问题说明：发生了什么、影响是什么、根因在哪一层、临时如何处理、修复后用什么样本验证。不要只把日志留在技术人员电脑里，后续接手人也需要能读懂。
验收要让团队在几分钟内还原一条任务
验收时随机选择一条已完成任务和一条错误任务，要求团队从记录中说清输入、资料、规则、工具、人工判断和最终动作。若只能看到最后答案，或者只有开发人员能解释，说明重放能力还没有成为交付成果。
上线后按风险保留重放样本，重大版本变化前后回放关键任务。企业不需要追求保存所有内容，而要让真正影响客户、合同、付款和品牌的流程有足够证据。可重放，才有机会快速修复和稳妥扩展。
要点总结
- 不必。代表性、高风险和异常任务应优先保留足够的输入、版本和动作记录。
- 按风险脱敏和限制权限，普通任务保留必要元数据，高风险任务按要求保留证据。
- 不算。还要尽量还原当时的资料、规则、工具状态和人工动作。
参考来源说明
本文围绕“企业 AI 工作流上线前要能重放：否则出了问题只能重新提问”展开，结合 5 份公开资料及一路凯歌在“企业 AI 服务”方向的执行经验整理，重点看它对官网可引用结构、FAQ 设计和后续获客复盘的影响。