每个月 5 人日的人工校验，这次被压缩到了 1 小时 26 分 28 秒。准确率接近 100%。
背景
每个月，团队会拿到一批商品 SKU，系统根据这些 SKU 采集授权范围内的商品图片（主图和详情图），然后通过 OCR 提取图片中的文字，再调用大语言模型分析这些文字，最终生成一份 Excel 结果文件。
听起来流程挺顺的。但问题出在最后那一步——Excel 生成之后，还需要人工校验。
这份 Excel 里，和这次优化最相关的几列是：
| 列 | 内容 | 说明 |
|---|---|---|
| B | OCR 图片文字 | 原始识别结果 |
| C | 注释文本 | 图片中的注释，如星号、角标等 |
| D | 解释文案 | 注释对应的解释说明 |
| J | 商品 SKU | 同一商品多张图片的分组依据 |
其中 C、D 两列是最容易出问题的地方。一件商品通常有多张图片，每张图片对应一行。注释文本可能出现在当前图片里，但对应的解释文案不一定在同一行——有时会藏在同一件商品的另一张图片中。所以校验的时候不能只看单行，得把同一个 SKU 下的所有图片文字放在一起看。
每个月，这部分人工校验大约需要 5 人日。
这次做的事，就是把这部分工作压缩到了 1 小时 26 分 28 秒。
原来的问题
前面虽然有 OCR 和大语言模型参与分析，但最终结果的准确率仍然不够稳定，问题集中在 C、D 两列：
- C 列漏了——图片里明明有注释文本，但没提取出来
- D 列空了——有注释文本，但没找到对应的解释文案
- 内容错配——C、D 列都填了，但配错了对象，或者把非注释内容当成了注释
这些错误直接影响后续数据使用，所以每次程序跑完，还得人工再过一遍。
逐行打开 Excel，按 SKU 对照图片文字，判断 C、D 两列到底对不对。每个月都要这么来一遍。
为什么不能只靠脚本
这个问题看起来像”从文本里提取字段”，直觉上写几个正则就能搞定。但实际做起来发现，图片里的注释形式太不统一了。
有的是常见的星号、数字角标，有的是括号说明，有的是页面边缘的小字；有的解释文案紧跟在注释旁边，有的散落在详情页底部。再加上 OCR 识别本身有噪声，文字顺序、符号、换行都可能不稳定。
如果硬上脚本，会撞上两个问题：
- 规则写严了，很多真实情况漏掉
- 规则写宽了，活动说明、免责声明、普通卖点全被误判成注释
NOTE这类任务真正需要的不是”写更多正则”，而是模拟人工校验时的判断过程：先把同一个 SKU 下的全部文本看一遍，再判断哪些是高置信的注释和解释，最后只改有把握的地方。
这件事，脚本做不了，但大语言模型可以。
这次的方案
这次没有继续把问题包装成纯脚本任务，而是让 Codex 接管了人工审阅的过程。
这里说的 Codex Skill，不是一次性的对话提示词，而是一套固定的执行流程和规则——输入范围、分批方式、判断标准、输出格式和校验方式都固化下来了。之后每个月只需要给它新的源文件，就可以按同一套流程重新处理。
核心思路是这样的：
先把 Excel 中需要审阅的信息按 SKU 分组，再让 Codex 逐组分析同一个商品下的 OCR 文本、已有 C/D 内容和上下文证据。对于可以高置信判断的空白或错误，生成修改清单；对于不确定的，保留原样，交给后续人工核查。
这个流程不是让模型一次性”猜完整个表”，而是把人工校验拆成可控的小批次：
- 每批处理一批 SKU
- 每批输出当前进度和修改数量
- 处理完自动继续下一批
- 直到所有 SKU 都完成才结束
这样既保留了大语言模型对非结构化文本的理解能力，又避免了单次任务过大导致遗漏或中途失控。
为了让结果方便复核，这次对修改过的单元格做了颜色标记：
| 标记颜色 | 含义 | 举个例子 |
|---|---|---|
| 🟡 黄色 | 原来为空，这次补充了内容 | C 列没有注释文本，但同一 SKU 的 OCR 文本中找到了明确证据，补进去标黄 |
| 🔴 红色 | 原来有内容，但判断为高置信错误 | C 列提取错了注释，或 D 列把另一个注释的解释文案填了进来，修正后标红 |
TIP这个设计很关键——它没有把自动处理结果伪装成完全正确，而是把”新增”和”纠错”清楚地区分出来。后续人工只需要看标记的地方，快速判断处理是否可靠。
效果
这次优化后，原本每月约 5 人日的人工校验工作，被压缩到了 1 小时 26 分 28 秒。
完整处理了 154 个 SKU，全部审核完成。其中 101 个 SKU 产生了高置信修改，53 个 SKU 因低置信保留原样——没有为了凑进度硬改。
一共修改了 327 个 C/D 单元格，黄色填充 24 个，红色修正 303 个。处理完成后通过最终校验，校验结果为 ok: true。人工复核反馈：准确率接近 100%。
成本结构也变了。过去主要消耗人工时间，现在主要消耗模型 token：本次消耗约 3.11M token，其中输入约 2.79M，输出约 317K。相比 5 人日的人工校验成本，这部分更可控，也更容易随着每月流程复用持续摊薄。
完整数据
| 指标 | 数值 |
|---|---|
| 总 SKU | 154 |
| 已审核 SKU | 154 |
| pending SKU | 0 |
| 有修改 SKU | 101 |
| 低置信跳过 SKU | 53 |
| 总修改单元格 | 327（黄色 24 + 红色 303） |
| 运行耗时 | 1 小时 26 分 28 秒 |
| Token 消耗 | 3.11M（输入 2.79M + 输出 317K） |
| 校验结果 | ok: true |
| 人工复核 | 准确率接近 100% |
经验总结
这次实践里一个很明显的感受：大语言模型不能只靠一次提示词解决复杂表格任务。
尤其是这种包含 OCR 噪声、跨行上下文、非标准格式和业务判断的任务，如果把整个 Excel 扔给模型让它直接输出结果，稳定性不会好。
更可靠的方式是给模型设计一个流程：
- 明确输入范围
- 明确判断标准
- 明确什么情况下允许修改
- 明确什么情况下必须保留
- 明确每次处理后的状态
- 明确最终如何复核
IMPORTANT真正有价值的不是让模型”更自由”，而是让它在一个清晰、可追踪、可复核的流程里工作。
总结
这次优化的核心价值，是把一个每月重复消耗 5 人日的人工校验流程，变成了一个可复用、可追踪、可复核的 Codex Skill。
它没有试图用规则脚本穷举所有注释格式，也没有让模型无约束地批量填表。而是让 Codex 按 SKU 分批审阅，高置信才修改，不确定就保留，并用颜色标记所有改动。
对于这类”规则写不完，但人工判断路径比较清晰”的任务，这种方式比单纯写脚本更合适，也更接近实际业务里能落地的自动化。
这些数据后续可以按月继续积累，用来评估这套方案的投入产出比，也方便判断哪些商品或场景仍然需要人工重点关注。