你说的 Skill，到底是什么
在开发者语境里，“Skill”更像一个可复用的能力单元：它有清晰的输入输出、稳定的行为边界、可追踪的执行过程，并且能够被更大的工作流（甚至 Agent）组合起来。
你可以把它当成：
- 一段“不会忘”的操作规范（比 Prompt 更稳定）
- 一个“可插拔”的能力模块（可被编排/路由）
- 一套“可回归”的交付物（能测、能观测、能迭代）
Prompt、Skill、Agent：不要混在一起
为了后续系列不绕弯，这里先给出一个开发者可用的区分方式：
- Prompt：一次对话里的指令/上下文组织方式。价值在表达，缺点是复用成本高、行为容易漂移。
- Skill：可复用能力单元。价值在稳定复用，强调契约、护栏、可观测。
- Agent：多步自主执行系统。价值在自动完成复杂任务，需要 planning、tool use、记忆、回滚/人类确认等能力。
这个系列的主角是 Skill，但会逐步讲到 Skill 如何组成 Agent。
什么时候值得把 Prompt 升级成 Skill
用一个简单判断：如果满足下面任意 2 条，就值得做成 Skill：
- 你会重复做（每周/每天都要做）
- 你希望多人复用（团队规范/代码审查/发布流程）
- 结果需要稳定格式（JSON、报告、PR comment、变更清单）
- 过程需要可追踪（为什么这次失败、卡在哪个工具调用）
- 涉及外部系统（GitHub/数据库/CI/工单/Notion/飞书）
Skill 的“工程化定义”：四个关键词
后续每篇文章都会围绕这四个词展开：
- 可复用：有明确入口、默认参数、边界与禁区
- 可组合：可以当子步骤被别的 Skill/工作流调用
- 可测试：有回归集与评分规则，避免“越改越飘”
- 可观测：能回答“这次为什么没跑通/为什么贵/为什么慢”
最小 Skill Checklist（建议贴在你仓库里）
你每做一个 Skill，至少回答这些问题：
- 它的目标用户是谁（开发者/运营/支持/管理者）？
- 输入是什么（字段、格式、必填项、默认值）？
- 输出是什么（结构、单位、允许为空、排序规则）？
- 不做什么（明确拒绝的范围，避免被滥用成“万能助手”）？
- 失败怎么办（重试？降级？需要人类确认？）？
- 需要哪些工具/权限（最小权限原则）？
- 如何衡量好坏（准确率、召回、格式正确率、成本、延迟）？
动手做：把一个 Prompt“产品化”为 Skill 的骨架
假设你现在有一个 Prompt：给 PR 写摘要和风险点。把它升级成 Skill，你可以按下面骨架拆：
- Step 1：定义输入输出契约（下一篇会讲 Schema）
- Step 2：定义工具边界（是否需要 GitHub API？是否允许联网？）
- Step 3：定义稳定格式（比如固定 5 个小节）
- Step 4：定义回归样本（5 个 PR，人工给出理想答案）
先别追求自动化，把“稳定复用”做出来就赢了一半。
常见坑（先避开）
- 把 Skill 写成“超级大 Prompt”：没有边界，越写越长，最后没人敢改。
- 没有输入输出契约：你以为它会输出 JSON，它偏偏输出散文。
- 一上来就做 Agent：多步系统没评测没观测，排查成本指数级上升。
本系列你会得到什么
如果你跟完 12 篇主线，你应该能独立完成：
- 设计一套 Skill 目录与文档规范
- 定义工具调用与权限模型
- 用 MCP/工具协议把 Skill 接入真实系统
- 用 Evals/Tracing 让 Skill 具备“可上线属性”
下一篇：Skill 的输入输出契约：用 Schema 把不确定性关进笼子。