AI 做完不等于任务完成：建立可回读的证据链

直接判断：AI 生成了文件、调用成功或页面出现提示，都不能单独证明业务状态已改变；完成必须由目标系统的回读证据支持。

独立站工作里最危险的词之一是“已完成”。本地脚本成功，不代表 Feed 已上传；上传成功，不代表 Merchant 端已处理；主题代码修改，不代表预览正确；预览正确，更不代表已经发布。证据链的作用，就是把这些中间状态拆开，防止语言提前越过事实。

先做判断

可靠链路可以概括为：输入快照 → 计划与差异 → 人工批准 → 显式应用 → 目标系统回读 → 结果评估 → 经验沉淀。并非每个低风险任务都需要人工批准，但任何任务都需要输入和结果两端的可比证据。

证据不是截图越多越好。最有效的证据应直接支持要声称的结论，并包含对象、时间、环境和状态。无法关联到结论的日志只是噪声。

诊断与决策框架

第一层是身份与环境证据。当前操作的是哪个环境、哪个店铺类型、草稿还是生产、什么时间的快照？不要公开真实账号信息，但内部执行必须能唯一确认目标。

第二层是输入证据。记录真源版本、查询条件、对象数量与关键字段摘要。后续若结果变化，才能判断是 AI 改动还是源数据已经更新。

第三层是变更证据。预览应显示新增、修改、跳过和冲突，且能定位每项改动的理由。只有最终文件而没有 diff，很难发现范围外变化。

第四层是授权证据。人工批准应对应同一份预览；预览后来变化，就需要重新确认。批准一个小样本不等于批准全量，也不等于批准发布。

第五层是应用与回读。应用日志只说明请求发出，回读才说明目标系统当前状态。回读应使用独立查询或页面重新加载，不能复述刚提交的请求体。

第六层是业务评估。状态正确不等于效果正确。Feed 字段同步后还需观察处理状态；页面上线后还需做关键路径 QA；运营建议执行后还需在预先约定窗口评估。

最后沉淀 lesson：哪些判断被证实、哪些被人工否决、哪些证据不足。沉淀的是规则和失败模式，不是客户数据或完整运行日志。

常见误判

• HTTP 成功码等于业务成功。请求可能被异步处理、部分接受或随后拒绝。
• 有截图就算有证据。截图若没有对象、时间和环境，仍可能无法证明结论。
• 预览批准后脚本又重新生成内容，却沿用旧批准。
• 把“本地已验证”“已上传”“已发布”“线上已回读”压缩成一个“已修复”。

验证清单

• 每个完成声明都能指向一个直接证据。
• 输入与回读包含对象、环境、时间和可比字段。
• diff 与批准绑定同一版本，范围变化会重新触发闸门。
• 应用和回读使用不同步骤，避免自证循环。
• 局部失败、跳过和异步处理中状态被明确保留。
• 沉淀内容去除账号、客户和可反推业务数据。

适用边界

证据链适合所有跨系统与高影响 AI 任务。低风险本地草稿可缩减授权环节，但不能把草稿状态写成线上结果。涉及个人数据时，应只保留最小必要摘要，并按组织的保存与访问规则处理。

先用 任务契约 定义证明目标，再用 AI 失败检测与复盘剧本 检查证据链在哪一步断裂。