AI 半成品接手：別把生成程式當成資產

AI 生成的程式碼最危險的地方，不是它寫錯，而是它寫得「看起來對」。變數命名整齊、註解齊全、目錄結構像模像樣，連 README 都附上了。工程師打開來掃一眼，潛意識就把它當成「同事交接的專案」處理——但它其實連一次真實流量都沒跑過。

這幾年我們協助客戶導入 AI 輔助開發的過程裡，最常見的不是「AI 寫不出東西」，而是「AI 寫了一堆東西，沒人敢動」。半成品堆積，反而比白紙更難起步。

先把它當成陌生人的 Pull Request

接手 AI 半成品的第一個心態調整，是別把它當作起點，而是當作一份待審的 PR。審視的順序我們通常會建議：

1. 資料流先於語法。先畫出輸入、處理、輸出三段，確認 AI 對你的領域邏輯理解是否正確。語法漂亮但商業邏輯錯位，是最常見的陷阱。
2. 邊界條件與錯誤處理。AI 生成的程式碼傾向假設 happy path，try/catch 常常是裝飾品。空值、逾時、重試、冪等，這些往往要重寫。
3. 依賴版本與安全性。AI 可能引用了已經棄用的套件版本，或寫出看似合理但有注入風險的 SQL 拼接。

舉個例子，假設你請 AI 產出一段「處理金流回呼」的程式骨架：

# 示意：實際接金流 API 請以官方文件為準
def handle_callback(payload):
    order = get_order(payload["order_id"])
    if payload["status"] == "paid":
        order.mark_paid()
    return "OK"

語法沒錯，但缺了驗簽、缺了冪等鍵、缺了狀態機檢查——這些補上去之後，往往比原本的程式碼長好幾倍。AI 給的是「形狀」，不是「成品」。

重構的順序：從介面往內，不要從內往外

半成品最容易讓人陷入的陷阱，是看到某個 function 寫得醜，就忍不住先重寫它。但當你不確定整個架構是否合理時，從內部細節開始重構，很容易做白工。

我們的經驗法則是反過來：

• 先固定對外介面。決定這個模組對外暴露什麼 API、收什麼參數、回什麼格式，先把測試寫起來。
• 再處理跨模組依賴。AI 常常把不該耦合的東西耦合在一起，例如把資料存取邏輯塞進 controller。
• 最後才動內部實作。當外圍有測試保護，內部要怎麼改都安全。

另一個實務建議：保留一份「原始 AI 產出」的 commit，不要急著美化掉。後續開發過程中，當你發現某個設計不對勁，回頭比對原始版本，常常能看出 AI 當初的「誤解」在哪裡，這對下一次寫 prompt 很有幫助。

我們的觀察

AI 半成品不是負債，也不是資產，它更像是一份「需要驗收的草稿」。真正會用 AI 的團隊，不是讓 AI 寫得更多，而是建立起一套穩定的接手流程：審視資料流、補齊邊界、由外而內重構、保留可追溯的歷史。當這套流程跑順了，AI 才會從一個「會偷工的實習生」，變成一個能放心交付半成品的協作者。