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 如何工作,或者数据库迁移是什么。
对于每一段内容,都问自己一句:“如果没有这条说明,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 可以说明应该关注什么,而不必规定死板步骤:
当操作比较脆弱、一致性非常重要,或者必须严格遵循某个顺序时,就应该更强约束
大多数 skills 实际上都会混合这两种情况。你应当针对不同部分分别校准。

给默认方案,不要给菜单

当有多种工具或方案都能完成任务时,应该选出一个默认方案,再简要提一下替代选项,而不是把它们平铺成完全等价的菜单。

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

一个 skill 应该教给 agent 一类问题应该怎么处理,而不是针对某个具体实例直接告诉它要产出什么。对比如下:
这并不意味着 skills 不能包含具体细节。输出格式模板(见输出格式模板)、像“绝不要输出 PII”这样的约束,以及工具特定说明,依然都很有价值。重点在于:即便包含了具体细节,整体方法仍然应该是可泛化的。

高效说明的常见模式

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

Gotchas 小节

很多 skills 中最有价值的内容,恰恰是一份 gotchas 列表,也就是那些违背常识预期的环境特定事实。它们不是“妥善处理错误”这种泛泛建议,而是一些如果不提前告诉 agent,它就很可能会犯的具体错误修正:
对于 gotchas,最好直接放在 SKILL.md 里,这样 agent 会在真正遇到问题前先读到它们。如果你能明确告诉 agent 何时加载,那么独立参考文件也可以;但对于那些不明显的问题,agent 可能根本意识不到触发时机。
当 agent 犯了一个需要你手动纠正的错误时,就把这条纠正补进 gotchas 小节。这是迭代提升 skill 的最直接办法之一(见用真实执行结果持续打磨)。

输出格式模板

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

多步骤工作流的检查清单

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

校验闭环

应该明确要求 agent 在进入下一步之前先校验自己的工作。典型模式是:先完成任务,再运行一个校验器(脚本、参考清单或自检步骤),修复发现的问题,然后重复,直到校验通过。
一份参考文档也可以充当“校验器”角色。你可以要求 agent 在最终提交前,把自己的结果与参考文档逐项核对。

先规划、再校验、后执行

对于批处理操作或破坏性操作,应先让 agent 以结构化格式产出一个中间计划,再把计划和可信来源进行校验,确认无误后再执行。
关键在第 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 之后,下面两份指南可以帮助你继续打磨它: