昨天那個主管有兩個毛病：14 封不需要人工的信，它把 6 封標成需要人工；派工之後還會自己補一筆專員沒回報過的事實。

今天重寫它的 System Prompt，然後拿 20 封信跑兩個版本做對照。結果是分數明顯變好，但也多付了 27% 的 token，而且新版自己違反了我寫給它的規則——違反得還挺有道理。

先把第二位專員接上去

重寫之前先補一件事：W2 掛上來。昨天只有 W1，主管遇到商品知識問題只能標記需要人工，這會讓「該不該轉人工」的統計失真。

接法跟 W1 一樣，再加一個 Call n8n Workflow Tool 指向 W2，工具描述把界線寫清楚：

派工給知識專員。專員會查官方 FAQ，回報有條目出處的答案，查不到會明確回報 not_found。
使用時機：客戶詢問商品知識、保存、沖煮、出貨與運費政策、付款方式、退換貨政策、保固。
不要用在查詢特定訂單。

另外把 W2 的 embedding 從 nomic-embed-text 換成 bge-m3。Day 12 已經測出差距（檢索命中率 9/15 對 15/15），主線沒有理由繼續用比較差的那個。換完記得重跑索引，Simple Vector Store 是存在記憶體裡的。

兩個版本

v1b 是昨天那份 prompt，只多加一行介紹 W2，寫法維持原樣：你的團隊、你的工作流程、派工規則、重要限制，總共 20 行出頭。

v2 是整份重寫。差別不在字數，在結構。

先寫成功標準。 v1 從頭到尾在講「你要做什麼」，沒有講「做到什麼程度算做完」。v2 第一段就定義：

## 你的成功標準
你的工作成果不是「客戶的問題被解決了」。
你的工作成果是「一份正確的案件分類與一組有來源的事實」。

你這次執行算成功，當且僅當：
1. intent 分類正確
2. 該派的工都派了，不該派的沒派
3. collected_facts 裡每一筆都來自專員回報，且 source 格式合法
4. 你沒有寫任何一句給客戶看的話

這段是針對「主管想自己解決問題」寫的。模型預設會往「把客人服務好」的方向用力，而主管的職責是分類和派工，這兩件事的成功定義完全不同。

把派工寫成查表，不是寫成原則。 v1 寫「如果需要查詢訂單資料，呼叫 order_lookup」，什麼叫「需要」交給模型判斷，而它判斷的結果就是遇到一點不確定就說需要人工。v2 改成一張表：

| 情況 | 動作 |
|---|---|
| 提到訂單編號 | 派 order_lookup，order_id 填該編號 |
| 沒提編號但問訂單／物流／到貨 | 仍然派 order_lookup，order_id 填空字串，customer_email 填寄件人 |
| 問商品知識、政策、沖煮方式 | 派 knowledge |
| 同時問了訂單和知識 | 兩個都派 |
| 退貨／換貨／保固 | 兩個都派 |
| complaint / promo_coupon / other | 不派工 |

重要：不要因為「資訊可能不足」就放棄派工。
判斷資訊夠不夠是專員的工作，不是你的工作。

最後那兩句是整份 prompt 最有效的一段，等一下看數字就知道。

禁止事項給錯誤示範。 光寫「不要把自己的知識當成事實」不夠具體，所以每一條都附一個錯誤的 JSON：

### ❌ 禁止 1：把自己的知識放進 collected_facts
合法的 source 只有兩種格式：
  orders!<訂單編號>   faq![<條目編號>]

錯誤示範：
  { "key":"estimated_arrival", "value":"1-3 個工作日", "source":"general_policy" }

這個示範不是我編的，是昨天實際出現過的那一類。

needs_human 綁在分類上。 v1 讓模型自由判斷要不要轉人工，v2 直接寫死：intent 是 complaint、promo_coupon、other、return_refund 時為 true。這樣它就不需要「判斷」，只需要照表對應。

實測：同樣 20 封信

在昨天那 15 封之外多加 5 封：一封問有沒有賣濾掛包（FAQ 沒寫）、一封已開封想退貨、兩封客訴、一封要折扣。只換 system prompt，其他完全一樣。

v1b 錯的三個意圖都很典型：

一封信問了兩件事（「A10294 出貨了嗎？另外淺焙的豆子可以做冰滴嗎？」），v1b 判成 other。它遇到不乾淨的情況就往最模糊的那一類放，這也是 Day 09 給 other 這個出口時預期的副作用。更糟的是它接著捏造了兩筆事實，一筆是訂單狀態、一筆是「淺焙豆沖煮建議」，兩筆都被守門員擋下。

兩封客訴信，一封判成 return_refund、一封判成 order_status。客訴信通常都附帶一個具體問題（我的包裹在哪、我要退款），模型容易抓住那個問題而忽略情緒。

v2 這三封全部正確，而且一信兩問那封它派了兩次工：order_lookup 查到備貨中，knowledge 從 BEAN-02 查到淺焙豆適合手沖和冰滴。兩個問題都有答案，unresolved 是空的。

那句「判斷資訊夠不夠是專員的工作」

多轉人工從 4 封降到 1 封，最大功臣是這一句。

v1b 多轉的三封分別是：沒給訂單編號只說「上禮拜買的東西什麼時候會到」、包裹顯示 9/12 會到但今天 14 號還沒到、問有沒有賣濾掛包。三封的理由都是「資訊不完整」或「需要進一步確認」。

但這三封都不需要真人。沒編號可以用 email 查，查不到就回信請客人補；FAQ 沒寫濾掛包，W2 會老實回 not_found，回信照實說會再確認就好。主管在還沒派工之前就先替專員判斷「這題查不到吧」，然後直接放棄。

明確告訴它「這不是你的工作」，它就會先派工再說。v2 的派工總次數 22 次，跟 v1b 的 23 次差不多，但收下的事實從 49 筆變成 61 筆——同樣的派工次數，拿回來的資料多了四分之一，因為它派得比較對。

v2 違反了我寫的決策表

v2 的決策表白紙黑字寫著「complaint / promo_coupon / other 不派工」。

實際跑下來，兩封客訴信它都派了工。一封查了訂單也查了 FAQ 的瑕疵品政策，另一封查了訂單狀態和物流單號。只有那封要折扣的信（promo_coupon）真的沒派工。

我本來要把這個記成缺點，但想了一下覺得它做得對。客訴信最後會轉給真人處理，真人接手的時候手上有訂單狀態、到貨日、瑕疵品政策，比什麼都沒有好。不派工的理由應該是「這封信不該由 AI 回覆」，而不是「這封信不該查資料」——我把兩件事混在同一條規則裡了。

所以該修的是規則，不是模型。決策表那一列應該拆成兩件事：要不要派工、要不要由 AI 回信。前者看「有沒有資料要查」，後者看 needs_human。這個修正我留到 Day 18 做派工實作的時候一起改。

順手記一下，這種情況在實務上比「模型不聽話」常見得多：模型的行為跟規則不一致時，有一半的機率是規則寫錯了。

唯一那封意見不同的信

v2 只有一封轉人工跟標準答案不一樣：「訂單 A10299 怎麼變成取消了？我沒有取消啊」。

它查到訂單狀態確實是已取消，然後把「訂單 A10299 被取消的具體原因」放進 unresolved，標記需要人工。我的標準答案寫的是不需要人工。

說實話我覺得它判斷得比我合理。客人否認自己取消過訂單，而系統只查得到「狀態是已取消」，查不到誰取消的、什麼時候取消的，這種情況交給真人很合理。

但我沒有改標準答案。為了配合模型的輸出去改標準答案是很危險的習慣，改著改著就會變成「模型做什麼都是對的」。標準答案要改，應該是在定義評估集的時候想清楚，不是在看到結果之後。這題就留著當作一個已知的爭議點，Day 27 整理評估集的時候再處理。

代價

v2 的 token 中位數比 v1b 多 27%，主要是主管自己那一段：3383 變成 5094。prompt 從 20 幾行變成 70 幾行，每次呼叫都要重送。

20 封信跑完，v1b 總共 13.8 萬 token，v2 是 16.7 萬。換到的是意圖分類從 17/20 變 20/20、捏造事實從 2 筆變 0 筆。

這筆交易在客服情境我覺得划算，因為分類錯誤的代價是客訴信被自動回覆。但如果是內部工具、錯了再改就好的場景，v1b 那種短 prompt 可能就夠。

小結

主管的 prompt 重寫，四個改動：先定義成功標準、把派工規則寫成查表、禁止事項附錯誤示範、needs_human 綁在分類上而不是讓模型判斷。20 封信實測，意圖分類 17/20 變 20/20，多轉人工 4 封降到 1 封，守門員擋下的捏造事實從 2 筆變 0 筆，代價是 token 多 27%。另外 v2 違反了自己的決策表去派工查客訴信的資料，而我認為該改的是規則。

明天把派工做成三種不同的實作：AI Agent Tool、Switch 條件分支、Execute Workflow，用同一批信比較。