# 把Claude中的Projects、Skills、Connectors、Plugins、LLM，一个案例搞懂

[![用Claude搭建工作邮箱 AI 助理一个真实案例，把 Projects、Skills、Connectors、Plugins 和大模型的分工一次性搞明白](https://img.youtube.com/vi/5eWvHtydBL4/maxresdefault.jpg)](https://www.youtube.com/watch?v=5eWvHtydBL4)
*▲ 点击上方图片无缝跳转观看完整视频*

大家都在说 AI「长出了手和脚」——不再只是聊天，而是能真正动手干活了。但你如果没用过，可能不太清楚这个「动手干活」到底是怎么体现的。

说实话，我一开始也没概念。直到我在 Claude 上搭了一个「工作邮箱 AI 助理」，亲眼看着它自己搜邮件、读内容、判断优先级，最后还生成了一张排版精美的汇总图——我才真正理解了那句话的意思。

今天我们通过这个案例，来拆解 Claude 是怎么做到的。以及在这个过程中，Claude 这个产品涉及的核心架构——Projects、Skills、Connectors、Plugins、大模型，它们到底是怎么协同工作的。

### 先给一个总览，有一个整体印象

大模型是大脑，负责「想」——理解用户输入指令的含义、进行推理、生成内容。

Connectors 是手脚，负责「做」——和外部工具对接（如：gmail），查邮件、发邮件。

Skills 是专业指导手册——告诉大模型做某件事的专业方法，不用每次从零摸索。

Plugins 是把手脚和专业指导手册打包好的完整功能体——装上就能干活。

Projects 则是整个AI助理所处的「工作室」——它有独立的聊天记录、知识库和自定义指令，当你换一个 Chat 也不用重新自我介绍、重新贴文件。

### 案例实解

下面我们通过 Claude 搭邮件助理的全过程，一个环节一个环节地拆开看。

曾经我工作邮箱在 Gmail 上，每天会收到很多封邮件。客户的、同事的、系统通知的、营销邮件，什么类型都有。

以前没有 AI 的时候，我得每天固定抽一小时来看邮件。先扫一遍标题，判断哪些该回、哪些可以忽略。遇到客户问了一个需要查资料才能答的问题，光一封邮件就得花十几分钟——先查找资料、再组织下语言，最后才敢点发送。

我一直觉得这件事应该能被自动化。不是那种「设个规则自动归档」的简单自动化——那个不够，因为每封邮件的处理逻辑不一样。我想要的是那种「能理解邮件内容，并且还能帮我回复」的工具。有了 AI 后，这个事儿才变得可能。

### 下面我用 claude\.ai 网页版来演示整个过程

我建了一个 Projects，名字叫「work」。在这个Projects 里，我添加了 Gmail Connector——让AI能使用我的邮件。又装了一个叫 canvas\-design 的 Skill——让我最终拿到的不是一堆文字，而是一张排版精美的图片。

准备好之后，我跟它说了一句话：“/canvas\-design 把我的谷歌邮箱的邮件按发件人分类汇总，提示我要关注的事情，把结果发个png图片给我。”

大概三分钟之后，它把活干完了。我打开图，邮件按发件人汇总，并且需要关注的事重点标记。

我当时的感觉着实有点震惊，AI助理确实真把活干了。

但更让我好奇的是：就这一句话背后，到底发生了什么？我建 Projects、添加 Connector、添加 Skill 这些操作，到底 Claude 做了哪些工作？

后来我把这五个概念彻底拆了一遍，发现它们的分工特别清晰。

### 大模型

先说大模型（比如：案例中用到的sonnet 4\.6），这是整套系统的核心——「大脑」。

大模型负责的事情只有一件：理解自然语言、再进行推理。它读你输入的话，解析出你真正想要什么；它自己规划出执行顺序（先干嘛、再干嘛、最后干嘛）；最终生成自然语言回复用户。

大模型干的全是「思考」的活。它不会发 HTTP 请求去调 Gmail 的 API，不会自己启动一个进程跑 Connector，也不会把生成的图片渲染出来——这些都不是大脑干的活。

那这些「执行」的活是谁在干？案例中的：Claude\.ai 这个 Web 端产品。

在上述案例中，我们用到了 Claude\.ai 的 4 样东西：Projects（特定聊天中预先加载的背景知识）、Skills（针对不同工作的技能手册）、Connectors（通过MCP将Claude和外部工具连接起来）、大模型（指挥干活的大脑）。

大模型产出的是「我要调查看Gmail邮箱的工具」。真正把这个调用发出去、等 Gmail 返回结果、把结果交还给大模型继续推理的——是 Claude\.ai 的 Connectors。

### Connectors

接着就说到 Connectors。它是这套系统的「手脚」——负责伸出去触碰外部世界。

我那个邮件案例里，Gmail Connector 的工作是这样的：大模型决定要搜索邮件，claude\.ai 的 MCP Client 把这个意图打包成一个标准格式的请求，发给 Gmail Connector。Gmail Connector 收到之后，把它翻译成 Gmail 真正的 API 调用，拿到 Gmail 返回的数据，再精简回标准格式，交还给大模型。

这里有个关键概念叫 MCP（Model Context Protocol）。它让所有 Connector 讲同一种语言。不管是 Gmail、Slack、Notion 还是 Jira，只要实现了 MCP 协议，大模型这边就用同一套方式跟它们对话。这意味着什么？任何第三方服务都能接入 Claude——不用 Anthropic 一家一家去做连接器，而是任何人都能做。这样大大提高了大模型公司和第三方公司的开发效率，让用户在Claude\.ai上能执行的任务越来越多和方便。

所以 Connector 做的事情很单纯：它不管这封邮件重不重要、需不需要回复——那是大脑的事。它只管「你要搜邮件？我去 Gmail 拿。你要发回复？我帮你发出去。」

### Skills

再说 Skills。它是最容易被误解成「功能列表」的东西，但其实它是「专家手册」。

什么意思呢？你刚进入一家公司，刚开始不了解岗位具体工作职责，通过这个专家手册，你马上就能上手干活了。

Skills 干的就是这事。每个 Skill 本质上是一个 SKILL\.md 文件，沉淀了针对某个特定任务的最佳实践和操作规范。比如官方有个叫「pptx」的 Skill，它包含了做 PowerPoint 的所有经验和规范——用什么字体、怎么排版、怎么配色，不需要大模型凭感觉乱来，直接调用这套专家手册就行。

在我那个邮件案例的尾声，大模型判断我要的是视觉化输出，于是触发了 canvas\-design 这个 Skill。Skill 文件被加载进大模型的上下文，它按照里面写的操作规范——先构思设计哲学，再生成视觉代码，再二次精炼调整——最终产出了一张排版精美的邮件分类汇总图。

Skills 有一个很聪明的设计：它不是常驻在大模型脑子里的。每个 Skill 的「名字和简介」只占几十个 token，会在对话启动时就注册进系统消息——让大脑知道「我有这个技能」。但 Skill 的完整操作指南可能上千个 token，只有在大脑判断「这个技能用得上」的时候才会加载进来。

这就好比你的大脑里存着一个索引：「我会骑车、会游泳、会弹吉他」。但「弹吉他的详细指法」不会时刻占用你的注意力——只有在你拿起吉他的时候，专家手册才被激活。

### Plugins

最后说 Plugins。它的角色最简单：就是把大脑、手脚和专家手册打包在一起，做成一个完整的功能体。

就像一个完整的人，有大脑（模型）、有手脚（Connectors）、有专家手册（Skills），三者缺一不可，而且互相配合。Plugin 做的就是把某个工作场景需要的所有「身体部件」打包好——你安装一个 Productivity 插件，等于一次性获得了 Slack 的手脚、Google Calendar 的手脚、任务管理类的专家手册，以及大脑驱动这些部件的能力。

你不需要手动去调用任何东西。你说「帮我梳理一下今天的待办事项」，大模型识别到意图，自动加载任务管理的专家手册，自动换起 Google Calendar 的手脚去查会议，然后按优先级整理好——整个过程就像你自己操作一样自然。

### Projects

那 Projects 呢？在 claude\.ai 网页版里，它是整套系统所处的「工作室」。

你在 claude\.ai 上创建一个 Projects，它会拥有自己的聊天历史、知识库和自定义指令。关键是——你在一个 Project 的「Instructions」里写的东西，以及上传到「Files」里的文件，这个 Project 下的所有 Chat 都能共享。

什么意思？你在一个 Project 的「自定义指令」里写了「客户王总的邮件优先级最高，回复风格简洁直接」，以后在这个 Project 下开任何一个新 Chat，Claude 自动就带着这条规则。它不是存在某一段对话历史里——那段对话关了这条规则就没了。它是挂在这个 Project 上的，所有 Chat 共享。

你上传到 Project 里的参考文件也是同理。这些文件加起来可以远超 20 万 token——但 Claude 不是每次对话都把它们全塞进脑子的。claude\.ai 有一个自动机制叫 RAG（检索增强生成）：当你的知识库内容接近上下文窗口上限时，Claude 会自动切换模式，用一个内置的搜索工具从知识库里捞出跟当前问题最相关的片段，只把这几段放进上下文。剩下的不相关文件安安静静待在知识库里，用到的时候再检索。

所以 Projects 解决的不是「单次对话能装多少信息」——那是上下文窗口 20 万 token 的事儿。Projects 解决的是「换一段新对话，我不用重新自我介绍、重新贴文件、重新说偏好」——它是跨对话的共享记忆。

这个过程完全自动。你不需要配置任何东西，上传文件、写好自定义指令，Claude 自己判断什么时候该全量加载、什么时候切到 RAG 检索。

### 总结

坦白说，这套架构也不是零门槛。

第一个困难是理解成本。大模型、claude\.ai 平台、Projects、Skills、Connectors、Plugins——六个概念，要一下子理清楚确实要花点时间。我第一次接触的时候，Connectors 和 Plugins 的区别就让我晕了好一阵。

第二个困难是生态还在早期。目前可用的手脚覆盖了主流办公工具——Slack、Notion、Gmail、Google Calendar、Jira 等——但离「什么都能接」还有距离。这需要整个生态都繁荣丰富起来，不是一家公司能完成的事情。

第三个困难是这套系统有多好用，很大程度上取决于大脑有多强。大模型越强，理解意图越准、拆解任务越合理、生成内容质量越高。如果用早期模型，效果会有可感知的差距。

但从方向上说，我觉得这条路是对的。

一个很本质的变化是：过去我们操作软件，是我们去适应软件的菜单和按钮——你得知道某个功能在哪、怎么点。当功能越来越多的时候，菜单就覆盖不了所有使用场景了。而当你的交互界面就是对话本身、你的身体有一整套手脚和专家手册的时候——你说「把上周的会议纪要从 Notion 找出来，提炼成三条要点发到 Slack 的产品频道」，这句话本身就定义了要做什么、数据从哪来、输出到哪去，不需要任何预设的菜单去匹配。

从「操作工具的人」变成「表达意图的人」——这就是这套架构想做的事。

如果你也想试试，建议从一个小场景开始——比如建个 Projects，接一个你平时用得最多的外部工具，看看它能不能帮你省掉一些重复操作。选个顺手的 AI Agent 工具，也不一定是Claude，主流的 Agent 工具架构思路大同小异。有时候理解这些概念最好的方式，不是看文档，而是亲自让它「跑通」一次。

如果你试了，欢迎来聊聊你的第一个用例。我挺好奇别人最先拿这套东西干了什么。

---

*本文案例基于 claude\.ai 网页版 \+ Projects \+ Gmail Connector \+ canvas\-design Skill \+ Sonnet 4\.6 大模型的组合。不同产品和模型功能可能存在差别。*