万字长文｜企业 AI 知识库从 0 到 1 真实交付指南：数据治理、权限、测试与验收（附落地检查清单）

这篇文章主要讲清楚一件事：企业 AI 知识库从“能演示”走到“能交付”，难点不只在模型，而在资料、人员、权限、系统、边界和验收。

全文围绕六个问题展开：

• 为什么原始资料本身可能就是错的；

• 怎样找到只存在于老员工脑子里的知识；

• 为什么企业知识库很难直接卖一套标准产品；

• 复杂文档、旧系统和私有化部署应该怎样处理；

• 怎样通过工作范围说明控制交付边界和需求变化；

• 怎样用两套测试集完成测试与客户验收（初步方案）。

文末还附有一份企业 AI 知识库落地检查清单，可以直接用于项目启动前的自查。

2023 年，我们给一个传统制造业公司做了个AI知识库。

他们当时遇到的问题很具体。

企业里的业务、销售、研发和售后之间，经常要通过电话或聊天反复确认产品问题。销售随时可能在群里提问，但研发和售后还有自己的工作，不可能一直守在群里回答。

所以，他们想做的不是一个对外客服，而是一个只给内部人员使用的知识库。

销售或业务人员遇到常见问题时，先去知识库里问。能够从资料中确定的，系统直接回答；真正复杂的问题，再去找研发和售后。

现在看，这类知识库已经很常见了。

但真正进场以后才发现：让 AI 根据产品资料回答问题，并不是整个项目里最难的部分。

最难的是，那些准备交给 AI 的资料，本身并没有大家想象得那么可靠。

项目测试时，系统曾经回答错过一个问题。

排查先从模型开始，又检查了知识库的检索结果，最后继续往前查文档解析。

结果发现，模型引用了知识库里的内容，知识库也找到了对应资料，扫描后的文字和原始图片同样一致。

从技术链路来看，每一步都没有问题。

但答案就是错的。

继续追到最原始的纸质设计文档，才发现那份资料当年打印时就印错了。

企业里的老员工其实都知道那里是错的。他们平时不会按照纸上的内容工作，因为这个错误早就通过口口相传，变成了大家默认知道的背景信息。

但没有人重新打印一份，也没有人把这条更正正式记录下来。

于是，当纸质资料经过扫描、解析，再被录入知识库时，系统得到的是一份与原文完全一致、但知识本身错误的资料。

技术团队能检查扫描图片和解析结果是否一致，却不可能只靠技术知道原始图片上的内容究竟对不对。

这个问题上线测试以后才被发现。大家沿着“AI 回答—知识库检索—文档解析—扫描图片—原始纸质资料”一层层往回追，最后才有一位熟悉历史的老员工站出来说：这个地方当年就是印错了。

这件事很小，却把企业 AI 知识库最真实的难点暴露了出来：

AI 可以准确地读取一份资料，也可以准确地引用一份资料，但它无法自动保证这份资料原本就是对的。

一、企业做知识库，通常不是因为“想拥有一个 AI”

这家企业想做内部知识库，背后真正要解决的是信息传递问题。

同一个产品问题，销售会问，业务人员会问，客服会问。研发和售后掌握答案，但他们不可能一直重复回答。

如果这些高频问题能够从产品资料里找到确定答案，那么知识库就可以先承担内部客服的作用。

它不是为了替代研发，更不是为了让企业从此不需要懂业务的人。

它首先解决的是：不要让掌握专业知识的人，一天到晚被相同的问题打断。

这也是为什么企业知识库看起来是一个非常通用的需求。

很多行业都有内部文档，都有销售、客服、研发和售后之间的信息差，也都有大量重复查询。

但“需求通用”不等于“交付可以完全标准化”。

企业真正需要的并不是一个可以上传文件的通用聊天窗口，而是一套能接进自己业务里的工具。

资料在哪里，谁能看，旧资料怎样处理，系统接不接得进去，答案怎样判断正确——这些问题，每家企业都不一样。

所以知识库的入口看起来相同，真正进场以后，工作量却藏在后面。

二、企业的很多知识，根本不在文档里

企业存在的时间越长，历史遗留问题通常越多。

特别是过去数字化基础没有建设好的企业，很多业务流程并没有进入系统，也没有完整的数据库或表格记录。

• 有些流程是师傅带徒弟，嘴上说的。

• 有些规则是在群里说一次。

• 有些错误是大家用久了以后都知道，但从来没有正式改过。

• 有些资料看起来是公司的正式文件，真正干活的人却知道不能完全照着它做。

这些知识长期存在于人的脑子里，靠口口相传维持。

对于企业内部的人来说，这套方式可能已经运行了很多年。大家共享相同的背景，所以不会觉得有什么问题。

但外部团队进场以后，没有这些背景。

AI 更没有。

它看到什么，就处理什么。原始资料如果少了一条默认规则，它不会自己补出来；原始资料如果是错的，它也不会因为“老员工都知道”就自动改正。

这也是为什么不能指望：客户把一个文件夹交过来，导入系统，项目就算完成了。

客户自己都未必知道，哪些关键知识只在少数人的脑子里。

只有当系统真正开始回答问题，或者交付团队进入工作现场，历史上的缺口才会慢慢暴露出来。

三、做知识库不能站在员工对面，要先看他们怎么干活

外部团队进企业做 AI，员工很容易担心一件事：你是不是来替代我的？

如果一进场就站得很高，告诉员工哪些工作可以自动化、哪些岗位可以减少，对方当然不会愿意把真实流程和经验交出来。

现场沟通时，交付团队采取的姿态更像是“半蹲下来”。

不是完全没有自己的判断，也不是站在员工头顶指挥，而是先站在辅助他的位置上，听他讲：

• 工作里哪个环节最烦；

• 哪个地方重复劳动最多；

• 哪个环节最容易出错；

• 现在具体怎样完成；

• 哪些问题一直在消耗他。

再根据他们真实的工作方式梳理流程，判断哪些地方可以使用 AI，哪些地方仍然需要人。

这个姿态很重要。

企业里的老员工有多年积累的行业经验，也踩过很多坑。其中相当一部分经验没有出现在互联网上，模型并没有学到。

如果交付团队一开始就假设“AI 比你更懂”，最有价值的信息反而不会出现。

知识库项目真正需要做的，不只是把已有文档放进系统，还要让那些影响正确答案、但没有写进文档的经验被发现。

开头那张印错的纸说明：正式文件不一定代表全部事实，熟悉业务的人也不是知识库建设中的障碍。

很多时候，他们恰恰是判断知识是否可信的关键。

“半蹲下来”也不等于技术团队完全没有自己的判断。

它更像是在提醒交付团队：客户选择了你，不代表你天然比客户更懂他的行业。

甲方提出的想法，在技术人员看来有时可能不合理。但很多时候，不是客户的想法真的错了，而是外部团队还没有理解他所处的业务环境。

一个在行业里工作多年的人，知道哪些规则是现实条件逼出来的，知道为什么没有采用看起来更简单的办法，也知道某个特殊流程曾经解决过什么问题。

这些上下文没有被听见以前，技术团队很容易把“不理解”误判成“不专业”。

所以遇到看起来不合理的需求，不要上来就反驳。

先问它从哪里来，想解决什么问题，为什么过去没有用其他方式解决，为什么现在一定要这样做。

背景听清楚以后，再把技术方案和风险讲出来。

这对知识库项目尤其重要。

因为知识库最终处理的是企业自己的知识。外部团队懂模型、检索和系统，但客户的员工懂产品、流程和行业。哪一边单独做判断都不够。

技术团队负责把资料接进系统、把问题查出来；业务人员负责告诉系统什么才是这个企业真正执行的知识。

如果两边的知识没有在现场对上，最后得到的可能仍然是一套技术上正确、业务上错误的系统。

四、只和老板聊，确定不了真正的交付边界

企业老板通常可以告诉你两件事：他想不想做，以及大概愿意花多少预算。

但真正要签进合同的交付边界，往往不能只和老板谈清楚。

因为老板讲的是目标，实际干活的人掌握的是流程。

这个项目需要哪些资料，资料现在是什么状态，哪个步骤可以改，哪个系统不能动，谁要配合，最后怎样验收，都要到现场以后才看得出来。

真正确定边界，需要进入客户的办公室或业务现场，和客户指定的人员、实际参与工作的团队沟通。

这项工作可能需要持续几天，甚至大约一周。

聊完他们现在怎样工作，才能判断哪些事情可以做、哪些事情暂时不能做。

这不是故意把需求分析做复杂。

而是知识库依赖的资料、流程和人员，本来就散落在不同地方。没有进入现场，只听一句“做一个企业知识库”，根本无法知道后面会遇到什么。

所以，真正的项目边界不是从老板的一句话里推出来的，而是从现场访谈和现状检查里确认出来的。

边界不能只靠口头理解，要写进工作范围说明。

现场谈清楚以后，还要把结论真正写下来。

企业项目里常用一份工作范围说明，也就是 SOW。它不是为了把合同写得更厚，而是要明确两类东西。

第一类，是交付团队最终要交什么。

例如知识库做到哪个场景，接哪些资料，包含哪些系统能力，怎样进入测试和验收。

第二类，是项目成立所依赖的前置条件。

哪些资料由客户提供，谁配合确认业务，客户要准备什么工作环境，哪个环节不提供就无法继续交付，都要在前期说清楚。

知识库项目最容易产生的一种误会是：只要最终目标里出现了某个结果，中间所有依赖都天然属于交付团队。

但真实情况不是这样。

假设项目约定使用客户已经整理好的产品资料，而进场后发现资料没有数字化、版本混乱、关键规则只在员工脑子里，这些工作会直接改变项目范围。

它们当然可能需要解决，却不能自动变成原合同里已经包含的工作。

如果一项资料、接口或环境本来应该由客户准备，项目开始后客户又无法提供，交付团队需要明确告诉对方：缺少这个条件，原来的交付无法按计划完成。

如果客户希望交付团队把前置问题也一起解决，可以重新评估需要多少时间和工作量，再作为新的范围讨论。

这些内容最好进入合同；合同来不及写得很细，至少也要在双方能保留的沟通记录中说清楚。

边界不是为了以后和客户争论，而是为了让双方在项目开始时就知道：你要交什么，我要准备什么，条件变了以后怎么办。

做着做着发现难度变了，怎么办？

即使前期做过验证，交付过程中仍然可能出现需求变化。

有时是前期测试或概念验证没有覆盖到某个问题；有时是实际开发以后，发现原来低估了难度；有时是开发周期必须延长；也可能做到一半才确认，某个需求在当前条件下根本完成不了。

这时不能假装原计划没有变化，也不能一直拖到验收前再告诉客户。

正常做法是走需求变更流程。

项目规模较大，可以走正式的变更程序；合同较小，也应该及时和客户负责人沟通，把变化说清楚。

如果只是需要增加时间，客户可以不同意加钱，但必须重新确认交付时间。没有足够时间，又要求交付结果完全不变，项目事实上就无法完成。

如果变化来自新增需求，就要重新判断它是否属于原工作范围。

现实中，合同签完以后再增加预算并不容易。客户通常更可能接受验收时间后移，而不是直接追加费用。

所以前期的现场访谈、概念验证和工作范围说明越清楚，后面双方需要重新谈判的次数就越少。

知识库项目不是把需求冻结以后机械开发。资料状态、接口条件和业务判断都可能在进场后暴露新问题。

真正专业的做法不是保证“绝对不会变化”，而是变化发生时，能够指出它为什么发生、影响什么，以及下一步需要重新确认什么。

五、知识库为什么一直没有“一统天下”的产品？

知识库看起来非常适合做成一个标准产品。

文档上传进去，用户提出问题，AI 找到资料并回答。只看这个流程，似乎所有企业都可以使用同一套工具。

但现实是，市场上一直有很多知识库产品在不同行业里运行，却没有一套产品能直接满足所有企业。

即使一家厂商已经把知识库做得很深，交付给具体客户时，仍然可能需要定制。

原因不是“上传和问答”还不够成熟，而是企业内部至少还有三类问题无法被一个通用界面直接抹平。

第一类是权限。

企业知识库不是个人文档库。哪个部门的人能看到哪些知识，不同角色能问到什么内容，都需要划分。

第二类是数据接入。

企业的数据不会天然集中在一个整理好的文件夹里。它可能存在不同系统和沟通工具中，也可能以企业原有的方式分散保存。

知识库要使用这些数据，就必须面对每家企业不同的接入条件。

第三类是数据治理。

一个经营多年的企业，文档数量可能非常大。哪些已经过时，哪些仍然有效，哪些存在冲突，需要先治理。

大部分知识库产品解决的是存储、检索和问答，却未必直接包含客户真正需要的知识治理。

所以，企业知识库的通用需求是真的，定制工作也是真的。

企业真正想用的，往往不是一个需要学习提示词的工具

企业用户对 AI 产品还有一个很现实的要求：使用门槛不能太高。

通用 AI 工具能力很强，但越通用，往往越需要使用者自己描述任务、组织提示词、判断下一步怎么做。

对于长期研究 AI 的人来说，这些操作不难；对于每天有固定工作的业务人员来说，它可能就是一道新的门槛。

很多企业真正想要的不是再学一套复杂工具，而是“点点点”。

打开原来的工作入口，选择自己要做的事情，输入必要信息，然后直接得到结果。

这也解释了为什么企业明明可以买到通用知识库，最后仍然会提出定制需求。

他们不只是要一个能聊天的模型，还希望它适应原来的角色、资料和流程。

内部销售问产品问题时，不应该先研究怎样写提示词；客服查资料时，也不应该先理解知识库背后的技术结构。

系统需要把那些重复出现的操作提前收好，让员工知道在哪里问、怎样得到结果、什么时候需要再找人。

这不是说企业知识库只能做成按钮，也不是说自然语言交互没有价值。

重点在于，产品不能把技术团队省下来的工作，重新变成业务人员的学习成本。

知识库底层可以通用，真正交到客户手里时，入口和流程仍然要贴近员工原来的使用习惯。

六、数据治理不是一个抽象概念，它首先要处理“新旧真假”

个人知识库里的文件相对有限，使用者通常也知道每份资料从哪里来。

企业不是这样。

企业经营时间越长，积累下来的产品手册、设计资料和历史文档越多。它们可能来自不同阶段，由不同的人维护，也可能长期没有统一整理。

当这些资料准备进入 AI 知识库时，一个无法绕过的问题就是：

哪些东西过时了，哪些东西没有过时？

开头那张印错的纸，只是“知识本身有问题”的一种情况。

另外一些情况可能不是内容印错，而是旧资料仍然保留，新资料又已经生效。如果两者一起进入系统，AI 能找到内容，却未必知道企业现在到底执行哪一版。

这里没有一套万能的治理表格，技术团队也不能自行判断所有资料。

他讲得更直接：企业的文档量一大，哪些过时、哪些没过时，本身就需要治理；不同厂商也有不同的治理方案。

这意味着，知识治理不是知识库外面一个可有可无的整理动作。

当客户的历史资料没有被处理好时，它会直接决定知识库最终回答什么。

如果源头不可靠，后面的模型、检索和界面再好，也只能把不可靠的知识更方便地提供给用户。

七、复杂 PDF 处理不了时，人工录入也是交付方案

这家企业早期的产品资料并不是结构清楚的网页或 Markdown 文档，而是图片形式的 PDF。

里面不仅有文字，还有产品图片、三维图、尺寸标注和不规则表格。

在当时的技术条件下，多模态模型对这类复杂 PDF 的识别能力有限。

如果强行完全自动化，识别效果不稳定，技术成本也会很高。

最后，这个项目采用的是人工操作，把资料接入系统。

这件事很能体现企业 AI 交付和技术演示的区别。

技术演示很容易追求“全自动”：上传一个 PDF，系统几秒钟全部识别，听起来很先进。

但客户最终要使用的是里面的产品知识。图片、尺寸或表格只要错一个关键位置，自动化比例再高也没有意义。

当技术手段的成本太高、结果又不稳定时，用人力完成录入并不丢人。

交付首先要保证事情能做完，而不是证明每一个步骤都必须由 AI 完成。

八、老系统没有接口，最好不要轻易碰

企业数据还可能存在原来的 ERP、OA 或其他业务系统里。

知识库要不要接这些系统，不能只看客户想不想要。

还要看原系统有没有可以使用的接口。

这类项目对老系统的态度非常明确：不会轻易去碰；如果 ERP 不提供接口，这部分业务就不做。

原因也很现实。

没有接口，交付团队就没有稳定、明确的方式把数据接出来。为了一个知识库项目强行改造遗留系统，很容易把项目拖进无法控制的范围。

所以现场确认边界时，既要知道客户希望知识库接什么，也要确认这些系统是否真的具备接入条件。

做不了的部分，要在开始前说清楚。

九、私有化还是云端，先看客户对数据的要求

企业部署知识库时，常见的第一类选择，是私有化还是云端。

有些客户非常在意自己的数据，明确要求数据不能离开公司，也不愿意调用外部模型。

这种情况下，就需要在企业自己的环境或单独的机器上部署。

另一些客户可以接受云端模型，那就可以使用云服务。

这不是哪种方案天然更先进，而是由客户的数据要求决定。

技术框架的选择也是一样。

如果客户自己已经研究过某套方案，可以结合客户的要求来做；如果客户没有明确偏好，小团队更适合使用自己熟悉、出现问题后能够处理的技术。

更重要的是，逐渐沉淀一套自己熟悉、可以复用的技术设施。

原因很简单：企业交付不是做完一个演示就离开。工具出了问题，交付团队要能判断问题在哪里，也要有能力修。

如果每个客户都临时追一套自己不熟的新工具，项目出现问题时，就很难真正负责。

私有化部署不是报一台机器，而是先说清场景依赖什么模型

客户要求私有化时，交付团队首先要给出的不是某个服务器型号，而是这套场景对模型能力的要求。

同一个知识库，模型规模和能力不同，最终效果也会不同。

如果场景需要较强的模型才能达到要求，就要把这个依赖明确告诉客户。较小模型满足不了，项目就不能先按“应该也能用”推进，等机器买回来以后再碰运气。

模型要求确定以后，才进入硬件和推理环境的评估。

客户有自己的技术团队，可以由他们根据模型、使用人数和调用量评估机器。

客户没有这方面的能力，交付团队可以把大致预算、要部署的模型以及预估的吞吐量交给服务器供应方，让专业供应方提供硬件方案和报价。

这里的分工很清楚。

知识库交付团队负责说明业务场景需要什么能力，服务器供应方负责根据模型和调用量设计硬件，客户再根据数据要求和预算做选择。

如果把顺序反过来，先买机器，再要求交付团队想办法把场景塞进去，项目从一开始就可能失去验收基础。

它需要先证明：在客户允许的环境里，能够部署的模型是否真的达得到这个知识库所要求的效果。

十、模型不是看排行榜选出来的，要拿固定问题去测

同一套知识库流程，换不同模型，效果会不一样。

早期模型能力不足时，即使资料中存在正确答案，模型也可能回答不出来。

所以模型选型不能只看宣传，也不能因为客户说要某个模型就默认它一定能完成场景。

更直接的方法是：先固定一组问题，用同样的问题测试模型。

如果不管怎样调整，准确率都达不到要求，就换下一个模型。

最终给客户的答案只有两种：

这套流程在哪个模型下可以工作；或者，目前的模型都实现不了。

私有化部署时也是同样的逻辑。

交付场景依赖什么级别的模型，需要先说清楚。如果较小的模型满足不了，就不能为了迎合预算，先假设它能用。

客户有自己的技术团队，可以由对方评估机器和推理环境；客户没有相关能力，可以再找服务器供应方给出方案。

但交付团队首先要明确的是：这个业务场景对模型能力有什么要求。

模型不达标就换；都不达标，就告诉客户现在做不了。

这句话听起来不对销售不利，却是项目能够真正验收的前提。

十一、知识库一定要做测试集，因为客户最后要验收

企业项目不能靠演示时问对了几个问题就算完成。

项目交付前后要做测试集，因为客户最终需要验收。

测试分成两套。

第一套是交付团队自己的测试集。

它的做法和传统软件时代设计测试用例很像：按照产品的各个小需求点，分别准备正向测试和反向测试。

交付团队设计完以后，不是自己看一遍就算了，而是把这套测试集交给客户确认。

客户需要判断：这些问题是否符合真实业务，有没有遗漏，测试范围是不是他们认可的。

交付团队用这套测试集反复测试，达到约定标准以后，再把系统交给客户。

第二套是客户自己的验收测试集。

这套题不会提前给交付团队看。

客户测试后，只反馈结果：达标还是不达标，还差多少。

知识库的输出是自然语言，怎样计算通过率？

这个项目实际采用的思路是：

知识库测试集中，大约 85% 的题目有确定答案。

例如某个产品通过了哪些认证，某个位置的电流是多少。这些问题在资料中有标准答案，回答正确与否可以直接判断。

剩下没有标准答案的题目，由人来评估。

这个比例不是一条适用于所有项目的行业标准，而是这次交付中采用的实际做法。它说明了一件事：即使 AI 输出是非结构化文本，也要尽量把验收建立在可判断的问题上。

不能全部依靠“读起来好像不错”。

从这套方法里，可以看到一条非常清楚的验收链路：

按照需求点设计正反用例 → 交给客户确认测试范围 → 交付团队测试达标 → 客户用未公开题目独立验收 → 标准答案机器判断，开放答案人工判断。

为什么知识库较少遇到长上下文“越用越笨”

很多人在使用聊天类 AI 时，会感觉它聊得越久，表现越不稳定。

常见原因大致有两类。

一类是产品侧改变了传给模型的调用参数，例如可用工具、思考强度或思考时长发生变化，使用者会明显感觉能力下降。

另一类是上下文越来越长。模型处理长上下文时，可能保留头尾，却忽略中间部分的信息，于是前面谈过的重要内容在后续任务里消失。

聊天型智能体确实需要面对这个问题：上下文满了以后怎样压缩，哪些旧信息应该保留，哪些可以丢掉。

但企业知识库的典型使用方式不完全一样。

大部分知识库任务是功能性的。

员工来查一个产品问题，得到答案以后就离开；下一次再查另一个问题，不一定需要系统记得昨天聊了什么。

一次使用可能只有一两个问题，上下文天然比较短，所以由超长对话引起的质量下降相对少见。

这也说明知识库没有必要为了“像人一样一直聊”而无限保存全部对话。

它更重要的任务，是在当前这一次查询里找到正确资料，并给出可以验收的答案。

私有化部署还有另一个特点：企业自己的模型调用参数不会被外部产品随时调整。

只要整套调用流程设计得足够清楚，模型能力相对稳定，团队就更容易使用固定测试集持续验证。

当然，私有化不代表答案天然正确。

资料、检索、权限和测试仍然要处理。它只是在模型和调用参数这一层，为企业提供了相对稳定的运行条件。

验收之外，还要把项目过程留下来

知识库项目有测试集，并不代表验收时一定不会产生分歧。

前期谈过什么、客户确认过什么、项目中间改过什么，如果都只停留在口头沟通里，最后很容易变成双方各自记得一套版本。

所以交付过程中，该确认的工作记录要确认，该签字或盖章的材料要完成，该保留的工作痕迹也要保留下来。

这套留痕至少贯穿几个关键节点。

项目开始时，要留下双方确认过的工作范围和前置条件。

客户应该提供哪些资料、人员和环境，哪项条件缺失会影响交付，都不能只靠现场的人记住。

需求确认以后，要留下客户对测试范围的反馈。

交付团队设计的正向、反向测试有没有漏掉真实问题，客户是否认可这套测试集，确认结果需要保留。

交付过程中出现变化，也要留下记录。

如果前期验证没有覆盖某个难点，导致周期需要延长，或者某个需求已经超出原范围，就要及时说明原因、影响和新的安排。

项目进入验收时，要能拿出测试结果和客户反馈，而不是只说“当时演示过，大家觉得可以”。

客户自己的测试集可以不提前公开，但最终达标还是不达标、还差多少，也应该形成明确结果。

工作留痕并不是为了把客户当成随时可能发生纠纷的对手。

恰恰相反，它是在保护双方对同一件事的共同理解。

项目顺利时，这些记录能减少反复解释；需求变化时，它能帮助双方找到原来的边界；如果真的出现不验收、不给款或其他争议，合同、聊天、邮件和过程记录才有可能成为解决问题的依据。

企业 AI 项目本来就比固定软件更容易遇到效果波动和需求变化。

越是这样，越不能只凭感觉管理项目。

知识库最终能不能验收，不只取决于系统答得怎么样，也取决于双方有没有在项目过程中持续确认：现在交付的，是否仍然是开始时约定的那件事。

十二、一个知识库项目，可能会做出第二个数据治理项目

开头那张印错的纸，不只是一次测试事故。

它还暴露出客户更底层的问题：大量产品资料和设计资料没有完成数字化与数据治理，历史问题仍然留在员工脑子里。

知识库交付过程中遇到的这些问题，有可能继续变成一个新的项目。

例如，先把原定的知识库交付完成，再讨论是否把企业的产品手册、设计资料重新数字化，并做一遍数据治理。

但这件事不能偷偷塞回原项目，也不能等做到一半才和客户争论“到底算谁的”。

这时还要同时守住交付边界。

签合同前，要写清工作范围：哪些由交付方负责，哪些资料和环境需要客户提供，哪些内容属于原项目，哪些不属于。

如果客户原本答应提供的资料或条件没有准备好，交付团队又被要求额外解决另一层问题，就要回到双方确认过的范围讨论。

知识库和数据治理可以互相连接，但并不是同一件事。

前者解决知识怎样被查询和使用，后者处理历史资料怎样重新整理、数字化和确认。

交付中发现第二个需求没有问题。

真正重要的是：把新需求作为新的范围谈清楚，而不是让第一个项目无限扩张。

附：企业 AI 知识库落地检查清单

1. 使用场景

• ☐ 已经明确知识库服务哪些内部人员；

• ☐ 已经找到目前反复回答问题的岗位；

• ☐ 已经确认知识库准备接住哪一类查询。

2. 现场与边界

• ☐ 已经和实际干活的人沟通过，而不只是听老板描述；

• ☐ 已经了解现有流程、重复劳动和容易出错的地方；

• ☐ 已经确认哪些事情能做、哪些事情暂时不能做；

• ☐ 已经写清交付内容和客户需要提供的前置条件。

3. 资料与历史知识

• ☐ 已经检查资料是否分散在不同位置；

• ☐ 已经检查复杂 PDF、图片、尺寸和不规则表格；

• ☐ 已经向熟悉业务的人确认是否存在口传经验；

• ☐ 已经区分过时知识和仍然有效的知识。

4. 权限与数据接入

• ☐ 已经确认不同部门能够获取哪些知识；

• ☐ 已经检查企业数据实际存在哪里；

• ☐ 已经确认旧系统是否提供可用接口；

• ☐ 没有把无法接入的老系统默认算进交付范围。

5. 技术与模型

• ☐ 私有化还是云端，已经根据客户的数据要求确定；

• ☐ 使用的是团队熟悉、出现问题后能够处理的技术；

• ☐ 复杂资料自动处理成本过高时，已经评估人工方案；

• ☐ 已经用一组固定问题测试模型；

• ☐ 模型不达标时会更换，全部不达标时会明确说明当前无法实现。

6. 测试与验收

• ☐ 已经按照各个需求点设计正向和反向测试；

• ☐ 交付团队的测试集已经交给客户确认；

• ☐ 客户保留了自己的独立验收测试集；

• ☐ 大部分题目具有可以判断的确定答案；

• ☐ 没有标准答案的部分由人评估。

7. 新问题与新范围

• ☐ 已经区分知识库项目和数据治理项目；

• ☐ 历史资料数字化、数据治理或旧系统改造没有被默认塞进原项目；

• ☐ 交付过程中出现的新需求，会重新确认范围和条件。

最后：企业知识库最怕的，不是 AI 不够聪明

回到 2023 年那次交付。

知识库回答错了以后，交付团队一层层检查，最后发现技术链路没有出错，错的是最初那张纸。

这个案例之后，再看企业知识库，就很难只把它理解成一个模型问题。

它同时涉及现场流程、口传经验、权限、数据接入、旧知识治理、复杂文档处理、遗留系统、模型选型和客户验收。

这些问题为什么不能被一个标准产品全部解决？

因为每家企业留下来的资料和系统不同，部门权限不同，在意的指标也不同。

这也是为什么，企业知识库的需求非常通用，真正交付时却仍然存在大量定制工作。

做这类项目，不能等客户把一切准备好，再带着工具过去实施。

客户现场一定会有资料缺失、历史问题和其他依赖。交付团队要做的，是进入现场，把哪些能做、哪些不能做、客户需要准备什么、最后怎样验收，一件一件说清楚。

有些问题用 AI。

有些问题用传统技术。

有些问题在当前条件下，直接用人力更可靠。

还有些问题，暂时做不了，就要明确说做不了。

企业 AI 交付的目标，不是证明 AI 什么都能做，而是把客户真正要用的东西，做到可以测试、可以验收。

也能稳定运行。

如果你也在关注企业 AI 服务、FDE 真实工作情况，欢迎关注。主页会持续更新企业 AI 落地的真实案例、实战判断和交付方法。