Skill彻底讲透：AI Coding时代，技能如何成为大模型能力的真正放大器

如果说 LLM 是大脑，Agent 是手脚，MCP 是工具箱，那么 Skill 就是一本本操作手册——它告诉 Agent 什么时候该用什么工具、怎么组合多个动作完成一个复杂任务。本文把 Skill 从概念到实战彻底讲清楚。

一、一个真实的场景：为什么你的 Agent 总是"半吊子"？

你大概率用过这样的 AI 工具：

• 让它"查一下北京天气"，它能调用天气 API，给出准确结果。
• 让它"帮我用 Python 写个爬虫并运行"，它能生成代码，甚至调用终端执行。
• 但让它"帮我做一份竞品分析报告，先搜 5 家友商的产品信息，整理成表格，再生成 PPT"，它就开始犯迷糊：
• 先搜谁？用什么关键词？
• 信息怎么汇总？表格格式是什么？
• PPT 用什么工具生成？每个页面放什么内容？
• 中间某一步失败了，怎么回退？

问题不在于大模型不够聪明，也不在于 MCP 工具不够多。问题在于：Agent 没有一套明确的"操作流程"来完成这类复合型任务。

这套流程，就是Skill（技能）。

二、什么是 Skill？它和 MCP、Agent 有什么关系？

2.1 Skill 的定义

Skill（技能）是面向特定任务的可复用能力单元。它封装了完成某类任务所需的知识、步骤、参数和判断逻辑。

一个 Skill 通常包含：

2.2 Skill vs MCP vs Agent：别再混淆

这三个词经常一起出现，但定位完全不同：

用一个比喻：

• MCP是电源插座和插头标准——让电器（工具）能接上电网。
• Skill是电饭煲的使用说明书——告诉你按什么顺序加水、加米、选模式。
• Agent是厨师——他看了说明书，动手操作，如果饭没熟再调整。

也就是说：

MCP 提供工具，Skill 编排工具，Agent 执行编排。

三、Skill 为什么是 AI Coding 的必修课？

在 AI Coding 场景下，Skill 的价值尤其明显。原因有三：

3.1 代码任务天然是"多步骤流程"

一个看似简单的开发任务，背后往往包含多个步骤：

需求理解 → 方案设计 → 代码生成 → 依赖安装 → 运行测试 → 错误修复 → 文档更新

如果没有 Skill 来规范这些步骤，Agent 很容易跳过关键步骤——比如生成代码后忘了写测试，或者改了代码后没更新文档。

3.2 每个团队都有自己的"套路"

不同团队写代码的风格不一样：

• 有的团队要求所有接口必须写 Swagger 文档。
• 有的团队要求提交前必须跑black和flake8。
• 有的团队要求新功能必须附带单元测试覆盖率 80% 以上。

这些"套路"可以封装成 Skill。只要告诉 Agent"用我司的标准开发流程 Skill"，它就会自动按团队规范执行。

3.3 复杂任务需要稳定的质量基线

当 Agent 能调用几十个工具时，"怎么调用"比"能不能调用"更重要。Skill 的作用就是把专家经验固化下来，让 AI 每次执行都达到一个可接受的水平。

四、Skill 的常见形态

Skill 并不一定需要复杂的框架。根据场景不同，它可以很薄，也可以很厚。

4.1 最简形态：一个 Prompt 模板

有些 Skill 本质上就是一段写得很清楚的 Prompt。

# 代码审查 Skill 你是一位资深 Python 工程师。请对以下代码进行审查，关注： 1. 是否存在明显的性能问题 2. 是否有安全漏洞（如 SQL 注入、命令注入） 3. 是否遵循 PEP8 规范 4. 是否有更 Pythonic 的写法 请按以下格式输出： - 问题等级：高/中/低 - 问题位置：行号或函数名 - 问题描述 - 修改建议

4.2 中等形态：工具调用链

这类 Skill 不仅包含 Prompt，还定义了要调用哪些工具。

name: 代码库问答 skill: codebase_qa steps: - action: retrieve tool: vector_search input: "{{user_question}}" - action: generate tool: llm_chat prompt: | 基于以下代码片段回答用户问题： {{retrieved_context}} 问题：{{user_question}}

4.3 完整形态：状态机 + 错误处理

复杂 Skill 会包含分支判断、循环、重试和错误恢复。

name: 自动化 Bug 修复 skill: auto_bugfix steps: - action: read_issue tool: github_api input: "{{issue_url}}" - action: search_code tool: codebase_search input: "{{issue_description}}" - action: generate_fix tool: llm_chat condition: "search_results.found" - action: run_tests tool: test_runner retry: 3 on_failure: generate_fix

五、动手实现一个最小 Skill 系统

下面用一个纯 Python 示例，展示一个最简单的 Skill 调度框架。我们定义两个 Skill：

1. 天气查询 Skill：调用天气 API，然后生成穿衣建议。
2. 数学计算 Skill：调用计算器工具，而不是让 LLM 自己算。

import json import re # ====== 模拟 MCP 工具集 ====== def weather_api(city: str) -> str: """模拟天气查询工具""" mock = {"北京": "晴，25-33℃", "上海": "多云，28-34℃", "深圳": "雷阵雨，26-31℃"} return mock.get(city, "未知城市") def calculator(expr: str) -> str: """安全计算器""" if not re.match(r'^[\d\+\-\*\/\.\(\)\s]+$', expr): return "非法表达式" try: return str(eval(expr)) except Exception as e: return f"计算错误: {e}" # 工具注册表 TOOLS = { "weather_api": weather_api, "calculator": calculator } # ====== Skill 定义 ====== SKILLS = { "weather_advice": { "description": "查询城市天气并给出穿衣建议", "trigger": "用户询问某城市天气或穿衣建议", "steps": [ {"tool": "weather_api", "input_param": "city"}, {"llm": "根据天气 {{last_result}} 给出 20 字以内的穿衣建议"} ] }, "math_calc": { "description": "计算数学表达式", "trigger": "用户要求计算数学表达式", "steps": [ {"tool": "calculator", "input_param": "expression"} ] } } # ====== Skill 执行器 ====== class SkillExecutor: def __init__(self, llm_call): self.llm_call = llm_call def run(self, skill_name: str, params: dict) -> str: skill = SKILLS.get(skill_name) if not skill: return f"未知 Skill: {skill_name}" last_result = "" for step in skill["steps"]: if "tool" in step: tool_fn = TOOLS[step["tool"]] input_key = step["input_param"] last_result = tool_fn(params.get(input_key, "")) elif "llm" in step: prompt = step["llm"].replace("{{last_result}}", last_result) last_result = self.llm_call(prompt) return last_result # ====== 模拟 LLM ====== def mock_llm(prompt: str) -> str: if "天气" in prompt: return "天气炎热，建议穿短袖，注意防晒。" return "收到" # ====== 运行示例 ====== executor = SkillExecutor(mock_llm) print(executor.run("weather_advice", {"city": "北京"})) # 输出：天气炎热，建议穿短袖，注意防晒。 print(executor.run("math_calc", {"expression": "2 * (3 + 5)"})) # 输出：16

这个例子展示了 Skill 的核心思想：

1. Skill 是任务流程的封装：不是直接调用工具，而是按预定义步骤执行。
2. Skill 可以组合 LLM 和工具：先拿数据，再生成回复。
3. Skill 让能力可复用：同样的天气 Skill 可以被多个 Agent 调用。

六、Skill 在真实框架中的形态

上面的示例是为了理解原理。在实际项目中，Skill 通常以更规范的形式存在。

6.1 OpenAI 的 Function Calling

OpenAI 的 Function Calling 可以看作是最早期的"Skill 雏形"。开发者定义函数签名和描述，模型自己决定调用哪个函数。

tools = [ { "type": "function", "function": { "name": "get_weather", "description": "获取指定城市的天气", "parameters": { "type": "object", "properties": { "city": {"type": "string", "description": "城市名"} }, "required": ["city"] } } } ]

这里的每个 function 定义，就是一个极简 Skill 的接口声明。

6.2 LangChain 的 Tools 和 Agents

LangChain 把工具封装和 Agent 调度结合得很紧密。你可以用@tool装饰器定义工具，然后交给 Agent 选择：

from langchain.tools import tool from langchain.agents import initialize_agent @tool def get_weather(city: str) -> str: """获取城市天气""" return f"{city}今天晴天，25℃" agent = initialize_agent([get_weather], llm, agent="zero-shot-react-description") agent.run("北京天气怎么样？")

在 LangChain 里，"Tool 描述 + 执行函数" 就是 Skill 的底层形态。

6.3 WorkBuddy 的 Skill 系统

WorkBuddy 的 Skill 是更完整的封装。每个 Skill 是一个独立目录，包含：

skill-xxx/ ├── SKILL.md # 技能说明：触发条件、参数、输出格式 ├── scripts/ # 执行脚本 ├── references/ # 参考资料 └── assets/ # 图片等资源

当 WorkBuddy 检测到用户任务匹配某个 Skill 时，会自动加载该 Skill 的说明，并按其流程执行。比如：

• csdn-auto-publishSkill：自动发布文章到 CSDN。
• minimax-docxSkill：生成专业 Word 文档。
• humanizerSkill：去除文本中的 AI 味。

每个 Skill 都是一个小型专家系统，可以独立完成一类任务。

6.4 Anthropic 的 Claude Computer Use

Claude 的 Computer Use 能力把 Skill 推进到了 GUI 自动化层面。它允许 Agent 控制鼠标、键盘、截图，直接操作计算机界面。这本身也是一种 Skill：

Skill: 操作浏览器 - 打开 Chrome - 访问指定 URL - 截图 - 点击元素 - 填写表单

七、如何设计一个好的 Skill？

Skill 不是把 Prompt 写长一点那么简单。一个高质量的 Skill 需要满足几个条件。

7.1 边界清晰

一个 Skill 只解决一个明确的问题。不要把"写代码 + 测代码 + 发邮件汇报"全部塞进一个 Skill，而是拆成三个：

• write_code：写代码
• run_tests：跑测试
• send_report：发邮件

这样 Skill 更容易维护、复用和组合。

7.2 输入输出明确

每个 Skill 都应该像函数一样定义清晰的输入和输出。

input: city: string # 城市名 output: weather: string # 天气描述 advice: string # 穿衣建议

7.3 工具描述精确

如果 Skill 内部调用工具，每个工具的描述必须让 LLM 知道：

• 这个工具是干嘛的
• 参数是什么
• 返回值是什么
• 什么时候不该用

7.4 容错设计

Skill 必须有失败处理路径。比如：

steps: - tool: search on_failure: fallback_to_llm - tool: generate retry: 3

7.5 版本管理

Skill 是会迭代的。建议每个 Skill 都有版本号，并且记录变更历史。这样当 Agent 行为变化时，可以追溯到具体是哪个 Skill 的更新导致的。

八、Skill 在 AI Coding 中的典型应用场景

8.1 代码生成 Skill

name: generate_api_endpoint steps: - read: 项目路由规范和模型定义 - generate: 根据规范生成 CRUD 接口代码 - check: 运行类型检查 - fix: 如果类型检查失败，自动修复

8.2 代码审查 Skill

name: code_review steps: - analyze: 读取 PR 变更文件 - check: 检查安全、性能、规范 - comment: 在 PR 中留下审查意见

8.3 文档生成 Skill

name: generate_docs steps: - parse: 读取代码中的函数和类 - extract: 提取注释和签名 - write: 生成 Markdown 文档 - update: 更新到 docs 目录

8.4 自动化测试 Skill

name: auto_test steps: - read: 读取新功能代码 - plan: 制定测试用例 - generate: 生成测试代码 - run: 执行测试 - report: 输出覆盖率报告

九、Skill 的进阶：Skill 之间的组合

真正强大的 AI 系统不是单个 Skill 强，而是多个 Skill 能组合成更复杂的流程。

比如"开发新功能"这个高级任务，可以分解为：

需求分析 Skill → 方案设计 Skill → 代码生成 Skill → 测试生成 Skill → 代码审查 Skill → 文档生成 Skill

这种组合有两种方式：

9.1 线性组合

按固定顺序执行。适合流程明确、步骤稳定的任务。

9.2 动态组合

由 Agent 根据任务类型决定调用哪些 Skill。比如：

• 如果是 Bug 修复，调用bug_reproduce→code_fix→test_regeneration
• 如果是新功能，调用requirement_analysis→code_generate→doc_generate

动态组合更灵活，但也对 Agent 的规划能力要求更高。

十、Skill 与 Prompt Engineering 的关系

Skill 和 Prompt Engineering 不是替代关系，而是互补关系。

换句话说：

Prompt Engineering 让 LLM 回答得更好；Skill 让 Agent 做事更稳。

十一、Skill 设计的常见坑

坑 1：Skill 过于庞大

一个 Skill 试图解决所有问题，结果变得臃肿、难维护。建议拆小，通过组合解决复杂问题。

坑 2：工具描述含糊

LLM 因为工具描述不清而调用错误。比如把"搜索代码"和"搜索文档"两个工具描述得太像，Agent 经常选错。

坑 3：没有处理失败路径

假设所有工具调用都会成功。现实中网络超时、API 报错、返回格式异常都是常态。Skill 必须有 fallback。

坑 4：忽略输入校验

用户输入可能缺字段、格式不对。Skill 应该在入口就做校验，而不是等工具调用失败再处理。

坑 5：版本混乱

多个 Agent 共用同一个 Skill，改了 Skill 后不知道谁受影响。建议用版本号管理，并让 Agent 明确指定使用哪个版本。

十二、总结

Skill 是 AI Coding 时代的一个关键抽象。它不像 LLM 那样直接生成内容，也不像 MCP 那样提供底层工具，而是把任务流程封装成可复用、可组合、可维护的能力单元。

核心要点回顾：

1. Skill 是任务流程的封装，定义了完成某类任务的步骤、工具、输入输出和错误处理。
2. MCP 提供工具，Skill 编排工具，Agent 执行编排。三者缺一不可。
3. Skill 让 AI 能力从"能用"变成"稳定可用"，是复杂任务质量的关键保障。
4. 好的 Skill 边界清晰、输入输出明确、工具描述精确、有容错设计、可版本管理。
5. Skill 可以组合，多个 Skill 协同能完成更复杂的端到端任务。

如果你已经理解了 MCP、Agent 和 RAG，那么下一个最值得深入的概念就是Skill。它可能是决定你的 AI 项目能不能真正落地、能不能稳定交付的核心因素。

参考阅读：LangChain Tools 文档，OpenAI Function Calling 文档，WorkBuddy Skill 开发指南。