可塑软件：80%底座+20%代码，AI时代的软件构建新范式

无代码革命只兑现了一半

2019年，一位在协作工具行业深耕近20年的老兵Michael Dubakov（Fibery创始人）押注了一件事：无代码革命即将到来。然而多年后回头看，这个赌注只兑现了一半。今年8月，他发文承认自己当年的判断对了一半——无代码没有赢下市场，真正回来的东西让所有人都没想到：代码本身。

大模型把写代码的成本打了下来，那些低代码、无代码厂商反而开始拼命往自家产品里塞代码。Dubakov把这个趋势命名为「可塑软件」（Malleable Software），核心公式只有一行：80%的坚实底座 + 20%的定制代码。

这个公式看似简单，却揭示了AI时代软件构建方式的深层转变。无论你是接私活、做内部工具，还是选技术栈，都会撞上同一个问题——如何在灵活性与稳定性之间找到平衡。

「可塑软件」（Malleable Software）这一概念源自软件研究领域对「终端用户编程」（End-User Programming）的长期探索。其核心理念是：软件不应是一个封闭的黑盒，而应像黏土一样可以被使用者本人按需塑形。早在2019年，Ink & Switch研究机构就发布了题为《Malleable Software in the Age of LLMs》的白皮书，探讨如何让普通用户在不具备专业编程能力的前提下修改软件行为。Dubakov的「80%底座+20%定制代码」公式，本质上是把这一理念落地为一套可操作的产品架构策略：由平台负责通用的、所有团队都需要的基础能力，由用户（或AI辅助生成的代码）负责那些只有自己才能定义的差异化逻辑。这与传统SaaS「功能越多越好」的竞争逻辑截然相反——它承认没有任何一家厂商能替用户建模自己的业务，因此把「定制」视为产品设计的一等公民，而非事后打补丁的插件体系。

一家虚构农场照出所有小团队的处境

为了把问题讲具体，Dubakov虚构了一家10人规模的蘑菇农场。他们种双孢菇，需要管理菌包批次、订单、库房，但市面上没有现成的行业软件，团队只能拿Google表格硬撑。

这家农场是一面镜子，照出了所有小团队的共同处境：需求真实、预算有限、流程还在不断变化。

你可能会问：现在AI这么强，让Claude Code或Codex从零写一个不就完了？一个人玩确实可以，写崩了重写就行。但一旦加上「协作」这个维度，难度立刻上台阶——你需要处理带关系的数据存储、并发编辑、通知、变更历史、权限体系。这些才是真正的脏活累活，占了系统的大头，而且一点也不酷。

五条路，每条都缺一块

Dubakov把今天的技术选择列成五条路，按诞生年份排开，讽刺的是没有一条是理想的。

丛林生成：永远停在80%

Claude Code和Codex这类AI编程工具，提示词一开前80%确实快得让人上头。但剩下的20%会教你做人：托管要自己搞、登录认证要自己搞、权限和审计日志还是自己搞。这些没有一样能靠一句提示词糊过去。

每个程序员都踩过这个坑：Demo一个下午就出来，上线拖三个月。Dubakov对这条路的判断是：模型迟早会强到能干脏活，但那还很远。

「Demo一个下午，上线拖三个月」在软件工程中有一个对应的经典规律，常被称为「最后10%定律」或「冰山问题」。可见的功能演示往往只占整个系统工作量的20%左右，而真正耗时的是那些用户看不见的部分：身份认证与授权（OAuth、SSO、多租户隔离）、审计日志与合规、数据备份与恢复、错误处理与监控告警、以及跨浏览器/设备的兼容性。AI代码生成工具在「写出能跑的代码」这件事上已经相当出色，但它生成的代码往往缺乏对这些横切关注点（Cross-Cutting Concerns）的系统性处理——每次生成都可能用不同的方式实现认证，导致整个项目的安全模型支离破碎。这正是Dubakov所说「底座」价值的本质：把这些无聊但关键的基础设施一次性做对，让所有在其上运行的定制代码自动受益，而不是每次重新发明轮子。

Vibecode平台：魔法有边界

Lovable、v0这类Vibecode平台比丛林生成好一点，托管、数据库、认证、部署都开箱即用。对不会写代码的人来说几乎像魔法，但魔法有边界——一旦需求超出生成器擅长的范围就会卡住。它们给的是技术底座：服务器、原始数据库、认证，而协作、评论、变更历史一概没有。

低代码平台：应用底座≠工作底座

Retool、Softr这类低代码工具十年前就在卖同一套东西。它最擅长的是给已有数据库套一层管理界面，但它给的是应用底座，离工作底座还差一层——数据往往存在别处，团队在里面的工作痕迹它管不了。

可塑工具：灵活但扩展点不够

Notion、Fibery这一类可塑工具看起来很诱人，数据模型自己捏，上手飞快。麻烦在于贴合流程——它们够灵活，但未必撑得住特殊需求，扩展点不够。想想Jira插件生态过去定制代码的痛苦，懂的都懂。

专用工具：灵活与专用是死对头

市场再小也有专用软件，连蘑菇农场都能找到量身定做的工具。如果你的流程跟它匹配，直接买别犹豫。但只要差一步，你就得削足适履。它有个宿命：一旦变得通用灵活，就不再专用了。

底座不是一种东西

很多人以为未来属于生成能力最强的工具，谁能从提示词生成整个应用最猛谁就赢。Dubakov的判断恰好相反——赢下市场的是80%坚实底座 + 20%定制代码。

界面会被生成，几分钟一个，越来越便宜；但底座——存储、全线历史这些无聊的「水管工程」——搭起来还是要好多年。

关键在于，「底座」这个词今天根本不是一种东西：

• 技术底座（Vibecode平台提供）：服务器、原始数据库、认证
• 应用底座（低代码平台提供）：UI组件、连接器、访问控制
• 工作底座（可塑工具提供）：数据本身就住在里面，协作、历史、权限一应俱全

过去黑客时代，你手里唯一的底座是编译器和操作系统，其他全得自己造。今天有了更高的抽象层，真正的问题变成了：抽象该停在哪一层？

专用工具是最硬的底座，硬到改不动；Codex几乎没有底座，表达力拉满什么都能写。两个极端都不行，甜点在中间——底座管所有团队都一样的东西，定制代码管你不一样的东西。

Dubakov对「底座」的三层分类，对应的是软件架构中「抽象层次」（Level of Abstraction）的经典讨论。技术底座对应基础设施层（IaaS/PaaS），解决的是「代码能跑起来」的问题；应用底座对应框架与组件层，解决的是「界面能拼起来」的问题；工作底座则更接近领域驱动设计（Domain-Driven Design，DDD）中「通用语言」和「领域模型」的概念，解决的是「业务数据能被统一管理」的问题。三层之间的关键差异在于数据的归属：技术底座和应用底座中，业务数据通常存在用户自己的数据库里，工具只是提供连接；而工作底座中，数据本身就是平台的一部分，协作、历史版本、权限控制因此可以被平台统一实施。这也是为什么「选底座」的决策如此重要——你选择在哪一层构建，就决定了你的数据未来被谁「托管」，以及两年后迁移的代价有多高。

20%定制代码的两个硬条件

那20%定制代码量不大，分量却极重。它包括你的专属界面（如车间平板上的采收屏）、你的业务规则（如菌批质量判定）、你的外部连接（批发客户API、湿度传感器）。这部分就是你的公司本身，没有任何厂商能替你建模。

但定制代码要成立，必须满足两个条件：

1. 继承底座：权限、历史、数据完整性自动对定制代码生效。如果每个生成的应用都自带一套认证和审计，那就全完了。
2. 有边界：定制代码可以把自己写崩，但绝不能腐蚀底座。出问题能一键回滚——一个烂应用应该只是麻烦，不能变成丢数据的事故。

最值钱的原则：选底座，别选界面

Dubakov给出了全篇最值钱的一条原则：选底座，别选界面。

数据、历史、权限会不断累积，两年后想换底座，迁移成本高得让你绝望。而界面正在变成便宜且可替换的部分，AI几分钟就能生成一个新的。想想你的前端框架三年一换你心疼过吗？可生产库里的数据你动一次试试。

过去厂商卖的是界面，底座是藏在底下的无聊水管；现在彻底倒过来了——界面几分钟生成，底座还要搭好几年。谁的底座扎实，谁手里就攥着复利。

对写代码的人同样成立：你积累的领域模型和数据资产，比你写的任何界面都值钱。

这一原则在数据库领域有一个广为人知的反面教材：早期许多团队选择将业务逻辑深度耦合进某个SaaS工具的私有数据模型（如早期Salesforce的对象模型、或Notion的块结构），数年后当需求超出平台能力时，才发现数据导出格式残缺不全，关联关系在迁移中丢失，历史记录无法携带。这种现象被称为「供应商锁定」（Vendor Lock-in）中最难解除的一种——不是因为合同，而是因为数据已经被平台的私有结构「消化」了。与此对照，「界面可替换」的论断有充分的历史支撑：从桌面GUI到Web、从Web到移动端、从移动端到今天的AI对话界面，每一次交互范式的切换都让旧界面快速贬值，但底层的数据资产和业务规则却得以延续。因此，评估一个工具时最关键的问题不是「它的界面好不好用」，而是「我的数据以什么格式存在哪里，以及我能不能完整地把它带走」。

落到实操：怎么选？

Dubakov给出了分场景的技术选型建议：

• 一个人干活：Vibecode平台随便玩，开心就好
• 有现成专用工具能盖住90%流程：直接买
• 流程还在演化的团队（如那家蘑菇农场）：从可塑工具起步，底座已经在了，缺的20%每个月都更好Vibe一点

他自己用Fibery的Custom Apps，一小时就搭出了蘑菇农场的管理空间。带货成分确实有，但逻辑自洽。

最后他给市场下了两个赌注，验收日期是2030年：

1. 「坚实底座 + 定制代码」将赢下生产力市场
2. 可塑工具最有机会先到终点——因为加扩展点按季度算，造底座按年算

结语：AI没有杀死代码

AI没有杀死代码，它把代码送回了舞台中央，只是换了个位置。选型时记住三个问题：

• 底座是谁的？
• 定制代码能不能继承底座？
• 两年后数据搬不搬得走？

在生成式AI让界面变得廉价的时代，真正的护城河反而回到了那些「无聊却困难」的地基工程上。这或许是对所有创业者和工程师最实在的提醒。