同樣用 AI 寫 code，差距為什麼越拉越開？

前幾天公司同事傳了一段訊息給我：

不好意思再問一個問題，想請教一下在現代 AI 發展的當下，如何成為資深前端工程師？感謝你撥空回答。

我當下回了「沒有標準答案」加幾點通用想法——基本功、判斷力、side project、觀察力——這些上一篇 AI 時代務實派工程師講過。但送出之後我想到另一件比「怎麼變資深」更具體、現在就觀察得到的事：

同樣用 AI 工具寫 code，每個人的產出已經拉開兩個量級了。

這篇就寫這個現象，三個我看過的具體失敗模式，跟我覺得真正的差別在哪。

工具一樣，差距來自習慣

現在每個團隊裡，每個人都在用 AI——Cursor、Claude Code、Codex 之類的。表面上做的事一樣：打 prompt、收 code、送 PR。但開出來的 code 品質差很多。

跟誰付費 plan 比較高、誰 prompt engineering 課上得多都沒關係。差別在更根本的層：你打開那個工具的時候，腦袋處在什麼狀態。

下面三個 anti-pattern 是我抽象化後的常見模式，不針對任何特定對象。如果你看了覺得眼熟，每個團隊都有類似版本。

Anti-pattern 1：滿足字面，漏掉意圖

PM 說：「在登入失敗的畫面加一個『忘記密碼』的連結。」

實作的人叫 AI 做完之後上線，那個 link 放在頁面最底部、淺灰色、跟 footer 的 copyright 文字同色同字體。技術上「link 加了」這個條件滿足了，所以 engineer 覺得做完了。

但實際 use case 是使用者剛剛登入失敗、正在找補救方法。這個 link 應該是 primary action：螢幕中央、明顯顏色、按鈕樣式。

AI 沒做錯——它忠實完成了 prompt 描述的任務。問題出在實作者沒停下來問：「這個連結是要解決使用者什麼處境？」只要停一秒，就會注意到 discoverability 比「功能存在」更重要。

更精準一點的 prompt 是：

在登入失敗畫面加一個「忘記密碼」的 primary action。
使用者剛失敗，需要明顯看到下一步該怎麼做，所以樣式要醒目、
位置要靠近主要視線，不能藏在 footer 區。

多花 5 秒寫 context，AI 給的就是另一個東西。「描述任務」跟「描述意圖」差距很大。前者 AI 永遠完成得很完美，後者你不寫，AI 永遠補不出來。

Anti-pattern 2：機械式 rename，看不到語義層次

同事提醒：「前端跟後端 API 溝通用 userId 欄位就好，不要用 username，username 會重複。」

實作的人把這段話丟給 AI：「幫我把 username 改成 userId。」

結果 UI 上所有「Username」的欄位標題、form 的 placeholder="Enter your username"、帳號設定頁面的「Change your username」按鈕，通通變成了「UserId」、「Enter your UserId」、「Change your UserId」。

AI 忠實執行了 prompt。但原意其實是兩件事被混在一起：

資料合約層：API request payload 用 userId 當 identifier
UI 顯示層：使用者看到的標籤還是「Username」、「使用者名稱」

這兩層不應該被同一次 rename 串成一件事。原始 prompt 沒有區分這個差別，AI 也沒辦法自己推論出來——它只能照字面改。

這個 anti-pattern 的真正成因，是實作者沒有意識到「資料」跟「呈現」是兩個不同的層。在沒用 AI 的時代，這種錯誤會在你手動改 code 的時候被察覺：「等等，我要改 <label> 裡面的字嗎？應該不用吧。」AI 把全部一起改完之後，這個內建的 friction 就消失了。

Anti-pattern 3：快照當規則，當下可以跑、下週就壞

有些人會寫一些「自動化小工具」來省事。我看過有人做「自動產生 CRUD boilerplate」的 script，邏輯是「找到檔案中 const routes = [ 的那一行，讀下面 N 行，在第 X 行插入新內容」。

當下那個檔案長那個樣子，跑得動。下週誰在那個 array 上面多加一個 import 或調整排版，整個工具就壞了。作者自己會覺得很冤：「昨天都還好好的啊。」

更諷刺的是這種寫法常常伴隨一句 self-justification：「這個不用 AI 啦，AI 不穩定，我直接寫 script 去爬就好。」但他寫的 script 才是真正脆弱的那個——AI parse 一份 AST 比 hardcode 行數穩定得多。

這類實作有一個共同的味道：它描述的是當下的快照，不是一條規則。實作的人腦中沒有「這份 code 一週後可能長什麼樣」這個維度。

差別在哪：四個小分水嶺

這三個 anti-pattern 背後其實都是習慣的差距，跟能力沒太大關係。會用 AI 的人跟不會的人，外表接近——都在打 prompt、都在 ship code、都在開 PR——但幾個分水嶺很清楚：

會用的人，ship 之前會自己把 AI 給的東西讀一遍、改幾句；下 prompt 前先想「正確的描述該長怎樣」；輸出不對的時候，改的是 prompt 跟 context，不是直接動 AI 生出來的 code。

不會用的人剛好反過來：複製貼上就送、把腦中第一個句子丟給 AI、生出來不對就自己下海改。最明顯的差別是——早上 AI 幫他寫完的東西，下午問他「這段在幹嘛」答不出來。

工具本身不會挑人，但會放大你原本的習慣。如果你本來就會停下來想、會驗證、會問「這是對的嗎」，AI 讓你變 5 倍快；如果你本來就跳過這些步驟，AI 讓你變 5 倍產出不可信的 code。

「會用 AI」在這個時代是核心技能，但它講的是你有沒有把判斷的肌肉留在自己身上，跟你用哪個工具、訂哪個 plan 沒關係。

一個換個角度的解法：與其改 code，不如教 AI

我跟前主管聊到這現象的時候半開玩笑說了一句：

與其花力氣 review 別人用 AI 寫出來的 code、回覆 PR 寫一堆 review comment，不如直接花時間把專案的 docs、convention、reference example 寫清楚，給他們的 AI 用。把 AI 教懂比把人教懂容易多了。

後來想想這個玩笑其實半認真。在 AI 時代，把你的知識 encode 成 AI 能讀的格式——一份清楚的 CLAUDE.md、一組 reference example、一份 naming convention、一份 architecture decision 紀錄——本身就是一種新的資深能力。你寫得好，整個團隊的 AI 產出都能更上一個層級。

這也對應上面三個 anti-pattern 的解：

Anti-pattern 1（漏掉意圖）：把產品意圖寫成 docs，prompt 引用過去
Anti-pattern 2（看不到層次）：把資料層 vs UI 層的 convention 寫成 example
Anti-pattern 3（快照當規則）：把「為什麼這樣設計」的脈絡寫進 README，AI 才推得動結構而不是抄 surface

Prompt engineering 是輸入端的功夫。這個是輸出端的功夫。後者目前比較沒人在認真訓練，但價值會越來越高。

回到同事原本的問題

繞了一圈回到「AI 時代怎麼當一個資深前端工程師」這題。

我上一篇寫過台灣跟北美處境的差別、為什麼在台灣會用 AI 主動做東西的人是最缺的——那邊的觀點到現在還是成立。

這篇想補一句更近距離的：「資深」會變成什麼樣，看你身邊兩三個常一起 review code 的同事，半年下來差不多就有答案。

AI 沒有魔法，它只是放大你原本的習慣。資深要做的，是讓自己的習慣經得起放大跟檢視，然後想辦法讓它能複製給整個團隊。

參考資料

上一篇：AI 時代，務實派工程師靠什麼活下來？