AI Agent 的能力并不只取决于模型本身。很多时候，真正决定可用性的，是围绕任务沉淀出来的 Skill：它把常见流程、边界条件、工具约定和验证方式写清楚，让 Agent 不必每次都从零开始猜。

这篇文章整理一些通用的 Skill 编写建议，适合用于自动化运维、文档处理、代码生成、信息检索等场景。

1. 先定义适用范围

一个好 Skill 首先要说明“什么时候用它”，也要说明“什么时候不要用它”。

建议包含三类信息：

  • 触发条件：用户说什么、任务有什么特征时应该使用；
  • 排除条件：哪些看似相关但不应该使用；
  • 预期产出：最终应该交付什么形式的结果。

如果范围太泛，Agent 会在不合适的时候套用流程；如果范围太窄，Skill 又很难被触发。

2. 把流程写成可执行步骤

Skill 不是说明书越长越好，而是要让 Agent 能按步骤行动。可以把流程写成：

  1. 收集输入；
  2. 检查前置条件；
  3. 执行核心操作；
  4. 验证结果；
  5. 汇报变更和风险。

每一步最好都有明确的判断标准。例如“验证结果”不要只写“检查是否成功”，而应该写“运行测试命令”“确认 HTTP 状态码”“比较生成文件数量”等。

3. 明确危险操作边界

Agent 经常会操作文件、配置、服务和外部接口。Skill 里应该把危险动作写清楚：

  • 删除、覆盖、发布、发消息、改权限前是否需要确认；
  • 是否必须备份；
  • 失败后如何回滚；
  • 哪些命令不能自动执行。

这类约束不是为了降低效率，而是为了让自动化长期可信。

4. 偏向小而稳定的工具约定

如果一个任务依赖外部工具，Skill 应该规定稳定的调用方式。例如：

  • 优先使用只读命令做探测；
  • 长任务后台运行；
  • 避免高频轮询；
  • API 写操作合并批量执行；
  • 输出只保留关键日志。

工具约定越具体，Agent 越不容易在细节上漂移。

5. 写清楚失败路径

很多 Skill 只描述成功路径，遇到异常时 Agent 只能临场发挥。更稳的写法是列出常见失败：

  • 权限不足；
  • 网络超时；
  • 依赖版本不兼容；
  • 文件不存在；
  • 返回内容为空；
  • 第三方 API 限流。

每种失败都给出下一步动作：重试、换源、降级、询问用户，或者停止并报告。

6. 要求可验证的完成标准

Skill 最后应该定义“什么叫完成”。例如：

  • 代码任务：测试通过，或说明为什么无法测试；
  • 部署任务：新版本可访问，旧版本可回滚；
  • 文档任务：目标文件已更新，并给出路径；
  • 检索任务：列出来源和时间。

没有完成标准，Agent 容易停在“看起来做了”的状态。

7. 保持 Skill 可维护

Skill 也会过期。建议把易变信息和通用流程分开：

  • 通用流程写在 Skill；
  • 本地路径、账号、主机名、偏好写在环境笔记；
  • 踩坑记录及时补充；
  • 过时命令及时删除。

这样 Skill 才能从一次性提示词，变成真正可复用的工程资产。

结语

好的 Skill 不追求复杂，而追求清晰、稳定、可验证。它应该像一个经验丰富的人留下的操作手册：知道什么时候出手，知道怎么检查，也知道什么时候停下来。

当 Agent 的任务越来越多，Skill 的价值会越来越明显。它让经验不只停留在一次对话里，而是变成可以重复使用的能力。