可塑软件：80% 稳固底座加 20% 自定义代码
Malleable software = solid bases and custom code
我在生产力工具市场深耕 22 年，见证了从 No-code 到 AI 编码的变迁。如今，单纯从零构建或完全依赖专用软件都难以满足团队需求。真正的未来在于“可塑软件”：一个覆盖数据库、权限、协作等通用需求的稳固底座，加上 20% 的自定义代码来适配独特业务。无论是 Vibe-coding 平台还是 Malleable tools，都在向这个方向演进。对于像蘑菇农场这样的团队，选择拥有稳固底座的工具，再通过 Fibery Custom Apps 等扩展点补充个性化功能，才是平衡效率与灵活性的最佳路径。
稳固的底座应覆盖每个团队的共性需求，而自定义代码则应解决你独特的差异化需求。
HN 评论区
33- watty
这个观点很棒，我完全赞同作者！看看我遵循这些模式的 [INSERT VIBE CODED GITHUB LINK]！
- mickael-kerjean
这就是我开发 Dropbox 替代品 [1] 所走的路径。80% 是专注于文件管理的快速核心，剩下的 20% 通过插件实现，这些插件实现了核心接口之一，因此你可以处理自己的存储、授权、认证、用于处理文件类型的自定义应用等等。有趣的是，各种插件 [2] 中的代码量是核心代码的 10 倍，这些插件旨在满足各种需求，而核心代码本应是那 80%。不出所料，每个人需要的 20% 都不一样。另外，我觉得很酷的一点是，那个需要一个符合 gobd 标准的日志系统的人（该系统拥有大量属性，能让审计人员满意，并强制使用符合 rfc3161 标准的哈希链签名），并没有因为他的特殊需求而让系统对其他人变得更糟糕。
- momojo
非常喜欢这个观点。在生物成像领域，Napari 就是一个很好的例子。它有一个非常稳固的基础，但极其可扩展，因为底层全是 Python。
有个很棒的体验是：同事带着问题走过来，我能在午饭前就快速敲出一个 Napari 插件，完美解决他们的具体问题。
我的“工具升级”顺序通常如下：
- 我能通过 Napari 的内联终端解决他们的问题吗？
- 我能用一个一次性脚本解决吗？
- 我能用一个创建一次性插件接口的脚本解决吗？
- 我应该把这个插件加到我们全公司通用的仓库里吗？因为这个问题似乎经常发生。
- brabel
为什么我们要相信一个之前对无代码（no-code）观点错得离谱的人？
- NoelDeMartin
挺有意思的，我看到这篇帖子是因为我对 Solid Protocol 和 Malleable Software 运动感兴趣，但这篇文章似乎完全没提到这些。
这里有一些相关链接，供感兴趣的人参考：