作者以 FDE 一线实践复盘企业知识库智能体落地经历，指出企业 AI 项目的核心瓶颈不在技术，而是需求边界划定、资料治理、用户实测、反馈分层处理。Demo 易于实现，打通业务闭环、建立验收标准才是落地关键。

上一篇，我跑了四个业务团队，带回了六个反常识判断。

这一篇，我挑了其中一个，真刀真枪做了一周。

最大的感触是：搭一个智能体只要10分钟，但让它真正进入业务，却花了整整一周，其中最值钱的工作，没一件和技术有关。

如果你也在做企业AI项目，这周我总结的五个动作可以直接复用。

在开始这周工作前，这个项目主要是在调研阶段，我做为FDE（前线部署工程师，Forward Deployed Engineer），会和团队一起走访业务部门，了解他们的真实工作痛点。

大家的积极性很高，也收集了不少需求。什么查资料、写材料、整理数据、制作PPT、处理录音、辅助校对等等，很快就把需求列表填得满满当当，这是好事，但就怕继续这样聊下去，项目就收不住边界了。

于是我给自己定了个具体目标：挑一个典型团队作为代表，先做出业务人员能真正上手的最小样板。

我选的是一个长期负责综合材料的部门，他们的原话是：

我们以前那些材料太分散了。领导讲话、专题报告、调研材料，到处都是。真要用的时候，找一段话都要翻半天。我想以后用到某个领导的观点，或者他的某段讲话的时候，能直接查出来，还要告诉我来自哪个文档。

总结来看，他们希望解决历史资料查询的问题。想把过去形成的领导讲话、专题报告、调研材料和正式成稿，统一放进知识库。当需要某个观点、或者某类历史材料时，能直接找到，并给出原文出处。

之所以选这个场景，也是因为它是业务人员每天都要做的事，而且边界可控，客户预期也不会被拉得很高，对他们而言，AI写的东西，能帮他们节省60%的时间就足够了。

听到这里，可能你会认为：“这有什么难的，不就是搭个问答助手么”。

而只有真正做过FDE项目的人才知道，你真正要花时间的，是要去和客户明确边界，包括：选哪些资料入库，这些资料是否需要复验，该如何测试，什么结果算达到可用状态，以及出现问题后，判断是该改资料、改检索方式还是改产品功能。

换句话说，你要做的，不光是搭出这个样板间，还要负责让它真正进入业务。

第一件事：定义完成标准

企业AI项目最大的风险，不是做不出来，是收不住。

做着做着，”查个资料”就变成了”全部门数字化转型升级”。需求列表越拉越长，每个都有道理，加在一起就是无底洞。

既然要做部门知识库，就会继续讨论资料分类、标签体系、版本管理、权限分级、审核流程和运营机制；既然能查历史材料，就会自然想到材料写作、数据整理、PPT生成和会议纪要。

如果全设计完再开始做，黄花菜都凉了。

所以要先给样板划出一条清晰的边界：

使用一批已经形成的正式材料→搭建一个知识查询助手→开放给实际使用资料的人→通过现场测试验证内容能不能查到、答案能不能找到来源。

同样，如果用户还需要AI辅助写材料，那就先验证能不能用已有资料，按指定模板形成大纲和初稿。

明确了这个边界，这周的工作就能聚焦到“跑通知识查询样板”的首轮闭环上。尽管可能距离业务人员稳定使用还有距离，真实任务、模板适配和引用效果还要继续测试。但已经能向客户证明AI样板的可用性和价值。

定义最小样板，我通常会先回答三个问题：

这次只解决谁的什么问题？用哪些真实资料验证？出现什么结果才算可以进入下一阶段？

这三个问题不回答清楚，后面的工作大概率还是会很模糊。

首批资料的采集标准：必须能暴露真实问题

从客户那收到第一批资料，我没有马上把文件全上传，而是先分花了大半天，逐份检查。因为知识库项目的第一个坑，就在资料端。

这些资料里有领导讲话、专题研究材料、工作汇报和过去形成的成熟成稿，将近50篇，数量不算多，但覆盖度足够了。我会先按实际用途做分类，再逐条检查文档格式是否适合被解析，同一表述在不同文档间是否有冲突，多份时间不同的文档以哪一份口径为主。基于此，形成一份《智能体建设工作核验问题台账》:

需要调整格式的文档（如复杂排版的表格、PPT），要提前清洗后才能入库，之后按实际分类建好知识库，执行入库操作。

上传后，还要记录入库位置、入库格式，并确认正文有没有被正确识别，标题和来源能不能随着查询结果保留下来，是否要额外处理，并更新到《入库台账》中。

这些工作挺枯燥的，虽然部分可以靠Vibe Coding快速做文档处理，但远不像想象中的那样，几分钟帮客户开发出一个可用的NB工具。

不过在真实的企业AI项目里，后续效果往往就取决于这些前期的细节操作。

比如同一个主题内容，可能同时出现在领导讲话、专题报告和内部汇报里。如果系统只返回一段语义相近的文字，没说清材料名称、形成时间和使用场景，业务人员肯定不敢直接用。

还有些文件，文件名里保留了版本信息，正文标题却不完整。系统虽然找到了相关内容，却无法准确告诉用户这段话来自哪份材料。

这时候调模型和提示词都很难解决根本问题。

更合适的处理方式是：先选出几种典型材料进行逐份核对，再从直接查询、跨材料整理和相似成稿这些维度进行充分测试，尽可能还原真实场景。

很多知识库项目一开始就想批量导入几千份文件。资料多了以后，结果一旦不理想，项目组就很难判断问题究竟出在源文件、文档解析、信息标注、知识检索还是模型回答。

首批资料少一点，不会影响样板价值。只要样本选得对，反而能更快找到真正需要解决的问题。

配系统前，先决定如何验收

知识查询助手的界面配置并不复杂，创建智能体，关联知识库，选模型，调整检索和回答参数，再完成发布，十分钟就够了。但怎么判断它能用，才是真正花时间的地方。

如果临时准备几个问题，很容易挑到系统已经能回答的内容。演示效果很好看，却证明不了这个样板能进入真实工作。

更合适的做法，是提前准备多个不同场景下的评测问题集。

有些问题要能直接查到某份材料中的内容，有些问题要限定时间、主题和材料类型，有些则是要求跨材料整理同一主题的不同表述，还有一些则可以让它查过去正式使用过的相似成稿。

此外，还要专门准备知识库中没有答案的问题。它要验证的，是系统在没有企业内部依据时，会不会使用模型自身的通用知识补出一个看起来合理的答案。

涉及领导观点、经营数据和内部工作要求时，这条边界绝不能模糊。找不到依据，就明确说明当前资料中没有相关内容。

这套评测结构可以直接复用。换一个企业、换一个部门，具体问题会变，但直接查询、条件查询、跨材料整理、相似资料查找和无答案测试，仍然是知识查询样板最基本的几类验证。

能用的先进业务，没验证完的把边界讲清楚

这一周，我同时推进了知识查询助手和材料写作助手。

查询助手完成基础测试后，我会先发布出来，给业务负责人开通权限。

而写作助手涉及模板结构、参考资料调用和材料类型判断，还要继续测试，我就把当前完成度和预计可用时间如实告诉对方。

企业项目经常遇到的悖论是：业务部门希望尽快看到成果，最好今天提出需求，明天就可以开始用。项目组则需要留出时间做资料整理、参数调整、提示词测试和结果核对。

比较合适的解法，是按照成熟度拆分能力。

达到使用标准的部分先开放，让真实用户尽快产生反馈；仍存在明显不确定性的部分继续测试，同时把边界说清楚。

最忌讳的，是让用户以为功能可用，拿到实际工作中才发现完全不是那么回事，这会极大影响信任度。

当然，就算内部测试达到标准，也不能认为是可用了，毕竟身为开发者，我们自己知道资料在哪里，提问时就很容易下意识地使用系统更容易理解的说法，而业务人员不会配合系统组织语言的。

因此样板越早接触真实用户，我们就越早知道自己究竟做对了多少。

演示会的作用：把理想拉回现实

周五下午，我带着内测好的智能体来到业务部门。

最开始我还挺有信心的。内测试跑了好几轮，几十道问题翻来覆去测过，检索精准，引用齐全，连最刁钻的跨材料整理题都答得漂亮。

我想着，这次演示大概十分钟就能结束。

介绍完基本用法，我把电脑递给业务负责人：”您试试，随便问。”

然后，尴尬就来了

。

用户想查一位领导在一次座谈会上的讲话。系统很快给出了答案，内容也没错。但这位负责人的反应让我意外——

他没看答案对不对。而是目光直接跳过正文，盯着底部的来源标注，连问了三个问题：”这段话是哪份材料里的？讲话内容取的是哪段？有没有引用原文标题？”

紧接着又补了一句：”除了这份，还有没有同主题的其他稿子？”

我愣了一下。

这四个问题，系统一个都没答上来。

另一位业务部门的同事在旁边做了补充，他说，同样是一段讲话，用在向上级汇报、领导调研接待和内部工作会议里，表述方式是完全不同的，需要总结的侧重点也不同。光找到内容没用，你得知道这段话是谁说的、什么场合、什么级别。

业务人员要的从来不是一个”语义相近的答案”，而是在特定时间、特定文体、特定场景下，过去正式使用过的口径。

继续往下试，问题接二连三冒出来。

标题识别不对。明明文件名里有版本号，却缺失正文标题。系统找到了内容，说不清来自哪份材料。

无法按时间精准定位。用户要查”去年某会议上的讲话”，返回结果横跨好几年，新旧口径混在一起。

没有区分材料类型。正式纪要里的讲话和内部沟通会上的，权威性完全不同，但系统会不加区分全部返回。

有些结果甚至不是内容错，而是缺了业务人员做判断的上下文。系统给了答案，用户还是要打开原文件，重新确认细节。

这场演示会开了四十分钟，不是十分钟。

回来后我在会议纪要上写了一句话：

内部测试可以检查功能跑没跑通，但只有真实用户，才能暴露业务判断链条里还缺了什么。

企业知识查询，不能只看有没有召回相关文字，还要看系统能不能帮用户快速确认这段内容的来源、上下文、能不能作为下一步工作的依据。

做企业AI样板，非常建议设计这样一个步骤，就是和真实用户共测。让用户按自己的工作习惯提问，项目组只负责观察、记录和追问。你不需要演示产品，而是要和用户共同验收。

回收反馈后的关键动作：问题分拆

现场反馈回收后，不能简单一句“去优化”，把责任丢给研发团队。作为FDE，首先要做的，是把任务分流。

用户说结果不对，有时是资料中根本没有对应文件，或者放进去的不是正式版本。这种情况要补资料、确认版本；有时正文里明明有相关内容，但没写清标题、时间、作者和材料类型，这时应该检查文档解析和资料标注。

还有一些问题，确实出在检索和回答环节。库里有内容系统没召回，或者已经找到了原文，模型却做了过度推断。这时才需要调检索参数、提示词和回答规则。

再往后，还有产品权限和知识运营问题，要讲清楚资料由谁上传、定稿由谁确认、业务人员如何参与维护等等。

总的来讲，可以把问题拆成四类：需要补充和确认的资料，解析与信息标注问题，检索与回答问题，以及权限与维护机制问题。每条反馈都要进入对应的处理路径，形成下一步动作。

用户只会告诉你好不好用，技术团队更关心有没有故障。中间必须有人判断问题出在哪一层，再把业务语言转成资料、配置、产品或组织动作。

样板被认可的信号：客户愿意继续投入了

现场试用结束后，业务部门开始提出更具体的查询维度，也明确了后续资料由谁负责维护，以及下一批准备补充的资料范围，包括近几年形成的信息材料、工作汇报、重要会议材料和领导讲话等等。

这样的信号表明，项目的重点开始发生变化了：最开始，大家关心的是AI能不能帮忙找资料。真实试用后，开始探讨怎样让它查得更准、覆盖更多材料，以及如何把这套能力持续维护下去。

企业客户对一个样板的认可，不一定表现为在会上夸一句效果很好。愿意继续提供资料，愿意安排真实用户测试，甚至开始指出各种不好用的地方，反而更能说明他们已经把这件事当成自己的工作来考虑。

到了这个阶段，样板才真正进入业务。

复盘这一周，我总结的五个可复用动作

复盘这一周，我把整个推进过程整理成了五个可复用的动作：

第一，写一张需求定位表。明确服务哪个部门、先解决哪个问题、用什么资料验证，以及什么结果算完成。

第二，收集一批典型资料。选择能覆盖真实任务的典型样本，逐份检查版本、标题、时间和解析结果。

第三，提前准备验收问题，搭建智能体进行自测。既测能不能查到，也测能不能核对、跨材料整理和无答案处理。

第四，组织真实用户现场共测。让业务人员按自己的习惯提问，项目组观察哪些业务判断条件没被系统支持。

第五，把反馈分类分层。资料缺失、解析与标签不足、检索与回答问题、补充产品权限与运营机制，这些问题分别进入不同的处理路径。

这样，一轮样板结束后留下来的，除了开发好的智能体Demo，还有样板定义、资料范围、验收标准、用户反馈和下一轮建设任务。换一个部门、换一批材料，这套路径仍然可以继续使用。

所谓可复用的方法论，并不是把一次项目过程包装成汇报材料。而是应该能告诉下一位项目负责人：明天先做什么，需要找谁，拿什么材料，怎么判断结果，以及问题出现后怎么分工处理。

如果做不到这一点，它就还只是经验，没有真正变成方法。

FDE的价值，就在于能在这套方法中，判断需求范围、验收标准和推进节奏，这是真正能帮企业降低项目风险的关键。

FDE的交付标准之一：能借助样板跑通一个小闭环

一周前，我们还在讨论第一阶段应该先解决什么问题。

这一周，业务人员已经真正使用过产品，知道它现在能做什么、哪里不好用，也开始准备下一批资料和维护规则。

回过头来看，这周的工作不难，就是整理资料、检查解析结果、写测试题、调整参数、配置权限、手搓智能体准备演示，现场观察客户使用反馈，最后进行任务分拆。都是脏活累活，但这才是真实的FDE现场工作。

企业AI项目的真正壁垒，不在技术和模型能力，而在于有没有人愿意把这些琐碎的、不起眼的动作一个个串起来。

会写提示词、用Agent、搭工作流，只是能力层的入场券。

真正值钱的，是知道先做什么、找谁做、拿什么验证、出了问题怎么分——而这些，恰恰是AI最替代不了的部分。