.md 编译了个人认知,什么来编译企业的认知?

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

作者:周卫林,Aloudata 创始人 & CEO

春节期间,我干了件跟公司业务无关的事——给自己写了一个 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 时代数据基础设施的下一个关键变量。

相关文章
|
25天前
|
数据采集 供应链 物联网
别再只会调用 API 了:一步步教你用 Python Fine-Tune 一个定制化大模型
别再只会调用 API 了:一步步教你用 Python Fine-Tune 一个定制化大模型
218 3
|
22天前
|
自然语言处理 调度 语音技术
一行 Python,三种世界:聊聊文本 + 图像 + 音频的多模态协同生成
一行 Python,三种世界:聊聊文本 + 图像 + 音频的多模态协同生成
122 4
|
2月前
|
人工智能 应用服务中间件 API
刚刚,阿里云上线Clawdbot全套云服务!
阿里云上线Moltbot(原Clawdbot)全套云服务,支持轻量服务器/无影云电脑一键部署,可调用百炼平台百余款千问模型,打通iMessage与钉钉消息通道,打造开箱即用的AI智能体助手。
5663 61
刚刚,阿里云上线Clawdbot全套云服务!
|
3月前
|
机器学习/深度学习 缓存 物联网
打造社交APP人物动漫化:通义万相wan2.x训练优化指南
本项目基于通义万相AIGC模型,为社交APP打造“真人变身跳舞动漫仙女”特效视频生成功能。通过LoRA微调与全量训练结合,并引入Sage Attention、TeaCache、xDIT并行等优化技术,实现高质量、高效率的动漫风格视频生成,兼顾视觉效果与落地成本,最终优选性价比最高的wan2.1 lora模型用于生产部署。(239字)
1351 103
|
11天前
|
人工智能 安全 程序员
50%的人给了差评:龙虾为何在技术论坛翻车了?
OpenClaw(龙虾)AI工具因“自动赚钱”“代约主播”等夸张宣传走红,但吾爱破解论坛投票显示:50%技术用户未下载且不认可其能力。技术圈冷静源于见惯“神器”泡沫——AI擅写代码(搬砖),却难懂需求、统筹系统。它不是神药,而是待磨的砍柴刀。
150 3
50%的人给了差评:龙虾为何在技术论坛翻车了?
|
25天前
|
缓存 运维 监控
从踩坑到高效落地:淘宝天猫商品详情API的实操心得
本文分享淘宝天猫商品详情API从踩坑到高效落地的实战经验,涵盖准入权限避坑、签名与调用规范、异常处理、缓存优化、批量调度及监控运维等关键环节,助开发者快速稳定接入,提升开发效率与系统稳定性。(239字)
|
12天前
|
SQL 数据采集 人工智能
别把数据中台做成“数据坟场”:聊聊企业数据中台架构的真实落地之路
别把数据中台做成“数据坟场”:聊聊企业数据中台架构的真实落地之路
109 4
|
21天前
|
人工智能 安全 数据可视化
GitNexus:GitHub一周暴涨6000星!这个"零服务器代码神器"让AI终于能看懂你的代码了
GitNexus是GitHub一周暴涨6000星的「零服务器代码智能引擎」,纯浏览器/本地运行,用Tree-sitter构建交互式知识图谱,让AI真正看懂代码依赖、调用与架构,支持TS/Python/Java等10+语言及Cursor/Claude等MCP工具,隐私安全,重构无忧。(239字)
644 4
|
3月前
|
存储 自然语言处理 测试技术
一行代码,让 Elasticsearch 集群瞬间雪崩——5000W 数据压测下的性能避坑全攻略
本文深入剖析 Elasticsearch 中模糊查询的三大陷阱及性能优化方案。通过5000 万级数据量下做了高压测试,用真实数据复刻事故现场,助力开发者规避“查询雪崩”,为您的业务保驾护航。
1698 89
|
1月前
|
机器学习/深度学习 数据采集 人工智能
OpAgent:登顶WebArena的多模态Web GUI Agent
蚂蚁集团自研多模态Web智能体OpAgent,以71.6%的成功率登顶WebArena榜单。该方案通过层次化多任务微调构建基座,利用在线强化学习与混合奖励机制应对环境动态性,并结合模块化架构实现复杂任务的稳健执行与自我修正,刷新了Web智能体领域的SOTA纪录。
185 11