AI基础设施很容易被简化为一张采购清单：加多少卡、建多少机房、铺多少基站。但企业真正买到的不是这些资源的名义规模，而是某个现场任务能否在规定时间内完成，数据能否按权限流动，最后能否在一台可生产、可维护的终端上稳定运行。把通信、算力和终端拆开规划，账面能力可能很漂亮，业务链路却仍然断着。
9月23日，在2026中国国际信息通信展期间，工信部副部长余晓晖提出推动人工智能与信息通信业深度融合。原日报援引的公开数据是：我国5G基站超过515万座，智能算力规模达到2185 EFLOPS，建成5G工厂超过1260家。下一阶段部署涉及新一代通信网络、低轨卫星互联网、国际海缆与陆缆、算力扩容，以及算力网络协同和算力互联。这些数字说明供给侧已有相当大的基础；它们并不能直接回答一家工厂的视觉质检为什么仍有延迟、一家终端厂为什么做完样机却难以量产。
通信和算力之间，缺的是可用的服务链路
把一批算力节点连起来，并不自动得到一个可以统一调度的算力池。任务进来之前，先要知道模型在哪里、数据能否出厂、所需硬件是否兼容、排队时长是多少；任务跑完之后，还要看结果通过什么网络返回现场，出现错误由谁处理。跨城市、跨运营商、跨芯片的协同尤其如此。网络在这里不是单纯的传输费用，而是决定任务可否安排、能否按时交付的运行条件。
以工厂设备巡检为例，现场摄像头持续产生视频，最紧急的异常可能需要在边缘侧即时判断；批量复核可以晚些送到区域算力节点；用于改进模型的样本又可能受到企业数据权限约束。这三个环节都叫“用AI”，对带宽、时延、稳定性和审计的要求却不同。若一开始只按总算力配置资源，后期才补网络、权限和边缘设备，现场很可能要为一次模型升级改动整条链路。
企业可以先画出实际任务链，而不是先选技术名词。对每类任务记录数据来源、数据量、最大允许延迟、断网后的处置方式、推理地点、结果接收人和责任部门。再据此区分本地、边缘和远端算力：哪些决策必须留在设备旁边，哪些工作允许排队，哪些敏感数据只能以脱敏或聚合形式外发。所谓“算力互联”落到企业账本上，应当能看见任务迁移成功率、等待时间、传输成本和故障恢复时间，而不只是可调用节点数量。
5G工厂超过1260家的统计也应这样读。它反映已有建设基础，并不意味着所有工业场景都需要相同的无线方案。固定产线、高密度移动设备、室外场站的通信需求不同；既有有线网络也未必需要被替换。评估通信升级时，应先找出目前拖慢生产的具体链路，再比较网络改造、边缘计算和流程调整各自的成本。换了更快的网络却没有统一设备身份和数据接口，数据照样进不了模型。
低轨卫星互联网、海缆与陆缆建设则面向更广的网络覆盖和互联能力。对企业来说，不必把每项基础设施都写进近期采购计划。真正相关的问题是：跨区域业务有没有单点线路依赖？偏远场站如何回传关键数据？网络中断时，终端能否保持最低限度的安全功能？先把这些问题回答清楚，再决定是否需要新增连接方式，避免把“多网络接入”误当成“高可靠”。
从模型演示到终端交付，中试是另一道关
9月24日，北京经开区披露，将打造全球AI终端产品定义中心和智能制造高地。原日报给出的区域背景是，制造业占当地地区生产总值约60%，已集聚600多家AI产业链核心企业，相关产业规模超过800亿元。规划包括AI终端共享工厂、AI眼镜试制、微纳光学和硅基微显示等中试平台，并开放城市级真实测试环境。
这条信息容易被读成“地方发力AI眼镜”。更值得企业研究的是中试环节。模型软件可以按周更新，终端硬件却要面对物料选型、结构公差、散热、功耗、佩戴或操作舒适度、可靠性测试和售后维修。一个在实验室表现不错的交互功能，如果连续工作时间不够，或者在强光、噪声、粉尘环境下失效，就不能用概念视频证明产品成立。共享工厂和试制平台的价值，恰恰在于把研发问题提前暴露在量产之前。
以AI眼镜为例，产品定义不能从“接入哪个大模型”开始。先确定谁在什么场景佩戴：是巡检人员需要解放双手，还是维修人员要调阅图纸，抑或消费者只想完成短时问答？同一副眼镜，光学显示、收音效果、重量分布、隐私提示、无线连接和续航的取舍都不一样。XR、机器人、车载设备和工业手持终端也有类似逻辑。模型能力是零部件之一，整机体验由多个限制条件共同决定。
中试阶段最好把验证项目写成可否决的门槛。样机连续运行后是否过热；工人戴手套时能否操作；网络波动会不会让关键指令消失；摄像头采到无关人员时如何处理；零部件替换后是否要重新校准；返修时能否取出日志而不泄露客户数据。这些问题听起来琐碎，却直接决定企业是否敢下量产订单。城市级测试环境可用于观察真实交通、公共空间或多设备并发条件，但测试场景不等于正式市场，仍需确认客户是否愿意采购、谁负责维护。
把网络、算力和终端放到同一张设计图上
很多项目的组织方式仍是三段式：通信部门负责连接，IT部门采购算力，产品部门做硬件，业务部门最后试用。故障发生时，大家都能说自己负责的部分“指标达标”，整条服务却不可用。更稳妥的做法是以一个业务场景为单位设共同负责人，把网络时延、推理耗时、设备功耗、现场误报和人工接管成本放在同一张验收表里。
设计时还应区分训练与推理。训练任务通常可以批处理，对吞吐和数据治理敏感；终端推理更在乎响应、能耗和断连后的行为。若一个终端需要实时识别危险动作，就不能把安全告警完全交给远端链路；若本地芯片无法承担复杂模型，也可以把即时判定留在本地，把较慢的复核任务移到边缘或中心节点。需要写明的不是“云边端协同”六个字，而是每层负责什么、切换条件是什么、谁有权修改策略。
技术路线也要允许迭代。终端产品的生命周期往往长于模型版本周期，模型更换不能每次都要求更换硬件。厂商应尽量把采集、预处理、推理和业务规则分离，留出模型压缩、参数更新和回滚的路径。但模块化并非免费：接口越多，适配与安全测试越复杂。平台方需要给出清晰的版本兼容范围，不能把所有集成风险留给客户现场。
用一张账检验项目是否值得扩张
基础设施项目喜欢报资源规模，终端项目喜欢报出货量。两类数字都需要补上使用情况。算力侧要看有效任务量、峰谷利用率、跨节点调用失败率，以及每次完成任务的综合成本；终端侧要看设备激活、连续使用、维护工时、替换件成本和实际减少的业务损失。若某个试点只在厂商驻场时稳定运行，或终端销量依赖一次性补贴，项目就还没有证明可复制性。
风险不只在技术。数据跨域流动涉及权限、合同和审计，算力节点之间可能存在软硬件适配差异；硬件中试还面对供应链波动、良率爬坡和责任划分。大型企业有能力建立统一接口，小厂商却可能被不同客户的定制需求拖住。园区若建设公共平台，应明确开放对象、收费方式、知识产权归属和测试失败后数据如何处理，不能只公布设备清单。
一个可执行的顺序是先挑两三条明确的业务链路做基线测量，再分别验证网络、算力调度和终端原型，最后做端到端压力测试。每一阶段都留一条退出条件：预期延迟达不到、单次任务成本降不下来、现场人员不愿持续使用，就暂停扩建，回到产品定义。建设越重，越需要允许早停。
企业落地核对表
- 场景是否有清楚的操作者、频次、失败后果和现行人工成本？没有这些数据，不启动大规模采购。
- 数据能否离开现场，模型与日志分别存在哪里？每个跨域环节是否有权限记录和删除办法？
- 网络中断、算力节点不可用、终端电量不足时，现场保持什么功能，由谁接管？
- 是否测量端到端响应，而不是分别接受运营商、算力平台和设备商提供的单项指标？
- 样机是否经过典型工况、长期运行和维修测试？量产良率、备件和升级责任是否已落实？
- 试点结束后，谁为连续运营付费？设备利用率和每次有效任务成本能否支持扩张？
通信网络与算力互联解决的是“资源到不到得了现场”，AI终端解决的是“能力能不能被人持续使用”。两端任何一处缺位，基础设施就可能停留在统计表里。对企业而言，下一笔投入该花在网络、算力还是中试平台，不需要靠概念排序；把业务链路拆开测一次，答案通常会具体得多。
资料依据
本文仅据《2026年9月25日三篇日报》“新质生产力每日动态”中的工信部通信业部署、北京经开区AI终端规划扩展分析；上述建设数量、区域产业数据与规划口径沿用原日报，未另作核验。