ClaudeCode

.webp) 工程界有句老话：“缓存统治一切（Cache Rules Everything Around Me）”。在开发 AI 智能体（Agent）时，这句话同样适用。 像 Claude Code 这样需要长时间运行的智能体产品，之所以具有可行性，很大程度上归功于 Prompt 缓存（Prompt Caching）。它允许我们复用之前的计算结果，从而大幅降低延迟和成本。 关于 Prompt 缓存的原理和技术实现，这里不展开。在 Claude Code 团队，我们整个底层架构都是围绕 Prompt 缓存设计的。如果缓存命中率高，成本就能降下来，我们也能为订阅用户提供更宽松的使用限制。为此，我们甚至对缓存命中率设置了告警，一旦低于某个阈值，就会触发紧急故障（SEV）处理。 在优化大规模 Prompt 缓存的过程中，我们学到了很多经验。有些经验甚至有点反直觉，下面就和大家分享。 一、合理安排提示词的结构 Prompt 缓存的工作原理是“前缀匹配”（prefix matching）。API 会从请求的开头开始，一直缓存到你设置的断点。这意味着，内容的排列顺序至关重要。你希望尽可能多的请求，能够共享相同的前缀。 最好的做法是：把静态内容放在前面，动态内容放在后面。 在 Claude Code 里，我们的排列顺序是这样的： 静态系统提示词与工具定义（全局缓存） Claude.md 文件（在项目级别缓存） 会话上下文（在单个会话内缓存） 当前对话的具体消息 通过这种方式，我们能让更多的会话共享缓存命中。 但要注意，这种顺序出乎意料地脆弱！我们曾经踩过坑，破坏了这种顺序。比如：把详细的时间戳放进了静态系统提示词里、工具的排列顺序变成随机的、或者动态修改了工具的参数。这些都会导致前缀改变，缓存失效。 二、用消息来传递状态更新 有时候，你放在提示词里的信息会过期。比如，时间变了，或者用户修改了某个文件。你可能会想，那我去更新一下系统提示词吧。千万别这么做。这会导致缓存未命中，让用户付出高昂的成本。 更好的做法是：在下一轮对话中，通过“消息”来传递这些更新。 在 Claude Code 中，如果信息有更新（比如“现在是星期三了”），我们会在下一条用户消息或工具结果中插入一个 <system-reminder> 标签。这样既告诉了模型新情况，又保住了前面的缓存。 三、不要在对话中途切换模型 Prompt 缓存是和特定模型绑定的。这就导致了一个很反直觉的成本计算。 假设你正在用最强大的 Opus 模型聊天，已经积累了 10 万 token 的上下文。这时，你想问一个非常简单的问题。你可能觉得切换到便宜的 Haiku 模型会更省钱。错了。切换到 Haiku 反而更贵，因为你需要为 Haiku 重新建立那 10 万 token 的缓存。 ...

 开发一个智能体（Agent）系统，最难的部分之一，就是怎么给它设计"工具箱"（Action Space）。 Claude 是通过调用工具（Tool Calling）来做事的。但在 Claude API 里，有各种各样的工具构建方式，比如执行 bash 命令、调用 Skills，或者最近新出的代码执行功能。 面对这么多选择，你怎么给 Agent 设计工具？是只给它一个全能工具（比如直接执行代码或 bash），还是给它 50 个工具，覆盖它可能遇到的每一种场景？ 为了弄明白这个问题，我喜欢把自己代入模型。想象一下，如果给你一道很难的数学题，你希望手头有什么工具？这其实取决于你自己的能力！ 给你一张纸是最低配置，但你只能手算。给你一个计算器会好很多，前提是你得知道怎么按那些高级功能键。最快、最强大的工具是一台电脑，但这要求你必须懂编程，能写代码来解题。 这是一个设计 Agent 时非常有用的思维框架。你给它的工具，必须跟它的能力相匹配。 可是，你怎么知道它有多大能耐呢？答案是：去观察它，去读它的输出，去不断实验。你要学会"用 Agent 的眼光看世界"。 在开发 Claude Code 的过程中，我们一直在观察 Claude。下面是我们学到的一些经验。 改进提问方式与 AskUserQuestion 工具 我们在开发 AskUserQuestion 这个工具时，目标是让 Claude 更擅长向用户提问（这通常被称为激发，elicitation）。 虽然 Claude 本来就能用纯文本问问题，但我们发现，回答这些问题通常很费时间。我们该怎么降低这种摩擦，让用户和 Claude 的沟通更高效呢？ 尝试 1：修改 ExitPlanTool 我们最初的想法是，在现有的 ExitPlanTool（退出并输出计划的工具）里加一个参数，让它在输出计划的同时，也输出一组问题。这是最容易实现的方法，但它把 Claude 搞糊涂了。因为我们让它同时做两件事：一边给计划，一边问跟计划相关的问题。如果用户的回答和计划冲突了怎么办？Claude 是不是得再调用一次 ExitPlanTool？显然，这条路走不通。 尝试 2：改变输出格式 接着，我们尝试修改 Claude 的系统提示词，让它输出一种特定格式的 Markdown，用来表示问题。比如，我们可以要求它输出一个列表，括号里写上可选项。然后我们通过解析这个格式，在终端里渲染出一个漂亮的提问界面。 这看起来是个通用的改动，Claude 似乎也能做到，但这并不可靠。Claude 有时会多加几句话，有时会漏掉选项，或者干脆用了别的格式。 尝试 3：推出 AskUserQuestion 工具 ...

 前几天，Anthropic 团队分享了一篇文章，总结了他们内部使用 Claude Code 的经验，特别是关于 “Skills”（技能）的使用心得。我觉得这篇文章非常有启发性，不仅介绍了 Skills 的各种类型，还给出了很多编写好 Skill 的建议。 下面是这篇文章的中文翻译（略有删改）。 在 Claude Code 中，Skills 已经成为最常用的扩展方式。它们非常灵活、容易制作，分发起来也很简单。 但是，这种灵活性也带来了一个问题：不知道怎么用才是最好的。什么样的 Skill 值得开发？写好一个 Skill 的秘诀是什么？什么时候该把它们分享给其他人？ 在 Anthropic 内部，我们在大规模使用 Claude Code 的 Skills，目前有数百个在活跃使用中。下面就是我们在开发中总结出的一些经验。 什么是 Skills？ 如果你对 Skills 还不熟悉，建议先阅读官方文档，或者观看我们的最新教程。本文假设你已经对它有所了解。 关于 Skills，最常见的一个误解是：它们"只是 Markdown 文件"。但其实最有趣的地方在于，它们不仅是纯文本，还是一个完整的文件夹，可以包含脚本、静态资源、数据等等。AI 代理（agent）可以发现、探索并操作这些内容。 在 Claude Code 中，Skills 还有非常丰富的配置选项，甚至可以注册动态的 hook（钩子）。 我们发现，最有趣的一些 Skills，正是创造性地结合了这些配置选项和文件夹结构。 Skills 的常见类型 我们把内部的所有 Skills 梳理了一遍，发现它们基本上可以归为以下几类。最好的 Skills 通常只专注于其中一类，而那些让人困惑的 Skills 往往跨越了多个类别。 这并不是一个绝对的列表，但如果你想看看团队内部还缺什么工具，它是一个很好的参考。 1. 库与 API 参考指南（Library & API Reference） 这类 Skill 主要向 Claude 解释如何正确使用某个代码库、CLI 或 SDK。它们既可以针对内部私有库，也可以针对 Claude 容易出错的一些公共库。这类 Skill 通常包含一个参考代码片段的文件夹，以及一份列出各种"坑"的清单，让 Claude 在写代码时避开。 ...

Claude Code 开发者的一些使用建议 作者：Boris（Claude Code 的创造者） 译者：Claude 日期：2026年3月17日 我是 Boris，Claude Code 的创造者。我想快速分享一些来自 Claude Code 团队的使用建议。团队使用 Claude 的方式和我个人使用的方式不太一样。记住：使用 Claude Code 没有唯一正确的方式——每个人的配置都不同。你应该多尝试，找到适合自己的方法！ 1. 多任务并行处理 同时启动 3-5 个 git worktree，每个运行独立的 Claude 会话。这是最大的生产力提升点，也是团队的首要建议。就我个人而言，我使用多个 git checkout，但大多数 Claude Code 团队更喜欢 worktree——这正是 @amorriscode 在 Claude Desktop 应用中内置支持 worktree 的原因！ 有些人还会给 worktree 命名，并设置 shell 别名（za, zb, zc），这样一键就能在它们之间切换。还有人专门设置一个"分析" worktree，只用于读取日志和运行 BigQuery。 参考：https://code.claude.com/docs/en/common-workflows#run-parallel-claude-code-sessions-with-git-worktrees 2. 复杂任务先从 plan 模式开始 把精力投入到计划中，让 Claude 一次性完成实现。 有人会让一个 Claude 写计划，然后启动第二个 Claude 以高级工程师的身份审查它。 另一个人说，一旦事情开始偏离轨道，就切换回 plan 模式重新规划。不要硬撑下去。他们还明确告诉 Claude 在验证步骤时进入 plan 模式，而不仅仅是在构建时。 ...