AI 时代的小程序来了,软件开始在使用中长出来

从 ChatGPT Intelligent UI 到 Claude Mods，看需求、开发与使用的新关系

四个人一起吃饭，账单 600 元，先算下来，每人 150 元。

接着有人说，自己没喝酒；还有人已经把钱转给了垫付的人。一个简单的除法，又变成了几条分账规则。

你请 AI 帮忙，它可以算出结果。如果回答里直接带着一个能填金额、调人数的小工具，后面再有变化，就方便多了。

ChatGPT 最近推出的 Intelligent UI，已经把分账工具作为官方展示案例。Claude 则推出了 Mods，让用户给 Agent 增加自己的功能。

看着这两种尝试，我想到一个熟悉的东西：小程序。这一次，工具有机会随着使用产生。

一、回答开始成为工具

10 月 7 日，OpenAI 发布 Intelligent UI。ChatGPT 可以根据问题，把文字、图表、按钮、表单和交互工具组织成一个回答。^[1]

这让“问一个问题”之后的动作发生了变化。

比如，请 AI 比较几种方案，最初可能只得到一张表。接着，你想调一个参数，看排名如何变化。

有了可以操作的界面，这些调整就能直接完成。对话用来表达意图，界面用来精确选择，二者可以接着用。

OpenAI 先准备了原生组件库，模型负责决定怎样组合，编译器在生成过程中逐步显示界面。^[1]

按钮和图表像一盒现成积木，AI 根据眼前的问题，把它们搭成一个可以操作的界面。

我觉得，分账器这样的例子，比一张更漂亮的回答截图有意思。

它让人马上试一试。改个数字，看看结果，再问一句，理解问题和处理问题接在了一起。

二、Agent 可以现场增加功能

Claude Mods 往另一个方向走了一步：用户可以改造 Agent 的工作环境。

Mods 运行在 Claude Code 中，扩展界面主要显示在终端和 Claude Desktop 的 Code 标签里。^[2]

官方举了一个很直观的例子：增加一个面板，显示当前上下文用了多少。

所谓上下文，可以简单理解为 AI 在这段会话中能够参考的信息。聊得越久、处理的文件越多，就越有必要看清它的占用情况。

用户可以用自然语言描述想要的功能，让 Claude 写出 JavaScript 或 TypeScript 代码，在当前会话中加载。

用起来后继续提出修改，代码改完，这一轮结束时就会重新加载。^[3]

这种方式把功能设计变成了对话的一部分。先要一个简单仪表，觉得看得不够清楚，再让它换一种显示方式，或者增加变化趋势。

Mods 还可以增加命令、调整工具调用与工作流程。^[2] 一个扩展可以承担一个局部操作，也可以把你习惯的工作方式带进 Agent。

Intelligent UI 围绕当前问题组织回答；Claude Mods 让用户扩展 Agent 的界面与行为。

前者更接近日常问答，后者更接近定制工作环境。但它们都把一件原本发生在开发阶段的事，带到了使用现场：根据用户眼前的需要，决定功能该长成什么样。

三、AI 时代的小程序，新在哪里

用过微信小程序的人，对这种便利并不陌生：不必离开当前环境，点开一个轻量工具，就能完成点餐、缴费或预约这样的具体事务。

过去，通常是开发者先定义功能、写好代码、发布应用，用户再来使用。用户可以填写内容、切换选项，也可以提出反馈，但反馈进入产品，往往要等下一轮开发。

现在，有些需求可以直接成为生成工具的依据。“帮我做个分账器”或者“在这里加一个用量仪表”，既是在表达使用目的，也是在定义软件功能。

ChatGPT 是按问题组合界面，Claude Mods 可以直接编写扩展代码。生成之后，你就能像使用普通工具一样，填写金额、调整选项、查看结果。

我认为，真正值得关注的是：用户开始更直接地参与软件的形成。

一些需求过去很难获得专门工具。它可能只属于一个人，只用于一次活动，或者只有某个团队才需要。找现成软件，功能往往太多；专门开发，又很难说服自己投入时间。

当 AI 能更快地把描述变成可操作的东西，这类需求就有了新的实现方式。用一次的工具可以用完放下，好用的功能可以留下来，继续修改，逐渐成为个人工作环境的一部分。

以前，你要在一排现成工具里，找最合适的那个。现在，多了一种办法：把要做的事情说出来，让 AI 给你搭一个。

拿准备一次周会来说，你可能只需要三个区域：上周完成的任务、这周要处理的事项、需要同事帮助的问题。

用了一次，发现还想加上负责人和截止日期，就继续修改。功能可以围绕这次会议生长，无须一开始就规划一套完整的项目管理系统。

与此同时，Agent 也需要更丰富的交互。任务越复杂，人越难只靠一长串聊天记录看清发生了什么。一个进度面板、一组可调整选项、一处直观的结果展示，都可能让协作更顺手。

自然语言适合表达目标，按钮和表单适合明确选择。把它们放在一起，人能够一边和 Agent 讨论，一边操作具体结果。

回到开头的分账器。用过一遍，你发现还想记录谁已经转账，于是再加一个选项。提出需求、实现功能、试用结果，开始挤进同一段对话里。

四、再往前看：需求与开发，正在越来越近

Vibe Coding 流行以后，很多人第一次体会到：说出想法，等一会儿，就能看到可以运行的东西。遇到问题，继续描述，软件便接着修改。

用户很难在用到产品之前，把所有需求说清楚。需求如何变成功能，使用中发现的问题又怎样带回开发，一直是软件开发要处理的问题。

瀑布式开发以阶段为主线：分析需求、设计、实现、测试、交付。它努力在前期把问题说明白，再组织后续工作。需求与实现之间，通常隔着文档、评审和不同角色的交接。

原型开发让想法更早变得具体。先画界面，或者做一个可以试用的版本，让用户对着它讨论。

很多时候，人看见按钮、流程和结果，才发现自己遗漏了什么，或者之前说得不够清楚。

敏捷把反馈更频繁地带进交付。先做一个较小的增量，交给用户使用，再调整后续工作。及早交付、响应变化，在 2001 年的敏捷宣言中就已经被明确提出。^[4]

这些方法至今可以组合使用。它们之间的一条共同线索，是让需求尽早面对具体结果，让反馈及时改变开发方向。

AI 协作开发进一步降低了把初步想法做出来的成本。一个界面、一段逻辑、一个可运行的版本，可以更早进入讨论。开发本身，也就更直接地帮助人发现需求。

比如，你最初只想做个任务列表。用起来才发现，需要按截止日期排序；再用几天，又发现需要区分自己与同事的任务。这些后续需求，是人与具体软件互动时形成的。

于是，工作节奏可以变成：说清目标与约束，选一个小范围，做出版本，体验和验证，再更新需求，继续迭代。

每做出一版，团队就多知道一点：哪些规则已经确定，哪些地方还得调整，下一版先解决什么。需求文档也跟着更新，记录这些已经形成的共识。

2025 年，Karpathy 在写 MenuGen 的开发经历时提出过一个设想：有些应用，能否由一段提示触发，再由模型直接用网页呈现出来？^[6]

今天的按需界面与现场扩展，让这个问题有了更具体的产品形态。

以前，一个只属于四个人、一顿饭的小需求，很难值得专门开发。现在，它也有机会得到一个顺手的工具。

用过以后再改，改到合适就留下来。提出需求的人，也更直接地参与了设计。

当需求可以在使用中表达，功能可以在使用中生成，软件开发就开始成为使用过程的一部分。