可塑软件之道：坚实底座与定制代码的归宿——Fibery创始人长文深度解构与内部工具选型指南

“2019 年，我重注押在无代码革命上。五年之后，这场赌注只应验了一半：无代码试图杀死代码，但真正以王道归来的，恰恰是代码本身。”
—— Michael Dubakov，生产力工具二十二年老兵、Fibery 创始人

在软件工程演化史上，人总在 “极端定制” 与 “开箱即用” 的两极之间反复摇摆。大模型（LLM）狂飙突进，代码门槛被彻底击碎，工程师与业务人员突然拥有了随心所欲生成界面的能力。

然而，随之而来的并非软件工程的乌托邦，而是无数碎片化、难以协同、没有权限与历史记录的“代码垃圾山”。Michael Dubakov 于 2026 年 8 月发表长文《Malleable software = solid bases + custom code》，以其二十余年行业阅历，为这场喧嚣指明了终局：可塑软件（Malleable Software）的黄金平衡点，在且仅在于“80% 的坚实底座 + 20% 的定制代码”。

1. 🍄 蘑菇农场的困境：为什么现存的一切路线都不完美？

设想你在经营一家仅有 10 名雇工的微型双孢蘑菇农场。

农场的业务高度具体：既要跟踪每个菇房的培养基配方、菌丝生长温湿度传感器数据，又要管理采收批次质量评级、批发客户订单与出库流向。对于这样一个小企业，摆在面前的通常只有五个选择，但荒谬的是，无一完美：

五条工具路线的残酷体检表

导语：在蘑菇农场的落地推演中，五大工具流派在业务契合度、协同沉淀能力与工程维护成本上暴露出互为因果的断裂面。

表达力（Expression Power）
软件工程度量指标之一，指开发者或用户能够将该工具“弯折扭曲（Bend）”至完全契合自身独一无二业务意图的自由度与极限边界。

2. 🏛️ 框架一：三种底座的区别（The Three Bases）

Michael Dubakov 指出，过去二十年所谓“底座”，从编译器、操作系统一路演进。而在当代软件工程视野下，底座（Base）绝非铁板一块，而是划分为三个截然不同的层次：

┌─────────────────────────────────────────────────────────────┐
│ 3. 工作底座 (Work Base)  【Fibery / Notion 等可塑平台】      │
│    数据、实体关系、协作讨论、变更审计、版本回溯、知识网络    │
├─────────────────────────────────────────────────────────────┤
│ 2. 应用底座 (App Base)   【Retool / Bubble 等低代码平台】   │
│    预置 UI 控件、API 连接器、RBAC 访问控制、单点登录       │
├─────────────────────────────────────────────────────────────┤
│ 1. 技术底座 (Tech Base)  【Vibe-coding / Supabase / Vercel】│
│    云服务器、裸数据库表、网络鉴权、容器自动化部署           │
└─────────────────────────────────────────────────────────────┘

① 技术底座（Tech Base）：提供“运行环境”

• 边界：解决的是“机器怎么跑起来”的问题。给你一块磁盘、一个 Postgres 实例、一套 OAuth 鉴权。
• 缺陷：它没有任何业务语义。两个人同时改一个蘑菇采摘记录，它只知道底层的行锁，完全不知道这在业务上意味着什么。

② 应用底座（App Base）：提供“表单与连线”

• 边界：Retool 等低代码平台的核心。它假定你的真实数据住在别处（比如某台 MySQL 数据库或 Salesforce 之中），它只负责快速拖拽出一个页面，把数据查出来、填进去。
• 缺陷：数据只是一行行冷冰冰的字段。这里 没有协同的生命周期——没有人在记录边上的讨论气泡，没有字段修改的前因后果回溯，没有文档与数据的共生。

③ 工作底座（Work Base）：数据与协同在此共生

• 定义：可塑工具所构筑的终极底座。
• 特质：数据本身就生活在这里，且 数据与团队围绕数据发生的一切行为（讨论、任务关联、状态跃迁、权限继承）天生咬合在一体。

可塑软件（Malleable Software）
这一概念源自人机交互先驱（如 Alan Kay 及 Ink & Switch 实验室）。指由终端用户在使用过程中，根据自身环境与认知的演化，拥有完全自主权对其进行 就地重塑、动态重构与随意缝合 的软件系统。

3. ⚙️ 框架二：定制代码（Custom Code）成立的两大铁律

无代码阵营过去五年的狂妄在于：试图消灭一切代码，用可视化拖拽实现万物。
这一狂妄最终被复杂业务逻辑的客观规律粉碎——在低代码平台里用连线和表单拼接一个复杂审批树，其心智负担远高于写三行 Python 或 JavaScript。

2025 年底 LLM 的爆发，促使“代码以意外的姿态重返王座”。任何人只要自然语言输入，AI 就能在数秒内吐出一段精准的业务逻辑。

然而，Michael Dubakov 严厉告诫：允许用户写代码（或由 AI 帮写代码）并非灵丹妙药；定制代码必须无条件服从两大铁律，否则系统必亡：

                  ┌───────────────────────────────┐
                  │       定制代码 (Custom Code)   │
                  │   (蘑菇品质算法 / 采摘平板界面)  │
                  └───────────────┬───────────────┘
                                  │
         ┌────────────────────────┴────────────────────────┐
         ▼                                                 ▼
【铁律一：无条件继承底座】                         【铁律二：严格沙箱物理隔离】
   • 权限 (Permissions) 自动注入                      • 代码崩溃绝不污染底座数据
   • 变更历史 (History) 自动留痕                      • 异常仅是一次局部 UI 报错
   • 数据约束 (Integrity) 原生继承                    • 随时一键瞬时回滚 (Rollback)

铁律 ①：代码必须无条件继承底座（It inherits the base）

• 定制代码绝不能成为独立的法外之地。
• 用户用 AI 敲出来的一个“蘑菇快速采摘记录界面”，其读取与写入必须自动继承底座所定义的一切权限规则、字段校验与版本历史。
• 如果每生成一个新组件，工程师都要自己写一遍用户鉴权、写一遍 Audit Log，那这种架构注定沦为灾难。

铁律 ②：代码必须严格边界隔离（It is bounded）

• 定制代码可以把自己玩崩溃，但绝对不能弄脏或破坏底层的工作底座。
• 一段糟糕的代码、一次 AI 生成的逻辑死循环，充其量只能导致屏幕右侧的一块区域变灰报错，而不能演变成删库事故或核心业务数据污染。
• 在数学抽象上，定制逻辑应当作为底座状态机的一个纯函数映射（Pure Function Mapping）：

任何不符合底座不变量（Invariants）的状态突变，都将被底层基础设施直接阻断并支持一键回滚（Zero-Cost Rollback）。

4. 🧭 框架三：选型第一公理——“选底座别选界面”（Select the Base, Not the Interface）

这是 Dubakov 长文中对所有技术决策者、架构师最具杀伤力的认知重构：

过去的生产力市场 (2000-2023)：
┌───────────────────────────────────────────────┐
│  前端界面 (UI)        ───► 核心卖点 (昂贵、光鲜)│
├───────────────────────────────────────────────┤
│  底层基建 (Base)      ───► 乏味管道 (便宜、附赠)│
└───────────────────────────────────────────────┘

AI 时代的生产力市场 (2025 至今)：
┌───────────────────────────────────────────────┐
│  前端界面 (UI)        ───► 易耗品 (分钟级生成、可随时抛弃) │
├───────────────────────────────────────────────┤
│  底层基建 (Base)      ───► 终极资产 (数年打磨、极难迁移)  │
└───────────────────────────────────────────────┘

市场倒转法则（Market Inversion Principle）
过去二十年，SaaS 厂商依靠五彩斑斓的界面收买用户，而存储、权限、并发、审计被视为隐于水下的“枯燥管道工活”。但在大模型时代，生成一个针对特定平板优化的蘑菇采摘界面只需 3 分钟；而搭建一套高可靠、多租户、细粒度权限和强一致性历史回溯的工作底座，依然需要顶尖团队打磨数年。

决策落地法则：

1. 切勿因为“界面好看”而购买软件：在今天，界面是最廉价、最容易被重新生成的消耗品；
2. 死死审视数据底座的厚度：团队未来三到五年的实体关系链、上下文对话、跨部门引用网络，都将沉淀在底座之中。一旦选错底座，迁移的阵痛将百倍于重写几个界面的代价；
3. 考察扩展点的密度（Extension Points）：底座是否允许随时用一行短小的代码、一个由 AI 辅助的微型组件（Micro-App）精准击穿业务孤岛。

5. 🎯 终局展望：通往绿野的不同道路

生产力工具的地图正在向同一片 “高表达力 + 极短构建时间” 的绿野迁徙：

构建耗时 (Build Time)
   ▲
长 │  [传统从零手搓]             [传统低代码]
   │
   │
   │                ★ 终局圣杯 (80% 底座 + 20% 代码)
   │               ┌───────────────────────┐
   │               │   可塑软件新范式       │
   │               │ (高表达力 x 极短耗时) │
   │               └───────────────────────┘
   │
短 │  [Vibe-coding]              [传统可塑工具]             [专用 SaaS]
   └─────────────────────────────────────────────────────────────►
     低                                                         高
                               表达力 (Expression Power)

• Vibe-coding 工具 必须疯狂补齐协同底座（但这需要耗费数年，极难）；
• 传统低代码工具 必须把冷冰冰的应用底座升级为有人情味的工作底座；
• 可塑工具（Fibery、Notion 类） 的胜算最大——因为 在坚实底座上开放代码扩展点只需几个季度，而在轻浮的代码之上搭建协同底座却需要数年之功。

正如 Dubakov 在文末充满诗意的预言：
“我们 2030 年见。到时候，我们再去看看那家 10 个人的蘑菇农场，到底有没有彻底扔掉他们的 Google Sheets。”

📚 参考文献与真实学术/业界信源

1. Dubakov, M. (2026-08-18). Malleable software = solid bases + custom code. Edge of Chaos. https://mdubakov.me/malleable-software-solid-bases-custom-code (本研究之核心一手论述原文).
2. Dubakov, M. (2019). The No-Code Revolution: Why Now?. Fibery Blog. https://fibery.com/blog/gems/no-code-revolution-why-now/ (五年前押注无代码之思想渊源).
3. Ink & Switch (2019). End-user programming and malleable software: Capstone essay. Ink & Switch Research Lab. https://www.inkandswitch.com/essay/malleable-software/ (人机交互领域“可塑软件”范式奠基之作).
4. Litt, G. (2023). Malleable software in the age of LLMs. Personal Research Essays. https://www.geoffreylitt.com/2023/03/25/llm-end-user-programming.html (大语言模型对终端用户自编程与可塑软件之赋能机制).