先抛一个我最近特别深的感触长 Prompt 和 Skill 是两码事把几十条指令堆进一个上下文里不叫“做了个 Skill”那只是把问题从“不会写提示词”变成了“不会管理提示词”。这段时间我在反复折腾 AI Agent 和各种 Skill 类项目也看了大量社区里关于“Skill 怎么做”的讨论。最大的体感是真正能把 Skill 玩明白的人并不是提示词写得有多花哨而是他们想清楚了一件事——Skill 不是一段更长的 Prompt而是一个更聪明的封装。这篇就围绕这个核心把 AI Skill 从“是什么”“为什么做”“怎么做”到“给一份可复制的 SOP”完整讲透。不管你是刚接触 Prompt 工程的入门玩家还是已经在用 Codex、Claude、Spring AI 这类工具搭正经工作流的开发者这篇都值得花十分钟看完。1. 长 Prompt 的边界为什么“堆内容”这条路越走越窄先聊个反直觉的现象。很多人遇到“AI 输出质量不行”时的第一反应是Prompt 写短了再加点约束、再加点示例、再补几个步骤。这个思路在对话轮次少、任务相对简单的场景下确实管用Prompt 从 50 字加到 200 字输出可能立刻不一样。但当你把它推到 2000 字、5000 字、甚至上万字时问题就来了——模型的表现不是线性上升而是先升后降过了某个点之后内容越多反而越不听指挥。1.1 上下文窗口的“隐形租金”我之前做过一个测试同一个写作任务分别用 300 字、800 字、2000 字、5000 字的 Prompt 去跑结果非常有意思。300 字和 800 字的版本输出质量最高2000 字已经开始出现“抓不住重点”的迹象5000 字的版本输出反而最差——它会把前面某条不太重要的约束当成核心要求然后长篇大论地跑偏。这个现象背后的原理其实不难理解现在的 LLM 虽然上下文窗口越做越大但模型对上下文中不同位置的注意力并不是均匀分配的。超长 Prompt 会稀释关键指令的权重就像一个老师一口气布置了五十条作业要求学生能记住的往往是第一条、最后一条以及重复最多的那条中间大部分内容都成了“橡皮檫”——写了但没写进脑子里。还有更实际的问题token 就是钱就是延迟。同样是生成一篇文章多塞 4000 字 Prompt单次调用成本可能翻几倍响应时间也可能从 2 秒拖到 8 秒。如果你在做的是批量任务或者实时交互这个代价会非常明显。我之前看过一个认知长 Prompt 的本质是“用上下文空间换取模型行为控制”但上下文空间是有限资源你在这上面花的每一分钱、每一毫秒都得算进成本里。1.2 Prompt 越长越难维护长 Prompt 带来的第二个麻烦是维护成本。举个例子你有个 Prompt 是帮团队写周报的里面有格式要求、语气要求、要包含的数据维度、要避开的雷区林林总总写了 800 字。某天你发现输出里日期格式不对于是你改了 Prompt 里一个句子又过两天你发现语气还是太正式又加了一句“请口语化一点”再过一周你说算了干脆把语气要求整体改掉……改完之后你有没有想过改了这行会不会影响前面那行这两条规则之间冲突了怎么办我见过很多人的 Prompt 文档最后变成了一笔糊涂账——每一行都是对的但合在一起就出问题。这就是纯文本 Prompt 的致命伤它没有结构、没有版本管理、没有模块化边界。你没法“单独测试”某个功能模块也没法“单独回滚”某个改动。这也是为什么我会说长 Prompt 不是 Skill 的进阶版而是 Skill 的“前身”——它其实在提醒你该做结构化封装了。1.3 一次典型的长 Prompt 失控案例再说个具体的例子。有个朋友找我调一个“专利相关辅助链接生成”的 Prompt对你没看错就是热词里那个“专利相关辅助链接 ai辅助”他最初的需求很简单让 AI 根据技术描述生成专利检索用的关键词组合。他一开始写了个 500 字的 Prompt效果还行后来为了提升准确率不断往里堆专利分类号、法律状态、语义扩展规则最后超过 3000 字。结果呢模型开始“幻觉”专利分类号自己编出一些不存在的国际分类代码还振振有词地附在输出里。他一开始以为是模型不行换了好几个大模型都一样。后来我们把那条超长 Prompt 拆开发现里面有两处规则是冲突的一处要求“严格使用标准分类号”另一处又允许“根据上下文进行合理扩展”。模型自己判断不了哪条优先于是选了最省事的方式——把两处全都“合理化”处理结果就编出个四不像。这就是长 Prompt 失控的典型剧本规则之间相互打架模型无法裁决只能随机应变。你问它为什么不报错因为它不会报错——它会很礼貌地给一个看似合理的错误结果。这就是纯文本方式管理复杂指令的极限。2. Skill 到底是个什么从“一次性指令”到“可复用能力”聊清楚了长 Prompt 的局限就能自然引出 Skill 的意义了。一句话概括我的理解Skill 是把一套“解决问题的方法论”封装成模型可重复调用的独立能力单元。它不只是提示词而是一个包含指令、示例、约束、可选参数和输出格式的完整功能包。2.1 Skill 不是 Prompt 的“加长版”我在热词里看到有人搜“skill 和 agent 的区别”“skill 和 prompt 的区别”这个困惑特别典型。先说结论Prompt 是你“告诉 AI 做什么、怎么做”的一段话Skill 则是“让 AI 在接到某个任务时自动加载一套完整的方法论去执行”的模块。类比一下Prompt 就像你给一位临时工口头交代工作“今天去仓库把 A 类货物搬到 B 区搬的时候轻拿轻放大件放底层小件放上层搬完数一下数量”——他照做但下次你还得重新交代一遍而且每次描述都会有点不一样。Skill 则像你给一位熟练工发了一本《仓库作业手册》他知道自己负责的是“货物搬运”这一职能手册里写明了货物分类标准、摆放规则、异常处理流程、最终交付格式。你只需要说一句“处理一下今天的搬运任务”他就会自己翻开手册、按流程执行、按要求交付。这个“自动翻开手册”的机制才是 Skill 和 Prompt 最本质的区别。Prompt 是被动等待你输入的文本Skill 是主动等待任务触发、然后加载预设行为模式的“可复用能力单元”。2.2 Skill 的技术本质结构化指令封装从技术角度看现代 AI 开发框架里比如 Claude 的 Agent Skills、Codex 的 custom skills、Spring AI 里的各种工具扩展Skill 通常有一套固定结构。一般包含几个部分描述文件定义这个 Skill 的用途、适用场景、触发条件。模型拿到任务后会先“读”这个描述判断要不要启用这个 Skill。指令主体这个可以理解为“被精心设计过的 Prompt 骨架”但不是一长串自由文本而是分段的、有优先级的行为规则。示例库输入输出的对照样例让模型知道“长什么样算对”。约束条件哪些不能做、哪些必须做、遇到边界情况怎么处理。参数接口让调用者可以传入变量比如数据源、目标格式、文件路径而不需要每次重写提示词。这套结构带来的核心收益是模块化和可复用性。你写好一个“专利检索辅助 Skill”下次换一个技术主题只需要改传入的参数不需要重写整个方法论。而且多个 Skill 之间可以自由组合——一个“数据分析 Skill”配一个“报告撰写 Skill”就变成了一个新的工作流。这种组合能力长 Prompt 永远给不了你。2.3 Agent 时代的 Skill为什么现在必须重新理解你可能会说这不就是“提示词工程”的另一种说法吗区别确实有但在Agent 时代这个区别被放大了。现在很多人在做 AI Agent——不只是一个会聊天的机器人而是一个能自主规划、调用工具、执行多步骤任务的智能体。Agent 的运作方式就像一个团队管理者它先理解大目标然后拆解成小任务再给每个任务分配合适的“员工”去执行。在这个体系里Skill 就是那个“员工”。没有 Skill 的 Agent 就像一个光杆司令所有事情都得自己亲自下场写提示词有 Skill 的 Agent 才像一个真正的管理者——它有“写作专家”“数据分析专家”“代码审查专家”这样一组干将每个干将都有自己专精的领域和成熟的工作方法。这也是为什么热词里“codex skill”“agent skill”会被频繁搜索大家都意识到了Agent 的能力上限取决于它手底下有多少高质量的 Skill。我之前看到有人说“skill 插件”这个概念其实挺传神的。Skill 某种程度上就是 AI 的“插件”——你不需要重写模型不需要改模型参数只需要挂载一个新的能力模块模型就多了一项本事。这种“即插即用”的能力扩展方式比任何调参技巧都来得直接。3. 值得做成 Skill 的判断标准不是所有任务都配讲了这么多 Skill 的好处但我也得泼盆冷水不是所有任务都值得做成 Skill。如果你每遇到一个小任务就去写 Skill那跟每遇到一个问题就写 5000 字 Prompt 一样都是过度工程。判断一个东西值不值得做成 Skill我一般看三个标准。3.1 频率这个任务你是不是每周都做有一次我问一个做自媒体运营的朋友他有个“写小红书种草文案”的需求每周至少要做 10 次。文案有一定格式套路但每次的主题、产品、素材都不同。这种高频率 半固定流程的任务就是典型的 Skill 场景。我给他设计了一个简单的 Skill把“产品卖点提取”“用户痛点分析”“文案结构模板”“字数与语气约束”全部封装进去。这样他每次只需要说“帮我写一篇XX产品的种草文案详细资料在 XX 文档里”模型就会自动按流程走。反过来如果某个任务你一年只做一两次哪怕逻辑很复杂也没必要做成 Skill——直接用一段精心写的 Prompt 就够了。做成 Skill 还要维护、测试、迭代投入产出比不划算。我见过有人把“帮我想今天中午吃什么”都做成了 Skill这种就属于过度兴奋了。3.2 稳定性流程是不是每次都一样第二个判断标准是稳定性。Skill 擅长处理“输入在变、方法论不变”的任务。比如“根据销售数据生成月报”——数据每月不同但月报的分析框架、格式、指标定义是稳定的这种就非常适合。但有一种任务不适合每次执行路径都高度依赖对话上下文、需要大量自由发挥的开放式头脑风暴。举个例子“帮我规划一次旅行”这种任务每次差异太大今天可能想深度游明天想亲子游后天变成穷游硬塞进一套固定的方法论反而会束缚模型的创造力。这时候更适合做成一个“轻量级 Prompt”而不是“重量级 Skill”。3.3 可评估性你有没有办法判断输出好坏这个标准很多人会忽略。Skill 之所以能迭代优化前提是你能评估它的输出质量。如果一个任务连你自己都说不清“什么叫做好了”——比如“写一首感动我的诗”——那你很难调优一个 Skill因为模型做得对不对你都无法给反馈。但像“生成符合 OpenAPI 规范的 API 文档”“提取合同里的关键条款”“把 SQL 从一种方言转换成另一种”这类有明确对错标准的任务就是 Skill 的最佳候选。我自己给 Skill 的候选任务分成三类第一类格式敏感型如生成 JSON、Markdown、表格报告第二类领域规则型如专利检索、法律文本分析、医疗知识问答第三类固定流程型如周报生成、会议纪要整理、竞品分析。这三类都有一个共性有明确的产出标准可以自动化评估可以通过迭代不断逼近“好”的定义。4. 动手做一个 Skill一步步拆解我的完整开发流程下面进入正题。这部分我基于“Claude 系的 Agent Skills”和“Codex 系的自定义技能”两套主流方案讲一个通用的 Skill 开发流程。你会发现整个过程的核心不是“写提示词”而是“拆解方法论”。4.1 第一步梳理任务流程画出“一步一步怎么做”很多人一上来就让我帮他写 Skill 的指令部分我说别急在写任何提示词之前你得先把“你希望 AI 怎么完成这个任务”的流程想清楚。我举个例子。假设我要做一个“销售周报生成 Skill”。我先不写提示词先画流程第一步读取原始销售数据文件第二步按产品线汇总本周销量、销售额、环比变化第三步对比上周数据标出异常波动的产品线第四步结合备注信息分析波动可能的原因第五步按固定模板生成周报周报包含“总览、分产品线明细、异常分析、下周计划建议”四个部分。你看这个流程一旦画出来指令部分其实就完成了一大半——你只需要把它翻译成“让模型能读懂”的语言。绝大多数人 Prompt 写不好不是因为文笔不好而是因为“脑子里的流程不清晰”。你用 5000 字来掩盖流程混乱那模型当然会变得混乱。4.2 第二步确定 Skill 的触发条件与描述接下来是写 SKILL.md 的开头部分也就是描述文件。这一段的作用是让模型知道“什么时候该用这个 Skill”“这个 Skill 是干嘛的”。我一般会写得很直白但不啰嗦--- name: sales_report description: 根据销售数据生成结构化周报。支持 Excel/CSV 数据的读取、汇总、异常分析和模板化输出。当用户提供销售数据并希望生成周报或月报时使用。 ---注意几个细节name要简短方便模型记忆和调用description要包含“触发场景”用户说什么话时该启用它和“功能边界”它做什么、不做什么。如果 description 写得模糊模型在多个 Skill 并存时就不知道该选哪个。4.3 第三步把流程写成“行为规则”而不是流水账流程画好了description 也定了接下来就是最核心的——如何把流程变成一个“模型愿意严格执行”的指令文本。这里有个特别反直觉的经验不要用大段散文要用分段 编号 简短句。模型对“结构化指令”的服从性远高于“自然段指令”。原因也不难理解模型的注意力机制对格式差异很敏感编号列表比整段文字更容易被“看到”。我会这样写## 执行流程 1. 读取用户提供的销售数据文件支持 .xlsx / .csv。如果文件无法读取请直接说明并停止。 2. 按“产品线”维度汇总本周销量、销售额、客单价并计算环比上周的变化率。 3. 对比本周与上周数据标记变化率超过 ±15% 的产品线为“异常项”。 4. 对每个异常项结合数据备注或行业常识给出最多两条可能的波动原因。 5. 按“周报模板”生成最终输出模板见下方。 ## 周报模板 ### 一、本周总览 - 总销售额 / 环比变化 / 完成目标比例 ### 二、分产品线明细 | 产品线 | 本周销售额 | 环比变化率 | 是否异常 | ### 三、异常分析 - 异常产品线原因推测 ### 四、下周计划建议 - 基于异常项给出 2-3 条合理建议你注意我故意用了“如果文件无法读取请直接说明并停止”这种异常分支。一个高质量的 Skill 必须包含异常处理逻辑——毕竟 LMM 的执行环境里文件读错了、参数传少了、数据格式不对都是常见问题。没有异常分支的 Skill遇到意外只会硬着头皮编造结果这是最危险的。4.4 第四步注入 Few-shot 示例告诉模型“长什么样算对”光有流程还不够我会再加 2~3 组“输入—输出”示例。这既是为了让模型学会格式更是为了让模型理解“输出风格”。举个例子在销售周报 Skill 里我会给一组输入用户输入请帮我根据这周的销售数据生成周报。 原始数据这里放一张简化的数据表 期望输出放一个完整示例这个“期望输出”必须是你亲自写好的、完全符合标准的样板。模型会模仿你给的这个“标准答案”的风格而不是自由发挥。Few-shot 示例不是越多越好2~3 个质量极高的样例胜过 10 个凑数的样例。我一般选一个常规场景、一个含异常数据的场景、一个数据缺失的场景覆盖多样性。4.5 第五步定义输入参数与接口如果你的 Skill 要在 Agent 或者其他程序里被调用那接口设计这步就不能省。我见过不少人忽略这一点结果 Agent 每次调用 Skill 时都不知道该传什么参数。一个简单的参数接口大概长这样inputs: data_file: type: string description: 销售数据文件的路径或内容 required: true period: type: string description: 周报周期如“2025年第14周” required: false default: 最近一周 language: type: string description: 输出语言 required: false default: zh-CN接口设计的原则是能默认的都默认必须用户决定的才设为必填。如果必填参数太多使用门槛会提高Skill 的使用频率就会下降。我自己用下来一个 Skill 的必填参数最好不超过 3 个。4.6 第六步测试并迭代“边界场景”Skill 写完之后先别急着投入使用。我通常会用 5 组测试用例来验证第 1 组正常输入看输出是否符合模板要求第 2 组输入数据缺了一个关键字段看 Skill 的反应第 3 组输入数据为空看 Skill 会不会报错或编造数据第 4 组数据格式跟描述文件里写的不一致比如传了 PDF 而不是 CSV看 Skill 怎么处理第 5 组连续多次运行看结果是否稳定一致。测试跑完几乎必然会发现几个问题。最常见的三种一是指令里有歧义模型选择了跟预期不一致的解释二是异常分支没有覆盖到某个意外情况三是输出格式和模板有细微偏差。这些问题都是正常现象——Skill 是一次性的“Product v1.0”需要持续迭代到 v1.3、v1.8。5. 附一份可复制的 Skill 开发 SOP从 0 到 1 全流程模板第 4 部分讲的是“制作思路”但我知道很多人看完还是会问能不能直接给我一份照着填的模板这一节就给一份相对通用的 SOP。你可以把它当“新建 Skill 时的默认骨架”往里套领域内容就行。5.1 通用 SKILL.md 模板骨架--- name: [skill_name] description: [一句话说明用途包含触发条件、功能边界] --- # [Skill 名称] ## 触发条件 - 用户请求涉及[场景 A] - 用户提到关键词[关键词 B] - 用户提供了[必要输入 C] ## 前置检查 1. 检查必填输入是否齐全。缺失则要求用户补充勿自行猜测。 2. 检查输入格式是否符合预期。不符合则尝试转换转换失败则中止并说明。 ## 执行流程 1. [第一步读取/解析输入] 2. [第二步核心处理逻辑] 3. [第三步中间结果校验失败则回到上一步修正] 4. [第四步生成最终输出] ## 输出格式 [在此定义输出的结构如Markdown 格式、JSON Schema、表格列名等] ## 示例 ### 示例 1常规场景 - 输入... - 输出... ### 示例 2边界场景 - 输入... - 输出... ## 禁忌 - [绝对不能做的事如不要编造数据、不要跳过数据校验] - [遇到不确定时的兜底策略如输出“无法确定”并要求用户补充信息]这个模板不是我凭空发明的而是综合了 Claude 官方的 Agent Skills 规范和 Codex 自定义技能的常规结构再结合我自己反复调试后的经验做的“通用化”版本。你可以把它当作 60 分的基础款在它的基础上填充自己的领域知识。5.2 一个“从需求到 Skill”的 30 分钟快跑清单如果你是个急性子不想看太多理论可以直接照着这个清单操作阶段时间行动产出物需求分析3 分钟用一句话说清“这个 Skill 解决什么问题”一句话需求描述流程梳理5 分钟写出完成该任务需要的 4~6 个步骤步骤列表结构搭建5 分钟套用上面模板填入流程内容SKILL.md 初稿示例编写5 分钟写 2 组高质量输入输出样例示例区块场景测试10 分钟用 3~5 个边界输入测一遍测试结果记录迭代修正2 分钟根据失败场景补规则、补禁忌SKILL.md v1.1这张表背后的时间分配逻辑是想清楚方法论8 分钟 写结构性内容10 分钟 花式测试10 分钟 最后微调2 分钟。如果你发现自己在“写提示词”这一步花了太长时间大概率是前两步没做透——方法没想明白怎么写都是错的。5.3 一个好 Skill 的“验收清单”最后送大家一份验收清单。每次你写完一个 Skill或者在网上看到一个 Skill 想评估它好坏时拿这份清单对照一下描述是否清晰只看 description我能不能判断这个 Skill 什么时候该被使用触发条件是否明确它会不会和另一个 Skill 的触发条件重叠执行流程是否可验证每一步的输出能不能被检查是否有异常分支遇到坏输入它是明确拒绝还是硬着头皮编造输出格式是否固定两次运行的结果会不会在格式上出现漂移是否包含跨领域假设如果它写的是“销售数据”但模型可能遇到“非销售数据”它有没有处理逻辑示例是否优质每个示例是不是都体现了输出质量的“最高标准”把这份清单当作“炉火纯青的指标”你对 Skill 质量的感知会迅速提升。它不是答题卡而是一面镜子。说到这我想起自己调一个“SQL 方言转换 Skill”时踩过的一个典型坑一开始我在指令里写“将 Oracle SQL 转换成 MySQL SQL”结果模型遇到 PG 和 SQL Server 的输入也硬转还转错了好几处。后来我在描述里明确加了一句“仅当输入方言为 Oracle 时启用本 Skill其他方言请提示用户语言不受支持”问题立刻就消失了。这就是“功能边界”的价值——Skill 不只是知道“该做什么”更要清楚“不该做什么”。Skill 这套玩法我自己也还在摸索中。但我越来越确信一件事AI 能力扩展的下一波红利不在于谁能写出更长的 Prompt而在于谁能构建出更清晰、更模块化、更可复用的 Skill 体系。你手里那堆零零散散的长 Prompt其实不是资产而是待改造的半成品——这波改造做得好后面省下的时间和心智成本绝对超乎你的想象。