從 AI 原型到 MVP：技術債與安全債的管理

一句話說明

用 AI 做出原型很快，但原型和 MVP 之間的差距在於認證、輸入驗證、錯誤處理和效能——這些 AI 在快速生成時通常會跳過。

Vibe Coding 原型通常缺什麼

飛飛在協助團隊做 AI 輔助開發時，統計了 20 個用 Cursor 或 Claude Code 做出的原型專案，歸納出 AI 產生的原型最常缺少的五個面向：

認證與授權。原型通常沒有登入機制，或用硬編碼的 token。所有使用者看到相同的內容，沒有角色區分。

輸入驗證。前端表單沒有驗證，後端直接接受任何格式的輸入。字串長度、數字範圍、檔案大小都沒有限制。

錯誤處理。程式碼用 console.log 印錯誤，沒有 try/catch，API 失敗時前端顯示空白畫面或 undefined。

效能考量。沒有分頁、沒有快取、沒有圖片壓縮。資料量一大就會慢到不能用。

安全設定。沒有 CORS 設定（或設成 *）、沒有 Rate Limiting、沒有 HTTPS、沒有 CSP。

技術債 vs 安全債

技術債是「以後要處理」的程式碼品質問題。安全債是「如果不處理可能被攻擊」的安全問題。在資源有限的情況下，安全債應該優先處理。

原因：技術債造成的問題是「功能不好用」，安全債造成的問題是「資料外洩」。一個載入慢 2 秒的頁面讓使用者不滿意；一個沒有認證的 API 端點讓攻擊者取得所有使用者資料。

安全債優先處理清單

第一優先：認證

從原型的無認證升級到生產環境的認證系統。

如果是 Next.js 專案，用 NextAuth.js（現在叫 Auth.js）。如果是獨立的前後端分離架構，用 JWT + refresh token。

不要自己實作密碼 hash。用 bcrypt（cost factor 至少 12）或 Argon2。AI 有時候會建議用 SHA-256 做密碼 hash，這不夠安全。

Session 管理要設定過期時間。JWT 的 exp 不要設超過 1 小時，搭配 refresh token 延長登入狀態。

第二優先：輸入驗證

前端驗證是給使用者看的提示，後端驗證才是安全防線。兩邊都要做。

用 Zod（TypeScript）或 Pydantic（Python）定義輸入格式：

// Zod 範例
const CreateOrderSchema = z.object({
  productId: z.string().uuid(),
  quantity: z.number().int().min(1).max(99),
  shippingAddress: z.string().min(10).max(200),
  note: z.string().max(500).optional()
});

AI 產生的原型通常直接把 req.body 或 request.json() 的內容拿來用，不做任何驗證。攻擊者可以送任意格式的 JSON 觸發未預期的行為。

第三優先：錯誤處理

把所有的 console.log(error) 換成適當的錯誤處理：

對使用者：顯示友善的錯誤訊息（「系統處理中，請稍後再試」），不要顯示 stack trace。

對開發者：用 logging 套件記錄錯誤細節（時間、請求路徑、錯誤訊息、stack trace），方便除錯。

對監控系統：整合 Sentry 或類似的錯誤追蹤服務，自動收集並分類錯誤。

第四優先：CORS 和安全 Headers

把 CORS 從 * 改成只允許你的前端域名：

// Express.js
app.use(cors({
  origin: ['https://your-app.com'],
  methods: ['GET', 'POST', 'PUT', 'DELETE'],
  credentials: true
}));

加上安全 Headers（X-Content-Type-Options、X-Frame-Options、HSTS）。

第五優先：Rate Limiting

登入端點、API 端點都要加上 Rate Limiting。不然上線後第一天就可能被掃描器打滿。

技術債處理清單

安全債處理完之後，再處理技術債：

分頁

原型通常一次載入所有資料。如果你的資料量超過 100 筆，加上分頁或無限捲動。API 加上 limit 和 offset 參數，預設一次回傳 20 筆。

快取

加入適當的 HTTP 快取 Headers。靜態資源（CSS、JS、圖片）可以設長期快取。API 回應根據資料更新頻率設定快取時間。

圖片優化

AI 產生的網站經常直接用原始大小的圖片。用 Next.js 的 Image 元件或手動壓縮圖片。WebP 格式比 JPEG 小 25-35%。

資料庫索引

原型跑得動是因為資料量小。上線後資料量增長，沒有索引的查詢會越來越慢。對常用的查詢欄位和外鍵加索引。

什麼時候該重寫

有時候原型的架構問題太根本，修補的成本超過重寫。以下情況建議重寫：

原型的資料模型和實際需求差距太大。例如原型用 JSON 檔案存資料，正式需要關聯式資料庫。

原型的技術棧和團隊技術能力不符。AI 用 Next.js 寫了原型，但團隊只會 Vue。

安全問題太多，修到後來等於每行都改過。

反過來說，如果原型的整體架構合理，只需要補上認證、驗證和錯誤處理，修補比重寫划算。

安全考量

原型到 MVP 的過程中，最危險的時刻是「原型直接上線」。飛飛見過團隊因為時程壓力，跳過安全檢查直接把原型部署到正式環境。然後在三天內被掃描器找到沒有認證的 API 端點。

用這篇的檢查清單做基本的安全處理，至少可以擋住自動化掃描和隨機攻擊。針對特定攻擊（Prompt Injection、商業邏輯漏洞），建議做一次專業的安全評估。

原型程式碼中可能包含 AI 工具的痕跡：TODO 註解、臨時的測試帳號、硬編碼的 API Key。上線前用 grep 搜尋這些痕跡：

grep -rn "TODO\|FIXME\|HACK\|password.*=.*['\"]" --include="*.{js,ts,py}" .
grep -rn "sk-\|api_key\|secret" --include="*.{js,ts,py,env}" .

知識檢測

讀完文章後，測試一下你對這個主題的理解。

常見問題