最近在技术社区里泡着大家张口闭口都是 Agent、智能体、工作流自动化但我自己最大的体感是真正让 Agent 从“玩具”变成能干活“工具”的关键往往不在模型选得有多强而在你有没有给它配好一套“Skills”。这个词直译过来是“技能”放在 AI 圈里它不是一个虚的岗位能力清单而是一套有结构、可复用、能让大模型稳定执行具体任务的模板和脚本集合。如果你刚接触 AI 编程或者正在公司里折腾智能体落地这篇内容大概适合你。我会从最基础的概念讲起跟你拆解 Skills 的标准结构然后带你手写一个能直接用的 Skill最后把我在实际调试中踩过的坑和排查思路一次性捋清楚。不是学院派那种从原理到原理而是我自己在真实项目里测过、调过、用过之后沉淀下来的东西。1. 先搞清楚Skills 在 AI Agent 里到底是个什么角色1.1 为什么模型越来越聪明做具体任务还是翻车先说个现象。早期大家玩 Agent基本思路就是“提示词驱动”在系统提示词里塞一堆规则让模型按规则做事情。但这个方案有个硬伤——提示词越长模型越容易“选择性失聪”前半段记得好好的后半段就开始自由发挥。你今天给它说“输出要分三段、每段要有小标题、语气要活泼”它明天可能就给你回一篇论文风。不是模型变笨了而是所有指令都挤在一条上下文里模型很难分清哪些是原则、哪些是临场说明。Skills 要解决的就是这个痛点。它的思路很朴素把完成某类具体任务的完整经验——包括背景说明、操作步骤、输出格式、调用脚本、参考案例——打包成一个独立的小目录放着备用。模型在对话里一旦识别出任务匹配就去加载这个 Skill按里面的剧本走。相当于你不再要求模型“临场背出全本 SOP”而是明确告诉它遇到这类活去抽屉里拿那张任务卡按卡片上的步骤干。这里有一个很关键的转变以前我们是在“教模型说话”现在是在“给模型配工具”。1.2 Skills 和 Prompt、MCP 的区别到底在哪很多人会把 Skills 跟 Prompt 混在一起也会把 Skills 跟 MCPModel Context Protocol搞混。我在群里聊天时发现这是咨询频率最高的问题。Prompt 是一段一次性对话指令它跟着每次会话的上下文一起走作用是“告诉模型当次任务的具体要求”。Skills 呢它是可以长期保存、按需调用的任务模块目标是让模型在特定场景下稳定复现一套流程。MCP 则是另一回事它解决的是“模型怎么连接外部系统”的问题比如让它能读取数据库、调用 API、操作本地文件。做一个生活化的类比MCP 是给模型一把螺丝刀和扳手Skills 则是一份“怎么换灯泡”的图文步骤说明书。螺丝刀解决的是“手里有没有工具”Skills 解决的是“知不知道该按什么顺序用工具”。我整理了一张对比表方便你一眼看明白维度PromptSkillMCP本质一次性指令可复用任务模板外部工具连接协议生命周期随对话存在长期保存按需加载长期部署按需调用解决痛点让模型理解当次需求让模型稳定执行复杂流程让模型能接触外部数据与功能典型形态一段文字文件/目录含 SKILL.md服务/接口理解完这三者的边界你在设计 Agent 方案时就不会走偏了。判断标准很简单如果你需要的是“告诉模型怎么做”优先写 Skill如果你需要的是“让模型能碰到某个系统”才需要考虑 MCP。2. 读懂 Skill 的标准结构一个好技能包长什么样2.1 目录结构SKILL.md 是灵魂文件现在主流 Agent 平台对 Skills 的约定已经趋于一致核心就是一个目录加一个灵魂文件。我在本地维护一个skills/文件夹里面按“一个技能一个子目录”管理典型的结构长这样skills/ └── weekly-report/ ├── SKILL.md ├── scripts/ │ └── format_report.py └── reference/ └── examples.mdSKILL.md是这个技能包的大脑一切指令和流程都写在里面。scripts/用于存放可执行的脚本比如需要做数据处理、内容格式化、文件整理时直接提供现成代码给模型调用避免它现场发挥写错。reference/则放参考材料比如范文、示例输出、数据字典模型写结果之前会先翻阅这些内容作为参照。为什么要这么拆我的理解是这个结构本质上是在给模型做“认知降噪”。把步骤说明、执行脚本、参考案例分开模型在加载 Skill 时能更快定位自己该看哪个文件而不是在一个超长的 Markdown 里上下翻找。实测下来这种分离结构能明显降低模型在复杂任务里的“迷路”概率。2.2 描述写得越“准”技能被调用的概率才越高SKILL.md 的开头通常有一段 YAML 格式的 frontmatter里面最重要的两个字段是name和description。很多新手会忽略这两个字段的价值随便写一句完事结果就是模型根本不会在关键时刻加载这个技能包。name要语义化最好一眼能看出技能用途。description要用“触发场景”的方式来写而不是“功能罗列”的方式来写。举个我改过的例子--- name: weekly-report-generator description: 当用户需要撰写、改写或整理周报时使用输入本周工作记录输出结构化的周报支持按目标导向或过程导向组织内容。 ---对比一下常见的错误写法description: 这是一个周报生成器可以生成周报。这种写法的问题在于模型判断“什么时候该用”时靠的是当前任务与描述中的场景词是否匹配。如果描述太笼统模型会犹豫这个技能真的适合当前任务吗一犹豫它就干脆不用了。我的经验是description最好包含三个要素触发场景用户提出什么需求时、输入形式喂给它什么、输出结果它要产出什么。这样的描述等于替模型画好了调用边界。2.3 指令部分的设计原则少写形容词多写步骤frontmatter 下面是正文也就是instructions区。这部分是技能的核心直接决定模型按照什么路径执行任务。写得好的 instructions模型几乎不需要额外发散写得模糊的 instructions模型还是会自由发挥。我自己写指令时遵循几个原则所有操作步骤用有序列表编号从输入校验到最终输出顺序写清楚。每一条指令都要包含“动作 标准”比如“将用户提供的要点整理为不超过 200 字的摘要”比“简洁地总结一下”要可控得多。明确输出格式用代码块给出模板让模型直接往模板里填。写约束条件比如“不要使用 emoji”“不要编造数据”“如果信息不足先提问”。给出错误兜底分支比如“当用户输入为空时要求补充材料后重试”。另外还有一条容易踩的坑不要试图在 instructions 里塞“思考过程”。你可以告诉模型按步骤执行但不要规定它“你应该先思考 A再思考 B再得出结论”——那样反而会干扰模型本身的推理能力让它做起事来畏手畏脚。Skills 的价值是提供稳定模板和路径而不是替模型思考。3. 从零手写一个 Skill以“小红书种草文案生成器”为例3.1 需求定义先拆清楚这个技能要做什么理论讲再多不如亲手写一个。我给你还原一下我自己从零做“小红书种草文案生成器”这个 Skill 的完整过程你跟着走一遍就能上手。第一步定义需求。我希望这个技能能做到给出一款产品的核心卖点模型自动产出一篇符合小红书风格、语言自然、有真实体验感的种草文案并且附带 Tag。但这里马上会遇到一个问题什么叫“小红书风格”这个说法太模糊了模型很难把握。所以我要继续拆成可执行的标准正文长度控制在 300 到 500 字之间分 3 到 4 段。开头 1 到 2 句话直接亮明用户身份和使用场景不铺垫。中间段落必须包含“痛点描述、产品介入、使用感受”三段式结构。语气口语化允许使用“我真的会谢”“谁懂啊”这类平台常用表达但每篇不超过 2 处。结尾必须有 3 到 5 个井号 TagTag 与内容强相关。文案里不得编造具体的使用数据或效果承诺。把这些标准写清楚模型就知道自己在做什么而不是凭印象“模仿小红书”。3.2 编写 SKILL.md给模型一张完整的任务卡需求拆完之后我直接给你看我写好的 SKILL.md 核心部分你可以拿来改改用--- name: xiaohongshu-copywriter description: 当用户需要生成小红书种草风格的产品推广文案时使用。输入产品名称和核心卖点输出一篇口语化、结构清晰的种草笔记。 ---# 小红书种草文案生成 ## 任务目标 根据用户提供的产品信息和卖点生成一篇符合小红书平台调性的种草文案。 ## 输入要求 用户需提供产品名称、目标人群、1 到 3 个核心卖点。如果缺少目标人群先向用户确认再开始写。 ## 执行步骤 1. 提炼产品卖点判断最打动目标人群的一个核心角度作为全文主题。 2. 按照“痛点场景引入 - 产品自然介入 - 个人体验反馈”三段式结构组织正文。 3. 第一段直接描写用户遇到的具体问题不使用“大家好”“今天推荐”等套话开头。 4. 第二段介绍产品重点写产品如何解决前面提到的问题用一到两句描述使用细节增强真实感。 5. 第三段给出个人感受语气口语化可以使用“真的绝”“后悔没早买”等表达但全文不超过 2 处不许堆砌。 6. 生成 3 到 5 个内容强相关的 Tag置于正文末尾每个 Tag 使用井号开头。 ## 输出格式 输出 Markdown 文本正文位于 Tag 之前。整体长度控制在 300 到 500 字。 ## 硬性约束 - 不得编造使用效果数据和具体用户评价。 - 不出现价格信息除非用户主动给出。 - 不出现违禁词如“最”“第一”“百分百”等绝对化用语。 - 如果用户提供的卖点不足以支撑写作先向用户询问补充信息而不是直接生成。 ## 示例 参考 reference/example.md 中的两篇范文模仿其段落节奏但不要照抄句式。写完之后我在reference/example.md里放了两篇自己写好的范文一篇是美妆类一篇是数码类。目的是给模型提供风格参照让它知道“口语化”到底是一个什么量级。3.3 调试与验证不经过测试的技能不要上生产Skill 第一次写好基本是跑不通的。我每次都会做一轮调试过程大概三步。先把 SKILL.md 的内容直接粘到对话里当 prompt 用。这一步花了大概十分钟主要是看模型能不能完全理解指令里的每个要求。第一次测试时模型写出来的文案还是偏官方问题出在“口语化”这个词上。于是我把第三段改成“允许使用‘我真的会谢’‘谁懂啊’‘救命’这类表达但每篇不超过 2 处”效果立刻稳定了不少。把 Skill 放进 Agent 平台做一个真实调用。这里要看的不仅是输出质量还有模型是否会在任务开始时主动加载 Skill。如果模型没加载基本就是description里的触发场景写得太窄我通常会把“种草”“推广文案”“小红书笔记”这种同义词都补进去。跑几个边界用例。比如输入信息缺失、产品卖点过于夸张、用户给的素材里有违禁词。每跑一个用例我就在 SKILL.md 的“硬性约束”里补一条规则。现在这个技能我总共测过二十多轮约束从最初的 4 条增加到 8 条输出质量越来越稳定。4. 管理 Skills 的黄金实践从够用到好用4.1 命名、分类与版本管理像维护代码一样维护技能库技能一旦多了管理就会变成新的成本。我现在维护着十来个 Skills包括周报生成、小红书文案、SQL 优化检查、读书笔记整理、发票信息提取等。如果不做好管理模型在选择技能时反而容易出现混乱。命名我统一用“动词-对象”的结构比如weekly-report-generator、xiaohongshu-copywriter、invoice-info-extractor一眼就能看出它是干什么的。目录上按领域分一层writing/、data/、office/这样找起来方便也方便以后挂到不同的 Agent 项目里。版本管理也很重要。Skill 的迭代非常频繁今天加一条约束明天修一个 bug如果没有 git 记录改错了很难回溯。我的习惯是每个 Skill 目录都是独立的 git 仓库每次调整都写清楚 commit message比如“fix: 增加违禁词过滤规则”。这样万一新版本效果反而不如旧版可以随时回退。4.2 评估第三方 Skill 的可靠度四个检查点现在社区里已经有人开始分享打包好的 Skills 了但你下载回来不能直接用得先做评估。我一般看四个检查点。看description是否清晰。如果一个 Skill 的描述写得很泛说明作者自己都没想清楚它什么时候该被调用这类技能大概率也帮不上忙。看脚本代码和依赖。如果 SKILL.md 里说要运行某个脚本我会先打开脚本读一遍确认它不会执行删除文件、上传数据、修改系统配置这类危险操作。看是否有示例输出。没有示例的 Skill很难验证作者声称的效果。看迭代历史。在 git 里看这个项目最近有没有更新、commit 信息有没有实质内容能够判断作者是否认真维护。这四条里安全审查是底线。AI 生成的代码本身就可能包含不可控的逻辑更不用说网上那些来路不明的 Skill。我自己的原则是凡是需要调用脚本的第三方 Skill必须逐行审查后才能进本地库。4.3 提高技能命中率的两个小技巧在用 Skills 的过程中我还发现两个能立竿见影提升“命中率”的细节。在 Agent 的系统提示词里加一行“索引提示”。比如写上“当用户要求写小红书文案时参考 xiaohongshu-copywriter 技能”。别小看这一行它相当于直接告诉模型“这里有现成工具可以用”比让模型在无数目录里自己找要快得多。我加了这行之后技能被加载的概率从六成提到了九成以上。定期清理低效 Skills。如果一个 Skill 连续两周都没被触发过我会翻出来重新看一遍多半是描述里触发场景写得太窄或者功能已经被其他技能覆盖了。及时合并和删除能防止技能库越来越臃肿也能减少模型“选错技能”的情况发生。5. 调试经验与常见问题实录5.1 我踩过的三个典型的坑先说第一个坑description写得太宽泛。我最早是一个“通用文案助手”技能描述写的是“帮助用户写各种文案”结果模型不管遇到什么写作任务都加载它反而干扰了其他更专业的技能。后来我把这个技能拆分成小红书、知乎、公众号三个独立技能后情况才好转。真相是技能的触发词要聚焦才能让模型在正确的时间调用正确的能力。第二个坑指令前后自相矛盾。有一次我在技能里写了“保持简洁”的要求却在执行步骤里让它“详细展开每个卖点每点不少于 100 字”。模型拿到这种互相打架的指令输出结果非常飘忽把两个要求都理解歪了。后来我养成了习惯写完之后通读一遍专门找前后冲突的约束发现一个改一个。第三个坑把思考过程写进指令。我一度在指令里规定“模型应该先分析用户心理再分析产品卖点再构建文案结构”结果模型输出的文案总有一种“端着”的感觉读着不自然。后来把思考过程删掉只保留动作步骤和输出标准反而好多了。这说明 Skills 更适合约束“做什么、按什么顺序做、做出什么质量”而不适合约束“大脑里面怎么转”。5.2 快速排查手册技能不生效怎么办用的时候总会遇到“模型根本不理我的 Skill”的情况我整理了最常见的排查清单现象可能原因处理办法技能从未被加载description 缺少触发场景词补充同义场景词在系统提示词中加索引加载了但输出不符合格式指令里缺少明确输出模板给一个完整的 Markdown 示例结构模型绕开技能自己写代码技能缺少示例或步骤不够具体增加示例文件和更细的步骤说明输出质量不稳定约束条件存在歧义或冲突逐条检查规则删除模糊表达技能在某些对话中失效已加载技能太多模型辨识负担大精简技能数量合并重复能力我每次调试新技能时都按这张表过一遍基本能覆盖 80% 的问题。剩下的 20%基本都是脚本本身的 bug那就要靠看日志和加上临时打印把数据流理清楚。5.3 发布前的最后一次检查清单在把 Skill 正式放进生产环境前我还会再花五分钟做一次收尾检查你也可以直接拿来当自己的清单描述里是否写清楚了“什么时候用”和“怎么输入”。instructions 是否全部可执行没有假设模型能“理解就好”的模糊表述。有没有提供至少一个输出示例如果有脚本是否在自己的机器上跑通过。有没有备份 git 提交记录确认可以随时回滚。是否在真实 Agent 会话里完整体验过一轮而不仅仅是单独测试过 Prompt。这套检查做完Skill 的可靠性基本就有保障了。最后说点个人体会。Skill 这东西上手门槛非常低你可能十分钟就能写出第一个版本但把它打磨到“稳定好用”却是个持续迭代的活。我现在的习惯是每次模型输出翻车我不急着改提示词而是先回来翻 Skill 本身——是描述没写准还是步骤有歧义还是示例误导了方向。这就像带新人稿子写好得靠流程清晰、标准明确、案例充分光喊“你要努力写好啊”是没用的。如果你正准备在自己的项目里引入 Skills建议从一个高频、重复、有明确输出格式的小任务开始试水跑通之后再慢慢拓宽。等技能库有了规模你会明显感觉到 Agent 的整体可用性提升一大截。
最近在技术社区里泡着大家张口闭口都是 Agent、智能体、工作流自动化但我自己最大的体感是真正让 Agent 从“玩具”变成能干活“工具”的关键往往不在模型选得有多强而在你有没有给它配好一套“Skills”。这个词直译过来是“技能”放在 AI 圈里它不是一个虚的岗位能力清单而是一套有结构、可复用、能让大模型稳定执行具体任务的模板和脚本集合。如果你刚接触 AI 编程或者正在公司里折腾智能体落地这篇内容大概适合你。我会从最基础的概念讲起跟你拆解 Skills 的标准结构然后带你手写一个能直接用的 Skill最后把我在实际调试中踩过的坑和排查思路一次性捋清楚。不是学院派那种从原理到原理而是我自己在真实项目里测过、调过、用过之后沉淀下来的东西。1. 先搞清楚Skills 在 AI Agent 里到底是个什么角色1.1 为什么模型越来越聪明做具体任务还是翻车先说个现象。早期大家玩 Agent基本思路就是“提示词驱动”在系统提示词里塞一堆规则让模型按规则做事情。但这个方案有个硬伤——提示词越长模型越容易“选择性失聪”前半段记得好好的后半段就开始自由发挥。你今天给它说“输出要分三段、每段要有小标题、语气要活泼”它明天可能就给你回一篇论文风。不是模型变笨了而是所有指令都挤在一条上下文里模型很难分清哪些是原则、哪些是临场说明。Skills 要解决的就是这个痛点。它的思路很朴素把完成某类具体任务的完整经验——包括背景说明、操作步骤、输出格式、调用脚本、参考案例——打包成一个独立的小目录放着备用。模型在对话里一旦识别出任务匹配就去加载这个 Skill按里面的剧本走。相当于你不再要求模型“临场背出全本 SOP”而是明确告诉它遇到这类活去抽屉里拿那张任务卡按卡片上的步骤干。这里有一个很关键的转变以前我们是在“教模型说话”现在是在“给模型配工具”。1.2 Skills 和 Prompt、MCP 的区别到底在哪很多人会把 Skills 跟 Prompt 混在一起也会把 Skills 跟 MCPModel Context Protocol搞混。我在群里聊天时发现这是咨询频率最高的问题。Prompt 是一段一次性对话指令它跟着每次会话的上下文一起走作用是“告诉模型当次任务的具体要求”。Skills 呢它是可以长期保存、按需调用的任务模块目标是让模型在特定场景下稳定复现一套流程。MCP 则是另一回事它解决的是“模型怎么连接外部系统”的问题比如让它能读取数据库、调用 API、操作本地文件。做一个生活化的类比MCP 是给模型一把螺丝刀和扳手Skills 则是一份“怎么换灯泡”的图文步骤说明书。螺丝刀解决的是“手里有没有工具”Skills 解决的是“知不知道该按什么顺序用工具”。我整理了一张对比表方便你一眼看明白维度PromptSkillMCP本质一次性指令可复用任务模板外部工具连接协议生命周期随对话存在长期保存按需加载长期部署按需调用解决痛点让模型理解当次需求让模型稳定执行复杂流程让模型能接触外部数据与功能典型形态一段文字文件/目录含 SKILL.md服务/接口理解完这三者的边界你在设计 Agent 方案时就不会走偏了。判断标准很简单如果你需要的是“告诉模型怎么做”优先写 Skill如果你需要的是“让模型能碰到某个系统”才需要考虑 MCP。2. 读懂 Skill 的标准结构一个好技能包长什么样2.1 目录结构SKILL.md 是灵魂文件现在主流 Agent 平台对 Skills 的约定已经趋于一致核心就是一个目录加一个灵魂文件。我在本地维护一个skills/文件夹里面按“一个技能一个子目录”管理典型的结构长这样skills/ └── weekly-report/ ├── SKILL.md ├── scripts/ │ └── format_report.py └── reference/ └── examples.mdSKILL.md是这个技能包的大脑一切指令和流程都写在里面。scripts/用于存放可执行的脚本比如需要做数据处理、内容格式化、文件整理时直接提供现成代码给模型调用避免它现场发挥写错。reference/则放参考材料比如范文、示例输出、数据字典模型写结果之前会先翻阅这些内容作为参照。为什么要这么拆我的理解是这个结构本质上是在给模型做“认知降噪”。把步骤说明、执行脚本、参考案例分开模型在加载 Skill 时能更快定位自己该看哪个文件而不是在一个超长的 Markdown 里上下翻找。实测下来这种分离结构能明显降低模型在复杂任务里的“迷路”概率。2.2 描述写得越“准”技能被调用的概率才越高SKILL.md 的开头通常有一段 YAML 格式的 frontmatter里面最重要的两个字段是name和description。很多新手会忽略这两个字段的价值随便写一句完事结果就是模型根本不会在关键时刻加载这个技能包。name要语义化最好一眼能看出技能用途。description要用“触发场景”的方式来写而不是“功能罗列”的方式来写。举个我改过的例子--- name: weekly-report-generator description: 当用户需要撰写、改写或整理周报时使用输入本周工作记录输出结构化的周报支持按目标导向或过程导向组织内容。 ---对比一下常见的错误写法description: 这是一个周报生成器可以生成周报。这种写法的问题在于模型判断“什么时候该用”时靠的是当前任务与描述中的场景词是否匹配。如果描述太笼统模型会犹豫这个技能真的适合当前任务吗一犹豫它就干脆不用了。我的经验是description最好包含三个要素触发场景用户提出什么需求时、输入形式喂给它什么、输出结果它要产出什么。这样的描述等于替模型画好了调用边界。2.3 指令部分的设计原则少写形容词多写步骤frontmatter 下面是正文也就是instructions区。这部分是技能的核心直接决定模型按照什么路径执行任务。写得好的 instructions模型几乎不需要额外发散写得模糊的 instructions模型还是会自由发挥。我自己写指令时遵循几个原则所有操作步骤用有序列表编号从输入校验到最终输出顺序写清楚。每一条指令都要包含“动作 标准”比如“将用户提供的要点整理为不超过 200 字的摘要”比“简洁地总结一下”要可控得多。明确输出格式用代码块给出模板让模型直接往模板里填。写约束条件比如“不要使用 emoji”“不要编造数据”“如果信息不足先提问”。给出错误兜底分支比如“当用户输入为空时要求补充材料后重试”。另外还有一条容易踩的坑不要试图在 instructions 里塞“思考过程”。你可以告诉模型按步骤执行但不要规定它“你应该先思考 A再思考 B再得出结论”——那样反而会干扰模型本身的推理能力让它做起事来畏手畏脚。Skills 的价值是提供稳定模板和路径而不是替模型思考。3. 从零手写一个 Skill以“小红书种草文案生成器”为例3.1 需求定义先拆清楚这个技能要做什么理论讲再多不如亲手写一个。我给你还原一下我自己从零做“小红书种草文案生成器”这个 Skill 的完整过程你跟着走一遍就能上手。第一步定义需求。我希望这个技能能做到给出一款产品的核心卖点模型自动产出一篇符合小红书风格、语言自然、有真实体验感的种草文案并且附带 Tag。但这里马上会遇到一个问题什么叫“小红书风格”这个说法太模糊了模型很难把握。所以我要继续拆成可执行的标准正文长度控制在 300 到 500 字之间分 3 到 4 段。开头 1 到 2 句话直接亮明用户身份和使用场景不铺垫。中间段落必须包含“痛点描述、产品介入、使用感受”三段式结构。语气口语化允许使用“我真的会谢”“谁懂啊”这类平台常用表达但每篇不超过 2 处。结尾必须有 3 到 5 个井号 TagTag 与内容强相关。文案里不得编造具体的使用数据或效果承诺。把这些标准写清楚模型就知道自己在做什么而不是凭印象“模仿小红书”。3.2 编写 SKILL.md给模型一张完整的任务卡需求拆完之后我直接给你看我写好的 SKILL.md 核心部分你可以拿来改改用--- name: xiaohongshu-copywriter description: 当用户需要生成小红书种草风格的产品推广文案时使用。输入产品名称和核心卖点输出一篇口语化、结构清晰的种草笔记。 ---# 小红书种草文案生成 ## 任务目标 根据用户提供的产品信息和卖点生成一篇符合小红书平台调性的种草文案。 ## 输入要求 用户需提供产品名称、目标人群、1 到 3 个核心卖点。如果缺少目标人群先向用户确认再开始写。 ## 执行步骤 1. 提炼产品卖点判断最打动目标人群的一个核心角度作为全文主题。 2. 按照“痛点场景引入 - 产品自然介入 - 个人体验反馈”三段式结构组织正文。 3. 第一段直接描写用户遇到的具体问题不使用“大家好”“今天推荐”等套话开头。 4. 第二段介绍产品重点写产品如何解决前面提到的问题用一到两句描述使用细节增强真实感。 5. 第三段给出个人感受语气口语化可以使用“真的绝”“后悔没早买”等表达但全文不超过 2 处不许堆砌。 6. 生成 3 到 5 个内容强相关的 Tag置于正文末尾每个 Tag 使用井号开头。 ## 输出格式 输出 Markdown 文本正文位于 Tag 之前。整体长度控制在 300 到 500 字。 ## 硬性约束 - 不得编造使用效果数据和具体用户评价。 - 不出现价格信息除非用户主动给出。 - 不出现违禁词如“最”“第一”“百分百”等绝对化用语。 - 如果用户提供的卖点不足以支撑写作先向用户询问补充信息而不是直接生成。 ## 示例 参考 reference/example.md 中的两篇范文模仿其段落节奏但不要照抄句式。写完之后我在reference/example.md里放了两篇自己写好的范文一篇是美妆类一篇是数码类。目的是给模型提供风格参照让它知道“口语化”到底是一个什么量级。3.3 调试与验证不经过测试的技能不要上生产Skill 第一次写好基本是跑不通的。我每次都会做一轮调试过程大概三步。先把 SKILL.md 的内容直接粘到对话里当 prompt 用。这一步花了大概十分钟主要是看模型能不能完全理解指令里的每个要求。第一次测试时模型写出来的文案还是偏官方问题出在“口语化”这个词上。于是我把第三段改成“允许使用‘我真的会谢’‘谁懂啊’‘救命’这类表达但每篇不超过 2 处”效果立刻稳定了不少。把 Skill 放进 Agent 平台做一个真实调用。这里要看的不仅是输出质量还有模型是否会在任务开始时主动加载 Skill。如果模型没加载基本就是description里的触发场景写得太窄我通常会把“种草”“推广文案”“小红书笔记”这种同义词都补进去。跑几个边界用例。比如输入信息缺失、产品卖点过于夸张、用户给的素材里有违禁词。每跑一个用例我就在 SKILL.md 的“硬性约束”里补一条规则。现在这个技能我总共测过二十多轮约束从最初的 4 条增加到 8 条输出质量越来越稳定。4. 管理 Skills 的黄金实践从够用到好用4.1 命名、分类与版本管理像维护代码一样维护技能库技能一旦多了管理就会变成新的成本。我现在维护着十来个 Skills包括周报生成、小红书文案、SQL 优化检查、读书笔记整理、发票信息提取等。如果不做好管理模型在选择技能时反而容易出现混乱。命名我统一用“动词-对象”的结构比如weekly-report-generator、xiaohongshu-copywriter、invoice-info-extractor一眼就能看出它是干什么的。目录上按领域分一层writing/、data/、office/这样找起来方便也方便以后挂到不同的 Agent 项目里。版本管理也很重要。Skill 的迭代非常频繁今天加一条约束明天修一个 bug如果没有 git 记录改错了很难回溯。我的习惯是每个 Skill 目录都是独立的 git 仓库每次调整都写清楚 commit message比如“fix: 增加违禁词过滤规则”。这样万一新版本效果反而不如旧版可以随时回退。4.2 评估第三方 Skill 的可靠度四个检查点现在社区里已经有人开始分享打包好的 Skills 了但你下载回来不能直接用得先做评估。我一般看四个检查点。看description是否清晰。如果一个 Skill 的描述写得很泛说明作者自己都没想清楚它什么时候该被调用这类技能大概率也帮不上忙。看脚本代码和依赖。如果 SKILL.md 里说要运行某个脚本我会先打开脚本读一遍确认它不会执行删除文件、上传数据、修改系统配置这类危险操作。看是否有示例输出。没有示例的 Skill很难验证作者声称的效果。看迭代历史。在 git 里看这个项目最近有没有更新、commit 信息有没有实质内容能够判断作者是否认真维护。这四条里安全审查是底线。AI 生成的代码本身就可能包含不可控的逻辑更不用说网上那些来路不明的 Skill。我自己的原则是凡是需要调用脚本的第三方 Skill必须逐行审查后才能进本地库。4.3 提高技能命中率的两个小技巧在用 Skills 的过程中我还发现两个能立竿见影提升“命中率”的细节。在 Agent 的系统提示词里加一行“索引提示”。比如写上“当用户要求写小红书文案时参考 xiaohongshu-copywriter 技能”。别小看这一行它相当于直接告诉模型“这里有现成工具可以用”比让模型在无数目录里自己找要快得多。我加了这行之后技能被加载的概率从六成提到了九成以上。定期清理低效 Skills。如果一个 Skill 连续两周都没被触发过我会翻出来重新看一遍多半是描述里触发场景写得太窄或者功能已经被其他技能覆盖了。及时合并和删除能防止技能库越来越臃肿也能减少模型“选错技能”的情况发生。5. 调试经验与常见问题实录5.1 我踩过的三个典型的坑先说第一个坑description写得太宽泛。我最早是一个“通用文案助手”技能描述写的是“帮助用户写各种文案”结果模型不管遇到什么写作任务都加载它反而干扰了其他更专业的技能。后来我把这个技能拆分成小红书、知乎、公众号三个独立技能后情况才好转。真相是技能的触发词要聚焦才能让模型在正确的时间调用正确的能力。第二个坑指令前后自相矛盾。有一次我在技能里写了“保持简洁”的要求却在执行步骤里让它“详细展开每个卖点每点不少于 100 字”。模型拿到这种互相打架的指令输出结果非常飘忽把两个要求都理解歪了。后来我养成了习惯写完之后通读一遍专门找前后冲突的约束发现一个改一个。第三个坑把思考过程写进指令。我一度在指令里规定“模型应该先分析用户心理再分析产品卖点再构建文案结构”结果模型输出的文案总有一种“端着”的感觉读着不自然。后来把思考过程删掉只保留动作步骤和输出标准反而好多了。这说明 Skills 更适合约束“做什么、按什么顺序做、做出什么质量”而不适合约束“大脑里面怎么转”。5.2 快速排查手册技能不生效怎么办用的时候总会遇到“模型根本不理我的 Skill”的情况我整理了最常见的排查清单现象可能原因处理办法技能从未被加载description 缺少触发场景词补充同义场景词在系统提示词中加索引加载了但输出不符合格式指令里缺少明确输出模板给一个完整的 Markdown 示例结构模型绕开技能自己写代码技能缺少示例或步骤不够具体增加示例文件和更细的步骤说明输出质量不稳定约束条件存在歧义或冲突逐条检查规则删除模糊表达技能在某些对话中失效已加载技能太多模型辨识负担大精简技能数量合并重复能力我每次调试新技能时都按这张表过一遍基本能覆盖 80% 的问题。剩下的 20%基本都是脚本本身的 bug那就要靠看日志和加上临时打印把数据流理清楚。5.3 发布前的最后一次检查清单在把 Skill 正式放进生产环境前我还会再花五分钟做一次收尾检查你也可以直接拿来当自己的清单描述里是否写清楚了“什么时候用”和“怎么输入”。instructions 是否全部可执行没有假设模型能“理解就好”的模糊表述。有没有提供至少一个输出示例如果有脚本是否在自己的机器上跑通过。有没有备份 git 提交记录确认可以随时回滚。是否在真实 Agent 会话里完整体验过一轮而不仅仅是单独测试过 Prompt。这套检查做完Skill 的可靠性基本就有保障了。最后说点个人体会。Skill 这东西上手门槛非常低你可能十分钟就能写出第一个版本但把它打磨到“稳定好用”却是个持续迭代的活。我现在的习惯是每次模型输出翻车我不急着改提示词而是先回来翻 Skill 本身——是描述没写准还是步骤有歧义还是示例误导了方向。这就像带新人稿子写好得靠流程清晰、标准明确、案例充分光喊“你要努力写好啊”是没用的。如果你正准备在自己的项目里引入 Skills建议从一个高频、重复、有明确输出格式的小任务开始试水跑通之后再慢慢拓宽。等技能库有了规模你会明显感觉到 Agent 的整体可用性提升一大截。
