當我們在一份營運工作裡累積多年經驗，會慢慢學會怎麼處理難搞的客戶、模稜兩可的案例，以及那些看起來很簡單、其實一點也不簡單的問題。到了某個階段，我們會希望這種工作品質能擴展到整個團隊，而不是只有少數資深的人做得到。
於是我們開始把事情寫下來。我們建立 SOP、整理內部 wiki、親自訓練新人，有時甚至一對一帶。到了今天，我們也可能把這些文件全部丟進 AI Agent，期待它立刻變成最強營運同事的數位版本。
但結果常常不是這樣。AI 會編出不存在的政策，或把一個需要細緻判斷的問題，回答得像是在照課本唸。
為什麼？因為我們規模化了文件，卻沒有規模化真正重要的東西：判斷。
這些靜態形式有用，但它們不會反過來檢查我們。它們不會主動產生新的案例讓我們處理，也不會把真實客戶對話收集起來，指出內部方法在哪裡開始失效。它們保存的是我們寫下它們那一刻的知識，卻無法讓知識跟著現實一起更新。
專業不會因為被寫成文件就變得可靠。它必須活在一個會持續浮現新情境、收集專家判斷、並迫使方法不斷改善的系統裡。
靜態知識承載不了判斷
一本手冊或一門訓練課，可以說明我們的理論，也可以示範幾個案例。但實際工作的人還是得把它套用到自己的情境裡，而真實世界的變化，永遠比任何 wiki 能涵蓋的範圍多得多。
SOP 記錄的是步驟，卻記錄不了「這件事到底有沒有做對」的判斷。團隊成員可能完成了每一個步驟，卻仍然錯過重點。指示是單向流動的，專家的判斷訊號沒有流回來。
直接訓練會好一些，前提是它包含真實案例的審查。專家可以看到具體成果、指出錯誤、解釋差別。但這種訓練很難規模化。一位專家能檢查的案例就那麼多。
這就是過去的取捨：
| 形式 | 能超越團隊規模 | 能保留判斷 |
|---|---|---|
| 書本／課程 | ✓ | ✗ |
| SOP／wiki | ✓ | ✗ |
| 直接訓練 | ✗ | ✓ |
| Agent + 判斷 | ✓ | ✓ |
現在最常見的捷徑，是跳過手冊，直接把所有東西倒進 AI：對話紀錄、email、文件、過去的回答。
但這沒有真正解決問題。它多半只是教 AI 模仿那一整堆資料。
那些過去的回答，有些很好，有些很趕，有些已經過時。AI 本身不知道哪些是我們真正願意背書的。它也只會複製說出口的話，而不是當時背後的思考。我們真正的專業，藏在我們權衡過的脈絡、默默排除掉的選項，以及知道何時該停下來轉交的邊界裡。
核心問題不只是規模，而是缺少一套回饋系統：一套能持續浮現新情境、指出現有方法在哪裡失效，並把專家判斷重新帶回劇本裡的系統。沒有這個迴圈，知識就會停在原地。它可以被保存，卻不能隨著真實世界的狀況一起演化。
我們其實已經有了關鍵材料
多數營運團隊，其實早就擁有一套可靠系統需要的兩種材料。
第一種是原則：那些我們慢下來時說得清楚的規則、區分與標準。我們知道什麼重要、什麼要避免、界線在哪裡。
第二種是已經發生過的判斷時刻：那些我們看得出好答案長什麼樣子的具體案例。也許是一次處理得很乾淨的客訴，也許是某個政策例外做得剛剛好，也許是看到一份草稿時立刻知道：「不對，這不是我們應該這樣說的方式。」
問題是，這兩種材料很少真正接上。原則不一定會在工作發生的當下派上用場；而那些精準的判斷時刻，也很少被收回系統裡。知識明明存在，卻沒有累積起來。
專業的基本單位：情境 + 判斷
要把這兩種材料接起來，我們需要改變對「知識」的定義。不是只寫下規則，而是捕捉「具體脈絡」和「判斷標準」交會的地方：
- 情境：團隊或 Agent 可能真的會遇到的狀況。
- 判斷：在這個狀況裡，一個好回覆必須達到的標準。
實際上會像這樣：
- 情境（測試）： 客戶因為航班取消，要求例外退費。
- 基準回答（理論）：「不好意思，我們的政策規定超過 30 天不能退費。」
- 我們的判斷（標準）： 不通過。 Agent 必須先承認航班取消這個特殊狀況，指出可能適用的不可抗力例外流程，並轉交給真人處理，而不是直接拒絕。
再看一個技術支援機器人的例子：
- 情境： 使用者問了一個模糊的技術問題，可能代表兩種完全不同的意思。
- 基準回答： Agent 猜一個最可能的意圖，然後自信地給出五段技術說明。
- 我們的判斷： 不通過。 Agent 在提供任何步驟前，必須先問一個明確的釐清問題，縮小使用者真正想問的是什麼。
這就是專業開始能被系統使用的地方。情境保留了真實世界的混亂，判斷保留了我們對「好」的標準。兩者合在一起，就能把一次性的專家修正，變成可以重複使用、可以自動檢查的標準。
Agent 照劇本執行，判斷負責驗證
用這種方式打造的智能系統，有兩個不同的部分。
劇本（Agent 設定）——我們的指示、system prompt 和知識庫。這是我們目前對「工作應該怎麼做」的最佳理解。
驗證標準（情境與判斷）——一個具體、真實的狀況，搭配一個好回覆必須達到的標準。它用來證明這份劇本是不是真的有效。
真正有力量的不是其中任何一邊，而是兩者之間的迴圈。Agent 根據目前的劇本回答；情境與判斷檢查這個回答是否符合我們的標準。當它沒達標時，那不只是錯誤，而是一個精準訊號，告訴我們方法哪裡需要改。
這會徹底改變營運專家的角色。我們不需要親自 QA 每一場對話，也不需要盲目相信 SOP 有被正確執行。系統負責日常執行，而我們把時間放在更重要的地方：檢查系統哪裡薄弱、補上新的判斷、持續改善劇本。
真正的資產是判斷資料庫
有了判斷，我們可以重建 Agent；只有 Agent，卻還原不出那些判斷。
多數平台把 Agent 設定當成主要資產，把評估當成事後補上的 QA。我們認為這剛好反了。
判斷，才是團隊真正標準所在。Agent 設定只是我們目前為了達到這個標準，做出的最佳嘗試。
Agent 會改變。我們會學到新東西，商業現實會改變，底層模型會更新，prompt、文件和工作流程也都會被重寫。穿過這些變化時，判斷資料庫才是穩定的錨點，告訴我們每個新版本到底有沒有變好。
只要有一套夠完整的情境與判斷，我們就能從零重建 Agent，因為這套資料庫已經清楚定義了什麼叫做「好」。但如果只有 Agent，我們無法反推出那些判斷。我們不知道哪些行為最重要、哪些錯誤不能接受，也不知道改一段 prompt 會不會破壞原本重要的表現。
這也符合專家判斷實際運作的方式。要坐下來寫出一套完整、毫無漏洞的理論，非常困難。但看著一個具體輸入和輸出，然後說「不對，這裡錯了，因為……」通常容易得多。
情境與判斷就是利用這個自然優勢。我們不需要先寫出完美劇本，只需要持續判斷系統有沒有達到我們的標準。
系統是如何改善的
一個失敗的 AI 回答不是死路。它是一個精準的診斷工具，會指出我們寫下來的指示缺了哪些原本只存在於腦中的專業。
我們執行一個情境。Agent 忠實照著指示做，也確實做了我們叫它做的事，但結果仍然沒有達到標準。
這個失敗非常有價值。它揭露了我們寫下來的方法，和我們真正想表達的方法之間的落差。這時候，我們可以問一個更有用的問題：我們真正的意思是什麼，而我們之前沒有把它說清楚？
有時候，修正是一份缺少的文件。有時候，是 wiki 裡有一條互相矛盾的指示。有時候，是團隊一直放在腦中、卻從來沒有明確命名的細微差別。一旦這個差別被寫進劇本，其他許多情境也會一起改善。
真實營運會讓這個迴圈更強。客戶問了一個我們沒預期到的問題；Agent 轉交、答錯，或暴露出內部流程裡一個令人困惑的地方。這些混亂的現實會變成新的情境，而我們的人工修正會變成新的判斷。系統之所以會進步，是因為現實不斷提供新的案例，逼它一起演化。
先打造判斷資料庫
Codeer 還很早期，這套工作方式也還很早期。但如果你正在嘗試自動化一個團隊，或打造一套內部專業系統，下一步其實很清楚：不要只是不斷微調 system prompt，而是開始累積情境與判斷。
不要把它們當成事後的 QA 或普通測試。它們是你的營運護城河。它們定義品質標準，在底層 AI 模型改變時保護你的團隊，也把每一次混亂的真實對話，轉化成系統性的改善。
如果你準備好停止打造靜態 Agent，開始真正規模化專家判斷，可以免費開始使用 Codeer 或預約示範。