Skills面试题，33道 Skill 八股文（1万字40张手绘图），面渣逆袭必看👍

01、什么是 Skills？

面试官好，Skills 简单来说就是一套预定义的指令集，它告诉 AI 在遇到特定类型的任务时应该怎么做、遵循什么规范、输出什么格式。

具体来讲，一个 Skill 通常就是一个 SKILL.md 文件，里面包含了针对某类任务的最佳实践。

比如说有专门生成 Word 文档的 Skill，里面会写清楚字体怎么设、标题层级怎么处理、页眉页脚怎么加；也有专门做 PPT 的 Skill，规定了幻灯片布局、配色、动画等细节。这些经验是经过大量试错沉淀下来的，不是临时拍脑袋写的 Prompt。

从架构上看，每个 Skill 有三个关键要素：名称用来标识，描述用来让系统判断什么时候该触发这个 Skill，文件路径指向具体的指令内容。

当用户发起一个请求时，Agent 会根据请求内容自动匹配相关的 Skill，把对应的指令加载进上下文，AI 就能按照这套规范来执行任务。

举个例子，如果用户说“帮我做一份季度汇报的 PPT”，Agent 会自动识别出这是一个 PPT 生成任务，然后加载 pptx 这个 Skill，AI 在生成幻灯片的时候就会遵循里面定义的排版规范和设计原则，而不是随意发挥。

所以本质上，Skills 就是把零散的 Prompt 工程经验模块化、标准化了，让 AI 的输出质量更稳定、更可控。它和传统的 Prompt 模板最大的区别在于，它是系统级的自动调度，不需要人工干预。

参考答案版本 2

Skills 是 Anthropic 推出的一种结构化知识包机制，用于增强 Claude 在特定任务上的能力。它不是 API 调用，而是把专业知识、指令、脚本打包成一个文件夹，让 Claude 按需加载。

核心概念：

• Skills 是一个文件夹，包含 SKILL.md 文件（必需）和可选的资源文件
• SKILL.md 包含 YAML 元数据（name、description）和 Markdown 指令
• Claude 根据任务需要，动态加载相关 Skill 的内容

三者对比：

举个例子：假设要让 Claude 更擅长处理 PDF，用 Skills 的方式：

pdf-skill/
├── SKILL.md          # 定义如何处理 PDF 的指令
├── examples/         # 示例用法
└── scripts/          # 辅助脚本

而不是写一个 parsePdf() 的 Function。Skills 更像是教会 Claude 一项技能，而不是给 Claude 一个工具。

参考答案版本 3

公共的 Prompt 就是 Skills。

每次让 AI 写代码我们需要告诉它“用 Java”、“遵循阿里巴巴代码规范”、“注释要写清楚”？

这些重复的指令，就是软件开发中的“重复代码”。在软件开发中，我们解决重复代码的方法是“封装复用”。

Skills 做的就是这件事。它把这些公共的 Prompt 封装起来，变成一个“技能模块”。下次需要用的时候，直接调用这个 Skill 就行，不用再把那些指令重复一遍。

这就像我们写了一个工具类，以后所有项目都能直接调用。区别在于，这个工具类是给 AI 用的，不是给人用的。

参考答案版本4

Skill 是 Claude Code 的扩展机制，本质上是一个包含 SKILL.md 文件和可选资源（scripts、references、assets）目录。它能把 Claude 从通用 AI 变成某个领域的专家。

比如说，我们装了一个 PDF 处理的 Skill，Claude 就能帮我们合并 PDF、提取文字、填写表单。装一个前端开发的 Skill，它就能帮我们生成符合团队规范的 React 组件。

一个标准的 Skill 结构长这样：

skill-name/
├── SKILL.md          # 必需，包含元数据和指令
├── scripts/          # 可选，可执行脚本
├── references/       # 可选，参考文档
└── assets/           # 可选，模板、图片等资源

01-1、Skills 的目录位置了解吗？

不同工具的 Skills 存放位置：

这里要说明两点，除了 .codex 目录，Codex 还支持 .agent 目录；~ 是相对你的根目录，不带的话，相对你的项目目录。

memo：2026年4月3日修改至此，今天有球友发来喜报说，拿到了腾讯的暑期实习offer，还称赞了二哥修改的简历有帮助，真是太棒了！祝贺这位小伙伴，也希望其他小伙伴都能拿到心仪的offer！加油！💪

02、为什么 Skills 不直接把所有内容都加载进去？

面试官好，这个问题其实涉及到大模型一个很核心的限制，就是上下文窗口（Context Window）是有限的。

不管模型的上下文窗口有多大，它终归是一个有上限的资源。

如果把所有 Skills 的内容一股脑全塞进去，首先会大量占用上下文空间，留给用户实际任务的空间就被压缩了。

比如说一共有十几个 Skill，每个几千字，全加载进去可能就占掉好几万 token，真正用来处理用户需求的空间就很紧张了。

其次是注意力稀释的问题。大模型在处理长上下文时，信息越多，对每条指令的关注度越低，容易出现“该遵循的规范没遵循、不相关的规范反而干扰了输出”这种情况。

只加载当前任务相关的 Skill，模型的注意力更集中，执行质量也更高。

第三点是性能和成本。token 数量直接影响推理速度和 API 调用费用，全量加载意味着每次请求都要多处理大量无关内容，响应变慢，成本也上去了，这在生产环境里是不可接受的。

所以现在的设计思路其实很像软件工程里的按需加载（Lazy Loading）。系统先通过 Skill 的名称和描述做一次轻量级匹配，判断当前任务需要哪些 Skill，然后只把相关的加载进来。这样既保证了指令的精准性，又最大化利用了上下文空间。

这个设计理念在很多地方都能看到类似思路，比如 RAG 也是先检索再生成，而不是把整个知识库塞给模型。核心逻辑是一样的：在有限的上下文里放最有价值的信息，而不是最多的信息。

参考答案版本 2

AI 的工作空间是有限的。

我们知道 AI 在工作的时候，并不是一个无限的资源空间，而是运行在一个特定大小的窗口上。

也就是上下文窗口（Context Window）。我的Claude Code 配的是GLM-5，目前大小是 200K，看起来很大，但真用起来，会发现很快就不够用了。

如果有 100 个 Skills，每个 Skill 的完整内容都是几千字的 Prompt，全部加载进去，上下文窗口直接爆炸。AI 还没开始干活，光加载这些 Skills 就把 token 用完了。

所以 Skills 的设计理念是：不是让 AI 知道更多，而是让 AI 在恰当的时间知道恰当的事。

这就是“渐进式披露（Progressive Disclosure）”架构的核心思想。

02-1、具体怎么实现渐进式披露呢？

面试官好，渐进式披露在 Skills 这个场景下，实现起来大致分三个层次。

第一层是轻量级索引匹配。系统不会一上来就读取所有 Skill 的完整内容，而是先维护一份索引，每个 Skill 只暴露名称和描述这两个字段。

当用户的请求进来后，系统根据请求内容和这些描述做语义匹配，判断哪些 Skill 跟当前任务相关。这一步的信息量非常小，可能每个 Skill 就几十个字的描述，十几个 Skill 加起来也占不了多少 token。

第二层是按需加载完整指令。匹配到相关 Skill 之后，系统才去读取对应的 SKILL.md 文件，把里面的详细规范和最佳实践加载进上下文。

而且一个任务可能匹配到多个 Skill，比如用户要做一份包含图表的 Word 报告，可能同时触发 docx 和 xlsx 两个 Skill，系统会把这两个都加载进来，但其他不相关的就不动。

第三层是执行过程中的逐步展开。即使一个 Skill 被加载了，也不意味着里面所有指令都要一次性全部执行。

很多 Skill 内部本身就是分阶段的，比如先搭骨架、再填内容、最后做格式调整，模型会根据当前执行到哪个阶段去关注对应的指令段落，而不是同时处理所有规则。

这个思路其实在前端工程里特别常见，就像代码分割（Code Splitting）一样。首屏只加载关键资源，用户滚动到哪里再加载哪里的内容。

本质上都是在解决同一个问题：资源有限的情况下，如何让最关键的信息在最需要的时刻出现。放到大模型场景下，这个“资源”就是上下文窗口，“关键信息”就是当前任务真正需要的指令和规范。

参考答案版本2

搞个分级缓存。当输入 Prompt 的时候，不要带上全量的 Skills 信息，而是最基本的元信息。AI 会按照语意进行匹配，匹配到了才会加载实际的内容。

这个过程分为三步：

第一步：发现阶段。 启动时，AI 扫描所有 Skills 的元数据，建立一个“技能注册表”。这个注册表只包含最基本的信息：Skill 名称、描述、触发关键词。就像图书馆的目录卡片，只告诉我们书名和位置，不会把整本书都给我们看。

第二步：语义匹配。 当用户输入一个问题，AI 会根据语义去匹配相关的 Skills。比如我们问“帮我写一个 Java 的单例模式”，AI 就会匹配到“Java 代码生成”相关的 Skill。这个过程是动态的，基于向量相似度计算。

第三步：执行阶段。 匹配成功后，才会加载这个 Skill 的完整内容。这时候，AI 才真正“看到”这个 Skill 的详细指令、示例、约束条件。

这三步走完，一个 Skill 才算真正被激活。而那些没被匹配到的 Skills，全程只占用几个 token 的元数据空间。这就是为什么你可以拥有几十上百个 Skills，却不用担心上下文爆炸。

02-2、Skills 的渐进式披露原理是什么？

面试官好，渐进式披露的原理，核心就是信息分层、按需释放，背后对应的是对上下文窗口这个稀缺资源的精细化管理。

可以把它类比成一个漏斗模型。最顶层是粗粒度的元信息，也就是每个 Skill 的名称和一段简短描述，这些信息常驻在系统提示词里，体量很小，目的是让模型具备“我有哪些能力可用”的全局认知。

中间层是完整的指令文件，只有当上层匹配命中之后，系统才通过读取文件的方式把具体内容拉进上下文。最底层是执行时的细节展开，模型在实际生成过程中逐步消化指令，分阶段完成任务。

这个设计背后有一个很重要的原理，就是信息论里的相关性过滤。上下文窗口本质上是一个固定容量的信道，往里面塞的信息越多，信噪比越低，模型的输出质量就越差。

渐进式披露做的事情就是在每个阶段只保留信噪比最高的那部分信息，把噪声挡在外面。

从工程实现的角度看，它依赖的是一个两阶段检索机制。第一阶段是基于描述的语义匹配，成本极低，相当于在一个很小的索引上做一次查找；第二阶段才是文件级别的内容加载，成本相对高但精准度也高，因为已经经过了第一阶段的过滤。

这跟数据库查询里先走索引再回表的逻辑是一样的，先用最小代价缩小范围，再精确获取需要的数据。

所以渐进式披露的本质，就是用多级过滤的方式，在有限的上下文空间里最大化有效信息密度。

它不是一个多复杂的算法问题，而是一个资源调度问题，核心思想在很多系统设计里都能看到，比如 CPU 的多级缓存、CDN 的分层分发，底层逻辑都是相通的。

参考答案版本2

考察点：理解 Skills 的核心设计理念

参考答案：

渐进式披露是 Skills 最核心的设计思想，解决的是上下文窗口有限的问题。

问题背景：传统做法是把所有工具说明、使用指南都塞进 System Prompt，导致：Token 消耗巨大（可能几万 Token 的说明）、无关信息干扰模型判断、上下文空间被挤占。

渐进式披露的三层加载：

就像一本技术手册，目录页（元数据）让我们快速知道有哪些内容，章节概述（主文档）告诉我们怎么用，详细示例（附加文件）只在需要时翻阅。

好处是 Token 高效：不需要时不加载，响应更准确：没有无关信息干扰，扩展性好：可以有几百个 Skills，不会撑爆上下文。

memo：2026年4月3日修改至此，今天有球友发来喜报说，拿到了美团的暑期实习offer，果然4月正是收获的季节啊！加油！💪

03、直接把 Prompt 保存到笔记里，下次复制粘贴不就行了？为什么还要搞个 Skills？

面试官好，关于这个问题，我的理解是这样的。

复制粘贴 Prompt 最大的问题在于上下文管理成本高。一个好的 Prompt 往往很长，场景多了之后笔记里攒几十条，每次得自己判断该用哪个，找起来费劲，而且不同场景需要微调，改完还不一定记得同步回去，版本就乱了。

Skills 解决的核心问题是自动化触发和结构化管理。Prompt 封装成 Skill 之后，它就不再是一段死文本，而是一个可以被系统自动识别、自动加载的模块。

比如让 Claude 写 Word 文档，它会自动读取对应的 SKILL.md 拿到最佳实践，不需要人工去翻笔记。这就像手动挡和自动挡的区别，都能开，但自动挡明显更省心。

第二点是可复用和可协作。Skills 有标准结构，有名字、描述、触发条件，可以在团队内共享，保证输出质量一致。复制粘贴的话，每个人手里的 Prompt 版本可能都不一样，质量参差不齐。

第三点是可组合。一个复杂任务可能需要同时加载好几个 Skill，系统会自动判断该用哪些，靠手动粘贴很难做到这一点，不可能每次都把三四个 Prompt 全部粘进去还不搞混顺序。

所以本质上，复制粘贴是把菜谱抄在纸上自己翻，Skills 是把菜谱录入智能系统让它自动调取。效率、一致性和可维护性上，Skills 高出一个台阶。

04、如何创建一个 Skill？

面试官好，创建一个 Skill 其实并不复杂，核心就是写好 SKILL.md 文件，然后把它放到指定目录下。

首先要明确这个 Skill 要解决什么问题。

比如说我想让 AI 在生成技术博客时遵循特定的排版风格和写作规范，那这个 Skill 的定位就很清晰了。

定位清楚之后，接下来就是写 SKILL.md 的内容，这里面一般包含几个部分：第一是任务描述，说明这个 Skill 干什么的；第二是具体的规范和约束，比如标题格式、段落风格、图片占位符怎么写、用什么标点符号；第三是示例，给模型展示一段符合规范的输出长什么样。示例这部分非常关键，很多时候光靠文字描述模型理解不到位，但给一个好的范例它就能快速对齐。

写好 SKILL.md 之后，需要给它配一个触发描述。这个描述的作用是告诉系统在什么场景下应该加载这个 Skill，写得越精准，触发的准确率越高。

比如描述里写“当用户要求生成微信公众号风格的技术文章时触发”，那系统在遇到相关请求时就会自动匹配上来。这个描述相当于 Skill 的“索引词”，直接决定了它能不能在该出现的时候出现。

文件组织上，通常把 SKILL.md 放在一个独立的目录里，如果这个 Skill 执行过程中需要用到模板文件、参考素材之类的辅助资源，也一起放在同一个目录下，保持结构清晰。

开发完之后还有一个很重要的环节是测试和迭代。实际跑几个典型场景，看输出是不是符合预期，哪些地方模型没有遵循规范，回去调整指令的措辞和优先级。

这个过程跟调 Prompt 本质上是一样的，只不过 Skill 的结构化程度更高，迭代起来更有章法，不像散装 Prompt 改来改去容易失控。

所以整体流程就是：明确场景定位、编写指令内容和示例、配好触发描述、放到指定目录、测试迭代优化。门槛不高，但要做好需要对具体任务场景有深入理解，知道模型在哪些环节容易出问题，针对性地去约束。

参考答案版本2

创建 Skill 的核心思路是：将工作中的案例总结提炼（归纳），固化为 Skill，用以应对同类问题（演绎），或是再次反馈完善这个 Skill。

听起来有点抽象，我用一个具体的例子来说明。

假设我们经常需要让 AI 帮忙做“逆向建模”。什么是逆向建模？就是有一段现有的代码，想让 AI 分析它的设计思路，然后生成对应的设计文档或者架构图。

这是开发过程中最高频的场景之一，对应着我们最常见的应用场景：需求迭代。

第一步，观察 Prompt 过程。

“帮我分析这段代码的设计思路，然后画一个架构图。” “注意要标注清楚各个模块的职责。” “用 PlantUML 语法。” “模块之间的关系用箭头表示。”

第二步，总结提炼。把这些指令固化为一个 Skill：

---
name: reverse-modeling
description: 逆向建模，分析代码设计思路并生成架构图
trigger:
  - 逆向建模
  - 代码分析
  - 架构图
---

## 任务目标
分析给定代码的设计思路，生成清晰的架构图。

## 输出要求
1. 标注清楚各个模块的职责
2. 使用 PlantUML 语法
3. 模块之间的关系用箭头表示
4. 包含关键数据流

## 示例
输入：一段 Spring Boot 应用的代码
输出：展示 Co...