Skill 会有自己的 App Store 吗？
Will Skills get their own App Store?连续整理了几篇 Skill 以后，我开始好奇另一个问题：
现在 Skill 主要还是通过 GitHub、Plugin、Extension 等方式被发现和安装。以后它会不会像 App 一样，有成熟的应用市场？
其实这件事已经开始发生，只是它可能不会完全复制今天的 App Store。
OpenAI 现在把 Skills、MCP server 和可选 UI 放进 Plugin 体系；Claude Code 的 Plugin 也可以包含 Skills、Hooks、Subagents 和 MCP servers，并通过 Marketplace 分发；Gemini CLI 则已经有 Extension Gallery，Extension 里面同样可以包含 Agent Skills。
所以“发现 → 安装 → 更新 → 分享第三方 AI 能力”这套基础设施已经在形成。
但 Skill 和 App 还是有一个挺本质的区别。
Skill 更像一种能力，App 更像一个完整的使用场所
拿前面拆过的 make-photo-stamp-archive 来说。
它提供的是一套能力：
怎么分析照片、怎么留白、怎么选印章、哪些地方不能改、最后怎么检查。
人当然是最终使用者。
只是直接读取这份 Skill、理解规则并执行它的，是 Agent。
所以更准确地说：
人是最终用户，Agent 是 Skill 的直接调用者。
这和传统 App 有一点不同。
一个修图 App 通常要自己设计：
- 上传照片
- 编辑界面
- 历史记录
- 导出
- 账户
- 支付
- 设置
用户进入这个 App，在它设计好的体验里完成事情。
而 Skill 很多时候没有自己的 UI，甚至没有自己的“入口”。
你只需要告诉 Agent：
帮我把这张照片做成 archival stamp 风格。
Agent 在后台找到对应 Skill，再配合自己已有的图片工具完成任务。
从用户角度看，他甚至未必在意背后用了哪个 Skill。
这也是为什么 Skill Marketplace 不一定会长成 App Store
App Store 的逻辑比较像：
我要完成 X → 找一个 App → 打开这个 App。
Skill 的逻辑可能越来越像：
我要完成 X → 告诉 Agent → Agent 自己组合需要的能力 (skills)。
例如用户说：
帮我研究这家公司，判断是否值得面试。
背后可能同时用了：
- Web Research Skill
- Company Analysis Skill
- Job Fit Skill
- 一个 LinkedIn / Web MCP
- 最后再调用报告生成能力
用户真正需要的是最后的结果，不一定想先研究应该安装哪五个 Skill。
这也是为什么目前三家都越来越倾向于用 Plugin / Extension 作为更完整的分发单位，而 Skill 可以成为里面的一部分。Claude 甚至直接把 Plugin 定义成 packaging layer；Gemini Extension 也可以同时打包 prompts、MCP servers、commands、hooks、subagents 和 Skills。
Skill 很“原子化”，这既是优势，也是限制。
它很好组合、很好 fork、很好复用。
但用户通常买的不是“一个方法”，而是“把某件事情解决掉”。
那 Skill 和 Product 又是什么关系？
我觉得这里也不能简单说：
Skill 不是 Product，App 才是 Product。
Product 其实不是一种技术形态。
一个 Skill 也完全可以被 productize。
例如有人维护一个非常好的 Design Review Skill：
- 持续更新；
- 有自己的品牌；
- 有稳定用户；
- 有 eval；
- 有版本管理；
- 有支持服务；
- 甚至收费。
它当然可以成为一个 Skill Product。
反过来，一个做了登录、数据库、漂亮 UI 的 App，也不代表它已经是一个好 Product。
所以我现在会这样区分：
Skill / App 描述的是产品形态。
Product 描述的是有没有围绕一个真实用户问题，持续提供完整价值。
对 Builder 来说，这个区别其实很实用
以前有一个 AI idea，很自然就会想到：
做一个网站 / App。
于是开始：
Landing Page、登录、数据库、Dashboard、支付……
但现在多了几个更轻的选择。
如果真正有价值的是一套方法
比如：
- 怎样 Review 一个 PR；
- 怎样检查一份设计稿；
- 怎样整理 User Research；
- 怎样做某种固定风格的图片；
可能先做一个 Skill 就够了。
先验证：
这套方法本身有没有价值。
如果这套方法需要外部数据或操作
例如 Skill 还需要：
- 查 Jira
- 读 GitHub
- 操作 CRM
- 查询数据库
可以继续加 MCP。
如果要把几个能力组合起来分发
例如：
Skill + MCP + Hooks + Subagents
开始更接近 Plugin / Extension。
如果真正的问题还需要完整的用户体验
例如：
- 用户账户
- 长期状态
- 数据管理
- 协作
- 权限
- 工作流 UI
- 支付
- 用户生命周期
这时候再做完整的 App / Product，理由就充分很多。
这个顺序对 Indie Builder 尤其有意义。
因为现在“把 App 做出来”的成本越来越低，但时间依然有限。
有些 idea 也许根本不需要先做一个完整产品。
如果一份 Skill 就能验证最核心的价值，先做 Skill 反而更诚实，也更便宜。
所以 Skill 会不会有自己的 App Store？
我觉得答案大概是：
会越来越像市场，但未必越来越像 App。
搜索、安装、评分、安全扫描、版本更新、作者信誉，这些 Marketplace 基础设施很可能越来越成熟。Gemini 已经通过 Extension Gallery 做公开发现和安装，Claude Plugin 已经通过 Marketplace 分发，Skill 本身也可以被这些能力包携带。
但 Skill 天生更适合被组合、被 Agent 自动调用，也更容易藏在完整 workflow 背后。
所以以后一个很成功的 Skill，最理想的状态甚至可能不是：
用户每天打开它。
而是：
用户需要的时候，Agent 总能自动用对它。
对 Builder 来说，我觉得最后值得留下的不是“Skill 会不会成为下一个 App Store”，而是一个更实际的判断：
下次有一个 AI idea 时，先别默认它需要一个 App。
先看真正有价值的到底是什么：
- 是一套方法 → Skill
- 是外部能力 → MCP
- 是一组可以安装的能力 → Plugin / Extension
- 是一个需要长期经营的完整用户体验 → App / Product
有时候，把产品做小一点，并不是少做了。
只是更早找到了真正需要 Build 的那一层。