这两年，AI Coding 工具越来越强。很多工程师第一次接触时，最直接的感受是：写代码变快了，整理文档也快了，连旧工程重构都能明显提速。

但对电源控制工程师来说，问题并不只是“AI 能不能写代码”。

真正的问题是：

在电源控制软件开发里，哪些工作适合交给 AI，哪些工作不能交给 AI？怎样使用 AI，才能真正提高研发效率，而不是更快地制造错误？

这个问题，如果放在普通业务软件开发里，答案可以相对宽松。但在电源控制、嵌入式实时控制这类场景里，答案必须更严格。

因为这里的软件从来都不是单纯的“代码逻辑”。它背后绑定的是：

• 功率拓扑
• 控制策略
• 采样链路
• PWM 执行链路
• 继电器 / 接触器时序
• 故障保护优先级
• 上电、停机、异常恢复行为
• EMI、热、驱动与硬件边界条件

所以，AI 对这个行业当然有帮助，而且帮助很大。但它的正确用法，不是“把项目丢给 AI，让它自动写完”。

真正合理的方式是：

工程师主导系统设计与正确性边界，AI 负责整理、展开、生成、重构和辅助审查。

---

一、AI 在电源控制软件里，真正擅长什么

如果把电源控制开发工作拆开来看，大致可以分成两类。

第一类是高价值决策工作，例如：

• 选择什么控制架构
• 状态机怎么划分
• 启停路径怎么设计
• 故障优先级怎么定义
• 继电器和 PWM 的先后顺序怎么安排
• 自动恢复是否允许
• 参数和保护阈值怎么定
• 哪些动作必须硬件兜底，哪些可以软件判定

第二类是实现展开工作，例如：

• 枚举和结构体定义
• 状态机骨架代码铺开
• 分支逻辑展开
• 接口整理
• 文档整理
• 旧代码目录分析
• 模块说明、测试表、检查表输出

这两类工作，难度和价值并不一样。

前一类，核心是工程判断。后一类，核心是表达和展开。

而 AI 最擅长的，恰恰是后一类。

它在下面这些任务上，已经非常强了：

• 快速生成状态机骨架
• 批量整理旧工程代码结构
• 把分散逻辑整理成文档
• 对重复代码做重构草案
• 生成测试清单、故障注入表、调试 checklist
• 帮你做第一轮一致性检查和遗漏扫描

但它并不天然擅长下面这些事情：

• 判断控制哲学是否合理
• 判断状态职责是否真的清晰
• 判断某个恢复策略是否会造成实机风险
• 判断某个时序在硬件上是否安全
• 判断某个保护边界是否足够保守
• 判断某种异常工况下系统会不会失控

所以说得更准确一点：

AI 擅长“把你已经想清楚的东西高效率展开”，并不擅长“替你想清楚最关键的系统问题”。这句话很重要。

---

二、为什么很多电源工程师开始觉得 AI 特别好用

不少人现在会明显感觉到：以前自己写状态机、自己铺代码、自己整理文档，很慢；现在先在对话里把状态机和实现逻辑讨论清楚，再交给 AI 或 CodeX 生成代码，效率高很多。这种感觉不是错觉。因为 AI 的价值，首先体现在它帮你吃掉了大量机械劳动。

比如：

• 写状态枚举
• 写结构体
• 铺 switch-case
• 补接口
• 对齐命名
• 生成注释
• 输出 Markdown 文档
• 形成测试表格

这些事情并不难，但非常耗时间，而且会不断打断工程师的思路。

传统开发里，一个工程师经常一边想系统，一边写代码，一边还要顾着命名、格式、注释、结构一致性。这种多线程脑力切换，本身就很耗神。而现在，一种更高效的方式开始出现：先在对话里把系统讲清楚，再让 AI 去把“已经明确的规则”翻译成代码和文档。这样，人的脑力就集中在真正贵的部分——系统设计与工程判断。而 AI 去处理那些必须做、但不值得消耗太多创造性精力的部分。这就是为什么它会让很多工程师第一次真正体会到“效率被拉开了”。

---

三、在电源控制软件里，正确的协同方式是什么

电源控制软件不适合“想到哪写到哪”，更不适合“直接让 AI 生成完整工程”。

更合理的流程，应该是这样的。

1. 先定义系统目标和边界

在动手写代码之前，先把项目边界钉死。

例如：

• 控制对象是什么
• 控制平台是什么
• 输入输出范围是多少
• 启停条件有哪些
• 有哪些外部命令
• 是否涉及预充、继电器、母线管理
• 故障后是否允许自动恢复
• 哪些故障必须锁存
• 哪些故障只允许告警不关机

这一阶段，AI 可以帮你做需求梳理、缺项提醒和边界归纳。但还不适合直接写实现代码。

---

2. 先把状态机讲清楚

状态机是控制软件的骨架。这一步如果没讲清楚，后面代码写得越快，错得越快。

一个真正可落地的状态机定义，至少应该明确：

• 有哪些状态
• 每个状态的职责是什么
• 进入这个状态时要做什么
• 在这个状态里运行时做什么
• 什么条件下退出
• 可以跳到哪些状态
• 不能跳到哪些状态
• 如果出故障，该怎么处理

例如，一个常见控制状态机可能包括：

• PWR_FREEZE
• STANDBY
• GRID_CHECK
• PLL_LOCKING
• SOFT_START
• RUNNING
• STOPPING
• FAULT

表面上看，这只是几个状态名。实际上，真正决定质量的不是状态数量，而是状态职责是否单一。

比如：

• STOPPING
  
   就只负责停机动作，不负责待机
• FAULT
  
   就只负责故障锁存与故障退出条件
• STANDBY
  
   就只负责等待命令和监视输入条件

如果把这些职责混在一起，代码会越来越乱，后面再修会很痛苦。

这一阶段非常适合先和 AI 讨论。不是让它替你决定，而是借助它帮你做逻辑审查、漏洞扫描和表达整理。

---

3. 再定义命令、条件和故障体系

很多人写状态机时，只写状态，不写事件体系。这在小 demo 里还可以，在真实工程里迟早会乱。

至少要把下面三类东西分开。

命令，例如：

• 开机命令
• 关机命令
• 清故障命令
• 休眠命令

条件，例如：

• 电网正常
• PLL 锁定
• ADC 就绪
• 继电器反馈正常
• 软启动完成

故障，例如：

• 过压
• 欠压
• 过流
• 过温
• PLL 超时
• 继电器异常
• 采样异常

同时，故障优先级也应该明确。不是所有故障都一个处理方式，也不是所有故障都应该自动恢复。

这一阶段，AI 很适合做分类整理、命名统一、漏项检查。但故障哲学本身，还是要工程师拍板。

---

4. 先生成骨架，不要直接生成完整工程

这是一个非常关键的经验。很多人一上来就让 AI “生成完整代码”，结果很容易得到一份表面完整、实际充满隐含假设的工程。更稳妥的做法是：

先只生成这些内容：

• 状态枚举
• 状态机结构体
• 状态转移函数
• 每个状态的 handler 空壳
• 命令接口
• 故障接口
• 日志点预留

这样做的目的，不是省事，而是为了先审“骨架正确性”。

因为真正危险的，通常不是某一行寄存器没写对，而是：

• 状态职责是不是混了
• 是否有隐式跳转
• FAULT
  
   与 STOPPING 有没有混淆
• 进入和退出条件是否不闭环
• 有没有模型自己补的自动恢复逻辑

先把骨架审清楚，再让 AI 去填具体硬件动作，会稳很多。

---

5. 人工审查骨架，再填充硬件动作

骨架出来后，工程师一定要亲自看。

重点看这些问题：

• 某个状态是不是既做停机又做待机
• 某个状态能不能进得去出不来
• fault
  
   是否抢占正确
• 是否偷偷加入自动恢复
• 是否偷偷加入默认超时
• 是否偷偷新增了你没定义的跳转
• entry / run / exit
  
   是否清晰分层

只有这些都确认过了，再让 AI 去补：

• PWM 使能 / 关断
• 继电器控制
• ADC 检查
• PLL 判断
• 软启动斜率
• 控制环接口
• 故障锁存动作
• 日志与诊断接口

这样生成出来的代码，虽然还是需要继续审查，但整体可信度会高很多。

---

6. 让 AI 一起输出测试资产

这是很多工程师还没充分利用起来的一点。

AI 不只是可以生成代码。它还特别适合同时帮你生成：

• 状态跳转测试表
• 故障注入测试表
• 上板验证 checklist
• 调试日志点建议
• 参数边界检查表

这类产出在传统开发里通常被拖到最后，或者根本没人认真整理。但实际上，它们对提高调试效率很有价值。

一个成熟的协同方式，不应该只是“AI 帮我写 .c/.h 文件”，而应该是：

AI 帮我把设计、实现、检查、测试几件事一起串起来。

---

四、这种方式为什么特别适合电源工程师

有些人会担心：自己是偏硬件、偏系统的工程师，不是纯软件出身，是不是跟不上 AI Coding 这波变化？

我反而觉得，很多电源工程师的优势恰恰在这里。

因为 AI 最缺的，不是语法知识，而是工程约束感。而电源工程师最强的，正是这部分。

你比 AI 更知道：

• 哪些继电器动作顺序不能乱
• 哪些保护必须先硬件兜底
• 哪些故障绝不能自动恢复
• 哪些 ADC 偏置会带来误判
• 哪些停机路径如果不闭环会留下安全风险
• 哪些工况在实验室能过、量产却不一定稳

所以，对电源工程师来说，最理想的位置不是“把自己变成纯 AI coder”。

而是：

你懂系统、懂拓扑、懂硬件边界，再把 AI 变成你的实现放大器。

这比单纯会写代码更有价值。

---

五、需要警惕的几个风险

说完优点，也必须说风险。因为在控制软件场景里，AI 如果用错，副作用并不小。

1. 设计没收敛就开始铺代码

这是最常见的问题。状态机定义还模糊，fault 逻辑还没想清楚，就让 AI 直接大规模写实现。结果只是更快地产生结构化错误。

2. AI 会补你没授权的逻辑

它很喜欢“自作聪明”地加一些东西，比如：

• 自动恢复
• 默认超时
• 隐式清故障
• 默认初始化
• 额外状态跳转

这些在一般软件里可能只是风格问题，但在电源控制里，可能直接变成风险。

3. 代码整洁不代表时序正确

AI 生成的代码通常会看起来很规整。但“规整”不等于“安全”。

它并不会天然理解：

• 某个继电器需要多少机械延时
• 某个采样点位于 PWM 周期的哪个位置
• 主循环和 ISR 之间的数据同步是否可靠
• 某类 fault 发生后应该先关 PWM 还是先断继电器
• 某个启动过程里软启动和母线建立的先后关系是否安全

所以，时序分析和实机验证这两件事，谁都替代不了。

---

六、一个更现实的判断：AI 不会替代工程师，但会改变分工

这件事我越来越倾向于这样理解：

AI 不会替代电源控制工程师。但会非常明显地改变工程师的工作方式。

过去，一个工程师往往要亲自做两件事：

• 做系统设计
• 做大量实现铺设

而现在，更合理的分工正在变成：

• 工程师负责设计正确性
• AI 负责实现效率

这不是“偷懒”，也不是“能力退化”。恰恰相反，这意味着工程师把精力从低价值重复劳动里释放出来，投入到更重要的系统判断中。

对真正有经验的工程师来说，这种协同方式的收益会比新手更大。因为你越知道什么地方不能乱来，越能把 AI 用在最合适的位置。

---

七、我认为比较成熟的工作流

如果把上面的内容收敛成一句最实用的话，我的建议是：

先讨论清楚，再形成设计文本；先生成骨架，再人工审查；最后补实现、做测试、上板验证。

也就是：

1. 先定义系统目标和边界
2. 先讲清楚状态机
3. 定义命令、条件和故障体系
4. 输出结构化设计说明
5. 让 AI 生成状态机骨架
6. 人工审查骨架
7. 再让 AI 填充硬件动作
8. 生成测试表和验证清单
9. 上板调试并回写设计文档

这套流程不花哨，但很实用。而且越是工程化要求高的项目，越适合这样做。

---

八、结语

AI 在电源控制软件开发里的价值，不在于“替你写代码”这么简单。它真正的价值，是帮助工程师把已经明确的设计思想，更快地变成结构化代码、文档和测试资产。

但前提始终不变：

系统正确性必须由工程师主导。

所以，真正值得追求的，不是成为“纯 AI coder”，而是成为这样的人：

懂拓扑、懂控制、懂硬件、懂边界条件，也懂得如何用 AI 放大自己的产出效率。

这才是更稳、更强、也更有长期价值的方向。

---

边界说明

本文讨论的是“电源控制软件与 AI 协同开发”的工程实践方法。其中涉及的 AI 生成内容，不能替代以下工作：

• 功能安全审查
• 代码评审
• 控制策略论证
• 时序分析
• 仿真验证
• 实机调试与边界工况验证

任何用于真实产品的软件实现，都必须经过人工审核与验证后方可使用。

---

正文流程：

1. 明确项目目标与边界↓2. 定义状态机、命令、条件、故障体系↓3. 输出结构化设计说明↓4. 让 AI 生成状态机骨架↓5. 人工审查骨架与跳转逻辑↓6. 让 AI 填充硬件动作与模块实现↓7. 生成测试表、故障注入表、调试清单↓8. 上板验证、时序检查、边界工况测试↓9. 回写文档，形成可复用模板

• AI 适合：整理、生成、重构、检查、成文
• 人必须主导：状态职责、保护哲学、时序安全、实机验证

总结：

不要把正确性交给 AI，要把重复劳动交给 AI。