用 chipcode AI 寫單片機程式三個月：踩過的 7 個坑

2026-11-06 2

版权

本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。

简介： 本文总结作者用AI编写单片机代码三个月踩过的7个典型坑：从轻信“已验证”、时序估算错误、引脚冲突，到环境误判、硬件故障、时序逻辑缺陷，再到会话遗忘。核心教训是——AI缺的是上下文与物理世界感知，而非知识；唯有将项目约定（主频、引脚、规范等）文档化，才能真正提效。

我用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 写嵌入式，建议从第七个坑开始收拾：先把约定写下来。这一个动作能省掉后面一半的来回。