Claude Code Session Patterns
一份从 Claude Code 中获得有用产出的实战 playbook:模型选择、会话结构、并行化,以及每个模式背后隐藏的权衡。
Claude Code 是 Anthropic 的终端编码 agent。产品表面很小 —— 一个 CLI 加几个 hook —— 但你组织会话的方式对产出质量、延迟和成本有不成比例的影响。本模块汇集了在研究、编码和运维会话中都成立的模式,并指出每个模式在哪里会失效。
1. 模型选择:按任务形状选,而非反射性选
默认反射是"用最强的模型"。错。最强的模型慢且贵,大多数任务不需要它。更好的启发式是把模型匹配到任务形状。
| 任务形状 | 模型 | 原因 |
|---|---|---|
| 深度研究、架构、跨文件横向推理的多文件重构 | Opus(当文件跨越大型 repo 时用 1M 上下文档) | 推理深度和长上下文容忍度主导延迟 |
| 日常编码、单文件编辑、机械 bug 修复、文档生成 | Sonnet | 足够快保持心流状态,对 ~90% 的编辑足够强 |
| 批量转换、简单工具调用、脚本胶水 | Haiku | 延迟主导;在这种任务规模下质量差异不可见 |
跑一段时间后浮现的几条实用规则:
- 会话中往下切换,不往上切换。 如果 Sonnet 会话进展良好,在 Sonnet 上结束比为"打磨 pass"换到 Opus 更快。打磨 pass 很少改变正确性;它们大多烧 token。
- 当遇到真正的推理墙时往上切换,而不是输出看起来略有不对时。"略有不对"通常是 prompt 问题。
- 1M 上下文 Opus 用在 repo 即是 prompt 时。 如果你能用两段话描述相关文件,你不需要 1M 上下文 —— 你需要更好的文件选择。
- 避免任务中途 A/B 模型。 任务中途切换模型会重置模型对你代码库约定建立起来的隐含工作记忆。
相关:openrouter 用于跨 provider 路由,openclaw-optimization 在不同 agent 框架中的类似权衡。
2. 会话结构:研究与编码流程形状不同
研究与编码会话表面看相似(都是"问 Claude 东西,拿到文本"),但正确的结构不同。
研究会话
- 宽范围查询 —— 框定问题,要一个 landscape,接受第一个答案会浅。
- 深度 pass —— 挑 2–4 条线索,用具体实体或主张做 follow-up 验证。
- 对抗 pass —— 要求最强的反论、最弱的假设、什么能证伪论点。这是大部分价值的来源。
- 综合 —— 要求结构化输出(表格、对比、排名列表)。指定结构;不要让模型选。
- 保存 —— markdown 写盘,不是聊天。会话结束时,没写下来的就丢失了。
编码会话
- 需求 + 约束 —— 要构建什么、不能破坏什么、哪些现有文件相关。
- 先计划,再编码 —— 在生成任何代码前要一个带文件级粒度的计划。修改计划便宜;修改 800 行代码贵。
- 切片迭代 —— 一次一个组件或一个函数。长生成是质量最快下降的地方。
- 边写边测 —— 能编译的生成代码不是能工作的生成代码。差异在第一个测试中显示。
- 最后写文档 —— README/注释在代码稳定之后,而不是之前。
常见失败模式是用研究流程做编码("只给我一个计划和一次性的代码")或用编码流程做研究("只给我答案")。两者都产出平庸输出。
3. 通过子代理并行化
Claude Code 可以派生子代理。可行的模式:
- 为独立工作 fan out:搜索多个目录、总结几个文档、对相同代码库检查 N 个假设。子代理并行运行并把文本返回给父代理。
- 不要为顺序工作 fan out:每个子代理失去父代理的上下文,因此需要连续性的多步推理在拆分后变得更糟,而非更好。
- 把子代理输出当作不可信:父代理应该在采取行动前验证或至少通读结果。子代理与父代理以相同的速率幻觉文件路径和 API。
- 预算 fan-out:3–5 个并行子代理通常是甜蜜点。再多,父代理的工作就变成"合并很多略有冲突的总结",这是它自己的失败模式。
延迟收益是真实的 —— 一个 5 路 fan-out 用于代码库探索大致在一次慢探索的时间内完成 —— 但仅当子任务真正独立时。
4. 待办跟踪与结构化计划
Claude Code 在其循环中维护一个待办列表。两个重要模式:
- 早期让待办列表显式化。 让 agent 在执行之前把计划写成待办,可以在最便宜的点上揭示歧义。坏计划显而易见;坏执行不是。
- 不要让列表漂移。 当会话中途出现新任务,它们应该落入待办列表,而不是成为静默的额外工作。与已完成不匹配的任务列表比没有列表更糟。
这与运行长任务的人类相同的纪律 —— 价值在于计划可见且可修订,而不在格式化。
5. Hook 与框架配置
Claude Code 支持在 settings.json 中配置的生命周期 hook(UserPromptSubmit、Stop 等)。有用的模式:
- 日志 hook 捕获会话记录供以后回顾。否则会话是临时的。
- 预飞 hook 注入项目上下文(当前分支、最近失败的测试、打开的待办文件)。比每次会话重新输入相同上下文便宜。
- Stop hook 自动运行 linter、formatter 或会话后总结。
Hook 不是魔法 —— 它们是框架在固定点运行的 shell 命令。陷阱是过度工程:静默重写 prompt 或自动提交的 hook 比有帮助更危险。保持 hook 可观察、幂等。
相关:openclaw-optimization 在 openclaw / hermes-agent 家族中的类似 hook 模式。
6. 输出纪律
会话产出文本。如果文本没有挺过会话,它就是无用的。
- 任何可复用的东西写到 markdown 盘上。 聊天输出消失;文件不会。
- 对比用表格,代码用代码块,论点用散文。 在单一回答内混合这些更难扫描、更难提取。
- 预先要求格式。 "对比 X 和 Y"产出散文;"对比 X 和 Y 作为带列 A、B、C 的表格"产出表格。如果你精确询问,模型会给你你要的。
- 把数字当作可疑的。 模型输出中的任何 benchmark、价格或统计数据在进入公开文档前应该交叉核对。速度和价格每周变化;模型的训练数据不会。
7. 成本与延迟观察
几个反复出现的粗略模式:
- 简单查询的延迟由网络和 token decode 时间主导,而非推理。 在一次性查询上从强模型切到快模型节省秒数,而非分钟。
- 复杂推理的延迟由输出长度主导。 要求更短、更结构化的输出比选更快模型是更大的胜利。
- 成本随上下文扩展,而不仅是输出。 大上下文窗口的长会话即使每个单独响应很短也会变贵。压缩或开启新会话比让上下文无限增长便宜。
- 预算紧时 provider 路由很重要。 同一模型名,不同 provider,不同成本和延迟。见 hermes-openrouter-models。
8. 何时 Claude Code 是错误的工具
值得明确指出:
- GUI 密集工作。 原生桌面或浏览器自动化属于 computer-use 或浏览器控制工具,而非 CLI agent。
- 实时 / 交互调试。 单步调试器或观察实时日志是人在回路任务;编码 agent 在该循环中太慢。
- 一个错动作就灾难性的任务。 迁移、强推、金融交易。用 agent 起草命令,然后自己执行。
- 微小编辑。 两字符 typo 修复不需要 agent。往返成本超过编辑成本。
通则:如果瓶颈是你的打字速度,agent 帮忙。如果瓶颈是判断,agent 是草稿工具,而非最终执行者。
相关
- openclaw-optimization —— agent 框架优化模式
- openclaw-optimization —— 相邻框架中的 hook 和生命周期模式
- openrouter —— 跨 provider 模型路由
- deep-research-workflow —— 更广范围内的研究流模式