让编程 Agent 随 UI 修复交付回归断言

UI 修复提交后，AI Agent 经常附上一串手工验收步骤：点击按钮、检查移动端、验证空状态。作者认为，这些条目很快就会过期，也无法在回归发生时让 CI 报错。他给出的替代要求很具体：为这次修改补一条修复前失败、修复后通过的 Playwright 断言。

这篇短文值得读的地方，是把「请帮我验证」变成了可审查的交付要求。不过，它提供的是作者的实践取舍，没有对照实验，也没有证明所有 UI 修改都适合只补一条断言。

一条断言，要证明什么才算有用

作者所说的「一条断言」，不是随便写一个能通过的 expect，而是围绕本次修改的一次交互，检查用户能看到的结果，例如错误文案、按钮状态或 URL。

它还必须满足几项约束：复用仓库已有的测试辅助函数、页面对象和 fixture，沿用同目录的元素定位方式，并与 UI 修改放进同一个 PR。邻近测试用 getByRole 就跟着用，用 data-testid 也可以，重点是保持现有约定。

最关键的验收证据，是没有修复时，这条断言确实失败。

只展示绿色结果，证明不了测试覆盖了原来的缺陷。Agent 可能选了一条始终正常的操作路径，测试执行得很顺利，却根本没有触发问题。先展示修复前的失败输出，再展示修复后的通过结果，才能检查测试是否对这次修复敏感。

如果 Agent 找不到可以复用的 helper，作者把它视为该流程可能尚未被测试覆盖的信号。这能暴露缺口，但还不能直接断定仓库没有相关测试，也可能需要继续查找。

怎样让 Agent 交付测试，而不是验收文案

作者给出的提示词，针对结账表单里邮编与城市字段的校验问题，同时限定了文件位置、复用方式、交互步骤和交付证据：

Add one Playwright assertion for the checkout zip-before-city fix.

Constraints:
- Extend `e2e/checkout.spec.ts` (or the nearest existing file)
- Reuse helpers from `e2e/helpers/checkout.ts` — do not invent a second page object
- One interaction: blur city with empty zip → expect the existing error copy
- No new test runner, no `page.waitForTimeout`, no screenshot-only checks
- Show the failing assertion output before the fix, then the green run after

If you need a new framework or a second suite, stop and explain why.

最该检查的是 Show the failing assertion output before the fix 这一行。它要求 Agent 提供执行证据，而不只是写出一段看起来合理的测试代码。原文没有附上这条测试的实际实现或运行日志，因此这里展示的是提示词范式，并非已经复现的案例报告。

其他约束也各有目的。指定 e2e/checkout.spec.ts 和 e2e/helpers/checkout.ts，是为了把新测试接入既有体系，避免另起一套页面对象。禁止 page.waitForTimeout，是为了避免依靠固定等待时间碰运气；机器负载变了，固定时间未必够用，也可能白白拖慢执行。

作者也不接受只看截图差异来证明行为修复。截图可以记录外观，但这次要求验证的是：邮编为空时，让城市输入框失去焦点，是否出现已有错误文案。断言应该直接落在这个结果上。

同样，如果 CI 已经使用 Cypress，就沿用 Cypress；已经使用 Playwright，就沿用 Playwright。为了一个局部修复增加第二个测试框架，会把验证问题扩成维护问题。

我的判断

我认同作者对局部 UI 缺陷的要求：把容易重复出现的问题变成可执行检查，比在 PR 里留下 40 步模板清单更容易持续发挥作用。测试失败还可以反过来检验 Agent 是否理解了触发条件，而不只是改出了表面效果。

但「更持久」有前提。测试要接入 CI，数据和环境要足够稳定，断言还要落在真正重要的用户行为上。否则，一条测试也可能长期被跳过，或者因为频繁误报而失去信任。原文没有提供维护成本、误报率或回归减少幅度，这部分应当按经验建议看待。

「一个 expect 通常就够」也需要限定范围。对于一个明确的校验缺陷，这个目标很实用；如果修改影响多条分支或多个页面，就不能为了守住数量而遗漏风险。手工探索、视觉检查与自动化断言各有用途，这篇文章有力反对的是：把一份没人重跑的清单，当作唯一验证成果。

能拿来做什么

• 修复前端表单、按钮状态或跳转问题时，在 Agent 任务中写清触发步骤和预期结果，并要求测试随同一个 PR 提交。
• 在提示词里提供现有 spec 和 helper 路径，要求沿用邻近测试的定位方式；仓库使用 Cypress 时，直接把要求改成已有框架。
• 审查 AI 生成的测试时，同时检查修复前失败、修复后通过的输出，并确认失败原因对应原来的缺陷。
• 对包含 page.waitForTimeout、仅比较截图或新建第二套测试体系的草稿，先缩小到本次修改的一次关键交互，再检查行为断言是否足够。