把 Playwright trace 交给 AI 前，先截对一帧
把 Playwright trace 交给编码助手之前，先找出界面最后一次还符合预期的位置。
测试说「保存」按钮没出现，这句话只描述了最后一刻。表单可能根本没进到编辑页，也可能已保存、按钮换了名字。光看超时文字，两种情况很像。
交给编码助手的任务
让助手根据脱敏的 trace 摘要写时间线。要求每个判断区分「观察到」和「待确认」，先写最后一个正常动作和第一个异常响应，再建议检查哪个字段。不要上传含真实会话、个人数据或请求凭据的原始包。
Playwright 的 Trace Viewer 可以回看录制到的动作和页面快照，也能检查网络记录。找问题时，从最后一个成功动作和第一个失败动作之间下手，比从头读整个日志快。
先留一份能回放的记录
想重跑某一个失败用例时，可以临时开启 trace：
npx playwright test tests/settings.spec.ts --trace on路径换成自己的用例。从报告或输出目录找到对应运行的 trace.zip 后，用 npx playwright show-trace path/to/trace.zip 打开。持续集成里，如果已经开启重试，可以配置 trace: 'on-first-retry' 控制开销。这个模式录的是第一次重试，偶发问题如果只在原始失败那次发生，重试的记录可能没拍到现场。需要保留那次失败时，按安装版本的选项文档调整采集模式。
给助手三条观察
还是用设置页举例。一次可用的交接是：「点保存后，页面仍停在编辑态；对应请求返回 422；断言期待成功提示。」先查请求参数和表单约束，这比让助手把按钮等待从 5 秒改成 30 秒有效。如果请求成功、提示稍后才出现，才检查断言是否有等待行为。Playwright 的 expect(locator).toBeVisible() 会重试定位和断言；自己取一次布尔值再断言，含义不同。
最后，重跑同一个用例，再看结果是否真跨过了之前的失败位置。修好前后最好各留一份记录。对含真实账号、请求参数或业务数据的 trace，先在本地看，摘出需要的信息再分享。
先准备一个对照样例
以设置页保存为例，摘三条时间线记录：点击保存、POST /settings → 422、成功提示没有出现。给助手的是这条链和脱敏字段样例。若它建议增加等待，要求它解释响应里的 422 会怎样变成成功。
用这些结果验收
- 同一用例可重跑。
- 失败时能指向一条请求或界面状态。
- 修改后用相同输入走到原先失败的位置，且等待时间没有被随意拉长。
审查时容易漏掉什么
当 trace 显示 422 时，先找字段或验证规则的差异。只有响应成功、预期状态晚到，才调查断言是否等待。对只在首次失败出现的偶发问题，检查采集策略有没有记录第一次运行，重试的 trace 有可能只有一份正常现场。
也要检查 trace 中选择的是失败的运行而非重试成功的运行。给助手的摘录可附用例名、步骤名和错误发生的相对时间。如果测试重试前改变了数据，就要比较两次运行的初始条件，别把正常样本解释成偶发问题已经消失。
