计划-执行-反馈的闭环：我如何在千亿级制造企业打造物理AI

文 | GritMeng 2004 年，我把一本 ERP 原理书翻到散架。那时候我还不知道，自己会用 22 年去回答一个问题：计划，到底该怎么做。 2007 年，我加入联想。2020 年，我离开。2026 年年初，我提炼出八大物理定律，建立《价值链物理学》。这条路，我走了 22 年。联想和它的 ODM 制造网络，对我而言从来不是"雇主"——它们是一批实践场，是我花了 22 年才看清的"定律提炼厂"。 如果要用一个物理场景概括这 22 年，那就是—— 一张工单在车间地板上改变了，系统在人还没反应过来之前，已经重新算完了齐套、重排了产线、发出了 Call 料指令、更新了交期、通知了库房发货准备。 从感知扰动，到执行动作， 全链条没有人工断点 。这就是"计划—执行—反馈"的刚性闭环。我把它的跑通，叫作自主决策；把它在千亿级物理世界中的可计算性，叫作复杂性科学。 我不代表联想，联想也不代表我。 ​ 它们做对过，也做错过，后来退化了。这三件事我都亲眼见过。 所以这篇不写联想的成败。只写我自己的经历——因为真正重要的，从来不是那家公司怎么样了，而是那个真正跑通了"计划—执行—反馈"闭环的物理 AI，到底是怎么做出来的。 下面每一件事，都是当时真实发生的。 而每一件事背后藏着什么定律，我当时一个都不知道。 我当年手里只有两样东西： 逻辑自洽性 ，和一股停不下来的死钻。 就是靠这两样，我硬生生把它走通了。 不是因为我提前知道什么范式，不是因为我聪明到能预判什么定律。是我被现实逼得无路可退，只能一遍一遍拿“自洽”当尺子去量，拿“死钻”当镐子去砸。 然后，恰巧，走通了。 二十年后回头鸟瞰，我才一条一条认出来：原来当年那个“恰巧”，每一步都踩在定律上；我们当年在废墟里撞出来的，竟然就是今天全行业一直在追逐的世界模型与物理 AI。 一、首问负责：废墟上重建（2004–2012） 2004 年，我从计算机专业毕业。出于对系统化运营逻辑的兴趣，我把一本 ERP 原理书反复研读，甚至对比不同译本以构建认知的闭环。那时我不仅学习了微软 MBS 与 SAP 系统，还跨越技术边界，深入学习了财务的借贷记账法与三大报表。在做业财进销存的过程中，我总是在思考一件事： 计划，到底该怎么做。 2007 年，我加入正处于全球并购整合期的联想。 并购 IBM 个人电脑业务之后，联想迅速长成一家标准的大型科层制企业。总部大楼里，权力的划界和流程的流转严丝合缝： BT 出方案 → 业务提需求 → IT 架构组做设计 → 实施项目组交付。 而我所在的位置，是这条流水线的最末端—— IT 运营团队 。 这个位置极其特殊。特殊到，当那些已经上线、已经表彰的“成功项目”被丢到我们手里时，没有一条制度规定我必须接。我完全可以不接。大不了项目继续烂在那里，系统继续跑不出来，车间继续用 Excel。最后骂的是项目组，不是运营。 但我还是接了。 不是因为我有多高尚。是因为我听到“无米下锅了”，听到“产线停了”，听到工人在线上傻等——我自己也会跟着疼。那种疼，不是情绪，是生理性的。就是坐不住，没办法假装没听见。 所以，当失败的项目像烂摊子一样被推过来的时候，我的第一反应不是“凭什么是我”，而是： “既然已经到我手里了，那就尽量把它救活。” 团队文化里有几句话，刚好说到了我心坎上： 首问负责，不推卸、不诿过。 说到做到，尽心尽力。 敢为天下先。 这文化是联想塑造的，不是我个人的发明。但那几句话，确实和我这个人对上了。系统每天真实地跑着，车间每天真实地停着。我接了，还有可能修好；我不接，它就一定烂到底。 从 2007 年到 2012 年，因为全球工厂 24 小时连续生产，我经常在半夜被来自全球工厂的紧急电话叫醒。我接了，然后，就再也没有走出来。 二、项目全失败了，但上线那一刻，所有人都升了职 那时候，关于“计划”的系统，上线了一个又一个。 最贵的德国 ERP。全球顶尖的 APS。各种名目的 S&OP、IBP、控制塔。每个项目立项都声势浩大，预算千万，承诺的指标美轮美奂。 结果呢？ 全都失败了。 没有一个能把日内有限产能排产真正跑出来。没有一个能让车间脱离 Excel 手工账。没有一个能自动把料、线、人、交期算明白。 这里必须立下一个冷冰冰的划界标准： 数字化转型真正的成功，唯有一条物理标准——那就是“计划—执行—反馈”高频闭环在真实物理世界中的跑通与自愈运转。 此以外的一切升职加薪、官方叙事、PPT 汇报与喜报表彰，全都是与物理做功无关的组织噪声与虚构泡沫。 但当时整件事最荒诞的地方在于—— 上线那一刻，所有人都升职加薪了。 系统打通第一个接口、吐出第一张漂亮报表那天，庆功会开了，红酒碰了，奖章发了，喜报贴满了内部网。 业务 VP 凭此兑现了“业务转型”KPI。IT 领导把履历写亮了。外部顾问收了尾款，做成了“最佳实践案例”。项目经理升官调任。 那一夜，热闹非凡。 除了那套系统。它依然静静地躺在服务器里，跑不出来。庆功声一落，车间计划员默默关掉系统界面，重新打开 Excel。 这不是某一个项目的问题。是全部。 系统根本没有形成真正的物理闭环。 三、我做的所有事，在组织的账本里是“隐形”的 系统跑不通，活儿总得有人干。 我只能在被庆功遗忘的废墟上，带着运营团队，一段一段把核心业务逻辑和架构重新焊起来。管理层看到的“平稳运行”，本质上是我们在地下硬撑出来的。 但这件事，在组织账本里完全隐形。 因为项目已经“成功上线”，已经表彰，已经是公文里闭环的“历史成就”。 既然已经成功了，废墟上的真相，就没有通道直达天听。承认系统跑不通，就是承认一把手剪彩的项目是失败的。就是抹杀一整条链上所有人的功劳。就是把组织的既定结论撕碎。 所以真相被封印在底层。天上是歌舞升平的数字化蓝图，地下是泥泞不堪的手工对账。我一个人在废墟里，修补碎了一地的逻辑。 四、业务本身，是一个不可分割的原子 在废墟里撞了无数个弯路，我慢慢想明白一件事。 一个企业的业务要“可计算”，底层靠的不是管理口号，就是两样最基础的东西： 数据模型 + 业务算法。 原子数据模型：描述物理世界的真实状态——“物料A_库存已占用_车间3号位”。 原子业务算法：执行物理世界的规则与动作——“基于优先权释放占用并重新扣减”。 这俩是一个物理实体的两面。数据模型是体，业务算法是用。你把它们撕开，它们就都死了。 所以，数据模型和业务算法，才是真正的业务方案。它们不是“IT的实现”。它们就是业务本身。 而传统的做法呢？业务部门画流程图，IT部门写代码，架构团队画框架，咨询顾问讲方法论。四拨人各干各的，都以为自己在“做业务”。 这不叫分工。这叫割裂。 一套活着的业务系统，被组织硬生生切成了四块，每块还都宣称自己是完整的。最后拼起来，要么逻辑冲突，要么物理失配，要么上下割裂，要么内外两张皮。 所以，判割裂死刑，不是因为分工不好。是因为 业务在本体上不可分割 。你把一个不可分割的东西强行切开了，它就不再是那个东西了。 这就是为什么所有“业务和IT对齐”的项目最后都变成了甩锅。不是人不配合，是这事从根上就不该被分开。 后来我在废墟里做的第一件事，就是把这些碎片全捡起来，塞进一个模型里，补到它自洽为止。因为只有自洽，它才是一个活的东西。只有自