一套覆盖嵌入式产品产线管理全周期的链路系统：多客户固件管理、设备与配件烧录、序列号与入库、出库与质保、维修与质量追溯，再加上仓库 PDA 里的蓝牙入库、二维码打标和扫码出库，都收进同一本账。本文先讲这条链路具体怎么走，再讲我怎样用 AI 工具探索需求、用 Pencil 承载界面设计、用 BMAD 拆 Epic 落地，并在上线后持续维护，把它做成多客户 SaaS。
鸿尘客 Honchic · 全栈开发 · 2026-09-01
一块嵌入式板子焊好、通电，离「一台能发给客户的设备」，还差好几道手续。
得认出它是谁，烧上这个客户该用的固件，写一个不会重号的序列号，登记入库，再贴上一张能扫的二维码标签。出库的时候要扫一下码，记下发给了谁，质保到哪天。发出去以后它要是坏了，还得知道坏的是什么，修过几回，值不值得再修。
这些手续，我做成了一套云端系统，叫它嵌入式产品产线管理全周期链路系统。从烧录一直管到报废，每个环节都记在同一本账上。
| 环节 | 系统做什么 | 对应页面 |
|---|---|---|
| 烧录 | 识别设备，刷固件，写序列号，回读确认 | 设备操作、配件烧录 |
| 固件 | 按客户、按型号管理多个版本，配件每个客户一份当前固件 | 固件管理 |
| 客户与权限 | 客户档案，客户自己的账号，九种角色 | 客户管理、用户管理 |
| 库存与售后 | 设备状态流转，可用库存，出库质保，错误码与维修 | 数据预览、设备历史、出库设备、维修历史、质量分析、错误码字典 |
| 仓库现场 | 蓝牙连设备，入库打标签，扫码出库 | 仓库 PDA 应用 |
客户有自己的账号，只看得到和自己有关的东西，多少有点 SaaS 的样子。前半篇讲这条链路具体怎么走，后半篇讲我怎么靠 AI 工具、Pencil 和 BMAD 把它做出来，又一直养着它。
烧录，一块板子怎么变成设备
接上一块板子，设备操作台先问它是谁。串口答得上来，就读型号、固件版本和 MAC。答不上来，就改去读芯片 Flash 里的 NVS 分区。读到的结果归成三种状态，全新设备、固件已烧录、序列号已写入，按钮能不能点，下一步做什么，都跟着状态走。操作员不用自己判断这块板子走到了哪一步，界面替他想好了。
刷固件的时候，系统自动取该型号当前可用的最新固件，没有可用固件就不让开始。写序列号更讲规矩，格式是型号、年月加五位流水号，重号写不进去，MAC 已经在库里的设备必须沿用原来的序列号。写完回读确认，再登记入库。右下角还有擦除 Flash、发起维修和报废设备，设备从产线走向售后，用的是同一个入口。
配件是另一条线。手环和三类遥控器同样是 ESP32-S3，走单独的一页。接上 CH340 串口自动识别，选好所属客户，擦除后整包写入，地址和波特率都是固定的，不用手填，也就没有填错的机会。
固件，跟着客户走
多客户这件事，最先落在固件上。设备固件按客户、再按型号分开放，每个型号保留多个版本，并标出哪个是最新。配件固件更省事，每个客户每一类只留一份当前固件，上传就是替换，连版本名都不用起。
上传的时候，系统按文件名识别型号和版本，比如MiniY_v4.1.0.bin，识别结果摆出来让人确认，型号和主版本对不上的，当场拦下。目前支持九种设备型号，固件的主版本和型号一一对应。
客户与权限，让它成为 SaaS
客户管理页记着客户阶段，是已签合同还是意向客户，归哪位业务员，启用还是停用。
客户账号一旦绑定到某个客户，角色就不能改。它登录以后，只能刷属于自己的固件，序列号也由云端按客户范围锁定。内部一共有九种角色，从超级管理员、生产管理员、销售管理员，到维修技术员、库存管理员和访客，再加上客户。权限矩阵集中放在一处，范围由后端强制，前端只是同步，光把菜单藏起来，不算授权。
库存、出库与售后，同一本账
设备在系统里只有一条路可走。已刷固件，已入库，已出库，出了问题进入维修中，修好了重新出库，修不好就报废。每一步还限定了谁能点，入库只有超级管理员、生产管理员和库存管理员，维修相关的流转才轮得到维修技术员。入库和出库这两步，在仓库里是用手持的 PDA 完成的，后面单独讲。
数据预览把这条路上的存量摊开，设备总数、可用库存、锁定客户库存和已出库四张卡，再加一条新增与出库的趋势线。这张的侧边栏比前面短，换个角色登录，看到的菜单就不一样。
设备历史里，序列号或 MAC 一搜就到，状态、型号、高级筛选和导出都在同一页。每次状态变化记一行，从哪个状态到哪个状态，是谁点的，都写着。
出库设备把每一台设备和客户、质保连起来，质保到期时间跟在出库时间后面，页面上直接分成质保中、已过质保、无质保信息。
故障这边，设备读出来的错误码，对着错误码字典翻成人看得懂的描述，进设备历史。维修记录可以关联之前的错误码，维修完成以后，相关错误码自动标为已解决。质量分析再把这些记录汇成故障率、趋势和错误码分布。
最后一块拼图，仓库里的 PDA
设备在产线上烧完固件、写好序列号，下一站是仓库。仓库里的人不坐在电脑前，手里拿的是 PDA，所以链路的最后一块，是一个跑在 PDA 上的 Android 应用，库存管理员主要用它。它只干三件事，蓝牙连设备，入库打标签，扫码出库。
蓝牙连上，再去云端问一句
入库从蓝牙开始。应用搜索 30 秒，弹窗右上角挂着倒计时，只列出名字以已知型号开头的设备，Mini、Pro、Max，加上 Y 系列和 Child，别的蓝牙设备一概不显示。点一台连上，5 秒内连不上就报失败。连上以后，应用每隔 5 秒问设备要一次信号强度，设备走远了或者悄悄掉线了，应用很快就知道，不会对着一台已经断开的设备继续操作。
连上拿到 MAC，马上去云端查这台设备，云端说了算。只有状态还是「已刷固件」的设备才允许入库，已经入库的，应用会把原来的标签调出来，可以补打。
入库，顺手把标签打出来
入库页除了蓝牙连接，还留了一个扫描标签的入口，给已经贴过标签的设备用，扫一下一样能认出它。
点入库，云端把设备转成已入库，同时返回一段标签内容，应用据此生成二维码，用 PDA 配套的打印 SDK 打出来。标签上是设备名称和一个二维码，坐标是绝对定位的，专门为了不多走纸，打印十秒没有回音就算超时。
二维码里装的是一段带版本号的 JSON。这个格式还单独写了一份说明，给下游客户的系统集成方看，要求用 JSON 解析器读，不要按位置截取字符串，因为后续版本可能加字段。应用自己的解析器也留着两种竖线分隔的旧格式，之前打出去的老标签，照样扫得出来。
出库，扫一下就对上客户
出库靠扫码。PDA 自带扫码头，按下扳机，扫码结果通过系统广播交给应用。1.2 秒内的重复扫描会被忽略，同一时刻只处理一次，免得手一抖出库两次。
码值解出 MAC，云端查到设备，再给出能选的客户。刷过某个客户固件的设备，只能出给那个客户，别的客户根本不在选项里。客户本身也有门槛，不存在的、没启用的、没签合同的客户，出库都会被拒绝。再填一个质保月数，默认 12 个月，填 0 表示无质保，下次自动记住上一次填的。设备必须是已入库状态，才能提交。
一车货发给同一个客户，就开批量模式。先选客户、质保月数和台数，再一台台扫，应用数着还剩几台。扫到一台只能出给别的客户的设备，会弹出不匹配的提醒，不会悄悄混进这一批。
提交以后，云端把设备改成已出库，记下质保，再留一条出库流水，操作人和「来自 APP」都写着。应用里还有一页看板，按本日、本周、本月、本季度看入库和出库的数量，明细能按型号、日期和 MAC 关键字筛选，每个人看到的，是自己的操作记录。
PDA 上做的每一次入库和出库，回到桌面端，都出现在设备历史和出库设备里。从烧录到报废，这条链路上没有哪一步靠口头交接。
把几块拼在一起，大概是这个样子。设备操作留在桌面端和 PDA 上，业务数据只走云端。
这套链路是怎么做出来的
这么多环节，不是一开始就想清楚的。我让三样东西各管一段。AI 工具加 BMAD 的流程，负责把需求问透。Pencil 负责让界面有图可依。Epic 和故事负责把它拆开，一件件落地。上线以后冒出来的零碎需求，交给 spec。
需求，先让 AI 问透
起点是一份产品简报，问题只有一句话，设备的烧录和售后维修没有系统化的管理手段，错误数据没法追踪，也没法做质量分析。
后面的功能，大半是 AI 帮我问出来的。BMAD 的头脑风暴工作流，用五个为什么、形态分析、角色扮演和失败分析四种方法，一轮下来生成了 115 个想法。我从里面留下的结论很具体：设备要有一套严格的状态机，转换规则写死；维修要分级处理；MAC 和序列号的绑定与变更要受控。前面那条从已刷固件走到报废的路，就是从这里长出来的。
PRD 把这些整理成功能需求，编号一路排到 FR60 以上，UX 规范里的弹窗直接标着对应的 FR 编号。需求、界面和故事，因此能互相对上。仓库管理员这一端也是同样的路子，单独有一份 PRD，写了七条用户旅程，从正常入库、遇到非法状态，到扫码出库、改密码。
界面，让 AI 照着 Pencil 的图做
UX 阶段，AI 先给出几个界面方向，选定的方向 A 落成了 Pencil 设计稿。这一步不是一页一页临摹，而是顺着需求，把整套页面一口气排出来。
桌面端是一个文件，三十多个画板。上半是登录、设备操作、设备历史、设备详情、用户管理、质量分析、固件管理、错误码管理这些页面，下半是烧录成功和失败、序列号确认、删除确认、高级筛选、维修记录这些弹窗。需求里每一条会走到的路，包括走不通的那一条，都有一张图在等着。
PDA 端是另一个文件，二十三个画板，六个页面加十七个弹窗。蓝牙搜索、连接失败、打印失败、扫码失败、设备状态不符、权限不足、登录过期，这些出了岔子才会看到的界面，也提前画好了。底部 Tab 的激活色各不相同，入库蓝，出库绿，数据紫，我的橙。
画板排出来以后，最关键的一步，是给每个界面留编号。
UX 规范末尾有一节 Pencil Design Assets，列了七个页面和三十一个组件的节点编号，每一行都对着具体的故事。设备操作页是PiUVE，质量分析页是REwJc，侧边栏是wWWg6，删除用户的确认弹窗是Ok84e。
然后是约定。AI 做界面类的故事，动手之前要做四件事：
- 用 Pencil 的 MCP 读对应节点的属性，尺寸、颜色、间距、字体、圆角。
- 截一张设计稿的图，当对照基准。
- 取设计变量，颜色和间距不自己编。
- 写完以后再截一次图，回来对一遍。
epics.md里把它写成了强制规则，禁止凭记忆或者目测截图去实现界面，节点属性是唯一依据。
设备操作页是个好例子。项目里留着一份当时让 AI 写的对照报告，把PiUVE的属性一条条列出来。侧边栏宽 240，信息卡内边距 24，右边的操作区固定 280 宽，三个按钮各有各的身份。刷固件是橙色，高 48。写序列号是主按钮，蓝色，高 56。读取错误码是白底蓝边。把设计稿和现在的设备操作台放在一起看，橙色刷固件，蓝色写序列号，描边的读取错误码，次序和颜色分工，还是PiUVE里那一套。后来多出来的擦除 Flash、发起维修和报废设备，都排在原来的按钮下面。
设计稿也不是一次对齐。Epic 9 里有一次提交，专门修维修记录表单和设计规范不一致的地方。节点编号只能让对照变容易，对照这件事，还是得有人真去做。
PDA 这一端把这套办法用得更彻底。设计稿先画好，再让 AI 从设计稿反推出一份一千两百多行的交互规格，PRD 按它改了一轮，故事逐个对到节点。先有图，再有规格，顺序反过来，也一样走得通。出库页的设计稿里没有选客户，也没有批量模式，这两样是后来加的。
BMAD，拆成一件件能交付的事
设计和需求都有了，BMAD 负责让它们稳步落地。PRD 之后是架构，再之后是 Epic 和故事。
桌面端拆出了十一个 Epic，从项目基础与用户认证、设备检测、序列号刷写与入库，到固件烧录与版本管理、设备状态机、维修与故障、废弃设备，一共五十六个故事文件，每个故事自带验收标准。拿 Epic 9 来说，维修与故障管理，十个故事，二十四条验收标准，逐条过。PDA 端另有五个 Epic、二十二个故事，登录、入库、出库、数据看板和个人中心各占一个。
开发、代码审查和回顾各有各的工作流。sprint-status.yaml的注释还建议，代码审查换一个全新的上下文，最好再换一个模型，免得自己审自己。每个 Epic 收尾留一份回顾，桌面端的 Epic 1 到 10 都有。
账不是每次都干净。Epic 9 的回顾是自动执行的，十个故事全写着 done，故事文件里的状态却还停在 review 和 ready-for-dev。有的 Epic 干脆整个退了场，系统早期是单机本地库，数据迁移与备份那两个 Epic，随着本地数据库一起拿掉了。AI 流程里，文档和现场对不上是常事，后面那份给 AI 看的规则文件，就是为这个准备的。
上线以后，靠 spec 继续往里加
主体落地以后，需求变得零碎。客户要自己刷固件，销售要分权，型号从五种变成九种，桌面端要能在线更新。再走一遍完整的 PRD 太重，我换成 BMAD 里偏轻的一条路，先写一份 spec，批准以后再动手，再审查。
BMAD 官方文档里有一张交付循环图，画得很直白。想法还模糊，从澄清开始。想法清晰，进规划。改动很小，直接构建和验证，做完再回头调整计划。
图出自 BMAD 官方仓库，MIT 许可。我后半程的需求，大半走的是第三条，改动小，直接构建和验证。
项目里有十二份这样的 spec，客户与分级管理员权限、九种设备型号、客户空设备刷固件、客户序列号继承、Windows 在线更新，都是这么一份一份加出来的。结构基本一样：
## Intent ## Boundaries & Constraints ## I/O & Edge-Case Matrix ## Code Map ## Tasks & Acceptance ## Verification最上面的 Intent 被框在一个标记里，写着 human-owned intent，批准之后 AI 不许改。Boundaries 分三档，Always、Ask First、Never。
拿「客户空设备刷固件」这份来说。客户把设备擦干净以后，设备里的固件版本、MAC 和序列号全是空的，而刷写之前要先解析出 MAC，于是真正的空设备反而刷不了。这份 spec 的 Never 一栏写得很干脆，不把读取失败当作空设备，不信任渲染进程提交的客户范围，刷后身份解析成功之前不开放写序列号。
边界矩阵里的几行，比一段功能描述有用得多：
| 场景 | 预期行为 |
|---|---|
| 真正的空设备 | 创建临时会话，刷写本客户该型号的固件，刷后解析身份 |
| NVS 读取失败 | 不刷写，设备保持原状并显示明确错误 |
| 固件已刷，网络暂断 | 保持「已刷写、待解析」，重试只补解析，不再次擦除或刷写 |
最后一行是为刷机专门留的。刷机这件事没有撤销键。
另一份 review 记的问题更隐蔽。客户写序列号，设备其实已经写进去了，桌面端却报超时。review 把原因追到了串口通信那一层，每条命令先写数据，隔 100 毫秒才挂上响应监听器，第二条命令的 OK 回得太快，监听器还没挂上，就被漏掉了。修法是每次写序列号都开一条新连接，只发这一条命令，另外补了六条回归检查。
这类问题 AI 找得出来，也肯老实记下来。deferred-work.md里就躺着还没修的几条，串口、NVS 和 esptool 之间还没有按端口互斥，NVSReader没有超时，创建用户在并发下可能撞上唯一约束。spec 的任务清单里还单独留了一项，真实设备验收。硬件相关的行为，自动检查覆盖不全，最后还是要接上真机。
还有一份project-context.md，三十一条规则，专门给 AI 看。最要紧的一条是，不要重新引入本地 SQLite 和dbIPC，业务数据一律走云后端。旧文档里残留的 SQLite 描述，AI 读到了很可能照做，这份文件就是拦在它前面的牌子。它自己也写明了，文档和代码冲突，以代码为准。
留下来的，和没灵的
| 做法 | 留下来的好处 | 要付的代价 |
|---|---|---|
| 节点编号对照表 | 设计稿、故事和代码能互相查到 | 对照得有人真去做，设计稿改了表也要跟着改 |
| 冻结意图的 spec | 必须先问人的事，写在了纸上 | 小改动也写一份，不划算 |
project-context.md | 旧架构不容易被 AI 当真 | 技术栈一变，就得人手更新 |
| 每个 Epic 一份回顾 | 当时卡在哪，翻得到 | 自动回顾和故事状态会对不上 |
没灵的部分也记一笔。桌面端的前端没有成熟的自动化测试基线，project-context.md里写得明白，后来补上的，是scripts目录下一批针对具体问题的回归脚本。后端有三十八个测试文件，守得住权限和状态机，守不住真实设备上的那些毛病。
PDA 那一端更是如此。单元测试有五个测试类，管出库错误提示、数据看板、型号和查询结果的解析、HTTP 错误映射，蓝牙、扫码头和打印机，只有接上真实的 PDA 才验得了。代码里扫码软触发的广播动作，还留着一句「需要确认具体值」的注释，这种和厂商 SDK 绑定的细节，文档也救不了。
回到那块板子
开头那块板子，现在从认出它、烧上固件、写下序列号，到蓝牙连上入库、打出标签、扫码出库，再到维修、报废，每一步都有账可查，每一步该谁点，也有规矩。
AI 写了这么多页面和接口，我靠什么确认它没跑偏，答案藏在一串五个字母里。PiUVE，设备操作页的节点编号。设备操作台后来长出了擦除 Flash，长出了维修和报废，多了客户和九种角色，后台也整个搬进了云端，那三个按钮的颜色分工，到现在还是原来的样子。
我没法说每一次都做到了回头对照。能说的是，这套东西让「回头」有地方可去。AI 负责把需求问透，Pencil 让每个界面有编号可查，BMAD 让每件事有名字、有验收。三样都不负责写对，只负责让「对不对」有处可查。脑洞先落地，细节慢慢打磨。
鸿尘客 Honchic · 把脑洞焊到电路板上
