FDE第一次见客户，到底应该问哪20个问题？

判断问题真实性与业务价值

客户第一次见面说：“我们想做一个销售Agent。”很多团队会立刻追问：想用哪个模型？知识库有多少文档？要不要私有化？需要接哪些接口？这些问题并非不重要，只是问得太早。因为“销售Agent”可能指会后整理纪要，也可能指线索评分、自动跟进、报价生成，甚至端到端推进商机。不同目标需要完全不同的数据、权限、风险和投入。

FDE第一次见客户的任务，不是现场把方案讲得多完整，而是判断一个模糊愿望背后有没有值得解决的真实工作流。OpenAI当前FDE岗位把discovery、technical scoping、system design、build和production rollout放在同一个端-to-end责任中，并用生产采用、可衡量工作流影响和评估反馈判断成功。这意味着好的客户发现，必须从业务结果一直问到未来如何运行。

下面20个问题分成五组。它们不是审讯清单，也不要求一次会议机械问完。真正目的，是让价值、流程、依赖、风险和责任变得可见。

还原真实工作流与例外路径

第一组问完，FDE应能写出一句问题陈述：谁在什么场景遇到什么摩擦，带来什么影响，希望哪项可测结果改善。

第二组聚焦流程本身：什么事件会启动这项工作，什么状态才算真正完成？触发与结束定义了工作流边界。收到邮件、创建订单和客户挂断电话，都可能是不同触发；生成答案不一定算完成，写回系统或得到客户确认才可能是终点。

能不能现场带我走一遍最近一个真实案例？不要只听SOP。让执行者打开真实系统，从头到尾展示操作，FDE才能看到复制粘贴、私人表格、群内确认和经验判断。

正常路径之外，最常见的五种例外是什么？真实项目往往死在例外里：字段缺失、政策冲突、客户身份不明、系统超时、金额超限。例外数量也决定第一版是否应继续缩小范围。

哪一步最慢、最容易返工，哪一步完全依赖个人经验？慢不一定最适合AI。要区分信息搬运、规则判断、关系协商和权责决定。个人经验还要追问能否表达成标准，还是必须保留给人。

OpenAI Academy的工作流映射方法同样要求识别触发、可信输入、当前步骤与绕行、交接、输出、摩擦和待标准化事项。FDE要发现企业真实如何工作，而不是只把流程图上的方框自动化。

厘清数据、知识与系统依赖

第三组聚焦支撑要素：完成一次任务需要哪些信息，分别在哪里？列出结构化字段、文档、邮件、对话和外部数据。信息“存在”不等于可用，还要知道格式、质量和访问方式。

哪个来源是权威版本，谁负责更新？如果价格表、政策和产品说明在多个系统冲突，Agent无法自己决定哪个是真的。没有Owner的知识库会随时间快速失真。

当前涉及哪些系统，能读什么、写什么？明确CRM、ERP、工单、邮件和数据仓库的接口、认证、限流与环境。把“系统能接”细化为只读、生成草稿、更新字段、发送消息或执行不可逆动作。

能否提供一批脱敏历史样本和对应正确结果？没有真实样本，就无法建立基线和评估集。只有输入而没有正确动作，团队仍需邀请业务专家共同标注。

Microsoft的Agent设计框架把触发、渠道、数据、工具、流程、治理和评估放在一张画布里，并提醒不要把实际发生在邮件或业务系统的工作错误设计成聊天入口。技术问题必须服务于真实工作场所。

识别风险边界与人工决策点

第四组聚焦安全与权责：一次错误最坏会造成什么后果？错误答案、错误写入、错误付款和错误拒绝客户的风险完全不同。严重性、可逆性和影响范围决定自主程度。

哪些数据绝对不能访问、传出或长期保留？不能只问“数据敏不敏感”，要落实到字段、用户、区域、处理目的和保留时间，并由安全、隐私和法务相关方确认。

哪些动作必须由人批准，谁有决定权？区分AI可完成、可准备供审核、以及必须由人承担的决定。建议不是授权，模型置信度也不能替代组织决策权。

遇到缺失、冲突、低置信度或越界请求时，应该交给谁？升级不是失败状态，而是工作流的一部分。要明确停止条件、接收人、需要携带的上下文和服务时限，避免用户重新讲一遍。

OpenAI Agent Activator材料强调允许信息、禁止动作、人工复核和停止/询问/升级条件。首次会议不一定做完风险评审，但必须尽早识别需要谁进入下一轮。

确认组织采用条件与后续验证

第五组聚焦落地可持续性：谁是业务Owner，谁能决定范围和验收？发起需求的人不一定对结果负责。Owner需要提供用户、数据和业务判断，也要有权处理跨部门阻塞。

谁会每天使用或受它影响，他们现在在哪里工作？用户在CRM、邮箱还是协作群？如果新方案要求改变入口、重复登录和手工搬运，采用成本必须计入。

上线后谁负责支持、监控、知识更新和事故处理？没有持续Owner的Agent会在人员变动、政策更新和模型升级后失效。FDE不能把自己的长期驻场当作唯一运行方案。

下一步要做什么，谁在什么时间提供什么证据？首次会议不必形成最终报价，却必须形成下一步：流程跟访、数据抽样、安全评审、评估工作会或范围确认。每项都有责任人和日期。

区分事实、判断与愿望

同一个问题，客户可能给出三种性质完全不同的回答。“上个月一共处理了4280张工单，平均解决时间是16小时”，属于可以回到系统核验的事实。“客服觉得查政策最浪费时间”，属于一线判断，需要通过跟岗和抽样进一步验证。“我们希望上线后效率提升一倍”，则是目标或愿望，不能直接当成项目基线。

FDE在会议记录里最好给答案标注证据等级：已经有系统数据，可以现场提供样本，需要相关Owner确认，或暂时只是一个假设。这样做不是怀疑客户，而是避免团队在不同含义的数字上做方案和报价。

追问也要尽量从抽象走向具体。客户说“流程很慢”，可以问最近一次超时发生在哪一步；客户说“数据很多”，可以问一周能否提供50个脱敏案例；客户说“准确率必须达到99%”，可以问当前人工基线是多少、哪些错误比其他错误更严重。

一次60到90分钟的首次会议，可以把前15分钟用于目标与背景，中间40分钟沿着真实案例走流程，随后20分钟确认系统、风险与责任，最后10分钟复述已知、未知和下一步。若参与者很多，不要试图当场完成所有细节，把需要一线、技术或风险相关方回答的问题拆成后续工作会。

对国内企业项目尤其要留意“名义流程”和“实际流程”的差异。审批可能写在系统里，真正的优先级却在微信群确认；数据名义上归某部门，接口权限却由集团IT管理；业务负责人支持项目，一线团队却正在承受多个系统切换。把这些组织现实问出来，往往比多确认一个模型参数更能预测项目能否落地。

20问背后的五项关键判断

第一，问题是不是真实且值得。第二，工作流能否被描述和缩小。第三，数据与系统能否支撑。第四，错误是否可控、责任是否清楚。第五，组织有没有条件采用和持续运营。

如果五项都比较清楚，可以进入技术范围和PoC设计。如果价值明确但流程混乱，先做流程标准化。如果数据缺失，先安排样本审计。如果风险与决策权没有相关方参与，就把风险工作会作为下一步。

好的FDE不会因为客户当场答不出而急着否定项目。未知项本身就是发现成果，只要它被记录成验证任务，而不是被乐观假设掩盖。

会后交付五项具体产出

第一，一句话问题陈述与预期结果。第二，当前流程、关键例外与痛点地图。第三，数据、系统、权限和相关Owner清单。第四，初步AI/人工边界与主要风险。第五，下一步验证计划、责任人与时间。

把仍然未知的内容单独列出，并区分“客户待提供”“FDE待验证”“需安全或法务决策”。这样第二次会议才能推进，而不是重复第一次讨论。

首次会议最不该做的三件事

第一，不要在问题还没说清时展示所有产品能力。客户会被功能带着走，真实流程反而被隐藏。

第二，不要只和高层谈愿景。高层定义方向，一线员工掌握例外，系统Owner知道依赖，风险团队决定边界，缺一方都不完整。

第三，不要承诺一个未经数据和流程验证的ROI。可以提出假设和测量方法，不能把估算说成结果。

FDE的专业感，不来自现场回答所有问题，而来自知道哪些问题现在必须回答、哪些证据还缺、哪些人必须加入，以及在信息不充分时不替客户做未经授权的决定。

第一次会议结束时，最好的结果不是客户说“这个Agent听起来很厉害”。而是双方都能清楚复述：我们在解决哪条工作流，为什么值得，第一版做到哪里，哪里必须由人负责，以及下一步用什么证据决定是否继续。

JOTO 企业落地观察

• 对企业部署意味着，首次客户会议的核心不是技术方案设计，而是业务可行性验证。FDE需将模糊需求锚定到可测量的业务结果、可追溯的真实流程和可获取的脱敏样本上，否则后续所有模型选型、RAG构建和智能体编排都缺乏可靠基线。
• 这类系统的取舍在于：当客户无法提供权威知识源或系统写入权限时，企业需在‘轻量级辅助’（如仅读取+生成建议）与‘深度集成’（如自动更新CRM字段）间做出明确选择。前者降低风险但价值有限，后者需前置协调IT与法务，延迟启动但具备规模化潜力。
• 对AI安全治理而言，第13–16问构成最小可行风控框架。企业必须在项目早期明确错误后果等级、数据禁令字段、人工复核动作清单及升级路径，这些不是技术配置项，而是需由业务Owner、安全官与法务三方签字确认的治理契约。
• FDE驻场共创的价值，在于将客户回答中的‘判断’（如一线员工认为查政策最耗时）转化为可验证动作——例如安排半天跟岗抽样20次操作，而非直接基于该判断设计RAG检索策略。这种实证节奏决定了智能体能否脱离Demo阶段。