2026年07月01日赛博日记

生成时间：2026-07-01 23:55:01

📝 今日概要

技术突破日——一口气修复了 AI 自动化测试框架的 3 个核心 Bug，重构了用例入库体系（弃 CSV、统一环境规则、引入 AST 解析），并新建执行记录表实现完整的历史追踪。从底层数据结构到上层展示逻辑，完成了一次全链路治理。

1. AI 裁判系统三大 Bug 围剿 claude_2026-07-01

用例跳过误判：detectExecutionCaseSkip 在整段 stdout 扫关键词不区分运行是否已通过，导致 success=true 的用例被标 ⏭️。修复方案：新增 stdoutIndicatesRunSucceeded() 前置检查，跳过判定仅在 !executionSuccess 时触发，并解除 webBuAggregateRunSucceeded 与 isExecutionCaseSkipped 的循环依赖（3dc45ec）
APP 裁判卡片丢失：hasLiveRunOutput() 在有实时日志时拦截了所有 testcase:stepJudge 事件。步级裁判往往在进程结束后才返回，卡片永远不显示。修复：移除拦截，裁判卡片始终插入消息流
卡片顺序错乱 + 悬浮：裁判异步返回时 push 到列表末尾，步骤 3 执行时步骤 1 的裁判才到。新建 stepJudgeMessageInsert.ts，将裁判卡片插入到对应步骤日志正后方，去重 + 不触发滚底（b981955）

2. 用例入库体系全面重构 claude_2026-07-01

移除 CSV 双入口：删除 测试用例列表.csv（656KB），注释 --from-csv 分支，以代码扫描为唯一数据源
AST 替代文本解析：_get_marker_block 手写解析在多行 @parametrize 处断链，至少 13 个 Android 用例 marker 漏读。改用 ast.parse 读取 decorator，彻底解决
统一环境规则：新增 common/case_env.py，入库（多环境）与回写（单环境）共用 resolve_case_environments() / resolve_runtime_environment()，消除两套独立实现的漂移风险
清理脏数据 54 条：新增 prune_stale_cases()，DB 与代码扫描完全对齐（648 = 648）

3. 执行记录表 + 重试语义统一 claude_2026-07-01

新建 test_execution_record 表（id、test_case_id、ai_case_id、case_type、run_at、exec_result、created_at）
重试规则：首次失败写一条 FAIL（不重复），重试成功覆盖为 PASS，执行记录与主表 exec_result 在同一 stage_outcome() 中同步更新
确认三端生效：PC/Android 直接 import，iOS 经 loader.py 动态加载（补修父包注册）

4. 自动化日报表格化 claude_2026-07-01

5. PC 端 chromedriver 缓存修复 claude_2026-07-01

新版 webdriver-manager 解压到 chromedriver-win64/，旧查找逻辑只扫 chromedriver.exe 和 chromedriver-win32/
补全缓存路径 + 项目内 fallback + 网络异常容错（2d4fc37）

洞察：双数据源是系统性 bug 的温床。CSV 导入与代码扫描各自维护一套环境判定逻辑，差异静默积累，最终以「RC 服大量 NULL」的症状爆发。根治方式不是修 CSV，而是砍掉一个入口——单一数据源原则在测试基础设施中同样适用
洞察：入库（源码解析）与回写（运行时 marker）使用两套独立实现，是一个违反 DRY 的经典反模式。今天的 case_env.py 统一是正确方向，但三端 marker 命名仍不统一（Android test_RC vs iOS not_test vs PC 无标签默认），长期应收敛
教训：hasLiveRunOutput() 拦截裁判事件是一个典型的守卫条件放错位置的问题——为避免 UI 重复展示而加的 guard，副作用比解决的问题更大。加 guard 前必须考虑异步时序：裁判回调与实时日志的生命周期是否重叠
教训：手写文本解析 decorator 注定脆弱。Python AST 标准库一行 ast.parse() 就能拿到完整的 decorator 列表，不应该用正则/字符串扫描去对抗语言语法