# 7.6 Claude Code 高阶特性与多端生态

Claude Code 诞生之初就被定义为一个可以无处不在的 AI 智能助理。它不仅局限于开发者的终端 CLI 和 IDE，还能扩展到完整的开发工作流与跨平台的交互中。

## 7.6.1 多端无缝衔接

Claude Code 的能力不仅存在于本地 CLI 中，通过同一底层引擎的互联，可以实现多种场景的无缝切换。

### IDE 深度集成

原生的 Claude Code 扩展支持主流 IDE 和编辑器：

| 编辑器           | 集成方式 | 核心功能                           |
| ------------- | ---- | ------------------------------ |
| **VS Code**   | 官方扩展 | 内联 Diff、终端集成、代码操作              |
| **Cursor**    | 原生支持 | Composer、自动索引、Tab 补全           |
| **Windsurf**  | 原生支持 | Cascade 工作流、多文件编辑              |
| **JetBrains** | 官方插件 | IntelliJ、PyCharm、WebStorm 等全系列 |

在 IDE 中，Claude Code 可以直接读取项目上下文、展示内联的差异比对（Inline Diff），并在编辑器内完成代码修改与审查，无需切换到终端。

### Desktop 与 Web 协同

通过 **Desktop App**（桌面版应用），可以在可视化界面中管理多条并行任务工作流：

* **多任务视图**：同时观察多个任务的进度和 Diff
* **后台执行**：长耗时任务（如大规模重构）可在后台持续运行
* **实时日志**：查看每个子任务的输出和状态

通过 **Web 版**（`claude.ai/code`）或 **iOS App**，即使不在开发环境旁，也可以远程下发任务：

```
# 在手机上发起任务
"请审查 main 分支最近 3 天的所有 commit，检查是否有安全隐患，生成报告到 reviews/ 目录。"
```

任务会在云端的沙箱环境中执行，完成后通过通知推送结果。

### Slack 集成

将 Claude Code 集成到 Slack 后，团队协作效率大幅提升。典型工作流如下：

```mermaid
sequenceDiagram
    participant Dev as 开发者
    participant Slack as Slack 频道
    participant CC as Claude Code
    participant GH as GitHub

    Dev->>Slack: @Claude 这个报错帮忙看看<br>附带错误截图
    Slack->>CC: 接收任务
    CC->>CC: 提取报错信息<br>分析代码库
    CC->>GH: 创建修复 PR
    CC->>Slack: "已创建 PR #42，修复了空指针异常"
    Dev->>GH: 审查并合并
```

这种模式特别适合非紧急的 Bug 修复和日常维护任务，极大地压缩了从“发现问题”到“提交修复”的周期。

## 7.6.2 跨端继续当前会话

Claude Code 的多端协同需要区分“已经公开发布的能力”和“设想中的能力”。官方文档已经明确公开的能力主要有：

* **`/desktop`**：将当前会话继续到 Claude Code Desktop App。该命令只在 macOS 和 Windows 上可见。
* **`/remote-control`**：让当前 CLI 会话可从 `claude.ai` 远程接管或继续。
* **`/remote-env`**：配置 Web 端会话启动时使用的默认远程环境。

```bash
> /desktop

# 在桌面应用中继续当前会话

> /remote-control

# 允许从 claude.ai 远程控制当前 CLI 会话
```

当前官方命令包括 `/desktop`、`/remote-control`、`/remote-env`、`/teleport`；可用性依赖平台、计划和环境。写教程时应把这些命令和内部实验特性分开，不要混成同一组“未公开功能”。

## 7.6.3 高效工作流实践

Claude Code 的深度用户在实践中总结出了一套显著提升效率的工作方法论，核心理念是 **“80% 规划 + 20% 执行”**——与传统开发中 80% 写代码、20% 做计划的比例恰好相反。

### plan.md 驱动开发

这套方法的核心是 **plan.md 文件**。每当有新想法、新 Bug 或新需求时，第一步不是写代码，而是生成一份结构化的计划文件。计划文件包含问题描述、方案选择、需修改的文件列表和带复选框的验收标准。

计划文件的真正价值在于它是 **跨会话的持久化检查点**。当上下文丢失（窗口关闭、上下文膨胀等）时，只需开一个新会话，指向已有的 plan.md，即可从断点继续。计划就是能扛过一切的检查点。

社区中流行的 Compound Engineering 插件提供了 `/ce:plan` 和 `/ce:work` 命令来实现这一工作流：`/ce:plan` 并行启动多个 research agent（一个分析代码库、一个搜索历史经验、一个调研外部最佳实践），汇总后写出结构化计划；`/ce:work` 接过计划并逐步实现，运行测试，勾选验收标准。

### 并行会话

高效用户通常同时运行 **4-6 个 Claude Code 会话**，每个会话处理不同任务——一个在写计划、一个在执行另一个计划、一个在做技术调研、一个在修 Bug。这要求 Claude Code 能自主运行而不频繁请求权限确认，否则无法在多个窗口间来回切换。

### 语音驱动开发

语音转 LLM 与传统语音输入有本质区别：转录不需要完美，因为 Claude Code 理解上下文，能猜出麦克风听错了什么。可以含糊不清、话说到一半、重新组织句子。Monologue 和 WhisperFlow 等工具可以将语音直接输入到当前聚焦的应用中，配合编辑器的自动保存功能，实现类 Google Docs 的实时协作体验——说话即编程。

### 关键配置

三个显著提升体验的配置：

**1. 受控权限配置**（`~/.claude/settings.json`）：

```json
{
  "permissions": {
    "allow": ["Read", "Write", "Edit", "Glob", "Grep", "Bash(git status:*)", "Bash(npm test:*)"],
    "deny": ["Read(.env*)", "Read(**/secrets/**)", "Bash(rm -rf:*)"],
    "defaultMode": "acceptEdits",
    "disableBypassPermissionsMode": "disable"
  },
  "cleanupPeriodDays": 30
}
```

`bypassPermissions` / `--dangerously-skip-permissions` 只适合一次性容器、临时 VM 或其他强隔离沙箱；普通工作机应优先使用任务级 allow/deny 规则，并保留危险操作的人类确认门槛。

**2. 任务完成提示音**（Stop hooks）：

```json
{
  "hooks": {
    "Stop": [
      {
        "matcher": "",
        "hooks": [
          {
            "type": "command",
            "command": "afplay /System/Library/Sounds/Blow.aiff"
          }
        ]
      }
    ]
  }
}
```

同时跑多个会话时，听到声音就知道哪个完成了。

**3. 编辑器自动保存**（如 Zed 的 500ms 间隔配置，详见 7.4.3 节）。

**4. 自定义 Auto 模式分类器**（`autoMode`）：

Auto 模式（见 7.6.11）由一个分类器判断哪些操作可以免确认自动执行。`settings.json` 里的 `autoMode` 字段可定制它的判断依据：

```json
{
  "autoMode": {
    "allow": ["Bash(npm test)", "Bash(npm run *)", "Read", "Grep"],
    "soft_deny": ["Bash(git push *)", "Bash(rm *)", "Write(.env*)"],
    "environment": [
      "这是本地开发机，没有生产数据库访问权限",
      "测试套件可反复安全运行，用的是独立测试库"
    ]
  }
}
```

`allow` / `soft_deny`（以及 `hard_deny`）是权限规则；真正特别的是 **`environment`**——它不是规则，而是一组**自然语言**的环境描述，分类器会读取它来对模棱两可的命令做更贴合你环境的安全判断。描述越具体（“无生产访问”“测试库隔离”），它越敢在安全范围内自动放行。详见 [官方 Settings 参考](https://code.claude.com/docs/en/settings)。

### 非代码场景

这套工作流不限于编程。例如，开着会议录音工具（如 Granola），会后把完整的九十分钟会议记录（包括闲聊）粘贴到 Claude Code 中生成产品提案——Claude 会自动忽略关于餐厅的聊天，只提取产品相关的讨论，并交叉参照代码库和历史战略文档。战略文档、竞品分析、文章写作都可以用同样的“说、计划、迭代”循环。

对于需要随时远程操作的场景，可以在 Mac Mini 上部署 Claude Code，通过 Telegram 从手机发送任务指令；或者在飞机上通过 tmux 连接远程机器，即使 WiFi 中断 20 分钟，重连后会话依然在原处继续。

## 7.6.4 多智能体协作

当工程任务庞大时，Claude Code 的核心能力是把问题拆成多个角色清晰的子任务，而不是依赖某个神秘的“一键多代理”命令。

### Sub-Agents 并行执行

Claude Code 的 **Sub-Agents（子代理）** 更接近“独立上下文窗口下的分工协作”：

```
Lead Agent
├── Reviewer: 审查回归风险与缺失测试
├── Implementer: 负责局部代码修改
└── Writer: 更新迁移说明或文档
```

这里要注意：**默认是上下文隔离，不是仓库隔离**。如果你需要真正的文件级或工作树级隔离，应显式启用对应策略，而不是默认假设“每个子代理天然在独立分支里工作”。

### 自定义 Agents 的正确入口

当前官方入口是：

* 用 **`/agents`** 查看和管理 agent 配置
* 在项目内通过 `.claude/agents/` 维护专用 agent 角色

如果你需要 DAG、依赖关系、重试策略、统一观测面板这类更复杂的编排，那通常应该在你自己的应用层完成，而不是伪造一个并不存在的 `/execute-agents --agents-config ...` 或 `/run-team ...` 命令。

### Agent SDK 的边界

这里还要和官方 SDK 边界分清楚。当前 Anthropic 公开的 Python Agent SDK / Claude Code SDK 入口是 `claude_agent_sdk`，而不是 `from anthropic.agent import Agent` 这一套接口。像 `Agent()`、`AgentTeam`、`run_parallel()` 这样的写法，如果被写成“可直接运行的官方 API”，会误导读者复制后立刻报错。

## 7.6.5 Hooks 系统深度指南

Claude Code Hooks 采用的是**事件驱动配置**，不是上一版书稿里那种 `command_hooks / prompt_hooks / agent_hooks` 的自定义 schema。当前官方文档的核心模式是：

1. 先按事件名分组
2. 再用 `matcher` 匹配工具或场景
3. 最后在 `hooks` 数组里配置处理器

常见事件包括：

* `SessionStart`
* `UserPromptSubmit`
* `PreToolUse`
* `PostToolUse`
* `Notification`
* `Stop`
* `SubagentStop`

下面这个示例更接近官方 hooks reference 的真实形态：

```json
{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "\"$CLAUDE_PROJECT_DIR\"/.claude/hooks/check-safe-bash.sh"
          }
        ]
      }
    ],
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "\"$CLAUDE_PROJECT_DIR\"/.claude/hooks/run-tests-async.sh",
            "async": true,
            "timeout": 300
          }
        ]
      }
    ]
  }
}
```

这套结构的几个重点是：

* **事件先行**：例如 `PreToolUse` / `PostToolUse`
* **`matcher` 精准匹配**：决定命中哪些工具
* **`hooks` 数组**：每个事件可挂多个处理器
* **异步限制**：`async: true` 只适用于 `type: "command"` 的 hook

### 一个现实的 Hooks 场景

如果希望 Claude 在写完文件后异步跑测试，而不是阻塞当前会话，可以这样理解：

```bash
# .claude/hooks/run-tests-async.sh
npm test -- --runInBand
```

```json
{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "\"$CLAUDE_PROJECT_DIR\"/.claude/hooks/run-tests-async.sh",
            "async": true,
            "timeout": 300
          }
        ]
      }
    ]
  }
}
```

### Hook 的返回值：用 JSON 反向影响 Claude

Hook 不只有“退出码 2 拦截”这一种反馈方式。除了退出码，hook 还能在 stdout 上打印一段 JSON，**反向修改 Claude Code 的后续行为**——改写工具入参、不弹窗直接放行或拦截、向上下文注入内容。这是 hooks 从“被动审查”升级为“可编程中间件”的关键能力。

这里有一个**最容易踩的坑**：事件相关字段必须包在 `hookSpecificOutput` 对象里，并带上 `hookEventName`。网上不少博客把 `permissionDecision`、`updatedInput` 直接写在 JSON 顶层——那种写法会被**静默忽略**，hook 看起来“跑了但没生效”。正确形态是：

```json
{
  "hookSpecificOutput": {
    "hookEventName": "PreToolUse",
    "permissionDecision": "allow",
    "permissionDecisionReason": "只读命令，自动放行"
  }
}
```

不同事件可返回的核心字段（详见 [官方 Hooks 参考](https://code.claude.com/docs/en/hooks)）：

| 事件             | 字段                                         | 作用                     |
| -------------- | ------------------------------------------ | ---------------------- |
| `PreToolUse`   | `permissionDecision`（`allow`/`deny`/`ask`） | 不弹窗直接放行、拒绝或追问          |
| `PreToolUse`   | `permissionDecisionReason`                 | 决策理由，显示在 UI            |
| `PreToolUse`   | `updatedInput`                             | 执行前改写工具入参              |
| `SessionStart` | `additionalContext`                        | 向会话注入上下文               |
| `SessionStart` | `watchPaths`                               | 设置文件监听，变更时触发事件         |
| `SessionStart` | `initialUserMessage`                       | 预置到首条用户消息之前            |
| `PostToolUse`  | `updatedMCPToolOutput`                     | 改写 Claude 看到的 MCP 工具返回 |

举例，一个把只读 Bash 命令自动放行、其余交回正常权限流的 `PreToolUse` hook（注意 JSON 必须带 `hookSpecificOutput` 外层）：

```bash
#!/bin/bash
CMD=$(jq -r '.tool_input.command' < /dev/stdin)
if echo "$CMD" | grep -qE '^(ls|cat|pwd|git status|git log|git diff)'; then
  jq -n '{hookSpecificOutput: {hookEventName: "PreToolUse", permissionDecision: "allow", permissionDecisionReason: "只读命令"}}'
fi
```

或在执行前给 `git push` 悄悄加上 `--dry-run`（用 `updatedInput` 改写入参）：

```bash
#!/bin/bash
CMD=$(jq -r '.tool_input.command' < /dev/stdin)
if echo "$CMD" | grep -q 'git push'; then
  jq -n --arg c "$CMD --dry-run" \
    '{hookSpecificOutput: {hookEventName: "PreToolUse", updatedInput: {command: $c}}}'
fi
```

除了前面提过的 `async` 与 `timeout`，命令型 hook 还有两个进阶配置字段：

* **`asyncRewake: true`**：后台异步执行，正常路径不阻塞；一旦以退出码 2 结束，则唤醒模型并拦截该操作。即“顺利时不挡路、出问题时才拦”的安全网模式。
* **`shell`**：指定执行所用 shell（`bash` 或 `powershell`）。

（`once: true`“本会话只跑一次”目前适用于 skill / agent 作用域的 hook，配置在 SKILL.md 或 agent frontmatter 的 `hooks` 字段里，参见 6.4 节。）

### 调试 Hooks

如果 hooks 没有按预期触发，可以：

* 运行 `claude --debug`
* 使用 `/hooks` 查看当前配置
* 检查 `matcher` 是否命中目标工具

## 7.6.6 Memory 与长会话治理

Claude Code 的长会话治理更适合围绕两个官方入口理解：

* **`CLAUDE.md` / `/memory`**：管理项目或用户级长期记忆
* **`/compact`**：压缩当前会话上下文，降低上下文膨胀

```bash
> /memory

# 查看或编辑当前项目的记忆文件

> /compact

# 压缩当前会话上下文
```

这里同样要避免把并不存在的 `/settings memory.strategy ...` 或一串未公开的 `/compact --strategy ...` 选项写成既成事实。长期记忆和压缩能力应该以当前官方 Memory / Commands 文档为准。

### 长会话治理的实战原则

1. 把稳定规则写进 `CLAUDE.md`，不要每轮重复塞进 prompt。
2. 对临时调试日志、长错误栈、重复 diff 及时做 `/compact`。
3. 团队协作时，把共享约束写进仓库内的记忆文件，而不是只留在个人会话里。

### Memory 系统的容量阈值

Claude Code 的 **auto memory**（自动记忆）把 Claude 自己记录的经验写入 `~/.claude/projects/<项目>/memory/`，入口是 `MEMORY.md`，细节拆到 `debugging.md`、`patterns.md` 等主题文件；`/memory` 命令用于浏览、编辑这些文件并开关 auto memory。

这里有一个关键阈值（已写入[官方 Memory 文档](https://code.claude.com/docs/en/memory)）：每次会话开始时，只加载 `MEMORY.md` 的**前 200 行或前 25 KB**（以先到为准）。

要点是它是\*\*“加载”阈值，而非“截断删除”\*\*：超出部分不会被删除，也不会“静默覆盖”早期内容，只是不在会话启动时自动进上下文——文件仍完整留在磁盘上。Claude 的正确用法是把 `MEMORY.md` 当成一份精炼索引来维护，把细节挪进主题文件，需要时再按需读取。由此：

1. `MEMORY.md` 要保持精简、像目录索引；长内容拆进主题文件，而不是堆在一起指望系统自动清理
2. 必须每轮都在场的长期规则写进 `CLAUDE.md`——它整文件加载，不受 200 行 / 25 KB 限制
3. 该阈值只作用于 `MEMORY.md`；主题文件本就不在启动时加载，由 Claude 按需读取

### 环境变量与调试模式

介绍几个有用但文档较少的环境变量：

| 环境变量                             | 作用                        |
| -------------------------------- | ------------------------- |
| `CLAUDE_CODE_MAX_RETRIES`        | 设置 API 调用最大重试次数（默认 10）    |
| `CLAUDE_CODE_DISABLE_CLAUDE_MDS` | 禁用所有 CLAUDE.md 文件的加载（调试用） |

`--bare` 模式是另一个调试利器——它跳过所有 CLAUDE.md 和 Memory 的加载，让 Claude Code 以“裸机”状态运行，适合排查配置冲突问题。

## 7.6.7 Agent Loop 内部机制

> **来源说明**：本节内容基于社区对 Claude Code 源代码的逆向分析（HitCC 项目，CC BY 4.0），旨在帮助用户理解异常行为的成因。具体实现细节可能随版本更新而变化。

理解 Claude Code 的 Agent Loop 内部工作方式，有助于排查异常行为和优化使用体验。

### 自动压缩（Compaction）机制

很多用户以为上下文压缩只能通过 `/compact` 手动触发（参见 7.6.6 节），但实际上 Claude Code 还内置了**自动压缩**机制：

* 当 token 限制被触及时，系统会**自动触发**压缩
* 支持多种压缩策略：增量压缩、选择性丢弃、全局摘要等
* 内置保护机制防止压缩操作本身失控（例如反复触发压缩-恢复循环）

这意味着即使你从不手动执行 `/compact`，长会话也不会因为上下文溢出而直接崩溃——系统会尝试自动恢复。

### 错误重试与故障回退

模型响应通过流式传输逐步返回。当流式传输出现异常时，系统会自动切换到同步回退模式并重试。最大重试次数可通过 `CLAUDE_CODE_MAX_RETRIES` 环境变量配置（默认 10 次）。

常见的错误恢复策略包括：

| 错误场景  | 用户可观察到的行为     |
| ----- | ------------- |
| 认证过期  | 自动重新认证或提示重新登录 |
| 速率限制  | 自动退避等待后重试     |
| 上下文超长 | 自动触发压缩后重试     |

### 会话持久化

Claude Code 的会话记录不是简单的聊天历史，而是带有上下文元数据的**事件日志**。每条记录不仅包含消息内容，还携带工具调用元数据和状态变更信息。这也是 `--resume` 能够还原完整工作场景（而非仅恢复对话文本）的技术基础。

空会话不会创建持久化文件（惰性写入），只有产生真实数据后才写入磁盘。

## 7.6.8 上下文与记忆的工程最佳实践

Claude Code 的记忆层级设计遵循“分层防御”原则——每一层都被设计来防止更昂贵的下一层被触发，形成一个渐进式、成本优化的系统。Claude Code 采用的 7 层递进式记忆架构的详细说明，参见第 8 章 8.3.4 节。

**工程细节**：

* **GrowthBook 远程功能标志**：运行时控制任何子系统，无需部署即可回滚
* **锁文件互斥**：PID+时间戳，陈旧检测，崩溃恢复
* **3-失败断路器**：重复失败自动熔断，带状态重置机制
* **MEMORY.md 索引限制**：最多 200 行或 25KB，单条条目约 150 字节

最佳实践：

1. 频繁、短期的工作流依赖内存分层的第 1-2 层（工具结果存储 + 微压缩），成本极低
2. 长运行会话在自动摘要注入时立即进行手动 `/compact`，避免进入完整压缩阶段
3. 项目级规则永远写入 `CLAUDE.md`，而非依赖 Memory 文件（容量有限）
4. 关键的临时记忆在会话结束时显式标记用于持久化提取

## 7.6.9 沙箱化与安全隔离

随着 Claude Code 的能力提升，对安全性的关注也随之增加。Anthropic 在 2025 年 10 月推出了 Claude Code 的沙箱化特性，让 Agent 能够在隔离的执行环境中安全地运行代码。

**沙箱化的核心价值**

在没有沙箱之前，Claude Code 采用基于权限的模型：默认为只读，任何修改或执行操作都需要用户确认。虽然安全，但反复的确认会导致“审批疲劳”，用户可能不再仔细检查每个权限请求。

沙箱化解决了这个问题的根本：通过在操作系统级别强制执行边界，Claude Code 可以在无需权限提示的情况下更自主地工作。

**两个沙箱维度**

Anthropic 的沙箱采用了两个正交的维度来确保安全性：

1. **文件系统隔离**

限制 Claude Code 能访问和修改的目录范围：

* Claude Code 可以读写当前工作目录及其子目录
* Claude Code 无法修改系统文件或工作目录外的文件
* 防止的威胁场景：即使被提示注入攻击破坏，Claude Code 也无法修改 SSH 密钥、系统配置等敏感文件

2. **网络隔离**

限制 Claude Code 的外向网络连接：

* 所有网络通信都必须通过代理服务器
* 代理服务器维护了“允许列表”，只允许连接到特定的域名/主机
* 任何尝试连接到未审批的地址，用户都会收到通知并能够授权或拒绝
* 防止的威胁场景：被破坏的 Claude Code 无法泄露本地文件到攻击者的服务器

**技术实现：操作系统级别的强制**

关键点是：沙箱不是由 Claude Code 应用层实现的，而是由操作系统原语强制的。

* **Linux 系统**：使用 `bubblewrap`（Flatpak 项目的沙箱化工具）
* **macOS 系统**：使用 `seatbelt`（Apple 的强制访问控制框架）

这意味着即使 Claude Code 的代码被破坏或被注入恶意指令，OS 内核仍然会强制执行隔离边界。这是一个深度防御策略。

**Claude Code on the Web：云端沙箱**

2025 年底，Anthropic 还发布了“Claude Code on the Web”——在云端浏览器中运行 Claude Code。这种情况下的沙箱化特别重要，因为：

* 每个用户会话在隔离的云端容器中运行
* Claude Code 有完整的文件系统和 bash 访问权限，但仅限于这个容器
* **Git 认证处理特别注意**：Claude Code 永远看不到真实的 Git 凭证

Git 安全设计：

* Claude Code 的所有 Git 命令都经过代理服务
* 代理层验证 git 凭证是否有效，检查命令是否试图推送到错误的分支
* 只有被验证的操作才会使用真实的 GitHub/GitLab 凭证
* 如果 Claude Code 被破坏，也无法接触到实际的 token 或密钥

这确保了即使在云端，用户的开发环境也是安全的。

**启用沙箱化：`/sandbox` 命令**

在 Claude Code 中，可以使用 `/sandbox` 命令来配置沙箱：

```bash
/sandbox

# 这会打开沙箱配置界面，你可以：
# 1. 指定哪些目录 Claude Code 可以访问
# 2. 配置允许的网络目标（默认只允许必要的服务）
# 3. 查看当前的隔离规则
```

**最佳实践**

1. **对生产环境启用沙箱**：任何与生产代码交互的 Claude Code 会话都应该启用沙箱
2. **审慎配置文件系统范围**：给予最小必要的文件访问权限（如只允许项目目录，不允许主目录）
3. **监视网络访问**：定期检查“要求用户审批”的网络请求，了解 Claude Code 在尝试连接哪些地址
4. **结合版本控制**：沙箱化与 Git 的集成使得意外修改很难被推送到远程，提供了额外的安全层

***

*融入自 Anthropic 的《Beyond permission prompts: making Claude Code more secure and autonomous》中关于沙箱化机制的设计与实现*

***

## 7.6.10 综合案例：长时间开发会话的记忆管理

一个典型的多日开发会话中，记忆系统如何协作：

**第 1 天**：多次 Git diff、构建输出填充工具结果。第 1-2 层自动冻结和清理，用户无感知。 **第 2-3 天**：会话达到 80K tokens。用户在第 3 层自动触发时看到摘要注入（\~2-3 条新笔记），成本低。 **第 4 天**：如果仍未 `/compact`，达到 150K tokens。第 4 层开始：draft thinking 生成 9 段摘要（成本 \~1/3 正常调用），旧消息组被替换为摘要。 **任务完成**：第 5 层提取所有“新发现的代码模式”到 MEMORY.md，供后续会话使用。 **一周后**：足够的会话积累触发第 6 层梦想整合，相似的“修复策略”和“代码模式”被自动合并，冗余的会话摘要被清理。

这种设计的妙处在于：用户无需理解分层细节，系统自动选择最便宜的保存方式。同时，如果有任何层失控（如梦想 Agent 陷入循环），锁文件和断路器会在 3 次失败后自动停止。

## 7.6.11 本地自动化原语：`/goal`、`/loop`、`/batch`

在 7.7 节会介绍 Routines（Anthropic 云端定时执行）。在本地，Claude Code 提供另一套自动化原语，它们的共同特点是 **绑定到可验证的退出条件**，让 Claude 自驱动多轮直到目标达成。

### `/goal`：目标驱动的多回合循环

```bash
/goal all tests in test/auth pass and lint step is clean
```

设置 goal 之后，Claude 会跨多个回合持续工作，直到目标条件满足才停下。`/goal` 取消用 `clear`、`stop`、`off`、`reset`、`none` 或 `cancel`；不带参数会展示当前或最近达成的 goal。

设计 goal 时要遵循三个原则：

1. **可验证**：条件必须能由 Claude 自己检查（运行测试、读文件状态、调用工具），不能依赖人类主观判断
2. **确定性**：避免"代码看起来更好"这类模糊语言，改用"测试通过"、"文件存在"、"覆盖率超过 80%"
3. **绑定执行命令或文件状态**：测试命令、lint 命令、grep 结果、HTTP 状态码都是好锚点

实际可用模板：

```bash
/goal all integration tests pass without flaking 3 runs in a row
/goal docker compose up cleanly and healthcheck returns 200
/goal coverage on src/billing/ above 80% and tests not placeholders
/goal no TODO or FIXME comments remain in src/api/
```

### `/loop`：按间隔或自定步调重复运行

`/loop` 是一个 **bundled skill**，行为分两种：

* **定时模式**：`/loop 5m check if the deploy finished`——每 5 分钟跑一次
* **自定步调模式**：`/loop` 不带 interval，Claude 自己决定下次什么时候醒来（用于轮询外部状态）

可以配合 `.claude/loop.md` 写一份默认 loop 提示词，之后裸 `/loop` 即可启动维护循环。`/loop` 别名为 `/proactive`。

### `/batch`：扇出到独立 worktree 并行执行

`/batch` 也是 bundled skill，行为更激进：研究代码库后，把大改动 **拆解成 5-30 个独立单元**，每个单元在自己的 git worktree 里跑一个后台子代理，各自实现、跑测试、开 PR。需要 git 仓库。

```bash
/batch migrate src/ from Solid to React
/batch add OpenTelemetry spans to every handler in services/
```

`/batch` 自动并发的代价是上下文成本——只在确认任务能并行拆解时使用。先用一两个文件验证 prompt，再让 `/batch` 扇出到全量。

### `/branch`：分叉当前对话

```bash
/branch try-redis-instead
```

`/branch` 在当前对话节点 fork 出一条新分支：你切到新分支继续探索，原对话保留，随时 `/resume` 回到原线。别名 `/fork`。适合"我想试一下另一条路径但不想丢掉当前进度"的场景。

> 当环境变量 `CLAUDE_CODE_FORK_SUBAGENT` 被设置时，`/fork` 不再是 `/branch` 的别名，而是分叉子代理。

### 组合：`/goal` + Auto 模式 + Stop hook

三件套合起来就是一个完整的"夜间自动化"工作流：

1. **`/goal <可验证条件>`**——明确退出条件
2. **`/permission-mode auto`**——减少权限询问中断
3. **`Stop` hook**（见 7.6.3）——任务完成时声音/通知

```
> /goal all tests pass and lint is clean
> /permission-mode auto
> <离开半小时>
```

回来时要么看到完成提示音，要么看到具体阻塞原因。

### 几个常被忽视的辅助命令

| 命令                        | 用途                                                                  |
| ------------------------- | ------------------------------------------------------------------- |
| `/insights`               | 分析你的 Claude Code 会话，给出项目领域、交互模式、摩擦点报告。建议每月跑一次                       |
| `/btw <question>`         | 问一个边角问题，不进入对话历史。适合"顺便问一句"场景，避免污染主线                                  |
| `/focus`                  | 切换 focus 视图，只显示最后的 prompt + 一行工具调用摘要 + 最终回复。仅在 fullscreen 渲染下可用     |
| `/rewind`                 | 回滚对话和/或代码到检查点。别名 `/checkpoint`、`/undo`。配合 Esc×2 实现"检查点-试探-回滚"的安全实验流 |
| `/compact [instructions]` | 带提示的有损压缩。例如 `/compact 保留决策、被改文件清单、测试命令；丢弃试错过程`                      |

***

从命令行起步，通过 Hooks、Sub-Agents、Memory 和 `/compact`，Claude Code 已经覆盖了现代智能开发工作流里的大多数高频场景。真正重要的不是记住一串“看起来很酷”的命令名，而是分清楚哪些是官方已发布能力，哪些只是架构设想。


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://yeasy.gitbook.io/claude_guide/di-san-bu-fen-jin-jie-pian/07_coding/7.6_advanced.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.