PCBA、固件与 App：项目交付前要对齐的责任边界
硬件交付不只是拿到一块板。用接口、版本、测试与变更四张清单，把方案团队、品牌方和生产端的协作边界说清楚。
一个智能硬件项目通常不止一家参与方：有人负责结构与装配，有人提供 PCBA 和嵌入式程序，还有人开发 App 或维护服务。问题往往出现在交接处，而不是单个模块内部。交付前把责任边界写具体，可以帮助各方更快定位故障，也让后续版本更新有据可查。
第一张清单：接口与数据含义
列出硬件接口、通信数据、操作命令、错误码和设备状态。除了字段名称，还需要说明单位、取值范围、默认值、更新条件与兼容方式。例如“强度”到底代表原始采样、处理后的等级还是执行输出，应在文档里区分。示例数据可以帮助双方发现对同一字段的不同理解。
第二张清单：版本与兼容关系
硬件版本、固件版本、通信协议版本、App 版本与生产测试版本，建议分别编号并记录兼容关系。交付包中保留可识别的构建信息与变更说明。若现场发现问题，先确定实际运行的组合，避免拿新文档排查旧设备。试产物料发生变化时，也应记录变更批准与对应验证结果。
| 交付范围 | 需要对齐的内容 | 建议确认人 |
|---|---|---|
| PCBA 与生产资料 | 物料、测试点、烧录与生产检测要求 | 硬件与生产负责人 |
| 嵌入式固件 | 状态规则、参数、异常处理、升级与恢复 | 固件负责人 |
| App 与业务交互 | 协议映射、提示、数据保存、异常页面 | App 与产品负责人 |
| 联合验收 | 测试环境、用例、通过条件、问题归属 | 项目各方共同确认 |
第三张清单：测试方法与交付证据
测试规范需要说明输入条件、操作步骤、预期结果与记录格式。对于产线检测，还应确认使用的工装、操作时间、失败后的复测方法和记录保存方式。交付证据可以是报告、日志或数据文件，但应能对应到具体设备与软件版本。不要把一份无法复现的演示录像当作全部验收依据。
第四张清单：变更与后续维护
项目上线后，仍可能发生器件替换、系统适配、功能调整和故障修复。应约定谁提出变更、谁判断影响、谁执行回归、谁批准发布。对于源码、生产文件、账号、签名材料和使用授权，交付范围以各方实际约定为准，不能仅凭“整套方案”推定包含所有资源。
- 每个交付文件写清名称、版本、用途与维护人。
- 每项未解决问题写清影响、负责人和下一次确认时间。
- 把第三方依赖、运行环境与必要账号列入维护清单。
- 明确异常排查需要的日志，并约定如何避免收集不必要的用户信息。
清楚的责任边界不是把问题推给别人，而是让问题出现时，团队知道该从哪里开始、由谁一起解决。