在物联网固件开发中用claude code生成低功耗算法的能耗偏差

一、核心结论：AI生成的代码在能耗表现上存在系统性偏差

先给出最直接的结论：在不做特殊提示词优化的情况下，Claude Code（Claude 3.5 Sonnet / Claude 4 Opus，测试时间为2025年4月-6月）生成的嵌入式C代码，在相同功能逻辑下，实测功耗比人工优化的版本平均高出40%-180%。 这不是随机波动，而是可以被复现、被分类、被针对性修正的系统性偏差。

我把这个偏差称为“AI能耗偏差”（AI-Induced Energy Deviation, AIED），并总结了它最集中的五个表现形式：

第一，时钟门控缺失或错误。 AI生成的代码倾向于在初始化时一次性使能所有用到的外设时钟，但在进入低功耗模式前没有按正确顺序关断，或者遗漏了某些外设的时钟域。

第二，睡眠模式选择保守。 在执行条件判断后，AI倾向于让MCU停留在Run模式等待，而不是立即调度进入Sleep或Stop模式，因为逻辑上“等待”不违反功能设计，但它不知道这20ms的等待意味着多消耗几十微安时的电量。

第三，中断嵌套处理粗糙。 生成的中断服务函数通常只完成功能逻辑，没有考虑中断退出时的功耗状态恢复，也没有对嵌套中断的优先级做功耗优化排序。

第四，DMA与轮询的选择偏差。 对于周期性数据搬移任务，AI更倾向于生成轮询代码而非DMA配置，这符合通用编程习惯，但在低功耗场景下，轮询意味着CPU无法进入睡眠。

第五，编译器优化选项的匹配盲区。 AI生成的代码结构有时会抑制-Os或-Oz优化等级的效果，例如不必要的volatile修饰或数据对齐方式不当。

这五个问题不是Claude Code“能力不足”，而是训练数据的偏斜，互联网上的代码样本绝大部分不关注能耗，尤其是嵌入式底层代码的公开示例，多数是功能演示性质的最小实现，几乎没有功耗优化的影子。

二、实验方法：如何量化“能耗偏差”

在展开详细结论之前，先交代实验的边界条件。这部分看似枯燥，但如果不透明化实验平台，后面所有的数据都将失去参照意义。

2.1 硬件平台

我选择了三款不同架构的MCU，覆盖主流低功耗物联网应用：

选择多平台的理由是：排除单一硬件平台的偶然性。 如果偏差只在nRF上出现，那可能是SDK或工具链的问题；如果在三款芯片上表现出一致的趋势，那问题的根源确实在AI生成的代码逻辑本身。

2.2 功耗测量工具链

功耗测量是整个实验最难也是成本最高的环节。我用了两套工具交叉验证：

• Nordic Power Profiler Kit II (PPK2)： 专为nRF系列设计，采样率100kSps，分辨率0.2μA，动态范围200nA-1A。这是我们测试nRF52840功耗的主力工具。
• Keysight N6705C + N6781A SMU： 通用电源分析模块，用于STM32U5和ESP32-C6的精密测量。采样率200kSps，电流分辨率1nA。这套设备是从合作实验室借的，单台设备报价接近8万人民币，普通团队不一定买得起，但可以租用。
• Joulescope JS220： 备用验证工具，采样率2MSps，适合捕捉微秒级的电流尖峰。

这里必须严肃地说一句：做功耗偏差分析，示波器加采样电阻的方案精度不够，高边采样电阻会引入额外压降，影响MCU实际工作电压，进而改变内部LDO效率，最终导致测量本身产生5%-15%的误差。 如果你只有示波器，那至少要用100mΩ以下的精密采样电阻，并在电压反馈端做补偿。但即便如此，测量低于10μA的休眠电流时，噪声已经很难压住。

2.3 测试场景设计

我设计了三个典型低功耗固件场景，每个场景都有明确的功耗预算：

场景A：周期唤醒传感器采集（简称“定时唤醒”）

• 任务：每60秒唤醒一次，读取BME280温湿度+气压数据，通过BLE广播上报。
• 设计功耗目标：平均电流<5μA（不含BLE发射峰）。
• 功耗预算分配：休眠期<3μA，唤醒采集期<2mA持续5ms，BLE广播<8mA持续3ms。

场景B：事件驱动的LwM2M上报（简称“事件通信”）

• 任务：监听加速度计中断（基于阈值），事件触发时通过CoAP上报至云端。
• 设计功耗目标：待机<8μA，事件处理+通信功耗<15mJ/次。
• 关键约束：中断响应延迟<2ms。

场景C：动态电压频率调节（简称“DVFS”）

• 任务：根据当前任务负载自动在16MHz/64MHz之间切换，轻载时降频降压。
• 设计功耗目标：平均工作功耗<3mW。
• 关键约束：频率切换不能产生时钟毛刺，不能丢失UART缓冲数据。

2.4 提示词设计：从“裸请求”到“工程级请求”

这是整个实验最核心的变量之一。我设置了四个梯度的提示词复杂度：

从G0到G3，本质上是把工程师的经验以提示词的形式注入给AI。这组对照的目的，是回答一个关键问题：“能耗偏差到底是因为AI不懂低功耗设计，还是因为提问者没有说清楚需求？”

答案是：两者都有。G0和G1生成的代码功耗表现很差，而G2和G3有明显改善。但即使是G3，已经包含大量工程细节的提示词，生成的代码仍然在某些细节上不如人工优化版本。具体情况我将在第四节展开。

三、场景实测：偏差从哪来，数据怎么说

3.1 场景A：定时唤醒，睡眠模式的“最后一微安”

这是我最先测试也是最典型暴露问题的场景。在nRF52840上，官方SDK提供了三种低功耗模式：

• System ON Sleep： CPU休眠，外设、RTC、RAM保持，功耗约1.9μA（保留RTC和RAM）。
• System ON Sleep with 32K RAM retention off： 功耗约1.2μA。
• System OFF： 除GPIO唤醒和NFC外全部关闭，功耗0.4μA，但会丢失RAM数据。

我们的设计选择是System ON Sleep（需要保留RTC做唤醒计时），目标功耗1.9μA + 传感器静态功耗 + 少量外围损耗，总控在3μA以内。

G0提示词的输出： Claude Code生成了一段完全可编译通过的代码。逻辑正确，初始化RTC、配置BME280的I2C接口、BLE广播参数、主循环调用sd_app_evt_wait()等待中断。但实测待机功耗2.5mA。注意，是毫安不是微安。排查发现三个问题：

1. I2C总线未释放。 读取BME280后，代码没有调用nrf_drv_twi_disable()关闭TWI模块，也没有将SDA/SCL引脚恢复为高阻态输入。BME280本身进入休眠后I2C引脚处于开漏高阻状态，但nRF52840端的TWI控制器仍在内部时钟驱动下保持总线监控，这部分额外消耗约400μA。
2. GPIO未做电平锁定。 多个未使用的GPIO引脚被软件复位为默认状态（输入、浮空）。在PCB上这些引脚有上拉或下拉电阻，浮空状态下产生了额外的穿透电流。nRF52840有48个GPIO，不用的引脚不处理，累积泄漏电流很可观。在我的板上实测，所有浮空引脚合计泄漏约180μA。
3. BLE广播结束后未关闭HFCLK。 sd_app_evt_wait()在BLE活动结束后将CPU转入睡眠，但HFCLK（高频时钟）并没有被立即关闭。SoftDevice后台有一个约3秒的时钟保持窗口用于处理潜在的连接请求，这是合理的广播协议行为，但在纯信标场景（不需要连接）下，这段时间的额外功耗是浪费的。

修复方案： 我在代码中手动添加了三个操作：TWI释放时序、GPIO初始化为输出低电平、广播完成后强制进入System ON Sleep并设置NRF_CLOCK->TASKS_HFCLKSTOP = 1（仅当确认不需要BLE连接时）。修复后待机功耗降至2.3μA。

但这里出现了一个让我警醒的事实： 这三个操作中，前两个是通用嵌入式开发常识，但排查它们需要理解硬件行为，而这正是AI当前的盲区。AI知道TWI的API调用方法，但它不理解nRF52840的TWI控制器在使能后即使没有数据传输也会消耗电流，因为在它见过的所有训练样本中，几乎没有人写过“用完TWI记得关掉”这种注释，功能演示代码默认只跑几分钟就断电，功耗根本不在考虑范围内。

用G3提示词重新生成，Claude Code确实在代码中加入了外设关闭逻辑，但顺序仍然不够精细。例如它先关闭了TWI，再给传感器发休眠命令，这在逻辑上是错的，因为休眠命令需要通过I2C发送。正确的顺序应该是：先发传感器休眠命令，等待ACK确认，再关闭TWI控制器。这个细节，没有功耗敏感性的开发者可能也会疏忽。

3.2 场景B：事件通信，中断的代价你不知道

这个场景更容易暴露AI的深层问题。任务监听加速度计中断，设备平时在休眠，当检测到震动超过阈值（模拟冷链箱开箱事件），立即唤醒并通过蜂窝模组（NB-IoT）上报一条CoAP消息。

功耗设计的关键指标是“事件能耗”而非平均功耗。 因为事件是稀疏的，一天可能只有几次开箱，所以关键在于每次事件处理的能耗总量。设计目标限制为每次事件<15mJ。

在STM32U575上测试，G1提示词生成的代码实测单次事件能耗约38mJ，是目标的2.5倍。问题出在中断服务例程（ISR）的设计上：

问题一：ISR中执行了过多操作。 AI生成的ISR在触发后直接调用CoAP消息构建和AT指令发送。这导致CPU在中断上下文下跑了近200ms才退出，在此期间，中断优先级机制阻止了其他低优先级中断，更重要的是，CPU跑在较高的中断处理电流下（约8mA），而不是可以降频的Thread模式。

嵌入式工程师的常识是：ISR应该尽可能短，只设置标志位或信号量，实际处理交给主循环或低优先级任务。 但AI没有这个肌肉记忆，因为它看到的大量代码把业务逻辑写在中断里，在非低功耗场景下这甚至被认为是“高性能”的做法（减少上下文切换），但在低功耗场景下这是致命的。

问题二：等待AT指令返回时使用轮询而非DMA+中断。 代码中有一段检查NB-IoT模组响应状态的循环：

while (uart_rx_buf[0] != 'O' && timeout timeout++;

HAL_Delay(1); // 每次1ms的忙等

}

这段代码“正确”但耗电。HAL_Delay(1)本质是1ms的忙循环，CPU在这5秒（最坏情况）内完全无法进入睡眠。实测这个等待循环贡献了约18mJ的额外能耗，接近一半。

人工优化方案很简单：STM32U575的UART支持IDLE中断和DMA接收，配置好DMA环形缓冲区和IDLE中断后，CPU可以在模组返回响应前进入Sleep模式，由硬件自动收数据并在接收完成后唤醒。修改后，单次事件能耗降至11.2mJ。

3.3 场景C：DVFS，当节能算法本身不节能

这是三个场景中最复杂也最能暴露AI局限的一个。动态电压频率调节需要软件根据任务负载决定何时升频/降压、何时降频/升压。在ESP32-C6（RISC-V架构）上实现。

目标简单但实现很复杂：空闲时跑16MHz @ 0.8V（内部LDO），任务到来时切换到80MHz @ 1.1V。切换本身需要稳定时间（PLL lock time + LDO settling time，约50μs），如果在错误的时间做了不必要的切换，切换的代价可能超过频率调整带来的收益。

G3提示词生成的第一版DVFS代码出现了一个很微妙的错误： 它使用了简单的“队列长度检测”来决定是否升频，如果freertos任务队列深度超过阈值，就升频。问题在于，这个判断本身被放在了每次任务切换时执行，而任务切换频率远高于实际负载变化的频率。结果是，CPU每周检查一次队列长度（还好检查本身很快），但检查逻辑触发了额外的寄存器读取和分支预测失败，实测表明这个检查本身消耗了约400μA的平均电流，而省下来的电远不及这个开销。

这本质是一个“控制理论”问题而不是代码质量问题。 AI学过DVFS的概念，也能写出频率切换的寄存器操作代码，但它不理解控制回路自身的开销对整个系统的影响。人工设计的DVFS方案通常有迟滞（hysteresis），不是队列一满就升频，而是连续三次采样都超过阈值才动作；同样，不是队列一空就降频，而是至少空置100ms才进入慢速模式。这些策略防止了频繁振荡，而AI生成的版本没有。

更隐蔽的一个问题是频率切换时未保护UART FIFO。ESP32-C6的UART FIFO在频率切换过程中如果还有数据未发送完，切换PLL时钟源会导致FIFO指针错位，发送乱码。AI的切换代码没有在切换前检查UART状态并等待发送完成。这个bug在功能测试中不一定能抓住，取决于切换时刻UART是否正好在发送数据，属于典型的概率性故障。但在低功耗场景的长期运行中，这种偶发错误可能积累成数据链路问题。

四、偏差根源分析：AI大脑的三个“工程盲区”

经过三组场景实验和大量补充测试（包括更换Claude模型版本、使用不同MCU的SDK、尝试不同的代码组织方式），我将能耗偏差的根源归纳为三个AI工程盲区。这里的“盲区”不是指AI能力缺陷，而是指在当前训练范式和架构约束下，AI难以自然掌握的嵌入式系统工程直觉。

4.1 硬件行为模型的缺失

AI对代码的理解是基于文本和语义的，它知道nrf_drv_twi_init()是初始化I2C，但它不会“感知”到调用这个函数后，芯片内部的TWI控制器时钟树被激活，电流从3μA跳变到600μA。这个物理层面的因果关系，在训练语料中极少被显式表达。

绝大部分嵌入式代码的文档和注释描述的是“做什么”，而不是“代价是什么”。我在GitHub上用search: "TWI disable" language:c搜索nRF52相关的代码库，结果中只有不到8%的示例在初始化后有关闭TWI的逻辑。AI从这些样本中学到的模式就是：初始化外设→使用外设→程序结束。至于“程序结束”之前要关闭外设这个模式，训练数据中太少了。

这不是Claude独有的问题，而是所有基于公开代码语料训练的模型的共同局限。 我在GPT-4o和Gemini 2.5 Pro上做了相同的提示词测试，功耗偏差的趋势高度一致，偏差程度有差异，但“不关外设”这个错误几乎所有模型都会犯。

4.2 时间维度的“感知缺失”

低功耗设计的核心是在时间的微观维度上做“电量管理”，什么时候醒、什么时候睡、睡多久。AI在生成代码时基于静态的语义理解，不理解代码执行的时间剖面。

以场景B中的HAL_Delay(1)为例，从语法上看，这是一条合法的延时语句，和其他任何延时语句没有区别。但从功耗角度看，HAL_Delay(1)意味着1ms的全速运行无睡眠，1ms的全速运行电流（约8mA）相当于在1μA睡眠状态下8000秒的电量消耗。这不是夸张：1ms的忙等 = 近2.3小时的浅睡眠电量消耗（在1μA睡眠电流下）。

AI不理解这个换算关系。它不知道一段轮询代码的实时代价，因为它在生成代码时没有“电量表”的概念。这种对时间-电流乘积的直观感受，是嵌入式工程师在长年累月盯电源分析仪屏幕的过程中内化形成的。

4.3 编译器与指令级功耗的割裂

这是更深也更难解决的一层问题。同样的C代码，经过不同的编译选项（-O0, -Os, -O2, -Oz）编译后，生成的机器指令序列可能完全不同，而不同的指令序列在相同架构的CPU上执行时，功耗表现不同。

例如ARM Cortex-M4F上，32位整数乘法在不同场景下可能被编译为单周期MUL指令，也可能被分解为多次移位和加法。前者的峰值电流更高但总执行时间短，后者的峰值低但持续更久。哪种更省电？取决于VDD电压、CPU频率、当前任务的时间裕度，这需要结合具体参数才能判断。

AI完全不知道它写的代码会被怎样编译，也不知道编译结果在目标硬件上的指令级功耗特征。 它看到的是C语言抽象层，而功耗表现取决于C语言之下的编译器、指令集和微架构实现。这种跨抽象层的因果关系，需要从硬件到编译器到代码的完整链路知识，而AI目前只拥有其中“代码”这一环。

五、修正路径：一套可复用的AI低功耗代码验证方法

讲完问题，我必须给出行之有效的解决方案。过去三个月的反复测试，让我总结出一套标准作业程序，我称之为“AI低功耗代码三阶段验证法”。这套方法已经在公司内部两个项目上实践过，效果显著：G3提示词+三阶段验证后，AI生成的代码在功耗表现上可以达到人工优化版本的90%-95%。

5.1 第一阶段：提示词注入，“把你的经验翻译给AI”

这是投入产出比最高的环节。一个“工程级”的提示词，能让能耗偏差从一开始就缩小一半。以下是我的提示词模板框架：

[角色设定]
你是一个具有10年经验的嵌入式低功耗固件工程师，擅长Nordic/STM32/ESP32平台的低功耗设计。

[硬件约束]

目标芯片：{具体型号，如nRF52840-QIAA}

工作电压：{如3.0V，由CR2032供电}

目标平均功耗：{如<5μA，不含无线发射}

关键外设：{列出所有用到和可能用到的外设}

[功耗设计原则 - 必须遵守]

任何外设在未使用时应立即关闭，包括显式禁用对应时钟门控。
所有中断服务例程执行时间应<50μs，复杂处理放在主循环。
数据传输优先使用DMA，避免CPU轮询等待。
未使用的GPIO必须配置为模拟输入或输出低电平，禁止浮空。
休眠前检查所有外设状态，按从外到内的顺序关闭（先传感器，再I2C/SPI，再DMA，最后关闭对应总线时钟）。
唤醒后按从内到外的顺序使能（先时钟，再总线，再外设）。
避免使用忙等延时函数（如HAL_Delay、delay_us），改用定时器触发唤醒。
[功能性需求]

{具体的功能描述}

关键不在于模板本身，而在于模板中注入的工程原则，每一条都是用功耗测试台上的额外微安数换来的。

提示词写完后，我的习惯是让Claude Code把生成的代码用自然语言解释一遍它的低功耗设计决策。这个步骤很有效，如果AI在解释中出现逻辑混乱或自相矛盾（比如“我关闭了SPI以节省功耗”但代码中没有对应操作），说明它的理解可能存在问题，这个版本的代码需要重新审查或重新生成。

5.2 第二阶段：静态审查，“用一张检查表消灭70%的偏差”

收到AI生成的代码后，不要急着上板测试。先用以下检查表逐项审查。这张表来自我和团队在多个项目上收集的高频问题，每一条背后都有至少一次实际的功耗翻车经历。

AI低功耗代码静态审查清单：

这张检查表执行一遍大约需要30-45分钟，但用45分钟审查换回一个可能要调试两天的功耗问题，这个生意很划算。

5.3 第三阶段：仪器实测，“数据和直觉都要上场”

静态审查通过后，上板实测。这里我说一个可能不太“标准化”但非常实用的建议：不要只看稳态功耗数据，要看电流-时间曲线。

稳态数据，比如万用表读出来的3.2μA，告诉你现在的“状态”，但看不到过程的“动态”。很多功耗问题藏在曲线里：

• 异常尖峰： 有没有周期性出现的电流尖峰，表明有某个外设在不必要地定期唤醒？
• 休眠深度不一致： 曲线上的休眠电流是否稳定？如果有周期性波动，说明可能有时钟域未被完全关闭。
• 唤醒时长异常： 从触发唤醒到执行完任务重新进入休眠的时间是否合理？过长的活跃期说明处理效率有问题。

Nordic PPK2和Joulescope都支持长时间电流曲线记录。我的做法是把设备连上，让它跑24小时，第二天回看整段曲线。这个习惯帮我发现过很多单次测量发现不了的问题，比如每4小时一次的电流尖峰，日志和功能测试完全看不出异常，最后发现是RTC的一个内部溢出中断配置有误。

六、不同场景下的取舍建议

不是所有项目都需要做到极致低功耗。不同产品形态、电池容量、使用寿命预期，决定了对功耗偏差的容忍度不同。在有限工程资源下，合理分配验证精力才是王道。

6.1 三档功耗敏感度分级

如果你的设备插着电或者每周充一次电，不用在功耗偏差上花太多时间。 AI生成的代码即使功耗高了50%，对于常供电设备来说只是电费多了几分钱。但如果你的设备在火山口监测地震，每更换一次电池的成本是差旅费和人力，那功耗偏差的每一微安都值得较真。

6.2 Claude Code版本选择策略

在测试过程中，我对比了Claude 3.5 Sonnet、Claude 4 Opus和Claude 4 Sonnet三个版本在嵌入式代码生成上的表现：

Claude 4 Opus在理解复杂工程约束方面明显领先。 给它相同的G3提示词，它生成的代码在外设关闭顺序、睡眠模式选择等细节上的正确率高于其他版本。但它的生成速度较慢，单次请求可能需要15-30秒，适合不频繁但质量要求高的场景。

Claude 3.5 Sonnet是性价比较高的日常选择。 功耗表现比Opus略差（约10%-15%的差距），但生成速度快，适合快速迭代和原型验证。

Claude 4 Sonnet在两者之间取得了很好的平衡。 如果项目预算允许，我目前的推荐策略是：原型阶段用4 Sonnet快速迭代，关键模块用4 Opus做最后的精度打磨。

6.3 什么时候应该放弃AI，纯手写

经过三个月的密集测试，我的判断是：对于以下三类代码，目前阶段建议完全手写或至少以人工为主：

第一类：芯片上电复位后的时钟初始化代码。 这部分代码直接决定系统启动后的电流基线。时钟树的配置错误可能导致MCU从第一微秒就消耗比预期高几倍的电流，而这个错误可能贯穿整个产品生命周期而未被察觉，除非你有功耗基准测试。

第二类：多层中断嵌套的优先级调度代码。 中断优先级不仅影响功能正确性，还影响功耗脉冲的叠加方式。AI倾向于按“逻辑正确”来安排优先级，而不是按“功耗最优”。中断优先级的功耗优化需要理解具体任务的时间敏感性和能耗特征，这个决策目前仍严重依赖工程师经验。

第三类：电源管理IC（PMIC）的时序配置。 如果板上有独立的PMIC或充电管理芯片，其上电时序、电压轨切换顺序直接影响系统功耗。这部分配置通常需要对着芯片手册逐寄存器地确认，AI在这类高度依赖datasheet信息的领域出错的概率偏高，因为它看不到手册里的具体数值和时序图。

七、展望：AI需要什么样的“功耗意识”

文章写到这里，我想跳出具体的技术细节，谈一个更大的观察。

过去两年，AI辅助编程在功能正确性上取得了突飞猛进，从生成几十行的函数到能处理整个工程项目的重构。但在嵌入式领域，“功能正确”只是及格线，“能效正确”才是优秀的分水岭。而在这个维度上，当前所有AI模型都有明显的成长空间。

我认为下一代AI编码工具需要补齐三个能力：

第一，硬件功耗模型的集成。 如果Claude Code能读取芯片的数据手册，理解GPIO泄漏电流、外设功耗参数、睡眠模式电流等关键数据，它就有可能在生成代码时做功耗估算。这不需要完美的物理仿真，一个数量级精度的估算，就足以过滤掉大部分“关不关外设就差几百微安”的问题。

第二，时间-电流剖面意识。 在生成代码时，AI应该能输出一个粗略的“时间-电流”预测：这段代码执行大概需要多久，电流在什么范围，睡眠期间功耗多少。开发者拿这个预测和实测对比，偏差大的地方就是需要深入检查的地方。

第三，编译优化意识。 AI需要了解不同编译优化选项对代码的影响，并能够在生成代码时会刻意写出“对编译器友好”的结构。这可能是三个能力中最难实现的，因为它涉及C语言到机器码的跨层映射，但也是长期最有价值的一个。

这些能力的实现不一定需要重新训练大模型。更现实的路径是在AI编码工具的外围构建功耗感知的验证和反馈环路，就像现在的linter检查语法错误和代码风格一样，未来的功耗linter检查时钟门控、外设状态和睡眠深度。

八、最后的话

回到标题的核心问题：用Claude Code生成低功耗算法，能耗偏差到底有多少？

我的实测答案是：不做特殊处理，偏差40%-180%；用G3级提示词加三阶段验证，可以压缩到5%-10%。

这个答案本身说明了一个更深层的事：偏差不是AI的固定属性，而是AI和工程师交互方式的结果。 Claude Code是一把精度很高的刀，但它在低功耗这个特定领域缺少“手感”，这种手感是你、是我、是所有那些在深夜盯着电源分析仪屏幕、为了省下几微安而反复调代码的嵌入式工程师才有的东西。

我们的任务不是拒绝这把刀，而是教会它我们的手感。而教的过程本身，也在逼着我们把那些隐性的、经验性的知识，显性地整理出来，这对整个行业，未尝不是一件好事。

下一步行动建议：

1. 如果你正在用AI辅助低功耗固件开发，立刻按照本文的提示词模板重新审视你当前的prompt，加入外设关闭顺序和睡眠模式的具体约束。
2. 下载一份静态审查清单（本文第五章表格已经可以直接用），花30分钟审查当前AI生成的代码，我几乎可以保证你会找到至少一个功耗隐患。
3. 如果你的项目属于高敏感或中敏感级别，安排24小时电流曲线采集。数据不会撒谎，但你需要先收集数据。

我用三台电源分析仪、六块开发板、超过200次代码迭代换来的结论，希望能让你少走一些弯路。低功耗嵌入式开发没有神奇的银弹，但有更聪明的路径，而识别并修正AI的能耗偏差，就是这条路径上最关键的一公里。