| name | production-audit |
| description | 基于本地证据的生产就绪审计，适用于已发布应用、发布前评审、合并后检查和"生产环境会出什么问题？"的问题，无需将仓库数据发送到外部审计服务。 |
| origin | community |
生产审计
当用户询问应用是否准备好发布、生产环境可能出什么问题、或发布前必须修复什么时使用此技能。这是过时社区 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 任务和数据库迁移。
- 环境变量文档和启动检查。
- 可观测性钩子、错误报告、日志、健康检查和仪表板。
- 回滚、种子数据、迁移和回填指令。
- 最重要的用户路径的 E2E 覆盖。
如果已部署的 URL 在范围内，仅对该 URL 使用浏览器或 HTTP 检查，除非用户提供安全测试账户，否则避免凭证操作。
风险视角
安全和认证
- 公共路由、API 路由和管理路由是否清晰分离？
- 认证和授权是否在服务端强制执行？
- 密钥是否被排除在客户端包、日志、示例输出和已提交文件之外？
- 应用需要的地方是否存在速率限制、CSRF 保护、CORS 策略和上传验证？
- AI 或智能体表面是否防御了提示注入、工具滥用和不受信任内容流入特权操作？
数据完整性
- 迁移是否能干净地前向运行并有回滚或恢复计划？
- 破坏性迁移、回填和数据导入是否安全分阶段？
- 数据库策略、授权和服务角色边界是否与应用的租户模型匹配？
- 写入、任务和 webhook 处理程序的重试是否幂等？
支付和 Webhook
- 在解析受信任的负载字段之前是否验证了 webhook 签名？
- 每个支付、订阅或履行 webhook 是否幂等？
- 是否处理了重放、重复投递和乱序投递？
- 测试模式和实时模式凭据是否分离？
运维
- 应用能否使用文档化的命令从干净检出启动？
- 必需的环境变量是否已命名、验证和快速失败？
- 是否有证明依赖可达的健康检查？
- 部署、回滚和事件负责人路径是否已文档化？
- 日志是否有用而不泄露秘密或个人数据？
用户体验
- 发布关键路径是否在桌面和移动端覆盖？
- 表单在移动端是否可用，没有输入缩放、布局重叠或阻塞的提交状态？
- 加载、空、错误和权限拒绝状态是否告知用户发生了什么？
- 当关键操作失败时是否有支持或恢复路径？
评分
使用评分来强制优先级排序，而非暗示数学确定性。
| 区间 | 分数 | 含义 |
|---|
| 阻塞 | 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 履行和计费页面刷新添加一个 E2E 路径。
已检查证据：
- `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
