黃金圈三：從方法論到 Playbook — 操作化的三個缺口

這篇最短，卻解釋了一個很重要的概念，繼上一篇我們建構了方法論的三個核心，接著找出了結構性漏洞，最後設計了人類介入點，回頭看這些章節，會發現一件有趣的事：我們還沒有執行任何東西。

沒有寫程式、沒有跑測試、沒有修任何 bug，我們做的全部都是在「設計」：我們思考這個問題、用決定用什麼原則來做決策、找出系統的弱點在哪、以及人類該在什麼時候介入。

這就是方法論，方法論不是 SOP，不是步驟清單，不是「先做 A 再做 B 最後做 C」，它是指導你做決策的原則框架，有了方法論，你面對新問題的時候不需要從零開始思考，你有一套原則告訴你「這類問題應該從哪個角度切入、用什麼策略、注意哪些陷阱」，這點跟 SDD (Specification-Driven Development，規格驅動開發) 很像，而接著，決定具體要做什麼、用什麼工具、先做哪一個，是我們幾下來要做的事。

但大部分人跟 Agent 協作時跳過的，就是這一層。

方法論是「怎麼想」的框架，而要讓 Agent 能照著做，還需要往下走一層：Playbook。

很多人的直覺是：方法論再詳細一點就變成 Playbook 了吧？加上具體步驟就好？

沒那麼簡單。

操作化的三個缺口

方法論跟 Playbook 之間有一個缺口，叫做操作化（Operationalization） [1]，這個過程需要三層材料：

第一層：事實基礎（Facts）

方法論是通用的原則，但你的情況是你特有的，所以同一套方法論，10 人團隊和 500 人團隊的落地方式完全不同，所以第一步是搞清楚：現況到底是什麼？

回到我的案例：我們需要先知道平台有多少 Agent、已知問題分佈在哪些類別、目前的偵測率是多少、哪些信號源是可用的，從這些 Facts 才能回頭看方法論裡的哪些原則對我們現在建構 Playbook 是重要的。

第二層：場景識別（Scenarios）

有了 Facts，你才能列出「我們實際會碰到哪些情境」，場景不是隨便列的，沒有 Facts 就亂列場景，你會寫出一堆永遠用不到的 Playbook 規範跟步驟。

我的案例裡，真正需要處理的幾個場景包括：偵測到新類型問題時的處理流程、檢查誤報的判斷標準、系統指標停滯不前時的排查步驟、新的 Agent 加入平台時的 onboarding 流程等等。

第三層：工具與模板（Tools）

每個場景需要搭配具體的工具，問題記錄用什麼格式？指標怎麼定義和追蹤？人類介入的觸發條件用什麼監控？有了這層，我們才有更具體的落地步驟。

Facts 告訴你「我們在哪」，Scenarios 告訴你「會遇到什麼」，Tools 告訴你「拿什麼做」 [4]，三者加在一起，才能把方法論的智慧封裝成 Playbook 的套路。

所以，缺了 Facts 的 Playbook 是空中樓閣，缺了 Scenarios 的 Playbook 是工具清單，缺了 Tools 的 Playbook 是紙上談兵。

Playbook 跟方法論到底差在哪？

打個比方：

方法論是兵法思想，告訴你「應該怎麼思考戰爭」，知己知彼、以逸待勞、避實擊虛，這些是放諸四海皆準(嗎？至少在這個工作目標下是啦～)的通用原則。

Playbook 是作戰手冊，告訴你「遇到 A 情境就做 X」，敵人從左翼進攻，我就後退從右翼圍上，變成包圍之勢 → 這就是告訴你第一步做什麼、第二步通知誰、第三步怎麼調配。

方法論是 prescriptive（規範性的），告訴你「應該怎麼思考選擇」[2]，Playbook 是 scenario-based（場景驅動的），把常見情境整理成可直接套用的套路 [3]。

Playbook 的價值在於：它把經驗和判斷預先封裝好，讓執行者(Agent)不需要從頭理解方法論就能快速落地，等於你把原理(理論)透過方法論轉為運作的基礎，透過你的經驗、情境、工具過濾之後，就變成 Playbook，Agent 依照 Playbook 做事，遇到真的需要判斷但 Playbook 卻沒有 Cover 時，還有方法論作為最後一道防線。

一樣的概念回到我的案例，方法論說「所有判斷必須基於事實信號源」，這是一個原則，Playbook 則具體定義了：每一個指標要從哪個信號源取值、用什麼格式記錄、多久更新一次、當主指標和影子指標矛盾時照什麼流程處理，而如果遇到了 Playbook 沒有定義的新場景、新工具、新的事實(指標)，別擔心，我們還有方法論可以配合來建立新的 Playbook 區塊。

490 行文件拆成三份的瞬間

在我的實作過程中，這兩層誕生於一個很戲劇化的瞬間，一開始經過一整段的對談，Agent 把所有東西寫在同一份文件裡，方法論、操作流程、指標定義、專案計畫全部混在一起，大概 490 行，我回頭看了一遍，發現都混雜了，我這時下了一個指令：

「回頭看這整個文件，確認一下實際的方法論在哪一塊，哪一些其實是操作，哪一些其實是指標，哪一些其實是定義，以及哪一些其實是計畫。」

這驅策 Agent 做了一次內容審計，他才發現他把五種不同類型的內容交織在同一個檔案裡，他跟我說他發現了，問我該怎麼辦？所以我請他拆成三份獨立的文件：方法論（Why,為什麼這樣做）、Playbook（How, 怎麼操作）、計畫（What, 目前在做什麼），很眼熟嗎？對，就是 TedTalk 的 Simon Sinek 說的 Golden Circle [5]，也就是 Apple 製造產品的邏輯，我套用這個邏輯，把前面這些討論的結果，依照黃金圈的分層拆成三份文件，每份文件的開頭都要說明自己負責什麼、回答什麼、不回答什麼，以及跟其他文件的關聯。

這個「拆分」的動作本身就是操作化的核心。 把不同層級的知識分開管理，而不是全部擠在一起，讓 Agent 知道什麼時候該看方法論（做決策時）、什麼時候該看 Playbook（執行操作時）、什麼時候該看計畫（了解當前進度時）。

或許這裡最實際的收穫是：如果你發現你的 Agent 經常搞混「原則」和「步驟」，很可能是因為你把兩者寫在同一份文件裡。 拆開它們，不只是讓文件更乾淨，而是讓 Agent 在不同的情境下載入不同層級的知識，這本身就是我們在第三篇 Context Engineering [6] 裡討論過的 JIT 載入原則。

下一篇，我們來看最後一哩路：有了 Playbook，為什麼還需要 Execution Plan？以及計畫在實戰中碰壁之後會怎樣。

參考資料：

[1] Operationalization | A Guide with Examples — Scribbr https://www.scribbr.com/methodology/operationalization/

[2] Differences between a methodology and a playbook — ProjectManagement.com https://www.projectmanagement.com/discussion-topic/208849/differences-between-a-project-management-methodology-and-a-playbook-

[3] What Is a Business Playbook — FlippingBook https://flippingbook.com/blog/guides/what-is-a-business-playbook

[4] How Implementation Science Bridges the Know-Do Gap — UF https://impsci.med.ufl.edu/how-implementation-science-bridges-the-know-do-gap/

[5] Simon Sinek - The Golden Circle - TedTalks 2009 https://www.youtube.com/watch?v=fMOlfsR7SMQ

[6] 第三篇：Context Engineering — JIT 載入原則 /articles/3-context-engineering