软件上线前通常有这样一个流程：单元测试通过 → 集成测试通过 → QA 手工测试 → 上线。但有一类问题在这个流程里总是漏掉：技术上正确，但用户使用时会遇到问题。
比如：表单提交成功，但成功提示出现在用户看不到的滚动位置；API 返回了正确数据，但前端渲染时在移动端截断了；功能本身没问题，但操作路径需要 7 步，用户在第 4 步就放弃了。
这类问题不会让测试失败，但会让用户流失。
/exp 的定位是：在代码测试之外，增加一层体验验证——用 AI Agent 模拟真实用户的操作，在上线前发现用户会遇到的问题。
Agent 怎么「使用」你的产品
/exp 基于 Playwright，让 AI Agent 以自动化浏览器的方式操作你的产品界面。但它不是简单的录制-回放脚本，它是：
- 目标导向：给 Agent 一个用户目标（「完成一次购买」），而不是操作步骤列表。Agent 自己规划路径，就像真实用户会做的那样。
- 观察异常：Agent 会注意那些「不符合期望但不报错」的情况——按钮变灰、页面卡住、跳转到意外页面、内容截断。
- 记录行为轨迹：每一步操作都有截图、DOM 状态快照、网络请求记录。问题复现有完整证据。
四类产品的验证场景
Web 应用
验证核心用户旅程（用户注册 → 完成第一个核心任务 → 退出）是否流畅。重点关注：
- 表单交互（提交、验证、错误提示的时机和位置）
- 状态反馈（加载状态、成功/失败提示的可见性）
- 响应式布局（移动端和桌面端的关键操作路径）
- 导航流（前进、后退、刷新后的状态保持）
API 服务
对于 API，/exp 模拟的是「API 消费者」的行为：
- 按文档示例调用，验证返回值格式和内容
- 边界输入（空值、超长字符串、并发请求）
- 错误响应的格式是否符合 API 规范
- Rate limiting 的行为（到达限制后的提示是否清晰）
AI Agent 产品
AI Agent 产品的体验验证最复杂，因为输出是非确定性的：
- 对常见意图的处理是否符合预期（不需要完全准确，但方向要对）
- 对边界输入（歧义指令、超长输入、语言混用）的处理是否优雅
- 错误状态下的用户提示是否有用（不能只说「发生了错误」）
- 多轮对话中的上下文保持是否正确
命令行工具
CLI 工具的体验验证关注：
- 帮助文本是否准确（
--help描述和实际行为一致） - 错误信息是否可操作（告诉用户怎么修，而不只是报错码）
- 标准输出/错误输出的分离是否正确
三轮自动修复循环
当 Agent 发现问题时，/exp 不只是报告，它尝试修复：
- 第一轮：定位问题代码（查图谱找到相关组件/函数），生成修复，重跑验证
- 第二轮：如果修复后问题仍然存在，分析是否是更深层的原因（数据问题、状态管理问题），调整修复策略
- 第三轮：第二轮修复后再次验证，如果还有问题，生成详细的问题报告，标记为「需要人工处理」
三轮循环的设计逻辑：多数表面问题一轮就能修完；需要两轮的是有复杂度的问题；三轮后还存在的，通常需要更大的架构决策，超出了自动修复的边界。
真实 Bug 样本
在 WorkClaw 的一次上线前验证中（/exp 运行了 12 个场景），发现了以下问题：
| 问题描述 | 类型 | 自动修复？ |
|---|---|---|
| 会话列表在 Safari 下滚动时闪烁 | CSS 渲染 | 是（第一轮） |
| 文件上传 > 5MB 时进度条不更新 | 状态反馈 | 是（第二轮） |
| 快速切换会话时旧会话内容残留 | 状态管理 | 否（人工处理） |
| 移动端键盘弹出时输入框被遮挡 | 布局适配 | 是（第一轮） |
| 网络断开后重连提示在中文环境下显示英文 | 国际化 | 是（第一轮） |
这 5 个问题，在正常的单元测试和 API 测试中不会出现。它们只有在「模拟真实用户使用」时才会浮出水面。
什么时候跑 /exp
- 每个版本发布前：作为发布检查清单的最后一关
- 核心功能改动后：任何影响用户主流程的改动，都应该触发完整体验验证
- 引入新依赖后：第三方库升级有时会在 UI 层引入静默的兼容性问题
代码测试验证「代码是否按预期运行」，体验验证确认「用户是否能按预期使用」。两者缺一，都不算真正的上线前验收。