怎么把业务需求翻译成AI能做的事？

业务方很少会说「我需要一个分类模型」。他们说的是「这个活太累了」「老出错」「新人上手太慢」。这些都是抱怨，不是需求。翻译工作就从这里开始。

一、第一步：把抱怨还原成动作

追问的核心是：这件事具体是谁、在什么时候、对着什么东西、做什么操作。把「报价太慢」还原成「销售拿到客户图纸后，要找工艺员估工时、找采购问料价、再自己套公式算，平均三天」。

还原到这个颗粒度，问题的形状就出来了：三天里有多少花在等人回复上，多少花在实际计算上。这两个数字决定了该优化哪一段。

很多项目跳过了这一步，直接进入方案设计，结果做出来的系统优化的是本来就不慢的那一段。

二、第二步：从动作里拆出判断

把每个动作分成两类：照规则执行的和需要判断的。查表、套公式、填单据属于前者，用传统自动化就能解决，不需要 AI。

「看这张图纸大概属于哪一类产品」「这个客户的要求算不算特殊」「这批料的描述和库里哪个物料是同一个」属于后者，这才是 AI 真正能发挥价值的地方。

一个判断标准：如果这件事换个熟练老员工来做，他要想一下，那就是判断；他不用想，那就是规则。规则的部分别用 AI，贵且不稳定。

老员工要想一下的地方，才是 AI 的战场。不用想的地方，写个脚本更靠谱。

三、第三步：确认判断有没有依据

找到判断环节之后，要问一个残酷的问题：这个判断是基于什么做出来的？如果答案是「凭经验」，那就要继续追问经验来自哪里。

如果经验来自历史案例，那这些案例有没有被记录下来？如果只在老师傅脑子里，那第一步工作不是做模型，是把经验捞出来。

如果连老师傅自己都说不清楚为什么这么判断，那这个场景的难度会陡增，通常建议先换一个场景做。先做说得清的，再做说不清的。

四、阿优至简的视角

我们做需求翻译时有个习惯：让业务方现场演示一遍，我们在旁边看，不打断。看完之后再问问题。

光靠会议室里的描述，永远会漏掉那些「这个大家都知道所以没必要说」的环节。而恰恰是这些环节，最后决定了系统好不好用。看一遍实际操作，胜过开三次需求会。

落地前的三条至简建议

1. 先看操作：坚持现场观摩一遍完整流程，比开会更能发现真实问题。
2. 先分两类：把动作分成规则和判断，规则的部分不要用 AI。
3. 先问依据：判断基于什么信息做出，这个问题答不上来就先别做。

AI 项目的成败，一大半在需求翻译这一步就决定了。技术再强，也救不了一个翻译错了的需求。