Claude Code Skills 完全指南
写在前面：我的内容哲学
不写"10 个技巧"，只写"1 个框架"。不制造焦虑，而是提供可在自己项目中立刻验证的思维模型。
每篇文章的统一结构：
text
1. 核心问题 —— 这篇解决什么认知缺口？
2. 原理框架 —— 给读者一个可复用的思维模型
3. 真实案例 —— 从第一手实践中提取，附完整代码
4. 常见误区 —— 你以为对的，但实际是错的
5. 行动清单 —— 读完立刻能做的 3 件事
这不是 10 篇独立文章，而是一套完整的知识体系。它们之间有严格的递进关系：
text
理解本质 → 掌握设计 → 实战构建 → 工程化管理 → 组织级扩展
第 1 篇
「Skill 的本质：为什么一个 Markdown 文件能改变 AI 的行为？」
核心问题
大多数人对 Skills 的理解停留在表面——"装上就好了"。但从来没有人真正解释清楚：一个 Markdown 文件是如何在底层改变模型行为的？ 理解这个原理，才能设计出真正有效的 Skill。
原理框架：「三层加载模型」
Skills 围绕渐进式披露（progressive disclosure）构建。Claude 分三个阶段获取信息：第一层是元数据（name + description），始终在 Claude 的上下文中，大约 100 个 token。Claude 仅基于此决定是否加载一个 Skill。
完整指令仅在 Claude 判断该 Skill 相关时才加载（不超过 5,000 token）。支持脚本和文件仅在被明确需要时才加载。这意味着你可以安装几十个 Skills 而不影响无关任务的性能。
这揭示了一个深刻的设计哲学：Skills 本质上是 prompt injections。它们是 Markdown 文件，存放在你的 ~/.claude/skills/ 目录中，在触发时被加载到 Claude 的上下文中。它们引导模型的行为——语气、结构、优先级、输出格式。没有什么比这更魔法的了。
真实案例：同一个任务，有 Skill 和无 Skill 的认知鸿沟
一位开发者构建了一个"商业模型审查"Skill，迫使模型在分析任何内容之前先深入单位经济学。没有 Skill 时，Claude Code 给出了平衡、礼貌、但毫无用处的概述。有了 Skill，它发现一个 $39/月 的 SaaS 甚至无法覆盖其每用户的计算成本。这就是区别。
没有 Skills 的 Claude Code 是一个没有你偏好记忆的杰出通才——一个极其聪明的新员工，但每周一都要问你报告格式。
常见误区
误区 1：Skills 是高级版提示词
不完全正确。Skills 添加了可选功能：支持文件的目录、用于控制谁调用它们的 frontmatter，以及让 Claude 在相关时自动加载的能力。它们是可版本化、可测试、可组合的知识单元，而不仅仅是一段文字。
误区 2：装得越多越好
一位作者安装了全部 47 个（某合集的）Skills，对每一个与原始 Claude Code 输出进行了测试。其中 40 个让输出变得更差。围绕 Skills 有太多科技圈的炒作，几乎不可能把有效的和无用的分开。
行动清单
- 理解 → 打开你安装的任何一个 Skill 文件夹，阅读 SKILL.md 的 frontmatter 和正文，理解"元数据"与"指令"的分离
- 实验 → 对同一个任务，分别在有 Skill 和无 Skill 下运行，截图对比输出差异
- 删除 → 卸载所有你从未验证过效果的 Skills，只保留经过 Before/After 测试的
第 2 篇
「Description 设计的科学：为什么你的 Skill 永远不触发？」
核心问题
第一次直接写 SKILL.md 时会遇到问题。如果 description 设计不好，Skill 甚至不会触发。应该在写提示或代码之前花时间设计。
这是每一个 Skill 构建者必然会遇到的第一个坎：你精心编写的 Skill 为什么被 Claude 无视了？
原理框架：「触发机制模型」
Skills 以列表形式存在于 Claude 可见的系统提示中。当你输入请求时，模型基于你的词句与 Skill 的 description 之间的模式匹配来决定是否调用该 Skill。这是概率性的，不是确定性的。没有保证你的 Skill 一定会触发。
而且更关键的是：Claude 倾向于对简单任务自己处理而不调用 Skills。它默认不触发。所以你的 description 需要足够具体，让 Claude 认识到"这是 Skill 的工作，不是我自己能做的"。description 需要有一定的"推动性"。
真实案例：200+ 提示的实测数据
一位测试者写了一个 CPO 审查 Skill，精心设计了 description。然后运行了 20 个显然应该触发它的不同提示——"做一个 CPO 审查"、"给我一个 go/no-go 评估"、"找出这个产品策略的漏洞"。触发率远低于预期。
Bad vs Good description 对比框架：
Bad——太模糊，Claude 不知道何时触发：name: data-helper / description: Helps with data tasks。Good——具体的触发条件，略带"推动性"：name: sales-data-analyzer / description: Analyze sales/revenue CSV and Excel files to find patterns, calculate me...
框架：Description 设计的四要素
text
一个优秀的 description =
① 具体动作（"Analyze sales CSV"，不是"Help with data"）
② 具体触发词（"Use when user mentions sales data, revenue analysis"）
③ 边界声明（"Only for CSV and Excel files, not SQL queries"）
④ 推动性措辞（让 Claude 意识到这不是它可以自己做的简单任务）
常见误区
误区：Description 是给人读的摘要
Skill 的 description 字段是触发器，不是摘要——为模型而写（"我什么时候该触发？"）。这是反直觉的：大多数人把 description 写成给人类看的产品介绍，但它的读者是模型本身。
行动清单
- 审计 → 检查你所有 Skill 的 description，用"四要素框架"逐一评分
- 测试 → 对每个 Skill，写 10 个你认为应该触发它的自然语言提示，记录实际触发率
- 迭代 → 对触发率低于 70% 的 Skill，重写 description，加入具体触发词和推动性措辞
第 3 篇
「从零构建一个生产级 Skill：三种设计模式的选择与实战」
核心问题
知道 Skill 是什么和怎么触发之后，下一个问题是：怎么设计一个真正有用的 Skill？ 不是 demo 级别的，而是可以在真实工作中每天使用的。
原理框架：「三种模式决策树」
需要与外部 API 实时通信？→ Pattern C。需要确定性处理如计算、验证或文件转换？→ Pattern B。Claude 的语言能力和判断力可以独立处理？→ Pattern A。当犹豫不决时，从 Pattern A 开始。后续很容易添加脚本演进为 Pattern B。但简化一个过于复杂的 Skill 更难。
Pattern A：纯 Markdown
最简模式。仅 Markdown 指令，无脚本。适用于：品牌指南、编码标准、审查清单、提交信息格式化、写作风格约束。使用条件：Claude 的语言能力和判断力足以胜任任务。
Pattern B：Markdown + 脚本
SKILL.md 定义"何时与为何"，脚本处理"如何"。
Pattern C：MCP/子代理
该模式从 Skill 的工作流中调用 MCP 服务器或子代理。适用于涉及外部服务的工作流——如创建 Issue → 创建分支 → 修复代码 → 打开 PR。更多活动部件意味着更多需要调试的东西，所以建议先熟悉 Pattern A 或 B。
真实案例：电商 KPI 分析 Skill 从设计到交付
第一步是定义 2-3 个具体用例。不是抽象的"有用的 Skill"，而是你在实践中观察到的真实重复性工作。一位开发者注意到许多同事在重复做每月和每季度的业务回顾。在电商和零售行业，KPI 分解过程遵循类似模式。这成为起点。他定义为："一个接收订单 CSV 数据、将 KPI 分解为树状结构、总结发现与优先级、并生成具体行动计划的 Skill"。
构建流程的完整展示
text
第 1 步：用例定义
✦ "月度电商 KPI 回顾" — 输入 CSV，输出分析报告 + 行动计划
✦ "季度业绩对比" — 输入两个月的数据，输出趋势分析
✦ "异常检测" — 识别 KPI 异常下降并归因
第 2 步：模式选择 → Pattern B
✦ 需要 Python 脚本做 CSV 解析和数值计算（确定性处理）
✦ 但分析洞察和行动建议依赖 Claude 的判断力
✦ → SKILL.md（指令）+ scripts/parse_csv.py（处理）
第 3 步：Description 设计
✦ 具体动作 + 触发词 + 推动性措辞
✦ "Analyze e-commerce order data from CSV/Excel files.
Use when user mentions orders, revenue, GMV, conversion,
retention, or asks for monthly/quarterly business review."
第 4 步：测试 → 10 条提示 → 记录触发率 → 迭代
第 5 步：Gotchas 部分 → 记录 Claude 的失败点
常见误区
误区：一个 Skill 什么都做
为不同工作流创建独立 Skills。不要在 Skill 中陈述显而易见的事情——聚焦于推动 Claude 偏离默认行为的内容。多个聚焦的 Skills 比一个大而全的 Skill 组合得更好。
行动清单
- 观察 → 这周记录你重复做了 3 次以上的同一类任务
- 定义 → 为其中一个任务写出 2-3 个具体用例
- 构建 → 从 Pattern A 开始，写一个最简 Skill，测试并迭代
第 4 篇
「Skill 设计的 5 种架构模式：从 Google、Anthropic 和 McKinsey 的实践中提炼」
核心问题
有了基础的 A/B/C 模式后，进阶的问题是：Skill 的内容应该怎么组织？ 不是"放什么指令"，而是"指令之间的结构关系"。这是从"能用"到"好用"的关键跃迁。
原理框架：「五种架构模式」
通过研究跨生态系统的 Skill 构建方式，从 Anthropic 的仓库到 Vercel 和 Google 的内部指南，有五种反复出现的设计模式可以帮助开发者构建 Agent。
模式 1：Tool Wrapper（工具包装器）
Tool Wrapper 给你的 Agent 提供针对特定库的按需上下文。不是将 API 约定硬编码到系统提示中，而是将它们打包成 Skill。Agent 仅在实际使用该技术时才加载此上下文。这是最简单的实现模式。SKILL.md 文件监听用户提示中的特定库关键词，从 references/ 目录动态加载你的内部文档，并将这些规则作为绝对真理应用。
模式 2：Reviewer（审查器）
审查器模式将"检查什么"和"如何检查"分离。不是在长系统提示中详述每个代码味道，而是将模块化的评分标准存储在 references/review-checklist.md 中。当用户提交代码时，Agent 加载这个清单并系统地评分，按严重程度分组。如果你将 Python 代码风格清单换成 OWASP 安全清单，你就得到了一个完全不同的专业审计——使用完全相同的 Skill 基础设施。
模式 3：Pipeline（管道）
在报告生成器示例中，Skill 文件不包含实际的布局或语法规则。它只是协调这些资产的检索，并强制 Agent 逐步执行它们。
模式 4：Inversion（反转）
反转模式翻转了常规动态。不是用户驱动提示、Agent 执行，而是 Agent 充当采访者。反转依赖于明确的、不可协商的门控指令（如"在所有阶段完成之前不要开始构建"），强制 Agent 先收集上下文。它按顺序提出结构化问题，并等待你的回答后才进入下一阶段。
模式 5：Generator（生成器）
接收变量输入，基于模板和规则生成结构化输出。
关键洞察：模式可组合
这些模式不是互斥的。它们可以组合。一个 Pipeline Skill 可以在末尾包含 Reviewer 步骤来复查自己的工作。一个 Generator 可以在开头依赖 Inversion 来收集必要变量，然后再填充模板。
行动清单
- 分类 → 用这五种模式重新分类你已有的 Skills，看看你最依赖哪种
- 组合 → 尝试在一个 Pipeline Skill 末尾加入 Reviewer 步骤
- 设计 → 下次构建新 Skill 时，先画出模式草图，再动手写 SKILL.md
第 5 篇
「Context Engineering：管理 Claude 最稀缺的资源」
核心问题
大多数 Claude Code 最佳实践都基于一个约束：Claude 的上下文窗口填满得很快，性能会随着填充而下降。Claude 的上下文窗口保存你整个对话的内容——每条消息、每个 Claude 读取的文件、每个命令输出。这很快就能填满。一次调试或代码库探索可能就产生和消耗数万个 token。当上下文窗口接近满时，Claude 可能开始"遗忘"早期指令或犯更多错误。上下文窗口是最重要的需要管理的资源。
原理框架：「三层上下文模型」
使用 Claude Code 成功的关键根本在于上下文工程。不仅是问对问题——而是提供正确的知识基础。有效的 AI 辅助开发需要三个核心组件：a) 项目架构知识——对类层次结构、库、框架和设计模式的理解，主要存储在 CLAUDE 文件中。b) 产品需求文档——产品应该做什么的清晰规格，存储在 *.prd.md 文件中。c) 深层技术知识——对核心技术、数学概念、算法和关键中间件的专业理解。
真实案例：从"困惑的初级开发者"到"知识渊博的架构师"
当为特定技术创建了专门的知识文件后，上下文从根本上转变了 AI 助手——从一个困惑的初级开发者变成一个知识渊博的架构师。在 Claude Code 中，注入上下文很简单：只需提示 Read @ditto-advanced-knowledge.md and understand。回报是：以前需要数天试错的功能现在几小时就能交付。AI 会建议你自己想不到的优化。最重要的是，它理解你的特定用例，而不是给出通用建议。
关键警告
知识文档中的幻觉是灾难性的——它们随每次使用而累积。生成任何知识文件后，必须彻底审查和调整，更好的做法是让领域专家验证。一个错误的 API 模式在你的知识文件中意味着未来每个实现都会出错。当知识文件超过 50KB（约 12,000 token）时，你有可能在实际编码开始之前就耗尽上下文 token。
框架：Context Engineering 的四原则
text
原则 1：分而治之
✦ 不要把所有上下文塞进一个 CLAUDE.md
✦ 按功能分多个知识文件，按需加载
原则 2：知识文件 ≠ 代码文档
✦ 知识文件是为 Claude 写的，不是为人类写的
✦ 重点放在决策逻辑和常见陷阱上
原则 3：定期 /clear
✦ 每 30-45 分钟清理一次上下文
✦ 用文件保存中间成果，而非依赖对话记忆
原则 4：宁精勿多
✦ Claude 读取的每个字节都是你的成本
✦ 一个精炼的 500 行 Skill > 一个臃肿的 2000 行 Skill
行动清单
- 度量 → 下次长会话结束时，检查你用了多少 token，找到浪费最大的环节
- 分解 → 将你的 CLAUDE.md 拆分成 3-5 个按需加载的知识文件
- 验证 → 请领域专家审查你的知识文件，标记每一个可能的幻觉
第 6 篇
「Command → Agent → Skill：编排模式完全指南」
核心问题
单个 Skill 解决单个任务。但真实工作是多步骤、跨角色的。如何把多个 Skills 编排成一个完整的工作流？
原理框架：McKinsey 的确定性编排模型
编排层应保持确定性。Agent 不应该决定下一步是什么或产物应该存放在哪里。应使用确定性工作流引擎，遵循预定义规则将工作推进各阶段。这是一个关键的设计选择。早期实验中，让 Agent 自行编排——决定何时从需求进入设计，或该做哪个任务——在小项目上可行。但在有横切关注点和多个进行中功能的大型代码库中，Agent 经常跳过步骤、创建循环依赖或陷入分析循环。Agent 擅长在有界问题内生成内容；它们在工作流排序的元级决策上很吃力。
Claude Code 的原生编排架构
一个完整的 Command → Agent → Skill 编排架构示例：/weather-orchestrator command 作为入口点——询问用户 C/F 偏好、调用 agent、然后调用 SVG skill。weather-agent 使用预加载的 weather-fetcher skill 获取温度。weather-svg-creator skill 创建 SVG 天气卡片。
使用多个 CLAUDE.md 管理 monorepo——祖先 + 后代加载。创建功能特定的子代理（额外上下文）配合 Skills（渐进式披露），而非通用的 QA、后端工程师代理。使用 context: fork 在隔离的子代理中运行 Skill——主上下文只看到最终结果，不包括中间工具调用。
真实案例：多 Agent 系统 vs 单 Agent 的效果对比
在实际项目的多个非简单开发任务中，将多 Agent 上下文工程方法与单 Agent 基线（仅有 CLAUDE.md 上下文和直接用户提示）进行对比。简而言之，多 Agent 方法在更多任务中成功，且需要更少的迭代。它通常在首次尝试时就产出可用的解决方案，而基线经常需要后续提示或开发者干预来修正错误。
编排设计的核心原则
现代 Agent 平台正趋同于 Agent Skills：可复用的模块化指令（通常是 SKILL.md 文件），编码领域特定的专业知识。每个专门化的 Agent 本质上就是一个 Skill——一组有界的指令、模板和特定类型工作的评估标准。每种产物类型都有结构化模板和完成的定义。需求、设计和任务不是自由格式文本，而是具有一致结构的产物。
行动清单
- 拆分 → 将你一个复杂 Skill 拆成 Command（入口）+ Agent（角色）+ Skill（能力）三层
-
隔离 → 用
context: fork确保子代理的中间过程不污染主上下文 - 确定性 → 编排逻辑不要让 Claude 决定，用明确的步骤顺序写死
第 7 篇
「知识管理系统：用 Claude Code 构建可复利增长的项目上下文」
核心问题
使用越多，就构建出越好的流程和模式，彼此之间不断累积。这种复合效应是 Claude Code 与其他 AI 工具的根本区别。你创建的每个文档、优化的每个流程、捕获的每条指令，都成为不断增长的知识库的一部分，使下一次交互更有价值。与静态工具或孤立的聊天会话不同，这个系统使用越久越善于帮助你。
原理框架：知识管理的文件系统架构
为应对这些挑战，必须构建结构化的知识管理系统。一个经过验证的目录结构如下：
text
project-root/
├── CLAUDE.md # 主配置
└── .claude/
├── context.md # 项目背景与约束
├── project-knowledge.md # 技术知识与模式
├── project-improvements.md # 改进历史与教训
├── common-patterns.md # 常用命令模式
└── debug-log.md # 重要调试记录
Knowledge Management System 使用以下文件系统化管理知识：context.md——项目背景、目标和约束、技术栈选择原因、业务需求和技术约束。project-knowledge.md——实现模式和设计决策知识、架构选择的原因、需要避免的模式和反模式。project-improvements.md——过去试错的记录、失败实现及其原因、改进过程和结果。重要：当做出新的实现或重大决策时，更新相关文件。
真实案例：独立顾问的知识管理实践
一位顾问在每个客户文件夹中设置 CLAUDE.md 文件——Claude 读取的指令文件。它们包含客户背景、沟通偏好、文档模板、业务术语和写作风格指南。你可以随着 Claude 对你工作方式的了解而更新它们。他还设置了自动工作日志生成——在重要工作（会议、文档、研究）后触发更新，以结构化摘要随时间构建上下文。
另一个更完整的系统是 Obsidian + Claude Code 的个人知识管理启动套件：早上——/daily 创建今日笔记，显示本周的一个大目标和活跃项目的下一步行动。你选择你的焦点。晚上——/daily 总结今天哪些目标和项目得到了关注。未关联的任务被标记。周日——/weekly 读取所有每日笔记、扫描项目状态、计算目标进度，并帮你规划下周。月末——/monthly 汇总每周复盘，对照年度目标检查季度里程碑，并设定下月优先级。
行动清单
- 初始化 → 在你的项目中创建上述 5 个知识文件，各填入 3-5 条核心内容
- 习惯化 → 每次重大决策后，立即更新 project-knowledge.md
-
自动化 → 创建
/update-knowledge命令，让 Claude 在会话结束时自动提取值得记录的内容
第 8 篇
「Workflow vs Agent vs Skill：什么时候该用什么？」
核心问题
最常见的架构错误不是技术问题，而是在不该用 Agent 的地方用了 Agent，或在该用 Skill 的地方硬写了 Workflow。
原理框架：「决策评分系统」
Anthropic 工程博客提出了一个很好的心智模型：用 Workflow 为可预测的事物构建结构，用 Agent 探索不可预测的事物。大多数现实世界的 AI 系统是混合的——其中很多严重依赖 Workflow，因为生产环境不奖励聪明，它奖励韧性。
成本是决策的核心：根据 Anthropic 的研究，Agent 消耗的 token 是简单聊天交互的 4 倍。多 Agent 系统？试试 15 倍。这不是 bug——这就是重点。它们循环、推理、重新评估，通常与自己对话多次才得出决定。如果 Agent 陷入工具调用循环或误解指令？你会看到账单仪表盘出现类似加密货币暴涨的尖峰。
调试差异更大：对 Workflow，调试就像走过一栋灯火通明的房子，你可以追踪 输入 → 函数 → 输出。简单。对 Agent？更像在一片未标记的森林中游荡，而且树偶尔会自己重新排列。
框架：三者的精确定位
| 维度 | Skill | Workflow | Agent |
|---|---|---|---|
| 本质 | 知识注入 | 确定性编排 | 自主决策 |
| 控制权 | Claude 判断何时加载 | 你定义每一步 | Claude 决定下一步 |
| token 成本 | 低（仅相关时加载） | 可预测 | 4-15 倍于基线 |
| 调试难度 | 低 | 低 | 高 |
| 适用场景 | 重复任务的标准化 | 固定流程的自动化 | 需探索和判断的开放任务 |
框架容易让人在简单方案足够时添加不必要的复杂性。Anthropic 建议开发者从直接使用 LLM API 开始：许多模式可以用几行代码实现。
常见误区
大多数糟糕的架构决策不是源于知识不足——而是来自行动太快。在一次同步会议上，有人说"这感觉对 Workflow 来说太动态了——也许我们直接用 Agent？"所有人点头。听起来合理。Agent 很灵活，对吧？快进三个月：系统在奇怪的地方循环，日志不可读，成本飙升，没人记得是谁建议用 Agent 的了。
行动清单
- 评估 → 对你当前的每个自动化任务，用上表判断它属于 Skill / Workflow / Agent
- 降级 → 如果有任何 Agent 方案可以用 Skill + Workflow 替代，立即降级
- 原则 → 新任务默认从 Skill 开始，证明不够用时才升级到 Agent
第 9 篇
「团队级 Skill 系统：从个人工具到组织知识资产」
核心问题
个人 Skill 解决个人效率问题。但真正的价值在于：当你离职后，你的 Skill 还能帮助团队吗？ 如何将个人隐性知识变成组织显性资产？
原理框架：Agent 工程化的组织模型
与最初级的开发者不同，AI Agent 不带任何背景知识、对过往项目的直觉、或通过耳濡目染习得规范的能力。每一条指南都必须明确且机器可读。现代 Agent 平台正趋同于 Agent Skills：可复用的模块化指令（通常是 SKILL.md 文件），编码领域特定的专业知识。每个专门化的 Agent 本质上就是一个 Skill。
当编排器调用某个 Agent 处理任务时，该 Agent 仅接收与其任务相关的信息（加上持久化的项目上下文），不会看到完整对话历史或无关数据。这种设计是有意的：防止不同工作流阶段之间的交叉污染，保持每个 Agent 的专注。所有 Agent 应知道的共同背景信息（编码约定、项目架构说明等）通过持久化上下文文件（CLAUDE.md）提供，预加载到每个 Agent 的上下文中。
框架：团队 Skill 系统的四层架构
text
第 1 层：个人 Skills（~/.claude/skills/）
✦ 个人偏好、工作习惯、常用模式
✦ 仅影响自己
第 2 层：项目 Skills（.claude/skills/）
✦ 项目编码规范、架构约定、部署流程
✦ 通过 git 与团队共享
第 3 层：组织 Skills（通过插件/Registry 分发）
✦ 跨项目的标准化工作流
✦ 品牌指南、安全审查、合规检查
第 4 层：社区 Skills（开放标准）
✦ 行业最佳实践
✦ 跨平台兼容
Claude Code Skills 遵循 Agent Skills 开放标准，该标准可跨多个 AI 工具使用。
真实案例：功能特定 Agent 的最佳实践
Agent 的完整配置包括：skills——预加载到 Agent 上下文的 Skill 名称列表；mcpServers——该子代理的 MCP 服务器；hooks——作用于该子代理的生命周期钩子（PreToolUse、PostToolUse 和 Stop 最常用）；memory——持久记忆范围：user、project 或 local；isolation——设为 "worktree" 可在临时 git worktree 中运行。
行动清单
- 盘点 → 列出你团队中每个人私下使用的 AI 提示和工作流
-
标准化 → 选出最有价值的 3 个，转化为项目级 Skills（放入
.claude/skills/，提交 git） - 制度化 → 建立"新知识 → 新 Skill"的团队流程：每次发现有价值的工作模式，立即创建或更新 Skill
第 10 篇
「全景图：2026 年 AI Agent 工具链的终极指南与选择框架」
核心问题
Skills、MCP、Hooks、Subagents、Commands、CLAUDE.md——这些概念之间到底是什么关系？什么时候该用哪个？这篇文章提供一个完整的心智地图，把所有碎片拼在一起。
原理框架：「分层协同模型」
Context Engineering 是构建有效 AI 应用的核心学科。通过适当使用 Skills、MCP 和 Subagents，遵循工具设计和评估的最佳实践，你可以充分释放 Claude 的潜力，构建真正生产就绪的 Agent 系统。
完整的协同模型：
text
┌─────────────────────────────────────────────┐
│ CLAUDE.md（持久上下文） │ ← 始终加载
│ 项目架构 · 编码规范 · 团队约定 │
├─────────────────────────────────────────────┤
│ Skills（按需知识注入） │ ← 相关时加载
│ 工作流指令 · 审查标准 · 输出模板 │
├─────────────────────────────────────────────┤
│ MCP（外部能力连接） │ ← 工具调用时激活
│ 数据库 · API · 文件系统 · 第三方服务 │
├─────────────────────────────────────────────┤
│ Subagents（隔离执行单元） │ ← 委派时创建
│ 独立上下文 · 并行执行 · 结果返回 │
├─────────────────────────────────────────────┤
│ Hooks（确定性守卫） │ ← 生命周期自动触发
│ 安全检查 · 格式验证 · 自动提交 │
└─────────────────────────────────────────────┘
每层的精确定位：
Skills 是指令、脚本和资源的文件夹，Claude 可以动态发现和加载。你可以把它们看作"专业知识包"，通过一致的高质量输出提升组织级生产力。
Hooks 用于必须每次都发生、零例外的操作。Hooks 在 Claude 工作流的特定节点自动运行脚本。与 CLAUDE.md 指令（只是建议性的）不同，Hooks 是确定性的，保证操作一定发生。
一个有用的类比：MCP 是厨房——刀、锅、食材。Skill 是告诉你如何使用它们的食谱。两者可以组合。Sentry 的代码审查 Skill 在 Skill 中定义 PR 分析工作流，并通过 MCP 获取错误数据。但在许多情况下，仅一个 Skill 就足够开始了。
选择框架：「5 个问题决策树」
text
问题 1：这个知识需要每次对话都存在吗？
→ 是 → CLAUDE.md
→ 否 → 继续
问题 2：这是一个可重复的工作流或标准？
→ 是 → Skill
→ 否 → 继续
问题 3：需要连接外部系统或 API？
→ 是 → MCP（可配合 Skill）
→ 否 → 继续
问题 4：这个任务必须每次都执行，零容忍？
→ 是 → Hook
→ 否 → 继续
问题 5：任务需要独立上下文、防止污染主对话？
→ 是 → Subagent
→ 否 → 直接在主会话中处理
行动清单
- 画图 → 用上面的分层模型，把你当前项目中的所有 AI 配置归类，看是否有错位
- 精简 → 如果有 Skill 在做 Hook 该做的事（如代码格式化），迁移到 Hook
- 打印 → 把"5 个问题决策树"打印贴在电脑旁，每次新建配置时先过一遍
🗺️ 10 篇文章的知识地图
text
基础认知层
├── 第 1 篇：Skill 的本质（它是什么）
└── 第 2 篇：Description 的科学（为什么不触发）
设计能力层
├── 第 3 篇：三种设计模式（A/B/C 怎么选）
└── 第 4 篇：五种架构模式（内容怎么组织）
工程实践层
├── 第 5 篇：Context Engineering（管理稀缺资源）
└── 第 6 篇：编排模式（多 Skill 如何协同）
系统构建层
├── 第 7 篇：知识管理系统（复利增长）
└── 第 8 篇：Workflow vs Agent vs Skill（不要过度工程化）
组织级扩展层
├── 第 9 篇：团队 Skill 系统（从个人到组织）
└── 第 10 篇：全景图（把所有碎片拼在一起）
网友评论