售货机项目最容易误判的地方，是把“机器能卖货”当成“机器适合接软件”。前者在厂商自己的演示程序里跑通就可以，后者却要面对商品、订单、支付、出货、退款、库存和设备告警之间的一整套状态变化。现场网络会断，货道会卡，光检会误报，控制板会重启。正常流程谁都能演示，联调能力往往要到第一次异常时才看得出来。
站在红数科技这样的软件服务方位置，我们判断硬件厂商时，先看一件很朴素的事：软件发出指令以后，机器到底做了什么，系统能不能知道，而且双方能不能根据同一份记录把问题说清楚。
“支持 MDB”不等于软件接口已经具备
截至 2026 年 7 月，NAMA 公开的 MDB/ICP 文档版本为 4.3，发布于 2019 年 7 月。它规定了总线通信格式、时序、供电、连接器，以及纸币器、硬币器、无现金支付设备等外设与售货机主控之间的通信方式。欧洲自动售货与咖啡服务协会（EVA）在 2026 年 5 月更新的技术标准页面中也明确，EVA-DTS 用于售货机、支付系统与计算机端记账和管理系统之间的数据传输，并强调不同厂商设备采用共同标准，才便于统一读取和管理。
这些标准很重要，却不能替硬件厂商回答所有联调问题。MDB/ICP 主要解决机器内部主控与外设怎样通信；手机端、售货机屏幕应用或云平台怎样调用主控板，常常还要经过串口、USB、RS-485、TCP 或厂商自己的 SDK。数据怎样上云，又可能使用 HTTP、MQTT 或另一套私有协议。只说一句“支持 MDB”，软件团队仍然不知道自己接在哪一层。
厂商需要把接口边界讲到可以动手的程度：谁是主机，谁是从机；使用哪一个协议版本；串口参数、字节序、校验方式、超时和重试怎么定；货道号与商品号怎样对应；一条出货指令会返回哪些中间状态；断线重连后，上一笔指令是继续、取消，还是需要查询。涉及无现金支付时，还要确认厂商实际支持的功能级别，是否覆盖取消、失败、补退款或多商品交易，而不是只证明读卡器能亮、能扣一笔钱。
一份能用于开发的协议文档，至少要带版本号、修订记录、完整命令表、字段说明、状态码、报文示例和错误处理。只有几张聊天截图，或者必须让厂商工程师远程改程序才能跑起来，这种接口很难支撑后续迭代。最好还能提供控制板测试套件、串口调试工具或模拟程序。软件工程师不必每改一行代码都守着整机，联调速度会快很多。
联调别只点一下出货，要把一笔订单跑到底
现场验收不要停在“点击商品，电机转了”。应从软件创建订单开始，连续核对价格下发、支付结果、出货指令、货道动作、传感器判断、订单终态、库存变化和退款处理。每一步都要有可核对的设备号、订单号、货道号、时间和结果。
出货成功并不等于电机转过一圈。弹簧货道、履带货道、升降机和格子柜的成功判定并不相同。项目用了光检、掉货检测、门锁反馈或取货口检测，就要明确哪个信号代表“已经交付”，哪个只能说明“执行机构动过”。如果硬件只能返回“命令已接收”，软件却把它当成“用户已拿到商品”，退款和库存很快就会对不上。
随后要故意制造问题。拔掉网络后下单，出货过程中让控制板断电，堵住货道，让传感器持续被遮挡，重复发送同一个订单，延迟回调，再让设备恢复。冷藏机还要看温度越界、压缩机故障和门长时间未关时能否上报。带升降机构的机器，应测试升降台不到位、取货门未开和防夹信号异常。
这些测试不是为了难为厂商，而是把退款责任和订单状态提前说清。一次出货命令超时，可能是机器没收到，也可能是商品已经掉下去但回包丢了。合格的方案不能靠再次盲目出货来碰运气。主控板应能查询最近指令或出货结果，软件端也要用订单号、设备事件号或双方约定的唯一标识防止重复执行。
看日志，往往比看演示更准
一台适合联网运营的售货机，至少要让技术人员查到设备启动、网络状态、指令接收、货道动作、传感器结果、故障码和固件版本。日志时间应当能够和服务器时间对上，否则软件说 10 点 03 分下发，主控说 10 点 06 分才收到，双方连同一笔问题都找不到。
再问厂商一个具体问题：设备已经铺到外地后，怎样拿到这台机器最近一次失败出货的原始记录？如果答案仍是“让现场拍视频”“重启看看”，这批机器铺得越远，排查一次问题就会越慢。远程日志不一定越多越好，但关键状态不能只留在某位工程师的电脑里，也不能因为主控重启就全部丢失。
故障码也要稳定。代码 12 今天代表电机超时，下个版本不能悄悄变成门锁异常。新增和废弃状态必须进入修订记录，软件才能做兼容。拿不到状态码表，或者厂商坚持所有异常只回一个“失败”，运营后台最后只能看到一片红点，没人知道该补货、换电机，还是联系网络服务商。
固件和批量交付，决定联调成果能保留多久
样机联调通过以后，还要锁定主控板型号、硬件版本、传感器配置、线束定义和固件版本。量产机器换了芯片、换了电机驱动或调整了货道板，通信时序和故障反馈都可能跟着变化。厂商可以因供应链调整物料，但应提前给出变更说明和兼容性结论，必要时重新做回归测试。
固件升级要能回答四件事：升级包怎样校验，失败后能不能恢复，是否支持小批量灰度，旧版本是否可以回退。只允许全量强制升级、又没有回退办法的设备，不适合直接铺到生产环境。升级之后还应保留设备序列号、货道配置和必要的业务参数，不能让运维人员逐台重新设置。
序列号本身也不能随便生成。EVA 在数据传输标准页面中专门说明，设备编号需要避免不同制造商之间出现重复，并维护制造商前缀代码。国内项目未必直接采用同一编码方式，但原则一样：整机、主控板和关键部件要有稳定、唯一、可追溯的身份，软件平台不能上线后才发现两台机器报着同一个编号。
批量一致性最好用抽检说话。同批次随机拿机器刷入约定固件，跑同一套指令和故障用例，检查返回报文、传感器逻辑和线束接口是否与样机一致。样机由研发手工调过，量产机却来自另一套物料和配置，这类问题靠合同里的“同等品质”很难查出来。
合作态度要看责任能不能落到人
联调期间，销售愿意拉群不算技术支持。需要确认硬件、固件、协议和现场电气问题分别由谁判断，问题单在什么时间内首次响应，什么情况下需要寄板、换件或到场。这里不必追求不现实的“随叫随到”，但至少不能让软件团队在硬件、支付和设备厂商之间反复转述。
支付边界尤其要写清。谁对接支付终端，谁保存交易标识，扣款成功但未出货由谁发起退款，设备离线时允许不允许交易，相关密钥和证书由谁保管。若项目接入银行卡受理环境，PCI DSS 4.0.1 提供的是保护支付账户数据的技术和运营基线；如果只使用第三方聚合支付，也不代表可以把密钥明文写进应用或让所有机器共用一个固定口令。
软件与硬件的安全责任同样不能空着。设备应有唯一身份，生产环境关闭不必要的调试入口，远程指令需要鉴权，升级包需要验证来源。采集会员、摄像头或其他个人信息时，只保留业务确实需要的字段，并在项目合同和产品设计中明确谁处理、保存多久、怎样删除。硬件厂商未必承担全部合规责任，但必须把设备和 SDK 实际采集、上传的内容讲明白。
签批量采购合同前，先拿这张表去验机
| 要查的事情 | 现场要看到的证据 | 不能接受的回答 |
|---|---|---|
| 接口能否开发 | 带版本号的协议或 SDK 文档、报文示例、调试工具 | “都支持，买回去再对” |
| 订单能否闭环 | 支付、出货、检测、失败和退款状态能逐笔对应 | “电机转了就算成功” |
| 异常能否恢复 | 断网、断电、卡货、重复指令测试后状态一致 | “重启以后一般就好” |
| 问题能否定位 | 可导出的设备日志、稳定故障码、统一时间 | “拍个视频发群里看看” |
| 版本能否管理 | 固件清单、变更记录、兼容范围、回退方案 | “同型号都一样，不用记版本” |
| 量产能否一致 | 样机封样、物料变更通知、批次抽检结果 | “元件会换，但功能差不多” |
| 责任能否落实 | 技术责任人、问题单流程、备件与换件规则 | “有问题先找销售” |
实际项目可以先用一台控制板或一台样机完成协议验证，再拿接近量产配置的整机做异常测试。进入小批量试运营后，重点看失败出货、离线恢复、日志完整性和版本一致性，而不是只统计卖出了多少单。所有关键问题关单后，再放大采购数量。
还有几种信号，出现一个就值得暂停：厂商拒绝交付接口文档，只提供自己的演示软件；必须先下大单才安排技术联调；协议和固件没有版本号；异常状态全部返回同一个失败码；硬件改版不通知；同一问题每次都由不同的人给出不同解释；支付成功、出货失败时没人愿意承担退款链路。
硬件厂商适不适合联调，最终不靠印象判断。能把接口说清、把异常复现、把版本锁住、把日志拿出来，再把责任落到具体人员，这样的厂商才有条件陪项目走到批量运营。机器外观、报价和交期当然要谈，但在软件真正接进去之前，它们都不能替代这几项验证。
