生产就绪评估 (MVP → 生产)
目标：向产品负责人提供基于证据的判断——产品是否准备好迎接真实用户、哪些因素阻碍发布，以及为弥补差距所需的最少工作量。所有内容均根据产品实际情况量身定制，绝不生成一个通用的200项任务清单。
硬性规则
- 没有证据即为“未知”。 每个条目只能是“通过 / 差距 / 不适用 / 未知”，并且“通过”需要提供证据（文件路径、配置、CI运行记录、仪表板、文档链接）。绝不能仅根据README中的声明就标记为“通过”。
- 按层级合理定级。 不要为一个只有50名用户的测试版要求多区域灾难恢复。为每个差距标记其所需的层级。
- 验证平台规则的最新情况。 应用商店、OAuth、支付和电子邮件发送者的规则每年都会变化。在引用某个商店/供应商的要求之前，请查阅该供应商的官方文档（进行网络搜索），并注明链接和检查日期。
- 复用而非重复。 如果
pm-ai-shipping:ship-check、security-audit-static、performance-audit-static或derive-tests可用，请运行它们以获取代码层面的证据，并将结果整合进来。本技能负责所有与代码无关的评估内容。 - 输出简洁明了。 产品负责人阅读一页的记分卡；详细信息放在附录和差距积压清单中。
- 治理融入工作流程，而非事后添加。 优先选择在实际工作环节中运行的检查（如CI、PR模板、预提交钩子、产品内的保护措施），而不是在发布前临时添加的评审会议。一个只在最后阶段运行的关卡会成为瓶颈。
- 发布 ≠ 采用。 大多数产品在发布后停滞不前，是因为人和流程没有改变，而非代码失败。就绪状态包括采用计划（领域13），而不仅仅是系统本身。
就绪层级
| 层级 | 含义 | 典型标准 |
|---|---|---|
| T1 公开测试 | 真实用户，低规模，可容忍偶尔宕机 | 无秘密泄露，身份认证稳固，备份可恢复，错误被追踪，法律页面存在，回滚可行 |
| T2 正式发布 | 付费用户，有SLA预期 | + SLO/警报/值班计划，负载测试通过，运行手册存在，支持通道存在，集成有降级方案 |
| T3 企业 / 监管行业 | B2B合同，涉及受保护健康信息/支付卡行业/儿童数据，受审计 | + 单点登录/跨域身份管理系统，审计日志，数据处理协议/业务伙伴协议，渗透测试，SOC 2 / HIPAA控制措施，灾难恢复演练 |
工作流程
步骤 0 — 分析产品（一次性提问，批量收集）
捕获：目标层级和发布日期；一个成功指标及其目标值（什么能让这次发布成为成功的标志，如何衡量，何时达成）；明确的负责人和签署利益相关者（产品、工程、安全、法务/隐私、支持、市场——如果涉及个人数据、AI输出或受监管用户，必须在第一天标记法务/隐私）；产品形式（Web、iOS、Android、桌面端、公共API、CLI、浏览器扩展、开发工具/插件/库等分发给其他开发者的东西）；托管环境/技术栈；数据类型；用户类型；区域；AI/LLM特性；支付；每个外部集成（消费的API、接收的Webhook、发布到的市场/应用商店、单点登录/身份提供商）。首先扫描仓库（包清单、环境变量模板、SDK导入）以预填集成列表，然后仅要求负责人确认或补充缺失项。
分析档案将决定哪些模块需要评估。将其记录在报告的开头。
步骤 1 — 收集证据
仓库（代码、CI配置、基础设施即代码、环境变量模板、数据库迁移）、托管仪表板/连接器（如果可用，如Vercel、Railway、Supabase、Render等）、问题跟踪器、现有文档。运行可用的审计技能。记录无法检查的内容 -> 标记为“未知”。
步骤 2 — 评估核心领域（始终执行）+ 适用的模块
为每个条目打分。严重性：阻塞（无法在目标层级发布）/ 高（发布后两周内修复）/ 稍后。
步骤 3 — 交付
- 记分卡（1页）： 可行 / 有条件可行 / 不可行；阻塞项数量；按领域划分的红-黄-绿表；用平实的语言列出前5大风险。
- 差距积压清单： 每个差距一个任务——标题、为何重要、验收标准、关闭所需的证据、层级、严重性、大致工作量（小/中/大）。如果连接到Linear/Jira/GitHub Issues，则提供创建为项目/里程碑的选项；否则为表格形式。
- 强化工具包（按需提供）： 生成仓库特定的CI质量门禁、代理规则文件（CLAUDE.md/.cursorrules）、
.env.example、运行手册模板——全部基于仓库实际使用的内容，而非模板转储。 - 重新运行模式： 在后续运行时，与上一份报告进行差异比较，仅显示变化的内容。
核心领域（始终评估）
1. 秘密与配置 — 代码或Git历史中无秘密（使用gitleaks/trufflehog扫描整个历史）；.env 被忽略，.env.example 存在；生产环境秘密存储在平台秘密存储中；开发/预发布/生产环境密钥分离；轮换计划及可执行轮换的人员；密钥泄露的响应步骤。
2. 身份验证与访问 — 经过验证的认证提供者或经过严格审查的库（禁止自实现密码学）；每条数据路由均进行服务端授权（检查是否存在不安全的直接对象引用/缺失租户过滤器/过于宽松的行级安全策略）；会话/令牌生命周期及撤销机制；登录、注册、重置、一次性密码接口的速率限制；管理员的多因素认证；服务账户的最小权限原则；管理员操作日志记录。
3. 边缘与应用程序安全 — HTTPS + HSTS；安全头（内容安全策略、框架祖先等）；严格的CORS策略；边界输入验证；文件上传限制/类型检查；URL获取器的SSRF防护；T2+ 级别的WAF/机器人保护；依赖扫描 + 锁定文件；CI中的静态应用安全测试；T3级别的软件物料清单和许可证检查。
4. 数据 — 自动化备份 以及经过验证的恢复（记录实际的恢复时间）；支持数据库的时间点恢复；向后兼容的迁移（扩展 -> 迁移 -> 压缩）；预发布环境不使用原始的生产PII；数据保留 + 删除路径（用户账户删除必须实际删除数据库、存储、日志和供应商处的数据）；确认默认启用了传输中和静态加密。
5. 可靠性 — 每个外部调用都设置超时；仅在幂等操作上使用带退避和抖动的重试；支付/Webhook/任务使用幂等键；后台工作使用持久队列；当依赖项宕机时实现优雅降级；T2+ 级别定义SLO（可用性、延迟）；T2+ 级别进行预期峰值3倍的容量/负载测试。
6. 可观测性 — 带有发布标签的错误跟踪（例如 Sentry）；带有请求/跟踪ID和 PII脱敏 的结构化日志；每个端点的关键指标（速率、错误、持续时间）；外部正常运行时间检查；基于症状的警报，路由到实际会看到它们的人员；为发布日准备的仪表板。
7. CI/CD与发布 — 主分支的必选检查（lint、类型检查、测试、秘密扫描、依赖审计）；预览/预发布环境；已验证过一次的一键回滚；风险特性使用功能开关；迁移在部署中安全运行；发布说明/更新日志；分支保护。
8. 测试 — 关键路径测试（认证、支付、数据写入、权限）优先于代码覆盖率百分比；针对真实数据库的集成测试；部署后运行顶级用户旅程的端到端冒烟测试；外部API的契约测试或录制的fixture。
9. 性能与成本 — 核心Web Vitals / 应用启动预算；N+1查询和缺失索引检查；缓存/CDN；按供应商设置费用警报和硬上限（云、LLM、短信、邮件）；每活跃用户成本估算；可能导致高额账单的滥用场景（注册垃圾邮件、LLM提示循环、短信轰炸）。
10. 运维与支持 — 即使是一个人也要明确负责人/值班计划；事故处理流程（严重性、沟通、事后复盘）；针对前5大故障模式的运行手册；T2+ 级别的状态页面；支持渠道和服务水平协议；常见支持任务的运维管理工具（修复问题无需直接操作数据库）。
11. 法律与信任 — 与实际数据流匹配的条款和隐私政策；在需要时实施Cookie同意（欧盟/英国）；与处理个人数据的供应商签订数据处理协议；T3级别的子处理者列表；无障碍目标（WCAG 2.2 AA）和基本审计；开源许可证合规；产品名称的商标/名称清查。
12. 产品就绪度 — 对激活漏斗的分析（经同意）；新手引导和空状态；交易邮件正常投递（见Web模块）；帮助文档/常见问题解答；定价/计费如果已订阅则必须生效；反馈循环；有问题的特性开关（kill switch）。
13. 采用与运营模型 — 成功指标和试点退出标准在发布前已书面确定（什么将其从“试点”变为“扩展”或“终止”）；文档化的发布工作流程，每个风险层级指定了审批人（低风险变更 = 一位审核人，高风险 = 多位），并商定周转时间以避免签核停滞；发布沟通（变更内容、未变更内容、已知限制）；首批用户/倡导者群体以及倾听他们反馈的方式；产品内帮助、模板或示例，帮助用户在学习使用工具；反馈循环（用户反馈 + 使用指标）并定期评审（例如30/60/90天，之后按季度）；随着使用量增长，指定支持维护的负责人。
条件模块
M1. 你消费的集成（每个供应商一张表） — 生产环境账号/密钥（非沙箱）及账号负责人；速率限制与期望峰值的对比；定价上限及警报；认证类型和令牌刷新；Webhook签名验证、重放保护、幂等处理器、重试/退避和死信队列；API版本锁定 + 弃用监控（订阅更新日志）；超时 + 断路器 + 用户可见的降级方案；订阅供应商状态页面；服务条款允许你的使用方式（转售、AI训练、爬取）；退出计划——你拥有自己的数据/提示/配置并可导出，合同没有多年锁定且无退出条款；数据驻留/数据处理协议；OAuth应用验证/审核要求（例如Google敏感/受限作用域、Microsoft发布者验证、Slack/Zoom应用审核）——核实现行规则。
M2. 你暴露的公共API — 发布OpenAPI/规范；版本控制和弃用策略；带有作用域的API密钥/OAuth，支持轮换和撤销；每密钥速率限制和配额；分页、POST上的幂等键；一致的错误格式；沙箱环境；你发送的Webhook经过签名、重试并可重放；开发者文档 + 更新日志；如果按使用计费则需使用计量。
M3. 移动端与应用商店 — 在引用前对照当前官方文档进行逐项验证：
- Apple: App Review指南；隐私标签匹配实际数据收集；隐私清单（包括第三方SDK）；如果应用支持创建账户则必须提供应用内账户删除功能；提供第三方登录时必须提供Apple登录；数字内容的IAP规则；TestFlight外部测试；出口合规。
- Google Play: 当前目标API级别截止日期；数据安全表单；新个人开发者账户的封闭测试要求；Play应用签名和上传密钥保管；账户删除网页链接。
- 两者通用: 崩溃报告；针对破坏性API变更的强制/可选更新机制；深度/通用链接；公司账号拥有的推送凭证；商店列表素材、年龄分级、支持URL、隐私URL；发布计划中为审核拒绝预留缓冲（计划天数而非时数）。
M4. Web与邮件 — 自定义域名、公司账号拥有的DNS、域名注册商锁定 + 自动续期；如果可发现性重要则需SEO基础（标题、站点地图、robots、开放图谱标签）；404/500页面；邮件发送者认证SPF、DKIM、DMARC以及批量邮件的一键退订（检查当前Gmail/Yahoo发送规则）；退信/投诉处理；事务邮件与营销邮件分离。
M5. AI / LLM特性 — 提供者抽象层或带备用模型的网关；429/5xx错误的超时和重试；由模式验证的结构化输出（Zod/Pydantic）；在CI中对真实用例的评估集进行测试，然后再进行提示/模型更改；当模型读取不可信内容或可调用工具时的提示注入防御（最小权限工具、破坏性操作需人工确认）；每用户和全局成本上限；PII处理及提供者数据保留设置；跟踪模型弃用日期；在需要时向用户进行AI披露；生成输出的品牌/质量护栏（禁止词汇、语气检查、按风险分级的人工审核）；UI告知用户限制（如“请核实事实”、声明附上来源）；首先在沙箱中使用历史或样本数据测试提示/模型更改，然后逐步推广到少量流量；定期（例如每半年）进行模型/供应商审查。
M6. 支付 — 托管结账以最小化PCI合规范围；由Webhook驱动的状态（绝不信任客户端重定向）；幂等履约；退款、争议、催款；按区域征税；测试时钟/沙箱覆盖；收入对账。
M7. 受监管数据 — 受保护健康信息 -> HIPAA：与接触受保护健康信息的每个供应商签订商业伙伴协议，访问日志，最小必要原则。超出托管结账的PCI -> 自我评估问卷范围。儿童数据 -> COPPA/年龄门槛。欧盟/英国用户 -> GDPR合法依据、数据主体访问请求流程、数据传输。加州 -> CCPA/CPRA。标记给法务审查；不提供法律结论。
M8. B2B / 企业 — 经过测试的租户隔离（跨租户访问测试）；T3级别的单点登录和跨域身份管理系统；审计日志导出；角色/权限模型；数据导出；安全问卷包（架构、子处理者、渗透测试、政策）；正常运行时间SLA和信用额度。
M9. 你发布到的市场 — Chrome Web Store、Slack/Teams/Zoom应用目录、Shopify、MCP/插件注册表等：列表要求、审核时间线、权限合理性说明、隐私披露——进行实时验证。
M10. 开发工具、库、插件与开源 — 有意识地选择许可证（像AGPL这样的Copyleft许可证会阻碍公司采用；MIT/Apache等宽松许可证传播更快），且NOTICE/第三方许可证正确；SECURITY.md 包含私有披露渠道；语义化版本控制、更新日志，以及针对任何存储数据或配置格式的经过测试的升级/迁移路径；在CI中实际测试支持的平台矩阵（操作系统 × 运行时版本 × 其声明的每个客户端/IDE）；从干净机器上验证每个记录在案安装路径的安装；在PyPI、npm、插件市场等每个注册表上预留包名称；签名发布 / 构建溯源；遥测默认关闭或需明确同意且有文档说明；CONTRIBUTING、行为准则、问题/PR模板；一个“这不是什么”的章节，以防用户误用。
记分卡模板
产品: <名称> 目标层级: T1/T2/T3 发布日期: <日期> 结论: 可行 | 有条件可行 | 不可行
阻塞项计数: N 高优先级项: N 未知项: N
[按领域排列的RAG表]
前5大风险:
1. ...
2. ...
3. ...
4. ...
5. ...
关键发现摘要: ...