一个十人的小组要举办一个三天的客户workshop，需要收集议题、认领时间、上传讲义，还要检查谁还没填表。在以前，没有人会为这三天的流程去请工程师写一个网页系统。光是配置代码库、数据库、权限和服务器所花费的时间，就比这个活动本身还要多。大家通常会用共享的表格、文档和表单来做一个临时的台账，然后派人在群里催，手工核对数据。
当写代码和托管部署的成本都降低之后，这个成本结构就发生了变化。现在只要在聊天框里用自然语言描述清楚字段和逻辑，几分钟内就能拿到一个带数据库和登录功能的在线应用，直接把链接丢进群就能用。于是软件又多了一个一次性软件层。因为写代码和上线维护的边际成本都接近于零，专门为一次决策或短期协作造一个工具反而比在表格里手工维护更划算。当年在线共享文档淘汰了把初稿打出来传阅的习惯，如今用户生成软件也在淘汰为小流程专门排期立项。
有人会问，这种流程用腾讯问卷加共享表格不也能凑合？如果只是收一份名单，问卷确实够了。但收完答案之后的协调它管不了：谁认领了哪个时段、两个人撞了怎么办、讲义传到哪、谁还没填、什么时候该催。状态一多，表格和群聊又变回人工对齐。问卷负责把答案收上来，一次性软件接手的是收完之后的协调：那张需要人盯着更新的表格，和群里反复对齐的工作。
聊到这些产品的时候，很多技术同学会有两个困惑，一个是我感觉周围的人都没有在用这种建站工具，另一个是我感觉大厂们进场只是为了凑热闹，可能没有真实的需求。这两点都来自于软件的分发方式的改变。我们日常协作里面，发链接的人不会特意说明这个网站是什么平台做的。但大家经常在微信群里打开一个网址，填上信息之后就把网页关了。这个过程跟填写一份腾讯问卷差不多。填写表格的人并不会觉得自己是问卷平台的用户。点击小工具的同事也不会意识到下面的建站平台。做工具的人一个月可能只生成一两次页面，后续的交互都在这条链接里完成。这种用完即走的分发方式造成了没有人在用的错觉。一次性软件不是还没到来。在愿意为 AI 付费的人群里，它已经成了日常，只是没人把它当成软件。
这个判断不是今天才有的。2025 年 11 月，我们写过《超越 DRY》和《一次性软件》：前者判断交付物会从成品变成生成内核，后者判断为一次决策专门造工具会变划算。当时它更像一次提前的推演，工具散落在各个独立平台里，没人说得清它什么时候、以谁的入口变成主流。一年之后，ChatGPT Sites 把建站变成聊天里的日常动作，Lovable 的订阅收入证明个人愿意为这种小工具持续付费。市场开始印证这次推演。
经营对话建站平台，这笔账比普通软件复杂。普通软件大多服务单一画像的买单人；对话建站要同时面对三类付费者：个人长尾用户、企业内部采购、专业开发者。三类人之外，还有平台自己的一本账。四本账凑在一起，掏钱买的却是四样东西，各自不愿意买单的部分也完全不同。
个人长尾用户买的其实是省事。他们参照的是腾讯文档这类共享表格，不知道数据库在哪里，也不关心服务器如何维护，出问题就找平台，所以只为省心花钱，不愿为底层可靠付费。用户一旦看见配额和运维就会走，不会学。Lovable 的年化经常性收入达到 4 亿美元，其中大约 95% 来自个人和小团队的月度订阅，可见长尾本身是大生意。靠低单价月费来平账，平台得把单用户支持成本打下去，把运维、备份、迁移和配额全藏起来，用极低单价覆盖生成和托管成本。
企业内部采购算的是另一本账，他们买的是治理。个人用户嫌烦的后台细节，在企业里都是合规硬门槛：身份认证、权限隔离、数据驻留、内网连通和操作审计，缺一项都过不了安全审查。企业愿意为这套可控性签下高价合同，却不会为生成速度更快多掏钱，因为没有合规兜底，前端生成得再快也无法在公司内部上线。
专业开发者买的是退出权。企业希望平台把环境全管起来，开发者却防备自己困在黑盒里。他们动手前先看退路：代码能不能完整拿走，数据能不能顺畅迁出，项目能不能接入现有的代码自动测试发布流水线（CI）和自有云服务。开发者愿意为不锁定付费，却不会为封闭托管掏钱；一旦发现代码或数据拿不走，他们会因为锁定直接拒绝入场。
第四本账是平台自身的商业模式。它决定的是平台愿意承诺什么，而不是买什么。按账号卖订阅座位、按项目卖建站额度、按消耗卖算力，三种收入结构对可靠性的容忍度不同。座位制靠轻度使用摊平成本，额度制把收入放在生成环节，算力制按实际消耗收费。收入结构不同，平台愿意为稳定性担保背多少成本也就不同。
把这四本账合在一起看，平台很少默认做生产级兜底，原因不在技术，全看谁愿意为可靠性掏钱。个人用户不会为可靠性多付钱，平台要是默认包揽全套运维保障，只会白白增加支持成本。只有把工具接进正式业务的企业客户，才愿意为权限治理和可靠性担保付钱。顺着个人与企业这两种不同的付费需求，对话建站的产品路线自然走向分叉。
过去四年，一次性软件走过了四个阶段。每一代产品都在补上一代留下的缺口，补缺的工程取舍又顺带分出一条独立的产品路线。单靠一张横向功能表给市面上的建站工具打分，很容易看丢真正的主线。早期困扰普通人的环境配置与代码模板，随着脚手架逐渐变成标准商品沉入产品底层，已不再构成壁垒。各家真正拉开差距的地方，是每一代补缺都要回答三个问题（平台状态归属）：程序跑在谁的地盘上、数据存在哪、访客的身份由谁提供。答案不同，路线就分开了。
第一阶段是文档工具，代表是 Notion、Airtable 和挂脚本的 Google Sheets。传统文档只能展示图文，无法记录数据变化和实现交互。这一代补齐了读写和交互，让非技术人员也能做小工具、做跟踪、做表单、做简单审批。但依然要求用户具备工程思维：得自己设计表格、定义角色权限、设置规则。业务流程一复杂，表格+脚本的维护就接近传统软件开发。
为了解决这个痛点，第二阶段走向了聊天产物，典型代表是前端生成工具 v0 和 Anthropic 推出的 Claude Artifacts。用户在对话框中用自然语言描述想要实现的功能，模型直接写出前端代码，在聊天窗口旁边实时渲染一个可交互的网页界面，并一键生成分享链接。这一步省去了设计字段和拖拽布局的繁琐过程，用自然语言跨过了界面门槛。但纯前端预览也带来了新的问题：页面没有数据库支撑，没有真实用户登录，也没有历史版本与上下线管理。这类纯前端预览没有后端支撑，无法直接承载多人共享、持续读写数据的业务流程。
第三阶段是独立全栈平台，Bolt.new、Lovable、Replit Agent 与 Manus 是代表。它们补上了数据长期保存和用户登录认证的缺口；其中 Manus 还提供内置分析、自定义域名与版本回滚。面对同一个后端与数据缺口，不同平台用了不同补法，由此分出不同路线。
第一条路是把运行环境和存储直接藏在聊天平台后面。比如 ChatGPT Sites 和基础设施厂商 Cloudflare 合作，生成的网页应用跑在按需启动的无服务器计算环境 Workers 上，配一个轻量关系型数据库和对象存储，通过配置文件声明绑定关系。应用发布分成保存候选版本和在原网址原地替换两段动作，让用户几乎感知不到底层运维。
第二条路是粘接现成的后端服务。Lovable Cloud 基于开源后端平台 Supabase，预先配好数据库、认证、存储和云函数，也允许连回用户自管项目。Bolt Cloud 内置关系型数据库与认证功能，并支持外接同一套开源后端。Google 的 Firebase Studio 则完全走自家生态，由 Gemini 生成应用后直接对接自家的托管与认证服务。
身份方面，在线编程平台 Replit 提供了 Replit Auth，可以让用户用 Replit 账户登录，也可以换成第三方身份服务 Clerk。OpenAI 也有 Sign in with ChatGPT，适合公开网站做身份层，它提供了登录登出的按钮，验证后把访客的姓名和邮箱放进请求头传给服务端，用来判断权限，这样公开网站可以允许未登录访问，同时登录后又能提供个性化功能。
交付的边界分成两条路。前端云平台 v0 生成 Next.js 源码，一键部署到用户自己的 Vercel 账号下，登录交给 Clerk 或 NextAuth 处理，平台本身不托管身份，便于工程团队接手维护。深圳创业公司 YouWare 走向社区分发，用作品流与社交机制把生成的网页做成可浏览、可改编的内容作品。
独立全栈平台补齐了数据库和登录，却很快撞上企业落地的阻碍：它们孤立在企业原有组织架构和高频办公入口之外，每做一个内部工具都要额外配库或注册账号，很难融入日常办公流。于是行业进入第四阶段，手握对话入口与企业账号的大厂进场收编，把全栈托管能力收进自家的办公工作区。Anthropic 把聊天里的 artifact 升级成跑在自有基础设施上的企业级托管应用，直接连接企业内部的多个数据源。OpenAI 在今年七月开放 ChatGPT Sites 公测，秋天推出企业正式版，具备五档受众权限、站点级定时更新、读取访客授权数据的站点插件与内网私有隧道。按 OpenAI 开发者大会披露的已部署站点口径，该平台托管的站点已达 800 万个。同时，通用代理平台 Manus 的新一代版本用付费常驻云电脑与事件触发补上后台运行能力，支持由邮件、广告数据、日历、即时通讯工具 Slack 或协作文档 Notion 的事件触发全天候自动化任务。GitHub Spark 在预览不到一年后，于 2026 年 8 月停止接纳新用户与新建应用。此前，传统建站商 Wix 已于 2025 年年中收购 Base44。走到这一阶段，现成的组织身份与后台常驻能力，正式成为平台的护城河。
回顾这四步演变，这些产品分化的路线其实对应着前面算过的四本账：个人图省事，所以选全托管；企业要治理，所以选平台身份、数据驻留和内网；开发者想退出，就选代码归自己；社区要分发，就选作品流。看清这层映射，再去看具体产品，判断标准就清楚了。
如今，基础模型的代码生成能力趋于同质化，所有厂商在生成第一分钟时都能做出同样惊艳的 demo。一个工具三个月后能否持续使用、融入团队流程，不再取决于第一屏的效果，而取决于身份、数据、运行时这三个位置由谁掌控。
第一，身份。身份绑在企业聊天/工作区或编程平台账号上，内部协作最方便，但外部访客受平台规则限制。比如 ChatGPT Sites 目前无访问口令、邮箱域名门槛或链接过期机制，未注册用户只能访问公开站。基于 Supabase/Clerk 可自建用户体系。第二，数据。支持连自管库，外部工具能读写备份。ChatGPT Sites 的版本回滚只恢复代码，不恢复数据库与已上传文件；发布失败时，数据库可能已部分写入。第三，运行时与自动化。ChatGPT Sites 有两处独立缺失：无公开发布/管理接口，不能像 Manus 那样用公开接口把建站嵌入外部流水线；项目导出没有官方文档。
把这三个位置落到实际选型上，动手前只要问三个问题。第一，访客是谁？公司内部十几个同事协作，而且团队已经开通了企业工作区，直接用内置托管最省心，现成的权限和内网隧道能省掉大半审批；如果是发给外部客户用，就不该绑定特定厂商的账号。第二，未来要不要迁出？三天工作坊收集议题用完就扔，锁在哪个平台上都没有损失；但如果是准备交给工程师继续迭代的早期原型，从第一天起就应该选 v0 配自己的云账号，或者在独立平台里挂载自己管理的数据库。第三，有没有后台常驻需求？公开文档里，站点级常驻或定时能力并不普遍；如果业务需要全天候监听邮件、定时拉取数据或者自动触发工作流，就得提前核实平台支不支持站点级定时任务，或者直接选带付费常驻环境的代理平台。把这三个归属问题想清楚，不管市面上再冒出多少新名字，都能一眼看清它的真实边界。