把 LLM 用在一个叫 Picodevil 的项目里是最近让我最有成就感的一次尝试。Picodevil 是我基于树莓派 Pico 做的一个桌面环境监测小设备名字就是 Pico 加 devil目标不大但五脏俱全有温湿度传感器、有按键切换显示、有简单的 LED 状态反馈最终还要通过 WiFi 把数据上报到本地服务。整个开发过程从最开始的需求拆解、引脚接线确认到 MicroPython 代码生成、串口日志排错再到把项目文档整理成 LLM 可以检索的资料库大部分环节我都交给了大语言模型。做完之后的结论先说在前面LLM 真的能帮你把一个软硬件结合的项目做出来但前提是你得知道怎么跟它配合。它不是万能的会一本正经地编造引脚号也会给出逻辑完整但时序完全错误的代码。这篇文章不聊概念直接按我的落地顺序拆一遍。如果你也在做电子 DIY或者想把 LLM 更高效地塞进自己的开发流程这篇会比较有用。1. 先搞清楚LLM 在这个项目里到底能替你做哪些事动手之前我把 LLM 能介入的环节分成了四类后面所有操作都在这四类里走。不然很容易变成“让 LLM 写代码复制进去报错再扔回去改”的低效循环。1.1 需求拆解让一个模糊想法变成可执行清单第一个能大量用到的能力是需求拆解。很多项目卡住不是因为代码难写而是需求说不清楚。我最初对 Picodevil 只有一个大致想法用 Pico 做一个能读取温湿度、能通过按键切换显示状态、能把数据上报的小设备。这个描述其实非常模糊直接写代码肯定会乱。我把这句话原样丢给 LLM让它输出一份任务清单要求包含硬件清单、接线方式、代码模块划分、测试步骤和可能踩的坑。它给出的结果比我预想的具体得多。它提醒了几个我自己容易忽略的点Pico 的 ADC 参考电压是 3.3V传感器模块供电最好独立多个 I2C 设备要检查地址冲突。这些信息不一定每条都对但至少给了我一份检查方向。这是 LLM 的第一个实际价值它不节省思考但能帮我把思考展开。你只需要提供一个非常粗糙的目标它就能生成一份需要人工复核的框架。我一般会再补一句约束“每个引脚说明都要标注信息来源不确定的地方标记为待确认。”这能明显减少后续幻觉内容的影响。1.2 代码生成LLM 写代码的边界到底在哪LLM 生成嵌入式代码的能力现在不算差。像 Pico 这种生态成熟、网上资料多的板子MicroPython 和 C SDK 的示例都很多模型完全可以参考这些资料生成能跑的代码。但要注意边界。LLM 生成代码的问题在于它没见过你的真实硬件不知道你的传感器实际型号是否兼容 3.3V 逻辑不知道你手上那根杜邦线是不是接触不良更不知道你的板子当前是什么固件版本。它能给出的是一个逻辑完整的代码框架但引脚号、外设初始化顺序、上拉电阻配置这些细节必须由你把关。我的做法是先让它生成最小可运行版本跑通之后再逐步加功能。不要一上来就让它写一个几千行的完整项目那样一旦出错你根本分不清问题出在哪个模块。1.3 解释和排错LLM 最被低估的能力排错是我在 Picodevil 上体验最好的环节。把串口输出的一段报错原样贴给 LLM让它解释可能原因再让它给出几种排查顺序它通常能给出靠谱的方向。MicroPython 的缩进错误、模块导入失败、引脚复用冲突这类问题它处理得比搜索引擎高效很多。为什么效果好因为报错文本本身就是非常明确的上下文模型从大量真实项目里学到过这些错误的标准解法。反过来如果只丢一句“我的设备不工作”效果就会差很多。这给出一条通用经验给 LLM 的上下文越具体得到的答案越可执行。报错日志、代码片段、硬件接线、供电方式这些信息给得越全LLM 的回答就越接近一个真实工程师的判断。2. 把环境分成三块硬件、软件和 LLM 访问方式很多人第一步就搞混了。用 LLM 开发一个硬件项目环境不是一个“开发环境”而是三个环境同时在工作硬件环境、代码编译环境、LLM 访问环境。我建议先把这三块分开准备每一块单独验证最后再合到一起。否则出了问题你根本不知道先查哪一边。2.1 硬件侧Pico 的烧录和串口日志是第一道门槛硬件侧的准备主要是三件事板子能上电、固件能烧录、串口能输出日志。Pico 的烧录方式很成熟按住 BOOTSEL 按钮再插入 USB电脑上会挂载出一个 U 盘把 UF2 格式的固件文件拖进去就行。这里要注意固件选择MicroPython 固件有不同构建版本下载时确认文件名和板子型号匹配。C SDK 方式则要配置交叉编译链复杂度会高一些。第一道门槛其实是串口日志。跑硬件项目没有日志就像闭着眼开车。Pico 的 MicroPython 默认把 print 输出到 USB 串口电脑上需要装好 USB 驱动然后用串口工具连接。Windows 下经常出现识别不到串口的问题多数是驱动没装或者 USB 线只能充电不能传数据。这个坑我后面专门讲。2.2 软件侧让 LLM 帮你决定用 MicroPython 还是 C SDKPico 有两个主流开发路径MicroPython 和 C SDK。选哪个会直接影响后面所有代码生成和排错方式。我当时把这个问题直接抛给 LLM。它给出的选择标准很清楚如果项目以快速验证为主对性能不敏感优先 MicroPython如果要做低功耗、复杂时序、高性能外设驱动优先 C SDK。它还提醒MicroPython 在内存不足和实时性上有明显上限C SDK 的学习成本和编译链路复杂度更高。这个思路是对的。像 Picodevil 这种桌面小设备用 MicroPython 足够。不过要注意LLM 给出的建议是一般性规律它不知道你的具体场景。如果你的项目涉及大量外设并发、精确的传感器时序或超低功耗哪怕规模小也建议直接走 C SDK避免后期返工。2.3 LLM 侧云端 API、本地推理、Agent 框架怎么选LLM 的访问方式有三种常见路径我整理了一个对比表方便你根据自己的情况选。方式适合场景需要关注的指标常见坑点云端 API追求生成质量上下文需求大接口超时、并发限制、成本上下文越长成本越高返回格式可能不稳定本地推理数据敏感、离线开发、简单代码片段显存或内存、推理速度、量化格式配置不够时速度很慢小模型容易写错复杂逻辑Agent 框架需要多步操作、调用工具、自动化工具调用准确率、任务编排、失败重试框架本身有学习成本过度自动化反而更慢我的建议是第一次跑通用云端 API 或本地推理都行关键是别在访问方式上花太多时间。如果你只是让 LLM 写代码、解释报错直接用聊天窗口就够了。等你需要“自动读取串口日志再自动改代码”这类流水线操作时再上 Agent 框架。这里特别说一下本地推理。很多人会纠结推理引擎选哪个其实更值得关注的是模型量化和上下文长度这两个参数。同样的模型量化位数不同速度和生成质量差异很大上下文窗口不够时长代码文件会被截断导致 LLM 只看到一半代码就给出判断。3. 实操流程从一句需求到 Picodevil 跑起来环境准备好之后我建议把整个开发流程拆成四步。每步都有明确的验收标准不满足就停下来检查不要往下走。这套流程不只是在 Picodevil 上适用换到其他嵌入式小项目也一样。3.1 第一步让 LLM 输出需求说明书和任务清单先把你的项目目标写清楚哪怕只是一句话。比如我写的是“用树莓派 Pico 做一个读取温湿度、按键切换显示、通过 WiFi 上报数据的桌面设备”。然后把这句话丢给 LLM要求它输出一份需求说明书必须包含功能列表哪些是必须功能哪些是后续扩展硬件接线表每个外设用哪个引脚、供电方式代码模块划分每个模块负责什么测试步骤每步如何验证成功风险清单可能踩的坑和规避方式这一步的验收标准不是“它写得对不对”而是“它有没有把你自己没想清楚的问题暴露出来”。LLM 很擅长生成看起来完整的清单但里面可能有臆造内容。如果你对硬件不熟最好用它的清单去对照官方文档和其他教程看看引脚号、模块名是否对得上。3.2 第二步生成接线表和引脚映射先对照再动手给 LLM 提供你手上外设的具体型号让它生成引脚映射表。比如“DHT11 数据脚接 GPIO 2VCC 接 3.3VGND 接 GND”这类信息LLM 一般能写出来但你必须人工核对一次。核对标准很简单打开 Pico 的引脚图依次确认每个引脚编号是否存在再对照外设的数据手册确认供电电压是 3.3V 还是 5V确认模块是否支持板载上拉。最容易出问题的是 I2C 和 SPI 这类总线LLM 可能把 SDA 和 SCL 的引脚号写反或者忽略 I2C 设备地址冲突。这一步不要省。我发现把接线确认放在最前面后面的代码调试会顺畅很多。绝大多数“代码运行出错”根源其实是硬件接线错误。3.3 第三步单文件代码生成先跑最小闭环不要一开始就生成完整项目。我的做法是先把最小闭环跑通让 LLM 生成一个单文件 MicroPython 脚本功能就是开机后在串口打印一句启动信息然后循环读取传感器并打印数值。这个最小闭环要验证三件事固件能跑、串口能输出、传感器能返回数值。只要这三件事都正常后面加功能就只是迭代问题。如果最小闭环跑不通先别急着让 LLM 改代码先检查固件、接线和串口确认是环境问题还是代码问题。等最小闭环通过再逐模块加功能加显示、加按键、加网络请求。每加一个模块就跑一次把新报错贴给 LLM。这个过程有点像两个人结对编程LLM 负责写思路和实现你负责验证和把关。3.4 第四步把报错日志直接丢给 LLM形成调试闭环代码报错时最有效的做法是把完整报错信息连同相关代码片段一起发给 LLM然后问三个问题这个报错最可能的原因是什么应该先检查哪个位置给出一个最小修复方案这里有个细节尽量报告完整的“现象加输入加输出”。比如“我执行 sensor.read() 后返回空值数据脚接在 GPIO 2供电 3.3V日志没有任何报错”。这种上下文比单纯贴报错更容易让 LLM 定位问题。调试闭环的关键是让每一次修复都可验证。改完代码重新跑一次确认输出发生变化再决定是否继续。如果连续三次修改都没有改善停手回到硬件侧检查接线和供电不要继续和代码死磕。注意最浪费时间的调试方式是让 LLM 在一个错误假设上反复打补丁。连续多次没进展时优先怀疑硬件和输入而不是代码逻辑。4. 从聊天窗口升级成可复用工具链当你从“问一句答一句”变成要处理多个文件和多次迭代时纯聊天窗口就不够用了。这时候可以考虑把 LLM 组织成工具链。但工具链不是必须的要根据实际迭代频率决定。4.1 为什么需要编排框架对话式生成是单点Agent 是流水线聊天窗口本质是单点交互你抛一个任务它返回结果。对写代码、改代码这种单任务是够用的。但如果你想整个流程变成“读取代码文件、检查日志、提出修改、重新生成文件、自动测试”单点对话就不够了。这就要用到编排框架。LLM Agent 的核心思路是让模型在多个步骤之间决策它可以选择读哪个文件、调用哪个工具、决定改哪个参数。好处是流程可以自动化坏处是它可能选错工具、读错文件或者在一个错误方向上反复尝试。“比人高效”和“比人可靠”是两回事。我的经验是先不要上完整 Agent。可以在项目里先加一个简单的脚本封装几个固定动作读取串口日志、把日志存成文件、把日志发给 LLM、把 LLM 回复的代码写回文件。这样一个半自动流程比完整 Agent 好控制得多。4.2 用 MCP 把工具接进 LLM文件读取、串口日志、文档查询MCP 是当前很常见的把工具接入 LLM 的方式。它定义了一套统一协议让 LLM 能调用外部工具比如读取本地文件、执行命令、查询文档。对 Picodevil 这种项目MCP 能接的工具大概有这三类文件读写让 LLM 直接读取当前代码文件生成修改建议后写回串口日志读取把串口输出写入日志文件再让 LLM 分析文档查询把芯片手册、外设 datasheet 变成可检索内容接入 MCP 的好处是减少复制粘贴让 LLM 基于真实数据做判断而不是基于你手动转述的信息。但要注意权限问题MCP 服务如果配置了命令执行权限一定要限制可执行命令范围只留项目需要的白名单命令不要开放任意命令。4.3 用 RAG 整理硬件手册和芯片资料另一个值得做的是 RAG也就是把资料库变成 LLM 可以检索的上下文。很多人听说过 RAG但不知道对硬件项目有什么用。我把它用在两个地方。第一把 Pico 官方文档、MicroPython 文档、外设 datasheet 的关键章节整理成文本片段存入向量库。这样问答时LLM 可以从资料库中检索相关段落而不是完全依赖自己的记忆能明显减少引脚和寄存器信息的幻觉。第二把开发过程中自己和 LLM 的对话记录、修过的坑、验证通过的代码片段沉淀成项目笔记。这个笔记本身也能变成检索源。时间久了这个项目的知识库会越来越完整后续调试速度会快很多。RAG 实现不算复杂核心是文本切分、向量化、检索和拼装上下文。但要注意切分粒度硬件手册按章节切最好按自然段切容易丢失上下文。切分过细会导致检索结果不完整切分过粗会造成上下文超长。4.4 什么时候需要自己写一个工作流脚本最后说一个实际判断不是所有场景都需要框架。如果你只是偶尔用一次 LLM聊天窗口足够。如果你每天都要处理几十次代码修改和日志分析那才值得搭 Agent、MCP、RAG 这一套。搭工具链本身也要花时间而且会引入新问题比如版本兼容、API 变化、上下文管理。以我的经验先用脚本打通最小闭环比如一个 Python 脚本封装“日志到 LLM 到写回文件”跑稳之后再考虑上完整框架。这个顺序能帮我把“工具问题”和“项目问题”分开避免出现“代码报错但搞不清是程序问题还是工具链问题”的混乱。5. 关键参数和判断标准怎么知道 LLM 给你的东西能用用 LLM 开发最常被问的就是怎么判断它给的东西能不能用我总结了一套自己的判断标准。5.1 代码能用的标准不是“没报错”而是“输出可验证”很多人觉得 LLM 生成的代码只要编译不报错就能用。对嵌入式项目来说这个标准完全不成立。编译器不报错只能说明语法没问题不表示逻辑正确、引脚正确、时序正确。我的判断标准分三层第一层能否在真实硬件上运行运行后串口有预期输出第二层连续多次运行是否稳定不会随机卡死或偶尔失败第三层更换环境参数后是否仍然可控比如换一批传感器或改供电方式如果你只是学习验证到第二层就够。如果要长期使用就必须考虑第三层。很多项目在开发环境跑得很好一到现场就出问题往往就是第三层没做验证。5.2 模型精度和本地推理要关注什么用 LLM 做开发时我对精度的关注点和其他应用不太一样。如果用的是云端 API精度由服务端决定一般不用管。如果用本地推理就要注意量化格式对生成质量的影响。常见做法是用低精度量化省显存但量化位数过低会导致代码生成质量下降尤其是复杂逻辑和长代码。我的建议是代码生成任务优先用 FP16 或 BF16 这类精度起步只有当显存或内存确实不够时再考虑更低精度量化。同时要关注上下文长度优先确认模型的上下文窗口能覆盖整个代码文件否则分析不完整结论自然不准。5.3 生成质量不稳定时先查上下文和输入格式如果你发现 LLM 的回答时好时坏先别怀疑模型不行先检查三样东西上下文是否完整代码文件有没有截断报错日志是否完整输入格式是否清晰有没有明确区分“事实信息”和“任务要求”两部分约束是否明确有没有告诉 LLM 哪些引脚是确定的哪些需要它推理我经常看到的问题是用户把一段乱七八糟的日志和代码混在一起发给 LLM模型分不清哪里是报错、哪里是代码、哪里是描述。这种情况下生成质量差不是模型问题是输入问题。5.4 速度、质量、成本之间的取舍最后落到工程层面。用 LLM 开发项目速度和质量往往不能两头都占。我的建议是日常调试用快而便宜的小模型生成复杂完整模块时再换更强的大模型。这个策略在本地推理和云端 API 都适用。实际操作时我会准备两套配置一个快速模式用于解释报错、简单问答一个高质量模式用于代码生成、架构设计。快速模式用较小模型和较高采样温度高质量模式用较强模型并降低随机性。用不同配置处理不同任务整体效率会明显提升也不会在简单问题上浪费太多成本。6. 踩过的坑和调整过的地方最后写一写我实际踩过的坑。这些坑不一定每个你都会遇到但遇到时可以帮你少走弯路。6.1 LLM 编造引脚和寄存器这是最需要注意的问题第一个坑是幻觉。LLM 在生成硬件相关代码时会一本正经地输出不存在的引脚、错误的寄存器地址、不存在的库函数。尤其是在资料比较少的传感器或芯片型号上幻觉率明显更高。我的应对方式有三条凡涉及引脚、寄存器、库函数都让 LLM 标注来源并给出理由把官方文档关键信息通过 RAG 放进上下文减少对模型记忆的依赖每次拿到代码先用最小测试脚本验证硬件相关部分再叠加业务逻辑如果你发现 LLM 连续几次给出同一个不存在的引脚马上停手。不要在错误假设上继续加代码否则后面排错会非常痛苦。6.2 别让 LLM 一口气生成整个项目第二个坑是贪大。让 LLM 一次生成整个项目的所有模块看起来省事实际是给自己埋雷。模块之间的接口约定、变量命名、时序配合LLM 一次生成时可能不一致。一个模块的 bug 会传染给另一个模块最后你根本不知道问题出在哪。我的做法前面已经说过先最小闭环再逐模块加。每个模块单独验证通过后再合并。合并时特别关注全局变量、共享状态和初始化顺序这三个地方最容易在合并阶段出问题。6.3 串口、权限、路径问题比代码逻辑更容易卡住第三个坑容易被忽略。开发过程中真正卡住我的往往不是代码逻辑而是环境问题Windows 下串口驱动没装、USB 线不支持数据传输、文件写入权限不足、项目路径含中文导致编译工具异常、MCP 服务读取日志时权限不够。这些问题的特点是报错信息五花八门容易误导方向。我的排查顺序固定为先看串口能不能识别、日志能不能输出再看文件路径和权限再查依赖版本和编译环境最后才怀疑代码逻辑先确认环境能不能支持再判断代码写得对不对。这个顺序能避免很多无效调试。6.4 落地前留一份检查清单把这次的经验总结成一份检查清单方便后面复用需求是否拆成了可验证的小任务引脚和接线是否人工核对过是否先跑通了最小闭环串口日志是否全程可用每个模块是否单独验证过验证通过的代码和踩过的坑是否沉淀成笔记是否确认上下文长度能覆盖完整代码文件是否预留了失败重试和日志清理机制这份清单不复杂但每一条都是实际踩过坑之后的总结。对硬件项目的 LLM 辅助开发来说最重要的不是模型有多强而是你自己有没有一套稳定的验证流程。做完 Picodevil 之后我的整体感受是LLM 确实把“从想法到原型”的门槛降低了一大截但它没有替你省掉工程判断。它能帮你快速生成代码、解释报错、整理文档但接线对不对、供电够不够、引脚冲突不冲突最终还得你自己去确认。如果你也想做类似的项目我建议先把单任务流程跑稳再考虑上 Agent、RAG 这些工具链。先让 LLM 从一个代码生成器变成你的结对编程伙伴再让它变成一条自动化流水线。这个顺序比一开始就搭一套复杂框架可靠得多。