> ## Content Index
> Fetch the complete content index at: http://localhost:2368/llms.txt
> Use this file to discover other available public pages before exploring further.

# 會議轉看板卡片：難的是路由，不是搬運
- URL: http://localhost:2368/meeting-to-cards-routing/
- Published: 2026-07-20T06:55:14.000Z
- Updated: 2026-08-23T13:54:26.000Z
- Description: 把一次會議的討論整理進團隊看板，難的不是抓逐字稿或搬運，而是「內容對到哪張卡」的路由；記下改成半自動（AI 整理逐字稿、對卡、產生預覽，人確認）的理由，以及六個現實限制：逐字稿權限門檻、一個連接器只綁一個帳號、寫入身分、別覆蓋既有筆記、術語聽錯、清單順序不保證。
- Author: yuchang23
- Tags: #wiki, #wiki-experience

> **定義**：把一場會議或通話的討論整理進團隊看板，最難的一步是搞清楚「這段內容該對到哪一張卡」。抓逐字稿和搬運都有現成做法，路由才是卡住的地方。現階段最划算的做法是半自動：AI 處理逐字稿、對卡、產生預覽，人看一眼確認再寫入。

一次十九分鐘的通話，談了某內部系統的幾個待改項目（報工數量算法、時間欄位、檢查表標題、工序順序）。這類會議的決策很容易流失，事後要手動把它抄進團隊的問題看板（一個線上專案管理工具的「問題紀錄」貯體）相當費工。最初的念頭是全自動：用 webhook 通知「有新的會議記錄」，整理後寫進對應的卡片。

## 第一個轉彎：AI 質疑了「全自動」這個前提

AI 沒有照「webhook 自動化」直接做，而是先質疑前提：整條流程裡最容易出問題的一環，是「怎麼知道這段話該寫到哪一張卡」。webhook 和抓逐字稿都有現成路徑，卡住的不是它們。一場會議常常同時談到好幾張卡的內容，全自動路由要嘛猜錯卡，要嘛把好幾張卡的內容全寫進同一張。

於是 AI 提議把目標從「全自動」改成「半自動、AI 當處理器」：AI 負責處理逐字稿、對應到問題卡片、產生預覽，人看過確認之後才真的寫入。理由是卡片路由目前沒有可靠規則可循，人確認一眼的成本很低，但寫錯卡之後的清理成本很高。這個轉向是 AI 提出的，人的角色是點出真正該擔心的其實是寫錯卡，讓討論方向對準路由，而不是搬運管道。

## 六個現實限制（這是最有用的部分）

把這條流程真的做出來時，遇到六個限制。它們大多是權限、身分、資料品質這類邊界問題，程式本身反而不難：

- **全自動抓逐字稿的門檻很高。**要讓程式自動拿到會議逐字稿，得用 Microsoft Graph 訂閱會議事件，需要更高的權限（讀取所有會議逐字稿）加上 IT 管理員同意，有時還要付費的 Teams Premium 方案；而且會議錄製檔六十天後就過期。改成半自動、由人「手動匯出逐字稿」，正好繞過這一關。
- **一個連接器只能綁一個帳號。**claude.ai 上把微軟 365 接進來的 連接器，一次只能連一個帳號（官方文件明確寫，無論什麼方案都一樣）。當逐字稿檔案在同事的個人雲端硬碟、連接器卻連著自己的帳號時，只有三條路：切換連接器的帳號（約三十秒，走一次 授權登入）、請對方把檔案分享過來、或自己本來就是與會者而有存取權。沒辦法同時掛兩個帳號。
- **寫入的身分掛在「授權那顆通行證的登入者」名下。**看板上顯示是誰改的，不是操作的人，而是這份流程當初授權憑證是用誰的帳號登入的。這件事要先知道，否則看板上會出現「不是你以為的那個人」在改卡。
- **不要覆蓋既有筆記。**卡片的描述欄可能是別人寫的。補充脈絡要用「附加（append）」而不是覆寫，並在每次補充前加一行日期標記；這行標記同時當防重複的依據：同一份會議重跑時，看到標記已存在就自動略過，不會重複寫入。
- **逐字稿會把專業術語聽錯。**中文加上特定領域詞，語音轉文字常出錯（例：「報工」被聽成「報公」、「製令」變「制令」、「圖號規格」變「圖畫規格」）。寫進卡片前，一定要先把逐字稿讀過、整理成看得懂的內容，不能把原始逐字稿照原樣貼上去。
- **清單項目的顯示順序不保證。**看板卡裡的待辦清單，若沒有特別設定排序提示，就照工具的預設排，不一定跟你輸入的順序一致。內容都在，只是順序不強求；這種小取捨要講清楚，不用當作不存在。

## 最後做成什麼

把這條半自動流程做成一份 skill：手動匯出的逐字稿 → 用系統內建工具轉成純文字 → 讀現有卡片 → 把逐字稿整理成看得懂的內容並對到卡片、產生一份規格 → 先試跑（dry-run）給人確認 → 寫入 → 回讀確認。它直接重用了另一份既有 skill 的 Microsoft Graph 授權，沒有重造一套。

用那通真實會議實跑了一次：三張既有卡補上了待辦清單與決策脈絡，一張新卡（工序順序）從無到有建起來，內容和當時的決策討論都寫了進去。

面對「把一場會議的討論變成看板上一張張卡」，先別急著全自動。真正難的是「內容對到哪張卡」這個路由問題，而不是搬運管道；把人留在確認那一步，是這類流程現階段最划算的設計。

## 相關條目

- [把規格決策做成團隊問卷：選載體的三個條件](https://yuchang23.com/spec-decisions-to-team-form/?ref=localhost)
- [同仁回饋用問題卡收斂](https://yuchang23.com/feedback-issue-cards/?ref=localhost)
- [用 Teams Planner 當開發工作紀錄](https://yuchang23.com/planner-as-dev-log/?ref=localhost)
- [第一性原理：動手前先質疑前提](https://yuchang23.com/first-principles-questioning-premises/?ref=localhost)
- [踩過的地雷要變成可重用的知識](https://yuchang23.com/pitfalls-to-reusable-skills/?ref=localhost)