BSP这个词在嵌入式外包的报价单上出现频率很高，但很多项目到验收时才发现：双方对“交付什么”的理解从来没对齐过。扯皮基本都发生在这里，供应商觉得给过了，甲方觉得没收到。

这份清单把该有的东西列全。签合同前对照一遍，验收时逐项打钩。

先分清两样东西：镜像和源码

镜像是编译出来的产物，.img文件，能烧不能改。源码是改动的依据，内核要打安全补丁、换一颗物料、加一个外设，全得从源码来。

有的报价单写“交付完整系统”，到底交的是镜像还是源码，不问清楚，验收时才发现手里只有几个bin。拿到源码才算真正拥有这个系统，镜像只是它的快照。

交付物清单

三个最容易缺的东西

1. 源码。行业里默认给镜像、源码另算的情况真实存在，这不丢人，丢人的是不写清楚。报价单里“交付完整系统”这种表述，到验收时双方各执一词。要问的就一句：镜像和源码，交哪个，还是都交。

2. 编译文档。 源码一堆压缩包给过来，没步骤没说明，“在我们机器上能编”不算数。判断文档够不够的标准很粗暴：接手的工程师照着做，一遍过。补丁同理，一堆patch文件，不知道打在哪个基线版本上，等于白给。

3. 已知问题清单。 没有bug的系统不存在。不给清单的意思，就是这些问题留给你在量产前自己发现。敢把已知问题写出来的供应商，反而更值得签。

验收只要一条硬标准

复现编译。

拿到全部交付物，找一台没装过开发环境的机器或虚拟机，按文档从零编译一遍。产物能烧录、能启动、外设正常，这单才算交付完成。要求bit级别完全一致不现实，编译产物里带时间戳，但可以要求版本号一致、功能一致。

这项测试放在付款节点之前做。

清单要进合同

上面那份表整页贴进合同附件，验收标准写“复现编译通过”，别写“系统可运行”。可运行没法界定，复现编译可执行。

另外源码归属和使用范围，能不能二次修改、能不能给第三方，写在知识产权条款里。这几行字比验收标准还容易扯皮。

这份清单我们自己也用，接单时按单核对，交付时逐项打钩。