二、工作流设计

2.1 整体阶段划分

```

Phase 0  预处理        → 拆分分段、编号

Phase 1  Subagent校对  → 并行逐段修正

Phase 2  残项攻坚      → 被拦截项重跑、漏修补修

Phase 3  质量验证      → 抽检3,000条

Phase 4  终版输出      → 合并、报告

```

2.2 分段策略

按五十音顺序拆分为41个独立文件，作为subagent的工作单元。每个subagent独立处理一个分段，互不冲突。

分段原则：

- 按五十音顺序划分，每段对应一个假名行

- 大段（し段3,055条）和小段（ぬ段14条）分开调度

- 先小后大，逐步推进

三、Subagent机制的经验

3.1 优势

- 上下文独立：每个subagent有独立的上下文窗口，可装载完整的校对规则

- 天然并行：独立分段可同时调度，总耗时大幅缩短

- 隔离性：一个subagent失败不影响其他段

3.2 问题与对策

问题1：Classifier拦截

现象：subagent在修改文件时频繁被auto mode classifier拦截，尤其是结构性修改（条目碰撞拆分、跨行合并）和批量替换。

影响：约30%的subagent在首次运行时未能完成全部修正。

对策：

- 对拦截的段进行重跑（部分成功）

- Python脚本绕过逐条Edit的限制（最有效）

- 逐条补修（适用于少量残留）

教训：subagent的Edit工具对结构性修改的容错率低。涉及多行操作的场景应优先考虑Python脚本。

问题2：subagent被kill

现象：部分subagent在运行中被自动终止，原因不明。

影响：被kill的subagent已做的修正可能部分丢失（取决于是否已写入文件）。

对策：对每个segment在subagent完成后做文件完整性检查。

教训：subagent不是事务性的——它可能在中途被kill，已做的部分修正是已写入的，但未写入的部分丢失。建议subagent每完成一批修正就主动写入文件，而非在最后一次性写入。

问题3：修正后验证不足

现象：subagent报告"已完成"但实际部分修正被拦截未生效。

影响：产生了"假成功"的误导，降低了信任度。

对策：最终做了一次全量扫描，使用fix_all.py中的全部已知错误模式逐段检查。

教训：不能信任subagent的"完成"报告。应该在subagent完成后，由主agent重新扫描该段验证修正是否实际生效。

3.3 最佳实践（总结）

```

subagent工作流最佳实践：

1. 每个subagent的任务粒度：100-500条/段为宜

2. 大段（>1000条）拆分为多个子任务

3. subagent完成后，主agent用已知错误模式验证

4. 结构性修改（多行操作）用Python脚本

5. 每完成一批修正即写入文件，避免被kill时丢失

```

四、OCR错误类型的分布与规律

4.1 按类型分布

| 类型 | 占比 | 示例 |

|---|---|---|

| 中文释义中日字残留 | ~60% | 保険→保险、検→检、単→单 |

| 日文汉字OCR错字 | ~16% | 築→筑、統→航、轄→轟 |

| 假名读音错误 | ~12% | 濁点脱落（き→ぎ）、拗音（しよう→しょう）|

| 英文拼写错误 | ~4% | grantore→grantor、storeage→storage |

| 条目结构损坏 | ~4% | 碰撞、断裂 |

| 日文词条中字形恢复 | ~4% | 权→権、济→済 |

4.2 高密度错误段

| 段 | 原因 |

|---|---|

| こ段 | ~450处，有大量系统性的拗音/浊点错误和字形混淆 |

| と段 | ~248处，有特許系列词条的大量拗音错误 |

| い段 | ~190处，假名和字形错误密集 |

| ち段 | ~230处，賃金系列批量字形混淆 |

4.3 低密度错误段

| 段 | 原因 |

|---|---|

| す段 | 英语词条多，日语固有词少，OCR错误少 |

| ぬ段 | 仅14条，且多为简单词条 |

4.4 规律总结

- 浊点脱落是日语OCR中最常见的假名错误（無 voiced→unvoiced）

- 拗音（よう→ょう）在读音括号中系统性出现

- 中文释义部分的日文汉字残留是最普遍的跨字形问题

- 英文错误集中在 `-or` → `-ore`（agent noun后缀）

- 条目碰撞（两词条合并到一行）在双栏排版的扫描件中常见

五、LLM知识校对的适用边界

5.1 有效场景

- 字形相似的日文OCR错误（漢→漢/识、続→繊）

- 常见的英文拼写错误（coreresponding→corresponding）

- 读音错误（拗音、浊点脱落）

- 三语语义不一致的检测

- 条目结构损坏的识别

5.2 无效/低效场景

- 严重损坏的条目（无法推测原文，需PDF回查）

- 译者的主观选词（无法判断"对错"）

- 需要视觉比对的新字形（LLM无此能力）

5.3 关键原则

只改OCR错误，不改翻译选择。 这个边界必须严格执行。LLM的法律知识用于判断"这一串字符是否可能是OCR损坏的结果"，而不是用于判断"这个翻译是否准确"。

六、数据统计

| 指标 | 数值 |

|---|---|

| 原始扫描PDF | 263页，164MB |

| OCR后编号条目 | ~18,000条 |

| 实际有效条目 | 17,240条 |

| 修正总数 | ~2,500+处 |

| 抽检规模 | 3,000条（17.4%）|

| 抽检通过率 | 100% |

| 残留标记 | ~24个（[読欠]/[要PDF]/[要確認]）|

| 总耗时 | 约6-8小时（含多次重跑）|

| subagent调度次数 | ~50+次 |

七、改进建议

1. 预处理增强：在分段前做条目结构修复（碰撞拆分、断裂合并），减少subagent处理结构性问题的负担

2. 校验自动化：subagent完成后自动触发已知错误模式扫描，确保无遗漏

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

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

5. 分段合理性：split_sections.py按行号分段不合理，应按条目编号分段，避免边界gap