2026年5月22日（周五）赛博日记

生成时间：2026-05-22 23:58

📝 今日概要

深度修复了 AI 自动化测试系统的三处硬核问题：Web 侧模型输出可读性、APP 侧 AI 裁判上下文缺失、执行架构阻塞问题；完成了 dev/test 和 dev/main 分支合并；积累了 browser_use 和 Prisma 的技术实战经验。

🔍 核心技术进展

1. Web 侧执行过程模型输出增强

来源： Claude Code 会话 10:22

  • 修改 runner.py 中的 _extract_step_detail 方法，新增 thinking（思考过程）和 memory（记忆）字段输出
  • 提升截断长度：evaluation 和 next_goal 从 120 字符提升到 200 字符
  • 在 _on_step_start 钩子中 monkey-patch get_model_output，实现「半流式」输出（不等动作执行完就输出思考内容）
  • 步骤摘要从单行 | 分隔改为多行格式，每项独占一行
  • 核心技术选型： 利用 browser_use 的 register_new_step_callback 回调机制拦截 LLM 输出

2. APP 侧 AI 裁判上下文增强

来源： Cursor 会话 12:04

  • 裁判的 stepDescription 改为使用实际下发的指令（executionTasksFinal[idx].description）
  • 通过 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 同时附上用例库步骤原文（二者不一致时分段展示）
  • 新增 prependAppEntryPreludeToTasks 方法：将入口预处理拆成独立步骤，不参与步级裁判
  • 实现了下标映射机制：xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx / xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
  • 关键决策： 同时提供「实际下发指令」和「用例库步骤原文」给 LLM，增强上下文信息

3. 执行架构阻塞问题修复

来源： Cursor 会话 多个

  • runTasks 改为「立即返回 + 后台执行」模式，避免无限阻塞
  • 设置明确超时机制：准备阶段 5 秒，步级裁判 90 秒，整体 15 分钟
  • 推送准备进度事件（testcase:prepProgress）
  • 执行锁 + 强制释放机制（超 2 分钟强制释放）
  • 先 stopRunTasks() 再 subscribe 事件，清理僵尸会话
  • 入口映射 5 秒超时，失败使用本地配置

4. 分支合并与 Prisma 迁移

来源： Cursor 会话 12:04

  • 在 dev/test 分支上快进合并 dev/main 的全部改动
  • 应用 Prisma 迁移：npx prisma migrate deploy
  • 修复了 BuildJobStatus、BuildProfile 等类型缺失问题
  • 关键经验： 拉含新 prisma/migrations 的分支后，必须执行 npm run prisma:generate 和 npx prisma migrate deploy

💡 深度洞察与经验教训

洞察

  1. 半流式输出的实用性： browser_use 使用 llm.ainvoke() 非流式调用，无法逐 token 推送，但通过 monkey-patch 在 LLM 返回后立即输出思考内容，可以接近流式体验，满足调试需求。
  2. 步骤拆分的价值： 入口预处理作为独立步骤不仅解决了步骤过长导致 AI 执行时步骤丢失的问题，还让执行流程更清晰，便于调试和追踪。
  3. 执行架构设计的权衡： 立即返回 + 后台执行模式解决了阻塞问题，但需要额外的事件机制来通知执行完成，增加了复杂度但提升了用户体验。

教训

  1. browser_use 库的限制： 必须深入了解第三方库的回调机制和 LLM 调用链，才能找到合适的拦截点。register_new_step_callback 是最适合拦截 LLM 输出的回调。
  2. Prisma 迁移的必要性： 只 npm install 不够，必须重新生成客户端并应用迁移。postinstall 可能未执行，需要手动处理。
  3. IPC 阻塞风险： 主进程中的 await agent.runTasks() 会无限阻塞，必须设置超时和返回机制，否则前端会一直显示「正在执行」且无报错。
  4. 步级裁判的上下文重要性： AI 裁判需要实际执行指令的上下文，仅用预期结果和日志对比会丢失关键信息，导致误判。

🚀 未来行动设想

  • 考虑在 browser_use 中实现真正的流式输出，需要修改库内部实现
  • 入口预处理作为一个独立步骤的思路可以推广到其他需要预处理的场景
  • 执行准备阶段应该有明确的进度反馈，避免用户感觉"卡在初始化"
  • Web 侧和 App 侧的执行输出应该统一格式，都支持流式输出
  • AI 裁判的上下文提供方式值得进一步优化，可能需要更多实际执行信息
  • 将 browser_use 的回调机制封装成更易用的 API

📊 自动化统计

  • 捕获 Memory 数：2 个（2026-05-22.md、claude_2026-05-22.md）
  • 笔记更新数：0 个（note-gen-sync 目录下最近24小时无修改）