市面上所有會議記錄工具都只做「聲音→文字」。即使 Google 和 Microsoft 有最好的語音辨識，它們的 Meeting Notes 產品本質上也只是一份文字檔。但真正有用的影片筆記，應該是圖文對齊的時間軸——每段摘要旁邊就是那段的畫面截圖。這篇整理我實際跑通之後的 7 個最佳實踐。

作者： Wisely Chen 日期： 2026 年 6 月 系列： AI 工具實戰 關鍵字： AI, Whisper, Meeting Notes, Video Processing, 圖文筆記, Screenshot Alignment, PM 訪談, PRD

目錄

問題：所有人都在做「聲音→文字」，沒有人在做「影片→筆記」

我們日常生活中有大量 Meeting Notes 是從影片產生的。Google Meet、Teams、Zoom，每天錄下來的影片裡面包含的資訊其實是「逐字稿 + 畫面」的組合——不是純文字。

但你去看市面上所有的會議記錄產品，從 Otter.ai 到 Fireflies 到 Google 自己的 Gemini Notes，本質上都在做同一件事：把聲音轉成文字。

這裡有一件很弔詭的事。

Google 自己就同時擁有 YouTube（全世界最大的影片平台）和 Google Meet（企業最常用的視訊會議工具之一）。它有影片，有聲音，有圖片，有字幕系統，有 Gemini 的多模態能力——它擁有做圖文整合會議記錄的所有拼圖，但它就是不做。

Microsoft 也一樣。Teams 錄影直接存進 OneDrive，它有 Azure 的語音辨識、有 Copilot、有 PowerPoint 的投影片結構——所有材料都到位了，但 Teams 的會議記錄產出依然是一份純文字。

這不是技術限制，是產品思維的盲點。這些公司的 Meeting Notes 產品，從第一天就是圍繞「語音辨識」這個能力來設計的。聲音進去，文字出來，結束。畫面裡的東西？不在 scope 內。

只有聲音的會議記錄，到底丟掉了什麼

這個盲點在某些場景下特別致命。

想像一個技術 Demo 的場景：講者在螢幕上展示一個系統介面，一邊操作一邊說明。他說的話可能是「你看這邊有一個按鈕，點下去之後就會跑出這個結果」。

如果你只有逐字稿，這段話完全沒有意義。哪個按鈕？哪個結果？ 沒有畫面，聽眾根本不知道他在講什麼。

再想像一個更常見的場景：講者投影一張表格或數據圖表，然後開始解釋趨勢和數字。他可能會說「你看 Q2 那邊有一個明顯的下降」——但如果你只有文字，你看不到那張圖表，也不知道「明顯的下降」到底是多少。

影片裡的資訊，至少有一半在畫面上，不在聲音裡。

簡報投影片、螢幕分享的程式碼、技術架構圖、Demo 操作流程、表格數據、UI 原型——這些視覺資訊在純文字逐字稿裡全部消失。你拿到的「會議記錄」就是一大片文字，然後你要靠自己的記憶去回想「他當時講這段的時候畫面上是什麼」。

為什麼是現在：多模態模型成熟了

這件事之前做起來非常複雜。

2024 年如果你想做圖文整合的會議記錄，你需要自己寫 OCR pipeline 去辨識投影片上的文字、用 object detection 去抓 UI 元素、再想辦法把辨識結果和逐字稿對齊。光是「讓機器看懂一張截圖裡面在講什麼」這一步，就足夠消耗一個工程師好幾週。

但 2025-2026 年，多模態模型已經完全成熟了。

現在的 LLM——不管是 Claude、GPT-4o 還是 Gemini——你丟一張系統介面的截圖給它，它可以直接告訴你「這是一個資料庫管理介面，左邊是 table list，右邊是 query editor，目前正在執行一個 SELECT 語句」。你丟一張投影片給它，它可以讀出標題、重點、圖表的趨勢。你丟一張表格截圖給它，它可以把數字全部提取出來。

模型可以「看懂」圖片了。這是做圖文整合最好的時機。

以前你需要 OCR + object detection + layout analysis 三套系統串聯才能做的事，現在一個多模態 API call 就解決了。技術門檻從「需要 CV 工程師」降到了「任何會寫 API 呼叫的人都做得到」。

所以現在的 pipeline 很直覺：Whisper 負責轉錄，LLM 負責摘要（同時可以理解截圖內容），ffmpeg 負責抽圖，Claude Code 負責串流程。整個跑一次大概 5-10 分鐘，產出一份帶截圖的圖文時間軸筆記。

我最近拿一支 YouTube 技術教學影片（Holo 3.1 Agent 模型介紹）來實際跑這套流程，踩了不少坑。做完之後最大的發現是：這件事最容易做錯的地方不是「有沒有轉出文字」，而是「最後產物到底像不像一份人會想讀的筆記」。

下面是兩個實際產出的圖文時間軸。第一個是用 Holo 3.1 Agent 教學影片跑出來的，第二個是 Google 試算表教學：

Holo 3.1 Agent 教學影片的圖文時間軸產出

Google 試算表教學影片的圖文時間軸產出

對 PM 的額外價值：訪談 PRD 的圖文整合

這套流程對 PM 做客戶訪談或需求訪談特別有用。

傳統做法是：開會錄影 → 回去聽逐字稿 → 手動整理成 PRD 或會議紀要。這個過程通常要花會議時長的 2-3 倍。

用這套流程的話：

  • 客戶 Demo 的畫面操作會被自動截圖，對應到他當時講的需求描述
  • 技術架構討論的白板畫面會跟討論內容自動對齊
  • 需求衝突（客戶說 A 但畫面顯示 B）可以直接從圖文對照看出來
  • PRD 的 UI 參考可以直接從段落截圖裡擷取，不需要回去翻影片

這就是我在開頭說的：真正的圖文整合，不是把聲音變成文字就結束了。

影片裡有一半的資訊在畫面上。丟掉畫面只留文字，等於丟掉一半的會議內容。

附錄：可直接使用的提示詞模板

以下提示詞可以直接貼給 Claude Code 或 Codex 使用。把 {...} 換成你的影片路徑、輸出資料夾或需求即可。

提示詞 1：完整產生圖文 Meeting Note

適用場景：拿到一支新影片，從零開始產出完整圖文筆記。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

請幫我把這支影片做成圖文 meeting note：

影片路徑：
{影片絕對路徑}

需求：
1. 用 OpenAI Whisper API 拆逐字稿。
2. 產生字幕檔：SRT、VTT、TXT。
3. 把逐字稿切成有意義的時間段，不要把逐字稿直接貼成筆記。
4. 每一段都要產生：
   - 段落小標
   - 1-2 句摘要
   - 2-4 個重點 bullet
   - 可展開的原逐字稿
5. 每一段都要從該段時間範圍內抽 3 張截圖，避免截圖對不上內容。
6. 另外保留全片 scene-change gallery。
7. 輸出一個可直接打開的 meeting_note.html。
8. 最後幫我驗證 HTML 圖片都有載入、沒有 broken image。

輸出資料夾：
{輸出資料夾絕對路徑}

語言：
{zh/en/ja...}

注意：
- API key 不要寫進任何檔案。
- 如果需要 API key，請只用環境變數或互動 stdin 傳入。
- 完成後列出主要產物路徑。

提示詞 2：已有逐字稿，只重做段落摘要

適用場景：Whisper 已經跑過了，但摘要品質不滿意——太像逐字稿、標題不夠精煉、bullet 太碎。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

這個 meeting note 的時間軸目前太像逐字稿，不像筆記。

請根據現有逐字稿重新整理段落摘要：
{輸出資料夾}/transcript.verbose.json

重新產生：
{輸出資料夾}/timeline_summaries.json
{輸出資料夾}/meeting_note.html

要求：
1. 每段主內容要是有意義的 summary，不要照抄逐字稿。
2. 每段要有：
   - 小標題
   - 1-2 句摘要
   - 2-4 個 bullet
3. 原逐字稿只能放在可展開 details 裡。
4. 不要重跑 Whisper，除非必要。
5. 完成後幫我抽查前幾段內容，確認不是逐字稿。

提示詞 3：截圖不對，只重抽段落截圖

適用場景：筆記文字沒問題，但截圖跟內容對不上——可能是用了全片 scene-change 圖庫猜最近圖，導致圖跑到別段。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

我覺得 meeting note 每段旁邊的截圖和內容不太對。

請不要用全片 scene-change 圖庫去猜最近圖片。
請改成每個段落都從自己的時間範圍內直接抽圖：

輸入：
影片路徑：{影片絕對路徑}
輸出資料夾：{輸出資料夾絕對路徑}

請更新：
1. segment_frames/
2. segment_frames.json
3. meeting_note.html

規則：
1. 每段抽 3 張圖：前段、中段、後段。
2. 每張圖的時間點必須落在該段 start/end 之間。
3. 圖片 caption 顯示時間戳。
4. 保留下方全片 gallery，但時間軸主圖要使用 segment_frames。
5. 完成後驗證每段都有 3 張圖、圖片都能載入。

提示詞 4：只要字幕檔和逐字稿

適用場景：不需要圖文筆記，只需要乾淨的字幕檔做後續使用（剪輯、搜尋、存檔）。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

請使用 OpenAI Whisper API 幫我處理這支影片：

影片路徑：
{影片絕對路徑}

只需要輸出：
1. transcript.srt
2. transcript.vtt
3. transcript.txt
4. transcript.verbose.json

不需要產生 HTML，不需要截圖。

注意：
- API key 不要寫進檔案。
- 完成後告訴我每個檔案的位置。

坦白說

這套流程不是完美的。幾個已知限制：

截圖品質依賴影片品質。 如果原始錄影是 720p 或更低，抽出來的截圖可能不夠清晰，特別是程式碼或小字的畫面。

45 秒的分段不是萬能的。 有些主題可能橫跨 2-3 分鐘才完整，45 秒一段會把它拆得太碎。目前我還沒有一個完美的自動分段策略，有時候還是需要人工微調 JSON。

LLM 產生的摘要有時候太像逐字稿。 特別是當原始發言本身就很結構化的時候，LLM 會傾向「重述」而不是「提煉」。這需要在 prompt 裡明確要求「用自己的話重新組織」，不要「照原文縮寫」。

整個流程目前還是工程師友善的。 需要跑 ffmpeg、Python 腳本、API 呼叫。對非技術背景的 PM 來說，上手門檻不低。理想狀態是封裝成一個指令或一個 Skill，一行指令就跑完全部。

但即使有這些限制，跟「只有純文字逐字稿」的傳統做法比，產出品質已經是不同量級。

關鍵洞察

  1. 影片裡至少一半的資訊在畫面上，不在聲音裡。 講者說「你看這邊」的時候，如果你沒有「這邊」的截圖，那段話就是廢話。只做聲音→文字的會議記錄，等於丟掉一半的會議內容。

  2. Google 同時擁有 YouTube 和 Google Meet，卻不做圖文整合。 這不是技術限制，是產品思維盲點。它們從第一天就圍繞「語音辨識」設計產品，畫面不在 scope 內。這代表這個方向有巨大的市場空白。

  3. 2026 年是做圖文整合最好的時機。 多模態模型已經成熟到可以直接「看懂」截圖內容。以前需要 OCR + object detection + layout analysis 三套系統的事，現在一個 API call 就解決了。技術門檻從「需要 CV 工程師」降到「會寫 API 呼叫就行」。

  4. 逐字稿 ≠ 筆記。 Whisper 的輸出是原始資料，不是可閱讀的知識整理。中間需要一層「分段 + 摘要 + 結構化」的處理。

  5. 截圖對齊是整個流程裡最容易做錯的環節。 從全片 scene-change 圖庫找「最近的圖」看起來合理，但教學影片的過場畫面會讓匹配完全失準。正確做法是每段從自己的時間範圍內直接抽圖。

  6. 中間層 JSON 是整個流程的核心。 它讓你可以局部修正而不需要全部重跑。快取策略直接決定了迭代效率。

  7. 視覺驗證不能省。 「檔案生成成功」和「筆記可讀」是兩回事。圖文對齊的驗證只能用眼睛看，沒有捷徑。

  8. 這套做法對 PM 訪談最有價值。 客戶 Demo 的畫面操作、架構白板、UI 原型——這些資訊在純文字逐字稿裡完全消失，但在圖文筆記裡會被自動保留。

延伸閱讀