制造业 AI 第三关:能验收的,才叫需求

客户说的需求，为什么往往不是他真正要买的东西？

这事在制造业 AI 项目里太常见。人找来了，话也聊了，最后发现双方说的根本不是同一件事。上一关讲客户从哪里来，这一关讲怎么把话问对。

01  老板要的是结果，不是模型

这几年我见过很多渴望聊 AI 的制造业老板。他们对 AI 的认知，比当年对大数据、对移动互联网都要强烈。

最典型的情况是这样的：老板自己用过豆包，开始接触WorkBuddy、Codex这类工具，然后很自然地认为，AI 应该可以解决公司里的一切问题。

但他找到你的时候，说出来的话通常很短：“我要在公司里搞 Agent。”“我要做一个知识库，把老员工的经验都放进去。”再激进一点，“能不能用 AI 替掉一部分人？”

这些都不是可以直接交付的需求。它只是一个方向、一笔预算，或者老板暂时的想象。

企业老板不会因为你用了一个更先进的模型，就天然愿意多付钱。他愿意掏钱，是因为某个具体问题被解决了：

• 员工每天反复查产品资料，现在能更快找到答案；
• 客服、售后、销售不再一天到晚打断研发；
• 一项重复录入的工作少花了多少时间；
• 运营脑子里的流程变成了一套能运行的软件；
• 一项原来依赖某个老员工的工作，开始有了可查询、可交接的记录。

02  第一句话该问什么

所以判断一个项目，第一件事是问两句话：现在具体哪一步最烦、最慢、最容易出错？做完以后，工作会发生什么变化？

这两句话不太客气，但能立刻把话题从技术拉回业务。前一句是在找真正的痛点在哪里，后一句是在确认这个痛点有没有解药。

答得清楚的客户，项目一般能往下走；答不清的，说明他自己还没想明白，这时候你花再多时间做方案也是空转。

FDE 真正要做的，是在老板的想象和实际落地之间找一个平衡点。把一句模糊的话，变成双方都能理解、能够测试、能够验收的结果。

反过来，也有客户一上来就问你们用哪个模型、有没有上最新的框架。这时候你要把话头接回来：模型可以慢慢选，先说说现在这一步是怎么做的、卡在哪里。

03  混乱本来就是交付的一部分

这也是 FDE 和普通软件开发最不一样的地方。

普通开发可以等产品经理把需求拆完，再按任务写代码。企业 AI 项目刚起步时，客户自己通常也没想清楚。

资料可能没整理，流程可能靠嘴说，部门之间可能有冲突，老板以为的问题和员工每天真正遇到的问题，甚至不是一回事。

这些混乱不是项目开始前应该由客户自行清理干净的东西。它们本身就是交付的一部分。

FDE 进场要做的第一件事，往往是把这些夹在人与人之间的东西摊到桌面上，写代码反倒是往后排的事。

所以第一阶段的动作要小，把老板嘴里那句模糊的话，收缩成一个双方都能理解、能够测试、能够验收的结果。

进场调研的时候，我习惯带一张空白的调研表。不填功能，只填人和流程：这个环节谁在做、做完交给谁、错了谁兜。

填满之后，很多所谓的需求会自己浮出来，很多想象中的需求也会自己消失。

客户要的是这个东西能不能用，错了谁接，做到哪里算完成。数字化项目里，验收标准写得越模糊，后面扯皮的空间越大。一份更先进的方案解决不了这些。

04  FDE 不是一个人假装成一家公司

这里有个常见的误解。一个人确实可以完成一些简单、边界清楚的场景，但项目稍微复杂一点，获客、产品、开发、测试、部署、运维和客户沟通，不可能全压在一个人身上。

这时候就要跟做过交付、彼此信任的伙伴合作。

所谓 FDE 或者 OPC，说的是核心人员足够少、决策链足够短的一支队伍，同时清楚自己缺什么、该找谁补上。

这一点在接单之前就要想清楚。有交付能力、彼此信任的伙伴，不能临时缺人了才去找。

平时不联系，出了事再打电话，对方多半也没空。所以找伙伴这件事，最好在没有项目的时候就开始做。

那么把一句模糊的话翻译成一个能验收的结果，具体怎么做？

答案就是问清楚哪一步最烦、做完之后工作会发生什么变化。

这套问法不复杂，建议先收藏，下次坐下来谈之前过一遍。这十三关会一篇篇发，跟着走完，就是一套从接单到交付的完整流程。

下一关要聊的是另一头：老板能说清预算，但说不清交付边界。