RMDC系统设计文档 整体转换为SKILL
This commit is contained in:
zeaslity
@@ -0,0 +1,429 @@
|
||||
## 1. 执行摘要：智能体时代的上下文工程新前沿
|
||||
|
||||
在生成式人工智能（Generative AI）的演进历程中，开发者与大语言模型（LLM）的交互模式正经历着一场深刻的范式转移。长期以来，\*\*提示工程（Prompt Engineering）\*\*一直是驾驭模型能力的核心手段，通过精心构造的静态文本来引导模型的随机性输出。然而，随着软件工程复杂度的指数级上升，单纯依赖无状态（Stateless）的提示词已难以满足构建大规模、多步骤、具备长期记忆的自动化系统的需求。
|
||||
|
||||
本报告旨在为具备深厚提示工程背景的专家提供一份关于 **Claude Code Agent Skills** 的权威技术指南。Claude Code Skills 不仅仅是提示词的延伸，它们代表了一种全新的\*\*智能体编排（Agentic Orchestration）\*\*架构。在这种架构中，静态的文本指令被转化为动态的、可执行的、且具备文件系统感知能力的“技能”模块。这种转变使得 LLM 从一个被动的文本生成器，进化为一个能够主动感知环境、执行确定性代码、并根据任务需求动态加载上下文的智能实体 <sup>1</sup>。
|
||||
|
||||
通过对 **模型上下文协议（Model Context Protocol, MCP）** 、文件系统级记忆架构以及混合执行模式（Hybrid Execution Pattern）的深度剖析，本报告将揭示 Skill 如何解决传统提示工程中面临的“上下文窗口过载”、“工具幻觉”以及“复杂逻辑推理不稳定”等核心痛点 <sup>3</sup>。对于致力于构建自动化代码开发工作流的资深工程师而言，掌握 Skill 的开发与部署，是迈向下一代 AI 辅助开发（AI-Assisted Development）的关键一步。
|
||||
|
||||
---
|
||||
|
||||
## 2. 架构基础：从无状态对话到有状态智能体
|
||||
|
||||
要理解 Agent Skills 的本质，首先必须解构 Claude Code 的运行时环境。与传统的 ChatGPT 或 Claude.ai 网页端对话不同，Claude Code 是一个运行在开发者本地终端（CLI）中的**智能体循环（Agentic Loop）** 。这种环境差异决定了其认知架构的根本不同。
|
||||
|
||||
### 2.1 文件系统即认知中枢
|
||||
|
||||
在传统的 LLM 应用开发中，所谓的“记忆”通常是通过向量数据库（Vector Database）实现的检索增强生成（RAG），或者是硬编码在系统提示词（System Prompt）中的规则。然而，Claude Code 引入了一种更为原生且符合开发者直觉的架构：**文件系统即长期记忆与能力注册表** <sup>1</sup>。
|
||||
|
||||
Agent Skills 并非存储在云端数据库或复杂的配置中心，而是以扁平文件的形式直接驻留在项目的 `.claude/skills/` 目录或用户的主目录 `~/.claude/skills/` 中。这种设计带来了几个关键的架构优势：
|
||||
|
||||
1. **上下文局部性（Contextual Locality）：** Claude Code 具备递归发现机制。当智能体在 `packages/frontend/` 目录下工作时，它不仅会加载全局技能，还会自动发现并挂载该子目录下的 `.claude/skills/`。这意味着，开发者可以为前端项目定义一套特定的构建和测试技能，而为后端项目定义另一套数据库迁移技能，模型会根据当前的工作路径自动切换“思维模式”和“工具箱” <sup>6</sup>。
|
||||
2. **版本控制即治理（GitOps for AI）：** 由于 Skill 本质上是 Markdown 和脚本文件，它们完全纳入 Git 版本控制体系。这意味着团队对智能体行为的每一次修改、优化或回滚，都像代码审查（Code Review）一样可追溯、可管理。这解决了传统提示工程中 Prompt 版本混乱、难以协作的难题 <sup>7</sup>。
|
||||
3. **环境感知（Environment Awareness）：** Skill 能够直接访问本地环境。通过 `{baseDir}` 等变量插值，Skill 可以精确调用与其关联的 Python 或 Bash 脚本，实现从“文本建议”到“代码执行”的跨越 。
|
||||
|
||||
### 2.2 元工具（Meta-Tool）范式与动态加载
|
||||
|
||||
从技术实现的角度来看，Skill 是对 LLM **工具使用（Tool Use / Function Calling）** 能力的高级抽象。当开发者创建一个 `SKILL.md` 文件时，Claude Code 的运行时环境（Runtime）并不会立即将文件中的数千字说明全部塞入模型的上下文窗口。这样做会导致上下文窗口迅速耗尽，且过多的无关信息会干扰模型的注意力机制。
|
||||
|
||||
相反，系统采用了一种\*\*元工具（Meta-Tool）\*\*机制 。在启动阶段，Claude Code 仅扫描所有 Skill 的 YAML 前置元数据（Frontmatter），提取 `name`（名称）和 `description`（描述）。这些轻量级的信息被注册为模型可见的工具定义。
|
||||
|
||||
当用户发出指令（例如“分析这个 Git 仓库的提交历史”）时，模型首先基于 `description` 进行语义匹配，判断是否需要调用某个 Skill。只有当模型决定激活特定 Skill 时，运行时环境才会读取 `SKILL.md` 的完整内容，并将其作为“临时系统指令”注入到当前的上下文窗口中。这种\*\*按需加载（Just-in-Time Context Loading）\*\*策略，是 Skill 能够支持数百个工具而不会导致模型“痴呆”或成本爆炸的核心原因 <sup>6</sup>。
|
||||
|
||||
### 2.3 执行生命周期深度解析
|
||||
|
||||
一个典型的 Skill 执行过程包含以下几个严密的微步骤，理解这一流程对于调试和优化至关重要：
|
||||
|
||||
1. **意图识别（Intent Recognition）：** 用户输入自然语言。模型在后台评估所有可用 Skill 的描述字段。
|
||||
2. **路由决策（Routing Decision）：** 模型输出一个工具调用请求，例如 `UseSkill(name="git-analyzer")`。
|
||||
3. **上下文注入（Context Injection）：** 系统拦截该调用，读取 `.claude/skills/git-analyzer/SKILL.md`，解析其中的 `{baseDir}` 等变量，将处理后的 Markdown 文本插入对话历史。
|
||||
4. **混合推理（Hybrid Reasoning）：** 模型阅读 Skill 中的详细步骤（Prompt），结合用户输入的参数（Arguments），规划执行路径。
|
||||
5. **代码执行（Code Execution）：** 如果 Skill 指示运行脚本，模型会生成 `Bash` 或 `CodeExecution` 工具调用，系统在本地沙箱中执行脚本并返回 stdout/stderr 结果。
|
||||
6. **结果合成（Result Synthesis）：** 模型根据脚本的输出，结合 Skill 中定义的输出格式要求，生成最终回复 <sup>2</sup>。
|
||||
|
||||
---
|
||||
|
||||
## 3. 比较分析：提示词、MCP 与 Skills 的三角关系
|
||||
|
||||
对于精通提示工程的开发者来说，最大的认知障碍往往在于混淆 **Prompt（提示词）** 、**MCP（模型上下文协议）** 和 **Skill（技能）** 的边界。它们虽然都旨在增强模型能力，但在架构栈中处于完全不同的层级。
|
||||
|
||||
### 3.1 提示工程 vs. 技能工程
|
||||
|
||||
从提示工程向技能工程的演进，本质上是从**无状态指令**向**有状态能力**的跨越。
|
||||
|
||||
| **维度** | **提示工程 (Prompt Engineering)** | **技能工程 (Skill Engineering)** | **核心差异分析** | | | | |
|
||||
| -- | ---------------------------------------------------------------- | -------------------------------------------------- | ----------------------------------------------------------------- | -- | -- | -- | -- |
|
||||
| **持久性** | 临时性；仅存在于当前会话窗口或需手动粘贴。 | 持久性；作为文件驻留于项目结构中 (`.claude/skills`)。 | Skill 是项目的永久资产，而 Prompt 是临时消耗品。 | | | | |
|
||||
| **上下文成本** | 高；复杂的 System Prompt 会持续占用 Token 配额。 | 低；采用“懒加载”机制，仅在激活时消耗 Token。 | Skill 架构允许定义成百上千种能力，而不影响基础对话成本<sup>6</sup>。 | | | | |
|
||||
| **执行确定性** | 低；依赖模型生成代码并由用户复制粘贴。 | 高；通过捆绑 Python/Bash 脚本实现确定性逻辑。 | Prompt 告诉模型“如何写代码”，Skill 赋予模型“运行代码的手”<sup>4</sup>。 | | | | |
|
||||
| **作用域** | 全局（System Prompt）或 局部（User Message）。 | 层级化；支持组织级、用户级、项目级和目录级覆盖。 | Skill 具备继承和覆盖特性，更适合大型工程团队的协作管理<sup>6</sup>。 | | | | |
|
||||
| **逻辑封装** | 困难；超长 Prompt 容易导致“中间迷失”（Lost-in-the-Middle）。 | 模块化；复杂逻辑被封装在独立文件和脚本中。 | Skill 鼓励“关注点分离”，将业务逻辑从 LLM 的推理中剥离出来<sup>11</sup>。 | | | | |
|
||||
|
||||
**深度洞察：** 传统的提示工程实际上是在试图用自然语言“模拟”计算机程序的逻辑。例如，通过 Prompt 要求模型“像 Python 解释器一样行事”。而 Skill 工程则是**回归本源**，让模型调用真正的 Python 解释器来处理计算任务，只保留模型作为“推理引擎”和“自然语言接口”的角色。这种“脑（LLM）+ 手（Script）”的分离是构建可靠智能体的基石 <sup>12</sup>。
|
||||
|
||||
### 3.2 技能 vs. 模型上下文协议 (MCP)
|
||||
|
||||
**模型上下文协议 (MCP)** 是 Anthropic 推出的一项开放标准，旨在解决 AI 模型与外部数据源连接的“碎片化”问题 <sup>3</sup>。许多开发者困惑于何时使用 MCP，何时使用 Skill。
|
||||
|
||||
MCP（连接层 / "USB-C 接口"）：
|
||||
|
||||
MCP 是底层的数据管道和工具协议。它定义了 Client（如 Claude Code）如何与 Server（如 Postgres 数据库、Google Drive、GitHub）进行通信。MCP Server 暴露的是原子化的工具（Atomic Tools）和资源（Resources）。
|
||||
|
||||
- *例子：* `postgres.query_table`、`github.get_pull_request`、`filesystem.read_file`。
|
||||
- *特点：* 通用、标准化、无业务逻辑。
|
||||
|
||||
Skills（编排层 / "驱动程序"）：
|
||||
|
||||
Skill 是上层的业务逻辑编排器。它定义了如何使用这些 MCP 工具来完成一个复杂的任务。Skill 是一份 SOP（标准作业程序），指导模型按顺序调用 MCP 工具，处理中间结果，并做出决策。
|
||||
|
||||
- *例子：* 一个名为“自动化代码审查”的 Skill，可能会先调用 MCP 的 `git.diff` 获取变更，再调用 `filesystem.read` 读取代码规范，最后综合生成审查意见。
|
||||
|
||||
**对比表格：**
|
||||
|
||||
| **特性** | **Model Context Protocol (MCP)** | **Claude Code Agent Skills** | | | |
|
||||
| -- | --------------------------------------------------------- | ------------------------------------------ | -- | -- | -- |
|
||||
| **抽象层级** | 低层级；原子化 API 接口。 | 高层级；端到端工作流（Workflow）。 | | | |
|
||||
| **实现方式** | 编写代码（TypeScript/Python SDK）。 | 编写 Markdown (`SKILL.md`) + 脚本。 | | | |
|
||||
| **主要角色** | 提供数据访问和基础动作（躯干）。 | 提供操作指南和策略推理（大脑）。 | | | |
|
||||
| **可移植性** | 通用协议；适用于所有支持 MCP 的客户端（IDE、Desktop）。 | 目前主要针对 Claude Code CLI 优化。 | | | |
|
||||
| **核心价值** | 连接孤岛数据（Data Connectivity）。 | 固化专家经验（Expertise Distillation）。 | | | |
|
||||
|
||||
架构协同效应：
|
||||
|
||||
最强大的模式是将 Skill 作为 MCP 工具的“包装器”。直接将原始的 SQL 查询工具（通过 MCP 暴露）交给 LLM 往往是危险的，因为它可能执行 DROP TABLE。但是，通过编写一个 SKILL.md，可以限制模型只能执行特定的查询模式，或者强制模型在执行破坏性操作前进行二次确认。Skill 在这里充当了 MCP 工具的安全护栏和上下文增强器 2。
|
||||
|
||||
---
|
||||
|
||||
## 4. 深度解析：Skill 开发规范与 `SKILL.md` 详解
|
||||
|
||||
作为 Context Engineering 的大师，理解 `SKILL.md` 的微观结构是至关重要的。这不仅仅是写文档，而是在编写**可执行的自然语言代码**。
|
||||
|
||||
### 4.1 Skill 的解剖学结构
|
||||
|
||||
一个标准的 Skill 是一个包含 `SKILL.md` 的文件夹。该文件由两部分组成：**YAML Frontmatter**（元数据）和 **Markdown Body**（指令体）<sup>1</sup>。
|
||||
|
||||
#### 4.1.1 YAML Frontmatter：元数据配置
|
||||
|
||||
这是 Skill 的“注册表信息”，决定了 Skill 何时以及如何被系统调度。
|
||||
|
||||
YAML
|
||||
|
||||
```
|
||||
---
|
||||
name: api-schema-validator
|
||||
description: Validates API response JSON against the OpenAPI specification. Use when user asks to check API consistency or debug backend responses.
|
||||
allowed-tools: Bash, Read, Write(test_reports/*)
|
||||
model: claude-3-opus-20240229
|
||||
user-invocable: true
|
||||
---
|
||||
```
|
||||
|
||||
**关键字段深度分析：**
|
||||
|
||||
- **`name`**：必须是 kebab-case（短横线连接）。这是模型内部引用该 Skill 的唯一标识符。
|
||||
- **`description`**：这是**上下文工程**中最关键的部分。它实际上是语义路由（Semantic Router）的匹配键。一个模糊的描述（如 "Helper tool"）会导致 Skill 永远不被触发。一个优秀的描述应该包含用户的潜在意图（Intent）和触发场景（Trigger Context），例如 "Use when user asks to..." <sup>6</sup>。
|
||||
- **`allowed-tools`**：这是一个**安全沙箱**机制。通过显式列出允许使用的工具，开发者可以防止 Skill 执行未授权的操作。
|
||||
|
||||
- *高级用法：* 支持 Glob 模式匹配。例如 `Bash(python scripts/*.py:*)` 表示仅允许执行 `scripts` 目录下的 Python 脚本，严禁执行 `rm -rf /` 等危险命令。这是企业级部署中不可或缺的安全特性 <sup>2</sup>。
|
||||
- **`model`**：可选字段。允许强制指定 Skill 运行的模型版本。对于需要极其复杂推理（如架构设计）的 Skill，可以强制指定 `claude-3-opus`；而对于简单的格式化任务，可以使用 `claude-3-haiku` 以降低延迟和成本 <sup>17</sup>。
|
||||
- **`user-invocable`**：如果设置为 `false`，则该 Skill 不会出现在 `/` 斜杠命令菜单中，只能由模型根据上下文隐式触发。这适用于那些作为“后台进程”存在的辅助 Skill <sup>6</sup>。
|
||||
|
||||
#### 4.1.2 Markdown Body：指令工程
|
||||
|
||||
`SKILL.md` 的正文是 Skill 的灵魂。它采用了“思维链（Chain-of-Thought）”的最佳实践，将模糊的任务转化为确定的步骤。
|
||||
|
||||
**结构化最佳实践：**
|
||||
|
||||
1. **目标声明（Objective Statement）：** 用一句话清晰定义 Skill 的产出。
|
||||
2. **参数解析（Argument Handling）：** 明确指示模型如何处理 `$ARGUMENTS` 变量。
|
||||
3. **分步逻辑（Step-by-Step Logic）：** 使用编号列表强制模型按顺序执行。这是防止模型“跳步”或“幻觉”的最有效手段。
|
||||
4. **输出规范（Output Schema）：** 严格定义输出的格式（如 XML 标签、JSON 结构或 Markdown 表格），以便于后续工具或人类阅读。
|
||||
|
||||
**示例片段：**
|
||||
|
||||
# API Schema Validator
|
||||
|
||||
## Context
|
||||
|
||||
You are a QA Automation Engineer. Your goal is to verify that the API response matches the rigorous OpenAPI v3.0 standard.
|
||||
|
||||
## Execution Plan
|
||||
|
||||
1. **Parse Arguments:** The user input is stored in `$ARGUMENTS`. Treat this as the target API endpoint URL.
|
||||
2. **Fetch Schema:** Read the `openapi.yaml` file from the project root.
|
||||
3. **Execute Request:** Use `curl` to fetch the response from `$ARGUMENTS`.
|
||||
4. **Compare:**
|
||||
|
||||
- Validate field types (e.g., string vs int).
|
||||
- Check for required fields.
|
||||
5. **Report:** Output findings in a Markdown table listing any violations.
|
||||
|
||||
### 4.2 复杂参数处理与变量插值
|
||||
|
||||
在 Prompt Engineering 中，我们习惯于处理自然语言。但在 Skill Engineering 中，我们需要处理结构化数据和变量。这是一个常见的陷阱区域。
|
||||
|
||||
\$ARGUMENTS 变量的微妙之处：
|
||||
|
||||
当 Skill 被触发时，Claude Code 会捕捉用户的输入并将其放入 \$ARGUMENTS 变量中。
|
||||
|
||||
- *场景：* 用户输入 `/validate-api https://api.example.com/users`。
|
||||
- *变量：* `$ARGUMENTS` 的值为 `"https://api.example.com/users"`。
|
||||
|
||||
引用与空格问题：
|
||||
|
||||
根据研究片段 18，在处理包含空格的参数时存在一定的不确定性。传统的 Shell 脚本习惯使用位置参数 \$1, \$2。虽然 Claude Code 的 Slash Command 支持这种位置参数解析，但在纯 Skill 模式下，最佳实践是将 \$ARGUMENTS 视为一个原始字符串（Raw String），并在 Skill 内部指示模型或脚本去解析它。
|
||||
|
||||
- *错误模式：* 直接假设 `$1` 可用，或者未加引号直接传入 Shell：`python script.py $ARGUMENTS`（如果参数含空格，会导致脚本接收到错误的参数个数）。
|
||||
- *正确模式：* 始终使用双引号包裹：`python script.py "$ARGUMENTS"`。并在脚本内部使用 `argparse` 处理复杂的参数逻辑 <sup>20</sup>。
|
||||
|
||||
JSON 注入模式：
|
||||
|
||||
对于需要传入复杂配置（如多个标志位、嵌套结构）的 Skill，最稳健的工程实践是要求（或由前置 Agent 生成）JSON 格式的参数。
|
||||
|
||||
- *指令设计：* "Analyze the input `$ARGUMENTS`. If it is not valid JSON, stop and ask the user for JSON format."
|
||||
- *优势：* LLM 解析 JSON 的能力远强于解析复杂的 Shell 命令行参数，这规避了转义字符和参数错位的风险 <sup>21</sup>。
|
||||
|
||||
---
|
||||
|
||||
## 5. 高级实现：确定性代码集成与混合智能
|
||||
|
||||
Claude Code Skills 的真正威力在于它能够将**确定性代码（Deterministic Code）与概率性推理（Probabilistic Reasoning）** 结合。这是解决 LLM “数学不好”、“逻辑跳跃”或“无法精确操作文件”等弱点的终极方案。
|
||||
|
||||
### 5.1 “大脑 + 计算器”混合架构模式
|
||||
|
||||
在这个模式中，`SKILL.md` 充当“大脑”，负责理解意图、规划任务和解释结果；而伴随的 Python/Node.js 脚本充当“计算器”，负责执行具体的计算、文件分析或 API 调用。
|
||||
|
||||
目录结构示例：
|
||||
|
||||
.claude/skills/
|
||||
|
||||
└── git-churn-analyzer/
|
||||
|
||||
├── SKILL.md
|
||||
|
||||
└── scripts/
|
||||
|
||||
└── calculate\_churn.py
|
||||
|
||||
实现细节：
|
||||
|
||||
LLM 非常不擅长直接统计 git 提交记录（因为上下文窗口有限，且计数容易出错）。因此，我们在 SKILL.md 中禁止模型手动统计，而是强制其运行脚本。
|
||||
|
||||
**SKILL.md 核心指令：**
|
||||
|
||||
## Execution Strategy
|
||||
|
||||
DO NOT attempt to count commits by reading git logs manually.
|
||||
|
||||
1. Execute the analysis script located in this skill's directory:
|
||||
python {baseDir}/scripts/calculate\_churn.py --target "\$ARGUMENTS"
|
||||
2. The script will generate a file named `churn_report.json`. Read this file.
|
||||
3. Based on the JSON data, explain to the user which modules require refactoring due to high churn.
|
||||
|
||||
**关键技术点：**
|
||||
|
||||
- **`{baseDir}`** **插值：** 这是一个极其重要的系统变量。它会被运行时环境动态替换为 Skill 所在的绝对路径。这确保了无论用户在项目的哪个子目录下调用 Skill，Claude 都能准确找到配套的脚本文件，解决了相对路径引用的噩梦 。
|
||||
|
||||
### 5.2 规避 Shell 解析限制与安全沙箱
|
||||
|
||||
在 Agent 开发中，直接让 LLM 生成复杂的 Shell 命令（包含管道符 `|`、重定向 `>`、通配符 `*`）是极具风险的。
|
||||
|
||||
1. **语法错误风险：** 模型生成的 Shell 命令可能在不同 OS（MacOS vs Linux vs Windows）上表现不一致。
|
||||
2. **权限拒绝风险：** `allowed-tools` 的解析器可能无法正确理解复杂的管道命令，导致权限校验失败 <sup>11</sup>。
|
||||
|
||||
解决方案：封装脚本化。
|
||||
|
||||
将复杂的逻辑（如 find. -name "\*.ts" | xargs grep "pattern" \> result.txt）封装进 scripts/search.sh。Skill 只需要申请运行 bash scripts/search.sh 的权限。这不仅绕过了 Shell 解析的歧义，还极大地提升了安全性——因为审核一个固定的脚本比审核模型生成的随机命令要容易得多。
|
||||
|
||||
### 5.3 钩子（Hooks）与“守门人”模式
|
||||
|
||||
Skill 还可以与 Claude Code 的 **Hooks** 系统结合，充当工作流的“守门人”。
|
||||
|
||||
- **场景：** `pre-commit` 检查。
|
||||
- **机制：** 配置一个 Hook，在用户尝试提交代码时自动触发 `security-audit` Skill。
|
||||
- **流程：** 该 Skill 运行 `trufflehog` 或自定义 Python 脚本扫描敏感信息。如果发现密钥泄露，Skill 会指示 Claude 终止操作并向用户发出警告。
|
||||
- **洞察：** 这种模式将 AI 从“被动助手”升级为“主动合规官”，在代码进入仓库前就拦截潜在风险 <sup>22</sup>。
|
||||
|
||||
---
|
||||
|
||||
## 6. MCP 集成策略：构建连接万物的神经网络
|
||||
|
||||
虽然 Skill 在本地环境中表现出色，但要构建真正的企业级 Agent，必须连接到 Jira、Salesforce、GitHub 或生产数据库。这正是 **MCP (Model Context Protocol)** 发挥作用的地方。
|
||||
|
||||
### 6.1 Skill 作为 MCP 的编排者
|
||||
|
||||
专家级开发者应将 Skill 视为**逻辑层**，将 MCP 视为**数据层**。Skill 的作用是“教”模型如何正确地使用 MCP 工具。
|
||||
|
||||
实战案例：Jira 故障修复工作流
|
||||
|
||||
如果没有 Skill，用户需要手动提示 Claude：“先查 Jira，再查代码，然后修 Bug”。
|
||||
|
||||
有了 fix-jira-issue Skill，流程如下：
|
||||
|
||||
1. **触发：** 用户输入 `/fix ENG-4521`。
|
||||
2. **Skill 激活：** `fix-jira-issue` 被加载。
|
||||
3. **MCP 调用 1：** Skill 指令：“使用 `jira-mcp` 服务器的 `get_issue` 工具获取 ENG-4521 的详情。”
|
||||
4. **逻辑推理：** Claude 阅读 Jira 返回的 JSON，理解这是一个空指针异常。
|
||||
5. **MCP 调用 2：** Skill 指令：“使用 `github-mcp` 工具基于 `main` 分支创建新分支 `fix/ENG-4521`。”
|
||||
6. **本地执行：** Skill 指令：“读取堆栈跟踪中的文件，定位问题并修复。”
|
||||
|
||||
**洞察：** Skill 实际上固化了使用 MCP 工具的“最佳实践”。它屏蔽了底层 API 的复杂性，即使用户不知道如何操作 Jira API，也能通过 Skill 完成任务 <sup>23</sup>。
|
||||
|
||||
### 6.2 解决“上下文过载”问题
|
||||
|
||||
直接连接 MCP 服务器的一个常见副作用是**元数据爆炸**。例如，连接一个企业级 Postgres 数据库的 MCP Server 可能会立即向上下文注入 500 个表的 Schema 定义，瞬间挤占所有的推理空间 <sup>3</sup>。
|
||||
|
||||
基于 Skill 的渐进式披露（Progressive Disclosure）：
|
||||
|
||||
我们可以编写一个 database-explorer Skill 来缓解这个问题：
|
||||
|
||||
1. **第一步：** 仅查询数据库的表名列表（Table Names），而非完整 Schema。
|
||||
2. **第二步：** 让模型根据用户问题（如“查询用户信息”），推断出可能相关的表（如 `users`, `profiles`）。
|
||||
3. 第三步： 仅针对这几个相关表，调用 MCP 工具获取详细 Schema。
|
||||
通过这种应用层面的渐进式加载，Skill 充当了一个智能过滤器，确保上下文窗口始终只包含当前任务所需的最少信息量。这是大规模系统集成的核心优化手段。
|
||||
|
||||
---
|
||||
|
||||
## 7. 战略工程：最佳实践与性能优化
|
||||
|
||||
编写一个能跑的 Skill 很容易，但编写一个健壮、高效且安全的 Skill 需要遵循严格的工程纪律。
|
||||
|
||||
### 7.1 渐进式披露与 Token 经济学
|
||||
|
||||
“上下文窗口是一种公共资源（Public Good）” <sup>9</sup>。每一个被 Skill 定义消耗的 Token，都在挤占对话历史和代码文件的空间。
|
||||
|
||||
- **策略：** 保持 `SKILL.md` 极其精简（建议 500 行以内）。
|
||||
- **技术：** 如果 Skill 需要参考一份 50 页的 API 文档，**绝对不要**将其直接粘贴在 `SKILL.md` 中。
|
||||
- **实现：** 将文档放入 `docs/api_spec.md`。在 `SKILL.md` 中写入：“如果且仅当你需要查询特定 API 参数时，读取 `docs/api_spec.md`。”
|
||||
- **效果：** 这种\*\*按需读取（Read-on-Demand）\*\*机制确保了在 Skill 激活的初始阶段只消耗极少的 Token，只有在深层任务执行时才动态加载重型知识库 <sup>6</sup>。
|
||||
|
||||
### 7.2 确定性解析 vs. 概率性猜测
|
||||
|
||||
不要让 LLM 去做正则引擎该做的事。
|
||||
|
||||
- *弱模式：* 提示模型“查看输入字符串 `user:admin role:editor` 并提取用户名”。LLM 可能会在边缘情况（如用户名包含冒号）下出错。
|
||||
- 强模式： 将字符串传递给 scripts/parser.py，脚本使用严格的正则表达式提取数据并返回 JSON。
|
||||
原则： 使用 LLM 处理意图（Intent）和非结构化数据，使用脚本处理语法（Syntax）和结构化数据。
|
||||
|
||||
### 7.3 安全性：最小权限原则
|
||||
|
||||
在企业环境中，Skill 本质上是拥有 Shell 访问权的自动化脚本，风险极大。
|
||||
|
||||
- **权限管控：** 必须在 YAML Frontmatter 中严格限制 `allowed-tools`。如果一个 Skill 只需要读取日志，决不能给它 `Write` 或 `Bash` 的权限 。
|
||||
- **代码审查：** 将 `.claude/skills` 目录纳入最严格的 Code Review 流程。任何对 `SKILL.md` 或关联脚本的修改都应被视为对生产代码的修改。
|
||||
|
||||
### 7.4 调试 Agent Skills
|
||||
|
||||
调试一个“黑盒”模型的思维过程极具挑战性。
|
||||
|
||||
- **会话隔离：** 利用 `${CLAUDE_SESSION_ID}` 变量。在脚本中将日志输出到 `/tmp/logs/${CLAUDE_SESSION_ID}.log`。这样可以将特定会话的脚本执行轨迹与并行运行的其他会话区分开来 <sup>6</sup>。
|
||||
- **显式回显（Verbose Echoing）：** 脚本不应默默失败。如果脚本遇到错误（如文件未找到），应打印明确的错误信息到 `stdout`。Claude 能够读取这些输出并进行**自我修正（Self-Correction）** 。例如，看到“FileNotFoundError”，模型通常会尝试查找正确的文件路径并重试。
|
||||
|
||||
---
|
||||
|
||||
## 8. 详细实现案例
|
||||
|
||||
### 8.1 案例一：“智能重构” Skill（AST 语法树集成）
|
||||
|
||||
此 Skill 展示了如何利用 Python 脚本进行抽象语法树（AST）分析，确保模型生成的重构代码在语法上是合法的，从而避免“代码写完跑不通”的尴尬。
|
||||
|
||||
**文件路径：** `.claude/skills/refactor/SKILL.md`
|
||||
|
||||
---
|
||||
|
||||
## name: smart-refactor description: Safely refactors Python functions using AST validation. Use when the user wants to rename functions or extract methods. allowed-tools: Bash, Read, Write
|
||||
|
||||
# Smart Refactor Skill
|
||||
|
||||
## Context
|
||||
|
||||
You are a Python Refactoring Specialist. You prioritize code stability and correctness.
|
||||
|
||||
## Workflow
|
||||
|
||||
1. **Analyze Request:** Identify the target file and function from `$ARGUMENTS`.
|
||||
2. **Pre-Computation Validation:**
|
||||
|
||||
- Execute the AST validator script:
|
||||
python {baseDir}/scripts/validate\_ast.py check "\$ARGUMENTS"
|
||||
- If the script returns an error, **STOP** immediately and report the syntax error to the user.
|
||||
3. **Plan & Edit:** Propose the refactoring plan and use the `Edit` tool to apply changes.
|
||||
4. **Post-Computation Verification:**
|
||||
|
||||
- Run the validator script again on the modified file.
|
||||
- If the script reports syntax errors, **Revert** the changes using `git checkout` and inform the user of the failure.
|
||||
|
||||
**配套脚本：** `.claude/skills/refactor/scripts/validate_ast.py`
|
||||
|
||||
Python
|
||||
|
||||
```
|
||||
import ast
|
||||
import sys
|
||||
|
||||
def check_syntax(file_path):
|
||||
try:
|
||||
with open(file_path, 'r') as f:
|
||||
source = f.read()
|
||||
ast.parse(source)
|
||||
print(f"SUCCESS: {file_path} contains valid Python syntax.")
|
||||
sys.exit(0)
|
||||
except SyntaxError as e:
|
||||
print(f"ERROR: Syntax error in {file_path}: {e}")
|
||||
sys.exit(1)
|
||||
except Exception as e:
|
||||
print(f"ERROR: Could not read file: {e}")
|
||||
sys.exit(1)
|
||||
|
||||
if __name__ == "__main__":
|
||||
if len(sys.argv) < 3:
|
||||
print("Usage: validate_ast.py check <file_path>")
|
||||
sys.exit(1)
|
||||
check_syntax(sys.argv)
|
||||
```
|
||||
|
||||
**分析：** 这个 Skill 注入了一个**确定性护栏**。它不再盲目信任模型的输出，而是利用 AST 解析器作为客观的裁判。这体现了 Agent Engineering 的核心思想：**Trust, but Verify（信任，但要验证）** 。
|
||||
|
||||
### 8.2 案例二：强制 TDD 开发循环
|
||||
|
||||
此 Skill 并不执行复杂代码，而是通过 Prompt 强制执行一种行为约束，即“测试驱动开发（TDD）”。
|
||||
|
||||
**文件路径：** `.claude/skills/tdd-cycle/SKILL.md`
|
||||
|
||||
---
|
||||
|
||||
## name: tdd-cycle description: Implements features using strict Test-Driven Development protocol. Use when asked to "implement feature X" or "add functionality". model: claude-3-opus-20240229
|
||||
|
||||
# TDD Enforcement Protocol
|
||||
|
||||
## Core Directive
|
||||
|
||||
You are FORBIDDEN from writing any implementation code until you have witnessed a specific test failure.
|
||||
|
||||
## Execution Steps
|
||||
|
||||
1. **Phase 1: RED (Write Test)**
|
||||
|
||||
- Analyze the requirement.
|
||||
- Create a new test file in `tests/` asserting the desired behavior.
|
||||
- Run the test command: `npm test`
|
||||
- **Checkpoint:** Verify the output shows a specific assertion error matching the new feature. If the test passes or fails for the wrong reason, refine the test.
|
||||
2. **Phase 2: GREEN (Make it Pass)**
|
||||
|
||||
- Write the *minimum* implementation code required to satisfy the test.
|
||||
- Do NOT optimize or add extra features yet.
|
||||
- Run `npm test` again to confirm all tests pass.
|
||||
3. **Phase 3: REFACTOR (Clean Up)**
|
||||
|
||||
- Review the code for duplication or clarity issues.
|
||||
- Refactor if necessary, ensuring tests remain green.
|
||||
|
||||
**分析：** 这个 Skill 充当了**行为约束器（Behavioral Constraint）** 。它为智能体植入了一个“超我（Super-ego）”，抑制了 LLM 倾向于直接给出最终代码（往往带有 Bug）的冲动。通过强制执行 Red-Green-Refactor 循环，Skill 显著提高了生成代码的质量和可靠性。
|
||||
|
||||
---
|
||||
|
||||
## 9. 结论：Agentic Workflows 的未来展望
|
||||
|
||||
Claude Code Agent Skills 的出现，标志着我们正在从**指令式交互（Instructional Interfacing）迈向环境工程（Environmental Engineering）** 。作为专家级的开发者，我们的工作重心正从“如何写出完美的提示词”转移到“如何构建完美的智能体运行环境”。
|
||||
|
||||
掌握 `SKILL.md` 的架构、策略性地使用 `{baseDir}` 脚本封装复杂逻辑、以及精细编排 MCP 数据流，是构建下一代半自主工程师（Semi-autonomous Engineers）的关键。未来，软件工程团队的核心资产将不仅仅是业务代码，还包括随代码库一同演进的、高度专业化的 Agent Skills 库。这些 Skill 将不仅包含代码的知识，更包含团队的工程文化、架构规范和最佳实践，真正实现“代码即知识，环境即智能”。
|
||||
Reference in New Issue
Block a user