从知识库到智能体：一个FDE在企业现场到底做什么

当企业AI项目遇上高知识密度的城乡建设服务商，FDE如何突破知识治理难题？本文通过驻场案例，揭示从知识审计到智能体落地的关键六步，呈现企业AI项目最真实的推进逻辑与风险边界。

这篇文章想聊的，是我作为FDE，在项目启动时，驻场为客户做知识梳理和访谈调研的一周。

这次服务的是一家扎根无锡的国有城乡建设综合服务商，业务覆盖市政环境、水务治理、道路交通、城市更新、EPC和数字化交付等多个方向。

这类企业有个很典型的特点：知识密度很高。

一个项目从前期沟通、投标、现场踏勘、方案设计、专业评审、图纸交付、施工配合到后期复盘，中间会产生大量文档、图纸、表格、流程、模板和经验。再加上设计院本身有很强的师徒传承色彩，很多关键判断不一定写在制度里，而是存在老员工和部门负责人的经验里。

所以他们需要的服务，表面上叫知识审计，实际是想把散在各个地方的企业知识，变成可以被员工查到，能持续更新的组织能力。

如果企业希望AI真正支撑员工工作，第一件事肯定不是直接学AI工具，而是先弄清楚组织里的知识家底：知识在哪里，质量怎么样，哪些能先用，哪些要治理，哪些场景适合做成智能体。

相比之前那篇后期救火的经历（一个救火FDE的一周），这次的项目更可控、有充足的时间在前期就做好规划。

周一下午，我会先和项目接口人开短会，对齐启动会流程、访谈名单、系统权限、阶段产出这些事。客户希望这个项目做得标准化，集团层面也希望把知识审计、知识库、Agent这些概念讲清楚，先让内部形成共识。于是，启动会前我会准备了两套材料，一套讲项目怎么推进，一套讲为什么企业AI落地要先做知识治理。

这就是企业AI项目真实的开始。不是上来演示一个工具有多强大，而是先把项目里的角色、资料、系统、边界和协同方式对齐。

这一周我的体感是：企业AI落地中，FDE的价值会越来越清晰。

FDE不一定是AI技术专家，但他要进到现场，懂得把客户的业务语言、知识现状、系统条件和交付约束连接起来，输出一条能推进的路径框架。

下面我就来尝试系统复盘下，这一周我作为驻场FDE，是如何完成客户需求分析和调研工作的。

一、先看知识在哪里

进场后的第一波重点访谈对象，肯定是IT和数字化团队。

这类访谈的目的，是做出一套知识地图。我要知道公司有哪些资料系统，也要知道资料在系统里是怎么存的。

包括哪些资料在线上系统，哪些资料在共享网盘，哪些资料还散落在个人电脑和部门文件夹里。

还要确认系统能不能导出文档清单；上传文档时，有没有记录上传人、更新时间，如何设置权限，历史版本怎么处理，这些都要问清楚。

最终需要输出知识盘点清单、明确知识运维人员、划清安全保密边界。

企业做知识库，不能默认“有文档就能入库”。真正能进入首批知识库的资料，至少要能追溯来源、确认版本、找到责任人，并且有机会被测试。所以我更倾向于先看资料状态，再谈系统建设。

二、再判断先做哪一块

企业里的知识一定很多。制度文件、技术规范、项目资料、投标材料、合同模板、培训课件，随便一盘就会铺开很大一张网。

这时候，FDE要帮客户做取舍。

第一批知识库肯定不适合追求全量。我的习惯是看业务价值高不高，员工是不是经常问，资料基础相对是否成熟，以及能不能形成可以让专家愿意复核的测试题。

有些知识很重要，但资料太散、争议太多、责任人不清楚，放在第一批会拖慢项目，比如一些模板、表格、参考文献。有些资料数量很大，但员工平时很少用，做进去也很难体现价值，比如只有特定部门才会查的制度规范。

比如在做工程板块访谈时，我问到哪些资料可以复用，对方的回答就很克制：类似进度计划书，理论上也是知识，但很难复用。房地产项目可能一栋楼一层多少天，相对标准化；但他们做水厂、道路、工业厂房，不同项目规模、工艺、现场条件差异很大。水厂经验拿去做道路，明显复用不了。

因此不是所有看起来有经验的地方，都适合第一批做知识库，如果复用条件太复杂，第一阶段硬做，很容易变成一堆看似有用、实际无法落地的材料。

后来聊到对复盘报告的检索场景，对方也很坦诚地说：复盘报告里会写问题，但写得太具体有风险，写得太泛又容易变成通病，AI如果拿这类内容去检索，最后很可能搜出一堆废话。

这也是很宝贵的调研结论，如果入库的内容无法对用户形成有效指引，反而会造成知识污染，这类材料就不要直接入库，至少不能作为高质量知识条目使用。要么重新萃取，要么只作为背景资料，放到后续阶段再做。

这些现实约束，才是AI项目的现场。而最考验FDE的地方，是既要理解客户的期待，也要敢于做项目判断。

工具交付容易关注“能不能实现”。FDE更要关注“值不值得先做”、“做到什么程度算成功”，以及“哪些风险要提前说清楚”。

三、一定要问员工真实怎么用

知识库最终要服务员工，所以一线访谈很重要。

尽管发起项目的是管理层，但他们关注的是组织能力、数字化建设、经验沉淀和人才培养。而一线员工会更关注资料能不能找到，需要用哪些关键词搜索，遇到问题该找谁确认，AI的回答会不会答错。

举个例子，在访谈一位路桥设计专家时，他提到：有时候好不容易找到一个文件，打开一看，里面没有想要的内容。还有些资料只能证明当时设计过什么，却不能代表最终竣工是什么样。别人来调资料时，还要提醒对方，这只是设计资料，不是竣工图。

这就对知识库的输出边界有了更高要求，知识库不能只解决“能不能找到文件”。更要关注这份资料能不能用，能用到什么程度，是否需要提示风险。

四、专家访谈要问出判断逻辑

企业知识里最值钱的部分，是专家的判断。

制度能告诉员工规定是什么，规范能告诉员工标准是什么，但专家能告诉员工什么情况下该怎么用这些制度规范，哪些哪些地方容易出错，哪些问题不能直接给答案。

比如在专家访谈时，不能只问“你觉得哪些资料适合作为知识库”，因为在工程设计领域里，要收集的资料，其实叫设计输入。像是甲方给一块地，规划条件是什么，能做多高，能做多大体量；结构专业要看地质资料，机电专业要看供电、供水条件。这些不是内部知识检索，而是设计工作开始前必须拿到的外部输入。

再比如，所谓的“查资料”，也要拆的很细，方案阶段，设计人员会找参考案例。初设和施工图阶段，会查规范、查条文、看图集、看模板。建筑、结构、机电、景观之间还有相互提资和交接。一个方案的图纸和说明，背后不是某一个专业单独完成的，而是多个专业串起来的结果。

也就是说，一个可用的知识条目，不能只是一段文档摘要。它需要有适用场景、问题描述、判断步骤、依据来源和更新时间。只有结构化到这个程度，后面才可能被检索、引用和测试。

FDE在这里要做的，就是把业务专家讲出来的工作流，翻译成知识库的分类、标签和检索维度。

五、调研阶段就要开始收集测试题

知识库建设不能等到最后才测试。

在访谈时，一定要同步留意员工平时问什么，专家经常被问什么，哪些问题有标准答案，答案的来源依据来哪里。

这些问题后面会变成测试题库，验收也是以此为依据的。

所以，需求调研阶段就要开始为测试做准备。

在我看来，第一批知识库更像是个AI样板间。它不需要一开始覆盖所有问题，但要先能跑通资料入库，问题检索，引用依据，错误复核，规则优化的完整闭环。

闭环跑通后，再扩大范围才有基础。

六、边界要在一开始讲清楚

企业AI项目很容易在启动时预期过高。

客户希望知识库能解决员工找资料的问题，也希望智能体能辅助员工处理业务问题。这些方向不是不能做，但边界要提前讲清楚。

通常要和客户确认的边界有：

信息查询和资料检索的边界、知识检索和文档生成的边界、需覆盖的权限范围的边界、要实现的场景优先级的边界、以及知识版本交叉冲突时的解释边界。

这些问题越早讲清楚，后面项目越容易推进。

AI可以辅助检索、整理、生成和提醒，但专业判断、内部审批、业务采纳和最终责任，仍然要回到企业自己的流程里。

FDE需要帮客户把技术能力、业务价值和现实约束都讲清楚，既不夸大AI能力，也不把项目做成保守的信息化整理工作。

能落地的方案，一定要同时说清楚价值、范围、路径、风险和责任。

七、FDE要做企业AI项目的现场翻译官

真实企业里的AI项目，没有标准答案。尤其是在知识库、智能体和业务场景结合的项目里。

有的部门资料成熟，但业务价值不够高。有的业务场景价值很高，但资料基础很差。有的专家很有经验，但没时间给你整理。有的员工问题很具体，但不是靠知识查询就能解决的。有的领导希望尽快看到AI效果，但组织内部还没有知识运营机制。

FDE要做的，就是在这些约束里找到一条能推进的路径。结尾：企业准备做知识库，可以先走这6步

如果一家企业准备建设知识库、知识问答智能体或业务Agent，我建议先别急着选工具，而是先完成下面六个动作：

第一，盘点知识位置，看看资料到底分布在哪些系统、文件夹、共享盘和业务流程里。

第二，筛选首批知识域，优先选择高频、刚需、资料基础相对好、专家能复核的场景。

第三，访谈真实用户，不只聊管理层，也要听一线员工、内勤、项目经理和种子用户。

第四，要拆专家经验，把案例里的判断条件、操作步骤、风险提示和依据来源整理出来。

第五，收集建立测试题库，用真实问题验证知识库和智能体是否可用。

第六，提前设计运营机制，明确谁负责入库、谁负责审核、谁负责更新、谁看测试结果、谁推动持续优化。

这六步走完，企业再谈知识库建设和智能体落地，就会顺利很多。

这也是我现在做企业AI咨询和FDE陪跑时最重视的部分：

先进现场，完成判断。

再做方案，跑通闭环。

最后沉淀方法，推动复制。

本文由人人都是产品经理作者【申悦】，微信公众号：【互联网悦读笔记】，原创/授权 发布于人人都是产品经理，未经许可，禁止转载。

题图来自Unsplash，基于 CC0 协议。