AI 產出的程式碼看起來能跑，往往是最危險的狀態。它會通過你隨手點的那次測試、會在 happy path 上表現得像模像樣，然後在正式流量進來後，用你想不到的方式壞掉。這幾年工程師接手 AI 半成品的頻率明顯變高，這篇整理一個務實的接手順序。
先讀邊界，再讀邏輯
很多人拿到 AI 產出的檔案第一件事是「跑跑看」。這是錯的順序。AI 生成的程式碼最脆弱的地方通常不在核心邏輯，而在邊界：輸入驗證、錯誤處理、外部呼叫的 timeout、資料庫交易的邊界、認證與授權的細節。
舉個例子，假設 AI 幫你生了一段串接金流的 webhook handler，主流程可能寫得很漂亮，但你要問的是：
- 有沒有驗簽？簽章比對用的是常數時間比較還是普通的字串比對？
- 重送（retry）進來時會不會重複扣款？有沒有 idempotency key？
- 資料庫寫入失敗時，回應給金流服務的狀態碼對不對？
# 示意：AI 常見的「看起來沒事」寫法
@app.post("/webhook")
def handle(req):
data = req.json()
order = Order.get(data["order_id"])
order.mark_paid()
return {"ok": True}
# 沒驗簽、沒 idempotency、沒 try/except、
# 沒交易邊界——但單元測試會過
讀邊界的意思，是把每一個「外部世界進來」與「往外部世界出去」的點都標出來，逐一問：這裡壞掉會怎樣？AI 不會替你回答這個問題，因為它沒有你的營運上下文。
重構的時機與剎車點
接手 AI 半成品的第二個常見錯誤，是一次改太多。看到不順眼的命名、重複的區塊、缺失的抽象，一口氣全部重寫，結果混淆了「修 bug」與「重構」兩件事，PR 變得無法審查。
我們的經驗法則是分三段走：
- 先讓它可觀測：補上 log、補上明確的錯誤型別、把靜默 catch 的地方掀開。這一步不改行為，只讓後面兩步能被驗證。
- 再讓它正確：修上一節列出的邊界問題，補測試——特別是失敗路徑的測試。AI 幾乎不會主動寫失敗路徑測試。
- 最後才談漂亮：命名、抽層、拆檔案。這一步是可以延後的，甚至可以不做。
另外一個實務上很重要的剎車點：如果你發現要修的東西超過 AI 產出的一半，停下來，考慮整段重寫。硬修一份結構本來就不對的程式碼，最後花的時間通常比重寫多。
判斷標準可以很簡單——問自己：「這個檔案的架構，如果是我從零開始寫，我會這樣寫嗎？」如果不會，而且差距很大，那就是重寫的訊號。AI 產出對你有價值的部分，可能只是它幫你想過的欄位命名、邊界情境、或某個函式庫的用法，這些拿走就好，不必連同它的架構一起收下。
我們的觀察
AI 工具讓「從零到一」變得非常快，但「從一到能上線」的比例並沒有跟著縮短，甚至因為初始品質參差不齊，反而讓資深工程師的審查負擔變重。與其把 AI 當成寫完程式的人，不如把它當成一位很勤勞但沒有營運背景的實習生——產出要看、邊界要補、責任還是在接手的人身上。這個心態抓對了，導入產品線就不會踩到最深的那幾個坑。