# 我希望 TraeCode 未来可以让测试验证策略可配置，用手动测试加日志回读替代烧 token 的截图分析
## 介绍自己
我是一家公司的开发，日常做业务项目的开发和维护，项目里有不少前后端联调和 UI 相关的改动。用 TraeCode 跑过不少完整的开发任务，对它的自主验证环节感受很深，有好也有痛。
## 我对 TraeCode 的愿景
### 希望新增什么功能：可配置的验证策略 + 日志回读验证
希望 TraeCode 把「怎么验证」变成一个任务级可配置的策略，而不是默认行为。具体是两件事：
**1. 验证手段分级，按信息含量选用，而不是默认上最贵的。**
- L0 静态检查：lint、类型检查——零 AI token，结果完全确定；
- L1 测试框架断言：单元 / 集成测试，只读退出码和输出——近零 token；
- L2 运行时日志验证：读服务日志、控制台报错、网络请求失败记录——低 token，结构化信号；
- L3 视觉截图分析：最贵，只在真正涉及 UI 变更时启用。
这样的截图分析，不仅截取不到翻页的瞬间，还会陷入节点消耗token，我更希望自己测试后告诉它问题进行改进。
**2. 「协作验证」模式：我手动操作，TraeCode 通过 CDP（Chrome DevTools Protocol）旁听回读。**
我手动点页面的过程中，TraeCode 通过 DevTools 协议实时收集 console 报错、未捕获异常、network 失败——我操作完，它拿到的是一份结构化的「操作期间发生了什么」，直接据此判断验证是否通过。这比「Agent 自己开浏览器截图 → 看图猜结果」便宜两三个数量级，而且准确得多。
### 为什么需要这个功能
现在的自动验证，token 消耗和收益严重不成比例。一轮浏览器验证通常是：起服务 → 打开页面 → 截图 → 分析 → 点一下 → 再截图 → 再分析，来回五六轮。一张截图折成视觉 token 就是几百上千，一轮下来轻松烧掉上万 token。
更亏的是**最贵的手段换来的是最不确定的结论**：模型看截图判断「页面是否正常」本质是看像素猜结果，报错不一定截到了，没报错也不代表对。误判之后 Agent 反复重试，token 翻倍烧，最后可能还给我一个错误结论。
而日志正好相反：它是结构化文本，报错栈、退出码都是确定信号，token 开销只有截图的零头，准确率高一个量级。同样的验证目的，读日志是降维打击。
### 希望优化的场景：前端改动后的验证环节
具体卡点：我让 TraeCode 改一个列表页的筛选逻辑。它改完代码，自动起浏览器、截图、分析——这时候它其实只需要确认两件事：接口返回对不对（日志里有）、控制台有没有报错（CDP 里有）。但现在的流程是截图好几轮去「看」页面，烧了一大笔 token，最后对筛选逻辑对不对的判断还不如我肉眼扫一眼可靠。
另一个场景是反向的：有些验证我更愿意自己做（涉及真实账号、验证码、内网环境的页面），现在我只能干看着 Agent 截图，或者手动打断它。我希望此时能直接选「我来操作，你看信号」。
### 希望如何融入我的工作流
- **与 CI/CD 对齐**：项目里已经有测试脚本和 lint 配置，验证环节应该优先复用它们（跑现成的 pytest / vitest / eslint），而不是 Agent 另起炉灶自己发明验证方式；
- **与 DevTools 打通**：协作验证模式下自动附加到我正在用的浏览器实例；
- **增量验证**：只测本次改动的影响面。现在复杂项目每次改一点都接近全量重验，这也是 token 消耗的大头；
- **验证预算**：任务级设一个 token 上限，快超限时自动降级到更便宜的验证手段，或者弹出来问我还要不要继续。
价值一句话：验证从「默认全上最贵的」变成「按需选用最准的」，单任务验证成本预计能降一个数量级，结论还更可靠。
## 你希望它以什么形态出现
- 任务执行前给一张**验证选择卡片**：自动验证 / 协作验证（我操作、它读信号）/ 跳过，复用 TraeCode 现有的工具卡片交互就行，选择记住偏好；
- 设置中心加一个**验证策略默认配置**，也可以在项目 Rules 里声明；
- CDP 旁听做成**自动触发能力**：我选了协作验证后，TraeCode 自动挂到我的浏览器上，不需要我额外配置；
- 截图分析保留，但作为 **L3 最后手段**，仅在日志验证通过后、且改动涉及 UI 外观时建议启用。