AI 寫得太多？先刪，再交差：把改動縮到能解釋、能驗證

AI 一口氣改了十個檔案，你卻只要修一個錯？最麻煩的往往不是它少寫，而是它順手多做：換命名、抽共用層、補一個目前沒人呼叫的介面，最後把真正要修的地方埋進一大片修改。

面對這種成果，先別用新增行數判定工作量，也別用刪除行數判定品質。更實用的問題是：這一段留下來，究竟讓哪個已確認的需求成立？如果說不清，先把它移出本次改動，而不是替它補一個想像中的未來用途。

pstack 的方向是減少負擔，不是保證變快

截至 2026 年 10 月 19 日查核，Cursor 的公開 plugins 儲存庫收錄 pstack。其 README 將「更少、品質更好的程式」作為目標。這是作者對工具的定位，不是同條件效能實驗，也不能推導成每個專案都會少花工時。

以下借用其中幾個公開工程原則，整理成一份改動刪減方法。原則文件可供閱讀，不代表需要先安裝整套工具，更不代表外部工具能取代既有的權限、審查或部署規範。

第一刀：刪掉沒有當前用途的新增負擔

先減再加原則主張先移除多餘複雜度，再建設；也提醒不要為尚未出現的情境預先堆檢查或解析層。

把它用在日常改動，可以先把每一項新增內容配回需求。需求只說搜尋欄清空後恢復完整清單，就不必同時引入另一套搜尋服務。若 AI 想順便整理所有列表頁，先拆成另一件事，等有理由與驗收條件再做。

這裡的「多餘」有前提：已確認沒有必要用途。不能因為程式看起來重複，就刪掉權限判斷、外部輸入檢查、交易保護或相容契約。刪除同樣要說清楚影響範圍；不確定是否有人依賴的內容，先查證，而不是先刪再等別人報錯。

第二刀：少一層，不是只少幾行

降低閱讀負擔原則把焦點放在兩件事：讀者要追多少層，腦中要記多少隱藏狀態。程式行數只是一種間接線索。

例如一個包裝函式只是把相同參數原封不動傳下去，卻讓人多開一個檔案才能找到真正邏輯，它可能沒有帶來足夠價值。反過來，一段較長但資料流清楚的程式，不一定比拆成許多小函式更難懂。

實務上先問「這個值從哪裡來、誰會改它」。若必須跨好幾個沒有新增意義的包裝層才答得出來，可考慮合併。若問題來自多人共享的狀態，單純把檔案攤平並不會消除負擔。抽象是否值得保留，要看它藏住了哪些真實決策，而不是名字有沒有專業感。

一張改動刪減表，先把理由列出來

下表是本文整理的檢查建議，不是 pstack 的實測結果，也不是任何專案的強制規則。

這張表不是要求每次修字都交報告。它的用途是讓有風險的決定可見：新增或刪除的內容愈靠近共用狀態、外部介面或權限邊界，就愈不能只靠「感覺比較乾淨」。

假想情境：搜尋欄清空，列表卻沒有恢復

以下純屬教學假想，沒有實際執行 pstack，也不是客戶案例。假設使用者輸入關鍵字後看到篩選結果，刪掉文字時卻仍留在舊清單。AI 提出三種改動：修正空字串處理、新增一個通用搜尋管理器、順便重新命名其他頁面的函式。

可以先保留與錯誤直接相關的處理，再確認既有資料來源與狀態更新方式。若目前沒有第二個使用情境，也不需要搜尋管理器才能解決問題，就先移出那項新增；其他頁面的命名更不必綁在這次修錯一起驗收。

接著從使用者真的操作的入口驗證：輸入關鍵字時只顯示符合資料，清空後恢復原清單。測試應根據需求準備已知資料與預期答案，而不是把程式目前產生的結果抄成標準答案。這樣才不會讓錯誤與測試一起自我證明。

刪到最後，驗證不能一起被刪掉

測試行為而非實作原則區分使用者能觀察到的結果，與內部函式怎麼安排。判斷一份測試是否有用，可以想兩種改動：故意讓結果錯誤時，它會不會失敗？只重整內部、結果不變時，它是否仍通過？

搜尋例子的重點不是一定呼叫某個私人函式，而是符合資料顯示正確，清空後也恢復正確。不過外部服務收到什麼請求，本身可能就是服務能觀察的行為；不能把所有呼叫檢查一律當成沒有價值。

直接驗證產物原則則提醒，不能只因助手說完成或編譯成功，就推定真正結果成立。適合的檢查能寫成可重跑腳本，留下輸入、結果與限制；一次操作成功，仍不能保證所有裝置與情境都沒問題。

交差前，用三句話說清楚

第一，這次解決哪個已確認的問題？第二，哪些順手改動被刻意移出，以及哪些必要檢查仍保留？第三，下一個人能用什麼方式重跑，確認相同行為成立？

如果答案只剩「AI 寫好了很多東西」，就還沒有交代成果。值得留下來的改動，不一定最短，但應該每一部分都有理由，而且讓驗證更容易，而不是把更多猜測留給下一個人。

查核日期：2026-10-19。本文為公開文件整理與作者建議；未執行工具安裝、真實專案測試、速度或成本比較，也不保證任一刪減方案適用所有系統。

參考：pstack README。各原則文件已在對應段落直接連結。