Everything Claude Code 终极指南

在《Claude Code 快速上手指南》里，我已经把基础配置都讲透了：技能和命令、钩子、子代理、MCP、插件，还有那些构成高效 Claude Code 工作流核心的配置模式。那篇是安装指南，也是基础架构。

Claude Code 终极速成指南

这是我深度使用十个月后，最终打磨出来的完整配置方案：包括各种技能、钩子、子代理、MCPs、插件，以及那些真正好用的部分。从二月份 Claude Code 开始实验性内测起，我就是它的忠实用户了，而且……

而这篇长篇指南要聊的，是那些真正区分高效会话和无效内耗的技巧。如果你还没读过快速上手指南，赶紧回去先把你的配置搞定。接下来的内容，都默认你已经把技能、代理、钩子和 MCP 都配置好并且能用了。

这里的核心主题是：令牌经济学、记忆持久化、验证模式、并行化策略，以及构建可复用工作流带来的复合效应。这些都是我过去 10 个多月天天实战打磨出来的模式，它们决定了你是会在第一个小时就饱受上下文腐化之苦，还是能持续高效工作好几个小时。

简版和长篇文章里提到的所有内容，都可以在 GitHub 的这个仓库找到：everything-claude-code

Context & Memory Management 上下文与记忆管理

要想在不同会话之间共享记忆，最好的办法是：用一个技能或命令来总结和检查当前进度，然后把内容保存到你 `.claude` 文件夹里的一个 `.tmp` 文件中，并且在整个会话期间不断往里追加内容。这样第二天，它就能以此为上下文，接着你上次停下的地方继续干活。记得为每个会话创建新文件，免得把旧的上下文搅和到新工作里。时间一长，你就会攒下一大堆这样的会话日志文件夹——找个有意义的地方备份一下，或者把不需要的会话记录清理掉就行。

Claude 会创建一个文件来总结当前状态。你检查一下，如果需要修改就提出来，然后就可以重新开始了。进行新的对话时，直接把文件路径给它就行。这招在你碰到上下文长度限制、需要继续处理复杂工作时特别管用。这些文件里应该包含：哪些方法确实管用（要有证据验证），哪些方法试了但没成功，哪些方法还没尝试过，以及接下来还有什么要做的。

Clearing Context Strategically: 策略性地清理上下文：

一旦你制定好计划并清理了上下文（claude code 中计划模式的默认选项现在就有这个功能），你就可以按计划推进了。这在积累了太多与当前执行无关的探索性上下文时特别有用。要进行策略性压缩，请关闭自动压缩功能。在逻辑节点手动压缩，或者创建一个技能来帮你完成，或者根据某些定义好的标准来建议何时压缩。

Strategic Compact Skill

#!/bin/bash
# Strategic Compact Suggester
# Runs on PreToolUse to suggest manual compaction at logical intervals
#
# Why manual over auto-compact:
# - Auto-compact happens at arbitrary points, often mid-task
# - Strategic compacting preserves context through logical phases
# - Compact after exploration, before execution
# - Compact after completing a milestone, before starting next

COUNTER_FILE="/tmp/claude-tool-count-$$"
THRESHOLD=${COMPACT_THRESHOLD:-50}

# Initialize or increment counter
if [ -f "$COUNTER_FILE" ]; then
  count=$(cat "$COUNTER_FILE")
  count=$((count + 1))
  echo "$count" > "$COUNTER_FILE"
else
  echo "1" > "$COUNTER_FILE"
  count=1
fi

# Suggest compact after threshold tool calls
if [ "$count" -eq "$THRESHOLD" ]; then
  echo "[StrategicCompact] $THRESHOLD tool calls reached - consider /compact if transitioning phases" >&2
fi

把它挂到 Edit/Write 操作的 PreToolUse 上——等你攒够了上下文，感觉压缩一下可能更高效的时候，它就会贴心提醒你啦！

高级玩法：动态系统提示注入

我最近摸索出一个新法子，正在试水：别一股脑把所有东西都塞进 CLAUDE.md（用户级）或者 .claude/rules/（项目级）里，那样每次会话都得全量加载。改用 CLI 参数来动态注入上下文，灵活多了！

claude --system-prompt "$(cat memory.md)"

这样一来，你就能更精准地控制什么时候加载什么上下文。可以根据手头的工作，为每个会话注入不同的上下文。

这比用 @ 引用文件好在哪儿呢？

当你使用 @memory.md 或者把东西放在 .claude/rules/ 里时，Claude 会在对话过程中通过 Read 工具来读取——它是以工具输出的形式进来的。而当你使用 `–system-prompt` 时，内容会在对话开始前就被注入到实际的系统提示词里。

区别在于指令的优先级。系统提示词内容的权重最高，用户消息次之，工具结果的权重最低。对于大多数日常工作来说，这点差别可能无关紧要。但对于那些严格的行为规则、项目特定的限制，或者你绝对需要 Claude 优先考虑的上下文来说——用系统提示词注入，就能确保它得到应有的重视。

Practical setup实用配置方案:

一个靠谱的做法是，用 .claude/rules/ 目录来存放你项目的基础规则，然后针对不同场景的上下文，设置一些 CLI 别名方便随时切换：

# Daily development
alias claude-dev='claude --system-prompt "$(cat ~/.claude/contexts/dev.md)"'

# PR review mode
alias claude-review='claude --system-prompt "$(cat ~/.claude/contexts/review.md)"'

# Research/exploration mode
alias claude-research='claude --system-prompt "$(cat ~/.claude/contexts/research.md)"'

System Prompt Context Example Files系统提示词上下文示例文件

(Direct Link):

dev.md 专注于实施
review.md 关于代码质量/安全性
research.md 在行动前进行探索

再说一遍，对于大多数情况，使用 `.claude/rules/context1.md` 和直接把 `context1.md` 内容塞进系统提示词里，效果其实差不了多少。用命令行（CLI）的方式更快（不用调用工具）、更稳（系统级权限），还能省那么一丁点儿 token。但这只是个锦上添花的小优化，对很多人来说，搞这套的功夫可能比它带来的好处还多。

进阶玩法：记忆持久化Hooks

其实有几个能提升记忆的 Hook，很多人要么不知道，要么没用对，白白浪费了：

SESSION 1                              SESSION 2
─────────                              ─────────

[Start]                                [Start]
   │                                      │
   ▼                                      ▼
┌──────────────┐                    ┌──────────────┐
│ SessionStart │ ◄─── reads ─────── │ SessionStart │◄── loads previous
│    Hook      │     nothing yet    │    Hook      │    context
└──────┬───────┘                    └──────┬───────┘
       │                                   │
       ▼                                   ▼
   [Working]                           [Working]
       │                               (informed)
       ▼                                   │
┌──────────────┐                           ▼
│  PreCompact  │──► saves state       [Continue...]
│    Hook      │    before summary
└──────┬───────┘
       │
       ▼
   [Compacted]
       │
       ▼
┌──────────────┐
│  Stop Hook   │──► persists to ──────────►
│ (session-end)│    ~/.claude/sessions/
└──────────────┘

PreCompact Hook：在上下文压缩发生前，把重要的状态存到文件里
SessionComplete Hook：会话结束时，把学到的东西持久化保存到文件
SessionStart Hook：新会话启动时，自动加载之前的上下文

Memory Persistant Hooks持久化内存钩子

{
  "hooks": {
    "PreCompact": [{
      "matcher": "*",
      "hooks": [{
        "type": "command",
        "command": "~/.claude/hooks/memory-persistence/pre-compact.sh"
      }]
    }],
    "SessionStart": [{
      "matcher": "*",
      "hooks": [{
        "type": "command",
        "command": "~/.claude/hooks/memory-persistence/session-start.sh"
      }]
    }],
    "Stop": [{
      "matcher": "*",
      "hooks": [{
        "type": "command",
        "command": "~/.claude/hooks/memory-persistence/session-end.sh"
      }]
    }]
  }
}

它们的作用是：

pre-compact.sh : 记录压缩事件，并用压缩时间戳更新活动会话文件
session-start.sh: 检查最近的会话文件（过去7天），通知可用上下文和已掌握技能
session-end.sh: 使用模板创建/更新每日会话文件，记录开始/结束时间

把这些脚本串起来用，就能实现跨会话的连续记忆，完全不用你手动操心。这套机制是基于第一篇文章里提到的钩子类型（PreToolUse、PostToolUse、Stop）设计的，但专门针对会话的生命周期进行了优化。

Continuous Learning / Memory 持续学习与记忆

我们之前聊过通过更新代码地图来实现持续记忆更新，但这招儿同样适用于其他场景，比如从错误中学习。如果你遇到过这种情况：同一个提示词得反复输入好几遍，或者 Claude 老是栽在同一个坑里、给出的回答你听着都耳熟——那这部分内容就是为你准备的。

这时候你八成得再发个提示词来“掰正方向”，给 Claude 的指南针做个校准。这类情况都适用同一个道理：那些反复出现的模式必须被收录进技能库里。

现在你可以轻松实现自动化：直接告诉 Claude 记住这个情况，或者把它添加进你的规则列表。当然，你也可以直接配置一个专门处理这类问题的技能。

问题来了：白费了 tokens，浪费了上下文，还搭进去一堆时间。更气人的是，你血压飙升，对着 Claude 怒吼，让它别再干你上次明明已经告诉它别干的事儿了！

解决方案是这样的：当 Claude Code 发现一些不简单的技巧——比如某个调试方法、一个变通方案，或者项目特有的模式时，它就会把这些知识存成一个新技能。下次再遇到类似的问题，这个技能就会自动加载起来。

Continuous Learning Skill (Direct Link):持续学习能力：

我干嘛不用 UserPromptSubmit 而选了 Stop hook 呢？UserPromptSubmit 这玩意儿每次发消息都会跑一遍——开销太大了，每个提示都得等它，说实在的，搞这个纯属杀鸡用牛刀。Stop 就轻巧多了，只在会话结束时跑一次，干活的时候完全不拖后腿，而且能评估整个会话，不是东一榔头西一棒槌的。

Installation:

# Clone to skills folder
git clone https://github.com/affaan-m/everything-claude-code.git ~/.claude/skills/everything-claude-code

# Or just grab the continuous-learning skill
mkdir -p ~/.claude/skills/continuous-learning
curl -sL https://raw.githubusercontent.com/affaan-m/everything-claude-code/main/skills/continuous-learning/evaluate-session.sh > ~/.claude/skills/continuous-learning/evaluate-session.sh
chmod +x ~/.claude/skills/continuous-learning/evaluate-session.sh

Hook Configuration

{
  "hooks": {
    "Stop": [
      {
        "matcher": "*",
        "hooks": [
          {
            "type": "command",
            "command": "~/.claude/skills/continuous-learning/evaluate-session.sh"
          }
        ]
      }
    ]
  }
}

这个功能利用 Stop hook，在每次会话结束时自动运行一个激活脚本，帮你“淘金”——把那些值得提炼的知识点都筛出来。当然，技能也能通过语义匹配来触发，但有了这个 hook，评估就稳了，次次不落空。

Stop hook 会在你结束会话时自动触发——脚本会仔细“复盘”整个会话，揪出那些值得提取的套路（比如报错怎么解、调试小技巧、临时解决方案、项目特有的模式等等），然后把它们作为可复用的技能存到 ~/.claude/skills/learned/ 目录下，方便你以后随时调用。

想手动提取？用 /learn 命令就行！

你完全不用等到会话结束。这个代码仓库里还包含一个 `/learn` 命令，当你刚刚解决了一个棘手问题时，可以在会话中途随时运行它。它会立刻提示你提取其中的模式，草拟一个技能文件，并在保存前请你确认。具体可以看这里。

**Session Log Pattern会话日志模式: **

这个技能期望会话日志以 `.tmp` 文件形式存在。模式是这样的：`~/.claude/sessions/YYYY-MM-DD-主题.tmp` —— 每个会话一个文件，里面记录了当前状态、已完成事项、遇到的阻碍、关键决策以及为下次会话准备的上下文。示例会话文件在仓库的 `examples/sessions/` 目录下。

其他自我改进的记忆模式： @RLanceMartin 提过一个法子，就是复盘会话日志来提炼用户偏好——说白了就是建个“日记本”，记下哪些管用、哪些不行。每次会话结束后，一个复盘智能体会提取出哪些地方做得好、哪些搞砸了、你做了哪些修正。这些经验会更新到一个记忆文件里，在后续会话中自动加载。

@alexhillman 的另一个思路是让系统主动出击，每 15 分钟就给你提优化建议，而不是干等着你自己发现规律。智能体会回顾最近的互动，提议更新记忆内容，由你拍板通过或拒绝。时间长了，它就能从你的批准习惯里学到东西。

Token Optimization Token 优化技巧

我收到好多来自价格敏感型用户的问题，或者那些作为深度用户老碰到使用限制的朋友。说到优化 Token 消耗，这儿有几招你可以试试。

核心策略：子代理架构

主要思路是优化你使用的工具，并设计一套子代理架构，目的是把任务派给能满足要求、且成本最低的模型，避免浪费。这里你有几个选择——你可以先摸着石头过河，边试边调整。等你摸清门道了，就能知道哪些活儿可以派给 Haiku，哪些适合 Sonnet，哪些又该交给 Opus 来处理。

基准测试法（更费事一点）：

另一个稍微复杂点的方法是，你可以让 Claude 帮你搭建一个基准测试环境。具体来说，你需要一个目标明确、任务清晰、计划周全的代码仓库。然后在每个 git worktree 里，让所有子代理都使用同一种模型。任务完成时做好记录——最好在你的计划和任务列表里都记上一笔。关键是，每个子代理你至少都得用上一次。

当你完成一轮完整检查，并且 Claude 计划里的任务都打上勾之后，先停一下，好好复盘一下进度。你可以对比代码差异，给所有工作树创建统一的单元测试、集成测试和 E2E 测试。这样你就能得到一个量化的基准——通过多少用例，失败多少用例，一目了然。如果所有测试都一帆风顺，那你就得再加点刁钻的边界用例，或者把测试复杂度往上提一提。不过这事儿值不值得投入，全看这对你来说到底有多重要。

模型选择速查指南：

针对各种常见任务的子代理假设配置及选择理由

日常写代码，90%的活儿用 Sonnet 就够啦。遇到第一次没搞定、任务涉及 5 个以上文件、要做架构决策或者处理安全关键代码时，再升级到 Opus。要是任务比较重复、指令特别明确，或者在多智能体协作里当个“打工人”，那就降级用 Haiku 呗。说实话，Sonnet 4.5 现在这定价有点不上不下的——输入每百万 token 3 美元，输出每百万 token 15 美元，比 Opus 省了大概 66.7%。单看数字是挺划算，但对大多数人来说，这点差价其实不痛不痒。最实在的搭配还是 Haiku 和 Opus 组合，毕竟 Haiku 和 Opus 之间有 5 倍价差，跟 Sonnet 那 1.67 倍的差价比起来可香多了。

在你的智能体定义里，记得指定 model 哦！

---
name: quick-search
description: Fast file search
tools: Glob, Grep
model: haiku # Cheap and fast
---

针对特定工具的优化：

琢磨一下 Claude 最常调用的那些工具。举个例子，把 grep 换成 mgrep —— 在各种任务上，它平均能有效减少大约一半的 token 消耗，而 Claude 默认用的可是传统的 grep 或 ripgrep。

后台进程：

如果不需要 Claude 实时处理整个输出流，那就尽量把后台进程挪到 Claude 外面跑。用 tmux 就能轻松搞定（具体操作可以看速查指南和 Tmux 命令参考直链）。拿到终端输出后，要么总结要点，要么只复制你需要的那部分。这样能省下大量输入 token——要知道成本大头全在这儿呢：Opus 4.5 每百万输入 token 收费 5 美元，输出 token 可是每百万要 25 美元！

模块化代码库的好处：

构建一个模块化更强的代码库，包含可复用的工具、函数、hooks 等等——让主文件保持在几百行而不是几千行——这既能帮你省下不少 token 开销，又能让你一次就把活儿干对，这两件事其实是相辅相成的。如果你得反复提示 Claude，那简直就是在烧 token，尤其是当它一遍遍啃那些超长文件的时候。你会发现它得调用一大堆工具才能读完整个文件。过程中，它还会提醒你文件太长了，得继续读。就在这个当口，Claude 可能会漏掉一些信息。而且，停下来重读还得额外花 token。这些都可以通过打造一个更模块化的代码库来避免。看下面的例子就明白了——>

root/
├── docs/                   # Global documentation
├── scripts/                # CI/CD and build scripts
├── src/
│   ├── apps/               # Entry points (API, CLI, Workers)
│   │   ├── api-gateway/    # Routes requests to modules
│   │   └── cron-jobs/      
│   │
│   ├── modules/            # The core of the system
│   │   ├── ordering/       # Self-contained "Ordering" module
│   │   │   ├── api/        # Public interface for other modules
│   │   │   ├── domain/     # Business logic & Entities (Pure)
│   │   │   ├── infrastructure/ # DB, External Clients, Repositories
│   │   │   ├── use-cases/  # Application logic (Orchestration)
│   │   │   └── tests/      # Unit and integration tests
│   │   │
│   │   ├── catalog/        # Self-contained "Catalog" module
│   │   │   ├── domain/
│   │   │   └── ...
│   │   │
│   │   └── identity/       # Self-contained "Auth/User" module
│   │       ├── domain/
│   │       └── ...
│   │
│   ├── shared/             # Code used by EVERY module
│   │   ├── kernel/         # Base classes (Entity, ValueObject)
│   │   ├── events/         # Global Event Bus definitions
│   │   └── utils/          # Deeply generic helpers
│   │
│   └── main.ts             # Application bootstrap
├── tests/                  # End-to-End (E2E) global tests
├── package.json
└── README.md

精简代码库 = 更省的 token：

这话可能听着像老生常谈，但你的代码库越精简，消耗的 token 成本就越低。关键在于要善用各种技能来揪出那些“僵尸代码”，通过重构技能和命令持续给代码库“瘦身”。我时不时还会把整个代码库快速过一遍，专门找那些特别扎眼或者看起来重复的地方，手动把这些上下文拼凑起来，然后连同重构技能和僵尸代码检测技能一起喂给 Claude。

系统提示词精简（进阶玩法）：

给那些真正精打细算的朋友提个醒：Claude Code 的系统提示词大概要占 18k 个 token（约占 200k 上下文的 9%）。通过打补丁的方式，这个数字可以压缩到 10k token 左右，能省下大约 7,300 个 token（相当于砍掉了 41% 的固定开销）。如果你想走这条路，可以参考 YK 的 system-prompt-patches，不过我个人没这么干。

Verification Loops and Evals 验证循环与评估

评估和调优这事儿，得看具体项目来定，但总归得搞点可观测性和标准化手段。

可观测性方法：一个法子是挂上 tmux 进程，让它实时追踪思维流，技能一触发就记录输出。还有个招是用 PostToolUse 钩子，专门记录 Claude 具体执行了啥操作、产生了哪些确切变更和输出。

基准测试工作流：你可以对比一下，在不使用这个技能的情况下提出同样的要求，然后检查输出的差异，这样就能直观地衡量出性能的相对提升了。

[Same Task]
                         │
            ┌────────────┴────────────┐
            ▼                         ▼
    ┌───────────────┐         ┌───────────────┐
    │  Worktree A   │         │  Worktree B   │
    │  WITH skill   │         │ WITHOUT skill │
    └───────┬───────┘         └───────┬───────┘
            │                         │
            ▼                         ▼
       [Output A]                [Output B]
            │                         │
            └──────────┬──────────────┘
                       ▼

[git diff]

│ ▼ ┌────────────────┐ │ Compare logs, │ │ token usage, │ │ output quality │ └────────────────┘

具体操作就是：复制一份对话，在其中一份里新建一个不包含该技能的工作树，最后拉出差异对比，看看日志里都记了些什么。这正好和“持续学习与记忆”那部分内容衔接上了。

评估模式类型：

更高级的评估和循环协议就体现在这儿了。主要分两种路子：一种是基于检查点的评估，另一种是基于强化学习任务的持续评估。

CHECKPOINT-BASED                         CONTINUOUS
─────────────────                        ──────────

  [Task 1]                                 [Work]
     │                                        │
     ▼                                        ▼
  ┌─────────┐                            ┌─────────┐
  │Checkpoint│◄── verify                 │ Timer/  │
  │   #1    │    criteria                │ Change  │
  └────┬────┘                            └────┬────┘
       │ pass?                                │
   ┌───┴───┐                                  ▼
   │       │                            ┌──────────┐
  yes     no ──► fix ──┐                │Run Tests │
   │              │    │                │  + Lint  │
   ▼              └────┘                └────┬─────┘
  [Task 2]                                   │
     │                                  ┌────┴────┐
     ▼                                  │         │
  ┌─────────┐                          pass     fail
  │Checkpoint│                          │         │
  │   #2    │                           ▼         ▼
  └────┬────┘                        [Continue] [Stop & Fix]
       │                                          │
      ...                                    └────┘

Best for: Linear workflows              Best for: Long sessions
with clear milestones                   exploratory refactoring

基于检查点的评估：

在你的工作流里，明确设置几个检查点。
在每个关键节点，都要对照预设的标准来检查。
要是检查没通过，Claude 必须得先搞定问题才能继续。
对于那种里程碑明确、流程线性的工作，这套方法特别管用。
每隔 N 分钟或重大改动后自动跑一遍
完整测试套件、构建状态、代码检查，一个不落
一有性能回退立马报告
先停下来修好，再继续推进
适合长时间工作会话

关键得看你手头活儿是什么性质。那种分阶段、目标明确的功能开发，用基于检查点的方式就挺好。但如果是探索性的重构或者维护工作，没啥明确的里程碑，那持续模式就更合适。

要我说，只要稍加干预，这套验证机制就足以规避大部分技术债了。让 Claude 在完成任务后，通过运行技能和 PostToolUse 钩子来自我验证，这招就很有帮助。再加上持续更新的 codemap，它能把所有变更和 codemap 的演变过程都记录下来，相当于在代码仓库之外又多了一个可靠的“事实依据”。只要规则定得严格，Claude 就不会到处乱建 .md 文件把项目搞得一团糟，也能避免为相似代码创建重复文件，更不会留下一堆没人管的“僵尸代码”。

基于代码的评分器：字符串匹配、二元测试、静态分析、结果验证。速度快、成本低、客观性强，但面对合理的代码变体时比较脆弱，容易出错。

基于模型的评分器：按评分标准打分、自然语言断言、成对比较。灵活性强，能处理细微差别，但结果不够确定，而且成本更高。

人工评分器：专家评审、众包判断、抽样抽查。质量堪称黄金标准，但成本高、速度慢。

pass@k: At least ONE of k attempts succeeds
        ┌─────────────────────────────────────┐
        │  k=1: 70%  k=3: 91%  k=5: 97%      │
        │  Higher k = higher odds of success  │
        └─────────────────────────────────────┘

pass^k: ALL k attempts must succeed
        ┌─────────────────────────────────────┐
        │  k=1: 70%  k=3: 34%  k=5: 17%      │
        │  Higher k = harder (consistency)    │
        └─────────────────────────────────────┘

当你只求能用、随便给点反馈就够的时候，就用 pass@k。要是结果必须稳如老狗，对输出的一致性（比如质量、风格这些）要求近乎苛刻，那就得祭出 pass^k 了。

制定评估路线图（同样来自 Anthropic 的指南）：

趁早开始——从真实失败案例中提炼的 20 到 50 个简单任务
把用户报的 bug 直接变成测试用例，这招太实用了！
任务描述得明明白白，让两个专家来评，结论都得一模一样才行。
设计测试集要讲究平衡，该出效果和不该出效果的情况，咱都得测到。
搭建的测试框架必须够稳，每次跑用例都得从干净的环境重新开始
看结果，别管过程
多跑几轮，看看日志
盯紧饱和点——要是通过率 100%，赶紧加测试

Parallelization 并行化搞起来

在多终端 Claude 环境下进行对话分支时，一定要把分支会话和原始会话的任务范围划分清楚。尽量让代码修改的部分别撞车，选那些互不干扰的活儿来干，这样才不容易互相添乱。

我个人的惯用套路：

我自己呢，喜欢让主聊天窗口专心处理代码改动，而开的分支会话就用来解决我对代码库及其当前状态的疑问，或者去搞点外部调研——比如拉取文档、上 GitHub 搜搜有没有能帮上忙的开源项目，总之就是做些对任务有帮助的通用调研。

关于终端数量这事儿：

Boris @bcherny（那位开发了 claude code 的大神）提了一些关于并行处理的建议，我有些赞同，也有些不同看法。他建议过类似在本地跑 5 个 Claude 实例、再开 5 个上游实例这样的操作。但我得劝大家别这么随意地设定终端数量。开一个新终端、新增一个实例，都得是真正有必要、有明确目的才去做。能用脚本搞定的事，就别折腾实例；如果能留在主聊天界面，让 Claude 在 tmux 里启动实例、再流转到独立终端显示，那就用这个方式。

咱们的核心目标应该是：用最精简的并行方案，搞定最多的事情。

对于大多数新手，我甚至建议先别碰并行处理，等你能熟练运行单个实例、并在其中统筹一切之后再说。这可不是让大家自缚手脚——只是提醒要谨慎。其实大部分时候，连我自己总共也就开 4 个左右的终端。通常只开 2 到 3 个 Claude 实例，就足够处理绝大多数任务了。

关于扩展实例规模：

如果你打算开始扩展你的实例，并且有多个 Claude 实例在处理相互重叠的代码，那你必须得用上 git worktrees，并且为每个实例都规划得明明白白。还有啊，为了避免恢复会话时搞不清哪个 git worktree 是干嘛的（光靠分支名可能不够），记得用 `/rename <名字>` 给你的所有聊天都起个名儿。

并行实例的 Git Worktrees：

# Create worktrees for parallel work
git worktree add ../project-feature-a feature-a
git worktree add ../project-feature-b feature-b
git worktree add ../project-refactor refactor-branch

# Each worktree gets its own Claude instance
cd ../project-feature-a && claude

实例之间没有 git 冲突
每个实例都有干净的工作目录
轻松对比输出结果
能用不同方法对同一任务进行基准测试

瀑布流工作法：

当你同时运行多个 Claude Code 实例时，建议采用“瀑布流”模式来组织它们：

新任务一律在右侧开新标签页处理
从左往右，按时间顺序由旧到新推进
保持方向流程始终一致
需要时随时查看特定任务进度
一次最多专注处理 3 到 4 个任务——贪多嚼不烂，精力消耗的速度会远超效率提升。

Groundwork 打好地基

万事开头难，基础打得牢不牢至关重要。道理大家都懂，但随着代码库越来越复杂、规模越来越大，技术债也会越积越多。管好技术债特别关键，其实只要遵循几条原则，也没那么难。除了要针对手头的项目把 Claude 配置到位（可以参考速成指南）。

双实例启动模式：

在我自己的工作流管理里（虽然不是必须，但确实很有帮助），我喜欢用一个空仓库，同时开两个 Claude 实例来启动。

实例一：脚手架代理

专门负责打好基础和搭好框架
创建项目结构
一键搞定所有配置（CLAUDE.md、规则、智能体——速成指南里的全套东西）
帮你把规矩都立好
把框架给你搭得明明白白

实例二：深度研究智能体

能连上你所有的服务和网页搜索，啥都能查。
给你整出详细的产品需求文档，写得明明白白。
自动生成架构图，用 mermaid 画得清清楚楚。
还能从官方文档里摘出原文片段，把引用整理得妥妥帖帖。

初始设置：左边终端写代码，右边终端提问题——记得用 /rename 和 /fork 命令。

刚开始用最少必要的东西就行——这样比每次都依赖 Context7、喂链接让它爬取或者用 Firecrawl MCP 站点快多了。当你已经深陷某个项目，而 Claude 明显搞错语法或用着过时的函数或接口时，这些方法才派上用场。

llms.txt 的用法：

很多文档页面都支持这个功能，你只要在它们的文档页面上输入 `/llms.txt` 就能找到。举个例子：https://www.helius.dev/docs/llms.txt

这样一来，你就得到了一份干净利落、专门为 LLM 优化过的文档，可以直接喂给 Claude 用。

核心理念：打造可复用的模式

我完全赞同 @omarsar0 的一个深刻见解：“早期，我花时间构建了可复用的工作流/模式。虽然搭建过程很磨人，但随着模型和智能体框架的进步，这事儿产生了惊人的复利效应。”

值得投入的方向：

子代理（速查手册）
技能（速查手册）
命令（速查手册）
规划模式
MCP 工具（速查指南）
上下文工程模式

为啥说它越用越香呢？(@omarsar0 分享心得)：“最棒的一点是，所有这些工作流都能无缝迁移到像 Codex 这样的其他智能体上。”一旦搭建好，它们就能通吃各种模型升级。投资在模式上，可比死磕某个模型的独门技巧要划算多了！

智能体与子智能体的最佳实践

在之前的速查指南里，我列出了子代理的结构——比如 planner、architect、tdd-guide、code-reviewer 等等。这部分咱们重点聊聊编排和执行层。

子代理的上下文难题：

设置子代理的初衷，是为了节省上下文空间——它们只返回摘要，而不是把所有东西都倒出来。但问题是，编排器掌握的语义上下文，子代理根本没有。子代理只知道字面上的查询，却不清楚请求背后的目的和推理逻辑。所以摘要常常会漏掉关键细节。

用 @PerceptualPeak 的比喻来说就是：“你老板派你去开个会，让你回来做个汇报。你回来后把情况大致说了一遍。十有八九，他肯定还会追问一堆问题。你的汇报不可能面面俱到，因为他掌握的那些隐含背景，你根本不知道。”

迭代检索模式：

┌─────────────────┐
│  ORCHESTRATOR   │
│  (has context)  │
└────────┬────────┘
         │ dispatch with query + objective
         ▼
┌─────────────────┐
│   SUB-AGENT     │
│ (lacks context) │
└────────┬────────┘
         │ returns summary
         ▼
┌─────────────────┐      ┌─────────────┐
│   EVALUATE      │─no──►│  FOLLOW-UP  │
│   Sufficient?   │      │  QUESTIONS  │
└────────┬────────┘      └──────┬──────┘
         │ yes                  │
         ▼                      │ sub-agent
    [ACCEPT]              fetches answers
                                │
         ◄──────────────────────┘
              (max 3 cycles)

要解决这个问题，得让 orchestrator 这么做：

评估每一个子代理返回的结果
接受之前，先追问几个问题。
子代理会返回源头，获取答案，再回来。
循环直到足够（最多 3 轮，防止无限循环）。

传递目标上下文，而不仅仅是查询。派发子代理时，既要包含具体查询，也要包含更广泛的目标。这有助于子代理在总结时确定优先级。

模式：分阶段串联的 Orchestrator

Phase 1: RESEARCH (use Explore agent)

- Gather context
- Identify patterns
- Output: research-summary.md

Phase 2: PLAN (use planner agent)

- Read research-summary.md
- Create implementation plan
- Output: plan.md

Phase 3: IMPLEMENT (use tdd-guide agent)

- Read plan.md
- Write tests first
- Implement code
- Output: code changes

Phase 4: REVIEW (use code-reviewer agent)

- Review all changes
- Output: review-comments.md

Phase 5: VERIFY (use build-error-resolver if needed)

- Run tests
- Fix issues
- Output: done or loop back

每个 Agent 只接收一个明确的输入，并生成一个明确的输出
每个阶段的输出，就是下一阶段的输入
千万别跳过任何阶段——每一步都有它的价值。
在不同智能体之间用 `/clear` 命令来保持上下文清爽。
记得把中间输出存到文件里，别光靠内存记。

智能体抽象层级排行（来自 @menhguin）：

第一梯队：直接增益（上手简单）

子代理 – 防止上下文腐化和临时特化的直接增益。效果是多代理的一半，但复杂度低得多。
元提示 – “我花 3 分钟写提示，搞定 20 分钟的任务。” 直接增益 – 提升稳定性，还能帮你检查假设是否靠谱。
一开始多问用户几个问题 – 通常是个增益，不过你得在计划模式下回答这些问题。

第二档：上手门槛高（想用好不容易）

长期运行的 agents —— 你得摸清门道，知道 15 分钟、1.5 小时和 4 小时的任务各自是什么路数、怎么权衡。这得花功夫调试，说白了就是个漫长的试错过程。
并行多 agent —— 效果波动太大了，只适合那些特别复杂或者能清晰拆分的任务。就像有人说的：“如果两个任务本来 10 分钟就能搞定，结果你花大把时间写提示词，或者更糟——还得手动合并修改，那纯属费力不讨好。”
基于角色的多 agent —— “模型进化得太快了，除非套利空间特别大，否则写死的启发式规则根本跟不上趟。” 而且这玩意儿还特别难测试。
计算机使用 agents——这还处于非常早期的范式，需要费点功夫调教。”你这是在让模型干一年前它们压根儿没被设计来做的事儿呢！”

核心建议：先从 Tier 1 模式入手。只有当你基础扎实了，并且确实有需要的时候，再考虑进阶到 Tier 2。

Tips and Tricks

有些 MCP 是可以替换掉的，能帮你腾出不少上下文窗口空间

就拿版本控制（GitHub）、数据库（Supabase）、部署（Vercel、Railway）这些场景的 MCP 来说吧——其实这些平台本身都有很强大的 CLI 工具，MCP 说白了就是给它们套了层壳。这层壳用起来是挺顺手，但代价也不小。

想让 CLI 用起来有 MCP 那味儿，又不想真的用 MCP（连带它那会缩水的上下文窗口），有个好办法：把这些功能打包成技能和命令。把 MCP 里那些让你省事的工具抽出来，直接做成命令。

举个例子：别总挂着 GitHub MCP 了，可以自己建个 `/gh-pr` 命令，把 `gh pr create` 和你常用的选项打包进去。也别让 Supabase MCP 在那儿白占上下文，直接写几个调用 Supabase CLI 的技能。功能一点没少，方便程度也差不多，但宝贵的上下文窗口就能腾出来干正事了。

这正好也回应了最近大家问的一些问题。自从我发了那篇文章之后，Boris 和 Claude Code 团队这几天在内存管理和优化上真是下了不少功夫，主要是搞定了 MCP 的懒加载，这下它们再也不会一上来就霸占你的窗口了。要搁以前，我肯定会建议尽量把 MCP 转成技能，用两种方式把功能卸掉：要么临时启用（这法子不太理想，因为你得退出再重进会话），要么用那些调用类似 MCP 的 CLI 命令的技能，让技能给它包一层——说白了就是让它当个“伪 MCP”。

有了懒加载，上下文窗口的问题基本算是解决了。但 token 用量和成本可没这么容易搞定。CLI + 技能这套组合拳，依然是个能优化 token 的招数，效果可能跟直接用 MCP 差不多，甚至更胜一筹。而且，你完全可以通过 CLI 来跑 MCP 的操作，而不是在上下文里搞，这样能大幅减少 token 消耗，对于像数据库查询或者部署这类重度的 MCP 操作尤其管用。