.md 编译了个人认知，什么来编译企业的认知？

春节期间，我干了件跟公司业务无关的事——给自己写了一个 OpenClaw Skill。

起因是团队里一个产品经理分享了他的 Skill 合集：一个帮他写周报的，一个帮他做竞品监控的，还有一个帮他自动整理需求反馈并归类优先级。我试了一下，确实好用，然后手痒了。

我花了大概四十分钟，写了一个帮我准备客户拜访的 Skill。逻辑不复杂：输入客户名称和拜访目标，它会帮我整理这个客户的行业背景、竞争情况、现在数据架构现状、上次沟通纪要里的遗留问题、销售拜访记录，然后生成一份一页纸的拜访准备材料。这套流程以前我在飞机上用脑子做，每次大概半小时；现在 Agent 三分钟就能给我一份 90 分的底稿。

写完之后我有一个很强烈的感受——这不就是把我脑子里的工作方法“编译”了一下吗？

一个 .md 文件，几百字自然语言，没有代码，没有模型训练。但它把“我怎么准备客户拜访”这个原本只在我脑子里的隐性流程，变成了机器可执行的显性指令。

然后一个念头冒了出来，让我兴奋了好几天——这不正是我们过去四年在企业数据领域做的事么！

只不过，个人认知的编译用 .md 就够了；企业认知的编译，需要的东西要大得多。

人人都在编译自己，但企业还没有

先看个人这边发生了什么。

OpenClaw 去年 11 月上线，三个月 GitHub 超 23 万 star，社区贡献了 5700 多个 Skill，精选市场 ClawHub 收录了 2800 多个。Claude Code 的 CLAUDE.md 让项目记忆自我进化，团队知识通过 Git 版本管理协作共享。

所有人都在做同一件事：把自己脑子里的经验、判断、流程，写成 .md 文件，交给 Agent 执行。

一个运营写了个 Skill 来做活动复盘，一个投资人写了个 Skill 来筛选项目，一个产品经理写了个 Skill 来拆解需求——以前这些东西叫“个人方法论”，现在它们有了一个新的存在形态：可执行的认知资产。

知识的载体正在从“人脑”迁移到“协议”。这件事的意义怎么高估都不过分。

但如果你做企业服务，你马上会想到下一个问题：个人认知可以用一个 .md 编译，企业认知呢？

一家零售企业有几千个业务指标，散落在十几个系统里。“GMV”在市场部、产品部、财务部的定义各不相同。“退货率”的计算逻辑随业务变化每年都在调整。这些不是一个人的方法论——这是整个组织用十年积累起来的经营认知，涉及几百人的共识、几十个系统的数据、无数次业务决策的沉淀。

你不可能用一个 .md 文件搞定它。

编译个人认知，需要的是 Skill；编译企业认知，需要的是一整套语义基础设施。

这就是我四年前从蚂蚁出来创业时就做的事，撞上了 Agent 这波浪。

2026 年 1 月 27 日，行业给了答案

那时候跟投资人讲“我们要做数据语义层”，对方最常见的反应是礼貌的困惑——“语义层是什么？为什么需要一个独立的语义层？”

说实话，前几年最难的不是做产品，而是解释这件事为什么重要。指标平台、语义层、NoETL……这些词在当时的市场认知里，约等于“又一个数据中间件”。

然后，2026 年 1 月 27 日，Open Semantic Interchange（OSI）v1.0 规范在 GitHub 正式发布（github.com/open-semantic-interchange/OSI）。

Snowflake、Databricks、Salesforce、dbt Labs、AtScale、Qlik、JetBrains——几十家全球数据技术公司联合推动了一个标准：让企业对数据的“理解”，第一次有了跨平台、跨系统的交换格式。

简单说，SQL 标准化了“怎么取数”——不管你用 Oracle 还是 MySQL，SELECT * FROM 的语法一样。OSI 要标准化的是“数据是什么意思”——不管你用 Tableau 还是 Power BI，“净收入”的定义、计算逻辑、适用范围，应该是同一套东西。

当 Snowflake 和 Databricks 这两个平时打得不可开交的对手，愿意坐下来联合定义语义交换标准的时候，说明一件事已经从“要不要做”变成了“怎么做”。

OSI 替所有做语义层的人回答了那个最难回答的问题：为什么需要它。

我在办公室看到这个消息的时候，内心是复杂的。一方面觉得“终于”——四年了，行业共识终于到了；另一方面也很清醒——标准发布只是起点，真正的挑战在后面。

光有“定义”没有“执行”，等于光有语法没有编译器

如果你仔细看 OSI v1.0 的规范，你会发现它解决的是“定义”问题——用一种统一格式描述指标、维度、关系和上下文，让不同系统可以互相理解对方的语义。

但光有定义是不够的。

打个比方：OpenClaw Skill 写得再漂亮，如果没有 Agent 来跑它，它就只是一个文本文件。OSI 也一样——企业把所有指标按标准格式定义好了，然后呢？谁来把定义翻译成精确的 SQL？谁来决定上亿条数据的查询里哪些该预计算、哪些该实时算？谁来保证返回的结果既准又快？

定义是协议的前半段，执行是协议的后半段。有了语法还不够，你需要编译器。

这正是我们过去四年扎进去做的事。Aloudata CAN 的核心能力不只是定义指标，而是把语义定义“编译”成可执行的数据服务——自动生成 SQL、智能路由查询路径、按需物化加速。我们内部把这个能力叫 Semantic Fabric（语义编织）。在数据 Agent 的架构里，它的角色类似 Supabase 之于 Lovable——前端用自然语言“定义”意图，后端需要强大的引擎来“执行”它。

关于这些技术细节，我在之前的文章里讲过 NL2Semantic2SQL 的路径和 Trusted AI 的框架，今天不再展开。

我更想讲的，是把视野拉远之后看到的东西。

从 Skill 到 OSI：认知正在变成可互操作的资产

往后退一步看，OpenClaw Skill、Claude Code 的 CLAUDE.md、OSI 语义标准——这三件看似不相关的事，底层逻辑完全一致：

把人类的隐性认知，转化为机器可执行的显性协议。

Skill 编译的是个人认知——“我怎么做竞品分析”变成了 .md 文件。

OSI 编译的是组织认知——“我们公司的净收入怎么算”变成了标准语义格式。

Aloudata 提出的 NoETL 语义编织是认知的执行层——让这些协议不只是“被理解”，而是“被算出来”。

粒度不同，载体不同，但本质一模一样。

如果这个趋势继续演进下去，我看到了三件正在发生的事：

第一，企业的“认知密度”将变得可测量。多少业务概念被结构化定义了？多少决策逻辑可以被 Agent 执行？这个比例越高，AI 的赋能杠杆越大。我们在客户那里已经看到了这种效果——100 个原子指标定义配合语义层的动态组合能力，可以结合 300 个维度覆盖企业 90% 以上的分析场景，传统方式需要为每个场景单独建一张宽表。这不是效率提升，是范式变化。

第二，数据基础设施正在被重新定价。过去二十年，数据中台 + BI 是服务人类分析师的数据套件，这个组合催生了一个千亿级的全球市场。现在，Agent 正在成为新的数据消费者——而且是一个永不下班、可以并行处理成百上千个分析任务的消费者。Agent 需要的数据套件——可执行的语义层——其市场规模和战略位置，大概率会超过服务人类的那一套。道理很简单：人类分析师的数量和产出有上限，Agent 没有。

第三，也是我认为最重要的——个人认知和组织认知最终会融合。 一个分析师的 Skill 里包含了他个人的看数经验；企业的 OSI 语义定义里包含了组织的指标共识。当这两层在 Agent 里打通，它既懂标准定义又懂个人偏好——这才接近一个真正的“数字同事”，而不是一个只会写 SQL 的工具。

想想看：你的企业知识库告诉 Agent “净收入”怎么算；你的个人 Skill 告诉 Agent “老板关心的是净收入的区域结构变化”。两层叠加，Agent 给你的不是一个冷冰冰的数字，而是一个带判断的洞察。

这才是“AI 用好企业数据”的终局画面。

尾声：让认知像代码一样流动

春节那个写 Skill 的晚上，我把那个客户拜访准备的 Skill 分享到了公司群里。CTO 回了一句：“这不就是低配版的 Aloudata CAN 吗？一个人的、非结构化的、没有执行引擎的。”

大家笑了一阵。但我觉得他说到了点子上。

.md 编译个人认知，语义层编译企业认知——这两件事之间，不是类比关系，是同一件事的不同尺度。OpenClaw 让每个人都体会到了“认知可以被编译”的兴奋感；OSI 和语义层要做的，是把这种兴奋感带到企业级。

在蚂蚁的时候，我们喊的口号是“让数据像水一样流动”，让每个念头都能被数据灌溉。现在我觉得这句话应该更新一下：

让认知像代码一样流动。

个人的认知，已经在流动了。

企业的认知，刚刚开始。

关于 OSI 标准的技术细节、全球厂商的语义层布局，以及“定义之后如何执行”的问题，我会在下一篇《从 SQL 到 OSI》中展开——那是一段跨越四十年的标准化故事，也藏着 AI 时代数据基础设施的下一个关键变量。