分久必合:从软件史,看Software3.0

1979 年 ，VisiCal 作为第一款表格 应用，作为 Apple II 搭配的杀手级应用出现 ，982年 ，微软接受 Apple 委托开发了第一个版本的 Excel（早于 Windows)，拉开序幕：

2005年，进入职场第一个项目，是一个汽车国企驻场ERP的实施（今天的 Title 就是 FDE），至今记忆犹新的，除了定福庄的中传食堂 ，便是会计主管的Excel表；巨大的公式+加行云流水的快捷键微操 ，差不多定义了，我后来 20 年我从来没见过的灵活与优雅的高度 ；  因为可以几乎看到任何你想要的数据， 只依赖于一位优秀的会计。 

2025年5月，Boris Cherny, Claude Code的作者在Sequoia的一场炉边谈话提到：  接下来的软件发行，应该跟发短信一样简单， 而这件事已经实现了。 Boris 继续说，制作财务软件最适合的人员，不会是工程师，而是一位非常优秀的会计。   

是的 ，又回到优秀的会计 。

这期间的40年，无论塞贝斯、.NET古董，还是SaaS，基本上可以是集 “难用/笨拙/不符合业务” 大成。需求谈必称 费用与排期； 这种拙劣，基本上就是工业化的思想的延续。  

它把原先的的一门手艺/一种整体性的认知 ，被“精确的幻觉”分隔，被专业主义撕裂； 这么一路下来； 再然后再用数据中台/DDD 去模拟，去找补，然后成就了 snowflake、Databricks

也就是说软件发展史， 也基本上一种以“知识分(类)” 为哲学底色的实践历史； 我这一路黑，不是对软件历史的否定，而是我们需要保留 对这种“”天生“”的缺陷，持有一直自知；

而整个过程中，Excel 就像一朵优雅的小花，一直无比倔强的绽放 。

一Excel合

Excel 的天才在于把三件事压进了同一个格子 —— 数据是单元格的值，计算是=SUM(A1:A10)公式，渲染就是网格本身。

三件事压在同一个格子里 —— 这是 Excel 的天才，也是它的极限。

任何人都能在 Excel 里”写软件”，因为他不用搞抽象 —— 数据、逻辑、视图都在眼前同一格里。这种直觉，是优秀会计友好的

但优雅的代价也很直接：一千人协同的公司没办法跑在一张 sheet 上。Excel 是小尺度的优雅。它能告诉我们在「整体/合」的状态下软件可以多直接、多贴近，但它不能承担一个组织

二SAP / Salesforce分

要承载一千人协作，在有限计算资源下，当然是拆分，无论是领域的，还是层次上。  就是横竖各切三刀 ；  Excel 那种三合一的格子被拆成三件事 —— [1]数据：需要有严格的schema-first 的关系表，[2]流程与编排对应触发器、Flow、ABAP…，[3] 交互层对应表单、报表。 然后在一层 更大的抽象中运行。

代价是 Excel 那种贴近性 彻底消失了：业务用户想改一个字段，得走 IT 流程；跨层一致性靠文档和流程掌控；只要业务一变，schema 就得跟着改，上层全部连带波及。 

从 1980 年代的 ERP 到 2010 年代的 SaaS，整整 40 年的工业化，骨子里都是同一个范式 —— schema 在底下做地基，应用在它之上，愈发复杂，直至难以驾驭。

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

三Palantir整 合

到这里 , 很多人会以为 Palantir 带着 Ontology 「新范式」出现。 仔细看，它仍然在「分」的延续 —— 今我们谈论的 Ontology/Action 层、是在SSOT与业务之间媒介层。注SSOT：Single Source of Truth（单一数据来源，事实层）

Palantir 的价值是两件事叠加在一起：[1] 用整合的思想，过去散落的能力打包成一个产品；[2]  使用高密度的咨询服务，让这个产品同时能给人用、给 AI 用。看清这两层，就看清了 Palantir。  也就这两件事 ，相对于他的客户 ：国防部、军工复合体和欧洲大企业（被掏空的那些） ，这些被官僚侵蚀的到绝望的机构来说，简直是 春风拂面。

① Ontology 产品层 —将打散的层次统一到一个交互

Ontology 不是全新的创造，数据中台、Semantic Web、BPM、DDD —— 这些过去分散在各自学派，各个企业内，现在 被拼成了一个简洁、统一、可部署的产品接口 = 可用

另一方面， Ontology 回到 C 位， 是正视了一件长期被忽视的基本事实： ——软件应该承认组织有多重业务现实（解读)—— 并通过 SDK\权限模型\审计 ，把它做成了可部署的产品变的可用。

打个比方：SAP / Salesforce 是把照片洗出来挂墙上 —— 想换角度，要重新拍。Palantir 是保留原始底片 —— 想换角度，从底片重新冲一张，老的还挂着。

② 执行层 —— 人和 AI 都在产品化层上工作

除了 Ontology 的产品哲学；  把客户那一团混乱的业务真正映射到 ontology 上，仍然要一支会用这套产品的人。这一层现在有两个角色：

AI FDE 在 2025 年 11 月落到这一层，并不算意外。LLM 2025 年的 SOTA 足以应付  处于封闭的业务空间中， —— 关键是Ontology 产品化层早就把一个干净、类型化的 playground 准备在那儿了。Agent 进来的时候，它操作的是typed Customer、typed Vehicle、typed Subscription，一个有边界、有类型的环境。就是今天我们所说的 Harness Engineering 的组织化表达

第一层造了 playground，第二层才能让 AI 进得去。Ontology 既是给客户的产品，也是给 AI 准备的施工现场 —— Palantir 第二个被低估的贡献。

两层合起来 = 工程+人的整合

下层是 Palantir 真正卖的 [技术产品]；上层是客户用得起来的[服务产品]。两者捆绑成一个整体卖出去 —— 客户拿到的不是一组零件，是”问题被搞定”这件事挑战本身。

Palantir 走完了「分」这条路上的最后一步 —— 在产品化层把分散能力整合成简洁接口，在执行层让人和 AI 一起把客户落地。这是”整合”，但也仍是过渡。

四AI-Generated Software合 2.0

如果「分 → 工程整合」是过渡，那么回到开始 Boris 所说的，像发短信一样 生产与分发，  像使用 Excel 一样自由创作， 我们先假设：

当DataSet、 Ontology、业务编排、交互层都可以由 Agent 即兴生成—— 三层不再需要工程团队去拼接，它们在 runtime 自然合成。

下面这张图把 60 年压成一条曲线：从整合（Excel）一路下到分（SAP/SalesForce），然后向上爬升 —— Palantir 用工程把”分”重新拼成”整合”，AI-Native 用 runtime 回到 “整合 “。 Palantir 用工程化做的事，AI-Native 用 runtime 做。其所依赖的 重投入、高人才密度的整合，未来会多大程度被 Agent 给民主化。

五回到“整合” —— Agent渗透与现实

在Andrej Karpathy 把软件分成三代 —— 1.0 是显式写规则，2.0 是用神经网络，3.0 是在上下文窗口里写 prompt。从给机器写代码，到给机器喂数据，到给机器讲意图。 

原话是 “programming turns to prompting”  ——Agent 作为一种新的交互入口，它接过了当年 Excel 单元格的角色。

回到 Excel 的天才。一个单元格把三层压在一起 —— “值”是事实，”公式”是方法共识，网格是业务消费。用户绕开抽象，一次写入就同时落到三层。

Agent 期待一句话、一次对话 —— 用户重新只面对一个入口；事实层、共识层、消费层在 runtime 由 Agent 即兴合成。

Excel 是三件事压进一格；AI-Generated Software 是三层压进一次对话。

合 → 分 → 合，看似回到原点，其实是螺旋上升。每一圈都换个尺度回来 —— Excel 的现实尺度是一张表，Agent 的期待的尺度是一个组织，甚至行业， 本质上是软件地基的渗透

但事情真的这么顺利吗？

ChatGPT、Claude Code 这些个人侧的 AI 能力的快速渗透，「Local Software」的概念也跟着热起来 —— 一个人不再依赖 SaaS，就能即兴生成自己要用的工具。

B 端却慢得多。一个组织把 Agent 接进财务、HR、CRM ，迟迟未动 ，模型早就 Ready，落地却卡得严严实实。

差别不在算力，不在模型能力， B 端软件的核心是业务共识达。

同一笔交易：

• 财务说：这是”递延收入”
• 销售说：这是”业绩提成”
• 运营说：这是”库存承诺”

三句话同时对，只是视角不同，同一份数据，在不同部门，不同场景，不同时点，更重要的是不同动机， 需要被当做不同的Ontology被调用； ontology 的确立——是组织对意义的确认， 因此它必须是动态的， 也必须是协议的，是一群人对意义的协议。在公司内，不同的场景，对共识的认定 有不一样的强度，

• 硬共识
  
  来自监管 / 行业 / 法律。改不了，AI 必须遵循
• 软共识
  
  组织内部协作，AI可以提议，但要协商。
• 无需共识
  
   个人 / 一次性，AI可以创作，与决定

两个维度，一张分布

如果把共识强度是一条横轴，软件构建的层次，作为纵轴 —— [1]数据层（或SSOT）、[2]共识层（Ontology/BPM）、[3]消费层（UX/UI）。把两条轴叠起来，Agent 自由度并不是单调递减，而是落在一个对角分布上：

• 左上角
  
  （消费层 × 无需共识）：Agent 完全即兴。ChatGPT / Claude / Cursor 已经在这里。这是个人软件能一夜起飞的原因。
• 对角线中段
  
  （软共识各层）：提议 → 采纳 / 写 · 留痕。Agent 可以动手，但要人或组织拍板。这是 B 端落地的真正主战场，也是它慢的原因。
• 右下角
  
  （事实层 × 硬共识）：完全锁定。财务底层、监管账目，AI 不该碰，也碰不动。

Software 3.0 应该不会是”软件全面 AI 化”，而是有梯度的渗透 —— 共识越轻的角落渗得越彻底，共识越硬的传统方法越有空间。Agent 不会替代 数据和流程，但会重塑 数据之上的所有层。

六软件从名词 成为 动词

像短信一样，如果足够简单 ，就会从名词 成为动词。   当通过对话，就能让三层 ，即时合成出一个此刻可用的应用，软件就不再是”物”，更像”事件”。 固化下来的”物（有形部分）”  只剩硬共识那一小块—- 持续支持无数次的临时“姿态”。

这个形态不确定，我姑且称呼为 AI Generated Software；或者是 AK 的 Software3.0  它的核心很可能是一份完整/可靠/可迭代 共识描述 或者；但它的护城河肯定不是功能 。

把开篇 Excel 的那张图，在3.0 场景下里重画一次 ——

和 Excel 一样，三层依旧压在一处。但中间多了关键的一段。「ESG」在不同客户、不同组合里定义不同 —— Agent 把一句模糊的「PLTR 在 ESG 组合里…」先对齐到这个客户和这只组合的 Ontology（持仓 PLTR、客户偏好「反战」、组合 mandate「ESG-主动」、PLTR 标签「战争倾向」），再合成出具体动作 —— 「剔除」。这一步对齐就是软共识在 runtime 的归位，是 Software 3.0 与「让大模型动态写 HTML」的本质区别。

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

#全文由 Huozi.app 起草，并且创作插图，人类编辑修改