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 会清理较早的工具输出，并在需要时总结对话。压缩是有损交接，不是逐字保留整段历史。 早期细节可能丢失，摘要也不能替代测试通过或决策获批的证据。 长任务可以按这套流程处理：-
先看占用，再补材料。 用
/context查看窗口里装了什么。过滤日志、按范围读取相关文件，避免反复加载整份输出。 -
区分长期规则与当前状态。 把持久的项目约定写进
CLAUDE.md；用简短的任务笔记记录当前目标、验收标准、已定决策、改动文件、测试命令与结果、未解决风险和下一步。链接到证据，不要复制大段输出。 -
在阶段边界压缩。 从调研转入实现、或从实现转入审查前，先保存任务笔记。需要主动控制时，使用带重点的命令：
- 交接后重新核对。 压缩后让 Claude 读取任务笔记并查看当前 diff，确认它能复述剩余工作；证据缺失或过期时，重新检查文件或运行测试。
-
无关任务另起上下文。 先保存需要保留的内容，再用
/clear，不要把上一个任务的无关历史带进来。
CLAUDE.md 中加入 Compact Instructions 小节，说明摘要应保留什么。但这只是指导，不是无损记忆的保证。更通用的持久状态设计见 Agent harness。
本次 Folo 线索建议在约 300k–400k token 时压缩，这是实践者的个人偏好，不是普适最优值。先核对所安装版本支持的命令，再根据质量、延迟和用量调整，不要盲目照搬阈值或删除已有的上下文限制配置。
可直接试验的示例提示
以下提示可以直接复用，用于探索 Fable 的能力边界：端到端深度调研
自我红队评审
巨量上下文审计
高约束创作
代码作曲
发现你的未知：盲区扫描技术
Thariq 演讲的第二个核心主题：你写给模型的提示词就像是”地图”，但真正的代码库和现实世界是”领地”。模型在领地里碰到地图上没标注的东西，就得自己做决定。Fable 5 的活动范围太大了，如果你不提前搞清楚这些未知数，它会在你没想到的地方做出你不想要的决策。 六个具体技巧：- 盲区扫描（blind spot pass）：动手之前，先让 Fable 通读相关代码，帮你找出你自己都不知道的潜在问题
- 四原型爆发：让它一口气做四个风格完全不同的原型，通过反应来发现自己的偏好，而不是先想清楚再描述
- 让它提问你：通过提问把你脑子里那些”知道但没写下来”的细节挖出来
- 参考代码当地图：给它一段别的系统里的代码当参考模式，比直接写规格说明书更高效
- 决策日志：让它在执行过程中记录每个偏离你预期的决策点，事后你能看到它在哪些地方遇到了你没考虑到的问题
- 反向考你：让它反过来考你，确保你理解它做了什么，这样提 PR 的时候能说清楚
Loops 设计范式
Claude Code 官方推出的 Loops 框架，把 Agent 工程从经验直觉提升为可复用的设计语言。核心洞察：触发、停止条件、工件、适用场景——四个变量一旦确定，循环的形态就确定了。判断的关键不是”任务难不难”，而是哪一段工作可以交付出去。四种循环类型
Turn-based（回合制循环，默认 agentic loop）- 你交付的是：检查这一步
- 触发：用户提示
- 停止：agent 自行判断任务完成，或认为需要更多上下文
- 主要工件：SKILL.md（把人工验证步骤编码进去）
- 适用场景：短期、一次性、不属于周期流程的任务
- 你交付的是：停止条件
- 触发：手动提示
- 停止：目标达成，或达到预设轮数上限
- 主要工件：/goal + 评估模型
- 适用场景：有可验证退出标准的任务
- 你交付的是：触发时机
- 停止：你取消它，或工作自然完成（PR 合并、队列清空）
- 主要工件：/loop（本地，关机即停）、/schedule（上云）
- 适用场景：周期性工作，或与外部系统交互
- 你交付的是：提示本身
- 触发：事件或计划，无人实时参与
- 停止：每个子任务达目标即退出；routine 本身持续运行直到关闭
- 主要工件：上述全部 + 动态工作流（research preview）+ auto mode
- 适用场景：持续流入的标准化工作——bug 报告、issue 分诊、依赖升级、批量迁移
质量护栏（四级递进）
- 保持代码库整洁——agent 跟随既有模式与约定
- 给 agent 自验证能力——用 SKILL 编码”好”的标准
- 文档易达——框架/库文档保持最新最佳实践
- 用第二个 agent 做代码审查——新鲜上下文的审查者不受主 agent 推理路径的”确认偏误”影响
成本护栏
- 选对工件与模型——简单任务不需要多 agent 或循环
- 明确成功/停止标准——具体到”什么样算完成”
- 大规模运行前先试点——动态工作流可产生数百 agent
- 确定性工作用脚本——例如表单填写脚本，比 agent 反复推导代码便宜得多
- 不要比必要更频繁地运行 routine
/usage、/goal（无参）、/workflows 审查 token 消耗分布。循环本身不省钱——模型分层 + 明确边界才省钱。
从哪开始
审视你已在做的工作，找出你自身是瓶颈的那一项，问自己：- 能写出量化验证检查吗？→ 能，试试 goal-based
- “完成”长什么样说得清吗？→ 说不清，先别自动化
- 工作是否按计划流入？→ 是，试试 time-based
- 都不是 → 老老实实用 turn-based，先把 SKILL.md 写好
维护 AI 生成的代码
当所有代码都由 AI 生成时，风险不再是写代码，而是让代码可持续迭代、可维护、不腐化。产品工程师 Tw93 在发布了一款约 11 万行 Swift 产品代码、7.3 万行测试代码的 App 第 13 个版本后，总结了六条实践：- 合理的架构和分层依然重要。 清晰的边界让 AI 生成的代码更容易维护和扩展。不要让模型每次都重新发明结构。
- 自动化测试是质量的主干。 每个 bug 修复必须同步添加回归测试，让同样的 bug 无法再次出现。
- 积极删除死代码。 删除功能时，代码也要一起清理。积累的残留物会同时迷惑人类和未来的 AI。
- CI/CD + 干净机器。 发布前在干净的云端 runner 上跑完整测试，而不只是在本地跑。
- 让 AI 自动验证、自动纠错。 把自动化验证接入循环，只在关键阶段保留人工验证。
- 重复工作做成 skill。 编码重复流程，避免每次从头解释。
监督比你聪明的人
前沿 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——从历史会话转录中捞回上下文，跨会话项目不必每次从零重建
核心要点
使用 Fable 5 的精髓不在于掌握更多命令或参数，而在于改变你和模型的关系：- 从”监督执行”转向”指引方向”
- 从”拆解步骤”转向”设定目标与验收标准”
- 从”小心试探”转向”大胆设想”
- 从”检查输出”转向”要求自检”
参考资料
- 宝玉：上下文自动压缩阈值建议 — 2026-10-09 的 Folo 线索，属于实践经验，不是官方默认值
- Claude Code：运行原理 — 上下文生命周期与压缩可能丢失的内容
-
Claude Code：最佳实践 —
/context、定向压缩、持久指令与任务隔离 - Thariq (Claude Code team): 用好 Fable 5 的秘诀 — 宝玉整理自 Thariq 的视频分享
- Thariq 在 AI Engineer World’s Fair 的 Fable 5 演讲全文 — 解除束缚 + 发现未知 + 打破常规四个主题
- Claude Code 官方：Loops 设计范式 — 从提示到循环的范式转换
- Tw93：代码全由 AI 生成时代的可维护性 — 六个实践：架构分层、自动化测试、清理死代码、CI/CD、自动验证、重复工作 skill 化
- Simon Willison：Agentic Engineering Patterns — 从代码边际成本趋零出发的完整工程方法论
- poteto：pstack Agent 工程完全指南 — 验证优先 + 监督比你聪明的人五技法