很多人的 Prompt 文件夹，最后都会变成一个很难整理的抽屉。

里面有“写代码用”“总结会议用”“写 SQL 用”“帮我排查 bug 用”。每个文件当初都觉得很有用，几周后再打开，却很难判断它应该在什么时候使用、是否还适配当前项目、运行后又该怎样检查结果。

问题不在于 Prompt 没有价值，而在于它通常只保存了“这句话怎么说”，没有保存“这类工作应该怎样完成”。

当一项任务开始重复出现，我更愿意把它从 Prompt 升级成一个 Skill：它不只是一段说明，而是一份可被 Agent 按需加载、可版本化、可验证的工作方法包。

一、Prompt 和 Skill 的分工

Prompt 适合表达当前任务的目标、边界和输出要求。

Skill 适合沉淀一种反复发生、步骤相对稳定、又容易漏掉关键检查的工作方法。

例如，“帮我发布这篇文章”是任务；“博客技术文章从草稿、敏感信息检查、构建到发布的标准流程”才是一个 Skill 应该负责的事。

所以 Skill 不是把 Prompt 再写长一点。

它应该让 Agent 在遇到同类任务时，少问一遍重复问题，少漏一个已知检查，也少依赖某个模型临场猜对流程。

二、什么工作值得做成 Skill

不是所有事情都应该被打包。一次性的探索或高度依赖现场判断的工作，过早固化反而会制造约束。

我会优先选择同时满足以下条件的任务：

• 经常重复；
• 步骤相对稳定；
• 很容易漏掉关键检查；
• 有明确产物；
• 至少部分结果能被脚本或规则验证；
• 做错后的返工、风险或沟通成本较高。

典型候选包括：Debug、发布、代码评审、架构评审、数据清洗、RAG 评测、数据库迁移和事故复盘。

反过来，如果一项任务每次目标都不同、没有稳定输入输出，或者现在连正确流程都还没摸清，就先保留为任务模板或实验记录，不要急着造 Skill。

三、一个 Skill 至少应包含什么

一个目录比一段长 Prompt 更容易演进：

skills/
└── release/
    ├── SKILL.md          # 什么时候使用、完整步骤、边界
    ├── checklist.md      # 发布前后的快速核对项
    ├── scripts/
    │   └── verify.sh     # 可确定执行的验证
    └── examples/
        └── rollback.md   # 真实或脱敏过的失败案例

其中 SKILL.md 不需要写成百科全书。它应该让 Agent 快速找到四件事：

1. 何时使用，何时不要使用；
2. 输入是什么，最后交付什么；
3. 按什么顺序执行，哪些点必须停下来确认；
4. 怎样验证，失败后怎样恢复。

下面是一份可直接改名复用的最小模板：

---
name: release
description: 在已经确认发布范围、需要构建、验证并交接发布结果时使用。
version: 0.1.0
---

# Objective

将已批准的变更安全发布，并提供可复查的验证证据。

## Trigger conditions

- 使用：用户明确要求发布，且目标环境、变更范围和回滚方式已知。
- 不使用：仍在探索需求、构建失败、包含未确认的数据库迁移或外部付费动作。

## Inputs

- 发布目标与环境
- 变更范围或 commit
- 构建与验证命令
- 回滚入口

## Workflow

1. Inspect：确认工作区、目标环境和未提交变更。
2. Validate：运行构建、测试与敏感信息检查。
3. Review：确认 diff 和影响范围。
4. Approval：外部写入前等待明确确认。
5. Release：执行已批准的发布命令。
6. Verify：检查健康状态、关键页面或接口。
7. Report：交付版本、证据、风险与回滚信息。

## Failure handling

- 构建或测试失败：停止发布，保留现场和错误摘要。
- 健康检查失败：按预先定义的方式回滚或请求人工决策。

## Output contract

- 发布范围
- 已执行命令与结果
- 验证证据
- 未解决风险与回滚入口

四、把确定性工作交给脚本

Skill 最容易变成“另一个更长的说明书”，原因是它试图用自然语言控制所有细节。

凡是机器可以稳定判断的事情，尽量从说明里移到脚本或 CI 中：

#!/usr/bin/env bash
set -euo pipefail

git diff --check
npm run build
npm run test

上面这个脚本不负责决定“要不要发布”。那仍然需要任务契约和审批边界。

它负责的是一个更确定的问题：如果要求发布前构建和测试都通过，就不要让 Agent 靠记性去逐项执行，也不要接受“应该没问题”的口头结论。

一个实用的分工是：

Skill：定义流程、判断点和停下来的条件
Script：执行可重复、可确定的检查
Agent：读取现场、调用工具、处理例外并报告证据
Human：批准风险动作，判断范围与价值取舍

五、用真实失败来改进 Skill

最值得写进 Skill 的内容，往往不是第一次设计时想到的，而是某次真实任务失败后才暴露出来的。

例如，某次发布出现问题，复盘发现原因不是模型不会发布，而是流程缺少“确认当前工作区是否混入无关修改”这一步。那么新增的不是一句“请务必小心”，而是一个可检查动作：

发布前必须执行：

```bash
git status --short
```

若出现与本次任务无关的修改，停止并请求确认；不要擅自暂存、清理或覆盖。

这条规则有明确触发条件、明确动作和明确停止条件，下一次就能真正减少同类风险。

建议为每个成熟 Skill 维护一个很小的变更记录：

## Changelog

- 0.2.0：发布前增加无关修改检查；来源：一次混入本地调试文件的失败。
- 0.1.0：初始发布流程。

这样几年后你仍能回答：为什么这条规则存在，它解决过什么真实问题。

六、三种常见的坏 Skill

1. 触发范围无限大

“所有编程任务都使用这个 Skill”通常意味着它会在不需要的地方占用上下文，还会和局部项目规则冲突。

替代做法：写清适用条件和不适用条件。一个 Skill 宁可窄一点，也不要假装全能。

2. 只规定动作，不规定验证

“修改代码、运行测试、提交结果”仍然太模糊。测试是什么？失败怎么办？提交结果要包含哪些证据？

替代做法：把验证命令、预期结果和失败停止点写出来。

3. 把一次偶发情况升级为永久规则

某次异常不等于一条普遍原则。过度学习会让 Skill 越来越臃肿、越来越难执行。

替代做法：先将它记录为候选规则；只有重复出现，或已被证明可以可靠自动检查时，再合并到正式流程。

七、今天就能做的练习

从你一周内做过至少两次的工作里，挑一件出来。不要一开始就建一个巨大的 Skill Library，只做下面五步：

1. 写下触发条件和不适用条件；
2. 列出最小输入和最终产物；
3. 将流程压缩成不超过七步；
4. 找出一个能交给脚本的确定性检查；
5. 写下一个失败后必须停止并请求确认的条件。

当这个最小 Skill 在三次真实任务中都能减少遗漏，再继续补充例子、脚本和评测。可复用性不是靠目录数量证明的，而是靠它是否真的替你少解释了一次、少返工了一次。

下一篇会讨论另一个更大的问题：Skill 有了，工具也接上了，为什么 Agent 仍可能在出错后无限重试，或者在没有证据时过早宣布完成？答案在于它所处的执行环境，也就是 Harness。

AI 实现摘要

• 要解决的问题：将重复的 Agent 工作从临时 Prompt 沉淀为具有触发条件、流程、脚本、验证和失败处理的可复用 Skill。
• 适用版本与前置条件：适用于支持读取项目文件、调用脚本或工具的 AI Agent；建议使用版本控制保存 Skill 演进历史。
• 输入、输出与验收标准：输入是一类重复任务及其真实失败案例；输出为 SKILL.md、检查表、脚本和示例。验收标准是同类任务能减少遗漏，且每次都能给出明确验证证据。
• 文件改动清单：建议新增 skills/<skill-name>/SKILL.md、scripts/、examples/；按项目结构调整。
• 完整命令：无通用命令。将项目自己的构建、测试、格式化和安全检查写入该 Skill 的脚本或说明。
• 测试步骤与预期结果：在至少三次真实任务中使用该 Skill，检查触发是否准确、流程是否过长、验证是否可执行，以及是否减少已知失败。
• 常见错误、回滚方法与安全边界：Skill 不取代权限系统；外部写入、删除、付费、生产变更和敏感信息仍需要最小权限与人工审批。发现规则造成误报或阻塞时，应通过版本控制回退 Skill 修改。