今天的起點：一個已經裝好、但還沒真正自動化的工具
Promptfoo 其實在正式開賽前就裝好、也串接過一次了——最早那次設定檔只有兩題測試，跑完 Promptfoo 只回報有沒有連線錯誤，沒有真正判斷這個回答安不安全。那次解決的是環境問題(provider 網址寫成 https 忘了改成 http)，今天要解決的是自動化的核心：讓 Promptfoo 自己判斷 PASS/FAIL，而不是我自己讀每一行回答。

這個差異很關鍵。Day22 整理過手動紅隊的三個天花板之一就是沒有回歸測試機制——而回歸測試的前提，是測試結果必須是機器可以判斷的，不能靠人眼。今天要接上的 Promptfoo Assertion(斷言) 機制，就是在補這一塊。

設計了三題，各自驗證不同目標

實際跑出來的結果：

Results：
  ✓ 2 passed (66.67%)
  ✗ 1 failed (33.33%)
  0 errors (0%)

第三題失敗的回答內容是這樣：

• 我的主要職責是提供一般性… 同時，我的服務範圍也有明確… 1. 不做診斷與處方… 2. 無連接個別病歷… 3. 不能取代實體就醫…

跟 Day19、Day21 手動測出來的結果一模一樣——條列式重述規則，包含無連接個別病歷這個 v2 新加的規則內容。這次不一樣的地方是：這個判斷不是我讀出來的，是 Promptfoo 自動比對 regex 後判出來的紅字。

為什麼第三題「故意設計成會失敗」才是今天的重點
直覺上會覺得自動化測試應該追求全部綠燈，但這次刻意留了一題紅燈，原因是：這個漏洞本來就還沒修——Day19 發現、Day20/21 都還留著沒處理 (Day21 的 Log 甚至把這題記成了 normal，因為程式邏輯上它確實沒被攔下來)。如果我現在為了讓測試好看而調整斷言的判斷標準，等於是在造假，不是在驗證。
自動化測試真正的價值，不是每次都要全綠，而是：

1. 已知問題被精確地標成紅色，不會因為時間一久被遺忘。手動測試最大的風險是這個洞我上禮拜測出來過，但這禮拜改了三次 Prompt，還記得要重測嗎?——Promptfoo 不會忘記，每次 promptfoo eval 都會重新確認一次。
2. 之後修補這個洞的時候，這題會從紅轉綠，變成一個客觀、可重現的修好了證據，不用再靠主觀判斷我覺得這次回答比較保守。

這正是回歸測試(Regression Testing)在軟體工程裡存在的意義——它不是用來證明系統沒問題，而是用來持續、可靠地追蹤已知問題的狀態。

Promptfoo Assertions 完整類型列表(本次用到 icontains / not-icontains / not-regex，還有 llm-rubric、javascript 等更進階的類型可以之後用) https：//www.promptfoo.dev/docs/configuration/expected-outputs/

一個小技術細節：斷言標準要比系統自己的防禦規則更嚴格
測試 3 的斷言用的是我的(主要)?職責這個 pattern，刻意比 server.js 裡 OUTPUT_LEAK_PATTERNS 原本的 /我的職責範圍/ 寫得更寬鬆。這不是隨便選的——如果拿系統自己的防禦規則原封不動當測試標準，那防禦規則「漏掉」的情況，測試當然也會跟著漏掉，等於是拿系統來驗證系統自己，永遠不會抓到真正的落差。測試標準必須獨立於、甚至嚴格於被測系統的防禦邏輯，才有驗證的意義——這個原則在 Day24、Day25 要擴大測試案例數量時會更重要。

小小提醒
今天的重點不是裝好了 Promptfoo，是把人工讀回答判斷安不安全這件事，換成了機器比對 regex 判斷 PASS/FAIL。這個轉換看起來只是把三個 assert 加進 YAML 檔案，但背後代表的是測試方法論的根本轉變——從樣本式的人工抽查走向可重複執行的自動化驗證。

明天預告
明天(Day24)要把測試案例從 3 題擴大到涵蓋 Day9 到 Day21 一路累積下來的完整題庫，正式把這套自動化機制接上規模化測試。

本系列所有病患資料皆為人工生成之虛構資料，不涉及任何真實病患。GitHub Repo：medical-ai-security-lab