Meeting Minutes

会议纪要工作流 v3（meeting-minutes）

v3 = 说话人分离版（v2） + 转写降级路径（v1）。 合并前两版各自的长处：v2 负责「转得准、可复核」，v1 负责「转不了也走得下去」。

第一条规则：先问，再动（优先级高于本文档其它一切内容）

收到录音或转写稿后的第一个动作，是把下面的开工确认单原样发给用户，然后结束本轮、等用户回答。

在用户回答之前，禁止做任何其它事，包括但不限于：

• 运行任何脚本（转写、试跑、预检、探测时长、检查音质、估算人数）
• 读取音频元信息、试听片段、判断说话人数量
• 替用户填写、猜测，或"为了让单子更有依据"而先去试跑
• 开始切段、提炼、出稿

唯一例外：用户给的路径明显不存在时，可以问一次路径；但仍然不跑任何脚本。

不要替用户做决定。 单子里每一项都由用户回答；用户答"不知道"就是合法答案—— 说话人数不知道，就按自动判断跑，不需要你先去"探明"。

为什么这条要放在最前面：试跑、探测、预检这些动作看起来无害，但它们让用户失去了 "先看选项、再决定怎么做"的机会，而且会让本该 10 秒完成的确认变成一轮跑完再说。 用户要的是被问，不是被替你决定。

用户回答之后，才进入 Phase 0 建档；一分钟试跑属于 Phase 1，也在那之后。

要发的原文（照抄，一次发完，不要拆成多轮问）：

【开工确认单】请先回答这 7 项，我再开始干活（每项都可以答"不知道"或"按默认"）

1. 材料：录音文件 / 已有文字稿（转写稿、会议速记、字幕、聊天记录）
2. 会议类型：内部工作会 / 决策评审会 / 跨部门对接会 / 外部沟通会 / 采访访谈
3. 参会人：姓名 + 角色 + 是否发言（未发言的人不会出现在正文）
4. 说话人数：几人（填了「发言人1/2/3」才稳定；不知道就写"不知道"）
5. 交付形态：Word 纪要 / 图文摘要 / PPT（可多选；PPT 按需生成）
6. 无关段落：寒暄、吃饭、闲聊 → 保留并标记【非议题】 / 直接剔除
7. 术语表：有没有经常被听错的词（可不填，之后随时补）

另外三件事先说清楚：
· 第 1 项答「已有文字稿」的话，转写这整步会跳过 —— 人工速记和会议平台导出的稿子，
  通常比离线转写更准，没有录音不等于纪要质量差。
· 说话人编号是声纹聚类结果，不等于真实身份，跨会议也不通用；有姓名表才能映射成真名。
· 录音质量决定纪要上限：远场、多人抢话的录音，转写准确率会明显下降。

第 1 项的答案决定 Phase 1 走哪条路（见下方「Phase 1 · 先判档，三条路」）。

一句话定位

把一场会议的原始材料（录音 / 转写稿 / 文字记录）变成可以直接发出去、并且每条结论都能被机器验证的纪要。

所有「共识 / 方案 / 决策 / 行动项」必须能在原文里找到依据。找不到就写「待确认」，不猜。

相比让模型直接写纪要，本技能强制多做四件事：

1. 先确认、再开工 —— 开工确认单没答完，不许进入转写。
2. 原文与纪要分开存 —— 原文只读、纪要派生，每条结论挂时间戳锚点。
3. 出处可被机器验证 —— verify_refs.py 拿锚点去和转写稿 JSON 对账，编造时间戳会被抓出来。
4. 确定性的事交给脚本 —— 转写、说话人分离、术语纠错、锚点校验、Word/HTML 出稿都不花 token。

何时使用

• 用户上传会议录音（.mp3/.wav/.m4a/.amr/.mp4）或已有转写稿
• 用户粘贴会议文字记录，要求整理成纪要
• 用户要求把会议做成汇报 PPT、图文摘要、待办清单
• 采访、访谈、调研类录音（用「采访访谈」模板）

不可违反的铁律

工作流

Phase 0 · 开工确认单（硬性关卡）

表单在本文档开头的【第一条规则】里，照抄发出即可，不要改写、不要拆成多轮。 本阶段的唯一动作就是发这张单子；用户没回答之前，不建档、不跑脚本、不探测音频。

用户答完后 → 建档：

python scripts/init_meeting_workspace.py "会议名" --dir "<输出根目录>" \
    --type 内部工作会 --date 2026-09-19 --speakers 4 \
    --attendees "A(主持,发言),B(发言),C(发言),D(发言),某同学(未发言)" \
    --output word,digest --noise keep

然后写 CP0：

python scripts/append_checkpoint.py "<工作目录>" --id CP0 \
    --phase "Phase 0 建档与确认" --output "过程/meta.md" \
    --basis "用户填写的开工确认单" --status 完成 \
    --pending "待补：XXX" --next "CP1 转写"

Phase 1 · 先判档，三条路（CP1）

转写不是必经步骤，只是拿稿方式之一。 这一步最容易把整个流程卡死，所以必须先判档、再动手。

按开工确认单第 1 项的答案分档：

路 1 · 直接用现成文字稿（甲档）

把用户给的文字整理进 原文/转写稿.md，统一成 [时:分:秒] 发言人N：… 的逐行格式：

• 原稿没有时间戳 → 用 [00:00:00] 起步或行号代替，出处照样可回溯。
• 原稿没有发言人 → 写「发言人未分离」，责任人一律「待确认」。
• 不要因为没走转写而心虚，这条路产出的纪要质量通常最高。
• 后续 verify_refs.py 仍需要 原文/转写稿.json；手工稿可按同结构补一份， 或在 CP1 里注明「人工稿，跳过锚点校验」。

路 2 · 本地离线转写（乙档）

判档靠体检，不靠猜（体检 10 秒，盲试一轮 10 分钟起）：

python scripts/doctor.py

体检末尾会给出路线结论：

默认 medium 模型（准确率与速度的平衡点；small 更快但专有名词错得多）。音频不出本机，无需 API Key。

试跑属于 Phase 1，不属于准备阶段。 只有用户已经回答完开工确认单、工作目录也建好之后， 才做下面这次 1 分钟试跑。不要在发单子之前"顺手先跑一下看看"。

# 第 0 步：先问出本机该用哪个解释器（bootstrap 装的虚拟环境）
# 输出里的 python 字段就是它。后面所有命令都用这个 $PY。
python scripts/doctor.py --paths

# 先试跑中间 1 分钟看音质与人数是否合理（够判断音质，又不用等）
& $PY scripts/transcribe.py "<音频>" --start <中间位置秒数> --duration 60 \
    --out-md "<工作目录>/原文/试跑.md"

# 确认可用后跑全量
& $PY scripts/transcribe.py "<音频>" \
    --out-md "<工作目录>/原文/转写稿.md" \
    --out-json "<工作目录>/原文/转写稿.json"

脚本会自动：归一化音量 → 分块转写（块间留重叠）→ 剔除提示词泄漏与机械重复幻觉 → 按术语表纠错 → 说话人分离并按切换点合并 → 输出 [时:分:秒] 发言人N：…。

--out-json 是后续锚点校验的凭据，一定不要省。

路 3 · 转人工供稿（丙档）

判定不可用后，立即停止一切转写尝试，把下面三条通道交给用户，然后等他给稿子：

1. 会议平台自带纪要 —— 腾讯会议 / 飞书妙记 / 钉钉闪记都自带「转写 + 自动纪要」，录完导出即可，准确率高于本地离线转写。最省事。
2. 手机录音机自带转写 —— iPhone 备忘录录音、小米/华为/OPPO 录音机多有「转文字」。
3. 剪映 / 讯飞听见 / 网易见外 —— 导入音频导出字幕或文稿，多数有免费额度。

用户实在拿不到稿子时，生成一份模板让他边听边填：

python scripts/make_manual_template.py "<音频>" --out "<工作目录>/原文/转写稿.md"

拿到稿子后按路 1 继续，从 Phase 2 开始，转写这步整个跳过。

三条死规矩（转写专属，违反必翻车）

收尾（三条路共用）

写 CP1 时记录：稿子来源（路 1/2/3）、转写覆盖率、低置信段数、缺口区间、术语纠错次数。 路 3 的 CP1 必须写明「本机不具备转写条件，已转人工供稿」。

Phase 2 · 切段提炼（CP2）—— 最关键的一步

目标：把长转写稿压成结构化要点，提炼完就把原文清出上下文。

1. 按议题切段：话题切换就切；时长 > 30 分钟或转写稿 > 8000 字必须切。
2. 逐段处理、原文即弃：每次只读一段 → 提炼 → 写盘 → 不再回读。禁止把整篇一次性读进上下文。
3. 每段固定六栏：议题 / 发言要点（带出处）/ 结论 / 数字与日期 / 待确认 / 未解决问题。
4. 全部写进 过程/要点.md。
5. 无效区间单列：静音、闲聊、幻觉段的时间区间单独成表，该区间内容不进正文。
6. 写 CP2。

Phase 3 · 合并去重与出稿（CP3）

1. 全局去重：同一事项合并为一条，出处置处引用。
2. 归集到「意见总结」：需求、共识、决策、技术要点全部进同一章，不拆到多章来回讲。
3. 选模板：按 meta.md 的会议类型，从 references/templates.md 取章节骨架。
4. 动态编号：模板内章节一律保留，无内容写「本次不适用」；只有模板外的章节才删。
5. 挂锚点：每条要点写成「结论 + 字段」结构，出处写 [时:分:秒]。格式见 references/evidence-and-qc.md，不能自创。
6. 输出 纪要/会议纪要.md，写 CP3。

排版的硬要求（对着写，别写完再补）：

• H1 之后、第一个 ## 之前的内容会被渲染成「速览」高亮块 —— 这里放一页速览：这次要解决什么、几条结论、最需要用户确认的 3 件事。
• 章节用 ## 1. 标题，子节用 ### 4.1 标题。
• 每条结论必须是 - **类型 ID**：一句话结论，字段缩进两格。不要把结论写成大段文字。
• 引用类字段用 引用，会被单独渲染成引文块；其余字段压缩成一行证据条。
• 用表格承载清单（决策清单、行动项、待确认），比一堆列表更好读。

Phase 4 · 质检（CP4）—— 只查不补

& $PY scripts/qc_check.py "<工作目录>/纪要/会议纪要.md" \
    --transcript "<工作目录>/原文/转写稿.md" \
    --transcript-json "<工作目录>/原文/转写稿.json" \
    --template 内部工作会 \
    --out "<工作目录>/过程/质检报告.md"

& $PY scripts/verify_refs.py "<工作目录>"

• Q1 可回溯性、Q2 章节完整性、Q3 行动项三要素、Q4 无凭空内容、Q5 去重、Q6 出处可验证。
• Q6 是 v2 新增：把锚点拿去和转写稿 JSON 对账，编造时间戳会被抓出来。
• FAIL → 回 Phase 3，遵守 R8（只允许标注「待确认」或删除）。
• 写 CP4。

Phase 5 · 交付（CP5）

& $PY scripts/build_outputs.py "<工作目录>"

产出：

PPT 只有用户明确要时才做（tencent-pptx 或 python-pptx），页序见 references/output-formats.md。

写 CP5，然后一次性把交付物位置列给用户。

工作目录结构

<会议名>_<日期>/
├── 原文/          转写稿.md / 转写稿.json / 转写稿.html（只读，不改动）
├── 纪要/          会议纪要.md/.docx/.html、图文摘要、待确认清单
└── 过程/          meta.md（开工确认单）、checkpoints.md、要点.md、质检报告.md

原文与纪要物理分开，是为了用户随时能查原文、也避免改纪要时污染原文。

参考文件

脚本

常见失败模式

• 在转写上反复试错（换源、换模型、蹭在线网站）→ 每轮十分钟级消耗，用户等到崩溃，成功率极低。先跑 doctor.py 看路线结论；判定 C 立刻转路 3。
• 有现成文字稿还去跑转写 → 纯浪费。甲档直接走路 1，永远不要碰转写脚本。
• 还没问就先去试跑/预检/探时长 → 用户要的是先被问，不是被替你决定。收到录音后的 第一个动作必须是发开工确认单，试跑是 Phase 1 的事。
• 替用户填确认单 → 单子里的每一项都必须由用户回答；他答"不知道"就照"不知道"处理。
• 跳过开工确认单直接开跑 → 交付形态靠猜，白跑一遍。这是 v1 最常犯的错。
• 一口气读完转写稿再写纪要 → 上下文被原文塞满，中段细节丢失。必须分段、原文即弃。
• 为了过质检而补内容 → 宁可留「待确认」。
• 出处只写"会上讨论过" → 没有时间戳等于没有出处，Q6 会失败。
• 把闲聊混进正文 → 用户要的是"保留但标记"，不是"删掉"也不是"混着写"。