核心问题

当系统判断错了，人如何重新进入回路？

自动化系统会做很多判断：

  • 封禁账号
  • 下架课程
  • 拒绝提现
  • 拒绝退款
  • 标记作弊
  • 拦截支付
  • 限制访问
  • 关闭评论

这些判断可能是对的，也可能是错的。

如果系统没有申诉和人工介入路径，那么错误判断就会变成不可挑战的权力。

核心句：

自动化越强，纠错路径越重要。

Human Override 不是反自动化

人类介入不是要否定自动化。

它的目标是：

在高影响、低确定性、强争议场景里，给系统保留纠错能力。

例如垃圾评论检测可以自动隐藏。

但永久封号、拒绝大额提现、下架核心课程，就不应该完全没有人工复核。

可以按影响分层：

低影响：自动决定
中影响：自动决定 + 可申诉
高影响：自动初筛 + 人工复核
极高影响：人工批准 + 系统辅助

重点不是“人还是机器”，而是：

决策影响越大，越需要纠错和责任机制。

Appeal：申诉不是客服备注

很多系统所谓申诉，只是：

联系客服。

这不够。

一个真实申诉系统应该有结构：

type Appeal = {
  id: string
  subjectId: string
  decisionId: string
  status: "submitted" | "under_review" | "approved" | "rejected"
  userStatement: string
  evidenceAttachments: string[]
  reviewerId?: string
  reviewerNotes?: string
  submittedAt: Date
  resolvedAt?: Date
}

它需要回答：

  • 申诉的是哪个决定？
  • 用户提供了什么材料？
  • 谁复核？
  • 复核状态是什么？
  • 结果是什么？
  • 为什么维持或撤销原决定？

申诉应该绑定原始 decision record，而不是飘在客服聊天里。

申诉需要 SLA

没有时间承诺的申诉，用户仍然处于无助状态。

例如：

账号封禁申诉：72 小时内回复。
提现拒绝申诉：2 个工作日内处理。
课程下架申诉：5 个工作日内给出结果。

SLA 不是形式主义。

它表达：

系统承认这个决定影响了用户，并承诺在合理时间内复查。

Reviewer 需要上下文

人工复核不能只给 reviewer 一个按钮：

[通过] [拒绝]

Reviewer 需要看到证据链：

  • 原始 decision record
  • reason codes
  • policy version
  • 用户历史
  • 风险信号
  • 用户申诉材料
  • 相关日志
  • 之前类似案例

否则人工复核只是另一种随机判断。

好的审核界面应该帮助人做更一致、更可追溯的决定。

Override 必须可审计

人工 override 风险很高。

例如：

  • 手动解封账号
  • 手动放行提现
  • 手动恢复课程
  • 手动发放访问权
  • 手动撤销风控标记

这些操作必须留下审计：

type OverrideRecord = {
  id: string
  decisionId: string
  actorId: string
  action: "approve_appeal" | "reject_appeal" | "manual_override"
  reason: string
  before: unknown
  after: unknown
  occurredAt: Date
}

原则：

人类介入不是绕过系统，而是系统承认并记录的一种路径。

避免 Rubber Stamp

人工复核容易退化成橡皮图章。

表现：

  • reviewer 只看模型分数
  • 默认相信系统
  • 没有时间认真看材料
  • KPI 只看处理量
  • 缺少抽检
  • 没有复核质量反馈

如果人工只是机械确认系统结论，就没有真正纠错。

需要：

  • 审核指南
  • 质量抽检
  • 争议升级
  • 复核一致性检查
  • reviewer training
  • 不只考核处理速度

用户应该知道可以申诉

有申诉系统但用户找不到，也等于没有。

当系统做出高影响决定时，应该告诉用户：

  • 发生了什么
  • 大致原因是什么
  • 是否可以申诉
  • 如何申诉
  • 需要提供什么材料
  • 预计多久处理

例如：

你的课程因版权风险被暂时下架。
如果你认为这是误判，可以在 5 个工作日内提交版权授权材料申请复核。
我们会在 3 个工作日内给出结果。

比：

课程违规，已下架。

更尊重用户。

Human Override 检查清单

设计自动决策时问：

  1. 这个决定影响用户多大？
  2. 是否可能误判？
  3. 用户能否知道大致原因？
  4. 是否提供申诉入口？
  5. 申诉是否绑定原始 decision record？
  6. 是否有 SLA？
  7. reviewer 是否有足够上下文？
  8. 人工 override 是否可审计？
  9. 是否有质量抽检，避免 rubber stamp？
  10. 是否能从申诉结果反哺规则和模型？

小结

  1. 自动化越强，纠错路径越重要。
  2. Human override 不是反自动化，而是高影响系统里的责任机制。
  3. 申诉应该绑定原始 decision record。
  4. 没有 SLA 的申诉会让用户继续无助。
  5. Reviewer 需要证据链，不只是通过/拒绝按钮。
  6. 人工 override 必须可审计。
  7. 人工复核要避免变成橡皮图章。
  8. 用户应该知道自己能否申诉，以及如何申诉。