AI 產出的程式碼最危險的地方，不是寫錯，而是「看起來都對」。它能編譯、能跑出畫面、能通過你隨手寫的測試，於是團隊以為剩下的只是收尾，結果一進產品線才發現邊界條件、錯誤處理、權限、交易一致性幾乎都是空的。
這幾年 AI coding agent 從補全片段演進到能交出整個專案骨架，但「半成品接手」這件事的本質沒有變：你拿到的不是一份程式碼，而是一份還沒被現實壓力測試過的草稿。
接手 AI 半成品時，先看哪裡？
我們在報價時通常會建議客戶，把審視順序固定下來，不要從最顯眼的 UI 開始挑，而是由內往外：
- 資料模型與邊界：schema 是否反映真實業務語意？欄位有沒有偷懶用 string 裝結構化資料？AI 很常為了讓 demo 跑起來，把「訂單狀態」做成自由文字而不是 enum。
- 錯誤處理與失敗路徑：try/catch 是否只是把例外吞掉？外部 API 失敗、逾時、429、半成功的情況有沒有被想過？這是 AI 草稿最常見的洞。
- 權限與多租戶邊界：查詢有沒有帶上使用者或租戶 ID？AI 預設世界裡通常只有一個 user。
- 交易一致性：跨資源寫入（DB + 第三方 + 訊息佇列）的補償邏輯有沒有？
- 可觀測性：log、metric、trace 幾乎一定缺，要補。
做完這輪，UI 的瑕疵反而是最後再修的，因為那是最便宜的問題。
舉個例子：假設你請 AI 生出一段「收到 webhook 後扣庫存並寄出通知」的程式，骨架大概會長這樣：
# 示意：實際接 API 請參考官方文件
def handle_webhook(payload):
order = parse(payload)
db.decrement_stock(order.sku, order.qty)
mailer.send(order.email, "出貨通知")
return 200
這段程式碼在 happy path 完全沒問題。但只要問四個問題就會崩：webhook 重送怎麼辦？扣庫存成功但寄信失敗怎麼辦？同一個 SKU 同時被扣會不會超賣？payload 被偽造怎麼辦？這四題 AI 沒被問就不會主動回答，而它們每一題在生產環境都是真實事件。
怎麼把半成品導入產品線
與其逐行重寫，不如把 AI 草稿當成一份規格草稿來對待，再用工程紀律補上骨架以外的東西。我們的經驗法則是：
- 先補測試，再動程式碼。把目前 AI 寫出來的行為先用測試固定下來，包含你「不希望它這樣做」的反例。這樣後續重構才有安全網。
- 把外部相依抽出來。AI 很愛把第三方 API 直接寫死在商業邏輯裡，先抽介面，未來換供應商或加上 retry、circuit breaker 都會輕鬆很多。
- 接上既有的可觀測性管線。不要讓 AI 產出的模組變成日誌黑洞。
- Code review 要由人主導，不要再丟回 AI 自評。AI 自評會傾向認可自己的輸出，這是已知的偏誤。
- 明確標記 AI 來源。在 commit message 或 PR 描述標註哪些段落由 AI 起稿，方便日後追溯責任與技術債。
至於要不要把 AI 草稿整段丟掉重寫？我們的判斷標準很簡單：如果補洞的工作量已經超過重寫，就重寫；如果只是補可觀測性和錯誤處理，留著反而省事。
我們的觀察
AI 把「寫出能動的程式」這件事的成本壓得很低，但「讓程式能在真實流量下不出事」的成本幾乎沒變。對中小企業團隊來說，與其爭論該不該用 AI 寫程式，不如把心力放在建立接手 SOP：審視順序、測試先行、可觀測性標準、code review 紀律。當這些流程到位，AI 就從一個有風險的捷徑，變成一個能放大團隊產能的起稿工具。半成品本身不可怕，怕的是沒人意識到那是半成品。