告别“一次性Prompt”：当AI学会“手艺活”，Skill才是智能体的终极进化

从"会聊天"到"会干活"，中间只差一个Skill的距离

你有没有这样的经历------每次让AI帮你写PRD，都要重复描述一遍需求格式？每次处理Excel，都要重新告诉AI"按公司第四季度的规划逻辑来分析"？每次生成PPT，都要手动调整排版和配色？

恭喜你，正在经历"AI对话疲劳症"。

一个尴尬的现实：AI很聪明，但记不住

2025年，大语言模型早已不是新鲜事。Claude、GPT、Gemini轮番上阵，谁家都能写出像模像样的情书和代码。但当我们真正想把AI融入工作流时，问题来了：

它太"健忘"了。

今天你跟AI说"帮我写一个PRD，要包含用户故事、功能清单、技术架构、排期表"，它写得很漂亮。明天你再找它，同样的需求，它给你一版完全不一样的结构。后天团队其他人来找它，又是一版。每次都要从头开始"调教"------这跟雇了个每天失忆的天才员工有什么区别？

更麻烦的是，当任务变得复杂------比如"分析这份销售数据，按我们公司的毛利率口径计算，再对比去年同期，最后生成一份面向董事会的汇报PPT"------你需要的不是一次对话，而是一整套可复用的专业流程。

MCP解决了"能做什么"，但没回答"怎么做得好"

如果你关注AI Agent领域，一定听说过MCP（Model Context Protocol）。作为Anthropic推出的开放标准，MCP确实解决了一个核心痛点：让AI连接外部世界。

通过MCP，AI可以：

• 读取本地文件（用@resource）
• 调用API接口（用@tool）
• 使用预定义的Prompt模板（用@Prompt）

这很棒。MCP就像给AI装上了"手"------它能拿工具了，能读数据库了，能发HTTP请求了。

但问题是，有了手，不等于会干活。

想象一下：你给一个学徒全套木工工具，告诉他"做个椅子"。他能做出来吗？也许能，但大概率歪歪扭扭。你需要的是一套标准工艺------先锯什么尺寸，再刨哪个面，榫卯怎么开，打磨到多少目。

这就是MCP和Skill的本质区别：

• MCP：提供工具和能力 ------ "我能做什么"
• Skill：提供专业流程和最佳实践 ------ "这件事怎么做才专业"

Skill到底是什么？一个AI的"手艺包"

如果说MCP是AI的"工具箱"，那Skill就是AI的"手艺活"。

Skill = Instructions（指令） + Scripts（脚本） + Resources（资源）

拆开来看：

• Instructions：告诉AI"这件事应该按什么步骤做"，相当于SOP（标准作业程序）
• Scripts：可执行的代码，让AI真正动手操作
• Resources：参考材料，比如设计规范、模板文件、品牌色板

以一个ppt-expert Skill为例：

ppt-expert/
├── SKILL.md          # 核心指令：告诉AI怎么一步步生成专业PPT
├── scripts/
│   ├── extract.py    # 从数据中提取图表
│   └── format.js     # 按公司模板格式化排版
└── resources/
    ├── template.pptx  # 公司标准模板
    └── brand-guide.md # 配色、字体、Logo规范

当你对AI说"帮我生成Q3业务汇报PPT"，它不再是从零开始瞎编，而是：

1. 读取SKILL.md，知道"哦，要先提取数据→生成图表→套用模板→润色文案"
2. 调用scripts/里的代码自动处理数据
3. 引用resources/里的模板和品牌规范
4. 输出一份专业、标准、可预期的PPT

每一次使用，都是对最佳实践的复用。

为什么Skill会火？因为它解决了Prompt的"三宗罪"

回顾过去两年，我们使用Prompt的方式其实很原始：

问题	表现	后果
一次性	每次对话都要重新描述上下文	浪费大量token和口舌
不稳定	同样的需求，不同时间得到不同结果	无法在生产环境中依赖
不可复用	个人经验无法传递给团队	AI能力被锁死在个体对话里

Skill的横空出世，恰恰是对这"三宗罪"的精准打击：

✅ 可复用 ------ 一次写好SKILL.md，团队上百人都能用，AI不再"失忆"

✅ 标准化 ------ 所有人用同一个Skill，输出质量一致，告别"看运气"

✅ 可组合 ------ 多个Skill可以串联成Agent工作流，比如data-analyzer + ppt-expert + email-sender = 自动数据分析汇报机器人

✅ 低成本 ------ 不需要像MCP那样搭建服务器端，一个文件夹+一个SKILL.md就能开工

Skill + MCP：这才是完整的AI Agent

很多人把Skill和MCP对立起来看，其实它们天生是搭档。

想象一个真实场景：

用户："分析这份Excel，按公司第四季度毛利率口径，生成一份CEO汇报PPT。"

MCP登场 ：通过@tool读取Excel文件，通过@resource拉取数据库里的历史数据。

Skill登场：

• 调用data-analyst Skill：按公司标准做数据清洗、毛利率计算、同比分析
• 调用ppt-expert Skill：按董事会汇报格式生成PPT，自动配色、排版、加注释
• 调用executive-summary Skill：提炼核心洞察，写出"一句话说清"的摘要

MCP负责"伸手够到东西"，Skill负责"用专业的方式处理东西"。

没有MCP，AI是"有手艺没材料"；没有Skill，AI是"有工具没章法"。两者结合，才是真正意义上的AI Agent------一个能独立完成复杂任务的数字员工。

从"对话"到"协作"：Skill改变了人机关系

Skill的出现，让我想起一个有趣的类比：

Prompt 就像跟实习生说"去做个方案"------每次都要从头交代背景、格式、预期。 Skill 就像给团队发了一本《SOP手册》------"按第三章的流程做就行。"

前者是"对话"，后者是"协作"。

更妙的是，Skill的"渐进式加载"设计（Progressive Loading）------当Skill比较复杂时，SKILL.md只加载核心骨架，具体细节按需从子模块读取。这大大节省了Token，让AI可以处理更复杂的任务而不撑爆上下文窗口。

想象一下这种场景：

# SKILL.md（头部）

---
name: software-architect
description: 企业级软件架构设计专家，支持微服务、DDD、云原生
---

## 核心能力
- 需求分析与领域建模 → [加载 domain-modeling.md]
- 架构选型与决策 → [加载 architecture-decision.md]
- 技术栈推荐 → [加载 tech-stack.md]
- 部署与运维规划 → [加载 devops-planning.md]

AI一开始只读取核心指令，当判断需要"领域建模"时，才加载对应的子模块。省Token、提速度、更聚焦。

小龙虾、Manus与"智能体的Windows时代"

最近开源社区有个很有意思的项目------小龙虾（Xiaolongxia），自称"Manus的开源版本+智能体管家OPC的实例"。

Manus作为通用AI Agent，一度让外界惊呼"AGI要来了"。但仔细看，它的本质是什么？一个能调度多个Skill的智能体操作系统。

而小龙虾的出现，意味着这种能力正在民主化------你可以像安装App一样安装各种Skill，让AI自动完成从"数据分析"到"PPT生成"到"邮件发送"的全流程。

有人把这一刻比作"智能体的Windows时代"------不再需要写代码，不再需要调Prompt，你只需要告诉AI"我要做什么"，它自己知道该调用哪个Skill、按什么流程做。

而Skill，就是这个操作系统里的".exe"可执行文件。

实战：我如何用一个Skill让团队效率翻倍

说点实际的。

我们团队之前有一个痛点：每次写产品需求文档（PRD），产品经理、设计师、工程师各写各的，格式五花八门，评审会上吵成一锅粥。

我花了半天时间，写了一个prd-writer Skill：

---
name: prd-writer
description: 按公司标准格式生成产品需求文档
---

## 工作流程
1. **需求收集**：与用户确认功能清单和优先级
2. **用户故事**：按"作为...我想要...以便..."格式撰写
3. **功能详述**：每个功能包含输入、处理逻辑、输出、异常处理
4. **技术架构**：推荐技术选型并说明理由
5. **排期估算**：按团队历史速度给出工期参考
6. **验收标准**：定义明确的AC（Acceptance Criteria）

## 输出格式
- 使用Markdown，一级标题为"# PRD - [项目名]"
- 每个功能模块用"## 模块名"分隔
- 验收标准用"- [ ]"清单格式
- 自动添加版本号和修订记录表

## 参考模板
[加载 resources/prd-template.md]

从那以后，团队所有人对AI说"写个PRD"，得到的永远是同一套结构、同一套标准。评审会从"这写的什么鬼"变成了"嗯，符合规范，直接过"。

效率提升50%，扯皮减少80%。

更妙的是，我还写了一个配套的prd-reviewer Skill，专门用来评审PRD是否完整。两个Skill配合使用，形成了一条自动化产线。

尾声：AI不会取代你，但会用Skill的人会

有人说AI会取代很多工作，我不这么认为。

AI不会取代你，但会用AI的人会。 而会用AI的人，正在用Skill把经验固化成可复用的资产。

今天，你花两小时写一个customer-support Skill，未来一年里，每次客户提问，AI都用你最专业的方式去回答。

今天，你花半天写一个data-report Skill，从此每周的数据周报自动生成，你只需要点"发送"。

Skill的本质，是把人的专业经验，变成AI的肌肉记忆。

它还处于早期------Skill的生态还在建设，标准的SKILL.md格式还在演进，MCP和Skill的整合还在磨合。但趋势已经很明显了：

未来的AI，不只看"会不会聊天"，更看"会不会干活"。

而干活，靠的是Skill。