1. 从一段重复劳动说起：我为什么开始琢磨 Skill 这件事
1.1 一个让我崩溃的场景：每周都要重新教一遍 AI
一年多前，我开始频繁用 AI 辅助写工作汇报，每次都要在对话框里粘贴同样的一堆东西：业务背景、分析维度、输出格式、禁区话题。当时我并没觉得这有什么问题，反正复制粘贴嘛，几秒钟的事。直到有一天我认真统计了一下，光是这些“背景说明”就占了整段输入的七成，而真正想让 AI 做的事只有一句：总结本周进展。
这事本身不算可怕，可怕的是它发生在每一次任务里。换一个任务，AI 要处理的主语变了，但背景说明永远原封不动。我就像开了一家完全没有流程的作坊，每个新来的员工都得从零培训一遍，哪怕他已经是干活熟手。更让我抓狂的是，同一套背景交代，在不同模型上的表现完全不可控：有的模型能照做，有的模型直接无视，还有的模型把它当作聊天内容来回应。反复试了很多次之后，我开始意识到问题不在模型，而在我一直把“做事情的方法”和“具体要做什么”混在一起喂给了 AI。
1.2 把“怎么做事”从“做什么”里拆出来
后来我尝试换一种思路：把任务请求和做事方法彻底分开。任务请求是“今天写一份市场周报”，做事方法是“市场周报应该按什么框架写、数据如何核验、结论怎么表达、哪些措辞绝对不能用”。前者是用户每一次的新需求，后者则是每次都不变的老经验。
这个思路说白了，就是把“可复用的做法”封装成一份结构化的说明，再交给 AI。你每次只需要描述新任务，AI 自己会去翻阅那份封装好的说明来指导输出。打个比方，去餐厅点菜时，你不需要临时教后厨怎么把肉切薄、火候多大、炖多久——因为后厨的墙上挂着出品标准卡。Skill 就是那张墙面上的标准卡，不是这一道菜的订单。
从那以后，我开始大量实践这种封装。周围的朋友也开始频繁和我讨论一个词：Skill。说实话，这个词被不少产品包装得神乎其神，但本质上它并不是什么黑科技。它不依赖某个特别的新模型，也不需要重写底层架构，它更像是一种组织信息的方法论：把一次性、临时的提问，转化成可以反复引用、持续优化的经验资产。这篇分享我就想把我在实操中的理解、踩过的坑、以及现在维护 Skill 的完整方法讲清楚，给正在用 AI 做重复性工作的朋友一个可落地的参考。
注意：我这里说的 Skill，泛指当前 AI 应用场景里一种通用的做法——把经验、流程、规范打包给模型执行。不同产品的叫法叫法可能不一样，有的叫技能，有的叫指令集，但底层思路基本一致。
2. Skill 到底是什么：它只是 Prompt，又不是普通 Prompt
2.1 Skill 的本质是一份“可执行的经验文档”
如果剥掉所有包装，Skill 在技术形态上就是一份文本：一份经过结构化组织、专门写给 AI 看的操作说明。很多项目习惯把它命名为 SKILL.md，放在固定的目录下，旁边再挂一些辅助资源。但既然只是文本，为什么值得单独认真对待？关键在于“可执行”这三个字。
普通 Prompt 偏向描述“我要什么结果”，而 Skill 偏向描述“你应该用什么过程去得到这个结果”。举个最简单的例子：你让 AI 写一封催款邮件，普通 Prompt 可能是“帮我写一封催款邮件，语气礼貌但坚定”。这种写法不是不行，而是质量全看模型当天状态。同一个任务如果做成 Skill，它就会具体到：开头先说明身份与双方合作背景、表达理解再提出逾期事项、给出明确的截止日期与打款账户信息、结尾附上联系人方式。每个步骤还要配上范例和禁忌，模型拿到的就不再是一句抽象要求，而是一整套操作规范。
所以我的理解是，Skill 确实是以 Prompt 形式存在的文本，但它又不是普通 Prompt。普通 Prompt 用完就扔，Skill 是沉淀下来的资产；普通 Prompt 只描述目标，Skill 规定路径；普通 Prompt 依赖个人临场发挥，Skill 依赖群体经验累积。说得更直白一点：Prompt 是你在指挥一个实习生干活，Skill 是你把实习生培养成老员工的那套培训手册加标准作业程序。
2.2 Skill 和 Prompt、Function、Workflow 的边界到底在哪里
很多刚接触 Skill 的人都会问：它和提示词模板有什么区别？和函数调用是不是一回事？和自动化工作流又是什么关系？我把自己的判断标准整理成一张表格：
| 概念 | 核心形态 | 解决什么问题 | 典型例子 |
|---|---|---|---|
| Prompt | 一次性指令 | 让 AI 完成一个具体任务 | “帮我把这段文章改写成口语化风格” |
| Skill | 可复用的过程资产 | 让 AI 按既定做法完成一整类任务 | “按我们团队的标准化流程改稿，包括标题测试、语气检查、事实核验” |
| Function / Tool | 原子能力 | 让 AI 调用一个确定性的功能 | 调用翻译接口、查询数据库、计算某个公式 |
| Workflow | 确定性流程 | 把多个固定步骤串成流水线 | 数据输入后自动清洗、分析、出报告，每一步由脚本控制 |
核心差异在哪里？Prompt 是一锤子买卖，任务结束它就失去了价值；Skill 是长期资产，可以反复调用、持续优化、多人共享。Function 是原子动作，只负责一个动作本身；Skill 是组合动作的方法论，负责教模型怎么组织多个动作。Workflow 追求的是确定性，最好每一步都按代码逻辑严格执行；Skill 追求的是在确定性框架里保留模型的判断和灵活性。
我在实践中有一条挺实用的判断标准：如果你发现自己连续三次在 Prompt 里复制粘贴同一段要求，这段要求就值得升级成 Skill。如果你要做的是一旦启动就必须按固定逻辑跑完、不允许模型自由发挥的流程，那应该去做 Workflow，而不是 Skill。两者用反了，都会很难受。
2.3 从文件结构看 Skill 的运行逻辑
既然 Skill 是“经验文档”，它到底长什么样？以一个我经历过的项目为例，一个标准的 Skill 通常会这样组织：
skills/ weekly-report/ SKILL.md # 主文件：角色、适用场景、执行步骤、输出规范 examples/ good-demo.md # 优秀范例，展示理想输出 bad-demo.md # 反例，标注常见错误和原因 checklists/ quality-check.md # 交付前自检清单运行时，系统会把 SKILL.md 的内容，连同必要的辅助文件一起注入模型的上下文。模型看到的就不只是用户当前的一句请求，还有一套“做这件事的操作手册”。它边看边执行，整个过程和把一份工作手册加范例扔给实习生，然后让他独立干活非常相似。
这里有个容易忽略的关键点：Skill 里的每个步骤必须能被模型转化为具体动作，而不是停留在抽象口号。比如“确保数据准确性”这句话，其实很弱，因为模型并不知道具体怎么确保。你应该写成“正文中出现的每个数字，都要回到源表格的对应单元格进行核对，并在报告末尾注明数据来源”，模型才知道该做什么。这个是 Skill 设计和普通文档写作最大的分水岭。
3. 为什么要用 Skill：它解决了 Prompt 时代三个扎心的问题
3.1 上下文窗口是稀缺资源，重复写等于烧钱
我建议做个体感测算。假设你要交给 AI 的做事规范大约一千字，每天跑十个任务，一周下来光重复交代就是七万字，而这些内容每次都在占上下文窗口。上下文窗口本来就有长度上限，塞进去大量重复交代，真正留给当前任务内容的余量就越小。
但这还不是最麻烦的。模型处理质量会随着上下文中无关信息的增加而下降，尤其是当你把一大段“去年就定好的分析框架”反复贴进去时，模型要费劲区分哪些是当前任务材料、哪些是历史经验、哪些只是噪声。这就像让一个员工做会议纪要时，桌上还摊着一本厚厚的旧制度汇编。他能干活，但精度一定受牵连。把重复内容封装成 Skill 之后，这段经验只需要在实际需要时被加载一次，用完即走，相当于把上下文空间还给了当前任务本身。
3.2 隐性经验传不下去，团队永远在重复造轮子
我观察过不少团队用 AI 干活的状态：谁提问谁写 Prompt，写得好的闷声发大财，写得差的每天在各种报错和烂输出里挣扎。每个人的 Prompt 风格五花八门，同一类任务能写出三种完全不同的提示词，产出质量自然忽高忽低。
这是典型的隐性经验问题。老师傅的判断思路、踩过的坑、对质量底线的偏好，全存在自己脑子里。Skill 真正有价值的地方，就是逼你把隐性经验写成显性文档。一旦写成文档，它就能被复核、被讨论、被优化、被团队其他成员复用，不再依赖某个人在现场。
我做数据清洗任务时感触特别深。团队里有一位对数据极其敏感的同学，平时积累了一套异常校验规则，谁遇到问题就当面问他，他说一遍对方记一遍，记不记全看缘分。后来我花了一个下午，把他的思路整理成一份 Skill：先做数据口径确认，再筛查缺失值，其次做逻辑异常检测，最后生成一份异常说明。整组人再用时，数据质量肉眼可见地稳定了。这种事情在传统工作模式里很难实现，因为你很难把“经验”从人身上剥离出来独立传递，但 Skill 做到了。
3.3 模型能力再强，也需要“操作范式”约束偏差
大模型有随机性，这是客观事实。同一个模型连续写五次周报，能写出五种不同风格，哪怕你用的是同一句话提示词。有些任务需要这种灵活性，但很多任务我们只想要“稳定地好”，不需要那么多惊喜。
Skill 在这里起的作用更像一个参照系。模型状态好时，Skill 提供质量下限；模型状态差时，Skill 把它从偏航轨道上拉回来。我见过大量上线 Skill 之后的案例，输出波动范围明显收窄。这不是玄学，而是模型有了明确的操作流程后，自由发挥的空间被约束在了安全区里。
当然这不意味着 Skill 要消灭一切随机性。它只负责划一条底线，底线之上模型依然可以有风格、有创意、有不同角度的表达。这正是 Skill 比固定模板高级的地方：固定模板是模具，Skill 是护栏。模具做出来的东西一模一样，护栏做出来的东西既符合标准又各有不同。
4. 手把手设计一个高质量 Skill：以“周报生成”为例
4.1 先定边界：管什么、不管什么，必须写清楚
我设计 Skill 的第一件事从来不是写步骤，而是写边界。没有边界的 Skill 就像一个没有岗位职责的员工，什么都能干，什么都干不好。边界写得越清楚，模型越不容易跑偏。
以周报生成 Skill 为例，我会先写清三件事：
- 输入是什么：本周的工作事件列表、项目进度记录、关键数据。
- 输出是什么：一份四百字以内的中文周报，按“本周成果 / 遇到的问题 / 下周计划”三段式组织。
- 不做什么：不主动编造输入没有提到的工作内容；不评价团队人员表现；不输出超出输入信息范围的战略建议。
这个“不做什么”特别关键。很多 Skill 写不好，就是光写了要做什么，没写不准做什么。AI 在边界模糊时，特别喜欢过度发挥。你让它总结成果，它能顺手把下季度战略也编出来。边界写清了，后期质检的时间和精力能省掉一大半。
4.2 把“经验”拆成“步骤 + 判断准则 + 具体动作”
定了边界之后，再把老师傅的做法拆成步骤。注意，不是泛泛的流程清单，而是每个步骤都配判断准则和具体动作。我拿一个简化版 SKILL.md 做示范：
# 周报生成 Skill ## 角色定位 你是一名熟悉该业务运营的助理，负责把散乱的工作记录整理成清晰周报。 ## 执行步骤 ### 第一步：信息分类 - 将输入的工作记录逐条归类为“成果”“问题”“计划”。 - 每条记录只归入最贴合的一个类别，不重复分类。 - 若记录模糊到无法判断，归入“待确认”并在末尾列出，不要自行脑补。 ### 第二步：组织语言 - 成果类：先写动作，再写量化结果。例如“完成XX页优化，转化率提升12%”，不能只写“完成优化”。 - 问题类：写明现象、影响范围、当前卡点，避免含糊其辞。 - 计划类：写明时间点与可验证目标，不写“争取完成”“积极推进”。 ### 第三步：格式输出 - 总字数控制在400字以内。 - 使用“本周成果”“遇到的问题”“下周计划”三个小标题。 - 每条内容不超过两行，不写空话套话。 ## 质量红线 - 禁止编造数据。 - 禁止输出与输入无关的战略建议。 - 禁止使用“大概”“差不多”等模糊量化词。看到区别了吗？我没有写“写一份好周报”，而是写了“先分类，再组织语言，最后按格式输出”。每一步都有判断依据和具体动作。模型拿到这种说明，才知道手往哪放。这种细致程度，正是 Skill 和普通 Prompt 拉开差距的地方。
4.3 范例比抽象规则更管用，一定要配正反例
只给规则，模型还是可能跑偏，因为自然语言天然有歧义。所以我的一个强烈建议是：每个 Skill 都要配正反两个例子。正面范例给模型一个“对标物”。当你写“成果类要写动作加结果”时，模型对“动作加结果”的理解可能千奇百怪，但一个完整的好例子放上去，它自己就能归纳规律。
反面范例同样重要。有些坑，你不点破，AI 一定会踩。比如周报里最常见的“结论跟数据对不上”，或者“结果描述没有量化”。把坏例子写出来，再在下面标注哪里有问题，模型会更快建立“排斥反应”。我在实践中的经验是：一个 Skill 里的正例和反例数量尽量保持一比一，纠偏效果最好。
4.4 给 Skill 配上自检清单，让它交付前自查
一个高质量的 Skill，最后一定要有交付前的自检环节。我给周报 Skill 加过一段检查清单，让模型在输出前逐项确认：
内容是否都来源于用户输入？有没有编造？ 每条是否都包含动作和可量化的结果？ 有没有出现质量红线里禁止的词汇或句式？ 字数是否在要求范围内？
一开始我以为这个环节只是走形式，后来实际跑下来发现，只要自检清单写得足够具体，模型漏网的几率会大幅下降。它相当于替我做了第一轮质检，我只负责看最后结果，纠缠成本低了很多。
4.5 像管理代码一样管理 Skill 版本
最后一个建议：Skill 是会进化的。你今天写的流程，过两个月可能就被业务变化淘汰了。所以我坚持给每个 Skill 加版本号并记录变更日志，改一个判断准则就升一个小版本，注明改了哪条。时间长了，这些变更记录本身就是团队的业务知识库。谁在什么阶段改过什么规矩，一眼就能翻出来。
5. Skill 在三种真实业务里的落地方式
5.1 内容创作团队：把“文风统一”变成可执行的规范
内容团队最头疼的问题就是风格不稳定。同样一个主题，让两个人各写一篇，出来像两个陌生人写的。但把“文风”做成 Skill，局面会改善很多。
具体做法是，把团队公认的几篇高水准文章拆解成字段：标题怎么取、开头怎么钩人、段落怎么过渡、句子偏长还是偏短、哪些词绝对不能出现、结尾要不要放引导语。然后把这些字段连同正反范例一起写进 Skill。团队写稿的人都调用同一份 Skill，产出的一致性会明显提高。最明显的变化是新人不再需要靠“看老同事文章自己领悟”来练文风，Skill 直接告诉他标准是什么、范例长什么样。内容团队做 AI 应用，我最推荐先做两个 Skill：统一的文风规范，加上发布前质检清单。
5.2 开发团队：把代码审查的隐性规则沉淀成 Skill
代码审查这件事，经验价值极高。资深工程师扫一眼代码，就能发现并发隐患、边界处理缺失、日志打得不规范，但这些经验很难完整传给新人。我就尝试把一整套审查规则写成了 Skill。
在 Skill 里，我固定了审查顺序：先看接口和数据结构定义，再盯并发与状态变化，然后检查错误处理分支，最后看代码可读性。每个维度下挂具体的检查点，比如“共享变量是否被锁保护”“错误分支是否留下关键日志”“异常返回是否吞掉了导致问题的重要信息”。实测下来，模型能按这套规则完成第一轮粗筛，把低级问题挑出来，工程师随后做深度审查。这不意味着 AI 可以替代人，而是把人从重复性检查中解放出来，把精力留到真正需要判断的地方。
5.3 数据分析团队：让“从数据到结论”的路径有据可循
做数据分析最怕的是拍脑袋下结论。同一个数据，有人能看出趋势，有人只能复述数字。一个成熟的分析师，脑子里会有一条完整路径：先确认数据口径，再清洗异常值，再做分层对比，最后写结论时严格区分事实与推断。
这条路完全可以沉淀成 Skill。每次分析时，AI 按路径一步步执行：当前数据口径是什么、样本有没有偏差、异常值如何处理、结论里哪些是数据直接支持的、哪些是分析师的推断。所有项目都走同一条路径，好处不只是产出更规范，更关键的是每一步都有据可查，事后追索问题也简单得多。
6. 我在踩过几次坑之后，形成的几条新原则
6.1 坑一：把 Skill 写成“百科全书”，模型抓不住重点
早期我写 Skill 很贪心，恨不得把所有可能遇到的情况都写进去。结果 SKILL.md 越写越长，最后超过六千字。真正用起来才发现，模型在超长上下文里反而抓不住重点，它会把关键步骤和次要说明混在一起，执行效果还不如一个短 Prompt。
后来我给自己定了一条硬规则：SKILL.md 里只放“非此不可”的步骤和规则。背景知识、完整案例、常见问答全部挪到外部引用文件里，主文件保持精简。模型需要细节时再去读对应文件。这条规则让我后面所有 Skill 的可用性都明显提升了。
6.2 坑二：把 AI 用成流程机器，所有判断都固化成 if-then
还有一种情况是过度结构化。我有一段时间把 Skill 写成了无数条件分支：遇到 A 情况就这样，遇到 B 情况就那样。看起来逻辑严谨，但模型一遇到真实复杂场景就乱套，因为现实总有没覆盖到的分支。
Skill 的目标是提供过程框架，而不是穷举所有规则。它应该给模型留出判断空间。现在我会在关键节点写开放式指示，例如“根据上下文选择最合适的处理方式”，而不是把所有路都堵死。后来我发现，这类开放指示能让模型面对意料之外的情况时，表现反而更好。
6.3 坑三：Skill 和模型底座不匹配，执行上限根本够不着
Skill 写得再好，也得底座模型撑得住。如果模型上下文很短，或推理能力偏弱，一个复杂 Skill 反而会把它压垮，表现为丢三落四、忽略关键步骤。我现在的习惯是：先评估运行环境，再决定 Skill 的复杂度。简单任务用轻量 Skill，复杂任务才用大 Skill。同一个 Skill 在不同环境下效果可能完全不同，每次换了运行环境，我都重新做一遍完整验证，绝不默认“换个环境也一样好使”。
6.4 我的维护节奏：用测试集回归每一个 Skill
Skill 不是写完就能一劳永逸的。我现在维护 Skill 的方法是：给每个核心 Skill 配一个大约五条的测试集，每次改动 Skill 之后重新跑一遍测试，看输出是否依然符合预期。这个思路和改代码跑用例是一样的。另外我会按月整体 review 一遍所有 Skill。有些 Skill 随着业务变化，判断准则过期了；有些步骤顺序已经有更好的替代方案。这类迭代不需要多频繁，但不能没有。Skill 是活的资产，它应该跟着业务一起进化，而不是被锁进某个版本里吃灰。
7. 说点实在的：把可复用做法交给 AI 之后，真正的变化在哪
我现在回头看，把“Skill 就是把可复用做法交给 AI”这句话实践了挺久，最大的体会是：它改变的不仅是 AI 的输出质量，更是团队做事的方式。当一个业务经验被写进 Skill，它第一次脱离某个具体的人，变成可以反复讨论、持续优化的独立资产。大家不再说“某位同学太强了全靠他经验撑着”，而是说“这套做法已经沉淀下来了，谁来做都不会跑偏太多”。
Skill 当然不是万能的。有些工作充满创造性和不确定性，硬做成 Skill 反而显得生硬。我现在的判断标准很简单：同一类事情重复出现三次以上，并且做法相对稳定，就值得做成 Skill；如果事情本身就靠随机应变，就直接交给模型自由发挥。这个判断标准一路帮我把精力花在最有价值的地方。
如果你刚开始接触这个概念，我给的最小可行动建议是：挑一个你让 AI 做得最多的任务，把操作步骤、判断准则、正反范例整理成一个文件，丢给模型连续跑几次，看看效果。你很快就会发现，把工作经验交给 AI 这件事并没有想象中复杂。关键是不要急着追求复杂框架，先把手头那件重复得最烦人的事写下来，跑起来再说。
