「把老师傅的判断做成系统」——这句话在企业 AI 项目里被说了很多年，但真正落地时，大多数团队卡在同一个地方：不知道怎么拆。
这篇文章讲一个可落地的拆法：四层结构。
一、为什么「直接让 AI 学老师傅」会失败
最常见的做法是：收集老师傅的历史输出，喂给模型，期待它学会。
这条路几乎一定失败，原因有三个：
第一，样本不够。
一个老师傅一年处理 2000 个案子，看起来很多。但业务是长尾的——真正需要判断力的案子，可能一年只有 50 个。50 个样本训练不出稳定判断。
第二，判断依据是隐性的。
问老师傅「你怎么判断这个客户该不该批」，答案往往是「感觉」。
追问「什么感觉」，答「就是不对」。
不是他不想说，是他自己也没把判断过程显性化过。
第三，错误代价不对等。
模型错一次，可能只是麻烦。老师傅错一次，可能损失几十万。这种场景下没人敢让模型全自动。
所以正确的做法不是「让 AI 学人」，而是「把人拆开」——拆成 AI 能做的部分和人必须做的部分。
二、四层结构
┌──────────────────────────────────────┐
│ L4 判断层：最终决定 │
├──────────────────────────────────────┤
│ L3 规则层：显性的业务约束 │
├──────────────────────────────────────┤
│ L2 信息层：把原始材料变成结构化输入 │
├──────────────────────────────────────┤
│ L1 采集层：拿到该拿的东西 │
└──────────────────────────────────────┘
L1 采集层
这一层做什么：把散落的信息收集齐。
失败模式：
- 该拿的没拿到（漏了关键文件）
- 拿到了但格式不对（扫描件、手写、方言录音）
- 拿到了但过期（用了旧版本的价格表）
设计要点：
- 清单化：为每类任务定义「必须齐的材料」，缺一项就不进入下一层
- 格式校验：进 L2 之前先验一遍能不能解析
- 时点标注：每条信息带来源和时间
这一层最容易被低估。 很多项目在 L2/L3 反复调优，最后发现是 L1 漏了关键输入。
L2 信息层
这一层做什么：把非结构化材料变成结构化输入。
典型任务：
- 合同 → 关键条款 + 金额 + 期限 + 违约条件
- 客户对话 → 需求点 + 顾虑 + 决策人
- 现场照片 → 面积 + 材质 + 问题点
失败模式：
- 抽取了但抽错（金额抽成含税/不含税混淆）
- 抽到了但没标注置信度（错的和对的混在一起）
- 关键字段缺失时静默跳过
设计要点：
- 每个字段都要有置信度和来源位置（原始文档第几页第几行）
- 缺字段要显式报错，不能默认填充
- 关键数值做二次校验（金额的位数、单位的量级）
L3 规则层
这一层做什么：把显性的业务约束写成可执行的规则。
这一层是「老师傅经验」里最容易显性化的部分。
举例，一个采购审批的老师傅，他的经验里至少有这些是可以用规则表达的：
- 单笔超过 X 万必须走招标
- 供应商成立不足 1 年的，需额外提供担保
- 同类物料 3 个月内已采购的，需说明理由
- 报价偏离历史均价 ±30% 的，需二级复核
失败模式：
- 规则写死了，业务变了没更新
- 规则之间冲突（A 规则说必须招标，B 规则说可直采）
- 规则太严，导致 90% 的单子都进人工（等于没自动化）
设计要点：
- 规则要有版本号和生效日期
- 规则冲突检测（上线前跑一遍历史数据，看冲突率）
- 统计命中率：如果某条规则的触发率超过 50%，说明阈值定错了
L4 判断层
这一层做什么：做最终决定，并给出理由。
关键设计：不是让 AI 做决定，是让 AI 起草决定。
AI 输出：
{
"建议": "批准",
"置信度": 0.82,
"依据": [
"供应商成立 4 年（满足）",
"报价低于历史均价 12%（在合理区间）",
"3 个月内无同类采购（无重复）"
],
"需人工确认的点": ["质保条款第 7 条表述模糊"]
}
人看到这个，只需要判断一件事：那个「需人工确认的点」重不重要。
这比让人从头看一遍材料快 10 倍。
失败模式：
- 给出了结论但没给依据（人不敢用）
- 依据是编的（更危险）
- 把所有情况都标成「需人工确认」（等于没干活）
设计要点：
- 依据必须可追溯到 L1/L2 的具体数据
- 置信度要校准（说 0.8 的时候，实际正确率应该在 75-85% 之间）
- 人工介入率是核心指标：理想状态是 20-30%，低于 10% 说明规则太松，高于 50% 说明没设计好
三、四层之外：反馈闭环
四层结构只解决「怎么拆」，不解决「怎么变好」。
必须加一个反馈闭环：
L4 的决定 → 人工修正 → 修正记录 → 回灌到 L3 的规则 / L2 的抽取
关键：人工修正不是「改一下就完了」，是要记录「为什么改」。
记录格式：
{
"原建议": "批准",
"实际": "驳回",
"原因分类": "资质问题", ← 可枚举
"具体说明": "供应商经营范围不含该品类"
}
每积累 20-30 条修正记录，就能提出一条新规则或调整一个阈值。
四、验收标准
一个 AI Skill 做完，怎么算合格？
不要用「准确率 90%」这种模糊说法。 用这四个指标：
| 指标 | 定义 | 合格线 |
|---|---|---|
| 建议采纳率 | 人工直接采纳 AI 建议的比例 | > 60% |
| 人工介入率 | 需要人工额外处理的案例比例 | 20-40% |
| 依据可追溯率 | 依据能对应到原始数据的比例 | > 95% |
| 兜底触发率 | 异常情况进入兜底流程的比例 | < 5% |
为什么采纳率只要求 60%？
因为剩下 40% 里，有一部分本来就该人工判断。要求 95% 采纳率，等于要求 AI 承担不该它承担的责任。
五、总结
把老师傅的判断做成系统，关键不是模型多强，是拆得对不对。
四层的检查清单：
L1 采集 → 清单化；格式校验；带时点
L2 信息 → 每字段有置信度和位置；缺字段报错
L3 规则 → 版本化；冲突检测；统计命中率
L4 判断 → 给建议不给结论；依据可追溯；置信度校准
再加一条：反馈闭环必须记录「为什么改」，不只是「改了什么」。
