第一次见客户，不要一上来就聊功能，而应该先从下面五个维度入手。
这是我做了一段时间项目、看过一些案例之后的经验总结。大家第一次见客户时，可以拿这 26 个问题直接来问，也可以用它做一遍自查。
一、先看：这是不是一个值得做的业务问题
1. 这条业务现在能不能先靠人，哪怕很笨、很低效的方式跑完？
如果连人工流程都跑不完，AI 往往不是第一个要解决的问题。先确认业务闭环是否存在，才知道该优化什么。
- 2. 客户说想做的功能，背后真正卡住的业务问题是什么？会不会只是他以为的解法？
“做一个智能助手”“上一个知识库”都可能只是表面方案。要继续问：他究竟在哪一步卡住了，为什么现在的做法不行。
- 3. 这个问题解决以后，业务上到底会变好什么？值不值得投入前期整理、试错和后续运行的成本？
节省时间、减少错误、提高转化、缩短响应，还是降低某一类风险？收益要尽量说清，也要和建设、维护成本一起看。
- 4. 这件事发生得多不多、频率高不高？不高频的事，是否真的值得先用 AI 做？
高频、重复、规则相对稳定的环节，通常更容易先跑出价值。低频但高价值的场景也可以做，但判断标准不能只看“听起来很痛”。
- 5. 做成以后，怎样判断它真的有价值，而不只是看起来更像 AI？
一开始就要约定验证方式：看处理时长、错误率、人工投入、业务结果，还是看某个关键节点是否不再堵住。没有验收口径，项目很容易停在“感觉还不错”。
二、再把客户说的一个点，拆成完整业务链路
6. 这件事从什么地方开始，到什么状态才算真正结束？
别只盯着客户指出来的那一步。要找到输入从哪里来、过程中经过谁、最后交付给谁，以及什么结果才算完成。
- 7. 能不能从客户说的痛点往上游、下游拆开，把整条业务链路看清？
很多“AI 问题”其实出在前面信息没进来，或者后面没有人接结果。往上下游拆，才能找到真正值得改的环节。
- 8. 每个环节现在是人做、系统做，还是人和系统一起做？各自依据什么判断？
这能帮助我们判断：这里需要的是 AI、固定规则程序，还是把原本分散的人机协作接起来。
- 9. 每一步和整条链路分别花多久、卡在哪里、返工在哪里？
客户说“效率低”，还不够。要落到具体步骤：谁在等谁、哪些资料反复补、哪些判断总要来回确认。
- 10. 正常流程以外，哪些情况最容易出错、冲突、缺信息，或者根本没有现成规则？
真正难的往往不是标准流程，而是例外。把例外提前暴露出来，才能判断自动化边界和人工兜底怎么设计。
- 11. 判断标准是能被业务专家讲清、写清的，还是主要藏在人的经验里？这些隐性经验能不能一起挖出来？
有些工作看上去只是“经验判断”，但专家其实有一套能讲出来的标准；也有些经验需要通过具体案例慢慢还原。两种情况，做法完全不同。
- 12. 能不能拿一个最近发生的真实案例，把上面这条链路从头走一遍？
一个真实案例，比一段抽象描述更容易让流程、数据、例外和责任边界显出来。第一次沟通时，最好就拿它做共同语言。
三、看数据、经验和系统能不能支撑
13. 这条流程到底需要哪些数据？数据在哪里，能不能持续取得？
不要只问“有没有数据”。要具体到每个关键判断需要什么信息、归谁管、是系统数据还是散落在表格、文档和聊天记录里。
- 14. 数据本身全不全、准不准、有没有清洗和结构化到能给 AI 用？
数据存在，不等于能直接使用。缺失、错误、口径不一、更新不及时，都会让模型输出看上去合理，却无法用于业务。
- 15. 现有系统有没有接口，数据和权限在 PoC、正式执行时能不能真正打通？
PoC 可以先用一份导出的样本验证；正式运行时，数据怎么进来、结果怎么回去、谁能访问，都是另一套问题。
- 16. 这个场景有没有成熟的业务专家经验；没有的话，是否至少有足够的历史案例让大家一起验证、迭代？
AI 项目不一定非要先有一套写好的标准答案。但至少要有能持续参与的业务经验，或者有足够的真实案例，供团队不断校正。
- 17. 哪些数据不能访问、传出或长期保留？
隐私、商业敏感信息和权限边界，不应当等方案快上线才补问。越早明确，越能避免后面发现路线根本走不通。
四、看 AI 的边界、风险与组织能不能承接
18. 哪些结果可以接受误差，哪些动作必须由人复核、批准或承担最终责任？
不是所有环节都适合交给 AI 自主执行。涉及资金、合规、安全和重大客户决策时，尤其要先定义人的复核点。
- 19. 如果 AI 判断错了、系统失败了、数据缺失或情况冲突，谁接手，怎样兜底？
一个能进生产的方案，必须有失败时的工作方式。客户要知道什么情况切回人工、由谁处理、处理后的结果怎样回到流程里。
- 20. 谁真正对这个业务结果负责？谁有权决定范围、调动资源、协调部门和给出授权？
真正的项目负责人，不只是来开会的人。没有能拍板、能协调、能授权的业务 owner，很多问题即使看见了也解不掉。
- 21. 一线人员愿不愿意按新流程工作？他们会不会担心责任、协作成本或收益分配？
流程变化不是技术上线就自动发生。谁的工作被改变、谁多了一步确认、出了问题谁担责，都会影响实际采用。
- 22. 客户这边有没有真正懂业务、愿意持续配合把隐性经验挖出来的人？项目开始和卡住时，谁负责对接和协调？
FDE 不能单靠外部团队猜业务。客户侧需要有稳定的共创者，也需要有人在跨部门卡住时把事情往前推。
五、别把 Demo 当成最终交付
23. 现在的 PoC 到底验证了什么？进入生产环境还缺数据量、性能、安全、稳定性、灰度、回滚和运维中的哪些条件？
PoC 验证的是一个假设，不是上线许可证。样本量、真实接口、并发、异常处理和权限管理，都会在生产环境重新提出要求。
- 24. 上线以后谁持续维护、更新和处理问题？原来的 FDE 不在时，这套东西还能不能运行？
交付不应停在“能演示”。谁维护知识和规则、谁处理异常、谁跟进效果，决定了它是否能留在客户业务里。
- 25. 这条要求究竟是客户特有、行业共性还是跨行业共性？它应该进入产品默认能力、配置模板、专项服务，还是明确拒绝或交给更合适的伙伴？
客户提出的每一个需求，不都应该直接做成产品功能。先判断复用边界，才能避免用大量定制把产品越做越散。
- 26. 如果目前没有成熟经验和历史案例，企业是否真的接受人力、时间和测试环境上的共同投入？
有些场景本来就是新的，不能要求一开始就有标准答案。但双方要先确认：愿不愿意一起投入、一起验证，也一起承担试错成本。
这 26 个问题的价值，不在于把客户问到无话可说。
它的作用是让双方尽早把一件事看清：现在要解决的到底是什么业务问题；这件事能不能被数据、流程和组织承接；以及它最终能不能从一个演示，变成客户愿意长期使用的能力。
第一次见客户，不一定要当场给出完整方案。先把问题问对，后面的方案、PoC 和产品边界，才有可能建立在真实需求上。
关注赵指导，每天学习一点小知识，3个月让自己刮目相看。
