一、启动入口：从命令行到 main()#

当我们在命令行中输入 claude 时，下面的流程就启动了

关键代码位置：src/main.tsx:1918-1932

1
typescript 体验AI代码助手 代码解读复制代码// 同步注册：必须在 getCommands 之前完成
2
if (process.env.CLAUDE_CODE_ENTRYPOINT !== 'local-agent') {
3
  initBuiltinPlugins();
4
  initBundledSkills();
5
}
6
// 并行启动
7
const setupPromise = setup(preSetupCwd, ...);
8
const commandsPromise = worktreeEnabled ? null : getCommands(preSetupCwd);

为什么要这样设计 ： initBundledSkills() 是纯内存的数组 push 操作（ bundledSkills.push(skill) ），耗时 <1ms。它必须在 getCommands() 启动前完成，否则 getBundledSkills() 返回空数组，结果技能会丢失。

二、技能加载#

当我们在 .claude/skills/ 目录、项目目录等地方放了 skills 时，会通过 IO 的方式读取 skills，整体的流程如下：

loadAllCommands 的合并顺序（优先级从高到低）：

1
typescript 体验AI代码助手 代码解读复制代码// 如果有重复的，会进行去重去处理
2
return [
3
  ...bundledSkills,          // 内嵌技能
4
  ...builtinPluginSkills,    // 内置插件技能
5
  ...skillDirCommands,       // 磁盘上的技能（用户/项目/管理）
6
  ...workflowCommands,       // 工作流命令
7
  ...pluginCommands,         // 插件命令
8
  ...pluginSkills,           // 插件技能
9
  ...COMMANDS(),             // 内置命令（非技能类型）
10
]

三、磁盘技能加载：getSkillDirCommands#

关键代码位置：getSkillDirCommands:

这是最核心的技能加载逻辑，负责从文件系统读取 SKILL.md 文件。

1
plain 体验AI代码助手 代码解读复制代码getSkillDirCommands(cwd) 搜索以下目录：
2
    │
3
    ├── Managed Skills      ←── /etc/claude/.claude/skills/ （企业策略管理）
4
    ├── User Skills         ←── ~/.claude/skills/            （用户全局技能）
5
    ├── Project Skills      ←── .claude/skills/              （项目级技能，沿目录树向上搜索）
6
    ├── Additional Skills   ←── --add-dir 指定的目录/.claude/skills/
7
    └── Legacy Commands     ←── .claude/commands/            （旧格式，向后兼容）

1
typescript 体验AI代码助手 代码解读复制代码const [managedSkills, userSkills, projectSkills, additionalSkills, legacyCommands] =
2
  await Promise.all([
3
    loadSkillsFromSkillsDir(managedSkillsDir, 'policySettings'),
4
    loadSkillsFromSkillsDir(userSkillsDir, 'userSettings'),
5
    Promise.all(projectSkillsDirs.map(dir => loadSkillsFromSkillsDir(dir, 'projectSettings'))),
6
    Promise.all(additionalDirs.map(dir => loadSkillsFromSkillsDir(join(dir, '.claude/skills'), ...))),
7
    loadSkillsFromCommandsDir(cwd),
8
  ]);

1
plain 体验AI代码助手 代码解读复制代码loadSkillsFromSkillsDir(basePath, source)
2
    │
3
    ├── 1. fs.readdir(basePath)               ←── 读取目录列表
4
    │
5
    └── 2. 对每个 entry 并行处理：
6
        │
7
        ├── 跳过非目录项（只支持 skill-name/SKILL.md 格式）
8
        │
9
        ├── 读取 skill-name/SKILL.md 文件内容
10
        │
11
        ├── parseFrontmatter(content)         ←── 解析 YAML frontmatter
12
        │   输入: "---\ndescription: ...\n---\n# Skill body"
13
        │   输出: { frontmatter: {...}, content: "# Skill body" }
14
        │
15
        ├── parseSkillFrontmatterFields(...)  ←── 提取结构化字段
16
        │   提取: description, allowedTools, model, hooks, paths, effort...
17
        │
18
        └── createSkillCommand(...)           ←── 构建 Command 对象
19
            闭包捕获 markdownContent，延迟到调用时再编译

1
typescript 体验AI代码助手 代码解读复制代码// 通过 realpath 检测符号链接和重复的父目录
2
const fileIds = await Promise.all(
3
  allSkillsWithPaths.map(({ filePath }) => getFileIdentity(filePath))
4
);
5

6
// 先到先得：优先级由合并顺序决定
7
// managed > user > project > additional > legacy
8
for (entry of allSkillsWithPaths) {
9
  if (seenFileIds.has(fileId)) continue;  // 跳过重复
10
  seenFileIds.set(fileId, skill.source);
11
  deduplicatedSkills.push(skill);
12
}

1
yaml 体验AI代码助手 代码解读复制代码---
2
description: React 组件开发助手
3
paths: src/components/**, src/pages/**
4
---
5

6
当用户操作的文件路径匹配 paths 模式时，技能被激活并加入动态技能列表。

四、SKILL.md 文件解析#

1
yaml 体验AI代码助手 代码解读复制代码---
2
# 基础信息
3
name: 显示名称（可选，默认取目录名）
4
description: 技能描述
5
argument-hint: <参数提示文本>
6
arguments: [arg1, arg2]
7

8
# 模型和行为控制
9
model: claude-sonnet-4-6       # 指定使用的模型
10
effort: high                    # low | medium | high | 整数
11
context: fork                   # fork = 独立子进程执行，inline = 主线程
12
agent: agent-name               # 指定 agent 定义
13

14
# 权限控制
15
allowed-tools: [Bash, Read, Write]
16
user-invocable: true            # 用户是否可通过 /name 调用
17
disable-model-invocation: false # 模型是否可通过 SkillTool 调用
18

19
# 条件激活
20
paths: src/**/*.tsx             # 匹配文件路径时自动激活
21

22
# 钩子
23
hooks:
24
  PreToolUse:
25
    - command: "eslint $FILE"
26
      matcher: "Write|Edit"
27

28
# Shell 执行环境
29
shell: bash
30

31
# 版本
32
version: "1.0"
33
---

1
typescript 体验AI代码助手 代码解读复制代码{
2
  type: 'prompt',              // 技能都是 prompt 类型
3
  name: 'skill-name',          // 目录名（唯一标识）
4
  description: '...',          // 从 frontmatter 或正文第一行提取
5
  source: 'projectSettings',   // 来源：userSettings / projectSettings / policySettings
6
  loadedFrom: 'skills',        // 加载方式：skills / bundled / plugin / mcp
7
  allowedTools: ['Bash'],      // 额外允许的工具
8
  model: 'claude-sonnet-4-6',  // 模型覆盖
9
  effort: 'high',              // 努力程度
10
  userInvocable: true,         // 用户可调用
11
  context: 'fork',             // 执行上下文
12
  hooks: {...},                // 钩子配置
13
  paths: ['src/**/*.tsx'],     // 条件路径
14
  contentLength: 1234,         // SKILL.md 内容长度
15
  skillRoot: '/path/to/skill', // 技能目录路径
16

17
  // 核心：延迟加载闭包
18
  getPromptForCommand: async (args, toolUseContext) => {...}
19
}

五、延迟加载机制：getPromptForCommand#

技能内容在 启动时只解析 frontmatter ，SKILL.md 的正文内容通过闭包捕获，仅在用户调用 /skill-name 时才执行完整的”编译”过程。

设计权衡 ：启动时只解析 frontmatter（用于技能列表展示），正文编译延迟到调用时。这使得启动速度快，同时支持动态内容（shell 命令在每次调用时执行获取最新结果）。

六、动态技能发现#

除了启动时加载，系统还支持在会话过程中动态发现新技能。

1
plain 体验AI代码助手 代码解读复制代码discoverSkillDirsForPaths(filePaths, cwd)
2
    │
3
    ├── 对每个 filePath：
4
    │   从文件父目录开始，向上遍历到 cwd（不含 cwd）
5
    │   每级检查是否存在 .claude/skills/ 目录
6
    │   记录到 dynamicSkillDirs（去重用）
7
    │
8
    └── 返回新发现的目录列表（按深度降序排列）

1
plain 体验AI代码助手 代码解读复制代码addSkillDirectories(dirs)
2
    │
3
    ├── 对每个目录调用 loadSkillsFromSkillsDir()
4
    │
5
    ├── 深层路径覆盖浅层路径（同名技能）
6
    │
7
    ├── 存入 dynamicSkills Map
8
    │
9
    └── skillsLoaded.emit()  ←── 通知缓存失效

1
typescript 体验AI代码助手 代码解读复制代码clearCommandMemoizationCaches() {
2
  loadAllCommands.cache?.clear?.()
3
  getSkillToolCommands.cache?.clear?.()
4
  getSlashCommandToolSkills.cache?.clear?.()
5
  clearSkillIndexCache?.()         // 技能搜索索引

七、技能优先级总览#

1
plain 体验AI代码助手 代码解读复制代码优先级从高到低：
2

3
1. managed skills          ←── 企业策略目录 /etc/claude/.claude/skills/
4
2. user skills             ←── 用户全局 ~/.claude/skills/
5
3. project skills          ←── 项目目录 .claude/skills/（最近的优先）
6
4. additional skills       ←── --add-dir 指定目录
7
5. legacy commands         ←── 旧格式 .claude/commands/
8
6. bundled skills          ←── 代码内嵌技能
9
7. builtin plugin skills   ←── 内置插件技能
10
8. plugin skills           ←── 第三方插件技能
11

12
同名技能：先注册者胜出（由合并顺序决定）
13
文件去重：realpath 相同的文件只保留第一个

八、关键数据流图#

代码的调用流程图如下#

详细代码调用流程#

1
javascript 体验AI代码助手 代码解读复制代码// 1. 检测是否是 immediate 命令（immediate: true 的 local-jsx 命令）
2
//    这些命令可以在 AI 正在处理时立即执行，不用排队
3
if (!speculationAccept && input.trim().startsWith('/')) {
4
  const commandName = /* 从 input 提取命令名 */
5
    const matchingCommand = commands.find(...)
6
  const shouldTreatAsImmediate = queryGuard.isActive &&
7
    (matchingCommand?.immediate || options?.fromKeybinding)
8

9
  if (matchingCommand && shouldTreatAsImmediate && matchingCommand.type === 'local-jsx') {
10
    // 直接执行，跳过队列 — return early
11
  }
12
}

1
javascript 体验AI代码助手 代码解读复制代码// 如果 AI 正在处理中（queryGuard.isActive），新的输入进入队列
2
if (queryGuard.isActive || isExternalLoading) {
3
  enqueue({ value: finalInput.trim(), mode, pastedContents })
4
  return  // 不执行，等 AI 空闲后 dequeue
5
}
6
// 否则立即执行
7
await executeUserInput({ queuedCommands: [cmd], ... })
8
executeUserInput 是实际执行的核心函数，它内部调用 processUserInput()。

1
javascript 体验AI代码助手 代码解读复制代码// Bash 模式 → processBashCommand()
2
if (mode === 'bash') { ... }
3

4
// Slash command → processSlashCommand()
5
if (inputString !== null && !effectiveSkipSlash && inputString.startsWith('/')) {
6
  const { processSlashCommand } = await import('./processSlashCommand.js')
7
  const slashResult = await processSlashCommand(inputString, ...)
8
  return slashResult
9
}
10

11
// 普通文本 → processTextPrompt()
12
// ...
13
/commit 以 / 开头，命中 slash command 分支。

1
javascript 体验AI代码助手 代码解读复制代码const parsed = parseSlashCommand(inputString)
2
// 如果输入的是 /commit fix: 修复bug
3
// 那么经过 parseSlashCommand 函数转化成： { commandName: 'commit', args: 'fix: 修复bug', isMcp: false }

1
javascript 体验AI代码助手 代码解读复制代码if (!hasCommand(commandName, context.options.commands)) {
2
  // 命令不存在 → 判断是文件路径还是未知命令
3
  if (looksLikeCommand(commandName) && !isFilePath) {
4
    return { messages: [...], shouldQuery: false, resultText: 'Unknown skill: xxx' }
5
  }
6
  // 可能是文件路径（如 /var/log）→ 当普通文本发给模型
7
  return { messages: [...], shouldQuery: true }
8
}

1
javascript 体验AI代码助手 代码解读复制代码if (command.context === 'fork') {
2
  return await executeForkedSlashCommand(...)
3
  // 在独立子 agent 中执行，有自己的上下文和 token 预算, 默认不是 fork
4
}

1
javascript 体验AI代码助手 代码解读复制代码const result = await command.getPromptForCommand(args, context)

1
javascript 体验AI代码助手 代码解读复制代码const messages = [
2
  createUserMessage({ content: metadata }),        // 命令元数据：名称、参数
3
  createUserMessage({ content: skillContent, isMeta: true }),  // SKILL.md 内容（对用户隐藏）
4
  ...attachmentMessages,                           // 附件消息
5
  createAttachmentMessage({                        // 权限声明：allowedTools
6
    type: 'command_permissions',
7
    allowedTools: additionalAllowedTools,
8
  }),
9
]
10
return {
11
  messages,
12
  shouldQuery: true,    // ← 关键：告诉上层需要调用 AI 模型
13
  allowedTools: additionalAllowedTools,
14
  model: command.model,
15
  effort: command.effort,
16
  command,
17
}

1
javascript 体验AI代码助手 代码解读复制代码await onQuery(
2
  newMessages,          // 包含 skill 内容的消息列表
3
  abortController,
4
  shouldQuery,          // true → 需要调用模型
5
  allowedTools ?? [],   // skill 声明的额外工具权限
6
  model ?? mainLoopModel,
7
  onBeforeQuery,
8
  primaryInput,
9
  effort,
10
)

2.1 声明层：SKILL.md 作为 DSL#

SKILL.md 不是 Markdown 文档，而是一个 领域特定语言（DSL） ：

1
yaml 体验AI代码助手 代码解读复制代码---
2
name: ...          # 标识符
3
description: ...   # 语义描述（用于模型路由）
4
when_to_use: ...   # 触发条件（用于模型自主调用）
5
paths: ...         # 文件路径守卫（用于条件激活）
6
allowed-tools: ... # 权限边界
7
model: ...         # 计算资源分配
8
effort: ...        # 推理深度控制
9
context: fork      # 隔离级别
10
hooks: ...         # 生命周期钩子
11
shell: ...         # 执行环境
12
---

每一行 frontmatter 都在回答一个问题： 这个 Skill 需要什么样的运行时保证？

但这里在梳理的时候也发现一个问题 ：目前的 DSL 缺少一个 depends_on 或 composes 字段。Skill 之间的组合目前只能通过 SkillTool 在 Prompt 层面隐式实现，没有声明式的依赖关系。这意味着 Skill 的组合是”调用时发现”而非”设计时保证”，不过如果设计了 depends_on ，也有可能会变成类似于 node_modules 可怕的依赖地狱。而且从现在 skills 开放以来，各种带“毒”的 skills 也在层出不穷，如果加上依赖，这些“毒”会隐藏的更深。

2.2 编译层：getPromptForCommand 作为编译管线#

延迟编译是一个精妙的设计 。启动时只解析 frontmatter（ estimateSkillFrontmatterTokens 只估算元信息的 token），正文编译推迟到调用时。这意味着：

• 启动速度不受 Skill 内容大小影响
• Shell 命令每次调用获取最新结果（而非启动时的快照）
• 代价是每次调用的首次延迟（需执行编译管线）

这是经典的 延迟求值（Lazy Evaluation）策略 ，在 prompt 工程中的应用， 很有意思， pi 在 pi-mono 中也用了同样的设计。

2.3 运行时层：Command 对象作为运行时表示#

createSkillCommand 返回的 Command 对象是一个 闭包 ——捕获了 markdownContent 和所有 frontmatter 字段，但不执行任何计算。直到 getPromptForCommand 被调用时，编译管线才启动。

这个设计有一个重要的推论： Skill 的内容在内存中只有一份拷贝 （闭包捕获引用），但每次调用会产生新的编译结果。这意味着：

• 内存效率 ：N 个 Skill 只占用 N 份 Markdown 的空间
• CPU 效率 ：只有被调用的 Skill 才消耗编译时间
• 一致性代价 ：同一个 Skill 的两次调用，如果中间 Shell 命令结果变了，输出会不同（这个可以测验一下，挺有意思的）

3.1 组合爆炸问题#

当前 Skill 的组合是隐式的——一个 Skill 可以通过 SkillTool 调用另一个 Skill，但：

• 没有声明式的组合关系（ A composes B, C ）
• 没有组合后的 token 预算管理
• 没有组合冲突检测（两个 Skill 对同一文件给出矛盾指令）
• 没有 DAG 调度（Skill A 的输出作为 Skill B 的输入）

如果引入声明式组合，Skill 系统会从一个”Prompt 模板库”进化为一个”Prompt 计算图”。每个 Skill 是一个节点， composes 定义边，运行时按拓扑序执行，每层的输出作为下一层的输入。这能解决：

• Token 预算 ：DAG 调度可以精确计算每层预算
• 冲突检测 ：编译期静态分析 DAG 的输出冲突
• 可观测性 ：每层的输入输出可独立审查

但是这样复杂度也上去了，孰好孰坏，还是要看这个痛点对于用户是否足够痛

3.2 验证闭环缺失#

从代码看，Skill 的执行路径是单向的：

1
plain 体验AI代码助手 代码解读复制代码SKILL.md → parseFrontmatter → createSkillCommand → getPromptForCommand → LLM → 输出

没有反馈回路。如果 LLM 的输出偏离了 Skill 的预期，系统无法：

• 自动检测偏离
• 回退到上一个检查点
• 动态调整 Prompt 参数

hooks 是一个部分解决方案（PostToolUse 可以校验工具调用的输出），但它只能拦截工具调用，不能拦截 LLM 的纯文本输出。

理想的结构是：

1
plain 体验AI代码助手 代码解读复制代码SKILL.md → 编译 → 执行 → 校验 → { 通过 → 输出 | 失败 → 回退 + 重新编译 }

这需要为 Skill 引入 output_schema 或 validation 字段，定义期望的输出结构。这样也让我们自己写 skill 没法写用例去进行测试，都只能边写边调，结果也没法量化。

3.3 版本和演进问题#

Frontmatter 有 version 字段，但代码中 不使用它做任何版本控制逻辑 。它只是一个标签。

当 Skill A 依赖 Skill B 的 v1 行为，而 B 升级到 v2 时，没有机制保证兼容性。这在团队协作中尤其危险——一个人的 Skill 升级可能悄悄破坏另一个人的工作流。

4.1 当前的现实#

Skill 目前自动化的都是 原子操作 ：/commit, /review, /test 等。这些是产研流程中的”叶节点”——它们不依赖其他操作的输出。

1
plain 体验AI代码助手 代码解读复制代码需求 → 技术方案 → 编码 → 测试 → 上线
2
  │        │         │       │       │
3
  │        │         ├─/commit      ├─/deploy
4
  │        │         ├─/review       │
5
  │        │         └─/test         │
6
  │        │                         │
7
  └────────┴───── 尚未有 Skill 介入 ─┘

4.2 Skill 能覆盖的范围（理论最大值）#

如果我们按产研流程的每个阶段来映射 Skill 的能力：

所以产研在 skills 上的探索，就可以以各个节点为基准点，通过各个领域内的专家来编写 skills，然后通过自动化或人工的方式，走通产研流程。

4.3 关键约束：Skill 不等于自动化#

正如上面的产研的覆盖范围做的，我们使用 skills 做嵌入产研流程，一定要放弃惯性思维，我们使用 skills ， 整个过程可能并不一定是提效，而是更好的提高整个研发的质量 ，更深度一点来说。Skill 的核心价值不在于 自动化 （用机器替代人），而在于 跟 AI 交互（交流）的 标准化 （让不同的人产出相同质量的工作）。

标准化带来的是：

1. 降低随机性 ：没有 Skill 时，代码审查质量取决于审查者的经验和状态；有 Skill 时，审查流程由 Skill 保证最低质量
2. 知识传递 ：高级工程师的方法论可以编码为 Skill，而非仅存在于他们的脑子里
3. 可审计性 ：Skill 的执行路径是确定性的，可以回溯和审查

但这有一个隐含假设： Skill 编写者的方法论是正确的 。如果方法论本身有缺陷，Skill 会以工业化的速度传播这个缺陷。所以，归根结底， 不在于要不要 AI 贯穿整个产研流程，也不在要不要使用 skill，而是团队或者编写 skill 的人方法论是正确的，是适合团队和个人的，不然整个方向会越走越偏 。

LLM 发展的四个阶段#

1. 刀耕火种（2022年底）：ChatGPT 爆火，核心是”怎么说才能让它听话”，知识高度碎片化，prompt 工程师出现
2. 开始规模化（2023年初）：Constitutional AI、prompt engineering 官方指南发布，prompt 模板库出现，但模板难以维护、跨任务迁移困难
3. 有标准（2023年6月）：Function Calling 推出，MCP 协议提出，“让模型做什么”和”模型怎么做”开始分离
4. 推出 skill（2025年10月）：Claude Skills 发布，可复用的能力单元出现

Skills 的定义与组成#

简单定义：可被语义触发的能力包，包含领域知识、执行步骤、输出规范与约束条件。

一个 Skill 文件夹包含三样东西：

1. SKILL.md 文件：用自然语言写的”指令”，告诉 AI 这个 Skill 是干什么的、什么情况下该用、怎么用
2. 脚本：Python、JavaScript 等代码，AI 需要”动手”时执行
3. 资源文件：参考文档、模板、配置文件等

Skills 加载阶段#

1
1. managed skills          - 企业策略目录
2
2. user skills             - 用户全局 ~/.claude/skills/
3
3. project skills          - 项目目录 .claude/skills/
4
4. additional skills       - --add-dir 指定目录
5
5. legacy commands         - 旧格式 .claude/commands/
6
6. bundled skills          - 代码内嵌技能
7
7. builtin plugin skills   - 内置插件技能
8
8. plugin skills           - 第三方插件技能

Skills 调用阶段#

Skills 系统的本质：Prompt 编译器#

作者提出了一个非常深刻的见解：Skills 不是简单的”模板”，而是一个 Prompt 编译器。getPromptForCommand 闭包中的多层转换（Base directory 注入、参数替换、环境变量注入、Shell 命令执行、返回结构化输出），每一层都在缩小 LLM 的决策空间，把高熵的人的意图，通过多层转换，编译成低熵的结构化指令。这是理解 Skills 系统设计的关键。

三个正交子系统的设计智慧#

文章将 Skills 系统拆解为三个正交的子系统，这个视角非常有启发性：

1. 声明层（SKILL.md 作为 DSL）：每一个 frontmatter 字段都在回答”这个 Skill 需要什么样的运行时保证？“，这种设计体现了”声明式”优于”命令式”的思想
2. 编译层（getPromptForCommand 作为编译管线）：延迟求值的设计精妙，平衡了启动速度和运行时灵活性
3. 运行时层（Command 对象作为运行时表示）：闭包设计实现了内存效率和 CPU 效率的双重优化

这三个子系统的正交设计，使得 Skills 系统既有灵活性，又有可维护性。

局限性分析：不仅仅是技术问题#

作者指出的三个局限性（组合爆炸、验证闭环缺失、版本和演进问题），本质上反映了 LLM 应用开发从”单技能”向”多技能协作”演进时面临的共性挑战。这些问题不仅仅是技术问题，更是生态问题：

• 组合爆炸：需要类似 npm 的包管理机制，但又不能重蹈 node_modules 的覆辙
• 验证闭环缺失：需要标准化的测试框架和验证机制，让 Skill 可以像传统代码一样进行单元测试和集成测试
• 版本和演进问题：需要语义化版本管理和依赖解析机制，保证 Skill 生态的健康发展

这些局限性既是挑战，也是未来的创新方向。

产研流程视角的重新审视：质量优先于效率#

作者最后提出的”Skill 的核心价值不在于自动化，而在于跟 AI 交互的标准化”这个观点，打破了人们对 AI 的常规认知。通常我们认为 AI 是为了提效，但在产研流程中，标准化带来的质量保证（降低随机性、知识传递、可审计性）可能比单纯的效率提升更有价值。这提醒我们，在将 AI 引入产研流程时，首先要思考的是”如何保证质量”，而不是”如何提高效率”。

对 Skill 编写者的启示#

这篇文章也给 Skill 编写者提供了重要启示：

1. 方法论正确性是前提：如果方法论本身有缺陷，Skill 会以工业化的速度传播这个缺陷
2. 深入理解系统设计：理解加载和调用流程，可以编写出更高效、更可靠的 Skill
3. 思考 Skill 的局限性：在单个 Skill 层面，可以通过设计缓解一些系统层面的局限性
4. 关注产研流程的实际痛点：最好的 Skill 来自对实际工作流程的深刻理解

总的来说，这篇文章不仅是对 Claude Code Skills 系统的技术解析，更是一份关于 LLM 应用开发的深度思考。它让我们看到，Skills 系统的意义远不止于一个功能特性，而是代表了 LLM 应用开发工业化的一个重要方向。

本文档基于 https://juejin.cn/post/7625838952655912994 整理总结，并加入了扩展理解

原文链接：https://juejin.cn/post/7625838952655912994