当每个人都能做 App，那么接下来呢？吐司 2.0 给出了答案

过去一年里，vibe coding 已经变成普通人接触 AI 生产力最直接的方式——不会写代码的人，也可以用自然语言描述需求，让 AI 帮自己生成一个能运行的 App。

但对于真正想做产品的人来说，「生成」只解决了最基础的一步。一个 App 能够运行，并不等于它已经具备了产品价值。只有当创作者开始关心它是否足够好用、运行是否稳定、能不能真正解决用户的问题，以及用户是否愿意长期使用时，这个 App 才有了成为产品的可能。

对于不会写代码的人来说，vibe coding 最直观的变化当然是降低了开发门槛。但如果本来就会写代码，它的价值反而没有那么显而易见。毕竟让 AI 帮忙补一个页面、写一段业务逻辑，如今已经不是什么稀缺能力。

真正耗费开发者时间的，往往是代码之外的那些事情。

一个 App 从功能完成到真正上线，中间还隔着测试、合规整改、隐私政策、软件著作权、App 备案、商店资料、审核提交，之后还要考虑分发与运营。这些事情大多不会直接改善产品的核心体验，却会消耗开发者大量时间和精力。

腾讯旗下的 AI 应用生成平台吐司最近上线了开发者权益包，也是我近期尝试的产品之一。相比于单纯强调「普通人也能做 App」，这次更新更让我感兴趣的，是吐司开始尝试让普通人不仅能做出 App，也能把它真正上架。

▍用吐司做一个「天光时刻」

在展开介绍吐司的功能之前，我想先从一次实际的经历讲起。

经常拍照的人应该都听过「黄金时刻」和「蓝调时刻」。太阳升起和落下前后的光线变化，会直接影响照片的色温、反差和整体氛围。然而，这些绝佳的光影往往稍纵即逝，想要精准「追光」，就极度依赖提前的规划与准备。

大多数天气类 app 都只会显示日出日落时刻

所以我也一直希望能有一款能够展示日月运行和特殊光线时段的摄影规划 App。我希望它既能清晰标注每日的日出日落、黄金时刻与蓝调时刻，也能读取当前位置，并查询未来任意日期的数据。虽然许多天气 App 也包含这类信息，但入口往往藏得很深，想要对比其他数据时只能反复跳转。

所以我决定用吐司来试试。吐司的使用方式很直接：先用自然语言描述需求，它会拆解出功能点并生成预览，之后再通过对话继续修改。吐司目前可以在 Android 和 iOS 端使用，但能够打包并安装为独立 App 的主要是 Android 版本，所以这次我也以 Android 端为例。

我给吐司的第一条提示词只有这样一句话：

需要做一个展示日月事件的 App，比如每天的蓝调时间、黄金时间、日出时间等天文细节有关的数据

吐司接收到需求后，自动拆解出了日出日落计算、黄金时刻、蓝调时刻等核心功能，并很快给出了第一版可交互预览。老实说，第一版已经比我预想中的完成度高。

不过，它距离一个我真的会长期放在手机里的工具还有不小距离。所以基本框架出来之后，我更多是在通过吐司的选取工具配合自然语言，逐步调整第一版中不太满意的界面、信息层级和交互方式。

基本形态敲定后，后续的修改主要聚焦在算法和功能细节上：补上了专业模式开关，让用户可以在简洁视图和详细天文数据之间切换；接入了系统定位权限，直接读取手机 GPS 获取当前位置的天文数据；加入了未来日期查询，方便摄影师提前规划拍摄计划；校正了蓝调时刻和黄金时刻的计算规则，进一步提高时间计算的准确性。

对有开发经验的人来说，用吐司这类的平台很容易有这样的顾虑：

如果我真的想把这个 App 继续做下去，还能不能离开吐司？

很多低代码和 AI 应用生成工具最方便的时候是在开始阶段，但随着产品逐渐复杂，平台本身也可能变成新的限制。如果应用只能继续留在原有平台里维护，那么早期节省下来的开发成本，未来可能又会变成迁移成本。

吐司在这里采用了相对开放的做法。为了满足从个人开发者、小型团队到有更复杂开发需求的不同用户，吐司提供了「基础版 Plus」和「进阶版 Pro」两档套餐。

Plus 和 Pro版本都支持下载生成应用的源代码。所以开发者可以先通过自然语言快速完成原型和 MVP，等到应用逐渐成熟，需要更精细地控制代码结构、性能或者业务逻辑时，再把项目带回自己熟悉的开发环境继续维护。

吐司生成的 Android App 可以直接申请和调用系统定位权限。比如在我的「天光时刻」中，我就可以通过手机里的 GPS 获得当前设备的位置。

不过，定位只是其中比较基础的一项。如果我想继续做下去，后续给「天光时刻」加上账号同步、拍摄提醒、甚至用 AI 分析照片构图。那么吐司目前开放的 30 多项系统、云端和 AI 能力，就能派上用场，不需要自己从零搭后端。相比之下，H5 页面会受到浏览器能力限制，小程序则依赖各自的宿主平台，在系统权限和运行环境上通常没有独立 App 那么自由。

▍为什么要生成安卓 App？

市面上的 vibe coding 产品路径各异。有的生成 H5 页面，需要依赖链接访问，缺少稳定的独立安装入口；有的生成小程序，依赖特定平台容器才能运行；有的生成可操作原型或网站，多用于展示与概念验证。相比之下，网页和小程序更适合快速分享与临时体验；对于每天都要打开的工具，独立安装的形式通常更自然。

吐司则走了另一条路，它能在安卓端生成可直接安装到手机上的 APK。这样生成后的应用也能拥有独立的桌面图标，可以离线运行。分享安装包给别人以后，即使他手机里没有安装吐司，也能像普通 App 一样使用。更重要的是，APK 让应用拥有了独立安装和长期使用的形态，也具备了进入应用商店分发体系的基础。对于希望长期使用的工具来说，这种独立应用形态也提供了比网页或临时页面更稳定的使用入口。

吐司是应用宝孵化的产品，应用宝又是中国最大的第三方安卓应用商店。对开发者而言，做完的 App 可以直接提交到应用宝上架，审核、分发、运营的流程都是现成的，不需要再额外寻找和重新熟悉另一套完全独立的分发渠道。

从 App 到真正的产品，还需要跨越的四道门槛

如果一个 App 只是解决自己的一个小问题，它更像是一个个人工具。比如我做的「天光时刻」，最初只是为了方便自己查看每天的黄金时刻和蓝调时刻。它不需要服务器、不需要账号体系，甚至不需要考虑商业模式，只要能够准确计算对应时间，就已经足够了。

但如果希望它被更多人使用，情况就完全不同了。吐司 2.0 想继续解决的，是 App 做出来之后的事情：怎么完善、怎么上架，又怎么被真正的用户找到。

第一道门槛：让一个 App 具备持续价值

对于很多人来说，AI 生成 App 的第一步已经不难：提出需求、描述功能，AI 就能快速生成一个能够运行的应用。但当这个应用真的交付给别人使用时，新的问题随之出现：

• 它应该免费吗？

• 有没有必要收费？

• 如果不收费，如何承担后续维护成本？

• 如果收费，用户为什么愿意付钱？

在我看来，这也是从「做一个工具」到「做一个产品」之间最大的区别。过去，一个创作者想完整回答这些问题，先要找到一种与产品阶段相匹配的经营方式，再要自己接入支付系统、设计会员体系等等。

问题在于，一旦开始考虑收费，开发者马上就要面对支付、会员权益、结算这些与核心功能完全不同的工作。对于没有技术背景的普通创作者来说，这些事情跟重新写一个 App 的难度差不多。

吐司 2.0 正在搭建的广告组件接入就可以解决这个痛点。简单来说，我可以根据应用所处的阶段，选择更合适的商业化方式。

对「天光时刻」这样的工具，我不会在一开始就加入商业化变现组件。那个阶段它的功能仍然比较单一，保持免费既能维持简洁的使用体验，也更适合验证究竟有多少人真正需要它。

等「天光时刻」进一步完善后，有了稳定的使用场景，比如「天光时刻」在最新版本中支持了专业拍摄规划、天气与能见度分析，甚至针对不同场景给出建议，它就有可能成为一款面向专业用户的垂直工具。对于这类解决具体问题、能够持续提供价值的 App，付费下载会更加合适。

不过，找到合适的商业化方式，只是让一个 App 具备持续价值的第一步。用户愿意持续使用甚至付费的前提，始终是这个应用能够不断回应新的需求。随着用户增多、使用场景不断扩展，原本只需要完成单一任务的小工具，也会逐渐产生数据同步、外部服务接入和智能分析等更复杂的需求。

第二道门槛：从「工具」成长为「服务」

「天光时刻」在我的设想中只需要计算各种时间。我把应用发给几位会拍照的朋友试用后，有人问能不能顺便显示天气和能见度，也有人希望它直接告诉自己「今天值不值得出门拍」。这些反馈已经超出了单纯计算时间的范围。

表面上这些功能看起来只是一个简单需求，背后却对应着完整的开发链路。比如账号登录需要用户体系，数据同步需要后端服务，AI 功能需要接入模型接口，实时信息则需要连接第三方数据源。对于专业开发者来说，这些都是开发过程中需要提前规划的基础设施。但对于通过 vibe coding 创造应用的普通用户来说，它们往往才是从「工具」成长为「服务」时遇到的第二道门槛。

吐司 2.0 的开发者模式开放了更多面向这一阶段的能力，包括大模型接口、多模态能力、云数据库和后端服务等，让应用不再停留在一次性生成的单机小工具，而是具备继续扩展、持续运营的空间。

当它需要走出朋友圈，面向更多陌生用户时，创作者还必须回答另一个更现实的问题：用户应该去哪里找到它，又如何放心地安装和使用它？

直接分享 APK 或许足以完成小范围测试，却很难支撑长期分发。它缺少稳定的下载入口，也难以建立用户信任，更无法获得应用商店提供的搜索、推荐、更新和版本管理能力。要让一个 App 真正进入公共市场，创作者最终仍然需要跨过正式上架这道门槛。

第三道门槛：正式上架一个 App

真正把一个 App 上架到国内的 Android 应用商店时，流程远比安装 APK 复杂。

应用名称、分类要符合规范，简介要通过审核，截图要按尺寸规格提供，权限说明要逐项列出，这些还都只是最基本的信息。进一步还要完成软件著作权登记、App 备案、合规材料准备和隐私政策声明，部分类别还需要额外资质。表面看起来这些事情不涉及一行代码，但流程和逻辑也能耗费一个创作者几周的精力。

而且这些环节又环环相扣，我哪怕只迭代了一部分应用功能，相应的隐私政策、权限说明甚至软著材料都可能需要跟着调整。软著申请本身又涉及复杂的文档整理和格式要求，按普通流程办理，通常需要大约 45 个工作日。如果应用还涉及联网服务，服务器、域名、实名认证以及相关备案之间的关系，也很容易让第一次接触这些流程的人摸不着头绪。

这也是为什么即便有了各种高级能力，很多创作者最后还是选择把 APK 发到群里让朋友手动安装——正式上架的门槛实在太高了。

经过简单的开发者认证以后，就可以使用吐司中的开发者功能了

所以，在我看来吐司 2.0 中最值得关注的功能之一，就是「一站式上架服务」。我觉得这套流程真正省心的地方，绝不仅仅是少填几张表。由于应用本身就是在吐司中完成的，平台可以自动提取应用名称、核心功能、权限调用和数据使用情况等信息，再由 AI 整理和生成对应的上架材料，直接帮助开发者整理应用名称、简介、分类、图标和截图等上架信息，也为后续软著申请、App 备案、隐私政策和用户协议等环节准备对应的所需材料。

到了备案和软著这些更繁琐的环节，吐司也进一步简化了办理流程。备案方面，我可以利用吐司接入的腾讯云相关服务，将服务器、域名认证和 ICP 备案等步骤整合到同一个流程中，降低无经验开发者的备案门槛。软著更是提供了快速办理通道，可以把周期从 45 个工作日压缩到大约 9 个工作日。

应用提交之后，我还可以在吐司里同步看到审核进度，根据审核结果提示补充或修改对应的内容。不必在多个平台之间反复查询规则、整理材料和重复填写信息。

传统流程从准备材料到完成上架，往往需要一个月甚至更长；如果资料齐全、审核顺利，吐司团队表示他们有机会将非联网应用的办理时间缩短到一周左右。

对开发者来说，这还关乎真金白银的成本。过去，找人代办软著、做备案、准备合规材料以及找上架服务，自己搞不定的话，每一步都需要额外花钱。而吐司直接把这些打包进了开发者权益包。虽说不敢保证每个项目都能拿到最低价，但至少把原本零碎的服务费和时间成本合并了，预算会更容易估算。

▍第四道门槛：进入真实市场

准备好上架所需的资料后，下一步就是让应用真正进入用户视野。吐司由腾讯应用宝孵化，这使它有条件把应用生成、资料准备、审核提交和后续分发串联到同一套流程中。在我看来，这也是它与许多止步于生成应用的 vibe coding 产品之间更显著的不同。

对于创作者来说，分发能力往往决定了一个产品能走多远。如果前面的备案、软著和审核算的是合规账，这里对应的就是另一笔获客账。

创作者当然可以自己在社交平台宣传应用，但每获得一个用户，都意味着新的内容生产、渠道维护和传播成本。应用商店至少提供了搜索、分类、推荐、版本更新等相对稳定的发现和分发机制。

除了手机端分发，应用宝还进一步拓展了应用的使用场景。吐司生成的是安卓 APK，但通过应用宝的跨端能力，同一个应用也能够在 Windows PC 上运行，让创作者获得「一次开发，多端触达」的可能。

以「天光时刻」为例，手机端适合在拍摄现场快速查看天文数据，如果用户需要提前规划一次远途拍摄，在电脑上对比不同日期、不同地点的日出日落时间显然更加高效。过去，如果一个移动应用还想覆盖 PC 使用场景，往往还需要额外做适配甚至开发新的客户端；应用宝跨端能力降低了这一过程的开发成本，让更多轻量应用也有机会进入 PC 使用场景。

过去，一个创作者往往需要先投入大量时间完成开发，再等待市场反馈；现在，从生成 APK、完成上架，到获得真实用户反馈，这个周期正在被大幅缩短。即使最终没有形成商业收益，创作者也能更快知道问题究竟出在哪里：需求是否成立、产品是否完善、用户是否匹配，或者商业模式是否需要调整。

如果说吐司解决的是「能不能做出来」，开发者模式解决的是「能不能持续完善并尝试商业化」，那么应用宝解决的就是「能不能进入真实的应用分发生态」。所以，我觉得三者共同构成了吐司 2.0 从一个想法，到一个可以被使用、被验证，甚至被经营的完整链路。

▍总结

回到最开始的问题：当每个人都能用 AI 做出一个 App，然后呢？

在深入体验吐司 2.0 之前，我以为行业迭代的方向无非是「生成界面更快一点」「代码质量更高一点」。但我发现更值得关注的，恰恰是生成之后发生的事情。

吐司 2.0 加入开发者模式、打通云端基础设施，并接入应用宝的上架与跨端生态，相比单纯提升生成速度，我现在更在意的是：App 做出来以后，它能不能继续迭代、完成上架，并最终找到真实用户。

当然，吐司并不适合开发需要处理高并发、复杂权限体系或金融级结算的大型应用。它更适合处理那些具体、分散、垂直的长尾需求。它们可能来自某个行业流程、某个地方社群，或者某个小众兴趣圈层，尽管需求真实存在，却很难支撑一个团队专门去做。吐司的价值，正在于让这些过去容易被忽略的小需求，有机会变成一个个小而美的 App。

所以，吐司 2.0 面向的也不只是想做一个自用工具的普通用户。在我看来，它尤其适合三类希望快速验证需求的创作者：

• 有明确副业想法、想低成本验证 MVP 的普通创作者；

• 熟悉行业工作流但不会写代码的垂直行业从业者；

• 以及本来就有产品判断力、希望快速测试需求的独立开发者或产品经理。
  

值得一提的是，除了帮助个人开发者，吐司的能力也在向小团队与企业级场景延伸。据吐司团队介绍，平台未来还计划面向部分企业客户开放更完整的云端权限、数据隔离和部署能力。不过，这部分尚未对普通用户开放，后续也将仅针对企业客户进行定向对接，但它意味着吐司不仅能生成 C 端小应用，未来还能帮助企业快速搭建员工 OA、AI 客服、数据表单系统、甚至定制化 SaaS 工具。

AI 让创造应用的成本快速下降，但真正决定一个应用价值的，仍然是需求、用户和分发能力。未来 vibe coding 的竞争，比的可能不只是生成速度，更是谁能够帮助创作者完成从想法到用户之间的完整闭环。

吐司 2.0 的开发者模式目前分为 Plus 和 Pro 两档，早鸟价分别是 899 元和 7999 元，有效期为 180 天和 365 天。如果只是想完整走一遍从开发、下载源码到上架的流程，Plus 已经覆盖了主要能力；Pro 更适合准备继续把 App 做下去的开发者，除了各功能额度更高，还增加了广告组件接入、多平台上架辅导等功能。