产品质量视角 Skill：从用户旅程中识别业务质量风险

8 分钟阅读 PolyForm Noncommercial 1.0.0

AI 测试Agent Skills产品质量视角

从产品角度看，质量落在用户任务、业务规则和信任成本上。会员能不能理解权益、完成升级，并在失败后继续完成任务——这些问题比缺陷数量更接近产品结果。

产品质量视角 Skill 围绕客户结果和产品风险评价质量，避免用绿色仪表盘代替用户价值。

本文围绕会员升级和支付回调，把用户任务、业务规则、验收风险一路带到发布评审。

Awesome QA Skills 按语言和测试阶段组织 Skill。目录结构和安装方式请先看系列总览；本文聚焦产品质量视角，重点说明用户任务、业务规则和验收风险如何落到行动。

先看源 Skill

主 Prompt 把工作拆到适用性判断、产品问题、输出合同、证据与边界、执行流程。这些标题只是导航，真正使用时还要回到项目材料。

它支持需求分析（requirements-analysis）、测试策略（test-strategy）、测试策略评审（test-strategy-review）、代码评审（code-review）、测试用例编写（test-case-writing）、测试用例评审（test-case-review）、测试报告编写（test-reporting）和测试报告评审（test-report-review）。stage 是必填项；缺失或不支持时，结果应停在“不适用”和材料缺口，不应该为了凑报告填一张通用清单。文章正文使用中文阶段名，调用参数仍使用括号里的英文键名；每次只加载对应阶段的一个 Prompt，研发协作会更容易复核。

产品视角也有明确边界：它可以评价用户价值、业务规则、范围、验收标准和决策风险，不能替开发确认代码正确，不能替 QA 宣称测试通过，也不能替发布负责人做 Go/No-Go 决定。

这个 Skill 没有单独示例目录，文章里的片段依据入口、主 Prompt 和评测约束整理。

相关 Skill

产品质量视角先回答用户任务和业务取舍；下面的 Skill 分别补齐角色协作、QA 证据和体验细节：

Skill什么时候接上它补什么
多角色质量汇总产品、QA、技术和体验材料需要合并时保留各角色证据与分歧，形成可决策的摘要
QA 质量视角产品风险需要落到覆盖、缺口和发布证据时检查测试结论能否支持具体发布判断
UX 质量视角用户任务卡在可理解性或失败恢复时把体验问题落到状态、影响和可验证动作
技术质量视角产品规则依赖接口、数据或恢复能力时把业务风险连接到运行后果和技术证据
项目交付视角范围、依赖和验证窗口影响发布日期时跟踪交付条件，但不替产品或 QA 做批准

同一研发流程，产品视角输出什么

产品、QA 和 UX 三个 Skill 使用同一组研发阶段，关注的问题不同，报告也会不同。拿会员升级改动来说，产品视角始终追问“这件事对用户和业务意味着什么”，不会把每个阶段都写成测试清单。

阶段产品视角要问什么输出给团队的内容
需求分析用户价值、业务规则、范围和验收是否明确产品报告、规则缺口、待确认问题和责任角色
测试策略哪些旅程和失败后果最值得保护，取舍是否能解释用户/业务风险优先级和决策所需证据
测试策略评审被排除或降级的风险是否有产品依据和接受人对策略取舍的发现、影响和修订动作
代码评审变更是否能回到用户价值、业务规则和验收标准用户影响问题，以及需要开发或 QA 补的证据
测试用例编写用例意图是否保护关键旅程和业务规则产品优先级、缺失规则和可验证的结果定义
测试用例评审用例预期是否代表用户能感知的业务结果覆盖缺口、业务歧义和待补材料
测试报告编写已测、未测和阻塞会怎样影响用户与业务决策产品影响说明、残余风险和发布待决项
测试报告评审报告结论是否追溯到用户价值、规则和真实证据风险、信息缺口、行动和信心等级

产品视角的输出合同固定包含摘要、事实、证据、发现、风险、信息缺口、待确认问题、行动和信心等级。它会解释测试状态的产品影响，但不会把建议写成测试通过或发布批准。

同一份研发材料交给三个视角时，输出可以这样区分：

共同材料：支付回调延迟产品质量视角QA 质量视角UX 质量视角
需求、PR、回归记录、支付日志、超时录屏确认等待规则、重复扣款风险和业务接受人判断超时、重试、对账是否真正执行并有证据检查用户是否看懂处理中/超时状态并能恢复

会员升级场景里，产品证据要回答什么

从用户价值与业务规则评审会员升级功能的范围、失败状态和验收缺口。示例片段把产品问题落到用户动作和业务结果。

产品问题证据判断
用户是否理解升级权益权益说明、价格页、可用性记录说明缺口会直接影响转化和投诉
支付失败后能否继续支付回调、订单状态、重试记录失败路径决定是否产生重复扣款
试用资格是否稳定规则文档、账户数据、边界用例资格漂移会破坏用户对产品的信任

先把用户任务、业务规则和证据放在一起，再让产品负责人决定取舍。

指标下降时，先回到用户任务

转化下降、退款增加和客服投诉上升都需要回到具体任务解释。产品视角要把信号、假设和下一步验证写在同一张表里。

信号候选解释下一步验证
升级转化下降价格变化、权益不清或支付失败分段漏斗、支付日志、用户访谈
退款率上升权益交付延迟或规则误解订单状态、权益到账时间、客服工单
投诉减少入口被隐藏，用户没有继续尝试入口曝光、放弃率和新用户反馈

结论要保留信号来源和仍未验证的假设。Skill 可以整理选项，产品负责人负责决定范围和发布条件。

放进研发过程：从需求到发布跟住同一条产品风险

产品质量判断要进入研发的交接点，而不是在发布会议前临时补一段结论。会员升级可以沿着下面这条路径走：

研发环节输入材料要回答的问题交付物
需求评审会员规则、价格页、权益说明、用户任务用户要完成什么，什么结果不可接受业务规则、验收缺口、待确认问题
设计与开发联调页面状态、接口契约、订单状态流转支付成功、处理中、失败和重试是否有一致定义状态表、边界规则、联调记录
测试与缺陷复核用例、订单样本、支付日志、客服反馈哪些风险已经有证据，哪些只是产品假设风险清单、证据索引、补测动作
发布评审构建号、漏斗数据、残余风险、负责人这次范围是否足以支持发布，谁接受剩余风险产品决策记录和后续动作

以“支付回调延迟”为例，产品、开发和 QA 可以围绕同一组事实协作：产品先确认用户是否会看到“处理中”以及最长等待时间；开发说明订单状态、回调幂等和权益发放的实现边界；QA 保留超时、重试和对账证据。三方都说“支付有问题”，信息还是太粗，下一步没有人知道从哪里开始。

可以把验收规则写得更具体一些：

  • 支付成功后，订单状态和会员权益最终一致，重复回调不会重复发放权益。
  • 支付处于处理中时，页面给出可理解的状态和下一步，用户不会被引导重复付款。
  • 支付失败时，订单不会被误标记为成功，用户可以安全重试或联系支持。
  • 试用资格、价格和权益说明来自同一版本的业务规则，测试数据和发布材料记录来源。

下面是一份假设材料下的产品质量记录。它展示结构，不代表某个真实项目已经发生过这些结果。

stage: test-report-review
user_task: 会员完成升级并立即获得权益
business_rule: 同一订单重复回调只能产生一次权益发放
facts:
  - 构建号 build-2026-09-24-01 的成功支付样例已保存
  - 支付超时样例只有页面截图，没有订单状态和回调日志
evidence:
  - checkout-success-report.html
  - order-1234-event-log.json
inference:
  - 超时恢复路径仍然无法支持“不会重复付款”的判断
unknown:
  - 处理中订单的最长等待时间和客服兜底规则
risk: high
action: 补充超时、重复回调和对账记录，再由产品确认等待文案
owner: 支付负责人 / 产品负责人
confidence: medium

开发联调时，产品负责人可以直接检查 business_rule 是否写进接口契约和验收条件；QA 可以从 evidence 反查运行记录；发布负责人只需要看 unknown、risk 和 owner，不用从聊天记录里捞结论。记录短一点没关系，字段要能接上下一步。

产品摘要可以短，但用户任务、业务规则、证据、产品风险、行动和信心不能省。产品视角提供判断材料，不替团队做代码正确性、测试通过或发布批准结论。

一段可以直接改的调用词

把下面的方括号换成项目内容。材料越具体，Skill 越少猜。

请使用 product-quality-perspective Skill。

阶段：测试报告评审（stage: test-report-review）
任务：从用户价值与业务规则评审会员升级功能的范围、失败状态和验收缺口
版本与环境：[需求版本 / 构建号 / 环境]
输入材料：[文件路径或链接]
范围：[本次包含与排除的业务链路]
限制：[账号、数据、时间、合规要求]

请按“摘要、事实、证据、发现、风险、信息缺口、待确认问题、行动、信心等级”输出。重点说明用户任务、业务规则、验收标准和业务影响；每条判断标明来源。没有材料支持的内容写成缺口或假设，不要输出代码正确性、测试通过或发布批准结论。

先用需求、规则和现有证据跑一遍，找出业务缺口；材料补齐后，再生成正式产物。

产品视角要把质量落在用户完成任务上

会员升级要同时检查页面状态、权益理解、支付完成和失败恢复。产品视角先列主任务、关键规则和不可接受的失败：重复扣款、权益延迟到账、试用资格丢失。这些情形决定验收优先级。

指标也要回到任务。转化下降可能来自价格，也可能来自支付失败；投诉变少也可能只是入口消失。结论里写出用户信号、业务规则和仍未验证的假设，产品负责人才能决定是否调整范围或继续发布。

这个 Skill 适合谁

产品经理可以用它检查验收标准是否真的对应用户任务；QA 可以用它补齐业务风险和不可接受的失败；交付负责人可以用它把转化、信任和范围取舍写进发布判断。材料不足时，它会留下问题清单，不会替团队编造用户结论。

产品判断交付前复核

产品质量记录要能回答“用户要完成什么、规则是什么、证据在哪里、业务会承担什么影响”。复核时还要确认它没有越过产品视角的边界。

复核项需要留下缺失时
用户任务目标用户、关键路径和不可接受的失败写成待确认问题，不替用户补规则
业务规则与范围规则来源、包含项、排除项和验收条件标记规则缺口和影响范围
证据与判断订单、日志、反馈、验收记录及其对应结论区分事实、推断和假设
产品风险与行动用户/业务影响、负责人、下一步和信心等级不把风险压成“整体可控”
职责边界产品影响说明，不包含代码正确性、测试通过或 Go/No-Go退回相关角色补充判断
stage: test-report-review
user_task: [用户要完成的任务]
business_rules: [规则来源和关键规则]
scope: [本次包含项 / 排除项]
acceptance_risks:
  - statement: [用户或业务风险]
    evidence: [证据链接或文件]
    status: verified / assumption / pending
actions:
  - owner: [负责人]
    next_action: [下一步]
confidence: high / medium / low

产品记录可以引用 QA、技术或 UX 材料，但要保留这些材料的原始边界；它们只能支持产品影响判断，不能被改写成产品视角之外的结论。

安装与调用

安装单个 Skill 就够了。项目总览里的安装说明不再在每篇重复。

npx skills add https://github.com/naodeng/awesome-qa-skills/tree/main/skills/zh/testing-workflows/product-quality-perspective -g

调用时直接写“请使用 product-quality-perspective Skill”，然后附上真实材料。

常见问题

转化下降时，Skill 会直接判断原因吗？

不会。它会把价格、支付、权益和入口等候选原因分开，并列出需要补的证据。

没有用户研究数据怎么办？

先使用需求、埋点、工单和订单记录，明确哪些结论只是风险假设，再安排用户研究确认。

产品质量结论可以直接替代发布评审吗？

不可以。它提供用户和业务证据，发布评审仍要结合测试、技术和运营风险。

什么时候算产品风险已经收敛？

关键任务、业务规则和失败恢复都有来源，剩余风险有负责人、接受人和截止时间时，才算进入可决策状态。

拿一份真实的用户任务、业务规则和订单证据跑一次产品质量视角，保留输入、输出和复核意见。文章里的片段只能帮你搭起结构，项目证据还得在项目里产生。

参考

安全测试白盒测试背靠背测试本地化测试边界测试
分享