子代理和 Skills 怎么写?3 个实用例子

0 阅读5分钟

子代理和 Skills 怎么写?3 个实用例子

技术系列第 3 篇,也是收官篇。前两篇装好了"说明书"和"门锁",这篇解决最后一个问题:当任务太多、角色太杂,主对话装不下的时候,怎么把活分出去。

一、先分清四个东西

用 Claude Code 时间长了,常见两个毛病:一是上下文越聊越满,翻过的大文件、跑过的长输出全堆在对话里,越到后面越迟钝;二是角色混杂,刚才还在写代码,转眼又要它当审查员,自己审自己,难免放水。

解法是让不同的活有不同的"容器"。先把四个容易混淆的东西摆在一起:

  • CLAUDE.md:常驻的说明书,每次会话都会读
  • 斜杠命令:你手动触发的提示词模板,放在 .claude/commands/*.md
  • 子代理:独立上下文的助手,有自己的窗口、可限定的工具
  • Skills:按需自动调用的能力包,一个目录、一份 SKILL.md

子代理和 Skills 最容易讲不清。看一张图:主对话就像你本人,子代理是你请的专门助手——它有自己的工位(独立上下文),干完活只把结论带回来,过程中的细节不会挤占你的脑子。

二、例子 1:代码审查员子代理

完整文件,保存为 .claude/agents/code-reviewer.md:

---
name: code-reviewer
description: 代码审查员。在完成一个功能或修复后使用。对照改动做
  质量与安全审查,按严重级别输出报告。主动使用。
tools: Read, Grep, Glob, Bash
---
你是资深代码审查员。工作方式:
1. 先运行 git diff 查看本次改动,再按需读取相关文件
2. 只审查,不修改任何文件
3. 按严重级别输出:
   - 必须修复:安全漏洞、逻辑错误、数据丢失风险
   - 建议:边界条件、错误处理、明显性能问题
   - 可选:命名、重复代码
4. 每条注明文件和行号,没有问题就直说没有

三处值得抄:tools 只给只读工具,它想改也改不了;description 写清"什么时候用",Claude 才会在合适的时机主动委派;"只审查不修改"写进正文,防止它顺手改代码。平时不用特意叫,改完一段代码它就可能被派来;也可以明确说"让 code-reviewer 审一遍"。

三、例子 2:测试排查员子代理

测试挂了最烦:报错一大屏,改哪儿都不确定。让专门的助手先去查,保存为 .claude/agents/test-debugger.md:

---
name: test-debugger
description: 测试失败排查员。在测试报错且原因不明时使用。负责定位
  原因并给出最小修复建议。测试失败时主动使用。
tools: Read, Grep, Glob, Bash
---
你是测试排查员。流程:
1. 先运行失败的测试,复现报错
2. 用 Grep 定位相关代码,区分三种情况:
   代码有 bug / 测试已过时 / 环境有问题
3. 给出最小修复建议。禁止修改测试来迁就代码;
   若认为测试本身错了,说明理由,由主对话决定
4. 输出:原因 → 证据(文件:行号) → 建议的最小改动

红线只有一条:不许偷偷改测试让它们变绿。这条写进系统提示,它就只能老老实实查原因。会话里输入 /agents 能看到这两个子代理是否已经加载。

四、例子 3:release-notes 技能

技能和子代理不同:它不是一个人,而是一个目录。建 .claude/skills/release-notes/,里面放两个文件:

release-notes/
├── SKILL.md
└── template.md

SKILL.md:

---
name: release-notes
description: 把 git log 整理成发布说明。当用户要求写更新日志、
  release notes、版本说明时使用。
---
# 步骤
1. 运行 git log --oneline <上一版本号>..HEAD 获取提交
2. 按模板整理;无法归类的提交放入"其他"
3. 只依据提交记录,不要推测功能细节
具体格式参考本目录下 template.md

template.md 就是你的发布说明格式:新增、修复、优化、破坏性变更四栏。

用法:对 Claude 说"根据上个版本生成发布说明",它匹配到 description 就会读这个技能。技能的好处是渐进加载:平时只有一个 description 占着上下文,用到时才读正文和模板,比把格式规则全写进 CLAUDE.md 省得多。

五、description 决定生死

三个例子里最值钱的一行,都是 frontmatter 里的 description。它是 Claude 派活的依据:写得好,该出手时就出手;写得差,要么永远不被调用,要么动不动乱入。

四条写法:

  1. 写清做什么 + 什么时候用,别只写名字
  2. 带上触发词:用户会说"审查""排查""发布说明",就写进去
  3. 写明主动使用,否则它可能只等你点名
  4. 有边界:写明"只做 X,不做 Y"

六、没被调用?按这个查

  • description 太泛或太抽象 → 加场景和触发词
  • 文件放错位置 → 子代理在 .claude/agents/,技能在 .claude/skills/<名字>/SKILL.md
  • 好像没生效 → 新开会话再试,或用 /agents 确认已加载
  • 名字和内置工具冲突 → 换个更具体的名字

具体字段和加载细节以官方文档为准,版本之间可能有差异。

七、安全提醒

技能和子代理里可以写脚本、可以授权工具,等于给 Claude 加能力。用第三方的之前,把每个文件读一遍:命令能不能信任、工具权限是否最小化、有没有让你输入密钥的步骤。自己的配置也遵守最小权限:审查员只给只读工具,排查员不给写权限。

系列总结

三篇凑成一套:CLAUDE.md 是说明书,Hooks 是门锁,子代理和 Skills 是分身。从今天开始的最小路径:先写一份 20 行的 CLAUDE.md,再加一个 Stop 提醒的 hook,最后把你最常叮嘱的事变成子代理或技能。一套下来,Claude Code 才算真正"记得住事、守得住规矩、分得出去活"。