✦ AI Use Case Showcase

CAN_Com 测试报告
智能复核

用 Claude Code 构建自定义 Skill，让 AI 自主解析 vtestreport、筛除 4.2 万条误判、精准定位真实通信故障

不写一行应用代码，仅通过一个 Markdown 文件 + 自然语言对话，将资深测试工程师的复核经验"教会"给 AI，实现从报告解析到故障定位的全流程自动化。

42,003
Warning 全量归类
99.8%
误判筛除率
7
复核步骤全自动
向下滚动
✦ OVERVIEW

全流程一览

从搭建到交付，7 个步骤构成完整的 AI 复核闭环。下面先看全貌，再逐个展开。

01
搭建
创建 Skill 架构
02
调用
一键启动复核
03
解析
DataApi 深度读取
04
训练
灌入专家经验
05
输出
生成 HTML 报告
06
仲裁
索取 BLF 日志
07
进化
总结经验迭代
✦ WHY

测试复核之痛

CAN_Com 测试完成后会生成一份 vtestreport 报告，包含所有测试用例的 Pass/Fail/Warning 判定。传统方式下，测试工程师需要逐条人工复核这份报告——但现实是残酷的。

⚠

海量 Warning 淹没真实故障

CAN 总线仲裁机制导致周期性报文频繁出现微小的时序波动。单次测试产生 42,003 条 Warning，其中 99% 以上是仲裁导致的周期超限误判。真实故障混在海量噪音中，人工逐条复核几乎不可能完成——既耗时又容易遗漏。

一次完整的 CAN_Com 测试约 2 小时，产生约 67 条 Fail 和 42,003 条 Warning。人工逐条复核预计需要 3-5 个工作日。
⚙

工具导出丢失关键信息

Vector 官方的 ReportViewerCli 导出 XML 时存在严重的信息丢失：每个 testcase 只保留第一条 Fail（官方文档明确写了 "first fail in the test case"），实际验证 68 条 step Fail 只导出 4 条汇总。更致命的是，42,003 条 Warning 完全丢失，仲裁分析所需的 LastID 信息全部缺失。用 XML 做复核分析，基础数据就是残缺的。

★

误判规则高度依赖个人经验

判断一条 Fail 到底是真实故障还是测试误判，需要依赖一系列经验规则：0xBC 报文延时是 Tx 优先级导致的、负偏差是上一帧仲裁的补偿波动、LastID 小于故障 ID 说明是仲裁导致的……这些规则完全依赖资深工程师的经验积累，新人需要数月才能掌握，且执行时仍有出错风险。

⚡

系统性故障最易遗漏

有些故障不体现在 Fail 或 Warning 中，而是藏在 testcase 末尾的 errorhook_cnt 值里。只要这个值不为零，就说明底层调度存在系统性异常，所有周期类测试结果的可信度都存疑。但人工复核时，这个数据往往被忽略。

✦ HOW

七步搭建 AI 复核系统

整个过程不写一行应用代码，仅通过一个 Markdown 文件定义规则、通过自然语言对话训练 AI。以下是每一步的详细做法和设计考量。

01

搭建 Skill 架构 关键

使用 Claude Code 的 /commands 自定义命令架构，在 commands 目录下创建 CanComReview.md 文件，这就是整个 AI 复核系统的"大脑"。

为什么不直接用对话？因为 Skill 架构让复核逻辑持久化、可复用、可版本管理。每次输入 /CanComReview，AI 都会加载同一套规则，确保每次复核标准一致。整个文件只有 312 行 Markdown，却定义了一套完整的测试报告分析方法论。

文件结构包含：前置输入校验规则 → 5 条核心复核判定规则（优先级排序）→ 7 步标准执行流程 → HTML 报告输出模板 → 边界异常处理 → BLF 索取规范
02

调用 Skill 启动复核

操作极其简单：下载好 vtestreport 文件后，打开 Claude Code 终端，输入 /CanComReview。AI 立即加载 Skill 定义，自动在 C:\Users\ZYJ\Downloads\ 目录下查找最新的 *.vtestreport 文件（按修改时间倒序取最新一份）。

如果文件缺失或不可读，AI 会明确列出缺失项并等待补充——不会猜测或跳过。这保证了每次复核的输入完整性。

03

深度解析 vtestreport DataApi + pythonnet

这是整个方案的技术核心。绕过 Vector ReportViewerCli 导出 XML 的信息丢失问题，直接调用 Vector.ReportViewer.DataApi 这个 .NET DLL，通过 pythonnet 桥接 Python 和 .NET 运行时，实现对 vtestreport 的全量无损解析。

具体实现：AI 自动检查 DLL 是否存在（位于 NuGet 包解压路径），检查 pythonnet 是否安装，然后用递归遍历算法提取所有 TestReport → TestGroup → TestCase → Step 层级的 Fail、Warning 和 errorhook 数据。每条数据都保留了完整的路径上下文和 verdict 信息。

python — DataApi 全量提取核心逻辑
import sys, clr sys.path.append(r'C:\temp\dataapi\lib\net48') clr.AddReference('Vector.ReportViewer.DataApi') from Vector.ReportViewer.DataApi import RvAPI api = RvAPI.Instance report = api.OpenTestReport('path/to/report.vtestreport') # 递归遍历所有元素：TestReport → TestGroup → TestCase → Step def collect(element, path='', depth=0, current_tc=''): verdict = str(element.Verdict) if verdict == 'Fail': fails.append(...) if verdict == 'Warning': warnings.append(...) # errorhook 检查：无论 verdict，值≠0 即为致命故障 if 'errorhook' in title.lower(): error_hooks.append(...) for child in element.Children: collect(child, path, depth+1, current_tc)
为什么不能用 XML 导出？
① Vector 官方文档确认："failure — first fail in the test case"，每个 testcase 只导出第一条 Fail
② 实测验证：68 条 step Fail → XML 仅显示 4 条汇总；42,003 条 Warning 完全丢失
③ 仲裁分析需要 Warning 中的 LastID 信息，XML 中完全缺失
04

训练 Skill 为复核专家 核心

将资深测试工程师的复核经验总结为一套结构化的规则库，直接复制粘贴给 Claude Code，让它自行将这些规则更新到 CanComReview.md 中。AI 不仅理解规则文本，还能在实际复核中正确应用优先级排序和交叉判定。

规则按优先级从高到低排列：强制检出（errorhook ≠ 0、非周期类 Fail）→ 可忽略误判（仲裁规则、0xBC 规则、负偏差规则、Δt 规则）→ 需仲裁项（LastID 不足判定的周期超限）。同时定义了 HTML 报告的 UI 标准——深色渐变头部、数据卡片、胶囊标签、斑马纹表格，确保输出专业统一。

关键设计考量：BLF 不是预先必须提供的。AI 先用 vtestreport 完成初筛，仅当 LastID 信息不足以判定仲裁时，才向用户索取对应时间段的 blf 文件。这避免了用户一开始就被要求准备大量日志文件。
05

生成可视化 HTML 报告 输出

AI 将分析结果自动输出为专业级 HTML 复核报告，保存到桌面，浏览器直接打开即可查看。报告结构严格遵循 Skill 中定义的模板：

顶部概览区（6 个数据卡片：Fail 总数、Warning 总数、筛除误判、真实故障、待仲裁、errorhook 异常）→ 真实故障区（errorhook 异常置顶红色标注 + 按严重等级排序的 Bug 卡片）→ 已筛除误判区（按规则分类汇总）→ 待仲裁区（按偏差量级标注优先级 + BLF 索取指引）→ 行动建议区（高优先级处理建议 + 次要优化建议）。

UI 设计标准：深色头部渐变（#1a1a2e → #16213e）、卡片圆角 12px + 细阴影、严重等级胶囊标签（致命=红/严重=橙/中等=黄）、斑马纹表格 + hover 高亮，参考 Notion / Linear 等现代 SaaS 风格
06

按需索取 BLF 日志完成仲裁 仲裁

报告生成后，AI 会立即在对话中向用户输出一份 BLF 索取清单，而不是被动等待用户追问。清单按偏差量级标注优先级：偏差 >5000 次的标记为「高优先级，大概率真实故障」；偏差 <20 次的提示「可能在容差范围内，建议先核对 DBC 周期定义」。

AI 会精确告知需要的时间段（从 vtestreport 中 testcase 的 starttime~endtime 推算），并说明 BLF 的命名格式（CAN_Com_YYYY-MM-DD_HH-MM-SS_L###.blf）和放置路径（Downloads 目录）。用户将文件放入后，AI 用 python-can 的 BLFReader 解析，逐帧检查故障区间内是否存在仲裁报文，完成最终判定。

仲裁逻辑：在 blf 中定位故障帧和上一帧同 ID 报文 → 获取两帧之间的时间区间 → 检查该区间内是否存在其他 ID < 故障报文 ID 的报文 → 存在 = 仲裁误判；不存在 = 真实故障
07

经验迭代与人工审批确认 闭环

每次分析完成后，必须执行两件事：

第一，让 AI 总结新经验并更新 Skill——本次复核中发现了哪些新模式？哪些规则需要调整？哪些边界场景需要补充？AI 自动将这些经验写入 CanComReview.md，版本号递增（V1.0 → V1.4.1），下次调用时自动生效。

第二，人工确认 AI 的仲裁结论——本次 AI 提出的所有待审批项，逐一确认是否认可。确认过的判断下次不再重复提出，形成"信任积累"。这确保了 AI 的判断标准与工程师的实际认知持续对齐。

为什么这一步至关重要：没有经验迭代，AI 永远停留在初始规则；没有人工审批确认，AI 的判断可能偏离实际。两者的结合让系统"越用越准、越用越省心"。
✦ DEMO

实际操作截图

以下是搭建和使用过程中的真实界面截图，点击可放大查看。

Claude Code 命令架构搭建

Step 1 — Skill 架构搭建

在 Claude Code 的 commands 目录下创建 CanComReview.md。这张截图展示了 Skill 定义文件的位置和结构——一个 Markdown 文件即完成了整个 AI 复核系统的规则定义，包含前置校验、核心判定规则、执行流程和输出模板。

Claude Code 执行 CanComReview

Step 2 — 一键启动与执行过程

输入 /CanComReview 后，AI 自动执行全流程：查找最新 vtestreport → 调用 DataApi 解析 → 递归遍历提取 Fail/Warning/errorhook → 按 4 条规则逐一筛除误判 → 聚合分析 → 输出复核结论。整个过程几分钟内完成，不需要人工干预。

复核经验库与数据分析

Step 3 — 经验驱动的复核决策

这张截图展示了项目背景与数据分析的上下文。核心思路是：先根据自己的日常报告分析经验总结出一个经验库（哪些是误判模式、哪些是真实故障特征），然后直接复制发送给 Claude Code，让它自行更新 Skill 定义。AI 理解这些经验后，在后续复核中自动应用。

✦ RULES

复核规则引擎

V1.4.1 版本包含 1 条强制检出规则 + 4 条误判判定规则 + 1 条输出标准，覆盖 99% 以上的测试场景。规则按优先级从高到低执行，同一项命中多条规则时按最高优先级判定。

/CanComReview V1.4.1 · 312 行规则定义 · 适用 vtestreport 格式 CAN 通信测试报告复核
强制检出 — 最高优先级
errorhook 系统性调度故障
遍历所有 testcase 的 errorhook_cnt_c0/c1，任一值 ≠ 0 → 致命级真实故障，置顶报告。即使该 testcase 没有 Warning 也没有 Fail，errorhook ≠ 0 仍必须报告，因为它质疑所有周期类测试结果的可信度。
规则 1
CAN 总线仲裁导致的周期超限
Warning 中的 LastID < 故障报文 ID → 说明在两次同 ID 报文之间有更高优先级（更低 ID）的报文抢占了总线，导致周期超限。判定为仲裁误判，可忽略。若 LastID 不足判定，则向用户索取对应时间段的 blf 做最终仲裁。
规则 2
0xBC 报文 ctime 延时超限
CAN ID = 0xBC 的报文 ctime 频繁超阈值 → 直接判定为 Tx 发送中断优先级高于 Rx 接收导致的测试误判。这是经过大量实测验证的固定模式，无需额外仲裁。
规则 3
实际周期小于预期（负偏差）
周期性报文实际周期 < DBC 设定的预期周期（Warning 中显示负偏差）→ 上一帧仲裁延时导致的周期补偿性波动。判定为误判，可忽略。注意：同一 CAN ID 的正负偏差必须分开处理。
规则 4
Δt 较大导致的帧长影响
单帧报文 Δt 较大引发相邻周期超限 → 核查上一帧报文的帧长度。若上一帧报文过长占用总线发送时间，直接判定为误判。
输出标准
HTML 报告模板规范
深色渐变头部 + 6 列数据卡片 + 严重等级胶囊标签（致命/严重/中等）+ 斑马纹表格 + 行动建议区 + 待仲裁区（含 BLF 索取指引），确保专业统一的视觉效果。
✦ RESULTS

一次复核的完整数据

以 2026-03-22 的一份真实 CAN_Com 测试报告为例，展示 AI 复核从 42,003 条噪音中精准提取真实故障的全过程。

67
原始 Step Fail (16 项)
42,003
Warning 总数
38,238
筛除误判
4
真实故障 (1 根因)

致命发现：errorhook 系统性异常

全部 4 个 Payload 测试用例的 errorhook_cnt_c0 均非零（值分别为 20、340、20、376）。底层调度存在系统性异常，所有周期类测试结果的可信度存疑。这是人工复核最容易遗漏的高危故障——它不体现在 Fail 或 Warning 中，只藏在 testcase 末尾的一个计数器里。

精准定位：0x2fe 报文完全缺失

0x2fe 在 CAN4 上始终未被接收，导致 4 项 Fail。AI 根据规则判定：这是非周期类报文缺失，不属于仲裁波动范畴，直接判定为真实故障。排查方向：确认 ECU 发送配置、检查 CAN4 通道连通性、核对 DBC 映射、在线抓包验证。

高效筛除：99.8% 误判过滤

0xbc（规则 2）筛除 38,228 条 Warning + 8 条 Fail——这是 Tx 优先级高于 Rx 导致的已知误判模式。负偏差（规则 3）筛除 2 条 Fail——上一帧仲裁延时的补偿波动。最终从 42,003 条 Warning 和 67 条 Fail 中，精准提取出 4 条真实故障（同属 0x2fe 缺失这一个根因）。

智能仲裁：14 个 CAN ID 待确认

对 LastID 信息不足以判定的 14 个 CAN ID（共 53 Fail + 3,771 Warning），AI 按偏差量级标注优先级：6 个高优先级（偏差 >5000，大概率真实故障）、2 个极小偏差（偏差 <20，可能在容差范围内）。AI 主动列出 BLF 索取清单，精确到时间段和文件命名格式。

复核前后对比

维度人工复核AI 复核
处理 42,003 条 Warning需 3-5 个工作日逐条判读几分钟内全量聚合归类
误判筛除准确率依赖个人经验，易遗漏规则按优先级逐条匹配 4 条规则，0 遗漏
errorhook 检测容易忽略 testcase 末尾数据遍历所有 testcase，强制检出
报告一致性不同工程师复核结果可能不同同一套规则，每次标准一致
经验传承新人需数月跟师傅学习读 Skill 文件即可获得专家级能力

生成的 HTML 复核报告预览

以下为 AI 自动生成的专业级 HTML 复核报告（真实数据），包含顶部概览、真实故障区、已筛除误判区、待仲裁区和行动建议区。

CAN_Com_复核报告.html
在新标签页中打开完整报告 →
✦ EVOLUTION

持续进化的闭环

这个系统不是一次性搭建就结束的。每次复核都是一次"训练"，让 AI 的判断越来越精准、越来越贴合实际工程需求。

每次复核后 → 总结新经验

每次复核结束后，AI 会自动总结本次分析中发现的新模式：哪些 CAN ID 有特殊的仲裁阈值？哪些误判模式之前没有覆盖到？哪些边界场景需要补充规则？这些发现不会被丢弃，而是写入 Skill 文件，成为下一次复核的知识储备。

示例：V1.3 时发现 0xe0 报文同时存在正偏差和负偏差，需要分开处理。更新规则："同一 CAN ID 的正负偏差必须按偏差方向分开处理，负偏差归入误判，正偏差进入仲裁流程。"

自动更新 Skill 定义，版本号递增

新经验直接写入 CanComReview.md，下次调用 /CanComReview 时自动加载最新版本。从 V1.0 到 V1.4.1，规则库经历了 4 次大版本迭代，覆盖的测试场景从基础的周期类误判扩展到了 errorhook 检测、BLF 仲裁、零 Warning 有 Fail 的特殊处理等复杂场景。

人工审批确认 → 信任积累

每次 AI 提出的仲裁结论和待审批项，需要工程师逐一确认是否认可。确认过的判断会在 Skill 中标注，下次不再重复提出相同的人工审批要求。这形成了一种"信任积累"——AI 越来越了解工程师的判定标准，交互成本越来越低。

示例：第一次复核时 AI 对 0xbc 的判定需要人工确认。确认后更新 Skill："规则 2：0xBC 报文 ctime 延时 → 直接判定为误判，无需人工审批。" 后续复核不再为此提问。

跨项目复用，低成本适配

同一套 Skill 规则可以应用于不同项目的 CAN_Com 测试报告。核心的误判判定规则（仲裁、0xBC、负偏差、Δt）是通用的，适配新车型时只需更新 DBC 数据库文件即可。这意味着一个工程师积累的复核经验，可以在团队内横向推广。

✦ VALUE

核心价值总结

这个案例展示了 AI 在嵌入式测试领域的落地可能性——不需要大模型微调、不需要搭建平台，只需要一个 Markdown 文件和正确的使用方式。

零代码开发

整个系统仅靠一个 Markdown 文件（312 行规则定义）+ 自然语言交互搭建，不需要写任何应用代码。测试工程师不需要学习 Python 或 Web 开发，即可独立完成 AI 复核系统的搭建和维护。

经验显性化

将资深工程师的隐性经验（仲裁规则、误判模式、严重等级判定标准）转化为 AI 可执行的显性规则。新人不再需要数月跟师傅学习，读 Skill 文件即可获得专家级复核能力，且执行标准完全一致。

效率质变

人工复核 42,003 条 Warning 需要 3-5 个工作日 → AI 在几分钟内完成全量聚合归类、规则匹配、故障定位。同时完成 XML 导出做不到的全量 Warning 分析和 errorhook 系统性故障检测，效率和质量同时提升。

持续进化

每次复核后自动总结经验、更新规则库，形成"越用越准"的正反馈循环。从 V1.0 到 V1.4.1，规则已覆盖 99%+ 的测试场景。人工审批确认机制确保 AI 的判断标准与工程师的实际认知持续对齐。