不是所有问题都该靠 Skill 解决。官方已经把很多能力做成原生 Tools，又允许你通过 agent / workspace / 配置去调整行为。所以更重要的能力，不是“会装 Skill”，而是能判断什么时候该装、什么时候不该装、什么时候只用 Tool 或普通提示就够。
如果你缺的是动作能力，先看 Tool；如果你缺的是可复用的方法和规则，再看 Skill。
适合用 Skill 的 5 类场景
1. 这是一个会反复发生的任务
比如内容改写、周报整理、资料归档、渠道运营模板。只做一次的需求，往往不值得专门装 Skill。
2. 你需要固定步骤和固定输出格式
Skill 特别适合把“先查什么、再做什么、最后按什么格式输出”固化下来。
3. 你希望多人或多 workspace 复用
如果一套方法不只你自己会用，而是团队里会重复用到，那 Skill 的价值会明显上升。
4. 你要把领域经验沉淀下来
当一个任务开始包含行业规则、检查清单、输出标准时，它就越来越像 Skill，而不只是一次性的 Prompt。
5. 你需要和工具链稳定配合
比如固定会配合 web 工具、浏览器、文件操作或消息工具一起工作，这时候 Skill 能把流程串稳。
不适合用 Skill 的 5 类场景
1. 系统原生 Tool 已经够了
如果你只是想搜索网页、抓页面、读文件、发消息，先看 Tools，别上来就装 Skill。
2. 这只是一次性的临时需求
一次性任务更适合直接在当前会话里说明白，不必为了“一次使用”给系统再加一层扩展。
3. 你其实只想调模型提示词
很多人把“想让语气稳定一点、格式固定一点”直接理解成该写 Skill。其实不少场景只要 agent 指令或当前 Prompt 就够。
4. 风险高于收益
如果这个 Skill 要高权限、要密钥、要执行外部脚本，但你只是为了省一点时间，那通常不值。
5. 你还没搞清系统边界
连 Tools、Workspace、会话和日志都还没理顺时，越早装很多 Skill，后面越容易混乱。
一个很实用的判断流程
- 先问：这是不是系统原生 Tool 就能做的事？
- 再问：这件事会不会反复发生？
- 再问：我需不需要固定步骤和固定输出？
- 再问：它值不值得承担额外安全和维护成本？
四个问题里，只要前三个答案大多是否，就先别装 Skill。
对中国用户最常见的几个例子
- 网页搜索 + 总结：先看 web Tools，很多时候不必先装 Skill。
- 固定格式的小红书选题分析：更适合 Skill，因为步骤和输出都固定。
- 飞书会议纪要整理：如果是稳定团队流程，适合 Skill；如果只是偶尔一两次，先直接写 Prompt。
- 复杂渠道自动化：先看渠道和 Tool 权限，再决定要不要叠 Skill。
什么时候该自己写 Skill，而不是继续装别人的
- 你已经明确自己的场景很固定。
- 公开市场上的 Skill 都不完全贴合你的流程。
- 你不想把关键业务流程交给第三方不透明实现。
最后一个很重要的提醒
Skill 不是“越多越强”的收藏系统，而是会真实影响加载、优先级、会话判断和安全面的扩展层。真正成熟的用法，是只保留高频、稳定、可解释的那一批。