AI Coding 商業軟件上線前安全 Checklist
AI coding 可以很快做出 prototype，但當 prototype 開始處理真實用戶、付款、文件、客戶資料或內部審批時，業務風險就開始出現。上線前真正要問的，不是 app 能否成功跑一次，而是當真實用戶使用時，系統是否會安全地失敗。
1. 分開 prototype 風險和 production 風險
Prototype 可以粗糙，因為它的任務是測試想法是否值得做。Production software 的任務不同：它要保護資料、處理錯誤輸入、面對局部故障，並讓團隊在出事時有方法支援用戶。
上線前先分類系統：它是 public marketing page、internal workflow、payment flow、customer portal，還是有 tool access 的 AI Agent？不同類型需要不同 review 深度。Public page 可能只需要 form validation 和 spam control。付款或客戶資料系統就需要更深入檢查。
2. 檢查 secrets 和 environment variables
AI-generated code 看起來完整，很多時是因為 examples 直接放入 keys、tokens 和 URLs。如果任何 secret 進入 repo、browser bundle、logs、screenshots 或 support messages，就會很危險。所有 secret 都應放在 hosting provider 的 secret store 或 environment config。
檢查 API keys、private tokens、database URLs、Stripe secrets、email credentials、OAuth secrets 和 webhook signing secrets。亦要檢查 generated config files 和 test fixtures。即使 secret 只在 test file，只要 repository 會被分享，仍然有外洩風險。
3. 分開驗證 authentication 和 authorization
Authentication 是確認用戶是誰。Authorization 是確認該用戶可以做什麼。AI-generated code 很容易做到第一步但忘記第二步，特別是在 dashboard 和 internal tools。
每個 route 和 API endpoint 都要問：誰可以 access？然後再問：誰可以修改、刪除、export、upload、approve、invite、refund 或查看敏感記錄？如果答案是「frontend 隱藏了按鈕」，系統其實未受保護。Authorization 必須在 server-side 執行。
4. 將所有輸入視為不可信，包括公司內部輸入
Forms、file uploads、webhooks、query strings、AI prompts、CSV imports 和 admin fields 都是 input。商業團隊常以為 internal tools 可以信任內部用戶，但錯誤資料和複製貼上仍然可以令系統出事。
檢查長度、類型、必填欄位、file size、file type 和 allowed values。Render user-provided text 前要 escape。如果系統會將 input 放入 LLM prompt，要定義哪些資料可以進入 prompt，以及模型可以回傳什麼。
5. 測試付款、電郵和不可逆 actions
付款和電郵會產生外部後果。錯誤 retry 可能重複扣款，缺少 idempotency key 可能重複建立 order，錯 recipient 可能將私人資料寄錯人，沒有 confirmation 的 admin action 可能刪除重要資料。
上線前要測試 happy path、failure path、retry path、cancellation、webhook replay、duplicate submission 和 permission failure。對不可逆 actions，要加入 confirmation、logging 和 recovery plan。測試要證明第三方服務變慢或回傳意外 status 時會發生什麼。
6. Logs 要幫到 support，而不只是存在
公司不需要噪音 logs。公司需要足夠資料回答支援問題：誰做了什麼、何時發生、影響哪個 record、外部 provider 是否接受 request，以及用戶看見什麼。
不要記錄 secrets、完整付款資料、raw access tokens 或不必要個人資料。重要 actions 應用 structured events。對 AI Agents，要記錄 tool calls、input category、output status 和 guardrail decisions，方便團隊調查壞結果。
7. Review dependencies 和 generated packages
AI coding tools 可能建議過時、不必要、維護不足，或範圍過大的 package。每個新 dependency 都會增加未來維護和安全 surface。
Review 時要問：這個 package 是否真的需要？專案是否已有相同能力？Package 是否仍然維護？它是在 browser 還是 server 跑？對細小 utilities，自寫少量 code 可能比加入新 dependency 更安全。
8. 令 launch decision 可見
最後 review 不應只是感覺 app 看起來正常。應該建立 launch note：改了什麼、測試了什麼、仍然有哪些風險、使用哪些 credentials、誰可以 access，以及如何 rollback。
這就是 operator workflow 比 unmanaged vibe coding 好的地方。輸出不只是 code，而是 code 加上業務可以安全使用的證據。