德国工博会的新闻弹出来，我盯着那些机械臂和AGV小车，脑子里蹦出的第一个念头是：我过去十年写的那些狗屁代码，那些API、那些数据库、那些前端界面，在未来的物理智能面前，是不是一堆废铜烂铁？
这感觉就像2016年我死磕SEO和爬虫，以为掌握了流量密码，结果算法一更新，所有技巧瞬间归零。现在看，AI对物理世界的渗透，不是又一个算法更新，是地基换了。我们还在讨论怎么用大模型写周报、画PPT，人家那边机器视觉已经能实时识别产线上毫米级的瑕疵，机械臂的路径规划开始用强化学习动态优化了。我们的软件，那些跑在服务器上的、依赖HTTP请求和JSON数据包的“虚拟层”，怎么跟这些有胳膊有腿、有传感器、实时反馈的“物理实体”对话？靠REST API？靠消息队列？延迟和可靠性够吗？一个机械臂等你的云端服务响应500毫秒，可能一个批次的产品就废了。
我去年疯狂补课大模型，以为抓住了核心，现在发现可能只抓住了“大脑”。物理智能需要的是“大脑”+“小脑”+“脊髓”的完整神经系统。大脑是LLM做高层任务理解和规划，小脑是实时控制系统处理传感器融合和运动控制，脊髓是底层的现场总线、工业以太网。我们这些产品经理、软件开发者，传统上只负责“大脑”里最上面那一点点逻辑，顶多到应用层协议。下面的世界，PLC编程、运动控制卡、实时操作系统，对我们来说几乎是黑箱。
这就产生了一个恐怖的断层。你让大模型生成一段“把红色零件从A框搬到B框并拧紧螺丝”的指令，它可能写得头头是道。但这段指令怎么变成KUKA机器人的KRL代码？怎么适配那台特定型号的拧紧枪的扭矩参数？怎么处理摄像头突然识别到零件有毛刺的异常情况？现在的做法是堆人，堆集成商，写大量的、硬编码的中间件和适配层。每一个新场景，就是一次痛苦的、昂贵的定制开发。这根本不是未来该有的样子。
未来的接口，必须更高维、更语义化。不能是“调用MoveTo(x,y,z)函数”，而应该是“以平稳的加速度和轨迹，避开障碍物，将物体放置于目标区域中心”。软件需要提供的是“意图”，而物理智能系统（机器人、流水线）需要自己将意图分解为可执行的动作序列，并具备实时调整的能力。这意味着，我们软件资产的架构要彻底重构。状态管理要从请求-响应模式，转向事件流和世界模型同步。你的软件需要维护一个对物理世界的实时、一致的“数字孪生”，所有决策基于这个孪生体做出，再通过低延迟通道影响物理世界。
我最近在封装n8n工作流和GUI工具，试图把AI自动化做得很“轻”，让小白也能用。但现在看来，如果只停留在虚拟世界的信息处理，天花板太低了。真正的硬仗，在如何为这些自动化工作流加上“手”和“眼”。也许下一步，我得去啃啃ROS2了，哪怕只是理解一下它的节点通信模型和数据格式。或者，看看怎么用大模型去生成和优化Simulink那样的控制模型。代码不会废，但写代码的思维必须从“处理数据”切换到“影响物理实体”。十年前焦虑流量，现在焦虑的是，我的技能树会不会又一次在时代换轨时，被连根拔起。
工博会上那些德国和日本的厂商，展示的已经是雏形了。他们的机器人开始标配统一的描述性接口和语义层。我们的互联网软件，如果还沉溺在APP和SaaS的旧叙事里，等物理智能的浪潮真的拍过来，可能连做适配层的资格都没有，因为到那时，控制和语义的标准，可能已经不掌握在写业务逻辑的人手里了。得抓紧了，这次不是学个新框架那么简单，这是换一个世界观。
