生產就緒度 (MVP → 生產環境)

目標：以證據向產品負責人說明該產品是否已準備好供真實用戶使用、哪些因素阻礙了上線，以及為彌補差距所需的最小工作量。所有評估都根據產品的實際規模而定——絕不使用通用的 200 項願望清單。

嚴格規則

要有證據，否則視為「未知」。 每一項都必須標記為「通過 / 有差距 / 不適用 / 未知」，而「通過」需要提供證明（檔案路徑、配置、CI 執行結果、儀表板、文件連結）。絕不能僅憑 README 中的宣稱就標記為「通過」。
根據分級調整規模。 不要對一個只有 50 名用戶的 Beta 版要求多區域災難復原。每個缺口都需標註其在哪個分級下為必要。
即時驗證平台規則。 應用程式商店、OAuth、金流以及電子郵件寄送者的規則每年都可能變更。在引用商店/供應商的要求前，必須查閱該供應商最新的官方文件（網路搜尋），並在報告中引用連結及查閱日期。
重複使用，避免重複造輪。 如果已有 pm-ai-shipping:ship-check、security-audit-static、performance-audit-static 或 derive-tests 等技能可用，請直接執行它們來取得程式碼層級的證據，並將結果整合進來。此技能負責程式碼以外的一切。
輸出要簡潔明瞭。 產品負責人只需閱讀一頁計分卡；詳細的資訊則放在附錄和待辦清單中。
治理應內建於工作流程中，而非最後才做。 優先採用那些在實際開發（CI、PR 範本、pre-commit hook、產品內的防護機制）中自動執行的檢查，而不是在上線前才臨時召開審查會議。只在上線前才執行的關卡會成為瓶頸。
產品上線 ≠ 產品被採用。 大多數產品在上線後停滯不前，是因為人員和流程沒有改變，而不是程式碼出了問題。生產就緒度必須包含採用計畫（領域 13），而不只是系統本身。

就緒度分級

分級	意義	典型標準
T1 公開測試	有真實用戶，但規模小，可容忍部分停機	無機密外洩、身分驗證穩固、備份可還原、錯誤可追蹤、法律頁面完備、能回滾
T2 正式上市	有付費用戶，具有 SLA 期待	+ SLO/警報/ON-CALL、通過負載測試、有操作手冊、有支援管道、整合有降級方案
T3 企業級 / 受監管	B2B 合約、涉及 PHI/PCI/兒童、須通過稽核	+ SSO/SCIM、稽核日誌、DPA/BAA、滲透測試、SOC 2 / HIPAA 控制措施、災難復原演練

工作流程

步驟 0 —— 分析產品（一次問完，批次詢問）

收集：目標分級與預計上線日期；唯一成功的指標及其目標值（如何判斷這次上線是成功的？用什麼指標衡量？何時達到？）；指定的負責人與簽核的利害關係人（產品、工程、安全、法務/隱私、支援、行銷——若涉及個人資料、AI 輸出或受監管用戶，第一天就要標記法務/隱私）；產品介面（Web、iOS、Android、桌面端、公開 API、CLI、瀏覽器擴充功能、分發給其他開發者的開發工具/外掛/函式庫）；主機/技術棧；資料類型（PII、PHI、金流、兒童資料）；用戶類型（B2C/B2B）；營運地區（美國/歐盟/其他）；AI/LLM 功能；金流；每個外部整合（消費的 API、接收的 Webhook、上架的 Marketplace/應用程式商店、SSO/IdP）。先掃描程式碼倉庫（package manifest、環境變數範本、SDK imports）來預填整合清單，然後只請產品負責人確認或補齊缺口。

產品分析結果會決定哪些模組需要評估。將其記錄在報告的最頂端。

步驟 1 —— 收集證據

倉庫（程式碼、CI 配置、IaC、環境變數範本、資料庫遷移腳本）、主機儀表板（如可連接，例如 Vercel、Railway、Supabase、Render 等）、問題追蹤器、現有文件。執行可用的稽核技能。記錄下哪些部分無法檢查 → 標記為「未知」。

步驟 2 —— 評估核心領域（永遠執行）+ 相關模組

對每個項目進行評分。嚴重程度：阻擋（在目標分級下無法上線） / 高（上線後兩週內必須修復） / 之後再處理。

步驟 3 —— 產出結果

計分卡（一頁）： 「可行」/「有條件可行」/「不可行」；阻擋項目數量；每個領域的紅黃綠表格；用白話文說明的五大風險。
缺口待辦清單： 每個缺口一張工單——標題、為何重要、驗收標準、需要何種證據才能關閉、分級、嚴重程度、大約規模（小/中/大）。如果已連接 Linear/Jira/GitHub Issues，則提供選項直接建立為一個專案/里程碑；否則提供表格。
強化工具包（依要求提供）： 根據該倉庫實際使用的技術，產生專屬的 CI 品質閘門、代理規則檔（CLAUDE.md/.cursorrules）、.env.example、操作手冊草稿——而不是直接套用範本。
重新執行模式： 在後續執行時，與上次報告進行比對，只顯示有變動的部分。

核心領域（永遠評估）

1. 機密與配置 —— 程式碼或 Git 歷史中無機密資訊（對整個歷史使用 gitleaks/trufflehog）；.env 已被忽略，有提供 .env.example；正式環境機密存放在平台的機密儲存服務中；開發/暫存/正式環境使用不同的金鑰；有輪換計畫以及誰可以輪換；金鑰外洩的應對步驟。

2. 身分與存取 —— 使用經過驗證的驗證提供者或廣受好評的函式庫（絕不可自行實作密碼學）；每個資料路由都需有伺服器端的授權檢查（檢查是否有 IDOR、缺乏租戶過濾、過於寬鬆的 RLS）；會話/Token 的生命週期與撤銷機制；登入、註冊、重設密碼、OTP 等端點需有速率限制；管理員需啟用 MFA；服務帳戶遵循最小權限原則；管理員操作需記錄日誌。

3. 邊界與應用程式安全性 —— HTTPS + HSTS；安全標頭（CSP、frame-ancestors 等）；嚴格的 CORS；在邊界進行輸入驗證；檔案上傳大小限制/類型檢查；對 URL 擷取器實施 SSRF 防護；在 T2+ 階段啟用 WAF/機器人防護；依賴套件掃描 + lockfile；在 CI 執行 SAST；在 T3 階段產出 SBOM 與授權檢查。

4. 資料 —— 自動備份 以及經過測試的還原流程（記錄實際還原時間）；資料庫支援的時間點還原；向後相容的遷移策略（擴展 → 遷移 → 收縮）；暫存環境不使用原始正式 PII 資料；資料保留與刪除路徑（用戶帳戶刪除需確實從資料庫、儲存、日誌、第三方供應商等處刪除）；確認預設已啟用靜態/傳輸中加密。

5. 可靠性 —— 每個外部呼叫都需設定逾時；對等冪操作使用具備 backoff + jitter 的重試機制；金流、Webhook、後台任務使用冪等金鑰；後台工作使用持久佇列；當相依服務異常時需有優雅降級機制；在 T2+ 階段定義 SLO（可用性、延遲）；在 T2+ 階段於預期尖峰流量 ×3 的情況下執行容量/負載測試。

6. 可觀測性 —— 具備釋出版本標記的錯誤追蹤（例如 Sentry）；結構化日誌包含請求/追蹤 ID 以及 PII 遮罩；每個端點的關鍵指標（速率、錯誤、持續時間）；從外部進行正常運行監控；將症狀式警報路由給實際會看到的人；為上線日準備儀表板。

7. CI/CD 與釋出 —— 主要分支的必要檢查（Lint、型別檢查、測試、機密掃描、依賴審計）；預覽/暫存環境；已驗證過一次的一鍵回滾；對風險功能使用功能開關；資料庫遷移在部署時安全執行；釋出說明/變更日誌；分支保護。

8. 測試 —— 對關鍵路徑進行測試（身分驗證、金流、資料寫入、權限），不只是追求覆蓋率百分比；對真實資料庫進行整合測試；部署後對主要用戶旅程進行 E2E 煙霧測試；對外部 API 使用合約測試或錄製的 fixture。

9. 效能與成本 —— Core Web Vitals / 應用程式啟動時間預算；N+1 查詢及缺少索引的檢查；快取/CDN；每個供應商的成本警示與硬性上限（雲端、LLM、SMS、郵件）；每個活躍用戶的成本估算；可能導致費用暴漲的濫用情境（註冊垃圾郵件、LLM Prompt 循環、SMS 充值詐騙）。

10. 營運與支援 —— 即使只有一人，也需指定負責人/ON-CALL；事件處理流程（嚴重程度、溝通、事後檢討）；針對前五大故障模式提供操作手冊；在 T2+ 階段提供狀態頁面；提供支援管道與 SLA；為常見的支援任務提供管理工具（避免需要直接操作 SQL 才能解決問題）。

11. 法務與信任 —— 條款、隱私權政策需與實際資料流相符；在需要的地區（歐盟/英國）提供 Cookie 同意機制；與處理個人資料的供應商簽訂 DPA；在 T3 階段提供子處理者清單；無障礙目標（WCAG 2.2 AA）及基本稽核；開源授權合規；產品名稱的商標/名稱清查。

12. 產品就緒度 —— 啟動漏斗的分析（需取得同意）；新手引導與空白狀態；交易性郵件可送達（見 Web 模組）；幫助文件/常見問題；若為付費產品，價格/帳單系統需已上線；回饋迴圈；針對問題功能的緊急停止開關。

13. 採用與營運模式 —— 在上線前即書面定義成功指標與試用版退出標準（如何判斷何時從試用版轉為「全面推廣」或「終止」）；記錄完整的釋出工作流程，包含針對不同風險等級指定的核准者（低風險變更 = 一人審查，高風險變更 = 多人審查）以及協調好的 turnaround 時間，避免簽核成為瓶頸；上線溝通文件（說明哪些會變、哪些不變、已知限制）；第一批用戶/擁護者群體，以及能從他們那裡獲得回饋的管道；產品內說明的幫助、範本或範例，讓用戶能在工具內學習；回饋迴圈（用戶回饋 + 使用指標）並設定定期檢討節奏（例如上線後 30/60/90 天，之後每季一次）；指定隨著使用量成長而持續提供支援的負責人。

條件式模組

M1. 你消費的整合（每個供應商一張表） —— 正式環境帳號/金鑰（非沙箱）及帳號擁有者；速率限制與配額 vs 預期尖峰；定價上限與警示；驗證類型與 Token 刷新；Webhook 簽章驗證、重放保護、冪等處理器、重試/backoff 與死信佇列；API 版本鎖定 + 棄用監控（訂閱更新日誌）；逾時 + 斷路器 + 對用戶可見的降級方案；訂閱供應商狀態頁面；服務條款允許你的使用方式（轉售、AI 訓練、爬蟲）；退出計畫——你擁有自己的資料/Prompt/配置並可匯出，合約無多年綁定且無違約金條款；資料駐留/DPA；OAuth 應用程式驗證/審查要求（例如 Google 敏感/受限範圍、Microsoft 發行者驗證、Slack/Zoom 應用審查）——即時驗證現行規則。

M2. 你開放的公開 API —— 發布 OpenAPI/Spec；版本管理與棄用政策；API 金鑰/OAuth 搭配範圍、輪換與撤銷；每個金鑰的速率限制與配額；對 POST 請求提供分頁與冪等金鑰；統一的錯誤格式；沙箱環境；你發送的 Webhook 需有簽章、重試與重放機制；開發者文件 + 變更日誌；若為付費服務，提供用量計量。

M3. 行動端與應用程式商店 —— 在引用之前，必須根據每個商店最新的官方文件進行驗證：

Apple： App Review 指南；隱私權營養標籤需與實際資料收集相符；隱私權清單需包含第三方 SDK；若 App 允許建立帳號，則必須提供 App 內帳號刪除功能；當提供第三方登入時，須檢查是否需支援「Sign in with Apple」；針對數位商品需遵守 IAP 規則；TestFlight 外部測試；出口合規。
Google Play： 最新的目標 API 等級截止日期；Data safety 表單；新個人開發者帳號的封閉測試要求；Play App Signing 與上傳金鑰的保管；帳號刪除的網頁連結。
兩者共通： Crash 回報；針對破壞性 API 變更的強制/軟更新機制；Deep/universal links；推播憑證需由公司帳號持有；商店 listing 素材、年齡分級、支援 URL、隱私權 URL；在上線計畫中為審查被拒預留緩衝時間（以天計，而非小時）。

M4. Web 與電子郵件 —— 自訂網域、DNS 由公司帳號持有、註冊商鎖定 + 自動續約；若可被搜尋發現很重要，則需具備 SEO 基礎（標題、Sitemap、Robots、OG 標籤）；404/500 頁面；電子郵件寄件者驗證 SPF、DKIM、DMARC，以及大量郵件的一鍵取消訂閱（請檢查最新的 Gmail/Yahoo 寄件者規則）；退信/垃圾郵件投訴處理；將交易性郵件與行銷郵件分流。

M5. AI / LLM 功能 —— 提供者抽象層或具備備援模型的閘道；對 429/5xx 狀態碼設定逾時與重試；使用 schema (Zod/Pydantic) 驗證結構化輸出；在 CI 中針對 Prompt/模型變更執行真實案例的評估集；當模型讀取不受信任內容或可呼叫工具時，需具備 Prompt 注入防禦機制（最小權限工具、破壞性操作需人類確認）；每個用戶與全域的費用上限；PII 處理與提供者的資料保留設定；追蹤模型棄用日期；在需要時向用戶揭露 AI 的使用；對產生的輸出設定品牌/品質防護機制（禁止詞彙、語氣檢查、依風險分級的人工審查）；UI 告知用戶其限制（「請驗證事實」、為聲明提供來源）；Prompt/模型的變更應先在沙箱環境中針對歷史或樣本資料進行測試，然後才逐步推廣到少量流量；定期（例如每半年）評估模型/供應商。

M6. 金流 —— 使用託管結帳頁面以最小化 PCI 範圍；以 Webhook 驅動的狀態機（絕不相信客戶端重新導向）；冪等履行；退款、爭議處理、催款；按地區徵稅；沙箱/測試時鐘涵蓋所有情境；營收對帳。

M7. 受監管資料 —— PHI → HIPAA：與每個接觸 PHI 的供應商簽訂 BAA、存取日誌、最小必要原則。超出託管結帳的 PCI → SAQ 範圍。兒童 → COPPA/年齡限制。歐盟/英國用戶 → GDPR 法律基礎、DSAR 流程、跨境傳輸。加州 → CCPA/CPRA。標記為需法務審查；不要給出法律結論。

M8. B2B / 企業級 —— 測試過租戶隔離（跨租戶存取測試）；SSO（SAML/OIDC）與 SCIM（在 T3 階段）；稽核日誌匯出；角色/權限模型；資料匯出；安全問卷資訊包（架構、子處理者、滲透測試、政策）；正常運行時間 SLA 與補償。

M9. 你上架的 Marketplace —— Chrome Web Store、Slack/Teams/Zoom 應用程式目錄、Shopify、MCP/外掛註冊中心等：上架要求、審查時程、權限理由說明、隱私權聲明——即時驗證。

M10. 開發者工具、函式庫、外掛與開源軟體 —— 經過審慎選擇的授權（像 AGPL 這類 copyleft 授權可能阻礙公司採用；MIT/Apache 這類寬鬆授權則傳播較快）以及正確的 NOTICE/第三方授權檔案；SECURITY.md 需包含私人揭露管道；語意化版本、CHANGELOG、以及針對任何儲存資料或配置格式的經過測試的升級/遷移路徑；在 CI 中實際測試過的支援平台矩陣（OS × 執行時期版本 × 每個聲稱支援的客戶端/IDE）；針對每個文件化的安裝方式，從一台乾淨的機器上驗證安裝是否成功；在每個套件註冊中心（PyPI、npm、外掛市場）預留套件名稱；簽署釋出 / 建構來源驗證；遙測功能預設關閉或為選擇加入，並記錄在文件中；CONTRIBUTING、行為準則、Issue/PR 範本；一個「這不是什麼」的章節，以避免用戶誤用。

計分卡範本

產品：<名稱>   目標分級：T1/T2/T3   上線日期：<日期>   判定：可行 | 有條件可行 | 不可行
阻擋項目數量：N   高優先級：N   未知：N

...

生產就緒度