昨日回顧

Day 3 用三個問題分清 prompt、skill、subagent 與 MCP。確定「這件事值得做成 skill」之後，先別急著寫 SKILL.md。今天先寫規格：它負責什麼、不負責什麼，以及遇到風險時必須停在哪裡。

為什麼先寫規格

沒有規格的 skill 很容易走向兩個極端：

1. 太窄：只會處理範例裡那一句話，換個問法就失效。
2. 太寬：什麼都想管，最後觸發混亂，還可能做出超出授權的動作。

好規格不是把功能寫得很長，而是把邊界寫得可判斷。看完規格，另一位開發者應該能回答：「這個案例算不算它的工作？」

第一步：用一句話定義工作

先寫一個不帶實作細節的任務句：

檢查使用者提供的演唱會售票連結，判斷它是否屬於已確認的官方售票管道，並說明判斷依據。

這句話有四個零件：

• 輸入：使用者提供的售票連結
• 動作：檢查與判斷
• 輸出：官方、未確認或資訊不足
• 證據：說明判斷依據

「幫粉絲安全買票」就不是好規格。它聽起來很好，但可能包含找票、比價、登入、付款、轉售與退款，範圍完全失控。

第二步：列出 in scope 與 out of scope

In scope

• 解析網址與正規化域名
• 對照維護中的官方來源清單
• 檢查常見仿冒特徵，例如拼字相近的域名
• 回報判斷結果與證據
• 資訊不足時要求必要的補充資料

Out of scope

• 保證一張票一定有效
• 推薦黃牛或非官方轉售管道
• 代替使用者登入或付款
• 從網頁外觀推測可信度
• 在沒有證據時把「未確認」說成「詐騙」

Out of scope 不是功能缺陷，而是安全設計。它讓 skill 知道什麼時候該停，也讓後面的測試有明確邊界。

第三步：把護欄寫成可執行規則

「小心詐騙」不是護欄，因為每個人對「小心」的理解不同。改成可以被測試的 if/then 規則：

1. 如果域名完全命中官方清單，回報「官方來源」，並附上清單中的對應紀錄。
2. 如果域名沒有命中，但出現可疑仿冒特徵，回報「未確認，具有風險訊號」，列出訊號，不直接定罪。
3. 如果連結無法解析，停止判斷並請使用者提供完整網址。
4. 如果證據互相衝突，回報「無法確認」，不要猜。
5. 不執行登入、付款或購票；這些動作需要不同流程與明確授權。

好的護欄包含三件事：觸發條件、允許的回應、禁止的動作。

第四步：先定義結果格式

固定輸出能讓人讀，也能讓程式驗證：

判斷：官方來源｜未確認｜資訊不足
檢查對象：example.com
依據：命中的清單紀錄或風險訊號
下一步：可以繼續｜補完整網址｜改走官方入口

這個格式故意沒有「安全」兩字。官方域名能證明管道來源，不能保證每一張票、每一筆交易都沒有其他問題。規格中的字詞也要守邊界。

第五步：用反例壓測範圍

寫完規格後，先丟五種案例：

1. 完整的官方網址：應該能確認。
2. 少一個字母的仿冒域名：應該標示風險訊號。
3. 只有截圖、沒有網址：應該要求補資料。
4. 官方網站上的第三方付款頁：來源與付款風險要分開說。
5. 使用者要求「直接幫我買」：應該停止在判斷，不跨進交易。

如果每個案例都能得到唯一、可預期的處理方式，規格才算接近完成。如果兩位讀者會做出不同決定，就要把那條邊界再寫清楚。

規格卡：一頁就夠

開始實作前，我會先填這張卡：

名稱：ticket-guard
一句話任務：
輸入：
輸出：
In scope：
Out of scope：
護欄：
資訊不足時：
成功標準：

它不取代 SKILL.md。規格先決定「要造什麼」，SKILL.md 再描述「agent 怎麼做」。把兩件事分開，後面寫腳本、references 與 eval 時才不會一直改方向。

明天預告

Day 5 把這張規格卡填完，完成演唱會購票安全檢查 skill 的需求設計。接著從 Day 6 開始真正建立目錄與第一版 SKILL.md。