Skill是将领域知识、执行策略和资源打包的可复用能力单元按需加载而非一次性塞满上下文。文章从Skill的必要性、定义、运作方式、编写方法及与Tool/MCP的关系进行详细阐述并通过实例对比展示Skill在稳定性和效率上的优势。Skill通过YAML Frontmatter和Markdown正文定义支持按需加载scripts、references和assets资源有效降低Token成本并沉淀领域知识。文章还介绍了Skill的生命周期、与Tool/MCP的层级关系以及编写高质量Skill的实战要点旨在帮助程序员理解和应用Skill技术提升大模型应用能力。一句话定义Skill是将”领域知识 执行策略 资源“打包而成的可复用能力单元让 Agent 在需要时才按需加载而不是一次性把所有本事都塞进上下文。如果你已经用过 Function Calling、Tool Use 或 MCP可能会产生一个自然的疑问我都有 Tool 了为什么还需要 Skill这篇文章会从”为什么”讲起把 Skill 是什么、怎么运作、怎么写、和 Tool/MCP 的关系一次讲清楚。一、为什么要有 Skill从”有工具”到”会用工具”2024 年 MCPModel Context Protocol解决了一个关键问题——让模型能标准化地连接外部世界。但很快大家发现仅仅”连上”是不够的一个数据库 MCP Server 可能暴露上百个工具光是tools/list的 Schema 就能吃掉数万 tokenAgent 知道”有execute_sql这个函数”但不知道什么时候用、怎么组合、边界在哪同一个数据库不同业务场景有完全不同的使用套路这些”套路”无处安放换句话说MCP 解决的是”能不能做”Connectivity而Skill 解决的是”怎么做好”Capability。如果说 MCP 是 USB 接口那 Skill 就是装在电脑里的专业软件——定义了”在什么场景下、按什么顺序、以什么参数调用哪些已连接的设备”。一个具体例子同一个需求加不加 Skill 差多少假设你给 Agent 接了一个github-mcp服务器里面有list_pull_requests、get_pr_diff、create_pr_comment等 20 多个工具。现在用户说“帮我 review 一下 PR #128。”只有 Tool / MCP 的版本Agent 看到这个请求大概会这样运作① 列出所有20个工具的 Schema → 上下文被塞进一大块 JSON ② 猜哪个工具能review PR→ 可能先调 list_pull_requests、再调 get_pr_diff ③ 拿到一大段diff→ 直接让 LLM 自由发挥点评 ④ 评论风格看心情 → 今天可能只挑拼写明天可能长篇大论 ⑤ 不知道要不要逐文件评论、要不要分严重级别、要不要 作者问题很明显Agent 知道”有什么工具可调用”但不知道”一次代码审查应该长什么样”。每次 review 的质量完全取决于模型当下的心情和上下文残余。加上code-review-workflowSkill 之后这个 Skill 目录里有一份正文大致写着工作流程1. 调用 getprdiff 拿到改动文件列表按文件分批 review2. 每个文件按语言套用检查清单 - Python是否违反 PEP 8 / 是否有未处理异常 / 命名是否清晰 - JavaScript是否有未 await 的 Promise / 是否滥用 any3. 把问题分三个等级 阻塞 / 建议 / 优化4. 只有 级别才用 createprcomment 逐行评论5. 汇总写入 PR 总结评论 作者6. 最后给出 approve / request-changes 判断建议再来一次同样的”帮我 review PR#128”① Agent 扫描所有 Skill 描述每个 ~100 token→ 命中 code-review-workflow ② 加载这个 Skill 的 SKILL.md 正文 → 上下文里现在有review SOP③ 严格按6步流程执行 → 行为稳定可预测 ④ 输出风格统一分级、分文件、有总结 → 每次 review 结果一致对比一下维度只有 Tool / MCP加上 SkillAgent 知道”能做什么”✅✅Agent 知道”应该怎么做”❌✅行为稳定性每次都是即兴发挥流程化、可复现领域经验能否积累无处安放每次丢失写进 SKILL.md可版本化上下文成本20 个工具 Schema 常驻≈8k token命中才加载正文启动只费 ~100 token × NTool 是”能力”Skill 是”做事的方法”。一个没有 Skill 的 Agent就像给了刚入职的新人一把瑞士军刀但没发员工手册——工具齐全就是不知道今天该干啥、按什么标准交付。这种分离带来了三个直接收益收益机制Token 成本骤降只有元数据常驻正文按需加载。实测可从 16k 降到 500 左右领域知识可沉淀业务经验、最佳实践、避坑指南变成可版本化的文件能力可分发复用一个 Skill 目录就是一个”即插即用”的能力包二、什么是 Skill一个目录 一份说明书1 最小定义一个 Skill 就是一个目录里面至少有一个SKILL.md文件。仅此而已my-skill/ └── SKILL.md 必需YAML Frontmatter Markdown 正文SKILL.md是这个能力包的”身份证 使用说明书”顶部 YAML Frontmatter 是机器读的元数据决定何时被触发下面的 Markdown 正文是给 LLM 读的执行指令决定做什么、怎么做。2 Skill 长什么样一个目录的构造打开任意一个 Skill你看到的就是一个普通的文件夹。以官方为例pdf-processing/ 目录名Skill 名 ├── SKILL.md# 必需入口文件元数据 指令├── scripts/# 可选可执行脚本Python / Bash / JS│ └── extract.py ├── references/# 可选补充参考文档按需加载│ └── REFERENCE.md └── assets/# 可选模板、图表、数据等静态资源└── template.pdf整个 Skill 规范只有一条硬性规定必须有SKILL.md。其他三个子目录都是可选的用与不用、怎么用由这个 Skill 的作者决定。SKILL.mdSkill 的身份证和使用说明书。顶部 YAML Frontmatter 是给 Agent 读的元数据名字、描述、许可证等下面的 Markdown 正文是给 LLM 读的执行指令这个 Skill 能做什么、怎么做、有哪些坑scripts/Agent 可以调用的可执行代码。当任务需要”确定性结果”格式转换、复杂计算、二进制处理时交给脚本比交给模型生成更稳、更便宜references/详细的参考资料。不会默认加载只在 Agent 觉得”需要看一下 FORMS 的定义”时才打开对应文件assets/文档模板、图表、数据文件等静态资源3 Agent 是怎么加载一个 Skill 的理解了 Skill 的构造下一个问题就是Agent 在一次对话里是怎么从这堆文件中把需要的部分”请”到自己脑子里的答案是按需分层加载——Skill 规范里把它叫做「渐进式披露Progressive Disclosure」。一次典型的加载路径可以分成三步每一步只拿走自己需要的那部分步骤加载内容规模何时触发① 启动时所有 Skill 的 name descriptionFrontmatter 的两个必填字段~100 tokens / SkillAgent 启动自动加载常驻上下文② 激活时命中的那个 Skill 的 SKILL.md 完整正文 5000 tokens推荐语义匹配上之后才加载③ 执行中scripts/ 的脚本、references/ 的文档、assets/ 的资源按需不限LLM 决定需要时按需读取用图书馆做类比会很直观第 ①步像翻书目卡片——每本书的卡片都摆在桌上但只有书名和简介成本极低第 ②步像把那本书借出来——用户提到”帮我处理下 PDF 表单”Agent 从卡片里识别出pdf-processing最匹配才把这本书的正文放上桌第 ③步像按需翻附录——书正文里写了”详细表单规范见附录 A”Agent 在真正需要填表单时才去翻references/FORMS.md这套机制的价值体现在三个数字上50 个 Skill 常驻只要 ~5k token只有卡片在桌上激活一个 Skill 才花 5k token正文上桌资源层不计入常规预算附录躺在书架上需要时再翻换句话说你装了多少 Skill 都行真正消耗上下文的永远只有当前那一个的正文以及它这次真正用到的那几个附件。这就是 Skill 能同时做到”能力库无限扩展”和”Token 消耗可控”的根本原因。4 Agent 是怎么读取目录里的其他文件的3 节说到执行时会”按需读取scripts/、references/、assets/“。具体怎么读——Agent 不扫描目录只读SKILL.md正文声明过的路径。一句话SKILL.md是目录树的地图地图没标的地方 Agent 看不见。SKILL.md 正文里会用自然语言声明文件的用途和时机例如工作流程1. 提取内容时调用uv run scripts/extract.py --input lt;filegt;2. 填表单前先阅读 references/FORMS.md3. 生成新文档时从 assets/template.pdf 开始这段正文进入上下文后Agent 就知道什么时候该动哪个文件。三类资源的打开方式各不相同资源类型触发时机Agent 的动作效果scripts/正文提示”调用脚本”时Bash 执行脚本的 stdout 注入上下文references/正文提示”详见 XXX”时Read 读文件文件内容注入上下文assets/需要模板/数据作为输入时Read 或 Bash原始字节作为输入关键区别scripts/是”执行拿结果”references/和assets/是”读取拿内容”。三条避坑规则只有写进SKILL.md的文件才”存在”。放references/ADVANCED.md但正文没提到 → Agent 永远不会打开它。这是最常见的”功能不触发”根因。路径相对 Skill 根目录。写scripts/extract.py即可框架会自动拼成绝对路径别手动写~/.skills/…。权限受allowed-tools白名单约束。声明了Bash(python scripts/*.py)就只能跑 scripts 下的 Python其他命令需要用户现场批准。这种声明式按需加载是 Skill 纪律性的来源——目录里可以放很多资源但任何一次执行都只碰正文明确指向的那几个。三、再看一遍完整的运行流程3 节讲了三层加载的静态划分这里把它展开成一次真实对话中发生了什么。假设用户说”帮我合并这两个 PDF”① 启动阶段Agent 启动 → 扫描 Skill 目录 → 把每个 SKILL.md 的 name description 加载进系统提示常驻 ② 发现阶段用户说帮我合并这两个 PDF → Agent 在常驻的元数据里做语义匹配 → 命中 pdf-processingdescription 中含合并 PDF关键词③ 激活阶段把 pdf-processing/SKILL.md 的完整正文注入上下文 → 模型看到处理 PDF 可调用 scripts/merge.py④ 执行阶段: 模型决定调用脚本 → 通过 Bash 工具跑 scripts/merge.py input1.pdf input2.pdf → 如果遇到表单字段问题按需读取 references/FORMS.md⑤ 返回阶段整合脚本输出 → 生成自然语言回复 → 资源层脚本输出、FORMS.md滚出上下文 下一轮对话不再占用 token整条流水线里真正常驻上下文的只有第①步的元数据正文在第③步进出资源在第④步进出该走就走。这就是为什么一个 Agent 可以装几十上百个 Skill 而不爆上下文。四、SKILL.md 规范一份文件的解剖1 YAML Frontmatter元数据契约Frontmatter 是文件顶部、由—包围的 YAML 块定义了 Skill 的身份和元数据---name: pdf-processing 必需description: 从 PDF 中提取文本和表格、填写表单、合并多个 PDF。当用户提到 PDF、表单、文档提取时使用。 # 必需license: Apache-2.0 # 可选compatibility: Requires pdftotext, jq # 可选allowed-tools: Bash(pdftotext:*) Read Write # 可选实验性metadata: # 可选 author: example-org version: 1.0---字段速查表字段是否必需核心约束name✅1–64 字符小写字母 数字 连字符必须与目录名一致不能以 - 开头/结尾不能含 –description✅1–1024 字符描述做什么 何时用包含触发关键词license❌许可证名或捆绑许可文件名compatibility❌≤ 500 字符环境要求依赖、网络、目标产品allowed-tools❌预批准的工具白名单减少人工确认实验性metadata❌任意 key-value用于自定义扩展2 description 是决定 Skill 命运的字段description是 Agent 判断”要不要激活这个 Skill”的唯一语义依据。写好它几乎决定了 Skill 的成败❌ 差的示例——过于模糊匹配不到任何具体意图description: Helps with PDFs.# ✅ 好的示例——讲清楚做什么 何时触发 包含关键词description: 从 PDF 或 Excel 财报中提取关键指标营收、净利润、毛利率 生成结构化摘要和趋势图表。当用户提到财报、财务分析、 季度报告、利润表时触发。三条可操作的原则描述即触发器把用户可能说出口的关键词明确写进去说明独特价值和其他 Skill 能区分开避免匹配时混淆定义适用边界说明什么场景不适用防止误触发3 Markdown 正文给 LLM 的执行指令Frontmatter 之后就是正文。格式不限但有章法。推荐结构概述Overview这个 Skill 能做什么一句话讲清核心能力工作流程Workflow分步骤的操作说明越具体越好示例Examples输入 → 输出的 Few-shot 样例这是最便宜、最有效的指令边界条件Edge Cases常见坑和容易搞错的地方可用脚本 / 资源如果有scripts/或references/在这里说明什么时候用硬约束保持SKILL.md正文 500 行以内。更长的参考资料应拆分到references/按需加载否则会把指令层撑爆。4 可选目录scripts / references / assetspdf-processing/├── SKILL.md 必需主入口├── LICENSE.txt # 可选许可证├── scripts/ # 可选可执行代码│ ├── extract.py│ └── merge.sh├── references/ # 可选详细参考文档按需加载│ ├── REFERENCE.md│ └── FORMS.md└── assets/ # 可选模板、图表、数据 └── template.pdf每个目录各司其职目录用途设计要点scripts/可执行脚本自包含或清晰声明依赖无交互结构化输出有意义的错误信息references/补充参考文档按需加载单文件聚焦单一主题避免深层嵌套引用assets/静态资源模板、图表、数据文件5 脚本设计的五条铁律如果你的 Skill 带了scripts/脚本要为”Agent 消费”而设计和给人用的 CLI 有明显差异拒绝交互式提示Agent 跑在非交互 shell 里所有输入必须通过 flag / 环境变量 / stdin 传入–help即说明书Agent 靠–help学你的接口要简洁、带例子错误消息要可操作”Error: invalid input” 是在浪费 Agent 的下一回合要说”期望什么、收到什么、该怎么改”结构化输出stdout 输出 JSON / CSV诊断信息写 stderr便于组合jq /awk幂等 退出码Agent 会重试操作要幂等用不同退出码区分不同错误类型五、Skill 的生命周期从静态文件到动态能力一个 Skill 从硬盘上的一堆文件到被 Agent 真正用起来只会经过四个关键阶段——发现 → 加载 → 触发 → 调用。和前面章节的脉络完全一致只是这次按时间轴把它们串起来看。阶段发生时机做的事上下文变化① 发现Agent 启动时扫描 Skill 目录解析每个 SKILL.md 的 Frontmatter还未注入上下文② 加载启动完成前把所有 Skill 的 name description 注入上下文N × ~100 tokens常驻③ 触发用户消息到达时语义匹配命中某个 Skill把它的 SKILL.md 正文注入上下文正文 5k tokens④ 调用执行过程中按正文指引用 Read / Bash 读取 scripts/ references/ assets/按需追加阶段 ① 发现扫描 Skill 目录Agent 启动时先做一件事——到约定的目录下把所有 Skill 扒一遍。常见路径有两处用户级/.claude/skills/或/.workbuddy/skills/项目级./.claude/skills/或./.workbuddy/skills/对每个子目录Agent 检查是否有SKILL.md有就解析顶部的 YAML Frontmatter提取name和description格式不对、缺必填字段的直接跳过。这一步只读 Frontmatter不会碰正文和其他文件。产出一张本地能力清单Agent 知道”有哪些 Skill、叫什么、能做什么”。阶段 ② 加载元数据进入上下文扫出来的清单要被 Agent 真正”意识到”就得进入上下文。加载阶段只把每个 Skill 的name description注入系统提示——典型情况下每个 Skill ~100 tokens。这就是为什么 2.3 节说”50 个 Skill 常驻只要 ~5k token”不是因为 Skill 小而是加载阶段只塞了名片。加载完成后Agent 的”潜意识”里就有了一张能力目录卡片看到用户请求时可以在这张卡片上做语义匹配。阶段 ③ 触发正文进入上下文用户发来一条消息Agent 第一反应是在卡片上找最匹配的 Skill。匹配靠两个东西用户消息里的关键词Skill description 里埋的触发词这也是为什么 description 要把”财报 / 利润表 / 季度报告”这些词明写出来命中后Agent 做一件事——把这个 Skill 的SKILL.md完整正文读出来注入当前对话的上下文。这一步前Agent 只知道”有个叫pdf-processing的能做 PDF”这一步后它知道了”要先读 FORMS.md、再调用 extract.py、参数怎么传、边界有哪些”。触发是多次性的对话里每次用户意图变了Agent 会重新匹配、重新触发不同的 Skill 正文可以轮流进入上下文。阶段 ④ 调用按正文指引操作资源正文进入上下文后Agent 开始按里面的指令干活。2.4 节讲的”声明式按需加载”正是在这一阶段发生正文说”先读references/FORMS.md” → 用Read把文件内容注入上下文正文说”调用scripts/extract.py --input …” → 用Bash执行把 stdout 注入上下文正文说”从assets/template.pdf开始” → 读取模板作为生成起点调用可以反复发生一个任务里 Agent 可能多次 Read、多次 Bash也可能结合其他 Tool 和 MCP。每次调用产生的输出都会回到上下文供 Agent 决定下一步。四个阶段的节奏对比阶段频次Token 开销是否可感知① 发现启动一次无不进上下文用户不可感知② 加载启动一次N × ~100 tokens 常驻用户不可感知③ 触发每次意图切换单次 5k tokens用户可感知回复变专业了④ 调用每次具体动作按需追加用户可感知文件被读、脚本被跑越靠前越不可见但越基础越靠后越频繁但越直接产生价值。这四个阶段串在一起就是 Skill 从文件系统到真实能力的全部旅程。六、Skill、Tool、MCP 的关系分层架构很多人会困惑Tool、MCP、Skill 这三个概念到底是什么关系它们不是竞争而是处在不同的抽象层次各司其职。1 三层抽象┌─ Skill 层知识与策略──────────────────────────--───┐│ 何时用 / 怎么用 / 按什么顺序 / 注意什么边界 ││ 回答的是在什么场景下做什么 │└────────────────────────────────────────────────-─-─┘ ↓ 指导┌─ MCP 层标准化协议──────────────────────────────--─┐│ JSON-RPC 2.0 统一接口Tools / Resources / Prompts ││ 回答的是怎么标准化地连接外部系统 │└──────────────────────────────────────────────--────┘ ↓ 承载┌─ Tool 层原子能力─────────────────────────────--───┐│ Bash / Read / Write / WebFetch / MCP Tool ││ 回答的是一个动作的最小执行单元 │└────────────────────────────────────────────────--──┘2 一张表看完三者差异维度ToolMCPSkill本质原子操作函数通信协议标准知识策略封装载体函数 / 可执行程序JSON-RPC 消息格式SKILL.md 脚本 配置抽象层次最低做一件事中间统一接口最高编排多件事有没有领域知识无无有解决什么问题“怎么做一个动作”“怎么标准化连接”“何时做、做什么、怎么组合”复用粒度跨 Skill 通用跨框架跨模型通用面向特定任务领域一个直观的例子“用 GitHub 做代码审查”ToolBash(curl:*)、WebFetch—— 能发 HTTP 请求MCPGitHub MCP Server 暴露list_pull_requests、create_pr_comment—— 标准化访问 GitHubSkillcode-review-workflow—— 告诉 Agent”先获取 PR 详情再逐文件审查 Python 按 PEP 8 / JavaScript 检查未处理的 Promise最后用create_pr_comment发严重问题建议性意见留到总结”三者合在一起才完整Tool 提供能力MCP 提供连接Skill 提供智慧。3 两条务必记住的原则原则一Skill 目录里放mcp.json不会生效。MCP 配置由 Agent 框架在项目级或用户级统一加载如.mcp.json/~/.claude.json不属于任何单个 Skill。Skill 只负责”描述怎么用已连上的 MCP 工具”。原则二SKILL.md 不要重复 MCP Schema。MCP Server 运行时会通过tools/list动态告诉 Agent 工具的参数 Schema。SKILL.md 只应该写 MCP 无法表达的业务经验✅ 该写的稳定、MCP 不提供❌ 不该写的会漂移、MCP 已提供业务意图 → 工具选择策略工具参数的字段名和类型多工具组合的执行顺序工具的基础功能描述已知边界条件和坑必填 / 可选参数列表认证和权限注意事项工具名运行时动态获取结果的业务解读方式返回值结构七、实战如何写一个高质量的 Skill理论讲完来点能马上用的。以下是写 Skill 时绕不过去的 10 个要点1 命名与描述动名词命名processing-pdfs、analyzing-spreadsheets而不是documents、data。Skill是个”能力”名字里要有动作第三人称描述”分析 PDF 文档”不是”你可以用这个来分析 PDF”——正文是写给 LLM 看的系统提示不是教程触发词要前置description里把用户口语化的关键词如”财报”、”利润表”、”季度报告”明确写出来语义匹配才准2 模块化与单一职责一个Skill 只做一件事与其做”通用数据分析”不如拆成mysql-employees-analysis、sales-data-analysis、user-behavior-analysis。范围越宽匹配精度越低复杂任务拆子 Agent像skill-creator那样把”评分、分析、对比”这些专业子任务委托给agents/下的专门 Agent 模板每个任务一个上下文3 渐进式披露策略正文控制在 500 行以内超过就拆到references/通过”需要做 X 时阅读references/X.md“的方式按需加载示例驱动在正文里放 2–3 个 Few-shot 示例用户输入 → 期望输出往往比一大段文字指令更有效4 脚本与确定性能用脚本就别让 LLM 硬算格式转换、复杂计算、二进制处理交给scripts/下的脚本比让模型生成更稳定、更便宜allowed-tools最小权限只预批准这个 Skill 真正需要的工具如Bash(git:*) Read降低误操作和安全风险5 可测试与可迭代配一份评估集几条”应该触发”和”不应该触发”的测试用例存到evals/evals.json每次改完description都跑一遍防止触发漂移最后一个可以直接抄的最小可用模板---name: my-skilldescription: 这个 Skill 做 X当用户提到 关键词A、关键词B、关键词C 时触发。allowed-tools: Read Write--- My Skill## 概述一句话讲清核心能力。## 工作流程1. 第一步...2. 第二步...3. 第三步...## 示例输入...输出...## 边界条件- 场景 X 时改用 ...- 遇到 Y 情况返回 ...八、结语Skill 改变了什么Agent Skills 不是一个”又一个新协议”它提出的是一个关注点分离的架构思想连接性MCP和能力Skill应该分离原子动作Tool和 编排策略Skill应该分离静态知识元数据和动态资源指令 脚本应该分离这三层分离一旦打通你会发现一些美好的事情开始发生成本可控50 个 Skill 常驻只要 5k token按需加载让上下文永远精炼知识可沉淀团队的业务经验、避坑指南、工作流 SOP终于有了可版本化的载体能力可流通一个 Skill 目录就能分享社区可以像 NPM 一样繁荣起来维护可解耦MCP 团队改基础设施Skill 团队改业务逻辑各管一摊从 Prompt Engineering到 Function Calling到 MCP再到 Skills——每一次演进都在解决上一代留下的问题。Skill 不会是终点但它把”Agent 如何掌握领域知识”这件事向前推进了一大步。如何学习大模型 AI 由于新岗位的生产效率要优于被取代岗位的生产效率所以实际上整个社会的生产效率是提升的。但是具体到个人只能说是“最先掌握AI的人将会比较晚掌握AI的人有竞争优势”。这句话放在计算机、互联网、移动互联网的开局时期都是一样的道理。我在一线科技企业深耕十二载见证过太多因技术卡位而跃迁的案例。那些率先拥抱 AI 的同事早已在效率与薪资上形成代际优势我意识到有很多经验和知识值得分享给大家也可以通过我们的能力和经验解答大家在大模型的学习中的很多困惑。我们整理出这套AI 大模型突围资料包✅ 从零到一的 AI 学习路径图✅ 大模型调优实战手册附医疗/金融等大厂真实案例✅ 百度/阿里专家闭门录播课✅ 大模型当下最新行业报告✅ 真实大厂面试真题✅ 2026 最新岗位需求图谱所有资料 ⚡️ 朋友们如果有需要《AI大模型入门进阶学习资源包》下方扫码获取~① 全套AI大模型应用开发视频教程包含提示工程、RAG、LangChain、Agent、模型微调与部署、DeepSeek等技术点② 大模型系统化学习路线作为学习AI大模型技术的新手方向至关重要。 正确的学习路线可以为你节省时间少走弯路方向不对努力白费。这里我给大家准备了一份最科学最系统的学习成长路线图和学习规划带你从零基础入门到精通③ 大模型学习书籍文档学习AI大模型离不开书籍文档我精选了一系列大模型技术的书籍和学习文档电子版它们由领域内的顶尖专家撰写内容全面、深入、详尽为你学习大模型提供坚实的理论基础。④ AI大模型最新行业报告2025最新行业报告针对不同行业的现状、趋势、问题、机会等进行系统地调研和评估以了解哪些行业更适合引入大模型的技术和应用以及在哪些方面可以发挥大模型的优势。⑤ 大模型项目实战配套源码学以致用在项目实战中检验和巩固你所学到的知识同时为你找工作就业和职业发展打下坚实的基础。⑥ 大模型大厂面试真题面试不仅是技术的较量更需要充分的准备。在你已经掌握了大模型技术之后就需要开始准备面试我精心整理了一份大模型面试题库涵盖当前面试中可能遇到的各种技术问题让你在面试中游刃有余。以上资料如何领取为什么大家都在学大模型最近科技巨头英特尔宣布裁员2万人传统岗位不断缩减但AI相关技术岗疯狂扩招有3-5年经验大厂薪资就能给到50K*20薪不出1年“有AI项目经验”将成为投递简历的门槛。风口之下与其像“温水煮青蛙”一样坐等被行业淘汰不如先人一步掌握AI大模型原理应用技术项目实操经验“顺风”翻盘这些资料真的有用吗这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理现任上海殷泊信息科技CEO其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证服务航天科工、国家电网等1000企业以第一作者在IEEE Transactions发表论文50篇获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。资料内容涵盖了从入门到进阶的各类视频教程和实战项目无论你是小白还是有些技术基础的技术人员这份资料都绝对能帮助你提升薪资待遇转行大模型岗位。以上全套大模型资料如何领取https://mp.weixin.qq.com/s/sf5dh9JwehICXFrrIYtgYw
收藏必备！小白程序员快速掌握大模型核心技能：Skill详解与实战
发布时间：2026/5/19 12:01:04
Skill是将领域知识、执行策略和资源打包的可复用能力单元按需加载而非一次性塞满上下文。文章从Skill的必要性、定义、运作方式、编写方法及与Tool/MCP的关系进行详细阐述并通过实例对比展示Skill在稳定性和效率上的优势。Skill通过YAML Frontmatter和Markdown正文定义支持按需加载scripts、references和assets资源有效降低Token成本并沉淀领域知识。文章还介绍了Skill的生命周期、与Tool/MCP的层级关系以及编写高质量Skill的实战要点旨在帮助程序员理解和应用Skill技术提升大模型应用能力。一句话定义Skill是将”领域知识 执行策略 资源“打包而成的可复用能力单元让 Agent 在需要时才按需加载而不是一次性把所有本事都塞进上下文。如果你已经用过 Function Calling、Tool Use 或 MCP可能会产生一个自然的疑问我都有 Tool 了为什么还需要 Skill这篇文章会从”为什么”讲起把 Skill 是什么、怎么运作、怎么写、和 Tool/MCP 的关系一次讲清楚。一、为什么要有 Skill从”有工具”到”会用工具”2024 年 MCPModel Context Protocol解决了一个关键问题——让模型能标准化地连接外部世界。但很快大家发现仅仅”连上”是不够的一个数据库 MCP Server 可能暴露上百个工具光是tools/list的 Schema 就能吃掉数万 tokenAgent 知道”有execute_sql这个函数”但不知道什么时候用、怎么组合、边界在哪同一个数据库不同业务场景有完全不同的使用套路这些”套路”无处安放换句话说MCP 解决的是”能不能做”Connectivity而Skill 解决的是”怎么做好”Capability。如果说 MCP 是 USB 接口那 Skill 就是装在电脑里的专业软件——定义了”在什么场景下、按什么顺序、以什么参数调用哪些已连接的设备”。一个具体例子同一个需求加不加 Skill 差多少假设你给 Agent 接了一个github-mcp服务器里面有list_pull_requests、get_pr_diff、create_pr_comment等 20 多个工具。现在用户说“帮我 review 一下 PR #128。”只有 Tool / MCP 的版本Agent 看到这个请求大概会这样运作① 列出所有20个工具的 Schema → 上下文被塞进一大块 JSON ② 猜哪个工具能review PR→ 可能先调 list_pull_requests、再调 get_pr_diff ③ 拿到一大段diff→ 直接让 LLM 自由发挥点评 ④ 评论风格看心情 → 今天可能只挑拼写明天可能长篇大论 ⑤ 不知道要不要逐文件评论、要不要分严重级别、要不要 作者问题很明显Agent 知道”有什么工具可调用”但不知道”一次代码审查应该长什么样”。每次 review 的质量完全取决于模型当下的心情和上下文残余。加上code-review-workflowSkill 之后这个 Skill 目录里有一份正文大致写着工作流程1. 调用 getprdiff 拿到改动文件列表按文件分批 review2. 每个文件按语言套用检查清单 - Python是否违反 PEP 8 / 是否有未处理异常 / 命名是否清晰 - JavaScript是否有未 await 的 Promise / 是否滥用 any3. 把问题分三个等级 阻塞 / 建议 / 优化4. 只有 级别才用 createprcomment 逐行评论5. 汇总写入 PR 总结评论 作者6. 最后给出 approve / request-changes 判断建议再来一次同样的”帮我 review PR#128”① Agent 扫描所有 Skill 描述每个 ~100 token→ 命中 code-review-workflow ② 加载这个 Skill 的 SKILL.md 正文 → 上下文里现在有review SOP③ 严格按6步流程执行 → 行为稳定可预测 ④ 输出风格统一分级、分文件、有总结 → 每次 review 结果一致对比一下维度只有 Tool / MCP加上 SkillAgent 知道”能做什么”✅✅Agent 知道”应该怎么做”❌✅行为稳定性每次都是即兴发挥流程化、可复现领域经验能否积累无处安放每次丢失写进 SKILL.md可版本化上下文成本20 个工具 Schema 常驻≈8k token命中才加载正文启动只费 ~100 token × NTool 是”能力”Skill 是”做事的方法”。一个没有 Skill 的 Agent就像给了刚入职的新人一把瑞士军刀但没发员工手册——工具齐全就是不知道今天该干啥、按什么标准交付。这种分离带来了三个直接收益收益机制Token 成本骤降只有元数据常驻正文按需加载。实测可从 16k 降到 500 左右领域知识可沉淀业务经验、最佳实践、避坑指南变成可版本化的文件能力可分发复用一个 Skill 目录就是一个”即插即用”的能力包二、什么是 Skill一个目录 一份说明书1 最小定义一个 Skill 就是一个目录里面至少有一个SKILL.md文件。仅此而已my-skill/ └── SKILL.md 必需YAML Frontmatter Markdown 正文SKILL.md是这个能力包的”身份证 使用说明书”顶部 YAML Frontmatter 是机器读的元数据决定何时被触发下面的 Markdown 正文是给 LLM 读的执行指令决定做什么、怎么做。2 Skill 长什么样一个目录的构造打开任意一个 Skill你看到的就是一个普通的文件夹。以官方为例pdf-processing/ 目录名Skill 名 ├── SKILL.md# 必需入口文件元数据 指令├── scripts/# 可选可执行脚本Python / Bash / JS│ └── extract.py ├── references/# 可选补充参考文档按需加载│ └── REFERENCE.md └── assets/# 可选模板、图表、数据等静态资源└── template.pdf整个 Skill 规范只有一条硬性规定必须有SKILL.md。其他三个子目录都是可选的用与不用、怎么用由这个 Skill 的作者决定。SKILL.mdSkill 的身份证和使用说明书。顶部 YAML Frontmatter 是给 Agent 读的元数据名字、描述、许可证等下面的 Markdown 正文是给 LLM 读的执行指令这个 Skill 能做什么、怎么做、有哪些坑scripts/Agent 可以调用的可执行代码。当任务需要”确定性结果”格式转换、复杂计算、二进制处理时交给脚本比交给模型生成更稳、更便宜references/详细的参考资料。不会默认加载只在 Agent 觉得”需要看一下 FORMS 的定义”时才打开对应文件assets/文档模板、图表、数据文件等静态资源3 Agent 是怎么加载一个 Skill 的理解了 Skill 的构造下一个问题就是Agent 在一次对话里是怎么从这堆文件中把需要的部分”请”到自己脑子里的答案是按需分层加载——Skill 规范里把它叫做「渐进式披露Progressive Disclosure」。一次典型的加载路径可以分成三步每一步只拿走自己需要的那部分步骤加载内容规模何时触发① 启动时所有 Skill 的 name descriptionFrontmatter 的两个必填字段~100 tokens / SkillAgent 启动自动加载常驻上下文② 激活时命中的那个 Skill 的 SKILL.md 完整正文 5000 tokens推荐语义匹配上之后才加载③ 执行中scripts/ 的脚本、references/ 的文档、assets/ 的资源按需不限LLM 决定需要时按需读取用图书馆做类比会很直观第 ①步像翻书目卡片——每本书的卡片都摆在桌上但只有书名和简介成本极低第 ②步像把那本书借出来——用户提到”帮我处理下 PDF 表单”Agent 从卡片里识别出pdf-processing最匹配才把这本书的正文放上桌第 ③步像按需翻附录——书正文里写了”详细表单规范见附录 A”Agent 在真正需要填表单时才去翻references/FORMS.md这套机制的价值体现在三个数字上50 个 Skill 常驻只要 ~5k token只有卡片在桌上激活一个 Skill 才花 5k token正文上桌资源层不计入常规预算附录躺在书架上需要时再翻换句话说你装了多少 Skill 都行真正消耗上下文的永远只有当前那一个的正文以及它这次真正用到的那几个附件。这就是 Skill 能同时做到”能力库无限扩展”和”Token 消耗可控”的根本原因。4 Agent 是怎么读取目录里的其他文件的3 节说到执行时会”按需读取scripts/、references/、assets/“。具体怎么读——Agent 不扫描目录只读SKILL.md正文声明过的路径。一句话SKILL.md是目录树的地图地图没标的地方 Agent 看不见。SKILL.md 正文里会用自然语言声明文件的用途和时机例如工作流程1. 提取内容时调用uv run scripts/extract.py --input lt;filegt;2. 填表单前先阅读 references/FORMS.md3. 生成新文档时从 assets/template.pdf 开始这段正文进入上下文后Agent 就知道什么时候该动哪个文件。三类资源的打开方式各不相同资源类型触发时机Agent 的动作效果scripts/正文提示”调用脚本”时Bash 执行脚本的 stdout 注入上下文references/正文提示”详见 XXX”时Read 读文件文件内容注入上下文assets/需要模板/数据作为输入时Read 或 Bash原始字节作为输入关键区别scripts/是”执行拿结果”references/和assets/是”读取拿内容”。三条避坑规则只有写进SKILL.md的文件才”存在”。放references/ADVANCED.md但正文没提到 → Agent 永远不会打开它。这是最常见的”功能不触发”根因。路径相对 Skill 根目录。写scripts/extract.py即可框架会自动拼成绝对路径别手动写~/.skills/…。权限受allowed-tools白名单约束。声明了Bash(python scripts/*.py)就只能跑 scripts 下的 Python其他命令需要用户现场批准。这种声明式按需加载是 Skill 纪律性的来源——目录里可以放很多资源但任何一次执行都只碰正文明确指向的那几个。三、再看一遍完整的运行流程3 节讲了三层加载的静态划分这里把它展开成一次真实对话中发生了什么。假设用户说”帮我合并这两个 PDF”① 启动阶段Agent 启动 → 扫描 Skill 目录 → 把每个 SKILL.md 的 name description 加载进系统提示常驻 ② 发现阶段用户说帮我合并这两个 PDF → Agent 在常驻的元数据里做语义匹配 → 命中 pdf-processingdescription 中含合并 PDF关键词③ 激活阶段把 pdf-processing/SKILL.md 的完整正文注入上下文 → 模型看到处理 PDF 可调用 scripts/merge.py④ 执行阶段: 模型决定调用脚本 → 通过 Bash 工具跑 scripts/merge.py input1.pdf input2.pdf → 如果遇到表单字段问题按需读取 references/FORMS.md⑤ 返回阶段整合脚本输出 → 生成自然语言回复 → 资源层脚本输出、FORMS.md滚出上下文 下一轮对话不再占用 token整条流水线里真正常驻上下文的只有第①步的元数据正文在第③步进出资源在第④步进出该走就走。这就是为什么一个 Agent 可以装几十上百个 Skill 而不爆上下文。四、SKILL.md 规范一份文件的解剖1 YAML Frontmatter元数据契约Frontmatter 是文件顶部、由—包围的 YAML 块定义了 Skill 的身份和元数据---name: pdf-processing 必需description: 从 PDF 中提取文本和表格、填写表单、合并多个 PDF。当用户提到 PDF、表单、文档提取时使用。 # 必需license: Apache-2.0 # 可选compatibility: Requires pdftotext, jq # 可选allowed-tools: Bash(pdftotext:*) Read Write # 可选实验性metadata: # 可选 author: example-org version: 1.0---字段速查表字段是否必需核心约束name✅1–64 字符小写字母 数字 连字符必须与目录名一致不能以 - 开头/结尾不能含 –description✅1–1024 字符描述做什么 何时用包含触发关键词license❌许可证名或捆绑许可文件名compatibility❌≤ 500 字符环境要求依赖、网络、目标产品allowed-tools❌预批准的工具白名单减少人工确认实验性metadata❌任意 key-value用于自定义扩展2 description 是决定 Skill 命运的字段description是 Agent 判断”要不要激活这个 Skill”的唯一语义依据。写好它几乎决定了 Skill 的成败❌ 差的示例——过于模糊匹配不到任何具体意图description: Helps with PDFs.# ✅ 好的示例——讲清楚做什么 何时触发 包含关键词description: 从 PDF 或 Excel 财报中提取关键指标营收、净利润、毛利率 生成结构化摘要和趋势图表。当用户提到财报、财务分析、 季度报告、利润表时触发。三条可操作的原则描述即触发器把用户可能说出口的关键词明确写进去说明独特价值和其他 Skill 能区分开避免匹配时混淆定义适用边界说明什么场景不适用防止误触发3 Markdown 正文给 LLM 的执行指令Frontmatter 之后就是正文。格式不限但有章法。推荐结构概述Overview这个 Skill 能做什么一句话讲清核心能力工作流程Workflow分步骤的操作说明越具体越好示例Examples输入 → 输出的 Few-shot 样例这是最便宜、最有效的指令边界条件Edge Cases常见坑和容易搞错的地方可用脚本 / 资源如果有scripts/或references/在这里说明什么时候用硬约束保持SKILL.md正文 500 行以内。更长的参考资料应拆分到references/按需加载否则会把指令层撑爆。4 可选目录scripts / references / assetspdf-processing/├── SKILL.md 必需主入口├── LICENSE.txt # 可选许可证├── scripts/ # 可选可执行代码│ ├── extract.py│ └── merge.sh├── references/ # 可选详细参考文档按需加载│ ├── REFERENCE.md│ └── FORMS.md└── assets/ # 可选模板、图表、数据 └── template.pdf每个目录各司其职目录用途设计要点scripts/可执行脚本自包含或清晰声明依赖无交互结构化输出有意义的错误信息references/补充参考文档按需加载单文件聚焦单一主题避免深层嵌套引用assets/静态资源模板、图表、数据文件5 脚本设计的五条铁律如果你的 Skill 带了scripts/脚本要为”Agent 消费”而设计和给人用的 CLI 有明显差异拒绝交互式提示Agent 跑在非交互 shell 里所有输入必须通过 flag / 环境变量 / stdin 传入–help即说明书Agent 靠–help学你的接口要简洁、带例子错误消息要可操作”Error: invalid input” 是在浪费 Agent 的下一回合要说”期望什么、收到什么、该怎么改”结构化输出stdout 输出 JSON / CSV诊断信息写 stderr便于组合jq /awk幂等 退出码Agent 会重试操作要幂等用不同退出码区分不同错误类型五、Skill 的生命周期从静态文件到动态能力一个 Skill 从硬盘上的一堆文件到被 Agent 真正用起来只会经过四个关键阶段——发现 → 加载 → 触发 → 调用。和前面章节的脉络完全一致只是这次按时间轴把它们串起来看。阶段发生时机做的事上下文变化① 发现Agent 启动时扫描 Skill 目录解析每个 SKILL.md 的 Frontmatter还未注入上下文② 加载启动完成前把所有 Skill 的 name description 注入上下文N × ~100 tokens常驻③ 触发用户消息到达时语义匹配命中某个 Skill把它的 SKILL.md 正文注入上下文正文 5k tokens④ 调用执行过程中按正文指引用 Read / Bash 读取 scripts/ references/ assets/按需追加阶段 ① 发现扫描 Skill 目录Agent 启动时先做一件事——到约定的目录下把所有 Skill 扒一遍。常见路径有两处用户级/.claude/skills/或/.workbuddy/skills/项目级./.claude/skills/或./.workbuddy/skills/对每个子目录Agent 检查是否有SKILL.md有就解析顶部的 YAML Frontmatter提取name和description格式不对、缺必填字段的直接跳过。这一步只读 Frontmatter不会碰正文和其他文件。产出一张本地能力清单Agent 知道”有哪些 Skill、叫什么、能做什么”。阶段 ② 加载元数据进入上下文扫出来的清单要被 Agent 真正”意识到”就得进入上下文。加载阶段只把每个 Skill 的name description注入系统提示——典型情况下每个 Skill ~100 tokens。这就是为什么 2.3 节说”50 个 Skill 常驻只要 ~5k token”不是因为 Skill 小而是加载阶段只塞了名片。加载完成后Agent 的”潜意识”里就有了一张能力目录卡片看到用户请求时可以在这张卡片上做语义匹配。阶段 ③ 触发正文进入上下文用户发来一条消息Agent 第一反应是在卡片上找最匹配的 Skill。匹配靠两个东西用户消息里的关键词Skill description 里埋的触发词这也是为什么 description 要把”财报 / 利润表 / 季度报告”这些词明写出来命中后Agent 做一件事——把这个 Skill 的SKILL.md完整正文读出来注入当前对话的上下文。这一步前Agent 只知道”有个叫pdf-processing的能做 PDF”这一步后它知道了”要先读 FORMS.md、再调用 extract.py、参数怎么传、边界有哪些”。触发是多次性的对话里每次用户意图变了Agent 会重新匹配、重新触发不同的 Skill 正文可以轮流进入上下文。阶段 ④ 调用按正文指引操作资源正文进入上下文后Agent 开始按里面的指令干活。2.4 节讲的”声明式按需加载”正是在这一阶段发生正文说”先读references/FORMS.md” → 用Read把文件内容注入上下文正文说”调用scripts/extract.py --input …” → 用Bash执行把 stdout 注入上下文正文说”从assets/template.pdf开始” → 读取模板作为生成起点调用可以反复发生一个任务里 Agent 可能多次 Read、多次 Bash也可能结合其他 Tool 和 MCP。每次调用产生的输出都会回到上下文供 Agent 决定下一步。四个阶段的节奏对比阶段频次Token 开销是否可感知① 发现启动一次无不进上下文用户不可感知② 加载启动一次N × ~100 tokens 常驻用户不可感知③ 触发每次意图切换单次 5k tokens用户可感知回复变专业了④ 调用每次具体动作按需追加用户可感知文件被读、脚本被跑越靠前越不可见但越基础越靠后越频繁但越直接产生价值。这四个阶段串在一起就是 Skill 从文件系统到真实能力的全部旅程。六、Skill、Tool、MCP 的关系分层架构很多人会困惑Tool、MCP、Skill 这三个概念到底是什么关系它们不是竞争而是处在不同的抽象层次各司其职。1 三层抽象┌─ Skill 层知识与策略──────────────────────────--───┐│ 何时用 / 怎么用 / 按什么顺序 / 注意什么边界 ││ 回答的是在什么场景下做什么 │└────────────────────────────────────────────────-─-─┘ ↓ 指导┌─ MCP 层标准化协议──────────────────────────────--─┐│ JSON-RPC 2.0 统一接口Tools / Resources / Prompts ││ 回答的是怎么标准化地连接外部系统 │└──────────────────────────────────────────────--────┘ ↓ 承载┌─ Tool 层原子能力─────────────────────────────--───┐│ Bash / Read / Write / WebFetch / MCP Tool ││ 回答的是一个动作的最小执行单元 │└────────────────────────────────────────────────--──┘2 一张表看完三者差异维度ToolMCPSkill本质原子操作函数通信协议标准知识策略封装载体函数 / 可执行程序JSON-RPC 消息格式SKILL.md 脚本 配置抽象层次最低做一件事中间统一接口最高编排多件事有没有领域知识无无有解决什么问题“怎么做一个动作”“怎么标准化连接”“何时做、做什么、怎么组合”复用粒度跨 Skill 通用跨框架跨模型通用面向特定任务领域一个直观的例子“用 GitHub 做代码审查”ToolBash(curl:*)、WebFetch—— 能发 HTTP 请求MCPGitHub MCP Server 暴露list_pull_requests、create_pr_comment—— 标准化访问 GitHubSkillcode-review-workflow—— 告诉 Agent”先获取 PR 详情再逐文件审查 Python 按 PEP 8 / JavaScript 检查未处理的 Promise最后用create_pr_comment发严重问题建议性意见留到总结”三者合在一起才完整Tool 提供能力MCP 提供连接Skill 提供智慧。3 两条务必记住的原则原则一Skill 目录里放mcp.json不会生效。MCP 配置由 Agent 框架在项目级或用户级统一加载如.mcp.json/~/.claude.json不属于任何单个 Skill。Skill 只负责”描述怎么用已连上的 MCP 工具”。原则二SKILL.md 不要重复 MCP Schema。MCP Server 运行时会通过tools/list动态告诉 Agent 工具的参数 Schema。SKILL.md 只应该写 MCP 无法表达的业务经验✅ 该写的稳定、MCP 不提供❌ 不该写的会漂移、MCP 已提供业务意图 → 工具选择策略工具参数的字段名和类型多工具组合的执行顺序工具的基础功能描述已知边界条件和坑必填 / 可选参数列表认证和权限注意事项工具名运行时动态获取结果的业务解读方式返回值结构七、实战如何写一个高质量的 Skill理论讲完来点能马上用的。以下是写 Skill 时绕不过去的 10 个要点1 命名与描述动名词命名processing-pdfs、analyzing-spreadsheets而不是documents、data。Skill是个”能力”名字里要有动作第三人称描述”分析 PDF 文档”不是”你可以用这个来分析 PDF”——正文是写给 LLM 看的系统提示不是教程触发词要前置description里把用户口语化的关键词如”财报”、”利润表”、”季度报告”明确写出来语义匹配才准2 模块化与单一职责一个Skill 只做一件事与其做”通用数据分析”不如拆成mysql-employees-analysis、sales-data-analysis、user-behavior-analysis。范围越宽匹配精度越低复杂任务拆子 Agent像skill-creator那样把”评分、分析、对比”这些专业子任务委托给agents/下的专门 Agent 模板每个任务一个上下文3 渐进式披露策略正文控制在 500 行以内超过就拆到references/通过”需要做 X 时阅读references/X.md“的方式按需加载示例驱动在正文里放 2–3 个 Few-shot 示例用户输入 → 期望输出往往比一大段文字指令更有效4 脚本与确定性能用脚本就别让 LLM 硬算格式转换、复杂计算、二进制处理交给scripts/下的脚本比让模型生成更稳定、更便宜allowed-tools最小权限只预批准这个 Skill 真正需要的工具如Bash(git:*) Read降低误操作和安全风险5 可测试与可迭代配一份评估集几条”应该触发”和”不应该触发”的测试用例存到evals/evals.json每次改完description都跑一遍防止触发漂移最后一个可以直接抄的最小可用模板---name: my-skilldescription: 这个 Skill 做 X当用户提到 关键词A、关键词B、关键词C 时触发。allowed-tools: Read Write--- My Skill## 概述一句话讲清核心能力。## 工作流程1. 第一步...2. 第二步...3. 第三步...## 示例输入...输出...## 边界条件- 场景 X 时改用 ...- 遇到 Y 情况返回 ...八、结语Skill 改变了什么Agent Skills 不是一个”又一个新协议”它提出的是一个关注点分离的架构思想连接性MCP和能力Skill应该分离原子动作Tool和 编排策略Skill应该分离静态知识元数据和动态资源指令 脚本应该分离这三层分离一旦打通你会发现一些美好的事情开始发生成本可控50 个 Skill 常驻只要 5k token按需加载让上下文永远精炼知识可沉淀团队的业务经验、避坑指南、工作流 SOP终于有了可版本化的载体能力可流通一个 Skill 目录就能分享社区可以像 NPM 一样繁荣起来维护可解耦MCP 团队改基础设施Skill 团队改业务逻辑各管一摊从 Prompt Engineering到 Function Calling到 MCP再到 Skills——每一次演进都在解决上一代留下的问题。Skill 不会是终点但它把”Agent 如何掌握领域知识”这件事向前推进了一大步。如何学习大模型 AI 由于新岗位的生产效率要优于被取代岗位的生产效率所以实际上整个社会的生产效率是提升的。但是具体到个人只能说是“最先掌握AI的人将会比较晚掌握AI的人有竞争优势”。这句话放在计算机、互联网、移动互联网的开局时期都是一样的道理。我在一线科技企业深耕十二载见证过太多因技术卡位而跃迁的案例。那些率先拥抱 AI 的同事早已在效率与薪资上形成代际优势我意识到有很多经验和知识值得分享给大家也可以通过我们的能力和经验解答大家在大模型的学习中的很多困惑。我们整理出这套AI 大模型突围资料包✅ 从零到一的 AI 学习路径图✅ 大模型调优实战手册附医疗/金融等大厂真实案例✅ 百度/阿里专家闭门录播课✅ 大模型当下最新行业报告✅ 真实大厂面试真题✅ 2026 最新岗位需求图谱所有资料 ⚡️ 朋友们如果有需要《AI大模型入门进阶学习资源包》下方扫码获取~① 全套AI大模型应用开发视频教程包含提示工程、RAG、LangChain、Agent、模型微调与部署、DeepSeek等技术点② 大模型系统化学习路线作为学习AI大模型技术的新手方向至关重要。 正确的学习路线可以为你节省时间少走弯路方向不对努力白费。这里我给大家准备了一份最科学最系统的学习成长路线图和学习规划带你从零基础入门到精通③ 大模型学习书籍文档学习AI大模型离不开书籍文档我精选了一系列大模型技术的书籍和学习文档电子版它们由领域内的顶尖专家撰写内容全面、深入、详尽为你学习大模型提供坚实的理论基础。④ AI大模型最新行业报告2025最新行业报告针对不同行业的现状、趋势、问题、机会等进行系统地调研和评估以了解哪些行业更适合引入大模型的技术和应用以及在哪些方面可以发挥大模型的优势。⑤ 大模型项目实战配套源码学以致用在项目实战中检验和巩固你所学到的知识同时为你找工作就业和职业发展打下坚实的基础。⑥ 大模型大厂面试真题面试不仅是技术的较量更需要充分的准备。在你已经掌握了大模型技术之后就需要开始准备面试我精心整理了一份大模型面试题库涵盖当前面试中可能遇到的各种技术问题让你在面试中游刃有余。以上资料如何领取为什么大家都在学大模型最近科技巨头英特尔宣布裁员2万人传统岗位不断缩减但AI相关技术岗疯狂扩招有3-5年经验大厂薪资就能给到50K*20薪不出1年“有AI项目经验”将成为投递简历的门槛。风口之下与其像“温水煮青蛙”一样坐等被行业淘汰不如先人一步掌握AI大模型原理应用技术项目实操经验“顺风”翻盘这些资料真的有用吗这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理现任上海殷泊信息科技CEO其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证服务航天科工、国家电网等1000企业以第一作者在IEEE Transactions发表论文50篇获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。资料内容涵盖了从入门到进阶的各类视频教程和实战项目无论你是小白还是有些技术基础的技术人员这份资料都绝对能帮助你提升薪资待遇转行大模型岗位。以上全套大模型资料如何领取https://mp.weixin.qq.com/s/sf5dh9JwehICXFrrIYtgYw
