应用发布
把 Agent 生成的成果从「本机可运行的 Demo」变成「别人打开就能试用的入口」的那一步——它解决的不是功能问题，而是部署、登录、数据这一整套「落地」问题，因此是 MVP 从内部自嗨走向外部验证的分界线。
简介
应用发布指的是 AI 产品/Agent 平台把生成产物一键变成可被他人访问、可被真实使用的形态。典型形态包括创建试用版小程序、发布可访问的 Web 应用、生成分享链接等。它与”代码生成""原型生成”处在链条的不同位置：生成解决”我做出来了”，发布解决”别人能用上”。
这中间卡住的从来不是功能，而是”落地”三件套——部署、登录、数据。过去用 AI 做 Demo 最常见的断点是：Demo 在自己电脑上跑起来了，想交给别人体验还得另外处理部署；发截图、录视频虽然能介绍功能，但用户只有亲手操作，才更容易说清哪里不顺手、哪些功能真正有用。应用发布把这一段折掉之后，产物的性质发生了变化：它不再是”带后端的演示”，而更接近一个带后端数据逻辑、支持用户登录使用的 MVP 产品。
对早期产品验证来说，收益不只是省了部署功夫：MVP 交付时间缩短 → 更早交给用户试用 → 更早拿到真实反馈，人也才能把精力放在判断”哪些功能真正有帮助、下一版该改什么”。这使它成为 MVP 方法论在 AI 时代的自然延伸——MVP 的核心是”用最小代价验证核心假设”，而发布能力直接压缩了”验证前的等待时间”。
需要注意的是：应用发布降低的是交付摩擦，不是验证质量。发布出来的东西仍需有人判断哪些反馈值得采纳；“能打开”并不等于”被验证”。
关键信息
- 类型：概念 / 产品能力 / 交付机制
- 领域：AI Agent · 产品交付 · MVP 验证 · 低代码/无代码发布
- 典型形态：创建试用版小程序 / 发布可访问链接 / 一键部署（含登录与数据层）
- 核心收益：把”发给别人用”的成本从一次工程任务降到一次点击；缩短 MVP 到真实反馈的周期
- 相关概念：MVP、WorkBuddy、60 分原型原则、AI 执行环境、样板田
核心特性
Demo 与「可试用产品」的分界线
| 维度 | 本机 Demo | 应用发布后的产物 |
|---|---|---|
| 访问方式 | 只有自己电脑上跑 | 一个可分享的入口，别人打开就能用 |
| 数据 | 常为假数据/本地文件 | 带后端数据逻辑 |
| 身份 | 通常无登录 | 支持用户登录使用 |
| 反馈质量 | 靠截图/视频转述 | 用户亲手操作后指出哪里不顺手 |
| 交付成本 | 需另找地方部署配置 | 预览区一键创建试用版 |
判据可以浓缩成一句话：“这个产物能不能被不是你的人，在不需要你讲解的情况下打开并使用？“
为什么它改变的是验证节奏而非功能
- 早期产品验证真正稀缺的不是功能数量，而是真实反馈的次数；每多等一天，就少一轮判断”该改什么”的机会。
- 发布让”给用户看一眼”从工程任务（搭环境、配数据库、做登录）变成日常动作，于是试错轮次增加。
- 反过来说，如果一个团队发布很轻松却没人愿意打开，问题多半在需求侧而非交付侧——发布能力会放大这个问题，因为它让”没人用”变得无法再用”还没部署好”来解释。
与相邻概念的区别
- vs 原型：原型用于内部沟通与方案对齐，发布产物用于外部验证；
- vs PoC：PoC 验证技术可行性（当然前提是它不带登录与数据），发布产物验证”用户愿不愿意用”；
- vs “做个 Demo 看看”：Demo 的验收标准是”能演示”，发布的验收标准是”别人能用”。
常见的伪发布
- 发布出来的仍是只读演示（无数据写入、无登录），用户点两下就退——拿到了”能打开”，没拿到”能验证”；
- 发布到位但没有回收入口（没有反馈渠道、没有埋点），试用的价值随时间流失；
- 把发布当成终点而非起点，忽略了发布之后”下一版改什么”的决策环节。
不同素材中的观点
- 2026-09-24-woshipm-workbuddy-one-line-requirement-mvp（欧阳俊杰）：首次把”应用发布”作为独立能力面记录下来。作者在 WorkBuddy 里按 PRD 做出第一版面向英语老师的教学工作台小程序后，需要交给用户实际体验，而”这也是过去用 AI 做 Demo 时最麻烦的一步”；借助 WorkBuddy 新增的应用发布能力，点击小程序预览区域右上角的分享 → 选择创建试用版小程序，直接得到一个可访问、可使用的小程序，省去另外找地方部署配置。他给产物定性的一句话最具价值：“WorkBuddy 给我的不仅仅是一个 demo，已经说一个带后端数据逻辑，并且支持用户登陆使用的 mvp 产品——从 Demo 到能真正用起来的产品，差的往往不是功能，而是部署、登录、数据这一整套’落地’的东西。” 收益也被落在节奏上：“MVP 的交付时间缩短了，就能更早交给用户试用、获得真实反馈，我也可以把更多精力放在判断哪些功能真正有帮助、下一版应该改什么上。“这条素材把 MVP 页既有的”分发策略”讨论（H5 零摩擦 vs 小程序 vs App）往前推了一步：过去选型是在”自己做发布”的前提下比较摩擦，现在发布本身被平台内化，摩擦的量级改变了。
实用信息
- 快速上手步骤：① 用 Agent 按 PRD/方案完成第一版开发；② 在预览区域找分享入口（如右上角分享 → 创建试用版小程序）；③ 确认产物是否带登录与数据层（这一步决定它是 MVP 还是 Demo）；④ 把入口发给真实目标用户，并要求他们亲手操作后再反馈；⑤ 回收反馈，转成下一版的功能判断。
- 发布前自检：是否有登录？是否有真实数据读写？别人是否可以无需我讲解就打开？反馈从哪里回来？
- 注意事项/避坑：① 不要把”能打开”当成”被验证”；② 试用期产物涉及用户数据时，先想清楚数据存放在哪、谁能看；③ 发布成本极低时，警惕”发得越多、验证越少”——每一版都应对应一个明确的待验证假设。