> “2019 年，我重注押在无代码革命上。五年之后，这场赌注只应验了一半：无代码试图杀死代码，但真正以王道归来的，恰恰是代码本身。” > —— Michael Dubakov，生产力工具二十二年老兵、Fibery 创始人
在软件工程演化史上，人总在 “极端定制” 与 “开箱即用” 的两极之间反复摇摆。大模型（LLM）狂飙突进，代码门槛被彻底击碎，工程师与业务人员突然拥有了随心所欲生成界面的能力。
然而，随之而来的并非软件工程的乌托邦，而是无数碎片化、难以协同、没有权限与历史记录的“代码垃圾山”。Michael Dubakov 于 2026 年 8 月发表长文《Malleable software = solid bases + custom code》，以其二十余年行业阅历，为这场喧嚣指明了终局：可塑软件（Malleable Software）的黄金平衡点，在且仅在于“80% 的坚实底座 + 20% 的定制代码”。
—
1. 🍄 蘑菇农场的困境：为什么现存的一切路线都不完美？
设想你在经营一家仅有 10 名雇工的微型双孢蘑菇农场。
农场的业务高度具体：既要跟踪每个菇房的培养基配方、菌丝生长温湿度传感器数据，又要管理采收批次质量评级、批发客户订单与出库流向。对于这样一个小企业，摆在面前的通常只有五个选择，但荒谬的是，无一完美：
graph TD A[“10人蘑菇农场的数字化选型”] –> B[“① 从零全量生成 (Codex / Claude Code)”] A –> C[“② 感觉编码 (Vibe-code / v0 / Lovable)”] A –> D[“③ 低代码平台 (Low-code / Retool / Softr)”] A –> E[“④ 可塑软件工具 (Malleable / Fibery / Notion)”] A –> F[“⑤ 传统垂直专用SaaS (Specialized SaaS)”]
B –>|”致命伤”| B1[“基建黑洞: 鉴权/协作/数据库全得自己从零造”] C –>|”致命伤”| C1[“技术底座: 缺乏团队协同/变更历史/权限体系”] D –>|”致命伤”| D1[“应用底座: 数据在外/冷冰冰表格/缺乏上下文”] E –>|”现状与希望”| E1[“工作底座: 协同齐备，唯缺 20% 代码扩展点”] F –>|”致命伤”| F1[“水泥浇死: 无法定制/业务稍变即沦为废铁”]
五条工具路线的残酷体检表
导语：在蘑菇农场的落地推演中，五大工具流派在业务契合度、协同沉淀能力与工程维护成本上暴露出互为因果的断裂面。
| 工具路线类别 | 代表产品 / 范式 | 核心供给（它给了什么） | 致命短板（它缺了什么） | 蘑菇农场结局研判 |
|---|---|---|---|---|
| ① 从零生成 (Prompt from scratch) | OpenAI Codex<br>Claude Code | 绝对无限的表达力（Expression Power），想要什么形态就生成什么 | 必须从零手搓鉴权、数据库、并发锁、审计追踪与服务器运维 | 🚨 基建泥潭：前 80% 极其惊艳，最后 20% 的多用户协同基建让人崩溃 |
| ② 感觉编码 (Vibe-coding) | Lovable<br>v0 / Bolt | 开箱即用的数据库、自动托管部署、快速生成的炫酷 UI | 仅停留在技术层（Tech Base），缺乏深度的多用户协同逻辑 | ⚠️ 单兵玩具：个人用极爽，10 个人一协作，权限错乱、脏写频发 |
| ③ 低代码应用 (Low-code Builders) | Retool<br>Softr / Bubble | 十年打磨的成熟应用底座（App Base）：完备的 UI 组件、企业级 RBAC、API 桥接 | 假定数据在外部，系统内部没有活生生的业务上下文（评论流、版本脉络） | 📊 冷血仪表盘：只管调接口查表，无法沉淀菇农之间的日常协同讨论 |
| ④ 可塑工具 (Malleable Tools) | Fibery<br>Notion | 天生的工作底座（Work Base）：数据、关系、文档、协作脉络长在一起 | 过去缺少足够的“代码击穿点”，遇到奇葩业务逻辑（如传感器公式）易卡死 | 🏆 理想种子：已有 80% 协同底座，只待 20% 定制代码将其激活 |
| ⑤ 垂直专用软件 (Specialized SaaS) | 传统农业 ERP<br>垂直行业套件 | 深度契合通用农业流程，开箱即用 | 铁板一块，不可变形；一旦流程与软件预设不符，完全无法修改 | 🔒 削足适履：为了迁就软件死板的表单，菇农被迫重回 Excel |
> 表达力（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）：
![\[S_{t+1} = text{BaseCommit}Big(S_t, ; text{Sandbox}big(f_{text{custom}}(S_t)big)Big)\]](https://www.zhichai.top/wp-content/ql-cache/quicklatex.com-2f711d31c7aa595045b93f6e9448526e_l3.svg "Rendered by QuickLaTeX.com")
任何不符合底座不变量（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 (大语言模型对终端用户自编程与可塑软件之赋能机制).