Appearance
Skill 评估框架
第四部 · Skill · 第41章
撰写日期：2026-07-02
结论
Skill 是 Agent 能力的最小封装单元。它把领域知识、工作流程、工具调用和输出标准打包，让通用 Agent 能稳定完成某类任务。
判断一个 Skill 是否值得保留，不能只看“能不能跑”，而要看：
是否更容易触发、更稳定执行、更少误用、更容易验证。
Skill 生命周期
| 阶段 | 核心问题 |
|---|---|
| 被发现 | Agent 是否知道什么时候该用它 |
| 被执行 | Agent 是否知道具体怎么做 |
| 被验证 | 用户是否能判断结果是否正确 |
| 被维护 | 后续是否容易更新、扩展和调试 |
八个评估维度
| 维度 | 评估问题 | 常见问题 |
|---|---|---|
| 元数据质量 | name 和 description 是否准确 | 描述太泛，触发不稳定 |
| 执行引导 | 步骤是否清楚 | 只有原则，没有操作路径 |
| 领域知识密度 | 是否提供通用模型不知道的信息 | 内容太常识，不值得封装 |
| 工作流完整性 | 是否覆盖端到端流程 | 只写中间步骤，缺少验证 |
| 输入输出清晰度 | 用户给什么，得到什么 | 起点和终点模糊 |
| 资源利用 | 是否合理拆分脚本、模板、参考资料 | 全塞进一个大文档 |
| 写作质量 | 是否结构清晰、可扫读 | 冗余、重复、无优先级 |
| 范围聚焦 | 是否只做好一类任务 | 什么都想做，最后都做不好 |
评分建议
| 等级 | 判断 |
|---|---|
| S | 可直接复用，边界清晰，验证充分 |
| A | 主流程可靠，少量边界可补 |
| B | 能用，但触发、流程或验证存在明显短板 |
| C | 依赖人工解释，复用价值有限 |
| D | 不应沉淀为 Skill，保留为普通 Prompt 即可 |
Skill 写作模板
markdown
---
name: skill-name
description: 一句话说明适用场景；写清什么时候应该触发，必要时写清不适用场景。
---
# Skill 名称
## 适用场景
- 什么时候用
- 什么时候不用
## 输入
| 字段 | 说明 | 是否必需 |
| --- | --- | --- |
## 输出
明确最终交付物格式。
## 工作流
1. 读取输入
2. 判断是否需要追问
3. 执行主流程
4. 验证结果
5. 输出交付物
## 失败处理
| 失败情况 | 处理方式 |
| --- | --- |
## 验证标准
- 标准 1
- 标准 2
- 标准 3常见反模式
| 反模式 | 问题 | 修正 |
|---|---|---|
| description 太宽 | Agent 误触发或不触发 | 写具体任务、关键词和边界 |
| 只写原则 | 执行时仍要模型猜 | 写步骤、输入、输出、失败处理 |
| 过度抽象 | 用户看不出解决什么问题 | 用真实任务定义范围 |
| 资源不拆分 | 加载成本高，维护困难 | 模板、脚本、参考资料分文件 |
| 没有验证 | 做完不知道对不对 | 写成功标准和检查项 |
我的判断
Skill 的价值不在“让 Agent 看起来更懂”，而在降低重复任务的不确定性。
一个好 Skill 应该让三件事更稳定：
- 什么时候该做。
- 怎么把事情做完。
- 如何证明做对了。