别把AI当作“工具”，而是要当作“员工”来设计。
这正是“数字员工”概念的来源，我们会在第二篇中展开。
2025年的企业技术领域的发展很有意思。一方面，全球在人工智能领域的支出预计将突破6000亿美元，基础设施和应用投资的同比增幅高达76%。然而，在这场资本狂欢的阴影下，一个残酷的统计现实正困扰着每一个渴望数字化转型的董事会和CIO：高达95%的生成式AI试点项目未能成功投产，更别说产生商业价值了。这一判断也与 MIT报告《The GenAI Divide》中提到的数据，以及Gartner 对“AI Pilot-to-Production Gap”的研究结论都高度一致。
这便是“生成式AI鸿沟”。本文作为《企业AI落地三部曲》的首篇，旨在通过我们近两年在企业AI落地实践中的教训与经验，为企业技术决策者提供我们的独特视角。时间到了2025年底，企业AI落地的失败已经不能再归咎于模型能力的不足——GPT-5.2与Claude 4.5等模型已足够强大。企业往往陷入了“忽略业务目标”、“单纯技术迷信”、“混淆个人与企业AI差异”这三大误区。
本系列目前的计划是三篇，每周一篇，分配是：
上篇：通过我们在企业AI落地实践中获得的教训和经验来分析为什么95%的企业AI落地项目失败了。 中篇：数字员工是目前最好用，也必将是未来的主流趋势的企业AI Agents落地形态。 下篇：企业AI落地的基石，知识构建、知识治理与知识健康。
以下是上篇内容。
一、当AI成为目的而非手段
在所有导致企业AI项目夭折的因素中，最致命的并非技术本身，而是战略出发点的偏离。正如思维导图所强调的，“忽略业务目标”是失败的根源。太多的企业陷入了“为了做AI而做AI”的怪圈，将手段异化为目的。
解决业务问题，而不是做一个“AI项目”
在2023年至2024年的生成式AI爆发初期，以及2025年上半年的DeepSeek热潮，许多企业的IT部门面临着来自董事会的巨大压力：“我们必须有AI战略。”这种压力催生了大量的“AI项目”——这些项目的核心驱动力是技术展示而非业务痛点。CIO们忙于部署聊天机器人，生成会议纪要或润色邮件，却鲜少追问：这是否是当前阻碍业务增长的最大瓶颈？
当技术团队沉迷于大模型的上下文窗口大小或推理速度时，他们往往忽略了最本质的问题：我们试图解决什么业务难题？。一个典型的失败案例是某大型制造企业投入数百万元开发了一个通用的“企业知识助手”，试图回答员工关于公司政策的所有问题。然而，员工真正的痛点并非查询休假政策（这是低频需求），而是生产线上的设备故障诊断（这是高频、高价值需求）。由于项目目标与业务痛点错位，该助手在发布三个月后日活跌至个位数，最终被叫停。
成功的5%企业采取了截然不同的路径。他们不问“AI能做什么？”，而是问“我们的业务哪里最痛？”。例如，我们服务的某中国500强企业，他们就把业务难题着眼于商用硬件产品的售后问题，帮助全国的售后工程师提升问题解决效率。他们甚至不在意检索问答的准确率是多少，而是把“问题解决率”当作核心指标：减少把问题流转给总部研发人员的次数，同时减少问答解决时间。截止目前问题解决率比之前的全文检索增加了70%以上，问题解决时间平均减少50%以上。而且通过交互过程中的点赞/点踩和反馈，售后知识维护者可以及时补充相应知识，让知识飞轮转动起来。现在该知识引擎和AI应用，已经开始影响400热线和售前的业务领域，目标是通过在企业知识引擎和AI应用上的投入让企业各个业务条线的效率都能获得显著提升。
换句话说，当一个AI项目被大肆宣扬为“AI项目”时，它往往已经处于危险之中。最好的AI项目是“售后服务效率优化项目”、“制度审核提升项目”或“研发加速项目”，AI仅仅是其中不可或缺的技术。
你的项目可测算ROI吗？
“忽略业务目标”的另一个表现是缺乏可测算的投资回报率（ROI）在每个项目的立项中，我们可以扪心自问一下：“这个项目可测算ROI吗？”
目前的现状是，绝大多数企业在计算AI价值时使用的是“虚荣指标”，如“节省工时数”或“模型准确率”。麦肯锡的调研指出，虽然AI采用率很高，但真正能影响到损益表的企业寥寥无几。
为何“节省时间”是一个ROI陷阱？
如果一个编程助手帮助初级开发人员节省了30%的编码时间，但这并未转化为更快的产品上市速度，或者这些节省下来的时间被用于浏览网页，那么对企业而言，ROI为零。更糟糕的是，如果AI生成的代码包含隐蔽的Bug，导致资深工程师需要在后期花费双倍的时间进行调试，那么ROI甚至是负值。
ROI的影响有自己的一些硬指标，比如上面说到的售后问题的“问题解决率”，直接影响到的就是企业的售后队伍人员数量和成本，进一步影响的是客户满意度和续约率等，这些都直接影响到了企业生存的根本——成本和收入。
所以真正成功的企业关注的是下面三个“硬指标”：
收入提升： AI系统和应用是否直接提高了收入，如客单价、转化率或者续约率等等？ 成本规避： Agent是否真正解决很多人类无法快速完成的工作，是否节省了员工时间，进而减少整体的运营成本支出？ 风险降低： 这是前面没有提到的，但确是我们的银行客户非常关心的，如合规Agent是否真的减少了因违规操作导致的罚款风险？
AI不是玩具，也不是魔法，它是昂贵的计算资源，必须像对待任何资本支出一样进行严格的财务审查。企业在考虑AI落地的时候，对于目标的设定，要尽可能往前走一走，比如不是要求“问答准确率”，而且要求“问题解决率”。因为问答准确率真的是可以刷题的，而问题解决率确实实实在在的，这才是对企业的成本支出负责。
二、单纯靠技术解决不了问题
如果用一句话总结过去两年的企业AI实践经验，那就是：
RAG 不是企业AI的答案，它只是一个放大器。
没有知识结构、权重和治理，RAG放大的只会是混乱。
单纯的技术解决不了问题，这应该是我们在企业AI落地中得到的教训和经验。企业AI落地这样的大事情，可不是一个单一产品就可以搞定的，对于崇尚产品的技术极客来说可能会失望，正确的方式是必须把这件事当作一个工程来看。
1.纯技术的RAG解决不了太多企业问题
熟悉我们的朋友都知道，TorchV是以RAG“起家”的，RAG也被视为企业落地的“银弹”。其逻辑看似完美：将企业文档切片存入向量数据库，用户提问时检索相关片段，再由大模型生成答案。然而，现实是残酷的：纯技术的RAG解决不了太多企业问题。为什么？因为它面临着三大难以逾越的障碍：语义相似度陷阱、缺乏全局视角、权重缺失。
1）语义相似度陷阱
传统的RAG依赖向量检索，其核心机制是计算查询词与文档片段在多维空间中的余弦相似度。这种机制假设“字面或语义接近”等同于“逻辑相关”。这在企业复杂的业务场景中往往失效。
场景模拟：
用户提问：“如果我的供应商违约，我该如何终止合同？”
向量检索的反应： 它可能会检索到一份名为《供应商合同终止流程》的文档（这是正确的）。但同时，它也极可能检索到《如何与供应商建立合同》或《防止供应商违约的策略》，因为这些文档中充斥着“供应商”、“违约”、“合同”等高频词，且语义距离极近。 结果： 模型接收到了大量相关但无用的噪音，甚至可能混淆“建立”与“终止”的条件，导致回答似是而非。
不过，我们在一家国内TOP5的城市商业银行项目中已经完美解决，虽然做不到标准产品一次性匹配，但是落地工作也不复杂。
2） 缺乏全局视角
这是传统RAG最著名的“阿喀琉斯之踵”。向量检索本质上是局部的、点状的。它擅长回答“文档A中关于X说了什么？”，却无力回答跨文档的聚合性问题。
失效案例：
企业CEO问：“过去一年我们所有子公司的IT审计报告中，共同的风险点是什么？”
传统RAG的困境： 它会尝试检索包含“IT审计”、“风险”的片段。由于受限于Top-K（例如检索前5个最相关的片段），它可能只能找到子公司A和子公司B的报告片段，而完全忽略了子公司C、D、E的报告。 结果： AI基于不完整的信息进行总结，得出片面的结论。它无法“阅读”成百上千份文档并提取共性，因为它缺乏一个能够俯瞰全局的结构化视角。这导致了所谓的“以偏概全”的幻觉，这种幻觉比凭空捏造更难被发现，因为它的每一个论据都是真实的，只是结论是错误的。
面对这样的问题，我们也是针对性地在产品上做了很多补充，比如Top-K，召回数量，以及分拆执行等。
3） 权重缺失
这可能是三个问题里面最严重、最难的，它需要知识维护，而且并非一蹴而就的事情。企业知识是有优先级的，是有权重的。但在纯向量的世界里，所有文本片段在索引中往往是平等的，唯一的区别是与查询词的相似度得分。
业务痛点：
一份是2020年的过时《员工手册》（因为某些条款适用于新手册出台之前入职的员工，如期权行权相关内容、离职与年终奖计算等内容，所以在很多企业中依然会被保留），一份是2025年最新的《员工手册》。
当用户问“年假怎么算？”时，如果2020年的版本由于措辞与提问更匹配（也许是因为使用了更通俗的语言），其相似度得分可能高于2025版。
RAG的失败： 系统检索出了旧版本，AI据此给出了错误的政策解答。 缺失的环节： 纯技术RAG缺乏“时效性权重”、“权威性权重”或“来源权重”的概念。它不知道CEO的邮件比实习生的笔记更重要，不知道“已废止”标记意味着该文档即便语义再匹配也不应被引用。这种元数据与业务逻辑的剥离，使得AI在企业环境中显得极其“天真”且不可靠。
针对这样的问题，成功的实践都不会只依赖语义相似度，而是会建立知识价值体系（KVS），定义文档 在查询 下的最终检索得分 为语义得分与价值得分的加权融合：
其中， 为原始的向量相似度得分，而 则是本文档体系建设的核心——全局静态质量分。然后通过PageRank算法、点赞点踩交互统计和威尔逊区间法等来综合这个全局静态质量分，该得分与查询无关，仅取决于文档本身的属性。到这里，你也可以看到，虽然我们用一系列算法可以解决一部分问题，但是要让这个系统真正在企业里有效运转，我们需要设计很多交互动作和数据埋点来收集这些决定最后全局静态质量分的功能细节。TorchV AIS的KVS设计正是这一实践路径的一种工程化实现。
这就够了吗？不够！还需要培训，需要陪跑，这才是真正的企业AI落地实践。
2.企业需要有一个知识底座
当然，站在2025年年底这个关头回头看，我们已经把近两年的企业AI落地实践中遇到的问题的解决方案都尽可能的“装进”我们的标准产品TorchV AIS了，企业需要有一个这样的知识底座。
对于企业的AI应用来说，什么最重要？答案是和企业有关系才是最重要的！
我们可以使用LLM做文档润色整理，可以找问题的答案等等，但是这些似乎都和企业没有直接关系。企业AI应用需要将结果作用于企业数据和知识，也需要从企业的数据和知识中获得资源。
所以企业需要有一个知识底座来管理自己的数据和知识，这也是为不断发展的AI应用作底层支撑和准备。知识底座（引擎）主要作用包括：
数据接入与清洗： 知识引擎应该是可以与企业原有系统、数据库等进行对接，将知识和数据的同步自动化，在同步过程中实现数据清洗工作。在进入模型之前，数据必须经过严格的清洗、去重和脱敏（如有需要），避免出现“垃圾进，垃圾出”的情况。 知识治理： 类似上面已经提到过的为每一块数据、切片自动打上时间戳、作者、部门、密级、关键词和摘要等标签，这些都属于知识治理。当然，还有知识价值系统的一系列算法和交互，都需要知识引擎这样一个载体。 知识权限与安全：AIS知识引擎可以进行知识库级别、文档级别和应用级别的权限控制，为人员/团队/组织进行个性化授权，保障文档和数据导入到知识库之后的安全。且可对知识库内的行为进行审计日志生成，不可篡改和消除，保障系统安全。
关于AIS知识引擎的更多功能，我们会在本系列的第三篇文章中详细讲述。
3.需要与现有应用端无缝集成
“单纯的技术解决不了问题”的另一层含义是：孤立的AI没有价值，AI应用需要可以与现有应用端无缝集成的能力。
目前的许多AI试点项目是独立的Web界面（类似ChatGPT的对话框）。员工需要离开他们日常工作的写作工具、ERP、CRM或IM系统，登录到一个专门的AI网页去提问。这种“上下文切换成本”极高，导致用户粘性极低，这也是很多AI项目在企业内部失去支持者的重要原因。
也是得益于和微众银行、台州银行等优秀银行客户一起实践得来的经验，我们的应用是和钉钉、企业微信和飞书等无缝集成的。
而且目前的数字员工产品做的更加极致，我们可以在钉钉中与数字员工（如管理产品需求的巴图鲁）完成需求提交，也可以在钉钉中让数字员工“爱丽丝”帮我们总结某次讨论的内容，并存储到知识引擎中，需要的时候可以让她帮我们做一个分析，把分析结果交给我。而我们所做的这些交互全部在钉钉上完成，就像是我们和一个同事交流那么简单，使用的培训成本几乎为零。
关于TorchV数字员工我们将在本系列的第二篇文章详细讲述。
三、企业AI与个人AI的区别
本来不想讲这一章了，但是后来感觉本章的很多内容和MIT的那篇《The GenAI Divide：STATE OF AI IN BUSINESS 2025》中提到的有很大关联。很多企业把“企业AI与个人AI（如个人版ChatGPT）”混淆，让我们缺失了两个核心维度的思考：学习能力和从问答到执行。
1.缺少学习能力
当你告诉个人版ChatGPT你的名字时，它可能会在当前的对话窗口中记住。但当你关闭窗口，下周再来时，它已经忘记了你是谁。对于企业而言，这就没玩继续玩下去了。
企业AI必须具备“长记忆”：
用户偏好记忆： 如果一位高管曾纠正过AI：“不要给我生成表格，我喜欢关键信息的列表”，AI必须永远记住这一点，而不是让高管每次都重复指令，特别是这些用户习惯问题。 业务演进记忆： 昨天AI犯了一个错误，被员工纠正了。今天，系统中的所有其他AI Agent都应该学会这个纠正，不再犯同样的错误。当然，目前这样的操作不会自动发生，需要人来最终确定，也就是“人在回路”的核心思想。
知识引擎会专门为企业、部门和个人提供长记忆。知识引擎里面不仅包括静态文档，还包括反馈回路，当用户对AI的回答点“踩”并提供修改意见时，这一行为必须被捕获并回写到知识库中，成为系统进化的一部分。仅影响到用户个人的反馈和修改，可以立即实现。对于全局的，则需要经过系统管理员确认。
2.从问答到执行
这是从Copilot到Agent的跨越，绝大多数失败的AI项目都停留在“聊天机器人”阶段——它们能陪聊、能写诗，但不能干活。
企业雇佣员工不是为了让他们整天回答问题，而是为了让他们解决问题。同理，企业AI的价值在于做事情，而不仅仅是请来一堆“师爷”。当然，这对于目前的企业AI落地来说依然是有挑战的。
1）操作企业知识和数据
这一点其实我已经在第二章提到过了，不再赘述，而且在下一篇文章（关于AI数字员工）会更加详细展开来讲。
2）提供企业上下文
场景： 我会在钉钉上对梁卉说：“等你完成本月的差旅统计之后，给胡总发个邮件，抄送我。”
缺乏上下文： 梁卉会问：“胡总是谁？发什么内容？目的是什么？”，这应该比自己写还麻烦。
具备企业上下文： 梁卉知道我说的胡总是我们营销中心负责人，知道这是每次月会胡总工作分享材料中的重要数据，所以她也会知道这封邮件该怎么写。
这就是“上下文感知”（Context Awareness），它是AI从“累赘”变成“助手”的关键。
3） 集成企业业务流程
AI不应游离于流程之外，而应成为流程的节点。
在传统的BPM（业务流程管理）中，节点是人或固定的脚本。在AI时代，Agent成为了流程中的动态节点。
比如，在采购审批流程中，一个“合规Agent”可以自动审查合同条款。如果条款标准，它直接批准进入下一环节；如果发现异常（如非标准赔偿条款），它挂起流程并通知法务专家。这种集成实现了“人在回路”（Human-in-the-Loop）的无缝协作，既提高了效率，又控制了风险。
当然，这里还有一点非常重要，就是企业也要建立自己的MCP服务，这是我们在实践中真正受益的，在那些已经建立了MCP服务的客户那里享受到了开发新的数字员工的简便。
结尾：开启数字员工时代
过去的两年，我们像是在招聘大量的“数字实习生”——那些基于LLM的、只会聊天、偶尔犯错、没有记忆的助手。这很有趣，但无法支撑企业的未来。
现在，是时候解雇这些“实习生”，聘请真正的“数字员工”了，而且要建立自己的数字员工军团，释放超级巨大的企业能量。
这就需要我们跨越“生成式AI鸿沟”，走出单纯依赖模型能力的误区。
不要再问：“这个模型有多聪明？” 要开始问：“我们的知识底座（引擎）有多扎实？我们的数字员工能执行多少步复杂的业务操作？我们的ROI是否经得起财务审计？”
失败的95%倒在了对工具的盲目崇拜上。
成功的5%赢在了对业务本质的深刻理解和对基础设施的耐心打磨上。
说的更直接一些：
真正的分水岭，并不是你是否使用了AI，
而是你的组织，是否已经具备了“管理非人类员工”的能力。
