用 AI CLI 把會議錄音變成待辦事項

每個人都假裝不存在的問題

會議在十二分鐘前結束了。你記得三件事：有人提到一個截止日、有一場關於 API 設計的爭論、你確定自己自願接了什麼工作 -- 但你想不起來是什麼。

這不是個人能力問題。這是結構性問題。

一場一小時的會議大約產生 8,000 到 10,000 字的口語。一般人的短期記憶只能保留四到七個獨立項目。數學很殘酷：超過 99% 說過的話在幾分鐘內就消失了。倖存的是最後說的東西（近因效應）和引發情緒反應的東西（那場 API 爭論）。第 23 分鐘那個安靜的決策 -- 真正重要的那個 -- 蒸發了。

組織試了幾十年要解決這個問題。有人做筆記。筆記不完整，因為做筆記的人同時也是參與者。有人錄音。錄音躺在共享資料夾裡沒人碰，因為沒人有 58 分鐘重看一場已經參加過的會議。有人寄追蹤 email 總結待辦事項。email 是錯的，因為它是靠記憶寫的，而記憶我們剛才證明了不可靠。

真正的問題不是擷取資訊。是從混亂中萃取結構。會議逐字稿是一條文字的河流，重要的東西是沉在河底的石頭 -- 決策、待辦事項、負責人、截止日 -- 埋在閒聊、離題、和某人解釋他的螢幕分享不能用之下。

你需要的是一台掃描那條河的金屬探測器。掃描整份逐字稿，精確拉出重要的結構化資料。然後把它放到該去的地方：你的專案追蹤器裡，帶著正確的負責人和正確的截止日，不需要你動一根手指。

這就是我們要建的東西。

你會做出什麼

一條 pipeline，輸入會議錄音，輸出被追蹤的待辦事項。流程：

1. 錄音 -- 任何格式：.mp4、.webm、.m4a、.wav
2. 在本機用 Whisper 轉錄 -- 資料不會離開你的電腦
3. 用 Claude Code 抽取決策、待辦事項、負責人、截止日
4. 透過 MCP 推送 structured output 到 Linear 或 GitHub Issues

一個指令跑完第 2 到第 4 步。你從一個音檔開始，結束時得到專案追蹤器裡的工單。

這篇文章結束後，你會有：

• 本機 Whisper 安裝，保護隱私的轉錄方案
• 一段 CLAUDE.md 抽取 workflow，把原始逐字稿變成結構化 JSON
• MCP server 連線到 Linear 和/或 GitHub，自動建立工單
• 一個 shell script 把整條 pipeline 串成一個指令

整個設定大約 30 分鐘。之後，每小時錄音從會議到工單不到 2 分鐘。

事前準備

• Claude Code v2.1+ 搭配 API 存取
• Python 3.10+（跑 Whisper 用）
• ffmpeg 已安裝（macOS 上 brew install ffmpeg）
• Node.js 18+（跑 MCP server 用）
• Linear 帳號有 API key，或 GitHub CLI（gh）已驗證

如果你從來沒建過 MCP server，20 分鐘建一個 MCP Server 那篇教學涵蓋了基礎。

第一步：安裝 Whisper 做本機轉錄

Whisper 是 OpenAI 的開源語音轉文字模型。完全在你的機器上跑。沒有 API 呼叫、沒有雲端上傳、沒有隱私疑慮。這很重要 -- 會議錄音經常包含不應該離開你基礎設施的敏感商業資訊。

安裝：

pip install openai-whisper

驗證安裝：

whisper --help

Whisper 有好幾個模型尺寸。取捨是速度對準確度：

做會議轉錄，medium 是最佳平衡點。它能抓到人名、技術術語和交叉對話，準確度足以讓下游 AI 抽取可靠運作。如果你有 10+ GB VRAM 的 GPU，large-v3 更好。如果在筆電 CPU 上跑，small 是實際天花板。

測試一個樣本錄音：

whisper meeting-recording.m4a --model medium --language en --output_format txt

這會在當前目錄產生 meeting-recording.txt。打開它。你會看到一份原始逐字稿 -- 沒有說話者標籤，文本裡沒有時間戳。逐字稿很亂，滿是語助詞和重新開始的句子。沒關係。AI agent 的工作就是從這堆混亂中找到結構。

替代方案：faster-whisper。 如果 Whisper 速度是瓶頸，faster-whisper 是基於 CTranslate2 的重新實作，速度快 2-4 倍，準確度相同。用 pip install faster-whisper 安裝，模型名稱通用。

第二步：設定 MCP Server 做工單建立

抽取 pipeline 需要一個地方推送找到的待辦事項。設定 MCP server 對接你的專案追蹤器。

方案 A：Linear

{
  "mcpServers": {
    "linear": {
      "command": "npx",
      "args": ["-y", "@linear/mcp-server"],
      "env": {
        "LINEAR_API_KEY": "lin_api_your_key_here"
      }
    }
  }
}

方案 B：GitHub Issues

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_your_token_here"
      }
    }
  }
}

把你用的那個加到專案的 .mcp.json。重啟 Claude Code 並執行 /mcp 確認 server 顯示綠色狀態。

重要： 把 token 存在環境變數裡，不要直接寫在 .mcp.json。上面的範例為了清楚才寫成內嵌值。

第三步：寫 CLAUDE.md 抽取 Workflow

這是 pipeline 的核心。CLAUDE.md 告訴 Claude Code 怎麼解析會議逐字稿、該抽取什麼結構化資料。

加到你專案的 CLAUDE.md：

## Meeting Transcript Extraction Workflow

When I provide a meeting transcript, follow this sequence:

### Phase 1: Identify Structure
1. Scan the full transcript. Identify distinct topics or agenda items discussed.
2. For each topic, note the approximate position in the transcript (beginning, middle, end).
3. Identify all participants mentioned by name or role.

### Phase 2: Extract Decisions
For each decision made during the meeting, extract:
- **Decision:** What was decided, in one sentence.
- **Context:** Why it was decided (the key argument or data point).
- **Decider:** Who made or ratified the decision.
- **Dissenters:** Anyone who disagreed (and their objection, briefly).

### Phase 3: Extract Action Items
For each action item, extract:
- **Task:** What needs to be done, in one sentence. Be specific.
- **Owner:** Who is responsible. If unclear, mark as "UNASSIGNED".
- **Deadline:** When it is due. If no deadline was stated, mark as "NO DEADLINE".
- **Priority:** Infer from context -- P0 if blocking others, P1 if mentioned as urgent,
  P2 for everything else.
- **Dependencies:** Other action items or external factors this depends on.

### Phase 4: Extract Open Questions
Items discussed but not resolved:
- **Question:** What remains unanswered.
- **Assigned to:** Who was asked to follow up (if anyone).
- **Context:** Why it matters.

### Output Format
Return a JSON object with this structure:
{
  "meeting_date": "YYYY-MM-DD",
  "participants": ["name1", "name2"],
  "topics": ["topic1", "topic2"],
  "decisions": [...],
  "action_items": [...],
  "open_questions": [...]
}

### Rules
- Extract only what was explicitly stated. Do not infer action items from vague
  discussion. "We should probably look into caching" is an open question, not an
  action item -- unless someone said "I will look into caching by Friday."
- Attribute by name when possible. If genuinely unclear, mark as "UNATTRIBUTED."
- Deadlines must be explicit. "Soon" or "next week" should be captured verbatim.
- Preserve disagreements. If the decision was contentious, the dissent is as
  important as the decision.

這個 workflow 遵循所有 agent workflow 通用的 CLAUDE.md 撰寫原則：明確的輸入、structured output、模糊情境的明確規則。

第四步：串起來

這是跑完整 pipeline 的 shell script：

#!/bin/bash
# meeting-to-tickets.sh
# Usage: ./meeting-to-tickets.sh recording.m4a

set -euo pipefail

RECORDING="$1"
BASENAME="${RECORDING%.*}"
TRANSCRIPT="${BASENAME}.txt"
EXTRACTION="${BASENAME}-extraction.json"

echo "Step 1: Transcribing with Whisper..."
whisper "$RECORDING" --model medium --language en --output_format txt --output_dir .

echo "Step 2: Extracting structured data with Claude Code..."
claude -p "Read the file ${TRANSCRIPT} and run the meeting transcript extraction workflow. Output the JSON to ${EXTRACTION}." --allowedTools "Read,Write,mcp__linear__*,mcp__github__*"

echo "Step 3: Creating tickets..."
claude -p "Read ${EXTRACTION}. For each action item, create a Linear issue (or GitHub Issue) with the task as the title, the owner in the description, the deadline in the due date field, and the priority mapped to the tracker's priority levels. Skip items marked UNASSIGNED -- list those separately at the end for manual review." --allowedTools "Read,mcp__linear__*,mcp__github__*"

echo "Done. Extraction saved to ${EXTRACTION}"

讓它可執行：

chmod +x meeting-to-tickets.sh

執行：

./meeting-to-tickets.sh weekly-planning-2026-03-22.m4a

Script 分三個乾淨的階段跑。Whisper 轉錄。Claude Code 抽取。Claude Code 建工單。每個階段產出一個可檢視的成品：逐字稿檔案、抽取 JSON、追蹤器裡的工單。

為什麼分三個階段而不是一個？ 可除錯性。如果轉錄品質差，你調整 Whisper 模型選擇。如果抽取漏了項目，你調整 CLAUDE.md workflow。如果工單格式不對，你微調建票的 prompt。每個階段可以獨立修正。

第五步：檢查輸出

第一次跑完後，打開抽取的 JSON。它看起來像這樣：

{
  "meeting_date": "2026-03-22",
  "participants": ["Alice", "Bob", "Carol", "Dave"],
  "topics": [
    "Q2 roadmap priorities",
    "API versioning strategy",
    "Hiring timeline for senior backend role"
  ],
  "decisions": [
    {
      "decision": "Adopt URL-based API versioning (v2/endpoint) instead of header-based",
      "context": "Header-based versioning caused issues with CDN caching in production",
      "decider": "Alice",
      "dissenters": ["Bob -- preferred header-based for cleaner URLs"]
    }
  ],
  "action_items": [
    {
      "task": "Write the API versioning migration guide for external developers",
      "owner": "Bob",
      "deadline": "end of next sprint",
      "priority": "P1",
      "dependencies": ["API v2 endpoints must be deployed to staging first"]
    },
    {
      "task": "Schedule interviews for senior backend candidates next week",
      "owner": "Carol",
      "deadline": "next Friday",
      "priority": "P1",
      "dependencies": []
    },
    {
      "task": "Benchmark new caching layer under production-like load",
      "owner": "Dave",
      "deadline": "NO DEADLINE",
      "priority": "P2",
      "dependencies": ["Staging environment provisioned"]
    }
  ],
  "open_questions": [
    {
      "question": "Should the v1 API have a hard deprecation date or stay in maintenance indefinitely?",
      "assigned_to": "Alice",
      "context": "Affects how aggressively we push partners to migrate"
    }
  ]
}

檢查三件事：

1. 待辦事項是真的嗎？ 跟你自己對會議的記憶比對。Agent 不應該從模糊的討論捏造任務。
2. 負責人對嗎？ 從逐字稿做姓名歸因不完美。Whisper 不標記說話者，所以 agent 從 context 推斷（「我來處理」+ 前後對話）。
3. 決策準確嗎？ 異議欄位特別重要 -- 它捕捉了簡單摘要會遺失的細微差異。

提升準確度：說話者分離

基本 Whisper 轉錄最大的弱點是缺乏說話者標籤。當逐字稿寫「我來處理 migration guide」，agent 必須從 context 猜「我」是誰。有時候猜錯。

說話者分離（diarization）-- 標記誰在什麼時候說話 -- 解決這個問題。用 whisperX 加上它：

pip install whisperx

替換 script 裡的 Whisper 步驟：

whisperx "$RECORDING" --model medium --language en --diarize --output_format txt --output_dir .

輸出現在包含說話者標籤：

[SPEAKER_00] Let's move on to the API versioning decision.
[SPEAKER_01] I think we should go with URL-based. The header approach broke caching.
[SPEAKER_02] I disagree. Header-based keeps the URLs clean.
[SPEAKER_00] Alright, we'll go with URL-based. Bob, can you write the migration guide?
[SPEAKER_02] Sure, I'll have it done by end of sprint.

標籤是 SPEAKER_00、SPEAKER_01 等。你可以在 CLAUDE.md 加一段對應表：

### Speaker Mapping
When processing diarized transcripts, use this mapping:
- SPEAKER_00 = Alice (Engineering Manager)
- SPEAKER_01 = Dave (Backend Engineer)
- SPEAKER_02 = Bob (API Lead)
- SPEAKER_03 = Carol (Recruiting)

每個固定會議群組更新一次這個對應表。臨時會議的話，agent 通常能從逐字稿本身找出名字（「謝謝 Bob」或「Carol 你能處理招聘嗎？」）。

微調 Workflow

跑幾次之後，你會注意到值得調整的模式。

待辦事項太多。 Agent 可能把每個模糊建議都抽取成 task。收緊 CLAUDE.md 規則：Only extract action items where a specific person committed to a specific deliverable. Vague suggestions go in open_questions.

缺少截止日。 如果你的團隊不會明確說出截止日，加一條規則：If no deadline is stated but the task is P0 or P1, mark the deadline as "NEEDS DEADLINE -- follow up with owner."

歸因錯誤。 沒有說話者分離的話，歸因錯誤無法避免。加一個信心欄位：For each action item owner, include a confidence score (high/medium/low). High = name was explicitly stated. Medium = inferred from context. Low = guessing.

非英語會議。 Whisper 支援 99 種語言。把 --language en 改成你的會議語言。Claude Code 原生支援多語言抽取。CLAUDE.md 可以維持英文，即使逐字稿是日文 -- agent 會自動適應。

自動化重複性會議

每週站會、sprint planning、回顧會議等重複性會議，可以把整個流程自動化。

加一個 shell alias：

alias meeting='./meeting-to-tickets.sh'

或建立每種會議的 alias：

alias sprint-planning='./meeting-to-tickets.sh ~/recordings/sprint-planning-latest.m4a'
alias retro='./meeting-to-tickets.sh ~/recordings/retro-latest.m4a'

如果你的錄音工具會存檔到已知目錄，cron job 或檔案系統 watcher 可以在新錄音出現時自動觸發 pipeline：

# 監聽新錄音並處理
fswatch -0 ~/recordings/*.m4a | while IFS= read -r -d '' file; do
  ./meeting-to-tickets.sh "$file"
done

現在整個 workflow 完全免手動：會議結束、錄音存檔、pipeline 觸發、工單出現在追蹤器裡。你邊喝咖啡邊檢查就好。

多面板的優勢

在 debug 這條 pipeline 時，你同時要處理三個階段。Whisper 轉錄可能在多人搶話的段落產生亂碼。抽取可能漏掉待辦事項。工單建立可能把優先級對應錯。

高效率的做法：Whisper 輸出串流在一個面板、Claude Code 抽取作業在另一個、你的 Linear 或 GitHub 看板在第三個。Whisper 完成時，你可以在抽取開始前先目測逐字稿品質。抽取完成時，你在工單建立前先檢查 JSON。每個階段都可見，不需要切換視窗。

對於重複性會議，佈局會穩定下來：主面板顯示最新抽取輸出、側面板顯示正在即時建立的工單、第三個面板放著逐字稿供抽查，當某個待辦事項看起來不對時可以回頭對照。

為什麼 CLI 在這個工作流贏過 Chat

你可以把會議逐字稿貼進聊天介面然後要求列待辦事項。很多人這樣做。一次性使用沒問題。但 CLI 做法在三個層面上根本不同。

第一，可 script 化。Shell script 把 Whisper、Claude Code、MCP 工單建立串成一個指令。聊天介面在每個階段都需要手動複製貼上。

第二，隱私。Whisper 在本機跑。逐字稿在抽取步驟之前不會離開你的電腦，而且你完全控制哪些 MCP server 接收資料。聊天介面會把完整逐字稿上傳到雲端服務。

第三，可重複性。CLAUDE.md workflow 在每場會議都產生一致的抽取結果。聊天 prompt 取決於你每次措辭有多仔細。Shell script 有版本控制。聊天 prompt 是即用即丟的。

更深入的 AI CLI 工具比較和能力說明，可以參考 2026 AI CLI 工具指南。

總結

會議產生會蒸發的決策。資訊存在 -- 它在一個房間裡被大聲說出來了 -- 但它消失在人類記憶和專案追蹤器之間的縫隙裡。

修復方法是一條三階段 pipeline。Whisper 在本機轉錄，保護隱私。Claude Code 用定義好的 CLAUDE.md workflow 抽取結構化資料 -- 決策、待辦事項、負責人、截止日。MCP server 把結果推送到 Linear 或 GitHub Issues，變成有真正負責人的真正工單。

全部設定：安裝 Whisper、設定一個 MCP server、一段 CLAUDE.md workflow、一個 shell script。之後，「我們在會議上決定的」和「有一張工單在追蹤」之間的差距縮短到不到兩分鐘。那場因為沒人追蹤待辦事項而在兩週後重新開的會議 -- 不會再發生了。