黃金圈四：從 Playbook 到執行 — 計畫會變才是重點

上一篇我們把方法論操作化成了 Playbook [4]，搞清楚了 Facts、Scenarios、Tools 三個讓方法論變成 Playbook 的轉化劑，也看到了把 490 行混合文件拆成三份的過程，結束了嗎？

還差一點，Playbook 是通用的套路，沒有時間軸、不指定誰做、不談資源限制，它是一份菜單跟食譜，所以我們還缺一個 Plan。

Execution Plan（執行計畫）是今晚的備餐清單跟流程步驟，食譜告訴你宮保雞丁怎麼做，備餐清單告訴你「6 點前切好雞肉、5:30 先去買花生、瓦斯爐右邊那個爐子壞了所以用左邊的」。

情境化決策 — 從 Playbook 到 Plan 需要什麼？

從 Playbook 到 Execution Plan 需要經過情境化決策，包含三件事：

現狀評估（Situation Assessment）

Playbook 裡可能有十個場景，但你當前面對的是哪一個？嚴重程度如何？有什麼約束條件？

我的案例裡，計畫的第一步不是直接開始跑偵測迴圈，而是「前置研究」：先量測目前的真實 Baseline，這邊的真實是真實跑過量出來的實際值，不是 Agent 自己看 Code 算出來的估計值，知道哪些指標是實測的、哪些是估計的很重要，只有標清楚了，才能把 Playbook 從「通用」變成「跟我有關」。

排序與取捨（Prioritization & Trade-offs）

Playbook 會告訴你每個場景該怎麼處理，但不會告訴你當多個場景同時發生時該先處理哪個，因為這是當下人類、計劃、商業環境的判斷。

這需要影響和緊急度的排序 [2]、明確的「不做清單」、以及依賴關係分析，比如我的案例裡，必須先完成前置研究，才能知道哪些偵測迴圈的改善是最有價值的，不能跳過研究直接開始修檢查。

承諾與綁定（Commitment）

最關鍵的一步，把「應該做」變成「誰在什麼時候做完」[1]：責任人指派、時間線、資源分配、成功標準。

計畫會變 — 這才是重點

我的案例裡發生了一件事，完美地說明了為什麼計畫需要跟方法論和 Playbook 分開。

第一版的計畫是四階段序列式的：Phase 1 建立 Ground Truth → Phase 2 改善偵測 → Phase 3 啟動發現迴圈 → Phase 4 持續進化。很正式、很完整。

但實際開始執行後，CEO 看了這個計畫，覺得太理論太大了，他指示改成 PR 驅動的模式：每改善一個檢查就是一個 PR，不需要等整個 Phase 完成才能推進。

於是我們做了一件事：方法論不動、Playbook 微調、計畫大改。

方法論裡的三環閉環、三個核心、漏洞防護 [3]，這些原則完全不變，因為 CEO 的決定跟方向還是完美地落在方法論中，Playbook 的操作流程做了一些調整（從正式的閉環循環改為 PR 驅動的工作流），但核心概念不變，而計畫則幾乎全部重寫：四階段變成 PR 清單、正式的 Ground Truth 登記表被取消、指標從系統化的追蹤簡化成「改善前後的違規數量 + 誤報率」，這讓整個計劃變成一個 MVP 的驅動模式，簡化到可以在非常短的時間之內實現並驗證，然後我們可以在後續依照實際狀況看看怎麼調整，甚至慢慢長回原本的規劃。

這就是為什麼三個層級要分開管理。 如果你把方法論和計畫寫在同一份文件裡，計畫一改，你會不小心把方法論也改了，但方法論是穩定的「為什麼(Why)」，計畫是變動的「現在做什麼(What+Where)」，混在一起只會讓兩邊都失去清晰度。

而且最重要的是：計畫會變，是正常的，因為我們除了 What，還加上了我們現在在哪？(Where are we now？)，這個 Where 跟進度、時間、所處情境有關，所以計畫變了不代表之前是錯的，只是情境改了，好的計畫不是永遠不變的計畫，而是變的時候你知道我們在哪、該改哪一層、不該改哪一層。

回到 Agent — 為什麼這對 AI 協作特別重要

你可能會想：這些東西不就是傳統的專案管理嗎？Theory → Methodology → Playbook → Plan，這在軟體工程裡不是常識？

區別在於：傳統專案管理裡，執行者是人類，人類有隱性知識，就算計畫寫得不完整，有經驗的人會自動補上缺口，沒寫進 SOP 的判斷，資深的同事也知道該怎麼做。

但 Agent 沒有隱性知識

Agent 只知道你告訴他的東西，如果你只給他方法層級的指令（「先做 A 再做 B」），他遇到 A 和 B 之間沒覆蓋到的情境就會卡住，或者更糟，會自己猜一個做法然後安靜地執行，就像我們在時區盲點那篇 [5] 看到的。

但如果你同時給他 Playbook（「所有判斷必須基於事實信號源」「偵測到矛盾時先自行調查一輪再 escalate」），他在面對新情境時就有一個判斷框架可以依循，如果連判斷框架都無法解決，就升級到方法論看看應該怎麼做，沒有這些，你就是在進行一場賭博，賭 AI 構建的跟你想的一樣，甚至賭 AI 猜的會是你想做的，這就是為什麼跟 Agent 協作時，這條鏈比跟人類協作時更重要：

方法論是讓 Agent 從「照著做」升級到「知道為什麼這樣做」的關鍵，接著的 Playbook 是讓 Agent 從「每次都要問你」升級到「遇到常見情境可以自行處理」的關鍵，而計畫是讓 Agent 知道「我們現在在做什麼、下一步是什麼、什麼是優先的」。

完整的鏈路

每一層往下，都是從「通用」到「專屬」、從「可能」到「確定」的過程，我們越往下、彈性越低，但可執行性卻會變的更高。

而最重要的是：這條鏈不是單向的，執行計畫在實戰中碰壁了，回饋修改 Playbook，Playbook 的修改如果觸及原則層面，回饋更新方法論，方法論的更新如果挑戰了原本的理論基礎，那就是一個新的發現。

我的案例裡，v1 計畫碰壁了（太大了），回饋簡化了 Playbook（PR 驅動），但方法論的三環閉環和三個核心完全沒動，因為問題出在操作層面，不是原則層面。

我的觀察

走過一整段路之後，我覺得這一路走來最值得記住的不是每一層是什麼，而是大部分人跳過了哪一層？

如果你跟 Agent 協作的經驗是「給他指令他做得到，但遇到例外就破功」，問題很可能不是 Agent 不夠聰明，而是你只給了他方法層級(Playbook)的東西，缺了方法論層級的判斷框架。

如果你的經驗是「Agent 的 Playbook 寫得很好看但用不了」，問題可能在操作化的三個缺口：你有沒有先搞清楚自己的 Facts？有沒有列出真正會遇到的 Scenarios？有沒有配對應的 Tools？

如果你的經驗是「計畫一做完就過時了」，那不是計畫的問題，是你把計畫跟方法論混在一起，導致計畫一變就什麼都跟著亂。

或許最實際的建議是：下次你給 Agent 一個新任務的時候，先問自己三個問題：

1. 我有沒有告訴他「為什麼」要這樣做？（方法論）
2. 我有沒有告訴他常見的情境該怎麼處理？（Playbook）
3. 我有沒有告訴他目前的情況、優先度、和約束條件？（計畫）

如果三個都有，Agent 才有足夠的 Context 在面對新情境時做出合理的判斷，如果只有第三個，你就只是在給他指令，而不是在跟他協作。

或許這就是從「用 Agent」到「跟 Agent 一起工作」的那條線：你願不願意花時間把你腦子裡的「為什麼」也教給他。

參考資料：

[1] Project Execution Plan vs Project Management Plan — 123Worx https://123worx.com/blog/differences-between-project-execution-plan-and-project-management-plan/

[2] Prioritization Matrix — Atlassian https://www.atlassian.com/team-playbook/plays/prioritization-matrix

[3] 心法五：理論 vs 方法論 — 本系列前一篇 /articles/17-mindset-theory-vs-methodology

[4] 心法七：從方法論到 Playbook — 本系列前一篇 /articles/19-mindset-methodology-to-playbook

[5] 實戰 Tips 4：Agent 的時區盲點 — 隱性假設案例 /articles/16-tips-agent-timezone-blind-spot