我在调试一台 48V 通信电源模块的时候同事把一段用 AI 生成的控制代码发到群里说“这版代码逻辑挺完整的直接用应该没问题”。我把它下到板子里输出电压纹波直接飙到 300mV系统还时不时触发过压保护。代码逐行看过去确实没毛病问题出在它跑在了一个 AI 没看见的世界里ADC 采样点正好落在开关噪声毛刺上PWM 更新时机和中断优先级搭得稀碎定点数换算还悄悄截了一位符号位。这就是我写这篇文章的起点。AI 时代电源 DSP 软件工程师还需要会写代码吗我的答案是需要而且比以往更需要但“会写代码”这四个字的含义正在发生肉眼可见的变化。今天这篇东西不打算讲抽象道理我直接从数字电源、DSP 开发的实际场景出发拆一拆代码到底在我们这个行当里承担什么角色AI 能替我们做掉什么又替不掉什么。1. 先回答那个“是或否”的问题现在的AI能写什么样的电源代码先说个大多数人容易忽略的事实AI 写代码的能力增长确实快但它擅长的是“语言层面”的生成而不是“系统层面”的重构。你让 ChatGPT 或 Claude 写一段字符串解析、状态机框架、标准 PID 函数它能在几秒内给出非常像样的东西。可你要是拿这段代码直接塞进带电路的 DSP 里它不一定能跑跑起来也不一定稳。1.1 工具本身很强但强在“局部生成”我日常用的 AI 编程工具主要是 Copilot 和 Claude Code。实话说它们在几个场景里已经成了我的效率杠杆寄存器级初始化框架比如 TI C2000 系列的 EPWM、ADC、GPIO 初始化这类代码网上模板一大堆AI 整合能力很强能省去我翻 datasheet 的时间。通信协议解析PMBus、CAN、UART 自定义协议只要把协议格式描述清楚AI 能写出结构化不错的解析封包代码。常见控制算法的“标准版”比如增量式 PID、抗积分饱和处理、一阶低通滤波器的离散化这些教科书级代码 AI 写得基本不会出错。但这里面有个前提我知道自己要什么而且拿到代码后能独立判断它对不对。AI 生成的是“符合自然语言描述的代码”不是“符合硬件行为逻辑的代码”。两者的差距在电源控制这种强实时、强耦合、强安全的领域会被迅速放大。1.2 电源DSP代码的特殊性代码即硬件行为嵌入式软件在很多场景里是“逻辑正确就行”但电源 DSP 软件不是。你写的每一行代码最终都要落到这样的物理过程里开关管以 20kHz、100kHz 甚至更高频率开关PWM 占空比的每一次更新都直接改变电感电流和输出电压。ADC 触发时刻决定了你看到的电压是峰值、谷值还是噪声毛刺。中断延迟哪怕差 1~2μs控制环路就可能从稳定变成震荡。这也就是说电源 DSP 里的代码不是“跑在抽象的处理器上”而是“跑在一台由电感、电容、MOSFET、变压器构成的功率电路上”。代码写错了轻则性能不达标重则炸管、炸电容、烧负载。所以如果标题里的问题改成“AI 能不能直接替代电源 DSP 软件工程师的编码工作”我的回答是短期内不可能因为它看不到电路也无法为代码行为负责。但“工程师还需要不需要会写代码”这个问题真正的答案藏在另一个地方你以为你靠写代码挣钱其实你是靠理解系统挣钱代码只是把理解变成机器行为的手段。2. 拆开“写代码”电源DSP工程师的代码到底长在哪四层很多非电源方向的人以为电源软件就是“写个 PID 稳住电压”。真这么简单就好了。一套量产级数字电源固件代码量通常在几万行到几十万行之间工作时长横跨初始化、实时控制、保护、通信、诊断、升级等多个维度。我习惯把电源 DSP 软件分成四层来看每一层的“写代码”性质完全不同。2.1 硬件驱动层把芯片变成“能用”的状态这一层包含系统初始化、时钟配置、GPIO 复用、ADC 校准、EPWM 模块配置、比较器子模块配置等。难点不在语法而在时序和外设之间的时钟关系。比如 C2000 系列里EPWM 的时基频率、ADC 触发信号来自哪个 EPWM 事件、采样保持窗口设多少纳秒——这些参数差一点控制性能就差一大截。AI 写这一层代码的失误率不算太高前提是你把芯片型号、外设模块、时钟频率等约束喂给它。但它生成的配置代码往往“看起来全”实际上忽略了很多硬件细节比如 ADC 的采样窗口没考虑前级运放的建立时间PWM 死区配置没考虑驱动芯片的传播延迟补偿。这些恰恰是模拟/功率电路长期工作后才会暴露的问题AI 无法从语言层面推断出来。2.2 控制算法层真正意义上的“控制律设计编码”这一层是电源软件的核心也是“写代码”最难被替代的部分。常见的控制算法包括电压模式 PID、电流模式 PID、双环控制电压外环电流内环平均电流模式 / 峰值电流模式PFC功率因数校正控制比如平均电流型 CCM PFCLLC 谐振变换器的 PFM/移相控制状态观测器、前馈补偿、死区补偿、非线性增益调整写这层代码表面上是写数值运算实际上是把你设计的控制策略变成实时可执行的离散算法。你得懂采样定理、懂离散化方法前向差分、后向差分、双线性变换、懂定点数溢出风险还必须在中断周期内把运算跑完。这里涉及到很多参数换算的细节比如母线电压 400V经过电阻分压 运放调理后进入 ADC数字量怎么换算成实际电压值电压环输出作为电流环给定两个环路的更新速率怎么分配Q 格式定点数下哪一步乘法会溢出需要做移位和饱和度处理。AI 能根据你的指令写出一版“教科书 PID”但它无法替你做环路参数设计——穿越频率选多少、相位裕量留多少、抗积分饱和阈值设在哪这些来自系统模型和实际调试的积累。2.3 状态机与保护层决定系统和人员安全的“最后防线”这一层最不出彩也最不能出错。数字电源的运行状态不是只有“工作”和“不工作”而是有上电时序、软启动、正常运行、轻载模式、突发模式、故障锁定、打嗝重试、断电放电这一整套状态流转。保护逻辑包括过压保护OVP、欠压保护UVP、过流保护OCP、短路保护SCP、过温保护OTP、输入浪涌限制、输出反接保护等。每一项都要有阈值、去抖时间、响应动作是关断还是限流还是打嗝、故障恢复方式自恢复还是锁死。我在这层的经验是写保护代码时一定要把“不可能发生的故障”也当一回事。比如故障标志位的优先级、不同故障同时发生时的处理顺序、进入保护后是否可靠关断所有相关 PWM 输出。AI 写状态机框架很拿手各位真的可以让它先搭一个通用状态机再逐个填充事件和条件。但保护策略里的每个数值、每个延时、每个优先级判断必须由懂电路的人拍板。2.4 通信与人机交互层和外面世界打交道的部分量产电源产品要支持 PMBus、CAN、RS485、I2C 等通信接口跟系统里的主控或 BMS 交换状态信息。这一层有不少繁琐的位操作、校验和、超时重传逻辑是最适合交给 AI 代写的部分。它不需要理解功率电路只需要遵循协议。但通信层有个常见的坑通信任务不能干扰实时控制。如果通信中断优先级设得比 PWM 中断还高或者通信库里用了阻塞式延时控制系统分分钟出问题。这一层的“写代码”考验的是任务划分和资源隔离能力而不是协议栈本身。3. 一次真实的翻车让AI写数字电源PID代码板子上发生了什么接下来进入实战复盘。为了让这篇文章的内容更具体我在写稿前专门做了一次实验用 AI 生成一版简单的 Buck 变换器数字电压环 PID 代码然后把它跑在一块基于 TMS320F28379D 的开发板上。实验条件如下拓扑同步 Buck开关频率 100kHz输入 12V输出 3.3V负载电阻 1Ω控制方式电压模式 PID单环控制ADC 采样输出电压PWM 更新占空比要求输出稳定、动态响应不太差、不能触发过压我把这些需求写成一个比较完整的 prompt还特意补充了“请用 TI C2000 的风格写”AI 很快给出了一版看起来很专业的代码。3.1 第一眼代码结构是完整的文档也是齐全的AI 生成的代码包括这几部分系统初始化PLL 时钟配置到 200MHzEPWM1 配置为 100kHzADC 配置为软件触发但没设置 PWM 触发源中断服务函数在 EPWM1 中断里读取 ADC 结果调用 PID 计算更新占空比PID 参数给了 Kp、Ki、Kd 的建议值还配了一堆注释说明“参数需根据实际系统调整”。代码能编译逻辑链路看起来也都串起来了。很多不熟悉数字电源的人拿到这版代码确实会觉得“可以下板试一下”。我当时也是这么想的然后就翻车了。3.2 实际波形从启动开始就有问题上电后我直接用示波器看输出电压和电感电流波形现象非常典型软启动阶段输出电压爬升很快冲到了 3.8V 左右才回落到 3.3V说明软启动斜坡设置几乎没有发挥限制作用稳态阶段输出电压纹波大约 200~300mV远超设计目标而且低频段有一个明显的 2kHz 左右的小幅波动负载突变测试电子负载从 0.5A 跳到 3A输出电压掉了将近 500mV恢复时间超过 5ms动态性能明显不行。我没有直接怪 AI 写错了什么——因为单看每一行语法它确实没什么错。真正的 bug 藏在那层它看不见的“硬件与实时约束”里。3.3 三个致命的“看不见”的问题问题一ADC 采样点没有和 PWM 载波同步。AI 生成的代码里ADC 是软件触发中断里读 ADC 结果。问题是它没有配置 ADC 的触发源来自 EPWM 时基这导致电压采样发生在开关周期的随机时刻。Buck 变换器在开关管导通和续流阶段的输出电压纹波特性完全不同随机采样等于给控制环路注入随机噪声。这就是 2kHz 低频波动的直接来源。问题二中断里加了浮点运算但没评估执行时间。TMS320F28379D 是有 FPU 的AI 也默认用了 float 类型看起来没问题。但它在 PID 计算里连续调用了多次乘法和分支判断加上 ADC 读取和使用外部库函数整个中断服务函数跑下来超过了 10μs。开关周期是 10μs100kHz中断里代码还没跑完下一轮 EPWM 中断又来了控制率实际上一直处于“被打断重来”的状态环路完全乱掉。问题三定点/浮点混用导致的采样换算误差。AI 生成的代码里电压采样值换算成实际电压是这么写的voltage (float)adcResult * 3.3 / 4095.0;——听着没错但它没考虑实际硬件上有分压电阻和运放比例ADC 满量程对应的不是 3.3V 而是 6V 甚至 8V。换算系数错的离谱PID 控制的“目标值”和“反馈值”压根不在一个坐标系里。我检查代码三遍才发现这个基础问题。我把问题和修正方案整理成了这个表格问题现象AI 代码里的根源人工修正采样不同步输出低频波动、纹波大ADC 触发源未绑定 EPWM 事件配置 ADC 触发源为 EPWM1 事件并在载波谷/峰固定时刻触发采样中断超时环路失控动态响应差中断内浮点运算量过大逻辑未优化精简中断逻辑、合理使用定点数、必要时拆分高低频任务换算系数错误输出电压偏离且 PID 饱和未结合分压/运放比例直接按 3.3V 满量程换算根据实际电路计算 ADC 满刻度对应电压统一量纲3.4 从这次翻车里得出的结论这次实验我收获很大因为它帮我把“AI 能写代码”和“AI 能写能跑的电源代码”这两个概念彻底区分开了。AI 生成的是“语法正确、逻辑看起来自洽”的代码但它对电路不感知对时序不敏感对量纲不会怀疑。能发现并解决上面这三个问题的人必须懂功率变换器的工作过程、懂 DSP 的外设行为也必须具备逐行读代码的能力——这本身就是“会写代码”的底层要求。所以别把“AI 写代码”理解为“AI 替你做决定”。把它理解为“AI 按你描述的需求草拟了一版初稿”最终的质量责任仍然在你手上。4. 未来三五年电源DSP工程师的“会写代码”正在变成什么如果说前面几章讲的是现状那这一章我想聊聊变化的方向。不会写代码还能不能入行我的判断是门槛确实是降低了但天花板也拉大了。AI 把代码生成变成了一种廉价能力于是行业对工程师的筛选标准会自动从“你会不会写”转向“你会不会写对的、写能跑的、写不怕故障的”。这个转变对初入行的人是好事对资深工程师更是机会。4.1 从“写代码”转向“审代码”和“拆需求”AI 生成代码的高效意味着一个有经验的电源软件工程师现在一天能完成以前三天的编码工作量。但这只在需求拆解足够清晰时成立。你需要把一句“稳住输出电压”翻译成 AI 能理解、硬件能执行的控制需求这个过程远比手写代码更考验功底明确电压环带宽要求穿越频率选多少相位裕量留多少动态响应指标是多少明确采样方案采样点放在 PWM 周期哪个位置是否需要过采样做平均明确保护阈值与动作时序过压保护阈值是额定电压的 110% 还是 115%故障后是立即锁死还是打嗝 5 次后锁死明确故障恢复策略自恢复条件是什么重启延迟多少毫秒是否需要记录故障码。每个需求细节都会直接影响 AI 生成的代码。这方面我有一个比较粗暴的经验prompt 里写的约束越接近生产规格书AI 生成的代码越接近能用的状态。如果你自己脑子里没有这些约束AI 生成的代码一定会在某个地方、以某种方式埋雷。4.2 从“验证功能”转向“验证鲁棒性”我工作这些年有个体会写代码的时间占三成调试和验证的时间占七成。AI 能帮你把三成压缩成一成但省下来的时间不能拿去休息要投入到更重要的七成里去——尤其是鲁棒性验证。以前你写一段 PID主要验证功能给定变化时输出能不能跟随。现在的验证应该包括满载、半载、空载切换时的动态响应是否达标输入电压从 9V 到 16V 变化时环路是否稳定温度从 -40℃ 到 85℃ 变化采样偏置、占空比更新的延迟是否仍然安全连续运行 72 小时甚至更久故障寄存器有没有异常计数在恶劣负载比如恒功率负载、容性负载下保护逻辑是否可靠不误动。这些验证对象的代码往往也是 AI 化的产物但你作为工程师必须设计出验证它们的方法和用例。这属于更高层次的能力也是未来更值钱的方向。4.3 从“自己能写”转向“能找到 AI 写不出来的问题”坦白讲在 GPT 级别模型帮你写代码的时代你完全可以把“手写”这件事外包出去。真正外包不了的是“知道问题在哪、知道为什么出问题、知道怎么改问题”的能力。比如你在示波器上看到输出电压在负载突变时出现了两个周期的振荡工程师需要判断是 PID 增益余量不足还是采样延迟太大还是 PWM 占空比更新时刻不对每一种可能都对应不同的代码修改方案而且这些修改不是单纯加几行代码能搞定的往往需要调整系统设计。AI 不会替你看示波器也不会替你理解电路的一阶、二阶特性。所以我对“还需要会写代码吗”这个问题的最终回答是你需要具备随时能逐行读懂、修改、重写代码的能力但不需要像以前那样把大量时间花在“敲键盘”上。就好比一位优秀的厨师不会拒绝使用自动切菜机但他必须知道每种食材该怎么切才能保住风味机器出了故障也能立刻用手工方式保证出品。5. 我的实操建议怎样和AI搭档又不丢掉自己的看家本领这一章是实打实的建议。我根据自己的使用经验把“可以用 AI 的场景”“必须自己把关的场景”和“不同经验阶段的人怎么调整策略”分开讲供参考。5.1 哪些任务可以放心交给AI先说结论越像“文书工作”的代码越适合交给 AI。我日常用得比较多的包括初始化模板的草稿生成尤其是新项目启动时寄存器级初始化代码量大、套路固定AI 可以快速生成初版通信协议栈PMBus/CAN/Modbus 的帧解析、组包、校验、超时重传只要把协议表喂清楚AI 写得很规整单元测试与自动化脚本给控制算法模块写一批边界值测试用例、脚本AI 能补全很多人类懒得写的分支代码注释和文档整理这一项属于“辅助性写作”完全可以让 AI 接手。此外AI 还特别适合做“代码互译”比如你以前用汇编写了一段关键时序逻辑现在想转成 C 语言版本AI 可以帮你转但你必须自己对比时序周期。C2000 的编译器、优化等级也是可变因素别全信它。5.2 哪些地方必须亲自把控容不得半点甩手控制环路的核心策略和参数环路结构、穿越频率、相位裕量、热失控边界、抗饱和策略必须由人定。所有保护逻辑阈值、去抖时间、故障优先级、恢复机制。保护不是“功能”是安全底线。与硬件强相关的时序配置PWM 死区、ADC 触发点、中断优先级、看门狗配置、GPIO 上电默认状态。安全认证和可追溯性要求的代码医疗电源、通信电源、车载电源往往需要代码走查、静态分析、需求追溯这些环节要求工程师能解释每一处关键实现的依据。这里我特别想强调一个词解释能力。AI 生成的代码你再熟悉也要能够对着硬件设计图和原理图把每一处关键实现讲明白。不是为了应付评审而是为了你自己能判断风险。你能解释清楚才说明你真的理解了系统。5.3 给初级、中级、资深工程师的不同策略不同阶段的工程师跟 AI 协作的方式应当有差别初级工程师不要一上来就依赖 AI。先手写几轮完整的电源控制代码哪怕写得慢、效果不好。这个过程不是为了让你练打字速度而是逼你理解 PWM、ADC、中断、PID 这条链路是怎么咬合在一起的。AI 可以当“答案参考”但要自己推一遍、用示波器验证一遍后再下结论。中级工程师把 AI 当作结对编程搭档。遇到新器件、新拓扑、新算法先让 AI 出一个基础框架再对照 datasheet 和应用手册做逐项核对。这个时候的重点是培养“挑刺”的意识比如主动去看 AI 生成的代码里有没有忽略硬件约束的地方然后提出自己的修改需求。资深工程师AI 能帮你把更多执行层面的工作压缩掉让你把精力集中在系统设计、团队规范、平台化建设、故障分析和跨团队协作上。你应当主动建立一套“需求描述模板”和“代码审查清单”让团队里的 AI 使用方式标准化而不是每个人各写各的。5.4 我的个人习惯强制自己“逐行解释”最后分享一个对我帮助很大的小习惯。每次用 AI 生成代码后我会强迫自己逐行用“人话”解释一遍尤其是那些涉及硬件行为的行。解释不通就停下来查资料解释通了的就说明我真懂了。这个过程听起来笨但它确保我不被工具带走也让我在团队技术评审时能扛住任何提问。我甚至建议把“逐行解释”形成文档直接当代码注释的一部分。既方便自己复盘也方便后续接手的人理解设计意图。AI 生成代码最大的风险就是代码看起来很对但没人说得清它为什么这样写。只要还有人能说清这个岗位的核心价值就没有被替代。现在再回到开头那个问题AI 时代电源 DSP 软件工程师还需要会写代码吗我的答案已经具体化了——需要而且需要的是那种“能看穿 AI 代码背后物理世界”的能力。工具让我们写得更快但系统理解、风险判断和最终责任始终是工程师自己的。如果你能把这三点稳稳握住AI 对你来说就是最顺手的工具而不是悬在头顶的那把刀。