"可审核"意味着两件事
AI 输出被用于业务决策时（写库、发信、审批 ✔），必须可审核 ✔。可审核有两层含义 ✗→✔：
- 可追溯（这条输出来自哪次调用、什么版本、依据什么资料 ✔）；
- 可证明未被篡改（事后有人改过结果吗 ✔）。
第二层常被忽略 ✗，但在合规与追责场景很关键 ✔。
一、可追溯：把"证据"固定下来
每条需要审核的输出，至少记录 ✔：
call_id（唯一 ✔）｜ ts ｜ 操作者/系统（谁触发的 ✔）
model + prompt_version + index_version（见可复现那篇 ✔）
输入摘要（hash + 截断 ✔）｜ 输出原文（或对象存储引用 ✔）
检索片段 id 列表（依据什么 ✔）｜ 校验结果（通过/拒绝原因 ✔）
后续动作（谁审的、改了什么、最终落库值 ✔）
要点："后续动作"要并入同一条记录 ✗ ✔ ——
否则"AI 输出"与"人工修改"是两条孤立的日志 ✔，无法回答"最终落库的是什么" ✔。
二、防篡改：最低成本的三种做法
| 做法 | 说明 | 成本 |
|---|---|---|
| 追加写 + 只读存储 | 日志只增不改 ✔ | 低 ✔ |
| 链式哈希（每条含上一条哈希 ✔） | 改动会被发现 ✔ | 中 ✔ |
| 定期摘要 + 外部留存（每日哈希对外备份 ✔） | 防内部整体改写 ✔ | 中 ✔ |
建议：至少做到第一条 ✔；涉及资金/合同的场景加第二条 ✔。
三、审核留痕的四个字段
- 审核人（人或系统 ✔）；
- 审核时间（UTC ✔）；
- 审核动作（通过 / 修改 / 拒绝 ✔）；
- 修改内容（diff ✔ —— 见草稿编辑那篇 ✔）。
忌讳：只记"已审核" ✗（无法知道改了什么 ✔）。
四、三个常见坑
- 只存最终值 ✗（丢掉了"AI 给的是什么、人改了什么" ✔）；
- 日志可被覆盖 ✗（等于没有证据 ✔）；
- 审核记录与业务记录不同步 ✗（对不上账 ✔）。
五、一条判据
抽一条已落库的记录 ✔，你能否还原"AI 原样输出什么、谁改的、改成什么、依据是什么" ✔？
不能，说明输出还不可审核 ✗。