FDE见客户的26个必问清单

一、先看：这是不是一个值得做的业务问题

第一次见客户，不要一上来就聊功能，而应该先从下面五个维度入手。

这是我做了一段时间项目、看过一些案例之后的经验总结。大家第一次见客户时，可以拿这 26 个问题直接来问，也可以用它做一遍自查。

1. 这条业务现在能不能先靠人，哪怕很笨、很低效的方式跑完？

如果连人工流程都跑不完，AI 往往不是第一个要解决的问题。先确认业务闭环是否存在，才知道该优化什么。

1. 2. 客户说想做的功能，背后真正卡住的业务问题是什么？会不会只是他以为的解法？
2. 3. 这个问题解决以后，业务上到底会变好什么？值不值得投入前期整理、试错和后续运行的成本？
3. 4. 这件事发生得多不多、频率高不高？不高频的事，是否真的值得先用 AI 做？
4. 5. 做成以后，怎样判断它真的有价值，而不只是看起来更像 AI？

一开始就要约定验证方式：看处理时长、错误率、人工投入、业务结果，还是看某个关键节点是否不再堵住。没有验收口径，项目很容易停在“感觉还不错”。

二、再把客户说的一个点，拆成完整业务链路

6. 这件事从什么地方开始，到什么状态才算真正结束？

别只盯着客户指出来的那一步。要找到输入从哪里来、过程中经过谁、最后交付给谁，以及什么结果才算完成。

1. 7. 能不能从客户说的痛点往上游、下游拆开，把整条业务链路看清？
2. 8. 每个环节现在是人做、系统做，还是人和系统一起做？各自依据什么判断？
3. 9. 每一步和整条链路分别花多久、卡在哪里、返工在哪里？
4. 10. 正常流程以外，哪些情况最容易出错、冲突、缺信息，或者根本没有现成规则？
5. 11. 判断标准是能被业务专家讲清、写清的，还是主要藏在人的经验里？这些隐性经验能不能一起挖出来？
6. 12. 能不能拿一个最近发生的真实案例，把上面这条链路从头走一遍？

一个真实案例，比一段抽象描述更容易让流程、数据、例外和责任边界显出来。第一次沟通时，最好就拿它做共同语言。

三、看数据、经验和系统能不能支撑

13. 这条流程到底需要哪些数据？数据在哪里，能不能持续取得？

不要只问“有没有数据”。要具体到每个关键判断需要什么信息、归谁管、是系统数据还是散落在表格、文档和聊天记录里。

1. 14. 数据本身全不全、准不准、有没有清洗和结构化到能给 AI 用？
2. 15. 现有系统有没有接口，数据和权限在 PoC、正式执行时能不能真正打通？
3. 16. 这个场景有没有成熟的业务专家经验；没有的话，是否至少有足够的历史案例让大家一起验证、迭代？
4. 17. 哪些数据不能访问、传出或长期保留？

隐私、商业敏感信息和权限边界，不应当等方案快上线才补问。越早明确，越能避免后面发现路线根本走不通。

四、看 AI 的边界、风险与组织能不能承接

18. 哪些结果可以接受误差，哪些动作必须由人复核、批准或承担最终责任？

不是所有环节都适合交给 AI 自主执行。涉及资金、合规、安全和重大客户决策时，尤其要先定义人的复核点。

1. 19. 如果 AI 判断错了、系统失败了、数据缺失或情况冲突，谁接手，怎样兜底？
2. 20. 谁真正对这个业务结果负责？谁有权决定范围、调动资源、协调部门和给出授权？
3. 21. 一线人员愿不愿意按新流程工作？他们会不会担心责任、协作成本或收益分配？
4. 22. 客户这边有没有真正懂业务、愿意持续配合把隐性经验挖出来的人？项目开始和卡住时，谁负责对接和协调？

FDE 不能单靠外部团队猜业务。客户侧需要有稳定的共创者，也需要有人在跨部门卡住时把事情往前推。

五、别把 Demo 当成最终交付

23. 现在的 PoC 到底验证了什么？进入生产环境还缺数据量、性能、安全、稳定性、灰度、回滚和运维中的哪些条件？

PoC 验证的是一个假设，不是上线许可证。样本量、真实接口、并发、异常处理和权限管理，都会在生产环境重新提出要求。

1. 24. 上线以后谁持续维护、更新和处理问题？原来的 FDE 不在时，这套东西还能不能运行？
2. 25. 这条要求究竟是客户特有、行业共性还是跨行业共性？它应该进入产品默认能力、配置模板、专项服务，还是明确拒绝或交给更合适的伙伴？
3. 26. 如果目前没有成熟经验和历史案例，企业是否真的接受人力、时间和测试环境上的共同投入？

有些场景本来就是新的，不能要求一开始就有标准答案。但双方要先确认：愿不愿意一起投入、一起验证，也一起承担试错成本。

这 26 个问题的价值，不在于把客户问到无话可说。

它的作用是让双方尽早把一件事看清：现在要解决的到底是什么业务问题；这件事能不能被数据、流程和组织承接；以及它最终能不能从一个演示，变成客户愿意长期使用的能力。

第一次见客户，不一定要当场给出完整方案。先把问题问对，后面的方案、PoC 和产品边界，才有可能建立在真实需求上。

JOTO 企业落地观察

• 对企业部署意味着：FDE首次拜访不应聚焦于技术方案，而应成为一次联合诊断。26问中前5问构成最小可行性验证框架，企业需在启动任何开发前，用真实业务指标（如人工耗时、错误率、响应延迟）确认问题存在且可衡量。
• 这类系统的取舍在于：当客户提出‘做一个智能助手’时，团队必须通过问题6–12厘清其实际嵌入的业务链路。若输入依赖未打通的ERP字段、输出需人工二次录入CRM，则当前阶段更适合构建轻量级API桥接而非大模型应用。
• 对RAG知识工程而言，问题13–17是不可绕行的准入检查。企业若无法提供持续更新、带元数据标注、符合权限策略的文档源，强行构建知识库将导致召回结果不可信、更新机制失灵，最终沦为静态检索工具。
• AI安全治理需前置嵌入问题18–22的判断逻辑。例如问题18要求明确人机责任边界，这意味着企业必须在设计阶段定义哪些输出需人工复核、哪些操作触发审计留痕——这直接决定模型部署时的安全策略配置粒度。