如果你现在要做一个新产品，第一反应大概率还是：做一个 App。
这很正常。过去二十年，软件产品几乎都长这样：一个入口，一套界面，一组功能，一个用户必须进入的地方。
AI 出现之后，大家开始做 AI App。传统 App 旁边加一个聊天框。再进一步，是一个独立 agent：它能对话，能调用工具，能帮用户完成一段任务。
这已经比传统 App 前进了一步。
但它可能仍然不是终点。
很多产品会经历这样的变化：
传统 App -> AI App -> Skill App
也就是说，你的下个产品，不一定应该首先被设计成一个独立 App，也不一定应该首先被设计成一个带聊天框的 AI App。
它可能应该首先是一个 skill。
1. 传统 App 的问题：用户其实不想进你的产品
传统 App 有一个隐藏前提：用户愿意进入你的系统。
这在过去很合理。因为软件能力只能通过 App 提供。你要做合同，就进合同系统；要找文件，就进文件搜索；要分析客户，就进 CRM；要写报告，就进文档工具。
App 是能力的容器，也是用户的入口。
但用户真正想要的，往往不是"进入某个系统"。
他想要的是：
帮我审查这份合同。
帮我找出上周和 A 客户有关的材料。
帮我判断这个客户下一步怎么跟。
帮我把这些会议纪要整理成项目计划。
这些话里没有"打开某个 App"。
用户要的是任务完成，不是产品入口。
过去没有办法。任务只能拆成一个个软件操作，用户只能在不同 App 之间搬运上下文。
但通用 Agent 出现后，这个前提变了。
如果用户已经在一个 Agent 工作区里处理文件、邮件、代码、文档、日程、CRM 和知识库，他为什么还要为了每个小任务打开一个新 App？
产品不再只竞争"用户会不会打开我"，还要竞争"Agent 会不会调用我"。
2. AI App 太重，而通用 Agent 正在成为运行环境
很多团队意识到了入口变化，于是开始做 AI App。
这一步当然有价值，但它经常会掉进另一个坑：为了让自己的产品变得 agentic，团队开始重做一整套通用 Agent 基础设施。
你原本可能只想做一个合同审查产品。
结果很快发现，你还要处理：
- 对话入口；
- 上下文管理；
- 文件上传和解析；
- 工具调用；
- 长任务状态；
- 用户记忆；
- 权限控制；
- 高风险操作审批；
- 执行日志；
- artifact 展示；
- 模型选择；
- token 成本控制。
这些事情都重要。
但它们不是合同审查这个产品的核心价值。
合同审查的核心价值应该是：能不能识别风险，能不能理解交易背景，能不能给出可靠修改建议，能不能让用户相信结论。
问题在于，一旦你要做一个完整 AI App，你很容易被"通用 Agent 外壳"吞掉。
而另一边，通用 Agent 本身正在变强。早期聊天机器人主要负责回答问题。后来的 Agent 开始能调用工具。现在 Agent 正在拥有更完整的工作区能力。
趋势很清楚：
通用 Agent 正在从"一个能聊天的产品"，变成"很多能力可以运行其上的环境"。
有了通用 Agent 运行时之后，不是每个 AI 产品都要自己造一个完整 Agent App。
它可以先成为一个 skill。
3. skill 是什么，为什么应该 skill-first
Skill 不是 prompt。
Prompt 是一次表达。它告诉模型这次怎么写、怎么答、怎么生成。
Skill 也不是 API。
API 是系统暴露出来的操作接口。它告诉外部系统"我能做什么"。
Skill 更像是任务级产品能力。
它回答的是：
在某类用户任务里，如何使用上下文、工具和判断步骤，把事情完成到可验收状态？
一个真正有产品价值的 skill，至少包含：
- 它解决什么任务；
- 它不解决什么任务；
- 什么时候应该被触发；
- 需要哪些输入和上下文；
- 能调用哪些工具；
- 任务分几步；
- 哪些地方要用户确认；
- 输出什么结果；
- 如何判断结果好不好；
- 哪些风险不能自动越过。
比如"合同审查 skill"不是一句"请帮我审查合同"。
它应该是一套任务能力：
识别合同类型
-> 确认我方立场
-> 提取关键条款
-> 标记风险项
-> 生成修改建议
-> 让用户选择处理策略
-> 输出审查报告
-> 导出或发送前请求确认
Prompt 是"你怎么说"。Skill 是"你怎么做"。API 是工具。Skill 是任务经验。
这也是为什么产品应该首先是 skill。
做 App 很容易先做容器：主页、导航、模块、账号、设置、通知、管理后台。
这些东西最后可能都需要，但它们不一定是产品一开始最该回答的问题。
做 skill 则迫使你先定义能力：
用户反复发生的任务是什么？
任务完成状态是什么？
需要什么上下文？
需要哪些工具？
哪些步骤可以自动？
哪些地方必须人判断？
结果如何展示？
质量如何验证？
更重要的是，skill 可以把非核心复杂度剥离出去。
通用 Agent 负责通用部分：对话、上下文装配、工具编排、artifact 渲染、任务状态、用户审批、执行日志、记忆、权限、token 成本控制。
产品开发者负责核心部分：领域判断、数据能力、工具能力、工作流经验、输出标准、质量评估。
这是一种更合理的分工。
4. 一个例子：个人电脑文件搜索
拿个人电脑文件搜索举例。
传统 App 的做法是：做索引 → 做搜索框 → 做结果列表 → 支持打开文件。
AI App 的做法通常是：在搜索框旁边加聊天，让用户用自然语言找文件。
Skill App 的思路会不一样。
它先问：用户围绕文件真正想完成什么任务？
答案可能是：
帮我找出上周和 A 客户有关的所有材料。
把这个项目的文件整理成交接包。
比较这几个合同版本的差异。
找出重复的大文件，但删除前让我确认。
帮我回忆之前写过的那篇文章在哪里。
这些不是单纯搜索，这是文件任务。
于是产品首先可以是一组 skill：file-search、file-briefing、version-compare、project-packaging、file-cleanup、personal-memory。
它们依赖你的核心能力：本地索引、内容解析、语义检索、命中证据、隐私控制和安全文件操作。
它们运行在通用 Agent 里，由 Agent 提供对话、任务状态、artifact、审批和日志。
这时你的产品不一定首先是"AI 版 Finder"。它首先是 Agent 可以调用的本地文件能力层。
如果后来用户需要更强的可视化、更复杂的权限、更细的批量操作，再长出独立 App。
但产品的第一性能力，已经在 skill 里成立了。
5. skill-first 不等于没有 UI，也不是所有产品都适合
Skill-first 不是 chat-only。
复杂任务不能只靠聊天完成。合同审查需要风险表、条款 diff、修改建议和审批。文件整理需要结果列表、路径、预览、勾选、打包和回滚。
所以通用 Agent 必须提供 UI primitive：artifact、form、stepper、button、approval、context panel、execution log。
Skill 声明自己需要什么，Agent 负责渲染。
这不是 UI 消失，而是 UI 重新分工。
当然，不是所有产品都适合 skill-first。
更适合 skill-first 的产品，通常有几个特点：
- 任务重复，但每次上下文不同，比如合同审查、客户跟进、候选人筛选、文件整理、代码 review；
- 用户知道目标，但不知道操作路径；
- 需要跨多个工具和数据源；
- 有明确质量标准；
- 专家经验可以流程化。
这些经验过去藏在人的操作里。Skill-first 的机会，是把它们变成 Agent 可以调用的产品能力。
6. 最后：先问哪件任务值得成为 skill
如果你正在做一个 AI 产品，不要先问：我要做一个什么 App？
先问：我要把哪件高价值任务做成 skill？
至少回答几个问题：
- 用户在什么场景下需要它？
- 它完成时应该是什么样？
- 需要哪些输入和上下文？
- 要调用哪些工具？
- 任务分哪几步？
- 哪些地方必须用户判断？
- 哪些动作必须审批？
- 输出什么 artifact？
- 如何评估结果质量？
一个好的 skill 应该小而完整。
"法务助手"太大。"基于我方立场审查采购合同并生成风险清单和修改建议"更好。
"个人文件助手"太大。"围绕某个项目查找相关文件，让用户筛选后生成交接包"更好。
AI 产品不应该只停留在"传统 App + 聊天框"。
真正的变化是：产品能力可以从 App 里拆出来，变成 Agent 可以调用的 skill。
这件事不只是入口变化。它改变了产品分工。
通用 Agent 负责模型、上下文、工具、状态、审批、日志和 token 成本。
产品开发者把精力放回真正有价值的地方：领域任务、专业判断、数据能力、工具能力和结果质量。
所以，"你的下个产品应该首先是一个 skill"，不是说先做一个简陋版本。
它是在说：
不要先问我要做一个什么 App。
先问我能把哪件高价值任务，做成一个可被 Agent 稳定调用的能力。
如果这个能力需要专门界面，它会长出 App。
如果不需要，它作为一个 skill，就已经是产品。