从 Excel 到 SSOT

Excel 的天才，在于把三件事压进了同一个格子。数据是单元格的值，计算是 =SUM(A1:A10) 这样的公式，显示结果的界面，就是网格本身。

任何人都能在 Excel 里“写软件”，因为他不用先搞清那些抽象层。数据、逻辑、视图都在眼前。改一个值，看一下结果；发现公式不对，直接改公式。知道业务该怎么算，也就知道这张表该怎么做。这种直觉，对优秀的会计很友好。

那位会计主管的手艺，也正在这里。他对业务的理解和手里的工具没有分开。哪些数该合在一起，哪些要单独处理，计算到哪一步需要回头核对，都能直接落实在表里，不必先变成一份交给别人的需求文档。

但优雅的代价也很直接：一千人协同的公司，没办法只靠一张 sheet 运行。同一份表发给几个部门，各改一遍，再收回来，光是确认哪份有效，就已经是另一种工作。公式可以算得很漂亮，却不会自动解决谁有权改、改完谁负责的问题。

Excel 是小尺度的优雅。它让我们看到，在整体没有被拆开的时候，软件可以多直接、多贴近业务；但把这个尺度放大到一个组织，还需要解决另一批问题。

要承载一千人协作，在有限的计算资源下，很自然的办法就是拆分。按业务领域拆，再按技术层次拆。横竖各切几刀，每一块都交给专门的人处理。

Excel 那种三合一的格子，被拆成了几件事。数据进入关系表，先定义字段、类型、关联，也就是 schema；流程与编排进入触发器、Flow、ABAP 等工具和程序；交互层则留下表单、报表。各个产品实现不同，但业务用户面对的，已经是这几层重新组装出来的结果。

代价是 Excel 那种贴近性消失了。业务用户想改一个字段，要走 IT 流程。听起来只是加一列，接下来却得确定：它存在哪里，由谁维护，哪些页面显示，旧报表要不要跟着改。跨层的一致性，靠文档和流程维持。业务一变，底下的数据结构可能要改，上面的规则、页面也跟着受影响。

每个环节单独看，都有充分的理由。不能让所有人随手改生产数据，也不能让每个部门各写一套程序。可这些理由加在一起，业务人员就越来越难直接修改自己的工具。最后，那个最清楚事情该怎么做的人，只能等排期。

从 ERP 到 SaaS，企业软件变得越来越丰富，背后的分工方式却相当熟悉：数据结构在底下做地基，应用建在它之上，再加一层、再接一个系统，直到很难有人能把全貌说清楚。

而江湖上的手艺人，也越来越少了。

到这里，很多人会以为 Palantir 带着 Ontology 这个新范式出现了。仔细看，它仍然延续着“分”的结构。今天谈论的 Ontology 和 Action 层，是 SSOT 与具体业务之间的媒介：底下是事实，上面是如何理解这些事实、如何据此采取行动。

SSOT 是 Single Source of Truth，在这里指共同认可的事实来源。Ontology 则把客户、订单、车辆这些业务对象，以及它们之间的关系、能执行的动作，明确地描述出来。

Palantir 的价值，我认为是两件事叠加在一起：用整合的思想，把过去散落的能力做成一个产品；再用高密度的实施和咨询服务，让这个产品真正能给人用、给 AI 用。对那些长期被复杂流程和官僚作风困住的机构而言，能有人把这一团业务落到可运行的系统里，已经是春风拂面。

① 产品层：把散落的能力接起来

数据接入、语义建模、业务流程，都有很长的历史。数据中台、Semantic Web、BPM、DDD，各自解决过其中一部分问题。Ontology 的产品价值，是把原先散落在不同学派、不同系统里的东西，组装成一个相对统一、可以部署的接口。

比如看一个订单，使用者可以沿着关系找到客户和交付，也可以在允许的范围内执行更新。数据查询、业务理解、动作执行，终于能围绕同一个对象工作。前面提到的那些技术，不必再由客户一件一件自行拼装。

另一方面，Ontology 回到中心，也是在正视一件长期被忽视的事：软件应该承认，组织对同一份事实存在多重业务解读。财务、销售、运营各有各的工作，不能因为系统只做了一种表单，就要求所有人用同一种方式理解业务。

打个比方：把一种业务理解固定在系统里，像把照片洗出来挂在墙上，想换角度，要重新拍。保留事实、允许不同的业务解释，则像保留原始底片，想换角度，可以重新冲一张，老的还挂着。

② 执行层：有人把客户的业务放进去

产品有了，客户那一团混乱的业务，还得有人弄明白。哪个系统里的客户才算客户？同名的两家公司是不是同一个主体？订单到了哪一步可以取消？这些问题，光看一张数据表是回答不了的。

这就是 FDE 团队的工作。FDE 通常译作前线部署工程师，他们在现场陪客户把业务落实到 Ontology 上。产品层提供工具，实施的人要把具体公司的规则、例外和责任关系整理进去。2005 年那种驻场实施的工作，并没有因为工具变新就消失。

AI FDE 进入这一层，并不意外。产品层已经把一个类型明确、有边界的工作环境准备在那里了。Agent 面对的可以是定义清楚的 Customer、Vehicle、Subscription，也就是客户、车辆、订阅对象；可以调用的动作、需要的参数和权限，也都有据可查。它能直接在这套环境里写函数、改流程、操作对象。

今天常说 Harness Engineering，也就是围绕模型准备工具、上下文、约束和检查方法。放到组织里看，Ontology 做的这部分工作，恰好就在为人和 Agent 准备同一处施工现场。

两层合起来，才是工程与人的整合。下层是技术产品，上层是让客户用起来的服务。客户要解决自己的问题，一组零件显然不够。

Palantir 沿着“分”这条路，把分散的能力重新整理成统一接口，再让人和 AI 一起完成实施。这种整合很有价值，但在我看来，它仍然是一个过渡。它所依赖的重投入、高人才密度的工作，未来有多少能由 Agent 承担？这是接下来更有意思的部分。

回到开头 Boris 说的，像发短信一样生产与分发软件，像使用 Excel 一样自由创作。我们先作一个假设：当数据集、Ontology、业务编排、交互界面，都能由 Agent 按照眼前的任务组合，会发生什么？

用户说清楚要做什么，Agent 找到相关数据，调用已有的业务规则，生成当下需要的界面。原先由工程团队分头开发、再拼起来的几层工作，可以在使用时一起完成。这里的 runtime，指的就是这种运行时的组合。

例如，临时要查一批订单为什么没能按时交付，可能只需要把订单、库存和交付记录放在一处，按当前问题组织成一张表。以前，这个需求容易变成一个新的报表项目；在这个假设里，它可以在一次对话里形成。用完之后，未必需要把这张页面永久加进菜单。

Excel 把三件事压进一格；AI-Generated Software 期待把几层工作合进一次对话。用户重新只面对一个入口，也重新有机会亲手决定工具该怎么用。

这条曲线画的是我理解的软件分合：Excel 在一张表里完成整合，企业软件为了承担组织协作而拆分，Palantir 用工程把它们重新接起来，AI 则让运行时的组合成为一种可能。

回来的尺度已经变了。Excel 的尺度是一张表，Agent 所期待的尺度，可以是个人、临时任务，也可以是一个组织。这里面最难的那部分，正藏在“一个组织”这几个字里。

Andrej Karpathy 把软件分成三代：1.0 显式编写规则，2.0 通过训练神经网络形成能力，3.0 则在上下文里用自然语言描述意图。从给机器写代码，到给机器喂数据，再到给机器讲清楚要做什么。

沿着这条思路，Agent 接过了当年 Excel 单元格的一部分角色。值是事实，公式是计算方法，网格供业务人员使用。一次对话，也在尝试让用户同时触及这几层，不必逐一处理背后的抽象。

但事情真能这么顺利吗？

个人侧已经很容易试起来了。用 ChatGPT、Claude Code 给自己做个工具，只要自己觉得可用，就可以继续。一个人不必等一家 SaaS 公司排期，便能生成眼前需要的软件。

到了组织里，情况就变了。财务、HR、CRM 都有人想接入 Agent，也都有能演示的功能，但演示结束之后，谁来决定规则、谁承担结果，往往还没有谈清楚。把这些问题全归到模型能力上，恐怕看错了地方。B 端软件很大一部分工作，是让一群人对业务达成共识。

看同一笔交易。财务要判断其中哪些属于递延收入，销售要算业绩提成，运营要确认库存和交付承诺。三种说法可以同时成立。它们引用的是同一笔交易，回答的却是各自工作里的问题。

同一份数据，在不同部门、不同场景、不同时点，甚至出于不同动机，需要被放进不同的业务解释里。Ontology 的确立，就是组织对这些含义的确认。因此它必须能够变化，也必须是一种约定：一群人同意，在这个场景下，这个对象按这套含义和规则使用。

比如销售决定用签约额看业绩，财务仍然可能按履约进度确认收入。只要各自的依据和用途说得清，两种口径完全可以并存。真正麻烦的是，两边都把结果叫作收入，却没有告诉接着使用这些数字的人，它们分别怎么算出来的。

SSOT 要让大家找得到共同的事实来源。订单是哪一笔、合同用的是哪个版本、钱是否到账，这些需要对得上。在此之上，业务解释可以不同。把数据全搬进同一个数据库，并不会自动让几种口径达成一致。

公司内部对共识的要求，也有轻重。来自法律、监管和行业规则的要求，可以称为硬共识，AI 必须遵循，不能凭一次对话改掉。部门之间商定的提成办法、协作流程，是软共识，AI 可以提方案，但要协商。只给自己用的临时计算和页面，通常就不需要别人来拍板。

把共识强度放在横轴，把数据、业务含义与流程、界面这几层放在纵轴，就能看见不同位置上的差别。个人界面可以相当自由地生成；涉及团队规则，Agent 可以试算、比较方案，最后由负责人采纳；涉及正式记录，就要按既定的权限和变更流程处理。

中间那一大片软共识，才是组织里最费工夫的地方。提成规则改了，有人受益，也有人吃亏。客户归属重新划分，会影响几支团队的业绩。Agent 可以把计算做完，却没有资格替这些人宣布谈妥了。

Software 3.0 在组织里的进入方式，大概也会有这样的梯度。共识轻的地方，变化快；共识重的地方，传统系统和既定流程仍然有用。我们谈 AI 如何落地，应该具体看看它要改哪一层、影响哪些人，而不是只问它能不能生成一个应用。

如果足够简单，像发短信一样，软件就可能从名词成为动词。

通过对话，几层工作即时合成一个此刻可用的应用。这个应用更像一次发生的事情：为了眼前的问题出现，处理完以后，也许就不再打开了。留下来的那部分，是下一次仍然要用的事实和约定。

这个形态还不确定，我姑且称它为 AI-Generated Software，也可以放在 Karpathy 的 Software 3.0 里讨论。它的核心，很可能是一份完整、可靠、能够迭代的业务共识描述。但它的护城河，肯定不是功能。

把开篇 Excel 的图放到这个场景里重画一次，中间会多出关键的一段：Agent 得先弄清楚，此刻这些词是什么意思。

举一个假设的例子：一位客户明确反战，持有一个按 ESG 约定管理的组合，组合中有 PLTR。客户问，这笔持仓是否符合自己的要求？

光看到 ESG 这三个字，Agent 无法得出结论。它需要找到这个客户的偏好、这只组合的管理约定，以及在这个约定下怎样看待相关业务。如果该组合采用的分类把有关业务认定为与客户反战要求冲突，才有依据提出剔除建议。换一个客户、换一套组合约定，结论可能就不同。这里是在举例说明业务含义如何对齐，并非给股票下一个通用标签。

这一步，就是软共识在运行时落实到具体任务上。客户口中的符合要求，必须找到对应的约定，后面的数据查询、界面和动作才知道该怎么办。至于建议是否执行，还要交给有权决定的人，按实际业务流程处理。

让模型写出一张动态页面，已经可以做得很好。但页面上为什么是这个结果，依据的是谁的约定，才决定它能不能在组织里使用。原先留在一位优秀会计头脑和公式里的理解，走到这个尺度上，需要能被其他人、也被 Agent 找到和使用。

最终，一个念头，替代一个格子，就像发短信一样。