“希望系统更智能”很难直接转成开发任务。“每天要在三个表格之间核对同一个订单”则已经接近一个可以解决的问题。两句话的差别，通常来自一次认真观察，而不是一次更长的需求会议。
从最近发生的一件事开始
英国政府的服务设计手册建议通过访谈、观察和既有证据理解使用者，并将未经验证的意见作为假设处理。[1] 对企业系统项目，这意味着可以先请一位员工演示最近完成的一笔工作，而不是直接讨论理想功能清单。
以物流异常处理为例，让操作人员从收到异常消息开始，演示查单、核对设备记录、联系负责人和关闭工单的过程。记录每次切换页面的原因、复制了哪些字段、哪一步需要等别人答复。观察时先不打断，也不要急于把每一步改成 AI。
区分工作时间与等待时间
一个流程用了一天，不代表一天都在操作。它可能包含十分钟查资料、两小时等确认，以及后续无人接手的空档。如果只优化文字生成速度，主要延迟仍然存在。
可以把过程拆成主动操作、系统等待和组织等待三类。主动操作适合通过界面或自动化减少；系统等待要检查接口与数据更新；组织等待往往需要明确负责人、通知规则或审批边界。分类之后，AI 是否适合介入，才有具体的判断对象。
把例外写进需求，而不是留给上线
正常流程容易说明清楚，例外更能揭示系统边界。订单号缺失时如何查找？两个系统的状态冲突时相信哪一个？负责人休假时交给谁？这些问题决定了系统在真实环境中是否可用。
我们建议建立一张简短的异常表，每一行包含触发条件、现在的处理方式、允许的自动动作和人工接手人。先覆盖高频或后果较重的异常，其他情况明确进入待处理队列。表格的作用是让责任可见，不是穷举所有可能性。
用小样本形成下一步，不替代全面结论
观察几次工作足以发现候选问题，却不足以证明整个公司的效率损失。选择试点时，应补充不同班次、不同熟练程度和不同任务复杂度的样例。访谈中的估计时间与系统日志中的实际时间，也要分开保存。
一个合适的发现阶段产物可以只有四页：当前流程、主要阻塞、试点范围、验收方法。把尚未确认的内容标出来，并指定下一次验证动作。这样，团队讨论的重点会从“谁的想法更好”转向“哪一个假设值得先验证”。
下一次需求访谈，请对方演示最近一次完成的工作，并问：哪一步让你不得不离开当前系统？
参考资料
本文结合公开资料与 Terriva 的方法建议整理。文中的假设场景用于说明设计思路，不代表客户实绩。