课程导论：为什么用 Skill 实现工作流

过去两年，AI 编程助手已经从"帮你补全一行代码"进化到"能理解整个项目、规划多步骤修改、调用工具链完成端到端任务"的 Agent 形态。Claude Code、Cursor、GitHub Copilot、Gemini CLI、Qoder 等工具相继推出了各自的 Agent 模式：你抛给它们一个自然语言目标，Agent 会自己分析代码库、制定计划、执行命令、验证结果。

这种能力飞跃带来了一个新问题：Agent 很强大，但它并不总知道"你的团队希望这件事怎么做"。

举个例子。你让 Agent"帮我生成这个 API 的文档"，它可能会：

• 直接调用某个通用模板，产出一份格式尚可但不符合你们团队规范的文档；
• 漏掉你们内部要求的"错误码表格"和"鉴权说明"；
• 把参数命名写成驼峰式，而你们团队统一使用 snake_case；
• 在没有确认受众的情况下，把面向后端工程师的接口文档写成了产品经理也能看懂的通俗版。

这些问题的根源不是模型不够聪明，而是上下文缺失：Agent 没有加载你们团队的约定、流程、检查清单和输出模板。每次任务都要把这些信息重新口述一遍，既低效又不稳定。

这就是 Skill（技能）出现的背景。

Skill 是一套开放的、可移植的、版本可控的指令包。它把"某类任务应该怎么做"写成一份SKILL.md文件， optionally 配上参考文档、模板、脚本，存放在项目目录或团队共享库里。当 Agent 识别到任务匹配时，会自动加载对应 Skill，从而获得完成任务所需的领域知识和流程约束。