夜雨聆风
AI 时代,App 还有出路吗?
点击蓝字
这两年，做产品的人多少都有一点不安。
这种不安，不是因为软件突然没人用了，也不是因为手机、电脑和应用商店会一夜之间消失，而是因为用户寻找产品、使用产品的方式，正在悄悄发生变化。过去，当一个人有需求时，他的第一反应通常是：“这件事该用哪个 App？”于是，他会去找图标、打开软件、进入页面，在菜单和按钮里寻找功能入口，最后一步步完成操作。可现在，越来越多人的第一反应已经变成了：“我直接告诉 AI，我要做什么。”然后，他期待系统自己理解目标、选择工具、串联步骤，最后把结果交回来。
下面这位就是这种方式
表面上看，这只是交互方式变了；但如果往深里看，你会发现，变化的根本不只是交互，而是入口、路径，以及软件被发现和被调用的方式。至少从当前公开的官方生态看，OpenAI 仍在持续推进 Apps SDK，Apps SDK 明确以 MCP server 作为能力暴露的基础，UI 则是按需补充的承接层；另一边，Skills 也已经被正式定义为一种可复用的能力包，用来把 instructions、resources 和 optional scripts 组合起来，让模型更可靠地完成一类 workflow。
也正因为如此，越来越多开发者开始焦虑：AI 时代，App 还有出路吗？未来会不会真的是 Skill 的天下？今天还在做 App，会不会其实已经慢了半拍？如果一定要变，那 App 又该怎么平滑过渡，而不是把过去积累的产品、用户、品牌和分发体系全部推倒重来？
这些问题都不是假问题，但它们特别容易被回答得太极端。有人说，未来所有 App 都会被 AI 吃掉；也有人说，所谓 Skill，不过就是换个名字的插件，最后用户还是会回到 App。这两种说法都有情绪，但都不够接近现实。
我更愿意给出一个不那么刺激、却更接近真相的判断：未来不会是“App 消失、Skill 接管一切”的世界，但未来一定会是“所有产品都必须学会 Skill 化”的世界。真正发生变化的，不是 App 会不会彻底死掉，而是 App 的价值，正在从“页面和按钮”，迁移到“能力、数据、流程、信任和结果”。
说得再直接一点，App 不会消失；但只靠页面和按钮活着的 App，会越来越难。这，才是今天所有开发者都必须面对的现实。
一、真正让 App 感到危险的，不是 AI 很强，而是“入口变了”
很多人一谈这个问题，就喜欢先讨论模型有多强、上下文有多长、推理有多猛。这当然重要，但它不是最根本的变化。真正更大的变化，其实是：用户不再总想先找工具，再完成任务；用户开始更习惯先说任务，再让系统去找工具。
在移动互联网时代，一个产品要成立，首先要解决的是入口问题。你得先让用户找到你。用户找到你之后，还要理解你，理解你的导航结构、页面层级、菜单设计、设置逻辑，最后他才有机会真正用到你最核心的价值。换句话说，过去的软件世界有一个默认前提：用户必须先学会你的结构，才能拿到你的结果。
这件事，在过去是理所当然的，因为没有更好的办法。可 AI 出现之后，事情开始变了。用户越来越不愿意先学结构，也越来越不愿意自己走路径。他更愿意直接说一句：“帮我把这件事做完。”当这种习惯一旦形成，软件世界最先被改变的，不是功能本身，而是入口本身。
OpenAI 当前的 Apps SDK quickstart，本身就非常能说明这种变化。官方不是先从“做一个页面”讲起，而是先让开发者搭一个 MCP server，把能力注册给系统。UI 不是先决条件，而是按需补上的承接层。也就是说，在新的调用体系里，能力先被发现，界面再按需出现；工具先被理解，页面再来承接复杂交互。
这意味着什么？意味着软件未来竞争的第一战场，可能不再只是“谁的页面更顺手”，而是“谁更容易被找到、被理解、被调用，并最终完成真实任务”。以前，你只要把页面设计得足够顺，用户就会愿意在你的软件里完成整条流程；以后，用户可能连你的页面都不想先看一眼，他只在乎一件事：我说一句话，你到底能不能把这件事给我做成。
这就是为什么，今天很多工具类 App 会让人产生一种说不上来的“笨重感”。不是它不好，也不是它没价值，而是用户会越来越自然地问：明明我只是想改个格式，为什么还要先打开软件，再导入文件，再设置参数，再点执行，再等导出？明明我只是想看一个状态，为什么还要进入页面，再翻栏目，再切 tab，再手动筛选？明明我只是想做一件小事，为什么非得先学习你的产品结构？
当这种疑问越来越普遍，App 真正的压力就来了。所以，今天让 App 感到危险的，未必是 AI 抢走了所有功能，而是 AI 正在重写用户对“怎么获得结果”的预期。过去，用户愿意为结果走流程；现在，用户越来越希望系统替他吞掉流程。这，才是入口变化的本质，也是今天所有产品焦虑的源头。
二、Skill 为什么会突然重要起来？
如果只从字面看，Skill 很容易被误解。很多人会觉得，它无非就是插件、脚本、快捷指令、API 包装层，听起来像是旧东西换了个壳。但真正重要的，从来不是名字，而是它代表的软件组织方式。
前文我们写过 AI Agent Skill 简述
Skill 真正的意义在于：它把原来藏在页面里的能力，重新整理成了可被模型理解和调用的任务单元。
过去，我们做软件，最习惯的思维是“做页面”。我要放一个按钮，我要做一个设置区，我要加一个菜单，我要把某个功能藏在二级页还是三级页，我要把参数放在弹窗里还是侧边栏里。这些思路在过去完全没问题，因为用户是沿着页面在走。可 AI 时代，模型并不沿着页面走，模型是沿着“目标—判断—调用—执行”在走。于是，过去那种“页面是组织核心”的软件方式，就开始暴露出一个问题：页面可以让人理解你，但页面不能天然让模型理解你。
模型理解你的前提，不是你页面做得多好，而是你有没有把自己的能力边界说清楚。它需要知道：你是干什么的，什么情况下该调用你，你适合解决什么问题，你不适合解决什么问题，你要什么输入，你会给出什么结果，失败时怎么办，边界在哪，风险在哪。
这就是为什么 Skills 在当前官方体系里，不是一个无足轻重的小点缀。OpenAI 的官方文档写得很清楚：一个 skill 会打包 instructions、resources 和 optional scripts，让 Codex 更可靠地遵循一条 workflow；而且模型不会一开始就加载所有 skill 的完整内容，而是先看每个 skill 的 metadata，再决定要不要进一步读取完整的 SKILL.md。系统并不是靠“硬塞上下文”来理解你的能力，而是先通过 name、description 和边界信息来做调用判断。
你会发现，到了这里，所谓 Skill 的本质就出来了。它不是“新功能”，也不是“新皮肤”，更不是模型顺手能用一下的附属品。它真正的意义是：它让软件第一次以“能力单元”的方式，正式进入 AI 的调用体系。
因此，Skill 之所以重要，不是因为它更新潮，而是因为它刚好适配了新的入口逻辑。用户现在越来越习惯说目标，而模型需要根据目标来选择能力。谁能把自己的价值写成模型能识别的形式，谁就更容易在这个新入口里被调用。未来值钱的，不只是“你有什么功能”，更是“模型知不知道何时该用你”。
三、未来真的会是 Skill 的天下吗？
如果你只想要一个情绪值拉满的答案，那最方便的说法当然是：“是，未来没有 App，只有 Skill。”这种话传播起来很爽，但大概率不对。
我更愿意说：不会是“纯 Skill 的天下”，但一定会是“全面 Skill 化的时代”。
这两个判断，只差几个字，含义却完全不同。前者的意思是，未来所有软件都失去界面，用户再也不需要 App；这显然不现实。因为大量高价值场景，本质上就是需要界面的。设计软件需要可视化编辑，视频软件需要时间轴和预览，运营后台需要复杂表格和密集状态，财务系统需要确认、审核、追溯，数据平台需要图表、筛选、对比和批量处理。这些东西，不可能全都压进一段自然语言里，也不可能只靠一轮对话就安全、准确地完成。
所以，界面不会消失，App 也不会消失。但另一层变化同样真实：未来几乎所有软件，都必须学会把自己的核心能力整理成可以被 AI 发现、理解、调用和组合的形式。这一点，几乎是躲不过去的。因为用户不会总是从你的图标进来，也不会总是先打开你的页面。他可能从聊天框进来，从搜索进来，从系统助手进来，从 IDE 进来，从 agent 进来，甚至从另一个平台的自动化工作流里调用进来。
这也是为什么 MCP 会在最近这段时间里变得越来越重要。MCP 的官方规范把它定义为一个开放协议，用来让 LLM 应用与外部数据源和工具实现无缝集成；而在 tools 规范里，又明确说明 servers 可以暴露 tools，让语言模型与数据库、API、计算流程或现实世界动作发生连接。说白了，MCP 解决的是“模型如何标准化接入能力层”的问题，而 Skill / Tool 解决的是“哪些能力可以被接入、被调用、被组合”的问题。
所以，未来的软件竞争，不会只是谁 UI 做得漂亮，也不会只是功能堆得多。未来的软件竞争，越来越像一场关于“任务完成率”的竞争：谁更容易被模型选中，谁更容易被系统接入，谁更容易在复杂场景里稳定交付结果，谁就更容易活下来。未来不是 App 和 Skill 的二选一，而是所有产品都要长出 Skill 化内核。
四、为什么 App 仍然不会消失？
这是整篇文章里最容易被说错的地方。因为很多人一看到对话式交互兴起，就容易得出一个轻率结论：既然用户都可以直接说需求了，那界面还有什么用？这个结论听起来顺，但站不住。
因为我们使用软件，从来不只是为了“把动作做完”。很多时候，我们还需要看见过程、确认结果、修改参数、理解边界、回溯错误、管理历史、建立信任。而这些东西，只靠一段对话，是不够的。
AI 很擅长拉起流程，但当任务变复杂、变关键、变高价值时，用户仍然需要一个更稳定的承接层。这个承接层，很多时候就是 App。不是因为 App 天生高贵，而是因为它特别适合承担四类角色。
第一类角色，是复杂信息的承接者。
聊天很适合开始，却不适合承载所有细节。一旦结果里涉及大量字段、历史记录、图表变化、版本差异、批量文件和复杂状态，用户最终还是要回到结构化界面里去看，否则他根本不放心。
第二类角色，是状态和权限的管理者。
真正的产品，不是一次性交付一段答案，而是要长期保存设置、历史、账户、授权、偏好、配置和版本。这些事情天然更适合由 App 和服务层来承接，因为它们需要可追踪、可恢复、可撤销、可管理。
第三类角色，是信任和品牌的容器。
用户愿意让系统动他的文件、动他的数据、动他的订单、动他的设备，前提往往不是“模型很强”，而是“我知道背后是谁”。我知道这是谁家的产品，我知道出了问题去哪里找，我知道它会怎么提示风险，我知道它的权限边界是什么。这种信任，不会凭空长出来，它通常要靠一个清晰、稳定、可识别的产品形态来承载。
第四类角色，是商业化和长期关系的载体。
订阅、会员、设置、统计、售后、分析、增长、留存，这些事情至少在相当长一段时间里，仍然更适合围绕 App 或 Web 控制台展开。Apple 目前仍把 App Store 作为应用发现、下载、提交审核和分发的重要基础设施；官方说明中也持续强调，提交到 App Store Connect 的 apps、updates、bundles、in-app purchases 与 events 都会经过 review，以提供安全、可信的体验。
所以，真正合理的未来图景，不是 Skill 干掉 App，而是：Skill 负责调用，App 负责承接。前者更像入口层和执行层，后者更像控制台、信任层和关系层。谁把这两者对立起来，谁就很容易误判；谁把这两者打通，谁才更像真正看懂了下一阶段的软件形态。
五、真正会被淘汰的，是“只有页面、没有能力沉淀”的 App
如果一定要说，什么东西会在 AI 时代被迅速压缩价值，我认为不是 App，而是那种只有页面外壳、却没有能力沉淀的 App。
这类产品过去其实很多。它们往往不是没有用，甚至在某一阶段还挺赚钱。因为过去的软件世界里，光是把一串操作包成一个产品，就已经很有价值。用户不会自己做，也懒得自己做，更找不到更简单的方法，于是，谁把流程包起来，谁就有机会获得用户。
但现在，情况开始变了。AI 天然擅长做一件事：把“用户一句目标”，翻译成“系统内部一串操作”。这会直接压缩很多“靠路径赚差价”的产品价值。以前，用户必须自己导入、自己设置、自己执行、自己导出；以后，用户会越来越自然地觉得：既然我已经把目标说清楚了，那系统就应该把这条链路替我走完。
一旦这种预期变成常识，那些只靠“我把几个按钮包在一起”获得价值的产品，就会非常被动。因为它最值钱的，不再是按钮本身，而是按钮背后那套真正的能力系统。你有没有稳定的执行链路？你有没有可复用的流程逻辑？你有没有真实的结果质量？你有没有异常处理机制？你有没有历史记录和审计能力？你有没有行业经验和判断规则？你有没有能力把一类任务长期做对？
如果这些都没有，那你的产品就只是一个壳子。而壳子，是最容易被时代压薄的。所以，今天最值得焦虑的，不是“我是不是还在做 App”，而是“我做的到底是一个界面，还是一套能力”。这是两个完全不同的层次。如果你做的只是界面，AI 来了，你很容易慌，因为你会发现用户越来越不愿意为界面本身付费；可如果你做的是能力，AI 来了，反而可能放大你，因为它会给你带来更多入口、更多调用场景、更多被组合的机会，以及更大的分发半径。
未来真正会被淘汰的，不是 App，而是那些只有外壳、没有内核的 App。这句话，几乎可以送给所有做工具类产品的人。
六、App 怎么到 Skill 平滑过渡？真正可行的，不是推倒重来，而是四步重组
这是最现实的一段，因为很多人手里不是只有一个想法，而是真的已经有产品、有代码、有用户、有订阅、有上架记录。这时再跟他说“别做 App 了，全部重来”，那不是建议，那是站着说话不腰疼。
真正更稳、更现实的路线，其实是：保留 App，抽取能力，逐步 Skill 化，最后完成重组。
第一步：别先拆整个产品，先拆最有价值的一个动作
很多人一做转型，就喜欢想大：我要把整个产品都 AI 化，我要把所有功能都做成 Skill，我要一口气做成 Agent 平台。这种想法，很容易把自己做死，因为你会同时撞上产品边界、技术边界、交互边界和维护成本。
更好的做法其实很朴素：先找出那个最值得被一句话触发的动作。是状态查询吗？是批量整理吗？是配置生成吗？是内容生成吗？是日志分析吗？是文件转换吗？是规则执行吗？只要它满足几个条件，就很适合先拆出来：目标清晰，输入输出相对稳定，结果可以验证，用户本来就嫌步骤多，而且频率不低。
先把最强的一个动作拆出来，不要先想着全拆。转型最怕的不是慢，而是一下子拆得太散，最后没有一个点能真正打透。
第二步：别再只写功能说明，要开始写“意图说明”
这是很多人最容易忽视的一步。过去做 App，大家很喜欢写这种文案：支持导入导出，支持批量转换，兼容多格式，提供高级配置。这些话写给人看还行，写给模型看远远不够。因为模型要的不是广告词，模型要的是边界。
它要知道，什么时候该调用你，为什么该调用你，你的能力适用到什么程度，你不能做什么，什么时候应该停下来让用户确认。OpenAI 近期关于 skills 的公开文章与评测实践也反复强调一个点：skill invocation 很依赖 name 和 description，description 必须能暴露边界和触发条件，否则模型并不会稳定地在你期望的时机调用它。
说白了，未来的软件描述，不只是给用户看的，还是给模型看的。这就是为什么，未来所有产品都得学会把“功能描述”改写成“意图描述”。以前你写的是“支持批量处理文件”；以后你更应该写成“当用户想一次性整理大量文件，并希望保留目录结构时调用我”。前者是功能介绍，后者是调用说明。未来值钱的描述，不是你有什么，而是系统知道什么时候该用你。
第三步：别把 UI 当主入口了，把它改造成确认台和控制台
很多人一聊 AI，就容易把 UI 想成被替代品，其实不是。UI 的重要性没有消失，只是职责变了。过去，UI 是主流程本身，用户必须一路点着走；以后，UI 更像几个关键节点的承接器，它负责确认、配置、回显和纠错。
当系统准备执行关键动作时，用户需要看一眼；当参数复杂到一句话说不清时，用户需要调一下；当结果信息量太大时，用户需要结构化查看；当自动化失败时，用户需要人工接管。这时，UI 就不是负担，它反而是安全感。OpenAI 的 ChatGPT UI 文档也明确说明，UI components 的作用就是把来自 MCP server 的 structured tool results 转成对人更友好的 inline UI，而且这套架构后来又被标准化为 MCP Apps，让开发者可以在兼容宿主之间复用。
所以，未来不是“不需要 UI”，而是“不该再把 UI 设计成唯一入口”。未来好的 UI，不是带着用户一步步走，而是在关键节点，让用户看得懂、接得住、改得动。
第四步：真正的壁垒，不要再绑在页面里，要沉淀到服务层里
这是最关键的一步。因为页面最容易被替代，而服务层里的沉淀，最不容易被替代。什么才是真正该沉淀下来的东西？你的数据接入、账户体系、权限管理、工作流、任务历史、结果评估、审计能力、异常兜底，以及你的行业 know-how。
当这些东西沉淀下来后，你的产品就不再只是一个 App，它会慢慢变成一个能力平台。到那时，App 仍然存在，Skill 也存在，Web 也存在，API 也存在，但它们不再是彼此分裂的东西，而是在共同调用同一套底层能力。这才叫平滑过渡：不是砍掉旧世界，而是把旧世界里的真正价值提炼出来，接到新入口上。
七、对独立开发者来说，这未必是坏消息，甚至可能是一轮重新分配机会
很多个人开发者一看到大模型、平台、生态这些词，就本能地紧张。因为你会觉得，大厂有模型、有流量、有入口、有生态、有资本，怎么打？这份担心很正常，但也不必只看到一面。
因为 Skill 化带来的变化，恰恰有可能把一部分机会重新释放出来。过去做一个 App，独立开发者最难的地方，不一定是能力不够，很多时候是“完整产品壳子”的成本太高。你得做前端、做后端、做账户、做设置、做支付、做增长、做引导、做教育、做留存。很多人不是输在能力，而是输在“还没来得及把能力展示出来，资源就已经被耗光了”。
可在新的入口逻辑下，事情变了。你有机会先不做一个庞大产品，先把你最强的那段能力做出来，先让它接住真实任务，先让它被调用，先让用户体验到结果。等结果成立，再往外长壳，长出控制台、长出账户体系、长出管理界面、长出商业模式、长出完整产品。
这其实是一条很适合独立开发者的路。不是因为门槛变低了，而是因为新的门槛，开始更偏向“能力质量”，而不是“产品壳子的完整程度”。当然，这并不轻松。因为未来更难的，不是把一个功能做出来，而是把一类任务稳定做对。谁能在一个很具体的场景里做到更高成功率、更高可信度、更高复用性和更高结果质量，谁就更有机会。
所以，独立开发者未来最好的位置，未必是做一个大而全的巨型产品，反而可能是做一个小而强、边界清晰、结果过硬、容易被系统调用的节点型产品。旧时代比谁壳大，新时代更比谁能力硬。这，未必不是一次机会重分配。
八、未来最稳的产品形态，是“App 外壳 + Skill 内核”
未来真正稳的产品，不会是那种死守旧逻辑、只会堆页面的 App，也不会是那种完全脱离用户关系、只剩一个抽象调用接口的 Skill。真正更稳的，大概率是两者的结合。
对用户来说，它仍然是一个产品：可理解、可管理、可确认、可付费、可信任。对模型来说，它是一组能力：边界清晰、调用稳定、可被组合、可被编排、可被嵌入不同入口。对业务来说，它背后则是一套长期沉淀的系统：数据、权限、流程、评估、审计、历史、策略和风控。
这就是未来最有竞争力的形态：App 外壳 + Skill 内核。前者解决信任、控制和关系，后者解决调用、分发和自动化。谁还把这两者当成互相取代的关系，谁就还停留在旧问题里；谁开始把两者当成协同关系，谁才真正进入了新阶段。
因为未来的软件竞争，不再只是“谁的图标更容易被点开”，而会越来越像：谁的能力更容易被系统想到，谁的结果更容易被用户信任，谁的产品更容易被不同入口共同消费，谁的底层能力更能穿透不同交互形态。未来不会没有 App，但未来的 App，必须拥有可被 AI 调用的内核。
结语：App 不是没有出路，而是不能只停留在旧出路上
每一次技术浪潮，都会制造两种错觉。一种错觉是：新东西来了，旧东西一定马上死。另一种错觉是：新东西只是噱头，旧逻辑还能一直用。可真实世界往往不是这样。真正的变化，通常更安静，也更扎实：先是入口变了，再是用户习惯变了，接着是价值重心迁移，最后产品形态才被重新定义。
今天的 App，不需要悲观；今天的 Skill，也不需要神化。真正值得认真想清楚的，从来不是“站哪一边”，而是：你做的，究竟只是一个页面，还是一个能力？你卖的，究竟只是一次点击，还是一次结果？你构建的，究竟只是一个图标入口，还是一个可以被未来各种入口共同调用的系统？
如果你的答案还停留在“我有几个页面、我有几个按钮、我有几个功能”，那你当然会越来越焦虑。可如果你的答案开始变成：我掌握了一类任务的稳定完成方式，我有自己的数据、权限、流程和评估体系，我能把能力通过不同入口交付出去，我能在用户需要时给出结果，在用户担心时给出控制，在用户长期使用时给出信任，那么 AI 时代对你来说，就不只是威胁，它反而可能是一种放大器。
所以，回到最初的问题：AI 时代，App 还有出路吗？答案当然是：有。只是这条出路，不再是停留在原地，继续把 App 做成一个单纯的功能容器，而是让它逐渐进化成一个能力系统。让它既能被人使用，也能被 AI 调用；让它既有界面的承接力，也有 Skill 的调用力；让它既能保留过去积累下来的用户关系、品牌信任和商业化阵地，也能接住新的入口、新的流量、新的任务分发逻辑。
这，才是 App 到 Skill 最平滑、也最现实的过渡路径。不是抛弃过去，而是重组过去；不是否定 App，而是升级 App；不是让产品从世界上消失，而是让产品从“页面集合”，进化成“能力系统”。
说到底，未来真正有竞争力的，不是 App，也不是 Skill 这两个词本身，而是那个既能交付结果、又能承接信任，还能被系统接入的产品。
未来真正值钱的，不是功能集合，而是能力系统。
