2026年，国内AI智能体产品盘点类的内容我看了不下二十份，几乎每一份都在讲办公助手、编程助手、客服机器人。但真正能回答“AI智能体在制造业怎么落地”的文章，少得可怜。制造业不是坐在电脑前写邮件、做PPT，它面对的是机床、产线、工艺参数、设备报警、质量异常这些实打实的物理对象，容错率极低。很多制造企业的朋友问我：智能体到底能帮车间干什么？为什么别人家的方案看起来很好，我们一上产线就废？怎么挑方案商才不会被割韭菜？这篇文章把我这两年在制造现场看到的、做过的、踩过的坑一次性讲透，适合正在做智能体选型、或者已经在内部推智能体试点的制造企业技术负责人、信息化部门，以及想进入制造业的AI创业者。
1. AI智能体在制造业的核心应用场景与价值拆解
1.1 制造业语境里的智能体到底是什么
先明确一个概念，制造业聊AI智能体，跟我们平时用的ChatGPT、豆包不是一回事。办公场景里的智能体，核心能力是“会说话、会检索、会写”，干的是知识工作。制造业的智能体，本质是一个“感知-决策-执行”的闭环系统：它要能从设备取数、从系统读单、从工单获知任务，经过大模型的理解和推理，给出一个动作建议，甚至直接触发一个操作，然后把结果反馈回来，再学习优化。
这个闭环能不能跑通，决定了它是“聪明的聊天机器人”还是“合格的数字员工”。我见过很多号称智能体的产品，实际就是个套了RAG的知识库问答，问它“这个设备最近三个月报警的原因是什么”，它能答上来，但你说“帮我调整一下明天的排产计划”，它就没反应了。这不是智能体，这是搜索引擎。
所以制造业智能体的价值，不在于它“懂多少”，而在于它“能不能把事情办了”。它替代的不是“脑子”，而是那些需要跨系统查数据、翻文档、打电话确认、写报告、盯流程的重复性协调工作。理解这一点，后面所有落地逻辑都不会跑偏。
1.2 最值得优先落地的四个场景
我从大量实际项目中筛下来，当前制造业最适合智能体切入的是四个场景，按落地难度从低到高排：
- 设备维护与专家知识沉淀。老师傅的经验、设备手册、历史维修记录，全部喂给智能体，让它做故障诊断辅助。车间维修工报故障时，智能体根据现象描述和历史数据给出可能的故障原因、维修步骤、需要的备件清单。
- 生产计划与排程辅助。APS高度复杂，但智能体可以先把“人在Excel里做排程”这件事半自动化：读懂订单交期、设备状态、物料齐套情况，生成排程建议，计划员确认后下发。
- 质量异常分析与归因。质检发现不良品，智能体关联工艺参数、设备参数、原材料批次、环境温湿度，给出异常原因的排序和调查建议，帮质量工程师节省大量查数据的功夫。
- 供应链协同与异常处理。供应商延期、物流滞留、缺料预警，智能体自动汇总各系统数据，生成处置建议，并协调沟通邮件、调度会议等动作。
这四个场景有一个共同点：都涉及大量跨系统查数据、大量非结构化知识、需要经验判断，但又不需要像机器人控制那样实时到毫秒级。它们是最容易跑出ROI的入口。一上来就让智能体直接控制产线设备、实时调整PID参数，那不是落地，那是给自己挖坑。
2. 制造业AI智能体落地难，难在四个硬骨头
2.1 数据环境：工业现场的数据比想象中"脏"得多
我在培训材料里常看到一句话：AI智能体的能力，取决于数据的质量。这句话对，但制造业的数据现状，严重低估了问题的严重性。
首先是多源异构。一个工厂里，MES、ERP、SCADA、PLC、手工Excel、纸质工单并存，数据格式五花八门，有些老师傅的记录根本不在系统里。我调研过一家汽配厂，质量数据散落在三个系统加两个Excel台账里，同一个产品编号在四个地方有四种命名方式。想要一个统一的数据视图，光清洗数据就干了几个月。
其次是历史数据的“断档”。很多设备的数据采集是从近两年才开始的，以前的数据要么没有，要么在已经离职的人脑袋里。智能体做故障诊断，需要故障样本，但很多故障是低频事件，样本本身就少，再联系上数据不全，模型的准确率自然上不去。
再一个是数据标注的“内伤”。工厂里的数据，记录时不是为了AI用的，而是为了人工追溯。字段含义、单位、异常标记，都带着人的理解和习惯。设备报警代码的含义不同车间可能不一样，同一个代码在一条产线是停机级别，在另一条产线只是提示级别。这些隐含语境，大模型不会自动理解，必须靠业务专家慢慢梳理。
所以在制造业做智能体，数据治理不是前提条件，而是项目的一部分。方案商如果跟你说“你们数据够好，直接上就行”，要么他不懂制造业，要么他打算先用Demo糊弄你。真正负责任的做法，是在项目启动时先做一次数据现状盘点，把数据成熟度摸清楚，再决定智能体的步子迈多大。
2.2 运行环境：确定性、实时性与安全性的刚性要求
办公室AI错了，最多是笑话。制造业AI错了，可能是停机、报废、安全事故。这个差异，是制造业智能体落地最难迈的坎。
大模型本身是概率模型，同样的输入，输出可能有微小波动。这是AI的基本特性，但在工业环境里，确定性是硬要求。产线上的操作指令必须明确、可重复、可追溯。你让智能体生成一个工单指令，它每次表述都不一样，车间工人反而不敢执行。
实时性也是一道坎。办公场景里，用户问一个问题，AI思考十秒钟无感。但产线上一个异常报警出现，系统需要在几秒内给出处置建议，等大模型慢悠悠地想上30秒，产线早就停了。传统的规则系统和专家系统在这一点上依然有优势，智能体想融入工业现场，就必须在架构上做“快慢分离”：把实时性要求高的判断留给规则引擎、边缘计算，把复杂推理交给智能体。
安全责任更是躲不开的话题。智能体给出的建议，如果执行出了问题，责任算谁的？目前绝大多数制造企业的做法是“人在回路”，智能体只做建议，最终动作由人确认。这不是技术退步，而是现阶段最务实的安全设计。方案商如果说“全自动闭环，不用人管”，你得警惕，制造业不是这么玩儿的。
2.3 系统环境：存量工业软件的历史包袱
制造企业的系统生态，跟互联网公司的架构完全是两码事。MES可能是十年前买的，接口文档早就找不到了；SCADA是不同品牌、不同年代拼起来的，通信协议五花八门：MODBUS、OPC UA、私有协议、甚至串口。智能体想干活，必须跟这些老系统打交道。
最大的痛点在于，工业软件厂商的接口开放程度参差不齐。有些老系统的接口，根本就没打算对外开放，想拿数据只能找原厂开发，费用高、周期长。还有一些系统，数据从设备侧出来，经过采集、汇总、清洗，到智能体能用的程度，中间的链路已经断了好几截。
我见过一个项目，智能体的推理能力都做好了，最后卡在数据获取上：设备数据散落在3个数采网关里，网关厂家之间互不兼容，只能一台一台想办法，硬生生拖了两个月。这个环节，方案商如果自己没有工业集成经验，根本搞不定。
所以，评估一个智能体方案，不能只看大模型层。数据接入层、系统集成层、中间件层的能力，往往才是真正决定成败的隐形战场。方案商有没有做过MES对接？有没有数采经验？有没有底层PLC通信的积累？这些比模型本身的参数重要得多。
2.4 组织环境：人机协同比技术替换更难
技术问题难，组织问题更难。制造业智能体落地，看起来是技术项目，实际上是个组织变革项目。
车间的老师傅、产线班组长、计划员，他们对智能体的态度很微妙。表面上欢迎，实际上担心：这个东西会不会抢我饭碗？会不会把我几十年的经验变成AI的经验，然后我就没有价值了？我见过有班组私下拒绝使用智能体推荐的工艺参数，也见过有资深工程师在评审时反复质疑智能体的每条建议，技术本身没有毛病，但在组织里就是推不动。
更麻烦的是，智能体项目涉及IT、OT、业务三个部门。IT部门管系统，OT部门管设备，业务部门管流程，三方平时各自为政，智能体要打通数据、流程和系统，就逼着三方必须协同。这个项目推进的难度，远超技术本身。
这时候，企业的负责人在智能体落地中就要意识到，这不是买一个软件的事，而是要搭一个跨部门的工作小组，把系统权限、数据归属、业务流程、KPI这些前置问题理顺。方案商如果只派几个算法工程师来，这项目不会成功，必须有懂业务、能组织流程梳理的人一起参与。
3. 解决方案商能力模型：挑选与合作的核心判断标准
3.1 行业Know-how是入场券，不是加分项
现在市场上AI方案商很多，一类是通用大模型厂商，一类是做AI应用开发的集成商，还有一类是从传统工业自动化转过来的。很多制造企业选型时，容易被前两类的PPT打动：模型能力多强、智能体平台多先进、成功案例多漂亮。
但真正到落地时，你会发现，模型能力只是端到端交付中的一环。方案商懂不懂工艺、懂不懂设备、懂不懂车间流程，才是能不能做出实用智能体的分水岭。
我举一个例子。同样是做设备故障诊断智能体，通用厂商的思路是做通用知识库，把公开的设备手册灌进去。可工厂里设备千差万别，同一个型号的设备，不同工况下的故障特征完全不同，公开知识库对现场根本没有用。懂行的方案商，会先跟老师傅做访谈，梳理现场故障现象、处置经验、备件库存逻辑，再结合设备实时数据去训练。这两个方案的成本和效果，天壤之别。
所以，判断方案商Know-how的方法很简单，问三个问题：你们团队里有几个人在制造企业干过五年以上？你们接触过我们这种工艺类型的产线吗？你们对设备的常见故障和维护逻辑有没有自己的资料库？如果答案都是“我们可以学”，那基本不靠谱。
3.2 交付能力要看"能不能上产线"，而不是"Demo多好看"
不少方案商的售前Demo做得非常惊艳。演示时用的都是他们构思好的场景，数据是精挑细选的，问的问题都是提前训练过的。你看着觉得无所不能，实际上线之后，面对真实数据的复杂多样，立刻原形毕露。
我建议制造企业在选型时，要求方案商做“用你的真实数据、在你的真实场景里跑一遍”的概念验证。这不是刁难，而是绕开演示陷阱最直接的办法。具体做法是，从你自己的系统里抽取一个有代表性的数据子集，让方案商在一个真实的任务上跑给业务人员看，让车间的工艺工程师、设备工程师来挑刺验收。
另一个交付能力的关键点是私有化部署能力。制造企业的数据高度敏感，很多企业连公有云都不想上，方案商必须支持私有化部署、支持内网环境运行。这个能力说简单也简单，说难也难。真正做过私有化的方案商，会考虑推理服务器的配置、模型的量化、与内部网络的兼容性；没做过的，往往张口就是上云。如果对方连一份私有化部署方案都拿不出来，基本可以排除。
3.3 持续运营能力决定智能体是否"越用越聪明"
很多制造企业把智能体当成传统软件来买，一次性交付验收就完事了。但智能体跟传统软件有个根本区别：它需要持续运营。数据的分布会变，业务场景会变，模型有漂移，知识库需要更新。智能体不是交付那天开始好用，而是越用越好用，或者越用越难用，取决于有没有人在持续喂养它。
方案商如果没有持续运营的服务体系，比如定期的模型评测、知识库更新、反馈数据标注、效果调优，那这个智能体三个月后基本就废了。
这一点在合同阶段就要想清楚。明确交付后的运营周期是多久、谁负责日常维护、新的业务知识怎么进知识库、效果下滑怎么止损，这些都要变成可执行的服务条款。如果方案商只愿意做到验收为止，后续一切另外收费，那成本最终可能远超预算。
3.4 2026年选型新变量：智能体开发门槛正在快速降低
2026年，AI智能体的行业格局跟两年前完全不一样了。DeepSeek等开源模型公开了智能体训练的新方法，一些平台推出了可视化的Agent搭建环境，以前要养一个十几人的AI团队才能做的事，现在一个懂业务的工程师在平台工具上拖拖拽拽就能搭出雏形。
智能体开发门槛降低，对于制造企业来说，既是机会也是陷阱。机会在于，你可以把一部分应用建设掌握在自己手里，不需要什么都依赖外部供应商，也更容易做好系统的持续迭代。陷阱在于，方案商用低代码平台快速给你搭一个Demo很简单，但要在工业现场真正跑起来，背后依然需要扎实的数据工程和系统集成能力，这恰恰是低代码平台解决不了的。
我接触过一些制造企业，自己用AI Studio之类的平台搭了设备知识问答助手，效果还不错。但到想让它自动对接工单系统、自动生成处置指令时，发现卡住了：系统没有开放接口，数据没有标准化，流程没有定义清楚。这印证了一件事：工具降低了“建立智能体”的门槛，但降低不了“让智能体在工业世界里干活”的门槛。后者拼的是数据、集成和业务流程的扎实程度。
3.5 评估方案商的量化打分表
选型不能光凭感觉。我把这两年的经验总结成一张打分表，制造企业在评估方案商时可以按这张表逐项打分，行为的维度如下：
| 评估维度 | 考察要点 | 权重建议 |
|---|---|---|
| 行业Know-how | 团队制造业背景、工艺理解、行业资料库深度 | 20% |
| 数据工程能力 | 数据治理经验、多源异构数据接入案例、数采经验 | 20% |
| 系统集成能力 | MES/ERP/SCADA对接案例、接口开发能力、中间件能力 | 15% |
| 模型与平台能力 | 大模型选型合理性、私有化部署能力、智能体平台成熟度 | 15% |
| 交付与实施能力 | 概念验证的真实效果、项目经理的经验、实施计划合理性 | 10% |
| 持续运营能力 | 服务体系、模型迭代机制、知识库更新流程 | 10% |
| 整体成本合理性 | 总拥有成本、隐性费用、扩展成本 | 10% |
这张表的核心逻辑是：AI能力和平台能力加起来只占30%权重，而行业Know-how、数据工程、系统集成这些“接地气”的能力占55%。在制造业，永远不要迷信“模型强大所以什么都行”，要相信“懂这个现场场景才是真正的行”。
4. 从试点到规模化：一套可落地的方法论
4.1 选对第一个场景：高价值、低风险、可量化
制造企业做智能体最容易犯的错，是开局就选一个“全流程大而全”的场景。要么是对全厂排产做全面优化，要么是做设备全生命周期管理。愿景很宏大，但落地极难，最后烧了几个月的钱，产出寥寥。
我建议的选型原则是三个关键词：高价值、低风险、可量化。
高价值，最好是人难做、耗时长、重复度高的环节。设备维修知识问答、质量异常初步归因、供应商异常处理辅助，都是这类。低风险，是不能一上来就碰实时控制、安全强制执行、涉及重大财务决策的场景，先在建议辅助层跑。可量化，是这个场景的效果能用明确指标衡量，比如平均排查时间缩短40%、每班次减少2小时报表填写时间等，方便后续向老板证明价值。
我见过最成功的一个试点项目，是一家注塑厂做的工艺异常归因助手。操作工发现产品有缺陷，系统自动关联当班的工艺参数、原料批次和环境数据，30秒内给出可能的原因和排查建议。原来老师傅查数据要花一两个小时，还经常漏掉信息。这个场景既不直接控制设备，又解决日常高频痛点，效果一眼可见，三个月就跑出了ROI。
4.2 用"最小的强闭环"跑通MVP
选好场景后，不要追求一步到位，先搭建一个“最小的强闭环”。所谓强闭环，就是智能体必须能完整地跑完从输入到输出的全流程，哪怕这个流程很窄。
以设备故障诊断为例，最小闭环的骨架如下：
- 数据接入：从数采平台获取设备状态数据、报警数据，解决数据怎么拿到的问题；
- 知识注入：把设备手册、维修记录、老师傅访谈整理成知识库，做好拆分和向量化；
- 推理决策：当故障发生时，大模型结合实时数据和知识库，输出诊断建议；
- 人机交互：把建议通过MES界面、企业微信、App推送等方式呈现给维修工；
- 反馈收集：维修工确认建议是否有用，实际故障原因标记回系统，形成知识闭环。
这五步跑通了，哪怕第一版只覆盖三个故障类型，也算是一个真正的智能体。它证明了数据链路通、模型能用、业务人员愿意用。MVP的价值不在于功能多，而在于把“整条链路”打通，验证关键假设。
在这个环节，我特别推荐利用当下的低代码智能体平台来提速。先在一些通用能力上可视化搭建，比如知识库问答、表单交互、自动提醒，自己动手几天就能看到雏形，比等外部定制快得多。但涉及系统对接和复杂数据链路的部分，还是需要专业工程师来做。
4.3 建立反馈回路和数据飞轮
智能体落地的分水岭，是有没有“反馈回路”。没有反馈回路的智能体，上线即巅峰，后续直线降智；有反馈回路的智能体，每个月都在变好变强。
反馈回路怎么建？核心就是让每一次人机交互都产生数据资产。比如，智能体给出的故障诊断建议，维修工觉得对不对，现场实际故障是什么，最后有没有采纳，这些数据一定要能反击回系统。让建议、评价、真实结果形成对照样本，用这批数据定期做模型的评测、微调和知识库的增补。
听起来简单，执行难度很高。难点在于业务人员不愿多填一个字段。一定要把反馈动作嵌入到他们的工作流里，不给增加负担。比如维修工本来就要在MES里记录故障原因，那顺便让智能体的推荐结果自动带入，他只是确认或修改，不额外花时间。这样反馈数据才可能积累起来。
数据飞轮是智能体项目从“能用”变成“好用”的唯一路径。方案商要是没有设计反馈回路的能力，或者根本没提这回事，那交付的智能体就是一个一次性玩具。
4.4 规模化复制的四个前提条件
试点成功后，制造企业往往会问：能不能推广到全厂？但我见过很多企业，试点成功之后规模化反而失败了，原因在于四个前提条件没准备好：
第一，标准化。试点阶段可能是一个老师傅配合、一套数据逻辑、一条人工通道。规模化之前，数据标准、接口规范、知识库结构必须沉淀成可复制的模板，而不是依赖某个具体的人。
第二，平台化。试点阶段可能是孤立的项目，规模化必须做一个统一的智能体平台底座，把权限管理、模型服务、知识库管理、数据接入统一管起来。每个新场景不是从零开发，而是在平台上配置递增。
第三，组织准备。前面说过这个问题，规模化推行前，必须把使用者的顾虑解决掉。操作工的实操培训、班组长参与的KPI设定、技术专家的角色转型，这些问题不做，规模化就是生推。
第四，责任边界。智能体纳入正式业务流程后，出了问题谁负责？建议采纳的权限边界在哪？需要在制度上明确。我见过有企业推广智能体后来突然叫停，就是因为有一条异常建议出了偏差，责任人说不清楚。
4.5 效果度量：看"用到什么程度"，而不是"演示多好看"
衡量一个智能体项目是否成功，我有几个务实的指标：
一是使用率。上线的智能体，业务人员每天都用吗？使用率低于三成，说明价值感没做出来，先别谈ROI。看使用率比看功能完整度重要得多。
二是任务完成率。智能体发起的任务，最终有百分之多少被业务人员接受并完成闭环。这个指标反映的是输出质量的真实水平。
三是时效改进。原来完成一项工作（如排查一个异常、处理一次缺料）的平均时间是多久，上线后缩短了多少。这个指标直接换算成人的工时成本，是算ROI的基础。
四是自动化率。在人工确认的前提下，智能体自动完成多少环节，人的参与从“全流程”变成“节点审批”。这是智能体逐步升级的路线图核心指标。
这四个指标，真实的系统后台都能统计。如果方案商只会给你看在PPT上写的预估ROI，却讲不清楚这几个指标的采集方式和逻辑，那基本可以判断，对方交付后不会去管智能体到底有没有被用起来。
5. 常见问题排查与避坑实录
5.1 智能体回答质量不稳定，怎么排查
上线之后，最常见的问题就是智能体时而靠谱时而不靠谱。排查时不要急着怪模型，按顺序梳理下面的环节：
先看知识库。问一问内容是不是已经正确导入、做没做切分处理、会不会检索到了错误片段。我遇到过好几个项目，所谓“幻觉”，其实是知识库里混入了互相矛盾的历史文档，模型不知道该按哪个回答。
再看检索链路。传统RAG的关键词检索在工业领域特别容易出现一个问题，就是专业术语和俗称不匹配。比如师傅管设备叫“大瓦数机组”，手册里写的可能是“高压列柜”，关键词检索查不到。这时候要做术语的归一化同义词映射，或者在检索里做混合召回、重排优化。
接着看上下文。智能体对多轮对话的记忆窗口是不是足够，业务人员问了几轮之后，模型是否还有足够的信息支撑它做判断。工业场景的专业问题，往往需要结合前文条件约束，上下文丢失是大模型在工业场景不稳定的常见原因。
最后看模型版本。有时候是编排中不经意把提示词调乱了，或者接入的模型版本跟开发时不一致。做个A/B对比，用同一组测试集去测不同版本的输出，很快就定位到问题。
5.2 智能体不敢"动手执行"，怎么设计安全边界
很多制造企业的业务人员一开始担心智能体权限太大乱执行，但真用起来，反而发现智能体太保守，什么都不敢做，啥都要人确认，效率反而下降了。这个矛盾怎么解？
我的建议是分三层设计权限。第一层是“纯知识建议”，像知识问答、文档生成，自动执行，不需要人确认；第二层是“流程辅助执行”，像工单创建、邮件通知、数据汇总，智能体直接做，但全程留痕，人可随时撤回；第三层是“高风险操作”，像调整工艺参数、下发设备控制指令，必须有严格的审批链，业务负责人在系统里点确认才生效。
安全边界不是一刀切，而是按风险等级配置执行深度。这样既避免智能体乱操作，又不至于让所有动作都卡在人工环节，变得比没有智能体还麻烦。这个设计的核心思路是“把边界写进流程，而不是把判断全交给大模型”。
5.3 制造企业最常问的三个决策问题
第一个问题：用公有云还是私有化部署？我的建议是，如果你的数据牵涉核心工艺参数、订单信息，或者对合规性有要求，建议私有化部署为主，云上跑模型训练和分析可以，但生产环节的数据别上去。中小企业如果没有条件自建算力，可以用行业云的私有化空间，部署一套独立的模型服务，把数据边界划清楚。
第二个问题：大模型会不会取代制造工程师？现在经常讨论大模型取代工作，但我们在制造业看到的现实是，智能体在取代“岗位中的任务”，而不是“岗位上的人”。一个工艺工程师典型的日常工作里，可能有30%是查资料、算参数、填报表，这30%完全适合交给智能体；但剩下涉及工艺创新、异常判断、跨部门协商的部分，智能体短时间内替代不了。与其焦虑被取代，不如主动把自己的经验搬进知识库，成为那个给智能体喂货的人，反而能放大个人的价值。
第三个问题：现在如果不上智能体，会不会被同行甩开？这是个真实的焦虑。但我要泼一盆冷水：制造业里慢半拍不可怕，可怕的是乱吃药。选错方案商、上错场景，赔进去的是真金白银和时间。我建议现在做的事情很简单：一是把内部的数据治理和系统集成基础打牢，二是选一个合适的小场景做验证，三是保持对AI工具链的敏感度。先把基本功做扎实，真正具备了条件再上智能体，并不晚。
5.4 我踩过坑之后总结的避坑速查表
这几年的经验，我整理成一张在制造业快速避坑的速查表，选型和项目推进时逐条对照：
| 误区 | 现象 | 应对办法 |
|---|---|---|
| 迷信模型参数 | 方案商把GPU规模和模型榜单当卖点 | 关注它在你现场场景的真实效果，用概念验证管它跑一遍 |
| 忽略数据现状 | 项目启动后才发现数据接口不通 | 合同前先做数据盘点，把数据成熟度写入需求清单 |
| 追求全流程自动 | 一上来就做无人工干预的闭环控制 | 从“建议辅助+人工确认”开始，再逐步提自动化率 |
| 只看初期建设费 | 忽略了后续模型迭代和服务成本 | 合同里明确运营周期、迭代内容与增补费用 |
| 不建反馈回路 | 上线后效果逐渐变差却不知道原因 | 上线第一天就把交互日志和结果反馈链路搭好 |
| 业务部门被当成配角 | IT部门主导，车间师傅不理解不配合 | 成立业务、IT、OT联合小组，试点从愿意用的车间开始 |
| 目标设得虚 | KPI是“提升智能制造水平” | 把KPI定为“某环节排查时间缩短X%”“自动完成率到X%” |
最后再分享一个我个人实际摸出来的土办法：在项目启动的第一天，就让智能体的使用方在系统的显眼位置看到它的第一批推荐结果，哪怕只有70%的准确率。只要推荐结果有用，哪怕需要人工修正，让业务人员感觉到“这东西能帮我省掉一半查资料的时间”，这个项目就成功了一大半。真正让智能体在制造业里活下来的，不是算法有多强，而是有没有让现场的人在用的那一刻觉得“它真懂我”。选方案商、做MVP、建反馈回路，我踩过不少跟头之后发现，所有的方法论最终都可以浓缩成这一条：从一个人愿意用的场景开始，把它用透，用到离不开了，再谈其他。
