AI 编程之后，软件会像 Excel 一样通用：不再有版本更新

1979 年，有公司会为了跑一个软件，去买一台几千美元的 Apple II。那个软件不是操作系统，是一张表格。四十多年后，Gerald Maria Dekkers 在 2026-10-23 那篇《Future software will be generalist.》里给出的判断是：下一个十年的软件会长回那个样子——像 Excel 一样通用，而且不再有版本更新。

他的论证不从代码开始，从一块石头开始。

一、5000 年前的泥板：人类最早的通用"软件"

图 1：原文取自牛津 Ashmolean 博物馆 Facebook 页面的泥板照片。上面刻的是：一个农民收上来的谷物，怎么在领主、领主的妻子、祭司和当时的官僚体系之间分配。

作者说这块泥板大概有 5000 年。它做的事情，是制表（tabulation）——而制表出现在文字之前。

在他看来这是双重意义上的分水岭。第一，它把飘忽、不可信的人脑记忆固化到石头上；记忆一旦固化，就能被可靠、客观地拿去和另一份同样固化的记忆比较。第二，也因为它是通用的：这套方法几乎能用在任何东西上。

顺带一句我们自己的观察：那块泥板同时是一张权力结构图——份额给谁、给多少，本身就是组织关系。数据从来不是中性的，它先决定谁被记录、谁被分配。这也解释了为什么"改一格"在真实企业里从来不是小事。

账本（ledger）的概念在那块泥板上就已经有了。"Spreadsheet"这个词要等到 19 世纪——记账人把表格画在摊开的账本的跨页（the spread of an opened accounting book）上，词就这么来了。

二、从 VisiCalc 到 Excel：赢的都是"不预设内容"的那个

图 2：原文用 Nano Banana 生成的配图，描述"一个老师在黑板前重算一格格数字"。

据说当年给 VisiCalc 两位作者灵感的就是这样一幕：老师在黑板上算房贷。利率一变，她得把每一格都重新算一遍——靠心算，还得算得快，不然学生会走神。Dan Bricklin 听了这样一堂课，突然意识到计算机能帮她做这件事；然后他和 Bob Frankston 用两个月时间做出了 VisiCalc。

VisiCalc 出现在计算机史的一个关键节点上，并且立刻走红：它是第一个为个人电脑写的表格软件。个人电脑恰好合上当时企业的胃口——把员工从费时费力的纸笔流程里解放出来、按到屏幕前面，由此定下了之后 50 年的办公体验。

图 3：1979 年的 Apple II 在跑 VisiCalc。来源：Computer History Org（原文引用）。

维基百科上那条记载常被引用：有公司买下非常昂贵的 Apple II，只是为了跑 VisiCalc。然后 Lotus 1-2-3 出来了，VisiCalc——以及"苹果作为商用机"——很快熄火。

图 4：Lotus 1-2-3。来源：Wikipedia（原文引用）。

再往后，这个故事里不可避免的结局是微软 Excel。

图 5：原文认为微软做过最好的界面是 Windows 3，图为早期的 Excel。图片取自 Virtually Fun。

作者要说的点在这里：早期的表格软件，是对几百年手工制表的直接模拟。它对方格里放什么没有强观点，只要是数字或文字就行。 后来的迭代让它能干的不止加减乘除——整段程序可以写进那几个小格子里，"power user"这个词就是这么来的。

于是 Excel 成了通用软件，也因此极其灵活，任何业务都能把它掰成自己要的样子。它是第一波自动化浪潮的一部分：当有人请我们做自动化时，我们经常撞上的就是一个深深嵌进业务的 Excel 世界。同时它也是前互联网时代打包软件的遗物——完全跑在你自己的机器上，不需要 wifi，是你的，只属于你。

但 SaaS 成为常态之后，这件事变了。

三、SaaS 这二十年：界面趋同，人也趋同

互联网，我们爱它。我们写博客，从 ICQ 聊到 Messenger、Signal、Telegram，当然还有 WhatsApp；几十亿封邮件发出去，能评论就评论。我们有太多话要说了。

按钮要按，滑块要滑，表单要填。真让人兴奋。

我们的爱是真的。但它也一直是"更多同样的东西"。用户界面这门手艺把"可用性"当成信条和教义，结果几乎所有东西看起来、用起来都很像。

不只是看起来像。作者让人去读 Kahneman 的《思考，快与慢》：外面的相似会变成里面的相似。"我们都一样"——某种程度上是的，至少我们希望如此、我们假设如此。

那如果互联网不是按钮和表单，而是被拉回到它最初被设计出来的用途——传输数据；如果我们能自己决定怎么消费这些数据呢？

四、"传统软件"这个名字，配不上它自己

作者打了个比方：传统软件像一栋用砖和混凝土盖的房子。算法被高薪工程师定死在石头里，改一次可能要几个月。

有了 Agentic AI 编程之后，我们又到了一个关键节点——而且只有过了这个节点，"软件开发"这个词才真正名副其实。我们还说"build（构建）"，但"构建"对于一个能靠 AI 写代码的过程来说，太静态了。

回到黑板前那位老师。她练了很多年才能在心里做算术。她是专家，她的能力稀缺，如果不算高薪至少也很贵。

做传统软件需要这样的专家：他们懂几门编程语言，能一次写出整段能跑的代码、不用调试。这样的人稀缺、也贵。所以老软件是被"建"出来的——一个静态实体，带着一批功能与属性，创建贵，改动也贵。

贵还不只是钱。作者点出的真正代价是排队：业务里的人每天在撞上软件的边界，而边界只能由别人来挪，于是每个"就差一点"的需求都要进一条按优先级排序的队。这条队排得越久，业务就越倾向于把例外塞进现有功能里——把规则揉到最接近的那个下拉选项上。

NEW 软件才是把 software 里那个"soft"落到实处的形态。它不是油泥，也不是雕塑泥——这两种材料过一段时间都会硬；它是橡皮泥：柔软，而且一直柔软。

表格的类比在这里才真正接上。表格里被连起来的格子，父值一变就自动重算；在 NEW 软件里，被 AI 驱动的代码，会在关键环境属性变化时自动改变。

五、2029 年，阿姆斯特丹，一笔水损理赔

一家小保险公司，2029 年。一笔理赔落到 Marieke 桌上：仓库被水泡了，而保单里有一条奇怪的条款，讲的是"洪水"和"渗漏"的区别。

三年前，她的选项只有软件给她的那些：把这个理赔塞进下拉框里；或者给开发团队发邮件，等一个月，等一个会被判成"不是优先级"的变更请求。

现在她用的理赔系统不是砖房。她用大白话把条款描述出来——"从屋顶进来的水，和从管道进来的水，要区别对待"——然后软件自己把逻辑写出来。

格子重算了。

接下来才是关键，也正是 Bricklin 在课堂上看到的那一幕：下个季度保险公司加一条新条款时，Marieke 在鹿特丹的同事调整了他那份同样的逻辑，改动像修正一个单元格一样顺着整本账往下传。没有等下一个版本发布，因为没有发布这回事了。软件不是"建好然后发出去"的，它是被持续维护的，像一本活着的账本。

分工也跟着变了。Marieke 一行代码都不会写，也从来不需要学。她懂理赔——那是她的专业——而这个专业现在直接进了软件，不再经过那个"懂编程语言、但不懂业务"的专家瓶颈。

每个业务岗的同事都成了黑板前那位老师：繁琐的重算不再归她，但"该算什么"仍然归她。

这就是新的分界线。传统软件说：用工程师给你的工具，或者付钱让工程师改。NEW 软件说：工具是你的，你可以塑形。专家并没有消失——我们仍然需要能在黑板前核对算数的老师，而且比以往更需要一个像 Marieke 那样问出恰到好处的问题的人——但通用软件回到了舞台正中间。这也就是那个该记住的词。

六、A4 纸：没人爱它，但所有人都在上面工作

Ashmolean 那块泥板没有任何"功能"。没有按钮，没有滑块，也没有服务条款。人类造过的最耐用的软件，是一个表面，加一个共识。

A4 纸是同一种发明。没人爱 A4，没人对 A4 有强烈意见。它不打扰你，它到处都是，所有东西、所有人都能跟它配合——恰恰是因为它对你往上面放什么没有意见。它是完美的通用介质。

这就是 NEW 软件：一个表面，而不是一份功能清单。软件变成由你去塑形的东西——由用户去塑形的东西。就像 19 世纪的记账人把账本摊开在纸上，就像 Bricklin 那位老师把数字装在脑子里，就像书记员把农民一家收成的份额刻进泥里。

七、原文的结论：结束的不是软件，是"编程"这件自觉的事

本世纪头二十年被 SaaS 平台占据：业务分析师、后端工程师、可用性专家、前端开发、项目经理、QA、产品负责人、运维——一大队人参与进来，建起来极其复杂、极其昂贵，维护和改动也一样。

像往常一样，我们那点脆弱的历史感让我们以为 SaaS 时代会永远持续下去。

但作者认为它就要结束了。Agentic AI 编程带来的，即使不算软件的"终结"（毕竟一切都是软件，软件无处不在），也是"写代码"作为一件自觉活动（conscious activity）的终结——而且，就像在表格里改一个值会波及别的格子一样。

他把它叫作 NEW 软件："有点开玩笑，对，但也不全是。"因为他真的认为软件会变成你买来的一件东西——或者继承来的？祖父母传下来的？它不再被分成一个个品类：做营销的 Salesforce、做账的 Exact、做企业资源计划的 SAP，也不再是 WhatsApp、Signal 或微信，而是这个不定形的实体，你跟它说话，把活干完。或者玩得开心。

NEW 软件围绕你成形，而不是你弯着腰去伺候软件。

这就是他说的"通用"：像 Excel，但装着一切东西。

八、我们的整理：这事要落地，得先过三道门

原文是一篇观念文章，好用的是它的框架，缺的是操作面。我们把它压成一张表、三道门和一组边界。

先分清两个"通用"（很容易读串）。 中文语境里的"通用软件"历史上指装机量大、能卖给所有人的打包软件（相对于定制开发）；原文的 generalist 讲的是另一件事——它对方格里放什么没有意见。 前者是市场结果，后者是设计选择。这篇文章论证的是后者，前者只是它的后果。

（上表为我们根据原文整理的对照，非原文图表。）

三道门——缺一条，通用化就只是把风险从工程侧搬到业务侧：

1. 领域知识真的在用户手里吗？ 他能把规则说清，而不是"大概这样"。说不清的规则交给 AI，只是把模糊生成得更快。
2. 改动可被验证吗？ 有测试、有对账、有样例、有回归。原文里 Marieke 的改动之所以可信，是因为"格子重算"本身可核对；真实系统里，这一步得由工程做出来。
3. 出错能回滚、能留痕吗？ 每次改动的输入（谁说的、什么时候、什么模型、什么上下文）与产出都要落库。否则"没有版本"就等于"没有责任链"。

如果明天就想试一次，最小闭环长这样： 挑一条"每次都靠人判断"的规则 → 让懂这条规则的人用大白话写三段：什么情况适用、边界在哪、什么情况必须报错 → 让 AI 把它翻成规则或代码 → 拿过去半年的真实案例跑一遍，人对着结果逐条核 → 通过才上线，并把这次描述、这段生成、这次核对记下来。走完一圈你会知道两件事：这条规则到底有没有被说清，以及你们有没有能力验证它。

最容易被跳过的是第二条，而它恰恰是最贵的那条。站内几篇正好是这块的补丁：

• Agent 说"做完了"，证据呢：三道交付验证门——把"能核对"落成可执行的检查。
• Claude Code 团队怎么做代码评审：7 层防线——人工时间压在真正需要判断的地方。
• 多 Agent 写代码：代码是最简单的部分，协议才是系统——"验证是证据，不是授权"。
• AI 编程的未来已经到来，只是分布得极不均匀——代码行数 +30%，不等于功能变多。
• AI 时代职业护城河：三种模式、工作流与判断力——复核成本高于自己动手时，就不该委托。

给工程团队的三件具体事：

• 把"只存在于代码里"的业务规则，挪到能被描述的一层（参数、规则表、配置、领域语言）。这一步跟 AI 无关，但它决定了 AI 能不能安全接手。
• 把每次改动变成"生成 → 评审 → 验证 → 落库"四步，而不是"保存即生效"。
• 按后果给"谁能改"分级：影响钱、影响安全、影响合规的，仍然走人和流程；描述得清、验得了、错了能撤的，才交到业务侧。

边界（别把这篇读成"以后不需要工程师了"）：

• 2029 年阿姆斯特丹那个场景是原文的虚构例证，不是实测；文中没有任何量化数据，作者的判断是趋势性的。
• 作者自己保留了专家：需要能在黑板前核对算数的老师，也需要能问对问题的人。我们站内的口径也是这句——辅助 + 必须人工复核。
• 受监管的场景（保险、医疗、工控）里"没有版本"不成立：每一处逻辑改动都要可审计、可回滚、可复现。更可能的形态是半通用——格子是语义层，AI 负责把话翻成规则，工程守着验证与回滚。
• 还有一个很容易掉进去的形态：把自然语言直接接到生产数据上，配置不落库、改动不评审、出错不能回滚。那不是 NEW 软件，那是把十年前没人敢用的野脚本换了个更贵的写法，还多了幻觉。
• 一个反证就摆在文章自己举的例子旁边：Excel 正是靠"没有意见"活下来的，但一家公司的关键表格最后总还是有人管版本、管口径、管权限。通用不等于无主。

来源：Gerald Maria Dekkers,《Future software will be generalist.》, 2026-10-23。原文链接：https://gmdekkers.substack.com/p/future-software-will-be-generalist（正文图片来自原文，已转存至站内；原文以 René Magritte《Key of Dreams》(1935) 为题图）。

本文由汇智网编译整理，转载请注明出处。

这是「AI 编程 / Vibe Coding」专题的一部分。完整地图见：AI 编程 / Vibe Coding 完全指南