AI时代，人人都能自定义软件功能

Cloudflare的首席工程师Jeremy Morrell坦言，他常用的阅读应用完全无法满足这些个性化诉求。他理想中的软件，应该能实现这样的场景：只需要简单描述需求，就能自动生成对应的代码片段，挂载到软件预留的扩展接口后直接运行，还能便捷地分享给有同样需求的用户。这就是他心中的可扩展软件。

在Morrell看来，当前绝大多数Web软件都是“静态”的——这里的静态并非指网页技术本身，而是指软件的逻辑无法被用户修改，功能在发布时就已经定型，用户只能被动使用，无法自定义。而AI技术的普及正在改变这一现状，让普通用户也能定制属于自己的应用，不再是遥不可及的梦想。

小众功能的死结：为什么你想要的功能永远无人开发

很多时候，你在某个应用里想要的小功能，并不是技术上做不到，而是投入产出比太低。因为全世界可能只有你一个人需要这个功能，开发者的时间和精力有限，只会优先服务最大的用户群体。

即便开发者想覆盖所有需求，也会受到界面复杂度的限制：每新增一个功能，都会给不需要该功能的用户增加使用负担。如果一个功能的受众只有几百人，却会让数百万普通用户的产品体验变差，这显然是不划算的。这两条约束，就是过去二十年来产品经理一直难以解开的行业死结。

以地图应用为例，绝大多数用户的核心需求都是基础导航服务，但右侧的长尾需求则是每个人各不相同的个性化设置，比如定制化的路线偏好、小众地点标注、专属的导航播报规则等等。

不过随着AI辅助编程的普及，这种局面正在被打破。用户不再需要成为工程师就能打造专属工具，制作只服务少数人的小软件的成本已经低到可以忽略不计，Y Combinator的Pete Koomen将这类工具称之为“小软件”。

无论是会计、医生、律师还是其他数千种职业，都可以拥有完全贴合自身工作流的专属小软件。显然，想让更多人用上智能体工具，不能指望把所有人都培养成工程师，真正需要改变的是软件本身的形态。

自定义代码的门槛降低，但部署的难题仍在

当普通用户也能通过AI快速生成自定义代码后，新的问题随之而来：写完的代码该放在哪里？目前不少Web产品提供的webhook接口门槛极高，需要开发者独立搭建整套服务，还要处理投递过程中的各类异常问题。

Morrell指出，要让陌生代码在系统中安全运行，需要突破五道关键关卡：

第一关：成本控制

如果有百万用户都挂载了自己的代码，给每个用户单独分配容器的成本完全无法负担。Morrell提出的标准是：代码未被调用时成本趋近于零，每次调用的成本压低到几分之一美分，还要兼顾编译、存储文件、日志收集等额外开销，最终单台服务器能承载的用户数量完全取决于内存占用。

第二关：冷启动速度

用户代码如果卡在请求响应的关键路径上，不能等待数分钟启动容器，理想的启动时间应该控制在个位数毫秒。当然，如果只是运行定时任务或事件回调，这个要求可以适当放宽。

第三关：资源限额

永远无法预判用户会写出什么样的代码。Morrell分享了一个在Heroku听到的真实案例：一份热门的入门教程教新手部署第一个程序，代码只有两行，一个死循环不断打印hello world。一个应用上线后瞬间开始每秒输出数百万行日志，且永不停歇，而新手还在等待屏幕上出现正常的日志内容。因此，必须对CPU占用、内存使用、网络请求数量、请求大小、日志输出频率等各项指标设置严格上限。

第四关：双层隔离

用户的代码如果出现崩溃、死循环或过度占用内存的情况，不能影响其他用户。恶意代码不能突破隔离边界窥探其他租户的数据，还要防范Spectre这类推测执行攻击。

第五关：代码的实用性

不能让用户的代码只能空转，必须让它能够访问到必要的系统资源和数据，否则就毫无价值。

从给钥匙到给权限：安全的代码调用模式

如何让不可信的代码正常工作，又不会泄露系统的核心权限？Morrell拆解了业内的三代解决方案：

第一代：直接暴露API密钥

这种方式的灵活性极强，但风险极高。拿到密钥的代码可以随意向第三方服务发起请求，即便代码本身没有恶意，也可能被用于发起分布式拒绝服务攻击。

第二代：添加中转代理层

用户拿到的是不透明的令牌，仅对代理服务有意义。代理验证令牌后替换为真实凭据转发请求，同时可以添加白名单和限流规则。这种方式比直接暴露密钥更安全，但维护成本很高：要将权限收窄到允许特定操作，需要在代理中编写复杂的过滤逻辑，还要随着上游API的更新持续维护。Morrell曾展示过一段示例代码，仅仅实现“读取一封已批准的邮件”这一个操作，代码就已经冗长且难以维护。而且这类过滤逻辑永远无法覆盖所有用户的使用场景，你永远猜不到用户会如何使用权限。

第三代：能力模型（Capability）

这才是真正的解决方案：不提供密钥，也不暴露服务地址，而是直接给用户代码传递一个预先定义好的专属函数。比如只开放“取回已批准的邮件”这一个动作，用户的代码只能执行这一项操作，无法访问其他任何资源。用户代码手中只有这些有限的函数，系统凭据从未进入用户代码的执行环境，即便拿到了数据也没有通道可以向外传输。

这种模式还有一个额外的好处：将TypeScript编写的能力定义提交给大模型，比传递OpenAPI格式的JSON更节省令牌且结果更准确。因此，真正的门槛不再是让AI生成代码，而是决定这段代码能够访问哪些资源。

四种实现路径，没有绝对的最优解

其实让软件支持自定义扩展的思路已经存在了二十年，但大模型的出现改变了谁能够编写扩展代码。Morrell列出了四种主流的实现路径：

最轻量级：嵌入式解释器

比如Lua、QuickJS这类轻量级解释器，也可以根据需求自定义开发。这种方案的资源占用极低，但安全性和隔离性相对较弱。

V8 Isolates

Google在V8的安全加固上投入了大量资源，直接使用V8 Isolates可以省去自行开发安全隔离层的成本。目前Cloudflare Dynamic Workers、Node的isolated-vm、Rivet的secure-exec都是基于这种方案。

MicroVM

这类方案砍掉了完整虚拟机中不必要的硬件模拟，比如USB、显卡、磁盘等，只保留核心运行环境。隔离性极强，可以运行二进制代码并支持完整的POSIX标准，但资源开销明显更大。Firecracker、libkrun都属于这一类。

WASM + WASI

WebAssembly从设计之初就没有内置网络请求、环境变量读取等能力，所有权限都需要宿主程序显式授予。从安全角度看这是最理想的起点，但对应的工具链复杂度也更高。

这四种方案并非互斥的，可以组合使用：比如WASM可以运行在V8 Isolates或MicroVM中，即便使用V8或WASM作为隔离边界，MicroVM也可以在编译打包、测试扩展的环节发挥作用。Morrell自己就曾将静态博客改造成一个演示平台，自嘲为“世界上最小的vibe coding平台”，本质上是一个可定制的网页抓取工具，用户可以输入URL，抓取内容后结合预先授予的工具运行自定义代码。

十年前的失败构想，被AI重新激活

十年前，现任Cloudflare Workers技术负责人的Kenton Varda就曾推出过Sandstorm.io创业项目。该项目的核心主张在当时显得有些超前：用户打开的每份文档都运行在专属的沙箱实例中，程序只能获取用户主动授予的权限，不发放密钥，只提供有限的能力。但这个项目最终未能成功，Varda后来复盘认为，失败的原因是当时没有足够的自动化工具，用户需要手动打包软件，极大的学习门槛劝退了大多数人。

2026年8月5日，Cloudflare以Apache 2.0协议重新开源了这套方案，命名为Cloudflare OS。当年缺失的自动化能力，如今已经被AI技术补上。Varda当天在社交平台上表示，这几乎是他酝酿十年的计划的最终落地。

软件正在变得更“柔软”

OpenAI在《Codex as a Platform》中提出的智能体框架也表达了同样的思路：与其让每个团队都使用通用的编码助手，不如将智能体嵌入到他们日常使用的软件中。无论是工程流程工具、运维仪表盘、安全调查平台还是客服控制台，都可以快速集成智能体功能。

这种模式的分工非常清晰：应用方负责提供界面、业务上下文、工具和审批边界，框架则负责智能体循环和沙箱执行。OpenAI的示例应用Relay将智能体集成在货运仪表盘旁，接入平台自带的MCP工具，改签机票前必须经过人工审批，完美展示了这种模式的应用场景。

现在不少公司都在鼓励员工通过vibe coding打造专属工具，但方向正确不代表没有后续难题：当企业内部出现成百上千个自定义工具后，谁来维护？如何保证工具只访问必要的数据？访问令牌的权限范围由谁制定、如何定期轮转？会不会有工具偷偷将客户信息写入第三方日志？如何符合GDPR等数据合规要求？

Morrell给出的答案是：为用户提供一个根本没有令牌可以泄露的部署环境，将数据访问的权限交给平台团队统一管理，确保合规性。

如果这种模式真的普及，产品经理的工作也将发生改变：他们不需要再覆盖所有的长尾用户需求，但必须设计稳定的扩展点、能力接口，并长期保证兼容性。如果厂商不主动开放扩展入口，用户就无法自定义软件。

Morrell在平台行业已经深耕近十年，他坦言平台的设计、运维和调试都极具挑战性：对外暴露API意味着需要大量的前期规划和长期的技术支持。但他依然认为这是值得的，因为用户的创造力会远超你的想象，他们开发出的功能可能是你从未设想过甚至认为不可能的。

或许在不久的将来，判断一款应用好坏的标准之一，就是看它允许用户自定义修改的程度有多深。