Menu
转录稿纠错与轻度优化。本技能应在用户需要按用户词典纠正 ASR 转录稿同音字与英文专有名称漂移时使用。不要用于：重写为课程章节、报告、总结，或完全空白的素材创作。
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
将本地开发的 Skills 批量同步到 ClawHub 与腾讯 SkillHub 两个平台。支持智能 .gitignore 过滤、白名单控制、增量同步、单个 skill 同步、双平台分流发布。本技能应在用户需要将本地 skills 发布到 ClawHub/SkillHub、批量同步技能、检查发布状态时使用。
跨平台 Agent 任务协调枢纽。本技能应在多个不同平台的 Agent 需要围绕项目任务源分配任务、标记归属、能力路由和交接上下文时使用。不要用于单一平台内的本地并行执行，或 Git 分支、提交、PR、merge 安全规则。
输入各类视频网站/播客平台链接后，自动下载对应媒体文件并交付给用户。优先使用 yt-dlp 覆盖抖音(Douyin)、B站(Bilibili)、YouTube 等常见视频网站，也可用于可直接暴露音频地址的播客平台（如小宇宙单集链接）。当遇到 403/登录/年龄或地区限制时，支持使用 cookies.txt 重试；对于可能存在 DRM/加密或条款限制的平台（例如部分 Spotify 内容），应提示用户仅下载其有权保存的内容，并在不可下载时建议改用官方离线/导出渠道或提供原始 RSS/直链。抖音视频在 yt-dlp 撞签名墙（"Fresh cookies needed"）时会自动 fallback 到无登录直连 aweme.snssdk.com/v1/play（仅需 video_id，不需要 cookie/a_bogus 签名）；抖音图文笔记暂不支持自动下载，需手动处理。
元典法条与案例检索。本技能应在需要查询中国法律法规条文、检索相关案例、为法律分析提供数据支撑时使用。
PDF 处理工具，支持扫描件预处理、OCR 双层 PDF、页码添加、PDF 合并、解密、水印去除和压缩。本技能应在用户需要一键处理、优化或整理 PDF 文档时使用。不要用于：纯文本 PDF 内容编辑、PDF 阅读与批注、电子签名、非压缩目的的格式转换。
面向中国发明和实用新型专利的结构化初步分析工具。本技能应在用户需要拆解或解释权利要求、比较专利保护范围、进行产品侵权比对、等同分析、稳定性与无效风险分析、FTO、规避设计、专利价值评估或制作专利分析图表时使用。不要用于：代替专利律师或专利代理师出具正式意见、仅下载/OCR专利、撰写专利申请文件，或在未确认法域与有效权利要求时给出确定性结论；外观设计近似判断需另行采用专门方法并人工复核。
| name | transcription-corrector |
| homepage | https://github.com/cat-xierluo/legal-skills |
| author | 杨卫薪律师（微信ywxlaw） |
| version | 1.0.8 |
| 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 | 会议纪要 / 总结 | 每章"本章摘要"+"关键洞察"就地嵌入对应 H2 标题下；文首主标题 + 文末关键词各一行 | 不引入新事实、不重切 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 洞察"）核心原则（v1.4 修订：摘要就地嵌入，不聚合到顶部）：
<!-- AI-SUMMARY --> markers，不产生"所有章节摘要汇聚在一起"的独立区块输出位置：
corrected.md：① 文首 H1 下加一行主标题；② 每个 H2 标题下就地嵌入本章摘要 + 关键洞察；③ 文末加一行关键词_summary.md，不写 markers就地嵌入格式（每个 H2 之下）：
## 一、章节名（Step 4.4 标题，原样）
**本章摘要**：50-100 字概括本章节核心内容（引用原话中的具体事实/数字/专有名，不引入新事实，不评价）
**关键洞察**：
- 洞察 1（15-30 字，横向观察本章节）
- 洞察 2
**发言人 1 00:02:09**
（该章原话正文，全部保留，紧跟在摘要 / 洞察之后）
...
文首主标题 / 文末关键词：
**主标题**：5-15 字概括全文核心议题**关键词**：词1, 词2, ...（5-8 个，逗号分隔）为什么改为就地嵌入（v1.4）：
生成原则：
严格不做：
## AI 摘要 聚合块、不写 <!-- AI-SUMMARY --> markers与 Step 4.4 的边界：
| Step 4.4 | Step 4.5 | |
|---|---|---|
| 输出文件 | corrected.md（修改） | corrected.md（修改，就地嵌入） |
| 操作 | 在原话章节前插入 H2 标记 | 每个 H2 标题下、原话前嵌入摘要 / 洞察；文首主标题、文末关键词各一行 |
| 保留原话 | 全部保留 | 原话全部保留 + 摘要中引用片段 |
| 引入新信息 | 不允许 | 不允许 |
幂等与验证：
^## 二级标题之下紧跟一个 **本章摘要** 行；② 全文无 <!-- AI-SUMMARY 字样；③ 主标题 / 关键词各一行存在校对日志记录：Step 4.5 的产出写到 correction_log.md 的"会议纪要"小节，格式：
| 字段 | 值 |
|------|-----|
| 主标题（文首单行）| 主标题文本 |
| 章节数 | 8（与 Step 4.4 H2 一致）|
| 总洞察数 | X 条 |
| 摘要字数总计 | Y 字 |
| 关键词（文末单行）| 词1, 词2, ... |
| 嵌入方式 | 就地嵌入每个 H2 之下；无顶部聚合块；无 markers |
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。