Skills 设计方法：任务拆分与输入模板
gemini镜像站入口：chat.aimirror123.com
gemini 镜像备用站：gemini-3.shop。
摘要：本文围绕 Skills 的设计方法，讲清楚任务拆分与输入模板。
从“要写什么”开始，而不是从 prompt 开始
我见过很多人一上来就写长提示词，结果写到一半发现目标都没定。Skill 不是一次性的聊天， 它是以后会被多次调用的“功能”。所以第一步不是写 prompt，而是决定这件事到底要解决什么问题。
我会先把场景写成一句话，比如“把一次访谈整理成结构化纪要”，或者“把一篇长文拆成可发布卡片”。 只要能读懂，就算成功了。你要知道自己是在写“功能”，不是在写“文章”。
选题从“重复劳动”里找
你可以回忆一下最近一周：有没有哪件事做了两次以上？有没有哪件事别人问了你三次？ 这些地方就是最适合做 Skill 的。因为它们重复、稳定，而且痛感强。
反过来，如果一个任务只会发生一次，或者每次都高度依赖人类判断，那就别硬做 Skill。 做出来也难用，最后只会变成没人维护的提示词。
边界写得越窄，效果越稳定
Skill 最大的问题是边界不清。今天让它写提纲，明天又让它写完整文章，模型很快就漂。 正确的做法是把边界写死。
我通常会写两句：一是“这个 Skill 要做什么”，二是“这个 Skill 绝对不做什么”。 这两句最好直接写进 system instruction 里。官方文档也强调可以用系统指令来指导模型行为， 它就是 Skill 的“产品说明书”。
输入模板，是 Skill 的地基
同样的模型，同样的系统指令，如果输入乱七八糟，输出就没救。Skill 的关键是输入格式， 这一步比你想的更重要。
我最常用的模板是四段：主题、受众、目标、限制。比如“主题：Gemini 工具调用；受众：产品经理； 目标：输出 5 个落地场景；限制：不要技术细节”。输入有结构，输出就能稳定。
如果你要做得更严谨，可以把输入也结构化成字段，甚至做成表单。这样 Skill 就不再是“提示词”， 而是一个真正的产品入口。
输入字段越少越好，但别少到没法用
我会先把字段缩到最小，比如只留“主题 + 目标”。跑一遍看输出是否可用，再加“受众”和“限制”。 一开始就堆一堆字段，用户会懒得填，模型也不一定用得上。
还有个小技巧：给每个字段写一句“示例输入”。这不是给模型看，而是给人看。 只要人能一眼懂怎么填，这个 Skill 就有使用的可能。
system instruction 的写法要像“产品定义”
system instruction 不是写文学句子，而是给模型一个明确角色和边界。官方 API 提供了 system instruction 配置方式，你可以在每次调用时传入它。
我会用短句来写：角色、输出结构、禁止项。比如“你是教程编辑，只输出提纲，每条不超过 30 字， 不要写结论”。你越直接，模型越稳定。
输出格式要“可消费”，而不是“好看”
这一步决定 Skill 能不能长期用。所谓“可消费”，就是结果能被程序、文档模板、或者你自己快速复用。 如果输出只是一段散文，那就没法进入工作流。
Gemini 支持结构化输出，可以用 JSON Schema 限定输出结构。你只要设置
response_mime_type 和 response_json_schema，模型就会按结构返回。官方说明里明确提到，
结构化输出支持 JSON Schema 的一个子集，这个限制反而让你更好设计字段。
我建议一开始只要 4-6 个字段，太多反而让模型乱。等稳定后再扩展。
输出节奏也能设计
有些 Skill 需要“快”，比如快速生成清单；有些 Skill 需要“稳”，比如写教程提纲。 你可以在 system instruction 里写清楚节奏要求，比如“每点不超过 30 字”“每步只写一句话”。 这会让输出更紧凑，也方便你后续拼接成文章。
我还会在输出里加入一个“完成度”字段，例如 0~100 的自评。这个字段不一定准确，但能提示你 是否需要人工补充。
风格一致性别靠形容词
很多人会写“语气自然、亲和”，但模型不一定懂。更好的方式是给一个短示例。 例如：你希望它写“像编辑写的开头”，就直接给一句示例。这比任何形容词都有效。
我还会补一个“反例”，告诉模型什么不该写。比如“不要写口号式句子”。
小案例：把“产品更新”变成“教程”
假设你要写“本周产品更新”。如果只是让模型总结，它往往会写成新闻稿。 但如果你把 Skill 定义成“给用户的教程说明”，输出就会变成步骤式结构。
这种差别来自边界和输入模板，而不是模型本身。所以别急着换模型，先把 Skill 设计好。
什么时候需要工具调用
当 Skill 需要“做事”而不是“说话”时，就该考虑工具调用。比如读网页、查数据、执行计算， 这些都应该交给工具。
Gemini 的 function calling 机制，就是把“动作”交给外部函数。你定义函数声明，模型决定何时调用。 文档里强调了函数声明要包含清晰的参数描述，否则模型容易乱填。
我通常会先把工具调用留空，等 Skill 稳定后再加。一步一个坑，修起来更轻。
别忽略“检索”这一类 Skill
很多 Skills 最后会变成“查资料 + 归纳”。这时候你不应该让模型凭记忆胡编， 而是用检索或搜索类工具把事实喂给它。
Gemini 提供了 Google Search grounding 工具，能让模型自动搜索并给出引用信息。 这种 Skill 特别适合做“更新型教程”，例如最新版本变化、最新政策等。
一个实用的拆分方法
我经常用“动词拆分法”。把任务写成动词：整理、提取、对比、改写。每个动词做一个 Skill。 你会发现原本很复杂的任务，拆开后变得清楚。比如“写一篇教程”其实可以拆成： 生成提纲、补步骤、加案例、出摘要。你可以一个个 Skill 去做，也可以组合。
别忽略“样例输出”
很多 Skills 写得再好，别人还是不知道该期待什么。你可以在文档里放一个“理想输出样例”， 让人一眼明白结果长什么样。样例不是给模型看的，而是给人看的。
这一步会直接提高使用率。我见过的失败 Skill，大多不是模型不行，而是别人不知道怎么用。
团队协作的最小清单
如果是团队用，我会写一个最小清单：输入模板、输出示例、版本号、负责人、更新时间。 这些看起来像“文档工作”，但它们能把 Skill 从“私人玩法”变成“公共能力”。
你不需要写得很复杂，一页纸就够。关键是让别人知道怎么用、怎么改、找谁问。
写给想长期维护的人
如果你打算长期维护一套 Skills，就别只写 prompt。写个 README，记录输入格式、输出样例、版本。 这样过一个月回来，你还知道这东西怎么用。
Skill 真正的价值不是“写得多聪明”，而是“能被别人用”。把它当成产品，而不是一次性的文本。 你会轻松很多。
什么时候不该做 Skill
有两类任务我会直接放弃：一类是一次性任务，比如临时汇报；另一类是高度依赖个人判断的事， 比如风格极强的文案。做成 Skill 只会浪费时间。
这不是保守，而是节省精力。把 Skill 留给真正可复用的地方，效果会更明显。
如果你还在犹豫，就做一个最小实验：先写一版简化 Skill，用三条输入测一下。 测下来能复用，就继续；不行就停。