欢迎关注 youcans@xidian【嵌入式软件AI编程】专栏
【嵌入式软件AI编程】15. VS Code 插件安装 Claude Code
本专栏结合STM32项目实践，介绍嵌入式软件AI编程的实战路径。本专栏内容来自图书《嵌入式系统AI编程》，即将出版。
第03章 第一个AI协同开发项目
本章使用NUCLEO-G431RB开发板作为硬件平台，以板载LED闪烁程序为例。首先基于现有工程制定任务清单，使用Claude Code完成代码编写与审阅，通过编译、烧录和板级运行验证程序功能，并演示需求变更后的程序迭代修改；最后从项目实践中提炼通用开发流程，整理格式化提示词，并将长期适用的开发要求编写为项目开发规则。
3.2 标准化AI协同开发方法
通过前一节的LED闪烁项目，读者已经完整经历了工程分析、任务规划、代码修改、审阅确认、运行验证和需求迭代等基本环节，完成了第一个AI协同STM32项目。
为了将这些实践经验迁移到后续不同案例中，还需要把具体操作提炼为稳定、可以重复使用的方法。本节将在前述实践基础上总结AI协同开发流程，整理格式化提示词模板，并将通用要求形成开发规则，使后续任务能够按照统一方式开展，减少重复说明和随意操作。
3.2.2 整理通用提示词模板
在LED闪烁项目中，开发者先后使用提示词完成了工程分析、任务清单制定、代码修改和需求变更。虽然不同STM32案例的功能目标和工程内容各不相同，但提示词的基本结构可以保持一致。
为了使Claude Code准确理解任务，提示词可以按"角色---背景---任务要求---输出要求"四个部分组织。其中，角色和部分通用背景保持不变，工程名称、硬件平台、功能目标、文件路径和当前任务则需要根据实际案例进行替换。
下面将3.1节使用的提示词整理为四类通用模板。
- 工程分析提示词模板
工程分析提示词用于确认实现功能所需的工程基础，适用于开始编码前的工程分析阶段。本轮只分析工程，不生成代码，不修改文件。
bash
【角色】
你是一名资深嵌入式软件工程师，熟悉STM32软件开发。
【背景】
本次需要实现的功能是：[功能目标]。
当前工程基于[开发板和MCU型号]，已由STM32CubeMX生成初始化代码。
【任务要求】
读取工程中的.ioc文件、初始化代码和相关源文件，分析实现该功能所需的工程条件。
本轮只分析工程，不编写代码，不修改任何文件。
【输出要求】
1.说明开发板和MCU型号。
2.说明相关外设、端口和引脚配置。
3.说明已有初始化函数、宏定义及所在文件。
4.说明实现功能需要使用的HAL函数。
5.说明需要修改的文件和代码位置。
6.说明是否需要新增变量、函数、文件，或需要配置中断。
7.指出当前工程中可能影响功能实现的风险或注意事项。分析完成后，可将结果保存到项目分析文档中，供后续制定任务清单和修改代码时引用。
- 任务清单提示词模板
任务清单提示词用于将功能目标拆分为目标明确、可以独立验证的实现任务。
bash
【角色】
你是一名资深嵌入式软件工程师，熟悉STM32软件开发。
【背景】
本次需要实现的功能是：[功能目标]。
工程分析结果位于：@[工程分析文档路径]。
【任务要求】
根据工程分析结果，将功能目标拆分为需要新增或修改代码的实现任务。
任务应按完整功能划分，每项任务都应目标明确且可独立验证。
不要按单条语句或单个函数调用机械拆分。
编译、烧录和运行验证作为相应代码任务的验证方式，不单独列为任务。
【输出要求】
请为每项任务说明：
1.任务目标。
2.涉及文件。
3.主要修改位置。
4.实施要点。
5.验证方式。
本轮只生成任务清单，不修改代码。生成的任务清单可保存到项目规划文档中，作为后续逐项修改代码的依据。
- 代码修改提示词模板
代码修改提示词用于完成任务清单中的一项具体编码任务。代码编写阶段应按照任务清单逐项推进，每次提示词只指定一项任务。
bash
【角色】
你是一名资深嵌入式软件工程师，熟悉STM32软件开发。
【背景】
本次需要实现的功能是：[当前任务名称和目标]。
工程分析结果位于：@[工程分析文档路径]。
任务清单位于：@[任务清单文档路径]。
【任务要求】
1.只完成当前指定任务，不处理任务清单中的其他任务。
2.根据工程分析结果，在相关文件中生成代码修改。
3.保持工程原有的命名、缩进和代码组织方式。
4.将应用代码写入CubeMX用户代码区。
5.不修改.ioc文件和与当前任务无关的文件。
【输出要求】
1.在VS Code编辑区打开代码差异视图，展示代码修改差异。
2.说明修改文件和主要修改位置。
3.简要说明修改内容和实现逻辑。
4.等待开发者审阅确认后再写入工程。接受修改后，应立即进行编译、烧录和运行验证。验证通过后，再继续执行下一项任务。
- 需求变更提示词模板
当需求变更范围较小、修改位置明确时，可以直接提出变更要求，不必重新分析整个工程或重新制定任务清单。
bash
【角色】
你是一名资深嵌入式软件工程师，熟悉STM32软件开发。
【背景】
当前功能为：[原功能描述]。当前功能已实现并通过验证。
现需要将当前功能调整为：[变更后的功能描述]。
【任务要求】
1.分析本次需求变更涉及的代码位置。
2.只修改与本次变更直接相关的内容。
3.不改变其他已通过验证的功能。
4.保持原有代码结构和编程风格。
5.不修改.ioc文件和与本次需求无关的文件。
【输出要求】
1.展示修改前后的代码差异。
2.说明修改文件和修改位置。
3.说明变更前后的主要差异。
4.等待开发者审阅确认后再写入工程。如果需求变更涉及多个模块或程序结构，则要重新分析影响范围，并根据分析结果调整任务清单，再按照任务清单逐项实施。
以上模板不是固定不变的命令，而是组织提示词的基本框架。实际使用时，开发者应根据当前案例替换方括号中的内容，并删除与当前任务无关的要求。如果后续任务仍处于同一次对话中，可以省略Claude Code已经了解的角色、工程背景和项目需求。
无论提示词如何调整，都应做到背景清楚、任务具体、范围明确、输出可检查，使Claude Code能够围绕当前任务高效开展工作。
3.2.3 编写案例开发规则
项目开发规则规定了STM32基础外设驱动和简单功能项目中普遍适用、需要持续遵守的基本要求。例如，应用代码应写入用户代码区、每次只完成一项任务、修改后必须验证等要求，如果每次都写入提示词，不仅增加重复输入，也容易遗漏。
Claude Code支持使用项目级开发规则。开发者可以在工程根目录下创建CLAUDE.md文件，写入需要长期遵守的开发要求。Claude Code进入工程后会自动读取该文件，并将其作为项目指令。
CLAUDE.md不能替代具体提示词。开发者仍需在每次任务中说明功能目标、引用文档和输出要求，但不必反复说明已写入规则的通用要求。
本章作为入门阶段，开发规则不宜过多，只需围绕工程分析、任务执行、修改边界、编码与验证等基本要求进行约束。
bash
#STM32项目开发规则
##工程分析
-修改代码前，先读取.ioc文件、初始化代码和相关源文件，确认外设配置、已有接口、涉及文件和修改位置。
-工程分析应以.ioc文件和当前工程代码为依据，不依赖经验猜测，以工程实际配置为准。
##任务执行
-根据工程分析结果制定任务清单。
-任务应按完整功能拆分，做到目标明确、可独立验证。
-按照任务清单逐项修改代码，每次只处理一项任务。
-完成每项任务后，记录任务目标、主要修改和验证结果。
##修改边界
-应用代码写入CubeMX用户代码区。
-不修改.ioc文件和与当前任务无关的文件。
-不修改底层HAL和CMSIS库文件。
##编码与验证
-保持工程原有的命名方式、缩进风格和文件组织方式。
-不添加与当前任务无关的功能和复杂结构。
-代码修改应通过差异视图审阅，确认后再写入工程。
-每项修改都应经过编译、烧录和运行验证。上述规则来自LED闪烁项目的实际开发过程，与3.2.1节提炼的基本流程相对应。其中，工程分析和任务清单为代码修改提供依据，逐项执行和差异审阅用于控制修改范围，编译、烧录和运行用于确认实现结果。
建立CLAUDE.md后，后续代码修改提示词可以适当简化。例如，不必每次重复说明用户代码区、修改边界和编码风格，只需说明当前任务并引用相关文档。
bash
请参考@docs/analysis/overview.md和@docs/planning/task_list.md，按照项目开发规则完成当前任务：[任务编号及名称任务编号及名称]。
本轮只完成该项任务，不处理其他任务。
请展示代码差异，等待审阅确认。项目开发规则并非一成不变。随着案例功能增加，如果出现新的通用要求，可以补充到CLAUDE.md文件中；如果某项规则只适用于单次任务，则写入当前提示词，不必加入项目规则。入门阶段应保持CLAUDE.md内容简洁，只记录长期适用、需要反复遵守的要求。这样既能减少提示词中的重复说明，也能避免规则过多而增加初学者的学习负担。
本章小结
本章以LED闪烁程序为例，带领读者完成了第一个AI协同开发的STM32项目。从工程分析、任务规划到代码修改与审阅，再到编译烧录、运行验证和需求迭代，读者初步掌握了与Claude Code协同完成编程任务的基本方法。
版权声明：
欢迎关注 youcans@xidian【嵌入式软件AI编程】专栏
转发必须注明原文链接：
Copyright by ai4mcu@qq.com
Crated：2026-10