扩展
软件的两难困境
Section titled “软件的两难困境”软件通常把用户困在两种模式里，每一种都有其困境。
第一种是完全预设的软件。你只能按设计者的剧本走，功能是固定的，界面是固定的，工作流也是固定的。有些软件可能会提供各种各样的配置，让你按需调整，但这些配置背后是各种因素叠加枚举的结果。它们只是给了你一些不痛不痒的配置选项，你无法跳出这个框架。当你想要一个小改动，或者发现某个细节不符合你的使用习惯时，你只能接受现状，或者寻找另一个”差不多”的替代品。这种模式把用户变成了被动的接受者。
第二种是可扩展的软件，像 VSCode 或浏览器。它们允许你通过扩展来定制功能，但扩展开发复杂得让人望而生畏。平台类软件把人分成开发者与使用者：开发者费尽心思写插件，使用者被动安装。这种分工看似合理，却人为制造了一道壁垒。当你想要实现某个功能时，你得先变身”开发者”：学API，搭环境，写代码，打包，发布。这条路漫长而痛苦，大多数好点子还没成型就胎死腹中。
传统扩展的问题
Section titled “传统扩展的问题”即使你决定走扩展开发这条路，依然会遇到重重障碍。大部分基于 Web 生态的扩展都提供打包好的、对用户不可见的 JavaScript 代码。即使扩展是开源的，从熟悉源码、理解架构、做出改进，再到重新打包、测试、部署，最终变成可用的扩展功能——这条路径依然太长。你需要的不是一套完整的开发工具链，而是一个能立即响应的创作环境。
这导致了一个尴尬的现实：绝大部分已经存在的扩展，因为上述原因，很难进行二次开发，更别提个性化的定制。你发现某个扩展几乎完美，只是缺少一个小功能，或者某个细节不符合你的使用习惯。理论上你可以 fork 它、修改它，但实际操作起来，成本高得让人望而却步。最终，你只能妥协，接受”差不多够用”的现状，或者干脆放弃这个扩展，寻找下一个”差不多”的替代品。
另一个问题在于数据本身。App 可以看作是操作系统的扩展，因为大部分人不具备扩展功能的能力，因此他们不得不使用他人开发的 app。不同的 app 就会有不同的数据方案，这导致你的数据被碎片化地困在不同的 app 和 SaaS 背后。
分工在一定程度上是合理的，专业的工具做专业的事情。但问题在于不可掌控：从长远看来，SaaS 工具很难存活很久，App 也会逐步停止开发。你依赖的服务可能突然关闭，你使用的工具可能不再更新，你的数据可能被困在某个无法访问的地方。如果这些工具都是开源的本地化工具，那么就没有这种担心。再进一步，如果所有的工具都能本地运行且开源，那为什么不把它们合并在一起，减少上下文切换的摩擦阻力呢？这样既能保持专业工具的优势，又能避免数据碎片化和不可掌控的风险。
理想的体验应该像在 Excel 里编写公式一样：你输入 =SUM(A1:A10)，结果立刻出现在单元格里。没有构建流程，没有打包步骤，没有等待时间。代码即功能，所见即所得。这种即时反馈让迭代变得自然，让实验变得轻松，让想法能够快速落地。
这就是 Malleable Software（可塑软件）的核心思想：软件应该像黏土一样，可以被用户随时塑形和改造，而不需要经过复杂的工艺和漫长的等待。在可塑软件中，用户既是使用者，也是创造者。他们不需要在”使用”和”开发”之间切换身份，而是可以在使用过程中无缝地调整和定制工具，让软件真正适应自己的需求。
Eidos 的实现
Section titled “Eidos 的实现”Eidos 把工具聚合起来，解决了数据碎片化和上下文切换的问题。它提供了所有工具的通用能力，例如通用文档和专注结构化数据的表格（实际上就是数据库）作为框架的基底。这样，你的数据不再被困在不同的 app 和 SaaS 背后，而是统一存储和管理，可以被统一的查询、链接和计算。同时，所有工具都在同一个环境中，减少了上下文切换的摩擦阻力。
合并的是基础能力，分开的是扩展需求。Eidos 统一了数据存储、查询、链接和计算这些基础能力，但不同的扩展需求可以通过扩展来实现。这样既能保持专业工具的优势，又能避免数据碎片化和不可掌控的风险。
在此基础上，Eidos 提供了一个所见即所得的扩展开发体验。扩展不再是外挂，而是软件的 DNA。你可以直接在里面写代码，实时看到效果。没有构建流程，没有打包步骤，没有等待时间。这种即时反馈让迭代变得自然，让实验变得轻松，让想法能够快速落地。
AI 的加入让这一切变得更简单。创造工具的门槛从未如此之低。当你想要实现某个功能时，AI 可以帮助你生成代码，解释逻辑，优化实现。这种协作让可塑软件的理念真正落地，让每个人都能成为自己工具的创造者。
Eidos 的扩展分两种：Script 处理数据逻辑，Block 处理界面交互。