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 文件，带时间戳：

   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 看转录有多大，按时长分三档处理：

# 在 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"

按结果分流：

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

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

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

阶段 1：议题边界检测

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

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：

# 伪代码（在 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，原因就是只看了文件夹名。

检测命令：

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 做事"的安排，默认走工作群（借领导/全员在场的影响力推进），而不是写"私聊跟进"——因为私聊容易被各种理由"忽悠"过去，群里就难推脱。如果某条确实只能私聊，纪要里说清楚原因。

例（怎么折叠私聊段）：

## 四、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 三份文件的分工

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 正式版的差异：

电销板块的特殊脱敏：

• ✅ 保留：电销技术路线（一段式淘汰 / 三段式 / 音色克隆 / 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 → 下次同类场景不会再问。

清单里应该列什么：

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

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

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

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

清单放在哪里：

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

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

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

5.6 交付时的回复

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

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

[会议原文整理-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（一个都不要，除非用户明确要）。
  • 不写流水账（详见下方"反流水账规则"）。

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

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

改的方向：

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

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

边界 / 自检：

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

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

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

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

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

边界判断（强制自检）

每遇到一句似乎可以删的话，问自己 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 字的纪要，回去再砍——一定有流水账没清完。

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

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

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

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

绝对禁止：

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

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

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

五、参考文件

六、术语表的迭代

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 出转录里所有"高频 + 非通用"候选词：

   # 提取转录正文（去掉发言人标签），按词频排序，过滤太短的、太常见的
   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. **在交付消息末尾放一段"术语候选清单"**给用户审定。

输出格式：

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

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

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

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

典型踩坑（来自真实对话）：

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

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

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

7.1 文件核验类

7.2 源忠实类

7.3 隐私 / 命名类

7.4 参会人员 / 团队组织类

7.5 敏感内容类

7.6 Review Pass 类

7.7 路径 / 部署类

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

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

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

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

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

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

案例：0615 那场 "「示例公司」 行业认知培训"——

• 录音是 Dave 账号录的 → ASR 把全场 1901 段都标 [Dave]
• 但实际全场都是 Alice 主讲（Dave 不在场，只是开了录音）
• 整份纪要差点把所有"我跟张工同步""我跟 Sam 讨论"全归到 Dave 身上

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

主动询问话术：

"这场是 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、大纲：

   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 新增"专业术语三档核对"：

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

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

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

新流程：

1. 核验：检查 ffmpeg + faster-whisper 是否可用：

   which ffmpeg && python3 -c "import faster_whisper" 2>&1
   

2. 不可用 → 装：

   pip install --break-system-packages --quiet faster-whisper
   

3. 跑转录脚本：

   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 三档流程 整理纪要。

⚠️ 关键质量约束：

示例声明（放在纪要顶部 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：