四条原则 · 可迁移的部分
方法论
这套闭环不是从框架论文开始做的，而是从四条被实践检验过的原则推导出来的。 它们比任何具体实现都更可迁移。
四条落地原则
先流程后工具
引入 AI 前先完成流程梳理与标准化。跳过流程标准化直接买工具期待提效， 是多数 AI 项目失败的根因。这个场景在动手搭 Agent 前花了整整两个季度做编目 SOP 原子化。
先确定性后自动化
把复杂业务拆成清晰可控的步骤 —— 每个字段是一个原子技能， 职责单一、格式标准、模块解耦。确定性是自动化的前提，不是它的产物。
先试点后推广
规则生效走灰度（10% 流量），验证修正率真的下降再全量。 机制本身也一样：先在一个场景跑通闭环，再谈复制。
先能力后平台
不等自演进框架成熟。「字段级 diff → 聚合 → LLM 归纳 → 人工审核 → 入库生效」 这条土路能拿到 90% 的价值，一周可以做出第一版。
白盒优于黑盒
通用 Agent 缺乏企业级应用所需的确定性、可解释性与可审计性。这套闭环的每个环节都刻意保持白盒：
- 修正日志是可 grep 的 JSONL，规则库是可人工直接审阅的 JSON；
- 规则是「条件 + 动作 + 理由 + 样本证据」的显式文本，不是权重；
- 不做端到端微调 —— 数据量不足，且不可解释、不可审计，与白盒原则冲突；
- 效果验证是一个可复算的数字：生效日前后的修正率对比。
置信度检验：最容易被忽略的一步
diff 分析会输出置信度分箱，回答一个问题：AI 说自己没把握的时候，是不是真的容易错？
- 低置信度样本占修正量显著更高 → 置信度机制可信，可据此排人工复核优先级；
- 各箱分布均匀 → 置信度机制本身是坏的，先修它，再谈规则提取。
先跑这一项，再决定要不要投入规则提取 —— 否则整个闭环建立在一个不可信的信号上。
让模型少做选择题，剩下的用校验兜住
规则提取是这套闭环里唯一用到模型的环节，也是唯一可能凭空编造的环节。 处理办法分两层，都不指望模型自觉：
- 先收窄自由度。规则类型由修正原因确定性地选定，不问模型； 模型只填该类型 schema 内的几个参数。从「写一段话」变成「填几个值」， 可编造的空间随之收窄。
- 再用校验兜底。结构化参数可以校验，自由文本不能。 编出一个不存在的数据源名，入库时当场被拒，而不是等审核人肉眼发现。
但 schema 只能挡住形状不对的参数，挡不住形状对而语义错的。 于是再加一层语义自测——规则本就强制附带样本证据，那些证据就是它自己的测试用例。
哪些能本地判，哪些只有上游能判
这条边界要划清楚，否则要么漏掉该拦的，要么编造一堆判不了的检查：
| 规则类型 | 本地能判什么 | 为什么 |
|---|---|---|
| normalize | 拿证据样本回算，逐条比对 | 参数本身编码了一个可执行的变换，能当场跑 |
| source_priority fallback_source | 只判一件事：出错的源不能当解药 | 换成哪个源更准，只有上游跑过才知道；但拿出错的源去补它自己出的错， 不需要跑就能断定无效——这是同义反复 |
| prompt_constraint | 不判 | 效果完全在上游生成环节体现，本地无从验证 |
这条边界是真实模型跑出来逼出来的。一次评测里模型给出过这样一条兜底规则： 字段为空时，去某个数据源补——而那个源正是该字段一直漏抓的源。 schema 全过、能入库、会进审核队列，却不可能有效。
反过来说，「换哪个源更准」就必须留给上游。本地强行判定只会拦掉正确的规则， 比漏拦更糟——宁可放过，不可乱拒：审核人还能拦下一条坏规则， 但被系统悄悄拒掉的好规则不会有人知道。
判不了就不判，宁可少一半数据
拿到一批真实的双版本数据时（每个条目两行：AI 产出、人工修改后）， 面对一个诱人的捷径：这批数据没有「修正原因」这一列， 但只要比对两个值，似乎就能推断出原因——空值补上的算漏抓， 值变短了算冗余，看着挺合理。
我们只推断了两类，其余如实标记为「判不了」，结果是65% 的数据用不了。
为什么不把那 65% 也推断出来：分析的全部价值就在于按原因归类。 AI 给了一个值、人工换成另一个——是抓错了源（该改采集策略）， 还是编造了内容（该改生成约束）？这两者的解法相反。 猜错不是「少一条数据」，是把规则引向相反的方向， 而且因为它披着数据的外衣，事后极难发现。
少一半数据的代价是可见的、可补的；一批被污染的归因是隐性的、不可查的。 宁可少，不可脏。
按形态分类，还是按解法分类
同一批差异，有两种分法：
| 按形态分 | 按解法分 | |
|---|---|---|
| 类别 | 值修改 / 空值补充 / 冗余删除 | 来源错误 / 格式不符 / 语义偏差 / 幻觉编造 / 漏抓补全 |
| 怎么得到 | 比对两个值即可，可自动 | 需要修改者当场说明 |
| 能推出下一步吗 | 不能 | 能，与规则类型一一对应 |
按形态分很省事，因为它不需要人填任何东西。代价是「值修改」 成了一个大筐——实测这一类占到近七成，而它内部既有「抓错源」也有「编造内容」， 两者要改的地方完全不同。
省掉的那一步，正是决定下一步该做什么的那一步。 这不是命名偏好之争，是分类维度选错了：分类的目的是决定行动， 按形态分恰好把决定行动的那个维度丢掉了。
先量再改：印象会过期
「提取成功率大概三分之一」这句话在待办里躺了一段时间。真去测量时， 成功率是 15/15——那次失败早已修掉，只是从没复测，印象就留下来了。 如果照着待办去调提示词，改的是一个没坏的东西。
所以把评测做成脚本，并且把失败分类，因为四类的改法完全不同：
| 失败类别 | 含义 | 该往哪改 |
|---|---|---|
| 调用失败 | 网络或鉴权 | 与提示词无关 |
| 空返回 | 模型认为样本无共同模式 | 样本量或聚合口径 |
| schema 不过 | 形状错：多余的键、白名单外的源 | 提示词讲清格式 |
| 自测不过 | 形状对但语义错，会改坏数据 | 加校验，别指望提示词 |
混在一起只会得到一个「成功率」数字，看不出该动哪里。
还有一条容易忽略的要求：评测的判定必须与产品代码一致。 产品代码已经拦下了、评测却仍报「成功」，是最糟的情况——读数好看， 拦截效果无从得知。这一点用测试钉住，不靠人记得。
结构同构：一次攻坚，多处受益
「人工修正回收」这个问题在不同场景里结构完全同构：
| 场景 | 人工动作 | diff 单元 |
|---|---|---|
| 元数据编目 | 改字段值 | 字段级：原值 → 新值 + 原因 |
| 视频智能切片 | 候选切片留用/弃用/入出点微调 | 切片级：AI 建议 → 人工终审 + 原因 |
| 任何 AI 初筛 + 人工终审的流程 | 接受/修改/拒绝 | 决策级 diff |
规则提取管线（聚合 → 归纳 → 审核 → 灰度）对以上场景通用 —— 攻坚做一次，同构场景都受益。