/transcription-corrector

误转写识别判断准则

重要：本文件不列"错误形式 → 正确形式"映射。 ASR 错误无穷无尽（大小写漂移、空格漂移、漏词、错位、同音字、形近字、音节吞并、断词重连…），任何静态映射表都会漏。 真正的判断由 AI 在通读全文时基于上下文完成。本文件只提供判断框架与边界条件。

1. 什么时候才替换

替换一个词必须同时满足：

1. 词典对齐：用户词典里有"正确写法"项
2. 上下文明确：当前段落/句子清楚指向该词典项（不是巧合撞词）
3. 形式漂移证据：原文相对词典项有可识别的漂移（大小写、空格、连字符、漏字、音近、形近、词序错位）
4. 替换后无损：替换不改变原意、不影响语法、不破坏专有名称的语义

任一条件不满足 → 保持原文，不替换。

2. 高频易错类别（不是错误表，是判断启动点）

以下类别在通读时优先扫描，但不要假设每个出现的词都错：

• 人名：律师、当事人、证人、对方代理人姓名
  • 判断要点：是否首次出现 + 后续是否被引用确认
  • 风险：同音字混淆最高，且不能从形式推断
• 英文产品/工具/平台名：Claude Code、WorkBuddy、Codex、Cursor 等
  • 判断要点：是否在工具使用、命令行、平台介绍、产品名引用等场景
  • 形式漂移模式（参考但不穷举）：
    • 大小写（WorkBuddy vs workbuddy vs WORKBUDDY）
    • 空格（work body / Work Buddy）
    • 连字符（Claude-code / Claude-Code）
    • 拆分被识别为中文（"开普尔 code" / "克劳德 code"）
    • 漏字只留半截（"body" 残留在"让，如果 body帮我们"）
• 机构/活动/品牌名：律协、青训营、训练营、赛题
  • 判断要点：上下文是否在介绍/引用该机构
• 法律术语同音/形近：代理 vs 带理、抵押 vs 抵压、知情 vs 至清
  • 判断要点：术语是否符合当下法律语境
• 数字/单位/时间戳：20 万 vs 20万、5-6 vs 5~6、1:30 vs 1:30
  • 保守原则：除非上下文强烈支持，不动数字

3. 不替换的边界（不做什么）

• 不替换"低置信"：形式上"看起来像"但没有上下文支持 → 保留原文
• 不替换"合理但有差异"：如果原文写法在合理范围内、词典里又没有，不主动统一
  • 例：词典里有"张律师"，原文出现"张老师"——不强行改成"张律师"
• 不替换"风格选择"：口语词、语气词、网络用语的"不太规范"——不是纠错对象
  • 例：把"呃"、"啊"、"那个"、"就是说"——保留
• 不替换"客观事实"：金额、时间、当事人关系、签字日期、法院名称——一律保留
• 不替换"专业表述的口语化"：例如"诉求的基础"如果原文是"打官司的理由"——这是润色范畴，不是纠错

4. 上下文支持度判定方法

拿不准时按以下顺序求证：

1. 同段内自证：当前段落是否解释/举例/使用该词
2. 跨段对照：本文其他位置是否出现该词的正确写法或可对照写法
3. 同主题邻近：前后 5-10 段是否在讨论同一对象
4. 语义场匹配：替换后在语法、语义、上下文逻辑上是否更通顺
5. 无法判定 → 保留原文 + 写入 correction_log.md 的"未处理"区

5. 组合错误的处理

ASR 经常产生叠加错误：漏词 + 拼写漂移 + 断词同时出现。

例：让，如果 body帮我们重新在此基础上生成了一个。

• 拆解：断词（让/如果 来自"然后让"）+ 漏字（产品名只剩 body）
• 处理：必须整段重写，不能只替换一个词
  • 改后：让 WorkBuddy 帮我们重新在此基础上生成了一个。
  • 注意保留原句的因果/时序关系

原则：识别组合错误时，整句重写优于单词逐个替换；重写后必须通读校验原意未变。

6. 基础空白清理规则

本节是"格式标准化"操作（默认开启），不替换语义、只调整空白字符。不做语义判断、不依赖词典（专有名称内部断裂空格的合并见 §2 高频易错类别）。

6.1 清理动作（白名单）

6.2 标点周围空白标准

6.3 严格不做

• 不删文字：空白清理只动空白字符，碰到"看上去像"的多余字符（如破折号、星号）一律保留
• 不动数字 / 时间戳 / 金额：1.5 00:33:09 ¥20,000 这类结构内部的空白不动
• 不重排段落：连续空行压缩为单个空行是"块内归一"，不跨块合并
• 不重写："呃 然后" 的两个语气词之间是空格也不删——语气词是说话人风格（属 Phase 4 润色范畴）
• 不改发言人分块标记：**发言人 1 00:33:09** 内部的双空格是 markdown 排版，保留
• 不跨行 \s+ 匹配：speaker 块结构（说话人 N HH:MM:SS + 内容 + 空行 + 下一标题）依赖"末标点 → 换行 → 空行"序列；任何让 \s+ 跨行消耗的操作都会把多个 speaker 块和 H2 标题合并到一行。中文标点周围空白的清理必须用按行迭代或不含 \s 的固定串替换（如 ln.replace("， ", "，")），禁止走单条跨行 regex。

6.4 与 Phase 3 / Phase 4 的边界

简单记：Step 3.1 改字、Step 3.2 改空白、Step 3.3 删填充词、Phase 4 改结构。

7. 口语词精简规则（Step 3.3，默认开启）

本节是"语言字符级清理"操作（默认开启），不替换语义、只删独立的纯填充词。不改写为书面语、不删整句。

7.1 可删的纯填充词（白名单）

7.2 保留规则（不删）

• 表态类："嗯" / "对" / "是的" / "不是" / "好的" / "是" 作肯定 / 否定 / 回应 → 删了丢失说话人态度
• 逻辑连接："然后"作逻辑连接词（"先 A 然后 B"）→ 删了破坏时序
• 认知停顿后接完整内容："呃……这个怎么解释呢" 整段保留
• 段尾 关键节奏标记 → 保留（v2 激进版起，段首节奏标记默认删除）
• 紧邻关键名词 / 动词 的口语词 → 保留（可能是说话人强调）
• 实义词（名词 / 动词 / 形容词 / 副词）→ 一律不删

7.3 判断原则

与 Step 3.1 一样的"通读 + 三重确认"思路：

1. 该词在当前上下文是否属于白名单词类
2. 在当前位置是否独立使用、是否承担实义
3. 删后不破坏说话人态度 / 时序 / 强调

任一不满足 → 不删，保留原文。模糊或低置信场景一律保留。

7.4 严格不做

• 不删整句、不删段落
• 不删实义词（即使重复）
• 不删关键信息（数字 / 人名 / 专有名 / 术语）
• 不改写为书面语、不补全、不改语气
• 不删"段首 / 段尾"的关键节奏标记

7.5 典型"易误判"案例

7.6 与 Phase 3 / Phase 4 的边界

简单记：Step 3.1 改字、Step 3.2 改空白、Step 3.3 删填充词、Phase 4 改结构。

8. 与润色开关的边界

纠错模式（默认）只做 Step 3.1 词典替换 + Step 3.2 基础空白清理 + Step 3.3 口语词精简，不：

• 合并同发言人连续发言
• 切分极长段
• 统一标点
• 改写口语

开启润色开关后，才进入 Phase 4 的最小动作集合（见 SKILL.md）。

重要：Step 3.3 口语词精简不属于 Phase 4 润色范畴——它默认开启（因为只删白名单纯填充词、不改风格），与"发言人合并 / 标点规范 / 段落切分"这种"风格调整"性质不同。

9. 工作方式提醒

• 必须通读全文，禁止只用 grep/正则匹配
• 词典项是"目标值"，不是"触发器"——不要为了使用词典而强行替换
• 口语词精简不依赖词典，依赖 AI 通读时按上下文判定
• 不确定的，保留原文 + 进 log，比改错了好
• 校对日志是纠错质量的承载体，每条决策都要可追溯

10. AI 培训类转录稿高频 ASR 误转写模式（沉淀自 5th/6th 组踩坑）

本节是从 260606_AI技能创新大赛 转录稿 v1 → v3 三轮迭代中实际命中的高频 ASR 误转写模式。遇到类似主题的转录稿（法律 AI 培训、技术分享、产品介绍）时优先扫描。

通用工作流仍按 §1 走（三重确认 + 上下文明确），本节只提供"启动点"和"形式漂移证据"。

10.1 中文同音字 / 形近字误转写

10.2 英文专有名词音节丢失 / 错位

10.3 英文专有名词被中文重码替代

10.4 复合错（断词 + 漏字 + 音节错位同时出现）

10.5 弱语义同音字（高频易漏）

10.6 词典中"AI 培训类通用项"建议

如长期处理法律 AI / 编程 AI 培训类转录稿，建议在 user_dictionary.yaml 中至少登记以下项（跨用户通用，可入 user_dictionary.example.yaml）：

terms:
  - "Alpha"          # ASR 误转写为"阿尔法"
  - "腾讯元宝"       # ASR 误转写为"腾讯文宝/文巴里/文和巴里"
  - "WorkBuddy"      # ASR 误转写为"work body/work by/work party/沃克巴里"
  - "Claude Code"    # ASR 误转写为"cloud code"
  - "DeepSeek"       # ASR 误转写为"deepseek/deep sick"
  - "MCP"            # ASR 误转写为"M C P"
  - "AI"             # ASR 误转写为"A I/ai"
  - "Auto"           # ASR 误转写为"auto"（模型选择模式）
  - "skill"          # ASR 误转写为"style/scale"

11. 段中并列停顿 啊 / 哦 的识别模式

口语词精简中最容易误删的是并列停顿——它和"段中独立 填充停顿"同形，但承担并列连接功能。

11.1 识别模式

11.2 三重确认

1. 位置：并列停顿 啊 必在两个可独立成义的名词/动名词之间，中间有顿号 / 逗号隔开（不是直接 + 名词）
2. 删除无损测试：删后并列结构是否仍通顺？
   • 证据啊，包括 删后变 证据，包括 — 仍并列通顺
   • 但语气上的"列举感"减弱
   • 因此并列停顿 啊 保留比删好（保留信息密度）
3. 内容负担：并列停顿 啊 后必接具体内容（如"包括"展开），不是"认知停顿后接完整内容"（"呃……这个怎么解释呢" 整段保留规则）

11.3 实战中容易混淆的边界

12. 必检清单（防止 v1 漏跑 bug 重现）

v1.0.2 跑转录稿时漏跑了 Step 3.3 整个章节，correction_log.md 中没有"口语词精简"小节，但代码实际"完成"了。这是校对质量的承载体失守。本节列出必检项，每次跑完后用 grep 自检。

12.1 correction_log.md 必检项

每次跑完，验证以下内容都存在：

# 必检 1：log 中必须包含"口语词精简"小节
grep -q "## 口语词精简" correction_log.md
# 或 v2 激进版后
grep -qE "(## 口语词精简|## Step 3\.3)" correction_log.md

# 必检 2：log 中必须包含"高置信替换"小节（Step 3.1 跑了）
grep -q "## 高置信替换" correction_log.md

# 必检 3：log 中必须包含"基础空白清理"小节（Step 3.2 跑了）
grep -q "## 基础空白清理" correction_log.md

# 必检 4：meta.json 记录了本轮 step36 数
grep -q '"total_step36_filler_removals"\|"step36"' meta.json

12.2 correction_log.md 必含字段

12.3 meta.json 必含字段