Vibe Coding 完整流程：從想法、開發、測試到安全上線

Vibe Coding 的產出離「可上線」有多遠

Vibe Coding 的強項是快速把想法變成可執行的程式碼。用自然語言描述需求，AI 幫你產生功能程式碼，幾分鐘就能看到東西跑起來。

問題在於：能跑起來和能上線是兩回事。飛飛看過太多用 Vibe Coding 做出來的應用，功能看起來沒問題但缺少認證、輸入驗證是空的、錯誤處理只有 console.log、API Key 直接寫在前端程式碼裡。

一個真實的例子：有人用 Vibe Coding 做了一個內部員工請假系統，功能正常——可以登入、填假單、主管審核。但沒有 CSRF 保護、密碼以明文存在資料庫、session 永不過期、SQL 查詢用字串拼接。這些問題在 demo 的時候看不出來，但上線後任何一個都可能被利用。

這篇整理從想法到安全上線的 6 個階段，每個階段標注 Vibe Coding 能幫你做到什麼、什麼需要你自己補。

主流 Vibe Coding 工具比較

在開始之前，先了解你手上的工具各自擅長什麼。

選擇建議：如果你是工程師，Cursor 或 Claude Code 給你最大的控制權。如果你不懂程式碼，Bolt.new 或 v0 讓你最快看到成果，但安全補強的工作量也最大。不管用哪個工具，從原型到上線需要經過的安全關卡是一樣的。

階段一：需求釐清

在打開 AI 工具之前，先花 15 分鐘回答這幾個問題：

這個應用要解決什麼問題？用一句話描述。誰會用這個應用？有沒有使用者帳號系統？需要存什麼資料？資料的敏感程度是什麼（公開、內部、機密）？預期的使用者量是多少？需要哪些第三方服務（金流、寄信、地圖）？

這些問題的答案會決定後面每個階段的安全需求。一個純靜態的個人作品集網站和一個有使用者系統的 SaaS 應用，安全要求差距很大。

有效的 prompt 範例：

我要做一個內部用的員工請假系統。使用者是公司的 50 個員工。
需要登入功能、填假單、主管審核。
資料存在 PostgreSQL。
部署在公司的 GCP 上。
請幫我列出功能規格文件、使用者角色清單、
資料分類表（哪些是敏感資料），
以及第三方服務清單。

Vibe Coding 能做的：幫你整理需求文件、產生 User Story、建議技術選型。你可以把你的想法用口語化的方式描述給 AI，它會幫你結構化成明確的功能清單。

你要自己做的：商業目標確認、安全等級判斷、法規合規需求（個資法、金流法規）。這些需要你對業務和法規的理解，AI 可以提供參考但不能替你做決定。

需求釐清的實際產出應該包含：一份不超過一頁的功能規格文件、一份使用者角色清單（誰能做什麼）、一份資料分類表（哪些資料是敏感的）、一份第三方服務清單和它們各自的安全要求。

階段二：原型搭建

用 Vibe Coding 快速產生原型。這個階段的目標是驗證想法可行，不需要考慮生產環境的要求。

有效的做法：

用 AI 產生專案骨架（Next.js、FastAPI、Django）。一次只做一個功能模組，不要一口氣生全部。每完成一個功能就跑一次，確認行為正確。用 Git 記錄每個功能點的進度。

每個階段適合的 prompt 模式不同：

# 原型階段的 prompt
請幫我用 Next.js + Prisma + PostgreSQL 建立請假系統的骨架。
先做登入功能就好。
用 NextAuth.js 處理認證。
提供完整可執行的程式碼。

# 不好的 prompt（一次要太多）
請幫我做一個完整的請假系統，包含登入、請假申請、
主管審核、行事曆整合、通知信、報表產生、
管理員後台、手機版。

常見的陷阱：在原型階段就開始處理邊界情況和錯誤處理——原型階段的目標是驗證核心功能，細節留到下一個階段。另一個陷阱是在一次 prompt 裡要求 AI 做太多事。一次做登入系統、購物車、結帳流程、訂單管理，AI 產出的程式碼品質會很差。每次只做一個功能，做完確認正確再做下一個。

Vibe Coding 能做的：產生 UI 元件、API 路由、資料庫 Schema、基本的 CRUD 邏輯。

你要自己做的：確認 AI 產生的架構方向正確，技術選型適合你的需求。AI 可能幫你選了 MongoDB 但你的資料關係其實適合用 PostgreSQL，這種架構層級的決定要你自己判斷。

原型階段的品質標準：核心功能可以 demo 給利害關係人看、主要的使用流程可以走通、用 Git 記錄了每個重要的進度點。不需要的東西：錯誤處理、安全機制、效能優化、UI 設計。

階段三：安全補強

這是 Vibe Coding 流程中最容易被跳過的階段。原型跑起來了，功能都有了，很多人直接跳到部署。飛飛見過的 Vibe Coding 專案中，超過七成跳過了安全補強直接上線。

認證與授權

AI 產生的程式碼常常缺少 session 管理、密碼 hash、JWT 過期設定、角色權限檢查。具體檢查項目：

密碼是否用 bcrypt 或 argon2 hash？不要用 MD5 或 SHA-256，它們不是為密碼設計的。Session 是否有過期時間？建議 Web 應用設 24 小時，敏感操作要求重新驗證。JWT secret 是否夠長（至少 256 bits）且從環境變數讀取？API endpoint 是否檢查使用者角色？

安全補強階段的 prompt 範例：

請檢查以下登入相關程式碼的安全性，
特別注意以下項目：
1. 密碼 hash 方式
2. Session 過期設定
3. JWT secret 管理
4. CSRF 防護
5. 登入失敗的暴力破解防護
（貼上你的認證程式碼）

輸入驗證

每個接受使用者輸入的地方都需要驗證：API endpoint 的 request body、URL 參數、query string、檔案上傳的類型和大小。AI 產生的程式碼很少做輸入驗證。用 zod（TypeScript）、pydantic（Python）或 Joi（Node.js）做結構化驗證，不要手寫 if/else。

環境變數

找出程式碼中所有的硬編碼值（API Key、資料庫連線字串、第三方服務的 Secret），全部改為環境變數。搜尋關鍵字：sk-、pk-、key=、password=、secret=、token=、mongodb://、postgresql://、mysql://。

資料庫安全檢查清單

AI 產生的資料庫程式碼常犯的錯誤：

SQL 查詢用字串拼接而非 parameterized query。正確做法是用 ORM（Prisma、SQLAlchemy、Django ORM）或 prepared statement。錯誤示範：f"SELECT * FROM users WHERE id = {user_id}"。正確示範：db.query("SELECT * FROM users WHERE id = $1", [user_id])。

資料庫連線沒有用連線池（Connection Pooling）。每次查詢都建立新連線，在高流量下會耗盡連線數。Node.js 用 pg-pool，Python 用 SQLAlchemy 的 pool 設定，或在 PostgreSQL 前面加 PgBouncer。

備份沒有加密。資料庫備份檔跟正式資料一樣敏感。用 pg_dump 備份後，用 GPG 或 AES-256 加密再存到 S3/GCS。定期測試備份還原流程，確認備份檔真的能用。

資料庫帳號權限過大。應用程式用的帳號不需要 DROP TABLE 或 CREATE DATABASE 的權限。建立一個只有 SELECT、INSERT、UPDATE、DELETE 權限的帳號給應用程式用。

安全標頭和 CORS

加上 Content-Security-Policy、X-Frame-Options、Strict-Transport-Security、X-Content-Type-Options、Referrer-Policy 等 HTTP 安全標頭。Express.js 用 helmet 套件一行搞定。Next.js 在 next.config.js 裡設定 headers。

AI 產生的程式碼常常把 CORS 開成 *（允許所有來源），這在開發時方便但上線時要改成只允許你的前端域名。

Rate Limiting

API 加上請求頻率限制，防止暴力破解登入和 API 濫用。Express.js 用 express-rate-limit，FastAPI 用 slowapi。建議登入 API 設定每個 IP 每分鐘最多 10 次嘗試。

依賴套件檢查

跑 npm audit 或 pip-audit，修復所有高風險和嚴重等級的漏洞。檢查 package.json 裡每個套件的最後更新日期，超過兩年沒更新的套件要特別注意。

階段四：測試

AI 產生的程式碼特別需要測試，因為你不是逐行寫出來的，你對程式碼的理解深度不如手寫時高。

測試的優先順序：

第一優先：API endpoint 的輸入驗證測試。送入空字串、超長字串（例如 10 萬個字元）、特殊字元（<script>alert(1)</script>）、SQL Injection 攻擊字串（' OR 1=1; --）、超出範圍的數值（負數、零、極大值），確認都被正確處理。

第二優先：認證和授權測試。未登入的使用者能否存取需要認證的頁面？一般使用者能否存取管理員功能？過期的 token 是否被正確拒絕？修改 URL 中的 user ID 能否看到別人的資料（IDOR 測試）？

第三優先：核心業務邏輯的單元測試。確認計算結果正確、狀態轉換符合預期。邊界條件特別重要：金額為零的訂單、數量超過庫存的購買、時區跨日的排程。

第四優先：整合測試。API 到資料庫的路徑是否正確。多個 API 串在一起的流程（例如建立訂單 → 扣庫存 → 產生出貨單）是否正確。

Vibe Coding 能做的：產生單元測試的骨架、邊界條件的測試案例。你可以把你的函式或 API 定義貼給 AI，讓它產生測試案例。AI 在產生正常路徑的測試上做得不錯，但常常遺漏安全相關的邊界條件——這些你要自己補。

階段五：部署前檢查

錯誤處理與日誌

錯誤處理的原則：不要把 stack trace 直接回傳給前端使用者。Stack trace 會洩漏檔案路徑、資料庫結構、使用的框架版本。正確做法是回傳通用的錯誤訊息給使用者（例如「系統發生錯誤，請稍後再試」），但在伺服器端的日誌中記錄詳細的錯誤資訊。

// 錯誤示範
app.use((err, req, res, next) => {
  res.status(500).json({ error: err.stack });
});

// 正確做法
app.use((err, req, res, next) => {
  logger.error({ err, requestId: req.id, path: req.path });
  res.status(500).json({ error: '系統發生錯誤，請稍後再試', requestId: req.id });
});

日誌記錄的原則。應該記錄的：使用者的操作行為（登入、登出、重要功能的使用）、API 請求的狀態碼和回應時間、錯誤和例外（含 stack trace，但只記在伺服器端）、安全相關事件（登入失敗、權限被拒絕、異常存取模式）。

不應該記錄的：使用者的密碼（包含 hash 後的密碼）、信用卡號碼、身分證字號、完整的 API Key 或 Secret（如果需要識別，只記最後四碼）、醫療或健康資訊。

Docker 和容器部署安全檢查清單

如果用 Docker 部署，這些是常見的安全問題：

不要用 root 使用者跑應用程式。在 Dockerfile 中建立專用使用者：

RUN addgroup --system app && adduser --system --ingroup app app
USER app

不要把機密寫在 Dockerfile 或 docker-compose.yml 裡。用 Docker secrets 或環境變數注入。不要把 .env 檔加進容器映像檔——在 .dockerignore 裡排除它。

使用特定版本的 base image，不要用 latest tag。node:20-alpine 比 node:latest 好，因為你知道用的是什麼版本，安全更新可控。

定期用 docker scout cves 或 Trivy 掃描容器映像檔的已知漏洞。

CI/CD 管線安全設定

用 GitHub Actions 設定一個包含安全掃描的部署管線：

name: Deploy with Security Checks
on:
  push:
    branches: [main]

jobs:
  security:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Install dependencies
        run: npm ci
      - name: Run tests
        run: npm test
      - name: Security audit
        run: npm audit --audit-level=high
      - name: SAST scan
        uses: github/codeql-action/analyze@v3
      - name: Build
        run: npm run build
      - name: Deploy
        if: success()
        run: ./deploy.sh

重點是把安全掃描放在部署之前。任何一個步驟失敗就停止部署。不要在 CI/CD 管線中用 npm audit fix --force，因為它可能自動升級主要版本造成相容性問題。

SSL/TLS 與域名安全

HTTPS 是上線的基本要求。使用 Let's Encrypt 取得免費的 SSL 憑證。如果部署在 Vercel、Netlify 或 Cloudflare Pages 上，HTTPS 是預設開啟的。如果自架伺服器，用 Certbot 自動化憑證的取得和續約。

DNS 安全設定：開啟 DNSSEC 防止 DNS 劫持。設定 CAA 記錄限制哪些 CA 可以簽發你的網域憑證。不要在 DNS 記錄中暴露內部伺服器的 IP（用 CDN 或反向代理隔開）。

程式碼檢查

所有 console.log 和 debug 資訊已移除。沒有硬編碼的密碼、API Key 或 Token。所有使用者輸入都有驗證。SQL 查詢使用 parameterized query。沒有把 stack trace 直接回傳給前端。

設定檢查

環境變數正確設定（production 值和 development 值不同）。Debug mode 已關閉（Django 的 DEBUG=False、Express 的 NODE_ENV=production）。HTTPS 已設定且強制跳轉。CORS 設定只允許必要的 origin。資料庫連線使用 SSL。

基礎設施檢查

防火牆只開放必要的 port（通常只需要 80 和 443）。資料庫不直接暴露到公網（只允許應用伺服器連入）。備份機制已設定（至少每天一次，測試過還原流程）。如果有用雲端服務，確認 IAM 權限是最小必要。

監控工具選擇

小型專案建議：Sentry 免費方案做錯誤追蹤 + Uptime Robot 免費方案做可用性監控。這兩個組合不花錢就能覆蓋最基本的監控需求。

容量規劃

預估上線後的使用者量和請求量。做一次基本的壓力測試（用 k6 或 Apache Benchmark），確認你的伺服器撐得住。設定自動擴展（如果是雲端部署）或至少設定一個警報在 CPU 或記憶體過高時通知你。

階段六：上線與維護

上線當天

跑一次功能測試。用 Lighthouse 檢查效能和無障礙。用 Mozilla Observatory 或 SecurityHeaders.com 檢查安全標頭。確認 SSL 憑證正確（沒有 mixed content 警告）。在不同瀏覽器和裝置上測試。

上線後第一週

監控錯誤日誌，看有沒有預期外的錯誤。觀察使用者行為，看有沒有功能不如預期的地方。監控效能指標，確認回應時間在可接受的範圍內。如果有發現問題，評估嚴重程度——影響安全的立即修、影響體驗的排進下週的 sprint。

持續維護

每週更新依賴套件（至少 security patch）。每月跑一次 npm audit 或 pip-audit。每季做一次安全檢視（OWASP Top 10 對照）。如果使用者量增加，定期做壓力測試確認容量足夠。關注你使用的第三方服務的公告，它們的 API 變更或停用可能影響你的應用。

技術債管理

Vibe Coding 產生的程式碼，技術債的累積速度比手寫的快。常見的技術債包含：重複的程式碼（因為是一個功能一個功能分別請 AI 寫的，沒有共用邏輯）、不一致的命名風格（不同次 AI 對話產生的程式碼風格可能不同）、過度依賴特定框架的特性（AI 傾向用它最熟悉的解法）。

建議每個月花半天時間專門處理技術債，可以用 Vibe Coding 來做重構——把重複的邏輯抽成共用函式、統一命名風格、更新過時的寫法。

從原型到上線的成本估算

很多人低估了從原型到上線的投入。以下是一個中等複雜度應用（有使用者系統、資料庫、第三方整合）的粗略估算：

總結：原型可能一兩天就能做好，但安全補強和測試通常需要原型開發時間的 2-3 倍。這不是浪費時間，是保護你的使用者和你自己。

實際案例：一個副專案從 Vibe Coding 到上線

飛飛的一個學生用 Cursor + Claude 做了一個線上讀書會排程工具。以下是他的時間線：

第 1 天：用 Cursor 產生 Next.js 專案骨架，包含 Google 登入、活動建立、報名功能。原型可以 demo，核心流程能走通。

第 2-3 天：安全補強。發現的問題包含：API 路由沒有檢查使用者是否登入（任何人知道 URL 就能改活動）、Google OAuth 的 redirect URI 寫死 localhost、表單沒有做輸入長度限制（活動名稱可以輸入 10 萬個字）、所有使用者都能刪除任何活動（沒有權限檢查）。

第 4 天：寫測試。重點放在權限檢查（只有建立者能編輯和刪除活動）和輸入驗證（活動名稱限制 100 字、日期不能是過去、同一時段不能重複報名）。

第 5 天：部署到 Vercel，設定自訂域名和 SSL。用 Sentry 免費方案做錯誤追蹤。用 Uptime Robot 監控網站可用性。

上線後第一週：Sentry 抓到一個 TypeError（某個 API 回傳格式跟預期不同），修了。收到使用者回報時區顯示錯誤（他用 new Date() 但沒處理時區），修了。

這個時間線代表的是一個有基本程式經驗的人的節奏。如果完全不懂程式碼，安全補強的時間可能要加倍，或者直接請有經驗的工程師協助。

常見錯誤清單

在輔導過數十個 Vibe Coding 專案後，飛飛整理了最常見的 10 個錯誤：

1. API Key 寫在前端程式碼裡。前端的程式碼任何人都看得到。API Key 必須放在後端，前端透過自己的後端 API 間接呼叫第三方服務。

2. CORS 設成 * 就上線。開發時方便，上線時要改成只允許你的前端域名。否則任何網站都能呼叫你的 API。

3. 沒有 Rate Limiting。攻擊者可以用自動化工具每秒發幾百個請求，暴力破解登入或耗盡你的資源。

4. 錯誤訊息洩漏內部資訊。{"error": "Column 'password' cannot be null at users.insert()"} 這種訊息告訴攻擊者你的資料庫結構。

5. 用 localStorage 存 token 但沒有防 XSS。如果你的應用有 XSS 漏洞，localStorage 裡的 token 會被偷走。敏感 token 用 httpOnly cookie。

6. 檔案上傳沒有限制類型和大小。使用者可以上傳執行檔或 GB 等級的檔案。限制允許的 MIME type 和檔案大小。

7. 環境變數只設了開發環境。production 的資料庫、API Key、redirect URI 都要另外設定，不能用 development 的值。

8. 沒有設定 HTTPS 強制跳轉。使用者可能用 HTTP 連上你的網站，傳輸中的資料（包含 cookie 和認證資訊）可能被竊聽。

9. 依賴套件有已知漏洞但不理。npm audit 報了一堆 critical 但沒去處理。至少要修 critical 和 high 等級的漏洞。

10. 備份沒有測試還原。有備份不等於能還原。定期測試從備份完整還原系統的流程。

安全與限制

Vibe Coding 降低了開發門檻，但沒有降低安全門檻。不管程式碼是人寫的還是 AI 寫的，上線前需要通過的安全檢查是一樣的。

如果你的應用處理使用者個資（包括 email、姓名、電話），需要符合台灣個資法的要求。這包括：蒐集時的告知義務、資料的安全保護、使用者的查閱和刪除權利。不確定的話，找法務或隱私顧問確認。

對於沒有資安背景的開發者，建議在上線前找有經驗的人做一次安全 Review。OWASP Top 10 是一個好的起點，至少確認你的應用沒有這十項常見漏洞。OWASP 提供的測試指南（Testing Guide）是免費的，裡面有每個漏洞的檢測步驟。

Vibe Coding 的另一個限制是：AI 產生的程式碼你不一定理解。當線上出問題時，你可能花更多時間 debug，因為你對程式碼的熟悉度比手寫的低。解法是在開發過程中，每當 AI 產生一段你看不太懂的程式碼，就請它解釋。理解每一段程式碼的作用，是你在出問題時能快速反應的基礎。

AI 工具本身也有安全考量。你在 prompt 中貼的程式碼和業務邏輯，會被傳送到 AI 服務商的伺服器。如果你的專案包含商業機密或敏感的業務邏輯，需要確認你使用的 AI 工具的資料處理政策。Cursor 和 Claude Code 都有不同的隱私模式設定，使用前先了解。

常見問題

相關文章

• 如何安全地讓 Claude Code 修改現有專案？
• 從 AI 原型到 MVP：技術債與安全債的管理
• 用 AI 做網站：從零到上線的 10 步驟
• AI 後端開發：Node.js/Python API 的安全開發指南

參考資料

• OWASP Top 10
• Mozilla Observatory
• Lighthouse CI
• OWASP Testing Guide
• Docker Security Best Practices（Docker 官方文件）