用 AI 主持敏捷回顧會議：把團隊教訓變成可執行改善

這篇教學會帶你用 AI 主持一場敏捷回顧會議，把團隊七嘴八舌的意見，轉成三到五個真正會被執行的改善行動，而不是開完會、共筆存檔、下個 Sprint 繼續重複同樣的錯誤。

為什麼回顧會議常常開成抱怨大會

多數團隊的回顧會議（Retrospective）都卡在同一個問題：資訊蒐集靠便利貼或線上白板，大家憑印象丟意見，主持人（通常是 Scrum Master 或 PM）要在會議現場即時分類、歸納、找出根因，還要引導大家不要淪為互相指責。結果常常是討論最大聲的人主導了話題，安靜的工程師意見沒被聽到，最後產出一堆「以後要多溝通」「品質要更好」這種沒辦法執行的空話。

AI 在這個場景能扮演的角色不是取代主持人，而是分擔三件最耗腦力的工作：把零散的原始回饋整理成結構化的分類、把「症狀」往下挖到「根因」、以及把根因轉寫成有負責人、有截止日、可驗收的行動項。主持人把腦力省下來，專心處理現場的人際互動與引導討論，AI 負責文字整理與邏輯拆解。

開始之前：準備 AI 需要的原始素材

AI 不會讀心，回顧會議的品質取決於你餵給它的原始素材夠不夠具體。開會前或開會中，請團隊用以下三個問題各自寫下具體事件，而不是模糊的形容詞：

• 這個 Sprint（或這段時間）哪件事做得好，值得繼續？請寫出具體情境，不要只寫「溝通不錯」。
• 哪件事卡住了、拖慢了進度、或造成了返工？請寫出發生的時間點與影響。
• 有什麼一直讓你困惑、但沒有人特別提出來討論的事？

如果團隊平常用 Jira、Trello、Slack 或 Notion 記錄工作，開會前把 Sprint 期間的重要訊息（延遲的任務、緊急插單、線上事故、客戶抱怨）貼給 AI 當背景資料，會讓後面的根因分析準確非常多。這一步也可以參考站內的 /prompt 頁面，先把你團隊常用的工具輸出格式（例如 Jira 的 CSV、Slack 匯出的訊息紀錄）整理成 AI 好讀的純文字。

第一步：用 AI 收集並分類團隊回饋

把每個人寫的便利貼內容（做得好 / 待改善 / 困惑）整段貼給 AI，請它先做去重與分類，而不是急著要它分析根因。分兩階段做，AI 的輸出品質會明顯更穩定：第一階段只做整理歸類，第二階段才做深度分析。

以下是第一階段可以直接複製使用的 Prompt：

你是一位資深的敏捷教練，正在協助我整理團隊的 Sprint 回顧會議原始回饋。

以下是團隊 {團隊名稱} 在 {Sprint 期間，例如：2026/08/18-08/29} 收集到的原始便利貼內容，共 {人數} 人參與：

【做得好的事】
{貼上原始文字}

【待改善的事】
{貼上原始文字}

【困惑或疑問】
{貼上原始文字}

請幫我：
1. 把語意重複的專案合併，並註明原本有幾則類似意見（代表這件事多少人有感）
2. 用中性、不帶指責語氣的方式改寫每一則，去除針對特定人名的措辭
3. 依主題分組（例如：流程、工具、溝通、需求不明確、技術債、跨部門協作）
4. 標出哪些專案屬於「團隊自己可以改」，哪些屬於「需要向上反映或跨部門協調」

請用表格輸出，欄位為：主題分類、合併後描述、提及次數、可控性（團隊內/需外部協調）。

這一步結束後，你會拿到一張乾淨的表格，取代原本散亂的便利貼牆，而且已經把情緒性語言中性化，減少現場討論時的防禦心態。

第二步：用 AI 做根因分析，避免流於表面

回顧會議最常見的失敗，是把「症狀」誤當「問題」來解決。例如團隊寫「這個 Sprint 常常加班」，如果直接開行動項「大家不要加班」，下個 Sprint 一樣會發生，因為沒有人處理加班背後的原因，可能是需求範圍在 Sprint 中途被追加、估點方式不準、或是關鍵人力請假沒有備援。

AI 很適合協助做根因追問（類似豐田的「五個為什麼」），因為它不會累、不會不好意思一直追問，也不會被會議室裡的人際壓力影響。

針對以下這個「待改善」專案，請用「連續追問為什麼」的方式，最多問到第五層，
幫我往下挖可能的根本原因，而不要停在表面現象：

問題描述：{貼上第一步整理出的其中一則待改善事項}

背景補充（如果有的話）：{團隊規模、使用的工具、本次 Sprint 特殊狀況}

請用條列方式呈現每一層「為什麼」，並在最後標註：
1. 你認為最可能的 1-2 個根本原因是什麼
2. 這個根因如果不處理，下個 Sprint 有多大機率重複發生（高/中/低）
3. 這是一次性事件還是結構性問題

實際主持時，建議把 AI 產出的根因分析投影出來，讓團隊當場確認或修正——AI 的推論只是假設，最終要不要採信，決定權永遠在團隊手上。這也是為什麼回顧會議不能整場交給 AI，人在現場的判斷仍然不可取代，詳細的人機分工邏輯可以參考 /workflows 裡其他協作類任務的設計方式。

第三步：把根因轉成可執行的行動項

找到根因之後，最後一步是產出行動項。一個好的行動項要符合「有負責人、有截止時間、有驗收標準」三個條件，而不是「大家要更注意品質」這種寫了等於沒寫的句子。

根據以下根因分析結果，請幫我把每一個根本原因轉寫成具體的行動項，
每個行動項需要包含：具體行動內容、建議負責人角色（不用寫真實姓名，寫職能即可，
例如「後端負責人」）、建議完成時間（本 Sprint 內 / 下個 Sprint 前 / 需要 1 個月以上）、
以及「怎麼樣算做到」的驗收標準。

根因分析結果：
{貼上第二步產出的內容}

團隊這次 Sprint 的容量（可以投入改善事項的心力）：{例如：有限，建議最多同時處理 2-3 項}

請依「影響大且容易做」優先，最多列出 5 項，超過 5 項的先放進「觀察清單」，
不要一次塞太多行動項給團隊，那會導致下次回顧會議發現全部都沒做完。

以下是一個實際輸出範例的行動項優先順序表，供你參考格式：

案例：台灣一家十人 SaaS 新創的敏捷回顧

一間位於台北、團隊約十人的 B2B SaaS 新創，過去用線上白板工具開回顧會議，每次都要花將近一小時，而且行動項常常只是口頭承諾，下次開會發現八成沒有人真的去做，因為沒有寫清楚誰負責、什麼時候要完成。

他們調整後的做法是：Sprint 結束前一天，工程師先各自用文字工具寫下便利貼內容，PM 在開會前用上述第一步的 Prompt 先跑過一次分類整理，把表格印出來或投影。正式開會時，團隊只花約十五到二十分鐘討論表格內容、確認 AI 分類有沒有誤解語意，接著現場對其中兩三個「提及次數最高」的專案，用第二步的根因追問法討論，最後用第三步產出行動項，並直接寫進下個 Sprint 的待辦清單裡，而不是另外存一份會議紀錄就沒有下文。

團隊自己回報的感受是，會議時間明顯縮短了，而且因為便利貼內容先被中性化改寫過，會議中比較少出現針對個人的防禦性發言。比較具體可驗證的變化，是他們開始追蹤「上次回顧會議的行動項，這次真的完成了幾項」，幾個 Sprint 下來完成率有明顯提升，不過這是單一團隊的自述經驗，不是嚴謹統計出來的數字，套用到別的團隊時，效果會依團隊文化與匯入方式而不同。

AI 的能力邊界與常見錯誤

用 AI 主持回顧會議，有幾件事誠實地說 AI 做不到，也是實務上最容易踩的坑：

第一，AI 沒辦法判斷會議室裡誰在說謊或誰在迴避真正的問題。如果團隊成員本來就不願意講真話（例如怕被主管檢討），AI 分類再漂亮，收進來的原始素材本身就是失真的，整理出來的行動項自然也對不到真正的病灶。這種信任問題要靠團隊文化與主持人現場引導，AI 解決不了。

第二，AI 的根因分析是基於你給的文字推論出來的假設，不是查證過的事實。它可能會「聽起來很合理」地編出一個根因，但其實跟真實情況有落差，尤其當你給的背景資訊不夠時，AI 傾向用一般敏捷開發常見的原因去套（例如「需求不明確」「溝通不足」），這時候一定要讓團隊現場確認，不能整段直接採信貼上行動項清單。

第三，行動項數量的節制要靠人來把關。AI 常常會很熱心地列出七八項行動項，看起來都很合理，但團隊每個 Sprint 能真正投入改善的心力有限，塞太多行動項的下場就是全部做不完，下次回顧會議又變成檢討「為什麼上次的都沒做」，反而打擊士氣。主持人要主動限縮數量，寧可少做兩三項但真的做完，也不要列一長串然後不了了之。

第四，AI 不會自動追蹤行動項的執行進度，除非你另外設計提醒機制（例如把行動項寫進 Jira 或設定站會提醒），否則整理得再漂亮的表格，開完會沒人回頭看，一樣是白費工夫。這一步如果想串接到日常工作流程，可以參考站內 /automation 介紹的自動化提醒做法，或是搭配任務型 AI 助理持續追蹤，相關概念可參考 /ai-agent。

把 AI 回顧會議變成團隊習慣的技巧

要讓這套流程長期跑下去，建議固定用同一份 Prompt 範本，不要每次都重新設計問法，這樣團隊看到的輸出格式一致，也比較容易累積歷史紀錄做比較（例如「困惑」這一類的專案，是不是每次都出現類似的主題，代表有結構性問題一直沒被真正處理）。另外，把每次的行動項表格存檔，下次開會第一件事就是先檢視上次的完成率，這個習慣比任何 AI 工具本身都更能決定回顧會議有沒有效果。如果你的團隊還沒有固定的回顧會議流程，也可以先參考 /recipes 裡其他任務食譜，或到 /guides 瞭解更完整的敏捷會議匯入步驟，再把這套 AI 輔助流程接進去。

常見問題 FAQ

延伸閱讀

• 更多工食譜
• AI 協作流程完整指南
• 敏捷會議相關工作流程
• 任務型 AI 助理入門