绝大多数本可以派上用场的软件，从未被开发出来。
并不是因为技术上做不到，而是因为问题太小。一个用于整理迁移数据、审查一批合同，或协调一项只持续两周的工作的工具，也许能节省很多时间，却仍不足以支撑一个软件项目。设计、开发、部署和维护它的成本，往往比继续使用几张电子表格还高。
代码生成正在移动这条边界。当获得一个可用界面不再需要数周时间，一类无须成为产品的应用便开始出现。它们为一个目标而生，在目标存在期间运行，随后被舍弃。
人们开始把它们称为 single-use apps、disposable apps，或短暂软件。名称尚未统一，但它们提出的问题很有意思：如果创建软件不再是最昂贵的部分，什么样的软件仍值得永久存在？
软件过去必须长期存在
传统软件开发基于一个合理预期：一款应用必须被使用足够多次，才能摊销构建它所付出的成本。
因此，产品总是试图覆盖许多使用场景。它们加入配置项、权限、导入工具、教程，以及面向不同人群的界面。这种通用性让成本可以分摊给成千上万名用户，并延续数年；与此同时，它也迫使每个用户把自己的问题适配到工具上。
一次性需求不符合这套经济账。如果一个团队在迁移期间需要一个非常具体的视图，通常只能把它硬塞进 Excel、拼接多个工具，或申请一项很可能永远排不上优先级的内部开发。
一次性应用把这笔账反了过来。它们不问软件能够存在多少年，而是问：现在生成它的成本，是否低于解决任务带来的价值。当重新构建的成本低于学习、配置和维护一个通用工具时，丢掉结果就不再是一种浪费。
2025年8月，Anish Acharya 用 disposable software 一词描述过去在经济上不值得开发的小型个人应用。他谈的并不是什么格外新颖的代码。新颖之处在于，一件工具可以有价值，却不必追求规模化、商业化或长期存续。
同一个名称下其实有三种不同思路
一部分混乱来自于：运行方式截然不同的系统，都被称为“生成式应用”。
最直接的版本是：生成一个常规应用，用完后再将其丢弃。模型编写初始的 HTML、JavaScript 或后端代码。结果可以像任何其他软件一样运行、检查和修改。它的生命周期短是人为选择，而不是因为它没有代码。
再进一步，则是生成式界面。系统不再总是用文字回答，也不只显示预先设计好的页面，而是针对请求构建恰当的呈现方式：表格、模拟器、图表，或一组组合控件。Google 将这条路线称为 generative UI，并在2025年底通过 dynamic view，开始在 Gemini 和 Search 的 AI 模式中测试。
此时，系统不一定是在生成一个会被长期保留的产品，而是在生成与答案互动的最佳方式。
第三种版本激进得多：用户使用应用时，由模型实时扮演应用的行为本身。
Anthropic 曾通过 Imagine with Claude 探索这一思路。在那项实验中，交互开始前并不存在一套准备完整的功能。Claude 会实时构建软件，并随着新的操作不断调整。后来，其中一部分成果以更克制的形式再次出现：在对话中创建的图表和交互式可视化。
Daniel Mewes 的原型 Mirage 几乎删除了整个应用。模型生成一个页面的 HTML；当用户点击按钮后，它接收这次操作，并生成下一个页面。没有持续存在的业务逻辑负责决定状态转换。模型只是在想象接下来应该发生什么。
在演示中，这三种方法看起来可能完全一样，但从技术上说并非如此。第一种生成软件；第二种在既定能力之上生成界面；第三种则让模型尝试成为软件本身。
一个真正适合这种思路的场景
设想一次基础设施迁移。在几天时间里，团队需要把云资源清单、成本导出数据和负责人名单进行交叉比对，找出无人负责的资源，梳理依赖关系，并形成行动计划。
如果要为这个流程开发永久应用，它就必须支持未来的云服务商、不同的数据结构和大量例外情况，最终会成为一个相当庞大的产品。但眼前的工作边界十分清楚：三个已知数据源、一个小团队和一项明确的交付成果。
一个 single-use app 可以为这组数据生成专门的审查空间，提供针对性的筛选条件，并导出最终计划。迁移完成后，界面不再有用；但修正后的清单、做出的决策和变更记录仍然有用。
这个差别至关重要。应用可以是临时的，但它所处理的事实不应该是临时的。
如果任务有明确的开始和结束、数据受到控制、错误可以被发现，并且最终结果能够保存在工具之外，这种模式就很合适。相反，如果程序本身必须成为记录系统、协调数百名用户，或执行难以撤销的操作，它就没那么合适。
最可行的架构不是一个凭空想象的应用
这种思路最稳健的版本，是将持久层与临时层分开：
目标 + 上下文
↓
为任务生成的界面
↓
获准使用的操作与组件
↓
持久的 API、规则与数据模型决定此刻应该展示哪些信息、哪些控件能够提供帮助。它不能自行决定发票如何计算、谁可以批准付款，或历史记录保存在哪里。这些职责仍由传统服务承担。
可以把它概括为：稳定的核心，临时的界面。
这种分离同时解决了多个问题。数据不会随会话消失；权限不依赖提示词；重要操作可以被验证和记录；界面可以变化，而无须重新生成保存事实的系统。
这也解释了声明式方法为何越来越受关注。Google 于2025年12月将 A2UI 作为开放项目推出，它允许智能体用结构化数据描述界面，再由宿主应用将描述转换成自己已经支持的组件。
模型可以请求一张表格、一个选择器或一份表单，却无须发送任意 JavaScript。产品仍然掌握设计、无障碍和可用操作的控制权。它不如任意生成代码那么自由，但恰恰是这种限制，让它更适合生产环境。
真正困难的问题不是画出页面
生成式界面的演示通常聚焦于视觉元素出现的瞬间。这部分最容易展示，也最能制造新鲜感，但风险并不主要积累在这里。
当界面需要完成真实工作时，真正的成本才开始出现：
- 跨会话保留状态；
- 区分用户和权限；
- 面对相同数据时给出相同的计算结果；
- 在模型故障时继续运行；
- 解释执行了什么操作，以及为什么执行；
- 允许撤销操作或恢复信息；
- 即使界面发生变化，仍保持无障碍、清晰和易懂。
对话上下文不能代替数据库。一个看似合理的预测不能代替状态转换。一个令人信服的界面，也不能证明其中显示的数据来自正确的来源。
Mirage 没有试图掩饰这些限制，所以它把问题展示得很清楚。这个原型会在会话关闭时丢失数据，可能意外修改信息，并在上下文填满后最终失效。作为实验，它很有价值：它展示了模型能够把软件模拟到什么程度。作为架构，它也说明了为什么仅仅模拟还不够。
生成技术降低了第一版的成本。信任、集成和运维仍然有各自不同的成本。
我们最有可能先看到什么
近期的变化不会是应用消失，而是应用中一部分固定页面消失。
拥有高价值数据和 API 的产品，可以根据任务构建不同视图。金融系统可以让账本和权限保持不变，同时生成一个专门用于调查异常的操作界面。运营平台可以把处理某次具体事件所需的控件集中到一个视图中，并在事件结束后删除这个视图。
面向内部长尾需求的软件也会增长：对账、迁移、审查，以及那些从未重要到足以进入产品路线图的临时流程。这些工具不会取代核心系统，而是依托核心系统，解决今天通常落入电子表格的具体环节。
其中一些工具从诞生起就会带有明确的到期时间。项目结束后，凭证被撤销，结果被归档，部署被删除。要让软件真正临时存在，其基础设施和访问权限也必须是临时的，而不只是留下一座无人维护的代码仓库。
产品工作的重心也会改变。团队不再只是设计页面，还必须设计模型可以组合页面的空间：存在哪些组件，允许哪些操作，哪些数据可信，以及哪些状态绝不能被生成。
长期存在仍然有其价值
稳定的界面会形成记忆。使用几次之后，我们知道每项功能在哪里、点击后会发生什么，也知道如何向别人解释整个流程。这种可预测性对于频繁而关键的任务非常重要。
每次会话都生成不同体验，同样会带来成本。它会增加延迟，让支持工作更困难，也会成倍增加需要验证的组合。有时，最好的表单就是一直以来的那张表单，因为数百万人已经知道该怎么使用它。
Single-use apps 并不意味着持续维护的软件将会终结。它们只是扩大了“值得开发”的范围，让那些太小、太短暂或太具体，因而无法成为产品的问题，也能拥有自己的界面。
Web 让大量软件围绕页面组织，移动端则让软件围绕应用组织。生成式界面提出了另一种可能：让一部分软件围绕意图组织——需求先出现，与需求互动的方式随后才出现。
在这些界面之下，我们依然需要不会即兴发挥的系统。问题不在于永久软件和一次性软件二选一，而在于准确判断：当界面已经不存在时，系统必须记住什么。
