AI时代嵌入式开发：小白Prompt工程与上下文组织实战指南

定位：让"完全不会写代码"的人，通过精心组织的上下文和精准的Prompt，让AI替他完成嵌入式项目的开发工作。
核心假设：你已经读过《AI辅助嵌入式开发工作流 — 小白实操手册》的方法论框架，本文在此基础上，提供可直接复制的Prompt模板和上下文组织方案。

---

一、认知前提：你是架构师，不是打字员

在动笔之前，必须先扭转一个认知。

传统学习路径	AI时代路径
学C语言 → 学寄存器 → 学外设驱动 → 学算法 → 能做项目（1-2年）	理解嵌入式架构 → 学会给AI布置任务 → AI完成代码实现 → 你做验收（1-2个月）

两条路的终点都是"能做项目"，但第一条路你学会的是执行，第二条路你学会的是判断。

判断力，才是AI时代工程师的核心能力。

判断力包括：

• 架构判断：这个系统需要分成哪几个模块？
• 边界判断：这个模块负责什么，不负责什么？
• 验收判断：AI生成的代码，我怎么知道它是对的？

本文要教你的是：如何把判断力翻译成AI能理解的上下文，让AI替你完成所有执行层的工作。

---

二、最重要的原则：上下文的质量决定AI输出的质量

2.1 什么是上下文

上下文是AI在回复你时能看到的所有信息。在飞书对话里，包括：

• System Prompt（AI的默认身份设定）
• 对话历史（你之前说过的话）
• 你粘贴的代码片段
• 你描述的项目背景

上下文构建是有意识地组织这些信息，让AI每次回复都基于准确、完整、无歧义的项目理解来工作。

2.2 上下文不是越多越好

我见过的小白最常见的错误是：把一整本芯片手册粘贴给AI，指望AI能从里面找到正确答案。

结果：AI在大量无关信息里迷失，给出的代码牛头不对马嘴。

对比	示例
好的上下文	当前在调哪个模块 → 这个模块的输入输出是什么 → 上次为什么这样设计 → 本次要做什么改动
差的上下文	"帮我写一个STM32的程序"

---

三、实战Prompt模板库

下面每一个模板都经过实战验证。小白要做的是：复制 → 填入自己的信息 → 粘贴给AI → 获得可用代码。

---

模板1：项目启动 — 让AI帮你设计架构

什么时候用：当你有一个想法，但不知道从何开始时。AI会帮你把模糊的想法转化为可执行的技术方案。
预期输出：一份架构设计文档，包含模块划分、接口声明、开发顺序。

我是一个嵌入式工程师，完全不打算自己写代码，我想通过AI辅助来完成项目。

## 项目基本信息
- 项目名称：[例如：工业传感器数据采集系统]
- 芯片型号：[例如：STM32F103C8T6]
- 存储限制：Flash ≤ 64KB，RAM ≤ 20KB
- 开发板：[具体型号或连接描述]

## 核心功能需求（用日常语言描述，不用技术术语）
1. [例如：传感器每2秒采集一次温度数据]
2. [例如：数据通过串口发送到电脑显示]
3. [例如：当温度超过40度时，亮红灯报警]

## 已有材料
- 开发板：[型号]
- 传感器型号：[型号]
- 其他外设：[列出你手里有的东西]

## 我不会
- 自己写代码
- 自己调试寄存器
- 自己理解技术手册

## 我的需求
请为我完成以下工作：
1. 推荐分层架构方案（应用层/驱动层/硬件层）
2. 推荐模块划分（每个模块的名字、负责什么、对外接口）
3. 给出每个模块的头文件声明（.h格式，不需要.c实现）
4. 告诉我每个模块需要什么硬件知识，我需要去查什么资料

输出时注意：
- 不要给我代码实现，只要接口声明
- 用最简单的话解释技术概念
- 告诉我每一步该做什么，不要跳跃

---

模板2：模块开发 — 让AI为你实现具体模块

什么时候用：当你有了架构设计，需要让AI帮你一个模块一个模块地实现代码时。
预期输出：完整的、可编译的C代码文件。

请帮我实现以下嵌入式模块。我不会自己写代码，只需要你生成完整代码，我负责复制粘贴和烧录。

## 项目架构背景（由模板1生成，已确认）
[粘贴模板1输出的架构文档相关部分]

## 本次要开发的模块
- 模块名：[模块名]
- 所在层级：[应用层 / 驱动抽象层 / 硬件驱动层]
- 依赖模块：[已完成的模块列表]

## 功能需求（用自然语言描述）
[例如：接收温度传感器的数据，转换成摄氏度后返回。如果读取失败返回错误码]

## 硬件连接（非常具体）
- 芯片型号：[型号]
- 引脚连接：[例如：温度传感器数据脚接PA0，VCC接3.3V，GND接GND]
- 通信协议：[例如：单总线，或者I2C地址0x3C]

## 约束条件
- 不能使用浮点数（嵌入式资源有限）
- 中断处理函数里不能有延时
- 所有延时必须用定时器实现，不能用软件delay

## 编码规范
- 变量命名：[例如：匈牙利命名法，uint8_t前缀u8，uint16_t前缀u16]
- 缩进：[例如：Tab缩进4字符]
- 注释：[例如：每个函数前加中文功能说明]

## 验收标准（我来测试）
[例如：发送读取指令后，串口输出"温度: 25°C"，读取失败时输出"Error"]

## 请生成
1. 完整的 .h 文件（头文件，包含所有函数声明和结构体定义）
2. 完整的 .c 文件（实现代码）
3. 每50行代码加一行中文注释，说明这段代码在做什么

---

模板3：调试求助 — 当代码出错时

什么时候用：任何出错的时候。这个模板的关键是提供了AI诊断所需的所有上下文。
预期输出：问题原因分析 + 精确的修改建议。

【我的情况】（请选择或描述）
□ 编译报错（AI给了错误信息）
□ 运行结果不对（现象和预期不符）
□ 烧录后没反应（没有任何输出）

## 环境信息
- 芯片型号：[型号]
- 开发板：[型号]
- 开发环境：[例如：Keil MDK 5.38 / PlatformIO]
- AI之前生成的代码：[粘贴相关代码片段，50行以内]

## 问题描述
- 预期：[应该发生什么]
- 实际：[发生了什么]
- 首次出现时间：[例如：今天下午第一次运行就出现]

## 错误信息（如有）
[粘贴编译器的完整错误信息，或描述运行时的异常现象]

## 我之前尝试过的方法（如有）
1. [例如：重新编译，结果一样]
2. [例如：换了USB线，结果一样]

## 我的技术水平
□ 完全不懂代码，只会复制粘贴和烧录
□ 懂一点，能看懂报错信息
□ 能做一些简单修改

## 请帮我
1. 分析最可能的原因
2. 给出需要修改的代码（精确到哪一行）
3. 告诉我修改后如何验证

---

模板4：需求变更 — 当你想加新功能时

什么时候用：项目已经有基础功能，想继续扩展时。这个模板的关键是明确"不变"的部分，让AI只在指定区域工作。

## 当前项目状态
项目已完成以下模块：
| 模块名 | 状态 | 关键接口 |
|--------|------|---------|
| gpio_ctrl | ✅完成 | LED1_Init(); LED1_SetState(u8 on); |
| usart.c | ✅完成 | USART1_Init(void); |

当前main.c的业务逻辑：
[用一句话描述现在程序在做什么]

## 新增需求
[用最日常的语言描述，例如：我想加一个功能，按下板子上的USER键，LED灯的状态就切换一次]

## 我对现有代码的要求
- 不要改动已有的gpio_ctrl和usart模块
- 新代码必须放在独立的.c/.h文件里
- 新功能通过调用已有模块的接口来实现

## 请生成
1. 新模块的头文件（.h）
2. 新模块的实现（.c）
3. 在main.c中需要做的修改（精确说明）

---

模板5：代码审查 — 让AI替你把关

什么时候用：AI给的代码你看不懂，但又必须决定是否烧录时。这个模板让AI用初学者能理解的语言解释风险。

请审查以下嵌入式代码，我是嵌入式开发的完全初学者，请用最简单的话解释问题。

【我的背景】
- 我不自己写代码
- 我能看懂简单的if/else和for循环
- 我负责把AI给的代码复制到Keil里烧录和测试

【代码来源】
- AI根据我的需求生成的
- 我还没有测试过，想先让AI检查明显错误

【我担心的问题】（可多选）
□ 会不会把芯片烧坏
□ 会不会有内存泄漏导致程序崩溃
□ 边界条件会不会出错（例如数组越界）
□ 中断处理安不安全

## 代码如下
[粘贴代码，200行以内]

## 请重点检查
1. 最可能让我烧板子的问题（高优先级）
2. 最可能让程序死机或崩溃的问题
3. 我在测试时如何验证这些风险是否存在

---

模板6：通信协议调试 — 当串口通信出问题

什么时候用：串口不工作、数据乱码、数据丢失时使用。

## 当前项目状态
- 已完成模块：usart.c/h（USART1，115200，8N1）
- 当前问题：串口通信不正常

## 环境
- 芯片：STM32F103C8T6
- 连接：PA9=USART1_TX，PA10=USART1_RX，接CH340 USB转串口模块
- 波特率：115200
- 串口助手设置：115200，8N1，无流控

## 问题表现（请选择）
□ 串口助手收不到任何数据
□ 收到的数据是乱码
□ 数据不完整，总是丢最后几个字节
□ 第一次发数据能收到，之后就没有了

## 已确认的事实
□ 用示波器/逻辑分析仪看过TX引脚：有信号输出
□ 串口助手波特率已确认和代码一致
□ USB转串口模块在其他设备上测试过：是好的
□ 接线已确认：TX接RX，RX接TX，GND共地

## 请帮我
1. 列出可能导致这个问题的所有原因（按可能性排序）
2. 给出排查顺序（先查什么后查什么）
3. 每一步的排查方法和预期结果
4. 如果确认某一步排查发现问题，给出修复代码

---

模板7：定时器和中断配置 — 当需要精确时序控制

什么时候用：需要精确延时、PWM输出、定时采集数据时使用。

## 项目背景
我需要一个精确的定时功能，但不知道怎么描述需求。

## 我想实现的功能
[例如：我想让LED每500ms闪烁一次，但要精确，不能用delay函数影响其他任务]

## 环境
- 芯片：STM32F103C8T6
- 已有模块：gpio_ctrl.c/h（LED控制）

## 约束
- 系统有一个主循环正在运行，不能在定时器里阻塞
- 定时器中断里不能做耗时操作（不能打印，不能用浮点运算）
- 定时精度要求：[例如：±10ms以内可接受]

## 请帮我
1. 推荐使用哪个定时器（TIM1/TIM2/TIM3...）
2. 推荐的中断优先级设置
3. 给出定时器初始化代码（.c文件）
4. 给出在main.c中启动定时器的代码
5. 告诉我如何修改LED闪烁间隔（修改哪个参数）

---

模板8：多模块集成 — 当需要把几个模块合并

什么时候用：多个模块各自测试通过后，需要合并到main.c里统一运行时使用。

## 当前项目状态
已完成的模块（每个模块均可独立编译运行）：
| 模块 | 源文件 | 头文件 | 关键接口 |
|------|--------|--------|---------|
| GPIO控制 | gpio.c/h | gpio.h | LED1_Init(); LED1_On(); LED1_Off(); |
| 串口 | usart.c/h | usart.h | USART1_Init(); USART1_SendStr(char*); |
| 定时器 | timer.c/h | timer.h | Timer_Init(); Timer_DelayMs(uint32_t); |
| 温湿度 | dht11.c/h | dht11.h | DHT11_Read(DHT11_Data_t*); |

## 本次任务
请帮我设计main.c，将以上模块集成起来，实现以下业务逻辑：
[用自然语言描述业务逻辑]

## 约束
- 不能修改已有的四个模块的.c和.h文件
- 所有业务逻辑写在main.c里，或新增一个app.c/app.h
- 主循环采用轮询方式，不要用RTOS

## 请生成
1. app.c/h（业务逻辑层，如果需要）
2. main.c（集成代码，注释说明每个部分在做什么）
3. 集成后的编译和运行预期说明

---

模板9：外设驱动选择 — 当不知道该用哪个外设

什么时候用：面对新需求，不确定该用哪种通信方式或硬件模块时使用。

## 我的需求
[用最日常的语言描述，例如：我想用开发板和电脑通信，在电脑上能看到数据]

## 我的约束
- 芯片：STM32F103C8T6
- 电脑操作系统：Windows
- 我没有示波器/逻辑分析仪，只有万用表
- 我希望接线简单，不要太多线

## 请帮我分析
1. 推荐哪种通信方式（USART/USB/I2C/SPI），为什么
2. 需要哪些硬件模块（CH340/FT232/CP2102等）
3. 电脑端需要安装什么软件
4. 大致的接线图（文字描述）
5. 给我一个最简单的测试方案

## 我的技术水平
□ 完全不懂通信协议
□ 知道USART大概是什么，但没调通过
□ 调通过USART但遇到问题

---

模板10：代码优化请求 — 当代码能跑但不够好

什么时候用：代码功能正常，但存在性能、内存或可读性问题需要优化时使用。

## 当前代码状态
- 模块名：[模块名]
- 现状：[描述代码现在在做什么]
- 目标：[描述想要达到的效果]

## 我希望改进的方面（可多选）
□ 执行速度：现在[XX]ms，希望降到[XX]ms以内
□ 代码大小：Flash占用超标，希望减少[XX]字节
□ RAM占用：峰值RAM超过[XX]字节，需要优化
□ 可读性：代码不是我写的，我想加注释方便以后维护
□ 可扩展性：以后可能加[XX]功能，现在的架构支持吗

## 约束条件
- 不能改变模块的对外接口
- 不能改变硬件连接
- 优化后必须保持功能不变

## 请生成
1. 优化后的完整代码
2. 说明每个优化点做了什么，为什么有效
3. 如何验证优化后功能没有退化

---

模板11：状态机设计 — 当你需要处理复杂的按键或事件

什么时候用：需要处理多种状态切换、多条件判断的复杂交互逻辑时使用。

## 需求描述
我想实现一个[功能，例如：按键控制LED的三种模式切换]

具体要求：
- 短按（<500ms）：切换开/关
- 长按（>=2秒）：进入配置模式
- 在配置模式下，短按切换选项，长按确认并退出

## 当前环境
- 芯片：STM32F103C8T6
- 按键：板载USER键（PC13，低电平有效，内部上拉）
- LED：PA5（低电平点亮）

## 请帮我
1. 用状态图描述这个逻辑（文字版状态机）
2. 给出状态定义（每个状态的名字和进入条件）
3. 给出状态转移表（当前状态+事件→下一状态）
4. 实现这个状态机的代码（.c/.h）
5. 说明如何测试每种切换路径

---

四、上下文组织方案：从零到完整的四步法

有了Prompt模板，你还需要知道什么时候该给AI什么信息。这就是上下文组织。

---

4.1 第一步：开局 — 建立项目语境（一次性）

第一次和AI讨论你的项目时，发送：

【我的项目】
- 名称：[项目名称]
- 芯片：[型号]
- 目标：[用一句话说你想做什么]

【我有什么】
- 硬件：[开发板型号、传感器型号等]
- 工具：[Keil/Arduino/PlatformIO等]

【我的限制】
- 我完全不写代码
- 我只有基础硬件知识（知道GPIO是输入输出、知道串口能发数据）
- 我能做的：复制代码、烧录、观察现象

【本次任务】
[具体描述你想让AI帮我做什么]

请先确认你理解了我的需求，如果有不清楚的地方，请先问我，不要直接开始写代码。

为什么先让AI确认：AI如果理解错了，你浪费的是AI的时间。如果等AI输出了1000行代码你才发现方向错了，损失更大。

---

4.2 第二步：分模块开发 — 一次只做一个模块

错误做法	正确做法
“我想做一个温度监测系统，包含传感器读取、OLED显示、阈值报警、串口打印，你能一次都给我吗？”	第一轮：先做传感器读取模块 第二轮：再做显示模块 第三轮：再加报警功能

为什么必须分开：

• AI同时处理太多需求，容易出现接口对不上的问题
• 分开后，每个模块都能独立测试，你更容易定位问题
• 模块边界清晰，后续加功能时不乱

---

4.3 第三步：验收 — 学会说"通过了"或"不对"

每次AI生成代码后，你都要做验收。验收不需要你懂代码，只需要你按步骤操作：

【模块名称】
[模块名]

【测试步骤】
1. 我把代码复制到了[文件名].c里
2. 我点击了编译，结果：[成功/有报错]
3. 我烧录到了开发板
4. 我做了[具体操作，例如：给传感器通电，打开串口助手]
5. 我观察到的现象：[描述你看到的结果]

【结论】
□ 通过：现象符合预期
□ 不通过：[描述哪里不对]

【错误信息】（如有）
[粘贴任何报错信息]

把这份报告发给AI，AI会根据它调整下一轮输出。

---

4.4 第四步：积累 — 建立自己的上下文笔记本

每次项目有进展，都要更新一份"项目状态文档"。这是你和AI之间的桥梁，让AI每次都知道项目当前处于什么状态。

为什么必须这样做：AI没有记忆。每次开新对话，AI不知道你之前做了什么。这份文档就是你给AI的"续命丹"。

保存在飞书文档里，每次开始新对话时发给AI：

【项目名称】：[名称]
【芯片型号】：[型号]
【最后更新】：[日期]

## 已完成模块

| 模块名 | 状态 | 关键接口 | 测试结果 |
|--------|------|---------|---------|
| gpio_ctrl | ✅完成 | LED1_Init(); LED1_SetState(u8 on); | 通过 |
| usart | ✅完成 | USART1_Init(void); | 通过 |

## 进行中
- 模块：[名称]，正在[具体在做什么]

## 未解决问题
1. [问题描述]：AI分析原因[原因]，已尝试[方法]

## 下一步
[下一步要做什么]

## 本次新任务
[具体描述这次想让AI帮什么]

---

五、真实案例：从小白到跑通

---

案例1：小明的温度监测系统（4小时完成）

背景：医学影像专业研究生，完全不会C语言，有一块STM32开发板，想做实验室温度监测。

阶段	操作	结果
第一步	用模板1请求架构设计	AI给出：sensor_dht11 → sensor_manager → alarm 分层方案
第二步	用模板2实现传感器模块	复制 → 编译（0 errors）→ 烧录 → 串口看到温度输出 ✅
第三步	用模板4加报警功能	合并代码 → 编译 → 烧录 → 手捏传感器模拟高温 → LED亮了 ✅

总耗时：4小时。代码量：0行（全是AI写的）。

---

案例2：小红的OLED菜单系统（2天完成）

背景：本科生，想用OLED屏幕做可交互菜单。有点C语言基础，但读写都困难。

时间	事件	教训
第一天上午	用模板1设计架构	AI给出menu/oled/key分层方案
第一天下午	编译报错"undefined symbol SSD1306_Init"	—
第一天傍晚	用模板3求助	AI发现缺少ssd1306.c文件，补全后通过
第二天	逐个集成menu和key模块	每天完成一个模块，逐步测试，最终跑通

关键教训：用"验收报告"模板准确描述现象，让AI能够精准定位问题。

---

六、避坑指南：小白最常犯的5个错误

---

错误1：需求描述模糊

❌ 错误示范："帮我写一个STM32的程序"

✅ 正确做法：用5W1H格式描述：

• What：读取温度传感器数据
• Which：DS18B20
• Where：接PB12引脚
• When：每2秒一次
• How：通过单总线协议
• Error：读取失败返回错误码

---

错误2：一次给太多需求

❌ 错误示范：一次性描述10个功能，希望AI一次全给

✅ 正确做法：分阶段，每个阶段只做一个模块。AI不是万能的，一次给太多需求，输出的代码接口会互相打架。

---

错误3：不给硬件信息

❌ 错误示范："帮我写一个I2C驱动"

✅ 正确做法："帮我写一个I2C驱动，芯片是STM32F103C8T6，SCL接PB6，SDA接PB7，目标是读写OLED屏幕，地址是0x3C。"

---

错误4：看不懂报错就放弃

❌ 错误示范："有报错，看不懂，算了不做了"

✅ 正确做法：把报错信息原封不动复制给AI，问：“这个报错是什么意思？我该怎么处理？”

---

错误5：不测试就烧录

❌ 错误示范："代码好长，看起来差不多，烧进去试试"

✅ 正确做法：

1. 先让AI做代码审查（模板5）
2. 先在仿真器里跑一遍
3. 观察串口输出的每一条信息，确认逻辑符合预期

---

七、硬件描述专项：让AI准确理解你的硬件

---

7.1 为什么硬件描述是小白最大的短板

小白的代码由AI生成，但硬件信息必须由人提供。AI无法替你感知开发板上的引脚定义、传感器型号、接线方式。这些信息一旦描述错误，AI生成的代码再漂亮也是废代码。

---

7.2 硬件描述的四要素

每个外设的描述必须包含以下四个要素，缺一不可：

要素	说明	示例
型号+封装	精确到具体型号	DS18B20（TO-92封装），STM32F103C8T6
引脚连接	所有GPIO的连接方式	DQ → PB12（开漏），VCC → 3.3V
通信协议	总线类型和关键参数	单总线、I2C地址0x3C、USART 115200 8N1
电源和地线	电压等级和共地要求	全部3.3V供电，所有GND共地

---

7.3 常用传感器快速描述模板

DS18B20温度传感器

型号：DS18B20（TO-92封装）
连接：DQ → PB12（开漏模式，外接4.7kΩ上拉至3.3V）
     VCC → 3.3V，GND → GND
协议：单总线（1-Wire）
供电：外接供电模式（不是寄生供电）

I2C OLED屏幕（SSD1306）

型号：0.96寸 OLED，SSD1306驱动，I2C接口
连接：SCL → PB6，SDA → PB7，VCC → 3.3V，GND → GND
协议：I2C，设备地址0x3C（7位地址）
屏幕规格：128×64像素

HC-05蓝牙串口模块

型号：HC-05（从机模式）
连接：TX → PA10（USART1_RX），RX → PA9（USART1_TX）
     VCC → 5V，GND → GND
协议：USART，波特率默认9600
注意：PA10是5V容忍引脚，可直接接蓝牙模块的TX

SG90舵机

型号：SG90 9g舵机
连接：棕色线 → GND，红色线 → 5V（独立供电）
     橙色线（PWM）→ PA8（TIM1_CH1）
协议：PWM，周期20ms，占空比0.5ms-2.5ms对应0-180度
注意：舵机转动时电流可达500mA，必须独立供电

---

7.4 小白硬件检查清单（烧录前必查）

□ 芯片具体型号（精确到C8T6/RBT6，不是只说F103）
□ 所有外设的供电电压（3.3V还是5V）
□ 所有GPIO引脚编号（PA0-PA15, PB0-PB15, PC0-PC15）
□ 哪些引脚已经被占用（调试口SWD、晶振等）
□ 通信协议类型（UART/I2C/SPI/单总线）
□ 设备地址或设备ID
□ 关键参数（波特率、I2C地址、帧格式等）

---

八、跨Session上下文持久化：让AI记住你的整个项目

---

8.1 为什么必须做上下文持久化

AI对话没有记忆。每次开始新的对话，AI是空白的。每次都重新解释项目背景会：浪费时间、信息丢失、代码接口互相冲突。

---

8.2 项目状态文档的标准格式

每次项目有重大进展，就更新一次这个文档：

# 【项目名称】状态文档
> 此文档是项目记忆的核心。每次开新对话时，将本文档的全部内容粘贴给AI。

## 基本信息
- 项目名称：[名称]
- 芯片型号：[型号]
- 最后更新：[日期]
- 当前阶段：[架构设计/模块开发/系统集成/调试阶段]

## 硬件清单

| 外设 | 型号 | 连接引脚 | 通信协议 | 备注 |
|------|------|---------|---------|------|
| 温度传感器 | DS18B20 | PB12 | 单总线 | 外接4.7kΩ上拉 |
| OLED屏幕 | SSD1306 | PB6=SCL, PB7=SDA | I2C，地址0x3C | 3.3V供电 |

## 模块状态

### ✅ 已完成并测试通过

| 模块名 | 文件 | 关键接口 | 测试方法 | 测试日期 |
|--------|------|---------|---------|---------|
| GPIO控制 | gpio.c/h | LED1_Init/On/Off | 观察LED亮灭 | 2026-03-20 |

### 🔧 开发中

| 模块名 | 当前状态 | 遇到的问题 |
|--------|---------|-----------|
| DHT11驱动 | 已生成代码，测试发现读取成功率只有60% | 可能是时序问题 |

## 最新项目状态（[日期]）
[粘贴最新一次对话结束时AI给出的总结]

## 未解决的问题
1. [问题描述]：已尝试[方法]，下一步[计划]

## 下一步计划
1. [优先级最高的任务]
2. [次要任务]

## 本次新对话的目标
[具体描述想让AI帮什么]

---

8.3 什么时候必须更新状态文档

操作	是否更新
完成一个模块并通过测试	✅ 更新模块状态
发现新问题并有了解决方案	✅ 更新"未解决问题"章节
改变硬件连接	✅ 更新"硬件清单"章节
调整模块接口	✅ 更新"架构设计"章节
正在调试中还没解决	❌ 保持原样，等解决了再更新
临时测试用的代码片段	❌ 测试完成后删除

---

九、嵌入式排错索引：常见问题的系统化排查

---

9.1 排错的核心思维：分层定位

嵌入式问题按层次分为四类，排查时要从上往下逐层定位：

层次	内容	排查优先级
第一层	硬件层（板子本身有没有问题）	优先排查
第二层	驱动层（外设初始化和通信是否正常）	其次
第三层	中间件层（环形缓冲区、协议解析是否正常）	再次
第四层	应用层（业务逻辑是否符合预期）	最后

---

9.2 症状索引：按现象快速查找

症状A：编译报错

错误类型	最可能原因	第一步排查
undefined symbol XXX	缺少.c文件或函数名拼写错误	检查文件是否加入Keil工程
undefined reference to XXX	.c文件没编译，或声明和定义不一致	确认.h声明和.c定义完全一致
implicit declaration of function	头文件没包含	在.c文件顶部加#include
cannot open source input file	路径错误或文件被删除	检查路径是否包含中文或空格

症状B：烧录后没有任何反应

排查顺序（按成本从低到高）：

1. 检查BOOT引脚设置：BOOT0是否接地（正常运行模式）
2. 检查供电：用万用表测量芯片VCC和GND之间是否有3.3V
3. 检查复位电路：NRST引脚是否被意外拉低
4. 最小系统测试：换成纯延时翻转LED的程序，看是否能跑

症状C：串口输出乱码

检查项	方法	如果不对
波特率	确认代码和串口助手都是115200	改成一致
数据位/停止位/校验	USART_InitStructure里确认是8N1	改成8N1
晶振频率	确认HSE_VALUE=8MHz	修改SystemClock_Config
电平不匹配	测量TX/RX电压	加电平转换

症状D：程序跑一段时间后死机

可能原因	排查方法
数组越界	在怀疑越界的地方加串口打印，看索引是否超限
栈溢出	把大数组改成static或全局变量
看门狗复位	增加喂狗频率，或临时关闭看门狗

---

十、芯片家族场景化指南：不是所有芯片都一样

---

STM32系列（最常用，适合学习）

优点	缺点	小白友好型号
资料最丰富，社区最大，AI训练数据充足	环境配置复杂，Keil需要license	STM32F103C8T6（性价比最高）

使用AI时的特别注意事项：

1. 必须在prompt里明确写清楚具体型号（F103不是F401）
2. F103用标准库或HAL库，F4/F7用HAL或LL，不要混用
3. GPIO开漏输出需要外接上拉电阻（I2C的SCL/SDA已有内部上拉）

---

ESP32系列（最适合WiFi/蓝牙项目）

优点	缺点	适合做的项目
内置WiFi和蓝牙，原生USB，生态好	功耗比STM32高，实时性略差	联网数据采集、手机APP控制、蓝牙透传

使用AI时的特别注意事项：

1. ESP32用Arduino框架比用ESP-IDF对小白更友好
2. 开发环境用PlatformIO比Arduino IDE更好
3. 引脚编号用Board Pin编号（例如：板子上的D21对应GPIO21）
4. 同一引脚可能同时是GPIO和ADC输入，需要在代码里配置模式

---

Arduino系列（最快上手，但有限制）

优点	缺点	适合做的项目
生态最丰富，库最多，接线最简单	性能最弱，不适合做复杂项目	纯传感器读取、简单LED和电机控制、创客类项目

不适合做的项目：

• 需要精确时序（DMA、多级中断）
• 需要低功耗（Bootloader本身耗电）
• 需要处理音频或图像

---

十一、无代码能力的验收方法：如何判断AI给的代码是对的

---

11.1 验收的本质：你不理解代码，但你理解现实世界的预期

验收不需要你理解代码，只需要你建立现实世界现象和预期之间的映射。

验收的核心问题只有三个：

1. 编译通过了吗？ → 0 errors，0 warnings
2. 烧录成功了吗？ → 没有任何报错信息
3. 运行符合预期吗？ → 观察到的现象 = 我描述过的预期

---

11.2 分层验收清单

第一层：编译层（必须100%通过）

检查项	标准
编译输出	0 Errors
Warnings	可以有一些，但不要有类型转换相关的Warning
文件大小	STM32F103的代码应该在4KB-64KB之间，太小说明可能没编译进去

第二层：烧录层（确认芯片能跑起来）

检查项	标准
芯片识别	烧录软件能识别到芯片，显示芯片ID正确
烧录过程	无报错
芯片重启	烧录后芯片自动重启

第三层：功能层（最核心，需要系统化测试）

## 【模块名称】功能验收报告
测试日期：[日期]

### 测试项目

#### 测试项1：[功能名称]
- 操作：[具体操作步骤]
- 预期：[应该看到什么]
- 实际结果：✅ / ❌ / ⚠️

### 边界条件测试

#### 测试项：最低工作电压
- 操作：降压到2.8V
- 预期：系统继续运行
- 实际结果：[结果]

### 总结
- 通过率：X/Y项通过
- 最严重问题：[描述]
- 是否可以集成：[是/否]

---

11.3 边界条件测试的最小集合

不管什么模块，以下5个边界条件都必须测：

序号	条件类型	测试内容
1	正常条件	参数完全正常时的表现
2	最小值边界	参数为0或最小有效值时的表现
3	最大值边界	参数为最大值时的表现
4	异常条件	参数越界或硬件异常时的表现
5	连续运行	同样操作重复100次，表现是否一致

---

十二、进阶Prompt工程心法：让AI不再"一答就偏"

---

12.1 理解AI如何处理模糊指令

AI生成代码时，实际上是在做概率匹配：它根据你描述的需求，在训练数据中找最相似的场景，然后生成对应的代码。

这意味着：

• 需求描述越像训练数据中的常见场景 → AI输出越准确
• 需求描述越偏离常见场景 → AI越容易"幻觉"（编造一个看起来对但实际错的代码）

---

12.2 让AI"说人话"的技巧

技巧1：加一个角色设定

❌ "帮我写一个STM32的I2C驱动"

✅ "我是一个完全不会写代码的嵌入式初学者。请帮我写一个I2C驱动，
   解释时要像教小学生一样，每个技术术语都要解释。
   例如你说'开漏输出'，要解释：开漏输出是一种GPIO模式，
   特点是芯片引脚只能拉低电平，不能主动拉高，
   需要外部接上拉电阻。"

技巧2：明确禁止某些输出格式

✅ "请用以下格式解释这段代码：
   1. 第一行（核心功能）：这段代码做了[一句话描述]
   2. 第三到五行（工作原理）：[用生活中的例子打比方解释]
   3. 如果有问题（高亮）：⚠️ 这里有一个潜在风险：[描述]
   不要超过200字。"

技巧3：要求AI先提问再行动

✅ "在开始写代码之前，请先问我以下5个问题：
   1. 芯片型号是什么？
   2. 引脚连接是什么？
   3. 有什么特殊约束？
   4. 预期如何验证？
   5. 如果出现问题，你希望我怎么描述给你？
   问完这5个问题并得到我的回答后，再开始写代码。"

---

12.3 减少AI幻觉的Prompt策略

策略1：要求AI说明假设

请在生成代码之前，先列出你做了哪些假设：
- 假设芯片型号是[XXX]，因为[你的描述里有YYY]
- 假设通信协议是[XXX]，因为[YYY]
如果这些假设有任何一个不对，请立即告诉我，不要继续生成代码。

策略2：分步骤生成，每步验证

第一步：请只告诉我应该选哪个传感器型号，不要给代码。我确认后，再进入第二步。
第二步：请只告诉我GPIO应该怎么配置（用文字描述），不要给完整代码。我确认后，再进入第三步。
第三步：请给我初始化代码。

策略3：要求AI给出参考来源

你给出的代码里，如果有引用了某本手册或某个标准的内容，
请在代码注释里标明来自哪里，例如：
// 参考：STM32F1xx官方参考手册 RM0008，第10.3.2节
这样如果代码有问题，我可以去查原始文档。

---

十三、完整项目全流程：从空白到交付

---

项目A：土壤湿度监测 + 自动灌溉（3天）

背景：农业大学学生小李，想做一个盆栽自动浇水系统。

天数	内容	使用的模板
第一天	需求确认 + 架构设计	模板1
第二天上午	传感器模块开发	模板2
第二天天下午	水泵控制模块	模板2
第二天傍晚	系统集成	模板8
第三天	调参 + 边界测试	模板3

最终交付：功能正常，代码全是AI写的。

---

项目B：蓝牙遥控小车（5天）

背景：中学生小张，想用手机蓝牙控制一辆4轮小车。

踩坑实录：

天数	问题	解决方案
第二天	芯片给L298N PWM输出后系统重启	电机启动电流过大拉低供电电压 → STM32和电机分开供电
第三天	蓝牙连接成功但收不到数据	HC-05默认波特率9600，代码里设的是115200 → 统一为9600
第四天	小车走"画龙"	加入简单差速校正算法

最终交付：手机蓝牙控制，前进/后退/左右转正常，行驶基本走直线。

---

项目C：宿舍智能门禁（7天，含云服务对接）

背景：研究生小王，想做一个门禁系统，RFID刷卡或密码开门，开门记录云端上传。

天数	内容	使用的模板
第一-二天	RFID刷卡识别	模板1+2
第三-四天	4×4矩阵键盘密码输入	模板11（状态机）
第五天	多因素验证（刷卡+密码）	模板4
第六天	远程通知（ESP8266 WiFi）	模板9
第七天	系统集成 + 掉电状态保存	模板8

最终交付：RFID+密码双因素门禁，开门记录云端上传，手机可查。

---

十四、结论：AI是杠杆，判断力是支点

经过本文的完整内容，我们可以看到AI辅助嵌入式开发的完整地图：

层次	工具（AI做什么）	人的判断（人做什么）
执行层	生成代码	判断模块划分
解释层	解释代码	判断是否符合现实预期
调试层	定位问题根因	判断测试结果是否可接受
优化层	优化性能	判断优化方向是否值得
持久化层	—	维护项目状态文档

最终目标：让你在AI的帮助下，用判断力而非代码力完成嵌入式项目，并在项目过程中逐步建立起真正的工程直觉。

---

本文是《AI辅助嵌入式开发工作流》的方法层扩展，聚焦于Prompt模板的实战细节、跨Session管理、排错索引和芯片场景化指导。与《方法论对话》一文共同构成"道-法-术"三层体系中的"术"层文档。

文档整理：OpenClaw | 2026-03-28