反面案例提示（Negative Examples）
「不要做 X」比「請做 Y」更精確。讓 AI 知道什麼不能做比該怎麼做更降低出錯率。
對照範例
❌ 正面規範（容易誤會）
請使用 Fixture 管理測試資料
→ Claude 可能還是寫 hardcode（覺得「這個簡單例子不需 Fixture」）
✅ 反面案例（更有效）
不要將測試資料 Hard Coding
→ Claude 一定避開，看到 hardcode 念頭就警鈴大作
為什麼有效
LLM 擅長模式辨識與避開禁令。明確的「禁忌」比模糊的「請使用」訊號更強：
- 「請避免 X」= 二元判斷（有沒有 X）
- 「請用 Y」= 連續判斷（夠不夠 Y）
二元判斷更可靠。
配合「說明為什麼」效果加倍
✅ 進階版：
不要將測試資料 Hard Coding。
理由：團隊已用 Fixture 管理機密資料，Hard Coding 會讓 secret 進 git。
帶 Context 後，Claude 在遇到 edge case 時有判斷依據，不會死板執行規則。
對 PAM CLAUDE.md 的應用
PAM 主規格已有「禁忌」段：
## 禁忌
- ❌ 拼接 SQL（"WHERE name = '" + n + "'"）
- ❌ Controller 吞例外
- ❌ 各處重寫等第公式（一律呼叫 GradingService）可以再加「為什麼」：
- ❌ 拼接 SQL —— EF Core 已支援 parameterized query，拼接會 SQL injection
- ❌ Controller 吞例外 —— 全域 ExceptionFilter 已處理，吞掉導致追蹤困難
- ❌ 重寫等第公式 —— 多處同步 bug 風險，已重構至 GradingService 為單一來源跟 Few-shot prompting 結合
Few-shot 同時給正反例最有效：
分類客戶評論為「正向 / 負向 / 中性」：
範例 1（正向）：「服務超棒，會再來」 → 正向
範例 2（負向）：「等了 1 小時還沒上菜」 → 負向
範例 3（中性）：「東西普通」 → 中性
❌ 不要把「東西很普通」分為負向（沒有明顯不滿）
❌ 不要把「我老婆也想吃」分為正向（沒有評論主菜）
反例幫 Claude 避開常見誤判。
應用清單
何時該用反面案例：
- ✅ 撰寫 CLAUDE.md（專案手冊） 時，禁忌段比規範段更易執行
- ✅ Code review prompt（找出不該有的東西）
- ✅ 內容審核（找出不該出現的詞）
- ✅ 程式 lint 規則（明確的「不」清單）
- ✅ Rules Directory 的 description——明確說「這個 rule 不適用於 X」
配合 上下文壓縮 的注意事項
長對話 + 上下文壓縮會丟資訊——禁忌規則更該寫在不會被壓縮的層：
✅ 寫在 CLAUDE.md（不被壓縮，永遠生效）
✅ 寫在 Rules Directory（按情境啟用）
❌ 只在對話一開始說過 → 後期可能被壓掉
→ 紅線級規則寫進專案層級檔案，不依賴對話記憶。
相關概念
強連結（原文明確提及）
- Few-shot prompting — 正反例混合
- XML 標籤提示 — 用
<dont>標明禁忌 - CLAUDE.md（專案手冊） — 寫法影響 AI 表現
- CLAUDE.md 4 層機制 — 規則放對層級才不被壓掉
- Rules Directory — 條件式規則啟用
- 上下文壓縮 — 設計禁忌時要考慮壓縮影響
- Self-check — 完成後自我檢查違反禁忌
深入閱讀（外部資源）
- 深入閱讀：04-進階提示技巧
← 回到 wiki