发现阶段：FDE进场之后的三件事丨三类对话、四类现场诊断、三个选点
上一篇说，发现阶段结束的标志是一句双方都认可的问题定义——可以说清楚，可以被衡量。
这篇讲怎么把客户一开始说的那句模糊的话，变成那句清晰的定义。
FDE进场之后，有三件事要同时推进：翻译需求、诊断现场、选定第一个落地点。这三件事不是顺序完成的，是在同一段时间里交织进行的。把它们分开讲，是为了说清楚每件事的逻辑；实际操作里，你和用户对话的同时就在诊断现场，诊断现场的过程里就在筛选落地点。
NotebookLM的音视频概览，解读的比较通俗易懂，对于时间比较紧张的读者朋友，可以听听，会有启发。
需求文档，捕捉不到真正的问题
先说一个案例。
客户找来，说想用AI优化客服流程，把一线人工处理量降低60%。高管签了合同，PM把这个目标拆成了一堆需求子任务，开发团队开始动工。三个月后，系统上线，技术指标全部达标——但用户不用，或者用了之后各种不满意。
出了什么问题？
不是模型不够好，不是工程质量差。是有一条不成文的规则从来没有人说出来：这家公司的客服团队有个内部约定，凡是涉及老客户的投诉，必须由人工处理，不走自动化流程。这条规则存在于团队的肌肉记忆里，没有写进任何文档，高管不知道，PM不知道，开发团队当然也不知道。
AI系统上线之后，第一批被转给自动化流程的，恰好有几个老客户投诉。结果可想而知。
这类问题有一个共同特点：它们往往不会出现在需求文档里，只有进了现场，和真实用户坐在一起，才有机会被发现。
需求文档能捕捉到的，只是客户能描述清楚的那部分需求。但决定一个AI系统能否真正被用起来的，往往不是这部分。
实际上，任何一个落地项目里，需求大致分三层：
第一层是明说的需求——客户能描述清楚、可以写进文档的。这部分最容易处理，也最容易被当成全部。
第二层是没说出来的需求——客户知道，但没想到要说，或者觉得理所当然不用说。上面那条不成文的规则就属于这一层。
第三层是客户自己也不知道的需求——只有在真实使用场景里才会暴露。系统上线之后，用户在用的过程中发现某个功能不对劲，说不清楚哪里不对，但就是用着别扭——这种反馈背后，往往是第三层需求没有被挖出来。
大语言模型有一类传统软件没有的失败方式，而且这类失败在测试阶段几乎发现不了。
传统软件出错，通常会报错、返回错误码、或者直接崩溃——用户知道出问题了。但大语言模型出错的方式不一样，它不报错，它继续生成内容，只是内容是错的。
三种具体情况：
测试阶段用的都是标准问法，模型表现很好。但真实用户的问法千奇百怪，遇到模型没见过的表达方式，它不会说"我不懂"，而是自信地给出一个错误答案——用户完全不知道答案是错的。
企业的知识库如果文档格式混乱、分块不合理，模型检索不到相关内容，但它不会说"没找到"，而是用自己的训练知识编一个听起来合理的回答。
企业内部有很多专业术语，听起来像敏感词但其实是正常业务用语。某家公司内部把一类高风险客户叫"黑名单用户"，模型看到"黑名单"可能直接拒绝回答，或者跳出警告。用户只是问了个正常业务问题，却被系统当成了违规请求。
这三种情况的共同点：需求文档里不会写"请确保模型在这些边缘情况下表现正常"，因为客户自己也不知道这些边缘情况存在。只有进了现场，和真实用户一起使用，这些问题才会暴露出来。
这就是发现阶段必须有人进场的根本原因。远程的需求收集，能覆盖第一层，偶尔能碰到第二层，第三层基本是碰不到的。
三类对话：和不同的人问不同的问题
进了现场，要和谁谈，谈什么？
不同层级的人，掌握的信息完全不同，要问的问题也完全不同。把三类人的对话混在一起，或者只和其中一类人谈，拼出来的需求图都是残缺的。
第一类：高层决策者
高管签了合同，他们代表这个项目的方向和资源。和高管谈，不是问功能列表，而是问成功标准和失败边界。
两个问题最重要：“你怎么判断这件事做成了？“和"什么情况下你会叫停？”
第一个问题让高管说出他们真正在乎的指标——不是技术指标，是业务指标。降低多少成本，提升多少效率，用什么来衡量。这个答案会成为整个项目的北极星。
第二个问题同样重要，但更少有人问。高管的容忍边界在哪里，哪些情况是绝对不能发生的，出了什么事项目会被叫停。知道了失败边界，才能在设计阶段就把护栏建好，而不是等出了事再补。
高管离实际使用场景最远，他们给的是方向，但他们描述的需求和一线用户的真实需求之间，往往有很大的落差。这个落差本身，就是发现阶段要找到的东西之一。
第二类：系统管理员和IT团队
这类对话是摸清技术现状的。
数据在哪里，格式是什么，有没有现成的接口，遗留系统的状态如何，合规要求卡在哪里，审批链有多长。这层对话往往会暴露大量在规划阶段完全没有预料到的障碍。
有一个问题值得单独问：“有哪些系统是我们绝对不能动的？“每个企业都有几个使用很久、文档很少、但业务高度依赖的系统。知道这些系统在哪里，能提前规避大量后期的集成风险。
第三类：一线终端用户
这类对话是最容易被跳过的，也是信息密度最高的。
每周使用系统四十小时的分析师，知道的东西是高管和IT都不知道的。和他们对话，不是问"你需要什么功能”，而是跟着他们走一遍实际的工作流程：你现在怎么处理这类任务？哪个环节最耗时？哪里最容易出错？遇到边缘情况怎么处理？
这个过程里，不成文的规则会自然浮现。不是因为用户主动说出来，而是因为你在看他们操作的时候会发现一些奇怪的步骤，问一句"为什么这里要这样做”，答案往往是"我们一直这样做”——背后就是一条没有写进任何文档的规则。
三类对话做完，你手里有三个版本的"需求"。这三个版本通常出入很大，把它们拼在一起，才能找到真正的需求所在。
四类现场诊断：先画地图，再动工
翻译需求的同时，要对现场做一次系统性的诊断。
诊断的目的不是找问题——进场之后问题多得很，如果只是找问题会没完没了。诊断的目的是画地图：这个环境里有什么、缺什么、能碰什么、不能碰什么。有了这张地图，后续的工程工作才能在现实条件下展开，而不是在假设条件下规划。
四类要摸清楚的现状：
数据现状
数据是AI系统的燃料，但很多项目在进场之后才发现，燃料是散的、脏的，或者根本拿不到。
要摸清楚的是：数据在哪些系统里，格式是什么，质量怎么样，有没有大量缺失，有没有使用限制。特别要注意的是"数据在哪里"这个问题——很多企业的数据分散在三到五个不同的系统里，格式各不相同，没有统一的接口，每个系统背后还有不同的数据权属和访问权限。
把这些摸清楚之后，经常会发现原本设想的方案需要大幅调整，因为数据的真实状态和规划时的假设之间有很大的距离。
系统现状
现有系统的架构是什么，有哪些接口是可用的，有哪些早就停止维护但还在跑。
遗留系统是这类诊断里最容易踩坑的地方。很多企业有十年以上的老系统，文档早就不全了，维护的人可能也已经离职，但业务流程高度依赖它。这类系统的接口状态，往往只有进场实际测试才能知道。
权限现状
谁能批什么，审批链有多长，合规部门的要求卡在哪里。
大多数企业障碍不是被说出来的，是被发现的。权限和合规障碍尤其如此——不是因为有人故意隐瞒，而是这类信息在组织内部本身就是分散的，没有一个人能全部掌握。把它们拼出来，需要和多个部门分别确认。
这类障碍不是工程问题，是组织问题。工程师能解决技术上的集成难题，但改变审批流程、推动合规豁免，需要借助客户内部的推动力量。这也是为什么发现阶段要找到内部推动者——技术问题之外，有很多事情需要有人在内部帮着推。
人的现状
谁是真正支持这个项目的人，谁会有阻力，团队对AI的信任程度在哪里。
内部推动者不等于签合同的高管。推动者是那个真正在乎这件事能否做成、愿意在内部帮你扫清障碍的人。从第一周就找到这个人，从第二周就让他参与进来，是后续所有工作能顺利推进的基础。
阻力的来源值得认真对待，不只是要绕开它。很多时候，阻力背后是合理的顾虑——担心AI出错影响客户、担心数据安全、担心工作流程被打乱。把这些顾虑提前摸清楚，在系统设计里就把对应的保护机制建好，比上线之后再处理阻力要省力得多。
三个选点标准：第一个落地点怎么选
翻译完需求、诊断完现场，发现阶段的第三件事是选定第一个真正动手的落地点。
这个选择很重要。第一个项目成功了，会给整个AI落地计划带来信任和动力，后续推进会容易得多。第一个项目失败了，不只是这个项目本身的问题，会让整个AI计划在组织里的信用受损，后续每一步都要先处理信任问题。
选点有三个标准，缺一不可：
低风险
出了问题不会造成严重后果，有容错空间。
第一个落地点的任务不是验证AI有多强，是建立信任。在信任还没有建立的阶段，容错空间非常重要——万一出了问题，要能回滚，要能解释，要不影响核心业务。
客服流程的分流、内部文档的搜索、报表的初稿生成——这类场景出了问题影响有限，适合作为第一个落地点。核心业务系统、财务决策、合规审批——这类场景出了问题代价很高，不适合作为第一个起点。
高可见
成果容易被感知，利益相关方能看到变化。
AI落地项目需要持续的内部支持。如果第一个落地点的效果要靠分析报告才能感知，普通利益相关方看不到变化，项目很容易在内部失去支持。
最好的选点，是成果可以被直接感受到的——处理时间明显缩短，错误明显减少，某个过去很烦人的步骤消失了。这类变化不需要看数据，用户自己就能感受到，感受到了就会开始信任系统。
可迭代
结果可以被测量，可以快速调整。
如果第一个落地点的效果要等三个月才能看到，反馈循环就断了。FDE需要在短周期内知道方向对不对，需要有足够的真实反馈来调整。
可迭代意味着：有清晰的输入输出，结果可以被评测，每次调整之后能快速验证效果是否改善。
这里有一个反直觉的地方：选点不是选最重要的问题，而是选最适合先动的问题。最重要的问题往往风险高、依赖复杂、反馈周期长，放在第一个做是在赌博。先在一个小点上建立成功经验，再向核心问题推进——这不是回避困难，是给整个项目争取足够的信任储备和迭代空间。
发现阶段结束的标志
三件事做完之后，发现阶段结束的标志是一句话，不是一份文档。
这句话的结构是：“我们要解决X问题，通过Y方式，成功的标准是Z。”
X是经过三类对话之后找到的真正问题，不是客户一开始说的那句模糊的话。Y是在四类现场诊断之后，在这个环境的真实条件下可行的方式。Z是高管认可的、可以被衡量的成功标准。
这句话写出来之后，需要让三类人都认可——高管、IT、一线用户。如果三方对这句话的理解有出入，说明翻译工作还没有完成，不能进下一个阶段。
看起来简单，但要让这句话真正准确，需要那三类对话、一次完整的现场诊断、一个选点判断。少了任何一步，这句话表面上清晰，实际上还是模糊的——只是把模糊藏得更深了。
写在最后
发现阶段产出的东西看起来不多——一句话，一张地图，一个选点判断。没有代码，没有演示，没有可以点击的原型。
这也是它最容易被压缩的原因。客户等着看成果，内部有推进压力，把发现阶段砍掉一半进入开发，看起来效率更高。
但方向错了，后面越努力，偏得越远。发现阶段花的每一天，都在给后续的工程投入定方向。这个方向对了，工程阶段是在积累；方向错了，工程阶段是在消耗。
下一篇进原型阶段——有了问题定义和选点，怎么在客户的真实数据上快速验证方向，在写生产代码之前把方向确认下来。
感谢你看到最后，如果你觉得有启发，随手点个赞、在看、转发吧，如果想第一时间收到推送，也可以给我加个星标⭐我们下期见。
我是「AioGeoLab」主理人塔迪Tardi，AioGeoLab是深度洞察AI第一性原理和应用实践的前瞻性研究实验室，目前有两个主要研究方向：
「塔迪GEO判断工程」是基于GEO的价值SEO化，在AI从“说”到“做”的重要跃迁阶段，试图回答，如何让AI敢于行动、不因为责任问题而畏手畏脚，而做的一个前沿研究项目。
「塔迪硅基禅心」是传统东方智慧、未来AI前沿、当下应用实践，深层共鸣的探索。不是用AI解读经典，也不是用经典指导AI。 这是一场跨越2500年的对话，在算法与古老智慧之间，照见意识、智能与存在的本质。
塔迪的微信 - tardyai2025。