验证工程：从 Vibe 硬件编程 Loop 到自迭代验证
内容提要
作者用ESP32开发板让AI自动搭建Arduino开发环境并烧录程序，AI约40分钟完成。但屏幕显示的“Qoder”被摄像头OCR误读为“Goder”，暴露出硬件验证难题：构建、上传、串口成功并不等于目标达成。作者由此提出“验证工程”，主张将目标拆成可验证命题，保留原始现场、处理结果与判断理由三层证据，并让验证结论改写下一轮行动，使验证能自我迭代，从而让AI编程真正进入工程化。
延伸解读
硬件验证的盲区：软件链路成功不等于目标达成
文章指出，构建通过、固件上传成功、串口有响应，只能说明软件链路走到了设备边上。真实输出还依赖屏幕、摄像头、光线、角度、字体和人眼。OCR将“Qoder”误读为“Goder”正是典型例子：如果只记录失败，下一轮可能盲目改代码；保留原图、处理图、OCR文本和裁剪参数，才能判断问题可能出在视觉验证器本身。
从测试清单到可验证命题：拆解目标的关键事实
作者主张验证工程不应先列测试清单，而应先拆可验证命题。测试清单是工具视角，问“能测什么”；可验证命题是目标视角，问“哪些关键事实必须被证明”。例如“自研云端AI终端可用”需拆成设备启动、屏幕显示、host relay通信、摄像头观察稳定token、麦克风响应、VAD触发、ASR返回文本、TTS播放声音等小命题，失败时才能归因。
验证要能解释自己：三层证据与下一轮动作
验证器不应只输出pass/fail，而应留下原始现场、处理结果、判断理由三层证据。结论需区分已验证、未验证、证据不足、验证器不稳定、需要更好现场、需要人工复查等状态，因为下一轮动作完全不同。已验证命题可升级为回归检查；验证器不稳定则先修验证器。只有验证结论能改写下一轮目标、实现、现场或验证方式，Loop才真正进入循环。
Q&A
什么是验证工程？它和传统测试有什么不同？
验证工程是把目标、测试、可验证和记忆等组织成一个能持续收敛的工程 Loop。它不只是多补几个测试或最后写测试报告，而是让系统知道自己是否真的接近目标。传统 TDD 为代码行为建立验证，验证工程则为目标和循环建立会自我演进的验证。
为什么构建通过、上传成功、串口有响应，仍然不能说明硬件 demo 真的跑起来了？
因为这些只能说明软件链路走到了设备边上，真实输出还在桌面上，在屏幕、摄像头、光线、角度、字体和人眼之间。只要这些没有回到工程系统，自动化验证就还停在半路。例如屏幕显示 Qoder 被 OCR 误读为 Goder，说明构建和上传成功不等于目标达成。
如何把目标拆成可验证命题？能举个例子吗？
不应先列测试清单，而应先拆可验证命题。测试清单是工具视角问能测什么，可验证命题是目标视角问目标里有哪些关键事实必须被证明。例如“自研云端 AI 终端可用”可拆成：设备能启动、屏幕能显示状态、host relay 能通信、摄像头能观察到稳定 token、麦克风指标能响应声音刺激、VAD 能触发、ASR 能返回文本、TTS 能播放声音等小命题。
验证器应该留下哪些证据？为什么不能只输出 pass/fail？
验证器应至少留下三层证据：原始现场、处理结果、判断理由。只输出 pass/fail 会导致下一轮盲目改代码；留下原图、处理图、OCR 文本、裁剪参数和预期 token 等，系统才能判断问题可能不在屏幕代码，而在视觉验证器本身。证据的价值是让下一轮少猜一次。
验证结论如何改写下一轮行动？Loop 为什么不是简单重复执行？
验证结论应改变下一轮的目标、实现、现场或验证方式：已验证的命题可升级成回归检查；未验证的继续推进实现；证据不足要补观察；验证器不稳定要先修验证器；需要人工复查就不要假装自动化已覆盖。Loop 不是重复执行，而是让偏差变成下一轮输入，让 Agent 不必重复做。
AI 编程中，为什么说“变化变得便宜，判断就变得昂贵”？
AI 能快速补齐脚手架、修复编译错误、生成配置等，使变化成本降低。但过去开发慢时团队会被迫讨论目标、边界、验收和风险；现在变化太快，系统反而更容易在没有可靠验证方式的情况下不断前进。AI Coding 的风险不是代码生成不出来，而是变化已经发生，但系统不知道这些变化是否真的接近目标。
