真正有效的會議準備模板
給工程主管的會議準備模板，從你的工具而非記憶中提取情境脈絡。
By Ellis Keane · 2026-04-03
我見過的每個會議準備模板都只是偽裝的議程模板。它們給你寫「討論主題」和「行動項目」的地方，然後稱之為準備，卻跳過了真正困難的部分：知道上次和某人交談以來發生了什麼。
會議準備的真正工作是你花十五分鐘滾動 Slack 試圖回憶你的直屬部屬週二說了什麼，或花十分鐘點擊 Linear 議題搞清楚那次遷移是否已經上線，或打開一對一會議卻發現沒有具體東西可討論，因為這一週模糊成一團（週往往就是這樣）。
這個會議準備模板從不同的前提出發：準備是關於收集情境脈絡，而非撰寫議程。營運脈絡存在於你的工具中，不在你的腦中；人際脈絡仍然需要判斷和筆記，但那比大多數人想的是更小的範圍。方法分三層：活動掃描、決策與阻擋檢查，以及變化差異。三層全部跑完不到七分鐘。
這個模板適合誰
主要受眾：進行一對一、團隊同步和跨功能檢查會議的工程主管 – 不過任何進會議時希望自己事先查過東西的人都可以調整使用。如果你管理 5–8 個直屬部屬，跨 Linear、GitHub、Slack，也許還有 Notion 或 Figma，你就是我心中的對象。不同的工具組合？結構仍然適用，替換具體查詢即可。
快速的一對一可能只需要第一層。五人以上出席且桌上有不可逆決策的高風險規劃會議大概三層都需要。
第一層：活動掃描（3 分鐘）
任何會議之前，拉出與會者的近期活動。不是他們做的所有事，只要足夠讓你走進去時知道他們這週實際上是什麼樣子。
- [ ] 在 GitHub 查看每位與會者的近期 PR（已合併、開啟中、已審查）
- [ ] 掃描他們的 Linear 議題：什麼移到了 Done、什麼 In Progress 超過 3 天、什麼被重新指派
- [ ] 瀏覽他們活躍的 Slack 頻道，尋找 5 則以上回覆的討論串（那些通常是有深度的討論）。Slack 的搜尋修飾符 如
from:@person before:today 能大幅加速
- [ ] 如果適用，查看設計相關會議的 Figma 活動或規劃會議的 Notion 更新
目的不是監視任何人（請不要把這變成生產力稽核）。目的是帶著足夠的了解出席，以便提出好問題。「遷移進行得怎樣？」和「我看到遷移 PR 收到平台團隊三輪審查意見，卡在哪裡？」之間有天壤之別。第二種告訴你的直屬部屬你在關注，根據我的經驗，它能更快進入真正的對話。
實際操作是這樣的。假設你在為一對一做準備，對象是一位正在做通知系統重構的工程師。你查 GitHub 發現他們這週合併了兩個 PR 但有一個開了四天沒有審查者。你查 Linear 注意到父級史詩昨天從「In Progress」變成了「Blocked」。你查 Slack 在 #platform 找到一個討論串，他問了資料庫 schema 變更的問題，兩位資深工程師給了矛盾的回答。
現在你有三個具體的討論主題，而你還沒寫議程。
會議準備不是把主題寫下來。而是從你的工具中收集足夠的情境脈絡，讓重要主題自然浮現。
第二層：決策與阻擋檢查（2 分鐘）
會議（理論上）是做決策的地方，所以知道哪些決策待定是有幫助的。這一層大約花兩分鐘，能攔截那些原本會在會議中途突然冒出的事情。
- [ ] 搜尋 Slack 中與會者在過去一週包含「決策」、「我們是否該」、「等待」或「被擋住」的訊息
- [ ] 檢查 Linear 中標記有涉及與會者的阻擋項或依賴關係的議題
- [ ] 尋找共享 Notion 文件或 Figma 評論中尚未解決的開放問題
- [ ] 回顧你上次與此人會議的筆記：你有承諾要跟進什麼嗎？
最後一項是大多數人跳過的，卻可以說是最重要的。忘記承諾會可靠地損害信任，而主動跟進會可靠地建立信任。這是改善一對一最簡單的方法，和會議準備模板或任何工具都無關。
有效的準備
- 從工具提取具體活動數據，在寫任何議程之前
- 搜尋待決決策，跨 Slack 討論串和 Linear 阻擋項
- 參考上次會議筆記 以檢查自己的跟進情況
- 讓脈絡浮現主題，而非猜測該討論什麼
浪費時間的準備
- 寫通用議程 如「更新 / 阻擋 / 行動項目」，沒有任何支撐脈絡
- 依賴記憶 回憶分散使用工具的一週中發生了什麼
- 最後問「還有其他的嗎？」 因為你想得起來要討論的事情已經說完了
- 把每場會議都一樣對待，不管工作中實際發生了什麼
第三層：變化差異（2 分鐘）
這一層是選用的，但對固定週期的會議真的很有用，像是每週一對一或雙週團隊同步。你在回答的問題是：上次談話以來什麼變了？
拿出上次會議的筆記或紀錄（即使那些「筆記」只是文件裡的一串要點），比較當時和現在的狀態。具體來說：
- 上次「進行中」的議題哪些已上線？哪些沒動？
- 有沒有新的優先事項或緊急狀況出現，是之前沒在雷達上的？
- 有沒有團隊變動、組織重整公告或路線圖調整影響到這個人的工作？
變化差異讓你的會議聚焦在進度與偏移。不是一份扁平的主題清單，而是走進一場關於軌跡的對話：事情在哪裡、現在在哪裡、這對我們接下來做什麼意味著什麼。
舉個實例：假設上週你的直屬部屬在支付史詩中有三個議題進行中，其中一個是高優先級的錯誤修復。這週，錯誤修復已上線（很好），一個議題進入審查（不錯），一個六天沒更新（值得輕聲問一下）。這就是你的一對一結構，組裝起來大約花了九十秒。
整合：模板
這是實際模板。複製它、調整它、丟掉不適用的部分。格式不如習慣重要。
```
會議準備：[人員/群組] – [日期]
第一層：活動掃描
- 近期 PR（已合併/開啟中/審查中）：
- Linear 議題（已完成/進行中/被擋住）：
- 值得注意的 Slack 討論串：
- 其他工具活動（Figma/Notion/等）：
第二層：決策與阻擋
- 需要解決的待決決策：
- 活躍阻擋項：
- 我上次會議的跟進事項：
第三層：變化差異（與上次會議比較）
討論筆記
（會議中填寫）
行動項目
（記錄負責人和截止日期） ```
這個模板刻意與工具無關。無論你查詢 GitHub、Linear、Jira、Shortcut 還是白板照片，結構都一樣：活動、決策、變化。
為什麼這比議程更有效
傳統的會議準備模板問「我想談什麼？」這個模板問「實際上發生了什麼？」然後讓主題從數據中浮現。實際上這意味著你會抓到原本會漏掉的東西，像是一個 PR 放了四天沒人審查，或一個決策在 Slack 討論串中做了但從未進入 Linear。
每次同一份檢查清單也意味著更少漏掉的阻擋項。當準備是一個具體的五到七分鐘例行工作（好吧，「瀏覽一些 Slack 討論串」能有多具體就多具體），你就不再畏懼它了。
在你的一週中擴展
假設你管理六個直屬部屬，每週一對一，加上兩個團隊同步和一個跨功能會議。這是九場需要準備的會議，已經比任何人在白板上從零設計公司時會安排的更多（但事實就是如此，會議不會消失，那就面對吧）。
如果每次準備平均花十五分鐘在工具間無結構地搜尋，那就是每週超過兩小時花在收集脈絡上。用這個會議準備模板，建立肌肉記憶後每次五到七分鐘。九場會議大約一小時，所以你每週省下約一小時，48 個工作週下來大約是每年 48–50 小時。你把那些省下的時間花在真正的工程工作上，還是望著窗外為自己的流程得意，那（老實說）不關我的事。
stat: "~48–50 小時/年" headline: "會議準備節省的時間" source: "基於 48 個工作週、每週 9 場會議，15 分鐘無結構 vs 6 分鐘模板化"
品質差異也會複利累積。九場有準備的會議意味著九場對話能更早浮現真正的問題，並減少之後「啊，我本來想問的是...」那種追加的 Slack 訊息。這很難量化，但如果你曾在下午 3 點私訊一個早上 10 點才和你開了三十分鐘會的人，你就懂那種感覺。
什麼時候完全跳過準備
不是每場會議都值得準備。如果你要參加公司全員會議或社交咖啡聊天，不要事先拉 Linear 查詢（認真的）。如果會議是那種沒人記得排了但所有人都怕刪的 30 分鐘循環會議，也許你需要的準備是按下「拒絕」的勇氣。在你擁有結果或需要做決策時使用這個模板：一對一、團隊同步、規劃會議、跨功能審查。
如果一場會議不值得五分鐘的準備，值得問的是它是否值得三十分鐘的出席。如果你想更進一步，完全自動化你的會議準備，那是一個不同的（老實說更有趣的）話題。
將訊號智慧送到你的收件匣。
常見問題
Q: 工程主管的會議準備模板應該包含什麼？ A: 好的會議準備模板在每次會議前提取三樣東西：與會者的近期活動（PR、議題、訊息）、與議程相關的任何待決決策或阻擋項，以及上次會議以來有什麼變化的快速掃描。模板本身不如用真實工具數據而非記憶來填寫的習慣重要。
Q: 一對一會議的準備應該花多久？ A: 有了結構化模板和正確的工具查詢，一對一會議準備應該在五分鐘內完成。大多數工程主管花 15–20 分鐘，因為他們在 Slack、Linear 和 GitHub 之間手動搜尋。一個明確指出該看哪裡的模板能大幅縮減時間。
Q: Sugarbug 能為工程團隊自動化會議準備嗎？ A: 可以。Sugarbug 連接你的 Linear、GitHub、Slack、Google Calendar 和 Notion 等工具，然後根據與會者和這些工具中發生的事情，在每次會議前組裝簡報。它提取的情境脈絡和你用這個模板手動收集的一樣，但是自動完成的。
Q: 不用特殊工具也能使用這個模板嗎？ A: 當然可以。這個模板只需要文字編輯器和瀏覽器分頁就能用。重點是提供一個可重複的情境收集結構。如果之後想自動化，有工具可以做到，但模板本身就能獨立運作。