验收前端页面，最靠不住的一句话是"代码能跑"。

构建通过只能证明产物链没问题，证明不了页面在浏览器里的真实行为。Codex 改完一个表单，我在代码里看不出提交按钮到底有没有绑对事件，看不出接口失败时页面会不会弹错，看不出小屏下按钮有没有被挤掉。

所以我现在的做法是，让浏览器真的把页面点一遍。这个活我从 GitHub 拉了一个现成的 skill 来做，叫 webapp-testing。

它在 GitHub 的哪个位置

它和上一篇的 web-artifacts-builder 在同一个官方仓库，github.com/anthropics/skills，Apache 2.0 许可。

我把 SKILL.md 拉下来核对过，它定位是本地 Web 应用的测试工具，基于 Playwright 写 Python 脚本，还带一个 with_server.py 负责把开发服务器管理起来。

它怎么让页面动起来

skill 的核心思路不是让你手写一整套测试框架，而是分两步走。

先用 with_server.py 把服务器拉起来。它支持单个服务器，也支持前后端一起起。比如前端跑在 5173，后端跑在 3000，可以一次都交给它管理，自动化脚本里就不用手动处理启动顺序。

python scripts/with_server.py \
  --server "cd backend && python server.py" --port 3000 \
  --server "cd frontend && npm run dev" --port 5173 \
  -- python your_automation.py

然后再写 Playwright 脚本，只负责页面操作。headless 的 Chromium，打开地址，等网络空闲，然后找按钮、填输入框、点提交、看结果。

这个分工很干净。服务器生命周期归脚本管，页面验证归测试代码管，各管一段。

静态页和动态应用要分开走

skill 里给了一个决策树，我照着用下来觉得最有用。

静态 HTML 页面，直接读 HTML 文件找选择器，然后写 Playwright 脚本。动态应用就要小心，它给了一条侦查再行动的顺序，先打开页面等网络空闲，截图或者检查 DOM，找到真实的选择器，再执行点击和填写。

这里有个坑我必须盯着 Codex，动态应用没等网络空闲就急着查 DOM。页面数据还没渲染完，截图是空白的，找按钮找半天找不到，Codex 容易以为选择器写错了。skill 把它标成 common pitfall，我也把它写进验收提醒。

我怎样把它接进 Codex 的验收

我不会让 Codex 每改一个组件都写一套完整测试，那样太重。我会在任务里限定关键路径。

按 webapp-testing 的 SKILL.md 写一段 Playwright 验证脚本。
用 with_server.py 启动前端开发服务器。
覆盖这条用户路径：进入列表页、点击新增、填写必填项、提交、确认列表出现新数据、再删除这条数据。
脚本只验证本次改动涉及的行为，不改动任何业务代码。
跑完把每一步的页面结果写在交付说明里。

这份任务的价值在验收。Codex 之前给我的交付说明里写"功能正常"，现在它能给我一段脚本跑出来的真实页面路径。能不能跑通，跑一遍就知道。

和前两篇的功能差异

这条 GitHub skill 主线我连着写了几篇，每篇补的环节不一样。

web-artifacts-builder 管把页面写出来，是生成。systematic-debugging 管 bug 怎么修对，是调试。webapp-testing 管页面到底成没成，是验证。

生成类解决怎么写，调试类解决怎么改，验证类解决怎么信。三条正好接成一条前端任务的收尾链，写完的页面用浏览器过一遍，有问题回调试，改完再验证一遍。

适用边界

这个 skill 依赖 Python 和 Playwright，项目里得有这套环境才能跑。

它能验证页面行为，验证不了接口契约，验证不了性能，也验证不了设计是否合理。它只能回答"点了一遍，结果符合预期"，回答不了"这么设计对不对"。

遇到动态应用不等网络空闲就查 DOM，是它最常见的坑，我会在任务里单独提醒 Codex。而页面验证这事，不管用不用这个 skill，我都会让浏览器真点一遍，只是现在这个活有了更顺手的工具。

下一篇继续这条主线，换一个作用在写代码之前的 skill。生成、调试、验证都在代码完成后才起作用，而 test-driven-development 要求 Codex 在写实现之前，先交一份会失败的测试。

本系列持续更新。GitHub 上的 skill 我从生成、调试、验证一路找过来，现在补最后一块，写之前就先定行为。