Wabi不再只帮你造App

Wabi把“造一个App”改成了“替你持续办事”

Wabi在9月29日重新调整产品定位：这家原本主打“用提示词生成App”的公司，正在把产品改造成一个以消息为入口的个人AI Agent。根据 TechCrunch 当天披露的信息，新版Wabi试图在同一套体验里合并聊天、按需生成的应用界面，以及可以持续运行的任务。

个人AI Agent是能够理解目标、调用工具、保存状态，并跨越多轮对话继续执行任务的个人软件代理。 它和普通聊天机器人的关键区别，不是回答更长，而是能不能在用户离开对话框之后继续推进事情，并在需要确认、补充信息或交付结果时重新找到用户。

动态界面是由AI根据当前任务即时生成或组合的交互界面。 它不是预先写死的“首页—列表页—详情页”，而是让表格、卡片、表单、图表、按钮等组件随着任务变化出现：比较航班时给你筛选器，整理预算时给你表格，审批操作时再出现确认按钮。

持续任务是能够跨会话保留状态，并按照时间、事件或外部数据变化继续运行的任务。 例如“每周一整理本周会议并提示冲突”不是一次问答，而是一条包含触发条件、数据权限、执行步骤、失败重试和通知机制的长期工作流。

这次转型的核心并不是Wabi增加了一个聊天框，而是它改变了“App”在产品中的位置。过去，用户输入提示词，目标是获得一个相对独立、可以打开和使用的小应用；现在，用户先把需求交给Agent，App式界面只是Agent完成任务时临时调出的交互工具。

换句话说，Wabi原来卖的是“生成软件”，现在想卖的是“交付结果”。

App从成品变成了Agent的界面零件

Wabi的新方向可以概括为一句话：聊天负责表达意图，动态界面负责高密度交互，持续任务负责跨时间执行。 这三者并非新概念，但过去通常分散在聊天助手、低代码工具和自动化平台里，Wabi现在试图把它们压缩到一个用户入口中。

纯聊天界面的问题在于，它适合表达模糊需求，却不适合承载所有操作。用户可以用一句话说“帮我比较这五个方案”，但真正做决策时，仍然需要排序、筛选、勾选和查看差异；如果AI继续用十几段文字回答，信息密度和可操作性都会迅速下降。

固定App界面的问题在于，它必须提前假设用户会做什么。开发者需要先定义页面、字段、按钮和流程，而现实任务经常只使用其中一小部分功能。动态界面反过来处理这件事：先理解任务，再只生成当前步骤需要的控件。

持续任务则补上了聊天产品最容易断裂的一环。多数AI对话在输出答案后就结束了，但真实工作常常包含等待、监控和追踪，例如等待价格变化、定期汇总数据、催收未完成事项，或者在某个条件触发时继续下一步。

因此，Wabi的转型不是从“应用生成器”简单退回“聊天机器人”，而是尝试把应用生成能力藏进Agent内部。用户不再需要先想清楚自己要造什么App，只需要说明自己想完成什么目标。

新旧Wabi的区别不在模型，而在任务闭环

Wabi此次公开报道没有披露底层模型名称、上下文长度、任务成功率、生成延迟或新的收费方案。截至2026年9月29日，可确认的变化主要集中在产品形态，而不是一组新的模型跑分。 对开发者而言，这意味着现阶段不宜把它理解成一次基础模型升级。

| 对比维度 | 旧定位：提示词造App | 新定位：个人AI Agent | 实际影响 | |---|---|---|---| | 用户入口 | 输入需求并生成应用 | 以消息会话持续交互 | 使用门槛更低，但对意图理解要求更高 | | App的角色 | 最终交付物 | Agent按需生成的动态界面 | 界面可能是临时的，也可能随任务变化 | | 任务周期 | 以一次生成、修改和发布为主 | 强调跨会话、持续执行 | 必须处理状态保存、调度和失败恢复 | | 交互方式 | 页面、表单和组件 | 对话与组件混合 | 比纯聊天更适合比较、确认和批量操作 | | 数据连接 | 为生成的应用配置数据 | Agent按任务调用数据与工具 | 权限边界和审计难度上升 | | 性能指标 | 生成速度、页面可用性 | 任务完成率、恢复能力、通知及时性 | 评价标准从“像不像App”转向“事情办没办成” | | 公开价格 | 本次报道未披露调整 | 本次报道未披露调整 | 暂时无法判断长期任务的成本结构 |

这张表揭示了Wabi真正承担的技术债务。生成一个能展示的页面，和可靠执行一项持续数天的任务，是两个难度等级完全不同的问题：前者失败了可以重新生成，后者失败可能意味着错过会议、漏掉订单，甚至执行了不该执行的操作。

Wabi也因此需要从“生成质量”转向“系统可靠性”。动态界面偶尔排版不好，用户通常还能接受；持续任务如果重复发送通知、错误修改数据或在授权过期后静默停止，产品信用会迅速归零。

它瞄准的是聊天助手、造App工具和自动化平台之间的空白

Wabi的新定位横跨了三类产品：通用AI助手、提示词应用生成器和工作流自动化平台。它的机会在于减少工具切换，它的风险则是同时继承三类产品最难解决的问题。

| 产品类别 | 典型入口 | 价格与计费形态 | 性能评价重点 | 核心特性 | 主要短板 | |---|---|---|---|---|---| | 新版Wabi | 消息会话+动态界面 | 新方案尚未公开 | 持续任务完成率、界面生成速度、状态恢复 | 聊天、App式界面和长期任务合并 | 可靠性与权限机制仍需实际验证 | | 通用AI助手 | 聊天、语音、多模态输入 | 通常为免费层、订阅层及用量计费并存 | 推理质量、响应延迟、工具调用成功率 | 知识问答和通用任务覆盖面广 | 复杂任务仍容易停留在“给建议” | | 提示词造App工具 | 项目工作区、编辑器、预览窗口 | 通常按订阅、生成额度或计算资源计费 | 首次生成成功率、修改效率、部署稳定性 | 适合快速制作可独立访问的应用 | 用户仍要承担产品定义与维护工作 | | 自动化平台 | 流程画布、触发器和动作节点 | 通常按任务次数、连接器或团队席位计费 | 触发准确率、执行成功率、重试能力 | 确定性强，适合固定业务流程 | 搭建成本较高，对模糊需求不友好 |

Wabi相较于提示词造App产品的优势，是用户不必先扮演产品经理。用户想解决“找出本月异常支出”这个问题时，不需要先描述一个财务看板应该有几张页面，Agent可以先读取数据，再按结果生成分类表格和确认控件。

Wabi相较于纯聊天助手的优势，是界面不必被压缩成自然语言。自然语言适合下达任务，却不是最好的数据操作方式；让用户在一句长回复里寻找三个候选项，通常不如直接给出可排序的卡片和对比表。

Wabi相较于传统自动化平台的优势，是它可以先理解模糊目标，再逐步收敛为流程。传统流程工具要求用户明确知道触发器、条件和动作，而Agent可以通过追问补齐参数，例如先确认预算、截止日期和允许操作的数据范围。

不过，Wabi并没有因此自动获得护城河。动态界面、工具调用和持久化工作流都可以被大型AI助手或现有应用生成平台吸收，真正难复制的是用户长期积累的任务上下文、连接器权限、执行历史和个性化规则。

真正的技术难点不是“生成几个按钮”

Wabi要兑现个人Agent定位，至少需要同时解决五个系统层面的问题。这些问题决定了产品是可长期依赖的助手，还是只能用于演示的生成式界面。

1. 动态界面必须可控，而不是让模型随意输出前端代码

可靠的动态界面通常不会让模型每次都自由生成整套应用代码。更现实的方式，是让模型从受控组件库中选择表格、表单、图表、日期选择器和确认框，再输出结构化的界面描述，由客户端负责渲染。

这种做法类似于让AI搭积木，而不是让它现场烧砖盖楼。组件受到类型、权限和交互规则约束后，界面一致性更好，也更容易避免模型生成危险链接、隐藏按钮或未经验证的输入逻辑。

2. 持续任务必须有明确的状态机

长期任务不能只依赖聊天记录，因为聊天文本无法可靠表达每一步是否已经执行。系统需要保存任务当前状态、下一次运行时间、已使用的数据、等待用户确认的步骤，以及失败后的重试策略。

一个“每天检查价格并在低于500元时提醒我”的任务，至少包含定时触发、数据获取、条件判断、去重和通知五个环节。如果系统忘记上一次已经通知过，用户可能每天收到同一条消息；如果系统没有记录数据来源，用户也无法判断结果是否可信。

3. 工具权限必须按动作拆分

Agent的权限不应该只有“允许访问”和“禁止访问”两档。读取日历、创建日程、删除日程是三种风险完全不同的动作；查看邮件、起草回复、直接发送邮件也不应共享同一授权级别。

Wabi如果要承担持续任务，就需要提供细粒度授权、操作前确认、权限有效期和随时撤销机制。尤其是删除、付款、发布和对外发送等高风险动作，默认要求人工确认比追求全自动更合理。

4. 失败必须对用户可见

Agent最危险的状态不是明确报错，而是悄悄停止工作。连接器失效、登录状态过期、网站结构变化和模型判断错误，都可能让持续任务中断。

成熟的个人Agent应当显示任务最近一次运行时间、执行结果、失败原因和下次计划，并允许用户重试或修改规则。一个没有运行日志的持续任务，本质上只是不可观察的黑箱。

5. 成本必须能被预测

持续任务会把一次性推理成本放大为长期成本。一次对话可能只调用模型几次，但一个每小时检查数据的任务，一天会触发24次，一年则可能触发8760次；如果每次还要访问多个外部工具，计算与连接器成本会继续累积。

Wabi尚未在本次报道中公开新定价，因此最值得关注的商业问题不是月费本身，而是后台任务如何计量。按消息收费不适合持续Agent，按任务运行次数收费又可能抑制高频使用，订阅额度与超额计费的组合更符合这类产品的成本结构。

Wabi为什么现在必须转向

提示词造App正在迅速变成一项基础能力，而不是一个天然独立的产品类别。模型的代码生成能力、可复用组件库和托管部署服务持续成熟后，“输入一句话生成页面”越来越像演示入口，难以单独支撑长期留存。

用户真正愿意反复使用的，通常不是某次生成出来的页面，而是页面背后的任务。预算看板的价值不在于它有几张图，而在于数据会不会自动更新；旅行规划工具的价值不在于卡片是否漂亮，而在于价格变化后能不能及时提醒并重新给出选择。

Wabi此次转型因此有明确的产品逻辑：把容易商品化的界面生成能力降到后台，把更有黏性的任务历史、个人上下文和持续执行推到前台。只要用户积累了几十条规则、多个数据连接和一套稳定习惯，迁移成本就会高于迁移一个单独生成的App。

但这也是一场更难的竞争。个人Agent的直接对手不只是一批AI应用生成器，还包括操作系统级助手、拥有大量用户入口的通用AI产品，以及控制企业数据连接的自动化平台。

这次转型值得关注，但还不能只看演示下结论

Wabi的新方向比“再做一个提示词造App工具”更有价值，因为它抓住了生成式软件的下一步：用户并不想不断制造新App，用户想让软件随任务出现，并在任务结束后退回后台。

动态界面尤其可能成为Agent产品的重要交互层。纯聊天把一切变成文字，传统App又把一切固化成页面，而动态界面允许系统在“自由表达”和“结构化操作”之间切换，这比单纯增加语音、头像或更长回复更接近真正的产品进步。

持续任务则会决定Wabi能否从新鲜工具变成日常基础设施。一个Agent能连续可靠运行30天，比它在30秒演示中生成一个漂亮界面更重要；任务完成率、重复执行率、人工接管次数和错误操作率，也比传统代码生成跑分更值得观察。

现阶段对Wabi最合理的判断是：方向成立，兑现难度很高。聊天、动态界面和持续任务的组合确实比孤立的App生成器更接近个人计算入口，但只要权限、审计、失败恢复和成本控制中的任何一项没有做好，它就会退化成一个会生成卡片的聊天机器人。

接下来应重点观察四项信息：

• 任务是否真的可以离线持续运行，而不是必须保持页面打开；
• 动态界面是否来自受控组件系统，以及能否被用户保存、修改和复用；
• 高风险动作是否默认要求确认，并提供完整执行日志；
• 定价是否覆盖长期任务成本，以及任务次数、模型调用和外部连接器如何计量。

Wabi这次没有放弃“造App”，而是把造App从目的改成了手段。如果这条路线成立，未来的个人软件可能不再是一排固定图标，而是一段持续存在的对话，以及在恰当时刻出现的界面。

参考来源

• Vercel AI SDK GitHub仓库：用于理解生成式界面、结构化输出和工具调用等技术背景，不代表Wabi采用了该项目。
• assistant-ui GitHub仓库：展示Agent聊天界面、工具调用状态和前端组件组织方式，可作为动态交互层的技术参考。
• LangGraph GitHub仓库：用于理解有状态、可恢复和长时间运行的Agent工作流，不代表Wabi使用其技术栈。

事件事实依据为TechCrunch于2026年9月29日发布的Wabi转型报道；按照本站外链域名规则，文末未收录其链接。