# 我把嵌入式开发做成了一条AI产品线：一个人的软硬件协同工作流
做嵌入式越久，我越发现：真正难的往往不是写一段驱动，也不是单独画一张原理图，而是把一个模糊想法稳定地变成可以交付、可以量产、以后还能继续维护的产品。
尤其是个人开发者或小团队，经常需要一个人同时面对客户需求、方案选型、原理图与PCB、固件开发、样机联调、测试和交付。任何一个环节的信息断掉，后面都会用返工来买单。
所以最近我做了一件事：把自己常用的嵌入式开发经验，整理成一套运行在本地的 **嵌入式AI工作流**。
它不是一个“帮我生成代码”的提示词，也不是简单堆叠几个AI工具，而是尝试搭建一条真正有角色、有分工、有交接的嵌入式产品线。
## 这套工作流里有哪些角色？
目前我把核心能力分成三类角色。
### 1. 资深嵌入式产品经理
负责理解客户真正想解决的问题，把零散、模糊甚至互相冲突的描述，整理成完整的功能框架、控制逻辑、异常场景和验收方向。
它的价值不是“写一份好看的需求文档”，而是在画板和写代码之前，尽量发现那些后期一定会造成返工的问题。
### 2. 资深嵌入式硬件工程师
负责硬件方案、电路设计、原理图评审、PCB Layout评审以及硬件风险识别。
因为我的PCB工作主要使用嘉立创EDA，所以这部分还结合了本地EDA能力，希望以后能够围绕真实工程进行分析，而不是只看一张截图给出泛泛建议。
### 3. 资深嵌入式固件工程师
负责嵌入式源码、工程构建、烧录调试、固件输出、Bug定位和风险检查。
我的日常开发以STM32为主，因此整个软件角色也会围绕实际的STM32、FreeRTOS、外设驱动和工程维护场景持续完善。
## 三个AI角色不是简单排队
这套工作流最重要的思路，不是让三个角色各做一段任务，而是让它们围绕同一个项目持续协作。
整体路径可以概括为：
```text
客户想法
↓
需求澄清与功能逻辑
↓
软硬件边界与接口约定
↓
电路、PCB与固件并行开发
↓
样机联调与问题归因
↓
测试、发布与量产资料
↓
后续维护与版本迭代
```
每个环节都需要明确：上一步交付了什么、当前角色负责什么、下一步凭什么可以开始。
这样做的目的，是减少嵌入式项目里最常见的几类问题：
– 客户说了一句话，开发人员却有三种理解；
– 硬件和软件使用了不同版本的接口定义；
– 原理图能通过检查，但上板后仍然反复飞线；
– 代码能够编译，却没有可重复的固件交付过程；
– Bug改完了，但没有留下复现和回归依据；
– 项目隔几个月再维护，已经没人敢动。
## 为什么要把它做成本地工作流？
我希望沉淀的不只是一次对话结果，而是一套可以反复使用、继续扩展的个人研发系统。
新项目进来时，它能快速建立统一的工作入口；老项目接管时，它能先梳理当前状态，再决定如何修改；以后增加新的MCU平台、硬件工具或测试能力，也可以接入同一条产品线，而不是推翻重来。
更重要的是，项目经验不再只留在某一次聊天里，而是逐步变成自己的角色定义、工作规则、项目模板和检查思路。
## AI会替代嵌入式工程师吗？
我目前的答案是：不会，但会明显改变工程师的工作方式。
真实电路仍然要上电，波形仍然要测量，PCB仍然要结合EMC、热和生产条件评审，固件也必须经过真实编译、烧录和目标板验证。
AI更适合承担的是：整理信息、补全思考维度、维持流程一致性、主动检查遗漏，并把个人经验转化为可复用的工程方法。
最终的判断、测试和责任，仍然属于工程师。
## 后续我会继续分享什么？
这篇先只介绍整体框架，具体内部实现暂不展开。后面我准备结合真实开发场景，继续分享：
– 如何让AI产品经理深度拆解嵌入式需求；
– 如何组织一次原理图和PCB评审；
– STM32固件工程如何与产品需求、硬件接口对齐；
– 新项目和老项目分别应该怎样接入工作流；
– 如何让AI输出真正能交接的工程资料，而不是一堆看起来正确的文字。
如果你也在做嵌入式开发，尤其是经常一个人同时负责需求、硬件和软件，可以关注这个系列。
我会继续把这套 **嵌入式AI产品线** 从思路、模板到实际案例逐步整理出来。
