我用chipcode AI 写单片机代码三个月，踩过的 7 个坑
三个月前我开始让chipcode AI 帮我写单片机代码。
现在回头看，代码本身几乎没出过问题。出问题的全是代码以外的事。有些坑还挺好笑，记下来给同样在折腾的人省点时间。
一、它说「已验证」，我信了
第一次翻车是这样：改完一个串口收发的函数，chipcodeAI 很利索地回我一句「已修复，已验证通过」。
我当时还挺感动，直接烧进板子。上电，串口一片安静。
后来我去翻它的工具调用记录，发现它压根没编译过。那句「已验证」是它自己写的，没有任何东西支撑。
这事儿的教训不是「AI 会骗人」，而是它分不清「我说了」和「我做了」。在它那儿这两件事长得一模一样，都是一段文字。
二、delay(1000) 到底是一秒还是一百年
我让它给一个 STM32F103 写个闪灯，它给了：
void delay_ms(uint32_t ms) {
for (uint32_t i = 0; i < ms * 1000; i++) __NOP();
}
在它脑子里，一个循环大概一微秒。实际跑在 72MHz 上，一个 __NOP 加上循环开销，跟我想要的时间差了大概 40 倍。
灯是闪了，闪得像接触不良。
这不是它的错——它不知道我的主频、不知道有没有开优化、不知道 Flash 等待周期。它缺的不是知识，是上下文。
后来我学乖了，写这种跟时间有关的东西，先把主频、时钟树、优化等级告诉它，或者干脆让它用 SysTick。
三、引脚是它编的
「把 LED 接在 PA5，按键接在 PB12。」
我照着接了。按键按下去没反应。
查了半天，PB12 在我的板子上被 USB 占着。AI 不知道我手里是什么板子，它给的是「典型接法」。而典型接法这东西，跟「别人家孩子」一样，听着美好，跟你没关系。
现在我都在项目里放一个 board.md，把板子型号、引脚占用、外设冲突写清楚。它每次都会读。
四、串口被占用，它诊断成「驱动问题」
烧录失败，日志里写着「端口无法打开」。
AI 很认真地分析：「可能是 CH340 驱动未安装，建议重装驱动。」
我重装了两次驱动，重启三次电脑。
真实原因：串口监视器没关。
这事儿的荒诞之处在于，它给的诊断听起来特别专业，专业到你不会怀疑它。「重装驱动」这四个字有一种不容置疑的权威感。
后来我养成了一个习惯：它说「环境问题」的时候，先自己看一眼有没有低级错误。
五、编译过了，烧进去没反应
这次真的不怪 AI。
代码编译零错误零警告，烧录成功，板子纹丝不动。
折腾一晚上，最后发现是复位电容焊虚了。
我想说的是：「编译通过」离「能用」还有很远的距离。中间隔着电源、晶振、复位、接线、焊接质量。AI 能保证的只有第一段，而后面的部分它连看都看不见。
如果你的工具把「编译通过」显示成一个绿色的勾，很容易让人误以为整条链路都通了。这个勾的语义其实很窄。
六、它给我写了个跑不动的温控
需求是「读 DS18B20，超过阈值就开风扇」。
它写得很规整：每 100ms 读一次传感器，读回来做浮点运算，算出温度，跟阈值比较，控制 GPIO。
逻辑没毛病。但 DS18B20 的转换时间本身就要 750ms，它 100ms 读一次，读到的全是上一次的残留值。而且它在一个死循环里做浮点，没开 FPU 的 M3 上全靠软件模拟，一次除法几百个周期。
代码能跑，但跑得很难受。
这类问题最有意思：它写的每一行都对，合起来是错的。 因为它只对语法和 API 负责，不对时序和物理世界负责。
七、换个会话，它把我教过的东西全忘了
这个坑最消耗耐心。
我花二十分钟跟它解释：这个项目用 C99、不要用动态内存、日志走 UART2 不要用 printf、命名用下划线不要驼峰。
它记住了，写得很好。
第二天开新会话，同样的代码风格全没了，动态内存也用上了。我重新解释一遍。第三天再来一遍。
到第四天我烦了，干脆把这些约定写成一个文件扔在项目根目录，每次开头让它读。
然后我发现，这不就是「项目记忆」吗。
后来这套东西越写越多：验收条件也写成文件，验证结果也写成文件，连「哪一步算做完了」都让文件说了算，不让它自己说。
再后来，这些文件加上一套判定规则，就成了我们产品里那套机制。写这篇文章的时候我特意翻了一下最早的版本，第一版只有一个 notes.md，四行字。
七个坑说完。前六个基本是我自己的问题——没给够上下文、没检查低级错误、指望它负责物理世界。第七个不太一样，那是工具该解决的问题，不该让每个用户自己想一遍。
如果你也在用 AI 写嵌入式，建议从第七个坑开始收拾：先把约定写下来。这一个动作能省掉后面一半的来回。
