Claude Skills 入门指南：概念、结构与最佳实践（附 skills 推荐）

用 GankInterview 的实时屏幕提示，自信应答下一场面试。

随着大语言模型应用从单纯的对话交互向能够自主规划与执行任务的智能代理（Agent）演进，掌握 Claude Code Skills 已成为开发者在终端环境中构建高效工程体系的关键能力。本文作为一份深度向的 Claude Code Skills 最佳实践指南与全方位教程，旨在帮助开发者彻底打破自然语言与本地工具链之间的壁垒，将零散的交互转化为可复用、可维护的生产力组件。我们将深入剖析以 SKILL.md 为核心的配置体系，提供经过验证的 SKILL.md 配置模板与详尽的 SKILL.md 语法参考，解析如何通过 Frontmatter 元数据与 Markdown 指令体的协同工作，实现从语义理解到本地脚本执行的精准映射。文章不仅涵盖了构建 Claude Code 自动化工作流的基础逻辑，更将重点探讨决定技能执行质量的高级议题，包括如何利用 Claude Skills 提示词工程优化模型对复杂指令的遵循度、设计高效且无歧义的 Claude Skills 触发指令，以及在涉及文件读写与系统操作时必须考量的 Claude Code 权限设置策略。此外，针对开发过程中可能遇到的路由失效或执行偏差问题，我们总结了一套实用的 Claude Skills 调试技巧，助您快速定位故障根源。通过系统性地学习本指南，您将能够把代码审查、测试生成等重复性劳动封装为确定性的工程能力，真正释放 Claude Code 作为下一代编程助手的全部潜能。

什么是 Claude Code Skills？

在 Claude Code CLI 环境中，Skills 是一种由用户定义的自定义工具机制。它们不仅仅是预设的提示词（Prompts），而是通过 Markdown 文件结构化的可执行单元，允许 Claude 在终端环境中调用特定的脚本、遵循严格的工程规范或执行复杂的多步工作流。

与标准的对话式交互不同，Skills 将 Claude 从一个被动的问答机器人转变为一个能够主动执行任务的 Agent。通过配置 Skills，开发者可以将重复性的工程任务（如代码审查、自动化测试生成、特定格式的文档编写）封装为标准能力，让 Claude 像调用内置命令一样调用这些自定义逻辑。

核心工作流：从定义到触发

创建一个 Skill 的过程遵循标准的“定义-注册-调用”生命周期。Claude Code 会自动扫描指定目录下的配置，并将其注入到系统上下文中，使其可以通过自然语言直接触发。

以下是构建一个 Skill 的标准三步流程：

创建目录结构
在项目根目录或全局配置中建立存放位置。

    mkdir -p .claude/skills/my-custom-skill

定义逻辑 (SKILL.md)
在目录下创建核心描述文件 SKILL.md。该文件包含两部分：告诉 Claude 何时使用该 Skill 的元数据（Frontmatter），以及告诉 Claude 如何执行任务的具体指令。

    ---
    name: generate-unit-tests
    description: Generates Jest unit tests for a given React component file.
    ---
    # Instructions
    1. Analyze the component props and logic.
    2. Create a test file named [Component].test.tsx.
    3. Cover edge cases and rendering states.

自然语言触发
无需记忆复杂的 CLI 参数，直接在 Claude Code 终端中描述意图即可激活：
> "帮我为 Button.tsx 生成单元测试。"

为什么需要 Skills？

Skills 的核心价值在于工程化（Engineering）与确定性（Determinism）。

上下文固化：在对话中，复杂的指令容易随着上下文窗口的滑动而丢失。Skills 将最佳实践（如“总是使用 TypeScript 严格模式”）固化在文件中，确保每次执行都遵循相同的标准。
工具链集成：Skills 可以配合 scripts/ 目录下的 Python 或 Bash 脚本使用，允许 Claude 调用本地编译器、Linter 或部署工具，打通了从“生成代码”到“验证代码”的最后一公里。
语义路由：Claude 会根据 SKILL.md 中的描述自动判断当前任务是否需要调用某个 Skill。这意味着你不需要显式指定工具名称，Agent 会根据语义自动选择最合适的工具来解决问题。

核心结构：详解 SKILL.md 语法与配置

在 Claude Code 的技能体系中，SKILL.md 不仅是配置文件的核心，更是定义 Agent 行为的唯一事实来源（Single Source of Truth）。与普通的 Prompt 工程不同，Claude Code CLI 要求 SKILL.md 遵循严格的语法结构，以便正确解析技能的元数据与执行逻辑。任何格式上的偏差（如缺少分隔符或 YAML 缩进错误）都可能导致 CLI 无法识别该技能。

一个标准的 SKILL.md 文件由两个主要部分组成，中间必须使用 YAML 分隔符严格区分。这种结构设计借鉴了静态网站生成器（如 Jekyll 或 Hugo）的 Frontmatter 模式，将“路由逻辑”与“执行指令”解耦。

文件结构概览

SKILL.md 的解析依赖于以下两个核心组件的顺序排列：

元数据配置 (Frontmatter)：
位于文件顶部，由三短横线 --- 包裹的 YAML 区域。这部分是技能的“控制层”，定义了技能的身份（ID）、名称以及 Claude 何时应该调用该技能的语义索引。
指令主体 (Body)：
位于第二个 --- 之后的所有 Markdown 内容。这部分是技能的“执行层”，包含具体的 Prompt 指令、步骤说明以及示例，指导 Claude 在技能被触发后具体如何操作。

以下是该文件的标准骨架结构：

---
# [Frontmatter 区域]
# 采用 YAML 语法
# 定义技能的 ID、名称、描述及输入参数
# Claude Code CLI 依靠此区域决定是否“唤醒”该技能
---

# [Body 区域]
# 采用 Markdown 语法
# 包含详细的系统指令 (System Prompt)
# 定义具体的执行步骤、注意事项及 Few-Shot 示例

理解这一结构至关重要：Frontmatter 决定了技能的“可发现性”（Discovery），而 Body 决定了技能的“执行质量”（Execution）。 在实际开发中，开发者必须确保文件以 --- 开头，并正确闭合元数据区域，否则整个技能将被视为无效文本。

元数据配置 (Frontmatter)

SKILL.md 文件的顶部必须包含一个 YAML 格式的 Frontmatter 区域，由三道短横线 --- 包裹。这是 Claude Code 识别和索引技能的入口，任何语法错误都会导致技能无法被加载。

在此区域中，你定义的是技能的“控制平面”信息。与传统的代码注释不同，这些元数据会被直接注入到 Claude 的系统提示词（System Prompt）中，决定了 Claude 在面对用户指令时是否会“唤醒”该技能。

核心字段详解

对于一个标准的 Claude Code Skill，以下字段是必须或强烈建议配置的：

name (必填): 技能的唯一标识符。
- 规范: 仅允许小写字母、数字和连字符（kebab-case），长度通常限制在 64 个字符以内。
- 限制: 避免使用保留字（如 "anthropic", "claude"），且不能包含 XML 标签。
description (必填): 技能的语义索引。这是 Claude 判断“何时调用此技能”的唯一依据。
- 机制: 当用户输入指令时，Claude 会在后台通过语义匹配检索所有已安装技能的 description。
- 最佳实践: 使用第三人称描述具体场景（例如 "Use this skill when..."），而非简单的功能堆砌。
input_schema (可选): 虽然 Claude Code 可以通过自然语言指令推断参数，但在需要严格结构化输入（如 API 调用）时，显式定义 JSON Schema 可以提高参数提取的准确性。

配置示例

以下是一个标准的 Frontmatter 配置示例，展示了一个用于生成 Git 提交信息的技能定义：

---
name: git-commit-generator
description: Analyzes staged changes and generates a commit message following Conventional Commits standards. Use this skill when the user asks to "commit code", "save work", or "write a commit message" based on current diffs.
version: 1.0.0
---

关键注意事项

语义索引与 Token 预算
description 字段至关重要，它充当了技能的语义索引。Claude 并不是每次都读取整个 SKILL.md 的正文，而是先扫描 description。如果描述过于模糊，技能将永远不会被触发；如果描述过长（例如超过几千字符），不仅浪费 Context Window，甚至可能导致技能被系统忽略。在 Claude Code 环境中，所有技能的描述都会占用系统提示词的字符预算，因此务必保持精炼。
ID 冲突与命名空间
name 字段在你的本地环境中必须是全局唯一的。虽然目前 Claude Code 允许本地覆盖，但为了避免调试时的混淆，建议在开发团队内部采用类似 team-skill-name 的命名约定。
语法严格性
YAML 对缩进和格式非常敏感。确保字段名后有冒号和空格（: ），且不要在 Frontmatter 区域外使用 --- 分隔符，以免解析器误判区域结束位置。

指令体与提示词工程 (Instruction Body)

SKILL.md 文件中 YAML frontmatter 之后的内容即为 指令体 (Instruction Body)。这部分内容实质上是该 Skill 的“系统提示词” (System Prompt)，它定义了当 Skill 被触发时，Claude 应当如何思考、处理输入并生成输出。

编写高效指令体不仅仅是用自然语言描述任务，更需要应用针对 Claude 模型优化的提示词工程 (Prompt Engineering) 技术。在构建 Skill 时，建议采用结构化的提示词策略，以确保执行的确定性和鲁棒性。

结构化与分隔符

Claude 模型对 XML 风格的标签具有极高的敏感度。在指令体中，避免使用大段的纯文本描述，而是利用分隔符将不同逻辑模块（如背景、规则、步骤、输出格式）清晰隔开。

例如，使用 <rules> 包裹约束条件，使用 <output_format> 定义返回结构。这不仅能帮助模型准确解析指令，还能在处理复杂上下文时防止“指令漂移”。

Few-Shot Prompting (少样本提示)

在指令体中提供具体的输入输出示例（Few-Shot Examples）是提升 Skill 表现最直接的方法。相比于抽象的描述，示例能让模型直观理解预期的语气、格式和深度。

思维链 (Chain of Thought)

对于涉及逻辑判断或多步操作的 Skill，应当显式要求模型在生成最终结果前进行“逐步思考”。可以在指令中加入 <thinking> 环节，要求模型先分析输入数据的特征，再执行操作。这种技术能显著降低模型在处理复杂代码审查或数据转换时的幻觉率。

案例对比：Git Commit 消息生成器

为了直观展示提示词工程的价值，以下对比了一个“Git Commit 消息生成器” Skill 的两种指令写法：

❌ 弱指令 (Weak Instruction)
这种写法过于依赖模型的默认行为，容易导致输出格式不统一，或包含不必要的闲聊文本。

请帮我根据当前的 git diff 写一个 commit message。
要写得专业一点，不要太长。

✅ 强鲁棒性指令 (Robust Instruction)
这种写法通过角色设定、明确的约束（Conventional Commits 规范）、结构化标签和少样本示例，确保了输出的高质量和一致性。

Role: 你是一个严格遵守 Conventional Commits 规范的代码审计专家。

<rules>
1. 格式必须为: <type>(<scope>): <subject>
2. type 仅限: feat, fix, docs, style, refactor, test, chore
3. subject 必须使用祈使语气，且不超过 50 个字符
4. 直接输出 commit message，不要包含任何解释或 markdown 代码块标记
</rules>

<examples>
Input: "修改了 readme 文件里的错别字"
Output: docs(readme): fix typo in installation guide

Input: "增加了用户登录功能的 API 接口"
Output: feat(auth): add user login api endpoint
</examples>

<instruction>
分析传入的 git diff 内容，识别变更的核心意图，并生成符合上述规则的 commit message。
</instruction>

通过这种工程化的方式编写指令体，可以将 Claude 从一个通用的对话助手转变为一个精准执行特定开发任务的自动化工具。

权限与安全设置 (Permissions)

在构建 Claude Skills 时，安全性往往是被低估的一环。由于 Claude Code 是一个在本地终端运行的 CLI 工具，它继承了当前用户的系统权限。这意味着一个设计不当的 Skill 理论上可以执行任何你本人能执行的操作，包括读取敏感配置文件（如 .env 或 ~/.ssh）以及执行破坏性的文件系统命令。

为了确保 Skill 在安全边界内运行，开发者必须在设计阶段就明确界定其“行动范围”（Scope）。

权限边界与文件系统访问

默认情况下，Claude Code 能够访问其启动目录及其子目录下的文件。当你的 Skill 涉及文件写入或 Shell 命令执行时，务必在 SKILL.md 的指令中明确限制其操作范围。

例如，如果你正在构建一个日志分析工具，不应赋予其全盘扫描的权限，而应在 Prompt 中明确约束：

"You are only allowed to read files within the ./logs/ directory. Do not access or modify files in the parent directory or other system paths."

这种自然语言层面的约束虽然不是物理防火墙，但配合 Claude 的对齐机制，能有效防止模型“幻觉”导致的越界操作。

工具白名单 (Allowed Tools)

在更复杂的场景下，可以通过配置限制 Skill 能够调用的具体工具。根据 Claude Code 文档，开发者可以使用 allowed-tools 字段来约束 Skill 的能力。

最小权限原则：如果一个 Skill 只需要读取代码，就不应赋予其 Edit 或 Bash 执行权限。
敏感操作隔离：对于涉及数据库迁移或生产环境部署的 Skill，建议通过 security-hooks.json 配置额外的审批钩子，强制要求人工确认关键步骤。

⚠️ 警告：关于 Shell 命令的风险

当赋予 Skill 执行 Shell 命令的能力（如通过 Bash 工具）时，请务必保持极度谨慎。
* 避免宽泛指令：切勿使用 "Clean up the directory" 这样模糊的指令，模型可能会误解并执行 rm -rf *。
* 限定目录：始终在指令中强制要求操作仅限于特定子目录（例如 Only execute cleanup commands inside ./temp/）。
* 沙盒测试：在将包含写操作的 Skill 应用于重要项目之前，务必在一个隔离的 Git 分支或临时目录中进行测试，以防止意外的数据丢失。

通过在 SKILL.md 中清晰定义权限边界，并利用 allowed-tools 进行硬性约束，你可以确保 Claude Code 既是一个强大的助手，又是一个安全的合作者。

实战教程：从零构建一个“代码审查” Skill

理论结合实践是掌握 Claude Skills 最快的方式。在本节中，我们将通过构建一个实用的“代码审查助手（Code Reviewer）”来演示完整的开发流程。这个 Skill 的目标是：当你要求 Claude 审查某个文件时，它能自动依据预设的最佳实践（如 PEP 8、错误处理规范）提供结构化的反馈，而不是泛泛而谈。

我们将按照以下四个步骤进行构建：

第一步：创建文件结构

Claude Code 通过特定的目录结构识别 Skill。我们需要在项目根目录下（或全局配置目录中）创建一个包含 SKILL.md 的文件夹。

在你的终端中执行以下命令，创建存放 Skill 的目录和文件：

mkdir -p .claude/skills/reviewer
touch .claude/skills/reviewer/SKILL.md

注意：Skill 的文件夹名称（如 reviewer）通常与其功能相关，但这主要用于组织管理。Claude 真正识别的是 SKILL.md 文件内部的元数据。

第二步：编写 Skill 定义代码

接下来，我们需要在 SKILL.md 中定义元数据（Metadata）和指令逻辑。元数据告诉 Claude 这个 Skill 是做什么的，而指令体则定义了它如何执行任务。

将以下代码完整复制到 .claude/skills/reviewer/SKILL.md 文件中：

---
name: code-reviewer
description: Reviews code for style consistency, security risks, and potential bugs. Use this when the user asks to review, audit, or check code quality.
---

# Code Reviewer Instructions

You are a strict code review assistant. Your goal is to ensure code quality and maintainability.

## Review Process
When the user provides code or asks you to review a file, follow these steps:

1.  Security Check: Look for hardcoded credentials, SQL injection vulnerabilities, or unsafe input handling.
2.  Style & Logic: Check for adherence to standard idioms (e.g., Python PEP 8) and logical flaws (off-by-one errors, resource leaks).
3.  Refactoring: Suggest specific improvements for readability.

## Output Format
Please format your response as follows:
- Summary: A one-sentence overview of the code quality.
- Critical Issues: (If any) Bullet points of bugs or security risks.
- Suggestions: Actionable improvements with code snippets showing "Before" vs. "After".

## Constraints
- Be concise. Do not explain basic syntax unless there is an error.
- If the code is perfect, reply with "LGTM (Looks Good To Me) ✨".

第三步：在终端触发 Skill

保存文件后，Claude Code 会自动检测到新添加的 Skill。现在，你可以通过自然语言直接调用它，无需输入复杂的命令参数。

假设你的项目中有一个名为 main.py 的文件，你可以在终端中输入：

claude "Review main.py for any potential bugs"

或者更简单地：

claude "Check the code style in main.py"

Claude 会根据你的输入（"Review", "Check code"）匹配到我们在元数据中定义的 description，从而激活 code-reviewer Skill。

第四步：验证输出结果

如果配置正确，Claude 将不再给出通用的回答，而是严格遵循我们在 SKILL.md 中定义的 Output Format。你应当看到类似以下的结构化输出：

Summary: The code in main.py is functional but contains a potential file handle leak and violates PEP 8 naming conventions.

Critical Issues
* Line 12: open('data.txt', 'r') is used without a context manager (with statement), which may leave the file handle open if an error occurs.

Suggestions
* Resource Management: Use with open(...) to ensure the file is closed automatically.
* Naming: Rename variable N to retry_count to allow for better readability.

通过这种方式，你不仅规范了 Claude 的输出格式，还强制它关注你最在意的代码质量维度（如安全性与风格），从而将一个通用的 AI 变成了定制化的开发工具。

调试与故障排除 (Debugging & Troubleshooting)

在构建 Claude Skills 时，最常见的挫败感往往源于“无声的失败”——你定义了一个完美的 Skill，但在实际对话中，Claude 仿佛完全不知道它的存在，或者虽然调用了 Skill 但执行结果与预期大相径庭。

由于 Skills 的触发机制依赖于大模型的语义理解而非刚性的代码调用，调试过程需要结合环境配置检查与提示词工程（Prompt Engineering）。以下是一份针对常见问题的排查清单与解决方案。

故障排查清单 (Troubleshooting Checklist)

当你发现 Skill 无法正常工作时，请按照以下步骤逐一排查：

验证文件路径与结构
确保你的 SKILL.md 文件位于项目根目录下的 .claude/skills/ 文件夹中。Claude Code 启动时会扫描该目录。如果文件位于子文件夹深处或命名不符合规范，可能无法被加载。
> 操作：重启 Claude Code 终端会话以强制重新加载配置。
确认 Skill 是否已加载
在对话中直接询问 Claude：“What Skills are available?”（有哪些 Skills 可用？）。

- 如果你的 Skill 未出现在列表中：说明文件解析失败或路径错误。检查 SKILL.md 中的 YAML 头部格式是否正确（例如缩进错误或缺少必要字段）。
- 如果 Skill 在列表中但从未触发：说明问题出在“触发描述”或上下文限制上。

检查描述字段的长度与清晰度
Claude 通过将所有可用 Skill 的 description 注入到系统提示词（System Prompt）中来“感知”它们。如果你的描述过于晦涩，或者所有 Skill 的描述总和超过了字符预算，可能会导致 Skill 被忽略。

- 根据相关研究，Claude Code 对 Skill 描述的字符数有限制（默认为 15,000 字符左右）。如果超出限制且没有警告，处于列表末尾的 Skills 可能不仅无法触发，甚至无法被模型“看到”。
- 解决方案：精简 description 字段，移除冗余的形容词，专注于定义“该 Skill 解决什么具体任务”。如果必须加载大量 Skills，可以尝试通过环境变量（如 SLASHCOMMANDTOOLCHARBUDGET）增加预算。

常见问题与修复策略

1. Skill 拒绝触发 (Skill Not Triggering)

即使 Skill 已加载，Claude 也可能倾向于使用内置能力而非调用你的工具。

原因：触发条件模糊。例如，描述为“帮助写代码”的 Skill 很难与 Claude 的核心能力区分开。
修复：在 description 中使用独特且具体的关键词。例如，将“代码格式化工具”改为“当用户要求‘执行企业级格式化’时使用的工具”。
强制测试：在开发阶段，不要依赖自然语言的自动推断。尝试使用明确的指令进行“隔离测试”，例如直接告诉 Claude：“使用 [Skill Name] 来处理这个问题。”如果强制调用成功但自动触发失败，说明功能正常，仅需优化描述。

2. 执行指令误解 (Misinterpretation)

Skill 成功触发，但输出结果不符合预期（例如忽略了某些参数或格式错误）。

原因：指令缺乏约束或示例（Few-Shot prompting）。
修复：在 SKILL.md 的正文部分（Instruction）增加具体的 Examples。展示“输入是什么”以及“期望的输出是什么”，这比单纯的文字描述有效得多。
上下文管理：确保 Skill 获取了足够的信息。如果 Skill 需要处理文件内容，确保在触发时已将文件读入上下文，或者在 Skill 内部包含读取文件的步骤。

3. 自动化流程中的“失聪”

在复杂的长对话中，Claude 可能会“忘记”使用 Skills。

观察：有开发者指出，即便在系统提示中存在 Skill，Claude 有时仍会忽略它们并尝试手动完成任务。
修复：对于关键的工作流，可以在 Prompt 中显式提及 Skill 的存在，或者使用 Project 级的配置（如 CLAUDE.md）来提示模型“在遇到 X 类问题时，优先检查并使用 .claude/skills/ 下的工具”。

查看日志与调试信息

虽然 Claude Code 的 CLI 界面较为简洁，但在调试时可以通过观察其“思考过程”来判断问题。当 Claude 决定调用 Skill 时，它通常会先输出一段分析文本（例如 "I will use the test-generator skill..."）。

如果它输出了这段话但随后报错，通常是 Skill 内部脚本执行错误（权限不足或依赖缺失）。
如果它完全没有输出这段话，直接给出了纯文本回复，则属于上述的“触发失败”范畴，需要回到步骤 3 优化描述。

通过建立“编写 -> 重启 -> 查询列表 -> 强制调用 -> 优化描述”的调试闭环，你可以大幅减少构建 Skill 时的不确定性。

进阶技巧：打造自动化工作流

当开发者掌握了基础的 SKILL.md 编写后，下一步便是将孤立的指令转化为可复用的自动化工作流。在复杂的工程场景中，单纯依赖自然语言对话往往不够高效，我们需要通过 Skill Chaining（技能链式调用）和精细的上下文管理，让 Claude 在处理长链路任务时保持稳定与精准。

技能链式调用 (Skill Chaining)

“技能链”是指将一个复杂任务拆解为多个原子 Skill，前一个 Skill 的输出作为后一个 Skill 的输入。这种模式不仅能降低单个 Prompt 的复杂度，还能提高调试的可观测性。

例如，在重构遗留代码时，可以设计以下链路：

Analysis Skill (analyze-complexity): 仅使用 grep 和 ls 扫描目录，输出高复杂度函数的列表，不进行任何修改。
Refactor Skill (refactor-method): 接收具体的函数名，应用单一职责原则进行拆分。
Test Skill (gen-unit-test): 针对修改后的代码生成覆盖测试。

在实际操作中，可以通过定义一个“编排型” Skill（Orchestrator）来串联这些步骤。例如创建一个 refactor-pipeline Skill，其核心指令明确要求按顺序调用上述工具或子指令，确保数据流转的确定性。

上下文管理与 Token 优化

在构建 Skill 时，最大的误区是将所有背景信息直接堆砌在 SKILL.md 中。这不仅浪费 Token，还会稀释 Claude 对核心指令的注意力。

最佳实践：渐进式披露 (Progressive Disclosure)
根据 Claude Code 文档，SKILL.md 应保持轻量（建议 500 行以内）。对于复杂的领域知识，应将其拆分为独立的参考文件，并仅在需要时引导 Claude 读取。

Bad Pattern: 在 SKILL.md 中包含 2000 行的整个数据库 Schema 定义。
Good Pattern: 在 SKILL.md 中仅保留目录索引，并指示：“当用户询问订单表时，请读取 docs/schema/orders.md。”

此外，利用 allowed-tools 字段可以强制 Skill 仅使用低成本工具。例如，对于一个只需读取配置文件的 Skill，显式限制其只能使用 Read 和 Grep，防止 Claude 尝试运行昂贵的构建命令或修改文件，从而在保障安全的同时减少意外的 Token 消耗。

决策指南：临时 Prompt vs. 正式 Skill

并非所有任务都值得封装为 Skill。过早优化会导致维护成本上升。以下对比表可帮助你判断何时投入时间构建正式 Skill：

维度	Ad-hoc Prompt (临时对话)	Formal Skill (正式技能)
使用频率	低 (每周 < 2 次)	高 (每日多次或团队通用)
上下文需求	简单，依赖当前会话记忆	复杂，需依赖特定的文件结构或文档
任务确定性	探索性，结果可变	标准化，要求输出格式固定 (如 JSON/Diff)
交互模式	自由问答	触发器驱动 (Trigger-based Action)
维护成本	零	需版本控制、测试与文档更新
典型场景	"帮我解释这段代码是什么意思"	"将当前改动生成符合团队规范的 Commit Message"

维度

Ad-hoc Prompt (临时对话)

Formal Skill (正式技能)

使用频率

低 (每周 < 2 次)

高 (每日多次或团队通用)

上下文需求

简单，依赖当前会话记忆

复杂，需依赖特定的文件结构或文档

任务确定性

探索性，结果可变

标准化，要求输出格式固定 (如 JSON/Diff)

交互模式

自由问答

触发器驱动 (Trigger-based Action)

维护成本

零

需版本控制、测试与文档更新

典型场景

"帮我解释这段代码是什么意思"

"将当前改动生成符合团队规范的 Commit Message"

当发现自己或团队成员在重复粘贴同一段“注意事项”或“代码规范”给 Claude 时，这就是将其固化为 Skill 的最佳时机。