AI 寫的 Code 在本機都能跑，為什麼部署到 Vercel 就掛掉？

這是一個經典場景：你用 Cursor 加上 "Vibe Coding" (意念流程式) 快速寫好了一個看起來超強的 SaaS，在自己的電腦上 (localhost:3000) 測試都完美無缺。你興奮地按下 Deploy，結果 Vercel 噴給你一片紅色的 Error，或是頁面打開一片空白。

為什麼？因為 AI 很會寫 Code，但它通常不懂架構。

以下是我們顧問團隊最常救援的三個「部署死亡之谷」：

1. 環境變數的失蹤案 (Environment Variables)

AI 會幫你在 .env.local 加上 API Key，讓你本機跑得動。但它常常忘記提醒你：Production 環境也需要這些變數。

在本機，process.env.SUPABASE_KEY 讀的是你電腦裡的檔案。在 Vercel 上，這檔案是不存在的 (因為 .gitignore)。

✅ 解法： 上線前，務必檢查 .env.local 裡所有的 key 值，是否都已經填入 Vercel 的 Project Settings > Environment Variables。

懶人包： 使用我們的發布前檢查清單 (Pre-flight Checklist) 來確認你沒有漏掉任何一個 Key。

這是最危險的陷阱。有時候為了方便，AI 會幫你寫這樣的 Policy：

create policy "Enable access to all users" on "todos"
for all using (true) with check (true);

這行程式碼的意思是：「全世界任何人都可以刪除你的資料庫」。在本機開發時因為這讓你方便測試，所以通常感覺不到問題。但一上線，這就是巨大的安全漏洞。

✅ 解法： 永遠不要使用 USING (true)。請確保你的 RLS 規則有包含 auth.uid()。

神器推薦： 擔心的話，把你的 Policy 貼到我們的 RLS 漏洞掃描器，讓 AI 幫你做資安健檢。

npm run dev 很寬容，它允許你有一些 Type Error 還是能跑。但 npm run build (Vercel 部署時跑的指令) 是無情的。只要有一個變數是 any 或是可能為 null，它就會拒絕部署。

AI 常常為了求快，寫出 any 或者忽略了 null check。

✅ 解法： 在推上 Github 前，一定要先在自己電腦跑一次 npm run build。如果出現錯誤，把錯誤訊息貼給 AI，並要求它：「Fix this build error, do not suppress it.」

卡關了嗎？ 去我們的 DevOps Prompt Library 複製「Vercel Build Error 專用咒語」，那是我們測試過解決率最高的指令。

從 Demo 到 Product，中間隔著一道「維運」的高牆。VibeAnchor 的存在，就是為了幫你架起這座橋。

如果你已經檢查了上面三點但還是修不好，歡迎預約我們的顧問服務，讓我們直接幫你 Debug。