vibe‑coding 九阳神功之测：让 AI 自己测、自己修、跑通了再汇报（Chrome MCP 全流程自动化）
vibe‑coding 九阳神功之测：让 AI 自己测、自己修、跑通了再汇报（Chrome MCP 全流程自动化）
系列顺序：夯（Git） → 抄 → 学 → 喂 → 规 → 验 → 测 → 扩 → 收
你不是质检员，你是甲方。让 AI 自己测完、自己修完，跑通了再来找你。
先说核心理念
以前测试是这样的：你写代码 → 你写测试 → 你跑测试 → 你修 bug → 你再跑测试。全程都是你。
现在应该是这样的：AI 写代码 → AI 写测试 → AI 自己跑 → 发现问题自己修 → 全部通过了再向你汇报。
你不需要盯着它。你甚至不需要在电脑前。
一次让 Claude Code、Codex 自己跑 20 个小时都没问题——只要你给它明确的验收标准和自动化测试手段，它会像一个不知疲倦的 QA，一遍一遍跑，一遍一遍修，直到全绿。
“测”的精髓：不是”我觉得能跑”，而是”AI 证明给我看能跑”。
Chrome MCP：让 AI 像真人一样操作浏览器
传统的单元测试只能测函数和接口。但你的用户不是用 curl 访问你的系统的——他们用浏览器。
Chrome MCP（Chrome DevTools Protocol / Model Context Protocol）让 AI 可以：
- 打开浏览器，访问页面
- 点击按钮、填写表单、提交
- 读取页面内容，判断结果对不对
- 截图留证
- 检查 Console 有没有报错
- 检查 Network 请求有没有失败
这意味着 AI 可以像一个真人 QA 一样，从头到尾走一遍你的系统。
在 OpenClaw 里，等价工具是 browser——同样的能力，不需要单独装 Chrome MCP。
全流程自动化测试：三层结构
我在做项目的时候，把测试分成三层：
第一层：冒烟测试（Smoke Test）
目标：系统能不能正常启动、首页能不能打开
请用 Chrome MCP / browser 执行冒烟测试：
1) 打开 http://localhost:3000，截图
2) 确认页面标题正确
3) 确认 Console 没有红色报错
4) 确认 Network 没有 5xx 错误
5) 截图保存到 tests/screenshots/smoke-{timestamp}.png
如果有问题，自己修复后重新测试。
全部通过后向我汇报。
第二层：核心流程测试（Happy Path）
目标：主业务流程能不能走通
请用 Chrome MCP / browser 测试以下核心流程：
## 流程 1：注册 → 登录
1) 打开 /register
2) 填写邮箱 test@example.com、密码 Test123456
3) 点击注册按钮
4) 验证跳转到登录页
5) 填写登录信息，点击登录
6) 验证跳转到 Dashboard
7) 每步截图
## 流程 2：创建计划
1) 在 Dashboard 点击"新建计划"
2) 填写计划名称、选择策略类型
3) 提交
4) 验证列表中出现新计划
5) 点击进入详情，验证数据正确
## 流程 3：查看报表
1) 导航到报表页面
2) 验证图表渲染（不是空白）
3) 验证数据区间选择器可用
每个流程如果失败：
- 截图 + Console 日志
- 分析原因
- 修复代码
- 重新测试该流程
- 全部通过后汇报
第三层：异常场景测试（Edge Cases）
目标：出错的时候不白屏、不崩溃
请测试以下异常场景：
1) 未登录访问 /dashboard → 应跳转到登录页
2) 登录时密码错误 → 应显示错误提示，不白屏
3) API 超时（断开后端）→ 应显示 loading/error 状态
4) 表单提交空数据 → 应显示校验提示
5) 连续快速点击提交按钮 → 不应重复提交
6) 浏览器后退/前进 → 页面状态正确
有问题就修，修完重测。全部通过再汇报。
关键指令：”有问题就修，全部通过再汇报”
这句话是整个”测”的核心。
传统做法：AI 跑测试 → 发现 bug → 告诉你 → 你看 → 你让它修 → 它修 → 你再让它测 → ……
vibe-coding 做法：AI 跑测试 → 发现 bug → 自己分析 → 自己修 → 自己重测 → 全绿了才找你。
你只需要在指令里加一句：
如果测试失败：
1) 截图保存证据
2) 分析失败原因
3) 修复代码
4) 重新运行失败的测试
5) 如果修复后产生新问题，继续修复
6) 循环直到全部通过
7) 最后向我汇报：修了哪些问题、改了哪些文件、全部测试结果
AI 可以这样跑 20 个小时——它不累、不烦、不会偷懒。你只需要第二天早上看一眼汇报。
实战案例：飞鸿平台全流程测试
我在做 fh_java 的时候，前端 18 个页面，后端 14 个 controller。手动测一遍至少半天。
我的做法：
@tasks.md
请对 fh_java 执行全流程测试，使用 browser 工具：
1) 启动前端 (localhost:3000) 和后端 (localhost:8080)
2) 按以下顺序测试所有页面：
### 认证流程
- 注册新用户
- 登录
- Token 持久化验证（刷新页面不掉登录）
### Dashboard
- 数据加载和图表渲染
- 空数据状态
### 计划管理
- 创建计划（定投/网格/反向网格各一个）
- 编辑计划
- 启停计划
- 删除计划
### API Key 管理
- 添加 API Key
- 测试连接
- 删除 API Key
### 报表
- 查看收益报表
- 切换时间范围
- 导出功能
### 设置
- 修改密码
- 通知设置
每个页面：
- 截图保存到 tests/screenshots/
- Console 不能有红色报错
- Network 不能有 5xx
- 页面不能白屏
发现问题就修，修完重测。
全部通过后给我一份报告：通过/失败/修复的明细。
然后我就去睡觉了。
第二天早上看到的汇报：
✅ 全流程测试完成
通过：16/18 页面
修复：2 个问题
1. Dashboard 空数据时图表组件报错 → 加了空判断
2. 计划编辑页面返回后列表未刷新 → 加了 onAppear refresh
改动文件：
- src/pages/dashboard/Chart.tsx (+3 行)
- src/pages/plans/PlanList.tsx (+1 行)
截图：tests/screenshots/ (36 张)
两个 bug，它自己发现、自己修、自己验证。我只用了 30 秒看报告。
测试脚本模板化
跑过一次之后，把测试流程固化成文件，以后每次改代码都能重跑：
tests/
e2e/
smoke.md # 冒烟测试指令
auth-flow.md # 认证流程
plan-crud.md # 计划 CRUD
report.md # 报表功能
screenshots/ # 自动截图留档
results/ # 测试报告
2026-02-21.md
每个 .md 文件就是一份”测试剧本”——AI 读了就知道怎么测。
下次你改了代码，只需要说：
请按 tests/e2e/ 下的所有测试剧本执行全量测试。
有问题就修，全部通过再汇报。
和 CI/CD 的关系
你可能会问：这不就是 E2E 测试吗？为什么不用 Playwright / Cypress？
区别在于：
- Playwright/Cypress 需要你先写测试代码
- Chrome MCP/browser 的方式是用自然语言描述测试，AI 直接执行
- 而且 AI 发现问题能直接修代码，不只是报红
当然，两者不冲突。你可以：
- 先用 Chrome MCP 让 AI 跑一遍全流程（快速验证）
- 稳定之后让 AI 把测试流程转化成 Playwright 脚本（自动化回归）
请把 tests/e2e/auth-flow.md 的测试流程转化成 Playwright 测试脚本。
保存到 tests/e2e/auth-flow.spec.ts
这样你既有”AI 随跑随修”的灵活性，又有”CI 自动回归”的稳定性。
测试的黄金法则
- 你不是 QA，你是甲方 — 让 AI 测，你看报告
- 有问题就修，全部通过再汇报 — 这一句话值千金
- 每次测试都截图 — 截图是证据，不是装饰
- 测试流程模板化 — 跑过一次就存成文件，以后一句话重跑
- AI 可以跑 20 小时 — 它不累，你累了就去睡觉
和”规”的配合
“规”给了 AI 任务清单（tasks.md），每完成一个 Phase 就可以触发测试：
Phase 2 完成。
请按 tests/e2e/ 执行与 Phase 2 相关的测试。
有问题就修，通过后更新 tasks.md 打勾并 commit。
这样”规”和”测”形成闭环：做一步，测一步，过了才推进下一步。
总结
“测”的精髓不是”怎么写测试”，而是让 AI 承担测试的全部成本。
- 你描述测试场景（自然语言）
- AI 执行测试（Chrome MCP / browser）
- AI 发现问题自己修
- AI 全部通过后向你汇报
- 你 30 秒看完报告，继续做甲方
不是”我觉得能跑”，而是”AI 证明给我看能跑”。
下一式我们讲 扩：你不懂的领域，AI 帮你学——但学到的东西必须可验证，不能 AI 说什么你就信什么。