🤖 嵌入式工程师学AI：用Claude Code三天，我发现了什么
本文最后更新于 2026年4月3日 下午
嵌入式工程师学AI：用Claude Code三天，我发现了什么
前言
接上篇《为什么嵌入式工程师要学AI》，这篇文章记录我实际使用 Claude Code 三天的感受。
不是软文，不吹不黑，有一说一。
Claude Code 是什么？
简单说，这是一个能在你的终端里跟你对话、帮你写代码的 AI 工具。跟普通的聊天机器人不一样，Claude Code 能：
- 读写你的文件系统
- 运行 terminal 命令
- 执行 git 操作
- 浏览你指定的技术文档
它不是回答完就结束了——它真的能帮你把活干了。
我的安装过程
安装过程其实不复杂，在 Ubuntu 22.04 上：
added 3 packages in 2s
2 packages are looking for funding
run npm fund for details
装完之后，在项目目录下运行 就能启动。
但第一天我就遇到了一个问题：默认的模型是 Claude 3.7 Sonnet，需要你有 API Key。我用的是 Anthropic 的订阅服务，第一天搞了一个小时才把订阅和 API Key 配置好。
建议： 如果你之前没用过 Claude，先在网页版上体验一下，了解它的能力边界，再来决定要不要用 CLI 版本。
我主要用它做什么？
1. 写代码
这是最核心的功能。我让它帮我写了几类代码：
STM32 GPIO 初始化：
我让它写了一个用 HAL 库配置 STM32F4 GPIO 的代码，描述需求的时候我只说了配置 PC13 为上拉输入，用于按键检测。
结果： 代码准确，可以直接用。但这个例子太简单了，体现不出 AI 的真实能力。
更复杂的场景：FreeRTOS 任务间通信
这个我让它写了一个用队列进行任务间通信的框架。代码结构是对的，但参数配置需要我自己调整——队列长度、任务优先级这些东西，AI 不知道你的实际需求是什么。
结论： AI 写代码的能力，取决于你对要写的东西了解多深。你了解得越清楚，给 AI 的指令就越精准，AI 的输出质量就越高。
2. 查文档
这个是意外惊喜。
嵌入式开发经常要翻手册。以前我的流程是：
- 在浏览器里搜索关键词
- 找到 ST 官方手册的 PDF
- 打开 PDF，搜索寄存器定义
- 找到需要的信息
现在我直接问 Claude Code：STM32F4 的 I2C 外设支持哪些速度模式？，它能直接回答，不需要我去翻手册。
限制： Claude Code 的知识有截止日期，它不知道最新的芯片型号。但对 STM32F1/F4、ESP32 这些经典芯片，它掌握的信息已经足够用了。
3. 写 README 和技术文档
这个是 AI 的隐藏强项。
嵌入式项目的 README 一般要写：功能描述、硬件需求、引脚定义、使用步骤。让我自己写，我每次都拖延。但让 AI 帮我生成一个初稿，我再根据自己的实际情况改，效率高很多。
4. 辅助调试
这个我还在探索。目前试过让它帮我分析一段 UART 接收不到的代码，它确实能找到几个明显的逻辑问题。但实际的硬件调试，还是得靠示波器和经验。
哪些地方踩坑了？
❌ 坑1：AI 不知道你的具体硬件配置
我第一次让它写 SPI 初始化代码，它生成的代码跟我实际用的 SPI 时钟频率不匹配。我花了半小时才定位到是 AI 的问题，而不是我的硬件问题。
经验：AI 给的代码，所有参数都要核对。
❌ 坑2：上下文窗口限制
项目大了之后，AI 会忘记之前的代码。特别是嵌入式项目，一个芯片有好几个外设的驱动文件，AI 可能同时处理不了这么多上下文。
经验：每次只让 AI 处理一个具体文件或一个具体问题，不要一次给它太多信息。
❌ 坑3：中文理解有时不准
有些嵌入式相关的专业术语，用中文描述给 AI，它理解会有偏差。比如上升沿触发、开漏输出这些术语，我用英文描述 AI 的反馈质量明显更好。
经验：跟 AI 描述技术问题时，尽量用英文术语。
❌ 坑4：配置环节容易出问题
我第一天折腾了很久才把 Claude Code 跟我的项目目录正确配置好。过程中遇到了权限问题、环境变量问题、Git 忽略文件问题。AI 虽然能帮你解决问题，但它解决问题的过程本身也需要你花时间。
经验：预留至少半天时间来配置和熟悉工具，不要期望五分钟上手。
用了三天，我的结论
有用，但别神话它。
AI 是杠杆，它放大你的能力，但不会凭空给你能力。
- 你懂嵌入式，它能帮你加速；
- 你不懂，它给你的是一堆你无法判断对错的代码；
- 你懂 AI 工具的使用技巧，它效率更高；
- 你不会提问，AI 的回答质量也很差。
对嵌入式工程师来说，AI 工具最适合的场景：
- 写有明确需求的驱动代码框架
- 查手册和参考文档
- 写技术文档和 README
- 代码审查，发现明显的逻辑问题
不太适合的场景：
- 完全没有思路的复杂算法设计
- 硬件相关的调试（示波器还是得自己看）
- 最新的芯片和框架（AI 知识有截止日期）
三天使用数据
为了对自己诚实，我记录了一下这三天用 AI 工具的情况：
- 总交互次数：约 40 次
- 生成的代码片段：约 25 个
- 其中直接可用的：约 8 个（32%）
- 需要修改后才能用的：约 12 个（48%）
- 完全不能用或方向错误的：约 5 个（20%）
结论：差不多 1/3 的输出可以直接用，这已经比我预期好了。
下一步计划
接下来我要试试：
- 用 AI 帮我读芯片手册的关键章节——而不是让它替我写代码，是让它帮我提炼手册里的关键信息
- 用 AI 辅助调试一个 I2C 协议 bug——这个问题我之前花了3天才解决，想看看 AI 能不能帮我缩短
- 研究 Claude Code 的 MCP 能力——Model Context Protocol 看起来能让 AI 直接操作外设，这个如果能用起来，对嵌入式开发的价值会更大
总结
三天用下来，我的感受是：这个工具值得学，但需要时间适应。
不是装上就能提效的工具，而是需要你花时间理解它的能力边界、调整自己的使用方法。一旦你跟它磨合好了，它确实能帮你省时间。
但前提是：你得先花时间。
《嵌入式工程师学AI》系列会持续更新，欢迎追更。下一篇文章，我会记录用 AI 读芯片手册的体验。