多角色质量汇总 Skill：整合质量分歧形成可决策结论

8 分钟阅读 PolyForm Noncommercial 1.0.0

AI 测试Agent Skills多角色质量汇总

同一个发布版本，在产品、QA、研发和运维眼里可能呈现出四种不同的风险图景。多角色质量汇总要保留这些差异，再把事实、影响和决策条件放到同一份材料里。

多角色质量汇总 Skill 把不同视角、假设和未解决风险放到一起，让跨职能团队即使存在分歧，也能基于同一份材料做决定。

本文以支付回调为例，展示如何在同一研发阶段里对齐产品、QA、UX、技术和项目约束。

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）。阅读时看中文名称，调用 Skill 时 stage 仍填写括号里的英文键名。

多角色质量汇总不是把八个阶段混成一份大报告。一次汇总应该只接收同一个阶段的角色报告；如果同时收到需求分析和测试报告评审，应该先拆开，分别汇总。产品、QA、UX 和技术 Skill 负责产生各自视角的阶段报告，多角色质量汇总负责整理这些报告，不替它们重新做一遍专业判断。

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

相关 Skill

多角色质量汇总不替任何角色做专业判断，只负责把输入校验、冲突和责任边界写清楚。下面前四项是常用的角色输入 Skill；项目交付视角提供项目约束，不属于质量角色报告：

Skill主要输入汇总时要保留什么
产品质量视角用户任务、业务规则、转化和反馈用户价值、业务取舍和未验证假设
QA 质量视角覆盖、用例、缺口和运行结果证据范围、残余风险和发布门槛
技术质量视角架构、日志、指标、Trace 和回滚记录运行后果、恢复能力和技术约束
UX 质量视角任务观察、可访问性和失败恢复记录用户影响、复现路径和体验改进动作
项目交付视角范围、依赖、里程碑和责任人把质量材料接到交付条件，但不改写质量事实

同一研发流程，汇总视角怎样接住不同输出

前面的产品、QA、UX 和技术文章使用同一组研发阶段，但每个阶段的关注点不同。多角色质量汇总接收这些同阶段报告，负责来源登记、事实分类、等价发现合并和冲突保留，不替任何角色补写一份“平均意见”。

研发阶段进入汇总的材料汇总视角要交付什么
需求分析产品规则、QA 可测试性、技术约束、UX 任务证据共同事实、输入缺口、角色分歧和待确认问题
测试策略覆盖优先级、技术风险、体验路径和项目约束质量事实与项目约束分区，保留各来源的取舍
测试策略评审各角色对范围、退出条件和降级风险的意见共识、冲突严重级别、阻塞项和行动来源
代码评审产品影响、QA 静态发现、技术 diff 观察和 UI 影响只合并语义等价发现，保留代码身份和证据边界
测试用例编写业务规则、可测入口、技术失败模式和体验状态用例相关共识、缺口和仍需谁确认的条件
测试用例评审用例可执行性、覆盖、可观察性和用户路径区分事实、风险和建议，不把建议写成执行结果
测试报告编写命令结果、产品影响、运行信号、体验观察统一运行身份和范围，保留 verified、not_run、blocked 等状态
测试报告评审各角色的结论、证据、项目要求和剩余风险共同事实、分歧、决策选项、批准人和信息缺口

这里的“交付”指汇总报告的交付，不等于发布批准。尤其在测试报告评审阶段，不能因为项目日期临近，就把 QA 的未执行项变成已完成；产品意见也不能覆盖技术报告里的高风险证据。

六篇文章可以这样串起来：产品、QA、UX 和技术视角分别看清问题，多角色质量汇总把同一阶段的报告放在一起，项目交付视角跟踪范围、依赖、时间和责任。它们可以串联，但输出不能互相替代。

不同角色怎样提供可合并的材料

合并产品、QA、UX 和技术视角时，要保留分歧，形成质量结论。

角色关注点必须带上的证据不能替对方做的决定
产品用户任务、转化和业务规则漏斗、验收记录、用户反馈是否调整范围和目标
QA覆盖、缺口和残余风险用例、运行记录、缺陷是否接受测试证据不足
技术稳定性、依赖和恢复日志、指标、Trace、回滚记录是否采用技术取舍
UX任务流、状态、可访问性和恢复原型、截图、录屏、复现步骤是否接受体验取舍

项目交付视角可以另外提供范围、依赖、日期和 Owner，但它属于项目约束，不应伪装成质量角色报告。汇总的第一步是检查每份材料有没有来源、时间窗口和明确的观察对象。

共同事实和冲突意见要分开写

假设支付回调在 staging 通过，产品会关注转化，QA 会关注异常覆盖，技术会关注生产配置差异——同一事实可以承载不同判断。

输出部分写法示例
共同事实所有角色都能指向的证据staging 支付回调通过，构建号为 build-42
冲突判断各角色的观察与影响分别保留QA 缺少超时用例；技术发现回滚窗口不足
待决策项选项、风险、批准人和截止时间缩小范围后发布，由产品负责人确认

不要把分歧压成“整体风险可控”。决策人需要看到每个选项会承担什么风险，以及还要补哪份证据。

会员升级示例：从四份报告到一个可决策输出

下面是一组假设材料，用来展示研发现场如何串联六篇文章。它不是当前项目事实；真实调用时必须替换成项目自己的 source_id、版本、环境和证据链接。项目交付约束单独登记，不和角色报告混在同一张质量输入表里。

source_id来源类型阶段观察与证据
PROD-42产品test-report-reviewPRD-42 规定支付成功后立即展示权益，但没有写回调超过 10 秒时的用户规则
QA-42QAtest-report-reviewRUN-42 只执行成功回调，超时和重复提交标记为 not_run
TECH-42技术test-report-reviewPR-42 的回调客户端缺少超时配置；代码观察来自提交 abc123，运行行为尚未验证
UX-42UXtest-report-reviewREC-42 在 iPhone Safari 录到等待状态没有进度说明，但只覆盖一个设备和一次路径

项目约束单独登记：

source_id来源类型阶段约束与证据
DELIVERY-42项目约束（非质量报告）test-report-review交付日历安排周五 18:00 评审，支付依赖方承诺周四 12:00 提供沙箱回调

汇总结果应把材料分成四层，而不是写成“多数角色认为可以发布”：

汇总区示例写法来源
质量事实成功回调已有一次执行记录；超时和重复提交尚未执行QA-42
技术发现代码中未看到超时配置；这只是静态观察，不等于已经证明线上必然超时TECH-42
体验发现一次录屏显示等待反馈不足，设备和路径覆盖有限UX-42
项目约束周五有决策会，沙箱回调有外部承诺时间DELIVERY-42
分歧与待决策待确认产品是否接受按期评审；QA 和技术材料提示应先补超时证据，批准人尚未提供PROD-42、QA-42、TECH-42、DELIVERY-42

可以把这个结果保存成下面的结构，后续交给项目交付视角处理时不用重新整理来源：

stage: test-report-review
common_facts:
  - id: FACT-01
    statement: 成功回调已有一次执行记录
    sources: [QA-42]
role_observations:
  - source_id: TECH-42
    finding: 回调客户端未见超时配置
    evidence: 提交 abc123 的代码观察
    status: static_observation
  - source_id: UX-42
    finding: 等待状态缺少进度说明
    evidence: REC-42
    status: limited_observation
conflicts:
  - topic: 是否具备按期评审条件
    sources: [PROD-42, QA-42, TECH-42]
    unresolved_reason: 超时与重复提交证据尚未补齐
decision_options:
  - option: 缩小范围后评审
    approver: pending
    required_evidence: [超时回调结果，回滚条件]
status: pending

这个模板有意保留 static_observation 和 limited_observation。汇总 Skill 可以整理它们，但不能把它们升级成“已验证”或“发布通过”。

汇总摘要可以短，但阶段覆盖、质量事实、项目约束、共识、分歧、阻塞项、行动和来源登记不能省。汇总 Skill 不投票，也不凭空增加批准人或新事实。

一段可以直接改的调用词

把方括号中的占位内容替换成项目实际信息。材料越具体，Skill 越少猜。

请使用 multi-role-quality-synthesis Skill。

阶段：测试报告评审（stage: test-report-review）
任务：合并同一测试报告评审阶段的产品、QA、技术和 UX 报告，形成保留分歧的汇总材料
版本与环境：[需求版本 / 构建号 / 环境]
输入材料：[文件路径或链接]
范围：[本次包含与排除的业务链路]
限制：[账号、数据、时间、合规要求]

每份输入都填写 `source_id`、`stage`、`source_role`、事实、证据、发现、风险、缺口、问题、行动和信心等级；所有输入必须是同一 `stage`。请按“阶段与输入覆盖、质量事实、项目约束、汇总发现、共识、分歧、阻塞项、信息缺口、待确认问题、行动、信心与限制、来源登记”输出。只合并语义等价的发现，保留冲突、原始严重性和项目约束；不投票，不新增材料中没有的事实。

先校验输入是不是同一阶段，再做汇总；阶段混在一起，越早“综合”越早把不同结论揉乱。

多角色汇总的工作是保留冲突，再让正确的人做决定

产品、QA、UX 和技术的结论发生冲突时，汇总不负责投票。它先把各方的事实、推断、影响和不可接受条件并排展示：产品担心转化，QA 缺少回归证据，UX 发现等待反馈不足，技术发现回滚窗口不足。它们都可能成立。

最终输出要落到一个可执行的决定上：继续发布并接受哪项风险，缩小范围后补什么证据，还是暂停等待哪个前置条件。每个选项标出决策人和截止时间，避免“综合来看可控”变成没人承担的结论。

这个 Skill 适合谁

发布负责人可以用它主持跨职能评审；产品、QA、UX 和技术可以用同一格式交付自己的阶段报告，项目负责人可以另外提供交付约束。它适合意见分歧、证据分散、需要明确批准人的质量决策材料。

汇总结果交付前复核

多角色汇总先复核输入是否可合并，再复核结论是否越界。尤其要确保项目约束没有覆盖质量事实，也没有因为角色缺席而假装形成共识。

复核项需要留下缺失时
阶段与输入覆盖所有输入的 stage、source_id、角色和字段完整性不同阶段拆开；缺失角色标为缺席
事实与约束分类质量事实、角色观察、项目约束和分析分区不让日期或资源约束改写质量事实
合并与冲突只合并语义等价发现，保留分歧和原始严重性保留原文和来源，不投票平均
阻塞与缺口阻塞条件、待确认问题、证据链接和限制不把缺口写成共识
行动与来源登记负责人、截止时间、行动状态、来源 ID 和信心等级汇总结果不能进入下一步评审
stage: test-report-review
role_reports:
  - source_id: [来源 ID]
    source_role: [产品 / QA / UX / 技术]
    completeness: complete / partial
project_constraints:
  - source_id: [项目约束来源]
    constraint: [范围、依赖、日期或资源约束]
consensus: [有来源支持的共同发现]
disagreements: [保留原始严重性和来源]
blocking_items: [阻塞条件]
actions: [负责人、截止时间和状态]
confidence: high / medium / low

如果某个角色没有报告，写成“该角色未提供材料”，不要用其他角色的观察代替。汇总只整理已有输入，不能补出新的质量事实。

安装与调用

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

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

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

常见问题

汇总结果必须只有一个结论吗？

不必须。共同事实、冲突意见和待决策项分开保留，反而更容易让负责人做出可追踪的决定。

某个角色没有材料怎么办？

标成缺席或代理分析，列出需要该角色确认的问题，不能替它补写观察。

谁负责最后的决定？

由有权限的产品、发布或技术负责人批准选项。Skill 只负责让依据和风险可见。

没有共同结论还能发布吗？

可以讨论，但必须列出未决风险、接受人和截止时间；没有这些信息就无法形成可审计的发布决定。

准备好同一阶段的角色报告后，就可以做一次多角色质量汇总，同时保留来源登记、输入、输出和复核意见。文中的片段只能帮你搭起结构，真正的项目证据仍要在项目中产生。

参考

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