二、工作流

将整个词典按五十音顺序切分为41个独立分段，利用subagent并行校对。整体分为五个阶段：

Phase 0 预处理。将OCR后的文本按五十音切分，每条词条编号，为每个分段估算对应的PDF页码范围。

Phase 1 并行校对。每个subagent负责一个分段，执行三语交叉验证。大段如し段3055条单独攻坚，小段如ぬ段14条快速过掉。每批同时跑4到6个subagent。

Phase 2 残项攻坚。对首次运行中被拦截或中断的分段进行重跑，再用Python脚本批量修正剩余的遗漏。

Phase 3 质量验证。等距抽检3000条，覆盖全部41个分段，100%通过。

Phase 4 终版输出。合并分段，生成校对报告。

三、三语交叉验证的校对逻辑

与传统的OCR后处理不同，LLM校对不是依赖固定替换表，而是利用四维知识做判断：

日语语言学知识判断读音是否正确，假名有无浊点脱落、拗音是否完整。日本法律知识判断日文词条是否是一个真实存在的法律制度或概念——会社更生法是真实存在的，会社更正法则不存在。中文法律知识判断中文释义是否对应正确的日本法律制度。英美法律知识判断英文翻译是否指向正确的日本法律概念。

这四条知识线同时作用，任何一行与其他三行不一致就是OCR错误。例如看到coreresponding，英语知识判断这是corresponding的OCR损坏。看到会杜，日语知识判断社被OCR误认为杜。看到水済陰保険単，中文知识判断应为水渍险保险单。

四、Subagent机制的经验

并行subagent是本项目效率的核心，但在实践中遇到了几个问题。

第一个问题是classifier拦截。subagent修改文件时频繁被auto mode classifier拦截，尤其是结构性修改。约三分之一的subagent在首次运行时未能完成全部修正。对策是对拦截段重跑，用Python脚本绕过逐条Edit的限制。

第二个问题是subagent被自动终止。部分subagent在运行中被kill，已做的修正是已写入的，但未写入的部分丢失。教训是subagent应每完成一批修正就主动写入文件，而非在最后一次性写入。

第三个问题是修正后验证不足。subagent报告已完成但实际部分修正被拦截未生效，产生了假成功的误导。最终补做了一次全量扫描才清除所有残留。教训是不能信任subagent的完成报告，应该在subagent完成后由主agent重新扫描验证。

五、OCR错误类型分布

修正约2500处错误，分布如下：中文释义中日字残留约占六成，是最普遍的跨字形问题。日文汉字OCR错字约占一成六。假名读音错误约占一成二，其中浊点脱落最为常见。英文拼写错误约占百分之四，集中在agent noun后缀or被识别为ore。条目结构损坏约占百分之四，在双栏排版的扫描件中常见，表现为两词条碰撞合并到一行。

六、LLM知识校对的边界

LLM校对在字形相似的日文错误、常见英文拼写错误、读音错误、三语语义不一致的检测、条目结构损坏的识别上效果很好。

但在严重损坏的条目上无能为力，因为无法推测原文，需要回查PDF。译者的主观选词也无法判断对错。

核心原则是：只改OCR错误，不改翻译选择。LLM的法律知识用于判断这一串字符是否可能是OCR损坏的结果，而不是用于判断这个翻译是否准确。

七、数据统计

原始扫描PDF 263页共164MB，实际有效条目17240条，修正约2500处，抽检3000条通过率百分之百。总耗时约6到8小时含多次重跑，subagent调度约50次以上。

八、改进建议

预处理增强：在分段前做条目结构修复，减少subagent处理结构性问题的负担。

校验自动化：subagent完成后自动触发已知错误模式扫描。

进度追踪：建立中心化的修正清单，subagent每修一条记一条。

权限预配置：对批量操作预先配置脚本权限，避免频繁被拦截。