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