真用戶上門之前：AI 原型檢查清單
Lovable、Bolt、v0、Replit 和 Cursor 能很快做出像樣的演示。問題往往出現在後面：陌生人開始註冊、錢開始流動的時候。下面是我們接手任何原型時最先做的檢查。大多五分鐘就能做完，也不需要讀很多程式碼。
九項檢查
一個用戶能看到別人的數據嗎？
最常見、也最嚴重的漏洞。介面上把別人的記錄藏起來了，伺服器卻可能照樣把它們交給任何直接來要的人。
檢查：開兩個測試帳戶。從一個帳戶複製某條記錄的連結或 ID，用另一個帳戶打開。如果你的應用用 Supabase，確認每張存用戶數據的表都打開了 Row Level Security（行級安全）。
瀏覽器或程式碼庫裡有沒有密鑰？
支付密鑰、資料庫密碼和 AI 介面密鑰只能放在伺服器上。一旦跟著前端發到瀏覽器，任何人都能複製。
檢查：在程式碼庫裡搜「sk_」「secret」「password」，看有沒有提交 .env 檔案。找到的都挪到伺服器上，並且換一把新密鑰。
收款經得起真實情況嗎？
測試模式永遠順利。正式環境會遇到被拒的卡、退款、重複的回調，還有付到一半關掉頁面的客戶。
檢查：確認訂單是由驗證過的 webhook 標記為已付款，而不是客戶付款後跳轉到的那個頁面。上線前做一筆真實的小額付款和一次退款。
有備份嗎？有人恢復過嗎？
沒人恢復過的備份只是願望，不是備份。同時確認測試數據和真實數據放在不同的資料庫裡。
檢查：找到備份在哪裡設定、多久一次，然後把一份備份恢復到臨時資料庫裡試試。
出問題時你會知道嗎？
沒有錯誤監控，你發現 bug 的第一個信號，就是一個默默離開的客戶。
檢查：故意觸發一個錯誤，看有沒有人收到通知。沒有的話，上線前加上錯誤監控和在線檢測。
費用有上限嗎？
AI 調用、圖片處理和發電郵，單次很便宜，循環起來很貴。某天流量一大，或者來了機器人，一晚上就能刷出一張大帳單。
檢查：在每個服務商那裡設好費用上限，給註冊和所有 AI 介面加上頻率限制，公開表單加上防機器人驗證。
電郵真的送到了嗎？
註冊確認和重設密碼的電郵進了垃圾箱，用戶的感受和產品壞了一模一樣。
檢查：用你自己的域名發信，設好 SPF、DKIM 和 DMARC，再用 Gmail 和 Outlook 電郵各測一次。
用戶能離開嗎？知道你存了什麼嗎？
一份隱私說明、一個刪除帳戶的入口，只收集真正需要的數據。App Store、支付服務商和隱私法規（包括香港的《個人資料（私隱）條例》）都會這樣要求。
檢查：刪除一個測試帳戶，確認它的數據已經刪除或匿名化。
所有東西都在你名下嗎？
域名、伺服器、資料庫、收款帳戶、發信服務、程式碼庫，還有 AI 工具裡的那個項目本身。只要有一樣掛在外包或朋友的帳戶下，先把它處理掉。
檢查：列出應用用到的每個服務，以及誰擁有登入權限。不是你的，現在就轉過來，趁現在還容易。
修，還是重做？
大多數原型值得保留：頁面和流程都是實打實的工作。只有當數據結構跟每個新功能都打架，或者權限控制要處處重寫時，重做才划算。先審完程式碼再決定，別先下結論。