Skip to main content

从真实专业经验出发

在创建 skill 时,一个常见误区是只依赖 LLM 的通用训练知识,而不给它提供领域特定的上下文,就直接让它生成 skill。这样得到的往往是模糊、通用的流程说明(例如“妥善处理错误”“遵循认证最佳实践”),而不是那些真正让 skill 有价值的具体 API 模式、边界情况和项目约定。 高质量的 skills 必须建立在真实专业经验之上。关键在于把领域特定的上下文输入到创建过程中。

从一次真实任务中提炼

和 agent 一起完成一项真实任务,在过程中持续提供上下文、纠正和偏好设定。然后把其中可复用的模式提炼成 skill。重点关注:
  • 哪些步骤真正有效:最终成功所依赖的动作顺序
  • 你做过哪些纠正:你在哪里调整了 agent 的做法(例如“用库 X,不要用 Y”“检查边界情况 Z”)
  • 输入 / 输出格式:进入和产出的数据分别是什么样子
  • 你补充过哪些上下文:agent 原本并不知道的项目事实、约定或约束

从现有项目资料中归纳

当你已经积累了一批现成知识时,可以把它们输入给 LLM,让它归纳出一个 skill。一个基于你们团队真实事故报告和 runbook 归纳出来的数据流水线 skill,通常会优于从一篇泛泛的“数据工程最佳实践”文章里总结出来的 skill,因为前者捕捉到了你们自己的 schema、故障模式和恢复流程。关键不在于泛用参考资料,而在于项目特定材料。 好的来源材料包括:
  • 内部文档、runbook 和风格指南
  • API 规范、schema 和配置文件
  • 代码评审评论和 issue 记录(能体现反复出现的问题和评审预期)
  • 版本控制历史,尤其是补丁和修复记录(能通过真实变更暴露模式)
  • 真实失败案例及其解决方式

用真实执行结果持续打磨

一个 skill 的第一版通常都需要继续打磨。把它拿去跑真实任务,然后把结果反馈回创建流程中,而且要反馈全部结果,不只是失败案例。你应该追问:是什么导致了误触发?遗漏了什么?哪些内容可以删掉? 哪怕只做一轮“执行再修订”,质量也通常会明显提升;而在复杂领域里,往往需要多轮迭代。
不要只看最终输出,也要看 agent 的执行轨迹。如果 agent 把时间浪费在无效步骤上,常见原因包括:说明过于模糊(agent 会尝试多种方案才找到可行解)、说明并不适用于当前任务(但 agent 还是照做了),或者给了太多选项却没有清晰默认值。
如果你想要更结构化的迭代方法,包括测试用例、断言和评分,可以参考评估 skill 输出质量

精打细算地使用上下文

一旦某个 skill 被激活,它完整的 SKILL.md 正文就会和对话历史、系统上下文以及其他已激活的 skills 一起进入 agent 的上下文窗口。你写进 skill 的每一个 token,都会和这个窗口里的其他内容竞争 agent 的注意力。

补 agent 所缺,删 agent 已知

聚焦那些如果没有你的 skill,agent 本来不会知道 的内容:项目特定约定、领域特定流程、不明显的边界情况,以及应该使用的具体工具或 API。你不需要解释 PDF 是什么、HTTP 如何工作,或者数据库迁移是什么。
<!-- Too verbose — the agent already knows what PDFs are -->
## Extract PDF text

PDF (Portable Document Format) files are a common file format that contains
text, images, and other content. To extract text from a PDF, you'll need to
use a library. pdfplumber is recommended because it handles most cases well.

<!-- Better — jumps straight to what the agent wouldn't know on its own -->
## Extract PDF text

Use pdfplumber for text extraction. For scanned documents, fall back to
pdf2image with pytesseract.

```python
import pdfplumber

with pdfplumber.open("file.pdf") as pdf:
    text = pdf.pages[0].extract_text()
```
对于每一段内容,都问自己一句:“如果没有这条说明,agent 会把这里做错吗?”如果答案是否定的,就删掉;如果你不确定,就去测试。如果 agent 在没有这个 skill 的情况下已经能很好完成整个任务,那这个 skill 可能并没有真正增加价值。如何系统地验证这一点,可以看评估 skill 输出质量

设计边界清晰的能力单元

决定一个 skill 应该覆盖什么,和决定一个函数应该做什么很像:你希望它封装的是一个边界清晰、且能和其他 skills 良好组合的工作单元。范围太窄的 skill 会让单个任务不得不同时加载多个 skills,带来额外开销和潜在冲突;范围太宽的 skill 又很难被精确激活。比如“查询数据库并格式化结果”可能是一个完整单元,但如果还顺带覆盖数据库管理,那大概率就做得太多了。

保持适中的细节密度

过于全面的 skill 往往弊大于利。agent 会难以提取真正相关的信息,还可能因为一些并不适用于当前任务的说明而走上无效路径。通常来说,简洁的分步骤指引,加上一个能工作的示例,比巨细无遗的文档更有效。当你发现自己在覆盖每一个边界情况时,不妨反思一下,其中大多数是不是其实更适合交给 agent 自己判断。

用渐进式披露组织大型 skills

规范建议把 SKILL.md 控制在 500 行、5000 tokens 以内,只保留每次运行 agent 都必需的核心说明。如果某个 skill 确实需要更多内容,应把详细参考资料移到 references/ 或类似目录中的独立文件里。 关键在于明确告诉 agent 什么时候 去加载每个文件。比如“如果 API 返回非 200 状态码,就读取 references/api-errors.md”,会比笼统地说一句“详情见 references/”更有用。这样 agent 就能按需加载上下文,而不是一开始全部读入,这正是渐进式披露的设计目标。

校准控制力度

不是每一部分都需要同样强的规定性。说明具体到什么程度,应该和任务本身的脆弱程度相匹配。

让具体程度匹配任务脆弱性

当多种方法都可行、任务也允许一定变化时,应给 agent 留出自由度。对于较灵活的说明,解释为什么这样做,通常比死板地下指令更有效,因为理解了说明背后的目的后,agent 才能在不同上下文中做出更好的判断。比如,一个代码评审 skill 可以说明应该关注什么,而不必规定死板步骤:
## Code review process

1. Check all database queries for SQL injection (use parameterized queries)
2. Verify authentication checks on every endpoint
3. Look for race conditions in concurrent code paths
4. Confirm error messages don't leak internal details
当操作比较脆弱、一致性非常重要,或者必须严格遵循某个顺序时,就应该更强约束
## Database migration

Run exactly this sequence:

```bash
python scripts/migrate.py --verify --backup
```

Do not modify the command or add additional flags.
大多数 skills 实际上都会混合这两种情况。你应当针对不同部分分别校准。

给默认方案,不要给菜单

当有多种工具或方案都能完成任务时,应该选出一个默认方案,再简要提一下替代选项,而不是把它们平铺成完全等价的菜单。
<!-- Too many options -->
You can use pypdf, pdfplumber, PyMuPDF, or pdf2image...

<!-- Clear default with escape hatch -->
Use pdfplumber for text extraction:

```python
import pdfplumber
```

For scanned PDFs requiring OCR, use pdf2image with pytesseract instead.

优先教方法,而不是直接给答案

一个 skill 应该教给 agent 一类问题应该怎么处理,而不是针对某个具体实例直接告诉它要产出什么。对比如下:
<!-- Specific answer — only useful for this exact task -->
Join the `orders` table to `customers` on `customer_id`, filter where
`region = 'EMEA'`, and sum the `amount` column.

<!-- Reusable method — works for any analytical query -->
1. Read the schema from `references/schema.yaml` to find relevant tables
2. Join tables using the `_id` foreign key convention
3. Apply any filters from the user's request as WHERE clauses
4. Aggregate numeric columns as needed and format as a markdown table
这并不意味着 skills 不能包含具体细节。输出格式模板(见输出格式模板)、像“绝不要输出 PII”这样的约束,以及工具特定说明,依然都很有价值。重点在于:即便包含了具体细节,整体方法仍然应该是可泛化的。

高效说明的常见模式

下面这些都是组织 skill 内容时可复用的技巧。不是每个 skill 都需要全部用上,只选择适合你任务的那些即可。

Gotchas 小节

很多 skills 中最有价值的内容,恰恰是一份 gotchas 列表,也就是那些违背常识预期的环境特定事实。它们不是“妥善处理错误”这种泛泛建议,而是一些如果不提前告诉 agent,它就很可能会犯的具体错误修正:
## Gotchas

- The `users` table uses soft deletes. Queries must include
  `WHERE deleted_at IS NULL` or results will include deactivated accounts.
- The user ID is `user_id` in the database, `uid` in the auth service,
  and `accountId` in the billing API. All three refer to the same value.
- The `/health` endpoint returns 200 as long as the web server is running,
  even if the database connection is down. Use `/ready` to check full
  service health.
对于 gotchas,最好直接放在 SKILL.md 里,这样 agent 会在真正遇到问题前先读到它们。如果你能明确告诉 agent 何时加载,那么独立参考文件也可以;但对于那些不明显的问题,agent 可能根本意识不到触发时机。
当 agent 犯了一个需要你手动纠正的错误时,就把这条纠正补进 gotchas 小节。这是迭代提升 skill 的最直接办法之一(见用真实执行结果持续打磨)。

输出格式模板

当你需要 agent 按特定格式输出内容时,最好直接提供模板。这比用大段文字去描述格式更可靠,因为 agent 对具体结构的模式匹配通常更好。较短的模板可以直接写在 SKILL.md 里;更长的模板,或者只在某些场景下才需要的模板,可以放在 assets/ 中,再从 SKILL.md 里引用,让 agent 按需加载。
## Report structure

Use this template, adapting sections as needed for the specific analysis:

```markdown
# [Analysis Title]

## Executive summary
[One-paragraph overview of key findings]

## Key findings
- Finding 1 with supporting data
- Finding 2 with supporting data

## Recommendations
1. Specific actionable recommendation
2. Specific actionable recommendation
```

多步骤工作流的检查清单

显式的检查清单能帮助 agent 跟踪进度、避免漏步骤,尤其适用于步骤之间有依赖关系或存在校验门槛的场景。
## Form processing workflow

Progress:
- [ ] Step 1: Analyze the form (run `scripts/analyze_form.py`)
- [ ] Step 2: Create field mapping (edit `fields.json`)
- [ ] Step 3: Validate mapping (run `scripts/validate_fields.py`)
- [ ] Step 4: Fill the form (run `scripts/fill_form.py`)
- [ ] Step 5: Verify output (run `scripts/verify_output.py`)

校验闭环

应该明确要求 agent 在进入下一步之前先校验自己的工作。典型模式是:先完成任务,再运行一个校验器(脚本、参考清单或自检步骤),修复发现的问题,然后重复,直到校验通过。
## Editing workflow

1. Make your edits
2. Run validation: `python scripts/validate.py output/`
3. If validation fails:
   - Review the error message
   - Fix the issues
   - Run validation again
4. Only proceed when validation passes
一份参考文档也可以充当“校验器”角色。你可以要求 agent 在最终提交前,把自己的结果与参考文档逐项核对。

先规划、再校验、后执行

对于批处理操作或破坏性操作,应先让 agent 以结构化格式产出一个中间计划,再把计划和可信来源进行校验,确认无误后再执行。
## PDF form filling

1. Extract form fields: `python scripts/analyze_form.py input.pdf``form_fields.json`
   (lists every field name, type, and whether it's required)
2. Create `field_values.json` mapping each field name to its intended value
3. Validate: `python scripts/validate_fields.py form_fields.json field_values.json`
   (checks that every field name exists in the form, types are compatible, and
   required fields aren't missing)
4. If validation fails, revise `field_values.json` and re-validate
5. Fill the form: `python scripts/fill_form.py input.pdf field_values.json output.pdf`
关键在第 3 步:通过一个校验脚本,把计划(field_values.json)和可信来源(form_fields.json)进行比对。像“Field ‘signature_date’ not found — available fields: customer_name, order_total, signature_date_signed”这样的错误信息,能够给 agent 足够的信息来自我修正。

打包可复用脚本

当你在迭代一个 skill时,可以比较 agent 在不同测试用例中的执行轨迹。如果你发现 agent 每次都在重复“重新发明”同一段逻辑,例如生成图表、解析某种特定格式、校验输出,那就说明应该把这段逻辑写成一个经过测试的脚本,并放进 scripts/ 关于如何设计和打包脚本,可以进一步阅读在 skills 中使用脚本

下一步

当你已经有了一个可用的 skill 之后,下面两份指南可以帮助你继续打磨它: