القائمة
转录稿纠错与轻度优化。本技能应在用户需要按用户词典纠正 ASR 转录稿同音字与英文专有名称漂移时使用。不要用于：重写为课程章节、报告、总结，或完全空白的素材创作。
استنادا إلى تصنيف SOC المهني
| name | transcription-corrector |
| homepage | https://github.com/cat-xierluo/legal-skills |
| author | 杨卫薪律师（微信ywxlaw） |
| version | 1.0.7 |
| license | MIT |
| description | 转录稿纠错与轻度优化。本技能应在用户需要按用户词典纠正 ASR 转录稿同音字与英文专有名称漂移时使用。不要用于：重写为课程章节、报告、总结，或完全空白的素材创作。 |
首次使用流程见 references/first_use.md。工作流中的判断准则见 references/correction_patterns.md。
把 raw 转录稿里"听得对但写不对"的同音/形近/拼写错误按用户词典统一改对，并按需做轻度润色。不做：改写、总结、删减、改事实、生成课程章节。
| 模式 | 触发 | 输出 |
|---|---|---|
| 纠错模式（默认） | 拿到 raw 转录稿，要先做"校对" | archive/.../{原文件}_corrected.md + 校对对照日志 |
| 纠错 + 轻度润色 | 还要顺手把发言人合并/标点整理 | 在纠错基础上再润色，输出到 archive/.../{原文件}_polished.md |
与下游处理工作的边界：
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 源文件目录镜像（必出）
为什么这样分组：
转录稿修正的本质是"对每一处误转写做出独立判断"。这个判断的输入是上下文，输出是一处 Edit，三者必须由同一个 agent 在同一个上下文里完成。
为什么按"每处 Edit"展开
terms: ["WorkBuddy"] 告诉 agent "正确的写法是 WorkBuddy"，但不告诉 agent "这处原文是否需要改"。由此推出自然的执行流：
Read 把源文件读进上下文（必须通读全文）Edit 把每一处的决策落盘Write 写出 correction_log.md / meta.json / 源目录镜像为什么这个流是自洽的
skill 各项润色开关由 config/config.env 控制。加载顺序：
key=value 覆盖config/config.env（本 skill 自带）config/config.env.example（默认值的"母本"，缺失 step 2 时用）配置示例（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 自己的 § 段注明默认值）。
词典文件查找顺序（找到第一个存在的即用）：
dictionary 路径config/user_dictionary.yaml（本 skill 自带）config/user_dictionary.example.yaml 为 config/user_dictionary.yaml词典 YAML 格式：
version: 1
terms:
- "WorkBuddy"
- "Claude Code"
- "Codex"
当输入是 .txt 文件时，先做格式转换再进入 Phase 2。
触发条件：输入文件扩展名是 .txt。
转换规则（保守——只做格式包装，不改内容）：
发言人 1 00:33:09）：
^(发言人|说话人|Speaker|S)\s*[\d一二三四五六七八九十]+[\.、]?\s*(\d{1,2}:\d{2}(?::\d{2})?)$**发言人 1 00:33:09**---、===）等全部保留###/####- xxx 改成 markdown 列表——保持原样输出：
{原文件 basename}_converted.md，保留在 archive 子目录.txt 文件保持不动示例：
输入（raw.txt）：
发言人 1 00:33:09
我先说一下比较好的部分，就是整个最终的报告篇幅是比较充分的。
然后大家在一开始不知道怎么样一个报告是比较完善的，也知道怎么样去借鉴他山之石。
从这个阿尔法 gpt里面的这报告相当于蒸馏他的一个一个想法啊。
这个这个在前期一开始搭基建的时候确实是很有必要的一个措施。
发言人 1 00:33:57
呃然后。我注意到咱们在最终生成法律服务意见书的时候...
输出（raw_converted.md）：
**发言人 1 00:33:09**
我先说一下比较好的部分，就是整个最终的报告篇幅是比较充分的。
然后大家在一开始不知道怎么样一个报告是比较完善的，也知道怎么样去借鉴他山之石。
从这个阿尔法 gpt里面的这报告相当于蒸馏他的一个一个想法啊。
这个这个在前期一开始搭基建的时候确实是很有必要的一个措施。
**发言人 1 00:33:57**
呃然后。我注意到咱们在最终生成法律服务意见书的时候...
不识别的格式（保持原文）：
通读 raw 稿，识别组织方式：
**发言人 1 00:33:09**）— 多数 ASR 输出识别目的：决定 Phase 4 润色时是否合并同发言人连续发言。不要改写分块结构，保留原貌。
必须完整通读全文，以 Agent 视角扫描。不列静态错误表——ASR 错误无穷无尽（大小写漂移、空格、漏词、错位、同音字、形近字、断词重连、音节吞并…），任何预设列表都会漏判。
核心原则：
仅在上下文明确指向某个词典术语时，才将近似误转写替换为该术语。 模糊或低置信场景保持原文，不做猜测式替换。
启动扫描的高频易错类别（不是错误表，是判断启动点）：
形式漂移识别（参考但不穷举）：
禁止：
Phase 3 三个 Step 改的是三类不同对象——Step 3.1 改字（语义）、Step 3.2 改空白（格式）、Step 3.3 删字（语言字符）。三类操作各自独立、可单独审计、单独计日志。
对 Step 2.2 识别出的高置信误转写：
{原文} → {改后}，并标注行号和上下文片段为什么独立于 Phase 4 润色：基础空白清理是"格式标准化"，不改变原文语义、不删减任何信息；与 Phase 4 发言人合并 / 标点规范 / 段落切分那种"风格调整"性质不同，所以默认开启（用户不需要为此做开关决策）。
清理动作清单（仅做以下五类，不做任何超出此范围的事）：
| 类别 | 动作 | 触发条件 |
|---|---|---|
| 行首/行尾空白 | 删除 | 任意行 |
| 连续空行 | 压缩为单个空行 | 任意位置 |
| 全角/半角空格 | 统一为半角空格 | 出现在英文单词之间或英文标点旁 |
| 专有名称内部断裂空格 | 合并 | 上下文明确指向词典中的专有名称（如"Work Buddy" → "WorkBuddy"） |
| 中文数字 + 空格 + 级/章/节 | 合并 | 模式：[一二三四五六七八九十百千]+ +级/章/节 合并为 [一二...]+级/章/节（如"二 级" → "二级"） |
标点周围空白规则：
，。、；：？！""''「」（） 前后不留空格（若出现则删除）, . ; : ? ! " ' ( ) 后空一格（中文段落中保留）严格不做（避免越界）：
**发言人 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 高置信替换区分开），便于审计。
为什么独立于 Phase 4 润色：与 Step 3.2 基础空白清理性质相同——属于"读起来对"的范畴，不改变原意（口语词不携带信息）；与 Phase 4 发言人合并 / 标点规范 / 段落切分那种"风格调整"性质不同，所以默认开启（用户不需要为此做开关决策）。
白名单（可删的纯填充词）——AI 通读时识别"作为填充词 vs 作为实义"，仅删独立出现且无语义负担的：
| 词 | 典型位置 | 删除条件 |
|---|---|---|
| 呃 | 段中独立 / 句首 | 认知停顿，不构成回答 |
| 啊 | 段中独立 / 句末 | 感叹停顿 |
| 哦 | 段中独立 | 过渡停顿（不作"明白了"回应） |
| 哎 | 段中独立 | 过渡停顿 |
| 那个 | 独立使用 | 纯指代填充（不指代具体名词） |
| 就是说 | 独立使用 | 纯连接填充 |
| 然后呢 | 段末 | 纯过渡填充 |
| 对吧 | 段末 | 纯反问填充 |
| 你知道吗 | 段中 | 纯引导填充 |
| 怎么说呢 | 段中 | 纯思考填充 |
| 这样子 | 独立使用 | 纯总结填充 |
| 其实呢 | 段首 | 纯转折填充 |
| 但是呢 | 段首 | 纯转折填充 |
保留规则（不删）：
段首 vs 段尾 vs 段中 决策树：
| 位置 | 判定标准 | 处理（v2 激进版起） |
|---|---|---|
| 段首 | 紧跟 **发言人 X HH:MM:SS** 之后第一个非空行的第一个词 | 删除（v2 起激进） |
| 段中独立 | 句中位置、不是紧邻关键名词/动词 | 删除 |
| 段中并列停顿 啊 | 两个名词/动名词之间 + 顿号/逗号 | 保留（删除会破坏并列结构） |
| 段尾 | 一段内容末尾的最后一个词 | 保留（标记节奏收束） |
详见 references/correction_patterns.md §11 段中并列停顿 啊 的识别模式。
判断原则：
严格不做（避免越界）：
校对日志记录：所有 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 字段Phase 4 下的所有 Step 由 config/config.env 配置文件中的开关决定是否启用。每个 Step 默认值的来源：
config.env：用 config.env.example 的值（即默认值）config.env.example：用本节速查表的默认值| Step | 类别 | 动作 | 边界 | 配置开关 | 默认值 |
|---|---|---|---|---|---|
| Step 4.1 | 发言人合并 | 同一发言人连续多段、可合并为一段时，合并 | 仅去重分块，不删任何原话 | POLISH_MERGE_SPEAKERS | true |
| Step 4.2 | 标点规范 | 中英文标点统一、句末补全 | 不改语气词、不删"呃/啊"等自然语流标记 | POLISH_PUNCTUATION | true |
| Step 4.3 | 段落切分 | 极长段（>500字）按语义边界切 | 不重组、不重排、不总结 | POLISH_PARAGRAPH_SPLIT | true |
| Step 4.4 | 主题分章 + H2 标题 | 在明确的话题切换点插入 ## 一、标题 行（带中文大写序号） | 仅在切换点插入，不重组内容、不改写、不总结 | POLISH_TOPIC_SECTION | true |
| Step 4.5 | 会议纪要 / 总结 | 注入到 corrected.md 顶部（funasr-transcribe 风格 markers），每章含"本章摘要"+"关键洞察"+"关键词" | 不引入新事实、不重切 H2、不评价 | POLISH_SUMMARY | true |
触发条件：话题发生明确切换（不同讨论对象 / 不同议程 / 不同主体焦点）时，插入 ## 一、标题 行；同一话题内部的子切换不插入。
识别原则：
标题文本从何而来：
编号规则：
一、、二、、三、...、 顿号分隔（中文正式排版惯例）：## 一、工具选择与日常使用corrected.md 中序号唯一，不重复严格不做：
校对日志记录：所有 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 更合身。
POLISH_SUMMARY 开关）触发条件：
POLISH_SUMMARY=true，或用户在调用时显式声明（"生成纪要" / "总结" / "AI 洞察"）输出位置：
corrected.md，在文件顶部插入 summary 块_summary.md 文件（v1.3 修订：原"独立文件"方案已改为"嵌入 corrected.md"）插入位置与标记（funasr-transcribe 风格）：
<!-- AI-SUMMARY:START --> / <!-- AI-SUMMARY:END --> 包住整个 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：
## AI 摘要 之下），层级关系清楚：原话章节 > 摘要章节生成原则：
严格不做：
与 Step 4.4 的边界：
| Step 4.4 | Step 4.5 | |
|---|---|---|
| 输出文件 | corrected.md（修改） | corrected.md（修改，注入 summary 块） |
| 操作 | 在原话章节前插入 H2 标记 | 在 H1 之后插入 AI 摘要块 |
| 保留原话 | 全部保留 | 原话全部保留 + 摘要中引用片段 |
| 引入新信息 | 不允许 | 不允许 |
幂等与验证：
grep -c "<!-- AI-SUMMARY:START -->" 验证 markers 存在校对日志记录：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）：
输出采用 双写 策略：主归档在 skill 内部，源文件目录同步一份易访问副本。原始文件保持不动。
输出位置：{skill 目录}/archive/{YYYYMMDD_HHMMSS}_{原文件 basename}/
文件：
{原文件}_corrected.md — 纠错后的完整文本（保留原始分块结构）{原文件}_polished.md — 仅在用户开启润色时生成correction_log.md — 校对对照日志meta.json — 处理时间、词典来源、是否润色、原始文件路径输出位置：原始文件所在目录（与原文件同目录）。
文件：
{原文件 basename}_corrected.md — 与 5.1 内容完全一致，仅是易访问副本_corrected 后缀，扩展名改为 .md（原文件是 .md 时，输出仍为 .md；原文件是 .txt 时，输出为 .md）为什么双写：
_corrected.md（polished 副本与 log 不镜像——它们的主归档位置就在 skill 内部）冲突处理：
_corrected.md → 用时间戳后缀区分（_corrected_20260608_153022.md），避免覆盖历史校对结果meta.json 记录 source_mirror: "skipped"原始文件保持不动——双写策略只生成"新文件"，绝不就地修改原文件。
当某次跑出的 _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：
_corrected_v3_20260608_120000.md）按时间戳命名，本身是"稳定"暗示，但 archive 内部 260606_AI技能创新大赛_corrected.md 没 STABLE 标记会被误认成"最新版"什么时候不写 STABLE.md：
archive 目录会保留每次跑的全量产物（主归档 + correction_log + meta.json），不主动清理历史版本。但当 archive 下子目录数 ≥ 5 时，建议在 STABLE.md / DECISIONS.md 备注保留策略：
_corrected.md / correction_log.md / meta.json（记录完整迭代轨迹）analysis_report.md 等中间产物可手动归档_corrected.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/config-decoupling.md。
基于现有文章、专栏、课程讲稿、逐字稿、访谈、课件、会议纪要、案例材料、PDF 文本、Word 文档和笔记等内容资产，判断它们最适合转化为书、小册子、课程、系列文章、实务手册或知识库，并输出精简策划意见；用户提到“把现有内容整理成书”“判断素材适合做书还是课程”“把文章/直播稿/课程稿/笔记重组成知识产品”等场景时，应使用本技能。
使用本地 FunASR 服务将音频或视频文件转录为带时间戳的 Markdown 文件，支持 mp4、mov、mp3、wav、m4a 等常见格式。本技能应在用户需要语音转文字、会议记录、视频字幕、播客转录时使用。
Git 工作流安全助手。本技能应在需要执行分支管理、Monorepo 安全合并、PR 创建/审查/合并、冲突处理、cherry-pick、安全回退，以及 stale/已合并分支审计与清理（branch cleanup，含 squash/rebase merge 校验）时使用。不要用于：批量生成提交信息、项目任务分配、长期任务状态管理或本地多 Agent 会话编排。
本技能应在用户需要 OCR、扫描识别、图片文字识别、文档识别，或将 PDF、图片、Office 文档、URL 转换为 Markdown 时使用。检测到法律材料时可进行保守的法律术语与文书结构优化。不要用于法律事实判断、补写缺失内容、语义改写、印章深度识别或图表实体分析。
Skill 质量验收与格式审查工具，也可称 Skilllint。本技能应在用户需要审查 Claude Code Skill 的目录结构、Frontmatter、引用一致性、发布版本、业务流深度、可评估性和安全风险时使用。不要用于：创建新技能、代码审查、应用功能测试、通用编程任务。
元典法条与案例检索。本技能应在需要查询中国法律法规条文、检索相关案例、为法律分析提供数据支撑时使用。