009 · 把数据手册变成脚本，验证就可信了吗？

核心问题：把硬件兼容性检查拆成工程属性、显式规则与确定性脚本后，系统真正消除了哪些不可靠性，又把信任转移到了哪里？

论文卡片

• 原题： LLM-Driven, Datasheet-Aware Automated Hardware Compatibility Verification for Early-Stage, Pre-Schematic Embedded System Design
• 作者： Haotian Qiao、Robert P. Dick。
• 机构： University of Michigan, Ann Arbor。
• 版本： 2026-08-25，arXiv v1；分类为 cs.AI。
• 定位： 面向嵌入式系统早期架构设计的数据手册驱动兼容性验证，属于 LLM、知识图谱与确定性工程规则结合的实证系统论文。
• 阅读入口： alphaXiv · arXiv · 免费全文 · PDF

论文讲了什么

论文讨论的是原理图绘制之前的组件选型阶段：给定若干制造商数据手册，以及“哪些器件供电给谁、通过什么接口通信、处于什么环境”的自然语言连接描述，系统能否提前发现电气、供电、通信和工作环境不兼容。

作者认为，把所有 PDF 一次性交给 LLM 并直接询问兼容性有两个根本问题。第一，所需参数散落在很长的数据手册中，模型容易遗漏或混用不同工作条件、器件型号下的数值；第二，用户的自然语言问题通常没有完整列出应检查的属性、比较方法和失败条件。即使模型给出正确的“兼容／不兼容”结论，也未必使用了正确证据。

DEVICES 因此把任务拆成四个阶段。系统先从高层连接描述生成设计图，把交互表示成电源、数据和环境三类 netnode；再依据预先定义的验证准则，确定每个 netnode 需要哪些工程属性；随后从硬件知识图谱中检索带有型号、工作条件和单位语义的属性；最后让 LLM 生成 Python 验证脚本，而数值换算、范围比较和功率计算由本地脚本确定性执行。

验证准则不是一句“检查 SPI 是否兼容”，而是同时写明所需属性、评价步骤和规则。例如逻辑高电平检查会指定输出端的最低高电平必须满足输入端阈值，并规定某些值缺失时可使用的替代参数。级联供电则从叶节点向上汇总最坏情况下的功耗和转换损失。LLM 负责把语义化属性映射到程序，最终的算术判断不由模型口头完成。

主要结果

实验覆盖 7 个嵌入式系统设计、34 份共 1,210 页的数据手册，涉及环境感知、健康监测和位置追踪三类 IoT 场景。接口包括 UART、SPI、I²C，环境属性包括温度、湿度和气压，供电组件包括太阳能板、电池、电源适配器和 LDO。

作者设置了两个 one-shot 基线。第一个把完整数据手册和连接描述直接交给模型，不提供详细验证准则；第二个额外提供与 DEVICES 相同的准则，但仍把整批文档放在一次上下文中，不做结构化属性检索和按 netnode 拆分。

端到端准确率要求同时满足三项：使用正确工程属性、遵守正确验证过程、得出正确结论。DEVICES 达到 97.5%，无准则 one-shot 基线为 14.9%，加入准则后为 62.7%。第二个基线的大幅提升说明显式规则本身贡献很大；从 62.7% 到 97.5% 的差距则支持作者关于任务化检索和紧凑上下文的主张。长上下文基线的典型错误不是凭空编造参数，而是把不同电压模式或器件变体下的真实参数组合到了一起。

论文还报告，DEVICES 相比完整 PDF 的 one-shot 方法将输入上下文总量降低约 8.6 倍。DEVICES 的统计值是一个设计内所有 netnode 查询的 token 总和；单次查询平均约 4.7k token，最大约 12.6k。因而这里的优势不是把一次大查询机械切成若干次后只比较单次长度，而是在所有局部查询合计后仍显著减少了输入量。

在 property faithfulness 指标上，DEVICES 和两个基线都没有使用输入上下文之外的工程属性。由此可见，主结果并不是“结构化流程消除了幻觉、基线一直编造数据”，而是它改善了属性选择、工作条件一致性和验证步骤完整性。

证据边界

首先，论文所称的兼容性严格限于文档和高层连接图能够表达的接口级约束。通过检查只意味着在已建模架构、已提供规格和已定义规则内没有发现不兼容；它不预测真实电路行为，也不覆盖软件、封装、应用功能、具体引脚连接或原理图级寄生效应，不能替代后续仿真和实物验证。

其次，97.5% 建立在有限的 7 个 IoT 设计和作者当前支持的领域上。系统只处理文本规格；依赖曲线图的开关稳压器效率等信息尚不支持。新增接口或器件类型需要人工加入相应验证准则，因此“可扩展”指框架无需重写、局部上下文不会随规则总量增长，不等于新领域知识能够自动出现。

再次，真值由人工查阅同一批数据手册、确定所需属性、评价过程和结论而建立。论文称真值经过独立评价，但没有报告外部盲审、标注者一致性或真实 PCB 结果的对照。当前结果证明了系统与这套文档级规则和人工真值高度一致，尚不能直接外推为实际硬件失效率下降。

最后，当前稿件没有给出多模型、多个随机种子或置信区间。两个基线有效地区分了“有没有显式准则”和“有没有结构化上下文”，但 DEVICES 还同时包含设计图分解、知识图谱检索、属性缓存、上下文邻接编排和脚本生成，实验没有逐一消融这些组件。因此不能从 34.8 个百分点的差距中精确分配每个机制的贡献。

重点读哪里

先读 §I 的 Problem Definition 与 Design target and scope，确认论文所说的“兼容性”边界；再读 §III-A–III-D，理解准则、设计图、属性检索和脚本之间如何传递证据；最后读 §IV-B–IV-D，比较真值、两个基线和三项指标。§V 是作者关于“更强长上下文模型是否会使分解失去价值”的观点，应与实验结果分开理解。

思考启发

以下是导读者由论文引出的理解角度，不是作者额外验证过的结论。

DEVICES 最重要的转变不是用脚本取代 LLM，而是让不同类型的不确定性停留在不同边界：文档抽取负责“证据是什么”，验证准则负责“应该检查什么”，生成脚本负责“如何把证据代入规则”，本地执行器负责“计算结果是什么”。确定性执行只消除了最后一层算术不稳定；前面三层仍可能出错，但中间产物使错误更容易被定位。

这也说明，减少上下文并不只是成本优化。完整文档包含更多信息，却可能降低条件一致性；经过规则约束的局部上下文信息更少，但任务相关信息的密度更高。不过，选择性暴露必然引入新的遗漏风险：如果准则没有要求某项属性，检索器就不会寻找它。结构化流程把“模型是否想到了”转换成了“规则库是否覆盖了”，可靠性提高的同时，知识边界也变得更明确。

三个思考问题

1. 确定性脚本究竟证明了什么？

当数值比较由 Python 执行后，为什么最终结论仍不能被视为形式化证明或完整硬件验证？

2. 紧凑上下文会不会系统性漏掉未知约束？

只检索验证准则列出的属性能够减少噪声，但如果真正关键的约束不在规则库里，会发生什么？

3. 97.5% 准确率的外推边界在哪里？

在 7 个设计和作者定义的文档级约束上接近满分，能否支持对新器件、新接口或真实板级结果的可靠性判断？