Transcription Corrector

Transcription Corrector

首次使用流程见 references/first_use.md。工作流中的判断准则见 references/correction_patterns.md。

概述

把 raw 转录稿里"听得对但写不对"的同音/形近/拼写错误按用户词典统一改对，并按需做轻度润色。不做：改写、总结、删减、改事实、生成课程章节。

与下游处理工作的边界：

• 本 skill 不输出课程大纲、不重组章节、不改写为书面课程；只做"读起来对、不再丢脸"这一步。
• 用户词典 YAML 格式（version + terms 列表）已成为本 skill 公开的接口约定；其他下游处理工作可以按需读取同一份词典文件。

工作流程

工作流按 5 个 Phase 组织，每个 Phase 含 1-3 个 Step。默认开启 Phase 1-3，Phase 4 默认关闭（需要用户明确开启）。

Phase 1 准备
  Step 1.1  读取配置（词典）
  Step 1.2  TXT → MD 转换（如需要）

Phase 2 识别
  Step 2.1  识别文件结构
  Step 2.2  通读识别高置信误转写

Phase 3 修正（默认开启）
  Step 3.1  词典统一替换（改字）
  Step 3.2  基础空白清理（改空白）
  Step 3.3  口语词精简（删字）

Phase 4 润色（默认关闭）
  Step 4.1  发言人合并
  Step 4.2  标点规范
  Step 4.3  段落切分

Phase 5 输出
  Step 5.1  主归档（必出）
  Step 5.2  源文件目录镜像（必出）

为什么这样分组：

• Phase 1 准备 vs Phase 2 识别 vs Phase 3 修正：准备不接触文本内容；识别是"看"；修正是"改"。三者性质分明
• Phase 3 内部三个 Step 改的是三类不同对象：3.1 改字（语义）、3.2 改空白（格式）、3.3 删字（语言字符）。三类操作各自独立，可单独审计
• Phase 3 vs Phase 4：Phase 3 是"读起来对"（无损 / 轻损），默认开启；Phase 4 是"看起来专业"（结构调整），默认关闭。两者泾渭分明
• Phase 5 输出 与前 4 个 Phase 解耦：无论前 4 步做了什么，输出阶段都按相同策略双写

---

工作机制

转录稿修正的本质是"对每一处误转写做出独立判断"。这个判断的输入是上下文，输出是一处 Edit，三者必须由同一个 agent 在同一个上下文里完成。

为什么按"每处 Edit"展开

• 每处误转写是否成立，取决于它在上下文中的指向。例如"style"可能是 skill 名，也可能是真正的"风格"——批量替换不能区分。
• ASR 错误无穷无尽（大小写漂移、空格漂移、断词重连、音节吞并、形近字……），任何静态规则都会漏。
• 词典是"目标值参考表"，不是"错误词 → 正确词"的映射。terms: ["WorkBuddy"] 告诉 agent "正确的写法是 WorkBuddy"，但不告诉 agent "这处原文是否需要改"。

由此推出自然的执行流：

1. agent 用 Read 把源文件读进上下文（必须通读全文） 2. 对每一处候选误转写，agent 在上下文中独立判断"换 / 不换" 3. 用 Edit 把每一处的决策落盘 4. 用 Write 写出 correction_log.md / meta.json / 源目录镜像

为什么这个流是自洽的

• 上下文只在 Read 之后才完整；判断必须在 Read 之后进行
• Edit 是"局部变更"工具，自然对应"每处决策"
• Write 写整文件，对应日志/元数据这种"一次性产出"
• 这三步组成了最小可执行闭环。任何其他方式（脚本批量、sub-agent 转交、regex 列表）都至少缺失其中一步的语义保证

---

Phase 1：准备

Step 1.0：加载 skill 配置（开关默认值）

skill 各项润色开关由 config/config.env 控制。加载顺序：

1. 命令行/调用参数传入的 key=value 覆盖 2. config/config.env（本 skill 自带） 3. config/config.env.example（默认值的"母本"，缺失 step 2 时用） 4. 若 step 2 和 step 3 都不存在，Phase 4 所有 Step 全部关闭，仅 Phase 1-3 跑

配置示例（config/config.env.example）：

# Phase 4 润色开关（默认全开，按需关闭）
POLISH_MERGE_SPEAKERS=true     # Step 4.1
POLISH_PUNCTUATION=true        # Step 4.2
POLISH_PARAGRAPH_SPLIT=true    # Step 4.3
POLISH_TOPIC_SECTION=true      # Step 4.4
POLISH_SUMMARY=true            # Step 4.5

# 输出策略
SOURCE_MIRROR=true             # 源文件目录镜像
SOURCE_MIRROR_CONFLICT=timestamp  # 冲突加时间戳

# 日志详细度
LOG_VERBOSITY=verbose          # verbose | compact

缺失的键统一按本节表格的"默认值"列取值（不在文件中硬编码，每个 Step 自己的 § 段注明默认值）。

Step 1.1：读取词典

1. 词典文件查找顺序（找到第一个存在的即用）：

• 命令行/调用参数传入的 dictionary 路径
• config/user_dictionary.yaml（本 skill 自带）
• 若都不存在，提示用户复制 config/user_dictionary.example.yaml 为 config/user_dictionary.yaml

2. 词典 YAML 格式：

version: 1
terms:
  - "WorkBuddy"
  - "Claude Code"
  - "Codex"

3. 词典的角色：目标值 + 置信度权重，不是触发器

• 词典项是"正确写法"——告诉 AI 目标值是什么
• 词典项不直接触发替换：AI 仍然必须先做上下文判断（这个词在当前上下文里是否指向词典项所代表的对象）
• 词典项提高候选替换的胜出权重：当 AI 在多个候选写法中二选一时，词典登记的写法优先级更高
• 也就是说：词典让"workbody / work body / Workbuddy"在竞争中更倾向被改写为"WorkBuddy"，但前提仍然是上下文明显指向 WorkBuddy 这个产品；脱离上下文的同形词不会被词典"硬拉"过去
• 不要把词典当作"错误词 → 正确词"映射表来使用
• 不要为了使用词典而强行替换普通词
• 模糊或低置信场景一律保持原文

Step 1.2：TXT → Markdown 转换（如需要）

当输入是 .txt 文件时，先做格式转换再进入 Phase 2。

触发条件：输入文件扩展名是 .txt。

转换规则（保守——只做格式包装，不改内容）：

1. 发言人 + 时间戳行（如 发言人 1 00:33:09）：

• 识别正则：^(发言人|说话人|Speaker|S)\s*[\d一二三四五六七八九十]+[\.、]?\s*(\d{1,2}:\d{2}(?::\d{2})?)$
• 转成 Markdown 加粗行：**发言人 1 00:33:09**

2. 段落间空行：连续的非空行视为同一段（保留原始换行），段落之间补一个空行 3. 不删除任何文字：空行、空白、ASCII 装饰线（---、===）等全部保留 4. 不识别 H3 / H4 标题层级：只到 H2 层级——H2 标题在 Phase 4 Step 4.4 中按"主题分章"原则插入；不主动把某段升级为 ###/#### 5. 不识别列表：不把 - xxx 改成 markdown 列表——保持原样

输出：

• 中间产物：{原文件 basename}_converted.md，保留在 archive 子目录
• 后续 Step 2.1~5.2 在 converted 副本上进行
• 原始 .txt 文件保持不动

示例：

输入（raw.txt）：

发言人 1  00:33:09
我先说一下比较好的部分，就是整个最终的报告篇幅是比较充分的。
然后大家在一开始不知道怎么样一个报告是比较完善的，也知道怎么样去借鉴他山之石。
从这个阿尔法 gpt里面的这报告相当于蒸馏他的一个一个想法啊。
这个这个在前期一开始搭基建的时候确实是很有必要的一个措施。

发言人 1  00:33:57
呃然后。我注意到咱们在最终生成法律服务意见书的时候...

输出（raw_converted.md）：

**发言人 1  00:33:09**
我先说一下比较好的部分，就是整个最终的报告篇幅是比较充分的。
然后大家在一开始不知道怎么样一个报告是比较完善的，也知道怎么样去借鉴他山之石。
从这个阿尔法 gpt里面的这报告相当于蒸馏他的一个一个想法啊。
这个这个在前期一开始搭基建的时候确实是很有必要的一个措施。

**发言人 1  00:33:57**
呃然后。我注意到咱们在最终生成法律服务意见书的时候...

不识别的格式（保持原文）：

• 没有时间戳的"发言人 1："→ 保留为正文
• "Speaker A:" → 保留为正文
• 纯文本无发言人标记 → 整段视为正文

---

Phase 2：识别

Step 2.1：识别文件结构

通读 raw 稿，识别组织方式：

• 按发言人 + 时间戳分块（如 **发言人 1 00:33:09**）— 多数 ASR 输出
• 自由段落（无显式分块）
• 混合（标题 + 段落 + 引用）

识别目的：决定 Phase 4 润色时是否合并同发言人连续发言。不要改写分块结构，保留原貌。

Step 2.2：通读识别高置信误转写

必须完整通读全文，以 Agent 视角扫描。不列静态错误表——ASR 错误无穷无尽（大小写漂移、空格、漏词、错位、同音字、形近字、断词重连、音节吞并…），任何预设列表都会漏判。

核心原则：

仅在上下文明确指向某个词典术语时，才将近似误转写替换为该术语。

模糊或低置信场景保持原文，不做猜测式替换。

启动扫描的高频易错类别（不是错误表，是判断启动点）：

1. 人名：律师、当事人、证人姓名是否首次出现 + 后续引用是否一致 2. 英文产品/工具/平台名：是否在工具使用、命令行、平台介绍等场景 3. 机构/活动/品牌名：律协、青训营、训练营、赛题 4. 法律术语同音/形近：代理 vs 带理、抵押 vs 抵压、知情 vs 至清 5. 数字/单位/时间戳：1/7、0/6、中英文逗号混用；保守原则

形式漂移识别（参考但不穷举）：

• 大小写漂移（WorkBuddy vs workbuddy vs WORKBUDDY）
• 空格漂移（work body / Work Buddy）
• 连字符（Claude-code / Claude-Code）
• 拆分被识别为中文（"克劳德 code"）
• 漏字残字（"body" 残留在"让，如果 body帮我们"）
• 同音/形近字（"张律师 / 张老师 / 章律师" 类推）
• 断词重连（"然后让" 被拆成"让，如果"）

禁止：

• 只用 grep/正则匹配清单（必然漏）—— 详见 §"工作机制"为什么按每处判断展开
• 把"我"改成"我们"等无明确对照的"风格化"改写
• 替换词典外的术语
• 强行补全"看上去缺字"的句子——除非能确定是组合错误

---

Phase 3：修正（默认开启）

Phase 3 三个 Step 改的是三类不同对象——Step 3.1 改字（语义）、Step 3.2 改空白（格式）、Step 3.3 删字（语言字符）。三类操作各自独立、可单独审计、单独计日志。

Step 3.1：词典统一替换

对 Step 2.2 识别出的高置信误转写：

1. 三重确认：

• 词典里有对应目标值
• 上下文明确指向该目标值所代表的对象
• 形式漂移证据成立（大小写/空格/连字符/漏字/同音/形近/断词）

2. 三重任一不满足 → 不替换，保持原文 3. 替换完成后在 correction_log.md 记录：{原文} → {改后}，并标注行号和上下文片段 4. 绝不修改原始文件，所有输出写到 archive/ 下的新文件

Step 3.2：基础空白清理（默认开启，无损）

为什么独立于 Phase 4 润色：基础空白清理是"格式标准化"，不改变原文语义、不删减任何信息；与 Phase 4 发言人合并 / 标点规范 / 段落切分那种"风格调整"性质不同，所以默认开启（用户不需要为此做开关决策）。

清理动作清单（仅做以下五类，不做任何超出此范围的事）：

标点周围空白规则：

• 中文标点 ，。、；：？！""''「」（） 前后不留空格（若出现则删除）
• 英文标点 , . ; : ? ! " ' ( ) 后空一格（中文段落中保留）
• 半角空格夹在中文之间 → 删除

严格不做（避免越界）：

• 不删除任何文字、标点、字母、数字
• 不改变段落结构（不合并段落、不切分段落——这是 Phase 4 范畴）
• 不修改数字、时间戳、金额、日期
• 不改发言人分块标记（如 **发言人 1 00:33:09**）
• 不重排、重组、归纳

与 Step 3.1 的关系：基础空白清理在 Step 3.1 词典替换之后执行；遇到"Work Buddy" → "WorkBuddy" 这类专有名称合并时，优先走 Step 3.1（词典替换路径），Step 3.2 仅做 Step 3.1 不覆盖的"无词典目标的纯格式"清理。

校对日志记录：所有 Step 3.2 的清理动作也写到 correction_log.md，在"基础空白清理"小节集中记录（与 Step 3.1 高置信替换区分开），便于审计。

Step 3.3：口语词精简（默认开启，AI 上下文判断）

为什么独立于 Phase 4 润色：与 Step 3.2 基础空白清理性质相同——属于"读起来对"的范畴，不改变原意（口语词不携带信息）；与 Phase 4 发言人合并 / 标点规范 / 段落切分那种"风格调整"性质不同，所以默认开启（用户不需要为此做开关决策）。

白名单（可删的纯填充词）——AI 通读时识别"作为填充词 vs 作为实义"，仅删独立出现且无语义负担的：

保留规则（不删）：

• 表态类："嗯"/"对"/"是的"/"不是"/"好的"/"是" 作肯定 / 否定 / 回应 → 保留（删了会丢失说话人态度）
• 逻辑连接："然后"作逻辑连接词（"先 A 然后 B"）→ 保留（删了破坏时序）
• 认知停顿后接完整内容："呃……这个怎么解释呢" 整段保留——"呃"虽属白名单，但"认知停顿 + 完整内容"是说话人思考过程的真实记录，整段保留比逐字删更尊重原文
• 段尾的语气停顿（"嗯"/"啊"/"呃"出现在段末）——保留（标记说话节奏收束）
• 紧邻关键名词 / 动词——保留（可能是说话人强调）
• 实义词（名词 / 动词 / 形容词 / 副词）——一律不删

段首 vs 段尾 vs 段中 决策树：

详见 references/correction_patterns.md §11 段中并列停顿 啊 的识别模式。

判断原则：

• 与 Step 3.1 一样遵循"通读全文 + 三重确认"思路
• 三重确认：① 该词在当前上下文是否属于白名单词类；② 在当前位置是否独立使用、是否承担实义；③ 删后不破坏说话人态度 / 时序 / 强调
• 任一不满足 → 不删，保留原文
• 模糊或低置信场景一律保留原文

严格不做（避免越界）：

• 不删整句、不删段落
• 不删实义词（即使重复）
• 不删关键信息（数字、人名、专有名、术语）
• 不改写为书面语、不补全、不改语气
• 不删"呃 / 啊"作认知停顿后接完整内容的版本
• 不删"段尾"的关键节奏标记（v2 激进版起，段首节奏标记默认删除）

校对日志记录：所有 Step 3.3 的精简动作写到 correction_log.md 的"口语词精简"小节，格式：

| 行号 | 原文片段 | 被删词 | 理由 |
|------|----------|--------|------|
| L207 | "呃 这个怎么说呢，我们今天来" | "呃" | 段首认知停顿，后接"怎么说呢"+完整内容，整段保留——本行不删（认知停顿后接完整内容的"呃"按 §3.3 保留规则例外）|
| L312 | "对，所以呢，我们" | "所以呢" | "所以呢" 不在白名单，保留 |
| L451 | "然后呢我们看一下" | "然后呢" | 段首过渡填充，可删 |

与 Step 3.2 的关系：Step 3.2 动空白字符，Step 3.3 动语言字符。两者都是"读起来对"操作，都默认开启，都在 correction_log.md 单独小节集中记录。

必检（防止漏跑整节）：跑完必须 grep 自检（详见 references/correction_patterns.md §12）：

• correction_log.md 必须包含 ## 口语词精简 小节
• correction_log.md 必须包含 ## 高置信替换 / ## 基础空白清理 / ## 口语词精简 / ## 未处理 四个小节
• meta.json 必含 summary / process_time / dictionary_source / polish_enabled 字段
• v1.0.2 漏跑 Step 3.3 整节无日志——本必检项是那次 bug 的复盘产物

---

Phase 4：润色（可选，按 config 开关决定）

Phase 4 下的所有 Step 由 config/config.env 配置文件中的开关决定是否启用。每个 Step 默认值的来源：

• 缺失 config.env：用 config.env.example 的值（即默认值）
• 缺失 config.env.example：用本节速查表的默认值

Step 4.4：主题分章 + H2 标题插入（默认开启）

触发条件：话题发生明确切换（不同讨论对象 / 不同议程 / 不同主体焦点）时，插入 ## 一、标题 行；同一话题内部的子切换不插入。

识别原则：

• 硬切换信号：双方反复回到同一对象 → 突然讨论另一对象（如"工具 → 律所管理"、"产品 → 客户关系"、"代码 → 知识库"）→ 插入 H2
• 软切换信号：仅是追问或深化（如"工具 A → 工具 A 的细节"）→ 不插入
• 不强行覆盖全文：开头寒暄 / 中间过渡闲聊 / 结尾收束 → 不强制加 H2，让它归在第一个/最后一个 H2 之下

标题文本从何而来：

• 不编造标题——agent 从该段上下文中提取 3-10 字主题词（如"工具选择与日常使用"、"本地部署与脱敏"、"知识库维护"）
• 标题文本应不与发言人姓名、时间戳、专有名重复——避免与原文混淆
• 同一段内多次 H2 用相同主题词时，去重

编号规则：

• 全文 H2 标题按出现顺序加中文大写数字序号：一、、二、、三、...
• 数字与标题文本之间用 、 顿号分隔（中文正式排版惯例）：## 一、工具选择与日常使用
• 序号连续编号，不跳号；中途若发现需要补插，agent 重新连续编号（不留断号）
• 同一份 corrected.md 中序号唯一，不重复

严格不做：

• 不重组内容顺序
• 不改写任何正文
• 不总结或提炼（标题文本只是该段已说内容的提取，不引入新信息）
• 不加 H3 / H4（本 skill 只到 H2 层级）
• 不为单个话题切分加 H2（哪怕该话题横跨 1000 字）

校对日志记录：所有 Step 4.4 的插入写到 correction_log.md 的"主题分章"小节（与 Step 4.1/4.2/4.3 区分），格式：

| 行号 | 标题文本 | 上下文锚点（前后 50 字）| 切换类型 |
|------|----------|------------------------|----------|
| L487 | ## 律所管理与本地部署 | "...他就不会愿意去做这个事事情。" | 硬切换 |

与 Phase 4 其他 Step 的关系：Step 4.1-4.3 是"风格调整"，Step 4.4 是"结构标注"——前者改分块形式，后者只插入锚点，不重排。

为什么本 skill 做这个而不下游做：原 §1.2 早期版本说"下游做章节重组时再处理"，但下游 skill（如 course-generator）做的是"基于转录稿生成课程"，与"忠实标注原话结构"是不同任务。H2 主题分章是"忠实标注"，放在本 skill 更合身。

Step 4.5：会议纪要 / 总结生成（默认关闭，按 POLISH_SUMMARY 开关）

触发条件：

• 配置开关 POLISH_SUMMARY=true，或用户在调用时显式声明（"生成纪要" / "总结" / "AI 洞察"）
• 必须 Step 4.4 已先跑过——没有 H2 边界就没有"按章节"颗粒度

输出位置：

• 修改 `corrected.md`，在文件顶部插入 summary 块
• 不创建独立 _summary.md 文件（v1.3 修订：原"独立文件"方案已改为"嵌入 corrected.md"）
• 源文件目录镜像随 corrected.md 同步

插入位置与标记（funasr-transcribe 风格）：

• 位置：在 H1 标题之后、第一个 H2 之前
• 标记：<!-- AI-SUMMARY:START --> / <!-- AI-SUMMARY:END --> 包住整个 summary 块
• 幂等：再次跑批时若 markers 已存在，替换旧 summary（用 re.sub 模式），不重复插入

结构：

# 原文件 H1 标题（如有）

<!-- AI-SUMMARY:START -->

## AI 摘要

**主标题**：5-15 字概括全文核心议题

### 一、章节名（与 Step 4.4 H2 一致；H3 而非 H2，避免与原话 H2 同级）

**本章摘要**：50-100 字概括本章节核心内容（引用原话中的具体事实/数字/专有名，不引入新事实，不评价）

**关键洞察**：
- 洞察 1（15-30 字，横向观察本章节）
- 洞察 2
- 洞察 3

### 二、章节名

**本章摘要**：...

**关键洞察**：
- ...

（其他章节同上）

**关键词**：5-8 个逗号分隔

<!-- AI-SUMMARY:END -->

## 一、章节名（原话正文）
...

为什么是 H3 而非 H2：

• corrected.md 文件中 H2 是"原话章节"（Step 4.4 标记的）
• summary 中的章节若也用 H2，会和原话章节在视觉上混淆
• summary 的章节用 H3（在 ## AI 摘要 之下），层级关系清楚：原话章节 > 摘要章节

生成原则：

1. 主标题：从全文最核心议题提取 5-15 字主题词 2. H3 章节：与 Step 4.4 的 H2 一一对应（不重切话题） 3. 本章摘要：

• 长度：50-100 字
• 引用原话中的具体事实/数字/专有名（不抽象化）
• 不引入原话外的事实
• 不评价（除非有原话支持）
• 紧贴本章节原话概括，不跨章节

4. 关键洞察：

• 数量：2-3 条（不强求 3 条；段落短就 2 条）
• 长度：每条 15-30 字
• 来自本章节的横向归纳，不来自某一段
• 不带"应该""必须""建议"等评价语气
• 形如"X 群体呈现 Y 趋势"、"X 与 Y 之间存在 Z 鸿沟"

5. 关键词：

• 数量：5-8 个
• 来源：原话中反复出现或具有区分性的名词/产品名/概念词
• 格式：逗号分隔一行

严格不做：

• 不引入原话外的事实
• 不重切 H2 边界（summary 的 H3 必须与原话 H2 一一对应）
• 不评价（除非有原话明确支持）
• 不在 summary 内加 H4 / H5
• 不写"行动项 / 决议 / 后续 TODO"（除非原话明确提到）

与 Step 4.4 的边界：

幂等与验证：

• 再次跑批时，若 markers 已存在，正则替换 旧 summary 块
• 跑完后用 grep -c "<!-- AI-SUMMARY:START -->" 验证 markers 存在
• 验证摘要字节数 > 200（防止空摘要被注入）

校对日志记录：Step 4.5 的产出写到 correction_log.md 的"会议纪要"小节，格式：

| 字段 | 值 |
|------|-----|
| 主标题 | 主标题文本 |
| 章节数 | 7（与 Step 4.4 H2 一致）|
| 总洞察数 | X 条 |
| 摘要字数总计 | Y 字 |
| 注入位置 | H1 之后，第一 H2 之前 |
| 标记验证 | <!-- AI-SUMMARY:START --> 已存在 |

---

Phase 4 整体边界（适用于 Step 4.1-4.4）：

• 改写为书面语
• 总结、提炼、删除"啰嗦"内容（Step 4.5 是唯一例外——它明确做"摘要 + 洞察"）
• 补全或推测说话人意图
• 改事实、改数字、改时间戳

---

Phase 5：输出

输出采用 双写 策略：主归档在 skill 内部，源文件目录同步一份易访问副本。原始文件保持不动。

Step 5.1：主归档（必出）

输出位置：{skill 目录}/archive/{YYYYMMDD_HHMMSS}_{原文件 basename}/

文件：

• {原文件}_corrected.md — 纠错后的完整文本（保留原始分块结构）
• {原文件}_polished.md — 仅在用户开启润色时生成
• correction_log.md — 校对对照日志
• meta.json — 处理时间、词典来源、是否润色、原始文件路径

Step 5.2：源文件目录镜像（必出）

输出位置：原始文件所在目录（与原文件同目录）。

文件：

• {原文件 basename}_corrected.md — 与 5.1 内容完全一致，仅是易访问副本
• 命名规则：原文件名后追加 _corrected 后缀，扩展名改为 .md（原文件是 .md 时，输出仍为 .md；原文件是 .txt 时，输出为 .md）

为什么双写：

• 主归档承担"可追溯 + 校对日志 + 元数据"的完整档案职责
• 源文件目录副本让用户在日常文件管理器中能直接看到"已校对版"，免去每次去 skill 内部目录翻找
• 双写的内容是字节级一致的 _corrected.md（polished 副本与 log 不镜像——它们的主归档位置就在 skill 内部）

冲突处理：

• 源文件目录已存在同名 _corrected.md → 用时间戳后缀区分（_corrected_20260608_153022.md），避免覆盖历史校对结果
• 源文件目录只读 / 不可写 → 静默跳过源文件目录镜像，仅输出主归档；在 meta.json 记录 source_mirror: "skipped"
• 源文件路径无法解析（如 stdin 输入）→ 同样静默跳过源文件目录镜像

原始文件保持不动——双写策略只生成"新文件"，绝不就地修改原文件。

Step 5.3：稳定版标记（可选）

当某次跑出的 _corrected.md 经用户确认无问题、视为该转录稿的"稳定版"时，在该 archive 子目录下加 STABLE.md 标记文件：

# Stable Version Marker

**v3 (2026-06-08 12:00) 标记为该转录稿的稳定版本。**

## 为什么 v3 是 stable

- v1.0.0 (2026-06-07 14:30) — 7 处，仅 Step 3
- v1.0.2 (2026-06-08 00:41) — 42 处，Step 3 + 3.5，漏跑 Step 3.6
- v2 (2026-06-08 11:00) — 170 处，补跑 Step 3.6（84 处）
- v3 (2026-06-08 12:00) — 226 处，激进版段首删除（+52 处）

## 锁定本版本

- 后续不再对 `260606_AI技能创新大赛_corrected.md`（v3）做改动
- 源文件目录三个版本并列保留供对比
- 如发现新的误转写需要补判，新建 `archive/<新时间戳>_*` 目录重跑，不就地修改 v3

为什么需要 STABLE.md：

• archive 目录会累积多轮迭代产物（v1.0.0 / v1.0.2 / v2 / v3 ...），未来 agent / 用户 / 下游 skill 进来不知道哪个是终版
• 源文件目录的镜像文件（_corrected_v3_20260608_120000.md）按时间戳命名，本身是"稳定"暗示，但 archive 内部 260606_AI技能创新大赛_corrected.md 没 STABLE 标记会被误认成"最新版"
• STABLE.md 让"哪个是终版"显式可查

什么时候不写 STABLE.md：

• 一次性试跑、用户没确认 / 校对量少 / 转录稿本身还要后续处理——不必强行标记
• 已经有更新的版本稳定了——避免给旧版加 STABLE 误导下游

Step 5.4：旧版本清理策略

archive 目录会保留每次跑的全量产物（主归档 + correction_log + meta.json），不主动清理历史版本。但当 archive 下子目录数 ≥ 5 时，建议在 STABLE.md / DECISIONS.md 备注保留策略：

• 保留：每次的 _corrected.md / correction_log.md / meta.json（记录完整迭代轨迹）
• 可清理：当 archive 累积 ≥ 5 个目录时，旧的 analysis_report.md 等中间产物可手动归档
• 禁止清理：被 STABLE.md 标记的稳定版目录的 _corrected.md（用户可能要从源文件目录镜像之外的路径找回终版）

校对对照日志格式（correction_log.md）

# 校对对照日志

- **原始文件**：/path/to/raw.md
- **处理时间**：2026-06-07 14:30:22
- **词典来源**：`config/user_dictionary.yaml`（含 18 项术语）
- **润色开关**：关闭

## 高置信替换

| 原文 | 改后 | 出现次数 | 上下文示例 |
|------|------|----------|------------|
| workbody | WorkBuddy | 3 | "通过第二版呢进行测试..." |
| work body | WorkBuddy | 2 | "我们把这个实践中办案..." |
| claude-code | Claude Code | 1 | "...重新调回那个 claude-code 里面..." |

## 未处理（保留原文）

- "智能件" — 上下文不足以判断是否为"智能体"
- "代理" — 同上

## 润色变更（如开启）

- 合并发言人 1 连续 3 段为 1 段
- ...

适用场景 / 不适用

见 references/scope.md。

配置示例 / 配置解耦原则

见 references/config-decoupling.md。

参考文档

• references/scope.md — 概述 / 适用边界
• references/config-decoupling.md — 配置示例 / 配置解耦原则（评价规范相关）
• references/first_use.md — 一次性配置引导（复制 example.yaml、跑试跑、多用户软链）
• references/correction_patterns.md — 工作流判断准则（误转写识别、口语词精简、并列停顿、必检清单、ASR 高频模式）
• config/user_dictionary.example.yaml — 词典公开模板

变更日志

本项目的所有重要变更都将记录在此文件。

[1.0.7] - 2026-06-08

重构

• references/skill_overview.md 拆分为两份 — 拆成 references/scope.md（概述 / 适用边界）与 references/config-decoupling.md（配置示例 / 配置解耦原则），单一职责更清晰。原 skill_overview.md 删除。SKILL.md "适用场景 / 不适用" 与 "配置示例 / 配置解耦原则" 两个跳转锚点分别指向对应文件；参考文档列表同步更新。DEC-013 落地
• references/ 子文件无 frontmatter — 删除 references/skill_overview.md 中冗余的 name / description frontmatter 块；scope.md / config-decoupling.md 新建时即不带 frontmatter（frontmatter 是 SKILL.md 唯一元数据来源）

文档清洁

• 公开文件清理外部 skill / 项目引用 — DECISIONS.md 中 6 处 "课程生成类工作流" 改为 "课程整理类工作流"；1 处 "借鉴 OCR 后处理中'基础空白清理'思路" 改为 "新增 Step 3.5 基础空白清理"（去除借鉴标注）；2 处 "agent 报告" 改为 "分析反馈"；DECISIONS.md "明确不放的" 列表去掉具体产品名（"Devonthink、Antigravity、Moltbook、Vibe Coding、Vibe Working、Manus、FunASR、MinerU 等" 改为 "仅本机使用的特定技术栈产品"）。CHANGELOG.md v1.0.0 段落 "听悟" 改为 "云端 ASR"。本条覆盖自检。
• frontmatter description 重写（按"功能 / 触发 / 不触发"三段式） — 从 369 字符（v1.0.6）压到约 116 字符（v1.0.7）："转录稿纠错与轻度优化。本技能应在用户需要按用户词典纠正 ASR 转录稿同音字与英文专有名称漂移时使用。不要用于：重写为课程章节、报告、总结，或完全空白的素材创作。" 归档策略 / 原始文件不动 / 内部步骤 / 默认行为 / 产物结构全部移除——这些应出现在 SKILL.md 正文，不应进入 description 触发指纹。对齐 skill-architect 5.17。

元数据

• frontmatter version 1.0.6 → 1.0.7

---

[1.0.6] - 2026-06-08

文档

• SKILL.md 拆分以达 skill-architect 500 行建议 — 把"概述 / 适用场景 / 不适用 / 配置示例 / 配置解耦原则 / 参考文档"6 个章节从 SKILL.md 拆到 references/skill_overview.md。SKILL.md 从 528 行降到 445 行（-83），聚焦"工作流骨架"。新增 references/skill_overview.md 121 行，明确三个 references 文件的职责分工：
• first_use.md — 一次性配置引导
• correction_patterns.md — 工作流判断准则
• skill_overview.md — 概述/适用边界/配置示例/解耦原则

SKILL.md 顶部 frontmatter description 仍 137 字符，未变（description 只描述触发场景，不重复概述）。 references 内已有 frontmatter（name/description）便于未来的 skill-architect 审查

---

[1.0.5] - 2026-06-08

行为规则

• Step 体系重构为 5 个 Phase — SKILL.md 工作流从 Step 0/0.5/1/2/3/3.5/3.6/4/5 整数小数混用重构为 5 个 Phase + 子步骤：
• Phase 1 准备：Step 1.1 读取配置 / Step 1.2 TXT→MD 转换
• Phase 2 识别：Step 2.1 识别文件结构 / Step 2.2 通读识别高置信误转写
• Phase 3 修正（默认开启）：Step 3.1 词典统一替换（改字）/ Step 3.2 基础空白清理（改空白）/ Step 3.3 口语词精简（删字）
• Phase 4 润色（默认关闭）：Step 4.1 发言人合并 / Step 4.2 标点规范 / Step 4.3 段落切分
• Phase 5 输出：Step 5.1 主归档（必出）/ Step 5.2 源文件目录镜像（必出）

重构理由：原"0.5/3.5/3.6"小数命名让人误以为是 Step 3 的子步骤，但实际和 Step 4（润色）同级。Phase 分组后"准备 / 识别 / 修正 / 润色 / 输出"五阶段性质分明，Phase 3 内部三个 Step 改的是三类不同对象（字 / 空白 / 填充词），各自独立可单独审计。DEC-009

• Step 3.3 加段首/段中/段尾决策树 — SKILL.md Step 3.3 新增"段首 vs 段尾 vs 段中 决策树"表格，明确位置判定标准和处理（v2 激进版起）。配合 references/correction_patterns.md §11"段中并列停顿 啊 的识别模式"，把口语词判断从经验变成可查表

文档

• SKILL.md frontmatter version 升 1.0.5
• references/correction_patterns.md 全面同步 step 引用：从 Step 0/3/3.5/3.6/4 更新为 Step 1.1/3.1/3.2/3.3/4.1/4.2/4.3 Phase-based 编号
• SKILL.md Phase 3 顶部加导航说明："改字 / 改空白 / 删字"三类操作性质独立可单独审计

---

[1.0.4] - 2026-06-08

行为规则

• Step 3.6 段首节奏标记默认删除（v2 激进版起）— SKILL.md §3.6.2 保留规则从"段首/段尾的语气停顿——保留"改为"段尾的语气停顿——保留（标记说话节奏收束）"；references/correction_patterns.md §7.2 同步更新；典型案例表 L207 行的理由说明同步更新。理由：v1 → v2 → v3 三轮迭代中用户明确反馈"呃没删干净"——段首节奏标记保留的实用价值低于段尾收束语义。DEC-008 落地
• Step 3.6 必检清单 — SKILL.md Step 3.6 末尾新增"必检"小节，要求 agent 在 correction_log.md 中必须包含"口语词精简"小节、按段首/段中/段尾三类分别计数。避免 v1.0.2 那种"漏跑整节无日志"的 bug 重现。DEC-008 复盘

知识沉淀

• ASR 误转写高频模式（5th/6th 组踩坑沉淀） — references/correction_patterns.md 新增 §8"AI 培训类转录稿高频 ASR 误转写模式"，枚举本轮命中 6 类：
• 中文同音字误转写（阿尔法→Alpha、腾讯文宝→腾讯元宝）
• 英文专有名词音节丢失（沃克巴里→WorkBuddy、work by→WorkBuddy）
• 英文专有名词被中文重码替代（cloud code→Claude Code、deep sick→DeepSeek）
• 大小写漂移（A I→AI、M C P→MCP、auto→Auto）
• 复合错（断词 + 漏字）"让，如果 body 帮我们"→"让 WorkBuddy 帮我们"
• 弱语义同音字（style/scale→skill、out style→out skill）
• 段中并列停顿 啊 的识别模式 — references/correction_patterns.md §7.5 增补：并列停顿 啊 在两个名词/动词短语之间充当连接，删除会破坏并列结构（如"证据啊，包括"、"合同啊、结算单啊"）。识别要点：前后都是可独立成义的名词/动名词 + 顿号/句中位置。区分于纯填充 段中独立 啊
• 多轮迭代处理流程 — SKILL.md §0 增加"多轮迭代"小节：第二轮起的 source file 是上一轮 _corrected.md（不是 raw）；Step 3 仅处理 v1 未替换的新项；Step 3.6 按当前规则（含激进版开关）跑全量

文档

• "首次使用"小节下移到 references/first_use.md — SKILL.md 主体聚焦工作流骨架；"复制 example.yaml、维护本地词典、跑一次试跑、多用户软链方案"等一次性配置引导放到独立 references 文件；SKILL.md 顶部加引用块指向该文件 + correction_patterns.md
• SKILL.md 一级标题去掉版本号 — # Transcription Corrector v1.0.3 → # Transcription Corrector；版本号仅保留在 frontmatter version 字段
• "配置解耦原则"小节明确归类为"评价规范" — 顶部加"本节是 skill 公开化时需要满足的评价规范的一部分，与工作流无关"的定位说明，并列出模板/实际配置/敏感数据三条核心约定；与 skill 公开化审查清单的配置文件规范对齐
• references 目录新增 first_use.md — 与 correction_patterns.md（工作流判断准则）分工清晰

[1.0.3] - 2026-06-08

新增

• Step 3.6 口语词精简（默认开启） — 新增独立步骤，删除独立出现的纯填充词（"呃/啊/哦/哎"、"那个/就是说/然后呢/对吧/你知道吗/怎么说呢/这样子/其实呢/但是呢"）。与 Step 3.5 基础空白清理同级，默认开启（仅删白名单纯填充词、不改风格）。明确"表态类/逻辑连接/认知停顿后接完整内容/段首段尾"等保留规则，三重确认判断
• example.yaml 扩展为"常见技术名词 + 常见法律术语" — 公开模板新增 27 项：技术名词（Cursor、Anthropic、OpenAI、Coze、Ollama、Manus、Moltbook、DeepSeek、腾讯元宝、豆包、智和、Alpha、Obsidian、Flomo、Cubox、FunASR、MinerU、Discord、Slack、Docker、Playwright、MonoRepo、clawhub、GitHub、Markdown、MCP、AI）+ 法律术语（商标、著作权、合同、诉讼、仲裁、代理、律师、当事人）。遵守"换另一个用户 clone 也需要"的边界
• references §7 口语词精简规则 — 白名单/保留规则/判断原则/严格不做/典型易误判案例 5 小节
• references §6.4 步骤对照表扩展 — 把"Step 3 改字、Step 3.5 改空白、Step 4 改结构"扩为"Step 3 改字、Step 3.5 改空白、Step 3.6 删填充词、Step 4 改结构"

改进

• 本地词典采纳实战反馈 — user_dictionary.yaml 追加：DeepSeek、Auto、AI、MCP、腾讯元宝、豆包、智和、Alpha、supreme legal analyzer、C1-C6、六大矛盾、四大图表
• 配置解耦原则明确收纳范围 — SKILL.md"配置解耦原则"小节细化"换另一个用户 clone 也需要"的判定标准；明确 example.yaml 收纳常见技术名词 + 常见法律术语，但不放个人工作栈 / 个人身份 / 极通用词

[1.0.2] - 2026-06-08

新增

• 基础空白清理（Step 3.5，默认开启） — 独立于 Step 3 词典替换与 Step 4 润色，作为"无损格式化"步骤默认开启。覆盖行首/行尾多余空格、连续空行压缩、英文单词间全角空格、半角空格夹在中文之间、中文数字+空格+级/章/节合并、中文/英文标点周围空白标准化。专有名称内部断裂空格的合并仍走 Step 3 词典替换路径
• 源文件目录镜像（Step 5.2） — 在保留 skill 内 archive/ 主归档的同时，向原始文件所在目录同步输出一份 {原文件}_corrected.md 易访问副本。冲突时用时间戳后缀区分，源文件目录只读 / 不可写时静默跳过并在 meta.json 记录 source_mirror: "skipped"

改进

• 公开文件不出现其他 skill 名称 — SKILL.md / CHANGELOG.md / DECISIONS.md / TASKS.md / references/correction_patterns.md / config/user_dictionary.example.yaml 中所有对外部 skill 名称的引用（课程生成类、通用转录引擎、其他工作流等）替换为通用描述；保留与 transcription-corrector 自身相关的工作流引用
• 本地用户词典扩展 — config/user_dictionary.yaml 追加个人工作栈常用术语（Devonthink、Cursor、Antigravity、Anthropic、OpenAI、Discord、Slack、Obsidian、Coze、Ollama、Flomo、Cubox、MinerU、FunASR、Docker、Playwright、MonoRepo、Manus、Moltbook 等）、工程概念术语（commit / push / pull / frontmatter 等）与业务领域术语（知识产权、专利）；保留"目标值+权重"原则

文档

• SKILL.md 新增"Step 3.5 基础空白清理"小节
• SKILL.md 重写"Step 5 输出"为双写策略（5.1 主归档 + 5.2 源文件目录镜像）
• references/correction_patterns.md 新增"§6 基础空白清理规则"小节
• DECISIONS.md 新增 [DEC-008] 基础空白清理作为独立步骤的决策
• DECISIONS.md 新增 [DEC-009] 双写输出策略的决策
• DECISIONS.md 修订 [DEC-001] [DEC-003] 等历史决策中所有对外部 skill 名称的引用为通用描述

[1.0.1] - 2026-06-07

新增

• TXT 输入支持 — 新增 Step 0.5：当输入是 .txt 文件时，先做格式转换（识别发言人+时间戳行转 Markdown 加粗、保留原始分块、输出 _converted.md 中间产物）再进入 Step 1
• 配置解耦原则 — SKILL.md 新增"配置解耦原则"小节，明确 example.yaml（入仓）与 user_dictionary.yaml（git ignore）的边界
• 首次使用提示 — SKILL.md 顶部加"首次使用"小节，引导用户复制 example → 改名为真实配置
• skill 局部 .gitignore — config/.gitignore 声明 user_dictionary.yaml 不入仓

改进

• description 精简 — frontmatter description 从 4 句压缩到 1 句；"不适用场景"挪到正文"不适用"小节
• 公开文件不出现作者名 — CHANGELOG / TASKS / DECISIONS / references / example.yaml 中"作者本人姓名"作为描述示例的提及全部移除；保留 frontmatter 的 author 字段

[1.0.0] - 2026-06-07

新增

• 转录稿纠错与轻度二次优化 — 读 raw 转录稿（本地转录引擎 / 云端 ASR 等输出），按用户词典纠正同音字、英文专有名称大小写与拼写（WorkBuddy、Claude Code 等）
• 用户词典机制 — config/user_dictionary.yaml 维护"目标值"，AI 通读全文后基于上下文判定是否替换
• 三重确认原则 — 替换前必须同时满足：词典里有目标值、上下文明确指向、形式漂移证据成立
• 校对对照日志 — 输出到 archive/{date}_{file}/correction_log.md，每条替换可追溯
• 轻度润色开关（默认关闭） — 可选合并同发言人连续发言、规范标点、切分极长段
• 原始文件保持不动 — 所有结果自包含存储在 archive/ 下
• 归档结构 — archive/YYYYMMDD_HHMMSS_{原文件}/ 内含 corrected 副本、polished 副本（如启用）、correction_log.md、meta.json
• 公开的词典 YAML 格式 — version + terms 列表结构，可与外部场景软链复用同一份用户词典

文档

• SKILL.md — 完整工作流（Step 0~5）、边界、模式选择
• references/correction_patterns.md — 误转写识别判断准则（不是映射表）
• config/user_dictionary.example.yaml — 词典模板，含"目标值+权重"原则说明

Config Decoupling

本文件聚焦配置示例 / 配置解耦原则——是 skill 公开化时需要满足的评价规范的一部分，与工作流无关。

概述 / 适用边界见 scope.md。

工作流判断准则见 correction_patterns.md。

首次使用流程见 first_use.md。

配置示例

完整公开模板：见 ../config/user_dictionary.example.yaml。包含常见技术名词（行业公认的产品 / 平台 / 格式 / 缩写）与常见法律术语（法律行业通用术语）。

最小词典（3 项起步，新用户复制后可立即使用）：

version: 1
terms:
  - "WorkBuddy"
  - "Claude Code"
  - "Codex"

进阶个性化：复制 example.yaml 为本地 user_dictionary.yaml 后，追加个人项到 terms 列表（不要覆盖 example.yaml，否则 git 同步时会丢你的本地项）：

version: 1
terms:
  # 通用项（来自 example.yaml，跨用户通用）
  - "WorkBuddy"
  - "Claude Code"

  # 个人工作栈（仅本机，git ignore）
  - "<你的工具栈 1>"
  - "<你的工具栈 2>"

  # 自定义 skill 名 / 项目编号
  - "<你的项目名 / 编号>"

  # 个人身份（仅本机，git ignore）
  - "<你自己的姓名>"
  - "<你的律所全称>"
  - "<你的客户代号>"

进阶：在多个场景间共用一份词典，可把本 skill 的 config/user_dictionary.yaml 软链到统一位置（多设备 / 多入口共用）。

配置解耦原则

核心约定：

• 模板文件命名 *.example.* → 提交
• 实际配置 user_dictionary.yaml → 不入仓（被 .gitignore 覆盖）
• 真实配置路径下不应有硬编码 API keys、Token、客户代号等敏感数据

本 skill 面向公开发布时，配置需要严格解耦：

"换另一个用户 clone 这个仓库，他需要这一项吗？"——判定标准：

`example.yaml` 当前的收纳范围：

• ✅ 常见技术名词：行业公认的产品 / 平台 / 格式 / 缩写（ASR 容易听错）
• ✅ 常见法律术语：法律行业通用术语（ASR 容易听错为同音字 / 形近字）
• ❌ 个人工作栈工具：仅本机使用的特定技术栈产品（即使"行业"可能认识，归"个人工作栈"更准确）
• ❌ 个人身份：人名、律所名、客户代号
• ❌ 极通用词：法律、法院、律师、合同（避免触发过度替换风险）

误转写识别判断准则

重要：本文件不列"错误形式 → 正确形式"映射。

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 排版，保留

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 必含字段

首次使用流程

本文件是一次性配置引导，不属于工作流判断准则。

工作流相关的判断准则（误转写识别、口语词精简边界等）见 correction_patterns.md。

1. 准备用户词典

复制 config/user_dictionary.example.yaml 为 config/user_dictionary.yaml，开始维护你的本地个性化术语。

cp config/user_dictionary.example.yaml config/user_dictionary.yaml

两个文件的分工：

判定标准："换另一个用户 clone 这个仓库，他需要这一项吗？"

• 需要（行业公认）→ user_dictionary.example.yaml
• 不需要（个人化）→ 本地 user_dictionary.yaml

详细收纳范围见 SKILL.md "配置解耦原则"小节。

2. 在本地 yaml 中追加个人项

打开 config/user_dictionary.yaml，在 terms 列表末尾追加：

terms:
  # example.yaml 已有的通用项（不要删）
  - "WorkBuddy"
  - "Claude Code"
  ...

  # 你的个人项（追加在这里）
  - "你自己的姓名"
  - "你的律所全称"
  - "你的客户代号"
  - "你的业务领域专属术语"

维护原则：

• 每次新发现 ASR 同音字 / 拼写漂移导致误转写时，把目标值追加到对应区
• 不要删除 example 里已有的通用项——这些是基础底座
• 不要为追求"用词典"而强行替换普通词

3. 跑一次试跑验证

准备一份 ASR 转录稿（.md 或 .txt），调用本 skill：

• 校对结果归档到 {skill 目录}/archive/{YYYYMMDD_HHMMSS}_{原文件 basename}/
• 源文件目录同步输出 {原文件}_corrected.md 易访问副本
• 校对日志在 correction_log.md，按"高置信替换 / 基础空白清理 / 口语词精简 / 未处理"四区分类

首次跑推荐先观察"未处理"区——根据实际未改的项决定是否需要：

• 补充词典项（按实战反馈追加个人术语）
• 调整 references 规则（如某些形式漂移模式未覆盖）
• 重新跑同一份稿看增量

4. 进阶：多用户 / 多设备共用

软链方案：

# 把本 skill 的真实 yaml 软链到统一位置
ln -s ~/Dropbox/dictionaries/legal_user_dictionary.yaml \
   config/user_dictionary.yaml

这样多个 skill / 多台设备共享同一份词典，避免在多处维护。

注意：软链的目标文件本身也应 git ignore（不要提交私人词典到任何仓库）。

5. 不该做的事

• ❌ 不要把个人项（姓名 / 律所 / 客户）追加到 user_dictionary.example.yaml——一旦 commit 会通过公开仓库泄露
• ❌ 不要修改 config/.gitignore 让真实 yaml 入仓
• ❌ 不要为了让词典项"用上"而强行替换普通词
• ❌ 不要在跑之前删 archive/ 下历史归档——它们是校对质量的承载体

Scope

本文件聚焦 skill 的概述 / 适用边界。

配置示例与配置解耦原则见 config-decoupling.md。

工作流判断准则（误转写识别、口语词精简、并列停顿、必检清单、ASR 高频模式）见 correction_patterns.md。

首次使用流程（复制 example.yaml、跑一次试跑）见 first_use.md。

概述

把 raw 转录稿里"听得对但写不对"的同音/形近/拼写错误按用户词典统一改对，并按需做轻度润色。不做：改写、总结、删减、改事实、生成课程章节。

与下游处理工作的边界：

• 本 skill 不输出课程大纲、不重组章节、不改写为书面课程；只做"读起来对、不再丢脸"这一步。
• 用户词典 YAML 格式（version + terms 列表）已成为本 skill 公开的接口约定；其他下游处理工作可以按需读取同一份词典文件。

适用场景

• 拿到 ASR 输出的转录稿，需要先校对再发布/归档
• 跨多次整理同一批转录稿（用户词典复用）
• 客户沟通录音转写稿，需要修正人名/产品名/术语

不适用

• 重写为课程章节、报告、总结
• 完全空白的素材，需要"创作"
• 单条语句改写润色 → 手工

references 目录分工