Claude Code最容易被低估的一点，是它不应该只停在"写代码"。如果它写完一个前端改动，只能把diff扔给你看，那它还是半个工程助手。

为什么Claude Code需要浏览器能力

很多前端bug，只看代码不够。比如：

• 按钮是不是被遮住了
• 表单校验文案有没有出现
• 登录后路由有没有跳对
• 弹窗是不是在移动端溢出
• 某个aria role是否能被识别

这些问题，单靠读文件很容易漏。

Playwright MCP补的就是这一层。它不是替代Playwright测试，而是让Claude Code在开发过程中多一个"现场验收工具"。

怎么接入

Playwright MCP是Microsoft做的Playwright Model Context Protocol server，把浏览器自动化能力通过MCP暴露给AI工具。

在Claude Code里，把Playwright MCP配成一个MCP server：

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": ["@playwright/mcp@latest"]
    }
  }
}

或者直接用命令启动：

npx @playwright/mcp@latest

关键确认三件事：

1. MCP server能启动
2. Claude Code能看到playwright工具
3. 打开测试页面后能拿到快照并执行点击/输入

一个可复制的验收流程

假设你正在改一个登录页，不要只让Claude Code写代码。可以这样要求：

请完成登录页错误提示优化。完成后使用Playwright MCP打开本地页面，测试三件事：

1. 空密码提交时出现错误提示
2. 错误提示文案符合设计稿
3. 修复没有影响正常登录按钮状态 最后给出修改文件、浏览器验收步骤和剩余风险。

Claude Code接上Playwright MCP后，可以在同一个任务里完成：

读代码 → 修改 → 启动本地服务 → 打开页面 → 操作页面 → 根据结果再修 → 输出报告

这才是coding agent该有的闭环。

它适合做什么

场景	说明
表单验证	空提交、格式校验、错误提示
登录/注册流程	完整流程验收
管理后台按钮操作	点击后状态变化
页面跳转检查	路由是否正确
弹窗、抽屉、Toast验证	UI组件行为
可访问性结构检查	aria role
生成Playwright测试前的探索	用真实页面确定selector

它更像是让Claude Code先用浏览器理解页面，再决定怎么写测试或怎么改代码。

什么时候不要用

场景	说明
纯后端逻辑修改	不需要页面验收
没有页面交互的工具库	同上
本地服务启动成本很高	效率不划算
依赖真实账号、支付、短信验证码	安全风险
还没有隔离测试环境	避免污染

涉及真实账号和真实支付时，不要让Agent随便点。可以给它测试账号、mock环境、只读后台，或者明确禁止提交类动作。

浏览器能力越强，边界越要写清楚。

建议加到CLAUDE.md里

如果你的项目长期使用Claude Code + Playwright MCP，建议在CLAUDE.md里写一段：

## Browser QA with Playwright MCP
- 本地页面启动命令：pnpm dev
- 默认测试地址：http://localhost:3000
- 可以使用Playwright MCP做页面验收
- 禁止在生产环境执行写入操作
- 涉及支付、删除、发消息、真实用户数据时必须先询问
- 前端改动完成后，至少验证相关页面能打开，关键按钮能点击，错误提示能出现

这段配置的目的，是让Claude Code知道什么时候该用浏览器，什么时候必须停下。

总结

Playwright MCP真正的价值，是把Claude Code的交付从代码层推进到页面行为层。

以前你可能只能问：代码改了吗？

现在可以问：页面验了吗？按钮点了吗？错误提示出现了吗？

最值得做的不是让它多写几段测试，而是让它形成一个习惯——写完代码，自己去浏览器里看一眼。