什么是 Skills，Skills 都能做什么
gemini镜像站入口：chat.aimirror123.com
gemini 镜像备用站：gemini-3.shop。
摘要：本文解释 Skills 的定位，以及它能做哪些事情。
Skill 的核心，不是“会说”，而是“可控”
一次性的 prompt 很爽，但只要换个问题或换个用户，结果就乱。Skill 的思路反过来： 先固定边界，再让模型在边界内发挥。它会更像一个接口，而不是一个随口一说的聊天。
在 Gemini API 里，这种“可控感”来自几件事：系统指令用于定义行为；工具/函数调用 负责把动作交给外部系统；结构化输出把结果收口成固定格式。你把这些拼在一起， 才是一个能长期用的 Skill。
Skills 和普通对话的差别
普通对话强调“现在就要一个答案”；Skill 强调“下次还能稳定复现”。 这听起来很绕，但用起来很直观：当你发现自己反复写同一条提示词， 或者团队里每个人都在用不同写法时，就是 Skill 的场景。
你要的是一个“可复用的任务动作”，而不是一次性的回答。Skill 的价值就在这里。
Skills 都能做什么
下面这些是我自己在做教程站时常用的方向，不全，但能让你感受到范围有多广。
如果你刚开始做，可以先选一个最贴近业务的场景，把它做顺手，再往外扩。
1) 内容类：让创作变成流水线
比如写一篇教程博客，你可以把 Skill 设成“生成大纲 + 给出关键步骤 + 提示常见坑”。 也可以做“文章拆成卡片式摘要”“长文压缩成 600 字摘要”。这些都是内容型 Skill。
关键在于：你给它清晰的输入结构，它回给你固定的输出结构，这样你就能持续生产内容。
2) 结构化提取：把“可读”变成“可用”
你可能需要把一段混乱的笔记整理成字段：标题、场景、步骤、风险。 这类场景适合结构化输出。Gemini 支持按 JSON Schema 输出， 你可以要求模型只回 JSON，而不是一堆散文。
这一步很实用，因为它让 AI 的结果可以直接进数据库、表格或文档模板。
3) 动作型：让模型去调用工具
当你的 Skill 需要“做事”而不仅是“说话”，就要用工具调用。 Gemini 提供内置工具（比如搜索、代码执行、URL 内容读取、文件检索等）， 也支持你自己声明函数，让模型按参数调用。
这会让 Skill 从“文字助手”变成“可执行的流程节点”。例如： 先抓取网页，提取关键信息，再输出结构化清单。
4) 多步骤流程：让 Skill 像一个小型工作流
有些任务不是一步能完成，比如“整理一份竞品分析”。你会先抓资料， 再筛选，再总结。你可以把这些步骤拆成多个小 Skill，或者让一个 Skill 内部 通过多次工具调用完成。
这类场景就接近 agent 了，但本质上仍是 Skill 的扩展：把复杂任务拆成稳定链路。
Skill 的颗粒度：越小越好用
新手最常犯的错是把 Skill 写成“万能助手”。结果是输入很长、输出很散，没人敢用。 我更推荐把 Skill 切得小一点，比如“写教程提纲”“把文章拆成卡片摘要”这种单一动作。 小 Skill 复用率更高，组合起来也更轻。
真正复杂的任务不要塞进一个 Skill 里，而是拆成两三个。这样哪一步出错，你能单独修。
输入的格式决定了输出的稳定性
Skill 和聊天最大的不同，是它对输入结构很敏感。你给它一段散乱的需求，它会散乱地回你。 如果你把输入拆成“主题 / 受众 / 目标 / 语气”，输出就会更稳。
这不是玄学，是工程习惯。写 Skill 的时候，最好先定一个输入模板，哪怕很简单， 也能帮你减少 80% 的漂移。
输出要能落地，而不是好看
如果输出只是给人看，随便写几段也行。但大多数 Skill 的目标是“能被复用”， 那就必须把输出变成结构。JSON、表格、清单都行，核心是稳定、可解析。
这也是结构化输出的价值：你把格式写死，模型就不能乱飞。它可能会抱怨“没法发挥”， 但你会发现团队协作效率直线上升。
我还会给输出配一个“最小示例”。不是给模型看，而是给人看。别人知道它应该长什么样， 以后就不容易走偏。
工具调用要像写接口文档
如果你的 Skill 需要做事（查资料、读网页、执行计算），就要用工具调用。 工具描述写得越具体，模型用得越准。不要只写“搜索”，而是写“搜索并返回 3 条带来源的结果”。
我通常会给每个工具一个明确的使用场景，避免模型在不该调用时乱调用。 这一步看起来啰嗦，但能省掉很多奇怪的输出。
什么时候该用 Skill
我自己的判断很简单：
- 任务是否会被重复使用（本周会不会再做一次）。
- 输出是否需要被系统消化（要不要进表格、进模板）。
- 团队是否需要同一套规则（避免每个人乱写 prompt）。
如果答案是“会”，那就值得做成 Skill。
Skill 的最小结构长什么样
一个可用的 Skill 不需要复杂。最小版本可以是这样：
- 系统指令：说明角色、语气、边界。
- 输入模板：告诉用户应该给什么信息。
- 输出模板：规定返回的结构或格式。
如果需要外部动作，再补上工具调用；如果需要稳定结构，再加 JSON Schema 约束。
小例子：教程大纲 Skill
假设你要一个“教程大纲 Skill”，输入可以是“主题 + 目标读者 + 教程目标”。 输出则固定为：标题、开头一句话、三到五个步骤、每步提示风险点。
这样写的好处是，你每次换主题，只改输入，不改逻辑。你得到的是一种稳定的产出节奏。
如何判断一个 Skill 写得够不够好
我一般会做两件事：第一，换三种不同输入，看输出还能不能保持结构；第二，让别人试用， 看他有没有问“我该怎么填”。如果这两关过了，Skill 基本能跑起来。
另外别忽略成本和时间。有些 Skill 看起来很酷，但每次调用都要跑一堆步骤， 反而拖慢节奏。轻量、稳定，才是能长期用的。
Skill 也需要命名和版本
如果你开始积累十几个 Skill，很快就会混。给它们起个清晰名字，比如“教程-大纲-基础版”， 再写个版本号，会让后续维护省很多事。
版本并不是形式主义。你改了输出结构，就该升版本；你调整了边界，也该记录。 不然别人今天用得好，明天就可能踩坑。
别把知识塞进提示词里
Skill 需要稳定，但不代表你要把所有知识写进提示词。内容一旦更新，提示词就老了。 更好的方式是把知识放在外部，让 Skill 通过检索或读取工具去拿。
你可以把常用资料做成文档或链接，调用时再读取。这样 Skill 会保持轻，内容也能随时更新。
常见坑
我见过的坑基本都和“边界不清”有关：
- 输入不干净，导致输出飘。
- 工具描述太含糊，模型不知道何时调用。
- 没有结构化输出，结果无法复用。
这些问题解决起来也不难：把指令写清楚、工具描述写清楚、输出结构写清楚。
写给团队的补充
如果你的团队会一起用 Skill，最好留一个“使用说明”：输入格式、输出示例、常见错误。 这不是形式主义，而是让新人不用猜。谁来维护、什么时候更新，也可以顺手写进去。
Skill 真正被用起来，靠的不是“写得好看”，而是“有人能用”。这点很现实。
写给自己的一句话
Skill 不是写给模型的，是写给“未来的你”和“团队里的别人”的。它能不能站住， 不取决于今天一次回答有多漂亮，而是明天还能不能复用。
如果你不知道从哪开始，就先做一个最小 Skill，把它塞进真实项目里跑一周。 你会很快知道该删什么、该补什么。