一段录屏能展示Bug，却未必能让任何人把它修好。测试者点一下奖励按钮，关掉弹窗，再打开，按钮看起来是可用的，但下一次点击毫无反应。视频拍下了症状，却没有交代起始状态、构建版本和预期行为。

在游戏工作室的AI工作流里，真正有用的交接是一份小型的“修复契约”：可复现的输入、有边界的改动，以及评审者能据此判断的证据。执行方不该在还没查代码之前，就被迫替产品做决定。

下面这个例子是一个虚构的移动游戏UI缺陷。构建标签、路径和行为都是示意性的，不是某款已上线游戏的证据，也不代表存在真实的游戏录像或已完成的修复。

先把状态迁移说清楚

假设奖励面板有三种状态：可领取、领取中、已领取。领取成功后重新打开面板，应显示已领取状态；如果请求失败，玩家应当能够重试。

这就给QA分出两个不同用例：成功领取后重新打开必须保持已领取；领取失败后必须回到可领取。一句“把按钮修好”抹掉了这个差别，容易招来一个补丁——解决了一种情况，却弄坏了另一种。

记录成功用例时，要让面板和输入指示器都可见：用全新的测试配置和一份可领取奖励启动指定构建；打开奖励面板点一次领取；等待成功响应和奖励确认；关闭面板、重新打开，再点一次按钮；记录可见状态以及是否产生了额外的领取请求。录像应呈现完整的状态迁移，起始状态到故障之间不能剪接，并连同构建标识一起附到任务上。访问令牌、个人数据和内部通知不要出现在录像里。

让环境可复现

“安卓”不是环境描述。需要记录设备型号、操作系统版本、应用构建、源码版本、后端环境、功能开关、账号夹具和网络条件，并说明问题是在干净启动后就能复现，还是只有经过此前的游玩才出现。

对这个虚构案例，一份有用的报告会写明：测试配置含一份未领取奖励，成功响应为桩数据；另一份夹具返回失败响应。这些是搭建说明，不是实测的复现结果。如果QA无法稳定复现，就把这份不确定性留在任务里，请执行方先调查并报告条件，再承诺修复。

契约要在实现提示之前写好。模板可以这样列：标题为“重新打开面板时保持奖励领取状态”；证据栏附原始录像、构建与源码版本、设备与系统与后端、夹具；复现步骤三步走；预期包括重新打开后仍为已领取、已领取控件不能再次提交请求、失败请求恢复可重试状态。

允许范围限定在奖励面板状态恢复及其针对性测试，只有在调查证明必要时才动共享状态，且扩展前要说明依赖关系。排除范围包括奖励数额、经济规则、网络协议变更、账号迁移和无关的UI清理。交付要求包括根因与相关源码引用、补丁与针对性回归测试、确切的测试命令与环境及观察到的输出、用同样复现步骤拍摄的前后对比录像、剩余不确定性和未测试的设备情况。验收责任分三方：QA验证原始复现和重试用例，工程师评审正确性与共享状态影响，产品负责人裁定有争议的预期行为。

证据字段留空是有意为之。用看似合理的值填满，会让任务显得完整，却抹掉了复现能力。

给执行方一个窄的第一步

执行提示可以写得很具体：在给定环境中复现所附的奖励面板问题，追踪领取状态如何在面板销毁与重建之间存活，在改代码前确认权威状态，在允许范围内做最小且有理据的修复，为成功后重开和失败后重试各加一个回归测试，报告观察到的内容和仍未测试的部分。

不要在调查之前就规定一个布尔重置。清掉加载标志可能恢复输入，同时也可能放行第二次领取。实现方式取决于面板是持有临时视图状态、读取持久化领取状态，还是收到了过期响应。

QA准备复现与预期行为，开发者或智能体用各自被授权的工具和仓库访问权限执行调查，评审工程师和QA判断改动结果。写任务本身并不确立谁有权限运行它。

要能证伪补丁的证据

有用的回归测试必须能为它所描述的缺陷而失败。安排一份可领取奖励，完成一次成功领取，重建面板，断言已领取状态仍然可见且不能触发再次提交；另一个用例模拟失败，验证重试变为可用。

伪代码可以把边界讲清楚：打开面板并传入可领取奖励，领取并返回成功，关闭面板，重建面板，断言领取状态为已领取，断言不能提交领取。这是测试大纲，不是某个引擎可直接运行的代码，要按项目实际的状态模型和测试框架改写，并记录真实命令与输出，而不是把大纲当成测试已通过的结论。

评审者还应查看前后对比录像、失败请求的重试，以及补丁触及的任何共享状态。自动化断言无法证明最终按钮文案在原始设备上是否可读。

协调与验收要分开。准备确立输入，执行产出候选改动，验收需要人对照证据做判断。一个有边界的任务消除不了偶发的后端故障，也替代不了真机测试，但它能让这些限制在有人把看似合理的补丁误当成已验证修复之前就暴露出来。