會議轉看板卡片：難的是路由，不是搬運
把一次會議的討論整理進團隊看板，難的不是抓逐字稿或搬運，而是「內容對到哪張卡」的路由；記下改成半自動（AI 整理逐字稿、對卡、產生預覽，人確認）的理由，以及六個現實限制：逐字稿權限門檻、一個連接器只綁一個帳號、寫入身分、別覆蓋既有筆記、術語聽錯、清單順序不保證。
定義：把一場會議或通話的討論整理進團隊看板，最難的一步是搞清楚「這段內容該對到哪一張卡」。抓逐字稿和搬運都有現成做法，路由才是卡住的地方。現階段最划算的做法是半自動：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 授權，沒有重造一套。
用那通真實會議實跑了一次：三張既有卡補上了待辦清單與決策脈絡，一張新卡（工序順序）從無到有建起來，內容和當時的決策討論都寫了進去。
面對「把一場會議的討論變成看板上一張張卡」，先別急著全自動。真正難的是「內容對到哪張卡」這個路由問題，而不是搬運管道；把人留在確認那一步，是這類流程現階段最划算的設計。
