一場會議結束後，AI 生成的摘要寫著：「團隊同意依原計畫推進。」這句話短、清楚，貼進工作紀錄也方便。可是在討論中，可能有人只是說「目前沒有更多資料」，有人要求補測試，也有人因時間到了而沒機會發言。當工具把不同程度的保留濃縮成「同意」，它省下的不只是打字時間，還可能是組織原本應該面對的分歧。
我們先定義問題。會議摘要不是逐字稿，也不必保留每一次停頓；它的工作是讓沒到場的人知道討論了什麼、決定了什麼、哪些事情仍未定。若摘要把「有人提出疑慮」變成「風險已討論」，或把「暫時先做」變成「所有人支持」，失真的地方不在某個字，而在決策責任被重新分配了。
流暢的文字，容易被當成確定的紀錄
自動摘要通常會整理重點、合併相似語句。這很有用，尤其當會議冗長、主題分散時。但模型偏好的整齊敘事，也可能把現場的不確定修平。對讀者來說，條列清楚的紀錄比含糊的對話更像「定案」；一旦被轉寄到別的團隊，原本能補充背景的人又離內容更遠。
我做模型風險工作，會特別注意動詞。是「建議」還是「決定」？是「同意測試」還是「同意上線」？是「沒有反對」還是「明確支持」？差一個動詞，後續採購、排程、審查與責任歸屬都可能不同。摘要不能只追求讀起來順，還要能對得上原始討論。
沉默不是一種方便的同意
會議裡的權力並不平均。有人掌握排程，有人負責承擔上線後的風險；有人可以隨時插話，有人得等主管點名。若工具只根據發言量寫出「多數人認同」，安靜的人可能被算進同意方。若主持者沒有明確問是否決議，事後的摘要也不該替會議補上一個不存在的表決。
這裡有一個假設情境，並非我的工作經歷：一項功能正在討論是否擴大試用。甲說技術測試已完成，乙說仍需檢查特定使用者受到的影響，丙表示要先確認申訴流程。會議時間到了，沒有人正式決定。若 AI 摘要寫成「團隊同意擴大試用，後續補充申訴流程」，它便把兩項前提降成附帶事項，也替尚未做出的決定找好了執行理由。
誰應該對摘要負責？
我不認為責任可以交給「AI 誤解了」這句話。工具提供草稿，採用它的人仍要確認。若摘要將成為決策依據，主持人或指定紀錄者應核對結論與待辦，讓有關的人有機會指出錯誤。這不是要求每個人逐字重聽整場會議，而是把影響最大的句子優先查清楚。
產品設計也有責任。若介面把生成摘要直接標成「正式紀錄」，又讓使用者一鍵寄給所有人，錯誤被放大的速度會超過修正速度。更好的設計應保留草稿狀態、標示哪些結論需要確認，並讓讀者能回到相關發言片段。是否能回溯、誰能修訂、修訂紀錄能否被看見，都是功能的一部分。
我會把紀錄分成三層
第一層是已確認的決議：寫明做了什麼決定、由誰決定、何時生效。若沒有決議，就明白寫「未決」。不要為了讓文件完整，替空白處填上一個體面的答案。
第二層是仍有分歧的意見：各方關心的風險與所需證據，盡量以原意表達。沒必要把每個人都描寫成對立陣營，但也不能把實質異議改成「已充分討論」。當一個人指出可能的歧視性影響，他是在提出待處理的問題，不是在替產品增添一個小備註。
第三層是下一步與停止條件：誰補資料、何時回報、什麼情況下暫停。這能讓「暫時先試」不變成無期限的默許。若試行後沒有得到需要的證據，就應再次討論，而不是讓上一次含糊的摘要自動替下一次決策背書。
留下異議，是讓合作可以繼續
我知道有人覺得把不同意見寫進會議紀錄，會讓團隊看起來不團結。我有不同看法。清楚記下異議，能讓提出問題的人不必在每場會議重複爭辯，也讓支持推進的人知道還缺什麼條件。真正消耗信任的，往往是有人以為自己提出了問題，事後卻看見紀錄寫著「全員同意」。
我的工作習慣是先定義問題、核對證據。用在會議摘要上，最基本的檢查就是：哪句是事實，哪句是推論，哪句是尚待確認的行動？AI 可以幫我整理雜訊，卻不該替會議創造一致。如果大家真的同意，寫出來很好；如果還沒有，寫出「我們尚未同意」也同樣是有價值的成果。
一份好的摘要不必顯得完美。它要讓下一個讀者明白目前的證據、決策與邊界，並有機會在錯誤被執行前提出更正。工具能把話縮短；是否尊重每個人的原意，仍要由使用工具的人負責。