🎯 什麼情境該想到我
當你叫 agent 改一個小地方，結果 diff 裡一半是它「順手幫你改好」的東西的時候。
⚙️ 怎麼用（步驟 / 公式）
一句話規則：只碰你非碰不可的，只清理你自己製造的髒東西。
改既有程式碼時
- 不要「改善」旁邊的程式碼、註解或排版。
- 不要重構沒壞的東西。
- 配合既有風格——即使你會用別的寫法。
- 看到無關的死碼，用講的、不要動手刪。
你的改動製造出孤兒時
- 移除因為你的改動而變成未使用的 import／變數／函式。
- 不要移除本來就存在的死碼，除非有人叫你刪。
⭐ 驗收判準（很好用）
每一行被改動的程式碼，都要能直接追溯到使用者的要求。
review 自己或 agent 的 diff 時逐行問這句，答不出來的就該還原。
怎麼把它落到 agent 上
把上面幾條寫進 CLAUDE.md／skill，並附那句判準。重點是要明確禁止「順手改善」——多數 agent 的預設傾向是主動幫忙，不講它不會停。
🧪 我實際套用的紀錄
- 2026-09-08：（待填）
⚠️ 注意 / 什麼時候不適用
- 這是紀律不是原則：如果你明確要求重構或統一風格，那就該做——它禁止的是未經要求的順手改動。
- 「看到死碼用講的」有個前提：agent 要真的講。沒有這條，你會失去它幫你發現問題的價值；有這條但它不講，你就兩頭空。驗收時留意它有沒有回報。
- 配合既有風格會累積技術債。長期而言仍需要有計劃的統一，只是那該是獨立的一次改動，不該混在功能修改裡。
- 它會讓 diff 變乾淨，但不會讓設計變好。乾淨的 diff 只是讓 review 看得懂，設計品質是另一回事。
🔗 相關工具
- 工具-把命令變成可驗證的目標 —— 同一份來源的另一條原則
- 工具-小步重構 —— 重構要做，但要當成獨立的一步做，不要混進功能改動
- 工具-影響分析 —— 「這行改動會影響到哪」的判斷；知道範圍才知道哪些非碰不可