OpenClaw 工作流改完以后，很多团队会做一次功能测试：能不能启动，工具能不能调通，最后有没有生成结果。但生产里的麻烦往往不在正常样本，而在旧事故、边界问题和人工曾经退回的样本里。
回放验收就是在上线前，把这些旧样本重新跑一遍。它接在 失败回放样本库、质量门禁 和 工具版本锁定 后面，用真实问题检查新版本是否更稳。
样本要来自真实失败
回放样本不要只靠测试人员临时编。更有价值的是旧事故、低置信度请求、人工退回记录、工具超时记录、客户投诉和格式校验失败。它们暴露过真实弱点，更能说明新版本有没有修好问题。
每个样本至少要保留输入、期望结果、当时失败原因、涉及工具、是否人工确认和最终处理动作。没有这些字段，回放时很难判断新结果到底算不算通过。
验收标准要提前写清
回放不是看“感觉好一点”。上线前要先写验收标准：答案是否引用正确来源，工具路径是否符合预期，是否触发该触发的人工确认，成本是否没有异常增加，外部写入是否被正确拦住。
如果只看最终文本流畅度，很多风险会被掩盖。尤其是涉及数据导出、客户回复和权限修改的流程，工具路径和确认节点比文案顺不顺更重要。
通过率要分层看
不是所有样本都同等重要。低风险问答可以接受少量格式调整，高风险写入样本必须严格通过。建议把样本分成普通、重要、高风险三层，不同层级对应不同通过标准。
这和 事故分级 的思路一致。样本来自不同风险等级，验收时也不能只算一个平均分。
不通过要有动作
回放不通过时，动作应该很明确：暂停发布、缩小灰度、补知识库、收紧权限、回滚工具版本，或者增加人工确认。最怕的是看到失败样本以后只记一句“后续优化”。
如果改动发生在关键业务期，还要结合 变更冻结窗口 判断是否延后发布。上线节奏不应该压过验收结论。
总结
OpenClaw 回放验收的价值，是把旧事故、人工退回、低置信度和工具失败样本放到发布前。新版本能通过真实失败样本，才更值得进入生产；通不过，就应该先修再发。
