当大模型不再是“玩具”，你该怎么用AI写出能跑的代码

大家好，我是肖遥。

前两天有个读者私信我，说自己用AI写嵌入式代码，结果是——代码能看着思路但编译不过，硬件不按预期跑，最后还得一行行手写。他问我：是不是用AI写代码的方法不对？

这个问题戳中了很多嵌入式工程师的痛点。

不是AI不行，是我们还没学会怎么用它。

学会当“指挥官”

网上有一堆AI辅助编程的教程，但大多面向纯软件开发。嵌入式领域的特殊性太强——硬件依赖、资源受限、实时性要求，都不是AI天生的强项。

作为在嵌入式领域摸爬滚打了十余年的工程师，我踩过不少坑，也摸索出一套适合自己的“人机协作”方法。

简单来说，AI是一个能理解指令的执行者，但它需要清晰的指引。这其实很像写代码本身——把复杂问题拆解成一个个可执行的步骤。只不过以前我们拆出来自己写，现在拆出来指挥AI写。

下面我把这套流程梳理出来，希望对大家有帮助。

步骤一：让AI理解你的“硬件背景”

嵌入式程序不是纯软件，它和硬件强相关。不同MCU型号的Flash、RAM、外设都不一样。如果你不给够上下文，AI生成的代码基本没法直接用。

有效提问示范：

“我现在用的是STM32F103C8T6，时钟配置为72MHz。我需要初始化SPI2，用于连接一个125kHz的RFID读写器。请帮我生成基于HAL库的SPI初始化代码，要求以主模式、数据宽度8位、最大速度2MBits/s运行。”

无效提问示范：

“帮我写个SPI初始化。”

前者提供了MCU型号、时钟、外设用途、具体配置参数；后者什么都缺。AI不是读心术，你需要把硬件环境描述清楚。这与我们开发时编写接口文档如出一辙——文档写得越清晰，下游开发就越省事。

同时建议，提问时明确指定驱动库是HAL还是LL，以及代码风格的偏好，比如命名规范、注释习惯等。

步骤二：把复杂任务“拆开喂”

嵌入式开发的代码通常涉及底层驱动、业务逻辑、实时调度等多个层面。一次性让AI生成全量代码容易出错，我的习惯是：单个任务单次问，驱动和业务分离。

例如，开发一个温湿度监测系统，建议这样拆分：

1. 第一轮提问：“请帮我生成初始化I2C2和读取SHT30传感器的C代码，MCU型号为STM32L051C8T6。要求在20ms内完成一次温湿度读取，并做好错误重试机制（重试3次）。使用LL库。”

2. 第二轮提问：“基于上一轮生成的读取函数，帮我写一个状态机，每500ms调用一次读取，当湿度超过80%时通过UART发送警告消息。”

3. 第三轮提问：“为以上功能编写一个简单的freeRTOS任务，优先级设置为中等（tskIDLE_PRIORITY + 2）。”

每完成一块，可以在本地跑通后再问下一块。这样定位问题也会更精准。

步骤三：不是检查代不代跑，是检查安不安全

在非嵌入式领域，AI生成的代码如果不完全符合预期，影响的可能只是软件功能。但在嵌入式领域，一个bug就可能导致硬件失效、系统死机。

所以AI生成的代码在烧录到目标板之前，建议系统性审查这几个方面：

• 引脚配置：GPIO复用功能、上下拉电阻等是否与硬件设计匹配

• 时序逻辑：中断优先级、看门狗喂狗时机是否合理

• 资源边界：数组索引、循环次数、动态内存分配是否可控

• 错误处理：外设通信失败后是否有重启或补救措施

• 功耗影响：不必要的外设是否在空闲时被正确关断

审查不是挑错，而是帮AI“补短”——许多AI模型在训练集里看到的嵌入式代码，大量来自demo板和教程示例，面向真实量产场景的边缘情况处理往往欠缺。最终代码质量把控，永远只能靠我们自己。

步骤四：让AI成为你的“长期队友”

当你发现AI某段代码写得好，可以把它收集到一个“习惯库”里。下次再生成类似代码时，把之前的片段作为参考，让AI学习你的风格。

比如你可以这样提示：

“这是我之前用过的一个读取传感器数据的函数（附上代码）。请参考这个代码风格和错误处理逻辑，生成一个读取另一个传感器的类似函数。MCU型号换成STM32F407，传感器通过SPI1连接。”

另外，如果AI给出的代码能用但不符合你的编码规范，可以要求它自动调整格式。但不要指望AI一次性生成完美代码，它需要多次迭代。就像对新手同事一样，给它反馈，它会不断改进。

实战案例：从单LED到完整系统的“5轮对话”

这里分享一个AI辅助开发的实际案例。

有一次，我需要基于STM32F103C8T6做一个简单的蓝牙遥控小车，包含以下几个模块：电机驱动（PWM控制）、蓝牙通信（UART接收指令）、LED状态指示。

传统手工开发，至少需要半天时间才能把各个驱动跑通。但通过AI辅助，我花了不到一个半小时就完成了全部代码编写和联调。整个过程用了5轮提问：

轮次	目标	提问方式
1	生成电机控制代码	“请帮我生成控制L298N电机驱动模块的STM32代码。需要两个PWM输出（PA6和PA7）控制转速，四个GPIO（PB0-PB3）控制方向……”
2	生成蓝牙解析代码	“请基于上一轮的代码，补充蓝牙UART数据处理部分。UART2接收指令，指令格式如SPD150表示速度150，DIR00表示两轮同时正转……”
3	添加LED状态指示	“请增加LED状态指示功能：收到有效指令时LED1闪烁一下；电机堵转时LED2常亮。GPIO分配……故障检测逻辑……”
4	生成中断处理和看门狗	“请优化代码：将UART接收改为中断方式；在主循环中加入IWDG看门狗喂狗，超时3秒。并提供初始化函数。”
5	代码整合与文档生成	“请将以上所有功能整合成一个完整的MDK工程代码，并在每个关键函数前添加中文注释，说明参数含义和返回内容。”

整个过程没有任何一次提问要求AI生成“全部最终代码”。每一轮的结果都能独立验证，发现问题立即回滚修正。这种从系统需求逐步拆解为模块再逐个生成的策略，大大降低了调试难度。

关于“AI写代码”的争议

有人说AI生成的代码质量差、隐蔽bug多。这话不假。但别忘了——我们写的代码不也有bug吗？

关键在于：谁来主导代码的质量把关？

如果一个工程师完全依赖AI而不具备审阅能力，那AI反而会放大缺陷。如果你的代码审查能力扎实，AI帮你生成框架和模板，你把关关键细节，效率翻倍的同时质量不降。

从另一方面讲，AI的出现也对工程师能力提出了新的要求：精准的Prompt能力、代码审查与调试能力、系统设计能力，这三者正在成为核心竞争力。工程师不再是单纯“写代码的人”，而是“指挥AI写代码的指挥官”。

哪些工具值得尝试？

我常用的AI编程工具有这几类：

1. GitHub Copilot：最成熟的代码补全工具，与IDE深度集成，能根据上下文实时生成建议，适合日常开发中的快速补全和重复性代码编写。

2. Cursor：基于VSCode构建的AI集成开发环境，支持跨文件的上下文理解，适合需要频繁调用多个模块的嵌入式项目开发。

3. Claude-Code（或Cline）：擅长“动手”，不仅能建议，还会主动执行命令、读取报错并尝试修复，适合复杂的调试和构建问题。

4. Ollama：开源本地运行平台，可在自己硬件上运行LLaMA、Mistral等模型，无需联网和订阅费用，适合对代码隐私要求高的场景。

不同的工具适用于不同的工作流，组合使用往往比单一工具更有效。在Coding场景下用Cursor或Copilot效率最高，在调试和维护场景下，Claude-Code这类动手型Agent往往更实用。

写在最后

回到开头那个读者的困惑：为什么AI生成的代码总是跑不通？

答案很可能是——我们的使用方法，还停留在“问AI”而非“指挥AI”的阶段。

AI不是魔法棒，而是一个工具。工具用对了事半功倍，用错了事倍功半。

把AI当助手而非替代者，明确自己的定位：你永远是代码的主人。

最后分享一个数据：研究表明，使用AI编程工具的开发者完成任务的速度比不使用的人快55%，完成时间总体减少20%到50%。但前提是——你有一套自己的AI协作方法论。

AI不会淘汰你，但会用AI的同行可能会。 与其焦虑，不如从今天开始，用好你手边的工具。

‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧  END  ‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧

关注我的微信公众号，回复“星球”加入知识星球，有问必答。
点击“阅读原文”查看知识星球详情，欢迎点分享、收藏、点赞、在看。