AI 給你的程式碼八成都能跑，但能跑不等於能上線。這是現在所有接觸 Copilot、Cursor、Claude Code、v0 之類工具的團隊都會碰到的真實落差——demo 看起來完整，跑單元測試也綠燈，可是當你想把它放進真正的產品線、串到既有的金流或 ERP，問題才開始浮現。
這篇想談的，是工程師面對 AI 半成品時，該用什麼框架去審視、修補、再導入。
先分辨「能跑」與「能交付」的距離
AI 產出的程式碼有幾個常見特徵：邏輯局部正確、命名合理、結構看起來像模像樣，但缺少對上下文的理解。它不知道你的資料表已經有兩個版本、不知道你的 API gateway 有 rate limit、也不知道你之前因為某個合規要求把驗證邏輯抽到另一個 service。
所以接手 AI 半成品時，第一步不是讀 code，而是先回答三個問題：
- 它解決的是不是真正的問題？ 很多時候 AI 會根據 prompt 字面意思生成功能，但 prompt 本身就是錯的需求描述。
- 它的邊界在哪？ AI 傾向於把功能寫得「自成一體」，這在原型階段很好，但在產品線會造成重複邏輯與資料不一致。
- 它假設了什麼？ 注意那些沒寫出來的假設：時區、字元編碼、空值處理、錯誤該丟還是該吞。
舉個例子，假設你請 AI 寫一段「批次匯入訂單」的程式，它很可能給你一個漂亮的 for-loop、加上 try-catch、甚至附上進度顯示。但它不會主動問你：失敗的那幾筆要回滾還是跳過？要不要寫進 dead letter queue？這些才是真正決定它能不能上線的部分。
修補的順序：架構 → 介面 → 實作
看到 AI 寫的 code，工程師最容易犯的錯是直接從實作層改起——改變數名、調 if-else、補幾個註解，然後就 commit。這種改法會讓技術債悄悄累積。
我們的經驗法則是反過來，由外而內審視：
# 示意：不要急著改實作
# 先問：這個 function 該不該存在於這一層？
def import_orders(file_path):
# AI 會把讀檔、驗證、寫 DB、發通知全塞在一起
# 真正要做的是先拆出邊界
...
第一層看架構：這段程式碼放對 module 了嗎？該不該是一個獨立 service？它的職責有沒有跨越既有的分層？
第二層看介面：input/output 的型別、錯誤回傳的方式、跟其他模組的契約是否一致？AI 經常生成「孤島型」介面，跟你既有的 convention 不同。
第三層才是實作：到這裡如果發現實作其實寫得不錯，就留著；如果發現它的演算法選擇有問題、或可讀性差，就重寫。重寫一段純函式遠比重構一個錯位的 service 便宜。
還有一個實務上的小建議：AI 寫的測試別全留。它生成的 test 經常是「為了測試而測試」，覆蓋率好看但抓不到真正的 regression。寧可砍掉一半，重新補幾個跟業務邏輯緊密相關的整合測試。
我們的觀察
AI 工具沒有讓資深工程師變得不重要，反而把「判斷力」的價值往前推了。寫 code 的速度被壓縮，但決定哪些 code 該留、該改、該丟的能力，依然只能靠經驗。把 AI 當成一個產出很快但缺乏上下文的初階成員，你會用什麼態度 review 他的 PR，就用什麼態度 review AI 的輸出——這大概是目前最務實的相處方式。