為什麼這個問題現在會跑出來
最近很多工程師在用 AI（人工智慧）寫 code（程式碼）時，遇到的麻煩已經換了一種樣子。以前你可能會先擔心它寫出不能編譯的東西；現在用 Cursor（一套把 AI 寫程式能力放進編輯器的工具）、Claude Code（一套讓 AI 在專案裡讀檔、改檔、跑指令的程式協作工具），或 Codex（OpenAI 的程式協作模型／工具）改 backend logic（用白話文講，就是服務端真正決定資料怎麼流、規則怎麼算的那段程式），它常常可以交出一段看起來像同事寫的 code。能跑，測一下也有結果。問題是行為不對。這很煩。 我最近看一位同事 review 一段 AI 改過的結帳邏輯，第一眼覺得很乾淨，變數命名也比原本好。結果仔細追才發現，折扣和運費的計算順序被換掉了，單元測試只蓋到一般訂單，沒有蓋到免運門檻附近的 2 種情境。這不是那種紅字噴滿螢幕的錯。它更安靜。 這篇要抓的核心判斷很簡單：AI 寫的 code 跑起來沒錯，但行為跟你預期不一樣，多數時候要先把它當成「邏輯錯」處理，而不是把它歸到工具還不夠聰明、或某個套件名字記錯。語法錯會被編譯器擋下，API（用白話文講，就是程式跟外部功能或套件溝通的介面）名字錯通常會被 linter（簡單講，就是幫你檢查程式風格與常見錯誤的工具）或型別檢查抓到。邏輯錯比較麻煩，因為它常常長得很像對的。這才是坑。
真正的原因不在表面
先把錯分清楚，review（用白話文講，就是工程師檢查程式碼改動是否合理的流程）才不會用錯力。第一種是語法錯，像少括號、型別寫壞、語言規則不通，編譯器通常會立刻讓你停下來。第二種是 API 名字錯，像把函式名稱猜錯、參數順序搞錯、套件版本不合，linter 或型別系統常常能抓到一部分。第三種是邏輯錯，像條件判斷反了、預設值選錯、狀態更新順序錯、例外情境被吃掉。這種最容易溜過。它會裝正常。 真正的原因不只是 AI 會「亂編」。在寫 backend logic 時，很多任務本來就依賴你腦中那套沒有寫下來的規則：取消訂單後庫存什麼時候回補、付款失敗要不要建立紀錄、使用者沒有權限時要回傳哪一種錯誤、同一筆資料被兩個請求同時改時誰先算。AI 看得到你給它的檔案和指令，但看不到你們團隊在會議、事故回顧、舊需求裡累積出來的默契。規範沒講清楚，它就會用最像樣的方式補洞。補得很順。 更容易誤判的是「熟悉感」。AI 現在寫出來的 code 很常有漂亮的函式切分、合理的命名、看似完整的錯誤處理，這會讓資深工程師在讀的時候降低警覺。人腦很擅長辨認風格，也很容易把熟悉風格誤認成正確邏輯。尤其當一個 pull request（用白話文講，就是把一組程式改動送出來請同事檢查的流程）有 300 行改動，AI 又順手幫你整理了結構，你可能會先看「寫得像不像我們團隊」，而不是看「每一條規則有沒有被保住」。這裡會出事。 所以這個問題的底層不是工具強或不強，而是你把哪一種錯交給哪一種檢查機制。語法錯交給編譯器，API 名字錯交給 linter 和型別檢查，邏輯錯要交給 test（用白話文講，就是用案例驗證程式行為是否符合預期）和人讀 code。這 3 類錯如果混在一起看，你會覺得 AI 明明都能跑了，怎麼還會錯；分開看就會發現，它只是通過了比較容易自動化的那幾關。還沒到終點。
現在先做什麼
現在先做的事，不是把 AI 產出的每一行都當成可疑物，這樣會拖垮速度。比較實際的做法是先問一個問題：這段改動如果錯了，會錯在哪個「行為」上？例如它會不會讓未付款訂單被標成已付款、會不會讓沒有權限的人拿到資料、會不會在重試時重複扣款。先抓行為，再看 code。順序要換。 我會建議你在讓 AI 改 backend logic 前，先用 3 句話把不可改的規則寫出來：哪些輸入要得到哪些結果、哪些例外情境要維持原樣、哪些副作用不能發生。這不是寫長篇文件，而是把你腦中的紅線放到任務裡。像「取消已出貨訂單時，不可以自動回補庫存」這種句子，比「幫我重構訂單流程」有用太多。AI 比較會照著範圍走。規則要明。 改完之後，不要先看它排版漂不漂亮，先找 2 到 4 個最容易壞的案例跑 test。這裡的 test 不一定要一開始就很完整，但要打中行為：正常案例 1 個、規則門檻附近 1 個、例外情境 1 個、狀態重複執行 1 個。舉例來說，折扣邏輯不要只測「有折扣能不能算」，還要測「剛好達門檻」、「差 1 元達門檻」、「折扣後是否仍符合免運」。這些案例比單純提高覆蓋率更能抓錯。抓關鍵點。 讀 code 時也要換一個角度：不要只看它有沒有照原本檔案風格寫，而是沿著資料流走一次。資料從 request（簡單講，就是外部送進服務的請求）進來，經過驗證、查詢、計算、寫入、回傳，每一段的條件有沒有被改掉。AI 很常在「看起來等價」的地方做簡化，例如把兩個 if 合併、把早退條件換順序、把 null 和空陣列視為同一類。這些改法不一定錯，但在 backend logic 裡很值得停 10 秒。慢一下。
常見的陷阱跟誤解
第一個陷阱，是把「跑得起來」當成「行為正確」。跑得起來只代表某條路徑順利走完，很多真正會傷到資料的錯，會藏在少數條件或少數狀態裡。別停太早。 第二個陷阱，是看到 AI 把 code 變乾淨，就順手接受整包改動。重構和改行為在 diff（用白話文講，就是這次修改前後差了哪些內容）裡常常混在一起，尤其是 AI 同時改命名、拆函式、搬條件時，真正的邏輯改動會被包在漂亮外衣裡。要拆開看。 第三個陷阱，是只補 happy path（簡單講，就是最順、最正常的使用流程）的 test。AI 寫 backend logic 時，正常流程通常比較像樣，反而是權限不足、資料不存在、重複請求、門檻上下 1 單位這些地方容易失準。要測邊角。 第四個陷阱，是把錯都歸因成 AI 幻覺。hallucination（用白話文講，就是 AI 編出不存在或不符合事實的內容）確實會發生，但這篇談的狀況更常是規則沒有被表達清楚，AI 用合理但不符合你系統的方式補完。判斷要準。
下次再遇到時可以怎麼判斷
下次再遇到「AI 寫的 code 跑起來沒錯，但行為怪怪的」，先不要急著問它為什麼寫錯。先把錯歸類：編譯器能擋的是語法錯，工具能抓一部分的是 API 名字錯，只能靠案例和讀 code 抓的，多半是邏輯錯。分類先做。 如果這次改的是小工具函式、沒有資料寫入、沒有權限判斷，放給 AI 多改一點通常風險較低；如果碰到金流、庫存、權限、狀態轉換、資料一致性，就把規則寫清楚，補幾個行為 test，再 review。這不是單一正解，而是取捨：你要用 AI 換速度，就要把檢查力放在最容易漏的地方。下次看行為。
