為什麼前端團隊應該停止把 AI 當成重寫機器

前端團隊應該停止把 AI 當成重寫機器，改把它當成受限編輯器。

理由很直接：現在最有價值的 AI 能力，不是把穩定程式碼整段翻新，而是把必要的改動縮到最小。Habr 的一則技術摘要提到，研究者在 400 個 BigCodeBench 任務上觀察到 code assistant 的「過度編輯」現象，並發現只要在提示中加入「保留原始程式碼」這類約束，多數模型就會明顯減少不必要的變動。這不是小細節，而是前端工程的核心問題。前端最怕的從來不是改不動，而是改太多，把原本只需要一行修補的地方，變成一個新的 bug 來源。

第一個論點：重寫會破壞前端最依賴的東西，也就是局部可預測性

前端程式碼看起來常常很短，但短不代表簡單。一個只有 40 行的 component，可能同時包含版面行為、無障礙屬性、事件順序，以及框架特定的假設。當 AI 助手把一個精準 patch 擴寫成更大的 refactor，它改變的不只是語法，而是團隊對這段 UI 的心智模型。Habr 摘要裡另一個關於 JavaScript chain call 的觀察也指向同一件事：chain 一旦拉長，閱讀與除錯成本就會上升。AI 式重寫也是如此，它把變動擴散到更多行、更多分支、更多命名，最後讓 review 比原始 bug 更難。

那篇被摘要引用的研究之所以重要，是因為它不是憑感覺說「AI 太愛亂改」。研究量化了 token-level Levenshtein distance 與 cognitive complexity，樣本是 400 個任務。這種量化對前端團隊特別有意義，因為我們每天都在處理 diff 品質。修一個 button state、調一條 validation rule、改一個 hook dependency，本來都應該是小範圍變更；如果 AI 回傳的是 helper 重命名、guard 重排、再加三個 null check，那就不是幫忙，而是在製造 review 成本。更好的做法不是叫模型「想辦法重構」，而是要求它守住原本結構，只做必要修補。

第二個論點：真正有效的 AI 用法本來就該是受限任務，而且表現更好

看同一則摘要裡其他案例，就能看出方向。wasm-xlsxwriter 的價值，不在於它「很聰明」，而在於它把一件明確的工作移到瀏覽器與 Node.js 端，邊界清楚：產生 .xlsx 檔，僅此而已。Cloudflare 的 Agent Readiness Score 也是同樣思路，它檢查的是可發現性、content negotiation、access control 與 capabilities，並對照 robots.txt、Markdown fallback、API catalog support 等具體標準。它不是叫系統「把網站變好」，而是驗證特定屬性。前端 AI 也應該長這樣：輸入要窄，輸出要窄，成功標準要可測。

效能面也支持這個結論。摘要提到 Cloudflare 文件在調整到新標準後，使用 Kimi-k2.5 搭配 OpenCode 的 agent 回答技術問題，速度快了 66%，token 用量少了 31%。這種提升來自結構，不來自自由發揮。當輸入空間被整理好，agent 就更便宜、更準確；當輸入空間混亂，它就會自信滿滿地產出一大段冗長改寫。前端團隊應該學的是這種結構化思維：把任務限制住，定義輸出格式，衡量結果。AI 很適合用在 code review 輔助、test generation、文件遷移、機械式小修補；不適合用在「幫我把這段改好」這種會默默引發設計漂移的寬鬆指令。

反方可能怎麼說

支持 AI 當重寫機器的人，最強的論點是速度。資深工程師看到一個 component，常常能直接判斷哪裡該拆、哪裡該抽、哪裡該簡化；AI 也能模仿這種模式，替重複性工作省下時間。對大型前端 codebase 來說，確實有不少地方本來就脆弱、重複、耦合過高。如果工具真的能把模組重寫成更乾淨的形狀，團隊看起來像是同時拿到更好的 code 和更快的 delivery。

這個說法不是假的。它在 code 已經隔離、測試很強、而且團隊本來就準備 refactor 的情境下，最有說服力。問題是日常產品開發大多不是這樣。日常任務的目標不是優雅，而是安全變更。前面提到的研究已經把方向講得很清楚：廣泛編輯會增加 cognitive load，而明確要求保留原始程式碼，則能減少 churn。界線應該畫在這裡：可以讓 AI 提出 refactor 建議，但不要讓它在沒有約束的情況下直接執行。只有當這本來就是一張 refactor ticket，且測試、review 時間都已經安排好，才值得接受較大的重寫。一般前端修補，助手就該待在 edit mode，不該進入 transformation mode。

你能做什麼

如果你是工程師，立刻改 prompt 和 review 習慣：要求模型保留結構、非必要不要改名、只碰最小範圍。如果你是 PM，不要用輸出看起來多戲劇化來衡量 AI 成功，而要看 escaped defects、review time、rollback rate。如果你是創辦人，投資 workflow integration，不要追求 demo 友善的魔法。前端真正會贏的 AI 工具，不會像自動重寫機器，而會像守規矩的編輯器，尊重既有程式碼、既有標準、既有意圖。這樣它才是在降低風險，而不是製造風險。