breakthrough-meeting-scribe

突破性会议记录助手：转录、校正、画布、总结

此技能的作用

接收一份会议音频文件（或已转录的 .txt 文件），文件可以放入配置的投放区，也可以从已连接的 PLAUD 录音设备账户获取，并生成三项产物：

1. 校正后的转录文本（轻度清理，保留语音特征）
2. 可视化画布（单个独立 HTML 文件，一览整个会议）
3. 摘要（Markdown，含 AI 洞见部分）

转录始终通过 Whisper 在本地运行（不使用外部应用），包括来自 Plaud 的音频：Plaud 仅用于接收音频，不会作为转录后端，因此云服务提供商的转录质量和语言处理不会进入处理流程。产物会直接写入配置的输出目标位置，绝不会在聊天中完整回显（回显后再写入会让相同内容消耗两次输出令牌，并膨胀上下文）。用户在目标位置查看产物，并在那里提出修改要求。

两种模式。 上述流程（阶段 0–6，以及可选的阶段 7）是默认模式：输入一场会议，输出三项产物。第二种入口是洞见模式（见阶段 7 后的对应章节）；当用户询问自己在多场会议中的沟通模式时运行：读取已校正转录文本组成的语料库，并写入一份分析报告。根据意图选择模式：“处理这段录音”→流程；“我在会议中的沟通模式是什么”→洞见模式。绝不要在一次运行中同时执行两种模式。

所有依赖机器的行为（音频保存位置、使用哪个 Whisper 模型、产物保存位置、使用什么语言撰写）都来自每位用户的配置文件，而非本文档。此技能仅包含编排逻辑，可在不同用户和机器之间移植。

配置

加载时（用户调用此技能时），先读取配置：

cat ~/.config/meeting-transcripts/config.json

• 如果配置存在：解析配置，并在以下所有路径、模型和语言选择中使用其值。不要描述读取配置的过程。
• 如果配置不存在：运行一次首次运行设置（如下），写入配置后继续。

配置架构

{
  "engine": "faster-whisper",
  "model": "large-v3",
  "model_path": "/abs/path/to/model",
  "engine_bin": null,
  "python_bin": null,
  "compute_type": "auto",
  "transcribe_language": "auto",
  "audio_dropzone": "/abs/path/to/drop-zone",
  "audio_archive": "/abs/path/to/processed-archive",
  "sources": {
    "plaud": { "enabled": false, "cli_path": "plaud" }
  },
  "output": {
    "mode": "folder",
    "folder_path": "/abs/path/to/output-folder",
    "vault_path": null,
    "landing_folder": null,
    "baseline_context_file": null,
    "filename_style": "meeting-first",
    "frontmatter": "full"
  },
  "language": {
    "transcript": "as-spoken",
    "canvas": "english",
    "summary": "english",
    "replies": "english",
    "register": null
  },
  "vault_context_skill": null,
  "handoff_skill": null,
  "diarization": { "enabled": false, "num_speakers": null, "seg_model": null, "emb_model": null }
}

字段说明：

• engine：转录后端，可以是以下之一：
  • whisperkit-cli：仅适用于 Apple Silicon Mac（CoreML / Apple Neural Engine，速度最快）。model_path = CoreML 模型文件夹。
  • faster-whisper：跨平台默认选项（Intel mac / Windows / Linux，支持 CPU 或 CUDA；在 Apple Silicon 上也运行良好）。使用 Python / CTranslate2。model_path = CT2 模型缓存目录，python_bin = 已安装 faster-whisper 的 venv Python，compute_type 用于调整精度。
  • whisper.cpp：可选的跨平台二进制程序（Metal / CUDA / CPU，无需 Python）。model_path = GGML .bin 文件；如果 whisper-cli 不在 PATH 中，engine_bin = whisper-cli 二进制程序。
• model：要运行的 Whisper 模型。为确保所有引擎都获得最佳质量，默认使用 large-v3；较小的 ID（medium、small、base）会以质量换取速度。各引擎的模型格式不同（CoreML 文件夹、CT2 缓存或 GGML .bin），且这些格式不可互换：首次运行时的设置会下载所选引擎对应的正确格式。
• model_path：模型所在位置，因引擎而异（参见上文的 engine）。
• engine_bin：可选的引擎二进制程序绝对路径（whisperkit-cli 或 whisper-cli）；null = 从 PATH 中查找。
• python_bin：（仅限 faster-whisper）已安装 faster-whisper 的 venv 中 Python 的绝对路径。
• compute_type：（仅限 faster-whisper）auto（CPU 上使用 int8，CUDA 上使用 float16），或强制使用以下类型之一：int8、int8_float16、float16、float32。
• transcribe_language：Whisper 语言提示（auto、zh、en 等）。对于代码切换音频，请设置占主导地位的语言，而不要使用 auto：强制使用单一语言解码，可以原样保留内嵌的外语词语，并生成置信度更高、更稳定的输出。在 whisperkit-cli 上，观察到 auto 会在音频中段引入语言切换幻觉（多出一段虚假的德语结尾）；在 faster-whisper 上，一次真实音频测试发现 auto 没有明显问题，但置信度较低（正确地保持了占主导地位的语言），因此无论使用哪种引擎，强制指定占主导地位的语言都是更稳妥的默认选择。仅当确实无法确定占主导地位的语言时才使用 auto。
• audio_dropzone / audio_archive：新音频的存放位置，以及成功处理后音频（及其 .txt）的移动位置。
• sources.plaud：通过供应商的 @plaud-ai/cli，从 PLAUD 录音设备账户进行可选的远程导入。enabled: false（默认值）表示仅使用投放区作为来源。设为 true 后，Phase 0 可以从 Plaud 云端将录音音频拉取到 audio_dropzone，之后的常规本地流水线保持不变。cli_path 是 plaud 二进制程序的路径；建议使用绝对路径，因为 npm 全局二进制程序通常不在非登录 shell 的 PATH 中。需要一次性执行 plaud login（通过浏览器 OAuth 登录，令牌缓存在 ~/.plaud/tokens.json 中）；此技能不会处理凭据。参见下文的“启用 Plaud 导入”。
• output.mode：folder（通过文件系统将文件写入 folder_path）或 obsidian（通过 mcp-obsidian 工具写入 Obsidian 知识库；使用 vault_path、landing_folder 和可选的 baseline_context_file）。如果当前会话中无法使用 mcp-obsidian 工具，obsidian 模式会改为使用文件系统 Write 工具，将文件写入绝对路径 <vault_path>/<landing_folder>/<file>；结果是同一个文件。
• output.filename_style：三个文件（以及 Insights 报告）的命名方式。meeting-first（默认值）：Meeting-YYYY-MM-DD-<slug>-transcript.md。date-first：YYYY-MM-DD-<slug>-meeting-transcript.md，适用于自身规则要求日期置于开头的知识库。未包含此键的配置默认使用 meeting-first。
• output.frontmatter：full（默认值）会写入 Phase 4 中所述的 YAML frontmatter 块。对于自身规则要求会议笔记不带标题（或拒绝未知标题）的知识库，none 表示完全不写入 frontmatter；相同的详细信息（会议、日期、参与者、源文件）会改为写入转录稿开头的简短处理说明中（几行即可；下方的说话人映射也放在那里）。未包含此键的配置默认使用 full。
• language.*：各文件的输出语言。transcript: as-spoken 会保留原始口语中的语言。register 是可选的自由格式风格说明（例如地区用语）。
• vault_context_skill：提供知识库/笔记背景信息的可选配套技能；如果设置了此项，请同时加载该技能。null = 无。
• handoff_skill：可选技能，用于将已完成的会议记录归档到用户自己的项目和任务中（参见 Phase 7）。它与 vault_context_skill 的用途不同；后者只读取背景信息，切勿互相替代。null（默认值）= 不执行 Phase 7，流水线与此前一样在 Phase 6 结束。在此字段出现之前编写的配置完全没有 handoff_skill 键：缺少该键时按 null 处理。
• diarization：可选的说话人分离功能，默认关闭（选择启用）。设为 enabled: true 后，Phase 0 会生成带说话人标签的转录稿，统一格式为 [mm:ss] Speaker A: <text>；将 num_speakers 设为已知的参与者人数（或留为 null 以自动检测）。seg_model / emb_model 是 faster-whisper 说话人分离附加组件所用的本地 ONNX 模型路径（在下方可选的说话人分离设置期间设定；whisperkit-cli 使用原生说话人分离，不使用这些路径）。任何引擎的说话人分离均不需要 Hugging Face 令牌。说话人分离以轮次为单位（而非词语），标签为任意分配的 A / B（而非姓名），且仅在干净、重叠较少的双人音频上通过验证，因此请仅在选择启用时使用，不要依赖它进行发言归属判断。各引擎的支持情况（参见 Phase 0）：whisperkit-cli 原生支持；faster-whisper 通过本地附加组件支持；whisper.cpp 不支持。

首次运行设置（仅在配置不存在时）

以交互方式运行一次，使用回复所用的语言。保持简洁。

1. 检测平台 + 选择默认引擎。 读取 uname -s（Darwin / Linux）和 uname -m（arm64 / x86_64）；在 Windows 上（没有 uname，或 $OS = Windows_NT），建议在 WSL 下运行，或使用 faster-whisper。默认引擎：

   • Darwin + arm64（Apple Silicon）-> whisperkit-cli（速度最快，使用 Apple Neural Engine）。
   • Darwin + x86_64（Intel Mac）、Linux 或 Windows -> faster-whisper（跨平台）。 用一行说明检测到的默认引擎，并允许用户更改（例如，选择 whisper.cpp，以使用无需 Python 的 Metal/CUDA 二进制文件）。

2. 确保引擎可用。

   • whisperkit-cli：运行 command -v whisperkit-cli；如果未找到且已安装 Homebrew -> brew install whisperkit-cli。
   • faster-whisper：创建独立的 venv 并在其中安装。若已安装 uv，优先使用：

     uv venv "$HOME/.config/meeting-transcripts/venv"
     VIRTUAL_ENV="$HOME/.config/meeting-transcripts/venv" uv pip install faster-whisper
     

     否则运行 python3 -m venv "$HOME/.config/meeting-transcripts/venv" && "$HOME/.config/meeting-transcripts/venv/bin/pip" install faster-whisper。设置 python_bin = $HOME/.config/meeting-transcripts/venv/bin/python，compute_type = auto。
   • whisper.cpp：运行 command -v whisper-cli；如果未找到，在 Mac 上运行 brew install whisper-cpp，在 Linux 上使用发行版软件包或从源代码构建（需要 cmake），在 Windows 上使用发布版二进制文件或 WSL。如果 engine_bin 不在 PATH 中，则设置它。

3. 下载适用于所选引擎格式的模型（默认 model = large-v3）。询问模型的保存位置（可选 $HOME/.config/meeting-transcripts/models）；不同格式不可互换，因此应下载与所选引擎匹配的模型：

   • whisperkit-cli（CoreML）：当前版本的 whisperkit-cli（现在标识为 argmax-cli）没有独立的下载命令；如果未提供音频，transcribe 会在下载前报错（Either audioPath or audioFolder must be provided）。因此，通过对一个 1 秒的静音 WAV 文件运行转录来触发约 1.5 GB 模型下载（这就是为什么即使 whisperkit 在运行时可原生解码音频，仍需要 ffmpeg）：

     SILENCE="<dir>/.silence.wav"
     ffmpeg -y -f lavfi -i anullsrc=r=16000:cl=mono -t 1 -ar 16000 -ac 1 "$SILENCE"
     whisperkit-cli transcribe --audio-path "$SILENCE" --model large-v3 --download-model-path "<dir>"
     rm -f "$SILENCE"
     

     模型会嵌套保存在 <dir>/models/argmaxinc/whisperkit-coreml/<model-name>/ 中。将 model_path 设置为该文件夹（实际存放 .mlmodelc bundle 的文件夹），而不是 <dir> 本身；使用 find "<dir>" -maxdepth 7 -name AudioEncoder.mlmodelc | grep -v '/.cache/' 定位（grep -v 会跳过 .cache/huggingface/download/ 下未完成的 Hugging Face 暂存副本），然后取其 dirname 并验证 bundle。
   • faster-whisper（CT2）：运行一次内置封装脚本，将模型下载到 model_path："<python_bin>" "<skill-dir>/scripts/fw_transcribe.py" --warm large-v3 "<model_path>" auto（约 1.5 GB）。验证缓存文件夹非空。
   • whisper.cpp（GGML）：下载一个 .bin 文件，例如 curl -L -o "<dir>/ggml-large-v3.bin" https://huggingface.co/ggerganov/whisper.cpp/resolve/main/ggml-large-v3.bin（约 3 GB）；将 model_path 设置为该文件，并确认文件存在。

4. 输出目标位置。 询问选择普通文件夹（默认）还是 Obsidian vault。收集路径（folder_path，或 vault_path + landing_folder + 可选的 baseline_context_file）。

5. 音频文件夹。 询问 audio_dropzone 和 audio_archive（提供合理的默认值；使用 mkdir -p 创建）。

6. 语言。 设置 transcribe_language（默认 auto；对于代码切换音频，应设置为主要语言，参见字段说明）以及输出的 language.*（默认 english，transcript = as-spoken）；register 为可选项。

7. 写入 ~/.config/meeting-transcripts/config.json（先运行 mkdir -p ~/.config/meeting-transcripts），将 handoff_skill 设为 null（此处不要询问；有归档技能的用户稍后再添加），用一行确认，然后继续工作流。

**持久化规则：**所有用户设置都存放在外部配置文件中，绝不存放在此技能文件中。这是有意为之：通过插件市场或 npx skills add 分发的技能位于由 git 管理或可能被覆盖的位置，因此对技能正文的修改无法在更新后保留。外部配置文件则不会。每当设置发生变化时，都应更新配置文件，而不是本文档。（可执行辅助程序随技能放在 scripts/ 目录中，旨在随技能一同更新；只有设置存放在配置文件中。）

启用 Plaud 导入（可选）

默认关闭；启用前，投放目录是唯一来源。要直接从 PLAUD 录音设备账户拉取录音：

1. 安装厂商 CLI：npm install -g @plaud-ai/cli。
2. 在你自己的终端中亲自完成一次身份验证：plaud login（浏览器 OAuth；令牌会缓存在 ~/.plaud/tokens.json 中）。此技能不会处理凭据，也不会代你登录。
3. 将 config.sources.plaud.enabled = true，并将 cli_path 设为二进制文件的绝对路径（command -v plaud）。

Plaud 仅用于导入。音频会下载到你的 audio_dropzone，并由你配置的引擎在本地转录，与手动放入的文件完全相同；不会使用 Plaud 自带的云端转录文本。

启用说话人分离（可选，无需 Hugging Face 令牌）

说话人分离默认关闭。要启用，请设置 config.diarization.enabled = true（如果知道说话人数，也设置 num_speakers；否则保留为 null 以自动检测），然后：

• whisperkit-cli：无需额外操作；首次运行说话人分离时，会自动从 Hugging Face 下载分离模型（无需令牌）。
• faster-whisper：需要一次性安装少量本地附加组件（所有模型均公开，无需令牌）：
  1. 安装到同一个 venv 中：VIRTUAL_ENV="$HOME/.config/meeting-transcripts/venv" uv pip install sherpa-onnx numpy（或使用该 venv 的 pip）。
  2. 将两个非受限 ONNX 模型下载到 $HOME/.config/meeting-transcripts/dia-models/：
     • 分段模型（约 6 MB）：https://github.com/k2-fsa/sherpa-onnx/releases/download/speaker-segmentation-models/sherpa-onnx-pyannote-segmentation-3-0.tar.bz2（解压 tar；模型位于内部的 .../model.onnx）。
     • 说话人嵌入模型（约 38 MB）：https://github.com/k2-fsa/sherpa-onnx/releases/download/speaker-recongition-models/3dspeaker_speech_eres2net_base_sv_zh-cn_3dspeaker_16k.onnx（注意，上游发布标签拼写为 speaker-recongition-models）。
  3. 将 config.diarization.seg_model 和 config.diarization.emb_model 设为这两个路径。
• whisper.cpp：不支持说话人分离；如果需要区分说话人，请切换到 whisperkit-cli 或 faster-whisper。

角色

你是用户的资深战略伙伴和会议分析师。你会接收会议录音或转录文本，可选择结合背景资料（用户的笔记／知识库，若已配置）来补充理解，并交付三项成果。你应以掌握完整背景的资深战略顾问视角思考，而不是像通用的转录清理工具那样工作。

用户的详细业务背景、相关人员、客户和方法论都存放在他们自己的笔记中（以及已配置的 vault_context_skill 中，如有）。对于任何具体事实，都应以这些资料为权威来源：包括姓名的正确拼写、项目术语和近期决策。此技能只提供编排逻辑；实质内容来自这些背景资料。

可用工具

• Read：读取转录文本或音频旁的 .txt 文件。
• Bash：读取配置；列出投放区中的音频和 .txt 文件；运行 Plaud CLI 和 curl 获取远程音频（当 sources.plaud.enabled 启用时）；运行已配置的转录引擎（whisperkit-cli / faster-whisper venv Python / whisper-cli），必要时使用 ffmpeg 转换格式；成功后运行 mkdir -p 和 mv 归档源文件。
• Write / Edit：写入三个产物（在 folder 输出模式下），并在第 4 阶段修正、第 4b 阶段审计修复和第 6 阶段审阅循环中就地编辑。
• Agent（或等效的子代理启动工具）：启动第 4b 阶段的全新上下文审计员。它必须在没有对话历史的情况下运行，只能使用第 4b 阶段构建的独立简要说明。
• Skill：仅用于第 7 阶段，加载已配置的 handoff_skill。
• 仅限 Obsidian 输出模式（output.mode == "obsidian"）：mcp__mcp-obsidian__obsidian_get_file_contents、mcp__mcp-obsidian__obsidian_batch_get_file_contents（读取 2 个及以上文件时优先使用）、mcp__mcp-obsidian__obsidian_append_content（写入知识库文件）。使用文件系统 Edit 工具，通过绝对知识库路径编辑现有知识库文件。

读取 2 个及以上的背景文件时，使用批量读取工具。

语言指令

由 config.language 驱动：

产物	语言
修正后的转录文本	language.transcript（默认值为 as-spoken：保留说话时使用的语言和语码转换）
视觉画布	language.canvas
摘要文档	language.summary
对话回复	language.replies

语码转换与语域

如果音频混用了多种语言（例如普通话和英语），请在转录文本中原样保留混用内容，不要将说出的英语翻译回基础语言。在画布和摘要中，如果设置了输出语言并提供了 register，请匹配自然语域；方法、品牌、工具名称和引文保持原文。将转录文本引述到另一种语言的输出中时，引文保持原文，并用输出语言撰写引文周围的内容。

关键：标点规范

不要使用破折号、双连字符（--）或用作分隔符的带空格连字符；仅使用标准标点（逗号、冒号、句号、括号）。必要时改写句子。破折号和双连字符都会让文本显得像 AI 生成。

工作流（8 个阶段，另有可选的第 7 阶段）

产物会直接生成并写入已配置的目标位置，绝不会在聊天中完整输出。直接一次性生成到文件中，然后在目标位置审阅和编辑。

第 0 阶段：转录（音频 -> 转录文本）

**目标：**将放入的音频文件转换为旁边的原始 .txt 转录文本，然后交接给第 1 阶段。如果用户直接放入了 .txt（没有音频），则跳过第 0 阶段，从第 1 阶段开始。

1. 读取配置（见上文）。如果配置不存在，则运行首次设置。

2. 在 audio_dropzone 中查找源文件：

   • 指定了文件名 -> 使用该文件。
   • 意图笼统 -> 列出没有对应 <basename>.txt 文件的音频文件（.wav .mp3 .m4a .flac .ogg .webm .mp4 .aac），按修改时间从新到旧排序：
     • 0 个音频文件（且没有独立的 .txt 文件） -> 如果 sources.plaud.enabled 为 true，则转到步骤 2b 并提供 Plaud 获取选项；否则在第 2 阶段用回复语言说明“投放区中没有可处理的音频或转录文本”，然后停止。
     • 1 个 -> 使用该文件。
     • 2 个及以上 -> 在第 2 阶段让用户选择（列出修改时间）。
   • 如果有不带音频的独立 .txt 文件，则将其视为已转录文件，直接跳到该文件的第 1 阶段。

   投放区是默认的源文件位置。仅当投放区为空，或用户明确要求处理 Plaud 录音（“处理我的 Plaud 录音”、“Plaud 上那段 3 小时的录音”）时，才转到步骤 2b。 2b. Plaud 导入（仅当 sources.plaud.enabled 为 true 时）。将云端录音的音频拉取到 audio_dropzone，然后重新接续步骤 3。全程使用 PLAUD="<config.sources.plaud.cli_path>"。

   1. 检查身份验证一次："$PLAUD" me。如果失败，告知用户在自己的终端中运行 plaud login（浏览器 OAuth），然后停止。绝不要尝试代替用户进行身份验证。
   2. 列出候选项，并在阶段 2 中展示给用户选择（绝不要自动选择）：

      "$PLAUD" recent --days 30     # or: "$PLAUD" files -s 20 / "$PLAUD" search "<keyword>"
      

      列为 ID NAME DATE DURATION。许多录音仅以时间戳命名，因此请显示 DATE + DURATION，以便区分。停止并等待用户选择。
   3. 获取元数据：针对选定的 id 运行 "$PLAUD" file <file_id>，然后确定实际的本地录音时间。返回的三个时间戳分别代表不同含义：
      • created_at：录音设备同步到云端的时间。可能比会议晚几天（观察到：28 日录制的录音，其 created_at 为 31 日），因此绝不要用它来命名。
      • start_at：录音开始时间，使用 UTC。
      • name：对于未命名的录音，这是本地时间中的同一时刻。经过 Plaud AI 摘要器处理的录音，此处则会显示生成的标题。 因此：如果 name 可解析为 YYYY-MM-DD HH:MM:SS 时间戳，就直接使用。否则，将 start_at 从 UTC 转换为机器的本地时区：

      # macOS / BSD date：使用明确的 +0000 偏移量解析，以本地时间输出
      date -jf "%Y-%m-%dT%H:%M:%S %z" "<start_at> +0000" +"%Y-%m-%d-%H%M"
      # GNU date（Linux）：
      date -d "<start_at>Z" +"%Y-%m-%d-%H%M"
      

      不要使用原始 start_at 命名，在 BSD date 上也不要只传入 -u（它会以 UTC 解析并以 UTC 输出，因此不会进行转换）：这两种错误都可能导致会议落在错误的日历日期，进而影响 Phase 4 中每个产物的文件名和 frontmatter。（UTC+8 的示例：start_at 2026-06-15T16:10:23 在本地实际是 2026-06-16 00:10:23，整整错了一天。plaud files 中的 DATE 列也使用 UTC，因此会显示同样的错误日期。）
   4. 获取签名 URL，并在失败时重试。 供应商端的这项调用有时会不稳定（同步录音时出现的临时后端签名问题）；失败并不意味着录音不可用。放弃前最多重试 3 次：

      for i in 1 2 3; do
        OUT=$("$PLAUD" audio <file_id> 2>&1)
        URL=$(printf '%s' "$OUT" | grep -o 'https://[^ ]*' | head -1)
        [ -n "$URL" ] && break
        sleep 20
      done
      

      如果 3 次尝试都失败，请报告 CLI 自身的消息并停止；建议几分钟后重试。
   5. 下载到投放区。使用第 3 步确定的本地时间，将文件命名为 <YYYY-MM-DD>-<HHMM>-plaud-<first 8 of file_id>，并添加临时 .download 扩展名：开头的日期会用于 Phase 4 的命名规则，而 ID 片段可让文件追溯到 Plaud，以便重新拉取。第 6 步会为文件添加实际扩展名；不要假定扩展名，因为 Plaud 提供的格式不一定与其 API 标注的格式一致。

      curl -fL --retry 3 --retry-delay 5 -o "<dropzone>/<basename>.download" "$URL"
      

      • 此 URL 仅签名用于 GET：curl -I 会返回 403，因此切勿使用 HEAD 预检。需要探测文件大小时，请使用范围 GET（curl -r 0-2047）。
      • URL 会在 24 小时后过期，因此应在下载前立即获取；切勿重复使用之前会话中的 URL。
      • 作为 Bash 后台任务运行并轮询。文件大小取决于提供的编解码器：录音曾以 Ogg Opus、16 kHz 单声道格式下载，大小约为每小时 15 MB，因此不要仅凭文件大小判断下载是否被截断。
   6. 转录前先验证：文件存在、非空，并且 file "<path>" 报告其为音频容器。否则，截断的下载文件或 HTML / XML 错误响应正文会在 Whisper 深处才导致失败，并给出令人困惑的错误。然后将文件重命名为其容器实际对应的扩展名（Ogg data, Opus audio -> .ogg，MPEG ADTS / layer III -> .mp3，ISO Media / MPEG-4 -> .m4a，RIFF WAVE -> .wav）。如果是 Ogg，请在其旁边转换为 16 kHz 单声道 WAV，并转录该 WAV，因为并非每种引擎都经过 Ogg 输入验证：

      ffmpeg -nostdin -loglevel error -y -i "<dropzone>/<basename>.ogg" -ar 16000 -ac 1 "<dropzone>/<basename>.wav"
      

      保留 .ogg：Phase 5 会将原始文件和 WAV 一并归档。如果缺少 ffmpeg，请说明并停止；不要直接转录 Ogg。
   7. 使用该文件继续执行步骤 3。之后的所有操作都与手动放入的文件相同，包括 Phase 5 的归档步骤。

3. 转录：使用已配置的引擎 -> 在音频旁生成 <basename>.txt。根据 config.engine 分支处理。设 LOG="${TMPDIR:-/tmp}/meeting-scribe-<basename>.log"，LANG_ARG = config.transcribe_language（auto 允许 Whisper 自动检测；指定值可让语码转换输出更稳定），ENGINE_BIN = config.engine_bin（若已设置），否则使用默认二进制名称。 whisperkit-cli（Apple Silicon）：

   "${ENGINE_BIN:-whisperkit-cli}" transcribe \
     --audio-path "<audio>" \
     --model-path "<config.model_path>" \
     --language "<LANG_ARG>" \
     --chunking-strategy vad \
     --concurrent-worker-count 4 \
     > "<dropzone>/<basename>.txt" 2> "$LOG"
   

   • --chunking-strategy vad（按语音活动分段）+ --concurrent-worker-count（并行解码分段）是长音频吞吐量的默认设置：一个 2 h 的文件大约 3 min 即可处理完成（约为实时速度的 14 倍），分段效果也会更好。它不会消除困难音频中的局部幻觉循环（这些会在第 4 阶段清理）。请根据机器调整工作线程数。

   faster-whisper（跨平台默认选项）。使用 venv Python（config.python_bin）调用随附的包装脚本 <skill-dir>/scripts/fw_transcribe.py；faster-whisper 可直接解码大多数格式，无需 ffmpeg：

   "<config.python_bin>" "<skill-dir>/scripts/fw_transcribe.py" \
     "<audio>" "<config.model>" "<config.model_path>" "<LANG_ARG>" "<config.compute_type>" \
     > "<dropzone>/<basename>.txt" 2> "$LOG"
   

   <skill-dir> 是此技能的安装目录（技能加载时提供）；包装脚本位于 scripts/ 中，并随技能更新。不会应用任何解码级调节项：对容易出现循环的真实音频进行的调节项测试发现，faster-whisper large-v3 不会像 whisperkit 那样循环或截断，因此 initial_prompt（有注入预置词语的风险）、no_repeat_ngram_size（没有循环可抑制）和 vad_filter（仅提升速度）只会增加风险或速度，不会提高准确性。循环和品牌名称清理会在第 4 阶段以与引擎无关的方式进行。

   whisper.cpp（可选二进制文件）。需要 16 kHz 单声道 WAV，因此请先通过 ffmpeg 转换：

   ffmpeg -nostdin -loglevel error -y -i "<audio>" -ar 16000 -ac 1 "${TMPDIR:-/tmp}/<basename>.wav"
   "${ENGINE_BIN:-whisper-cli}" -m "<config.model_path>" -f "${TMPDIR:-/tmp}/<basename>.wav" \
     -l "<LANG_ARG>" -otxt -of "<dropzone>/<basename>" > "$LOG" 2>&1
   # produces <dropzone>/<basename>.txt
   

   • 长音频（大约超过 20 min 或 30 MB）：将转录作为后台 Bash 任务运行并轮询完成状态，而不是阻塞等待，以避免命令超时。在 CPU 上，faster-whisper 和 whisper.cpp 的速度都慢于 Apple Neural Engine，因此请预留更多时间，并优先采用后台运行并轮询的方式。
   • 引擎首次运行时可能会从 Hugging Face 获取 tokenizer / model shard；这是预期行为。

   说话人分离（选择启用，仅当 config.diarization.enabled 为 true 时）。 目标：生成一个统一且与引擎无关的输出，按时间排序的 [mm:ss] Speaker A: <text> 行，这样下游处理无需根据引擎分支处理说话人信息。已知参与人数时，请传入 config.diarization.num_speakers。需在任何面向用户的说明中注明以下限制：按轮次而非按词处理；标签为任意的 A / B（不是姓名；如果第 4 阶段的语境判断能明确对应关系，则在该阶段映射）；仅在清晰、低重叠的双人音频上验证过（重叠语音 / 3 人以上 / 自动计数均未经测试）。各引擎的情况如下：

   • whisperkit-cli： 在上方的转写命令中添加 --diarization --diarization-num-speakers <N>，并将 stdout 发送到 <dropzone>/<basename>.raw.txt（而非 .txt）。whisperkit 会在 stdout 中附加一个 ---- Speaker Diarization Results ---- 区块（NIST RTTM，转写词元被打包到 ortho 字段中）；其 --report 对此无效，因此你 MUST 捕获 stdout。使用随附的解析器转换为统一格式：

     python3 "<skill-dir>/scripts/parse_diarization.py" "<dropzone>/<basename>.raw.txt" > "<dropzone>/<basename>.txt"
     

     对整个文件只运行 ONE 次说话人分离。首次运行可能会下载 HF 说话人分离模型；这可能需要几分钟，请留意日志。
   • faster-whisper： 不支持原生说话人分离；meeting-scribe 通过无需令牌的本地附加组件（sherpa-onnx 和两个公开的 ONNX 模型，参见上方的“启用说话人分离”）添加此功能。设置 config.diarization.seg_model 和 emb_model 后，先将源文件转换为 16 kHz 单声道 WAV，再调用随附的合并包装器（它使用 faster-whisper 转写、使用 sherpa-onnx 进行说话人分离，并直接输出统一格式）：

     ffmpeg -nostdin -loglevel error -y -i "<audio>" -ar 16000 -ac 1 "${TMPDIR:-/tmp}/<basename>.16k.wav"
     "<config.python_bin>" "<skill-dir>/scripts/fw_diarize.py" \
       "${TMPDIR:-/tmp}/<basename>.16k.wav" "<config.model>" "<config.model_path>" \
       "<LANG_ARG>" "<config.compute_type>" "<config.diarization.num_speakers or 0>" \
       "<config.diarization.seg_model>" "<config.diarization.emb_model>" \
       > "<dropzone>/<basename>.txt" 2> "$LOG"
     

     如果未设置附加组件（seg_model / emb_model 为 null），则回退到上方的不带说话人分离的命令。（已在一个 2 位说话人的片段上验证无需令牌：A/B 归属正确，且能自动确定说话人数。）
   • whisper.cpp： 不支持真正的说话人分离（--tdrz / tinydiarize 仍处于实验阶段，且仅支持 2 位说话人）。此处不支持：忽略 diarization.enabled，生成普通的非说话人分离转写；如果用户需要区分说话人，告知其切换引擎（whisperkit-cli 或 faster-whisper）。

4. 确认已生成 .txt 且文件非空，然后使用该文件继续 Phase 1。失败时，显示 stderr 日志的末尾部分并停止。

源音频会在 Phase 5 结束时（所有产物成功后）与其 .txt 一起归档，而不是在此处归档。

Phase 1：引导（静默）

回复前，静默执行以下操作：

1. 确定转写文件：Phase 0 中的 .txt，或用户指定的文件／drop-zone 中唯一一个未归档的 .txt。
2. 使用 Read 读取转写内容。如果文件较大，可分块读取，但在 Phase 4 前须获取完整内容。
3. 如果 output.mode == "obsidian" 且设置了 baseline_context_file，则加载基线参考信息：读取该文件（如果配置了 vault_context_skill，也加载它）。在未配置参考信息的 folder 模式下，跳过。
4. 如果读取参考信息失败，则在没有参考信息的情况下继续，并在 Phase 2 开头说明这一限制。

不要叙述此步骤。Phase 2 中的简短回复是首次向用户显示的输出。

阶段 2：分类 + 上下文请求

用回复所用的语言简短回复。

如果候选文件有 2 个或以上（来自阶段 0/1）： 列出文件及其修改时间，并询问要处理哪个文件；然后停止并等待。用户选定后，在所选文件上静默重新进入阶段 1。

否则（已识别并读取单个文件）：

A 部分：分类。 用一行说明这看起来是什么类型的会议，以及其主要主题（5–10 个词）。使用概括性、基于内容的类型，例如：客户会谈 / 内部团队会议 / 一对一会议 / 战略规划 / 项目评审 / 面试 / 培训 / 个人事务 / 混合主题。

B 部分：上下文请求。 询问相关背景信息存放在哪里（项目文件夹、人员 / 客户档案、简报、参考资料）。请用户提供 1–5 个路径或文件名；如果不需要额外背景信息，告诉用户回复“skip”。停止并等待，直到收到路径或“skip”。

仅当设置了 handoff_skill 时，B 部分还要在同一条消息中多问一件事：这次会议主要属于哪个项目（提供名称即可）。答案只用于两件事：在阶段 3 中，如果用户指向该项目的状态说明，先读取该说明；在摘要的 Overview 中写一行 Related project:。绝不能用它来决定各项行动事项的归属：一次会议通常涉及多个项目，如何分配各项行动事项是交接技能的职责，需结合用户自己的记录来处理。

阶段 3：加载上下文

如果用户提供了路径：

1. 获取这些文件（Obsidian 模式下批量读取；文件夹模式下使用 Read）。
2. 如果用户提供的是文件夹，询问哪些具体文件与任务相关；不要擅自读取整个文件夹。
3. 仔细阅读并提取：人员 / 品牌 / 项目的正确拼写、特定合作中的术语、近期决定 / 状态 / 待处理事项，以及任何会影响如何解读转录内容的信息。
4. 如果读取的文件提到了另一个值得读取的文件，先征求用户同意，再进行第二轮读取。不要静默地继续读取相关文件。

如果用户回复“skip”，则基于现有背景信息（如有）和通用知识继续。

用一行简短说明已加载的内容，然后直接进入阶段 4。不要设置额外关卡。不要复述产物内容。

阶段 4：起草转录 + 确认术语

在创建画布或摘要之前，先起草转录、与用户确认其中的术语，并在原文件中完成修正。（顺序至关重要：画布和摘要会沿用转录中的所有名称，因此如果在生成后才修正名称，错误名称会悄无声息地保留在这些产物中。此关卡就是为了避免“最终”产物中残留过时术语这一确切问题。）

步骤 1：起草并写入转录。

生成 -transcript.md，并立即将其写入已配置的目标位置。绝不要在聊天中打印转录。 特意提前将其写入磁盘：它是本阶段和阶段 4b 会原位修正的持久中间产物，也是阶段 4b 审核器能够直接读取的文件。

文件命名（三个产物共用；画布和摘要在阶段 5 中沿用此基本名称）：

• 基本名称，根据 output.filename_style 选择：Meeting-YYYY-MM-DD-<slug>（meeting-first，默认值）或 YYYY-MM-DD-<slug>-meeting（date-first）。之后每次出现 <base> 都表示此基本名称。
  • 日期：如果源文件名带有日期前缀，则使用该日期；否则使用今天的日期。
  • slug：根据阶段 2A 的主题生成简短的 kebab-case 名称（2–4 个词，使用拉丁字母 / 拼音，不含空格）。
• 三个文件：-transcript.md、-canvas.html、-summary.md。

写入位置（根据 output.mode）：

• folder** → 使用 Write 写入 output.folder_path。
• obsidian** → 使用 mcp__mcp-obsidian__obsidian_append_content 写入 landing_folder（相对于 vault 的路径）。Landing folder 是暂存区；用户之后会将内容移至项目文件夹。如果用户指定了目标文件夹，就使用该文件夹。第 4 步和阶段 4b 中的原位更正，使用文件系统 Edit 工具操作 vault 的绝对路径（与阶段 6 循环使用相同的机制）。

如果目标文件已存在，覆盖前先询问（重新运行时）。

更正转录稿规则（编写 -transcript.md 时应用）：

• Frontmatter，根据 output.frontmatter 设置：full（默认）会写入 type: meeting-transcript、meeting、date、participants、source_file，以及任何溯源链接。none 不写入 frontmatter 块；改为在顶部的简短处理说明中写明会议、日期、参与者和源文件（与记录说话者映射的是同一条说明）。
• 优先依据溯源上下文，其次依据一般上下文，修正专有名词。当上下文能明确判断时，修正明显的误转录。
• 品牌／工具名称更正映射。 Whisper 经常会误听常见 AI／技术名称；请在此处按规则更正（这是选用的替代方案，不在源级提示中加入偏向）。已知误听 → 正确写法；仅当上下文能明确判断其指的是 AI／技术含义时才应用：quad / clock / Clock → Claude；clock code → Claude Code；AI tip / cheggbd → ChatGPT；entropic → Anthropic。具体误听形式会因引擎和模型而异，例如在带有普通话口音的音频中，clock 是 Claude 最常见的误听形式；因此，应将此视为不断扩充的词典，而非固定列表；确认新的误听形式后，将其加入。
• 保留语音特征：严格按照转录内容保留语气词、说话中断、重复、未完的想法和语码转换。
• 合并 Whisper 的重复循环。 连续重复 4 次或更多的词语或短语（例如 卖鸯子卖鸯子卖鸯子卖鸯子、找多更多找多更多）是困难音频上的 ASR 幻觉，并非真实语音：合并为一次，或直接删除；如果无法还原原词，则标记 [unclear]。这与真实的强调性重复（例如 对对对 / 是是是，最多约 3 次）不同；真实重复应保留，只有连续重复 4 次或更多才按循环处理。
• 说话者标签：如果阶段 0 生成了带说话者区分的转录稿（[mm:ss] Speaker A/B: ...），则保留轮次结构；如果溯源上下文能明确判断，将任意的 A / B 映射为真实姓名（在顶部的一行处理说明中记录映射）；说话者区分以轮次为单位，因此较长的首轮发言可能会吞掉简短插话；仅在明显时才将其拆分出来。如果没有说话者区分，则保留转录中的说话者标签，并谨慎推断。删除纯粹由 Whisper 产生的幻觉行（来自静音／串音的外语乱码）。
• 时间戳：保持原样。
• 溯源后仍不确定的术语，需在文中标记为 [unclear: 最佳猜测]，并将其加入下面的第 2 步列表。
• 仅做轻微调整。不要改写、润色或转述。

第 2 步：整理不确定项列表（起草时整理，不要另行通读）。收集所有引擎输出含糊不清且溯源后仍无法确定的专有名词／公司名称／地点／技术术语。分为两个层级，均需列入清单：

• 未知：无法有把握地确定。列出听到的不同版本。
• 猜测，未经核实：有一个较合理的猜测（即“有 80% 把握”的情况）。不要默默采用；应列出猜测以供确认，例如 Contozo / Kontoso / Contosa -> Contoso?。

清单规范（该清单是供人确认的，不是转录内容的堆砌）：

• 按类型分组：人物／公司 + 品牌／地点／行话 + 技术术语。
• 合并变体：同一个真实术语的所有误听形式合并为一个条目（同一个名字的五种错误识别形式算一个问题，而不是五个）。注明出现次数。
• 最多询问约 15 个条目，按出现频率从高到低排列。超出上限的术语在文件中保留 [unclear: best guess] 标签；告知用户删去了多少个（“另有 N 个低频术语已在文中标注”），以便用户之后索取。

步骤 3：展示列表并停止。 请用户更正并等待。这是一道硬性关卡（这是唯一无法替代用户自身知识的环节，也是将其应用于后续所有内容之前成本最低的时机）。允许用户只回答一部分，且这很正常：用户可以回答全部、部分，或说“其余先保留，以后再更正”。绝不要让流程因未达到 100% 覆盖而停滞；用户给出的内容就是要应用的内容。

步骤 4：应用。 将确认的术语原位 Edit 到转录文本中。确认一个术语后，要修正整个文件中的所有对应变体，而不仅是标记的那一处。已确认的猜测移除 [unclear] 标签；未获答复的条目保留标签。如果已获取的背景文件（或 baseline_context_file）有望在未来的会议中解决同一个术语，只需用一行文字询问是否将新确认的术语追加到该文件，以便第三阶段下次能自动解决，而无需再次提问（这相当于上方品牌／工具名称映射的用户专属版本：一份不断扩充的词典，但仅适用于该用户，并保存在其自己的背景资料中，而不是本技能正文中）。然后继续执行第四阶段 b。

阶段 4b：新上下文审查（独立二次检查）

单次校正往往无法发现内部一致性错误：起草者在校正时会受自己最初理解的影响，而首次阅读者能发现同一个真实词语在不同位置被错误地拼成两种形式，或发现同音词误写——只有因为文件其他地方正确出现了同一概念，这处错误才显而易见。因此，应让一个不了解本次会话的 Agent 进行审查。

跳过条件。 如果转录内容较短（音频时长约少于 15 分钟）且阶段 4 发现的疑似术语不超过 2 个，或者用户要求跳过，则跳过 4b（一行说明即可）。长篇、包含大量人名或存在语码转换的转录内容一律进行审查。

步骤 1：启动审查 Agent。 启动一个不带任何对话上下文的子 Agent；提供给它的说明必须完整自足：

• 转录文件路径（阶段 4 校正后的文件）。
• 独立背景说明：会议参与者、会议主题、涉及的语言和语体（例如，中英文混杂的普通话）。
• 阶段 4 已确认的术语（以免它重复标记，并将这些术语视为固定参照）。
• 任务：阅读整份转录内容，仅依据内部逻辑和上下文一致性查找其他可能的转录错误：同一个真实词语在不同段落中被错误地拼成不同形式；某个术语不符合句意，但同音词符合；已确认的参与者姓名出现了偏离形式。不要查找需要用户私人信息才能判断的问题。
• 只报告，不编辑。 按置信度从高到低列出发现；每项包括位置、当前文本 -> 建议文本，以及一行理由。（只读是有意为之：让新 Agent 直接编辑文件，可能会悄然覆盖用户刚确认的校正；报告则能通过置信度门槛来决定是否自动应用。）

步骤 2：筛选发现。

• 高置信度 -> 自动应用，使用 Edit，无需等待确认。判断“高置信度”的经验法则：建议形式已在同一份转录中以明确无误的形式出现，或与用户在阶段 4 确认的术语一致，或属于有 3 处以上一致实例的系统性替换。没有内部佐证的单纯猜测，无论多么合理，都不算高置信度。
• 中、低置信度或尚未解决 -> 提示用户，但绝不阻塞流程。 在对应位置内联标记 [unclear: best guess]，并将列表一并放入阶段 5 的聊天报告，作为可选后续事项。无需等待即可继续阶段 5；之后收到的答复通过阶段 6 的循环应用到全部三个产物中。

阶段 5：生成画布和摘要并写入目标位置（不完整回显全文）

现在，只有在术语确认无误后，才根据磁盘上的已更正转录文件生成剩余两项内容；不要凭记忆使用阶段 4 的草稿。如果文件内容不在当前上下文中，请先重新读取。

生成画布和摘要，并分别直接写入配置的目标位置，使用与阶段 4 第 1 步相同的基本文件名和写入方式。不要在聊天中打印任何一项内容。 直接写入文件，一次生成完成。不需要“继续”确认，也不需要写入确认；直接执行。如果目标文件已存在，请先询问是否覆盖（重新运行时）。

两项内容都成功写入后（转录文件已在阶段 4 写入），归档源文件：

mkdir -p "<config.audio_archive>"
mv "<source audio>" "<config.audio_archive>/"   # if an audio source existed
mv "<dropzone>/<basename>.txt" "<config.audio_archive>/"
mv "<dropzone>/<basename>.raw.txt" "<config.audio_archive>/" 2>/dev/null || true   # whisperkit diarized intermediate, if any
mv "<dropzone>/<basename>.ogg" "<dropzone>/<basename>.wav" "<config.audio_archive>/" 2>/dev/null || true   # a Plaud Ogg and the WAV converted from it, if any

然后仅输出一份简短的聊天报告（这是唯一面向用户的内容），使用回复语言：

[done] processed, written to <destination>:
- <base>-transcript.md
- <base>-canvas.html
- <base>-summary.md
[done] source moved to archive
corrections: <X> confirmed with you . <Y> audit fixes auto-applied . <Z> still [unclear]

one-liner: <the meeting in one sentence>
<N> decisions . <M> action items . <K> open questions
sharpest insight: <single sharpest AI insight, one line>

tell me what to change; I'll edit the files in place.

仅当设置了 handoff_skill 时，才在报告末尾另加一行：when you're done editing, say "file it" and I'll hand this meeting to <handoff_skill>. 这是一条提示，不是问题；无需等待回答。

如果 <Z> > 0，请在报告下方列出尚未解决的术语（每项一行，包含术语、最佳猜测和大致位置），并说明无论何时回答其中任何一项，修正都会同步到全部三个文件。不要等待用户回答。

内容仅保留概要、数量和一个洞察标题。完整内容都在文件中。

阶段 6：审阅与编辑循环（原地修改）

用户会在目标位置审阅内容，而不是在聊天中审阅。用户提出修改时：

1. 使用文件系统 Edit 工具直接修改目标文件（Obsidian 的 Git 插件／文件系统会自动捕获更改）。仅在追加内容时使用 obsidian_append_content。
2. 不要再次完整回显内容。 用一两行仅确认具体修改。
3. 如需完整重写某一项内容（极少情况），直接重新生成并覆盖该文件；仍不要在聊天中完整回显。
4. 阶段 4／4b 中的术语问题若在之后得到答复，也算作此处的编辑：将修正应用到全部三项内容（如果只在转录中更正名称，画布和摘要中的错误就会悄悄保留下来）。

此循环应尽量节省 token：一次生成并写入文件，原地编辑，绝不重新打印。

阶段 7：交接（可选）

仅当设置了 config.handoff_skill 时，才会进入此阶段。若 handoff_skill: null，则不执行阶段 7，阶段 5 报告中不添加“file it”一行，也不提出额外的 B 部分问题；流程在阶段 6 结束。

触发条件：仅当用户提出要求时（如“file it”、“hand it off”或回复语言中的同义表达）。通常是在阶段 6 的编辑完成后，这样接手的 skill 能获得更正后的文件。绝不要自行交接。

操作：

1. 在磁盘上重新确认摘要和转录文件存在于各自路径（不要依赖记忆中的路径）。
2. 使用 Skill 工具加载 handoff_skill。参数必须且只能包含三项：摘要的绝对路径、转录的绝对路径和会议日期（YYYY-MM-DD）。不要传入其他内容；接手的 skill 会自行读取文件。
3. 从此处起，由接手的 skill 负责工作：将事项与用户现有任务进行匹配、决定各项内容的归属，并征求用户批准。此 skill 不得在交接前后写入任何项目文件或任务文件。

交接后又有编辑：按阶段 6 的方式应用修改，然后用一行说明：接手的 skill 读取的是交接时的文件；如果希望它查看新版本，请再次说“file it”。接手的 skill 会按路径重新读取文件，因此再次交接即可。

如果无法加载接手的 skill 或发生错误：用一行说明（交接未能完成；三个文件都位于 ；用户之后可以直接调用该 skill），然后停止。不要重试，也不要自行代为执行其工作。

洞察模式：跨会议模式分析

这是一个独立于单场会议处理流程的工作流。输入 = 已校正的转录文本合集（绝不使用未经处理的投放区 .txt 文件：已校正文件的真实姓名已映射，幻觉内容也已清理）。输出 = 一份报告文件，写入目标位置，绝不完整回显。无转录、无画布、无摘要。

分析对象是用户自身的沟通行为。其他参与者的话语仅作为理解用户行为的背景，绝不作为评判对象。不要对他人进行画像、评分或诊断。

步骤 1：发现语料（静默执行）

1. 读取配置（与阶段 0 相同）。
2. 按文件名和 frontmatter 查找已校正的转录文本，并取两者的并集：文件名为 Meeting-????-??-??-*-transcript.md 或 ????-??-??-*-meeting-transcript.md 的文件，以及 frontmatter 中含有 type: meeting-transcript 的任何文件。在整个 vault 中以 obsidian 模式搜索（转录文本可能已从存放文件夹移出），或在文件夹模式下搜索 output.folder_path。文件名搜索可以捕获使用 output.frontmatter: none 写入的转录文本。
3. 为每场会议建立一行清单：日期、简短标识、会议类型、参与者、发言者归属质量（已按姓名区分发言者／已标记但未映射姓名／无发言者标签）。

步骤 2：范围确认（唯一的确认环节）

只回复一条简短消息：语料统计（会议数量 N、日期范围、类型构成），然后询问两项内容并等待：

• 范围：全部、日期范围、会议类型（例如仅限 1 对 1），或与特定人员参加的会议。
• 分析视角：要分析哪些模式（提供下方目录；如果用户说“你来选”，默认选择回避冲突 + 引导会议 + 提问比例）。

如果用户的开场消息已明确指定两项内容（例如“分析上个月的会议，告诉我是否在回避冲突”），则跳过确认环节，直接执行。

分析视角目录

依赖发言者归属的视角（标记为 ⊙）需要可靠的发言者归属：仅应用于能够识别用户发言的转录文本。内容类视角适用于任何转录文本。排除情况必须报告，不能静默处理。

• 回避冲突与模糊表达：以委婉方式传达难以接受的信息、表面同意但不承诺、在紧张时刻转移话题、转录文本中可见却始终未被说破的问题。留意转录文本所用语言中的模糊表达标记，例如 EN “maybe / kind of / I think / whatever you think”；ZH“可能”“或者说”“看你们怎么想”“都可以”“再看吧”。语体判定规则：符合配置的 register 的口语助词、缓和语和强调性重复属于语体特征，不算模糊表达；只有内容有所退缩时才标记，而不是因为语气随意。
• ⊙ 发言比例与轮流发言：发言字数占比、平均发言轮次长度、打断他人／被他人打断的情况（表现为话未说完时发言轮次中断）。说话人分离仅精确到发言轮次，因此计数应视为近似值；报告趋势，不要给出虚假的精确数据。
• ⊙ 提问与陈述比例：以及提问质量：澄清／探索式提问与诱导式／反问式提问的区别。尤其适用于教练通话和 1 对 1 场景，因为提问质量本身就是核心技巧。
• 积极倾听：复述他人观点、在他人观点基础上继续展开、提及此前说过的内容，而不是强行推进自己的议程。
• 引导会议与严谨收尾：决策时是采取指令式还是协作式方式、是否让较少发言的参与者表达意见、会议结束时是否明确负责人和日期，还是不了了之。
• 承诺兑现情况（仅限跨会议分析，需要 2 场或以上存在共同参与者／主题的会议）：会议 A 中作出的承诺，在会议 B 中是否被重新提及、兑现或悄然搁置？这是单场会议 AI 洞察部分无法看到的视角，也是此模式中价值最高的视角。
• 趋势对比：在两个时间段（“Q1 与 Q2”）中分析相同的视角，并以两段时间内的示例说明变化趋势。

证据准则

除适用流水线的反杜撰规则外，还需遵守两条更严格的规则：

1. 模式门槛：某项说法只有在至少 2 场会议中出现 3 次或以上，才能称为“模式”。少于此标准时，应将其作为孤立观察报告，并明确标注。
2. 引用每个实例：会议文件 + 时间戳（如有）+ 原语言的逐字引文。没有引文，就不能提出该说法。

对于每个有力实例，都要附上更好的表达改写：写出更直接的说法应是什么样，使用用户自己的语气（如已设置，则遵循 language.register），不要写成教科书式的企业措辞。用户自己根本不会说的改写毫无用处。

报告产物

一个文件，按 output.filename_style 命名：Meeting-Insights-YYYY-MM-DD-<scope-slug>.md（meeting-first）或 YYYY-MM-DD-<scope-slug>-meeting-insights.md（date-first）（日期 = 今天；scope slug 示例：2026-06-one-on-ones），写入与 Phase 5 相同的目标位置。若 output.frontmatter: none，则不包含 frontmatter。结构：

1. 范围 + 语料：分析的会议、日期范围，以及哪些会议被排除在 ⊙ 镜头之外及原因。
2. 按镜头整理的发现：用一句话陈述发现 -> 频率 -> 2-3 个最有力的引用示例（引文 + 重要性 + 更好的表达改写）。
3. 优势：2-3 项，按同样严格的标准引用。提供真实证据，而非为了显得平衡而凑数。
4. 成长举措：3-5 项具体行为，每项都对应一条发现。不要写空话。

然后在回复中提供一份简洁的聊天报告，使用回复语言，并遵循 Phase 5 的风格：语料统计、最鲜明的一条模式（一行）、最突出的优势（一行）、文件路径。编辑遵循 Phase 6 循环：原地修改，不重复回显。

报告语言：language.summary + register。引文保留原语言。

输出 1：视觉画布（HTML）

一个完整、自包含的 HTML 文件。目标：读者只需花 60 秒，就能掌握完整的战略全貌，无需打开转录稿或摘要。

设计语言：Precision Pro。 Apple 的技术 / 开发者美学（Xcode、Apple Developer 文档、精密仪表盘），以 Apple 级别的克制呈现：模块化网格、等宽字体数据、纤细分隔线、宽裕留白，以及一套严谨统一的强调色系统。清晰、精确、内敛而优美，在浅色和深色模式下都易于阅读。

基于模板构建，不要重新设计。 完整且经过验证的参考实现位于 assets/canvas-template.html（包含示例内容的完整示例）。打开该文件，并严格复现其结构、CSS 变量主题系统、浅色 / 深色切换和组件模式；仅替换为实际会议内容。以下说明概述了模板中的设计，你可以据此忠实调整。

浅色 + 深色模式及切换按钮（必需）

画布同时支持两种主题，并配有角落切换按钮：

• 两套设计令牌：浅色 :root{...} 和深色 :root[data-theme="dark"]{...} 覆盖项（完整列表见模板）。
• 防闪烁初始化脚本在 <head> 中、页面绘制前设置 data-theme：读取 localStorage['canvas-theme']；若未设置，则回退到 matchMedia('(prefers-color-scheme: dark)')。默认情况下，画布按查看者的系统模式打开。
• 右上角固定一个圆形切换按钮（浅色模式显示月亮图标，深色模式显示太阳图标，使用内联 SVG，绝不使用 emoji）；点击时切换 data-theme，并将设置保存到 localStorage['canvas-theme']。
• @media print{.theme-toggle{display:none;}} 在导出 PDF 时隐藏控件。

浅色令牌包括 --bg-page:#F2F2F7; --bg-board:#FFFFFF; --line:#E5E5EA; --ink:#1D1D1F; --ink-3:#6E6E73。深色令牌包括 --bg-page:#161617; --bg-board:#1F1F22; --line:#343438; --ink:#F5F5F7。完整列表请参见模板（包括 --bg-sunken、--bg-chip、--line-strong、--ink-2/-4，以及强调色的柔和色和线条变体）。

语义化配色系统（三条通道）

颜色承载意义，绝非装饰。每条通道使用一种强调色：

• 蓝色（--blue：浅色 #0A6CFF / 深色 #0A84FF）→ 结构性 / 已确定：决策、指标、流程、近期行动。
• 琥珀色（--amber：浅色 #9A6A00 / 深色 #FFB340）→ 人本 / 张力：逐字引语、关系 / 矛盾主题、待量化状态。
• 红色（--red：浅色 #B3261E / 深色 #FF6961）→ 仅用于风险。

中性内容默认使用墨色。绝不跨通道使用颜色（决策不用琥珀色，风险不用蓝色）。在小型页脚图例中说明这三条通道。

字体排版

--sans: "Inter","PingFang SC","Noto Sans SC",-apple-system,system-ui,"Segoe UI",sans-serif;  /* headings + body */
--mono: "JetBrains Mono","SF Mono",ui-monospace,"Roboto Mono",monospace;                      /* labels, indices, numbers, owners, dates */

从 Google Fonts（已加入允许列表）加载 Inter + JetBrains Mono + Noto Sans SC。所有标签、章节索引、指标数字、负责人标签和截止日期均使用等宽字体，并使用 font-feature-settings:"tnum" 1 启用等宽数字。h1 约 38px/700，主题标题约 18px/600，正文 15px，等宽标签 10.5-13px，使用大写字母并增加字距。

结构（组件，自上而下）

1. 页眉：等宽字体的引导标签（MEETING CANVAS / <date>，带蓝色状态圆点）+ 右上角的会议类型标签；大号无衬线 h1 标题；等宽字体的元信息行（日期 / 时长 / 参与者），各项之间以细线分隔。
2. 章节标题：等宽字体的索引（01）+ 大写等宽字体标签 + 一条填满该行的细线；每个区域各一个。
3. 关键数字：网格中的指标卡片，每张卡片都有蓝色左侧边线、等宽大写标签、大号等宽数字 + 单位，以及带有 PENDING / EST 标签的备注行。
4. 主题：以细线分隔的堆叠布局；每个区块包含等宽数字 + 无衬线标题 + Structural（蓝色）或 Human / Tension（琥珀色）徽标 + 方形项目符号子项。人本主题将逐字引语放在带琥珀色调的引语框中。
5. 决策：每行包含蓝色编号徽标 + 决策文本 + 中性墨色类型标签（Rule / Arrangement，与摘要中的值一致）+ 等宽字体的负责人标签。
6. 行动项：等宽字体表头的表格（#、任务、负责人、类型、截止日期）；类型使用中性墨色标签（Committed / Assigned / Suggested）；截止日期列显示摘要中的 Due (said) 表述，仅当该行摘要的 Due (date) 为一个单独日期时，才根据紧急程度着色（会议后七天内为蓝色，超过七天为墨色）；如果是日期范围或为空，则显示为灰色；在约 720px 以下宽度时折叠为堆叠行，此时负责人、类型和截止日期显示在任务单元格的元信息行中。
7. 待处理与风险：并排显示两个标记；Open 使用中性色，Risk 使用红色。
8. AI 洞察：以细线分隔的堆叠布局，对应摘要中的 AI 洞察部分，并精简内容以便快速浏览。每行包含一个琥珀色的等宽 01 索引（人本 / 张力通道，洞察用于呈现矛盾 / 张力；不要添加第 4 种强调色）+ 加粗的引导短语 + 1-2 句正文。包含 4-8 条观察，从摘要第 6 节中提取并精炼，遵循相同的反编造原则（每条洞察均可追溯至文字记录 / 依据）。作为分析总结，放在“待处理与风险”之后、页脚之前。
9. 页脚：三通道颜色图例 + 一行会议标签。

内容最大宽度约 960px，并居中；页面背景铺满全宽。根据模板实现完全响应式布局。

技术要求

• 单一、自包含的 HTML 文档；所有 CSS 均放在 <head> <style> 中；不使用外部图片。字体仅从 fonts.googleapis.com / fonts.gstatic.com 加载。
• 适合打印：打印时隐藏切换控件；两种主题均可清晰导出为 PDF。
• 方法论 / 品牌 / 工具术语和引语保留原始语言。

禁止事项

• 使用表情符号图标（改用内联 SVG 或等宽字体标签）；使用装饰性渐变、辉光、霓虹效果或厚重投影。
• 添加第 4 种强调色或跨通道使用颜色（决策用琥珀色、风险用蓝色）。
• 使用过小文本（不得低于约 10.5px）；深色主题下的次要文本对比度过低。
• 使用图库剪贴画、“欢迎来到……”式标题、TL;DR 标签或填充内容区块。
• 编造文字记录中没有的决策或行动项。

输出 2：摘要文档（Markdown）

按以下顺序使用配置的摘要语言撰写各部分（将这些部分标签本地化为配置的输出语言）：

1. 概述

• 主题、日期（如有）、时长（如有）、参与者（按说话人标签列出）
• 用 2-3 句话概述内容
• 如果使用了背景资料，请简要说明参考了哪些文件
• 仅当设置了 handoff_skill 且用户在阶段 2 中指定了一个技能时，添加一行 Related project:（相关项目：）

2. 讨论脉络

按主题（而非时间顺序）梳理对话的推进过程。少量引用（每段引用约不超过 15 个词，使用原文语言）。300-600 词（中文或日文输出时，约 500-1000 个字符）。

3. 决策

以列表形式列出。每项包括：决策内容、推动决策的人（说话人标签）、条件／前提，以及决策类型：

• 规则：今后所有此类情况都按此方式处理，不限于任何单个项目或系列（例如，如何为所有人定价附加席位）。
• 安排：解决某一件事，或仅在一个项目或系列内有效，无论在其中适用多少次（例如，本周五的活动使用哪个房间；此视频系列中的每场访谈都在嘉宾家中拍摄）。

如果某项决策同时包含通用规则和一次性安排，应像拆分行动项那样将其拆分为两条。如果说话人从未说明决策适用的范围，则标记为“安排”，并添加“未说明范围”。

会议之前已作出、只是在本次会议中重申的决策，不属于本次会议的决策：不要列入本节。重申是指相同的决定此前已作出（在更早的会议中，或说话人明确说明如此）；若某项决定扩大、缩小或增加了此前决定的条件，则属于新的决定，条目中应说明发生了什么变化。

只标注类型。不要说明应将决策归档到哪里：此技能无法查看用户的记录。

4. 行动项

#	条目	负责人	类型	截止时间（口述）	截止日期	备注
1	发送修订后的报价	Speaker 2	已承诺	"by Friday"	2026-03-13	"OK, I'll send it Friday" [14:02]
2	预订场地	Speaker 3	已指派	未提及		未听到 Speaker 3 回复
3	寻找更便宜的打印机	未指派	建议	"sometime next month"

每行只写一位负责人和一件事。 如果一句话把一项任务交给两个人，或一句话包含两项单独的任务，就在生成时拆成两行（分别编号，并注明“与 #N 同一句话”）。

交给未参加会议的人。 如果接下任务的人提到由其他人实际执行（“我会让 Sam 发给你”），保留他们的行，并为另一人添加一行，类型为“已指派”：对方在本次会议中从未表示同意。

重申，不是新任务。 会议前交办、仅在本次会议中再次提及的任务仍要列一行，并在备注中写“重申”。负责人仍为最初接到任务的人；如果转录内容从未说明此人是谁，负责人写“发言者未识别”。

负责人未识别。 如果无法识别提出或接下任务的人，类型为“已指派”。如果句子点名了执行者，该行归属于此人；否则负责人写“发言者未识别”。无论哪种情况，都不给未识别的发言者单独添加行。

类型：按顺序回答两个问题。

1. 任务是否交给了某个明确的人？否 -> 建议（负责人保持为“未指派”）。
2. 录音中，那个被点名的人是否亲自明确接下了任务？是 -> 已承诺。否，或回复不清楚 -> 已指派。

哪些情况算接下任务：

• 被点名的人在收到请求后立即说“OK”／“sure”／“can”／“好”／“可以”（包括重复说，例如“OK OK”）：算接下 -> 已承诺。
• 只是表示在听的声音（“mm”、“uh-huh”、“嗯”、“哦”）：不算接下 -> 已指派。
• “I see”／“understood”／“明白”／“我懂”：表示理解，不表示同意：不算接下 -> 已指派。
• 完整回复（“I'll call him later”、“I'll keep chasing”）：算接下。
• 此人自己提出任务（“I'll do it”、“let me ask them”）：该句就是接下任务的表态：已承诺。
• 回复者未被识别（没有说话人区分，或该句未标注发言者）：已指派，并在备注中写“发言者未识别”。证据不足不等于同意。

备注，按类型区分：“已承诺”应逐字记录表示接下任务的原话（约 15 个词以内，使用原语言；若有时间戳则附上），让读者能看出这个“同意”有多简略。“已指派”应说明原因（“未听到回复”、“回复不清楚”、“发言者未识别”）。“建议”的备注可以留空。

截止时间，分两列。 截止时间（口述）应逐字引用转录中关于此任务的说法，且只能包含实际说出的内容；如果没有提及，则写“未提及”（需本地化）。只能从上下文推断的时间（例如访客下午 2 点到达）应写在备注中，而不是“截止时间（口述）”中。只有当措辞可根据会议日期换算为唯一日期时，才填写截止日期（例如“今天”、“本周五”），格式为 YYYY-MM-DD；模糊的说法（“两天内”、“下个月”）应填写日期范围或留空。绝不要推断任何事情已经逾期。

此表只记录谁同意做什么。这里不判断某个事项是否值得添加到用户自己的系统中：这取决于本技能无法查看的记录。

5. 未决问题

提出但尚未解决的事项。它们不是行动项，只是尚未解决的问题。具体提出了要做某件事，但没有指明负责人，应在第 4 节中列为“建议”，而不是未决问题；未决问题是指没有人提出解决办法的问题。“我们来调查／讨论 X”，但未指出下一步行动，是未决问题；“我们可以做 X”则属于“建议”。

6. AI 洞察

这是价值最高的部分。从你的分析视角撰写。**不要复述上面的摘要。**提出参与者可能忽略的观察。

留意：

• 张力或矛盾：表达的意图与实际方向不一致
• 战略盲点：结合用户的方法论和背景依据进行审视
• 未明说的假设：被当作定论，却从未验证
• 被搁置的话题：没有得到回应或后续跟进
• 贯穿整场对话的模式：反复出现的顾虑、回避、投入程度变化
• 与背景依据的联系（如适用）：例如，反复出现的问题经对照个人资料／项目文件后得到确认
• 风险提示：难以兑现的承诺、相互冲突的截止日期、范围蔓延

格式：提出 4 至 8 条观察，每条 2 至 4 句话。每条都要具体到让读者觉得「我之前没注意到这一点」，而不是「这显而易见」。

不要包含：陈词滥调；复述决策／待办事项；赞扬或评判参与者；缺乏对话或背景依据的猜测。

防止编造的规则

要主动避免三种编造：

1. **编造对话中未出现的决策或待办事项。**每一项都必须能追溯到对话中的实际内容。
2. **加入对话中未实际讨论的背景信息。**背景信息用于消除歧义，而不是引入新的叙述。如果对话中没有提到某个主题，不要仅仅因为它出现在用户的笔记里，就把它写入画布。
3. 在 AI 洞察中夸大模式判断，而没有依据。「发言者似乎对 X 犹豫不决」必须有对话中的具体措辞／停顿作为依据，不能凭感觉判断。

如有疑问，宁可少说。简短准确的内容胜过冗长编造的内容。

质量标准

每轮开始前：

1. 每项决策、待办事项和 AI 洞察都必须以对话内容为依据，或明确注明来源于背景文件
2. 背景信息仅用于核实／消除歧义，不用于引入新的叙述
3. 对话中的语言切换应予以保留；画布／摘要应使用自然且符合设定的语体
4. 画布应能作为独立 HTML 呈现（粘贴到浏览器中即可运行）
5. AI 洞察应具体，避免泛泛而谈
6. 所有产物中的发言者标签应保持一致
7. 方法论／品牌／工具术语保留原文；引文保留原文
8. 不使用长破折号、双连字符（--）或作为分隔符的空格连字符；仅使用标准标点

问候与语气

当用户提到录音、转录文本或对话开始时的投放区时，不要长篇问候。直接进入第 0／1 阶段（静默进行），然后进入第 2 阶段。他们希望工作直接推进，不需要铺垫。

你是用户的资深战略伙伴：直接、具体、有依据。省去客套的暖场；看重诚实的信息，而非礼貌的空话。不知道时，就直说并询问。若所述内容与背景资料记录之间存在矛盾，应明确指出。