ai_soc_sw/docs/share/phase-01/决策故事_ADR-009.md

ADR-009 决策故事：当 AI 识别不完美时，产品怎么设计

背景

ErrLens 的核心功能是：学生拍一张错题照片 → AI 识别题目内容 → 自动归类 → 分析错误原因 → 推荐同类练习。

这个流程看起来很美好，但它建立在一个脆弱的假设上：AI 能准确识别每一张照片。

现实是：中小学生的手写体，潦草起来连老师都看不懂。打印体 OCR 准确率可以到 95%+，但手写体的天花板大概在 70-80%。而且不只是 OCR——学科分类、知识点标注、错误类型诊断，每一步都可能出错。

第一个版本的 PRD 里，我完全没考虑这个问题。数据流画得很漂亮：「拍照 → AI 识别 → 入库 → 分析 → 推荐」，仿佛 AI 不会出错。

直到有人问我：「万一 AI 识别错了呢？」

---

问题：错误数据会污染整个系统

如果 AI 把「二次函数顶点坐标」错标成「一次函数斜率」，会发生什么？

1. 错题归到错误的知识点
2. 薄弱点分析显示「一次函数薄弱」，实际是二次函数有问题
3. 推荐系统给了 10 道一次函数的练习——和学生的真实弱项毫无关系
4. 学生发现推荐不准确 → 不信任产品 → 弃用

一条错误数据进入分析管道，污染的是整个推荐飞轮。

传统方案的思路是「提高 AI 准确率」——换更好的模型、加训练数据、调 prompt。但这条路的天花板很明显：手写体 OCR 准确率从 70% 提升到 85% 已经很难了，90% 在可见的将来都不现实。

而且，即使到了 90%，每 10 道错题就有 1 道是错的。100 道里有 10 道。对学生来说，10 次错误的推荐 = 再也不用了。

---

灵感：AI 做不好的事，让人来做

问题的本质是：AI 做识别很强但不够完美，人做识别很准但太慢。

那能不能结合起来？

我当时想到一个关键洞察：学生本来就要看自己拍了什么。 拍照录入的过程不是「拍完就完了」，用户本来就会确认「这张照片拍清楚了吗」「题目对吗」。这个「确认」动作，天然就是数据校验的机会。

于是设计了这样一个流程：

AI 识别结果不是「答案」，是「草稿」
    ↓
每个字段带置信度（这条我有多确定）
    ↓
高置信（>90%）：绿色标记，用户看一眼就行
中置信（70%-90%）：黄色提示，建议检查
低置信（<70%）：红色高亮，请手动修正
    ↓
用户确认/修正后 → 入库 → 进入分析管道
未经确认的数据 → 仅自己可见，不参与分析和推荐

核心设计原则：AI 是草稿，用户是编辑。分析管道只吃「干净数据」。

---

隐藏收益：每一次修正都是免费的标注数据

做到这一步后，我发现还有一个更大的收益。

用户修正时，系统记录两个值：

• ai_value：AI 的原始识别结果（比如标注为「二次函数顶点坐标」）
• user_value：用户修正后的值（实际是「二次函数图像性质」）
• ai_confidence：AI 当时对这个判断的置信度（0.72）

这条修正记录（CorrectionLog）就是一条完美的标注数据：

• 有原始模型输出（ai_value）
• 有人工标注结果（user_value）
• 有模型当时的置信度（可用于误差分析）

传统 AI 训练需要花钱请人标注数据。ErrLens 的标注员是用户——而且他们免费标注，甚至感谢你给了他们一个「修正」的功能。

P02 阶段（自研模型），这些 CorrectionLog 就是核心训练数据。产品用得越多，修正记录越多，模型越强——这是真正的数据飞轮。

---

结果

• error_items 表新增 verification_status（raw→reviewed→corrected→stale）和 ai_confidence（JSONB）
• 新增 correction_logs 表，记录每一条人机修正
• 分析/推荐查询强制加 WHERE verification_status != 'raw'
• 前端 UI 设计绿/黄/红三级置信度指示

---

一句话总结

AI 的弱点不一定是产品的弱点——如果你能设计一个把「AI 错误」变成「用户价值」的闭环。