AI 写的网页能打开，接下来怎么验收？拿一个保存在浏览器本地的待办页来说，可以沿着五个具体场景检查。
它们不用覆盖整个项目，却能抓住不少“第一次点起来没问题，刷新就坏了”的情况。
| 场景 | 应该看到的结果 |
|---|---|
| 新增一条任务后刷新 | 任务还在 |
| 删除后刷新 | 被删任务不回来，其他任务仍在 |
| 输入一串空格 | 不新增空任务 |
| 读到无法解析的缓存 | 页面能继续新增，并在刷新后保留 |
缓存能解析但结构错误，例如 {} |
新增→刷新→再新增→再刷新，两项都保留 |
最后一项尤其容易漏掉。JSON.parse('{}') 不会报错，但后续代码如果把它当数组用，仍可能出问题。
先在演示副本里构造异常
前三项可以直接点。后两项请在复制的演示项目里准备异常数据，不要拿真实资料试覆盖。
让 Codex 做时，可以把任务写完整：
1 | 保持页面样式，为待办页补上表中五项独立浏览器测试。 |
独立准备数据能避免前一项测试留下的状态掩盖问题；可等待的网页断言则用于检查最终行为。Playwright 测试实践
本例补的是测试
原项目本来就有数组结构校验。2026年10月9日这次工作补齐了第5项回归测试，本地 Windows / Edge 共5项通过，不能把它写成刚修复了一次线上故障。
如果你的实现选择在坏数据时弹出恢复提示，而不是清空到空清单，验收预期也应跟着产品设计调整。测试应该描述约定的行为，而不是把教学例子的策略硬套进所有项目。
原笔记发表于2026年10月11日；本文10月27日整理，没有重跑旧测试，也没有扩大到手机、其他浏览器或跨设备环境。