企业AI必须用企业知识开源来保障

我在周二的第二届AIEC大会上，系统阐述了企业知识开源对企业AI的重要意义，指出了企业AI应用真正的管理变革重点，并不是组织和流程，而是人类语言：

一、企业AI的瓶颈不是技术，而是人

当下企业在应用AI时，为了提升AI的效能，都把资源和注意力投向了技术方面——即在AI这一端：Prompt Engineering（提示词工程）、RAG（检索增强生成）、Ontology（本体工程）、Harness Engineering（智能体工程框架）、Context Engineering（上下文工程）等等。

这些技术工作固然重要，也确实构成了当前AI工程实践的主流范式。但这里存在一个认知误区：这些工程手段优化的，都是“AI如何更好地理解和处理输入”，而非“人是否给出了可被理解的输入”。

Prompt Engineering再精巧，如果使用者本身对问题的认知是模糊的、表达是歧义的、用词是自相矛盾的，那么再好的提示词模板也只是把一个错误的意图包装得更精致；

RAG检索得再精准，如果用户提出的问题本身用词漂移、指代不清，检索出来的知识也无法命中真实需求；

Context Engineering构建的上下文再丰富，如果不同角色对同一术语的理解本就存在分歧，堆砌再多上下文，只会让矛盾被掩盖，而不是被解决。

本体（Ontology）是几种技术手段里，在方法论上触及“语义一致性” 问题的——本体工程试图用形式化的方式，定义概念、属性、概念间的关系，构建一套机器可推理的知识结构，这应是解决语义歧义的天然武器。

但现实中，企业的本体建设是由知识工程师、架构师在技术团队内部完成的，本体一旦建成，就变成一份供机器检索、推理使用的静态资产，却很少反过来要求企业里通过说话、写字向机器提需求的人，去学习和遵循这套本体所定义的概念体系。

本体解决了机器内部如何表示知识的问题，却并没有解决人在开口的那一刻，用词是否落在本体所定义的语义边界之内的问题。本体工程是一套写给机器看的语义规范，却没有配套一套让人也能理解、遵守、内化的机制。

技术工程手段来提升企业AI效能的共同局限在于：它们都假设人的表达是给定的、可信的输入，然后集中精力优化AI如何处理这个输入，或者优化知识如何被结构化地表示。

但真正决定AI效能的，恰恰是这个被视为理所当然的前提——人的表达本身准不准确、用词本身能不能对齐到本体或知识库所定义的语义、能不能被AI以及被其他人一致地理解。

任何企业级信息技术应用，瓶颈都不是技术问题，而是人的问题——过去ERP系统是，今天企业AI仍然是。

二、从人理解机器到机器理解人

要理解这个瓶颈为何如此关键，需要回到人机交互范式的根本转变。

在传统信息系统时代，人机交互的语义主权掌握在机器一侧。程序员、需求分析师、UI设计师共同完成了一件事：把企业业务逻辑、管理概念、专业术语，编译成一套结构化、无歧义的形式语言——数据库字段、菜单层级、按钮标签、流程活动等。

用户要做的，是学习并适应这套机器语言。人在理解机器，机器的语义是权威的、固定的、不容协商的。这套模式代价高、周期长，但换来了语义的强制一致性——因为语义被锁死在结构里，歧义在设计阶段就已经被消除，人的表达能力如何并不重要，系统不会给人留下说错话的空间。

人适应机器的过程，就是我们过去实施ERP说的“变革管理”，也就是任正非、柳传志等老一代企业家在引进信息化管理时，说的“削足适履”、“先固化、再优化”等名言所蕴含的哲理。

以大语言模型为基础的企业AI则反转了这个方向——今天是机器在理解人，用户用自己习惯的自然语言表达意图，机器负责推测、补全、执行。

这一方面解放了用户的表达自由，同时把过去由系统结构承担的歧义消除、意思理解的责任，很大程度上转移给了说话的人。然而，绝大多数AI用户并未意识到这个责任已经转移到自己身上——人们仍然下意识地认为，只要模型足够强大，就应该能听懂自己想表达的意思，却很少反思自己的表达本身是否专业、符合惯例、机器应该听得懂。企业知识开源 ｜ 企业老板、大学教授、咨询顾问口中的“战略”，常不是一回事

下面这个有趣的视频虽然说的是用AI做视频，如果用AI来做财务、做供应链，同样会有这样对机器讲不清楚的困惑：

我能够观察到的现象是，目前企业AI行业的注意力普遍投向如何让AI更聪明或如何把企业知识结构化得更严谨——这些技术和工程的问题，而非如何让人说得更准、用得更准。

今天很多人在谈“企业AI带来的组织变革”，沿袭了过去三十年里管理数字化、组织数字化的思维惯性，将变革管理的重点放在工作方式和组织协作上，而今天企业AI对人真正的挑战，在于人类说话的知识体系和遣词造句能力上。

三、人的语言能力是企业AI的瓶颈

大语言模型的交付效能是模型能力和使用者能力的乘积。使用者对课题的认知深度，决定了他能否用精确的语言表达真实意图；使用者驾驭词汇的能力，决定了AI能在多大程度上摆脱猜测、直达业务本质。

在企业AI的各种场景中，组织管理、经营决策、流程执行等涉及多人同步或异步协作，语言的一致性就很重要；而且企业AI如果要形成产品级解决方案，可能还需要全社会的语言一致性。

如果各部门在与AI交互时，各自使用自己的方言式术语，例如“客户”究竟指销售接触过的外部机构、还是已经给我方下了订单的外部机构、还是我们财务开过发票的外部机构？在有些公司，甚至习惯把给我方供货的供应商也叫客户，在不同的组织或者不同的语境，同样一个词就会把AI搞糊涂。

本体定义了机器该如何理解和推理知识，但如果企业内部不存在一套配套机制，去训练和约束跨部门、跨角色的人，让他们说话用词能对齐到这套本体所定义的语义边界之内，那么本体也是不能发挥作用的。

四、企业知识开源的定位

要求全社会在全域统一语言使用，既不现实，也违背语言本身的多样性价值。

真正可行、也真正必要的，是局部共识：在特定的业务领域、特定的管理场景中，建立起受控、共享的词汇体系。这就是在特定范围内，人也能理解和遵循的公共语言规范，让参与同一套价值链的不同主体——企业内部各部门、外部咨询顾问、教育培训机构、企业软件供应商、业务流程外包服务商——能够在语义层面对齐，或者从某个企业AI解决方案供应商的角度，能够使得它的不同类型、不同组织的用户觉得他家的AI解决方案靠谱。

或者说，这是人和人之间能够达成企业知识的一致性认知的“人类本体”。

这正是"企业知识开源"的意义所在，它是参照开源软件的机制：

其一，标准化的知识资产可以脱离单一企业的边界自由流动。就像开源代码库让不同公司的工程师可以复用同一套函数库、遵循同一套接口规范，企业知识开源可以让本体所定义的核心概念——“客户、销售、供应链、流程、绩效”这些名词——连同其精确定义和相互关系，在教育培训、管理咨询、SaaS软件、BPO服务等不同环节中被共享和复用，而不是每一家机构、每一个人各自造一套话语体系，甚至为了自己的商业利益刻意制造隔阂。

其二，开源机制天然具备版本管理和协作演进的能力。企业知识、管理语言和本体定义都不是一成不变的，开源式的知识治理允许词汇表和本体随着实践共识的形成而版本化更新，任何环节的参与方都能追溯某个术语此刻的权威定义是什么。

其三，开源社区的同行评审机制，补上了大语言模型所缺失的结构化翻译层。传统模式下程序员和需求分析师承担了语义消歧的责任，本体工程师承接了这个责任在知识表示层面的延续，但这个角色如今需要进一步向外扩展——由行业协会、龙头企业、专业机构以类似开源治理的方式，把本体和受控词汇表一并开放出来，从根本上提升“人”这一端的表达精度，而不是持续加码AI端的工程投入去弥补人的表达缺陷。

一旦企业知识以开源方式流通，形成社会性的人类本体，“人”这一端的表达质量得到系统性提升，AI端的各种工程手段才能真正发挥应有的效力，而不是在治标不治本地做补偿：

• 模型训练/微调：模型可以基于受控词汇表和开源本体进行对齐与微调，减少因训练语料语义混杂而产生幻觉。

• 检索增强：企业在部署RAG系统时，可以直接锚定到开源的行业知识库、术语表和本体结构，为模型的语义空间划定边界——但这套边界能否发挥作用的前提，是提问者本身的用词与本体中的受控概念是对齐的。

• 本体应用：开源的本体如果同步配有面向业务人员的通俗释义、使用培训和真实场景案例，就能从只有知识工程师看得懂的技术图谱，转变为一线员工、外部顾问、合作伙伴都能理解和使用的共同语言地图。

• Prompt与Context工程：当使用者本身经过受控词汇表和本体概念的训练、具备清晰准确的表达能力时，Prompt Engineering 才能真正做用价值的优化，而不是承担猜测用户真实意图的任务；Context Engineering 构建的上下文也才能保证内部语义一致，而不是把多方歧义打包塞给模型，指望模型自己去消化矛盾。

基于以上这些想法，我才在第二届AIEC会上提出了建立一个面向业务人员和技术人员双方的表达范式——场景标记语言（Changjing Markup and Notation），用来实现本体、框架/上下文工程化的意思表达标准化，支持受控词汇表被广泛使用。

真正决定企业AI能走多远的，不是模型多聪明、本体多严谨，而是使用模型的人，能不能在一套共享、受控、经过训练的词汇和概念体系下，说出精确、一致、可被机器和同事共同理解的话。

工业时代的公共品是电力和道路，互联网时代的公共品是协议和标准，而大语言模型时代，受控的企业知识术语表、开源的企业知识本体，正在成为保障AI有效性的新型公共品，也是唯一能够从根本上解决“人”这一端瓶颈的路径。这就是我在三年前大模型刚兴起时，看到企业知识开源的价值。