这篇文章，是的后续，那篇文章里，我讲的是一个FDE怎么把停滞的项目重新带回运行状态。这一周，工作进入到下个阶段：开始真正走进业务部门，了解他们到底想怎么用AI。

几天时间，我们连续沟通了几个不同职能的团队。

有的团队负责收集生产运营数据，有的团队维护企业年鉴，有的团队每天督办重点任务，还有的团队长期撰写领导讲话、研究报告和各类汇报材料。

听起来差异很大，但抽出共性看，他们的需求基本可以概括为三句话：

查资料、写材料、做汇总。

如果只是到这里，那方案就太好写了：搭知识库，做个问答智能体，再配个智能写作助手，基本就能交差。

但走进业务现场后我发现，完全不是那回事。

①产线数据每年都会滚动更新；

②一本年鉴200多兆，里面既有文字也有照片，还有要特殊处理的历史内容；

③每天跟进的重点任务，来自二十多家下属单位发来的几十份EXCEL和Word，都要按固定格式自动汇总成文；

④还有人要从过去几年的报告中，快速找到某位领导讲过什么、上次向上级汇报时用了哪些数据、这一次怎么避免重复。

这些都叫知识，也都可以叫材料处理，但处理方法则完全不同。

这周给我的最大感触是：所谓调研，绝不是发个需求表给客户，让他们照着填。真正的需求，往往是在访谈过程中，出现在业务人员的某个文件夹中、某张表格里，或者一个只有他自己知道怎么处理的Word模板里。

接下来，我就把这周的见闻做个整理，让你看看真实的FDE交付现场，和你想的有什么不一样。

业务部门的AI需求，通常不会填在需求表里

记得有一次和客户督办部门沟通，对方一开始说他们的需求就是资料汇总。

我大意了，没有闪

殊不知，把几份文档上传，让AI总结核心内容，叫汇总，但二十多家单位使用同一份Excel模板报送信息，最后要按照任务逐行合并，并且保留每条信息来自哪家单位，这也叫汇总。

前一种，直接丢给大模型就行。后一种，则会涉及字段映射、表格合并、来源标记和固定格式输出，一定要拿真实样本反复测试，必要时还要定制开发。

正当我犹豫要不要接这个需求时，对方直接打开电脑，开始给我演示他现在的处理过程。

实际上，他并不是要AI替他读信息、写报告，而是希望AI能从二十多份材料里找到相同栏目，按照指定结构合并，再形成一份可继续人工修改的结果。

这项工作的技术含量并不高，人工半天也能做完。但每个月都要搞一遍，而且一条一条对比很消耗注意力。

到这里，我才真正搞懂对方到底想要什么，也初步能判断它的边界和实施成本。

当时我的回复是：原则上可以尝试，但要先拿几份真实材料回来测试。提示词也不会只有一句，需要讲清楚原始材料中的哪些内容，对应最终结果中的哪个位置。想让结果稳定，可能要连续调试几轮。

对驻场FDE来说，最基本的要求，是不只记录客户说了什么，更要让他打开正在处理的文件，看一遍他平时是怎么做的。

大国企的业务人员，并不都是AI小白

很多人可能会有个刻板印象，觉得大国企里的业务人员，都是AI小白。

但实际接触下来我发现，和我们提需求的业务人员，有的已经会用大模型自己写脚本、生成网页，也知道敏感信息要先替换成A、B、C，再交给外部模型处理。

他们会追问底层模型够不够强，能不能限定信息来源，能不能关闭联网搜索。还有人会问，知识库中上传的领导发言，出现不同时期观点有变化，系统会引用哪一次的发言，能不能同时展示原文和时间。

负责历史资料的同事问得更细：

如果因为特殊情况，某段内容不适合给用户查看，能不能临时拦截输出，不修改原始存档？ 能不能记录用户想查哪些信息、哪些数据没查到？希望能借助日志反过来指导下一年度补充内容。

这些已经不是简单的功能咨询，而是长期做业务的人，根据自己的责任边界，迅速能定位到产品可能出问题的地方。

FDE进场后，最危险的姿态就是急着教育客户。

客户对大模型的技术概念未必熟悉，但他比任何产品经理都清楚，一条错误数据会在自己的工作里造成什么后果。

所以，FDE需要讲技术，但更要听懂这些问题背后的业务判断。

知识库的数据源，首先对应的是组织权责

一次会议上，一位业务负责人问了我几个很典型的问题：

  • 同一个指标出现在不同报告里，但统计口径不一致，AI最终该用哪一个？

  • 一张上百项指标的表，每次只有三分之一发生变化。新版本上传以后，旧文件是删除、覆盖，还是继续保留？

  • 如果不同的人都能上传材料，谁来确认哪一份才是正式版本？

从技术角度，我们可以在提示词里要求模型优先引用最新文件，也可以通过时间和版本标签辅助判断。

但这些都没法根治问题。

只要源头没统一，模型就只能在几份互相冲突的材料之间猜。

最后我给出的建议是：企业级和部门级知识库必须有明确的维护人，资料更新要有确认和复核流程，已经失效的内容要有下线规则。

模型可以帮助检索、对比和合并，但绝不能替代业务部门决定哪个口径有效。

数据源不只是一个技术输入，还对应着谁有权发布、谁负责解释、谁来承担结果。

尤其在大型国企内，业务系统的接口可以由技术人员打通，资料背后的责任关系却不能靠代码来解决。

一个企业AI项目，必须同时维护两本账

在我们的知识库项目推进过程中，大领导最关心的一组数据是：

对接了多少个团队，覆盖了多少类知识，收集了多少份文件，接入了多少个数据源。

没有这些数字，项目很难说明自己到底推进到了哪里。

而业务现场调研时，另一位负责人却很明确地提出：资料不要追求多，要小而精。

行业数据优先选择权威来源，外部观点也只能选少数真正可信的媒体和研究机构。来源太杂，大模型最后只会把一堆质量不一的内容混在一起，生成一篇看起来完整、实际没有判断力的材料。

这两个要求放在一起，正好暴露了企业AI项目中的一个常见矛盾：

项目推进需要规模，业务使用需要精度。

如何解好这道题，考验的是FDE的协调和推进能力。

我的解法是：同时维护两个账本。

第一本是推进账：已经对接了哪些业务团队，拿到了哪些资料，覆盖了哪些知识类型，以及哪些系统和数据源没接通。

这本账让项目持续向前，也让领导知道资源花在了哪里。

第二本是效果账：哪些资料已经确认了可上线版本，哪些问题已经评测通过，存在冲突的答案谁负责修正，用户到底有没有因此节省时间。

这本账决定产品能不能真正上线。

广泛收集资料可以帮助项目发现机会，但真正进入生产使用的知识库，仍需经过筛选和治理。

项目早期先将资料收上来，再逐步优化，有它的现实价值。因为一开始就要求每个业务团队完成精细治理，项目大概率会被抵触并停滞。

但先收上来不等于直接上线，这里有个很重要的实施思路：设置一个宽入口，让更多资料先进入候选范围；再设置一道窄出口，只有经过确认的知识，才能支撑正式问答和材料生成。

FDE敢说做不到，反而更容易建立信任

驻场过程中，还有一件让人不舒服，但必须要做的事：当团队成员把产品能力讲大了，你要及时去纠正。

有一次产品演示中，同事向客户介绍说，部门可以维护自己的部门知识库。实际上，当时的平台只支持总管理员维护全局知识，以及个人维护自己的知识。查询端确实可以通过智能体控制只有本部门的人能访问部门知识库，但管理端还没做到部门级管理权限隔离。

一个是在用户端解决谁能看，一个是在后台解决谁能管，两个概念要拆开来讲清楚。要实现正式的团队共用和独立维护，产品能力还要继续完善。

当着客户的面纠正自己人会有点尴尬，但不纠正，今天的一句可以，过几周就会变成项目欠下的债。

同样的问题也出现在PPT解析、复杂Excel问答、录音整理和档案管理这些需求上。

客户一看到AI，就会自然地把想到的需求都提出来。FDE要做的，是及时判断这些是不是当前产品可以稳定满足的，有哪些要拿样本验证，有哪些要定制开发。

边界讲清楚并不会降低客户信心。

真正损害信心的，是演示时说什么都能做，交付时每一项都要重新解释。

AI落地的第一步，可能只是帮人找资料

有一场需求讨论会，我们开了将近一个半小时。

大家从领导讲话聊到研究报告，又聊到如何自动读PPT、表格、录音文件，自动抓行业数据和外部网站，再自动汇总排版、校对生成文稿。需求越聊越多，最后甚至开始讨论AI会不会让自己部门的人没饭吃……

快结束时，一位业务负责人主动收了一下口：

第一步先解决查询问题。让系统能从过去几年的报告、领导讲话和会议材料里，快速找到某个观点，或者某次汇报时说过的内容，并给出原文出处。

至于给领导写报告，可以尝试，但不要期待AI直接替代研究人员做判断。领导的要求高度个性化，真正重要的观点仍然要人来确定。

这个收口我非常认同。

企业AI项目经常喜欢从最有展示感的内容生成开始。到了真实现场，最能体现出的价值，可能只是先帮人找东西。

它虽然看不见摸不着，却能直接减少人工翻文件、找历史稿的时间，也不用再费劲回忆过去说过的话，或者向其他人反复要数据。更不会替代业务人员最核心的专业判断。

当系统能稳定找到资料、说明来源、区分版本后，业务人员自然会开始尝试让它整理、分析和生成初稿。

这个顺序比一开始就承诺写出一篇领导满意的讲话稿更可靠。

总结：大国企里做FDE，组织工作比技术更重要

海外FDE的典型故事里，经常是一名工程师拿着产品、接口和客户数据进入现场，快速做集成，再通过业务指标证明价值。

而到了国内，代码只是其中一类接口，更多时候，FDE要先处理组织接口。

提需求的、掌握资料的、使用和最终验收的，往往都不是一拨人。

能修改产品的人也未必总在客户现场。

因此，大国企里的FDE，很难只做一个深入客户现场的工程师。他还要不断做翻译和连接：

  • 将业务人员每天枯燥的复制粘贴操作翻译成产品需求；

  • 将产品限制翻译成可接受的过渡方案；

  • 将管理者关心的项目进展翻译成可以核验的数据；

  • 再将试用中暴露的问题同步给产品团队。

复盘这一周，我做的事，并不是想象中的写方案、调接口、VibeCoding、评测上线，而是天天约业务人员开会介绍产品，追问工作痛点，现场解释能力边界，拿走几份样本，开账号安排试用，再给产品经理反馈客户问题。

这些动作，并不像媒体口中提到的那么高大上，但这才是企业现场FDE的真实日常。

我是申悦，AI创业者、独立讲师、企业AI顾问。提供企业AI培训、AI落地方案咨询、AI智能体设计和运营陪跑服务。服务过东风集团、海亮集团等世界500强企业。如果你的公司正在做AI转型、流程重构、知识库建设和智能体落地，想要获得FDE式的服务，欢迎加V详聊合作：s2dongman