客户说的需求，往往不是真需求

客户说“我们想做一个知识库问答”，真实问题可能是新人培训成本太高。客户说“我们想做一个销售助手”，真实问题可能是线索优先级混乱。客户说“我们想做自动报表”，真实问题可能是管理层不信任现有数据口径。

客户说出来的，常常是他想象中的解决方案，而不是问题本身。

这不是客户不专业，而是新技术场景里很正常的现象。面对一个尚未成熟的品类，客户很难准确描述自己需要什么。他会借用市场上听到的词：助手、Agent、知识库、自动化、智能分析。但这些词只是容器，真正的问题要继续往下拆。

所以 FDE 不能只听需求，要看行为。

真实需求通常藏在绕路动作里。员工为什么从系统导出数据到 Excel 再处理？为什么明明有审批系统，大家还是先在群里问？为什么制度文档都在知识库里，新人还是到处找人？为什么每次出报告都要找同一个老员工？

这些绕路动作说明，现有系统没有真正解决问题。Excel 不是低级工具，它往往是组织对系统缺口的自救。群聊不是不规范，它常常承载了正式流程处理不了的例外和默契。老员工不是单点依赖的偶然，而是隐性知识没有被系统化的结果。

好的调研不是只做访谈，而是观察真实工作。跟着一个用户完成一天工作，看他打开哪些系统，复制哪些字段，在哪些地方停顿，问了谁，绕过了哪个流程，信任哪张表，不信任哪个后台。很多关键信息不会出现在会议上，只会出现在实际操作中。

还要看组织里的隐性知识。有些流程文档写得很清楚，但实际运转靠经验。有些数据源名义上权威，但大家都知道不准。有些审批系统形式完整，但真正决定早在群聊里完成。这些东西如果不被看见，AI 系统就会接入一个“纸面上的组织”，而不是“真实运转的组织”。

FDE 的任务，是把客户说的需求还原成真实痛点，再把真实痛点翻译成可验证的系统方案。客户说什么很重要，但客户实际怎么工作更重要。

做现场观察时，可以重点看三类信号。第一类是重复动作。凡是用户每天、每周重复做的复制、汇总、核对、分类，都可能是自动化机会。第二类是中断动作。凡是用户频繁停下来问人、查表、翻邮件、等审批，都可能是信息流或决策流断点。第三类是绕行动作。凡是用户绕开官方系统去用 Excel、微信群、私人文档，都说明正式系统没有满足真实需求。

观察完之后，不要急着写功能清单，而要写“痛点叙事”：某个角色，在某个流程里，因为某个信息或系统缺口，反复付出某种成本，导致某个业务结果变差。这个句子写清楚，方案才有根。

比如“做销售助手”可以还原成：销售每天面对大量线索，但 CRM 中字段不全、历史沟通分散、客户优先级不清，导致高价值客户跟进延迟。这样一来，方案就不一定是聊天助手，而可能是线索补全、优先级评分、下一步动作建议和跟进提醒。

需求不是客户说出来的名词，而是你从客户行为里还原出的因果链。

这一篇可以特别强调“看见变通”。变通不是坏事，它是组织对系统缺陷的补丁。员工私下维护一张 Excel，说明正式系统没有给他足够灵活性；大家先在群里问再走审批，说明审批系统不能承载真实讨论；新人反复问老员工，说明知识库没有解决信任问题。

FDE 要做的不是嘲笑这些变通，而是理解它们为什么存在。很多好产品机会，就藏在这些看似不规范的动作里。因为它们代表用户愿意付出额外成本也要完成的事，这往往比口头需求更真实。