proofread-review

# 校对复核工作流（index-X） 处理「校对工具改完，要判断改得对不对」这一类任务。仓库级规约以 `AGENTS.md` 为准，译文规范以 `docs/translation-spec.md` 为准，本文件写「怎么复核、怎么下判定」。 典型触发：BetweenLines 的 AI 辅助校对产出确认结果、应用到 `EPUB/` 之后，需要找出其中**误修改**并回改。 ## 一、先分清任务类型 | 任务 | 归属 | | --- | --- | | 复核成批、近重译级的译文改动（工作区未提交或已提交），判定每处改动的对错 | **本 skill** | | 同一日文锚点的异译收敛、术语／口癖／敬称裁定 | `translation-term-unification` skill | | 结构、行模板、中日对齐、图片行 | `AGENTS.md`「Agent 操作边界」＋ `check_alignment.py` | | 标点／字形等字符级规范化 | `tools/text_norm.py`（复核时属 `spec` 级，可批量放行） | 判据：改动是**批量的**、需要判断「改得对不对」，而不是「该改成哪个词」。 ## 二、八条复核纪律 1. **只回原文**。判定依据是日文原文，不是中文两版谁读着更顺、也不是与台版／网翻比对。 2. **分级处置**。规范级（`spec`）可批量放行，不逐条回原文；语义级必须逐条看。 3. **删减是误删实义成分的高发区**。工具会单独统计「明显删减（old−new ≥ 5 字）」，那批必须重点核；只抽样就必须在结论里写明未覆盖范围，不得用抽样结果宣布整批通过。 4. **事实层优先**：数字、单位、专名、否定、时态、行为主体、词义方向（正／反）逐条核——改错的代价最大。 5. **术语改动比对规约与已裁定口径，不只看日文字面**。历史案例：校对把「科学阵营／魔法阵营」改成「科学侧／魔法侧」，字面贴近日文 `サイド`，但违反术语分层规约（`サイド`→阵营、指示层 `側`→侧）。 6. **写「建议回改」前，必须确认引用的原文行号与被引句子一致**。历史案例：报告称 Epilogue L101 漏译「全裸」，引用的其实是 L83 的原文，L101 的译文本来正确。 7. **原文刻意的省略、留白、悬念不许补**。历史案例：`だから彼らは気づかなかったのかもしれない。`（宾语由后文揭示）建议「补上宾语」会错误指代前文并破坏悬念——否决。 8. **否决也是结论**，要写清理由与依据；证据不足时转人工并写明缺什么，不猜、不将就放行。 ## 三、输入形态与命令 改动来源：BetweenLines「AI 辅助校对」的确认结果导出（`out/projects/<id>/snapshots/<ts>/translation-compare.csv`，列含 `jp` / `cn`）经应用后落到 `EPUB/`。**复核入口是 git 改动**，与应用方式无关。 ```powershell # 工作区未提交的改动（校对结果刚应用、还没提交） python tools/proofread_review.py --worktree python tools/proofread_review.py --worktree --path "EPUB/[S3_01]创约 某魔法的禁书目录 01X" python tools/proofread_review.py --worktree --out .cache/epub-work/proofread-review-s301 # 已提交的批量校对（可一次给多个提交） python tools/proofread_review.py b7515335 2d44cb26 821c46b9 7a218119 ``` 产物（默认 `.cache/epub-work/proofread-review/`）： | 产物 | 内容 | | --- | --- | | `changes.tsv` | 全部片段：`commit / work / file / line / grade / kind / old / new` | | `semantic.tsv` | 需要回原文判断的片段（`tiny` / `local` / `rewrite`） | | `spec.tsv` | 规范确定性改动，可批量放行 | | `groups.txt` | 语义级按最小差异聚类，重复改动模式一眼可见 | 终端另给：片段数、各级别条数、`spec` 子类分布、**明显增补／明显删减**条数、按作品分布。 - **不要为复核新建 git worktree**：工具直接读 git 历史，`<commit>` 参数即够。 - 分级判据与参数的权威定义在 `tools/README.md`「译文校对复核（提交级，只读）」与 `tools/proofread_review.py` 源码；本 skill 只写怎么用、怎么判。 - `.cache/` 属只读分析区，工具产物（TSV / `groups.txt` / 复核报告）落在其下的 `proofread-review/` 即可，**不进仓库**；也不要把报告写进其它 agent 的工作目录。 ## 四、分级与处置 | 级别 | 含义 | 复核处置 | | --- | --- | --- | | `spec` | 改动由 `docs/translation-spec.md` 条款决定（`punct` 标点排版 / `quote` 引号体例 / `glyph` 全半角 / `erhua` 去儿化 / `particle` 规范语气词） | 批量放行；只确认子类与规范一致，不逐条回原文 | | `tiny` | 最小差异 ≤ 2 字且差异两侧全是虚词 | 仍要回原文，但一眼能看完；**不是「可跳过」** | | `local` | 最小差异 ≤ 12 字（术语、用词、数字） | 逐条看，按 `groups.txt` 的聚类批量核同类 | | `rewrite` | 最小差异 > 12 字，或整段增删 | 抽查（整句重写数量通常最大，不逐条） | 两条容易被误用的口径（工具已实现，复核者别用直觉覆盖）： - **数字与字母不是标点**：剥标点判「只动了排版」时不能把 `0-9a-zA-Z` 一起剥掉，否则「删掉／改掉数字」会被静默放行——那正是事实性纠错的高发区。 - **`tiny` 不能只看字数**：「念动力 → 念动能力」「第10位 → 第位」最小差异都只有 2 字，却是术语与事实改动。 ## 五、复核流程 R0–R7 **R0 圈定范围**：确认复核哪些提交／工作区改动，涉及哪些作品（单本还是跨本，决定留档方式）。同时记下这批改动的**性质**（零散订正 / 近重译级通校）——这决定抽样尺度。 **R1 跑工具、记基线**：把片段数、级别分布、明显增删数、按作品分布记进报告（后续结论要与它对比）。 **R2 放行规范级**：核 `spec.tsv` 的子类分布是否符合规范条款；掺了语义成分却落到 `spec` 的，单独挑出来按 `local` 重看。 **R3 分层核对语义级**（按风险从高到低）： 1. 事实层：数字、单位、专名、否定、时态、主体、词义方向 —— 逐条回原文； 2. 明显删减 → 重点核（误删高发）；明显增补 → 确认不是凭空添加； 3. 术语改动 → 对照 `translation-term-unification` skill §六 的已裁定结论索引与 `AGENTS.md` 口径； 4. `groups.txt` 聚类里的高频模式 → 按类抽样，同类结论一致即可批量判定； 5. `rewrite` → 抽查，重点看有没有整段删掉信息。 **R4 回原文核对**（方法见 §六）。每条结论都要落到「中文位置 + 日文原句 + 判定」，写在报告里可复核。 **R5 判定与处置**，只有三种出口： - **成立 → 回改**：译文确实错了，写进回改清单； - **不成立 → 否决**：写理由（引错行、原文刻意省略、规约优先于字面 ……）； - **证据不足 → 待人工**：写明缺什么证据，不猜。 **R6 回改与门禁**：回改同属「改译文用词」，用 `translation-term-unification` skill 的执行器模板（显式映射 + 逐条预检，只改行内文字、不增删行），跑完过门禁： ```powershell python tools/check_alignment.py --strict # 行模板 / 中日行数 / h2 / 图片行 python tools/check_epub_health.py --strict # 单侧结构（XML / ruby / 加粗 / 悬空引用） ``` **R7 同步、留档、提交**： ```powershell python tools/publish_auto.py # 打包上传 OneDrive + 回流缓存 ``` - 复核产物与报告写 `.cache/epub-work/proofread-review/`（不提交；`.cache/` 可随时删除重建，所以报告是工作产物而不是档案）。 - 报告的长期归属按 `AGENTS.md`「维护流程」第 7 项判定：复核引发的修改落在**两本及以上**书籍、或沉淀出可复用的判定口径 → 写 `docs/maintenance-records/`；**单本**（如只动 `S3_01`）**不留档**，判定口径、统计与证据写进本次提交信息，由提交承载。 - 提交用中文 Conventional Commits（如 `fix(epub): 创约1三处误译回改（开课/火花/旅行车）`）；只暂存本任务文件，不 push。 - 被否决的条目**不要**为了让报告「闭环」而硬改；它们的价值就是下次不再被误判；否决理由进提交信息或（跨本时）维护记录。 ## 六、回原文核对的方法 **配对**：中日两侧按同一作品号配对；文件按**内容序 NN** 一一对应（`01`=序章／引子、`02`=行间一、`03`=第一章 …）。文件**内部不是逐行对齐**，不要按行号去找日文——**按关键字检索**。 路径（注意两侧目录结构不同）： ``` 日文：.cache/epub-work/japanese-text/[S3_01]創約 とある魔術の禁書目録(01)/item/xhtml/S3_01-07.xhtml 中文：EPUB/[S3_01]创约 某魔法的禁书目录 01X/OEBPS/Text/S3_01-07_Chapter3.xhtml ``` 取纯文本要**先剥 `<rt>` 注音再 `text_of`**——`xhtml_text.text_of` 只去标签，不剥注音，带注音的词会被拆成「魔術 まじゆつ」而检索不到。用本 skill 附带的查证脚本（已封装路径、内容序、剥注音）： ```powershell # 看日文某内容序里含某关键词的行及上下文（纯文本、已剥注音） python .agents/skills/proofread-review/references/lookup_source.py jp S3_01 07 火花 -C 2 # 看中文某文件某一行的纯文本（核对译文现状） python .agents/skills/proofread-review/references/lookup_source.py cn S3_01-07_Chapter3.xhtml --line 56 # 也可以直接在中文侧检索关键字，再回日文确认 rg -n "小货车|旅行车" "EPUB/[S3_01]创约 某魔法的禁书目录 01X/OEBPS/Text" ``` 几条纪律： - **引用原文时必须连同内容序与实际句子一起写**，报告里的「日文原文」列要能被人直接检索到。 - 同一词在同卷多处出现时，逐处看：卷内一致性本身就是判定依据（例：`ステーションワゴン` 同卷一处译「旅行车」、一处译「小货车」→ 异译）。 - 原文分两级写法时不要合并判定（例：`念動能力` 与 `念動力` 是两个词，前者可作「念动能力」）。 - 检索脚本放 `.cache/`，跑完删除，不提交；只针对本次任务的批量导出／比对脚本属一次性脚本，不进 `tools/`。 ## 七、报告模板 报告按 §五 R7 的归属存放（工作产物在 `.cache/epub-work/proofread-review/`，不进仓库）。结构： ```markdown # <作品>「重新校对」提交复核报告 - 生成时间：<日期>（含第 N 轮查证修正） - 复核对象：<N> 个提交，全部落在 `EPUB/[S3_01]…/` - 原文依据：`.cache/epub-work/japanese-text/[S3_01]…/item/xhtml/S3_01-01..12.xhtml` - 工具：`python tools/proofread_review.py <commits>` - 原始数据：`.cache/epub-work/proofread-review/` ## 一、规模 | commit | 日期 | 文件数 | diff 行 | 片段数 | （+ 按文件分布、性质判断：零散订正还是近重译级通校） ## 二、改动类型 × 重要度 | # | 类型 | 数量 | 重要度 | 风险 | 处置建议 | （事实性纠错 / 术语 / 明显删减 / 明显增补 / local / rewrite / 引号 / 儿化 / 拟声 / 错别字 / punct） ## 三、已核实为正确修正（回查日文原文） | 位置 | 旧 → 新 | 日文原文 | 判定 | ## 四、需要关注的问题 ### 4.1 误改（含第三轮复核后的判定：成立／不成立） ### 4.2 表达／一致性问题 ### 4.3 术语回退（已被后续全库统一修正的，注明提交号与「无需处理」） ## 五、结论与建议 （整体质量判断；已回改 N 处 + 提交号；否决 N 处及理由；未覆盖范围：如「明显删减 136 处只抽样核实约 20 条」） ## 六、第 N 轮复核（工具或口径修复后） （触发原因、修复要点、本报告待办的最终处置） ## 附：复现方式 ``` 报告只写结论、范围、统计、保留项与必要样例，不复制整段译文。 ## 八、坑清单 | 坑 | 规避 | | --- | --- | | 引用原文行号与实际句子不一致 | 写「建议回改」前，用脚本把该行原文打出来核对（§六） | | 按日文字面判术语对错 | 先查规约与 `translation-term-unification` 的已裁定结论索引 | | 建议补上原文刻意省略的成分 | 看后文是否揭示；刻意留白一律否决 | | 把 `tiny` 当「可跳过」 | 术语／事实改动的字数也可能只有 2 字 | | 用「只差标点」的直觉放行数字改动 | 数字不是标点，事实层逐条核 | | 抽样后就宣布整批通过 | 结论里必须写明未覆盖范围（尤其明显删减） | | 只剥标签不剥 `<rt>` 就检索 | 用 §六 的脚本；带注音的词会被拆开 | | 用 `glob` 匹配 `[S3_01]` 路径 | 方括号是字符类，改用 `pathlib` / `os.listdir` | | 为复核历史提交新建 worktree | 工具直接读 git 历史，不需要额外工作树 | | 把复核报告写进仓库或别的 agent 的工作目录 | 工作产物放 `.cache/epub-work/proofread-review/`；需要长期保留的结论按「维护流程」第 7 项进 `docs/maintenance-records/`（跨本）或提交信息（单本） | | 复核报告自己的结论不再核对 | 报告自身也要回原文核（第二轮修正的教训） | ## 九、与其它 skill 的分工 | 场景 | 走哪条 | | --- | --- | | 判定「这批校对改动对不对」，回改误改 | **本 skill** | | 判定「这个术语该译成什么」，全库异译收敛 | `translation-term-unification` | | 回改的执行方式（显式映射 + 逐条预检） | 复用 `translation-term-unification/references/unify_terms_template.py` | | 改动引起的结构／对齐问题 | `AGENTS.md`「Agent 操作边界」＋ `check_alignment.py` |