生產審計
當使用者詢問應用程式是否準備好上線、生產環境中可能會出什麼問題，或是在發布前必須修正哪些項目時，請使用此技能。這是對既有社群 production-audit 概念的安全維護重寫：保留有用的生產就緒檢視角度，移除未固定版本的外部執行與第三方資料共享。
使用時機
- 使用者問「這個可以上生產環境了嗎」、「生產環境會壞掉嗎」、「我們漏了什麼」、「審計這個儲存庫」，或「準備好發布了嗎？」
- 某個功能已合併，需要進行部署前或合併後的風險檢查。
- 接近公開發布、展示、客戶上線或投資者產品演示。
- CI 通過但使用者想要的是生產風險評估，而不只是測試狀態。
- 有可用的已部署 URL、release 分支、PR 或當前 checkout 來收集證據。
不應使用的時機
- 在積極實作階段，此時正確的視角是逐行安全編碼；應優先使用
security-review。 - 純函式庫、模板、僅含文件的儲存庫或專案骨架，除非使用者需要的是打包/發布就緒度而非應用程式就緒度。
- 使用者要求正式合規審計時。此技能屬於工程分類，不是法律、財務、醫療或法規認證。
- 唯一可用的證據是產品點子，沒有儲存庫、部署、CI 或執行時期表面。
運作方式
從本地和使用者授權的證據建立審計報告。不要執行未固定版本的遠端程式碼、不要將儲存庫內容上傳到第三方服務，也不要呼叫外部掃描器，除非使用者明確批准該特定工具和資料流。
請依下列順序進行：
- 確定發布表面。
- 讀取最近的變更和當前分支狀態。
- 檢查儲存庫中實際存在的執行時期、驗證、資料、付款、背景任務、AI 和部署邊界。
- 檢查 CI、測試、資料庫遷移、環境文件以及回滾路徑。
- 產生簡短的「發布/阻止」建議，並附上具體修正內容。
證據檢查清單
從便宜、本地的訊號開始：
git status --short --branch
git log --oneline --decorate -20
git diff --stat origin/main...HEAD
然後檢查專案特定的表面：
- 套件腳本、CI 工作流程、發布腳本、Docker 檔案和部署清單。
- API 路由、Webhook、驗證中介軟體、背景工作、排程任務和資料庫遷移。
- 環境變數文件和啟動檢查。
- 可觀測性掛鉤、錯誤回報、日誌、健康檢查和儀表板。
- 回滾、種子資料、遷移和資料回填的說明。
- 最重要的使用者路徑的端到端測試覆蓋率。
如果已部署的 URL 在範圍內，請僅使用瀏覽器或 HTTP 檢查來對付該 URL，並避免需要憑證的操作，除非使用者提供安全的測試帳號。
風險透鏡
安全性與驗證
- 公開路由、API 路由和管理路由是否清楚分離？
- 驗證和授權是否在伺服器端強制執行？
- 秘密是否未洩露到客戶端套件、日誌、範例輸出和已簽入的檔案中？
- 應用程式需要的地方是否設有速率限制、CSRF 保護、CORS 政策和上傳驗證？
- AI 或代理表面是否能防禦提示注入、工具濫用，以及不受信任的內容跨入特權操作？
資料完整性
- 遷移是否能順利向前執行，並且有回滾或復原計畫？
- 破壞性遷移、資料回填和資料匯入是否以安全的方式分階段進行？
- 資料庫策略、授權和服務角色邊界是否符合應用程式的租戶模型？
- 寫入操作、作業和 Webhook 處理程式的重試是否具有冪等性？
付款與 Webhook
- 在解析受信任的酬載欄位之前，是否先驗證了 Webhook 簽章？
- 每個付款、訂閱或履行 Webhook 是否都具有冪等性？
- 是否處理了重播、重複傳送和亂序傳送的情況？
- 測試模式和即時模式的憑證是否分離？
營運
- 應用程式能否根據文件中的指令從乾淨的 checkout 啟動？
- 必要的環境變數是否已命名、經過驗證且能快速失敗？
- 是否有健康檢查能證明相依元件是可達的？
- 部署、回滾和事件負責人的路徑是否有文件記錄？
- 日誌是否有用，且不會洩漏秘密或個人資料？
使用者體驗
- 最重要的上線路徑在桌面和行動裝置上是否都已涵蓋？
- 表單在行動裝置上是否不會出現輸入縮放、版面重疊或提交狀態被阻擋的問題？
- 載入中、空白、錯誤和權限拒絕狀態是否告訴使用者發生了什麼事？
- 當關鍵操作失敗時，是否有支援或復原路徑？
評分
使用分數來強制設定優先順序，而非暗示數學上的確定性。
| 等級 | 分數 | 意義 |
|---|---|---|
| 封鎖 | 0-49 | 在修復最高風險項目之前不要發布 |
| 高風險 | 50-69 | 僅在小規模推出或內部測試版後才能發布 |
| 可發布但有注意事項 | 70-84 | 如果擁有者接受列出的風險則可發布 |
| 穩健 | 85-100 | 從現有證據來看沒有明顯的發布阻礙 |
如果以下任何一項成立，則將分數上限設為 69：
- 敏感資料缺少驗證或授權。
- 付款或履行 Webhook 不具冪等性。
- 必要的遷移無法安全執行。
- 秘密暴露在客戶端套件、日誌或已提交的檔案中。
- 高影響發布沒有回滾路徑。
如果 CI 不是綠燈，或者最重要的上線路徑沒有經過端到端測試，則將分數上限設為 84。
輸出格式
以一句話開頭：
生產審計：76/100，可發布但有注意事項，需在公開發布前修正 Webhook 冪等性和回滾文件這兩個風險。
然後列出：
封鎖項目：部署前必須修正的項目。高價值修正：如果使用者想要提高分數，接下來要修正的項目。已檢查的證據：檢查過的檔案、指令、CI、已部署 URL 或 PR。遺漏的證據：如果能提供，會改變信心水準的內容。下一步行動：一個具體的修正或驗證步驟。
保持優勢簡短。使用者問的是就緒度，所以有用的答案是剩餘風險和下一步行動。
範例
使用者：
這個可以發布了嗎？
回應：
生產審計：68/100，高風險，因為 Stripe Webhook 已驗證但不具冪等性，且待處理的遷移沒有回滾說明。
封鎖項目：
- 在履行訂單前，為 `checkout.session.completed` 加入冪等性。
- 撰寫並測試 `20260511_add_billing_state.sql` 的回滾路徑。
高價值修正：
- 加入一個健康檢查來驗證資料庫和付款供應商的可達性。
- 為升級、Webhook 履行和帳單頁面重新整理加入一個端到端測試路徑。
已檢查的證據：
- `api/stripe/webhook.ts`
- `db/migrations/20260511_add_billing_state.sql`
- 釋出分支的 GitHub Actions 執行結果
下一步行動：要我先修補 Webhook 的冪等性嗎？
反模式
- 將執行
npx <package>@latest或遠端掃描器作為預設的審計路徑。 - 未經明確批准就將原始碼、秘密、客戶資料或私有拓撲上傳到外部審計服務。
- 產生分數卻未說明檢查過的證據。
- 將綠燈 CI 視為生產就緒。
- 以通用的「讓我知道你想做什麼」作結。
參見
- 技能：
security-review - 技能：
deployment-patterns - 技能：
e2e-testing - 技能：
tdd-workflow - 技能：
verification-loop