你正在被 AI 編碼助手養廢——以下是自救指南

你有沒有過這種經驗：AI 幫你生了一段程式碼，看起來沒問題，編譯也過了，lint 也沒跳錯。你按了 Tab，merge 了 PR，然後三個月後的某個凌晨兩點，這段程式碼在某個你完全沒預料到的邊界條件下炸了。你打開那段 code，發現自己根本看不懂它在幹嘛——不是你寫的，是 AI 寫的，你當時只是「審了一下覺得看起來 OK」。

這不是你的錯，但這是你要解決的問題。

AI 編碼助手不是中性的工具。它們會改變你思考程式碼的方式，而且大部分的改變發生在意識層面之下。你開始習慣性地先按 Tab 再思考，開始把「編譯通過」當成「正確」的同義詞，開始發現自己寫不出某些以前隨手就能寫出來的 pattern——因為這幾個月都是 AI 在幫你寫。你不是變快了，你是把思考外包了。外包出去的思考不會自動回來。

這篇文章不是要叫你刪掉 Copilot。是要教你建立一套工作流程，讓你用這些工具的同時，保住你作為工程師最值錢的東西：獨立判斷程式碼的能力。

先搞清楚 AI 擅長什麼、不擅長什麼

AI 編碼助手有一個很窄的「安全區」和一個很寬的「危險區」。多數人安裝之後從來沒有認真畫過這條界線。

安全區內的東西：boilerplate、重複性的重構、測試腳手架、config 檔、文件生成。這些任務的共同特徵是，正確性容易驗證，而且不需要創造力。你需要一個 React 元件來渲染帶分頁和排序的列表，AI 十秒內就能生出來，你花三十秒確認邏輯沒問題，收工。你需要把一百個 API endpoint 從 REST 遷移到 GraphQL，AI 幫你做完機械性的轉換，你專心處理那三個有真正業務邏輯的 endpoint。這就是 AI 的正確用法。

危險區內的東西：架構決策、安全性相關的程式碼、效能關鍵路徑、任何需要「理解你的 codebase 全貌」才能做對的事。AI 不理解你的專案。它是在訓練資料裡做 pattern matching，所以它會信心滿滿地推薦一個「在別人的 codebase、別人的團隊、別人的限制條件下」行得通的方案。這段程式碼編譯會過，lint 會過，你現有的測試可能也會過。然後三個月後有人加了一個新功能，整段邏輯因為一個你沒注意到的耦合點全炸。

一個真實案例：我目睹過一個開發者接受了 AI 建議的 authentication middleware——JWT 驗證、refresh token 輪換，看起來很乾淨。code review 過了。上線了。兩週後安全審計發現 refresh token 的輪換邏輯在高併發下有 race condition，會把合法的 token 也一併失效。那段 code 單獨跑是對的，上線就跑錯了。接受那段 code 的開發者沒辦法逐行解釋輪換邏輯，因為他根本不需要——AI 寫的，他瞄了一眼，編譯過了，他就接受了。

判斷標準很簡單：如果驗證 AI 輸出所花的時間，比你親手寫的時間還長，那 AI 沒有幫你省到時間。它只是在表演一種「你以為省到了、實際上之後要連本帶利還回去」的魔術。

看不懂的 code，一率不要接

這句話聽起來像你大一程式設計課老師會講的話。它是。它也是實務上最常被違反的規則，因為這些工具的設計目的就是讓「接受」這件事情毫無摩擦力。

典型的使用流程是這樣的：寫一行註解描述你要什麼 → AI 生三十行程式碼 → 快速掃一眼 → 看起來大概對 → 按 Tab。整個循環不到十秒。你的大腦把「速度快」和「正確」當成同一件事——心理學上這叫流暢性捷思（fluency heuristic）——然後你就開始處理下一件事，覺得自己效率很高。

解決方法簡單到近乎愚蠢，但幾乎沒有人持續做到：逐行讀。不是掃。是讀。如果有一行程式碼你沒辦法對一個 junior 開發者解釋清楚——不只是「它在做什麼」，而是「為什麼選這個做法而不是其他做法」——就不要接受。等你搞懂了再自己打出來，或者叫 AI 解釋它的思路，然後你自己判斷要不要接受。

一個實用的練習：當 AI 跳出建議時，用手遮住螢幕上的建議區塊（或者最小化那個面板），先在腦中重建你預期要寫的邏輯。然後再打開建議，比對兩者。一樣就接受，不一樣就先搞清楚差異再決定哪個比較好。這大概多花十五秒，但這十五秒讓你保持在思考的迴圈裡，而不是滑入「接收→跳過→接收→跳過」的自動駕駛模式。

另一個練習：叫 AI 對同一個功能生三種不同實作，然後選一個你自己會寫的那個。比較的過程強迫你評估取捨，而不是在第一個能編譯的版本上蓋章了事。

你的測試現在比以前更重要，不是更不重要

當 AI 幫你寫大部分程式碼的時候，會產生一種弔詭的動態：你的測試變成你和一個你不再完全理解的 codebase 之間唯一的防線。

如果你原本的測試覆蓋率就很薄，AI 會加速你朝一個看不見的災難前進。如果你原本有扎實的測試，那些測試會在 CI 階段幫你攔住 AI 的錯誤，而不是等到 production 炸了才發現。

新規則：每一個 AI 生成的 function，merge 之前一定要有測試。不是「之後補」。不是「有時間再寫」。是 merge 之前。如果你沒辦法幫一個 AI 寫的 function 寫測試，因為你根本不完全理解它在幹嘛——那不是跳過測試的訊號，那是你自己重寫這個 function 的訊號。

Property-based testing 和 snapshot testing 在 AI 輔助的工作流中價值特別高。AI 很擅長 happy path。它對邊界條件完全不行，而且它對兩者都一樣信心滿滿。一個 property-based test，寫著「對任何合法輸入，這個 function 的回傳值應該落在這些範圍內」，可以抓到 AI 的幻覺——那種手寫的、針對特定輸入的 unit test 永遠抓不到。Snapshot test 則能抓到 AI 在重構時不小心動到不該動的輸出格式。

測試流程也應該調整。與其用傳統的 TDD（先寫測試再寫 code）或 code-first，一個更有效的模式是：先叫 AI 生實作 → 你審 → 再叫 AI 根據實作生測試 → 你審測試，而且審測試要比審實作更仔細。AI 生測試的能力比多數開發者以為的好，而 AI 生的測試常常會抓到 AI 生的 code 裡面的 bug——那些開發者和 AI 第一輪都沒發現的 bug。

排定「無 AI 時段」

技能退化的問題是真實的，而且是複利計算的。每次你沒經過充分思考就接受一個建議，你就錯過一個微小的學習機會。幾百次、幾千次累積下來——一天幾百次，一週上千次——你突然發現自己寫不出某些 pattern，因為過去幾個月都是 AI 在寫，不是你在寫。

你要刻意安排關掉 AI 的時間。一週一個早上。每天最後一小時。任何適合你工作節奏的頻率。在這段時間裡，所有程式碼自己打。自己查文件。自己跟 compiler error 搏鬥。仔細讀錯誤訊息，而不是複製貼上到 AI 對話框等解答。搏鬥的過程才是重點——你的大腦就是透過這個過程，重建那些 AI 在你不知不覺中侵蝕掉的心智模型。

有些團隊已經開始實施「無 AI 星期五」，或者要求某些模組——認證、金流、核心業務邏輯——必須完全不靠 AI 來寫。這些規定聽起來很極端，直到你曾經在某個星期六晚上十一點，對著一段 AI 生成的 authentication middleware 除錯，發現 refresh token 的 race condition 沒人看得懂也沒人改得動。經歷過這種事之後，這些規定聽起來就只是基本的職業衛生。

用一個物理世界的比喻：如果你每題算術都用計算機，你遲早會忘記怎麼心算乘法。如果你每次出門都靠 GPS，你永遠學不會路。AI 編碼助手是同一類工具。用它做無聊的部分。困難的部分自己來，不然你會失去做困難部分的能力。

把 AI 當成一個「讀很快但沒有判斷力的 junior 工程師」

這個心理模型比任何技術技巧都更有用。想像一個 junior 工程師：他每秒可以讀完一千頁文件，他背熟了 2015 到 2025 年 Stack Overflow 上所有的答案，但他完全沒有能力判斷哪些答案適用在你的情境。這就是你的 AI 編碼助手。它很快。它博學。它完全分不出「適合這個 codebase 的 pattern」和「適合另一個 codebase、但 function 名稱剛好很像的 pattern」。

你不會 review 都不 review 就把 junior 的 PR 直接 merge。你不會讓 junior 直接 push 到 main，只因為「他寫的 code 通常都能編譯」。你不會因為 diff 很小、他看起來很自信，就跳過 code review。對 AI 產出的 code，請用完全相同的標準。AI 比 junior 更快，犯的錯類型也不同——更陰險，因為 AI 的錯誤看起來更像「正確的程式碼」——但審查標準應該一模一樣。

有一個關鍵差別：junior 工程師知道自己什麼時候困惑，會開口問。AI 沒有「不知道」的概念。任何 prompt 它都會給出答案，而且每個答案都帶著相同的信心水準——不管答案是對的、微妙的錯的、還是完全的幻覺。這讓 AI 生成的 code 比 junior 寫的 code 更危險：錯誤訊號更難被偵測。Junior 的錯誤通常看起來像錯誤。AI 的錯誤通常看起來像一個聰明的解法。

---

AI 編碼助手不會消失。完全抗拒它的開發者，最終會比善用它的開發者慢。但「善用」不是預設模式。預設模式是逐漸依賴——接受越來越多、理解越來越少，然後某天醒來發現，你安裝來讓自己更快的工具，最終讓自己變得可以被取代。

真正會存活下來的開發者，是那些把 AI 當成加速器——加速不需要判斷力的部分，同時拼命保護需要判斷力的部分。這個區別聽起來很微妙。實際上，它會在每一個 PR、每一次事故檢討、每一次績效考核中顯現出來。