接手 AI／vibe coding 寫出來的系統，最常卡在這 8 個問題
短答案：接手一套用 AI 或 vibe coding 建立、而且已經上 production 的系統時，麻煩通常不在「程式看不看得懂」，而在控制權、可重現的部署、金鑰與相依、測試與監控、資料遷移、邊界情況與文件這幾件事幾乎都缺。以下是我們實際接手時最常遇到的 8 個問題，以及每一項先該查什麼——先穩定、先盤點，再決定要維護、局部重構還是重建。
這篇不是要嚇人。AI 幫很多團隊快速做出能 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 點盤清楚後，通常會落在四種方向之一，取捨依控制權、可維護性與風險而定，我們不預設每個都要重寫：
- 直接接手維護：控制權可取得、系統大致可維護，補上缺的部署、備份、監控即可。
- 局部重構：多數穩定，只有少數高風險模組需要重寫或替換。
- 逐步替換：邊維持現有服務、邊把風險最高的部分逐塊換掉。
- 必須重建：控制權、資料或核心架構風險過高，重建反而比硬救更快更安全。
如果你正面對「原團隊離開、系統還在跑卻沒人敢改」，可以看軟體接手與救援服務怎麼先把系統安全接回來；如果是 AI 原型做一半、卡在上線前，適合先看上線救援；想先自己快速評估，可以做Vibe-coded 上線就緒度自評。
本文查核依據
- NIST SP 800-218 安全軟體開發框架（SSDF）——用於檢查金鑰管理、相依控管與可重現建置等安全開發實務。
- OWASP Top 10——用於辨識硬編碼憑證、過期相依與缺乏驗證等常見高風險項目。
- AWS Well-Architected：營運卓越支柱——用於檢查可重複、可回復的部署與變更流程；不代表指定採用 AWS。
本文是接手前的檢查與決策指南，不是資安稽核、法遵意見，也不保證任何系統都能救回或任何架構、供應商的結果。盤點前不提供固定報價。
常見問題
接手用 AI 或 vibe coding 寫的系統，第一步該做什麼？
先把控制權盤清楚，再動任何程式碼。確認 repo、雲端、網域、DNS、資料庫、環境變數與金鑰、第三方 API、金流、email、監控與備份分別在誰的帳號下，能不能由你自己登入與撤換權限。控制權沒盤清前就改程式或重新部署，風險最高。
AI 生成的程式碼上 production，最危險的問題通常是什麼？
最常見且最危險的是把金鑰或密碼硬編碼在程式或前端、相依套件版本混亂含已知漏洞、以及完全沒有測試與監控。這三者會讓系統看起來會動，卻在流量、資料量或邊界情況變化時無預警出錯，且沒有人能及時發現。
「demo 會動」是不是代表系統可以安全維護？
不是。demo 通過只證明在特定輸入與環境下能跑一次。能不能安全維護要看：能不能在乾淨環境重現建置與部署、有沒有回滾方式、資料遷移與備份能不能還原、有沒有測試與監控，以及邊界情況與錯誤處理是否存在。缺這些時，系統隨時可能因一個小改動而中斷。
接手後一定要重寫嗎？
不一定。接手方案有直接接手維護、局部重構、逐步替換與必須重建四種，取捨依控制權、可維護性與風險而定。多數情況是先穩定化並補上缺的控制權、部署、備份與監控，再決定哪些模組需要重構，而不是預設整套重寫。
沒有原始開發者、也沒有文件，還能接手嗎？
多數情況可以，但要先做盤點式接手：從 source code、雲端與帳號反推架構、相依與資料流，補出 Access Map、Dependency Map 與 Risk Register，並先驗證備份能還原、部署能重現。無法保證每個系統都能救回，盤點前也不會給固定報價。