企业官网建设流程全解析

只会「让它写个函数」等于只用了一成能力。这篇讲三个进阶玩法：用 Subagent 隔离上下文、用 Git Worktree 并行开干、用 Hooks 把规矩变成强制执行。附可直接抄的配置。

一、先看差距：初级用法 vs 进阶用法

核心差别就一句话：初级用法是「对话框」，进阶用法是「工作流」。

二、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 会话：

• 终端 1：cd ../proj-pay && claude→ 处理支付重构
• 终端 2：cd ../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.py"""PreToolUse 钩子：拦截对受保护路径的写入。 输入从 stdin 读 JSON；退出码 2 = 阻断操作并把 stderr 反馈给模型。"""importjson,sysfrompathlibimportPath payload=json.load(sys.stdin)tool_input=payload.get("tool_input",{})target=tool_input.get("file_path")ortool_input.get("path")or""PROTECTED=["config/prod",".env","migrations/","secrets"]forpinPROTECTED:ifpinstr(target):print(f"禁止修改受保护路径：{target}（命中规则{p}）",file=sys.stderr)sys.exit(2)# 退出码 2：阻断本次工具调用sys.exit(0)# 其他情况放行

关键机制：退出码2会阻断操作，且stderr的内容会作为反馈给模型——所以错误信息写清楚「为什么不行、该怎么办」，模型往往能自己换个正确做法。

4.3 最值得配的三个 Hooks

五、长任务的上下文管理

会话跑久了上下文会满，几个实用习惯：

1. 主动 compact：感觉回答开始变糊、开始忘记前面说过的事，就是该压缩的时候了；
2. 拆阶段：把「重构整个模块」拆成「先出方案 → 确认 → 改 A 文件 → 跑测试 → 改 B 文件」，每阶段结束可以开新会话；
3. 把结论写进文件：长任务的阶段性结论落到NOTES.md，新会话读它就够，不必背着全部历史；
4. 探索交给 Subagent：这是最有效的省上下文手段（第二节）。

六、一套完整的工作流（可以直接照做）

以「给现有项目加一个导出功能」为例：

1. 起手 > 用 api-explorer 摸清导出现有实现的模式和数据流 2. 出方案（不写代码） > 基于探索结论，给出改动清单：涉及文件、每处改动目的、 > 风险点、需要补的测试。先不要写代码。 3. 人工确认 → 再动手 > 确认，按方案实现，一个一个文件来 4. 自动兜底 （PostToolUse hook 自动格式化；Stop hook 自动跑测试） 5. 审查 > 用 reviewer 审查本次改动 6. 并行推进下一块 git worktree add ../proj-next -b feature/next （开新终端，独立会话处理不相关的另一件事）

关键在第 2 步和第 3 步——先要方案、确认后再动手，能拦掉大量「改了一堆但方向错了」的返工。

七、踩坑清单

八、效率提升的检查清单

• 项目有AGENTS.md，模型不用猜命令和约定；
• 至少配了 1 个只读探索型 Subagent；
• 至少配了 1 个审查型 Subagent；
• PreToolUse 拦截了生产配置、.env、密钥；
• PostToolUse 自动跑格式化，Stop 自动跑测试；
• 复杂需求先出方案再动手，这是最省时间的一条；
• 独立并行任务用 Worktree 分目录，不互相干扰。

这三个能力（Subagent / Worktree / Hooks）合起来，才是「AI 编程工具」和「AI 编程工作流」的分界线。