只会「让它写个函数」等于只用了一成能力。这篇讲三个进阶玩法用 Subagent 隔离上下文、用 Git Worktree 并行开干、用 Hooks 把规矩变成强制执行。附可直接抄的配置。文章目录一、先看差距初级用法 vs 进阶用法二、Subagent给探索任务单独开一间房2.1 它解决什么问题2.2 定义自己的 Subagent2.3 怎么用三、Git Worktree真正的并行开发3.1 为什么需要它3.2 实操3.3 收尾四、Hooks把「约定」变成「强制执行」4.1 概念软约束 vs 硬约束4.2 实战禁止改生产配置4.3 最值得配的三个 Hooks五、长任务的上下文管理六、一套完整的工作流可以直接照做七、踩坑清单八、效率提升的检查清单一、先看差距初级用法 vs 进阶用法场景初级用法进阶用法让它改个功能直接说「帮我改」先让它出「改动清单」确认后再改大项目探索一个会话问到上下文爆用 Subagent 独立探索只回结论多个任务排队一个个做Git Worktree 开多个会话并行代码规范写在配置文件里靠它自觉Hooks 拦截违规直接阻断长任务一个会话跑到底拆阶段 定期 compact核心差别就一句话初级用法是「对话框」进阶用法是「工作流」。二、Subagent给探索任务单独开一间房2.1 它解决什么问题在一个会话里做代码探索有个致命问题搜索过程中读了几十个文件这些内容全部留在上下文里把真正重要的对话挤出去了。聊到一半你就会感觉「它开始忘事」。Subagent 的机制在独立上下文里干活只把最终结论返回主会话。搜索过程的噪声被隔离掉。2.2 定义自己的 Subagent在项目根建.claude/agents/目录每个 Subagent 一个 Markdown 文件!-- .claude/agents/api-explorer.md -- --- name: api-explorer description: 探索后端 API 结构。当需要了解路由、鉴权、数据模型时使用。 tools: Read, Grep, Glob --- 你是后端代码探索专家。你的任务是快速定位并总结不要修改任何文件。 输出格式要求严格遵循控制在 300 字内 1. **入口**路由注册在哪个文件 2. **鉴权**中间件名称与生效方式 3. **数据模型**涉及的模型文件与关键字段 4. **坑**你发现的不一致或可疑之处 只回答被问到的内容不要扩展阅读无关代码。两个设计要点tools只给只读工具Read/Grep/Glob。探索类 Subagent 绝不该有写权限否则它可能「顺手」改东西description要写清触发场景——主 Agent 靠它判断什么时候该派活返回格式写死否则它给你一篇小论文等于没隔离。2.3 怎么用 用 api-explorer 摸一下支付模块的路由和数据模型主 Agent 会派发任务等它回一份 300 字的摘要——你的主上下文干干净净。再配一个「代码审查」Subagent给它写权限但只用于跑测试!-- .claude/agents/reviewer.md -- --- name: reviewer description: 对改动做代码审查。提交前使用。 tools: Read, Grep, Bash --- 你是严格但不啰嗦的代码审查者。只输出问题清单格式 - [严重] 文件:行号 —— 问题 —— 建议 - [一般] ... - [建议] ... 没有问题的类别直接省略不要写「一切正常」之类的废话。 审查重点错误处理、并发安全、边界条件、是否引入未声明依赖。三、Git Worktree真正的并行开发3.1 为什么需要它多人或多个 AI 会话在同一个目录里改代码会互相干扰一个在改 A 文件、另一个 git checkout 就全乱了。Git Worktree 让你从同一个仓库签出多个独立工作目录共享.git但文件互不影响。3.2 实操# 为「支付重构」开一个独立工作目录gitworktreeadd../proj-pay-bfeature/pay-refactor# 为「日志优化」再开一个gitworktreeadd../proj-log-bfeature/log-opt# 查看现有 worktreegitworktree list然后在两个目录里各开一个 Claude Code 会话终端 1cd ../proj-pay claude→ 处理支付重构终端 2cd ../proj-log claude→ 处理日志优化两个会话同时在跑各自有独立的文件状态和上下文不会互相踩。这在「大功能拆成几个独立模块同时推进」时效率提升非常直观。3.3 收尾# 分支合并后清理工作目录gitworktree remove../proj-paygitbranch-dfeature/pay-refactor踩坑worktree 目录里不要再git clone一份仓库会重复占空间且容易搞混改完记得回主目录git pull同步。另外每个 worktree 有独立的node_modules/.venv需求第一次要重新装依赖。四、Hooks把「约定」变成「强制执行」4.1 概念软约束 vs 硬约束写在 CLAUDE.md 里的规则模型可能忘Hooks 是在工具调用前后触发的脚本能直接阻断。区别就是「建议」和「法律」。4.2 实战禁止改生产配置.claude/settings.json{hooks:{PreToolUse:[{matcher:Edit|Write,hooks:[{type:command,command:python .claude/hooks/guard_paths.py}]}],PostToolUse:[{matcher:Edit|Write,hooks:[{type:command,command:ruff check --fix $CLAUDE_FILE_PATH || true}]}]}}# .claude/hooks/guard_paths.pyPreToolUse 钩子拦截对受保护路径的写入。 输入从 stdin 读 JSON退出码 2 阻断操作并把 stderr 反馈给模型。importjson,sysfrompathlibimportPath payloadjson.load(sys.stdin)tool_inputpayload.get(tool_input,{})targettool_input.get(file_path)ortool_input.get(path)orPROTECTED[config/prod,.env,migrations/,secrets]forpinPROTECTED:ifpinstr(target):print(f禁止修改受保护路径{target}命中规则{p},filesys.stderr)sys.exit(2)# 退出码 2阻断本次工具调用sys.exit(0)# 其他情况放行关键机制退出码2会阻断操作且stderr的内容会作为反馈给模型——所以错误信息写清楚「为什么不行、该怎么办」模型往往能自己换个正确做法。4.3 最值得配的三个 Hooks时机动作收益PreToolUse拦截受保护路径写入杜绝「顺手改了生产配置」PostToolUse自动跑格式化/类型检查省掉一轮「改完再让你修 lint」Stop结束前跑一遍测试交付前自动兜底避免把坏的留下五、长任务的上下文管理会话跑久了上下文会满几个实用习惯主动 compact感觉回答开始变糊、开始忘记前面说过的事就是该压缩的时候了拆阶段把「重构整个模块」拆成「先出方案 → 确认 → 改 A 文件 → 跑测试 → 改 B 文件」每阶段结束可以开新会话把结论写进文件长任务的阶段性结论落到NOTES.md新会话读它就够不必背着全部历史探索交给 Subagent这是最有效的省上下文手段第二节。六、一套完整的工作流可以直接照做以「给现有项目加一个导出功能」为例1. 起手 用 api-explorer 摸清导出现有实现的模式和数据流 2. 出方案不写代码 基于探索结论给出改动清单涉及文件、每处改动目的、 风险点、需要补的测试。先不要写代码。 3. 人工确认 → 再动手 确认按方案实现一个一个文件来 4. 自动兜底 PostToolUse hook 自动格式化Stop hook 自动跑测试 5. 审查 用 reviewer 审查本次改动 6. 并行推进下一块 git worktree add ../proj-next -b feature/next 开新终端独立会话处理不相关的另一件事关键在第 2 步和第 3 步——先要方案、确认后再动手能拦掉大量「改了一堆但方向错了」的返工。七、踩坑清单现象原因解决Hook 不生效配置文件路径或 JSON 格式错检查.claude/settings.json注意不要留尾逗号Hook 把正常操作也拦了匹配规则太宽用更精确的路径匹配先跑一遍日志再收紧Subagent 返回一大段废话输出格式没约束在 agent 文件里写死输出结构 字数上限Worktree 里依赖跑不起来依赖目录是独立的每个 worktree 重新装依赖会话越聊越笨上下文满了compact / 拆会话 / 用 Subagent 做探索八、效率提升的检查清单项目有AGENTS.md模型不用猜命令和约定至少配了 1 个只读探索型 Subagent至少配了 1 个审查型 SubagentPreToolUse 拦截了生产配置、.env、密钥PostToolUse 自动跑格式化Stop 自动跑测试复杂需求先出方案再动手这是最省时间的一条独立并行任务用 Worktree 分目录不互相干扰。这三个能力Subagent / Worktree / Hooks合起来才是「AI 编程工具」和「AI 编程工作流」的分界线。