生产审计
当用户询问应用是否准备就绪、生产环境中可能出现什么问题、或发布前必须修复哪些问题时，使用此技能。这是对社区原先的 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、认证中间件、后台工作器、定时任务和数据库迁移。
- 环境变量文档和启动检查。
- 可观测性钩子、错误报告、日志、健康检查和仪表板。
- 回滚、种子、迁移和回填说明。
- 最重要的用户路径的端到端测试覆盖。
如果部署的 URL 在范围内，则仅使用浏览器或 HTTP 检查针对该 URL，并且除非用户提供安全的测试账户，否则避免凭据操作。
风险视角
安全与认证
- 公开路由、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 履约和计费页面刷新添加一个端到端路径。
已检查的证据：
- `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