Claude Code 专业工作流：MCP、Skills、子智能体与持久记忆
英文原题：The Ultimate Claude Code Guide | MCP, Skills & More。本文不是命令清单，而是把视频里的能力整理成一套从“临时聊天”走向“可复用工程系统”的实践框架。
一、问题引入：为什么多数人只用了 Claude Code 的 20%
视频从一个常见误区出发：打开终端、输入需求、等待代码，然后把 Claude Code 当成“更聪明的聊天框”。这种用法当然有效，但它把每次任务都变成一次性的临时协作。项目规范、工具权限、审查流程和上下文管理都依赖人反复说明，任务一长，质量就开始漂移。
更成熟的做法是把能力拆成不同层次：MCP 负责接入外部系统，Skills 固化团队做事的方法，子智能体隔离并行任务，CLAUDE.md 和引用文档承载长期上下文，而 /compact 之类的会话操作负责控制当前上下文成本。每一层解决的问题不同，混用才是复杂度的来源。
真正的增益不只是“让模型写更多代码”，而是把重复说明、工具接入、专业角色和项目记忆变成可复用的工作系统。
二、核心概念：四个层次不要混在一起
1. 会话上下文：模型此刻正在“看”的材料
上下文窗口包含当前对话、工具返回和读取过的文件。它越长，推理成本越高，也越容易把早期已经失效的线索带进新决策。视频演示了用 /compact 把历史对话压缩成摘要，以便继续同一任务。不过压缩不是免费午餐：细节被折叠后，关键约束可能丢失，所以在进入全新工作阶段时，开启一个干净会话往往比反复压缩更稳。
2. MCP：给智能体增加外部能力
MCP Server 提供工具、资源或提示模板，让 Claude Code 能操作 GitHub 等外部系统。视频用 GitHub MCP 说明了完整链路：安装服务、准备最小权限的 Personal Access Token、在终端完成配置，再让 Claude 创建远程仓库。重点不在“能连多少服务”，而在控制工具数量与权限范围。
3. Skills：把完成任务的方法写成可触发流程
Skill 是一种可复用的行为说明。示例把代码审查要求写进 SKILL.md：检查安全、错误处理、性能、代码质量和测试，并规定每条发现要包含严重程度与位置。这样团队不必每次重新写长提示词，模型也能按稳定格式执行。
4. 子智能体：用独立上下文承担专门角色
子智能体不是“更高级的 Skill”。它拥有独立上下文，可以并行调查、测试或审查，再把结论交还主任务。视频既展示了系统自带的探索型子智能体，也创建了专门的测试编写智能体，并为它选择模型、颜色和记忆范围。适合的任务应当边界清晰、结果可汇总；很小的单步操作没必要拆分。
三、实操路线：从一次性对话升级为工程工作流
步骤一：先清理环境，再开始复杂任务
先查看当前项目启用了哪些 MCP 服务、上下文是否已经过长、工作目录是否正确。关闭暂时不用的工具，避免模型在几十个近似工具之间选择。长任务进入新阶段时，明确决定是压缩旧会话还是开启新会话。
# 视频中的操作思路（具体命令以当前版本为准）
/mcp # 查看和管理 MCP 服务
/compact # 将当前会话压缩为摘要
/agents # 查看或创建专用子智能体步骤二：为 MCP 设计最小权限边界
以 GitHub 为例，先确定智能体只需要读仓库、创建仓库，还是还需要管理 Issues、Actions。Token 不应写进仓库或提示词；安装命令也不要被复制到公开文档。连接完成后用一个小而可逆的动作验证权限，再交给智能体执行真实工作。
- 确认 MCP Server 的来源与维护状态。
- 创建仅覆盖所需仓库和 scope 的凭据。
- 在终端或安全配置界面完成认证。
- 用读取仓库信息等低风险动作做连通性测试。
- 不使用时停用服务，减少攻击面和上下文噪声。
步骤三：把重复的专业要求固化为 Skill
从一项每周都会发生、且验收标准明确的任务开始，例如代码审查、生成测试或发布检查。Skill 应写清触发场景、输入、步骤、输出格式和失败条件。视频的代码审查示例之所以合适，是因为它既有固定维度，又能对每个项目保留判断空间。
skills/
└── code-review/
└── SKILL.md
# 典型内容
- 什么时候触发
- 安全 / 错误处理 / 性能 / 测试检查项
- 每条问题的严重程度、文件位置和修改建议
- 没有发现问题时如何明确报告步骤四：只把可并行、可验收的工作交给子智能体
让主智能体保留任务目标和最终决策，把“查找认证调用链”“补齐单元测试”“评估数据库迁移风险”等独立问题分派出去。每个子智能体都需要明确边界和返回格式，否则只是把一个混乱上下文复制成多个混乱上下文。
步骤五：建立分层记忆，而不是把一切塞进一个文件
视频最后用 CLAUDE.md 演示持久记忆：把每次会话都需要的稳定事实放在主文件里，再链接到更细的参考文档。主文件应像目录和宪法，而不是仓库百科全书。架构说明、测试指南和部署步骤可以拆成独立文件，需要时再读。
.claude/
├── CLAUDE.md # 稳定原则、项目入口、引用索引
└── references/
├── architecture.md
├── testing.md
└── deployment.md四、决策矩阵：什么时候用 MCP、Skill、子智能体或记忆
| 机制 | 最适合的场景 | 主要优点 | 风险 | 决策建议 |
|---|---|---|---|---|
| MCP | 访问 GitHub、数据库、文档或其他外部系统 | 把实时数据和动作接入智能体 | 权限过宽、工具过多、凭据泄露 | 按项目启用，使用最小权限，先做低风险验证 |
| Skill | 代码审查、测试生成、发布检查等重复流程 | 稳定复用方法和输出格式 | 规则过长或过时会限制判断 | 把硬门禁写清，案例和背景按需引用 |
| 子智能体 | 可并行调查、独立模块分析、专业角色任务 | 隔离上下文，降低主会话噪声 | 协调成本、重复工作、结果冲突 | 任务必须有边界、交付物和验收条件 |
| CLAUDE.md | 每次进入项目都需要的稳定约束和背景 | 跨会话保持一致认知 | 文件膨胀后占用上下文，旧事实污染决策 | 主文件只放索引与原则，细节拆到引用文档 |
| /compact | 同一任务接近上下文上限，但仍需延续 | 降低历史 token 占用 | 压缩可能遗漏细节 | 阶段切换优先新会话；必须延续时再压缩 |
五、关键判断：优化目标是“可控”，不是“功能最多”
如果一个工具、Skill 或子智能体没有服务于当前目标，它就不是能力，而是上下文噪声。
视频里最值得保留的不是某一条安装命令，而是取舍原则。MCP 越多不等于能力越强；子智能体越多不等于速度越快；记忆文件越长不等于理解越深。专业工作流的核心，是让每个机制承担单一职责，并且能解释权限、输入、输出和失败方式。
这也意味着要定期维护：删除已经不用的服务，更新 Skill 的验收条件，审查持久记忆中的过期事实，观察子智能体是否真的减少主任务负担。只有这些机制可以被检查和回滚，它们才从“炫技配置”变成工程基础设施。
六、时间戳目录
以下时间点按英文字幕与视频节奏整理，播放器广告或章节标记可能造成数秒偏差。
- 为什么大多数人只使用了 Claude Code 的一小部分能力
- 专业环境与常用会话命令：模型、上下文和工具管理
/compact如何压缩会话，以及什么时候应该直接开新会话- MCP 的作用、工具膨胀问题与 GitHub Server 配置
- 用 GitHub MCP 创建并验证远程仓库
- Skills 的定位与代码审查 Skill 实战
- 多会话工具演示与并行工作界面
- 子智能体的独立上下文、内置角色与自定义角色
- 为测试智能体选择模型、颜色和记忆范围
CLAUDE.md、全局/项目记忆与分层引用结构- 总结：把工具、方法、分工和记忆组合成可维护系统