可塑软件指用户可以自己改造工具来适应自身需求的软件形态。它的对立面是今天主流的封闭应用，功能由远处的开发团队决定，用户只能适应软件。研究者把软件最初的承诺说成一种粘土，实际交付出来的却更像家电，远程制造、密封、不可更改。Ink & Switch 实验室 2025 年发布的长文梳理了这条线索，并用一批可运行的原型验证了可行性。判断一个软件是否可塑，看它能不能让修改发生在使用现场，而不是等下一次发布。
粘土和家电的差距在哪
Alan Kay 在 1984 年把软件称作新材料，用户可以像捏粘土一样塑造它。四十年过去，个人算力翻了几十个数量级，这件事反而离用户更远了。修改权被收拢到少数团队手里，一个工具要适配所有人的长尾需求，成本高到不可能。医生被电子病历的僵化流程拖到倦怠，原因是这个形态本身装不下现场的需求，产品做得再精细也补不上这个缺口。
可塑软件要解决的是修改权的归属。它不要求每个用户都写代码，只要求软件在结构上留出改造的位置。
平缓坡度，从能用到能改的台阶
MacLean 等人在 1990 年的 SIGCHI 论文 User-Tailorable Systems 里提出 gentle slope 模型，说的是从纯使用到深度编程之间不该有一道悬崖，要有一串连续的台阶。
HyperCard 是这个模型最完整的早期实现。1987 年 Bill Atkinson 做出这个 Mac 程序，Apple 随后发布。它把用户分成五个等级，第一级只能看卡片，第五级能写完整的 HyperTalk 脚本。用户可以一级一级往上走，每步只比上一步多学一点东西。后来的电子表格和 Notion 沿用了这个结构。
坡度可以从两端修。降低编程门槛靠更友好的语法、实时反馈的编辑环境、从示例反推规则。提升使用能力则在已经有用的工具里逐步开放可编程性。
一批原型给出的答案
这些原型共享一个底座 Automerge，本地优先的同步库，数据结构本身可以合并，多人的修改能自动收敛。
Webstrates 让浏览器里的 DOM 本身成为共享底座，用户对网页的修改通过 Operational Transformation 同步给其他人，渲染结果只是共同编辑的一种输出。
PushPin 把 React 组件和 Automerge 的 JSON 文档绑在一起，界面显示什么直接由一份可编辑的文档决定。Farm 把代码也当成数据，用 Elm 写工具，源码存在同一个 Automerge 文档里，多人可以并行改同一个工具的不同部分。Patchwork 把两者拼起来，加上历史视图和简单分支，实验室自己的写作和白板大部分已经迁到这里。
Potluck 和 Embark 验证了具体交互。前者让用户定义检测器，从纯文本里识别结构和关系，AI 起草规则，用户在实时环境里改。后者做旅行规划的层次化大纲，把地图位置这样的一等对象放进大纲，拖动条目时地图视图同步响应。
三个设计模式反复出现。平缓坡度是一。工具而非应用是二，应用像牛油果切片器只干一件事，工具像刀可以组合，前提是数据格式能共享。共同创造是三，研究者在公司电子表格里观察到大量业余开发者，他们为自己身边的问题写代码。
现在做不成的原因
最大的障碍是信任。允许陌生人修改你的软件，等于允许他访问软件能看到的数据。当前所有原型都只在小范围可信群体里验证，同事之间可以，公开环境不行。
商业模式跟着失效。工具组合起来不需要为每个功能单独付费，维护和质量由谁承诺就成了问题。个人改的工具也到不了商业产品的打磨程度，用户得先知道手里这份有没有人维护。
还有社会协商。分叉一个工具修自己的问题，和原开发者之间怎么协调，现在没有答案。
常见问题
可塑软件等于用户要学编程？ 不等于。它是留出改造的位置，用不用是用户的选择。坡度低端的设计恰恰是让不编程的人也受益。
低代码平台算可塑软件吗？ 多数不算。它们把用户限制在平台设计者预设的几种组合里，真正的可塑要求用户能改到工具的实现。