一套覆盖嵌入式产品产线管理全周期的链路系统多客户固件管理、设备与配件烧录、序列号与入库、出库与质保、维修与质量追溯再加上仓库 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 · 把脑洞焊到电路板上