固定资产盘点系统项目里，真正容易让预算失控的往往不是业务功能写多少，而是硬件那一端。软件界面可以反复调整，需求也能分批上线，但 PDA 和读写器之间的底层协议一旦对不上，问题会在交付现场集中爆发：扫码没有响应、批量读取出错、数据上传丢包。此时再谈优化交互，已经没有意义了。
PDA 对接难的核心，在于“安卓应用开发”和“硬件协议适配”并不是同一件事。不少团队按通用安卓接口完成扫码功能，到了工业手持终端上才发现，不同品牌的射频读写模块通信指令并不统一，需要额外编写监听与适配逻辑。原文给出的量级很有参考价值：普通手机扫码大约 3 到 5 人天，适配工业级安卓 PDA 并编写激光扫头广播监听插件，通常要 5 到 8 人天。差距不在代码行数，而在于是否愿意把设备当成一个有脾气的外设来对待。
RFID 会把难度再抬一个台阶。多标签防碰撞、信号滤波去重、射频功率动态调节，这些都不是“扫一下返回一个编号”能覆盖的。软件端若缺少数据过滤中间件，隔壁房间的设备被误读入库并不罕见；金属反射、液体吸收则会让漏盘率在部署后才暴露。这两类问题的共同点是：它们在办公室的演示环境里几乎不会出现，却在真实库房和车间里成为主要验收障碍。
风险还会顺着协议往上游传导。识别介质选错、标签类型不合适，返工的不只是软件参数，还可能包括已采购的硬件。若项目还要求离线盘点、重连后双向合并数据，后端架构需要重新设计，预算自然会往上走。采购环节另一个隐蔽点是授权口径：终端接入数量、资产总数是否阶梯收费，源代码是否交付，次年技术支持如何计价，这些条款不写清楚，前期低价就只是把成本推迟到了运维阶段。
务实的做法是把硬件清单前置到立项阶段：明确 PDA 型号、读写模块类型、标签使用环境、盘点频次与网络条件，再让开发方基于这套物理环境评估工期。软件功能可以靠需求文档约束，硬件协议只能靠早期验证和现场测试兜底。把这一步做扎实，比在报价单上反复压价更能守住预算。
