可塑软件 = 80%坚实底座 + 20%定制代码 — Dubakov 的 AI 时代选型框架¶

Fibery 创始人 Michael Dubakov，2004 年入行生产力工具市场，观察这个行业 22 年。2019 年他押注无代码革命；2026 年 8 月他发文承认这个赌注「兑现得一般」（aged so-so）——真正回来的是代码本身。本笔记基于「为什么叫QQ」频道的解读视频，全部论点已对照原文《Malleable software = solid bases and custom code》逐条核验。

目录¶

0. 一手来源档案
1. 背景：无代码神话破灭与代码回归
2. 五条工具路线评析
3. 三种底座的分层
4. 定制代码的两个合格条件
5. 市场走向与选型原则
6. 验证与勘误记录
7. 行动启示
参考资料

0. 一手来源档案¶

[!info] 来源链（全部一手验证） - 原文: Malleable software = solid bases and custom code — mdubakov.me，2026-08 - 作者: Michael Dubakov，Fibery 创始人/CEO，生产力工具市场 22 年（2004 入行） - HN 讨论: item 49508059，111 points / 33 comments，2026-08-31 由用户 tablet 提交 - 解读视频: 为什么叫QQ 频道，2026-09-06 发布，6450 订阅的频道 - 原文 P.S. 自引：Ink & Switch 的 Malleable Software 宣言 + Geoffrey Litt 的《Malleable software in the age of LLMs》（研究侧视角）

Dubakov 的写作谱系（原文自引链条）：

2019 押注无代码革命（fibery.com/blog）
   │
   ├─ 2025-08 Malleable Software: code → low-code → no-code（分层分析）
   ├─ 2025-08 Malleable Software Will Eat the SaaS World
   │
   └─ 2026-08 Malleable software = solid bases + custom code（本篇）
         └─ 新赌注验收日期：2030（回头看蘑菇农场有没有扔掉表格）

1. 背景：无代码神话破灭与代码回归¶

1.1 两个赌注的对照¶

	2019 年赌注	2026 年新赌注
内容	无代码革命，淘汰写代码环节	坚实底座 + 定制代码赢下生产力市场
结果/预期	只兑现一半：无代码没赢，代码反而回归	可塑工具最先到终点（加扩展点按季度计，造底座按年计）
驱动力	可视化搭建降低门槛	LLM 把写代码成本打下来，「人人可以 prompt」
讽刺点	无代码阵营开始往产品里塞代码	过去难做的定制扩展（Jira 插件生态之痛）现在变容易

核心公式一行：可塑软件 = 80% 坚实底座 + 20% 定制代码。原文明确标注「这是生产力工具的理想解」——注意 Dubakov 的论述范围是生产力/协作工具市场，不是全部软件。

1.2 蘑菇农场案例¶

Dubakov 虚构一家 10 人蘑菇农场（种双孢菇/champignons），要管菌包、批次、订单、库房。它是所有小团队处境的镜子：

痛点维度	蘑菇农场的表现	一般小团队的共性
需求真实	菌包批次追踪、库存、订单一个不少	业务流程确实存在，不是伪需求
预算有限	10 人厂养不起 IT 团队	买不起深度定制开发
流程演进	种植流程还在调整变化	今天的模型明天就不够用
市场缺口	以为没专用软件，其实有（Kinoko）	再小的市场也有专用工具，但未必贴合

一个人玩，vibe-code 随便写、写崩重来都行。可一旦加上协作这个维度，难度立刻上台阶：带关系的数据存储、并发编辑、通知、变更历史、权限体系——这些才是系统的大头，是「不酷的脏活累活」。

2. 五条工具路线评析¶

2.1 总览表（按出生年份排开，信息以原文为准）¶

路线	出生	代表工具	给你的底座	致命短板	未来希望
从零生成	2024	Claude Code、Codex	几乎没有	前 80% 快，后 20%（托管/认证/权限/审计）全是你的活	模型强到能干脏活（「那是希望，距离现在还远」）
Vibe-code 平台	2023	Lovable、v0	技术底座	超出生成器擅长范围就卡死；协作/评论/变更历史一概没有	不停加组件，往「底座+定制代码」方向挪（补课以年计）
低代码/应用搭建器	2017	Retool、Softr	应用底座	数据假设存在别处；自带库存的也只是应用数据，无协作痕迹	应用底座能否足够快长成工作底座（两头都得补）
可塑工具	2013	Notion、Fibery	工作底座	扩展点不够，贴合特殊流程难（Jira 插件生态之痛）	加扩展点，让剩余 20% 可以 vibe-code（以季度计）
专用行业软件	1999	Kinoko（蘑菇农场真有）	最硬的底座	流程与预设假设差一步就削足适履	守住细分行业即可；转通用「基本不可能，也没必要」

2.2 路线时间线¶

1999            2013          2017        2023       2024
 │               │             │           │          │
 专用软件         可塑工具       低代码       Vibe-code  从零生成
 Kinoko          Notion        Retool      Lovable    Claude Code
 (最硬底座,      Fibery        Softr       v0         Codex
  改不动)        (工作底座)    (应用底座)   (技术底座)  (几乎无底座,
                                                           表达力满格)
 ─────────────────────────────────────────────────────────────▶
      硬 ◀─── 底座硬度 ──────────────────────▶ 软
      弱 ◀─── 表达力   ──────────────────────▶ 强

两个极端都不行：专用工具硬到改不动，从零生成什么都能写但什么都得自己造。甜点在中间——底座管所有团队都一样的东西，定制代码管你不一样的东西。

2.3 每条路的经典坑（从零生成详说）¶

从零生成的坑是程序员人手一个：demo 一个下午就出来，上线拖三个月。剩下的 20% 没有一样能靠一句提示词糊过去：

托管（hosting）要自己搞
登录认证（auth）要自己搞
权限（permissions）和审计日志（audit log）还是自己搞

Vibe-code 平台好一点——托管、数据库、认证、部署开箱即用，应用「看起来」很快成形；但它的底座到技术底座为止，协作语义、变更历史这类东西不是堆组件能堆出来的，补课计价单位是年。

3. 三种底座的分层¶

3.1 定义与包含关系¶

┌─────────────────────────────────────────────────┐
│ 工作底座 (Work Base)  ← Notion / Fibery          │
│ ┌─────────────────────────────────────────────┐ │
│ │ • 数据原生驻留（批次/订单就在里面）             │ │
│ │ • 团队协作痕迹：评论、@、通知                  │ │
│ │ • 变更历史 / 审计日志                         │ │
│ │ • 并发编辑 / 权限体系                         │ │
│ │ ┌─────────────────────────────────────────┐ │ │
│ │ │ 应用底座 (App Base)  ← Retool / Softr    │ │ │
│ │ │ • UI 组件  • API 连接器  • 基础访问控制   │ │ │
│ │ │ • 但数据假设存在别处（你的库在别处）        │ │ │
│ │ │ ┌─────────────────────────────────────┐ │ │ │
│ │ │ │ 技术底座 (Tech Base)  ← Lovable / v0 │ │ │ │
│ │ │ │ • 服务器  • 原始数据库  • 基础认证    │ │ │ │
│ │ │ │ • 协作？变更历史？——没有              │ │ │ │
│ │ │ └─────────────────────────────────────┘ │ │ │
│ │ └─────────────────────────────────────────┘ │ │
│ └─────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────┘

3.2 对比：你的团队痕迹存在哪¶

维度	技术底座	应用底座	工作底座
数据位置	你自己接的库里	假设在别处；自带的只存应用数据	原生驻留，数据就在工具里
协作（评论/@/通知）	无	无	原生
变更历史/审计	自己搭	部分有	原生
权限体系	基础认证	基础访问控制	面向团队的完整体系
典型代表	Lovable、v0	Retool、Softr	Notion、Fibery
历史视角	过去唯一的底座是编译器和操作系统（真黑客的黄金年代）；今天的抽象层高了，真正的问题变成：抽象该停在哪一层

4. 定制代码的两个合格条件¶

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

条件一：可继承性（It inherits the base）

✅ 底座的权限、历史、数据完整性对定制代码自动生效
✅ 认证直接继承，不用重复配置
❌ 每个生成的微应用都自带一套认证和审计——那就全完了（you are doomed）

条件二：安全边界（It is bounded）

✅ 定制代码可以把自己写崩——这只是麻烦（inconvenience）
❌ 但绝不能腐蚀底座数据——那会变成数据丢失事故（data-loss incident）
✅ 出问题能一键回滚（rollback should be easy）

场景	结果	定性
定制采收屏崩了，刷新后重开	底座数据无损	麻烦，可接受
定制代码写坏并发逻辑，污染批次历史	底座被腐蚀	事故，设计失败
微应用要求全员再注册一套账号	未继承认证	条件一不满足

AI 时代的意义：过去定制扩展很难（想想 Jira 插件生态的开发体验），现在 LLM 让「低代码/无代码工具靠代码解决定制问题」变得更快、更容易、更深——这是代码讽刺性的回归（原文：ironically!）。

5. 市场走向与选型原则¶

5.1 表达力 × 构建时间坐标图（原文核心图表的 ASCII 复原）¶

 构建时间
    ▲
 高 │  ● 从零生成                 ← 表达力满格，时间也拉满
    │  (Codex/Claude Code)
    │
    │        ○ Vibe-code          ◇ 低代码
    │        (Lovable/v0)         (Retool)
    │                  □ 可塑工具
    │                  (Notion/Fibery)
    │        ┌───────────────────┐
 低 │  ▼    │   绿色区域          │  ← 高表达力 + 短构建时间
    │ 专用  │   （大家都在往这挪） │     可以兼得
    │ 工具  └───────────────────┘
    │ (Kinoko)
    └─────────────────────────────────▶ 表达力
      低（改不动）                高（什么都能写）

 各家路线：
   Vibe-code 工具：必须造底座（造底座以「年」计）
   可塑工具：      必须加表达力/扩展点（以「季度」计）→ 更可能先到
   低代码：        两头都得补
   大问号：        AI 从零生成会不会作废整张地图？——「现在还没有」（but not yet!）

5.2 原则：选底座，别选界面（Select your base, not the interfaces）¶

这是全篇最值钱的一条原则，逻辑是一个倒置：

	过去	现在（AI 时代）
界面（UI）	厂商卖的主体，贵	几分钟生成一个，便宜且可替换（想想前端框架三年一换，你心疼过吗）
底座（存储/权限/历史）	藏在底下的无聊水管	仍要搭好几年；数据、历史、权限不断累积
迁移成本	—	两年后想换底座，成本高到绝望；生产库里的数据动一次试试

谁的底座扎实，谁手里就攥着复利。这个判断对写代码的人也成立：你积累的领域模型和数据资产，比你写的任何界面都值钱。

5.3 今天怎么选（决策树）¶

你的处境是？
│
├─ 一个人干活 ──────────▶ vibe-code 随便玩，开心就好
│
├─ 专用工具能盖住 90% 流程 ▶ 直接买，别犹豫（流程匹配是前提）
│
└─ 团队 + 流程还在演化 ───▶ 从可塑工具起步
    │                      （底座现成：批次/订单/历史/权限都在，
    │                       缺的 20% 每个月都更好 vibe 一点）
    ├─ 检查定制代码能否继承底座权限/历史？
    ├─ 检查有无沙盒边界 + 一键回滚？
    └─ 检查两年后数据/业务模型能否平滑导出？

原文实操注脚：Dubakov 用 Fibery Custom Apps 约一小时搭出蘑菇农场管理空间（含几个定制应用）——他自带货成分确实有，但逻辑自洽（视频原话）。

6. 验证与勘误记录¶

全部关键声称已对照原文《Malleable software = solid bases and custom code》与 HN 讨论串核验（2026-09-07）：

视频声称	验证结果	来源
Dubakov 2019 押注无代码，2026-08 发新文承认只对一半	✅ 原文开篇 In 2019 I bet... aged so-so（「对一半」是视频对 so-so 的意译）	原文首段
核心公式 80% solid bases + 20% custom code	✅ 原文独立章节标题级论点	原文
生产力工具市场 22 年（2004 入行）	✅ 原文：joined in 2004, observing for 22 years	原文首段
蘑菇农场 10 人种 champignons + Kinoko 专用软件真实存在	✅ 原文链接 kinoko-app.com（A new way to manage your mushroom farm）	原文
五条路线及出生年：2024 从零生成 / 2023 Vibe-code / 2017 低代码 / 2013 可塑工具 / 1999 专用	✅ 与原文完全一致	原文
低代码代表是 Retool 和 Softr	✅ 原文为 Retool、Softr；⚠️ 视频 Content Insights 写成 Retool/Appsmith，以原文为准	原文
三种底座：tech base / app base / work base 及各自归属	✅ 原文 Solid bases 一节，逐条一致	原文
定制代码两条件：继承底座 + 有边界（含 you are doomed / data-loss incident 原话）	✅ 原文 Custom code 一节	原文
表达力×构建时间坐标图与绿色目标区域	✅ 原文含此图（本笔记 ASCII 复原）	原文
扩展点按季度加、底座按年造	✅ 原文 Wrap Up 新赌注原话（quarters vs years）	原文
选底座别选界面 + 界面变便宜、底座仍要搭几年	✅ 原文 Select your base, not the interfaces	原文
Fibery Custom Apps 一小时搭出蘑菇农场空间	✅ 原文配图说明：built in Fibery in about one hour	原文
新赌注验收日 2030，回头看农场有没有扔掉表格	✅ 原文 See ya in 2030 🍄	原文
原文有 HN 讨论串	✅ item 49508059，111 points / 33 comments / 2026-08-31 / 提交者 tablet	HN API
AI 从零生成会不会作废整张地图？现在还没有	✅ 原文括号原话 (but not yet!)	原文

勘误与口径说明：

Retool 的搭档是 Softr 不是 Appsmith——用户 Content Insights 把低代码代表写成 Appsmith，原文明确是 Softr；视频口播与原文一致。
「只赢了一半」是意译——原文 aged so-so 语气更接近「兑现得一般」，语义方向相同。
「Retool 最擅长给已有数据库套管理界面」是视频的合理转述，原文对应表述是 your data is assumed to live somewhere else。
论述范围限定：Dubakov 谈的是生产力/协作工具市场，不是全部软件；原文 P.S. 指出研究侧视角见 Ink & Switch 宣言与 Geoffrey Litt 的文章。

7. 行动启示¶

选型三问（视频结尾版，直接可用）：

底座是谁的？——纯技术底座、应用底座，还是真带协作与权限痕迹的工作底座
定制代码能不能继承底座？——权限/历史/数据完整性是否自动生效，有无沙盒隔离与一键回滚
两年后数据搬不搬得走？——预设迁移，避免被界面或厂商绑架

✅ 团队流程还在演化 → 从可塑工具起步，底座现成，AI 逐月补齐 20%

✅ 把工程精力投向底座层：领域模型、数据资产、权限与历史——这些有复利

✅ 界面层保持廉价心态：AI 几分钟能重生成的部分，不值得长期绑定

❌ 不要用 AI 从零硬造带协作的系统——并发、审计、权限这 20% 脏活会吃掉你三个月

❌ 不要押注专用工具变得更灵活——原文判断：转通用基本不可能，也没必要