一个"自动生成周报"的工具，把数据汇总成结论发给管理层。某周它把"环比上升"写成了"同比下降"（字段取错），而没有人复核——因为"它是自动化流程的一部分"。事后复盘的第一句是"谁该看这份报告"，而答案没人知道。
AI 输出的"责任问题"不是伦理问题，而是流程问题：这份输出"进入决策链"的那一刻，谁读过、谁签过、错了谁修。这个"没人签"的根源是"分工"："谁做的"与"谁用的"分离——做的人以为"用的人会看"，用的人以为"系统算的没错"，于是"两边都不看"。
而"没人签"的自动化输出，是风险最高的一类。
1. 三种"输出用途"与签字要求
| 用途 | 签字要求 |
|---|---|
| 参考（自己看） | 无 |
| 对外发布（客户/公众） | 有人审 |
| 进入决策（预算/人事/合规） | 有人签 + 可追溯 |
第三项是"最高风险"：它的错误会被"当成事实"用于决定第三项的"时间差"很致命：错误在"决策之后"才被发现，而"依据它的动作"已经执行——于是"改数据"救不了"已经发出去的调薪通知"。
——而"事后发现"往往已经"按错的结论执行了"。
"谁在等这份输出"要能"答得出来"，否则签字无从谈起:
// 三步确认"输出的下游"
1 它在"谁的日程"里（谁的邮箱/看板/会议材料）
2 有没有"系统"直接消费它（API/表/消息）
3 错误会"多久"被发现（当天 / 一周 / 从不）
// 判据：第 3 项答"从不" → 它就是"没人签"的高风险输出
2. "没人签"的三种形态
| 形态 | 表现 |
|---|---|
| 定时任务直发 | 无人看，直接进邮箱 |
| 仪表盘默认可信 | 没人问"这个数怎么算的" |
| 下游系统直接消费 | 错误被"系统放大" |
第三项的"放大"很具体："结论错"被"下游"拆成"十条动作"——而每条动作都"有依据"（依据是那个错的结论），于是"追责"变成"追到一条源头"。
第三项最危险："AI 输出"被"另一个系统"当输入——于是"一个字段错"变成"一批动作错"。
"断言"的写法要"贴业务"，而不是"贴技术":
-- 三条"业务断言"（每次生成后跑）
1 分组求和 = 总计 -- 漏行/去重错
2 本期的"方向"与原始数据一致 -- 取错字段
3 关键指标在"历史区间"内（±30%） -- 量级错/单位错
-- 判据：任一条失败 → 阻断"发送"，并"回滚到'待人工'"
3. "签字"的三种轻量实现
| 实现 | 成本 |
|---|---|
| 人工确认（点一下） | 低（但会疲劳） |
| 抽样复核（每天 N 条） | 中（可持续） |
| 断言校验（程序校验关键结论） | 最低（自动） |
第三项是"最划算"的：把"关键结论"写成"可校验的断言"第三项的"前提"是"结论可结构化"："同比上升 3%"能被校验，"整体向好"不能——于是"能写成断言的"就自动校验，"写不成的"就留给人。
——如"总数 = 分组之和"、"环比方向与原始数据一致"——于是"程序每次签字"。
4. "该签什么"的三级
| 级 | 内容 |
|---|---|
| 数据级 | 数字对不对（求和/单位/口径） |
| 结论级 | 方向与因果对不对 |
| 建议级 | 该不该这么做 |
这个"多数事故"值得强调：人们以为"AI 的错是'判断错'"，而实际多数是"取错字段、算错汇总"——它们恰好是"最容易被自动校验"的那一类。
第一级"完全可自动化"，第三级"只能人签"——而多数事故出在"第一级没自动校验"。
// 三条"数据级"断言（每条一次查询/一次比较）
1 分组之和 = 总计（漏行会不等）
2 环比方向 = 原始数据的方向（取错字段会反）
3 单位与量级在"合理区间"（漏乘 100 会离谱）
// 判据：三条都过，才允许"进入下游"
"人签"要"轻"，否则"签"会退化成"点一下过":
// 三种"轻签字"（按成本）
1 只签"异常项"（断言失败的，或与上期差异 > 20% 的）
2 抽签（每天 5 条，随机）
3 全签（只在"高后果"场景，且"一天一次"）
// 判据：签字量"一天超过 10 条"时，签就"不会真的读"
5. "可追溯"的三种要素
| 要素 | 作用 |
|---|---|
| 输入（数据快照） | 复现 |
| 生成参数（提示/模型版本） | 复现 |
| 签字人/时间 | 责任 |
第二项常被漏："同一份数据、不同模型版本"会产出不同结论第二项的"实践"是"把提示与模型版本写进输出"（如页脚一行"生成于 2026-11-10，model-x v2"）——于是"半年后复现"有据可依。
——而"没记录版本"就"没法复现"。
"下游污染"要用"一道门槛"挡住，而不是"约定":
// 三种"门槛"（从弱到强）
1 约定："下游自己校验"
2 标记：输出带 "verified: true/false"，下游"只消费 true"
3 隔离：未签字的输出"进另一个队列"，下游"不订阅"
// 判据：下游"是否有能力"校验——没有就必须用 3
6. 排错：五种"AI 输出责任问题"
| 现象 | 成因 | 处理方向 |
|---|---|---|
| 数错了没人发现 | 无数据级校验 | 加断言 |
| 结论错了被采纳 | 无人工签 | 加确认 |
| 无法复现 | 无输入快照 | 存快照 |
| 追责找不到人 | 无签字记录 | 加签字 |
| 下游被污染 | 直连消费 | 加"校验门槛" |
7. 边界：什么情况"不签"可以接受
| 场景 | 为什么 | 做法 |
|---|---|---|
| 内部探索（自己看） | 不进决策 | 不签 |
| 草稿（待人工改写） | 有人在后面改 | 不签（但要标"草稿"） |
| 低后果（摘要、提醒） | 错了无成本 | 不签 |
| 有"下游强校验" | 会被拦 | 不签 |
最后一条与"标注"有关的边界："AI 生成"这件事要在"输出上"可见：页脚一行字，成本为零——而"不标注"会让"读者"默认它"是人工写的"，于是"信任"被错误地给到"系统"。
判断口径一句话："这份输出的错误，会不会"改变某人的决定"。会（预算、人事、合规、对外发布），必须有"数据级断言 + 人签 + 可追溯"；不会（摘要、探索），标一句"AI 生成，供参考"即可。
最后补一个"组织"现实："签字"这件事只有在"有人真的会看"时才有意义——如果签字人"一天要签三十份"，那签字就等于"盖章"。所以"签字流程"的设计目标是"让"需要看的"被看到"，而不是"让所有人都签一遍"：断言替人挡掉 80%，人只看剩下的 20%。而"剩下 20%"里，"与上期差异最大"的那几条应当优先。
还有一个"文化"细节值得说："AI 生成"的标注不该写成"甩责任式"的一行小字，而该"写清它经过了什么"——"数据已校验（3 项断言通过）、结论由张三复核于 11-10"。这句话既"给了读者信任的依据"，也"明确了责任链"；而"仅供看看、请自行判断"这类写法，等于"把风险推给读者"，而读者通常没有能力判断。
而"写清经过"，比"提醒风险"更有用。
这也是"自动化输出"能被"放心使用"的唯一路径：先让它可校验，再谈它可信。
而"可校验"的第一步，永远是"把结论写成能被程序检查的形状"。
8. 自测
- 三种"输出用途"分别要求什么签字？为什么"进入决策"风险最高？
- "没人签"的三种形态里，哪一种最危险？为什么"一个字段错"会变成"一批动作错"？
- "断言校验"为什么"最划算"？它签字的是哪一级？
- "数据级/结论级/建议级"里，哪一级"完全可自动化"？多数事故出在哪一级没做？
- "可追溯"的三个要素里，哪一个常被漏？为什么它会"没法复现"？
- 判断"能不能不签"的那个问题是什么？