欢迎阅读「从零开始写好 Skill」系列文章 —— 上一个系列我们用 7 篇文章拆解了 Agent 的骨架，这个系列教你给 Agent 写“工作手册”。
开场：从“用别人的”到“自己写”
前两篇你一直在看别人的 Skill——第一篇看 wespy-fetcher 的效果，第二篇拆解它的结构。这篇我们换个角色，尝试自己从零写一个。
场景承接第一篇。还记得吗？wespy-fetcher 帮你把公众号文章抓下来，存成了 Markdown 文件。然后呢？
你打开 Agent，对它说：“帮我总结一下这篇文章，要列出核心观点、关键论据、值得深思的点。” Agent 给了一份还不错的总结。
第二天，又抓了一篇文章，你又得说一遍：“帮我总结一下，要核心观点、关键论据、值得深思的点……”
第三天，同样的话再说一遍。
到了第四天你开始烦了：每次都要把同样的要求重复一遍，这不就是 Skill 要解决的问题吗？
没错。我们要写的 Skill 叫 article-summarizer：输入一篇 Markdown 文章，输出一份结构化的要点总结。wespy-fetcher 管抓取，article-summarizer 管总结，各管一段。
接下来你将经历三个版本的迭代。第一版凭直觉写，会暴露很多问题；第二版用第二篇的检查清单修，解决结构性问题；第三版基于实际踩坑优化，打磨细节。这个“从烂到好”的过程，比直接看一个成品更有价值。如果你对更多 AI Agent 的实践感兴趣，可以深入探索。
一、第一版：凭直觉写
先不翻第二篇的检查清单，凭直觉写一版。大多数人第一次写 Skill 就是这种状态——知道大概该写什么，但不确定该写多细。
---
name: article-summarizer
description: 总结文章内容
---
# 文章总结
帮用户总结文章的要点。
## 步骤
1. 读取文章内容
2. 提取核心观点
3. 列出关键论据
4. 给出总结
就这么短。看起来好像也够了？
让 Agent 用这个 Skill 去总结一篇公众号文章，看看实际效果。第一次跑，Agent 输出了这样的“总结”：
这篇文章主要讨论了 Agent 时代的 API 设计。作者认为 API 需要更加智能化，能够支持 Agent 的自动调用。文章还提到了几个具体的设计原则，包括减少交互轮次、提供结构化响应等。总的来说，这是一篇有价值的技术文章，对 API 设计者有参考意义。
看着像那么回事？仔细看，问题很多。
问题一：结构不稳定。 这次输出是一段话，换一篇文章再跑，可能变成三个要点，再换一篇变成五个要点加一个表格。每次格式都不一样。为什么？因为你没有定义输出格式，Agent 每次自由发挥。
问题二：深度不够。 “作者认为 API 需要更加智能化”——这算什么核心观点？这是把文章标题换了个说法。“提取核心观点”这个指令太模糊了，什么算“核心”？Agent 不知道你的标准，所以只能给你最表面的概括。
问题三：缺少判断力。 一篇技术文章和一篇商业分析，总结的侧重点应该完全不同。技术文章要抓方案和论证逻辑，商业分析要抓数据和结论。但 Skill 没有告诉 Agent 怎么区分，所以它对所有文章都用同一种方式概括。
问题四：触发不了。 这个问题更致命。description 写的是“总结文章内容”，但用户说的可能是“帮我提炼一下这篇文章的要点”“给我做个读后摘要”“归纳一下核心论点”。“提炼”“要点”“摘要”“归纳”这些词和“总结”匹配不上，Agent 可能根本不会加载这个 Skill。
第一版的问题不是“写错了”，而是写得太粗。对照第二篇的检查清单，几乎每一项都没达标。
二、第二版：拿着检查清单修
翻出第二篇的检查清单，逐项修复。
修 description
第二篇讲过：description 是触发器，不是摘要。要写触发条件 + 覆盖用户的多种说法。
---
name: article-summarizer
description: 对 Markdown 格式的文章进行结构化要点总结。
Use when user asks to 总结文章、提炼要点、文章摘要、
归纳核心观点、读后总结、summarize article。
---
改了什么？“总结文章内容”→ 明确说了“结构化要点总结”（告诉 Agent 输出类型），加了 “Use when” 触发词列表，覆盖了“总结”“提炼”“摘要”“归纳”等多种说法。
修概述
第二篇讲过：概述要划边界，不做广告。
# Article Summarizer
对已有的 Markdown 文章进行结构化要点提炼。
不负责文章抓取（抓取请使用 wespy-fetcher），只处理已有内容的总结。
关键是第二段：明确和 wespy-fetcher 的分工。为什么要写这个？因为用户经常会说“帮我下载并总结这篇公众号文章”。如果不划清边界，Agent 可能会试图用 article-summarizer 去做抓取的活，然后失败。写清楚“我只管总结，不管抓取”，Agent 就知道应该先调 wespy-fetcher 再调 article-summarizer。
修操作指南
第一版的“步骤”太模糊了。第二篇讲过：操作指南要给具体场景的示例，不给抽象的通用模板。更重要的是——要定义输出格式。
## 操作流程
1. 通读全文，判断文章类型（技术文章、商业分析、观点评论、教程指南）
2. 根据文章类型确定总结侧重点：
- 技术文章：侧重方案设计和论证逻辑
- 商业分析：侧重数据、结论和商业洞察
- 观点评论：侧重核心主张和论证方式
- 教程指南：侧重关键步骤和注意事项
3. 按以下固定格式输出总结：
### 输出格式
**一句话概括：**（不超过 30 字，说清楚这篇文章的核心主张）
**文章类型：**（技术 / 商业 / 观点 / 教程）
**核心观点（3 个）：**
1. [观点]：[一句话展开]
2. [观点]：[一句话展开]
3. [观点]：[一句话展开]
**关键论据或数据：**（支撑上述观点的关键证据，2-3 条）
**值得深思的点：**（文章中最有启发性的一个观点或问题）
**一句话评价：**（这篇文章的价值和局限）
这里做了三个关键改进：
第一，加了文章类型判断。Agent 不再对所有文章用同一种方式概括，而是先判断类型，再决定侧重点。
第二，定义了固定的输出格式。每个字段都有明确的要求——“一句话概括”不超过 30 字，“核心观点”固定 3 个并且要展开。Agent 不再有自由发挥的空间，每次输出结构一致。
第三，强制做取舍。“核心观点 3 个”不是随便定的——强制 Agent 只挑 3 个最重要的，而不是把文章每个段落都概括一遍。取舍本身就是总结的核心能力。
修补充说明
## 注意事项
- 如果文章过短（少于 200 字），提示用户内容不足以生成有意义的总结
- 如果文章是纯列表或清单类内容（如“十大工具推荐”），
调整为“要点归类”模式而非“观点提炼”模式
- 核心观点固定 3 个，不多不少——宁可舍弃次要观点，也不凑数
- 一句话概括必须是文章的核心主张，不是标题的改写
每一条都在堵一个具体的坑：“文章太短怎么办”“清单类文章怎么办”“Agent 凑数怎么办”“概括变成改写标题怎么办”。
第二版完整效果
把修改后的完整 SKILL.md 交给 Agent，用同一篇文章再跑一次：
一句话概括： Agent 时代的 API 应从“人类友好”转向“意图驱动”
文章类型： 技术
核心观点（3 个）：
- 交互模式需重构：传统 API 的分页、确认弹窗等交互模式为人类设计，会严重拖慢 Agent 的执行效率
- 接口粒度需升级：应提供“意图级”接口而非“操作级”接口，让 Agent 用一次调用完成原本需要多步操作的任务
- 文档受众需转变：API 文档的主要读者将从人类开发者变为 Agent，可读性需要为机器优化
关键论据或数据：
- 作者对比了同一任务在传统 REST API 和意图级 API 下的调用次数差异
- 引用了多个云服务商正在进行的 API 改造案例
值得深思的点： 如果 API 的主要消费者变成 Agent，那“开发者体验”这个概念本身是否需要重新定义？
一句话评价： 观点前瞻且论证清晰，但缺少对过渡期兼容性问题的讨论
好多了。格式稳定、有结构、有深度、有判断。和第一版完全不是一个水平。
但别急着满意——多跑几篇不同类型的文章，新的问题就来了。
三、第二版的坑：实际跑了才发现
用第二版连续总结了十几篇文章后，发现两个靠“想”想不到、只有“用”才能发现的问题。
坑一：“核心观点 3 个”不是万能的。
有些文章确实有 3 个清晰的论点，3 个刚刚好。但有些文章其实就在反复论证一个核心主张——Agent 为了凑 3 个，把同一个观点拆成三种说法，看起来像 3 个其实是 1 个。
还有一些深度长文，信息密度极高，3 个根本兜不住，硬压成 3 个会丢掉重要内容。
固定数量在大多数情况下是好的（防止 Agent 罗列），但在极端情况下反而成了束缚。
坑二：“值得深思的点”和“核心观点”经常撞车。
Agent 在核心观点里已经挑了它认为最重要的 3 个点。到了“值得深思的点”，它又从这 3 个里选了一个换个说法再写一遍。两个字段的内容高度重叠，“值得深思”变成了“核心观点的第四条”。
同样的问题也出现在“一句话评价”上——有时候和“一句话概括”说的是同一件事，只是一个正面表述一个加了“但是”。
这两个问题有一个共同点：它们不是第一版就能预见到的。 只有真正跑了十几篇不同类型的文章，才会发现“固定 3 个”在某些场景下不合理，才会发现字段之间会撞车。
这就是为什么 Skill 需要迭代。不是写完就不管了，而是用起来，踩坑，改进，再用。
四、第三版：基于踩坑优化
针对上面的两个坑，做三个调整：
调整一：核心观点数量改为弹性。
把“核心观点（3 个）”改为“核心观点（2-5 个）”，并加一条约束：
**核心观点（2-5 个，根据文章内容密度调整）：**
- 短文或单一论点文章：2 个即可，不凑数
- 常规文章：3 个为佳
- 深度长文：最多 5 个，超过 5 个说明你在罗列而非提炼
给 Agent 判断空间，但用上下限和指导原则防止它失控。
调整二：合并重叠字段。
把“值得深思的点”和“一句话评价”合并为一个“点评”字段：
**点评：**（用一两句话说说这篇文章最大的价值是什么，
以及它没有覆盖到或可以进一步探讨的地方）
合并后，这个字段同时承载了“亮点”和“局限”两个维度，信息量更大，而且不会和核心观点重复——因为它要求说的是“价值和不足”，不是“观点是什么”。
调整三：加入适用范围声明。
在补充说明里加一条：
- 本 Skill 适合 500-10000 字的深度文章、分析或评论
- 短消息、新闻快讯（少于 500 字）不需要这种级别的总结，直接阅读原文更快
- 超长文章（超过 10000 字）建议先分段，再逐段总结
这条是“防过度使用”——不是所有文章都值得做结构化总结。一条 200 字的新闻快讯，你非要用这个 Skill 去“提炼核心观点”，出来的总结可能比原文还长。
第三版完整 SKILL.md
把所有修改整合到一起：
---
name: article-summarizer
description: 对 Markdown 格式的文章进行结构化要点总结。
Use when user asks to 总结文章、提炼要点、文章摘要、
归纳核心观点、读后总结、summarize article。
---
# Article Summarizer
对已有的 Markdown 文章进行结构化要点提炼。
不负责文章抓取（抓取请使用 wespy-fetcher），只处理已有内容的总结。
## 操作流程
1. 通读全文，判断文章类型（技术文章、商业分析、观点评论、教程指南）
2. 根据文章类型确定总结侧重点：
- 技术文章：侧重方案设计和论证逻辑
- 商业分析：侧重数据、结论和商业洞察
- 观点评论：侧重核心主张和论证方式
- 教程指南：侧重关键步骤和注意事项
3. 按以下格式输出总结
### 输出格式
**一句话概括：**（不超过 30 字，说清楚文章的核心主张，不是标题的改写）
**文章类型：**（技术 / 商业 / 观点 / 教程）
**核心观点（2-5 个，根据文章内容密度调整）：**
- 短文或单一论点文章：2 个即可，不凑数
- 常规文章：3 个为佳
- 深度长文：最多 5 个，超过 5 个说明在罗列而非提炼
每个观点格式：
1. [观点]：[一句话展开]
**关键论据或数据：**（支撑核心观点的关键证据，2-3 条）
**点评：**（这篇文章最大的价值是什么，以及它没有覆盖到或可以进一步探讨的地方）
## 注意事项
- 本 Skill 适合 500-10000 字的深度文章、分析或评论
- 短消息、新闻快讯（少于 500 字）不需要结构化总结，提示用户直接阅读原文
- 超长文章（超过 10000 字）建议先分段再逐段总结
- 如果文章是纯列表或清单类内容（如“十大工具推荐”），
调整为“要点归类”模式而非“观点提炼”模式
- 一句话概括必须是文章的核心主张，不是标题的改写
- 核心观点之间不能有明显重叠，每个观点必须提供独立的信息增量
这就是你的第一个 Skill。可以直接复制使用。更多的技术文档 与最佳实践，可以帮助你进一步打磨类似的工具。
五、三版对比：从“能用”到“好用”差在哪
把三个版本的关键差异放在一起看：
| 维度 |
第一版 |
第二版 |
第三版 |
| description |
“总结文章内容”，太笼统 |
触发词覆盖六种说法 |
同第二版 |
| 边界 |
没有 |
明确和 wespy-fetcher 分工 |
加了适用范围（500-10000 字） |
| 输出格式 |
没定义，每次不同 |
固定格式，结构稳定 |
弹性观点数量，合并重叠字段 |
| 文章类型判断 |
没有 |
四种类型，不同侧重点 |
同第二版 |
| 兜底逻辑 |
没有 |
覆盖短文、清单类 |
加了字数范围、分段建议 |
| 坑点沉淀 |
无 |
基于检查清单 |
基于实际使用迭代 |
这张表里最值得关注的不是第三版有多完美，而是每次改进的来源不同：
第一版 → 第二版的改进来自知识——对照检查清单，知道该写什么。任何人读完第二篇都能做到。
第二版 → 第三版的改进来自经验——只有实际跑了十几篇文章，才会发现“3 个观点不够弹性”“字段之间会撞车”。这些坑不是理论能预见的。
这就是写 Skill 的正确姿势：第一版靠直觉，第二版靠知识，第三版靠经验。不要试图一次写对，而是快速写完，跑起来，踩坑，迭代。
六、一个延伸思考
回头看这个 article-summarizer，它和第一篇的 wespy-fetcher 天然形成配合：
- 用户说“帮我保存并总结这篇公众号文章”
- Agent 先调 wespy-fetcher 抓取文章，存成 Markdown
- 再调 article-summarizer 对这个 Markdown 文件做结构化总结
- 两个 Skill 各管一段，串起来就是一个完整的工作流
这不是巧合。好的 Skill 天然是单一职责的——一个 Skill 只做一件事，做好一件事。需要更复杂的能力？组合多个 Skill，而不是把所有功能塞进一个 Skill。
这个“Skill 之间怎么配合”的话题，我们在后面的文章里展开。
下一篇预告
你已经写出了自己的第一个 Skill，也体验了三轮迭代。但你可能注意到了：每一轮都要自己思考问题在哪、怎么改、改完再跑一遍验证。这还只是一个简单的总结 Skill——如果是更复杂的场景，迭代成本会更高。
有没有办法让这个过程更高效？
下一篇，我们介绍 Anthropic 官方出品的 skill-creator ——一个帮你创建、测试和迭代 Skill 的“元技能”，用 AI 来写 AI 的工作手册。
「从零开始写好 Skill」系列是「从零开始理解 Agent」系列的姊妹篇。如果你还没有读过 Agent 系列，建议先从 第一篇：Agent 的底层原理 开始。
发表于 1 小时前
|
查看: 4|
回复: 0
