AI 开发验证体系：三层验证 + V0–V4

内容类型：验证方法难度：基础到进阶适合：所有使用 AI 修改 C# 上位机项目的工程师阅读时间：约 12 分钟

AI 说“完成”不等于项目已经验收。另一方面，为了安全把所有修改都跑全 solution、全测试、全现场，也会让日常开发变得极慢。

V10 把验证拆成两个维度：

三层模型：我在验证什么？
V0–V4：这次需要验证到多深？

并把结果状态单独记录，避免“没测到”和“测失败了”混为一谈。

1. 三层验证模型

层级	要确认什么	常见证据
代码层	语法、API、编译、Diff、资源结构	static、build、code review
功能层	正常/异常行为是否符合需求	focused test、simulation、replay、UI smoke
工程层	设备、长稳、环境、交付是否可控	现场日志、性能基线、真机、发布检查

一个任务不一定每次都要覆盖三层。例如改一个静态标题通常只需要代码/静态层；联锁和设备恢复则必须进入功能甚至工程层。

2. V0–V4：验证强度

等级	典型任务	推荐验证
V0	文案、注释、纯静态资源	git diff --check、readback、静态检查
V1	XAML、样式、普通局部 C#	affected project build；有明确 focused test 时再跑
V2	设备、通信、MES、存储、配置语义、共享约束	affected build + focused unit/fake/replay
V3	workflow、state、interlock、concurrency、stop/fault recovery	focused tests + WorkflowSmoke + 必要人工步骤
V4	发布、广泛重构、公共协议/Schema、兼容性	full checkpoint / release validation

验证等级和任务分析深度是两回事：

• 明确的联锁 Bug 可以直接 Execution，但验证仍是 V3；
• 新的简单展示流程可能需要先 Discovery，验证却只有 V1。

3. V0：不是“什么都不验证”

V0 适合文字、标题、注释、不参与编译的说明资源和明确静态内容。

至少检查：

Diff 是否只改了目标
文本是否正确
编码/格式是否异常
git diff --check

不要为了一个 Label 改名自动跑全套单测。

4. V1：affected build，不是 whole solution first

UI 样式、XAML、局部 ViewModel 修改，优先构建真正受影响的顶层项目。

有明确对应测试时跑 focused test；没有明确测试时可以写：

NoRelevantFocusedTest

不要因为找不到 focused test 就自动 fallback 到整个测试解决方案。

5. V2：设备/通信/数据优先 Fake 和 Replay

适合串口/TCP/UDP、协议解析、MES、数据存储、配置兼容、共享业务约束和测量值换算。

优先证据：

固定报文
Fake device
Captured Replay
数据库/文件临时样本
focused unit/integration test

真实设备测试与软件自动化证据分开记录。Fake/Replay 能证明软件行为，不自动证明真实设备、驱动和现场链路已经通过。

6. V3：行为后果和状态转换必须验证流程

如果修改了：

• InterlockFault / AlarmOnly；
• Stop / Continue；
• 连续 N 次触发；
• 窗口切换；
• 故障恢复；
• 并发与竞态；
• 多设备协调；

只证明某个方法返回值正确还不够，要覆盖关键 workflow。

推荐：

focused state/workflow tests
+ WorkflowSmoke
+ 必要的受控人工步骤

默认不直接升级成 WorkflowFull，除非影响面确实广泛。

7. V4：只在真正需要时全量

常见触发：正式发布、公共协议/Schema 变化、大范围架构重构、多项目依赖兼容、SDK/框架升级或用户明确要求。

V4 是发布检查点，不应该成为每次保存文件后的默认动作。

8. Focused Test 的两个重要纪律

8.1 0 个测试匹配不等于通过

如果过滤器跑出来：

0 tests matched

结果应记为：

NoTestsMatched / FilterMiss

不能写成 TestPassed。

8.2 测试优先验证行为，不绑死实现细节

优先复用稳定 seam：parser 输入输出、application service、state transition、workflow、fake/replay adapter、ViewModel 可观察行为。

不要为了测试一个小改，先重构出一套新接口。

9. 最终验证状态必须分开

推荐使用四种主状态：

状态	含义	示例
Verified	当前声明有实际证据支持	focused test/replay/现场步骤已经完成
Unverified	证据尚不足，且不是特定环境或设备原因	需求还缺样例、性能未测
EnvironmentBlocked	本应可执行的验证被构建/权限/工具环境阻断	E-SafeNet、缺 SDK、CI 权限
HardwarePending	软件侧可继续，但真实设备/HITL 步骤尚未执行	真机不在现场、高压测试未授权

EnvironmentBlocked 不等于 CodeFailed

例如：

• E-SafeNet 导致 MSB3541 / Null character in path；
• 权限阻止写构建目录；
• CI 缺 SDK。

这些不等于代码逻辑测试失败。

HardwarePending 不等于 EnvironmentBlocked

“真实设备今天不在现场”不是普通构建环境故障。若软件侧 Fake/Replay 已完成，但真机动作尚未做，应写：

SoftwareEvidence: Verified
HardwareVerification: HardwarePending

不能为了得到“全绿”让 Agent 自动连接设备执行高风险动作。

详见 真实设备操作与验证安全边界。

10. 同一代码指纹的环境结论可以复用

如果源码没有变化，而同一个 build fingerprint 已经证明是 E-SafeNet 环境阻断，不需要每个小改反复撞同一条失败命令。

代码变化后再重新计算 affected scope 和需要的验证。

11. Feedback Ladder：复杂 Bug 不必从自动测试开始

existing focused test
→ Fake / Simulation
→ Replay
→ 日志 / 时间线 / known-good diff
→ 最小 harness
→ 只读真实设备验证
→ HITL 现场验证

选择当前成本最低、最稳定、最能证明/证伪假设的反馈环。

12. 日志证据也有边界

日志调查优先：

收窄时间窗
→ 多源时间对齐
→ 第一个异常点
→ Evidence / Inference / Unknown

日志中没有 RX 只能证明“当前日志没有观察到 RX”，除非日志覆盖链路本身已被证明完整，否则不要直接升级成“设备没有发送”。

详见 日志与时间线诊断。

13. 性能验证需要同场景基线

“感觉不卡了”不是正式性能结论。

至少记录可复现场景和前后指标，例如：

Scenario: 2 series × 5000 points, refresh 10 Hz, 60 min
Before: WorkingSet 1.2 GB, UI p95 180 ms
After:  WorkingSet 430 MB, UI p95 28 ms

如果只跑了 5 分钟，就不能写“72h 长稳已通过”。

详见 性能与长稳诊断。

14. EvidenceGrade：结论强度跟证据走

等级	例子	可写结论
A	自动测试可重复	强结论
B	稳定 Fake/Replay	较强软件侧结论
C	日志 + 代码 + known-good	有证据支持的结论
D	仅代码推测	候选/怀疑

EvidenceGrade 表示“调查证据强度”，不替代 HardwarePending。一个 B 级 Replay 根因证据仍可能需要真机确认设备侧行为。

15. UI 验证也要分层

UI 修改	验证
纯文案	V0
布局/Style/XAML	V1 build + 页面查看
Binding/Command	V1/V2 focused behavior
状态/按钮使能	V2/V3
联锁/危险动作	V3 软件侧 + HardwarePending/HITL

“能编译”不能证明按钮状态和设备后果正确；按钮禁用也不能替代后端安全条件。

16. 交付报告怎么写验证结论

推荐：

Changed:
VerificationLevel:
VerifiedEvidence:
Unverified:
EnvironmentBlocked:
HardwarePending:
ResidualRisk:

不要只写“已测试，无问题”。

17. 和其它分级不要混用

本站还存在：

• G0–G9：新项目/大功能的阶段质量门；
• R1–R5：修改风险教学分级；
• L0–L5：允许 AI 自主程度。

它们与 V0–V4 解决不同问题。

G = 项目阶段是否可以往下走
R = 修改风险有多大
L = AI 可以自主到什么程度
V = 这次验证要做到多深

相关页面：

• 全流程质量门
• 回归测试与验收清单
• AI 辅助测试与回归
• V10 Skill 说明

一句话原则

验证不是越多越好，而是证据强度与改动风险匹配；任何“通过”都必须说清通过了哪一层，真机未做就明确 HardwarePending。