业务部门提 AI 需求为什么总说不清

业务部门说不清需求，通常不是表达问题。业务人员熟悉的是具体处理过程，而不是抽象的功能描述；他们知道每一种情况该怎么处理，但很难直接说出这些情况可以被归成几类。把经验转成规则，需要一套方法，而不是要求对方一次说清。

从具体案例开始，而不是从概括开始

让业务人员描述功能，往往得到的是模糊表述。换成让他们讲具体案例，信息密度会明显提高。

可行的做法是先收集一批真实实例，覆盖日常处理中最常见的情况，以及印象深刻的异常情况。每一个案例讲清三件事：输入是什么，判断依据是什么，处理结果是什么。

收集到足够的案例之后，规律往往自己会呈现出来。技术方可以据此归纳分类，再回到业务方确认。这种从案例到规则的路径，比从抽象需求到规则更容易推进。

案例数量不需要很多。几十个覆盖全面的实例，通常足以暴露主要的判断分支。收集时按处理环节分组，可以让覆盖是否完整更容易判断。

判断依据要问到条件层面

业务人员说的判断依据，常常停留在感觉层面，例如看起来可疑、感觉不规范。这类表述无法直接转成规则。

追问的方式是把表述落到条件上：根据什么指标判断可疑，超过什么范围算不规范，这个范围是谁定的。多数情况下，业务人员能给出具体条件，只是平时不需要这样表达。

追问过程中会出现两种情况。一种是条件本身模糊但可以量化，这种情况需要业务方给定阈值并承担后果；另一种是条件依赖经验，难以用规则覆盖，这部分应当保留人工处理，而不是强行自动化。

分歧需要显式解决

同一个环节，不同的人处理方式可能不同。这类分歧在原有工作方式下不会暴露，因为各人按自己的判断处理，结果差异不容易被察觉。

转成规则时，分歧会集中出现。此时需要业务方给出统一口径，而不是由实现方任选其一。可以把分歧点单独列出，交业务负责人决策并留档，作为后续处理依据。

分歧不解决就上线，结果是系统按其中一种方式运行，另一部分使用者不认同，进而绕开系统。这比延期更影响项目效果。留档的分歧结论应当在规则变更时一并更新。