“vibe coding” 在美國區仍保持穩定搜索需求，相關查詢裏 Lovable 與 OpenCode 都在上升。
原型能演示，不代表它能承受真實用戶、真實數據和真實賬單。
下面十二道門檻按失敗影響排序，而不是按開發流程排成通用模板。
門檻一：團隊能解釋關鍵代碼
至少一名維護者能說明認證、支付、數據寫入與部署路徑。
無法解釋的生成代碼先隔離，不直接上線。
爲關鍵目錄指定代碼所有者。
門檻二：倉庫是唯一事實來源
所有生產代碼進入 Git。
低代碼平臺中的未同步修改必須導出。
默認分支開啓保護和狀態檢查。
每次部署能追溯到 commit SHA。
門檻三：依賴可以重複安裝
鎖文件必須提交。
在全新環境執行：
|
|
構建不能依賴某個開發者全局安裝的軟件。
檢查廢棄包、許可證和已知漏洞。
門檻四：密鑰從代碼中消失
|
|
前端環境變量會進入瀏覽器包，不能存放服務端 secret。
曾提交過的密鑰必須輪換。
生產和測試使用不同憑據。
門檻五：認證之外還有授權
登錄成功只證明用戶是誰。
授權決定用戶能讀取和修改什麼。
用兩個普通賬號測試橫向越權。
用普通賬號直接請求管理員 API。
前端隱藏按鈕不能代替服務端檢查。
門檻六：數據庫變更可向前兼容
先增加可空字段，再部署兼容代碼，最後收緊約束。
大表遷移評估鎖表時間。
刪除列和重命名不與應用發佈同步冒險完成。
在生產數據規模的副本上演練。
備份必須實際恢復過。
門檻七：輸入輸出都有邊界
服務端驗證類型、長度、格式和權限。
文件上傳檢查真實類型、大小和存儲路徑。
富文本按輸出上下文轉義。
URL 抓取阻止內網地址和重定向繞過。
錯誤響應不泄露堆棧與數據庫結構。
門檻八：支付和配額不能只在客戶端計算
價格、折扣和訂閱狀態在服務端確認。
Webhook 驗證簽名並防重複處理。
每個消耗型 API 有速率與費用上限。
免費額度不能通過換參數繞過。
人工可以快速暫停異常賬戶和功能。
門檻九：測試覆蓋失敗路徑
|
|
再測試登錄失敗、權限不足、第三方超時與數據庫不可用。
關鍵流程至少有一個端到端冒煙測試。
AI 生成代碼不得刪除或跳過裁判測試。
門檻十：日誌可定位但不泄密
每個請求有 request ID。
日誌記錄錯誤類型、耗時和版本。
Authorization、Cookie、密碼、完整提示和個人信息需要脫敏。
日誌保留週期與訪問權限明確。
告警指向可執行 runbook，而不是隻發一條紅色消息。
門檻十一：發佈採用漸進流量
先部署內部或小比例用戶。
觀察錯誤率、延遲、登錄成功率和費用。
數據庫遷移與應用版本分別有健康指標。
不要在週五晚上首次上線無法值守的功能。
功能開關應能關閉新路徑而不重新構建。
門檻十二：回滾在發佈前演練
上一穩定鏡像仍可部署。
配置變化有版本記錄。
數據庫不兼容時準備向前修復腳本。
第三方故障有降級頁面。
明確誰能決定回滾、誰執行、誰通知用戶。
用預演暴露隱藏依賴
創建與生產相似的 staging。
從空數據庫開始部署一次。
從上一版本升級一次。
斷開郵件、支付和 AI API 各測試一次。
模擬磁盤滿、配額耗盡和 DNS 失敗。
記錄恢復時間與缺失信息。
AI Agent 在發佈流程中的合理角色
Agent 可以生成測試、解釋 diff、整理依賴和執行只讀檢查。
它不應獨自批准生產部署、輪換主密鑰或刪除數據庫。
高風險命令保留人工確認。
Agent 的結論必須由 CI、監控或實際文件驗證。
發佈記錄應包含什麼
|
|
這些字段讓事故響應不依賴某個人的聊天記錄。
哪些情況應該推遲上線
沒有可恢復備份。
團隊不知道生產密鑰在哪裏。
登錄用戶能猜 ID 讀取他人數據。
部署無法映射到源碼版本。
第三方賬單沒有上限。
唯一維護者即將離線。
推遲一天通常比帶着未知數據風險上線便宜。
最終簽字表
| 負責人 | 需要確認的證據 |
|---|---|
| 開發 | CI、diff、版本與依賴 |
| 安全 | 密鑰、授權與負面測試 |
| 數據 | 遷移、備份與恢復 |
| 運維 | 監控、告警與回滾 |
| 產品 | 降級體驗與用戶通知 |
Vibe Coding 縮短的是原型時間，不會自動承擔生產責任。
只有十二道門檻都有證據，原型才真正變成可運營的軟件。
生產化延伸閱讀
建立發佈前的變更凍結窗口
進入生產發佈前，只接受阻塞上線的修復。新的 AI 生成改進進入下一個版本，避免驗收期間持續改變基線。
凍結開始時記錄 commit、依賴鎖文件、數據庫遷移和配置版本。任何例外修改都重新運行相關檢查。
爲第三方 AI API 設計降級
設置單請求超時、併發上限和賬號預算。供應商不可用時，頁面給出可理解的提示，而不是無限旋轉。
非關鍵生成功能可以暫時關閉；涉及數據寫入的 Agent 任務應停止並保留中間狀態，不能悄悄換模型繼續執行。
監控真實用戶路徑
首頁可訪問不代表產品可用。合成監控應覆蓋註冊、登錄、創建核心對象和退出，使用專門測試租戶。
支付流程不在生產反覆下單，可以監控配置、Webhook 健康和測試環境交易。關鍵指標同時設置錯誤率與延遲閾值。
用戶數據刪除要端到端驗證
刪除賬號時檢查主數據庫、對象存儲、搜索索引、分析平臺和異步隊列。備份中的刪除遵循公開保留策略。
發起刪除後生成內部任務 ID，用戶界面只展示進度，不暴露後臺存儲結構。
域名、郵件與安全響應頭
上線前驗證 HTTPS 自動續期、DNS 控制權和域名註冊賬號的 MFA。郵件域名配置 SPF、DKIM 與 DMARC，並用真實收件箱測試。
檢查 CSP、HSTS、X-Content-Type-Options 和合理的 Referrer Policy。CSP 先用報告模式觀察，再逐步收緊。
發佈後第一個小時
指定一名發佈負責人觀察錯誤、延遲、註冊、支付、數據庫連接與第三方費用。其他人避免同時進行無關部署。
預先寫好回滾閾值。例如五分鐘錯誤率持續超過基線三倍就暫停流量，而不是事故發生後臨時爭論。
覆盤 AI 生成部分
標記本次發佈中由 AI 首次生成、由 AI 修改和完全人工編寫的模塊。比較它們的缺陷與審覈時間，但不要據此簡單歸因。
真正需要改進的是提示、測試、權限還是架構，應由證據決定。把有效檢查加入下一次發佈門檻，形成可重複流程。
發佈完成二十四小時後再關閉值守事件。確認備份任務、費用告警和次日定時任務均正常，才把版本標記爲穩定。
穩定版本仍保留回滾目標，直到下一個版本通過同樣檢查。