04｜客户说“做一个智能助手”，第一步该问什么？

采购在找什么？是哪份表格找不到，还是几份表格的数字对不上？建议交给谁批准？批准之后，谁跟进供应商和仓库？如果这些问题没有答案，功能清单很可能只是把旧流程换了一个入口。

业务发现要做的，是让团队从抽象愿望走到可核查的任务。最有效的起点通常不是“你希望 AI 有什么功能”，而是“请带我完整看一次最近发生的工作”。

“采购效率不高”很难直接验证。一条运输延期通知却可以打开实际流程：消息何时到达，谁先看到，采购查了哪些库存，为什么决定调拨，负责人如何批准，执行中发生了什么。

沿着一项具体任务询问，能够减少事后概括造成的遗漏。业务人员可能说“我们有问题就通知仓库”，但查看记录后会发现，有时在群里发消息，有时修改表格，有时只口头说明。不同做法会影响谁能及时接到信息，也影响系统应该接入哪里。

第一次访谈可以围绕五个连续动作展开：请对方展示触发记录，说明需要达成的结果，演示实际处理过程，指出卡住的位置，展示最终交给下一个人的材料。每一步都尽量对应一份消息、表格、单据或系统记录。

这并不要求客户在开会前准备完美资料。资料缺口本身就是调查结果。例如找不到审批记录，可能意味着审批只发生在聊天里；不能说明库存更新时间，可能意味着系统缺少必要的时间语义。此时应记录未知，安排补查，而不是替客户补出一个理想流程。

提出需求的人不一定是使用者，使用者也不一定有权开放数据。物流项目中，运营关心缺货，采购负责方案，仓库负责实物记录，财务关注预算，IT 负责接口，管理者决定资源与授权。少了其中某个关键角色，某些条件可能在开发后才被推翻。

利益相关者地图应记录他们与任务的关系，而不只是姓名和联系方式。谁提出机会？谁确认业务目标？谁维护数据？谁批准动作？谁承担长期运行？谁会因为新流程多出工作？

最后一个问题尤其重要。采购希望自动汇总库存，但若代价是仓库每天额外填三份表，试点可能很快停止。调查需要看见工作量的转移，把新责任放到具体角色面前确认，而不是把它写成“业务配合”。

当不同角色存在分歧，应先把冲突对应到真实决策。运营希望快速补货，财务希望控制现金占用，两者都可能合理。FDE 需要帮助明确本轮任务的目标与约束，并找有权的人作出取舍，不能自行用技术偏好替代经营决定。

单次访谈可以提供线索，但不足以覆盖完整事实。人们倾向于描述正常流程、成功经验和自己的职责范围。异常处理、等待、返工和岗位之间的空隙，往往需要其他材料才能看见。

可以用四种来源交叉检查同一项判断。口述解释为什么这样做；系统记录说明操作何时发生；业务数据提供数量、频率与结果；现场观察展示那些没有进入系统的绕行和补救。

假设采购说“每次缺货都因为物流通知太晚”。进一步检查可能发现，通知已及时到达，但原补货表没有更新到货日期；也可能发现库存记录本身过期。两种原因需要不同的方案。前者涉及事件如何改变现有判断，后者涉及数据刷新与维护责任。

调查并非为了证明某个岗位说错了，而是把一个影响结果的问题还原到足够具体的条件。记录中应保留来源和时间，避免把对方的意见直接改写成全公司的事实。

正常任务能说明系统要完成什么，异常任务往往决定系统能否安全进入业务。访谈中应主动寻找最近一次失败、例外或需要人工协调的情况。

设备租赁可以问：客户改日期时怎么办？历史优惠和现行价目冲突怎么办？机器空闲但操作员没有时间怎么办？礼品设计可以问：客户说“可以了”时，确认的是一个方向、一件作品还是一整套？物流可以问：货已签收但有质量隔离，是否已经增加可售库存？

这些问题会暴露规则与责任的边界。所谓“自动完成”，可能只适用于普通情况；遇到例外，需要保留原始依据，让指定角色接手。早期把异常列出来，有助于明确第一期范围，也有助于后续设计评测样本。

异常还应继续追到结果。有些问题看似解决，只是转交出去。采购批准调拨之后，调出仓是否锁货，接收仓是否清点，未满足需求是否仍然存在？如果任务在岗位之间失去状态，自动生成一份建议也无法修复这种断裂。

现状流程常用 As-is 表示，目标流程常用 To-be 表示。画现状时，应忠实保留重复、等待和绕行，不要为了整齐提前优化。先知道实际怎样发生，才能说明改造改变了什么。

一个轻量流程记录可以按“触发—角色—输入—动作—状态—输出—异常”展开。动作描述人或系统做了什么，状态描述业务对象处于哪里。两者需要分开：点击“提交”是动作，申请进入“待审批”才是状态；收到一张物流照片是输入，货物“已入可售库存”则需要其他条件。

跨岗位协作适合用泳道表达；对象状态复杂时，再补一张状态转换图。不是所有项目都需要复杂建模，但至少要知道结果交给谁，以及对方开始下一步需要什么条件。

目标流程在现状基础上重新安排分工。系统可以整理材料，程序可以检查明确规则，模型可以帮助解释，人工保留专业判断和授权。每项改变都应能回答：减少了哪个具体困难，新增了什么条件，由谁负责。

业务发现结束时，不应只有会议纪要和功能愿望。团队至少需要一段问题陈述、一条现状流程、初步基线、关键参与者和一份未知清单。

问题陈述可以这样组织：“某类用户在某个触发条件下，需要完成某项任务；目前因为哪些有依据的原因，产生何种可观察影响；本轮优先调查哪一段。”其中每个关键判断，都应尽量对应记录或待验证项。

以下是可直接使用的访谈收束清单：

为未知指定责任人与时间，可以防止它长期停留在“待确认”。例如“接口是否支持写回”应落实到具体系统负责人和调查动作；“自动建议能否节省时间”应交给后续样本或试点验证。不同类型的未知，需要不同的证据路径。

当一项需求能够从触发记录一路追到后续结果，方案才开始有了扎实基础。下一篇会在这个基础上讨论取舍：发现了很多困难，怎样判断先解决哪个，以及哪一部分真正值得使用 AI。

如果还难以把需求收敛成具体任务，AI随心创提供AI 场景诊断，可围绕当前流程、关键角色、输入资料和质量标准讨论场景优先级。准备一段流程描述和两三个实际样例，有助于更快进入具体问题。