项目交付视角 Skill：从范围与依赖变化评估交付风险

8 分钟阅读 PolyForm Noncommercial 1.0.0

AI 测试Agent Skills项目交付视角

判断能否交付，要同时看范围、节奏、证据和后果。日期本身不能证明版本已经就绪，真正有用的是把承诺和前置条件放在同一张表里。

项目交付视角 Skill 把里程碑、前置条件和取舍放在一起，用就绪信号检查承诺是否还能兑现。

本文用会员升级 v3 的排期做例子，说明依赖延期时，范围、验证窗口和责任人如何一起调整。

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 仍填写括号里的英文键名。

先说清楚支持边界：项目交付视角只支持测试策略、测试策略评审和测试报告评审。其他阶段可以为交付判断提供上下文，但不能直接用这个 Skill 生成项目交付结论。

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

相关 Skill

项目交付视角负责把承诺、依赖和责任人放在同一份交付判断中。发生变更后，可以按下面的顺序衔接：

Skill什么时候接上它补什么
变更影响分析需求、代码或依赖发生变化时识别受影响的系统、角色、证据和交付物
回归范围分析影响面已经明确，需要安排验证时把风险映射成必须回归、可抽样和可延后的范围
生产验证版本已发布，需要确认真实环境时用可回滚、可观测的检查验证关键路径和止损条件
多角色质量汇总产品、QA、技术和 UX 已提供同一阶段报告时保留共识、分歧和来源，再交给交付视角跟踪动作
技术质量视角依赖、稳定性或恢复证据影响交付承诺时提供运行后果、技术缺口和恢复证据

同一研发流程，交付视角接住什么

交付视角不是把八个阶段都重新评审一遍，而是只在支持的三个阶段里整理范围、依赖、里程碑、责任人和行动状态。其他阶段的产物要先由对应角色 Skill 产生，再作为交付约束的输入。

研发阶段交付视角的处理方式应该交给谁或留下什么
需求分析不直接执行；只接收已经明确的范围、排除项和验收前置条件由产品、QA、技术或 UX 输出事实，再登记依赖
测试策略支持阶段；记录目标日期、产能、环境、依赖、里程碑和 Owner输出项目约束、行动跟踪和信息缺口
测试策略评审支持阶段；检查策略取舍是否有截止时间、责任人和升级路径输出可执行的交付选项，不改写质量事实
代码评审不直接评代码；只保留代码评审暴露的依赖或返工影响由技术质量视角提供技术发现和证据
测试用例编写不直接设计用例；记录用例规模、数据和环境对窗口的影响由 QA 质量视角提供验证工作量与缺口
测试用例评审不替 QA 判断用例是否通过；跟踪评审行动是否影响里程碑保留行动 Owner、截止时间和状态
测试报告编写不替执行方生成报告；等待运行身份、结果和失败证据由 QA/测试报告 Skill 提供质量事实
测试报告评审支持阶段；把质量事实、项目约束和未决行动分区输出评审时点、依赖阻塞、行动和协同问题

同一件事在这组文章中的位置不同：技术质量视角回答“依赖失败会怎样”，多角色质量汇总回答“各角色的证据哪里一致、哪里冲突”，项目交付视角回答“在已有条件下，范围和日期怎么调整”。

发布计划要把承诺和前置条件放在一起

这里从排期、依赖和责任人出发，整理版本进入发布评审所需的范围、验证和责任条件；这不是项目交付 Skill 单独做 Go/No-Go 决定。

交付条件当前证据失效后的动作
范围已冻结的需求、排除项和验收标准记录变更影响，重新估算日期
外部依赖接口、环境、数据和审批的承诺时间指定替代方案和最晚升级时间
验证窗口回归、灰度和回滚所需时长缩小范围或延后发布
责任人每个交付物和风险都有 Owner未指定 Owner 的事项不能标完成

每个条件都要有来源、截止时间和失效后的动作，计划才真的能驱动交付。

会员升级 v3 的交付跟踪示例

下面的项目输入是假设的。真实报告只有在材料明确提供日期、责任人和状态时，才能把这些字段写成事实；没有来源就标成缺口。

里程碑已提供的前置条件Owner截止时间条件失效后的动作
范围冻结PRD-42 已列出会员升级主链路和排除项产品负责人周三 12:00重新估算范围，不把未确认需求算入按期承诺
沙箱回调支付依赖方承诺提供超时与重复回调样例支付服务负责人周四 12:00记录依赖阻塞；只能使用模拟服务时，不把真实回调验证写成完成
回归窗口QA 预留结账、权益和对账回归时间QA 负责人周五 10:00—14:00缩小范围或延后，不用“时间不够”改写执行状态
回滚演练已安排候选版本的回滚和数据校验发布负责人周五 14:00—15:00进入协同问题，等待授权负责人决定是否调整发布计划
QA 执行状态QA-42 记录超时回调尚未执行QA 负责人周五 14:00 前补测后更新质量事实，不改写成通过

如果支付依赖方周四没有交付，交付视角可以输出三种选项：继续等待并调整日期、缩小到已具备证据的链路，或者把候选版本拆成两次发布。它不能把模拟服务的结果写成真实依赖已通过，也不能把尚未执行的回归标记为通过。

一个可交接的记录可以这样写：

stage: test-report-review
milestone: 会员升级 v3 发布评审
scope: [主链路，权益发放，支付回调]
dependencies:
  - name: 支付沙箱回调
    source_id: DELIVERY-42
    due: 周四 12:00
    status: pending
validation_window:
  owner: QA 负责人
  window: 周五 10:00—14:00
  source_id: QA-PLAN-42
retained_quality_facts:
  - source_id: QA-42
    statement: 超时回调尚未执行
    status: not_run
decision: pending
next_action: 确认依赖交付；若未交付则提交缩小范围或延期选项
owner: 发布负责人

这里的 decision 仍然是 pending。交付记录负责让人、日期和退路可见，不负责替发布负责人做 Go/No-Go 决定。

交付结论要写成可执行决定

“按期发布”不是唯一选项。Skill 需要把继续发布、缩小范围、延后或拆分发布的条件写清楚。

选择适用条件必须留下的证据
按计划发布范围冻结，依赖和验证窗口均满足发布清单、回归结果、回滚演练
缩小范围核心链路就绪，低风险功能仍缺证据排除项、用户影响和补做日期
延后发布核心依赖或回滚条件未满足阻塞原因、升级路径和新日期

每个决定都要标出批准人和最晚确认时间。Skill 整理条件和证据，不替项目负责人做承诺。

交付摘要可以短，但项目约束、行动跟踪、保留质量事实、信息缺口和下一步交付行动必须保留。项目交付视角不产出质量或 Go/No-Go 结论。

一段可以直接改的调用词

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

请使用 project-delivery-perspective Skill。

阶段：测试报告评审（stage: test-report-review）
任务：从排期、依赖与责任人角度整理版本进入发布评审所需的范围、验证窗口和责任条件
版本与环境：[需求版本 / 构建号 / 环境]
输入材料：[文件路径或链接]
范围：[本次包含与排除的业务链路]
限制：[账号、数据、时间、合规要求]

`stage` 只能使用 `test-strategy`、`test-strategy-review` 或 `test-report-review`。请提供有来源的日期、容量、依赖、里程碑、Owner 和行动状态，并按“摘要、项目约束、行动跟踪、保留的质量事实、信息缺口、协同问题、下一步交付行动、信心等级”输出。项目约束和质量事实分开记录；不要修改缺陷状态、执行结果、测试通过状态或发布决定。

先把日期、依赖、Owner 和行动状态填齐，再讨论按期、缩小范围还是延期。

交付视角关心的是承诺还能不能按现有条件兑现

范围变更、外部依赖和验证窗口一起滑动时，项目最容易用“基本完成”掩盖风险。交付视角把必须交付、可延后、依赖方承诺和验证截止日放到同一张计划里，明确哪一个条件失效会改变发布日期。

风险不是一串红黄绿标签。每项风险要有 owner、最晚决策时间和退路：接口未就绪时使用模拟服务还是拆分发布，测试环境不可用时延期还是降级验证。这样团队讨论的是动作，不是情绪。

这个 Skill 适合谁

项目经理可以用它检查计划是否包含验证和回滚；QA 可以据此提出测试窗口；技术负责人可以明确依赖和恢复条件。它适合需要把“能不能按期交付”变成证据和动作的团队。

项目交付记录复核

项目交付记录要让承诺、前置条件和退路可追踪，但不能替质量报告做结论。复核时把项目事实和保留的质量事实分开看。

复核项需要留下缺失时
支持阶段仅 test-strategy、test-strategy-review、test-report-review其他阶段转交对应 Skill
项目来源日期、容量、依赖、里程碑、Owner、时间窗口和行动状态标为信息缺口，不写成承诺
项目约束范围、依赖、验证窗口、资源和退路写明失效条件与升级路径
保留的质量事实原始来源、状态、证据和严重性不改写成通过或完成
交付行动负责人、截止时间、下一步和待决策项不能作为已关闭事项
决策边界记录选项和条件，不替授权人做 Go/No-Go明确等待批准人
stage: test-report-review
project_constraints:
  - source_id: [项目来源]
    constraint: [范围、依赖、日期或验证窗口]
    status: pending / blocked / verified
action_tracking:
  - owner: [负责人]
    due: [截止时间]
    action: [下一步]
    status: pending
retained_quality_facts:
  - source_id: [质量报告来源]
    statement: [原始质量事实]
    status: verified / not_run / blocked
decision: pending
confidence: high / medium / low

如果质量报告只说“尚未执行”，项目记录就保留这个状态，并把补测列为行动；不能因为里程碑临近而把它改成“已完成”。

安装与调用

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

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

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

常见问题

日期没变，为什么还要重新评估？

因为依赖、范围和验证窗口可能已经变化。日期只是承诺，前置条件才是交付证据。

外部依赖延期时怎么办？

记录影响、替代方案和最晚升级时间，再决定拆分范围或调整发布计划。

怎样判断风险已经有人负责？

每项风险都有明确 Owner、决策人、截止时间和可验证的关闭条件。

Skill 能直接决定 Go/No-Go 吗？

不能。它输出选项、条件和证据，发布决定仍由有权限的人确认。

准备一份带日期、Owner 和依赖来源的计划，再做一次项目交付视角分析，并保留输入、输出和复核意见。文中的片段只能帮你搭起结构，真正的项目证据仍要在项目中产生。

参考

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