# Huiyijiyao

> 把会议转录（Zoom 自动字幕、腾讯会议纪要、飞书妙记、其他 ASR 工具导出的逐字稿，以及用户直接粘贴的对话文本）整理成结构化的中文会议纪要。固定输出 Markdown，按「背景 → 核心共识 → 分工 → 议题讨论 → 本周/本阶段冲刺 → 行动项汇总 → 待跟进」的标准模板组织，自动识别发言人、自动修正 ASR 错别字、按预设团队术语表统一人名和产品名，并抽取出可执行的行动项。当用户说"整理一下这份会议纪要""帮我把这个会整理一下""把字幕整理成纪要""做个会议总结""这个会的纪要""会议纪要""meeting minutes""把这份逐字稿整理一下"，或者直接丢一份带时间戳的会议转录文件/字幕文件进来要"整理"，都用这个 skill。哪怕用户没明说"纪要"二字，只要场景是「拿到一份会议转录/字幕/逐字稿，希望得到一份能直接发群的结构化总结」，都用这个 skill。

- Skill: `b-bzy/huiyijiyao` (Agent Skill, multi-file: 5 files)
- Install (CLI): `npx skillmds@latest add b-bzy/huiyijiyao`
- Raw SKILL.md: https://api.skillmd.com/api/skills/b-bzy/huiyijiyao/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Docs & Writing
- Author: b-bzy (https://skillmd.com/u/b-bzy)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/b-bzy/huiyijiyao

---


# huiyijiyao · 会议纪要整理

把一份机器转录的会议字幕（满是错别字、口语化、东拉西扯）变成一份**能直接发群里、能直接落地推进**的结构化纪要。

## 一、这个 skill 解决的核心问题

会议转录的原始字幕有三类毛病，导致它不能直接当纪要用：

1. **ASR 错别字**：人名、产品名、技术术语经常被识别错（"Carl"→"案流/阿牛/Andy"、"Bob"→"本省/biscuit"、"优先级"→"U 型机"、"Minimax"→"medi ex/linux 模型"），读起来割裂。
2. **结构散乱**：对话是非线性的，议题来回跳，结论藏在中间，看完转录也不知道"谁负责什么、什么时候完成"。
3. **信息冗余**：客套话、口头禅、跑题、重复确认，占了大段篇幅，但纪要里不需要。

这个 skill 的工作就是：**把这三件事一次性处理干净，输出一份让没参会的人看一眼就能跟上、让参会的人看一眼就知道自己今天该做什么的纪要**。

## 二、工作流程

### 步骤 1：先核验文件，再读转录

**这是开局第一件事，不能跳。** Zoom 默认把每次自动字幕都存成 `meeting_saved_closed_caption.txt`——用户电脑上可能堆了几十份同名文件，他自己都分不清。**你 ABSOLUTELY 不能假设当前附件就是用户今天想整理的那场会**，必须主动核验：

1. **跑 bash 列出 uploads 目录里所有 `.txt` / `.vtt` / `.srt` / `.md` 文件**，带时间戳：

   ```bash
   ls -la /sessions/<sid>/mnt/uploads/*.txt /sessions/<sid>/mnt/uploads/*.vtt /sessions/<sid>/mnt/uploads/*.srt /sessions/<sid>/mnt/uploads/*.md 2>/dev/null
   ```

2. **对每个候选文件读前 3 行** 作为内容指纹（首条字幕的发言人 + 时间戳 + 开头几个字就能区分出不同会议）。

3. **如果 uploads 目录里有多份转录文件**：
   - 用户在消息里附了具体的一份 → 用那份，但**在回复开头一句话告诉用户**："我看到的是 `xxx.txt`（开头：'……'，时间戳起点 HH:MM），如果不对告诉我"；
   - 用户消息里没明确附件，或者用户的附件是几天前的旧文件、和 uploads 里更新的某份明显冲突 → **必须用 AskUserQuestion 列出候选，让用户选**。

4. **如果只有一份转录**：直接用，但**也要在回复开头说一句**"看到的是 `xxx.txt`（开头：……）"，让用户能立刻识别拿错没拿错。

**为什么这一步必要**：曾经出现过的真实 bug——用户以为"我刚上传了新会议"，但实际上系统拿到的是几天前的旧文件（Zoom 同名覆盖陷阱），导致连续几次跑 skill 都基于错误的转录，用户却以为我没读他给的文件。**这一步就是修这个 bug。**

---

确认文件之后，再读转录，识别：

- **参会人**：扫一遍发言人标签（`[Name] HH:MM:SS` 是 Zoom 字幕的标准格式），列出所有**实际发言**的名字（不要列被提及但没说话的）。
- **会议时长**：从第一条和最后一条时间戳推断。
- **议题脉络**：会议通常会有 3-7 个议题，按出现顺序记下来。
- **决议和承诺**：留意"我们就这么定了""你负责 X""周五前给我"这类语言。

### ⚠️ 步骤 1.5：会议时长分流（强制）—— 长会议走专门协议

**这一步在文件核验之后、读取转录之前判断**——用 bash 看转录有多大，按时长分三档处理：

```bash
# 在 mcp__workspace__bash 里跑：
F="<转录路径>"
TOTAL_LINES=$(wc -l < "$F")
FIRST=$(grep -oE '[0-9]+:[0-9]+:[0-9]+' "$F" | head -1)
LAST=$(grep -oE '[0-9]+:[0-9]+:[0-9]+' "$F" | tail -1)
# 用 awk 算分钟差
DURATION_MIN=$(echo "$FIRST $LAST" | awk -F'[ :]' '{
  s=$1*3600+$2*60+$3; e=$4*3600+$5*60+$6;
  print int((e-s)/60)
}')
echo "时长: $DURATION_MIN min | 行数: $TOTAL_LINES"
```

**按结果分流**：

| 档位 | 标准 | 策略 |
|---|---|---|
| **短** | ≤ 20 min 或 ≤ 1500 行 | 标准单次工作流（直接 Read 全文） |
| **中** | 20-40 min 或 1500-3000 行 | 标准工作流 + 分段 Read（Read 单次 ≤ 1200 行） |
| **长** | **> 40 min 或 > 3000 行** | **⚠️ 触发长会议协议**（见下方专门章节） |

**为什么这个分流必要**：曾经踩过的真实坑——拿 96 分钟的 Alice 主讲会议直接整理，结果上下文稀释、张工重构的"第三块"漏写、议题之间细节互相干扰。长会议必须分段处理。

### 长会议协议（> 40 min / > 3000 行）—— 议题驱动的 chunked 处理

**核心思路**：不是按时间窗口机械切，而是**按议题边界切**——每个议题独立 Read、独立写 mini-summary，再合并成标准纪要。

#### 阶段 1：议题边界检测

跑 `scripts/detect_topics.sh` —— 这是 skill 内置的探测脚本：

```bash
bash /var/folders/.../skills/huiyijiyao/scripts/detect_topics.sh "<转录路径>"
# Cowork 环境里换成实际的 skill 安装路径
```

脚本输出三块：

1. **基础信息**：时长、行数、自动分级；
2. **发言人时长分布**：识别"主讲型"（某人 >60%）vs"讨论型"；
3. **建议议题切分点**：基于强切换语（"接下来" / "然后第 N 个" / "下一个板块" / "再说一下"）+ 间隔合理性过滤（< 100 行的切分点合并）。

**输出会给你一份议题切分清单**，类似：
```
议题 1 起点: L878  | 接下来我们现在是6月。
议题 2 起点: L1418 | 然后第三个就是电销，电销都不用写了。
议题 3 起点: L2279 | 然后下一个板块，我们讲我们的。
…
```

#### 阶段 2：议题级 chunked 整理

对每个议题区间，**单独 Read + 单独写 mini-summary**：

```python
# 伪代码（在 Claude 实际跑时用 Read 工具）
for topic in topics:
    Read(file_path=F, offset=topic.start, limit=topic.end - topic.start)
    # 然后在 TaskList 或 scratchpad 里写这个议题的 mini-summary
    mini = {
        "决议": [...],           # 这个议题里明确拍板的事
        "关键论据": [...],       # 1-2 条推导出决议的核心论据
        "行动项": [...],         # 这个议题派出去的 todo
        "数字 / 版本号": [...],  # 不能省略的具体细节
        "待跟进 / 分歧": [...]   # 没结论的问题
    }
```

**重要**：每个 mini-summary 控制在 **≤ 200 字**，只记结论 + 关键细节，**不记讨论过程**（应用反流水账规则）。

#### 阶段 3：跨议题排序 + 主线提炼

读完所有议题的 mini-summary 之后，做四件事：

1. **按重要性排序**：核心共识 > 分工 > 各业务板块 > 流程性话题；
2. **提炼 TL;DR 三句话**：从所有议题里抽出最关键的 3 件事；
3. **识别跨议题模式**：同一决议在多处出现的、同一人多次被点名的、反复强调的（说明 Alice 真在意）；
4. **建立议题间依赖**：如"议题 X 完成后才能启动议题 Y" 这种顺序关系。

#### 阶段 4：填入标准模板

把 mini-summaries 按 `references/template.md` 填进标准结构，应用：

- **信息浓度规则**（议题 ≤ 8 个、每议题 bullet ≤ 8 个、字数控制）；
- **反流水账规则**；
- **隐私 / 钱待遇硬规则**；
- **参会人员只列发言者**。

#### 阶段 5：长会议专属 Review Pass

普通 Review Pass + **额外两项检查**：

- **跨 chunk 一致性**：同一决议 / 同一人物在多个议题被提及时，描述是否一致？（曾经踩坑：Bob 在议题 1 写"在职"、议题 4 写"已离职"，因为 Alice 在不同段落上下文里说的话产生了歧义）
- **议题间过渡平滑性**：相邻议题是否有冲突结论？是否有信息在 chunk 1 提到但 chunk 4 漏写了？

**真实案例验证**：6/6 的 Alice 主讲会议（96 min），用这个脚本跑出 **7 个建议议题切分点**，和人工整理时的板块划分高度吻合：群运营 Base 版 / Plus 版讨论 / 电销复盘 / 模型组人才 / HR 招聘策略 / 产品 K 未来产品 / 客户层面。**这就是脚本要做的事**。

### 步骤 2：自主决定主题和日期（默认不问用户）

**核心原则**：用户希望的工作流是"扔一份转录给你 → 你直接出纪要"。**不要因为礼貌而问问题**——尤其不要问主题、详略、纠错策略这种"你完全可以自己定的"事情。

**A. 主题——基于转录自主推断，默认不问用户**

读完转录后，自己定主题。主题要满足：

- **类型词** + **具体内容**（如"0525周会-业务主线与本周冲刺"、"Eve 入职对齐与项目交接"、"会后技术研讨-音色克隆与语种选型"）；
- 类型词怎么选：
  - 用户在调用消息里明说了类型（"今天**站会**的内容""**周会**纪要""**1-on-1**整理"）→ 用用户说的；
  - 用户没说类型 → 看转录性质判断（多人逐个 update + 行动项分派 = 周会/站会；两人深聊技术方案 = 技术研讨；单人介绍项目给新人 = 入职对齐）；
- 长度 12-24 个汉字之间，**带类型前缀 + 一两个核心议题**，让你和用户后续在 Finder 里一眼能认出。

**只有以下情况才问用户主题**：
- 转录极度模糊、说不清是什么会（罕见）；
- 用户在调用消息里明确说"主题叫 X"或"帮我想几个标题选"。

**不要在每次跑 skill 时都默认抛 AskUserQuestion 问主题——这是过去的错误习惯，已废止。**

**B. 日期——自动取，永不问用户**

按下面顺序取，第一条命中就停：

1. **从文件 modify 时间反推**（最可靠）—— 用 bash 的 `stat` 看转录文件的 modify 时间戳，**字幕通常在会议结束当时写盘**，所以 modify 时间 ≈ 会议结束时间。再结合**字幕末条时间戳**校验（如末条是 "14:56:16"，文件 modify 是 14:56 UTC → 会议在「城市」或类似时区结束于 14:56，会议日期就是 modify 那天）；
2. 转录正文里有明确的日期标记（某条字幕开头是 "2026-05-18" 等）→ 用那个；
3. 用户调用消息里明说了日期（"今天的""昨天的""上周五的"）→ 据此推算；
4. 都没有 → 用今天的日期，用 bash 取：`date +%Y-%m-%d`。

最终日期格式固定为 `YYYY-MM-DD`，便于按时间排序。

> ⚠️ **Zoom 文件夹名陷阱**——**绝对不要直接信 Zoom 录音文件夹的命名日期**（比如 `2026-05-21 10.12.54 [Host Name]'s Zoom Meeting`）。Zoom 在用户**重复使用同一会议室**时，文件夹日期是**会议室首次创建时**的日期，不是当次会议的日期。如果文件 modify 时间和文件夹名日期对不上（差几天甚至几周），**信 modify 时间，不信文件夹名**。这是真实踩过的坑——曾经把 5/25 的会议错写成 5/21，原因就是只看了文件夹名。
>
> **检测命令**：
> ```bash
> stat "<转录文件路径>" | grep Modify
> # 然后看字幕末条时间戳：
> grep -E '^\[' "<转录文件路径>" | tail -3
> ```
> 两者吻合（考虑时区偏移）就用 modify 那天作为会议日期。

**C. 详略 / 纠错策略——直接用默认值，不问**

- **详略**：默认"标准版"（议题 + 讨论 + 决议 + 行动项）；
- **ASR 纠错**：默认"自动纠错 + 文末说明列纠错对照"。

只有用户在调用消息里**主动**要求精简版/详尽版/不纠错时，才走非默认值。

**D. 重复 / 误名文件的清理——自己决定，不问**

如果发现 `会议纪要/` 目录里有同一份转录的旧版本、或者过去命名不准的文件（比如把"周会"叫成了"站会"），**自己删/重命名，不要每次问用户**。决策依据：

- **同一份转录生成过多份**：保留最新/最准的那份，其他删；
- **命名不准**：直接 mv 到准确的名字；
- **不确定**：才问——但应该很少不确定。

**整体心法**：用户找你做纪要是因为他懒得自己想标题、懒得自己整理。**每多问一个问题，就在违背"少打扰"的承诺**。

### 步骤 3：纠错 + 统一术语

先读取 `references/glossary.md`，这是预设的团队术语表，包含人名、产品名、技术词的常见 ASR 错误对照。**遇到匹配的字符串就替换，不需要每次询问用户**。

术语表覆盖不到的可疑点（比如某个新出现的人名、某个明显说错但你不确定原词的字符串），用以下原则处理：

- 能从上下文 99% 确定原意的，直接改（比如"陈经理矿机"在产品讨论里几乎必然是"产品经理"）。
- 不能确定但明显是错别字的，改了之后在文末"说明"段落里列一笔，让用户能回查。
- 完全猜不出来的，原样保留，并在该处用 `[?]` 标注。

**重要**：纠错只改字符，**不要意译、不要"美化口语"、不要替发言人补全没说出口的逻辑**。纪要要忠于原会议，"听起来更专业"不是目标。

### 步骤 4：按标准模板组织

读取 `references/template.md`，这是固定的纪要骨架。**严格按这个模板的顺序和章节来填**，不要自己发明新章节，也不要省略章节（如果某章节这次会议确实没内容，写"本次会议未涉及"而不是直接删掉）。

填的时候记住几条：

- **⚠️ 隐私硬规则：纪要里不暴露真实全名 / 中文全名 / Zoom 显示名 / 拼音全写**：
  - **优先级**：① 英文名（Carl / Alice / Frank / Bob / Dave / Jaco / Bason / Sam / Amy 等）→ ② 已确立的中文称呼或昵称（**小楚 / 张工 / 阿牛**等）→ ③ 描述性角色（"远程数据负责人"）。**绝不**使用真实全名或外文姓全写。
  - ❌ "Carl（张三 / San ZHANG）" ← 暴露了真名和拼音
  - ❌ "Bob（李四）" ← 暴露了真名
  - ❌ "Eve（转录里识别为 'lee fulln'）" ← 暴露了 Zoom 显示名
  - ❌ **生造英文名占位**（如 "Alan" 代替小楚）—— 容易造成"团队里其实没这个人"的混乱
  - ✅ "Carl" / "Bob" / "Eve" / "小楚" / "张工"（昵称或既有称呼直接用）
  - 这条适用于**参会人员行、议题正文、说明段、行动项**——纪要里**任何地方**都不要出现中文真实姓名或拼音转写。
  - **文末"说明"段也不要列 真名 → 英文名 映射**，只写"人名已统一为团队内英文名 / 既有昵称（Carl / 小楚 / Alice 等）"。详细映射只在 skill 内部 glossary 里有，**不暴露给纪要的读者**。
  - **不知道某人英文名时**：直接用转录里 Alice / 团队对他的称呼（如"小楚 / 张工"）——不要发明新名字。如果只有 ASR 错写多种形式，统一用最常见 / 最像本人的那种。
  - 这是用户的明确隐私要求。
- **参会人员只列实际发言的人**：纪要顶部 metadata 里的"参会人员"那一行，**只写本次会议里实际发言/在场的人**。不要加"缺席但被提及""未到会但被讨论"这类条目——被提及的人物（老板、同事、客户）在议题正文里自然出现就够了，metadata 里不需要重复。这是用户的明确偏好。
- **议题分块**：一个议题一个 `### 议题 N：标题` 小节，每个小节里再分"背景/讨论/结论"。
- **分歧要写出来**：如果某个问题 A 说一种、B 说另一种，最后没定，**明确写出双方观点 + "未定，会后再议"**。不要替会议下不存在的结论。
- **行动项要有主、有事、有时**：每条行动项必须有"负责人 + 具体动作 + 截止时间"。没截止的写"待定"，但不要省略这一列。
- **数字、版本号、链接、域名、价格** 这些信息要原样保留，不要四舍五入也不要省略。

#### ⚠️ 严格源忠实（Source Fidelity Rule · 不可违反）

**纪要里写进去的每一个事实、每一个人物标签、每一段背景描述，都必须能在本次转录里找到原话或直接对应的发言**。

明确禁止的脑补来源：

- ❌ **跨会议串戏**：从用户之前给过的别的会议转录里、之前你帮他整理过的别的纪要里、glossary 里记过的背景里，往这次纪要里抄事实。
  - 反例：上次有一份「Eve 入职对齐」会议，所以这次站会的纪要里给 Eve 标了"（**新成员入职首日**）"——但本次转录里**没有**"今天入职""第一天""首日"这种字眼，所以**不能写**。本次转录里只有"我们新同志刚加入嘛"（来自 Dave），那就只能写"（**新同事，刚加入**）"。
- ❌ **从职位/能力推断当下事件**：知道某人是 CTO，不代表能在纪要里写"这次他主导了 X"——除非转录里他确实主导了。
- ❌ **把背景常识塞进纪要**：比如"团队正处于关键冲刺期"这类总结性框架，**只有在转录里有人明确说过类似的话**才能写；否则去掉。
- ❌ **替没说出口的人补充意图**：如果 A 在转录里只说了"OK"，不要写"A 同意了 X 方案"——他只是说了 OK，至于他同意的是什么，留给读者读上下文。
- ❌ **把通用观察当成个人特征**：主讲人在讨论某人时，常会顺带说一句通用观察（"做这个方向的研究生通常两年半都在踩雷"），这是**对整个职业方向的判断**，不是这个候选人本人的经历。**绝不可以把通用观察归到具体某人身上**，否则会让纪要看起来像在做人身评价。
  - 反例（踩过的真实坑）：Alice 在面试 李工 时说"项目型人才好——这个方向的研究生通常读三年两年半在踩雷"，我原文整理时写成了"**她**研究生读三年，两年半都在踩雷"——这是错的，**通用观察被错误归到了她个人**。正确写法是"**一般情况下做这个方向的研究生**读三年，两年半都在踩雷——所以项目型人才落地经验直接换两年半的时间"。
  - **自检方法**：所有形如"她 / 他 + 时间段 + 状态"的句子（如"她读三年两年半都在踩雷"、"他工作 5 年都在做杂活"），回查转录看主语是否真的是这个人——还是讲一类人的通用描述。

允许的最大程度推断（仅限以下三种）：

- ✅ **ASR 错字纠正**（已经在 glossary.md 覆盖）；
- ✅ **代词解释**（"他"、"那个"指代谁，从上下文清楚的情况下可以补全）；
- ✅ **隐式总结**（把多次零散讨论合并成一个议题时，做一句话总结——但用词要保守，避免"夸大"或"补完")。

**自检方法**：写完纪要后扫一遍，凡是带有"首"、"第一次"、"刚"、"已经"、"长期"、"一直"这种**时间/状态判定词**的句子，都要问自己——**这个词转录里出现过吗**？没出现就删。


### 步骤 4.5：交付前检查（敏感内容 / 政治正确清单）

**这一步是把纪要写完之后、动笔保存之前的强制检查**。来自一条真实复盘：之前曾经把"会后一对一私聊"的薪资/工时/岗位安排原样写进会议纪要，意识到那段内容根本不该出现在能发群的文档里。**这种错误一次就够了，靠 skill 强制扫一遍**。

逐条扫描下面 5 项，**任何一项命中，必须主动处理**（折叠、删除或加 INTERNAL ONLY 标记），处理完才进入步骤 5：

1. **个人隐私 / 一对一私聊**：薪资、工时、奖金、绩效评级、个人健康、家庭情况、离职意向、晋升计划、岗位调动安排，以及任何"会议结束后某两人单独留下来谈"的内容。
   - **处理**：放进 `<details>` 折叠块，块顶写 `⚠️ INTERNAL ONLY · 私聊内容，发群前请删除整节`。不要直接删（用户自己回溯需要看），但绝不能让它在默认视图里出现。
2. **老板/上级未拍板的设想**：会议里被提到的"老板想做 X"、"我设想要做 Y"、"未来可能 Z" 但**还没正式定**的方案。
   - **处理**：要么不写，要么明确加"**未拍板 · 不要向下传达**"标注。**不要把它写成既定结论**——因为方案改了之后承诺人会被动。
3. **转岗 / 团队调整话术**：涉及把某人从 A 组挪到 B 组、调整汇报关系、缩减/扩大职责范围的描述。
   - **处理**：用"安排到一个更好的团队 / 调整到更匹配的方向"这类正向话术，不要直接写"转岗""调走""换组"。如果是 INTERNAL 内容，照样进折叠块。
4. **工作安排只讲坏不讲好**：给某人新派任务、调整工作量、要求加班/加速时，**必须同时把"对他的利益"讲清楚**——不只是写"X 负责 Y，截止 Z"，要补一句他为什么应该接（成长 / 曝光 / 后续机会 / 薪资 / 职业路径）。
   - **处理**：如果会议里没讲清楚利益，纪要里**明确标注"利益点待补充"**作为待跟进项，提醒下次单独沟通时补上。**利益不讲透，执行就会拖。**
5. **群里 push 还是私聊 push**：行动项里所有"催 X 做事"的安排，默认**走工作群**（借领导/全员在场的影响力推进），而不是写"私聊跟进"——因为私聊容易被各种理由"忽悠"过去，群里就难推脱。如果某条确实只能私聊，纪要里说清楚原因。

**例（怎么折叠私聊段）**：

```markdown
## 四、Dave ↔ Bob 私下衔接（其他人退会后）

> ⚠️ **INTERNAL ONLY · 私聊内容，发群前请删除整节**
> 涉及个人薪资、工时、岗位安排，仅供自己回溯。

<details>
<summary>展开查看（INTERNAL ONLY · 不发群）</summary>

…私聊内容…

</details>
```

完成这 5 项检查后，再进入步骤 5 实际保存文件。

### 步骤 4.7：Review Pass · 二次核对（强制 · 不可跳）

**这是初稿写完之后、保存交付之前的"二次核对"环节**——目的是用转录原文反向校验初稿里每一个事实陈述，专门抓四类问题：

1. **脑补 / 跨会议串戏**——纪要里有的事实，转录里其实没说过；
2. **事实错误**——人名、时间、数字、动作主语和转录原文对不上；
3. **重要内容遗漏**——转录里 Alice / 主讲人讲过的关键板块、行动项、人物职责，纪要里漏了；
4. **善意翻译 / 自作主张的术语替换**——比如 ASR 把产品名"CEO"误识别成"ceo"小写，初稿里被我"翻译"成了 CRM；或者把"中台"和"IM"当成两个东西；或者发明了一个团队里不存在的英文名（如"Alan 占位代号"——这是踩过的真实坑）。

**Review Pass 的执行流程**：

1. **重读转录原文**（如果文件太大，bash `wc -l` 看行数，然后 `Read offset=... limit=...` 分段读完，确保覆盖全文）；
2. **对照初稿，逐段核对**——每个议题、每个行动项、每个人物职责，都要在转录里能找到原话或直接对应的发言；
3. **建一份"差异清单"**（不一定要写在文件里，列在 todo 里就行）：
   - 🟥 **重大事实错误**——必改（如：开除的两个人写错了、负责人挂错了）
   - 🟧 **脑补 / 遗漏**——必改（如：写了"长期"但转录没说、漏了某人的板块）
   - 🟨 **术语翻译过度**——必改（如：CEO→CRM、ASR 没注明等于 STT、中台 / IM 当两个东西）
   - 🟦 **无伤大雅的细节**——可改可不改（如：措辞润色）
4. **改完后再扫一遍**——重点扫"首 / 第一次 / 刚 / 已经 / 长期 / 一直 / 关键冲刺期 / 入职首日"这些**状态判定词**，每出现一次都要回查转录原文，没出现就删；
5. **在文末"说明"段补一句**："本纪要经过 Review Pass 二次核对，已修正 N 处初稿问题"——让用户知道你做过这一步，他可以选择信任或要求看差异清单。

**为什么这一步必须强制**：

- 初稿是基于"我读了一遍转录的记忆"写的，**记忆会丢失细节、会混淆同名实体、会善意翻译**；
- Review Pass 是基于"我对着转录原文一字一字核对"——精度数量级提升；
- 真实踩过的坑（已经沉淀到本 skill 的反例库）：
  - 把"CEO（产品名）" 翻译成 "CRM"（一次）
  - 把"小楚"误标为 Carl（一次）→ 然后又生造一个"Alan"占位（再一次）
  - 把 Alice 口误的"bason / 流笔芯"当成独立的人（一次）
  - 把"Bob + Eve"写成被开除（应该是 Carl + Eve）
  - 把"巴基斯坦见客户"原样写进 metadata（虽然转录里有，但属于敏感信息）
- 每一个错误都是 Review Pass 能抓到的。

**Review Pass 的输出**：直接在初稿基础上 Edit 修订；如果差异很大（5 处以上重大事实修正），在回复里贴一份简短的"差异 → 修订"对照表给用户看。

### 步骤 5：三输出交付（强制）

**每次跑 skill 必须产出三份文件**——

1. **原文整理版**（按时间忠实记录）
2. **规范化纪要 · 老板版**（结构化、完整，含 HR / 文化 / 心法 / 不确定清单全套）
3. **规范化纪要 · 正式版**（脱敏，只工作内容 + 行动项）

**三份缺一不可**。

#### 5.1 三份文件的分工

| 维度 | **原文整理版** | **规范化纪要 · 老板版** | **规范化纪要 · 正式版** |
|---|---|---|---|
| 文件名 | `会议原文整理-{主题}-{date}.md` | `会议纪要-老板版-{主题}-{date}.md` | `会议纪要-正式版-{主题}-{date}.md` |
| 组织方式 | 按**时间顺序**（保留实际发言流程） | 按**主题**重组（完整模板） | 按**主题**重组（脱敏模板） |
| 给谁看 | 自己 / 老板查证用 | 老板 / 管理层 | 团队群 / 全员 |
| 保留 | 谁说了什么 / 议题自然流转 | 决议 / 论据 / 行动项 / 负责人 + 全套 INTERNAL ONLY 段 | **只保留**：背景 / 产品板块 / 产品 K / 行动项 |
| 删除 | 填充词 / 单字段重复 / 客套 | 流水账 / 讨论过程 / 客套 | 流水账 + **全套敏感内容**（详见 5.4） |
| ASR 错字 | 全部按 glossary 纠正 | 全部按 glossary 纠正 | 全部按 glossary 纠正 |
| 隐私 / 钱待遇 | 按规则折叠 INTERNAL ONLY | 按规则折叠 INTERNAL ONLY | **直接全部删**——不折叠也不留 |
| TL;DR / 行动项汇总 | ❌ 不需要 | ✅ 顶部必有 | ✅ 顶部必有（TL;DR + 行动项） |
| 篇幅 | 转录原长 × 50-70% | 1 小时会议 2500-4000 字 | 1 小时会议 1000-1500 字 |
| 用途 | "Alice 当时具体怎么说的" | "全面理解 + 内部决策依据" | "团队群同步本月推进" |

#### 5.2 两份文件的存储路径和命名

**默认存储路径**：

```
~/Desktop/公司的文件/07-会议纪要/
```

**这个目录如果不存在，必须先用 bash 创建**（`mkdir -p "~/Desktop/公司的文件/07-会议纪要/"`），再写入文件。不要假设它一定存在。

如果当前 Cowork 把别的文件夹挂载成 workspace、并且明显意图是"放这个会的纪要进这个被选中的文件夹"，可以用 workspace 路径；但**没明确意图就一律走上面这个默认路径**。

**文件名格式严格固定（两份分别）**：

```
会议原文整理-{主题}-{YYYY-MM-DD}.md   ← 第一份，原文整理版
会议纪要-{主题}-{YYYY-MM-DD}.md       ← 第二份，规范化纪要
```

**注意**：两份文件的 `{主题}` 和 `{YYYY-MM-DD}` 必须**完全一致**——这样在 Finder 按主题筛选时，两份能一起出现，方便对照。

举例：

- 主题"0606周会-多板块规划与团队结构" + 日期 `2026-06-06`：
  - `会议原文整理-0606周会-多板块规划与团队结构-2026-06-06.md`
  - `会议纪要-0606周会-多板块规划与团队结构-2026-06-06.md`

#### 5.3 原文整理版的撰写规则（详细）

**这是新引入的输出形式，单独说清楚怎么写**：

1. **整体组织**：按**时间顺序 + 自然议题分段**——不重组顺序、不按主题归类；
2. **段落标题**：每个自然议题（持续 5-15 min 的一个话题）用 `## HH:MM-HH:MM · 议题简称`；
3. **段落正文**：
   - 主讲人（如 Alice 占 >60% 的会议）的连续发言**合并成段落**，每段 80-200 字；
   - 其他人的插话用 `> **[Speaker]**："xxx"` 引用块呈现，保留原话；
   - 转折 / 反问 / Alice 给的"反例"等修辞要保留；
4. **删除什么**：
   - ❌ 单独的"嗯/啊/对/对对对/这个这个那个那个"等填充词；
   - ❌ 重复同义的论据（"我们要快、要快、要快"留一次）；
   - ❌ 调试音视频 / 等人上线 / 找白板等会议前期杂事；
5. **保留什么**：
   - ✅ Alice 自己的论证链条、对比、举例（这些是她为什么这么想的核心）；
   - ✅ 数字、版本号、日期、平台名、模型名、人物名——**一个不能漏**；
   - ✅ 情绪 / 强调（"这是非常非常关键的"、"真的吃了大亏了"）——保留 1 个"非常"，但不堆"非常非常非常"；
6. **ASR 错字**：全部按 glossary 纠正——群运营→群运营、bason→Bob、小淑→小楚 等等；
7. **隐私 / 钱待遇**：照常折叠到 INTERNAL ONLY 区域，规则和规范化纪要一致。
8. **不确定项清单**：**不写进 md**，改为在对话里用文字列出让用户确认（规则见 5.5）。

#### 5.4 ⚠️ 正式版的脱敏规则（强制）

正式版是**给团队群 / 全员看的**，所以必须主动脱敏。**老板版 vs 正式版的差异**：

| 章节 | 老板版 | 正式版 |
|---|---|---|
| 一、会议背景 | ✅ 完整 | ✅ 完整（可略简） |
| 二、产品板块梳理 | ✅ 完整 | ✅ **保留 Base / Plus / IM / 模型 等技术板块**；电销板块**只保留技术路线 + 测试管理**，**删除 V1/V2/V3 失败复盘**（涉及离职背景） |
| 三、团队组织结构 | ✅ 完整 | ❌ **删除**（涉及离职、HR、人员安排）|
| 四、未来产品 产品 K | ✅ 完整 | ✅ 完整 |
| 五、流程与文化 | ✅ 完整 | ❌ **删除**（涉及 AI Native、奖惩等内部文化）|
| 六、INTERNAL HR | ✅ 完整 | ❌ **删除**（HR / 候选人 / 离职 / 钱待遇）|
| 七、行动项汇总 | ✅ 完整 | ✅ 保留，**移除离职人员相关条目** |
| 八、待跟进 / 悬而未决 | ✅ 完整 | ❌ **删除**（含管理层未拍板的设想）|
| 九、心法（Alice 反复强调的）| ✅ 完整 | ❌ **删除**（属于 Alice 个人思考心法，非工作流转）|
| 十、不确定项清单 | **不入文档**（改为对话确认）| **不入文档** |

**电销板块的特殊脱敏**：

- ✅ 保留：电销技术路线（一段式淘汰 / 三段式 / 音色克隆 / WER 等技术内容）、测试管理建议、上线时间计划；
- ❌ 删除：**V1 / V2 / V3 三个失败 Version 的具体复盘**（涉及 Carl + Eve 离职背景）、具体测试人员薪资金额、罚款金额。

**行动项的特殊脱敏**：

- ✅ 保留：所有面向当前在职团队的工作类行动项；
- ❌ 删除：涉及离职人员衔接、HR / 候选人面试、奖惩机制制定 等"内部管理"类行动项；
- ⚠️ 转化：把"利益讲透缺口" "Bob 三块负载评估" 等内部跟进项删掉。

**TL;DR 写法的差异**：

- 老板版 TL;DR：可以提"Carl 离职"、"团队结构调整"、"奖惩机制本月内出"等管理层关心的事；
- 正式版 TL;DR：只提产品 + 时间节点（如"群运营 Base 版 6/12 上线、IM MVP 6 月内交付、产品 K 7-8 月启动"）。

**篇幅控制**：

- 正式版目标 **1000-1500 字**（老板版的一半左右）；
- 如果超过 2000 字，回去再砍——正式版越短越容易让团队读完。

**结尾说明段**：

**正式版结尾不要加"这是脱敏版"之类的声明**——文档对外发出去后，**脱敏状态本身就是隐形的**，不需要也不应该在文末告诉读者"这份纪要做过脱敏 / 后面还有完整版"。

具体禁止的说明：
- ❌ "本纪要为正式版（脱敏）——以工作内容和行动项为主"
- ❌ "完整版仅供管理层查阅"
- ❌ "如有偏差请参考完整版"

正式版结尾**直接结束**，最多在文末加 "如有偏差，请以原始录音为准" 这一句，**不要透露还有别的版本存在**。

#### 5.4.1 正式版的额外脱敏细则（5 条）

除了章节级别的删除，正式版还需要应用以下 5 条细节脱敏：

1. **不提人员到岗 / 入职 / 离职的具体日期**——
   - ❌ "Bob 6/26 onsite 到岗承接"
   - ❌ "李工 7 月初到岗"
   - ✅ "Bob 承接" / "招聘中"
   - **理由**：到岗日是 HR 排期细节，对团队群读者没有信息价值，反而泄露 HR 安排。

2. **不提还没正式入职的候选人 / 名字 / 背景**——
   - ❌ "李工 7 月初到岗，某海外名校背景、项目型 PhD"
   - ✅ "招聘中"
   - **理由**：① 候选人信息本身就不确定（offer 可能黄）；② 涉及 PII（个人可识别信息）；③ 团队群里曝光候选人会让对方尴尬，也可能让对方反悔。

3. **不留"这是脱敏版"的元说明**——见上方"结尾说明段"。

4. **时间副词"下周一 / 本周内 / 下月初"等必须替换为具体日期**——
   - ❌ "Alice 谈 AI Lab 合作 | 下周一"
   - ✅ "Alice 谈 AI Lab 合作 | **6/8（周一）**"
   - **理由**：① 群里的人来自不同时区，"下周一" 各人理解不一样；② 一周后回看时"下周一"已经无意义；③ 具体日期能直接进日历。
   - **算法**：会议日期 + 时间词推算具体日期。如 2026-06-06 会议提到"下周一" = 6/8。

5. **公开身份的人员可以保留，但不提个人细节**——
   - ✅ "Bob 承接 [职责]"（保留英文名 + 工作分配）
   - ❌ "Bob（英国硬工科背景、某科研院所、机场赶飞机时还在改东西）"
   - ✅ "小楚（A 组业务负责人）"
   - ❌ "小楚（和 Alice 关系好像亲兄弟）"
   - **理由**：身份信息可以让团队知道谁负责什么；个人轶事 / 背景 / 性格不属于"团队群需要知道的"。

#### 5.5 ⚠️ 不确定项清单（强制 · 以「对话消息」形式输出，不写进任何 md）

> **【2026-07 更新 · 强制】不确定项清单只在对话消息里用文字输出，绝不写进任何 md 文件（老板版 / 原文整理版 / 正式版都不写）。用户在对话里确认后，照旧沉淀回 glossary。下方格式仅供在对话里组织内容时参考。**

**每次产出都必须给用户一份"不确定项清单"**——把整理过程中我无法 100% 确定的事实点 / 人物 / 术语 / 数字主动列出来给用户审定。

**为什么这一步强制**：

- 我整理时**必然有判断盲区**（陌生人名、模糊术语、矛盾表述、ASR 错识无法 100% 还原等）；
- 之前的做法是"我把不确定的当成确定的写进纪要" → 用户读完才发现问题 → 反复来回；
- 主动列清单 → **用户在交付时就能看到我哪些没把握** → 一次审定 → 沉淀到 glossary → 下次同类场景不会再问。

**清单里应该列什么**：

| 类型 | 例子 |
|---|---|
| 不确定的人名 | "彭瑞国"出现 1 次，是团队成员？外包？客户？ |
| 不确定的术语 / 类比 | Alice 说 "agent 用开源的，比如群聊 TDLib"——TDLib 实际是协议层不是 agent，是 Alice 类比还是 ASR 错？ |
| 矛盾表述 | 产品 K 同时被描述为"已存在但不成熟"和"未来要做" |
| 模糊数字 / 日期 | Alice 说"下周内 24 号 14 号之前 6 月 4 号之前"——我推断 **6/14 前**，但实际是哪个？ |
| 客户对接人 | "船长 / 老钱 / Sunri" 分别对应哪家客户？ |
| 上下文不通顺但 ASR 看着没错的句子 | 某句话语义不通，可能是 ASR 错但找不到合理替换 |

**清单的输出形式**（在对话消息里用文字列出，不写进 md）：

```markdown
## ⚠️ 不确定项清单（需要你确认）

整理过程中有以下事实点 / 人物 / 术语**无法 100% 确定**，列出来请你审定。审定结果会沉淀回 glossary，**下次同类场景不会再问**。

| # | 不确定的内容 | 转录原话 / 上下文 | 我的推断 | 待确认 |
|---|---|---|---|---|
| 1 | xxx | yyy | zzz | aaa |
```

**清单放在哪里**：

- **不放进任何 md 文件**（老板版 / 原文整理版 / 正式版都不写）。
- 作为**对话消息**发给用户确认；确认结果沉淀回 glossary。

**ASR 错纠的"我已经直接改了"** vs **"我不确定的列出来"** 怎么分？

- **我已经直接改了**（比如 群运营→群运营、bason→Bob、小淑→小楚 等 glossary 已有的映射）：**不列入不确定清单**，只在文末"说明"段提一下；
- **我推断改了但不 100% 确定**（如：张青代步 → 沾亲带故、英国 → 硬工科）：**列在"ASR 错纠案例"小表里**（在不确定清单的下半部分），让用户验证；
- **我完全无法判断的**（如：彭瑞国是谁、TDLib 是不是真的算 agent）：**列在主清单里**，是最重要的待确认项。

#### 5.6 交付时的回复

回复给用户时，**同时提供三份文件的 computer:// 链接**，并简短说明：

```markdown
三份文件已经落到 [文件夹路径]：

[会议原文整理-XXX](computer://...) - 按时间顺序保留 Alice 的实际发言流程，适合查证"Alice 当时具体怎么说的"。
[会议纪要-老板版-XXX](computer://...) - 按主题结构化，完整版，含 HR / 文化 / 心法 / 不确定清单，给老板看。
[会议纪要-正式版-XXX](computer://...) - 脱敏版，只保留工作内容 + 行动项，可以直接发团队群。
```

**文末必须加一个"说明"段落**，列出本次纠正的主要 ASR 错误（不用列全部，列代表性的 5-10 个就够），让用户能交叉核对。模板大致是：

> **说明**：本纪要基于 ××× 自动生成的中文字幕整理，已对明显的语音识别错误（如"XX"→YY、"XX"→YY……）做了纠正与术语统一。如有偏差，请以原始录音为准。

交付时用 `computer://` 链接，**不要把纪要全文粘到对话里**——用户看文件就行。回复保持简短，提一下做了哪些非显然的判断（比如"我把'Eve'这段从转录里拆出来单独成议题"），让用户能挑战。

## 三、关键判断准则

### 什么是"决议"什么是"讨论"

决议必须是**显式承诺过的、可执行的、有责任人的**。"我觉得我们应该 X"不是决议，"OK 那就 A 负责 X，周五前"才是决议。如果 A 没明确说"我接"，就放在"讨论"里，并在"待跟进"里写"X 的负责人待定"。

### 什么时候省略，什么时候保留

- **省略**：客套（"对对对""嗯嗯"）、重复确认、跑题闲聊、口头禅、自我修正过的发言（"我刚说错了，应该是 X"——只保留 X）。
- **保留**：分歧、顾虑、未解决的问题、技术决策的理由（不能只写结论，要简短带上"为什么这么定"——以后回看才有价值）。

### 议题怎么切

不要按时间顺序切（会议是非线性的），按**主题**切。如果"A 议题"被讨论了三次中间穿插了别的，整理时把三次合并成一个议题。

切完后排序时，按**重要性**排，不是按出现顺序排。一般顺序是：核心共识 → 分工/流程 → 各业务议题 → 工具/流程性话题 → 待跟进的小事。

## 四、风格要求

- **语言**：简体中文。即使原会议夹了英文术语（如 LiveKit、Agent、TTS、API、MVP），术语保留英文，叙述用中文。
- **语气**：克制、客观、不卖弄、**不口语 / 不大白话**。详见下方"口语化→书面化转换规则"。
- **格式**：
  - 顶部 metadata 用引用块（`>`）写时间/参会人/整理日期。**仅一行简洁注释**，避免堆砌"注 1 / 注 2 / 注 3"——除非真正必要（如 IM = 中台 这种术语等价说明）；
  - 议题用 `###`，子分块用粗体或 `####`。
  - 行动项用 markdown 表格，列固定为 `# | 行动项 | 负责人 | 截止`。
  - 不要滥用 emoji（一个都不要，除非用户明确要）。
  - **不写流水账**（详见下方"反流水账规则"）。

### ⚠️ 口语化 → 书面化转换规则（强制）

**两份文件都适用**。整理时遇到口语化、随意化、生活化的表达，要**改写成书面化的中文**——但**只改表达，不改意思**。

**改的方向**：

| 转录原话（口语） | 改写为（书面） |
|---|---|
| "牛逼 / 屌的很 / 牛逼的屌的很" | "出色 / 表现强 / 能力突出" |
| "搞砸了 / 搞死了 / 搞这种东西" | "处理不当 / 失败 / 做这件事" |
| "飞出差" | "出差" |
| "拉的最近吃亏最多" | "近期投入产出比最低" / "近期挫败感最强" |
| "啥都不会" | "技术储备不足" |
| "他妈的" / "卧槽" / "妈的" | 直接删（脏话 / 语气词无信息量） |
| "你看这个事吧" | "关于这件事" |
| "我们要快、要快、要快" | "我们要快"（重复同义只保留 1 次） |
| "非常非常非常关键" | "非常关键"（保留 1 个非常代表强调，不堆叠） |
| "对对对，对对对" | 删（纯填充词） |
| "完蛋了 / 玩完了" | "失败 / 收尾不佳" |
| "吹嘘 / 吹牛 / 吹牛卖货" | "对外讲故事 / 商务沟通 / 价值展示 / 营销路演" — **绝对不要用"吹牛卖货"作为"升级"**（仍然口语化）|
| "做时间冗余" / "做资源冗余" | 必须根据上下文判断维度：人员数量冗余 / 时间冗余 / 资源储备 — **不要随便换维度的词**|

**不改的方向**（一字不动）：

- ✅ **数字、版本号、人名、术语、平台名、模型名**——任何时候都不动；
- ✅ **决议、行动项、关键论据**——保留原话精确性；
- ✅ **团队内部约定的术语 / 黑话**（在 glossary 里有定义的）——保留；
- ✅ **Alice / 主讲人个人风格的标志性表达**（如她常说的"非常非常"）——保留 1 次。

**边界 / 自检**：

1. **改完之后，原话的"力度"有没有减弱？** Alice 说"我们吃了最多亏"是强调感受，改成"投入产出比最低"是事实描述——力度变了，所以要**保留原话的强调**：用"近期挫败感最强的板块"既书面化又保留力度；
2. **改完之后，原话隐含的态度有没有丢？** Alice 说"那个 AI 负责人这样还问我用什么软件——这种人不行" 改成 "该候选人不适合工程实现" 把判断保留了，但 Alice 的鄙夷态度丢了。在原文整理版可以保留 Alice 的态度（用"Alice 评价：...这种人不行"），在规范化纪要里只留判断结论即可；
3. **如果两种改法犹豫**：原文整理版倾向保留口语原味 + 加微小书面化；规范化纪要倾向完全书面化。

### ⚠️ 玩笑 / 跑题 / 与主题无关内容的删除规则（强制 · 边界要谨慎）

**两份文件都适用**。整理时遇到不直接服务于会议产出的内容，要**主动删除**——但**边界要小心**。

#### 应当删除的内容（直接删，不留痕）

| 类型 | 例子（删） |
|---|---|
| 纯调试 / 杂事 | "我把音频打开一下"、"白板看不到调一下"、"等 Alice 上线"、"那边那个谁来一下" |
| 工作之外的玩笑 | "我们昨天那顿饭真的太贵了"、"周末有人去打球吗" |
| 个人脾气评价 | "他这个人脾气是真的不好"（**除非**是工作场景里的判断依据） |
| 抒情 / 矫情 / 比喻 | "我感觉这就像爬山一样啊"、"咱们这一路走来真的不容易" |
| 半截没说完的填充 | "那个那个那个" / "我，我，我，我刚才说的是" / "嗯啊嗯" |
| 完全跑题的回忆 | "上次去新加坡见了一个朋友，他说的也是这个意思" 如果不直接服务于当前论点就删 |

#### **不能删的内容**（看起来像玩笑 / 跑题，但其实有信息）

| 类型 | 例子（保留） | 为什么保留 |
|---|---|---|
| 论据性的反例 / 类比 | Alice："那个 AI 负责人还问我用什么软件——这种人一定不适合工程" | 这是 Alice 判断"项目型 vs 学术型"的关键论据 |
| 反映价值观 / 文化 | Alice："我自己也适用所有条款，我违反了也一样罚" | 这是奖惩机制的**关键背书**，去掉就理解不了 Alice 为什么这么定 |
| 体现战略思考的轶事 | Alice："Sam 朋友的老板说他们每月花钱学 AI" | 这是 Alice 论证"AI Native"的**对照案例**，去掉论证就空了 |
| 反映组织信号 | Alice："这三个人都是沾亲带故的" | 这解释了为什么要"做时间冗余 + 选好人"——**操作依据**，不是闲话 |

#### 边界判断（强制自检）

每遇到一句似乎可以删的话，**问自己 3 个问题**：

1. **它是否服务于一个决策 / 论点 / 价值观判断？**
   - 是 → **保留**
   - 否 → 进入下一问
2. **如果删掉，读者会不会少理解一个动作的"为什么"？**
   - 会 → **保留**
   - 不会 → 进入下一问
3. **它是否纯属调味（情绪 / 修辞 / 调侃）？**
   - 是 → **删**
   - 否 / 不确定 → **保留**（不确定就别删）

**核心心法**：**删错了，信息丢了不可逆；多保留一句，最多浪费几个字。所以遇到 50/50 的犹豫，一律保留。**

### ⚠️ 反流水账规则（强制）

**纪要不是会议的逐字回放，是"会议成果的浓缩 + 可执行的下一步"**。常见的"流水账"陷阱：

- ❌ "11:32 Alice 开始正式输出"——开场谁连音视频、谁先发言、什么时候开始正式聊，**全部不写**；
- ❌ "Alice 说 X，Dave 回应 Y，Alice 又说 Z"——除非分歧本身是会议产出，**不写谁先说谁后说**；
- ❌ "讨论了 10 分钟某话题，最后没结论"——**只写结论**：如果没结论就写"未定，待 X 时间再议"，不写讨论过程；
- ❌ 重复同义的论据 / 反复确认 / 客套——**全部砍掉**。

**正确的写法是"方法 + 细节"**：

- ✅ 议题的**决议**是什么；
- ✅ 推导出这个决议的**关键论据**（1-2 条，不是全部讨论过程）；
- ✅ 落地的**方法**（具体怎么做，不是抽象口号）；
- ✅ **可量化的细节**（时间节点、版本号、平台名、模型名、责任人）；
- ✅ 显式的**分歧**（如果有，简明写出 A / B 两方观点 + 是否拍板）。

**自检**：写完后扫一遍每个段落，问自己——"如果删掉这句话，读者能不能少做错一个决策、少漏一个交付？" 答案是"不会"就删。

### ⚠️ 信息浓度机制（强制）—— 防止内容过多稀释注意力

**纪要篇幅控制原则**：

1. **顶部必有"TL;DR 三句话"**——所有 metadata 之后、议题之前，强制放一段"如果只看 3 句话能掌握的内容"。例如：
   > **TL;DR**：本周群运营 Base 版 6/12 上线；电销板块 Carl 离职后由 Alice 临时顶；IM (中台) MVP 6 月内交付，并行做 Plus 版调研。

2. **议题数量上限**：单份纪要**不超过 8 个议题**。议题多于 8 个时**合并相关议题**——把"音色克隆方案" + "音色技术成本" + "音色 API 选型"合成一个议题"音色克隆方向"。
3. **每个议题正文 ≤ 8 个 bullet**。超过 8 个就说明你在写流水账，需要再浓缩。
4. **可折叠 / 不可折叠的分配**：
   - **不可折叠**（核心层）：TL;DR、核心共识、本周冲刺、行动项汇总；
   - **可折叠**（详情层）：议题正文（每个议题用 `<details>` 折叠详情，**只在 summary 里露 1 行结论**）；
   - **必折叠**（敏感层）：HR / 私聊 / 钱待遇 / 未拍板设想；
   - 默认呈现 = 核心层完整可见 + 详情层折叠 + 敏感层折叠（且 INTERNAL ONLY 警示）。
5. **数字 / 链接 / 版本号原样保留**——这些是不能省略的具体细节；但**形容词、副词、口语化短语**全部砍掉。

**自检**：纪要保存前，**估算字数**：
- 1 小时会议 → 目标 1500-2500 字（不算折叠区）；
- 2 小时会议 → 目标 2500-4000 字；
- 超过 5000 字的纪要，回去再砍——一定有流水账没清完。

### ⚠️ 钱 / 收入 / 待遇硬规则（强制）—— 高敏感内容必须双重隔离

**任何涉及以下内容的数字 / 描述，纪要默认不能放在可发群的"明面层"**：

| 类别 | 例子 |
|---|---|
| 个人收入 / 薪资 | 月薪、日薪、时薪、奖金、提成比例 |
| 测试 / 外包 / 顾问报酬 | 测试人员日薪 200/300、外包顾问月费 |
| 罚款 / 扣款 | 1000/1500 罚款威慑数额、扣款比例 |
| 待遇 / 福利 | 假期天数、调休额度、商保等级、报销标准 |
| 招聘待遇 | 候选人 offer 数字、薪资 range、签约金 |
| 个人 ROI / 业绩相关 | 个人产出折算钱、个人贡献评估 |

**处理方法**（强制三选一）：

1. **直接不写**——会上提到的具体数字省略掉，纪要里只写"按市场行情对接 / 具体金额本周内单独确定"等中性表述；
2. **抽到 INTERNAL ONLY 折叠区**——单独建一段"钱 / 收入 / 待遇相关数字"表格，块顶写明 `⚠️ **严格不发群、不外传，仅供自己回溯 + 老板确认前的依据**`；
3. **用相对数表达**——把绝对金额改成相对比例（"罚款金额定在'让人记得住'的级别，本周确定"）。

**绝对禁止**：

- ❌ 在可发群的明面层直接写"测试人员日薪 200-300 元"——这暴露了对方收入；
- ❌ 在可发群的明面层直接写"罚款 1000-1500 元起步"——这是团队内部薪资敏感信息；
- ❌ 在"说明 / 数字"段落里把这些数字当作普通 ASR 纠错列出来——让所有读纪要的人都看到。

**这一条的依据**：用户明确反馈："涉及跟钱，收入和待遇相关的内容的东西，需要十分敏感，不要说出来。必须明确了之后才能发布出来。"

业务类成本数字（如"API 0.01 美金 / 分钟"、"自训练 500 万 vs API 50 万"）**不受这条规则约束**——因为它们是公司成本结构而非个人待遇，正常写。

## 五、参考文件

| 文件 | 用途 | 何时读 |
|---|---|---|
| `references/template.md` | 标准纪要骨架 | 写纪要前必读 |
| `references/glossary.md` | 团队术语表 + ASR 错别字对照 | 纠错阶段必读，遇到新名词时更新 |
| `scripts/detect_topics.sh` | 长会议议题边界探测器 | 步骤 1.5 分流判定为"长"时必跑 |

## 六、术语表的迭代

### 6.1 被动迭代——遇到术语表里没有的新名词

如果在整理过程中遇到术语表里没有但明显属于团队常见词的字符串（比如新加入的同事、新接的产品、新工具），**整理完之后在交付消息里提一下**：

> 顺便：术语表里没有「XXX」，这次我推断是「YYY」，建议加进 glossary.md 的"团队成员"/"产品名"段。要的话我可以帮你更新。

这样 skill 会越用越准。

### 6.2 主动迭代——项目专业术语自动识别（强制）

**这一步在 Review Pass 之后、交付之前执行**——专门挖掘项目里的"专业术语 / 内部黑话 / 产品别称"，主动报给用户。

**识别什么**：

- **行业专有名词不在通用词典里**：比如"群运营"（自动化群聊营销）、"群运营"（群运营的 ASR 错写）、"中台 / IM"（团队对同一板块的两种叫法）、"产品 K"（公司产品代号）；
- **多次出现但术语表没收录的字符串**：在转录里出现 ≥ 3 次的非通用词，且 glossary.md 里没有；
- **明显是产品 / 竞品 / 工具名但首字母大写或英文夹中文**：如"ktin / ktm / k team"、"livekit"、"CEO（产品名而不是高管）"；
- **团队代号 / 内部黑话**：如"A 组"、"V1.0 合并 / V1.1 合并"、"304 大组"、"上 MVP"。

**怎么识别**（在写完初稿 + Review Pass 之后跑一遍）：

1. 用 bash 简单 grep / awk 出转录里所有"高频 + 非通用"候选词：
   ```bash
   # 提取转录正文（去掉发言人标签），按词频排序，过滤太短的、太常见的
   grep -v '^\[' "<转录路径>" | grep -oE '[一-龥]{2,8}|[A-Za-z]{3,}' | sort | uniq -c | sort -rn | head -50
   ```
2. 把 top 50 里**不在 glossary.md 里、不是通用词（"我们 / 这个 / 然后"等）**的提出来；
3. 给每个候选词加上：① 出现次数；② 上下文 1-2 句；③ 我推断的含义；
4. **在交付消息末尾放一段"术语候选清单"**给用户审定。

**输出格式**：

```markdown
**【术语候选】发现 X 个可能值得加进 glossary 的项目专业术语：**

| 候选词 | 转录里出现次数 | 上下文片段 | 我的推断 | 建议归类 |
|---|---|---|---|---|
| 群运营 | 28 | "我们不要把 im 和群运营（群运营）给它搞混淆了" | 自动化群聊营销板块 | 业务板块 |
| 小楚的视图 | 7 | "小楚这边重点做的一个东西叫做视图" | 小楚负责的"会话管理"前端形态 | 内部功能命名 |

请确认哪些加进 glossary，哪些是 ASR 错写需要纠正后忽略。
```

**为什么强制做这一步**：用户的痛点是"等我读纪要发现术语没识别出来 / 错了，才提"——主动识别能在交付时就把"我不确定的内容"显式标出，**让用户审定一次，下次同类术语自动正确**。

**典型踩坑**（来自真实对话）：
- 转录里出现 28 次的"群运营"——一开始当成新词原样保留，后来用户指出是"群运营"的 ASR 错。如果首次出现就走"术语候选清单"流程，能在第一次交付时就被用户纠正掉，不会污染后续 N 次纪要。
- 转录里出现 6 次的"CEO"——一开始当成"高管"翻译成"CRM"，后来用户指出是竞品名。同理。

---

## 七、真实踩坑反例库（用户和我一起走出来的）

这一段不参与日常工作流，是给"以后改这个 skill 的人"看的——告诉你**每一条规则都是怎么从血的教训沉淀出来的**。看了这段，就不会想砍掉某条规则。

### 7.1 文件核验类

| 踩坑场景 | 我犯的错 | 沉淀到 skill 的规则 |
|---|---|---|
| Zoom 同名 `meeting_saved_closed_caption.txt` 多份堆在 uploads 里 | 每次默认用最新附件，不告诉用户读的是哪一份；用户以为给了我新的会议，其实系统拿到的是旧的 | **步骤 1 开局文件核验** —— ls uploads + 内容指纹 + 主动告知 |
| Zoom 文件夹名 `2026-05-21 10.12.54 Xxx's Zoom Meeting` 是会议室固定命名，不是会议日期 | 我直接把"5/21"写进纪要，实际是 5/25 的会议 | **步骤 2 日期反推法** —— `stat` 看 modify 时间 + 字幕末条时间戳交叉校验 |
| 用户给了 Mac 真实路径 `~/Desktop/meeting_saved_closed_caption.txt`，但被 Cowork sandbox 拦截 | 我提示路径错，让用户重传 | **优先 `request_cowork_directory`** —— 而不是抱怨路径不通 |

### 7.2 源忠实类

| 踩坑场景 | 我犯的错 | 沉淀到 skill 的规则 |
|---|---|---|
| 上一份会议提到"Eve 入职"，下一份站会就给 Eve 标"（新成员入职首日）" | 跨会议串戏，把别处的背景塞进当前纪要 | **步骤 4 严格源忠实规则 + 自检词表**（首/第一次/刚/已经/长期/一直） |
| 转录里 Alice 说"复刻一个 ceo"（产品名），我善意翻译成 "CRM" | 把不通顺的术语自作主张翻译 | **glossary 加 CEO 条目** —— 产品名不是高管，保留原名 |
| 转录里 Alice 说"惯例上奖励是钱"，没说假期；用户提醒奖惩双向（钱 + 假期） | 漏写一面 | **glossary 加奖惩条目** —— 明确双向 |
| Alice 描述 Bob 时说"硬工科 + 某科研院所"，ASR 错识成"英国 + 某科研院所" | 没识别出"硬工科"和"英国"的同音字 ASR 错（yìnggōngkē ≈ yīngguó），按字面翻译成出身国家 | **glossary 加 英国/硬工科 条目** —— 上下文是技术 / 学科背景判断时是硬工科；地理 / 出差才是英国 |
| Alice 在面试李工时说"这个方向研究生通常两年半都在踩雷"，我写成"**她**研究生读三年两年半都在踩雷" | 把对**一类人的通用观察**错误归到候选人本人身上 | **步骤 4 严格源忠实新规则** —— "她 / 他 + 时间段 + 状态" 句式必须回查转录主语；通用观察句子主语应当是"做这个方向的人"而非具体某人 |

### 7.3 隐私 / 命名类

| 踩坑场景 | 我犯的错 | 沉淀到 skill 的规则 |
|---|---|---|
| metadata 写 "Carl（张三 / San ZHANG）" | 把真名 + 全拼都暴露进可发群文件 | **步骤 4 隐私硬规则** —— 任何地方都不出现真实全名 / 拼音转写 |
| 小楚没有英文名，我生造一个 "Alan" 作为占位 | 团队里其实没这个人 → 用户读完一脸懵 | **步骤 4 隐私优先级** —— 英文名 > 既有昵称（小楚 / 张工 / 阿牛）> 角色描述；**禁止凭空生造英文名** |
| Alice 在会议里把 Bob 的名字误说成 "bason / 流笔芯"，我当成两个人 | 团队里突然多了个不存在的 Bason 角色 | **glossary 加 Bob 一行扩展** —— 把 bason / 流笔芯 / 李四 都映射到 Bob |
| "陈兴兰 / 陈信男 / 陈先生 / 陈先安"是同一个人（Jaco）的多种 ASR 错写 | 当成不同的人列出来 | **glossary Jaco 一行收齐所有 ASR 变体** |

### 7.4 参会人员 / 团队组织类

| 踩坑场景 | 我犯的错 | 沉淀到 skill 的规则 |
|---|---|---|
| 参会人员里写 "Alice（CTO，今天主攻端到端延迟）、老板（在见客户）" | 把没发言的人也列进 metadata | **步骤 4 参会人员只列实际发言的人** |
| 把"中台 + 群运营 + IM"列为三个东西 | 实际上 IM = 中台，只是团队内部交替称呼 | **glossary 加 IM/中台 等价条目** |
| 把"小楚"识别为 Carl（早期 ASR 把 Carl 识别成"阿牛"，我把所有"阿X"都当 Carl） | 小楚和 Carl 实际是两个人 | **glossary 严格区分** —— 阿牛 = Carl（已离职）；小楚 = 小楚（A 组业务负责人，在职） |
| 复盘 V3 失败时把"被开除的两人"写成 Bob + Eve | 实际是 Carl + Eve；Bob 是 V2 阶段休息，从未被开除 | **glossary 标注每个人当前状态** —— 在职 ✅ / 已离职 ❌ |

### 7.5 敏感内容类

| 踩坑场景 | 我犯的错 | 沉淀到 skill 的规则 |
|---|---|---|
| 把 Dave ↔ Bob 的会后私聊（薪资、工时、岗位）原样写进正式版纪要 | 用户复盘后说"这是我下意识没意识到的隐私问题" | **步骤 4.5 敏感清单第 1 条** —— 个人隐私 / 私聊段强制 `<details>` 折叠 + INTERNAL ONLY 警示 |
| 写"老板在巴基斯坦见客户" | 暴露老板行程的地理标签 | **步骤 4.5 + glossary** —— 地理标签按"出差 / 现场"中性化 |
| 给某人派任务时只写动作 + 截止时间，不讲他为什么应该接 | 利益没讲透 → 执行会拖 | **步骤 4.5 敏感清单第 4 条** —— 利益讲透缺口必须显式标"待跟进" |

### 7.6 Review Pass 类

| 踩坑场景 | 我犯的错 | 沉淀到 skill 的规则 |
|---|---|---|
| 初稿写完直接交付，用户来回提了 5-6 轮事实修正 | 每次都是用户先发现错误，我才改 | **步骤 4.7 Review Pass** —— 强制在交付前自己重读转录原文做二次核对 |
| 张工重构三块只列出了"冗余方法 + 日志"，第三块"并发稳定性"漏了 | 初稿读得不仔细，三块没识别全 | **Review Pass 的"重要内容遗漏"检查项** —— 重读时专门扫"刚好这三个 / 这两个 / 几件事"这种枚举词 |

### 7.7 路径 / 部署类

| 踩坑场景 | 我犯的错 | 沉淀到 skill 的规则 |
|---|---|---|
| 默认存储路径用了 `~/Desktop/公司的文件/会议纪要/` | 用户后来把文件夹改名为 `07-会议纪要` | **步骤 5 默认路径更新为 `~/Desktop/公司的文件/07-会议纪要/`** |
| 文件夹掉线后直接报错给用户 | 应该主动 `request_cowork_directory` 重新申请 | **新连接策略** —— 路径访问不到时优先重新申请 |

### 7.8 措辞精度类（重要 · 容易反复犯）

这类错的共性是：**对的概念用错的词组表达**——读起来通顺但偏离原意。Review Pass 时要专门扫这种。

| 踩坑场景 | 我犯的错 | 沉淀到 skill 的规则 |
|---|---|---|
| Alice 说 "做一个冗余量"（要求 3 个找 4 个 = 人员数量冗余），我写成 "做时间冗余" | 同义词族里选错了：把"数量冗余"换成"时间冗余"——意思变了 | **关键名词不要"自动替换"** —— 遇到"冗余 / 缓冲 / 储备 / 备份"这类含义微妙的词，必须回查转录上下文，看 Alice 在讲什么维度（时间 / 数量 / 资源 / 能力） |
| 把 "调研 CEO" 和 "不做 1:1 复刻" 写在同一段，没说清楚两者关系 | 让读者疑惑"到底调研还是不调研"——其实是配套关系（调研 = 知己知彼，复刻 = 低 ROI） | **如果纪要里同一对象出现"做 X" + "不做 Y" 看似矛盾的两条**，必须**显式补一句**："X 和 Y 不矛盾，因为……"或"两者是配套关系" |
| 把 Alice 说的 "深挖了几个月没招到人 → 渠道不行" 写成 "传统渠道已经招了商务很多人 → 招不到电销" | 因果关系搞错了——招了商务很多和招不到电销之间没有逻辑链 | **因果句必须按转录原意写** —— 不要把"无关的两件事"用因果词强行串起来。Alice 的因果是"尝试过 + 久 + 无果"，不是"招过别人很多" |
| Alice 原话 "也是要吹嘘讲讲我们 AI 牛逼的屌的很"，我总结成 "吹牛卖货" | 把口语换成了**另一种**口语，仍然偏离书面化要求；"吹牛卖货"在正式纪要里不雅 | **口语化升级要保守**：① 口语 → 书面词（"吹嘘 / 牛逼" → "对外讲故事 / 价值展示 / 商务沟通"）；② **不要从一种口语换到另一种口语**（"吹牛卖货" 不算升级）；③ 中性表述优先于带情绪倾向的词 |
| Alice 说 "本周内 / 本月内" 类时间表述，我没仔细看用哪个 | 默认按"本周内"理解 → 实际是"本月内" → 给执行人压力错配 | **时间副词必须精确还原**：本周内 / 本月内 / 下周内 / 下月初——任何带"本 / 下"的时间表述，必须回查转录原话，**不要在两个相近时间词之间"自由选择"** |

---

## 八、近期沉淀 · v2026-06-27 新增（0615 培训 + 0627 录音）

这一节是 0615-0627 期间从实际使用中沉淀的新规则，**优先级高于前面任何规则**。

### 8.1 ⚠️ Zoom 录音账号 ≠ 实际发言人（最严重的新陷阱）

**问题模式**：Zoom 把所有发言都标成"录音账号的人"——但实际可能完全是另一个人讲。

**案例**：0615 那场 "「示例公司」 行业认知培训"——
- 录音是 Dave 账号录的 → ASR 把全场 1901 段都标 `[Dave]`
- 但**实际全场都是 Alice 主讲**（Dave 不在场，只是开了录音）
- 整份纪要差点把所有"我跟张工同步""我跟 Sam 讨论"全归到 Dave 身上

**高危信号 → 必须主动核验**：

| 条件 | 触发 |
|---|---|
| **单一发言人占比 >90%** | ✅ 必查 |
| **时长 >30 分钟** | ✅ 必查 |
| **性质像培训 / 讲座 / 1-on-N 单向输出** | ✅ 必查 |

**主动询问话术**：
> "这场是 X 自己讲的吗，还是别人讲的、用 X 账号录的？"

如果用户确认是别人讲的 → **全文 `[X]` 批量替换为实际主讲人姓名**。

---

### 8.2 ⚠️ 用户提供的提纲 / 大纲优先级 = 最高（黄金标准）

**问题模式**：ASR 错纠完全靠推断时，会产生大量"听起来合理但错的"术语推断。

**案例**：0615 培训整理后，用户给了 `AI_行业认知培训_提纲_v4.md`——一对照发现 **22 项推断错误**：
- `SDS` 应该是 **STS** （Speech-to-Speech）
- `Multicultural` 应该是 **Multilingual**
- `千问 3.6 / 千问富` 应该是 **Qwen3 系列**
- `Personal Lasa` 应该是 **Moshi**
- `TRPO` 应该是 **GRPO**
- `Seedance` 应该是 **可灵**（快手）
- `Sierra / FreshChat` 应该是 **Cresta / 3Chat**
- `积极性` 应该是 **新智元**
- 等等等等

**新规则**：

1. **整理纪要前先扫 uploads 目录** — 看用户有没有上传 `.md / .pdf / .docx` 等**会议主题相关**的提纲、PPT、大纲：
   ```bash
   ls -la /sessions/<sid>/mnt/uploads/*.md /sessions/<sid>/mnt/uploads/*.pdf 2>/dev/null
   ```
2. **如果有 → 优先 Read 提纲**，把它作为**黄金标准**，整理纪要时所有术语对照提纲；
3. **没有 → 才走纯推断**，并显式提示用户："如果有培训大纲 / PPT，可以一起上传，能极大提升术语准确性"。

**对 AI / 技术 / 行业类高术语密度会议尤其重要**。

---

### 8.3 Review Pass v3 · 三档术语核对（强化版）

**原步骤 4.7 的 Review Pass** 只查"事实遗漏 / 隐私 / 利益缺口"。**v3 新增"专业术语三档核对"**：

| 档次 | 描述 | 处理 |
|---|---|---|
| **A 类 · 学术上确定错** | 业内标准术语错了（如 SDS vs STS、Multicultural vs Multilingual、千问 3.6 不存在） | **直接改 + 列入"已修正"清单** |
| **B 类 · 推断弱** | ASR 错纠推断了一个，但置信度低（如某厂商名 / 视频模型名） | **改成更合理推断 + 加 [推测] 注 + 列入"不确定项清单"** |
| **C 类 · 待主讲拍板** | 自己 + 提纲都判定不了（如内部人名 / 内部代号 / 待确认数字） | **全部归到"不确定项清单"** |

**操作**：交付前自己重读一遍专业术语列表，按上面三档分类。

---

### 8.4 ⭐ 新增：音频文件自动转录支持

**触发**：用户上传 `.m4a / .mp3 / .wav / .ogg / .flac` 等音频文件（**没有提供 ASR 文本转录稿**）。

**新流程**：

1. **核验**：检查 ffmpeg + faster-whisper 是否可用：
   ```bash
   which ffmpeg && python3 -c "import faster_whisper" 2>&1
   ```
2. **不可用 → 装**：
   ```bash
   pip install --break-system-packages --quiet faster-whisper
   ```
3. **跑转录脚本**：
   ```bash
   python3 scripts/transcribe_audio.py <audio_path> <output_dir> 200
   ```
   - 内部用 `faster-whisper base 模型 + int8 + 4 核 CPU`
   - 切分 200 秒一段（避免 bash 单次 timeout = 45s）
   - 8 段一切总耗时约 3-5 分钟
4. **得到 `<basename>_transcript.txt`** —— 包含时间戳的转录稿
5. **同时把原始转录稿存一份到用户可见目录**：
   ```
   ~/Desktop/公司的文件/07-会议纪要/会议原始转录-{主题}-{日期}.txt
   ```
6. **走标准 huiyijiyao 三档流程** 整理纪要。

**⚠️ 关键质量约束**：

| 项 | 说明 |
|---|---|
| 模型 | base 模型（CPU 推理质量受限）—— **不是 Zoom 字幕级别** |
| 错误类型 | 中文人名 / 学校 / 数字 / 专业术语 ASR 错较多 |
| **必须做** | 纪要顶部加**转录质量声明** |
| **必须做** | 老板版的"不确定项清单"必须非常详尽（>10 项是常态） |
| **应建议用户** | 下次优先用 **Zoom 自带字幕**（质量好 10 倍） |

**示例声明**（放在纪要顶部 metadata 区下方）：

> ⚠️ **转录质量提示**：本场转录基于 faster-whisper base 模型（CPU 推理），**ASR 错误较多**。涉及人名 / 学校 / 数字均做了**最合理推断**并加入末尾"不确定项清单"。如有偏差请以原始录音为准。

---

### 8.5 引荐人画像沉淀（与 jianli-shaixuan skill 联动）

**问题模式**：候选人面试纪要里只提候选人本身，不记**引荐人是谁、什么背景、和候选人什么关系**。

**案例**：
- **张明阳**（0614 TTS 候选人）由 **胡国强** 引荐
- 胡国强 = **前语音实验室出来的实习生**
- 胡国强 ≠ 胡津源（注意区分！）
- 胡津源 = 0613 那场清华本科 → MBZUAI master 候选人

**规则**：候选人面试纪要里：
- ✅ 必须有"引荐人"字段
- ✅ 引荐人独立画像沉淀进 glossary
- ✅ 候选人 + 引荐人之间的关系明确写出

---

### 8.6 私聊段判定升级 + 整段删除

**原规则 7.5** 只把私聊段"折叠"。**v3 升级**：满足三个条件之一 → **整段直接删除**（不折叠）：

1. 涉及**私人事务**（婚姻 / 家庭 / 朋友圈 / 高尔夫安排）；
2. 与会议主题**完全无关**（不是工作话题）；
3. 含**他人姓名**（非参会人员）。

**案例**：0615 培训 13:59-14:08 中场休息段——涉及高尔夫球场 / 酒店 / 招聘人选私聊（"王明阳"vs"张明阳"的散讲）→ **整段删除**，关键招聘信息已沉淀到 0613/0614 那两场专门纪要。

---

### 8.7 三档纪要的"原始转录"备份规则

**v3 新增**：除了三档纪要文件，**原始转录稿也存一份到用户可见目录**：

```
~/Desktop/公司的文件/07-会议纪要/
├── 会议原始转录-{主题}-{日期}.txt    ← 新增
├── 会议原文整理-{主题}-{日期}.md
├── 会议纪要-老板版-{主题}-{日期}.md
└── 会议纪要-正式版-{主题}-{日期}.md
```

**目的**：用户可以随时回查"我到底说了什么、ASR 怎么识别的"，方便核对纪要里的不确定项。

---

### 8.8 主讲人核验 + 提纲对照 = 交付前必做两件事

**v3 升级版步骤 4.7 Review Pass**：

| 检查项 | 之前 | v3 升级后 |
|---|---|---|
| 1. 事实遗漏（"刚好这几个 / 这两个"枚举）| ✅ | ✅ |
| 2. 隐私 / 私聊段折叠 | ✅ | ✅（删除 / 折叠两档）|
| 3. 利益讲透缺口 | ✅ | ✅ |
| **4. 主讲人核验**（单一占比 >90% + 培训性质）| ❌ | **✅ 新增** |
| **5. 提纲对照**（如用户上传提纲）| ❌ | **✅ 新增** |
| **6. 专业术语三档核对**（A 类直改 / B 类推测 / C 类待确认）| ❌ | **✅ 新增** |