说实话我最近被问得最多的一个问题就是AI 的 Skill 到底怎么学市面上聊 Skill 的文章不少但大部分都在讲我这个 Skill 多牛很少有人讲清楚你该怎么从零到一做出一个能稳定复用的 Skill。直到我认真跟了宝玉老师那套 5 步工程化流程才有一种通了的感觉——原来提示词不是用来写的而是用来做的。这篇文章不聊虚的。我把自己踩过的坑、反复验证过的步骤、以及从宝玉老师那套方法论里提炼出的实操要点完整梳理一遍。内容会覆盖 Skill 到底是什么、它和 Agent/Workflow 的区别在哪、5 步流程具体怎么落地、以及常见的翻车场景怎么排查。不管你是刚开始接触 AI 的新手还是已经在写提示词的进阶玩家照着这个流程走一遍你也能把手里的零散提示词沉淀成真正可复用的能力。1. 先搞清楚 Skill 的本质它凭什么比提示词值钱1.1 Skill 不是新概念只是把提示词工程化了很多人一听到 Skill 就觉得是个多高深的东西其实没那么玄乎。它本质上还是一个提示词或者说是一套结构化的提示词配套逻辑。区别在于普通提示词是一次性手写的纸条用完就丢Skill 是做成了标准件的工具任何时候拿出来都能用而且别人也能用。我举个生活化的例子。菜谱和速冻料理包的区别就是普通提示词和 Skill 的区别。菜谱写得再详细你还得自己备菜、掌握火候、应对突发状况速冻料理包是已经把调味、分量、步骤都标准化好了你只需要按说明书加热出来的味道就能稳定在 80 分以上。Skill 追求的就是这种稳定在 80 分以上的效果。在 AI 编程工具 Cursor、Codex、Claude 这类场景里Skill 承载的就是一整套专业工作方法。比如你想让 AI 帮你做专利分析如果只是随手写一句帮我分析这个专利你得到的答案很可能泛泛而谈但如果你有一个专利分析 Skill它内部可能包含了检索策略、权利要求拆解方法、对比维度、输出模板——这就是工程化和非工程化的差距。1.2 Skill、Agent、Workflow 三者的边界与关系这三个词经常被混在一起聊但它们的定位完全不同。我用一句话分别概括Prompt提示词你给模型的一句话或一段指令是一次性输入。Skill技能把完成某一类任务的方法论封装成可复用的模块比如写代码审查做竞品分析生成测试用例。它是 Prompt 的高级形态。Agent智能体能自主决策、调用工具、执行任务循环的执行者它会根据目标动态选择用哪个 Skill。Workflow工作流把多个步骤串成固定的流水线比如输入需求 → 拆任务 → 调 Skill A → 调 Skill B → 汇总输出。它们的关系像什么Workflow 是一条流水线Agent 是流水线上的车间主任Skill 是车间里一个个标准化工位而 Prompt 是你在工位上写的具体操作单。在实际项目中Skill 和 Agent 是配合关系。Agent 负责什么时候用、用哪个、用完之后怎么办Skill 负责这个具体活怎么干得漂亮。所以你在 Cursor、Codex 里看到的 Skill往往都是被 Agent 按需调用的。如果你只学 Agent 不学 Skill就像只学会了开公司却不懂业务执行只学 Prompt 不学 Skill又像是只会写操作单却不懂如何封装成流程。1.3 为什么现在学 Skill 正当时今年 AI 圈的明显变化是大家不再比谁的 Prompt 写得华丽而是比谁能把能力沉淀下来。大模型本身会持续升级但 Skill 是你自己的资产——你封装好的方法、验证过的逻辑、打磨过的输出格式不会因为换了模型就失效。另一个原因是工具生态逐渐成熟。Cursor、Codex 这类编程工具已经支持 SKILL.md 的规范市面上也出现了大量skill 插件分享站。这意味着 Skill 已经开始像软件插件一样流通你写一个好的 Skill别人可以直接安装使用这是普通提示词做不到的。说白了学 Skill 是用今天的投入换明天的复利越早开始你的积累就比别人厚。2. 宝玉老师 5 步工程化流程的整体设计逻辑2.1 5 步流程全景从想法到沉淀的完整闭环宝玉老师那套方法核心是把做 Skill 这件事从灵感驱动变成流程驱动。我把它整理成 5 个步骤步骤动作核心产出常被忽略的关键点第一步定义问题任务描述书明确输入、输出、边界和约束第二步结构化设计提示词提示词初版分角色、分步骤、有格式约束第三步建立测试集并迭代测试报告优化记录用真实样本量化评估第四步封装为 SkillSKILL.md 配套资源让 Agent 知道何时用、怎么用第五步版本管理与复用技能库命名规范、版本日志、跨项目移植我第一次看到这个流程时觉得挺普通的好像每个步骤都知道。但真按它做下来才发现以前自己做 Skill 翻车正是因为跳过了其中某几步——要么没定义好输入输出就开写要么没有测试集只靠感觉还行要么封装的 SKILL.md 缺少触发条件描述导致 Agent 不知道该在什么时候调用它。2.2 每步设计背后的底层逻辑不是拍脑袋定的先看第一步定义问题。这一步为什么放在最前面因为大模型对模糊问题的回答质量天然低于对明确问题的回答。你告诉它帮我写个总结和告诉它请阅读以下会议纪要按决策事项、待办任务、风险点三个维度输出一份总结每条待办必须包含负责人、截止日期——这两者的效果差距是巨大的。第二步结构化设计提示词本质是把你的思维方式外挂给模型。人类专家解决问题时有隐性知识比如先判断类型、再选择策略、最后按格式输出。Skill 要做的是把这些隐性知识显性化。步骤拆得越细模型的执行就越稳定。这里的一个关键技巧是不要把步骤写得太死要给模型留出判断空间否则遇到边界情况它就傻了。第三步建立测试集在很多人看来是最容易被跳过的。大家习惯写几个 Prompt 试一下就自我感觉良好但 Skill 是给一类任务用的不是给一个例子用的。你得准备一份覆盖典型场景、边界场景、异常场景的测试集每个样本都要有及格线标准。我自己的想法是宁可花一小时建测试集也别省这个时间因为省掉的每一分钟都会在后续调试里加倍还回来。第四步封装和第五步版本管理是把个人能力转成组织资产的关键。Skill 一旦封装好就不仅是你能用你的同事、你的团队都能用。版本管理则保证你改了 A 功能不会让 B 功能挂掉——这在多轮迭代后尤其重要。2.3 工程化思维 vs. 普通写提示词的本质差异说白了普通写提示词是在跟模型对话工程化做 Skill 是在给模型设计一套工作制度。前者是点和点的交互后者是面和面的体系建设。我见过很多朋友在聊天框里把提示词越写越长角色、背景、格式要求全堆在一起像一篇小作文。这种提示词在单次对话里可能效果不错但换个场景、换个模型、换个输入内容效果立刻打折扣。为什么因为它没有结构、没有边界、没有容错逻辑。工程化思维追求的是在约束条件下最稳定地完成任务。它要求你做四件事一是明确输入输出边界什么该收什么不该收二是把任务拆成可执行的步骤让模型按流程走而不是自由发挥三是预设异常情况比如输入为空、格式不对时怎么办四是定义输出格式用 Markdown、JSON 还是表格。这四件事做完你的提示词就不再是一段话而是一套操作手册。宝玉老师那套流程最让我受益的地方就是把做 Skill从玄学变成了工程。你不用依赖灵光一闪只需要按步骤推进每一步都有明确产出每一步都可以验证。说白了工程化不是束缚而是让你每一次创作都站在上一次的基础上往前够一点。3. 实操拆解5 步流程每一步具体怎么落地3.1 第一步把模糊需求变成明确的输入输出定义很多人在这一步犯的错是想也不想就开始写提示词。你以为自己知道想要什么但一旦落笔就发现根本不是那么回事。我建议你准备一个任务描述书模板至少包含这几个字段任务名称用一句话说清楚这个 Skill 干什么比如从技术文档中提取 API 变更点并生成迁移说明。输入定义明确这个 Skill 接收什么。是用户粘贴文本是上传文件还是从上下文里读取最好给出必需输入和可选输入。输出定义明确产出物的格式和内容结构。是列表是 Markdown 文档是 JSON 数据每条内容有什么要求约束条件比如字数上限、禁止编造、引用原文时必须标注出处等。边界说明这个 Skill 不负责什么。比如只做信息提取不做代码修改建议避免 Agent 拿着 Skill 去发散。我第一次做专利分析 Skill时就是因为没定义好输入边界结果模型把专利对比范围理解错了输出结果偏得离谱。后来我把输入定义写成接受一段专利文本可选接收对比技术清单不接收图像输入问题立刻解决。这步做得好后面所有环节都顺。3.2 第二步用结构化模板写提示词而不是聊天式乱写结构化提示词的常见写法是把一个复杂的任务拆成角色、目标、步骤、约束、输出格式、示例这几个模块。我自己常用的模板是这样的# 角色 你是一名有 X 年经验的 [领域专家]擅长 [核心能力]。 # 任务目标 在 [场景] 下帮助用户完成 [具体目标]。 # 执行步骤 1. 先 [第一步动作]判断输入内容是否符合要求。 2. 然后 [第二步动作]提取关键信息。 3. 最后 [第三步动作]按指定格式输出结果。 # 约束条件 - 不得编造数据或事实所有信息须来自输入文本。 - 如果输入信息不足明确告知缺少XX信息而不是硬补。 - 输出结果控制在 [字数/行数] 以内。 # 输出格式 [描述输出格式比如用 Markdown 表格呈现包含以下列...] # 示例 输入... 输出...这套模板的好处是模型能在一个清晰的框架里工作不会东一句西一句。尤其是示例模块价值极高——大模型从少量示例中学习的能力很强一个精心设计的正例往往比十句话的描述更管用。还要注意一个点提示词里的角色不要瞎写。不要为了华丽给它安一个世界级大师的帽子而是要写清楚它具备什么方法论、按什么标准工作。比如你是一个遵守专利审查指南的专利分析师比你是顶尖专利专家更有用因为前者给模型的约束更具体。3.3 第三步建立测试集用数据说话而不是感觉还不错这一步是整个流程里最容易被忽视的也是决定 Skill 上限的关键。我强烈建议你准备一个专门的测试集文件至少包含 10 到 20 个测试样本每个样本标注了标准答案或及格线。测试集的构成建议典型样本60%最常规的输入场景用来验证主流程是否顺畅。边界样本20%比如超长输入、极短输入、特殊字符、空字段测试 Skill 的鲁棒性。异常样本20%比如输入内容与任务不匹配、包含矛盾信息、格式乱排的文本测试 Skill 能否正确处理或拒绝处理。我通常用表格来管理测试集样本编号输入内容摘要预期输出要点实际输出情况是否通过T01正常会议纪要输出决策、待办、风险三块结构完整是T02空文档提示无有效内容有点跑偏否T03全英文输入输出跟随英文OK是每轮迭代后重新跑一遍测试集记录通过率和失败原因。你会发现一个规律改了一个地方可能解决 3 个问题但会引发 1 个新问题。没有测试集的话你根本无法察觉那个新问题是什么时候冒出来的。说句实在话我自己 80% 的 Skill 质量提升都来自测试集和迭代记录的功劳而不是一次性写出完美提示词。3.4 第四步封装成 SKILL.md让模型自己学会怎么用到了这一步你的提示词已经比较稳定了接下来要解决的是Agent 怎么知道什么时候该用你的问题。这就涉及到 SKILL.md 的封装规范。SKILL.md 是很多 AI 工具认可的技能描述文件它和普通提示词最核心的区别是它多了一个元信息层用于描述技能的触发条件和使用场景。我把 SKILL.md 的核心字段整理如下--- name: 文档总结专家 description: 在用户需要从文档中提取关键信息时使用。 - 输入用户提供一段文档文本或文件路径 - 输出结构化的 Markdown 总结报告 - 适用场景会议纪要、技术文档、论文、专利文本 - 不适用场景代码审查、图片理解 --- # 执行流程 这里是你的结构化提示词内容注意 description 字段的写法它要像电梯演讲一样让 Agent 一眼就明白这个 Skill 适合干什么。不要写这是一个文档总结工具这种废话要写当用户需要将长文本转化为结构化摘要时使用该 Skill。这样 Agent 在自主决策时才更容易把它匹配到用户的真实需求上。另外如果 Skill 逻辑比较复杂还可以创建references目录放参考文档或者用scripts目录放辅助脚本。但我的经验是第一版不要搞得太复杂一个 SKILL.md 文件能跑通就先用着后面再逐步拆分。3.5 第五步版本管理、命名规范与复用实践很多人做到第四步就觉得大功告成了但真正拉开差距的是第五步。Skill 和代码一样需要版本管理和沉淀迭代的意识。我的做法是为每一个 Skill 单独建目录目录结构如下skills/ document-summarizer/ SKILL.md tests/ test_cases.md iterative_log.md examples/ sample_input.txt sample_output.md命名规范我强烈建议用短横线命名法kebab-case比如document-summarizer、code-reviewer、meeting-minutes-agent。不要用中文命名目录也不要用空格和特殊字符因为很多工具对中文路径支持得不好跨平台移植时容易出问题。版本管理可以用 Git也可以简单地在 SKILL.md 头部加一个version字段。我建议至少做三件事每次修改后更新版本号比如 v1.0、v1.1。维护一个变更日志CHANGELOG记录改了什么、为什么改、验证结果如何。在 SKILL.md 的元信息里加last_updated时间戳。复用这块我的心得是不要把 Skill 焊死在某一个工具里。写成纯文本的 SKILL.md理论上可以在 Cursor、Codex、Claude 等不同工具间迁移。虽然各家规范略有差异但结构化描述任务 定义触发条件 明示执行步骤这个大原则是通用的。4. 一个真实案例把周报生成做成可复用的 Skill4.1 需求与边界定义理论讲再多不如实际操作一遍。我拿最近做的一个周报生成 Skill来完整演示。需求背景是我发现自己每周都要花半小时整理周报输入是无序的工作记录输出是老板喜欢的结构。这个需求看起来很普通但真做起来有不少细节。任务描述书写成这样任务名称周报生成器输入定义用户提供一周工作记录可以是无序列表、段落、语音转文字的内容可选提供本周项目目标。输出定义一份 Markdown 格式周报包含「本周重点成果」「问题与风险」「下周计划」三个板块每个板块内容不超过 5 条。约束条件所有内容必须来自用户输入禁止编造如果同一件事被重复提及合并去重没有提到的板块就写暂无不要硬憋。边界说明这个 Skill 只做周报内容组织不做错别字校对也不做 PPT 生成。这一定义花了我大概 15 分钟但它让后面所有工作都有了标尺。4.2 提示词初版与测试反馈按照结构化模板我写了一个初版提示词。核心执行步骤是通读用户输入识别所有工作事项。按「成果导向」原则将琐碎事项归类为「重点成果」提取数据变化时保留数值。识别输入中出现的阻碍、延迟、资源不足等信号归入「问题与风险」。依据用户的未完成事项和项目目标推断「下周计划」并标注建议字样。按 Markdown 格式输出。初版测试时我用了三类样本正常记录20 条事项、只有两三句话的极简记录、包含大量重复事项的记录。结果发现两个问题一是极简记录下模型会编造一些看似合理的细节违反了我禁止编造的约束二是重复事项没有合并导致内容冗余。这两个问题靠改提示词解决一是增加一条硬约束如果输入信息不足以支撑一个板块请明确输出暂无而不是合理推测二是增加步骤先将所有事项按关键词聚类同一事项只保留一次并记录出现次数。改完之后测试集通过率从 60% 提升到 95%。4.3 迭代过程和最终 SKILL.md 长什么样迭代了四轮之后SKILL.md 的最终版本简化版大概是这样的--- name: weekly-report-generator description: 当用户提供杂乱的一周工作记录并希望生成结构化的周报时使用。 - 输入一段或多段工作记录文本 - 输出Markdown 格式周报 - 适用周报、月报、项目小结 - 禁止图片输入、非文本文件 version: 1.3 --- # 角色 你是一名高效的项目助理擅长从庞杂信息中提炼关键成果。 # 执行流程 1. 读取用户的全部输入识别工作事项和上下文。 2. 按语义去重同一事项只保留一条多条记录合并内容。 3. 将事项归入三类重点成果、问题与风险、下周计划。 4. 涉及数据变化时保留具体数值如效率提升 20%。 5. 若输入不足以支撑某板块输出暂无禁止编造。 # 输出格式 ## 本周重点成果 - 成果描述包含量化数据 ## 问题与风险 - 问题描述 / 影响程度 ## 下周计划 - 计划事项标注建议这个版本在实践中成了我每周都在用的工具也分享给团队里几个同事用了。大家的反馈是输出的内容基本不用大改比自己从零写快很多。4.4 实测效果与经验感触这个 Skill 用下来我最深的感受是真正花时间的不是写提示词而是定义问题和迭代测试。初版提示词我只花了 20 分钟但测试和迭代花了差不多两个小时。可用性提升得非常明显它已经从一个偶尔能用的玩具变成一个让我放心的工具。另外一个经验是Skill 做出来不是结束持续的使用反馈才是让它保持活力的关键。我每次用的时候发现输出不对就顺手记在迭代日志里攒到一定程度集中改一版。这种节奏让维护成本很低效果却不打折扣。5. 常见问题与避坑实录我从翻车现场总结的教训5.1 为什么我的 Skill 经常不生效这是被问得最多的一个问题。排查思路其实很清晰按顺序检查三处第一处是 SKILL.md 的 description 写得是否准确。如果你在 description 里只写了document summarizer这样干巴巴的名词Agent 根本不知道它适配什么场景。把它改写成当用户需要将长文档转化为结构化摘要时使用触发率会高很多。第二处是文件摆放位置是否正确。不同的工具对 Skill 目录的搜索路径有不同的约定有的放在项目的.cursor/skills/下有的是全局用户目录有的支持远程仓库。我一开始就是把文件放在自定义目录里结果 Cursor 根本没扫描到。查一下你所使用工具的官方文档确认目录路径这个问题半天就能解决。第三处是 Skill 是否足够自包含。如果你的 Skill 依赖某个外部文件或脚本一定要写明路径和调用前置条件。我之前有个 Skill 依赖一个 Python 脚本但我没在 SKILL.md 里写清楚脚本怎么运行换到另一台机器上就彻底失效了。这个一定要测试干净环境。5.2 输出总是不稳定、格式老是变怎么办遇到这种问题先别急着骂模型不行。格式不稳定的常见原因是输出格式定义得不够具体。你不能只说用表格输出要具体到列名、列数、单元格内容规则甚至给出一个正例。我的经验是在提示词里放一个输入示例/输出示例对效果立竿见影。比如输入会议记录提到要开展用户调研。 输出 | 事项 | 类型 | 负责人 | 优先级 |这样模型就知道表格长什么样了。另外还有一个技巧把格式要求单独拆成一个模块不要跟执行步骤混在一起。我在测试中发现当格式说明和执行步骤混在一起时模型经常会顾此失彼把步骤做对了但格式跑偏了。拆开之后模型会把它当成一个明确的交付要求稳定性明显上升。5.3 会不会不小心泄露自己的提示词这个问题越早想清楚越好。现在有些工具的 Skill 文件是明文存放的如果你用的是公开插件仓库或者你的团队共享同一个工作区那就存在提示词被他人看到的可能性。我的建议是分级管理完全私有涉及个人工作习惯、公司敏感数据处理的 Skill放在本地私有目录不推到公开仓库。团队共享可以放团队仓库但慎写公司专有信息。公开分享可以作为个人品牌建设但剔除所有内部信息、真实姓名、项目代号。还有个细节是不要在 SKILL.md 的示例数据里放真实客户信息。我见过有人在测试集里放了真实的业务数据结果打包发布时一起泄出去了非常尴尬。5.4 Skill 要不要和 Agent 一起用边界在哪里Skill 和 Agent 的边界是很多人绕不清的点。我的简化判断标准是Skill 是单次任务的执行者Agent 是多任务的组织者。如果你的任务链路里需要决策、需要选择调用哪几个技能、需要多次工具调用那就上 Agent如果只是输入 → 处理 → 输出的单任务那一个 Skill 通常就够了。把 Skill 硬塞进 Agent 里有个坑Agent 可能会对一个 Skill 反复调用或者在不同步骤之间把 Skill 的上下文搞混。解决方法是在 SKILL.md 里写清楚执行完即返回不需要追加出额外内容并建议 Agent 每次调用前重新读取最重要的几个约束。5.5 踩坑速查表直接收藏症状可能原因解决方案Agent 从不调用 Skilldescription 写得太笼统改写描述加入触发场景和输入输出说明输出格式横跳格式定义太模糊增加具体列名、示例输出回答内容编造约束里没强调禁止编造加硬约束并给出够用即停的指令换个环境就失效有外部依赖未声明写清楚脚本路径、依赖文件多轮对话后逻辑混乱上下文干扰让 Skill 忽略无关上下文专注用户最近一次输入这张表是我自己摸着石头过河攒出来的不一定覆盖所有情况但能解决大部分新手会碰到的问题。最后再分享一个小技巧不要追求一个 Skill 覆盖所有场景。把技能拆得细一点、职责单一一点不仅好写、好测而且复用性更高。我早期犯的最大错误就是想把所有文档处理需求都塞进一个 Skill 里结果它什么都能干、什么都干不精。拆成周报生成会议纪要整理专利文本摘要三个独立 Skill 之后每个的质量都上了一个台阶。做 Skill 跟做软件是一样的——高内聚、低耦合永远是第一原则。
