生产验证 Skill：用业务信号验证发布后的真实状态
发布完成不是验证完成。真实流量、配置传播和依赖服务可能让预发看不见的问题刚刚开始出现。生产验证必须有明确的观察窗口和回退条件。
生产验证 Skill 明确观察对象、有效变更信号和继续或回退所需的证据强度。
本文用贴近协作现场的案例拆解判断过程，帮助你把不同信号转化为可沟通、可追踪的行动。
生产验证 Skill 用来做什么
生产验证适合需要确认发布影响是否落到真实用户和业务结果的团队。它把业务信号、技术遥测、对照窗口和回滚条件放在同一份观察记录里。
先回到源 Skill
这个 Skill 的完整执行规则在 生产验证 提示词。源目录还包含 3 个评测用例，用于验证输出是否遵守契约。
它要求特别注意：
- 默认先只读再低风险写入
- 必须使用批准账户和可清理数据
- 出现停止条件立即终止并升级
用一份项目材料开始
先把当前拿得到的材料摆上来。缺口可以保留，状态必须说实话。
| 材料 | 这次填什么 | 缺失时的处理 |
|---|---|---|
| 目标与范围 | 在订单服务发布后验证核心交易、指标、日志、告警与回滚条件是否符合预期 | 标出不在本轮判断内的链路 |
| 版本与环境 | 发布版本、区域、流量比例、部署时间和回滚版本 | 未锁定发布批次时不下生产结论 |
| 证据 | 合成交易、真实业务指标、日志、告警和回滚演练记录 | 缺少同窗口指标时标为待验证 |
| 决策边界 | 放量、暂停、回滚和观察窗口的负责人 | 每个动作附触发阈值与确认人 |
可以这样调用：
请使用 production-verification Skill。
任务：在订单服务发布后验证核心交易、指标、日志、告警与回滚条件是否符合预期
输入材料：[版本、链接、日志或报告路径]
范围：[本次包含和排除的对象]
限制：[时间、数据、权限、合规要求]
先审计输入，再按风险和证据强度排序。材料没有证明的内容标为假设，并列出验证方法。生产验证要把业务信号和技术遥测对齐
| 产物 | 要回答的问题 | 最低证据 |
|---|---|---|
| 业务信号 | 用户和交易是否按预期完成 | 转化、成功率、投诉和订单状态 |
| 技术遥测 | 服务是否出现异常 | 错误率、延迟、资源和告警 |
| 对照窗口 | 变化来自发布还是正常波动 | 发布时间、对照组和时间窗 |
| 回滚条件 | 什么信号会触发止损 | 阈值、Owner 和执行记录 |
没有业务结果和技术遥测的同窗证据时，只能写“已观察”，不能写发布验证完成。
在项目里跑一轮
先用一个边界清楚的小回合启动——在订单服务发布后验证核心交易、指标、日志、告警与回滚条件是否符合预期。别急着把结果写成报告。先把输入版本、时间窗口和负责人贴到同一处；然后把每个判断连回具体材料；最后只安排一项能改变结论的验证动作。
生产验证必须是授权的最小检查，读操作与写操作边界要事先说明。这一轮交付应当包含：可复查的证据索引、仍然成立的假设、以及下一位同事可以直接执行的动作。这样做很朴素，也很有效。
进阶使用：把一次分析变成持续机制
生产验证必须是授权的最小检查，读操作与写操作边界要事先说明。
每次生产验证都保存发布版本、观察窗口、对照组和信号来源。发布分批或指标定义变化时，按批次更新结论，保留原始数据。
三段式 Skill 链
release-testing-workflow → production-verification → production-incident-analysis
| 交接 | 传递内容 | 接收方要检查什么 |
|---|---|---|
| 上游到 production-verification | 来源版本、范围、风险、未决项 | 输入是否过期，冲突是否标记 |
| production-verification 到下游 | 判断、证据索引、残余风险、待办 | 产物是否可执行，Owner 是否明确 |
| 下游回写 production-verification | 执行结果、缺陷、事实变化 | 是否更新基线与回归范围 |
交接时传摘要、证据索引和原始材料的位置。信息量足够，结论出了问题也能回到来源。
团队门禁
| 门禁 | 检查内容 | 未满足时 |
|---|---|---|
| production-verification 输入门禁 | 版本、环境、证据来源和 Owner | 停止生成，列出缺口 |
| production-verification 产物门禁 | 关键结论带依据、状态和影响 | 退回补证据 |
| production-verification 执行门禁 | 命令、查询或验证路径可复现 | 标记基础设施或测试问题 |
| production-verification 决策门禁 | 残余风险有接受人与日期 | 不进入下一阶段 |
容易踩的坑
- 只看服务健康检查，漏掉订单、转化或用户反馈。
- 没有对照窗口，把自然波动当成发布影响。
- 验证结果没有绑定构建号和发布批次。
- 设了回滚阈值，却没有明确谁执行、如何确认恢复。
相关 Skill
生产验证需要和事故背景、发布证据及业务质量判断互相连接：
交付前复核：把判断落到证据
Skill 输出拿到手后，先核对四件事：输入版本是否明确，范围是否完整，每条结论能否回到证据，下一步由谁执行。少一项，报告就容易变成漂亮的猜测。
| 项目 | 需要留下 | 缺失时 |
|---|---|---|
| 输入边界 | 版本、环境、时间窗口和本次范围 | 标记假设，不写成事实 |
| 证据索引 | 日志、报告、Trace、截图或命令输出 | 标记 evidence_pending |
| 结论状态 | verified、assumption、blocked 或 pending | 停止扩大结论 |
| 后续动作 | 最小验证命令、负责人和截止时间 | 交付为待办，不进入门禁 |
source_version: [版本或提交]
scope: [本次包含和排除的对象]
evidence: [日志、报告、Trace 或命令输出]
status: pending
owner: [负责人]
next_action: [最小验证动作]分析类 Skill 要保留查询条件和时间窗口；执行类 Skill 要保留命令、退出码和失败产物。人工修改也要记录，下一次复核才知道结论从哪里变化。
安装与调用
安装这个 Skill：
npx skills add https://github.com/naodeng/awesome-qa-skills/tree/main/skills/zh/testing-types/production-verification -g安装后，直接使用下文的 production-verification 调用词，并附上本次的真实材料。
常见问题
输入还不完整，能开始吗？
能。先交付受限初版：列出已知事实、假设、缺口和最小验证动作。环境、数据或权限缺失时，不写执行结论。
什么时候需要人工确认？
范围取舍、风险接受、生产操作、数据权限和发布决定必须由对应负责人确认。Skill 负责整理证据与选项，不替团队做授权决定。
先用一份真实材料跑通 生产验证，把输入、产物、人工修改和验证证据留在同一个工作链里。下一次变化发生时，才有东西可以复用。
参考
- 生产验证 提示词：https://github.com/naodeng/awesome-qa-skills/tree/main/skills/zh/testing-types/production-verification/prompts/production-verification.md
- Awesome QA Skills：生产验证 Skill 源文件：https://github.com/naodeng/awesome-qa-skills/tree/main/skills/zh/testing-types/production-verification
- Awesome QA Skills GitHub 项目：https://github.com/naodeng/awesome-qa-skills
- 生产验证 Skill 详情页：https://inaodeng.com/zh-cn/qaskills/production-verification/