用途
Production Audit 用于在应用上线前、功能合并后或公开发布临近时，评估生产就绪程度与潜在风险。当用户询问“是否可上线”“生产环境会出什么问题”“我们漏了什么”“审计这个仓库”“准备好发布了吗”时使用。它适合公开发布、演示、客户推广或投资人演示前的风险检查，也适合 CI 通过但用户想了解生产风险而非仅测试状态的场景。
不适用场景：正在实现阶段需要行级安全编码时，应先用 security-review；纯库、模板、仅文档仓库或脚手架，除非用户关注打包/发布就绪而非应用就绪；用户要求正式合规审计时，本技能是工程分诊，不是法律、财务、医疗或监管认证；仅有产品想法而无仓库、部署、CI 或运行时表面时。
主要能力
该技能从本地和用户授权的证据构建审计，不运行未固定版本的远程代码，不将仓库内容上传第三方服务，也不调用外部扫描器，除非用户明确批准特定工具和数据流。
审计顺序：建立发布表面；阅读近期变更与当前分支状态；检查仓库中实际存在的运行时、认证、数据、支付、后台任务、AI 和部署边界；检查 CI、测试、迁移、环境文档和回滚路径；给出简短的发布/阻断建议与具体修复。
证据清单：先看低成本本地信号，如 git status --short --branch、git log --oneline --decorate -20、git diff --stat origin/main...HEAD。然后检查项目特定表面：包脚本、CI 工作流、发布脚本、Docker 文件、部署清单；API 路由、webhook、认证中间件、后台 worker、cron 任务、数据库迁移；环境变量文档与启动检查；可观测性钩子、错误报告、日志、健康检查、仪表盘；回滚、种子、迁移、回填说明；关键用户路径的 E2E 覆盖。若涉及已部署 URL，仅对该 URL 使用浏览器或 HTTP 检查，避免凭据操作，除非用户提供安全测试账户。
风险视角
安全与认证：公共路由、API 路由、管理路由是否清晰分离；认证与授权是否服务端强制；密钥是否远离客户端包、日志、示例输出和已提交文件；速率限制、CSRF 防护、CORS 策略、上传验证是否在需要处存在；AI 或智能体表面是否防御提示注入、工具滥用和不可信内容进入特权操作。
数据完整性：迁移是否向前干净运行并有回滚或恢复计划；破坏性迁移、回填、数据导入是否安全分阶段；数据库策略、授权、服务角色边界是否匹配应用租户模型；写入、任务、webhook 处理器的重试是否幂等。
支付与 Webhook：解析可信负载字段前是否验证 webhook 签名；每个支付、订阅或履约 webhook 是否幂等；是否处理重放、重复投递、乱序投递；测试模式与实时模式凭据是否分离。
运营：应用能否从干净检出使用文档命令启动；必需环境变量是否命名、验证并快速失败；是否有健康检查证明依赖可达；部署、回滚、事件负责人路径是否文档化；日志是否有用且不泄露密钥或个人数据。
用户体验：发布关键路径是否覆盖桌面和移动端；表单在移动端是否可用，无输入缩放、布局重叠或提交状态阻塞；加载、空、错误、权限拒绝状态是否告知用户发生了什么；关键操作失败时是否有支持或恢复路径。
评分
评分用于强制优先级，不暗示数学确定性。区间：Blocked 0-49，修复最高风险前不要发布；Risky 50-69，仅在小范围发布或内部测试后发布；Launchable With Caveats 70-84，若负责人接受所列风险则可发布；Strong 85-100，从可用证据看无明显发布阻断。
若以下任一为真，分数上限 69：敏感数据缺少认证或授权；支付或履约 webhook 不幂等；必需迁移无法安全运行；密钥暴露在客户端包、日志或已提交文件；高影响发布无回滚路径。若 CI 不绿或发布关键路径未端到端测试，分数上限 84。
输出格式
先一句话总结，例如：“Production audit: 76/100, launchable with caveats, with webhook idempotency and rollback docs as the two risks to fix before public launch.” 然后列出：Blockers（部署前必须修复项）；High-value fixes（若想提高分数的下一步修复）；Evidence checked（检查的文件、命令、CI、已部署 URL 或 PR）；Evidence missing（提供后会改变置信度的内容）；Next action（一个具体修复或验证步骤）。保持优势简短，用户要的是就绪度，有用答案是剩余风险和下一步行动。
示例
用户：is this ready to ship?
响应：Production audit: 68/100, risky, because Stripe webhooks are verified but not idempotent and there is no rollback note for the pending migration.
Blockers:
- Add idempotency for
checkout.session.completedbefore fulfilling orders. - Write and test the rollback path for
20260511_add_billing_state.sql.
High-value fixes:
- Add a health check that verifies database and payment-provider reachability.
- Add one E2E path for upgrade, webhook fulfillment, and billing-page refresh.
Evidence checked:
api/stripe/webhook.tsdb/migrations/20260511_add_billing_state.sql- GitHub Actions run for the release branch
Next action: Want me to patch webhook idempotency first?
反模式
默认审计路径运行 npx <package>@latest 或远程扫描器；未经明确批准将源代码、密钥、客户数据或私有拓扑上传外部审计服务；未命名检查证据就给出分数；将绿色 CI 视为生产就绪；以泛泛的“告诉我你想做什么”结尾。
参见
Skill: security-review；Skill: deployment-patterns；Skill: e2e-testing；Skill: tdd-workflow；Skill: verification-loop。