> ## Documentation Index
> Fetch the complete documentation index at: https://base.bangwu.me/llms.txt
> Use this file to discover all available pages before exploring further.

# Claude Code 高效使用模式

> 来自 Claude Code 团队和社区实践者的 Fable 5 使用心得：把模型当作思维伙伴、设定目标与验收标准、一次给足上下文、要求自检、用预算逼出更好的取舍。

# Claude Code 高效使用模式

Claude Code 的 Fable 5 模型带来了显著的编程能力提升——它可以连续运行数小时、自测代码，甚至写出比开发者更好的实现。但模型强不代表一定用得好。以下模式来自 Claude Code 团队成员 Thariq 的分享和社区实践，帮助你充分释放 Fable 的能力上限。

## 三个核心心态转变

Claude Code 团队成员 Thariq 总结了使用 Fable 5 后工作方式发生的三个关键变化：

### 解除 Claude 的束缚：让模型给你惊喜

Anthropic 内部管这个叫**能力悬余**（capability overhang）——模型其实已经能做很多事，只是我们还没找到正确的打开方式。早期模型需要详细的指令和大量示例，但 Fable 这个级别的模型反过来了：给太多示例反而会限制它，因为它自己的想象力比你给的示例更丰富。

Claude Code 最近一个关键变化是**砍掉了 80% 的系统提示词**。新的做法：给上下文，不给约束；告诉它情况，不告诉它不许做什么。

一个具体例子：你问聊天模型哪些宝可梦的名字以 aw 结尾，它答不上来，因为它没法在脑子里一个一个过名字。但给它代码执行工具，它会去拉全部宝可梦列表然后写脚本过滤，两秒钟就找出答案。能力一直都在，工具把它解锁了。

### 把 Claude 当作思维伙伴，而不是代码执行器

过去我们习惯把任务拆成小块交给模型，反复检查输出，在它过早停下时发现问题。Fable 改变的是：你越来越多地在检查 Claude 是否在做**正确的工作**，而不只是是否在做**正确的事**。

一个常见的失败模式是：你自己其实不知道想要什么，或者不知道什么可行。在思考过程中尽早让 Claude 参与，可以在实施前发现这些盲区。

可行的做法：

* 从一份小的需求规范开始。写最终 spec 之前，先让 Claude 就实施方案对你进行"面试提问"，帮你建立信心。
* 抛出一个想法，让它想出几个发展方向，生成 HTML 原型供你审查。
* 给它提供上下文，而不仅仅是约束条件。比如不说"保持简单，不要过度设计"，而是说"这是个实验性功能，一个月后大概率会删掉，所以不要构建丢弃起来会心疼的东西"。

### 设定目标，同时提供验证手段

一旦明确想要什么，考虑使用 Claude Code 的两个功能：

* `/goal`（目标指令）：帮助 Claude 持续工作直至完成
* **workflows（工作流）**：帮助 Claude 验证其工作

实用流程示例：

> 写完 spec 后，告诉 Claude："设定一个目标，以完整实现该规范。然后使用工作流来验证计划的每个部分，并准备一份报告，说明已实现的内容以及是否有任何差异。"

这让 Claude 尽可能以有创意和周全的方式发挥能力，同时又确保它构建的是你真正想要的东西。

### 尝试更有野心的事情

Fable 是一个令人难以置信的模型。如果你觉得某件事大语言模型做不到——给它个机会试试。

Thariq 举的例子是：他用 Fable 剪辑了自己发布的那个视频。不要因为过去的经验而对模型的上限设限。

## 把 Fable 逼到能力上限的五条原则

社区实践者 Gorden Sun 总结了让 Fable 发挥最大能力的几条实用原则：

### 1. 给目标和验收标准，把步骤留给 Fable 自己拆

不要微管理。告诉它你想达成什么、如何判断成功，让它自己规划执行路径。过度分解任务反而会限制模型发挥其规划能力。

### 2. 允许 Fable 先出计划、先提问再动工

给模型一个"思考阶段"。让它先提出方案、提出澄清问题，得到你的确认后再开始动手。这能大幅减少方向性错误和返工。

### 3. 一次性把全部原始材料扔给 Fable

不要分批次、分片段地喂信息。把相关文档、代码库上下文、需求说明一次性给足。Fable 的长上下文能力允许它自己判断哪些信息重要、如何关联。

### 4. 明确要求 Fable 自检

关键的自检维度：

* **写测试**：要求为每个功能写测试，并确保测试通过
* **找反例**：要求找出方案可能失败的边界情况
* **标注置信度**：为每个关键结论标注确信程度，并说明什么证据会改变判断

### 5. 给预算约束，逼出更好的取舍

适量限制资源（搜索次数、字数、时间）反而会迫使模型做出更聪明的取舍。无限制的资源有时会导致过度的、不够聚焦的输出。

## 主动管理上下文

大窗口是容量，不是必须填满的指标。“一次给足上下文”指需求和相关证据完整，不是把全部日志和无关对话都塞进去。

上下文接近上限时，Claude Code 会清理较早的工具输出，并在需要时总结对话。**压缩是有损交接，不是逐字保留整段历史。** 早期细节可能丢失，摘要也不能替代测试通过或决策获批的证据。

长任务可以按这套流程处理：

1. **先看占用，再补材料。** 用 `/context` 查看窗口里装了什么。过滤日志、按范围读取相关文件，避免反复加载整份输出。

2. **区分长期规则与当前状态。** 把持久的项目约定写进 `CLAUDE.md`；用简短的任务笔记记录当前目标、验收标准、已定决策、改动文件、测试命令与结果、未解决风险和下一步。链接到证据，不要复制大段输出。

3. **在阶段边界压缩。** 从调研转入实现、或从实现转入审查前，先保存任务笔记。需要主动控制时，使用带重点的命令：

   ```text theme={"theme":{"light":"github-light","dark":"github-dark"}}
   /compact 保留目标、验收标准、已定决策、改动文件、测试结果、未解决风险和下一步。
   ```

4. **交接后重新核对。** 压缩后让 Claude 读取任务笔记并查看当前 diff，确认它能复述剩余工作；证据缺失或过期时，重新检查文件或运行测试。

5. **无关任务另起上下文。** 先保存需要保留的内容，再用 `/clear`，不要把上一个任务的无关历史带进来。

可以在 `CLAUDE.md` 中加入 `Compact Instructions` 小节，说明摘要应保留什么。但这只是指导，不是无损记忆的保证。更通用的持久状态设计见 [Agent harness](/zh/env/agent-harness)。

本次 Folo 线索建议在约 300k–400k token 时压缩，这是实践者的个人偏好，**不是普适最优值**。先核对所安装版本支持的命令，再根据质量、延迟和用量调整，不要盲目照搬阈值或删除已有的上下文限制配置。

## 可直接试验的示例提示

以下提示可以直接复用，用于探索 Fable 的能力边界：

### 端到端深度调研

```
围绕"2026年AI Agent基础设施格局"做深度调研，交叉验证至少8个信源，
关键数据整理成表格并做趋势分析，最终交付一份带引用的中文PDF报告
加一页信息图。先给我大纲和验证思路，我确认后再动工。
```

### 自我红队评审

```
先给出你认为的最优方案，然后切换成最苛刻的评审，找出三个致命漏洞，
再给修订版。为每个关键结论标注置信度，并说明什么证据会让你改变判断。
```

### 巨量上下文审计

```
（附上整份合同、整个代码库或整本书稿）
通读全部内容，找出所有内部矛盾、定义不一致、前后引用对不上的地方，
按严重程度排序，每处给出原文位置。
```

### 高约束创作

```
写一首七言律诗，藏头四字自定，颔联须含一处双关，全诗禁用"风""月"二字，
平仄合规，写完附上逐条约束的自查清单。
```

### 代码作曲

```
不用任何音频素材，纯代码合成一段30秒电子乐，
再做个网页让一团粒子流体跟着节拍运动。
```

## 发现你的未知：盲区扫描技术

Thariq 演讲的第二个核心主题：你写给模型的提示词就像是"地图"，但真正的代码库和现实世界是"领地"。模型在领地里碰到地图上没标注的东西，就得自己做决定。Fable 5 的活动范围太大了，如果你不提前搞清楚这些未知数，它会在你没想到的地方做出你不想要的决策。

六个具体技巧：

* **盲区扫描**（blind spot pass）：动手之前，先让 Fable 通读相关代码，帮你找出你自己都不知道的潜在问题
* **四原型爆发**：让它一口气做四个风格完全不同的原型，通过反应来发现自己的偏好，而不是先想清楚再描述
* **让它提问你**：通过提问把你脑子里那些"知道但没写下来"的细节挖出来
* **参考代码当地图**：给它一段别的系统里的代码当参考模式，比直接写规格说明书更高效
* **决策日志**：让它在执行过程中记录每个偏离你预期的决策点，事后你能看到它在哪些地方遇到了你没考虑到的问题
* **反向考你**：让它反过来考你，确保你理解它做了什么，这样提 PR 的时候能说清楚

## Loops 设计范式

Claude Code 官方推出的 Loops 框架，把 Agent 工程从经验直觉提升为可复用的设计语言。核心洞察：触发、停止条件、工件、适用场景——四个变量一旦确定，循环的形态就确定了。判断的关键不是"任务难不难"，而是**哪一段工作可以交付出去**。

### 四种循环类型

**Turn-based（回合制循环，默认 agentic loop）**

* 你交付的是：检查这一步
* 触发：用户提示
* 停止：agent 自行判断任务完成，或认为需要更多上下文
* 主要工件：SKILL.md（把人工验证步骤编码进去）
* 适用场景：短期、一次性、不属于周期流程的任务

改进空间在于用 SKILL.md 把"你脑子里的验收标准"显式化，让 agent 能自检更多环节，从而压缩每一轮的回合数。

**Goal-based（/goal）**

* 你交付的是：停止条件
* 触发：手动提示
* 停止：目标达成，或达到预设轮数上限
* 主要工件：/goal + 评估模型
* 适用场景：有可验证退出标准的任务

当单轮不够、需要 agent 迭代时使用。关键是把"完成长什么样"写死——每轮 agent 想停时，由评估模型核对你的条件，不达标就送回去继续。确定性指标效果最好（通过多少测试、分数超过某阈值），因为评估模型只需比对，无需自行裁量"够不够好"。

**Time-based（/loop、/schedule）**

* 你交付的是：触发时机
* 停止：你取消它，或工作自然完成（PR 合并、队列清空）
* 主要工件：/loop（本地，关机即停）、/schedule（上云）
* 适用场景：周期性工作，或与外部系统交互

优先事件驱动而非纯时间驱动——设更长间隔、或基于状态变化触发，能同时省 token 与避免抖动。/loop 跑在本地机器，关机即停；上云用 /schedule。

**Proactive（主动式循环）**

* 你交付的是：提示本身
* 触发：事件或计划，无人实时参与
* 停止：每个子任务达目标即退出；routine 本身持续运行直到关闭
* 主要工件：上述全部 + 动态工作流（research preview）+ auto mode
* 适用场景：持续流入的标准化工作——bug 报告、issue 分诊、依赖升级、批量迁移

范例拼装方式：/schedule 定时巡查 → /goal 定义"完成"标准 + SKILL 编码验证方法 → 动态工作流并行探索多方案并对抗式审查 → auto mode 免授权全程执行。

### 质量护栏（四级递进）

1. **保持代码库整洁**——agent 跟随既有模式与约定
2. **给 agent 自验证能力**——用 SKILL 编码"好"的标准
3. **文档易达**——框架/库文档保持最新最佳实践
4. **用第二个 agent 做代码审查**——新鲜上下文的审查者不受主 agent 推理路径的"确认偏误"影响

单次结果不达标时，不要只修这一个问题，而应把它编码进系统，让未来所有迭代都受益。

### 成本护栏

* 选对工件与模型——简单任务不需要多 agent 或循环
* 明确成功/停止标准——具体到"什么样算完成"
* 大规模运行前先试点——动态工作流可产生数百 agent
* 确定性工作用脚本——例如表单填写脚本，比 agent 反复推导代码便宜得多
* 不要比必要更频繁地运行 routine

用 `/usage`、`/goal`（无参）、`/workflows` 审查 token 消耗分布。循环本身不省钱——模型分层 + 明确边界才省钱。

### 从哪开始

审视你已在做的工作，找出你自身是瓶颈的那一项，问自己：

* 能写出量化验证检查吗？→ 能，试试 goal-based
* "完成"长什么样说得清吗？→ 说不清，先别自动化
* 工作是否按计划流入？→ 是，试试 time-based
* 都不是 → 老老实实用 turn-based，先把 SKILL.md 写好

四种类型并非互斥，而是可组合的积木。最复杂的形式（Proactive）就是把 /schedule、/goal、动态工作流、auto mode 拼装起来。

## 维护 AI 生成的代码

当所有代码都由 AI 生成时，风险不再是写代码，而是让代码可持续迭代、可维护、不腐化。产品工程师 Tw93 在发布了一款约 11 万行 Swift 产品代码、7.3 万行测试代码的 App 第 13 个版本后，总结了六条实践：

1. **合理的架构和分层依然重要。** 清晰的边界让 AI 生成的代码更容易维护和扩展。不要让模型每次都重新发明结构。
2. **自动化测试是质量的主干。** 每个 bug 修复必须同步添加回归测试，让同样的 bug 无法再次出现。
3. **积极删除死代码。** 删除功能时，代码也要一起清理。积累的残留物会同时迷惑人类和未来的 AI。
4. **CI/CD + 干净机器。** 发布前在干净的云端 runner 上跑完整测试，而不只是在本地跑。
5. **让 AI 自动验证、自动纠错。** 把自动化验证接入循环，只在关键阶段保留人工验证。
6. **重复工作做成 skill。** 编码重复流程，避免每次从头解释。

贯穿的主线：AI 把写代码的边际成本降到了接近零，所以真正重要的纪律转向了架构、验证和清理。

## 监督比你聪明的人

前沿 Agent 消除了"必须先建立心智模型才能改代码"的门槛，但仍有两类高频失败：理解不了你的意图，以及缺少把事做对的上下文。两者同源——取决于你往上下文窗口里注入多高质量的语境。现代代码库已大到人类无法在脑中装下完整心智模型，所以方法论要从"自己懂"转向"让 Agent 向你证明它懂"。

来自一位每月交付数千 PR 实践者的五个技法：

**1. 间接提示（in your own words）。** 不直接下令，先让 Agent 用自己的话复述问题——"读这个 Slack 线程，用平实的语言复述你理解的根本问题"。一举三得：把噪声压缩成结构化问题陈述、立刻发现误解、避免你自己的错误假设带偏 Agent。

**2. 心智模型构建 skills。** 四个互补命令：

* `/how`——追踪运行时机制，跨目录/服务并行探索
* `/why`——调查动机与意图：代码只说发生了什么，很少说为什么。并行查 Git 历史、PR 评论、Linear、Notion、Slack、Datadog、Sentry
* `/teach`——让 Agent 以直觉可理解的方式讲给你听（这个过程也迫使 Agent 建立真实心智模型，而不是自信地不懂装懂）
* `/recall`——从历史会话转录中捞回上下文，跨会话项目不必每次从零重建

**3. README 驱动开发。** 对共享代码，先写 README 再实现。它逼你从假想用户的 API 视角倒推架构。用 Diátaxis 框架区分 Tutorial / How-to / Reference / Explanation，再做一遍去 AI 腔。写好的文档同时成为 Agent 可自我检验的明确目标。

**4. 原型优先。** 规划阶段最常见的两个错误：接受 Agent 的第一个设计，以及在缺乏实证时过度打磨。解法是让 Agent 并行产出多个原型——UI 变体挂在 switcher 后面、用验证 CLI 实测时序与布局——用截图/视频供人选择。原型就是用代码做规划：Agent 用实证回答自己的开放问题。

**5. /architect 五阶段。** Ground（用 /how + /why 建立现状模型）→ Sketch（多个独立 runner 跨模型家族并行，各产出完整设计包：调用点、类型定义、函数签名、理由）→ Cross-judge（不同模型按严格 rubric 交叉评审）→ Implement（以草图为准填实现）→ 循环回到验证。

## 核心要点

使用 Fable 5 的精髓不在于掌握更多命令或参数，而在于**改变你和模型的关系**：

* 从"监督执行"转向"指引方向"
* 从"拆解步骤"转向"设定目标与验收标准"
* 从"小心试探"转向"大胆设想"
* 从"检查输出"转向"要求自检"

好的 prompt 不是指令越细越好，而是**约束恰好够用，信任给到上限**。

## 参考资料

* [宝玉：上下文自动压缩阈值建议](https://x.com/dotey/status/2108669008283402744) — 2026-10-09 的 Folo 线索，属于实践经验，不是官方默认值

* [Claude Code：运行原理](https://code.claude.com/docs/en/how-claude-code-works#the-context-window) — 上下文生命周期与压缩可能丢失的内容

* [Claude Code：最佳实践](https://code.claude.com/docs/en/best-practices#manage-context-aggressively) — `/context`、定向压缩、持久指令与任务隔离

* [Thariq (Claude Code team): 用好 Fable 5 的秘诀](https://x.com/dotey/status/2074019009226322078) — 宝玉整理自 Thariq 的视频分享

* [Thariq 在 AI Engineer World's Fair 的 Fable 5 演讲全文](https://x.com/dotey/status/2074255513353642090) — 解除束缚 + 发现未知 + 打破常规四个主题

* [Claude Code 官方：Loops 设计范式](https://x.com/shao__meng/status/2074290011282055656) — 从提示到循环的范式转换

* [Tw93：代码全由 AI 生成时代的可维护性](https://x.com/HiTw93/status/2094015568101921254) — 六个实践：架构分层、自动化测试、清理死代码、CI/CD、自动验证、重复工作 skill 化

* [Simon Willison：Agentic Engineering Patterns](https://x.com/shao__meng/status/2094027833505144919) — 从代码边际成本趋零出发的完整工程方法论

* [poteto：pstack Agent 工程完全指南](https://x.com/shao__meng/status/2099300148874707297) — 验证优先 + 监督比你聪明的人五技法


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.