三个月前，一个做汽车零部件的朋友跟我吐槽：他们花大半年选的「国内最好的大模型」，搭了三个月的质检 Agent，上线两周被业务部门集体退货。我在 AI to B 的最后一公里 里记下了他那句话：「我们的 AI 项目，死在了数据治理和系统对接上——这两件事，跟模型半毛钱关系都没有。」
那是一次个案级的抱怨。今天，我看到了一份系统级的判决书。
公众号 REIVAX.io 发了一篇文章：《AI 落地传统企业：赋能个人、接管流程，还是造工具？》。作者自述在传统制造企业做数字化，把 AI 进入企业生产链条的方式分成三种模式，然后逐一裁决哪种能落地。这是我少见的 需求侧第一人称 的 AI 落地分析——不是厂商写的，不是咨询顾问写的，是那个要为项目成败负责的人写的。
判决结果出乎很多人意料：制造业用脚投票选中的那个模式，业务流程运行时没有大模型。
一、三种模式，一个判决
先把文章的框架压缩摆出来。AI 进入企业生产链条有三种方式：
| 模式一：赋能执行者 | 模式二：接管流程 | 模式三：生产工具 | |
|---|---|---|---|
| 形态 | 员工用 AI 做 PPT、表格、报告 | Agent 自动读信息、调工具、完成任务 | AI 参与开发，交付脚本/应用/内部服务 |
| 运行时有没有 LLM | 有（人调用） | 有（自动运行） | 没有 |
| 作者的判决 | 开箱即用，但触及不到核心竞争力 | 高价值场景门槛短期跨不过去 | 最应该关注，能推动数字化飞轮 |
三个判决里，最狠的是对模式一的：「没有谁是 PPT 专员或 Excel 专员」——做 PPT、处理表格只是各岗位的附属工作，这些环节提效，动不了企业的核心竞争力。这句话把「全员用 AI」叙事的价值上限直接钉死了。
对模式二，作者列了三道门槛：数字化（他引的数据：制造企业采集的数据只有 44% 被有效利用）、语义化（老师傅看一眼颜色纹理就能接近根因，但说不出自己依据了哪些线索）、治理（越接近质量放行和安全生产，越要「默认不行动」，最终控制权必须与岗位责任绑定）。结论是端到端 Agent 很难进入关键生产流程——前置条件太苛刻。
对模式三，作者的逻辑是：ERP、CRM、MES 这些标准软件和具体现场之间永远有「最后一公里」——特殊表单、跨系统对账、临时排程、异常看板。过去这些小需求单个价值有限、定制成本高，只能靠 Excel 和人工沟通凑合。AI Coding 改变的是这类软件的开发经济性，让工具能从业务内部生长出来。
我查了他引用的那个 44%：出自罗克韦尔自动化第 10 版《智能制造现状报告》（2025 年发布，调查覆盖 17 个国家的 1500 多名制造业决策者），报告的口径是「44% 的受访者表示其采集的数据得到了有效利用」。不是中国特例，是全球抽样的平均水位。
到这里为止，文章已经比大多数厂商内容诚实。但真正值得往下挖的，是它的判决里藏着一个作者自己没有点破的东西。
二、模式三没有跨过前两道门槛，它只被豁免了第三道
文章的推回点在这里：三道门槛杀死模式二，但模式三一道都没有豁免——除了最后一道。
你看，模式三的工具照样要接设备数据（数字化门槛一分不少），照样要把老师傅的判断写成业务规则（语义化门槛一分不少），作者自己都说需要 FDE「把模糊需求变成可验证的系统」。那为什么模式二「门槛太高跨不过去」，模式三却「最应该关注」？
差异只在治理这一道。而且严格说，模式三也不是跨过了治理门槛，是 治理成本塌缩了：
运行时 Agent 出错：
概率性输出 → 错误难以复现 → 责任无法绑定到岗位
→ 越接近质量放行，越不敢用 →「默认不行动」
确定性工具出错：
代码可复现 → 修一个 bug 有明确的 owner 和验收
→ 责任模型和传统软件完全一样 → 现有治理体系直接兜住
# generated by hugo AI
一个质检 Agent 放行了不良品，你没法处分一段概率分布；一个质检工具放行了不良品，那就是 bug，走既有的软件质量流程。制造业不是不要 AI 进生产流程，是不要「责任无法归属」的东西进生产流程。
有人会在这里追问：模式三的工具数据需求也小得多——一个对账工具只接两个系统的导出，不需要端到端 Agent 那样的全链路数据流，数字化门槛明明更低。对，但这个「小」本身就是治理结构决定的：确定性工具可以在自己能力的边界上把人接回来——边界外的情况人兜底，兜底责任落在岗位上；运行时 Agent 的边界是概率的，你没法预先声明它在哪里会失手，也就没法安排人在哪里接。能切小范围，是因为责任能切小范围。
如果把它收成一把可以随身带的尺子，我给任何想进核心流程的 AI 项目做三道判断，我叫它 责任可归属性测试——三道全是「是」，才谈得上进生产；任何一道是「否」，无论模型多强都会被挡在门外：
1. 出错时，错误能不能被复现？
（能复现 → 能定位 → 有 owner；概率性输出往往不能）
2. 能不能预先画出它的能力边界？
（边界确定 → 边界外人兜底；边界模糊 → 无法安排接管）
3. 出了事故，责任能不能落到一个具体岗位？
（能落到岗位 → 现有治理接得住；落不到 →「默认不行动」）
# generated by hugo AI
制造业的质检 Agent 三道全「否」，所以被退货；同一个场景的确定性工具三道全「是」，所以能上线。这不是技术差距，是问责结构的差距——也是为什么文章里「最终控制权必须与岗位责任绑定」那句话，比任何一个模型 benchmark 都更接近落地的真相。
这个发现让文章的两条判决突然变成了一件事。作者在治理一节写「最终控制权必须与明确的岗位责任绑定」，这和我在 大多数企业 AI 的终点是人，Palantir 的终点是业务 里讨论过的分水岭是同一个问题的两面：AI 要进业务操作层，前提是错误发生时有一个能问责的结构。Palantir 用 Ontology 加 FDE 给 Agent 建问责结构；制造业用确定性代码把问责结构直接退化回传统软件——笨一点，但今天的治理体系接得住。
所以模式三的真实身份是：在治理基建缺位时，用确定性代码托管 AI 生产力的过渡形态。 AI 的价值在编译期被固化进工具，运行时留下的是一个责任可归属的系统。这不是 AI 的降级，这是 AI 在责任基建跟上之前的正确落点。
三、钉钉去年做过的版本：把 AI 锁进编译期
这套判断不是纸上推演。去年钉钉和一个合作伙伴做过一个订单员流程自动化的项目，正好是模式三的活标本——开头那个质检 Agent 是模式二的失败，这个项目是模式三的成功，同一个制造业，两种命运。
问题很具体：制造工厂的订单是客户用邮件发来的，格式五花八门——非标 PDF、各种 EXCEL，每家客户的模板都不一样。过去只有一个办法：订单员盯着邮箱，把每一张订单的数据手工敲进 MES。一家工厂可能有几千个 B 类客户，就是几千种格式，全靠人眼人手。
模式三的做法是：
客户邮件（非标 PDF / EXCEL）
↓
AI 识别这一种格式的结构
↓
生成一个「只认这家客户格式」的精准提取程序
↓
程序自动提取订单字段 → 自动录入 MES
# generated by hugo AI
关键看 AI 站在哪一步。AI 只在「识别格式、生成程序」这一刻介入——这是编译期；程序一旦生成，之后每一张同格式订单进来，跑的都是那段确定性代码，运行时没有大模型。这就是这篇文章标题的来源：制造业选中的 AI，智能在编译期，运行时是确定性工具。
它也通过了上一节的责任测试。提取程序录错了数据，错误可复现（同一份订单再跑一遍还是错）、边界可声明（这个程序只认这一家客户的这一种格式，超出就交回订单员）、责任可归属（哪段程序错了修哪段，有明确 owner）。订单员的角色从「手工录入」变成「验收和兜底」——正是模式三把人接回边界外的样子。
而真正让这件事从想法变成项目的，是成本：
| 单个客户的提取程序 | 几千个 B 类客户全自动化 | |
|---|---|---|
| 过去：人写 | 上千元 | 几百万——没人做得起 |
| 现在：AI 生成 | 几块钱 | 万把块——一个项目铺得完 |
（成本是这个项目的实际口径。）过去几千个客户的订单只能靠人手工录入，不是因为没人想到自动化，是每个客户写一个解析程序要上千块，几千个客户就是几百万，经济上根本不成立。AI 把单个程序的成本压到几块钱、降了两个数量级之后，几千个客户的自动化从「想都不敢想」变成「一个项目就能铺完」。
记住这个「几块钱 vs 上千元」——后面回应「这不就是外包降价」时，它就是答案。
四、桌面长个人提效，云端长生产线自动化
订单项目之后，可以再往前推一步：企业的 AI 到底跑在哪里，谁为它付钱？
这两年最热闹的 Agent 产品几乎都在桌面端——编码 Agent、computer-use、个人助理。桌面端 Agent 很适合开发个人提效的自动化工作流：自己的脚本、自己的文档、自己的浏览器。这正是源文模式一的自然延伸——个人的、间歇的、人在场的。它的价值真实，但上限也真实：一个人在桌面上能用的，是他自己的碎片时间。
企业更需要的却是另一种东西：生产流程上的自动化工作流——人和人交接工作的自动化处理。销售把订单交给计划，计划交给车间，车间交给质检，质检交给发货；每一次交接之间都塞满了等待、催办、转录和核对。上一节的订单员场景本身就是一次交接：客户的邮件交到订单员手里，订单员再交到 MES 手里。企业的时间黑洞不在某个人的桌面上，在人和人之间的缝隙里——这些缝隙恰好长在组织图谱上：谁把什么交给谁、卡在谁手里、由谁兜底，都是我在 AI 钉钉的护城河不在 AI，而在组织图谱与协同飞轮 里说的那类只有组织平台才有的数据。
而交接有一个属性，决定了它的部署形态：它不下班。客户的邮件半夜到，客诉周末来，审批卡在出差的间隙里。桌面 Agent 依赖人开机、会话在场；交接自动化必须事件驱动、7×24 跑在云端，不管有没有人看着都在动。所以生产线上的工作流必然长在云上。
这个结构差异直接写进了 token 账单。桌面使用是间歇性的——人一天在线几个小时，一个会话消耗一次；生产线使用是持续性的——事件全天候触发，每一次订单识别、每一次跟进判断、每一次交接路由都在消耗。订单项目里「一个程序几块钱」还只是编译期的消耗；运行时的交接自动化按事件计费，乘以几千个 B 类客户、每天进来的订单，账单还要再上一个数量级。个人桌面提效花的 token，大多被个人订阅消化；企业生产线花的 token，是持续付费的云端消耗。
一句判断：桌面 Agent 决定个人跑多快，云端 Agent 决定组织跑多快——付费 token 的钱，花在组织跑的地方。
这里必须处理一个和标题的表面矛盾：生产流程上的工作流用运行时 Agent，不就撞上了前面的责任可归属性测试吗？没有——因为交接自动化进的是缝隙，不是决策点。跟进漏了可以再跟，转录错了可以再改，缝隙里的错误可回滚，和「放行一批不良品」的问责结构完全不同。源文其实已经给出了半个判决：模式二进不了核心流程，但自动项目跟进、客诉跟踪这类轻量场景是合适的。它没说的半个判决是：核心流程把 AI 固化成确定性工具，是因为错误不可回滚；交接缝隙用运行时 Agent，是因为错误可回滚。AI 跑在云端还是被编译进工具，分界线从来不是模型能力，是错误代价。
五、语义化的正确打开方式：不是写文档，是当验收
文章里我觉得最诚实、也最无解的一段是语义化：老师傅的经验属于「未知的已知」——人会做，但没意识到自己依据了哪些线索。作者说，语义化不是让老师傅坐下来写一份万能提示词，而是把隐性经验逐步外化，而且「就算不考虑专家的配合意愿，把经验和直觉外化这件事本身就有难度」。
但文章没有看到：模式三本身就是一台语义化机器。
FDE 把模糊需求变成可验证的系统，这个过程每跑一轮，都在强制外化一段隐性经验——不是靠老师傅写文档，是靠老师傅当验收。工具做出来，老师傅看一眼：「这个判定不对，颜色偏暗但纹理没断的不能算不良。」（对话是示意，机制是普遍的。）这句话就是被外化的经验，它接下来会变成一条业务规则或一个测试用例，永久留在代码库里。
这正是我在 Evals 是新的 PRD 里说的事：那位产品经理说不清「领导已读不回超过 48 小时该怎么提醒」，因为她的判断标准从没被外化过；直到 Agent 交付了她不想要的东西，她的真实标准才被逼出来。老师傅和她是同一个处境——人不会主动蒸馏自己，但人会否决错误的交付物。 验收是隐性经验唯一可靠的外化机制。
也是 AI Native 组织的第一生产力，是敢被蒸馏的管理者 的制造业版本：那位老板的中层不肯把判断标准写成文档，30 个数字员工全变成「等他拍板」的排队窗口。而模式三的聪明之处在于，它从头到尾没要求任何人「写文档」——它只是不断交付一个工具，然后让掌握隐性经验的人行使否决权。
从这个角度看，文章的三道门槛应该重排：数字化是硬前提，语义化不是一道要预先跨过的门槛，而是飞轮转动时自动发生的副产品。真正卡住一切的只有治理。
六、飞轮留下的资产，就是本体的原材料
现在可以说这篇文章最大的价值了。作者写模式三飞轮时有一段话，我认为他自己都没意识到写了什么：
「这条飞轮的关键不是代码生成得多快，而是每一轮都留下更多可复用的东西：数据接口、业务规则、测试用例、权限模型、操作日志和领域知识。」
把这六样东西换个名字念一遍：数据接口是对象和关系，业务规则是逻辑，权限模型是边界，操作日志是审计证据，测试用例是验收标准，领域知识是语义。这就是 Ontology 的原材料清单。
我在 Palantir 从本体长到 Agent，我们从 Agent 长回本体 里提过一条反向路线：不学 Palantir 自上而下先建本体（周期以月计、需要驻场、服务半径只有最大的几百家客户），而是先让 Agent 以数字员工身份上岗，再从运行痕迹里把本体长回来。这篇文章给了我一个我没想到的补充：长回本体的起点，不一定是 Agent，也可以是工具。
Palantir 路线： 先建 Ontology → Agent 长在本体上（自上而下）
Agent 路线： 数字员工上岗 → 从运行痕迹长回 Ontology（自下而上）
工具路线（本文）：AI 造工具 → 飞轮沉淀规则/权限/日志 → 资产聚合成 Ontology
# generated by hugo AI
三条路线的终点是同一个：一个机器可理解、可操作的企业世界模型。这也是 Databricks 逼近 Palantir，但最后一层藏在组织里 那篇的结论——数据侧爬不到最后一层，因为本体的稳定核心（身份、权限、问责）长在组织里。而工具路线恰好证明了这一点：制造业的飞轮资产之所以能持续积累而不是散掉，前提是有一个组织化的持有者把接口、规则、权限模型从一个个工具里抽出来，变成跨工具共享的东西。工具会死，资产层不能跟着死。
对传统企业，这个结论可以直接翻译成行动：做模式三，从第一天起就要求每个工具交付资产清单——留了哪些接口、固化了哪些规则、沉淀了哪些测试用例、权限怎么建模。只交付工具不交付资产清单的项目，是在给飞轮漏气。
七、反方：这不就是外包降价吗
写到这里，最聪明的反驳者会说：别把概念吹大了。模式三说的事情，本质是「用 AI 把内部定制开发变便宜」——数据接口、业务规则、测试用例，任何一个像样的软件团队本来就该沉淀这些资产，二十年前的 CMMI 就是这么要求的。所谓「飞轮」只是 IT 外包降价的新说法；而且内部工具的真实命运往往是：FDE 走了，工具烂了，资产清单没人维护，三年后没人知道那段代码为什么这么写。
这个反驳的前半段是对的——资产沉淀不是 AI 时代的新发明。但降价降到某个刻度，会引起质变，订单自动化项目就是证据。单个提取程序从上千块降到几块钱，是三个数量级里跨过两个数量级的降价——在「上千元」的刻度上，几千个客户的自动化是几百万的预算，任何一家工厂都不会批，所以「最后一公里」空着不是没人看见，是经济上不划算；在「几块钱」的刻度上，同样的事情万把块就能铺完，工具密度直接上一个数量级。密度够高，接口和规则的复用才开始产生正收益，「留下资产」才从最佳实践变成经济必然。这正是 软件工厂 3.0 里模具的逻辑：模具值钱的前提是有足够多的订单来摊销它——几千个 B 类客户，就是那「足够多的订单」。
后半段——「FDE 走了工具就烂了」——我不但不反驳，还认为这恰恰是全文最重要的推论。工具会烂，说明飞轮的产出不能停在工具层；资产层必须从工具里剥离出来，由一个不会随项目结束而解散的组织结构持有。作者说模式三需要「既懂软件工程又理解现场的 FDE 或团队」，他只说对了一半：FDE 负责把经验编译进工具，但编译产物里那些可复用的部分——接口、规则、权限模型——需要一个比项目寿命更长的持有者。这个持有者是谁，文章没有回答，而我认为这是接下来五年企业软件市场真正要争夺的位置。
写在最后
回到开头那个判决：制造业选中的 AI，运行时没有大模型。
初看这是 AI 的退场，细看这是 AI 换了一个存在方式——它的智能没有消失，而是从运行时的概率推理，前移到了编译期的经验固化。大模型没有进车间，大模型进的是造工具的那个环节；车间里跑的每一行确定性代码，都是 AI 生产力的托管形态。
而这套判决最有意思的地方在于它的普适性：把「制造业」换成任何一个治理基建跟不上模型能力的行业——医疗、金融、政务——三道门槛和那个真实的分水岭（责任能不能归属到岗位）同样成立。文章结尾说，AI 擅长「已知的未知」，传统企业难的是「未知的已知」和「未知的未知」。我想补一句：决定 AI 能不能进核心流程的，不是企业知道了多少，而是出错时谁来负责。
你的行业里，AI 卡在的是技术门槛，还是责任门槛？欢迎留言讨论。