談 AI coding tools 的 anti-pattern，網路上能找到的清單通常是「盲信 AI 不 review」「context 爆」「沒 test 先讓 AI 改」這幾條。這些都對，但都太顯眼了——只要你做過一陣子工程師，遇到一兩次都會學乖。
真正吃人的 anti-pattern 是另一類：commit 看起來正常、PR review 看起來通過、進 code 才發現架構被動到很亂。
這篇分兩層講。第一層是大家都會講的顯眼 anti-pattern；第二層是我親自踩過、其他人覺得還好但我覺得是地雷的隱形 anti-pattern——這層才是 AI coding tools 真正的危險地帶。
第一層：顯眼的 anti-pattern
這些是任何「AI coding pitfalls」清單都會列的。我都遇過、都同意。簡單帶過：
- 盲信 AI 輸出不 review——AI 會 hallucinate，會編 API、編 import path、編 type signature。不 review 就 commit，bug 等你一週後才發現。
- 一次塞整個 codebase 進 context——context 爆、模型注意力稀釋、回應品質崩盤。
- 沒 test 先讓 AI 改——AI 改完你不知道哪裡壞了，因為原本就沒 baseline。
- Agent mode 直接跑 prod——你不會知道哪個指令會爆。
- IP 敏感 repo 走 cloud provider——code 上傳到 third-party 才驚覺 retention policy 沒讀。
- Copilot / Cursor / Claude Code 同時開混亂——三個工具同時改同一份 code，誰改的最新都搞不清楚。
這些是「entry-level pitfalls」。讀過就知道、踩一次就學乖。
第二層：隱形 anti-pattern（這層才是真的痛）
下面這幾個是 commit 看起來都正常、PR review 也通過——進 code 才發現有問題。
架構位置錯
新 feature 的程式碼放錯地方。該在 service layer 的邏輯被 AI 寫進 controller、該在 repository 的 query 被寫進 service、該抽 module 的東西散在好幾個地方。
單看 PR 沒問題，因為「這段 code 確實 work」。整體看才會發現架構漂移。
不延續先前 pattern
專案有 pattern——例如「所有 API response 走同一個 wrapper」「error handling 統一在 middleware」「permission 走 decorator」——但 AI 寫新 feature 時不延續，自己搞一套。
PR review 看不出來，因為「自己搞的這套也 work」。直到下個 month 你 review 第三個類似 feature，發現每個都有自己的 pattern，整個 codebase 變花園。
判斷先前 pattern 判斷得很奇怪
更詭異的版本——AI 看到先前的 pattern 但「擴充得很怪」。例如：
- 既有 BaseService 但 AI 不繼承，反而抄一份
- 既有 helper function 但 AI 寫一個 80% 一樣的新 helper
- 既有 hook 但 AI 在組件內 inline 一個一樣的邏輯
PR 看起來都正常。但你已經有兩三份做同一件事的 code 散在不同地方。
該 DI 沒做 DI
依賴硬綁。Service 直接 new Repository() 而不是 constructor inject、設定值寫死在 class 裡而不是從 config、test 寫不出來因為 dependency 沒法 mock。
短期看 code work，長期看 test coverage 不上來、維護成本指數成長。
已經抽共用但是沒有續用
有 utils/、有 shared/、有 base class——但 AI 不知道，或知道但不用。新 code 把同樣邏輯重新寫一份。
review 看不出，因為新寫的也 work。直到下次有人改原本 utils 裡的邏輯，發現有三個地方在做一樣的事，但都散在不同檔案。
「work 但不好維護」
上面這些 anti-pattern 加起來，最終都是同一個現象：code work，但不好維護。
這個是 AI coding tools 最致命的地方——AI 的 reward function 是「produce working code」，不是「produce maintainable code」。如果你 review 時只 check「這個 PR 解了 task 嗎」，AI 永遠及格；如果你 check「這個 PR 後我們的 codebase 變更好或更糟」，AI 經常不及格。
為什麼這層 anti-pattern 最痛
我自己親身遇過——我看到問題，知道怎麼解、知道留著會出什麼事，但其他人覺得還好。
「但其他人覺得還好」是這層 anti-pattern 致命的原因：
- 表面指標都通過：lint pass、test pass、PR review approve
- 問題只有「對 codebase 整體有 mental model 的人」看得到
- 對沒 mental model 的人來說，「指出問題」會被當成「你太挑剔」
這個跟團隊的認知層級有關（詳見 AI06 #12）。如果團隊裡只有你看得到 architecture-level 的 drift，你 raise 出來不會有共識——大家會覺得「commit 都過了你還在 block 什麼」。
老手 vs 新手會犯的差別
第一層的顯眼 anti-pattern：新手才犯。寫個半年到一年就會學乖。
第二層的隱形 anti-pattern：老手都還在犯。原因是這層需要「對整個 codebase 有 mental model + 主動 architecture review」這兩個前提。AI coding tools 進來之後，產出速度變快，但 mental model 跟 architecture review 的時間沒變多——結果就是顯眼 anti-pattern 變少（被 AI 工具的 best practice 提示過濾掉），隱形 anti-pattern 變多（因為產出量大、但 review 深度沒跟上）。
老手不是看不出來。是寫的人有 deadline、review 的人有 PR queue，沒人有時間每次都做 architecture-level review。
修正後對效率提升最大的習慣
我自己修正最有感的習慣是：
進每個 PR 之前，先想一句「這個 code 在 codebase 裡的位置對嗎」。
不是 review code 的細節，是 review code 的「位置」——這段 code 該不該放這裡？是不是已經有類似的 pattern？跟既有架構有沒有衝突？
這個問題只要 30 秒就能問完，但能擋掉 70% 的隱形 anti-pattern。剩下的 30% 需要對 codebase 有更深的 mental model 才看得出來——那層只能靠長期經營。
反思一句話
commit 通過不代表 code 健康；PR approved 不代表 architecture 健康。
AI coding tools 不會修架構，AI 修的是「這個 task 的 code 寫法」。架構是長期累積的判斷，需要你自己去做——AI 給不了你那層。
當你看得出隱形 anti-pattern 但其他人覺得還好的時候，問題已經不在程式碼本身了。