如何正确用好 Claude Code 的 general-purpose（附一个反面教材）

general-purpose 真的又慢又笨吗？大多数时候不是------是派活的方式错了。今天用一个真实的反面教材，手把手教你怎么正确用它。

先搞清楚：general-purpose 到底是什么

在 Claude Code 里，你和我对话的这个窗口是「主会话 」，相当于大脑。但有些活不适合大脑亲自干------比如要同时处理好几件事、要隔离上下文、或者就是一些琐碎的批量操作。这时候，就可以「派生」（spawn）一个子代理（subagent） 出去专门干活。

子代理分两种：

general-purpose（通用子代理） ：内置的「万能工」，没被特别定制。什么工具都能用、什么活都能接，但脑子里没有你项目的任何预设信息------开工前，只能靠你给的任务书 + 自己现场侦察。
自定义 agent（定制子代理） ：你按特定场景调教过的「熟练工」，通过 .claude/agents/*.md 定义，里面提前写好了路径、命令、红线。相当于带着「入职手册」上岗。

一句话记住区别 👇

general-purpose 是「白纸万能工」，自定义 agent 是「带手册熟练工」。

本文要聊的，就是怎么把这张白纸用好------用不好，它就成了下面这个反面教材。

一个误会：它慢，多半是你的锅

很多人吐槽 general-purpose「磨叽」「不靠谱」，但真相是：

自定义 agent：带手册上岗，开工即用
general-purpose：白纸一张，只有你丢给它的那份任务书

它慢不慢，几乎完全取决于你那份任务书写得怎么样。下面这个反例，就是我把任务书写砸了的现场。

反面教材：一次 git 推送，为什么磨了 13 分钟

上周有个活：两个仓库要 登记 → commit → push → 镜像，四步链。我的派活链路长这样：

三层嵌套链路

plaintext

markdown 复制代码

第1层  主会话（掌握全部上下文，但不直接碰 git）
        │  写任务书：6+1 件、排除清单、commit message、四步链
        ▼
第2层  自定义 agent（自带手册）
        │  它没自己跑 git，又把活儿拆了一层
        ▼
第3层  执行子 agent（general-purpose，白板）
        冷启动：仓库长啥样？.gitignore 的 M 是什么？
        pom.xml 为啥是脏的？→ 全是现场查

结果：

15:22 启动 → 15:35 才完成仓 1 commit，光第一步就磨了 13 分钟

复盘下来，我犯了三个错误，正好是大多数人的通病 👇

❌ 错误一：让白板 agent 干「需要上下文」的活

第 3 层那个 general-purpose 白纸一张，却要它理解「这个仓库的 .gitignore 为什么有 M、pom.xml 为什么是脏的、哪些文件算越界」------这些答案，第 1 层我全知道，第 2 层手册里也写了大半。让一个没有记忆的人，去重建一份别人早就有的认知，注定慢。

❌ 错误二：任务书层层转手

任务书转了两手：我 → 自定义 agent → 子 agent。每转一手，信息可能丢、格式要重写、下一层要重新理解。三层里任何一层慢，整体就慢。

❌ 错误三：参数没给全，逼它自己猜

最致命的失误：我在任务书里把镜像路径写错了 。自定义 agent 按错误路径去，发现结构对不上，只好把整个目录扫一遍找正确路径------多花一整轮侦察。

一句话总结这个反例 👇

我把一个「参数残缺、层层转手、还要求现场侦察」的活，丢给了一个白板执行者。它慢，是必然的。

选型：什么时候用 general-purpose，什么时候用自定义 agent

会用之前，先得会「选」。这两个工具不是谁替代谁，而是各管一段：

维度	general-purpose（白纸万能工）	自定义 agent（带手册熟练工）
适合的活	一次性、探索性、边界清晰、结果可独立验证	有固定套路、反复要做、强依赖项目约定
上下文	白纸，靠任务书现场喂	手册预载，开工即用
启动成本	每次都冷启动侦察一遍	定义一次，反复复用
典型场景	搜代码、跑脚本、批量改名、陌生仓库探险、一次性数据整理	固定格式的 commit、定时巡检、特定平台的发布流程

判断标准就一句话：

「这件事我下个月还会不会做？」会 → 自定义 agent；不会 → general-purpose。

几个实战例子，一眼就能对号入座：

「帮我搜下这个函数在哪些地方被调用」→ general-purpose（一次性探索）
「探索一下这个陌生仓库的目录结构」→ general-purpose（探险）
「每次发版都要走的 git 提交流程」→ 自定义 agent（反复、有套路）
「按公司规范生成 commit message」→ 自定义 agent（强依赖约定）

选对工具，问题就解决了一半；选错了，再好的任务书也救不回来------那个反例里，我最大的错其实不是任务书写砸了，而是把一个本该由自定义 agent 干的固定流程，硬塞给了白板万能工。

正确姿势：五条照着做

反例正解对照

选对工具之后，剩下五条实操：

✅ 1. 任务书写成「傻瓜都能照着做」

别写「把代码提交了」，要写到这种颗粒度：

plaintext

bash 复制代码

对 src/xxx.java、src/yyy.java 执行 git add；
确认暂存区干净、无 pom.xml 混入；
commit message 用「FnCros0011 日终检查改造」；
完成后回传 git log 最后一条。

环境参数一次给全：路径、命令、配置位置、红线。白板 agent 最怕「东西在哪儿」这种要猜的问题------你替它把答案写进去，它就不用侦察了。

✅ 2. 明确要求「不嵌套、直接执行」

能自己敲的命令，就别再 spawn 子代理。任务书里直接加一句：「你自己直接执行，不要派生任何子代理。 」

✅ 3. 拆任务：小步走、每步可验证

别把大活一口气全丢给它。拆成小步骤，每完成一步就回报关键结果（比如「已 commit，最后一笔 hash 是 xxx」），再放它去下一步。跑偏了能早发现。

✅ 4. 复杂任务先要「计划」，再放行

路径多、分支多的活，先让它输出执行计划给你过目，确认无误再动手。多花 30 秒看计划，能省 10 分钟的重跑。

✅ 5. 结果要「可验收」

干完活别光听它说「完成了」，要它回传可核对的证据------最后一笔 commit 的 hash、改动的文件清单、执行日志。白板 agent 的「完成」和你的「完成」往往不是一个意思，要它用数据证明。

核心心法就一句：别把「动脑的活」和「查环境的活」混着派。 动脑的活自己留好上下文，查环境的活把答案直接喂给它。

总结

回到开头那个误会：general-purpose 慢，不是它「蠢」，而是你让它从零重建了一份本可以不用重建的认知。

这跟写代码一个道理：能复用的沉淀成模块（自定义 agent），不能复用的把依赖注入清楚（任务书参数给全）。 子代理的效率，本质是「任务书工程」的效率------那个 13 分钟的反例，就是我「任务书工程」没做好的代价。

把派活当门手艺练，你的 general-purpose 会快得让你意外。

参考资料：本文基于一次真实的 Claude Code 多仓库 git 推送任务的复盘