夜雨聆风
hi，我是小胖，这篇文章大约9000字。
尽量让你搞明白大模型、Agent、Skill、IDE、本地助手、MCP、连接器这些东西到底是啥，它们怎么互相依存的。
对我来说是一种挑战，试图将和我们工作协作比较密集的部分，用朴素且易懂的方式讲出来，这也是我内训的小分享，已脱敏。
我们需要新的工作范式
前段时间，我们做了一次招募。
这个招募很火爆，累计有小 200 人报名。
后面还会涉及到一件很细的事：用户要分享产品的使用体验，要写笔记，我们还要判断谁适合被邀请、谁适合哪个产品、谁可以放到第一批、谁需要再观察。
如果按传统的人肉逻辑来做，这件事很直接，也很累：一个账号一个账号看过去，一条信息一条信息盘点，起码要看200多个号。
先判断我的筛选逻辑是什么，再看每个报名者填了什么信息，适合哪个产品，适不适合来分享，邀请优先级是什么，要不要约，放在哪个批次。
这里真正消耗人的地方，不在于某一个判断很难，而在于细碎动作太多。
要看资料、搭框架、打分、排序、记录原因、安排批次、后续审稿、整理复盘。每一步都不大，合在一起就很重，因为我们只有一个人。
都说AI提效，但如果还在聊天框里做这件事，效率会更低，纯人肉做也很痛苦。因为要不停复制信息、补充背景、解释产品、说明筛选标准，再把输出搬回表格或文档里。
聊天框可以帮你想，但很难接住一个完整项目。后来，我们尝试放到本地助手里，工作方式就有趣起来了。
我可以先把产品信息、推广目标、报名表、用户填报资料、账号链接、笔记要求都放进一个项目工作台。
然后让助手先出一份筛号框架：什么样的账号适合这个产品，什么样的人适合分享，哪些信息需要重点看，哪些情况要降权。
框架确认后，还可以继续让它沉淀成一个筛号 Skill，或者一套评分标准。满分 10 分，这个账号整体打几分，为什么打这个分，要不要约，放在哪一批，推荐哪个产品，后续跟进要注意什么。
用户的笔记出来后，还可以继续让助手按审稿 SOP 做第一轮检查：产品理解有没有偏差，表达有没有夸大，笔记结构是否清楚，真实体验有没有讲出来，哪些地方需要用户补充，哪些地方适合发布。
这些判断仍然在人手上。
人负责出框架、定标准、做最后判断、看风险。
助手承担的是大量细碎动作：读资料、整理信息、定标准、给初步评分、生成审稿意见、沉淀复盘文档。
我想写这篇文章的原因就在这里。
AI 工具已经迭代了，很多工作正在从“我亲手做完所有细活”，转向“我讲清楚目标、框架和标准，让助手帮我推进”。
如果还停留在旧方法里，人会浪费很多精力。
所以这篇文章不只是解释几个新名词。
我想讲清楚：大模型、Agent、Skill、IDE、本地助手、MCP、连接器这些东西，到底分别站在什么位置，它们怎样一起帮助一个普通人完成真实工作。
AI 已经从聊天框走向工作台
很多人对 AI 的第一印象来自聊天框：你问一句，它答一段；你贴一段资料，它帮你总结；你给一个主题，它写一版文案。
这个阶段当然有价值。
它让普通人第一次感受到，大模型可以理解语言、生成文本、解释概念、归纳材料，但现在的 AI 工具已经往前走了一步。
新的变化是：AI 开始进入文件、项目、代码、表格、网页、软件和本地电脑。
它不再只停留在“给你一段回答”，还可以在授权范围内读取资料、调用工具、修改文件、生成交付物、跑检查、留下过程记录。
这就是“聊天框”和“AI 工作台”的区别。
聊天框更像问答窗口。你问，它答。
AI 工作台更像一个任务环境。你给它一个目标，它需要理解材料、拆解步骤、调用工具、执行动作、检查结果，再把交付物放回给你。
比如你说“帮我整理一份会议纪要”，聊天框可以帮你把文字整理得更顺。
工作台型工具还可能读取转写文件，按模板生成纪要，提取待办，整理成文档，保存到指定位置。
再比如你说“帮我看看这个项目还能怎么继续”，普通聊天框只能根据你贴进去的内容回答。
像 Codex、Claude Code、Cursor Agent、Code/Work Buddy 这类项目助手，在有权限时可以读取项目文件、理解目录、修改文件、运行命令或检查结果。
再回到刚才那个招募项目。
聊天框可以帮你想一个筛选标准。本地助手可以在一个项目目录里持续工作：读取报名表，整理账号信息，主页链接评估，生成筛选框架，按评分标准初筛，输出邀请批次，接着审用户笔记，最后生成项目复盘。
这就是普通人需要重新理解 AI 的原因：AI 正在从“回答问题的工具”，变成“可以进入任务现场的工作系统”。
先把这些词放进一张地图
入门时，可以先把 AI 工作系统拆成六个位置：
大模型：提供理解、推理和生成能力。 Agent：把任务拆开，并在工具和权限范围内推进。 Skill / 规则方法：把同类任务的做法固定下来。 工具动作：让系统能搜索、读文件、跑命令、调接口。 IDE / CLI / App：承载用户交互和任务执行的工作台。 记忆 / 上下文：系统用来理解这次任务的背景资料。
这六个位置有时会重叠。
一个产品也可能同时占好几个位置。
比如 Cursor 既是编辑器，也是 Agent 的运行环境，还能接入模型和工具；Codex 可以在终端、本地应用、云端任务等不同界面里处理软件工程任务；WorkBuddy 更偏桌面办公智能体工作台，可以在授权文件夹里处理文档、表格、PPT、资料调研和内容创作。
所以，这张图的价值不在于给每个产品贴死标签。
它的价值在于：当你听到一个新名词，可以先问一句，它主要站在哪个位置，负责哪件事。
比如我想从 200 个报名者里筛出合适账号。
大模型负责理解报名信息、产品要求和分享笔记的目标。
Agent 负责把任务拆成读取资料、设计筛选框架、逐个打分、输出批次、生成审稿清单。Skill 负责规定筛号和审稿的标准。
工具负责读取表格、整理账号、写入文档。
IDE、网页或本地助手界面负责让你发起任务。上下文负责告诉系统这是什么产品、这次推广目标是什么、你过去判断“好账号”的标准是什么。
同一个任务放进这张图里，名词就没有那么吓人了。
大模型：提供理解和生成能力
大模型可以先理解成 AI 系统里的能力来源。
你把一段会议记录贴进去，它能总结重点。你把一段资料发给它，它能解释含义。你让它写一段说明，它能生成初稿。
它也可以写代码、改句子、提纲、分类、翻译、归纳。
常见的大模型包括 GPT、Claude、Gemini、Qwen、DeepSeek、Llama。它们的共同点是提供语言理解和生成能力。
官方文档里通常会把这类能力描述为根据输入生成文本、结构化内容、代码或多模态结果。
用一个普通例子看：你把一段产品会议记录发给大模型，让它整理成“结论、争议、行动项”。这时大模型主要在做理解和生成。它读你给的材料，按你的要求输出文本。
边界也要看清。大模型本身通常只看得到你给它的内容，或者系统明确接入给它的上下文。
它不会天然知道你的本地文件夹里有哪些资料，也不会自动帮你打开电脑、改文件、跑命令。想让它接触外部材料，需要 Agent、工具、连接器、权限和上下文一起参与。
所以，大模型更像脑力来源。它能想、能写、能推理，但它单独站在那里时，很多“做事动作”还没有发生。
Agent：把任务拆开并推进
Agent 可以理解成围绕大模型搭起来的任务推进系统。
一个 Agent 往往会把模型、指令、工具、上下文和检查机制组织起来。它不只是回答一句话，还会根据任务目标拆步骤、调用工具、读取资料、修改文件、检查结果，并在一定范围内继续推进。
比如你说：“帮我整理这个项目文件夹，把里面的文章工作台找出来，判断哪篇可以继续写，再给我一份下一步建议。”
普通聊天框在没有工具和文件权限时，只能告诉你大概怎么做。
一个本地 Agent 在有权限的情况下，可以读取文件夹，识别文件，打开工作台，提取状态，写入建议，再检查有没有遗漏。你看到的是一段被推进过的任务。
再换成招募筛号场景。
我让 Agent 先读取报名表和产品说明，再让它生成一套筛选框架。
你确认框架后，它继续按框架处理每个账号，生成评分、理由、批次和跟进建议。
整个过程里，人不需要逐条复制材料，也不需要每次从头解释背景。这就是Agent来到本地的效率提升。
OpenAI Agents SDK 会把 Agent 放在 instructions、model、tools 等要素里理解；Claude Code 这类工具强调可以理解代码库、编辑文件、运行命令，并通过 MCP 接入外部数据源。
不同产品表达不同，但共同点很清楚：
Agent 的关键在于把模型能力组织成可执行的工作流。
这里也有边界。Agent 的能力取决于它接了什么模型、有什么工具、拿到哪些权限、能访问什么上下文。
没有文件权限，它读不了你的本地资料；没有浏览器或搜索工具，它查不了网页；没有明确规则，它可能直接跳到成稿，漏掉中间确认。
Agent 能推进任务，但推进方式需要规则约束，所以要持续沟通目标和背景，以及邀约主动提问、确认、再动手。
否则它很容易“做得很快”，然后你会很失望地说，这是个很笨的智能助手。
本地助手：把 AI 放进你的文件和工作流
本地助手可以理解成一种更贴近电脑和文件的 Agent 产品形态。
它通常运行在你的电脑、终端、编辑器或桌面工作台里。
它能接触的材料更接近真实工作现场：项目文件夹、代码仓库、文档、表格、PPT、图片、截图、网页资料、任务记录。
Codex 是一个典型例子。
OpenAI 的 Codex CLI 官方说明里提到，它可以在你选定的目录中读取、修改和运行代码。
换成普通语言，就是你可以把一个项目交给它，让它理解文件结构、改代码、跑命令、修 bug、写测试或解释一段陌生代码。
这类工具最适合的任务，是“帮我完成一段项目工作”。比如：
找出一个代码项目为什么跑不起来。 改一个网页里的按钮样式，并验证页面有没有报错。 把一个课程资料文件夹整理成目录说明。 扫描一批 Markdown 文件，找出重复、缺口和待办。 读取招募报名表，按筛选框架给账号打分和分批。 根据已有工作台继续写文章，并把修改记录写回同一个文件。
WorkBuddy 是另一个方向。
公开产品介绍把它定位成全场景职场 AI 智能体桌面工作台，强调自然语言下达任务、本地文件夹读取、文档/表格/PPT 生成、数据分析、行业调研、多智能体并行处理等办公场景。
它的任务栏文档里还把模式分成 Ask、Plan、Craft：Ask 偏查看和问答，Plan 先给计划再操作，Craft 更偏直接执行并修改文件。
这个例子对小白很重要。它说明“本地助手”并不只服务程序员。
程序员可以用 Codex、Claude Code、Cursor、CodeBuddy 处理代码项目；普通办公人群也可以用 WorkBuddy 这类桌面智能体处理文件整理、表格汇总、报告生成、资料调研和内容创作。
我对本地助手的描述是：它让 AI 更靠近你的真实材料，也更靠近一个可验收的结果。
在我的招募项目里，本地助手的价值远不止“帮我想一句文案”。
它可以从项目开始陪着做：先做筛号逻辑，再做评分标准，再做笔记审稿 SOP，再做用户稿件初审，最后把整次项目复盘沉淀下来。
人仍然要做判断，但不用把每一件细活都亲手过一遍。
Skill：把做事方法固定下来
Skill 可以先理解成 Agent 的工作方法包。
它告诉 Agent：遇到某类任务时，应该怎么判断，按什么流程走，读哪些材料，写入哪些区块，输出什么格式，哪些事情要停下来确认。
以写公众号文章为例。
没有写作 Skill 时，你说“帮我写一篇文章”，系统可能直接给你一篇顺滑正文。
看起来很快，但很容易跳过真实输入、观点提炼、选题判断、结构确认、资料边界和发前审核。
有写作 Skill 后，同一个请求会被拆成更稳的流程：
先接诊，看用户有没有真实素材；再提炼观点，看这篇文章到底想表达什么；然后选题，判断哪个角度值得写；再做标题结构，确认小标题和写作清单；必要时调研资料；再写正文；最后做表达校准和主编发布。
筛号也一样。
没有筛号 Skill 时，你每次都要临时解释：这次产品是什么，什么样的账号适合，评分怎么看，笔记审稿要看哪些点。
有了 Skill 后，它会变成一套可复用的判断标准：账号匹配度、内容质量、真实体验、表达能力、粉丝关系、风险点、批次建议，每次都按同一套口径先处理。
这就是方法包的价值。
它把“怎么做”固定下来，让同类任务可以重复执行，也让每个环节知道自己该交什么给下游。
这里要补一个准确性边界。Skill 在不同平台里的含义并不完全一样。
Claude Skills 官方文档里，Skill 是包含 instructions、scripts、resources 的目录，系统会在相关任务中动态加载。
其他平台可能用 AGENTS.md、CLAUDE.md、工作流提示词、项目规则文件来承担类似职责。
所以在这篇文章里，我们把 Skill 放在“规则方法”这个位置。
它不必拘泥于某个平台的专有名称。你只要记住：它解决的是“同一类任务以后怎么稳定做好”的问题。
IDE、MCP、连接器：它们分别解决什么
讲到这里，还剩几个高频名词：IDE、MCP、连接器、上下文。
它们经常和 Agent、本地助手混在一起。
先说 IDE。
IDE 原本是开发者写代码的工作环境，比如 VS Code、JetBrains、Cursor、CodeBuddy IDE。
AI 进入 IDE 以后，它就能更自然地接触代码项目：看目录、读文件、解释代码、生成代码、改多处文件、运行终端、看报错、做代码审查。
对小白来说，可以这样理解：IDE 是代码和项目的工作台。Cursor、CodeBuddy IDE 这类产品，把 AI 放进这个工作台里，让它能围绕项目文件、代码结构和终端结果工作。
工具动作负责让 AI 系统做具体事。
比如搜索网页、读取文件、运行命令、打开浏览器、调用 API、连接数据库、访问日历、读取邮件、使用 MCP 工具。
OpenAI Tools、MCP Tools、ChatGPT Apps 和连接器这类资料都在说一件事儿：模型或 Agent 需要通过工具，才能在授权范围内接触外部系统。
用普通例子看，你让助手查某个产品的官方说明。
大模型负责理解问题，Agent 负责规划查询，搜索工具负责打开资料来源，连接器可能负责接入某个外部服务。最后模型再把结果整理成你能读懂的话。
再说 MCP。
MCP 可以先理解成一种连接工具和数据源的标准方式。
它让外部服务把“可调用的工具”暴露给 AI 系统。
比如一个 MCP Server 可以提供读数据库、查项目、访问某个系统、操作文件或调用内部工具的能力。
举例Get笔记CLI，让本地工具链接知识库，或者数据库。
它解决的问题是连接标准。
Agent 想做事，需要工具；不同工具和系统各有接口；MCP 让这类连接更容易被统一管理和调用。
你不用一开始理解它的技术细节，只要知道：MCP 常常出现在“让 AI 接上外部工具和数据”的场景里，一般把命令行发给agent就能接入。
连接器和 Apps 更像产品里的具体入口。
比如某个 AI 产品允许你连接网盘、邮件、日历、协作文档、代码平台或其他应用。你授权后，AI 才能在那个范围内读取或使用相关信息。
所以，MCP 和连接器都和“接外部能力”有关，但角度不同。MCP 更像工具连接的通用协议和开发者接口；连接器更像普通用户在产品里能点开的授权入口。
记忆和上下文负责告诉系统“这次任务基于什么”。
上下文可以是当前对话、你贴进去的资料、项目里的 README、历史沟通纪要、用户偏好、长期记忆、工作台状态、上一轮修改记录。上下文越清楚，系统越容易判断你真正要什么。
还是拿写文章举例。
我如果只说“写一篇 Agent 入门课”，系统只能按常识写。
我把团队内训的起因、大家对AI的困惑、六个位置框架、禁用句式、工作台阶段、资料边界都放进去，系统就能写得更贴近你的真实目标。
所以，AI 工作系统能不能做成事，不只看模型强不强。
还要看 Agent 会不会推进，Skill 有没有规则，工具能不能触达材料，环境适不适合任务，上下文是否足够清楚。
用四个真实任务看懂这些工具
理解这些概念，最好的方式是选一个真实任务，用这六个位置跑一遍。
第一个任务：从 200 个报名账号里筛号，拿我的案例分享。
大模型负责理解产品信息、报名资料和分享笔记目标。
Agent 负责把任务拆成设计框架、读取资料、逐个评分、分批建议、审稿检查和复盘归档。
Skill 负责规定筛号标准和审稿 SOP。
工具负责读取表格、整理账号信息、写入文档。环境可能是本地助手、表格、工作台或项目文件夹。
上下文包括产品定位、推广目标、报名表、账号资料、笔记要求和历史判断标准。
这个任务最能说明 AI 工作台的价值。
人的角色从“逐个账号手动看”变成“先讲清楚判断框架，再监管助手执行”。你要做的是判断标准、风险控制和最终拍板，助手可以承担大量重复盘点和初筛动作。
第二个任务：整理会议纪要。
大模型负责理解会议内容，提炼结论和行动项。
Agent 负责把任务拆成读取原始记录、识别议题、归纳结论、找出待办、检查遗漏。
Skill 负责规定纪要格式，比如“背景、讨论点、决定、待办、风险、下次确认”。
工具负责读取录音转写、打开文档、搜索相关资料、写入文件。环境可能是网页 App、文档编辑器、本地文件夹或桌面助手。
上下文包括项目背景、参会人、上一轮决策、你的记录习惯、团队已有模板。
第三个任务：整理一个项目文件夹。
这时聊天框的作用有限，因为它看不到你的文件。
你需要更靠近本地资料的助手，比如 Codex、Claude Code、Cursor、CodeBuddy 或 WorkBuddy 这类工具形态。
你不需要整理文件，你要做的事让他们来帮你整理，你定好规则，只要有东西进来，他们根据规则自动分类。
它们在授权范围内读取目录、识别文件、提取状态、修改文档或生成清单。
对普通人来说，这类任务可以是整理课程资料、归档发票、合并表格、生成周报、梳理历史文章。
对开发者来说，这类任务可以是读代码库、找 bug、改文件、跑测试、生成 PR 说明。
第四个任务：把一堆想法写成一篇文章。
这里最容易出问题。
很多 AI 会太快进入正文，导致文章看起来顺，里面却缺观点、缺结构、缺资料边界。
更稳的方式是把写作当成工作台任务：先归档素材，再提炼观点，再选题，再搭标题结构，再补资料，最后写正文和校准。
这时 Skill 的价值就出来了。
它规定一整套写作流程，而不只是临时补一句提示词。
大模型负责理解和表达；Agent 负责推进流程；Skill 负责定义每一步怎么做；工具负责读取工作台、搜索资料、检查文本；环境负责承载文件和对话；上下文负责保留你的素材、偏好和禁区。
这些任务背后还有一个共同变化：
人的重点从亲自完成所有动作，转向出判断、定节奏、设标准、看结果。
你需要不断和助手沟通，把事情讲明白。这个过程本身也在训练你的表达、拆解、判断和管理能力。
看到一个新工具，先问五个问题
入门时不需要一次掌握所有工具。先会问五个问题就够了。
第一，它主要提供大模型能力，还是能推进任务？
如果只是帮你解释、总结、改写，它更接近模型或聊天产品。如果它能读文件、拆任务、改文档、跑检查，它就更接近 Agent 或本地助手。
第二，它靠近哪类工作现场？
靠近代码项目的，常见形态是 IDE Agent、CLI Agent、编码助手，比如 Codex、Claude Code、Cursor、CodeBuddy。
靠近办公文件的，常见形态是桌面智能体、文档助手、表格助手，比如 WorkBuddy 这类办公工作台。靠近外部服务的，常见形态是连接器、Apps、MCP Server。
第三，它有没有固定方法？
如果每次都靠你临时说清，结果会不稳定。
如果它有 Skill、模板、工作流、项目规则、角色分工，交付会更容易复用。
第四，它能接触哪些材料？
它能读当前聊天，还是能读你授权的文件夹？它能看代码库，还是能连接网盘、数据库、协作文档、网页资料？材料边界决定了它能做到什么程度。
第五，它的风险在哪里？
能改文件，就需要备份和确认；能连接外部服务，就要看权限和隐私；能自动执行，就要有日志和回退；能生成观点，就要检查事实来源和表达边界。
能回答这五个问题，你就不会被工具名牵着走。
最后，把名词放回任务里
大模型、Agent、Skill、IDE、本地助手、MCP、连接器，这些词会继续变。产品形态也会继续重叠。
普通人真正需要建立的能力，是把名词放回任务里看。
当你只想问一个问题、改一句话、解释一段材料，聊天框已经够用。
当你想让 AI 读一组文件、整理一个项目、持续做细碎的事、持续修改一篇文章、跑检查、留下记录，就要开始关注 Agent、本地助手、工具、上下文和工作台。
当你希望同类任务以后都按稳定流程完成，就要关注 Skill、规则文件和方法包。
当你希望 AI 处理本地项目、代码、文档、资料和外部系统，就要关注 IDE、CLI、本地助手、MCP、API 和连接器。
这篇文章只做一件事：先帮你把地图画出来。
以后再遇到新工具，你可以先不急着问“它厉不厉害”，先问“它站在哪个位置，帮我完成哪段任务，需要什么材料和权限”。
如果你正在带团队，也可以把这张图当成一次共同语言训练。
先让大家用同一个任务复述六个位置，再讨论各自手里的工具站在哪。
讨论到这里，很多争论会自然减少：有人需要更好的模型，有人需要规则，有人缺少工具权限，有人缺少上下文。
这一步走清楚，后面学习任何 AI 工具都会轻很多。
我也希望更多人真的用起来，多多把玩。
因为工具已经进入新的阶段，继续用旧方式硬扛，消耗会越来越大。
把目标、框架、标准和节奏讲清楚，让助手承担细碎执行，人回到判断和监测的位置，这会成为很多工作的基本变化。
这个时代，总有更轻松且快的方式，让自己成长，然后享受这个时代。
以上，与你分享。
更多文章推荐：
我的星球-戳底部了解详情。
会持续分享关于创作和构建的一切，内容维度丰富，期待你的加入。
-END-
「分享/思考/构建→人生复利⭕️星球OS」
不要有负担，我的朋友圈
xw2013GE
不用尴尬，不闲聊，不卖项目，也不答疑
