仪器“全量直采”在方案书里常常只写一句话，到了实施阶段却可能占掉LIMS预算的三分之一甚至更多。评估这件事的技术可行性，起点是先把“全量”拆成一份可以逐台核对的清单，不必先问“能不能采”。
拆解的第一个维度是协议族，也就是按通讯方式来分组，简单按设备台数来算并不合适。同一品牌、同一型号、共用同一套工作站软件的设备，接口开发通常可以复用；跨品牌、跨协议的设备，工作量则近似线性叠加。因此仪器台账至少应记录到型号、工作站软件、通讯方式，以及是否支持导出结构化文件，这四项信息直接决定后续报价的量级。
第二个维度是采集深度。单向文件解析适用于天平、酸度计，或本身就能自动导出CSV、Excel的工作站，单台开发成本通常在数千元；双向指令通信则是另一回事：液相色谱、气相质谱这类设备若要由系统下发任务列表、再反向抓取原始图谱，往往涉及私有协议逆向或动态库对接，单台成本会上升到万元级别甚至更高。可行性评估必须明确每台设备落在哪一层，而“支持仪器对接”不算有效表述。
真正容易让项目卡住的，是来自设备一侧的限制：工作站没有开放API、需要额外采购硬件转换模块、操作系统与软件版本过旧。这些情况是“不可行”或“代价过高”的主要来源，必须在立项前逐台确认，并把具体设备型号与采集方式写进合同条款，否则实施期按台追加接口费用几乎不可避免。
采集方案还要与数据完整性一起评估。原始谱图与检测数值进入系统后，是否纳入审计追踪、是否要求修改时强制备注原因并保留版本切片，取决于实验室是否面对CMA/CNAS评审或更严格的合规检查。采得进来却不可追溯，等于没有解决问题。
比较务实的验证路径是选两到三台产出频次最高、协议最具代表性的设备先做接口验证，用实测的开发工作量去推算全量接入的工期与成本，同时确认标准参数库是否可配置——若每次标准更新都要改代码，长期维保成本会远超初期的接口费用。对产出频次低的设备，保留结构化文件导入通常比强行直采更划算。
