找回密码
立即注册
搜索
热搜: Java Python Linux Go
发回帖 发新帖

2594

积分

0

好友

376

主题
发表于 昨天 13:47 | 查看: 6| 回复: 0

Claude Code 102进阶教程标题图

Eyad 发布的 Claude Code 开发实战第二篇来了。他曾是亚马逊、迪士尼和第一资本的软件工程师,拥有7年一线开发经验。此前,他的第一篇 Claude Code 入门教程获得了现象级传播,目前已有数百万人围观。

Claude Code 101入门教程社交媒体传播数据

现在,进阶篇已经正式发布。Eyad 指出,入门篇解决了基础性错误,而这篇进阶文章将深入剖析 Claude Code 底层系统的三大核心能力,帮助开发者实现从胜任到卓越的跨越。

这三大核心能力分别是:Skills(技能)Subagents(子代理)MCP connectors(MCP连接器)

Eyad 坦言,尽管功能都写在官方文档里,但文档并未解释这些组件在实践中如何协同工作,以及哪些配置才能在真实工作中发挥价值。以下内容,是他通过日常构建生产级软件,花费数周甚至反复试错总结出的全部经验,也适合在云栈社区这样的开发者社区进行交流探讨。

一切的基础:上下文窗口问题

在深入探讨高级功能之前,一个基础性问题影响着所有后续操作:上下文窗口

许多人可能认为,所有 AI 编码工具处理上下文的方式都大同小异。但事实并非如此。

根据 Qodo 工程团队的一份详细对比报告,Claude Code 提供了“一个更可靠、更明确的 200K token 上下文窗口”。相比之下,Cursor 虽然理论上也支持 200K,但“实际使用中常常达不到理论上限”,因为它会出于性能或成本管理的考虑,进行“内部截断”。这意味着系统会悄悄地削减你的有效上下文。

对于大型、互相连接的代码库——比如需要模型同时理解认证系统、API 路由和数据库模式之间关联的复杂项目——完整的上下文至关重要。因此,对于大型项目,直接使用 Claude Code 是更优选,因为它能持续稳定地提供完整的 200K 上下文。

这也解释了为什么接下来要介绍的 Skills、Subagents 和 MCP 连接器等功能在 Claude Code 中效果如此出众:它们都受益于一个可预测的、完整的上下文工作环境。

Skills(技能):教会 Claude 你的特定工作流

Skill,本质上是一个 Markdown 文件,用于教会 Claude 如何执行特定于你工作的任务。当你提出的问题与某个 Skill 的用途匹配时,Claude 会自动调用它。

其结构非常简单。

创建 Skill 文件:

  • 全局技能:~/.claude/skills/your-skill-name/SKILL.md
  • 项目级技能(可与团队共享):.claude/skills/your-skill-name/SKILL.md

每个 SKILL.md 文件都以 YAML frontmatter 开头:

name: code-review-standards
description: 在审查 PR 或提出改进建议时,应用我们团队的代码审查标准。在审查代码、讨论最佳实践或用户请求实现反馈时使用。

这里的 description(描述)至关重要。Claude 会根据它来判断何时应用该技能。因此,描述需要具体说明触发条件。当然,你也可以明确指示 Claude “使用 xx 技能”,但最终目标是让 Claude 能自行识别并调用。

在 frontmatter 下方,用 Markdown 格式编写具体的指令。以下是一个简单的示例:

---
name: commit-messages
description: 遵循我们团队的约定生成 commit message。在创建 commit 或用户请求相关帮助时使用。
---

# Commit Message 格式

所有 commit 都遵循“Conventional Commits”规范:
- feat: 新功能
- fix: bug 修复
- refactor: 既不修复 bug 也不增加功能的代码更改
- docs: 仅文档
- test: 添加或更新测试

格式: `type(scope): description`
示例: `feat(auth): add password reset flow`

描述保持在 50 个字符以内。如需更多上下文,添加一个空行后写入正文。

这种指令式的写作方式起初可能有些别扭,但带来的质量提升是显而易见的。

其核心架构原则是渐进式披露(progressive disclosure)。Claude 在启动时,只会预加载每个已安装 Skill 的 namedescription(每个约 100 个 token)。只有当 Claude 判断某个 Skill 与当前任务相关时,才会加载其完整的指令内容。这意味着你可以拥有数十个技能,而不会占用宝贵的上下文空间。

你还可以在技能文件夹中添加支持文件。如果参考资料很长,可以将其放入单独的文件,并在 SKILL.md 中引用。Claude 只会在需要时读取它。

值得注意的是,Skill 不仅限于代码。工程师们已经用它来构建各种工作流:

  • 针对特定数据库模式的查询模式
  • 公司内部的 API 文档格式
  • 会议纪要模板
  • 甚至是个人工作流,如餐饮计划或旅行预订

任何你发现自己需要反复向 Claude 解释相同背景或偏好的场景,都可以通过 Skill 来固化。

要查看当前加载了哪些技能,可以直接问 Claude:“你有哪些可用的技能?”或者在设置 → 能力 → 向下滚动找到技能列表。

Subagents(子代理):利用隔离上下文进行并行处理

Subagent(子代理)是一个独立的 Claude 实例,拥有自己的上下文窗口、系统提示和工具权限。这是 Claude Code 架构的真正差异化所在。

当主对话中的 Claude 将任务委托给一个子代理时,该子代理会独立运行,然后将摘要返回给主对话。

这个机制解决了上下文退化的问题(通常在上下文窗口使用率达到 45% 左右时发生)。你可以将复杂的研究或实现任务交由一个拥有全新上下文的子代理处理,然后只取回最相关的结果,从而保持主对话的干净。

Claude Code 内置了三个子代理:

  • Explore:一个快速、只读的代理,用于搜索和分析代码库。当 Claude 需要理解代码而不做修改时会调用它。Claude 可以指定其工作彻底性:快速、中等或非常彻底。
  • Plan:一个研究型代理,在“计划模式”下用于收集信息。它会调查代码库并返回发现,帮助 Claude 做出更明智的架构决策。
  • General-purpose:一个通用的、功能强大的代理,用于需要探索和行动的复杂多步骤任务。

创建自定义子代理

与 Skill 一样,强烈建议创建自己的子代理。在 Claude Code 中运行 /agents 命令可以查看所有可用的子代理并创建新的。

手动创建,只需在 ~/.claude/agents/(用户级)或 .claude/agents/(项目级)目录下添加一个 Markdown 文件。

示例结构如下:

---
name: security-reviewer
description: 审查代码中的安全漏洞。在检查身份验证问题、注入风险或数据泄露时调用。
tools: Read, Grep, Glob
---

你是一个专注于安全的代码审查员。在分析代码时:
1.  检查身份验证和授权漏洞
2.  寻找注入漏洞(SQL、命令、XSS)
3.  识别敏感数据泄露风险
4.  标记不安全的依赖项

为每个发现提供具体的文件和行号参考。按严重性分类:严重、高、中、低。

tools 字段控制子代理的能力。对于只读的审查员,可以限制为 readgrepglob 命令。对于需要修改代码的代理,则可以包含 writeeditbash 命令。

子代理如何通信?

这是大多数人会忽略的关键点。子代理之间不直接共享上下文,它们在隔离的环境中运行。通信通过“委托和返回”模式进行:

  1. 主代理识别出适合委托的任务。
  2. 主代理用一个描述任务的具体提示来调用子代理。
  3. 子代理在自己的上下文窗口中执行任务。
  4. 子代理将发现或操作的摘要返回给主代理。
  5. 主代理整合摘要并继续。

摘要是关键。一个设计良好的子代理不会把它的整个上下文都扔回来。这就是为什么子代理的描述和系统提示需要明确规定输出格式。

对于复杂的工作流,你可以链式调用子代理,由主代理进行编排:

主代理
 ├── 委托研究任务给 Explore 子代理
 │   └── 返回:“找到 3 个相关文件:auth.py, middleware.py, routes.py”
 │
 ├── 委托实现任务给自定义的 implementer 子代理
 │   └── 返回:“已添加密码重置端点,更新了 2 个文件”
 │
 └── 委托测试任务给自定义的 test-runner 子代理
     └── 返回:“全部 12 个测试通过,覆盖率 94%”

每个子代理都为其特定任务获得了全新的上下文。主代理只持有摘要,从而避免了上下文污染。

一个重要限制是:子代理不能生成其他子代理,这防止了无限嵌套。

实用的子代理模式

  • 大型重构:让主代理识别所有需要更改的文件,然后为每个逻辑分组启动一个子代理。
  • 代码审查流水线:创建三个子代理(风格检查、安全扫描、测试覆盖率),并让它们并行审查一个 PR。
  • 研究任务:当需要理解代码库中不熟悉的部分时,委托给 Explore 代理,让它返回相关文件和模式的精炼总结。

MCP Connectors(MCP 连接器):让你永远无需离开 Claude

MCP(Model Context Protocol,模型上下文协议)是一种标准化的方式,让 AI 模型可以通过统一接口调用外部工具和数据源,而无需为每个工具进行定制集成。

这意味着,你不再需要切换到 GitHub、Slack、Gmail 或 Google Drive。你可以让 AI 通过 Claude 界面,经由一个 MCP 服务器与所有这些服务“对话”。

添加连接器的命令:

# HTTP 传输 (推荐用于远程服务器)
claude mcp add --transport http <name> <url>

# 示例: 连接到 Notion
claude mcp add --transport http notion https://mcp.notion.com/mcp

# 带有身份验证
claude mcp add --transport http github https://api.github.com/mcp \
--header "Authorization: Bearer your-token"

当然,也可以通过 Web 应用的设置 → 连接器 → 找到你的服务 → 配置来完成。

MCP 连接器在过去 6 个月中带来的改变:

  • 从问题跟踪器实现功能:“实现 JIRA 问题 ENG-4521 中描述的功能。”
  • 查询数据库:“从我们的 PostgreSQL 数据库中找出上周注册的用户。”
  • 集成设计稿:“根据最新的 Figma 设计更新我们的邮件模板。”
  • 自动化工作流:“创建 Gmail 草稿,邀请这些用户参加反馈会。”
  • 总结 Slack 讨论:“团队在 #engineering 频道关于 API 重新设计的决定是什么?”

其真正的威力在于组合。一个过去需要五次上下文切换(查 JIRA、看 Figma、翻 Slack、写代码、更新 JIRA)的工作流,现在可以在一个连续的会话中完成。让你始终保持心流状态。

推荐连接的 MCP 服务器:

  • GitHub:仓库管理、Issues、PRs、代码搜索
  • Slack:频道历史、主题摘要、消息搜索
  • Google Drive:在开发过程中访问参考文档
  • PostgreSQL/数据库:直接查询
  • Linear/Jira:问题跟踪

要查看当前的 MCP 连接,可在 Claude Code 中运行 /mcp

注意:第三方 MCP 服务器未经 Anthropic 验证,使用时需谨慎。

复合效应

现在,将所有这些组合在一起,构成了一个强大的人工智能 Agent 系统:

一个了解你代码库模式的 Skill + 一个处理测试的 Subagent + 连接到你的问题跟踪器的 MCP = 一个无与伦比的系统。

  • Skill 固化了团队的规范,无需你操心上下文。
  • Subagents 在处理复杂子任务的同时,保持了主对话的整洁。
  • MCP 消除了分散你注意力的上下文切换。

那些从 Claude Code 中获益最多的工程师,并不是用它来完成一次性任务,而是将其视为一个放大其工作能力的系统。他们投入时间配置技能、定义子代理、连接服务。而这种投入,在后续的每一项任务中都获得了丰厚的回报。

如果你不知从何开始,不妨先为你最常解释的事情创建一个 Skill,或者只创建一个子代理。然后进行测试,并逐步扩展。

写在最后

上下文窗口并不相同。Claude Code 提供稳定的 200K token。Cursor 因内部保护机制,实践中常截断至 70-120K。

Skills(技能) 教会 Claude 你的特定工作流。通过在 ~/.claude/skills/ 下创建带有 YAML frontmatter 和 Markdown 指令的 SKILL.md 文件实现。

Subagents(子代理) 为复杂任务提供隔离的上下文(每个都有独立的 200K 窗口)。通过委托和摘要进行通信,而非共享上下文。

MCP 连接器 消除上下文切换。连接 GitHub、Slack、数据库等,将多标签页工作流整合为一个连续会话。

这些功能会产生复合效应。Skills 编码模式,Subagents 处理子任务,MCP 连接服务。它们共同构建了一个随使用而不断改进的强大系统。掌握这些配置与最佳实践,能极大提升你的 AI 辅助开发效率。

source: https://x.com/eyad_khrais/status/2010810802023141688




上一篇:为什么说搞嵌入式是个系统化的活?从Linux内核dma_buf看硬件零拷贝共享
下一篇:C++性能优化实战:深入CPU流水线、分支预测与缓存机制
您需要登录后才可以回帖 登录 | 立即注册

手机版|小黑屋|网站地图|云栈社区 ( 苏ICP备2022046150号-2 )

GMT+8, 2026-1-16 02:06 , Processed in 0.248271 second(s), 40 queries , Gzip On.

Powered by Discuz! X3.5

© 2025-2025 云栈社区.

快速回复 返回顶部 返回列表