AI 程式碼品質把關：diffdiet 如何限制 AI 代理的程式碼膨脹

當你要求 AI 程式碼代理修復一行問候語的錯誤時，你知道會發生什麼：它確實修好了，但同時也帶來了一堆「朋友」。一個新的模組、一個框架、四個抽象層，以及一個全新的依賴項。修復本身是正確的，但程式碼庫卻要永遠為此付出代價。

這種程式碼膨脹是 CI 系統無法檢查到的失敗模式。測試通過、程式碼風格檢查通過，而審閱者在面對一個本應只有五行變更，卻長達四十行的差異檔案時，眼睛都花了。因此，我開發了 diffdiet，這是一個針對 AI 程式碼代理的最小化差異守衛工具，它包含兩個部分。

首先是一個規則包，用於指導 AGENTS.md、CLAUDE.md 或 SKILL.md 等代理：在建立前先編輯、不使用一次性抽象、標準函式庫工作不新增依賴項，以及刪除無用程式碼而非註解。其次是一個測量工具，這是一個零依賴的 Python 命令列介面，它能解析統一的差異檔案，並以透明的 0–100 分數來評估，同時在 CI 中強制執行預算限制。這個評分沒有隱藏權重，你可以手動重新計算任何分數。

相同的問題，兩種不同的變更。這個儲存庫提供了兩種修復一個微小問候語錯誤的版本，你可以自己執行這個守衛工具來測試：執行 diffdiet check --diff examples/lean.diff 會通過，而 diffdiet check --diff examples/bloated.diff 則會失敗。精簡版獲得 100/100 分並通過，臃腫版則獲得 57/100 分並失敗。

精簡版只提取了一個小小的 greet() 函式，增加了五行程式碼，就完成了。臃腫版則用一個新的 greet_framework.py、一個抽象策略基底、一個帶有快取的模板引擎、一個策略註冊表，以及一個全新的 fancylib 依賴項來完成同樣的工作。

守衛工具對臃腫版差異檔案的判決是：程式碼精簡分數 57/100，扣分項目包括：新增行數 -5 (x57)、新增檔案 -8 (x1)、新增依賴項 -10 (x1)、抽象嫌疑 -20 (x4)。

其中，「抽象嫌疑」規則是我最喜歡的：任何在差異檔案中定義的函式或類別，其名稱在整個差異檔案中只出現一次，也就是說，只定義卻從未被使用。這就是經典的一次性抽象，可以透過機械化方式捕捉，而不是依賴疲憊的審閱者。你可以將它整合到 CI 中，例如執行 git diff origin/main...HEAD > change.diff，然後再執行 diffdiet check --diff change.diff。

預設的預算限制是：最多新增 300 行程式碼、最多 3 個新檔案、0 個新依賴項，以及最低分數 60 分，所有這些都可以在 .diffdiet.json 中調整。重點並不是懲罰大型變更，一個真正的大型功能可以在同一個 PR 中提高自己的預算。

重點在於，代理（和人類）必須證明其變更規模的合理性，而不是讓規模悄無聲息地成為預設。這與我早期工具背後的理念相同：whoapproved 審核代理做了什麼，cagerail 限制交易代理能做什麼，而現在 diffdiet 則限制代理為了完成任務能增加多少程式碼。主題是「護欄」，而非「禁止」，讓代理工作，但要讓過度行為的成本變得可見且可強制執行。

儲存庫連結：https://github.com/jacelovehaha/diffdiet，採用 MIT 授權，零依賴，Python 3.10+。試試這兩個範例差異檔案，然後告訴我你最近有哪些代理的 PR 會被這個守衛工具拒絕。