一句话: AI 幻觉不只是凭空编造。本文讲了一个更隐蔽的模式代码里填了临时占位值跑通逻辑AI 把它当成了已确认的规格值直接写进对外文档。核心教训——要求 AI 生成对外文档时必须对比待确认清单标注 ⚠ 未确认项。适合谁读用 AI 辅助嵌入式开发、要 AI 生成对外文档的工程师。事情经过项目里有一张 CMIS 寄存器表要给上位机同事做通讯协议。信息来源有两份固件代码app_cmis.h/c里面有寄存器定义和默认值同事的 docx 规格文档写了各寄存器的含义我让 AI 整合这两份信息生成一张完整表格。AI 生成的表格里功耗寄存器填了30W旁边还写了和同事确认过。问题出在哪我看到这句和同事确认过觉得不对劲——我不记得确认过这个数。倒回去查来源写了什么代码里#define CMIS_POWER_DEFAULT 30注释// TODO: 待实测同事文档功耗典型值 30W旁边标注需实测确定AI 输出功耗 30W已和同事确认代码里的 30 是临时占位值——能编译、能跑通逻辑就行。同事文档的 30 也是预估明确写了需实测。两个来源都标注了待确认。但 AI 看到代码有值 文档有值 两个来源一致 → 自动推断为已确认。这不是凭空编造常见的 AI 幻觉是无中生有——编一个不存在的 API、捏造一个寄存器地址。这类幻觉不一样信息源头是真实的——代码确实填了 30文档确实写了 30。错在 AI 把信息的状态搞混了临时占位值 ≠ 已确认的规格值 能跑通逻辑 ≠ 这就是最终值AI 没有区分这两种状态的能力——它看到两个来源都对上了就自动认为确认了。但工程实践中两个来源一致也可能两个都是错的。为什么容易踩嵌入式代码里临时占位值到处都是#define MAX_CURRENT 1000→ 先填个安全值等硬件回来后实测p-TargetPower 5.0→ 先设个初始值等标定数据出来再改DelayMs(100)→ 先给个大概等示波器量了再调这些值的特点是能编译、能跑、但目前不保证正确。AI 读代码时看到的是一行确定的#define或确定的赋值语句。它不会区分这个值是故意这么定的还是暂时这样填的。怎么防两条规则1. 生成对外文档时要求 AI 对比待确认清单在项目记忆里维护一个待确认项清单## ⚠ 待确认项 - CMIS_POWER_DEFAULT 30 → 需实测 - SOA_BIAS_CURRENT 250 → 等标定数据 - TEC_TARGET_TEMP 25.0 → 客户未确认指令生成表格时逐项对比待确认清单。命中任何一项标 ⚠ 并注明待实测/待确认。2. 要求 AI 标注来源不自己推断确认每个值标注来源(1)代码默认值 (2)文档预估值 (3)实测确认值 只有 (3) 才能写已确认。和之前踩过的坑是一类问题之前踩过两个类似的坑十进制/十六进制混淆代码里写了0x1AAI 读成十进制 1A不存在的东西然后自己脑补了一个值没读规范就写代码让 AI 写 SPI 驱动它直接用了 GPIO 模拟没读项目已有的硬件 SPI 封装——因为GPIO 模拟 SPI在它的训练数据里太常见了这三个坑的共同根因AI 倾向于填补信息缺口——当它不确定一个值的含义时不会说我不确定而是根据上下文推测一个看起来合理的答案。预防方法都一样显式告诉 AI 什么是不确定的。不确定的东西标出来比靠 AI 自觉更可靠。实测对比不对比待确认清单: 占位值当确认值发给上位机 | 逐项对比标⚠: 每个值来源清清楚楚有用的话点个收藏下次调试直接用。有问题欢迎评论区交流看到了都会回。下一篇一天学完15个源文件——DeepSeek看图、AI当老师、AI审查代码、省Token技巧——用AI加速嵌入式开发
——基于Spring Boot与jlibmodbus构建高可用ModbusTCP从机服务)
