提示工程實戰手冊（The prompting playbook）（第 3/3 段）

🧑‍🏫 這是 Claude 官方 prompt 教學的最後一段。講者從零做一個「排班 AI」，同時比較改 prompt（給 AI 的指令）、換模型、改變執行流程三種做法，看各自會帶來什麼好處和代價。最後總結工程師日常調 AI 時最實用的幾個原則。就算不寫程式，也能學到怎麼讓 AI 把複雜任務做對。

• 22:33 同一條指令，不同世代的模型可能會用很不一樣的方式執行。模型越聰明，越會自己做取捨，所以要把取捨的兩邊都寫清楚
  ↳ 同一句指令，換一代模型可能做出很不一樣的結果。越聰明的模型越會自己拿捏輕重。所以如果兩個目標會互相拉扯（例如要簡短又要完整），就要寫清楚兩邊各有多重要。
• 23:03 改完 prompt 後重跑最後一個 test case，所有 eval 都通過了
  ↳ test case 是一題事先準備好、可以對答案的考題。改完 prompt 再重跑最後一題，整組考題（eval）全部通過，代表這次修改確實有效。
• 23:03 第一個情境的回顧：套用 general hygiene 原則讓 prompt 先提升一截；拿掉原本為了修補舊模型行為而加的多餘指令；給模型工具，讓它能穩定完成特定任務
  ↳ 第一個情境做了三件事：先把基本功（general hygiene，像是整理結構、講清楚格式）做好，讓表現先上來；再刪掉以前為了遷就舊模型加的補丁指令；最後給模型工具，讓固定任務能穩定完成。
• 23:37 第二個情境是從零開始打造新的 agent。範例 agent 要根據員工的可上班時間和其他限制，排出一週的零售店員班表
  ↳ agent 是能自己分步驟完成任務的 AI 程式。第二個情境是從頭做一個新的：輸入員工哪天能上班和其他限制，讓它排出零售店一整週的班表。
• 23:37 從零打造 agent 時，除了 prompt，也要考慮用哪個模型和哪個 harness。這個範例會比較多種做法，看這三個面向各自的影響
  ↳ harness 是包在模型外面的執行架構，決定模型怎麼被呼叫、分幾步做、能用哪些工具。從零開始時，prompt、模型、harness 三樣都能調整，範例會分別比較三者的影響。
• 24:08 demo 用的是講者 vibe coding 做出來的 web app。題目有 8 位員工、一張要依人力需求排滿的班表，以及每種情況都必須滿足的限制條件
  ↳ vibe coding 是靠跟 AI 對話、自己幾乎不寫程式就把東西做出來。講者用這個方式做了一個網頁：有 8 位員工、每個時段需要的人數，還有無論如何都不能違反的規則。
• 24:40 因為限制條件是硬性規則，這次不像上一個案例用 LLM judge 評分，而是寫 Python 函式，用程式計算每份產出的班表違規幾次
  ↳ LLM judge 是請另一個 AI 打分數，適合「寫得好不好」這種主觀題。排班規則是對或錯很明確的硬規定，直接寫程式計算違規幾次，比較準也比較客觀。
• 25:15 先從簡單的開始：用 Sonnet 4.6 搭配只有必要內容的 prompt 當 baseline，之後再往上 hill climb
  ↳ baseline 是拿來比較的起點。先用 Sonnet 4.6（Claude 的中階模型）配最精簡的 prompt 跑一次，之後每次改一點、看分數有沒有變好，一步步往上爬，這就叫 hill climb。
• 25:15 baseline prompt 已經套用前面講的 hygiene 和最佳實踐：用 XML tags 組織結構，並指定輸出格式
  ↳ 就算是最簡單的版本，基本功也已經做好了：用 XML tags（像 <規則>…</規則> 這種標籤）把 prompt 分成區塊，讓模型分得清每段在講什麼，也講明要交出什麼格式。
• 25:45 要求模型輸出 JSON。如果沒有給輸出結構，下游可能會出現解析錯誤
  ↳ JSON 是程式可以直接讀取的固定資料格式。班表產出後要交給其他程式處理，如果模型每次交出的格式都不一樣，後面的程式就讀不懂，會出錯。
• 25:45 Sonnet 4.6 簡單版第一輪跑 eval，所有 case 都失敗
  ↳ 第一輪結果：簡單版的 Sonnet 4.6 每一題都沒過，排出來的班表都有違規。這就是起點，接下來看要怎麼改進。
• 26:15 test set 每題做 5 次 trial，表上的數字是每次 trial 的違規次數
  ↳ trial 是把同一題再跑一次。AI 每次的回答可能不一樣，所以每題跑 5 次，表上記下每次違規幾條，才分得出是穩定表現還是剛好運氣好。
• 26:15 從輸出看得出模型有認真推理，但花掉很多 token，而且顯然沒有檢查自己的結果
  ↳ token 是模型處理文字的計算單位，用得越多就越花錢、也越慢。從輸出看得出模型想了很多、花了不少 token，但排完就直接交出，沒有回頭檢查有沒有違規。
• 26:47 其他條件不變，改用推理能力更強的 Opus 4.7。雖然所有 case 還是失敗，但違規總數比 Sonnet 4.6 少很多
  ↳ Opus 4.7 是 Claude 更高階、推理能力更強的模型。只換模型、其他都不動，結果還是每題都沒全對，但違規數比 Sonnet 4.6 少了很多。
• 27:17 還不能上線，但看得出多給推理能力確實有幫助
  ↳ 班表只要有一條違規就不能用，所以還不能上線。不過方向確定了：讓模型多花力氣推理，結果確實會變好。
• 27:17 下一步讓 Opus 開啟 adaptive thinking，由模型自己決定要花多少思考和推理。prompt 沒改，只改了 API 設定
  ↳ adaptive thinking 是讓模型依題目難度，自己決定要想多久。API 是程式呼叫模型時用的介面；這一步 prompt 一字沒改，只是在呼叫時把這個設定打開。
• 27:58 Opus 4.7 加 adaptive thinking 能穩定產出符合規則的班表，但 token 用量大約變成 3 倍，latency 也變成 3 倍
  ↳ latency 是從送出請求到拿到結果要等多久。開了 adaptive thinking 之後，Opus 終於能穩定排出合規的班表，但 token 用量和等待時間都大約變成 3 倍。
• 27:58 這次 latency 約 100 秒，講者為了節省時間改成非同步執行。接下來要想辦法在成本和 latency 之間取得更好的平衡
  ↳ 一次要等大約 100 秒，所以講者改成非同步：送出後先去做別的事，跑完再回來拿結果。下一步的目標是在花費和速度之間，找到更好的平衡。
• 28:33 改試較小的 Sonnet 4.6 搭配更好的 prompt：補上怎麼推理這個問題，最關鍵的是要它在輸出前先檢查自己的結果
  ↳ 換個思路：改用比較小的 Sonnet 4.6，但把 prompt 寫得更好，教它這類問題該怎麼推理，最重要的是要它交出答案前先自己檢查一遍。
• 29:13 結果 5 個 case 過了 2 個。失敗原因不是違反排班規則，而是模型沒能在設定的輸出上限內完成任務
  ↳ 5 題過了 2 題。沒過的不是排錯，而是還沒寫完，就碰到設定的輸出上限被截斷了。這個上限叫 max tokens，意思是一次回答最多能輸出多少 token。
• 29:13 雖然可以調高 max tokens 讓 5 個 case 都通過，但 token 用得更多、latency 也更高，所以大概不會走這條路
  ↳ 把上限調高就能 5 題全過，但會用掉更多 token、等得更久，成本和速度都更差，所以講者大概不會選這條路。
• 29:45 最後改用比較 agentic 的做法：generate-evaluate-repair loop。先由 generator 產生班表初稿
  ↳ agentic 指讓 AI 分成好幾個步驟，自己檢查、自己修正。最後的做法是「產生→檢查→修正」的循環（generate-evaluate-repair loop），第一步先由負責產生的 prompt 排出一版草稿。
• 30:16 另一個獨立的評估 prompt 用 LLM 檢查（不是用程式），逐條規則比對，列出違規並附上證據
  ↳ 第二步交給另一個專門檢查的 prompt，由 AI 來查（不是用程式）：拿每一條規則去比對草稿，列出哪裡違規，並附上具體證據。
• 30:16 第三個 repair prompt 拿到違規清單後，針對問題做精準修正
  ↳ 第三步是修正：拿到違規清單後，只針對有問題的地方精準修改，不去動其他沒問題的部分。
• 30:46 三個 prompt 都很簡單，但各自獨立執行，不是全部塞進一個大 prompt
  ↳ 關鍵在於三個 prompt 都很短，而且分開執行，不是把排班、檢查、修正全塞進一個超長的 prompt。每個步驟只專心做一件事。
• 30:46 agentic 做法解決了所有 test case，token 用量少很多，latency 也比「Sonnet 4.6 加更好的 prompt」低
  ↳ 結果這個循環做法全部過關，token 用量少很多，等待時間也比「Sonnet 4.6 加上更好的 prompt」短。
• 31:16 結論：有兩種合適的做法，一是 Opus 4.7 加 adaptive thinking，二是 agentic loop。loop 之後還會再優化效率
  ↳ 結論是兩條路都可以：一是 Opus 4.7 開 adaptive thinking，讓一個強模型一路想到底；二是分三步的循環，講者之後還會再把它調得更有效率。
• 31:16 generate-evaluate-repair loop 還有一個重要好處：可以在執行時加入 soft requirements
  ↳ soft requirements 是「最好做到、但不是非做不可」的偏好。循環做法還有一個好處：這類偏好可以在執行的當下才臨時加進去。
• 31:47 例如在評估 prompt 裡寫「Harry 不喜歡和 Sally 一起上班，盡量把他們分開」，或「週三需要第三個班」
  ↳ 例如在檢查用的 prompt 裡寫「Harry 不喜歡跟 Sally 同班，盡量錯開」，或「週三要多開一個班」，AI 檢查的時候就會一併考慮進去。
• 31:47 這樣每遇到要個案處理的 soft constraint，就不必去改後端負責評估的 Python 函式
  ↳ 如果只靠 Python 程式檢查，每多一個個案偏好，就得請工程師改程式。寫在 prompt 裡的話，加一句話就能調整，彈性大很多。
• 32:19 總結兩個講者（工程師）日常最常遇到的情境：一是維護 prompt、換到行為不同的新模型；二是從零打造新的使用情境
  ↳ 兩位講者都是工程師，日常最常碰到兩種狀況：一是換了新模型後行為不一樣，要回頭維護舊的 prompt；二是從零開始做新的用途。這支影片剛好把兩種都示範了一遍。
• 32:19 照著 general hygiene 原則做，eval 表現馬上就能提升
  ↳ 不管是哪一種狀況，先把基本功做好（結構清楚、格式講明），分數馬上就會提升，是最划算的第一步。
• 32:50 要有 eval，才能嚴謹地看出改 prompt 對輸出造成的影響
  ↳ 沒有 eval，就只能憑感覺說「好像變好了」。有一組固定的考題可以反覆測，才能確定改了 prompt 之後是變好還是變差。
• 32:50 逐一處理 failure mode、增加結構、避免很長的禁止清單（ban list）等做法，都有助於把模型推向正確行為
  ↳ failure mode 是模型出錯的類型。做法是看它錯在哪一類就針對那一類修，並讓 prompt 有清楚的結構；不要一直往上堆一長串「不准…」的禁止清單（ban list）。
• 33:20 新的 agentic bot 拆成三個獨立的 prompt 系統，不用一個 prompt 包辦全部。每次都要走、又容易重複拆開的步驟，就把它們分開處理
  ↳ 新的排班 bot 拆成三個各自獨立的 prompt，不讓一個 prompt 包辦全部。只要是每次都得做、又能清楚切開的步驟，就把它獨立出來分開處理。

在排班 agent 範例中，用 Sonnet 4.6 搭配改良版 prompt（要求輸出前先檢查結果）時，5 個 case 只過 2 個。沒通過的主要原因是什麼？