先给结论：边界写在纸上，量产才不返工
AI 硬件产品从 0 到量产，最常见的失败不是模型不准，而是软件、固件、云端三层的责任边界没落到文档上：谁改引脚、谁定协议、谁负责升级回滚、出了问题由谁定位。边界模糊的项目，问题往往拖到小批量试产才爆发，那时改一次结构或协议，代价是样机阶段的数倍。
结论：打样前先冻结三份接口契约——应用与固件之间的通信协议、固件与硬件的引脚时序表、设备与云端的数据与指令规范。三份文档齐了，换人、换供应商的交接成本会明显下降，这也是判断一个 AI硬件方案 能否按计划推进的分水岭。
四层分工边界怎么划
把产品拆成四条线，每条线只对一类产出负责，这张表建议直接放进合同附件。
| 层级 | 负责什么 / 交付什么 | 常见越界 |
|---|---|---|
| 应用与交互层 | App、小程序、Web 后台的交互与状态展示；交付状态机映射表 | 绕过固件直接读硬件状态 |
| 设备固件层 | 驱动、采样、时序控制、端侧推理调度；交付引脚时序表与寄存器表 | 在固件里写业务规则 |
| 云端服务层 | 设备身份、指令下发、升级管理、数据统计；交付 API 契约与错误码表 | 替设备做实时安全决策 |
| 硬件层 | 器件选型、电路、结构、散热、天线与电源；交付原理图、BOM 与替代料 | 改引脚不通知固件侧 |
越界的后果是问题不可复现：日志散在几个系统里，没人能还原完整链路。边界固定后，定位按层收敛——是采不到、算错了，还是发不出去。
概念验证：先跑通一条最短链路
样机阶段别一上来就做完整功能，先跑通一条最短链路：采样、端侧判断、上报一条数据、云端下发一条指令、设备执行并回执。链路通了说明四层接口对得上；不通，排查范围也小。
- 冻结主控与关键器件，附替代料清单，避免缺料后临时换型、重做驱动验证。
- 定义状态机：待机、配网、工作中、异常、升级五个状态足够，它是页面、日志、告警的共同语言。
- 写出协议 v0.1：字段长度、字节序、校验、超时重试、断线重连，先粗糙但固定。
- 打通云端最小闭环，再做破坏性测试：断网、断电、异常重启各跑一轮，设备侧与云端共用 trace 标识。
端侧跑模型要实测目标芯片的首帧延迟与内存占用，别拿 PC 跑分推算。
接口契约：引脚、时序与错误码
接口契约是软硬件之间唯一可信的沟通渠道。口头约定到小批量试产几乎必然失效。
引脚与协议先冻结，再谈优化
引脚表至少写清编号与复用、默认电平、上电时序、变更流程。改一次引脚要同步更新固件配置、产测工装与原理图，缺一处就会变成产线上的「个别批次不良」。
错误码要能定位到环节
错误码带三段信息：层级（应用、固件、云端、硬件）、类别（通信、存储、算力）、可执行动作。「采样超时」与「采样越界」必须分开，前者指向时序，后者指向传感器与标定。
接口文档要有守门人：由固件负责人合并变更，主版本改结构、次版本加字段。
云端边界：设备身份、升级与数据回传
云端至少要做三件不能外包的事：确认设备是谁、保证设备还能被修好、决定哪些数据值得传。
| 能力 | 最低要求 | 常见误区 |
|---|---|---|
| 设备身份 | 一机一密、密钥可吊销 | 全局共用一个密钥 |
| 固件升级 | 断点续传、校验失败回滚、按批次放量 | 全量直推且无回滚分区 |
| 数据回传 | 实时指标、批量统计分级上报 | 原始采样全量上云 |
| 指令通道 | 带有效期与幂等标识 | 丢弃指令却显示成功 |
端侧推理还是云端推理，是四个维度的取舍：响应时延、数据能否离开设备、网络稳定性、单位算力成本。带摄像头或语音的消费产品多走「端侧先判断、云端再复核」；工业质检这类节拍敏感场景，主推理必须放端侧，算力估算可参考站内AI 边缘计算硬件选型。
升级通道按最坏情况设计：升级中断电、弱网下载失败。双分区加校验回滚是最低配置，代价只是一颗更大的存储；量产之后才发现没有回滚，返厂升级的代价会高得多。
小批量试产：产测治具决定良率口径
从几十台到几百台是分界点：样机可逐台调，小批量必须有工装，否则良率无从统计。
- 烧录与序列号写入：上位机加夹具一次完成，序列号与设备密钥同时入库。
- 产测项固定：电源电流、通信自检、传感器标定、推理冒烟，逐项给阈值。
- 老化抽检：连续运行若干小时，记录重启次数与内存增长。
- 数据留档与返修回归：每台结果与固件版本入库，返修机重走产测。
治具本身也是软件项目，要有版本管理并随固件协议同步更新。把它当成产线上临时写的小工具，换型时就会变成最大的隐性成本；这类工作通常与嵌入式与软件开发一并交付。
软硬联调最常返工的五个环节
下面五种现象反复出现，共同点是「看起来像软件问题，根子在硬件或流程」。
| 现象 | 真正的原因 | 提前做的动作 |
|---|---|---|
| 屏幕偶发花屏 | 上电时序与刷新频率冲突 | 时序表留可调延时参数 |
| 语音唤醒率下降 | 麦克风阵列与腔体不匹配 | 结构与声学同步打样 |
| 升级后设备无法启动 | 分区无校验、无回滚 | 双分区加校验，失败回退 |
| 云端指令延迟、丢失 | 心跳、上报、指令抢通道 | 分优先级队列，关键指令带确认 |
| 量产批次数据漂移 | 传感器未标定，沿用样机参数 | 产测加标定工位，按批次统计 |
共同解法是把可观测性提前：设备侧日志缓冲、云端事件流水、固定的联调用例集。
成本与人力：边界清楚才能控住预算
预算分几块：器件与模具、认证测试、固件与算法人力、云端带宽、产测与售后备件。趣凡科技习惯逐项列清。容易失控的是带宽与售后，它们随出货量增长。三个做法：工作量按接口数量估算；联调返工单独列缓冲；运维写进单独的年度约定。
选合作方时可以问的五个问题
把 AI硬件方案 交给外部团队时，问下面五个问题比看案例更能判断对方是否做过整机交付。
- 会先交付哪三份文档？答不出接口契约、引脚时序、错误码表，说明习惯直接从代码开始。
- 固件升级有没有回滚方案？量产后怎么分批放量？
- 产测治具由谁做？治具与固件的协议怎么同步？
- 端侧模型能否在目标芯片上复现实测？首帧延迟与内存占用是多少？
- 上线后的版本维护与故障响应怎么约定？跨层问题由谁牵头？
趣凡科技在做AI 软硬件解决方案时，习惯把这三份文档列为第一个里程碑，再谈功能与排期；深圳的供应链密度也让打样与改版更容易压缩周期。整机从算法到现场的分工，可参考站内AI 软硬件一体化解决方案。
常见问题
AI 硬件方案从样机到量产一般需要多久？
取决于结构复杂度、认证范围与云端功能，没有统一答案。能压缩的是接口对齐与联调，容易被低估的是结构打样、认证排队与治具制作。排期按「打样、联调、试产」三段定更接近真实。
固件和云端可以交给两个团队分别做吗？
可以，前提是先冻结接口契约与错误码表，统一日志格式和 trace 规则。但跨层问题必须由一方牵头定位，合同里最好指定一个对端到端链路负责的角色。
端侧推理和云端推理怎么选？
看响应时延、数据能否离开设备、网络稳定性与单位算力成本。时延敏感或涉及画面隐私的优先端侧，模型频繁更新的放云端；多数产品适合端侧先判断、云端复核。
小批量试产为什么一定要做产测治具？
治具决定良率能否统计、问题能否追溯到批次、返修后能否验证。没有治具，良率只能靠人工感觉，批次异常也定位不到工序。
已有硬件，只做软件和云端可行吗？
可行，但先做现状评估：引脚接口是否开放、固件能否接管、传感器能否标定、有无调试口与日志。缺一项就得用补丁绕开，结论通常决定「接入」还是「重构」。