生产审计
当用户询问应用是否准备好发布、在生产环境中可能出现什么问题、或发布前必须修复哪些问题时，使用此技能。这是对社区中已过时的 production-audit 概念的维护安全的重写：保留了有用的生产就绪性评估视角，同时移除了未固定的外部执行和第三方数据共享。
何时使用
- 用户询问“这个准备好生产了吗”、“在生产环境中会出什么问题”、“我们遗漏了什么”、“审计这个仓库”或“准备好发布了？”
- 某个功能已被合并，需要进行部署前或合并后的风险审查。
- 公开上线、演示、客户推广或投资者演示临近。
- CI 通过，但用户关心的不仅是测试状态，还有生产风险。
- 有可用的已部署 URL、发布分支、PR 或当前检出用于证据收集。
何时不使用
- 在积极实现阶段，正确的视角应该是行级安全编码；请先使用
security-review。 - 对于纯库、模板、仅文档仓库或脚手架，除非用户关心的是打包/发布的就绪性而非应用就绪性。
- 当用户请求正式合规审计时。此技能是工程分类，而非法律、财务、医疗或监管认证。
- 当唯一可用的证据是一个没有仓库、部署、CI 或运行时表面的产品想法时。
工作原理
基于本地和用户授权的证据构建审计。不要运行未固定的远程代码、将仓库内容上传到第三方服务、或调用外部扫描器，除非用户明确批准该特定工具和数据流。
按以下顺序进行：
- 确定发布范围。
- 读取最近的更改和当前分支状态。
- 检查仓库中实际存在的运行时、认证、数据、支付、后台作业、AI 和部署边界。
- 检查 CI、测试、迁移、环境文档和回滚路径。
- 生成简短的发布/阻塞建议及具体修复。
证据清单
从廉价、本地的信号开始：
git status --short --branch
git log --oneline --decorate -20
git diff --stat origin/main...HEAD
然后检查项目特定的范围：
- 包脚本、CI 工作流、发布脚本、Docker 文件和部署清单。
- API 路由、Webhook、认证中间件、后台工作者、Cron 任务和数据库迁移。
- 环境变量文档和启动检查。
- 可观测性钩子、错误报告、日志、健康检查和仪表板。
- 回滚、种子数据、迁移和数据回填说明。
- 最重要用户路径的端到端测试覆盖。
如果已部署的 URL 在范围内，则仅对该 URL 使用浏览器或 HTTP 检查，并避免凭据操作，除非用户提供安全的测试账户。
风险视角
安全与认证
- 公共路由、API 路由和管理路由是否明确分离？
- 是否在服务器端强制实施身份验证和授权？
- 密钥是否未包含在客户端包、日志、示例输出和检入的文件中？
- 应用是否需要的地方是否存在速率限制、CSRF 保护、CORS 策略和上传验证？
- AI 或代理接口是否能防御提示注入、工具滥用以及将不受信任的内容传递到特权操作？
数据完整性
- 迁移是否顺利向前运行，并且有回滚或恢复计划？
- 破坏性迁移、回填和数据导入是否安全地分阶段进行？
- 数据库策略、授权和服务角色边界是否与应用的多租户模型匹配？
- 写入、任务和 Webhook 处理程序的重试是否幂等？
支付与 Webhook
- 在解析受信任的有效负载字段之前，是否验证了 Webhook 签名？
- 每个支付、订阅或履行 Webhook 是否幂等？
- 是否处理了重放、重复传递和乱序传递？
- 测试模式和实时模式的凭据是否分离？
运维
- 应用能否根据文档化的命令从干净的检出启动？
- 必需的环境变量是否已命名、验证并快速失败？
- 是否存在证明依赖项是否可达的健康检查？
- 部署、回滚和事件负责人路径是否已记录？
- 日志是否有用且不会泄露密钥或个人数据？
用户体验
- 关键上线路径是否在桌面和移动端均得到覆盖？
- 表单在移动端是否可用，不会出现输入缩放、布局重叠或提交状态阻塞？
- 加载状态、空状态、错误状态和权限拒绝状态是否告知用户发生了什么？
- 当关键操作失败时，是否有支持或恢复路径？
评分
使用评分来强制优先级排序，而不是暗示数学确定性。
| 等级 | 分数 | 含义 |
|---|---|---|
| 阻塞 | 0-49 | 在修复最高风险之前不要发布 |
| 高风险 | 50-69 | 仅在小型发布或内部 Beta 后发布 |
| 可发布但有警告 | 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