看起來能跑，不代表能上線。這是工程師接手 AI 產出半成品時，最常忽略的落差。
當前的 AI 編碼助手（不論是 Copilot、Cursor 還是各家 agent 型工具）已經可以一口氣產出一個能 demo 的雛形：登入頁、CRUD、串第三方 API，甚至包含基本測試。問題是，這種「能 demo」與「能維運」之間，往往隔著整個工程紀律。把 AI 草稿直接丟進產品線，多半不是省時間，而是把技術債往後延。
接手 AI 程式碼時，要先看什麼
我們的經驗法則是：拿到 AI 產出的專案，先別急著補功能，先做三件事。
第一，確認邊界條件有沒有被處理。AI 很擅長寫 happy path，但對於空值、逾時、權限不足、併發寫入、第三方 API 回傳異常結構這類情境，常常只是 try/except 一把抓，或乾脆沒寫。這種程式碼在 demo 環境看不出問題，一進生產就會在凌晨噴錯。
第二，檢查資料模型是否站得住腳。AI 為了快速生成，常會把欄位攤平在一張表、或是反過來過度切割。舉個例子，假設你請 AI 生成一個訂單系統的雛形，它可能會把訂單狀態、付款狀態、出貨狀態全部塞進 order 一張表，欄位用字串描述。短期內可以動，但等到要對帳、要做狀態機、要支援退款流程時，整個資料層都得砍掉重練。
第三，讀懂相依套件的選擇。AI 偏好引用它「見過最多次」的套件，這不等於最適合你的場景。有時候它會引入一個維護不活躍的函式庫，只為了少寫十行程式碼。這種選擇要在接手第一天就挑出來，越晚換成本越高。
# AI 常見的草稿風格（示意）
def create_order(data):
order = Order(**data)
db.session.add(order)
db.session.commit()
send_email(order.user_email)
return order
上面這段在 demo 沒問題，但缺了交易邊界、缺了 email 失敗的補償邏輯、也沒有處理 data 結構不合預期的情況。這類「乍看乾淨、實際脆弱」的片段，是 AI 草稿的典型樣貌。
重構策略：分層接手，不要全盤改寫
看到 AI 產出的程式碼結構不理想，工程師很容易陷入「全部重寫比較快」的衝動。但全盤改寫通常會吃掉原本想省的時間，也讓 AI 的價值歸零。比較務實的做法是分層處理。
第一層：保留 UI 與骨架。AI 在版面、路由、表單欄位這類重複性高的工作上，產出品質通常堪用。這部分可以留下，只做命名與一致性調整。
第二層：重寫商業邏輯與資料層。這是 AI 最容易出錯的地方，也是日後維護成本最高的地方。建議由工程師主導，把核心 domain model、狀態流轉、交易邊界重新設計，AI 只扮演輔助打字的角色。
第三層：補上測試與可觀測性。AI 產生的測試經常只是覆蓋「函式有被呼叫」這種表層，缺乏對業務規則的驗證。接手時要補上整合測試、加上 log 與 metrics，這也是判斷一個專案能不能進產品線的硬指標。
換句話說，把 AI 當成資淺工程師的初稿，而不是資深工程師的成品。審視標準要拉到一致，不要因為「這是 AI 寫的」就放寬。
我們的觀察
AI 確實大幅縮短了從 0 到 1 的時間，但從 1 到上線這段路，工程紀律的重要性反而上升而非下降。協和數位在報價時通常會這樣建議客戶：如果專案打算用 AI 草稿起手，請預留接手與重構的時間，不要把它當成省下來的預算。願意把這段時間算進去的團隊，AI 才會真的變成加速器，而不是延後爆炸的計時器。