接手 AI／vibe coding 寫的 production 系統前，先檢查這 8 件事（附接手決策路徑）

這篇整理自我們實際接手 AI／vibe coding 產出、且已經上 production 的系統時，第一週最常踩到的地雷。完整原文（含常見問答與延伸閱讀）發表在 Omni Care 部落格，本文為 DEV 社群版重寫。

用 AI 或 vibe coding 快速做出能 demo 的產品是好事——問題是「能 demo」和「能安全維護」是兩件完全不同的事。當原團隊離開、系統還在跑卻沒人敢改，麻煩幾乎從來不是「程式看不看得懂」，而是控制權、可重現部署、金鑰與相依、測試監控、資料遷移、邊界情況、文件這幾件事同時缺席。

以下 8 點是我接手這類系統時固定會先跑一遍的檢查。順序有意義：先穩定、先盤點，再決定要維護、局部重構還是重建——不要一接手就急著改功能或重新部署。

1. 沒有人真正握有 production 的控制權

最典型的第一個坑：repo 在某個個人帳號、雲端綁另一個 email、網域和 DNS 在第三方、資料庫和金流又各自屬於不同人。原團隊一走，沒人能完整登入、也無法撤換權限。

先查：逐項確認 repo／雲端／DNS／資料庫／環境變數與 secrets／第三方 API／金流／email／監控／備份分別在誰的帳號下，你能不能自己登入、能不能移轉擁有權。控制權沒盤清前，一行程式都先別改。

2. 沒有可重現的建置與部署流程

系統「上線了」，但怎麼 build、怎麼 deploy 常常只活在某台機器或某個人的記憶裡：沒有 CI／CD、沒有部署腳本、沒有回滾方式。改一行就得靠運氣。

先查：能不能在一台乾淨環境從 source code 重現建置與部署？部署失敗能不能回滾到上一個可用版本？走通這條路，是後續所有修改的安全網。AWS Well-Architected 的營運卓越（Operational Excellence）支柱正是把「可重複、可回復的變更流程」列為基本要求。

3. 金鑰、密碼直接寫死在程式或前端

AI 生成的程式為了「能跑」，很常把 API key、資料庫密碼、第三方 token 直接硬編碼在程式碼、設定檔、甚至前端 JavaScript 裡。一旦進了 git 歷史或公開前端，就等於已經外洩。

先查：掃描 repo 與前端有沒有硬編碼憑證，確認哪些已進入 git 歷史。硬編碼與外洩憑證是 OWASP Top 10 長期點名的高風險項目。接手時應先輪替所有可能外洩的金鑰，再把 secrets 移到環境變數或密鑰管理服務。

4. 相依套件版本混亂、含已知漏洞

vibe-coded 專案常一次裝進大量套件、版本沒鎖定、或引用了不再維護的套件。哪天某個相依更新或消失，系統就跟著壞，其中也可能夾帶已知漏洞。

先查：有沒有 lockfile？跑一次相依漏洞掃描，列出高風險與不必要的套件。先鎖版本、再逐步升級——不要為了「清乾淨」一次大改而讓系統起不來。

5. 沒有測試、沒有監控，壞了才知道

AI prototype 幾乎都是零測試、零告警。系統壞掉時，往往是使用者先發現、你最後才知道；也沒有任何自動化能在改動後告訴你「這裡壞了」。

先查：有沒有任何自動化測試可跑？production 有沒有基本的錯誤與可用性監控、告警送到有人看得到的地方？重構前至少先補上「壞了會有人知道」這一層，否則每次修改都是盲改。

6. 資料模型與遷移沒有版本控制

沒有 migration、沒有 schema 版本、備份沒人驗證過能不能還原。改資料結構等於賭博——一出錯，可能連回不去的資料都救不回來。

先查：schema 變更有沒有以 migration 管理？最近的備份存在哪、多久一次、實際還原過嗎？動任何 schema 前，先確認「能安全回到現在這個狀態」。

7. 「看起來會動」，但邊界情況與錯誤處理缺失

demo 用的是乾淨輸入舌舌小資料量。真實 production 會遇到空值、超長輸入、併發、第三方逾時、額度用盡。AI 生成的程式常只寫了 happy path，例外一來就整個崩。

先查：關鍵流程（登入、付款、寫入、對外呼叫）有沒有錯誤處理與重試？輸入有沒有驗證？先找出「使用者一做非預期操作就會壞」的地方——通通常是接手後最先爆的雷。

8. 沒有文件、沒有架構圖，只剩一包 source code

最後一個、也是讓前面七頁都更難處理的問題：沒有架構圖、沒有部署說明、沒有相依清單，任何人要做下一個決定都得先自己逆向推敲一遍。

先查：把接手的第一份產出定位成「盤點文件」而不是「馬上改功能」。至少補出系統架構圖、Access Map（誰能存取什麼）、Dependency Map（相依與服務關係）與 Risk Register（已知驗證與處理順序），讓下一個決定朊依據。

接手不是只有「重寫」一條路

把上面 8 點清楚後，通常會落在四種方向之一，取捨依控制權、可維護性與風險而定——不預設每個都要重寫：

• 直接接手維護：控制權可取得、系統大致可維護，補上缺的部署、備份、監控即可。- 局部重構：多數穳定、只有少數高風險模組需要重寫或替換。- 逐步替換：邊維雭自有服務、邊把風險最高的部分逐塊換掉。- 必須重建：控制權、資料或核心架構風險過高時，重建反而比硬救更快更安全。

如果你正卡在「原團隊離開、系統還在跑去沒人敢改」，我們有整理一套先取得控制權、再判斷要維護／重構／重建的 軟體接手與救援檢查，可以先拿去對照自己的系統。

查核依據

• NIST SP 800-218 安全軟體開發框架（SSDF）——檢查金鑰管理、相依控管與可重現建置等安全開發實務。
• OWASP Top 10——辨識硬編碼憑證、過期相依與缺乏驗證等常見高風險項目。
• AWS Well-Architected：燱運卓越支柱——檢查可重複、可回復的部署與變更流程（不代表指定採用 AWS）。

本文是接手前的檢查與決策指南，不是資安稽核或法遵意見，也不保證任何系統都能救回或任何架構、供應商的結果。

本文由 Omni Care 團隊撰寫，內容為 AI 輔助草擬、經人工審閱與事實查核。原文出處：care.omniai.one。