Agent 写完前端，我要求它先自己点一遍
“改完了。”Agent 说。
我打开页面，弹窗出来了，却怎么也关不掉。我截图，描述现象，发回去。它几秒钟改完，我再刷新、再点。那个下午，我对着同一个页面重复了几十次：代码由它写，浏览器由我点，每一轮都要等我验完才能继续。
整个循环里，最慢的部分成了我的手。
“改完了”不等于完成
以前我默认 Agent 的交付边界是代码：文件改完、测试通过，它就可以报告完成。浏览器里的事留给我，毕竟最后总要有人点一下。
这个分工有个明显浪费。弹窗能不能关、空表单会不会报错、点击保存后页面有没有更新，这些都不是品味判断，只是有明确答案的行为验证。Agent 已经能启动 dev server、操作页面、查看 console 和截图，却在写完代码后停下来等我替它做最机械的一段。
我后来改的不是 prompt，而是“完成”的定义。前端任务没有经过浏览器自检，就还没有完成。
我写进项目里的规则
现在我会在项目规则里直接写：
前端改动在报告完成前，必须自行完成浏览器验收：
1. 启动本地服务，确认目标页面可以打开。
2. 走完本次改动涉及的核心交互路径。
3. 检查 console，不得出现新增报错。
4. 按验收标准核对关键状态，并提供截图。
5. 发现问题就修复后重新走一遍，不能把未验证的结果交给用户。这条规则改变的是交付顺序。Agent 写完弹窗逻辑后，要自己打开页面、触发弹窗、点击关闭，再检查页面状态和 console。关不掉，它会在报告“改完了”之前回到代码里继续修。等结果交到我手上，最便宜的错误已经在上一轮被消化了。
截图也不是装饰。它至少能证明 Agent 打开了正确页面，走到了声称验过的状态。涉及多个步骤时，我还会让它在说明里列出实际走过的路径，避免“页面能打开”被偷换成“功能已经验收”。
“走核心路径”也不能只写成一句空话。以一个新增弹窗为例，我会把路径写成：打开入口、触发弹窗、空表单提交、填写有效数据、关闭后重新打开。每一步都对应一个可观察结果。这样 Agent 才知道要走到哪里，我也能从报告里看出它有没有跳步。
验证范围同样要收住。改的是弹窗,就验弹窗相关路径;碰到响应式布局,再补桌面和移动宽度。让 Agent 漫无目的地把整个站点点一遍,既慢,也很难判断它所谓的”全部正常”到底覆盖了什么。
能写断言的，别先用浏览器
浏览器不是所有验证的第一选择。
API 返回、数据转换、权限判断这些能稳定写进测试的行为，继续交给自动化测试。测试跑得快，失败位置也更清楚。浏览器留给结构化工具覆盖不到的部分：真实渲染、跨组件状态、焦点、弹窗、表单和一段完整交互能不能走通。
顺序应该是先用最便宜、最确定的手段验证,再让浏览器补最后一段。否则 Agent 每改一行都重新点整套页面,只会把自动化变成更慢的人肉 QA。
人最后验什么
浏览器自检省掉的是第一轮机械验收，没有省掉人对产品的使用。
按钮有没有响应，Agent 可以按清单核对；按钮放在这里顺不顺手，要我自己用过才知道。颜色是否命中 design token 可以检查，层级是否舒服、文案是否别扭，仍然需要人的判断。我在上一篇讲过，离开实际使用，只看 diff，会漏掉手指和眼睛才能发现的问题。
所以我最后还是会打开页面，但不再替 Agent 检查弹窗能不能关、console 有没有红字。我接手的是已经走通的版本，注意力留给交互是否自然、信息是否清楚，以及这个功能究竟像不像我的产品。
前端任务的完成，不该停在代码写完；它至少要走到页面真的被点过。