给编码 Agent 装上浏览器：让它自己验证前端改动

编码 Agent 常把"测试全绿"当成前端做完了，但没人真正打开过页面。作者用 Playwright MCP 给 Agent 一个真实浏览器，并写了一套指令：从 diff 推导测试计划、验证最终状态而非点击动作、让独立的 reviewer agent 复查、只清理自己启动的进程。

Agent 缺失的那一环：打开前端

• 编码 Agent 对代码有不错的反馈闭环：读、改、跑 formatter 和测试、看失败、再试。但前端工作缺的输入就是前端本身。
• 作者想要的闭环是：改代码、跑测试、启动应用、使用改动的功能、看结果、修问题、再用一次。最后一步最关键——Agent 很爱说"现在应该好了"，不如让它再打开页面确认。
• 测试通过只说明你写下的场景没坏，不等于这次改动没引入问题。重叠的控件、store 里有但屏幕上没高亮的选中态、刷新后才暴露的保存问题、层级画反的地图层，都是人三秒能看出、测试看不出的。
• Playwright MCP 的配置很小：Node 20 以上，在 MCP 客户端里加一个 npx @playwright/mcp@latest 的 server 条目。可以用 TodoMVC 演示页加一条 todo 做冒烟检查。

只有浏览器还不够，缺的是指令

• 给 Agent 浏览器只是给了它"看"的能力，没告诉它看什么、看到什么程度、什么算证据。结果它会交回"打开了 /route，页面加载成功，浏览器验证完成"这种报告。
• 第一条规则：验证必须从改动出发。改了筛选就用筛选，改了重置就先改状态再重置，动了持久化就刷新页面，改了弹窗就开关弹窗，改了响应式就调整视口。
• 实操上，Agent 先读 diff 写一份简短测试计划，再动浏览器。例如筛选栏改动：打开 /projects 记下行数、按 Status: Active 筛选、叠加 Owner 条件、清空筛选看行数是否恢复、带筛选刷新看 URL 里状态是否保留。
• 通过 MCP 的 browser_navigate、browser_snapshot、browser_click 执行，元素用无障碍快照里的 ref 定位，不靠猜 CSS 选择器。

验证最终状态，而不是点击动作

• "点了重置没报错"说明不了什么，真正要验证的是重置把状态还原了。保存同理：改设置、保存、刷新、值还在，才算数。
• 写成 Playwright 测试时，关键断言在 reload 之后：重新加载页面再检查开关是否仍为选中。Agent 不一定要写测试文件，通过 MCP 手动做同样的事即可——点击、保存、重新导航到同一 URL、从新快照读状态。
• 不同问题要不同证据：URL 是否变化、按钮是否禁用、列表行数、空状态文案，各自对应不同的检查方式。
• 一个真实案例：某 PR 修交互地图上光标卡在 hover 态的问题，新加的单元测试在旧代码上也能过，证明不了修复。真正证明它的是 Agent 打开应用、在交互图层上来回移动、观察光标何时变化与复位。

指令放哪：AGENTS.md 与可复用 skill

• 作者把反复在 prompt 里重复的几行规则沉淀成 browser-review skill，项目级约定放 AGENTS.md，可复用的审查流程放 skill，避免每次会话重写。
• 分工上，AGENTS.md 负责"这个项目怎么启动、哪些路径算用户可见"，skill 负责"怎么审、审到什么程度、交什么证据"。
• 当规则越写越长、开始需要判断"这次改动该测哪几条路径"时，单靠 skill 已经不够，这也是后来做成工具的原因。

让 reviewer 独立，并只清理自己启动的东西

• 作者-agent 对自己刚写的代码有确认偏误，容易只走一遍顺利路径。让另一个 reviewer agent 拿着 diff 和测试计划独立复查，能抓到作者漏掉的问题。
• 清理规则要收紧：Agent 只关闭自己启动的 dev server 和浏览器进程，不碰用户原本就在跑的服务，动手前先看 git status 和端口占用。
• 这套习惯后来长成了开源工具 katalepsis，核心是判断一次检查是否真的通过——不是看 Agent 的自我陈述，而是看它是否按计划执行并带回可核对的证据。