週一上午的產品會議剛結束，會議摘要 Agent 在三十秒後把結果放進群組。

Q4 Payment Migration

- 討論遷移時程與 API 相容性
- 需要通知客戶
- 需要準備 rollback

Next steps
- 繼續技術驗證
- 確認遷移時程
- 準備客戶溝通

產品主管先看完。

「太長了。」

PM 把畫面拉回最上面。

「它根本沒寫誰要做什麼。」

負責 Gateway 的工程師停在「API 相容性」那一行，沒有說話。過了一會兒，他問：

「舊版裝置還在用 legacy auth header，這件事沒有留下來嗎？」

三個人看的是同一份摘要，也都在需求訪談時選過「自動產生會議摘要」。

平台團隊本來以為，這是最容易做成共用能力的需求之一。

直到他們發現，三個人說的摘要根本不是同一個東西。

同一份會議，三個人各自接著要做不同的事

主管不需要重看討論過程。他要判斷現在有沒有需要自己介入的事：遷移範圍是否已定、風險能不能接受、哪一項需要升級決策。

PM 則要在下午把工作拆進看板。她需要的是 Action、Owner、期限與卡點。有人說「週三前我確認」，她不能只留下「持續確認時程」。她得知道那個「我」是誰，沒有完成又會卡到什麼。

工程師要找的不是待辦事項。他把逐字稿拉回某一段：

Client 3.2 以下仍使用 legacy auth header；Gateway 先切換，舊版裝置會直接收到 401。

那段話當下沒有形成 Action。主管也不會想在摘要裡看到它。但兩週後開始改 Gateway 時，工程師得知道當初為什麼選擇兩套驗證並行。

同一份會議紀錄，主管要的是決策簡報，PM 要的是追蹤清單，工程師要的是不能壓掉的技術條件。

他們仍然都會說：「我要會議摘要。」

但那只是產物名稱，不是工作定義。

「摘要」只說明內容變短，沒有說明它要幫誰完成什麼

企業收集 AI Use Case 時，常拿到一串看起來很清楚的需求：會議摘要、文件摘要、Email 摘要、客訴摘要、Log 摘要。

這些名稱比「幫我提升效率」具體得多，卻還少了最關鍵的一段：看完之後，使用者準備做什麼？

如果沒有這個答案，系統只能產生一份平均版本：主題、討論重點、簡單結論，再補幾個模糊的 Next Step。每個人都看得懂，也沒有一個人能直接拿去做事。

這不是模型壓縮能力不足。系統只是把同一個輸出名稱，誤當成同一種任務。

平台團隊第一個反應是加三種模式：Executive、Project Manager、Technical。Prompt 也跟著分三套。

幾輪測試後，問題又回來了。

有些主管要看預算風險，不只要看決策；有些 PM 只更新狀態，不負責追人；工程師在架構審查要留下取捨，參加週會時又只想知道自己接到哪些事。

職稱不是工作。Persona 也不能替代工作。

真正需要先問的是：

這份輸出交到你手上後，你下一步要拿它完成什麼？

先共用會議事實，再決定各自要看的版本

後來他們沒有再找「大家都喜歡的摘要格式」。

Agent 先整理一份共同的會議紀錄：決策、行動、負責人、期限、風險、未解問題、技術限制，以及各項內容在逐字稿中的位置。

這一層不急著判斷誰該看什麼，只確認會議裡實際發生了什麼。

接著才回頭問輸出用途：

同一場會議可以產生三份不同的結果，卻不用維護三套不同的會議知識。共用的是會議事實；差異留在最後一段，讓輸出對準各自的下一步。

兩週後的 Migration Review 結束，畫面右側不再只出現一篇 Meeting Summary。

主管打開 Decision Brief，不到一分鐘就關掉；PM 把 Action Tracker 同步進看板；工程師把其中一條技術限制連到 Gateway 的 Ticket。

會議還是只有一份逐字稿，也只有一組真正發生過的事。

平台只是停止要求準備做不同事情的人，先看同一份摘要。