週會是職場上寫得最頻繁、也最沒人看的一種會議記錄。每週固定發一次，久了就變成「有發就好」的例行公事——洋洋灑灑三頁，沒有人讀完，下週開會時大家還是問「上次講到哪？」
問題通常不在寫得不夠多，而在寫錯東西。這篇給你三種可直接複製的週會範本、五個讓週會記錄失效的地雷，以及散會 5 分鐘內就發出去的做法。
（想看完整的 8 種會議記錄格式，請看會議記錄格式怎麼寫。）
週會記錄跟其他會議記錄哪裡不一樣？
一般會議記錄的讀者是「沒參加的人」，目的是讓他看懂發生什麼事。週會記錄的讀者是「下週的你們自己」，目的是讓下次會議不用重新對齊。
這個差別決定了三件事：
- 要能跨週比對——這週的「卡關」如果上週就卡著，那才是真正的訊號。所以格式每週要一致，不然無法比對。
- 不需要記過程——誰講了什麼不重要，重要的是狀態變化。
- 要短到有人看——週會記錄超過一個手機螢幕，就等於沒發。
範本 1：一般團隊週會（最通用）
適合 3-15 人的固定週會。核心是三個顏色：完成、進行中、卡關。
週會記要 — 2026/07/20（第 29 週）
出席：珮慈、阿明、Kevin｜請假：小美
🟢 本週完成
- 客戶訪談 10 場（珮慈）
- iOS 圖示改版 v3 上架（Kevin）
- 金流 webhook 修復（阿明）
🟡 進行中
- 八維度分析優化（阿明）→ 預計 7/24
- v2.0 線框圖（Kevin）→ 預計本週五
🔴 卡關｜需要協助
- App Store 審核卡第 6 天（Kevin）→ 珮慈協助聯繫 Apple
- 推薦碼 bug 無法重現（阿明）→ 需要更多用戶回報
📌 本週行動項目
- 珮慈 → 7/22 前：完成 Apple 申訴信
- 阿明 → 7/24 前：分析優化上線
- 全體 → 7/25 10:00：v2.0 kickoff
⏭️ 下週重點
- v2.0 正式啟動
- 決定 Android 上架時程
下次會議：2026/07/27（一）10:00
為什麼這樣排：卡關放在中間偏後但不放最後，因為那是唯一需要當場決定的東西；行動項目放最後，因為那是散會後大家要回頭查的部分。
範本 2：Scrum 站會 / 敏捷團隊
適合每日站會或雙週衝刺會。重點是衝刺目標達成率與阻礙，不是個人進度報告。
Sprint 12 站會記要 — 2026/07/20（Day 4 / 10）
🎯 衝刺目標：完成訂閱制升級流程
進度：8 / 13 點（62%）｜燃盡：略微落後
📋 看板變化
- 完成：SUB-21 方案比較頁、SUB-24 折扣碼驗證
- 進行中：SUB-22 付款失敗處理（阿明）、SUB-25 升級動線（Kevin）
- 未開始：SUB-26 降級流程、SUB-28 發票寄送
🚧 阻礙（Blockers）
- SUB-22 卡在金流商 sandbox 環境不穩 → 阿明今日改打正式環境測試
- 缺少法務對退款條款的確認 → 珮慈今天下班前追
📊 風險判斷
以目前速度，SUB-28 大機率延到下個衝刺。已與 PO 確認可接受。
下次站會：2026/07/21（二）09:30
關鍵差異：站會記錄要寫風險判斷。「照這個速度做不完」比「今天做了什麼」有用一百倍，因為前者能讓人提早反應。
範本 3：遠距 / 非同步團隊
適合跨時區、成員無法同時上線的團隊。這種週會記錄本身就是會議——大家把內容寫進去，不真的開會。
非同步週會 — 2026/07/20（本週請於週一 12:00 前填寫）
──────────────────────────────
【珮慈】台北 UTC+8
✅ 完成：客戶訪談 10 場、Apple 申訴信初稿
🔜 本週：整理訪談洞察、v2.0 需求確認
🆘 需要：Kevin 幫忙確認線框圖 7/23 前能否交
😊 狀態：正常
──────────────────────────────
【阿明】台中 UTC+8
✅ 完成：金流 webhook 修復
🔜 本週：分析優化上線
🆘 需要：無
😰 狀態：本週有家庭事務，週三整天不在
──────────────────────────────
【Kevin】溫哥華 UTC-7
✅ 完成：iOS 圖示 v3 上架
🔜 本週：v2.0 線框圖
🆘 需要：珮慈確認 v2.0 範圍是否含 Android
😊 狀態：正常
──────────────────────────────
📌 需要同步討論的（唯一要開會的部分，週三 09:00 台北時間，30 分鐘）
- v2.0 是否納入 Android
- Sprint 13 範圍
為什麼加「狀態」欄：遠距團隊最大的風險是看不到人。一行心情或負荷狀態，往往比進度報告更早預警問題。
5 個讓週會記錄失效的地雷
地雷 1：寫成流水帳
「9:00 珮慈報告上週進度，9:15 阿明補充，9:20 討論⋯⋯」——沒有人要看會議的過程。只記結論與狀態。
地雷 2：只有「完成」沒有「卡關」
一份全綠的週會記錄通常不是團隊很順，而是沒人敢講問題。卡關欄位長期空白，本身就是一個警訊。
地雷 3：行動項目沒有名字或日期
「要再確認一下」「盡快處理」——這種寫法等同於沒寫。行動項目必須是「誰 → 何時前 → 做什麼」三件齊全。
地雷 4：格式每週都在變
這週用條列、下週用表格、再下週用段落——你就永遠無法比對「這個問題卡了幾週」。固定格式比精美格式重要。
地雷 5：拖到週五才發
週一開的會，週五才發記錄，中間四天大家各憑記憶做事。週會記錄的價值隨時間急速衰減，散會當天沒發出去就幾乎沒用了。
散會 5 分鐘內就發出去的做法
上面第 5 個地雷是最常見、也最好解的一個。傳統做法是會議中有人負責打字，但那個人就沒辦法好好參與討論。
比較有效的流程是讓 AI 邊聽邊整理：
- 週會開始時打開 Huelo 會錄 按錄音（不需要機器人加入會議，也不用主辦人權限）
- 會議進行中，AI 儀表板即時更新決策、行動項目、待解問題
- 散會時八維度分析已經產出，其中「行動項目」與「結論」兩個維度直接對應上面範本的欄位
- 花 2 分鐘把 AI 產出的內容貼進固定範本、補上下次會議時間，發出去
實際花的時間是散會後 2-5 分鐘，而且因為錄音留著，日後有人問「這件事當時怎麼決定的」隨時查得到。
常見疑問
Q1. 週會記錄要多長？
一個手機螢幕以內，大約 200-400 字。超過的部分放連結（例如完整的訪談洞察另開文件）。如果你的週會記錄需要捲動三次才看得完，多數成員會直接跳過。
Q2. 週會記錄該誰寫？
不要固定丟給最資淺的人——他往往最不清楚脈絡。比較好的做法是由主持人負責，或用 AI 產出草稿後主持人校訂。有些團隊採輪流制，好處是每個人都會更投入聽會議內容。
Q3. 沒開會的那週要補記錄嗎？
要，但一行就夠：「本週因連假停開，進度照舊，無新增阻礙。」目的是保持時間序列不斷裂——日後回頭看才知道那週是停開而不是漏發。
Q4. 週會記錄要不要記出席狀況？
建議記，而且要含請假者。不是為了考勤，而是為了閱讀時知道誰不在場——沒出席的人對當週決議可能不知情，發送時要特別 tag 他。
Q5. 卡關的事情一直沒解決，要一直寫嗎？
要，而且要標上已卡幾週。例如「🔴 App Store 審核（第 3 週）」。同一個項目連續出現三週還沒動，就該升級處理層級或乾脆放棄——而如果每週重新寫成新的一條，沒有人會發現它卡了三週。
Q6. 週會記錄需要保存嗎？
至少保留一年。週會記錄的價值在長期比對：季度回顧時翻出 13 週的記錄，很容易看出哪些問題反覆出現、團隊速度的變化趨勢。這是單次會議記錄給不了的東西。
結論
週會記錄寫得好不好，差別不在文筆，在格式固定 + 當天發出 + 誠實寫卡關這三件事。三種範本挑一個直接複製去用，用滿一季再回頭調整。
如果你每週都在為這件事花 30 分鐘，免費註冊 Huelo（每月 2 小時、不需信用卡）——下次週會打開錄音，散會時行動項目與結論已經整理好，你只要貼進範本按發送。
延伸閱讀：會議記錄格式怎麼寫？8 種主流格式 + 範本。