AI降低了软件开发门槛，但协作场景仍需复杂功能。文章探讨了AI时代“可塑软件”的最佳形态：是每次从零开始编码，还是基于一个稳固基础，通过自定义代码进行灵活调整。

好的，这是根据您的要求，对原文进行的中文重述，保留了核心细节，并删减了与主题无关的冗余内容。

标题：可塑软件 = 坚实基础 + 自定义代码

作者在生产力工具市场观察了22年，认为当前市场正经历剧变。AI降低了软件开发门槛，任何人都能通过“氛围编码”快速构建解决个人问题的小应用。但当涉及团队协作时，事情变得复杂，需要处理数据存储、权限、通知、历史记录等一系列功能。

这引出一个核心问题：在AI时代，可塑软件的“热点”在哪里？是每次都从零开始用AI编码，还是应该有一个坚实基础，再通过自定义代码进行定制？

以一家10人规模的蘑菇农场为例，他们需要管理软件。市场太小，没有现成的专业工具，通常只能用谷歌表格凑合。作者分析了五种选择，但每种都不完美：

1. 从零构建：用Claude Code或Codex等工具。问题在于需要操心托管、认证、数据库等所有底层细节，前80%容易，最后20%很难。
2. “氛围编码”：用Lovable或v0等平台。比前者好，自带托管、数据库和部署。但一旦需求超出平台能力，就会陷入困境。
3. 低代码/应用构建器：如Retool、Softr。它们提供了“坚实基础+自定义代码”的框架（认证、权限、托管），但这是“应用基础”，而非“工作基础”。数据通常存在别处，缺乏协作、评论、变更历史等功能。
4. 在可塑工具中组装：如Notion、Fibery。能快速获得许多现成功能，但定制能力有限，无法满足特定流程需求，缺乏足够的扩展点。
5. 购买专业工具：如果流程匹配且无需定制，这是好选择。但一旦需要灵活性，它就不再专业。

核心论点：80%坚实基础 + 20%自定义代码

作者认为，理想方案是拥有一个覆盖80%通用需求的坚实基础（数据库、权限、历史、协作、通知等），然后允许用户通过自定义代码来扩展和混合这些功能。因此，市场正朝这个方向演进：“氛围编码”和低代码工具在增加坚实基础，而可塑工具则在增加扩展点。

坚实基础：过去，坚实基础只有编译器和操作系统。现在，我们有更高层次的抽象。坚实基础应覆盖所有团队都相同的部分（如技术基础、应用基础、工作基础），而自定义代码则覆盖使你的团队与众不同的部分（如独特的界面、业务逻辑、外部连接）。

自定义代码：这20%的代码量虽小，但定义了公司的独特性。AI让代码回归，赋能低代码/无代码工具解决定制化问题。自定义代码要工作良好，必须满足两个条件： * 继承基础：自动继承基础的权限、历史和数据完整性。 * 有边界：自定义代码只能影响自身，不能破坏基础，且应易于回滚。

市场走向：程序员过去虽有完全的表达能力，但构建个人工具耗时。现在AI缩短了配置时间，使可塑软件对非技术用户也变得友好，从而能更频繁地击败专业工具。所有工具都在争夺“高表达能力+短构建时间”的绿色区域，但路径不同： * “氛围编码”工具需要构建基础。 * 可塑工具需要增加表达能力。 * 低代码工具两者都需要。

给当前用户的建议：如果是个人使用，可以尝试“氛围编码”。如果专业工具能覆盖90%流程，就购买。但对于像蘑菇农场这样流程不断演进的团队，建议从可塑工具开始，因为其基础（批次、订单、历史、权限）已经存在，缺失的20%功能正变得越来越容易通过“氛围编码”实现。一个重要的原则是：选择你的基础，而不是界面。数据、历史和权限会不断积累，难以更换，而UI正变得廉价且易于替换。

总结：作者在2019年押注无代码，而2025年代码以出人意料的方式回归。现在，界面可在几分钟内生成，而构建坚实基础仍需数年。因此，作者的新押注是： * 坚实基础 + 自定义代码将赢得生产力市场。 * 可塑工具有最大机会率先到达，因为添加扩展点只需几个季度，而构建坚实基础需要数年。

根据评论内容，主要围绕“构建可扩展的坚实基础（solid base）”这一核心观点展开讨论，不同评论者从实践、理论和批判角度提供了多元视角。以下是总结：

主要观点与论据

1. 支持“坚实基础+可扩展插件”模式 - 核心论据：80%的通用功能作为基础，20%的定制需求通过插件或自定义代码实现，避免“一刀切”的臃肿系统。 - 关键引用： - “The 80% is the fast core that focus on file management, the remaining 20% is coming via plugins... everyone needed a different 20%.”（mickael-kerjean） - “Having that working base that agents can then customize from... often much faster and predictable compared to starting from scratch.”（genatron_ai）

2. 框架与工具的具体实践 - 核心论据：多个项目（如Filestash、Napari、Abject）通过插件系统或协议实现可扩展性，强调“基础层稳定，上层灵活”。 - 关键引用： - “Napari is a great example... wonderfully solid base, but extremely extensible since its just python all the way down.”（momojo） - “I’ve been building Abject as a malleable base for custom code... built on top of a protocol I created called the Ask protocol.”（mempko）

3. 对“坚实基础”概念的批判与反思 - 核心论据：部分评论认为“坚实基础”本质是“库生态系统”或“框架”的变体，且历史已有类似实践（如Unix哲学）。 - 关键引用： - “A 'solid base' is just another name for 'a library ecosystem'.”（oulipo） - “Those who don't understand Unix are condemned to reinvent it, poorly.”（contingencies，引用Henry Spencer）

4. 对作者可信度的质疑 - 核心论据：评论者质疑作者此前在“无代码（no-code）”领域的错误预测，认为其观点缺乏可信度。 - 关键引用： - “Why should we believe someone who was so extraordinarily wrong about no-code before?”（brabel）

平衡性说明

• 支持方：多数评论者（如mickael-kerjean、momojo、genatron_ai）通过实际项目验证了“坚实基础+插件”模式的有效性，强调其灵活性和效率。
• 质疑方：brabel对作者历史预测的质疑，以及oulipo、contingencies对概念本质的批判，提醒需警惕“新瓶装旧酒”或过度依赖单一模式。
• 中立观察：marcosdumay指出该预测“与世纪之交以来的做法一致”，暗示其并非创新。

总结

评论整体认可“构建可扩展的坚实基础”作为软件开发的实用策略，但对其创新性存在争议。支持者强调其解决定制化需求的能力，质疑者则指出其本质是已有模式的复现。作者的可信度因历史预测失误受到挑战，但多数实践案例仍支持该方向的有效性。