範例規格

提示詞清楚，結果卻偏了

你請 Claude Code 或 Cursor 修改一段邏輯，它很快回報完成，測試也跑過了。

但細看之後，商業規則被改成你沒想到的樣子。

問題通常不在 Agent 有沒有執行，而在需求的驗收邊界仍有解讀空間。Agent 只能自己猜。

範例規格用具體案例鎖定驗收邊界，讓 Agent 不必猜。

範例規格的四個組成

範例規格是實例化的需求：不用形容詞描述，而是列出具體案例。

每組案例包含四種資訊：輸入條件、預期結果、不可接受的結果，以及邊界案例。

前兩者定義「正確長什麼樣」。後兩者劃出「哪裡不能越界」。

少了任何一種，Agent 就可能在空白處自由發揮。

實例：把一句需求展開

假設需求是「訂單滿 1000 元打九折」。看似清楚，其實留下許多問題。

剛好 1000 元算不算？999 元呢？Agent 若自行判斷，結果可能各不相同。

寫成範例後：1200 元應得 1080 元；1000 元也打折，得 900 元；999 元維持原價。

若 999 元被打折，就是不可接受的結果。每條都有明確答案，你也能逐條核對。

偏離多半藏在邊界

多數偏離都發生在邊界：剛好達標、空值、例外情境。

提示詞通常只描述正常情況，Agent 便用自己的常識填補邊界。它的常識未必是你的商業規則。

明確寫出不可接受的結果也很重要。

它告訴 Agent 哪些看似合理的做法其實是錯的。

修改前對齊，完成後驗收

範例規格在流程中用兩次。

修改前：先把範例交給 Agent，讓它在寫程式之前就對齊行為預期。

完成後：拿同一組範例逐條檢查。符合才算完成；不符合就帶著失敗的範例請 Agent 修正。

這樣一來，「看起來完成」不再是驗收標準。

重點整理

下次給 Agent 任務前，先問：這個需求有沒有解讀空間？

若有，就寫出輸入條件、預期結果、不可接受的結果與邊界案例。

完成後逐條比對範例，不符合就帶著失敗案例回修。

範例讓 Agent 不必猜，也讓你有依據判斷結果是否真正符合需求。

Agent 產出的程式能執行，邏輯卻偏離預期，問題通常出在_____

• 需求的驗收邊界仍有解讀空間
• Agent 根本沒有執行指令

答案: 需求的驗收邊界仍有解讀空間

Agent 多半有照指令執行，真正的問題是需求中的驗收邊界不夠明確，留下解讀空間，Agent 只好自行猜測。改善方向是讓規格更具體，而不是懷疑 Agent 沒做事。

撰寫範例規格時，_____描述 Agent 會收到哪些資料，_____描述這些資料應產出的行為，_____則涵蓋極端值或例外情境。

答案: 撰寫範例規格時，輸入條件描述 Agent 會收到哪些資料，預期結果描述這些資料應產出的行為，邊界案例則涵蓋極端值或例外情境。

範例規格用具體例子取代抽象描述：輸入條件說明「給什麼」，預期結果說明「應得到什麼」，邊界案例說明「極端或例外時該怎麼處理」。三者齊備，Agent 才不必猜測。

你想請 Cursor 實作「消費滿額打折」功能。下列哪一種寫法最能讓 Agent 遵循並驗證？

• 金額 1000 → 打九折為 900；金額 999 → 不打折；金額為負 → 回傳錯誤
• 消費達到一定金額時給予適當折扣，並處理好各種特殊狀況
• 請依照一般電商的常見做法實作滿額折扣，邏輯要合理
• 實作滿額打九折功能，程式要乾淨並盡量涵蓋所有情況

答案: 金額 1000 → 打九折為 900；金額 999 → 不打折；金額為負 → 回傳錯誤

只有具體數值的範例才能被驗證：剛好 1000、差一元的 999、以及負數這種例外都清楚定義結果。「適當」「合理」「盡量」等字眼仍留有解讀空間，Agent 只能自己猜。