企业AI项目的推进往往陷入需求与方案的拉锯战。本文通过一个真实案例，揭示FDE如何在客户组织变动后重新锚定产品定义，将业务语言转化为验证任务，最终让停滞的项目实现加速。关键转折点在于从'功能场景讨论'转向'产品假设框架'的构建，展现了企业级AI落地的核心方法论。

这篇文章，是那篇“一个救火FDE的一周”的延续，也是对那个救火项目后续进展的记录。

上个故事，留了个悬念：我出的方案，仍未被客户认可，怎么办？

转机出现在客户内部的一次组织调整，又安排了一位新领导负责这个项目。

巧的是，他正是这个项目最早的发起人，只是中途因为工作调整离开了一段时间，现在又回到了项目中。

我意识到，这是一次重新理解项目的机会，于是又回到客户现场，准备启动新一轮需求调研。

这次进场以后，我没急着拉团队讨论上一版方案怎么改，而是直接约了这位新负责人，做了次一对一沟通。

聊完后我才发现，前面我的方案没得到认可，不是内容写得有问题，而是我们一直在讨论接下来要做哪些功能场景，而他关心的的是：

• 这个产品到底是什么？
• 它里面应该放什么？
• 谁会去用？
• 怎么让产品上的AI应用能跑起来？

没对这几个问题形成统一认知，后面无论做多少调研、开发，都会跑偏。

我这时才意识到，自己前面给出的方案，虽然已经在尝试回答怎么落地，但仍然跳得有点快。

我们已经开始讨论要去建设哪些场景，却还没有真正形成一套大家共同认可的产品定义。

领导真正想要的，并不是做几次访谈，提交一套方案建议。而是要你进项目、做规划，让业务、产品和技术形成合力，再将每天出现的问题转成明确的处理动作。

后面的几天，我们连续开了几次会。从产品定位、知识分类和专家选择，一直聊到信息来源、接口对接、测试验证和责任分工，讨论得很细。

这一次，项目的进展明显加快了。

每次会后都有新的判断，也有明确的下一步，开始逐渐往前走了。

接下来的内容，就是我对这段时间工作内容的总结和思考，希望对你有所启发。需求调研前，先给产品画个框

企业AI项目的推进逻辑，通常就是需求调研、场景梳理、优先级评估、方案设计，再选几个场景做PoC。

但这次的项目，我开始重新思考一个问题：当产品本身还没有形成清晰定位时，需求调研到底该怎么做？

如果直接去问业务部门你们有什么需求、希望AI帮你们做什么？

得到的答案很多都是不可用的，要么太抽象、要么太复杂，甚至有些业务老师，因为不了解产品能力，根本不知道该提什么。结果就是技术团队想当然地做了一堆工具，但没人会用。

这位客户领导给我的启发是：需求调研之前，FDE要先形成一套产品的假设框架。

以知识库场景为例，列一个提问大纲：

我们准备接收哪些类型的知识、这些知识以什么格式存在、进入系统后做哪些处理、最终支持员工完成哪些任务。

先把这个框画出来，再拿着它去找业务部门，让他们告诉你这个分类对不对，他们手里有哪些资料，这些资料存在哪里，由谁维护。

这时候，需求调研就不是空对空，而是双方有了一个共同讨论的对象。

企业AI落地要尊重业务，但尊重业务不等于把产品设计的责任全交给业务。

FDE应该先形成判断，再拿到现场验证。方案的视角，比方案本身更重要

第一次沟通后，我回去重新整理了一张表。把我们AI产品里的知识库结构，分成了公共知识、部门知识和个人知识。并写清了谁来维护，归哪个部门，权限怎么划分。

第二次拿着这张表去讨论时，对方直接就给我打了回来。他说：

“你这个方案，是站在知识维护者的视角来写的，但这个产品最终是给员工用的。员工遇到一个问题时，并不会先想：我要找的是公共知识，还是部门知识？他更可能想的是：我想找份资料、我有个问题想确认、我要基于现有资料写一份东西。”

这是我得到的第一个反思：

企业知识可以按组织归属来治理，但产品要围绕用户任务来组织。

顺着这个思路，后面的方案框架，就变成了从问、查、写三个维度来组织场景。

当然，对后台来说，知识还是要按照部门、权限和责任人进行治理。

但对用户，他关心的是这套系统能不能帮自己完成任务。

这两件事不能混在一起。FDE要做的，是把业务语言继续往下翻译

客户领导在几次会议里提了不少围绕知识库产品的想法，有的场景要放集团介绍、有的场景要能查公司新闻，有给全公司看的流程制度，也有给部门领导看的专项材料，还要求不仅能检索，更支持结合模板进行AI写作……

直接进入方案设计么？肯定不行，FDE要能基于此，继续往下拆。

比如要做新闻知识查询，似乎只要抓新闻网站内容，放进知识库，直接查就可以了。

但历史新闻从哪来？未来新闻怎么更新？有几个新闻来源，不同来源内容是否重复？信息获取可行性如何？查询结果要不要返回原文链接？涉及图片又该怎么处理？

看起来很简单的“新闻知识库”，拆到最后，其实包含了数据源、更新机制、搜索、RAG和内容回溯等不同问题。

我们最后的首期判断是：新闻更新频率高，可以先解决定向查询和原文回溯问题，用户能查到内容、看到来源，还可以基于这些内容辅助写作，这个场景就已经能跑起来了。至于后面是否要进知识库，再根据真实使用效果决定。

规章制度也是一样。一开始很容易顺着分类继续做：人事制度、财务制度、采购制度、IT制度。

真正往下盘点后，发现集团已有系统正在集中管理大量规章制度，另外的AI项目也在建设制度查询能力。

这时候就没必要新建一套制度知识库，而是去调研已有系统能力，判断是否可直接对接、统一入口。

这才是真实企业里的AI场景。

很少有企业做项目是从一张白纸开始的。企业里通常已经有很多信息系统、有数据、有历史项目，也有复杂的责任边界。这些都需要FDE做取舍。

你的判断做对了，项目就会轻很多。尽快把不确定的问题，变成验证任务

随着讨论的深入，项目里出现了越来越多无法直接回答的问题。比如已经开发完成的智能体能不能先上线？知识库自动切片可不可以直接用？PPT里的图片和表格解析效果如何？扫描版PDF要不要入库？等等。

这类问题，靠开会很难讨论出答案。怎么办呢？

我当时的方案是：把它们改成验证任务。

针对已ready的智能体，准备20到30个真实问题，内部先测一轮，再找业务人员复核。

找几份复杂PPT、扫描的PDF上传到系统里先测试，看看解析效果怎么样？

以前做方案时，我们总希望尽量把问题提前想清楚。而做企业AI项目，只有跑起来答案才会出现。

FDE需要管理这种不确定性。

暂时不知道的，可以先明确要验证什么，使用什么样本，结果要达到什么程度才能进入下一步。

这样一来，大家不用再反复争论“能不能做”，而是会关注下一步该怎么测。项目真正开始加速，是有人持续做判断以后

几轮沟通下来，客户领导对我的响应方式很满意，尤其提到在我入场后，项目推进速度明显加快。

这句话，既是一种认同，也让我有了新的反思：

其实这个项目一直有团队在跟，其中有项目经理，有产品，有技术，也有现场执行人员。

但其中真正缺少的，是能持续完成判断的人。

• 这个人要能在客户讲业务目标时，能理解他真正想解决的是什么问题。
• 这个人要能在技术说做不了时，判断出是产品限制、成本问题，还是有其他技术路线？
• 这个人要能在业务不配合时，判断当前是否必须依赖业务，还是可以先拿公开数据做一个样板？

这些问题很难提前写进一份项目计划，但它们会高频出现。

如果每出现一个问题，都要重新等待客户领导决策，推进速度一定会越来越慢。

这也让我对FDE这个角色产生了更深一层的理解：对FDE来说，除了具备需求调研和方案设计的能力外，持续的判断力，才是最关键的。

在我参与过的项目里，企业AI落地的卡点经常混在一起：

• 表面上看是知识库效果不好，实际可能是业务资料本身质量不高。
• 表面上看是技术实现困难，实际可能只是没有找到正确的数据负责人。
• 表面上看客户提出了一个新场景，继续调查后发现其他系统已经做了一半。

所以FDE不能只负责把需求转交给开发。还要判断项目现在卡在哪里。技术问题找技术、知识问题找业务专家、系统问题找平台负责人，涉及跨部门资源，再向管理者升级。

FDE的真正价值，就是在业务、产品、技术和项目推进之间，持续完成转换。FDE最终要解决的，是不驻场时，团队也可以自己往前走

这一周的最后，客户希望我继续主导这个项目。但我很清楚，一个项目不能永远依赖某个人在现场盯着。

我在《FDE的定位思考：是护城河，还是新一轮人力外包？》这篇文章中也提到，FDE不能沦为新一轮人力外包，成熟的 FDE 项目，也不应该让客户越来越依赖外部团队。

真正健康的状态，是随着项目推进，责任边界越来越清楚。

FDE负责整体判断和方案设计、项目经理负责节奏和任务推进、技术人员负责实现和测试，业务部门提供资料，也负责确认结果是否符合真实业务。

管理者则负责处理跨部门资源问题，并判断业务优先级。

只有责任链逐渐清楚，项目才不会因为一个人的离场，就立即停下来。

我后来也跟客户明确了一件事：最近这个阶段我可以继续主刀，尽量在现场把方向、节奏和关键动作理顺。而最终的目标，则是让这套项目机制最终能够自己运转。

这才是FDE真正应该留下来的东西。FDE交付的不是方案，而是项目的运行状态

回头看这一周，我最开始以为自己是在继续救一个方案。

重新进场后才发现，真正要解决的，是怎么让这个项目重新跑起来：

先重新建立共同语言，让业务、产品和技术讨论同一件事。

再把业务想法拆成数据来源、技术路线和验证任务。

遇到不确定的问题，尽快通过小范围测试拿到真实结果。

同时建立责任边界，让每个人知道自己在什么时候应该做什么。

然后持续做出几个能被用户使用、也能被管理者看到的成果。

当这些事情逐渐形成节奏以后，项目状态自然就会改变。

团队开始知道下一步该做什么，遇到问题后，有人能判断该找谁，一个场景完成，知道该怎么测试，也知道什么时候可以上线。

这样一来，即使关键人员暂时不在现场，项目也不会立即搁置。

这就是我理解的FDE交付。

方案只是工作的一部分，更重要的，是项目开始形成自己的运行状态。

最后，如果你也在推进一个企业AI项目，我建议你先做这么几件事：

先问问自己：这个项目到底要解决什么任务。

再盘点当前最大的几个阻塞点，判断它们分别属于业务、数据、技术还是组织协同问题。

接下来只选一个最小闭环，用真实资料、真实用户和明确的测试标准尽快跑出结果。

结果出来后，再补充责任边界、反馈机制和下一轮计划。

先让一个项目跑起来，它开始稳定运转后，才会有后面进一步优化的基础。