把 AI 接进硬件开发：用 Cursor / Claude 写固件

你已经会用 AI 写 Web、写脚本、改 bug。做硬件的时候，这个能力是你最大的外挂——而且收益比写软件还大。原因很实在：硬件的底层细节又多又碎（寄存器、时序、库的 API 名字），你又不熟，记不住也不想记，正好让 AI 补位。你负责"想要什么"和"判断对不对"，AI 负责把你不想啃的样板代码吐出来。

但硬件场景有个软件里少见的坑：AI 写错代码顶多编译不过、灯不亮，重来就行；AI 说错接线，可能直接烧板、甚至触电。 所以这一篇的重点不只是"怎么让 AI 干活"，更是"怎么用它而不被它坑"。读完你会拿到一整套能直接照搬的提示词，和一张"哪些能信、哪些必须自己验"的清单。

---

关键：把上下文喂够

AI 写硬件代码翻车，九成不是它笨，是你没给够信息。它看不见你桌上那块板，不知道你用哪个库、接在哪个引脚、供电几伏。你给的信息越少，它越只能靠"最常见的猜测"硬编，编出来的代码往往对不上你的实际硬件。

把下面这组坏提问 / 好提问对照着看，差距就出来了：

好提问长这样，一次把"四件套"说清——用什么板 + 什么框架 + 接了什么 + 接在哪个脚 + 想实现什么：

"我用 ESP32-S3，ESP-IDF 5.x，接了一个 DHT11 温湿度传感器在 GPIO4，帮我写一段每 2 秒读一次温湿度、把结果用 ESP_LOGI 打印出来的代码。如果要装组件，告诉我组件名和怎么加。"

这样给出来的代码，通常能直接编译、直接跑。多出来的那几句话（框架、引脚、波特率、库），就是把 AI 从"瞎猜"拉到"照你的硬件来"的关键。

---

三个高频用法，每个给一个能照搬的模板

日常用 AB 写固件，八成的场景就这三个：写初稿、解释看不懂的代码、查错。每个都给你一个填空式模板，把方括号里的内容换成你自己的就能直接发。

用法一：写初稿

我用 [开发板型号]，[ESP-IDF / MicroPython] 框架（本站主线 ESP-IDF）。
硬件接线：[元件A 接在 GPIOxx，元件B 接在 GPIOyy……]。
我想实现：[一句话描述功能]。
要求：代码要能直接编译；关键行加中文注释；如果要装第三方库，列出库名和安装方法。

用法二：解释看不懂的代码

把一段你抄来却看不懂的代码贴上，让它逐行讲。这是补底层知识最快的方式：

逐行解释下面这段代码在干嘛，每行讲清"它操作的是什么、为什么这么写"。
遇到寄存器或硬件相关的概念，用初学者能懂的话说明，不要只复述函数名。
[把代码贴在这里]

用法三：查错（最省时间的用法）

代码报错时，把报错原文整段贴给它，别自己转述、别只截一半。编译错误、串口乱码、Failed to connect，原文里藏着最关键的线索：

这段代码在 [编译时 / 上传时 / 运行时] 报错，下面是完整报错和相关代码。
帮我分析：1) 错在哪一行、什么原因；2) 怎么改；3) 怎么避免下次再犯。
报错原文：
[整段粘贴，不要删节]
相关代码：
[贴上]

---

走一遍完整工作流：从需求到能跑的代码

单个提示词会用了，再看怎么把它们串成一条线。下面用一个真实的小需求走完整流程——"DHT11 测到温度超过 30℃ 就让板载 LED 闪，否则常灭"：

1. 描述需求（用"写初稿"模板）：把板子、DHT11 接 GPIO4、板载 LED 在 GPIO2、判定逻辑一次说清，让 AI 给初稿。
2. 先读懂再上传：拿到代码别急着烧。扫一眼——它用的库是不是你装了的？引脚号和你接的一致吗？loop 里的读取间隔合理吗（DHT11 别读太勤，至少隔 1~2 秒）？看不懂的地方用"解释"模板问清楚。
3. 核对接线（这一步 AI 说了不算）：代码逻辑可以信 AI，但它顺手给的"DHT11 怎么接电源"必须你自己核——DHT11 是 3.3V 还是 5V 供电、要不要上拉电阻，回让 AI 帮你读 datasheet或官方资料对一遍。
4. 上传、看现象：编译烧录。如果报错，用"查错"模板把原文贴回去。
5. 迭代：跑通后想加功能（比如"再加个串口打印当前温度"），接着在同一段对话里说"在这基础上加……"，AI 带着上下文改，比从头写顺。

一条线下来你会发现：AI 把"写样板代码"这件烦事包了，你的精力全花在"判断对不对"和"接线安不安全"上——这正是该花精力的地方。

---

但是——它会一本正经地错

这是硬件场景必须刻进脑子里的一条：AI 对接线和电气参数，经常自信地说错。

为什么偏偏是接线电气这块容易错？因为 AI 是从海量文本里学来的，而网上的接线教程版本极多、相互矛盾、还常年不更新——不同厂家的同名模块引脚顺序就可能不一样。AI 没法"看见"你手上这块具体的板，只能给一个"统计上最常见"的答案，碰上你那块的细节差异就翻车。代码错了编译器会拦你，接线错了没人拦——直接通电烧给你看。

举两个真实会踩的反例：

• 反例一（电压）：你问"DHT11 怎么接 ESP32"，AI 可能顺口说"VCC 接 5V"。但 ESP32 的 GPIO 是 3.3V 逻辑，很多 ESP32 板子的数据脚直接灌 5V 是有风险的。这种电压匹配，必须自己回 datasheet 确认，不能信 AI 的口头答案。
• 反例二（限流电阻）：你问"LED 怎么接"，AI 给的电阻值可能是按 5V 系统算的，直接用在 3.3V 的 ESP32 上要么偏暗要么不安全。正确做法是用点灯那篇里讲的欧姆定律自己算，或用站内的限流电阻计算器。

---

哪些能信、哪些必须自己验

把上面这条原则拆成一张可对照的清单。判断的分界线就一句话：纯软件逻辑可以大胆让 AI 试；连接物理世界的东西必须自己再验一遍。

AI 说的内容	能不能直接信	怎么处理
代码语法、循环逻辑、函数怎么用	基本能信	编译跑一下，错了它自己会暴露
库的 API 名字、参数	多数能信，偶尔记错	装不上或报"未定义"就让它查最新文档
算法、状态机、数据处理	能信	用串口打印中间值验证
引脚接法、模块怎么连线	不能直接信	回 datasheet / 本站章节逐一核对
供电电压（3.3V/5V）、电平匹配	不能直接信	必须查 datasheet，错了会烧
限流电阻值、分压电阻值	不能直接信	自己用欧姆定律算，或用站内计算器
涉及强电、锂电充放电的任何建议	绝对不能直接信	这块出错有人身风险，务必查权威资料

记法很简单：代码归 AI 兜底，电归你兜底。 凡是"接错会冒烟"的，都划进必须自己验的那一栏。

---

进阶技巧：两段式提问，让 AI 先找料再成文

直接让 AI 写复杂代码，它容易"凭印象"硬编、把库的 API 记串。一个好用的技巧是把"找资料"和"写代码"拆成两步：

1. 第一段，只让它找料："我要用 ESP32-S3（ESP-IDF）驱动一个 SSD1306 OLED 屏。先别写代码，先告诉我：常用的是哪个库、怎么装、初始化要哪几个关键参数、I2C 地址通常是多少。"
2. 第二段，基于料写代码：确认上面信息对得上你的硬件后，再说"基于刚才确认的库和参数，写一段在屏上显示 'Hello' 的完整代码"。

这样分两步，AI 先把"用什么、怎么用"摆清楚给你过目，你能在它动笔前就拦掉跑偏，比一口气让它写完再回头查错省事得多。同样的两段式，也适用于"先认板列引脚、再写代码"和"先确认接线、再写驱动"。

---

动手挑战

别只看，动手把这个外挂用起来：

1. 让 AI 改代码：回到点灯，把那段闪灯的完整代码贴给 AI，让它帮你改成呼吸灯。改完先自己读懂 LEDC（PWM 外设）那几行在干嘛（看不懂就用"解释"模板问），再上传。
2. 故意喂一个坏提问：先用"写个读温度的代码"这种没头没尾的问法，看 AI 给你什么；再用本文的"四件套"好提问重问一遍，对比两次结果差多少。这一对比会让你真切记住"喂够上下文"有多重要。
3. 练查错：故意把代码里某个引脚号写错，编译报错后把原文贴给 AI，看它能不能定位——顺便体会"贴原文"和"自己转述"的差别。

---

小结 · 你现在掌握了什么

• 你知道了让 AI 写硬件代码靠不靠谱，关键在上下文喂得够不够——把"板 + 框架 + 接线 + 引脚 + 目标"一次说清。
• 你手上有了三个能直接照搬的提示词模板（写 / 解释 / 查错），还有一条从需求到能跑代码的完整工作流。
• 最重要的：你分得清哪些能信 AI、哪些必须自己验——代码归 AI 兜底，电归你兜底，凡是"接错会冒烟"的都自己核。

下一步：带着这个外挂，去让 AI 帮你读 datasheet——硬件世界里那本最难啃的"说明书"，AI 也能帮你嚼碎。把读手册和写代码这两个外挂叠起来，你做硬件的速度会和别人拉开差距。