前言

---

反复用 Agent 处理同一类工作时，麻烦的不是它完全不会做，而是同样的格式、标准和例外每次都要重新说明。少说一句，输出就可能变样。

Skill 用来把这些重复说明保存成可复用的工作方法。下次遇到同类任务时，Agent 可以按这套方法执行，而不是每次临场发挥。

课程目标

---

学完这节课后，你将能够：

• 把一套跑顺的工作方法写进 Skill。

• 调整 Skill 的触发条件和执行规则。

1 为什么需要 Skill：每次都要重复交代标准

---

先看一个周报例子。假设你每周都要让 Agent 根据工作记录整理周报，材料并不复杂：

完成客户续费名单整理，已按客户等级标注优先级。
更新“客户回访话术”说明，已放到团队共享文档。
下周客户拜访排期：3 位客户已确认时间，2 位客户待回复。
整理本周客户反馈，初步归为价格、交付和售后三类。
下周计划：跟进重点客户续费确认，补充客户反馈清单。

如果你只说：

根据这些本周工作记录，帮我整理成一份周报。

Agent 多半能写出一份周报，但每次格式可能不一样：这次叫“本周总结”，下次叫“工作进展”；这次把重点事项单独列出来，下次又散在各段正文里

Skill 要固定的，就是这套整理方法：

• 输出结构：周报包含“本周完成 / 进行中 / 下周计划 / 待确认事项”。

• 处理规则：重要客户或紧急事项写成高优先级跟进。

• 缺失信息：材料里没有依据的内容标为“待确认”。

Skill 固化的不是某一篇周报正文，而是“周报整理”这项工作的做法。

2把自己的周报写法保存成 Skill

新建 Skill 不只有一种方式。常见的有这几种，适合不同情况：

• 直接描述需求：你已经有明确的规则，比如团队 SOP 或操作手册，直接把规则告诉 Agent，让它生成 Skill。不需要先跑一遍任务。

• 给参考文件或样例：你手上有过去做得好的成品，比如几份符合标准的周报、一份格式规范的会议纪要模板，把它们交给 Agent，让它从中提炼规则并生成 Skill。

• 先跑通一次再生成：你还没想清楚规则该怎么写，先在对话里把任务做一遍、把标准调出来，再从过程中提炼成 Skill。

• 从已有 Skill 修改：安装一个技能广场或别人分享的 Skill，在它基础上改成自己的做法。

3.1 先把周报标准聊清楚

如果你还没有明确的周报标准，可以先在对话里把一次周报整理跑顺，从过程中发现规则。先让 Agent 读一份工作记录，整理出一版周报草稿。不要急着创建 Skill。先把不符合你标准的地方改出来，等符合标准了再创建skill

3.2 根据沟通记录创建 Skill

周报的栏目、分栏规则和输出顺序已经清楚了。这套周报规则只服务于当前练习项目，所以这次把它保存到当前项目里，也就是创建一个项目级 Skill。这样下次在这个项目里写周报时，Agent 就能继续按这套做法处理。

3.3 测试确认 Skill 能否被调用

创建完后，先别急着研究文件内容。先问一个简单问题：Agent 能不能找到这个 Skill，并按里面的做法写周报。

可以明确写出 Skill 名：

请使用周报整理 Skill，读取当前文件夹里的“本周工作记录”和“会议纪要”，生成一份周报草稿。

这次测试不追求一份完美周报。先看它有没有按固定几部分写，待确认事项有没有单独列出来，缺少依据的内容有没有标成“待确认”。

4 看懂 Skill 和提示词模板有什么不同

生成并调用过一次之后，再看 Skill 的结构会更容易理解。你可能会觉得：这不就是把一段提示词存起来吗？

差别在于，提示词模板需要你每次复制到对话里；Skill 会先用一小段说明让 Agent 判断这次要不要用它，确认要用以后，再读取完整做法。

Skill 在电脑里通常是一个文件夹，例如 weekly-report-draft。里面的核心文件是一份 SKILL.md。打开它，先看两块就够了：

• 开头的 name 和 description：告诉 Agent 这个 Skill 叫什么、什么时候该用。

• 正文：写完整做法，比如先读哪些材料、周报包含哪些部分、待确认事项怎么写、缺少依据时怎么处理。

这里要注意 description 的作用。Agent 启动时，只会读取每个 Skill 的 name 和 description，不会读正文。它靠这一小段话来判断"这次任务要不要用这个 Skill"。判断要用以后，才去读完整的正文。

所以 description 是 Agent 选择 Skill 的依据。写得不准，Agent 就找不到它；写得太模糊，几个 Skill 之间就容易选错。

Skill 文件夹里也常见 references/、scripts/ 等子目录。references/ 可以放模板、术语表、案例说明，scripts/ 可以放自动检查脚本。

这些内容也不是一次性全塞给 Agent。需要模板或脚本时，才继续读取 references/ 或 scripts/。

这种按需读取的方式，也叫渐进式披露。它的好处是：不用每轮对话都塞进一大段规则，但 Agent 真要处理这类任务时，又能拿到完整做法。看懂这个结构后，调用出问题时就知道该改哪一处。

5 把调用中发现的问题补回 Skill

5.1 没有自动调用，就改描述

Skill 能被调用，不代表它已经好用。调用后先看一件事：Agent 是不是主动用了这个 Skill。

如果你只是说“帮我整理本周进展”，Agent 没有使用周报整理 Skill，问题通常不在周报规则，而在开头那段触发说明。

如果只写”用于结构化工作汇报生成”，看起来正式，但 Agent 不一定容易判断什么时候该用。

写 description 时还有几个常见问题：

• 用了第一人称。description 会被注入到 Agent 的系统提示里，写”我可以帮你整理周报”会让 Agent 困惑这段话是谁说的。应该写成”根据工作记录整理周报”这样的第三人称陈述。

• 关键词没有放在前面。某些 Agent 对 description 有字符数上限，超出部分会被截断。所以最重要的触发词要写在开头，例如先写”整理周报、生成本周进展”，再写补充说明。

• 把具体规则写进了 description。前面讲过，Agent 启动时会读取所有 Skill 的 description，但只有决定使用某个 Skill 以后才会读它的正文。description 里只需要写”这个 Skill 做什么、什么时候触发”，让 Agent 能判断该不该用就够了。具体的栏目、规则、输出格式放在正文里——它们是 Agent 确定要用这个 Skill 以后才需要知道的。把规则也塞进 description，只会占用每轮对话都要消耗的上下文空间，但对触发判断没有帮助。

5.2 调用了但结果不对，就把问题写回 Skill

如果 Agent 已经使用了这个 Skill，但生成的周报还是不符合你的习惯，不要只改这一次周报。

比如它把待回复、待确认的事项散在正文里，没有单独列出“待确认事项”。你当然可以让它把这份周报改对，但真正有用的是让 Agent 把“待确认事项要单独列出”补回 Skill。这样下次再遇到类似材料，它才知道该怎么处理。

5.3 换样本验证 Skill

换样本时，可以准备 2 到 3 份差异明显的材料：一份信息完整，一份缺负责人或截止时间，一份包含待确认或冲突信息。每次调用后看三件事：是否触发了这个 Skill，是否按固定结构输出，是否把缺失和不确定内容标出来。

如果这个 Skill 会被团队反复使用，可以把测试样本再扩大一些，记录常见失败原因：触发不准、栏目跑偏、待确认漏掉、脚本检查失败。下一轮修改时，不是只修某一次输出，而是把失败原因补回触发说明、执行规则、参考资料或脚本。

6 换到别的任务时，也这样找和用 Skill

周报只是一次练习。换成页面、数据分析、读书笔记时，判断方式不变：先看技能广场或别人分享的 Skill 里有没有合适的，试一次；如果只差几条规则，就在已安装的 Skill 上补充；如果你的做法已经比较固定，再新建自己的 Skill。

让 Agent 帮你安装

找到 Skill 后，先确认来源，再安装。在 QoderWork 技能广场里，通常可以在技能详情页直接点击安装。

如果你拿到了别人分享的 Skill 安装命令，可以直接发给 QoderWork：

请帮我安装这个 Skill：npx skills add vercel-labs/agent-skills --skill frontend-design

如果你拿到的是 Skill 页面链接，也可以直接发给 QoderWork：

帮我安装这个 Skill：https://qoder.com/marketplace/xxx

QoderWork 会尝试识别命令或链接、下载对应文件夹，并把它放到合适的位置。

安装过程中，如果 QoderWork 问你“安装到用户级还是项目级”，可以按下面的规则选：

安装位置	适合放什么	例子
用户级 Skill	个人在多个项目中复用的方法	个人写作风格、常用汇报格式、PPT 偏好
项目级 Skill	当前项目或团队共享的方法	客户反馈规范、课程文档写作规范、团队复盘模板

简单判断：

• 只服务于个人习惯，并且多个项目都会用到，选用户级。

• 和当前项目强相关，或者希望团队按同一标准使用，选项目级。

个人 Skill 用来保存自己的写作习惯和常用格式；团队 Skill 用来让多人按同一套标准处理工作；组织或产品负责人维护的 Skill，则适合承载更成熟、需要持续更新的流程。

这个选择不是一次性决定。以后如果发现放错了范围，通常可以再让 Agent 帮你调整，例如“把这个 Skill 从项目级改成用户级”。

创建和修改 Skill 时的自查清单

为了减少找不到、误触发和选错 Skill，创建或修改时可以从三方面自查。

数量和触发

• Skill 不是越多越好：每个 Skill 的 name 和 description 都会占用上下文；装得太多，Agent 要看的说明变长，名字和触发条件接近时也更容易选错。

正文内容

• 少写常识，多写判断标准：不要解释 PDF、周报、会议纪要这类 Agent 已经知道的概念，优先写你的栏目、处理规则、例外情况和检查方式。

• 不要只写人设，要写清步骤：提示词里可以用角色帮助 Agent 理解任务风格，但 Skill 不能只写“你是一位资深专家”。更有用的是写清动作，比如“先读取材料，再按这几个栏目输出；缺少依据的内容标为待确认”。

• 写当前做法：默认写现在应该怎么做；废弃做法可以单独说明，不要让 Agent 在一堆日期条件里判断该用哪套规则。

文件组织和任务拆分

• SKILL.md 只放主要做法：正文里写任务流程、输出格式、判断标准和异常处理；长模板、案例、术语表放到 references/；复杂检查可以放到 scripts/。判断标准是：SKILL.md 正文一旦被 Agent 加载，就会在整个会话中保持在上下文里。每次执行都要用到的核心流程放正文；只在特定情况下才需要的详细参考放单独文件，Agent 会在需要时再去读取。一般建议 SKILL.md 正文不超过 500 行，接近这个长度时就考虑把部分内容拆到单独文件里。

• 开放任务用文字，精确任务用脚本：写作、审稿、资料整理这类任务，适合用文字说明判断标准；文件批量重命名、表格校验、格式检查这类任务，适合沉淀成脚本。

• 复杂任务可以组合多个 Skill：当一个任务自然分成“收集材料、生成初稿、检查质量、整理发布”等不同环节时，可以让不同 Skill 各负责一段。组合时要写清每个 Skill 的输入、输出和交接结果，例如先用资料整理 Skill 提取事实，再用写作 Skill 生成草稿，最后用检查 Skill 看格式和遗漏。不要为了显得完整而把一个简单流程拆成很多 Skill；如果只是同一类任务里的几个固定步骤，优先放在同一个 Skill 里。

6.4 Skill 管方法，MCP 管能力

最后别把 Skill 和工具混在一起。Skill 解决的是“这类工作应该怎么做”。比如写周报时，固定栏目、事项归类、待确认事项怎么写，这些都适合写进 Skill。

MCP 或外部工具解决的是“Agent 能不能拿到资料、能不能执行动作”。比如读取业务系统、查数据、操作文档、调用服务，这些靠工具能力完成。

同一个任务里，两者可以一起用。比如做客户拜访准备时，Skill 可以规定：先用企业客户系统 MCP 读取客户最近沟通记录，再用日历 MCP 查可约时间，最后用高德地图 MCP 估算路程，并按“客户背景 / 近期问题 / 拜访时间 / 路线安排”输出。