技术热点来得快，选择却要管好几年。一家制造企业上不上边缘计算、用公网还是专网、自建算力还是租用，这类决定往往在几次汇报里就被定下来，事后才发现被某个参数锁死。技术路线没有绝对优劣，只有适配与否，关键是有一套稳定的筛法，避免被演示效果和同行案例牵着走。

前三步：先定需求，再定边界

第一问是业务到底要解决什么。时延、并发、可靠性、数据不出厂，这四项里哪一项是硬约束，哪几项可以妥协，必须先排序。第二问是规模的天花板，三年内终端数量、数据量、峰值负载大概到什么量级，超过某个量级，今天的方案就要重做。第三问是运维能力，团队里有没有人能看懂日志、处理故障，没有的话，越先进的架构越是负担。三问的答案写成一页纸，后面所有选型都拿它对照。排序时可以请业务、财务、运维各写一版，差异最大的那一项，通常就是真正的约束。

后两步：算全生命周期成本，留退出通道

第四问是总成本，不只比设备报价，要把带宽、电费、机柜、人力、迁移费用一起算进去，通常按三年期一算，结论会和首年报价相反。设备报价之外，最容易漏的是专线月租和机房改造，这两项在三年里往往超过硬件本身。第五问是退出成本，接口是否标准、数据能否导出、更换供应商需要多久。这一条最容易被跳过，却决定了三五年后还有没有议价权。技术选型的边界也在这里：凡是数据格式私有、接口不公开、迁移要重做一遍的方案，除非业务确实离不开，否则应当扣分。还有一条软边界：方案要留一个人能看懂，团队里没人接得住，再好的架构也会荒废。

三条不能越的边界

一是不要把试验性技术直接放进生产环节，先在一条产线、一个车间跑够时间；二是不要让单一供应商同时掌握硬件、平台和数据，短期省事，长期被锁；三是不要为了概念统一而强行合并系统，业务节奏不同的部门共用一套平台，往往两边都不好用。边界的作用不是限制创新，而是让失败停在可承受的范围内，这一点在预算紧的时候尤其重要。

筛法的价值在于把争论变成打分。需求、规模、运维、成本、退出五项各占权重，团队先对权重达成一致，再看方案，比在会上比谁嗓门大要可靠。技术会迭代，这套筛法可以一直用下去。