看了很多文章依旧不会写 Skill？实战分享
Skill 的真正难点不是写一个文件，而是写出一个不需主动提醒就能自动触发、产出稳定且可长期维护的 Skill。本文从判断时机、两种构建方法、评估驱动开发、三大常见坑、长期维护和改造现成 Skill 六个维度，给出了一套可复制的 Skill 实战方法论。
基本信息
- 来源类型：网页文章
- 原文位置：raw/articles/2026-06-02-165823-tg-fe1100.md
- 原文 URL：https://www.woshipm.com/ai/6406379.html
- 消化日期：2026-06-02
核心观点
-
Skill 本质是一个文件夹，不是单文件：一个 Skill 由三个部分组成——SKILL.md（总控文件，包含 YAML frontmatter + Markdown 指令）、references/（规则、知识库、风格指南等参考资料）、scripts/（Agent 可直接执行的脚本）。背后机制是渐进式披露：第一层只加载 name + description，第二层触发后加载 SKILL.md，第三层按需加载 references 和 scripts，不触发时不占上下文窗口（来源：2026-06-02-woshipm-skill-creation-guide）
-
适合做 Skill 的任务满足三个特征之一即可：高频触发、有专属业务知识、出错成本高。高频任务省掉重复输入提示词的时间，业务知识让 AI 学会公司内部标准（文档格式、统计口径、交付标准），高出错成本任务通过 Skill 强制规范执行流程。满足任一条就值得封装（来源：2026-06-02-woshipm-skill-creation-guide）
-
构建 Skill 有两种方法：逆向工程和主动梳理。逆向工程适合新手——先让 AI 做真实任务，跑出问题后让 AI 把整个对话流程沉淀为 Skill；主动梳理适合已有明确想法的场景——把目标、流程、约束讲清楚，让 AI 整理成 Skill。核心心态不是问 AI 能做什么，而是问”我有没有把上下文、约束和目标准备到让 AI 有机会成功交付”（来源：2026-06-02-woshipm-skill-creation-guide）
-
评估驱动开发（Evaluation-Driven Development）是 Anthropic 官方推荐的 Skill 构建前置步骤：做 Skill 前先让 AI 不带任何方法论地尝试执行任务，观察它卡在哪里、哪里做得不好——这些卡点才是真正需要写进 Skill 里的内容。不要一开始就凭空脑补规则，真正有效的 Skill 迭代是”补系统缺口”，而不是”抽卡一样不断重跑”（来源：2026-06-02-woshipm-skill-creation-guide）
-
Skill 的三个常见坑：触发失败、产出不稳、太长导致 context rot。触发失败 90% 是 description 写得不对——要同时包含「做什么」和「什么时候用」、用第三人称、包含用户自然会说的触发词；产出不稳往往是因为 Skill 写得太窄——给原则（为什么这样做+心态+核心原则）比写死步骤更鲁棒，有客观对错的任务写窄，无客观对错的任务写框架；context rot 指加载 token 越多召回精度越低，官方建议不超过 500 行、作者控制在 200 行以内（来源：2026-06-02-woshipm-skill-creation-guide）
-
references 和 scripts 有明确分工：references 放细节和参考资料（不是每次加载的规则、特定场景扩展资料），scripts 放确定性操作（排序、格式验证、API 调用、文本清洗等有明确输入/规则/输出的事）。scripts 的额外优势：代码不进上下文、只有执行结果给 AI，且保证每次执行一致——把”AI 自己判断怎么清洗”变成”运行脚本拿干净素材”（来源：2026-06-02-woshipm-skill-creation-guide）
-
subagent 做质量控制的核心原则是职责分离：主 Agent 负责执行、subagent 负责检查。给 subagent 独立上下文和质检清单，让它按 checklist 验收。好处：(1) 不被主 Agent 执行过程干扰，(2) 避免主 Agent 既当运动员又当裁判。这是 Skill 在容错率低的商业场景中的关键安全层（来源：2026-06-02-woshipm-skill-creation-guide）
-
Skill 长期维护的两个触发时机和三件事：触发时机——新模型发布时（删掉为弥补旧模型能力不足而写的补丁，让上下文更干净）和工作流执行完后（让 Agent 复盘错误并沉淀）。维护三件事：删除冗余信息（一条信息讲一次够了）、重整结构（自己能快速看懂骨架）、提取 references（把示例/边界情况/特殊说明拆出去）。关键警告：不要完全放手让 AI 自己改——先让它说明修改方向，人审核结构是否干净（来源：2026-06-02-woshipm-skill-creation-guide）
-
改造现成 Skill 有五个维度：改 description、改输入来源、改 workflow、改输出格式、改停止条件。description 要贴近团队真实表达而非泛化介绍；输入来源要写清楚飞书/Notion/内部系统等具体来源；workflow 要对接团队真实流程；输出格式要写进团队模板；停止条件是很多人忽略的地方——不自动发布、不自动修改权限、遇到不确定时必须确认。判断改得好不好的标准：“你是不是少解释了几句？是不是少返工了几轮？Agent 有没有在该确认的时候停下来？“（来源：2026-06-02-woshipm-skill-creation-guide）
-
Skill 的真正意义是团队能力共享的新方式：写 Skill 不是为了让 AI 变得”更像你”，而是把你脑子里的执行逻辑、判断标准和工作方法变成 Agent 可调用的能力。以前高手能力难复制，新人要从零学；现在团队把关键方法沉淀成 Skill，新人的 Agent 直接继承。模型会越来越强，真正有价值的是你对业务的理解、流程的判断和结果的要求——这些才是 Skill 里最值得沉淀的部分。作者判断：Skill 是人和 Agent 协作的新接口（来源：2026-06-02-woshipm-skill-creation-guide）
实操内容保留
Prompt 模板
逆向工程 Skill 构建指令：
请使用 skill creator skill，把我们刚刚的对话转换成一份可以重复使用的 Skill。
确保下次我遇到同类公众号文章创作任务时，不需要像刚才那样反复调整选题、结构、观点和语气。
主动梳理 Skill 构建指令：
从现在开始，我每周都要写一篇公众号文章。
我希望你帮我制作一份 Skill，用来加快这个任务的执行速度，并且让文章质量更稳定。
我设想的流程是：先根据我提供的主题和素材，帮我判断最适合展开的文章角度；然后提炼核心观点，生成文章大纲；接着写出公众号风格的初稿；最后再检查标题、开头、结构、案例和结尾是否足够适合发布。
以上是我的初步想法。请你把它整理成一份以后可以重复执行的 Skill。
在开始之前，如果有任何不清楚的地方，请先向我确认，不要直接开始写。
评估驱动开发的执行提示词：
现在请你复盘刚刚的执行过程。
请列出我们犯了哪些错误，每个错误背后的原因是什么，并判断这些错误是否可以沉淀进现有 Skill，避免下次再犯。
团队知识库 Skill 改造示例：
name: team-kb-writer
description: 当团队成员提供飞书草稿、会议纪要或技术方案，并要求整理成可发布的团队知识库文章时使用。先读取原文，提炼读者和目标，按团队模板重组结构，输出知识库草稿和待确认事实清单。不自动发布，不自动 @ 人。
workflow:
1. 检查来源文档是否可读取。
2. 读取原文，判断内容主题、目标读者和发布目的。
3. 按团队知识库模板重组结构。
4. 标注待确认事实、缺失来源和风险表述。
5. 输出草稿到指定位置，但不自动发布。
操作步骤
Skill 构建的两种路径：
逆向工程（适合新手）：
- 开一个新对话，让 AI 做真实任务
- 协作过程中不断调整，找到好的产出
- 完成后不要关对话，说”把刚才的流程沉淀成 Skill”
- AI 基于真实上下文生成可复用的 Skill 文件
主动梳理（适合已有想法的场景）：
- 明确你的目标、流程和约束
- 把意图、目标和约束讲清楚给 AI
- 让 AI 整理成 Skill
- 有不清楚的地方，让 AI 先确认再写
改造现成 Skill 的五个维度：
- 改 description → 贴近团队真实表达（触发器，不是介绍）
- 改输入来源 → 写清楚文档来自哪里（飞书/Notion/聊天记录等）
- 改 workflow → 对接团队真实流程
- 改输出格式 → 写进团队固定结构模板
- 改停止条件 → 不自动发布、不自动修改权限、不确定时必须确认
Skill 长期维护时机：
- 新模型发布时 → 删掉为弥补旧模型不足而写的补丁
- 工作流执行完后 → 让 Agent 复盘错误并沉淀进 Skill
- 维护时做三件事：删除冗余 → 重整结构 → 提取 references
关键概念
- Skill：写给 AI 的 SOP，将隐性经验编译为可复用的程序性知识包
- 提示词工程：Skill 与 Prompt 的精确边界——Skill 在调用方式和承载复杂度两个维度突破了 Prompt 天花板
- 渐进式披露：Skill 的三层加载机制——name+description 触发 → SKILL.md 主流程 → references/scripts 按需
- 评估驱动开发（Evaluation-Driven Development）：Anthropic 推荐的 Skill 构建前置方法——先让 AI 无规则执行，从失败中提炼真正需要写的规则
- Context Rot：加载 token 越多召回关键信息精度越低的现象，直接影响 Skill 文件长度上限（官方建议 <500 行）
- 逆向工程：从真实对话中提炼 Skill 的构建方法
- 主动梳理：从明确目标出发整理 Skill 的构建方法
- 改造 Skill 五维度：改 description / 输入来源 / workflow / 输出格式 / 停止条件
不同素材中的观点
（首次消化，无交叉对比）
原文精彩摘录
关于 Skill 的真正难点
写一个 Skill 本身其实并不难。难的是，写出一个不需要你每次主动提醒，Agent 在需要的时候就能自动触发，并且产出稳定、长期且还能被人维护的 Skill。
关于评估驱动开发
Anthropic 官方把它叫做 evaluation-driven development，可以理解为「评估驱动开发」。意思是，在你做一个 Skill 之前，先让 AI 不带任何方法论地尝试执行一次任务。你什么规则都不提供，让它自己做。然后观察它会卡在哪里、哪里做得不好、哪里需要你补充。这些卡点，才是你真正需要写进 Skill 里的内容。不要一开始就凭空脑补一堆规则。
关于 Skill 写得太窄的问题
不要把 Skill 写的太窄。一份过窄的 SOP，本质上是在假设模型没有判断能力。但现在的推理模型，已经具备相当强的判断能力。我自己的实践是：给原则，但不要过度限制做法。规则写得太死，AI 遇到变化时就没有处理空间。一份好的 SKILL.md，最核心的不是步骤，而是执行原则。
关于 Context Rot
LLM 有一个现象叫 context rot。简单说，就是加载的 token 越多，它召回关键信息的精度就越容易下降。更直白一点：你塞进去的东西越多，模型越难从里面准确找到真正重要的内容。官方建议是，如果一份 Skill 超过 500 行，就应该拆分。我一般会控制在 200 行以内。原因很简单：500 行的 Skill，我自己看都不想看，更别谈维护了。
关于 Skill 的团队共享意义
过去，一个人多年积累下来的 know-how，往往只能存在自己脑子里。想教会别人，只能靠反复讲、手把手带，或者写一堆 SOP。但现在，你可以把这些经验整理成 Skill。一旦 Skill 写好，Agent 就能按照你的方法做事。所以，写 Skill 不是为了让 AI 变得”更像你”。而是把你脑子里的执行逻辑、判断标准和工作方法，变成 Agent 可以调用的能力。
关于改造 Skill 的判断标准
判断一个 Skill 改得好不好，不看它写得多完整，而看下一次真实任务里：你是不是少解释了几句？是不是少返工了几轮？Agent 有没有在该确认的时候停下来？如果答案是肯定的，说明这个 Skill 已经开始贴合你的工作流了。