写了上百个Skill效率起飞后,我总结了一套Skill实操教程
一名写了上百个 Skill 的实践者交付的”Skill 工程作业手册”——从 Skill 与 Prompt 的边界差异,到”先跑通再封装”的四步作业法、三层渐进式加载的组织结构、产品式版本迭代逻辑,再到 Skill 本质=SOP 化能力的元方法论判断。区别于偏理论的 ACT-R 视角,本文从一线踩坑路径反推 Skill 工程的可复制做法。
基本信息
- 作者:云舒(微信公众号:云舒的AI实践笔记)
- 来源:人人都是产品经理 /
https://www.woshipm.com/ai/6387189.html - 发布时间:2026-04-30
- 字数:约 3626 字
- 题图:Unsplash(CC0)
核心观点
-
Skill 不是”大号 Prompt”,而是一套可承载复杂 SOP 的作业系统:从底层逻辑看,Skill 和 Prompt 做的是同一件事——让 AI 按 SOP 作业,所以最简单的 Skill(单
Skill.md)等价于一段 Prompt。但 Skill 在两个维度上突破了 Prompt 的天花板:①调用方式——模型可以预先看到多个 Skill 的描述,根据当前任务自动判断要调用哪个;Prompt 只能人工手动指定,无法在全局工作流里形成稳定调用机制。②承载复杂度——Skill 可以包含规则、参考文档、Python 脚本、素材库,在不同阶段让模型调用不同内容;Prompt 必须一次性把所有内容喂给模型,信息量和复杂度都有限,多了反而让模型抓不住重点。 -
“先跑通再封装”是写 Skill 的最核心经验,不要一上来就设计 Skill:作者明确反对”先设计再验证”的写法。原因是 Agent 作业逻辑下,任务复杂度明显变高(涉及脚本、工具调用、文件读取、subagent 分工),很多流程很难在一开始就完整设计出来。正确做法是先和 AI 定一个目标,跑通真实场景,再回头把这个过程封装成 Skill——试错成本最低,测试成本也大幅降低。这与”写 Prompt”的逻辑根本不同:Prompt 时代是 Chatbot 多轮对话,可以先设计;Agent 时代必须先跑通再提炼。
-
作业流程四步:跑通→复盘→封装→回溯:①跑通:和 AI 定好目标,把真实场景跑出一个自己认可的结果(不需完美);②复盘:和 AI 讨论整个过程中哪些是正向流程、哪些是负向流程、哪些内容应该沉淀;③封装:让 AI 基于复盘结果进行 Skill 封装——从真实成功经验中提炼出来的流程往往比凭空设计的流程效果好很多;④回溯测试:开新对话测试 Skill 能否稳定复现类似结果,不稳定则定位问题、优化流程。
-
Skill 的组织结构是三层渐进式加载:Agent 调用 Skill 不是一上来就把全部内容塞给模型,而是分多层级渐进式加载:①第一层 Skill 描述(name + description)—— 一次对话中模型会加载所有 Skill 的描述,用于判断调用哪个;②第二层 SKILL.md—— 模型决定调用某 Skill 后才读取,描述主流程;③第三层 references/scripts/assets—— 主流程下各阶段按需补充。作者一句话总结:“name 和 description 负责触发,Skill.md 负责主流程,参考资料负责在复杂场景下补充能力。关键不是目录看起来多完整,而是每一层都要服务于模型的真实作业流程。”
-
Skill 的进化要像做产品一样迭代,围绕两个维度优化:①根本问题是什么——不要做着做着过界;②当前最明显的不足是什么——这次优化重点要解决什么。作者用两个真实案例佐证:多视角深度分析 Skill 1.0(subagent 自由选择视角,不稳定)→ 2.0(加语料库标准化视角,解决稳定性)→ 3.0(5 个顾问扩到 10 个,解决数量不够)→ 不做 4.0 万能化(因为初衷是思维复制分析,新需求另开 debug Skill / 设计 Skill,每个 Skill 对应明确场景);PPT Skill 1.0(能不能做,60 分)→ 2.0(增加底板和参考样式,65 分)→ 3.0(引入 subagent 设计逻辑,按内容做适配)→ 4.0(减少人干预,AI 更自主)。每个版本只解决一个当下最明显的问题,不要一开始追求完美。
-
Skill 边界要清晰,不要做成万能工具:3.0 版本时作者想给多视角深度分析 Skill 加上写代码和做设计的能力,但回归”Skill 的初衷是什么”后决定不把它做成万能分析 Skill,而是新开设计 Skill 和 debug Skill。这是 Skill 工程的关键判断——“它根本上要做的问题是什么?不要做着做着过界了”——直接对应 Skill 与 Workflow / Agent 的分层。
-
Skill 本质 = 人把一件事 SOP 化的能力:写 Skill 到最后考验的不是语法,也不只是提示词能力,而是”人能不能把一个真实场景里反复出现的问题,沉淀成一套 AI 可以复用的流程”。
-
熟悉 vs 不熟悉领域的两种作业模式:①熟悉领域 = 经验蒸馏——人本来就知道这件事该怎么做、什么结果是好的,要做的是把自己的经验拆出来变成 AI 能理解、能执行、能复用的流程;②不熟悉领域 = 建立回溯验证机制——难的不是让 AI 产出内容,而是判断它做的对不对。作者举了两个真实对比案例:六爻占卜 Skill 失败案例——看起来很适合 Skill 化(有规则、流程、参考资料),但作者自己不懂解卦、AI 也不懂,无法构建可靠的回溯测试系统,“我压根不知道解卦到底是准还是不准”,打磨半个月放弃;编程自动化测试成功案例——作者也不是专业测试工程师,但可以让 AI 设计测试逻辑,通过回溯测试不断优化合理性,最后稳定运行后封装成 Skill。结论:人不熟悉的领域不是一定做不出来 Skill,核心是看能否通过回溯机制来验证。
实操内容保留
写 Skill 的四步作业流程(原文细节)
| 阶段 | 关键动作 | 容易踩的坑 |
|---|---|---|
| 1. 跑通 | 和 AI 定好目标 → 把真实场景跑出来 | 追求一开始就完美,反而跑不通 |
| 2. 复盘 | 和 AI 讨论:哪些是正向流程 / 哪些是负向流程 / 哪些内容应该沉淀 | 跳过这一步直接封装,等于凭想象做产品 |
| 3. 封装 | 让 AI 基于复盘结果进行 Skill 封装 | 不让 AI 写,自己手写 Skill 容易脱离真实经验 |
| 4. 回溯 | 开新对话测试稳定性,不稳定就定位问题 | 不做回溯,永远不知道 Skill 是不是真的能复用 |
Skill 的三层渐进式加载结构
第一层:Skill 描述(name + description)
↓ 模型扫描所有 Skill 描述,判断调用哪个
第二层:SKILL.md(主流程)
↓ 模型决定调用后才读取,了解整体作业流程
第三层:references / scripts / assets(按需加载)
↓ 主流程各阶段调用补充资源作者原话:
name 和 description 负责触发,Skill.md 负责主流程,参考资料负责在复杂场景下补充能力。关键不是目录看起来多完整,而是每一层都要服务于模型的真实作业流程。
Skill 迭代两维度判断公式
每次优化前问自己两个问题:
1. 这个 Skill 根本上要做的问题是什么?(边界守护——不要做着做着过界)
2. 当前 Skill 做的不好的点是什么?(焦点守护——这次只解决一个最明显的问题)多视角深度分析 Skill 真实演进路径
| 版本 | 解决的问题 | 关键改动 |
|---|---|---|
| 1.0 | 跑通 | subagent 自由选择视角对内容评估 |
| 2.0 | 视角稳定性 | 给每个 subagent 派单增加语料库,标准化判断逻辑 |
| 3.0 | 视角数量不够 | 5 个顾问 → 筛选扩到 10 个 |
| 不做 4.0(万能化) | 边界守护 | 新需求另开「设计 Skill」「debug Skill」,每个 Skill 对应明确场景 |
PPT Skill 真实演进路径
| 版本 | 解决的问题 | 效果 |
|---|---|---|
| 1.0 | 能不能做 | 60 分 |
| 2.0 | 样式丰富度 | 增加底板和参考样式 → 65 分 |
| 3.0 | 内容适配 | 引入 subagent 设计逻辑,不只是套模板 |
| 4.0 | 减少人干预 | 优化整体流程,AI 更自主作业 |
熟悉 vs 不熟悉领域的 Skill 化判断模型
熟悉领域 → 直接经验蒸馏:把脑子里"会做"的拆成 AI 能执行的流程
↓
不熟悉领域 → 先建回溯验证机制:
- 能验证 → 可做(编程自动化测试案例:AI 设计测试逻辑 → 回溯优化 → 封装)
- 不能验证 → 放弃(六爻占卜案例:自己不懂、AI 也不懂 → 打磨半月放弃)关键概念
- Skill:本文从”作业系统”和”渐进式加载结构”两个维度补充了 Skill 的定义和工程实现
- 提示词工程:本文系统对比了 Skill 与 Prompt 的边界差异(调用方式 / 复杂度承载)
- 工作SOP:Skill 本质 = 把场景 SOP 化的能力,对应”工作 SOP 是写给人的、Skill 是写给 AI 的”
- AI Agent 智能体:Skill 的存在前提是 Agent 作业逻辑——任务复杂度高、涉及脚本/工具/subagent
- Codex:Claude Code、Codex 等 Agent 是 Skill 的调用方
- AI产品PRD:作者举例时多次提到 PRD Skill 的 description 写法
原文精彩摘录
在我刚接触Skill的时候,我在体验完后和朋友说的第一反应就是:这不就是一个大号的prompt吗?感觉好像也没有什么特别新的内容出来啊。但在亲手写了很多Skill后,我觉得它们之间确实有连续性,但是也有很多明显的差别……所以我后来对Skill的理解就变了:Skill并不是一个大号的Prompt,它是一套可以让AI完成更加复杂SOP的作业系统。
如果只说一个最核心的经验,那我认为是:不要一开始上来就是设计Skill,先和AI跑出效果,再封装成Skill。这个逻辑和我之前写提示词有很大区别……而在Agent作业逻辑下,任务的复杂度是明显变高的,它不再只是多轮对话,中间会掺杂各种脚本、工具调用、文件读取、subagent分工的情况,所以很多流程很难在一开始就完整设计出来。所以这套流程本质上不是先设计,再验证,而是先跑通,再复盘,再封装,再回溯。
当Claude Code、Codex这些Agent调用Skill时,并不是一上来就把整个Skill的全部内容都塞给模型,它是分多层级进行渐进式加载的……最后汇总一下我对Skill组织的理解:name和description负责触发,Skill.md负责主流程,参考资料负责在复杂场景下补充能力。关键不是目录看起来多完整,而是每一层都要服务于模型的真实作业流程。
比如我之前一直想做一个六爻占卜Skill。这个场景看起来很适合Skill化,因为它有规则、有流程,也有很多资料可以参考。但真正做成Skill的时候,我发现它很难稳定下来。我自己不够懂占卜,我其实对于怎么解卦毫无思路,然后AI也不懂,我们俩加一起没办法构建一个可靠的回溯测试系统。我压根不知道解卦到底是准还是不准,最后这个Skill我打磨了半个月还是放弃了……所以写Skill到最后考验的不是语法,也不只是提示词能力,而是人把场景SOP化的能力。
与其他素材的关联
- 与 2026-05-11-skill-sop-for-ai(冰冰酱 ACT-R 理论框架)形成”理论 + 实操”互补:冰冰酱用 ACT-R 把 Skill 定义为”将隐性经验编译为可复用程序性知识包”,云舒则用”上百个 Skill”的实战经验填充了这套程序性知识包到底怎么从零写出来的工程细节。云舒提到的”先跑通再封装”和冰冰酱”先做一遍再提炼 Skill”是同一观点的不同表述——两人都强调 Skill 应”从实践中生长,而非从想象中设计”。
- 与 2026-05-20-agent-skills-intro-claude-opus(Anthropic 万字实操入门)的 description 字段重要性互证:Anthropic 给出黄金结构公式
[功能] + [执行动作] + [触发关键词]和”3 条约束 + 1 个示例提升 60% 稳定性”的内部数据;云舒从踩坑角度补充:description 写得太泛会让模型在 app 设计时误调用网页设计 skill——这与 Anthropic 数据形成”why + how + what 会出错”的完整闭环。 - 与 2026-05-21-agent-skills-woshipm(沃垠AI 工程实现手册)形成”作业流程 + 文件骨架”双视角:沃垠AI 从工程层面讲清楚
SKILL.md + scripts/references/assets的标准骨架和渐进式披露机制;云舒从一线作业角度讲清楚这套骨架到底如何”渐进式加载”——三层结构(描述 / SKILL.md / 参考资料)在 Agent 实际调用时的工作机理。 - 与 2026-05-27-woshipm-central-skill-symlink(甜橙和亨亨的中央 Skill 方案)形成”内容生产 + 资产管理”互补:本文讲的是”如何写一个好 Skill”,甜橙文章讲的是”写完的 Skill 如何统一管理避免黑盒化”。两篇放在一起回答了 Skill 工程的两个并存问题——产能(写得出来)和保存(不会丢)。
- 与 2026-05-23-build-sop-personal-effectiveness(蔡锦海工作 SOP 四件套)形成”AI SOP + 人类 SOP”对照:蔡锦海给出 PDCA/5问/SCQA/重要紧急四象限是写给人的 SOP;云舒”Skill 本质 = 人把一件事 SOP 化的能力”印证 Skill 是写给 AI 的 SOP——两者本质同源,只是编译载体(AI 文件 vs 大脑习惯)和执行者(AI vs 人)不同。
- 与 2026-05-13-ai-pm-requirement-scheduling(Jo斯达 PM Skill 案例)的边界守护规则一致:云舒在 3.0 → 不做 4.0 万能化时明确”不要做着做着过界”,与 Jo斯达”需求拆解 Skill 不排优先级、不做变更管理”、“智能排期 Skill 不写代码、不分配开发人员”形成同一条规则——成熟 Skill 必须有清晰边界。
- 与 2026-05-27-woshipm-ai-ecommerce-kol-agent(Elaine.H 电商 AI 导购 PRD)形成”个体 Skill + 企业级 Skill”对照:本文聚焦个体写 Skill 的流程;Elaine.H 讲企业级 Agent + Skills 严格分层架构(Agent 决策中枢,Skills 原子化执行)。两篇放在一起完整呈现 Skill 在从个人到企业的不同尺度形态。