Claude AI使用指南：技巧与最佳实践

2026年9月16日 Claude Cowork 被并入聊天界面时，同时有三项创作功能以测试版上线：做文档的 Claude Docs、做幻灯片的 Claude Slides、做视觉设计的 Claude Design。本文讲的是其中的第一项。一句话说，Claude Docs 把对话产出的东西变成一份可以继续编辑的文档。你说“把刚才这些整理成规格书，做成能发给团队的形式”，Claude 就会当着你的面写出来，动笔之前先把缺的信息问清楚。做出来的是带标题层级和表格的富文本，而且一份文档里可以有多个标签页。你可以自己动手改，也可以在文档里选中一段文字、留一条评论并提到 @Claude，让它来改。最容易被忽略的长处，是还可以把 Claude Code 的一次会话变成规格书、操作手册或报告。不过它是测试版，缺的东西也缺得很明白：没有版本历史，删除无法撤销，手机端改不了，Team 和 Enterprise 不能向组织外共享。本文给这些“没有的东西”留出和功能同样多的篇幅，并梳理它适合做什么、不适合做什么。

Claude Code 的 Projects 被重建了。此前的项目是一个装着对话和参考资料的文件夹，新的 Projects 则是一整条对话：你写下需求，Claude 把它拆成一个个线程，线程在云端并行运行，每个完成后开一个 pull request 并回报结果，合上笔记本也不会让它们停下来。不过动手之前有三件事值得先确认：能用的账号仍然有限（Pro 和 Max 的公开测试，优先发放给还没有现存项目的账号）、github.com 与 Claude GitHub App 在实际操作中是硬性要求，以及它消耗用量上限的速度和单个会话完全不是一个量级。本文依据官方文档与官方博客，说明怎么判断放量有没有轮到你、一个线程启动时带着什么（包括项目里一旦有多个仓库、权限规则和钩子就会失效这个陷阱）、token 开销从哪里来（默认是 Opus 的 high effort），以及在 Subagents、agent view、Agent Teams、动态工作流和 Projects 这五种并行方式之间该怎么选。

只把制定计划的部分交给聪明的模型，实现交给又快又便宜的模型。Claude Code 的 opusplan 就是自动做到这一点的模型指定。它在 plan mode 期间用 Opus，其余时候用 Sonnet 运行，可以通过 /model opusplan 或 settings.json 的 model 使用。不过，它不会出现在 /model 的列表中，而且每次进入或退出 plan mode 都会切换模型，因此每次都会在没有缓存的情况下重新读入整段对话。本文根据截至2026年9月15日的官方文档、更新日志和 GitHub 上的 issue，整理设置方法（包括固定版本和 1M 上下文）、从 plan mode 批准计划再进入实现的流程、它在 v2.0.0 中从选择界面被移除的经过与 Anthropic 工作人员的说明、切换所产生缓存费用的估算及压低方法、与 advisor 工具和子智能体的区别，以及适合与不适合的用法。

Claude Code 的主对话保持 Opus 5，只把翻译、批量检查这类工作交给 Sonnet 或 Haiku 的子智能体，能做到吗？结论是可以。子智能体的模型按调用时的指定、定义文件中的 model、环境变量 CLAUDE_CODE_SUBAGENT_MODEL、主对话的模型这一顺序决定，effort（投入度）也可以为每个子智能体单独指定。本文根据截至2026年9月15日的官方文档，整理这一顺序在不同版本间的差异、把所有子智能体固定为同一模型的 CLAUDE_CODE_SUBAGENT_MODEL_FORCE、别名因接入平台而指向不同模型，以及内置的 Explore 自 v2.1.198 起改为沿用主对话模型这几点。在此基础上，给出实际用其他模型启动并对照对话日志确认的结果：子智能体按指定的模型运行；光是启动就要读入数万 token；即使是订阅，子智能体的缓存也是 5 分钟过期；以及把同一段翻译交给 Opus 5、Sonnet 5、Haiku 4.5 各做 2 次时，耗时、费用和译文质量的差异。最后总结对费用和用量的影响，以及判断哪些工作可以降档的依据。

并行运行多个会话时，你难免会想知道是哪一个在吃每周额度。然而 Claude Code 的 /usage 只显示当前会话的数字，以及把整个套餐的消耗按技能、子智能体、插件、MCP 服务器拆分后的比例；每个会话各用了多少，桌面应用的用量环和 claude.ai 的设置页面上都看不到（截至2026年9月）。答案就在本机保存的对话日志里（~/.claude/projects 中的 JSONL 文件），但直接相加会得出错误的结果，因为一次回复会按内容块拆成好几行写入，而子智能体的记录又保存在单独的文件里。在我自己的机器上实测，直接相加的总量约为正确值的两倍，而且误差倍数因会话而异，连排名都变了。本文介绍官方界面能看到和看不到的内容、如何用约 50 行的汇总脚本正确统计日志、一个会话用掉近三分之一用量的实测结果、这些数字能说明问题的边界，以及想持续观察时如何配置 OpenTelemetry。

不必每次都叮嘱“先说结论”“用中文回答”，只要在对所有对话自动生效的指令栏里写一次就行。ChatGPT 的“自定义指令”、Claude 的“Claude的说明”、Gemini 的“给 Gemini 的指令”就是这样的栏位，但三家的界面名称、所在位置、能写的字数都不一样。ChatGPT 的 Free 和 Go 为 1,500 个字符，Plus 及以上为 5,000 个字符（2026年7月提高），Claude 和 Gemini 没有公布上限。本文在三家官方帮助页面上核实位置与上限，并依据 Anthropic 的官方提示词指南给出管用的写法与示例。此外，还把官方帮助页面明确写出的“指令不生效的场景”——项目中、Gem 中、临时聊天、公司账号等——整理成一份检查清单。

明明用中文提问，Claude 却用英文回答——官方仓库里反复出现同样的报告，研究也已经证实，在请求与回复跨语言的条件下，即便是最强的模型，也无法始终如一地用指定的语言回答。不过原因并不只有一个。读代码和工具输出的过程中一点点滑向英文的类型、在把对话做成摘要的压缩之后忘掉语言的类型、不是英文而是变成别的语言的类型，一共三种，管用的对策也各不相同。本文梳理每种类型的判断方法，说明把指示固定在系统提示词里的 Claude Code language 设置为什么在压缩之后依然有效，并把 2026年9月开始出现报告的“长会话里输出本身出现崩坏”这一问题，按可靠信息与尚未确认的信息分开整理。

“技能装太多会挤占上下文”——这话一半是对的，一半是错的。按 Claude Code 官方文档的说法，技能列表用的是模型上下文窗口的 1% 这样一份固定预算，无论再往里加多少技能，都会在那里封顶。它不会膨胀，取而代之发生的是“不再被调用”——一旦超出预算，Claude Code 就从调用次数最少的技能开始丢弃说明，只留下名字。失去说明的技能再也对不上你的请求，可是不会报错，也不会变慢。本文梳理以下内容：三种测量手段（/context、/usage、/skill-doctor）各自的分工；缓存未命中被定义为“5% 且 2,000 token”；缓存的寿命会随合约形态从 1 小时降到 5 分钟；在 MCP 工具定义已经默认延迟加载的今天，CLI 为什么依然更轻；把 CLAUDE.md 保持在 200 行以内的依据；以及测完之后先削什么——全部限定在官方文档能够确认的范围之内。

用 Claude 的时候卡住了，把屏幕上出现的那句话原样拿去搜，却几乎什么都搜不到——这样的字符串是存在的。The model returned no content because the response was blocked by content filtering、The response was blocked by the provider's content filter、Streaming response ended before any complete data was received、Could not locate the Claude CLI on PATH、Connection to Claude's response was lost. Claude may still be working 这五条就是例子。它们的共同点是“明明是在用 Claude 时出现的，可翻 Claude 的资料也找不到（看上去是这样）”，理由很简单——写下你此刻屏幕上这句话的，未必是你以为的那个程序。本文不打算从零讲解每一种原因，而是作为一个入口：先判定这句话是谁写的，再把你送到正确的那篇文章去。首先把可能写出这句话的层分成四个：提供模型的后端、Claude Code 本体、启动它的 IDE 扩展或封装器、第三方客户端。在此基础上真去比对，五条里有两条作为条目就写在 Claude Code 官方的错误参考里。Streaming response ended… 的官方定义是“头返回了，可体里没有 Claude API 的消息”，并不是中途断掉的意思。Could not locate the Claude CLI on PATH 则被官方放进“Wrapper and IDE errors”这个独立的一章，也就是由启动方程序打印、而不是 Claude Code 自身的内容。另一方面，content filter 那两条属于第三方一侧的词汇，而且 OpenCode 的 Issue #35736 报告说，Vertex 的 404、套接字断开、真正的拒绝这三种完全不同的失败，全部以同一句“blocked by content filter”显示出来。三种里与字面相符的只有一种。GitHub 的官方文档也写明，使用 Claude 时输入与输出同样会经过 GitHub Copilot 的内容过滤器，所以你在用 Claude，并不代表拦下你的就是 Anthropic 的过滤器。剩下的一条，在官方错误参考和 Remote Control 的官方文档里都找不到这串字，没能确定出处，因此本文不点出名字，而是给出自己查明的四步。已经确定的与尚未确定的，用标签分开写。

Claude Code 在响应中途停住，屏幕上出现 API Error: Connection lost mid-response. The response above may be incomplete.——把这句话原样拿去搜却几乎找不到资料，是因为这是一个比较新的名字。官方错误参考明确写着，在 v2.1.227 之前，Connection lost mid-response 显示为 Connection closed mid-response；与此同时，Response stalled mid-stream 被换成了 The response stopped arriving，Connection closed while thinking, before producing a response 被换成了 Connection lost before a response was produced。也就是说，现象早就存在，只是单词变了。本文以这次改名为起点，只依据官方文档和公开 Issue 来梳理。先讲“中途被切断”的 4 条消息（Server error、Connection lost、computer went to sleep、The response stopped arriving）的官方定义，以及已经流出来的输出为什么会被刻意保留——因为重发有可能把同一次工具调用执行两遍——还有恢复步骤就是回复 continue 这一点。接着用官方的 Automatic retries 分支说明为什么不会自动重试：什么都还没完成时的断开会以指数退避最多重发 10 次，思考结束但还没输出时最多重发 2 次并以 Connection lost before a response was produced 收尾，完成一个块之后则不再重发，只附上这条提示。再往后是可能断开的 3 个层次（本机与线路、代理和网关等链路、服务端与连接复用）、mTLS 证书轮换时的重新读取（v2.1.232 之后）、9 步排查清单、4 个流监视计时器的默认值（first-byte 180 秒、event 300 秒、byte 180 秒、body idle 5 分钟）与 CLAUDE_CODE_MAX_RETRIES、CLAUDE_CODE_RETRY_WATCHDOG、API_TIMEOUT_MS 等环境变量、与 8 种相似消息的区分对照表，以及原始 HTTPS 一切健康却只有 CLI 因 ECONNRESET 而掉的真实报告（#86473 和 #85979）。最后按确信度分开说明：症状和恢复步骤在官方有文档，但原因的官方说明还没有出来，CHANGELOG 里也找不到这次改名的记载。

迁移到 Claude Fable 5.1，并不是把模型ID换掉就完事。官方明确把其中3项标为破坏性变更，而且有2项报错的位置和原因离得很远。第1项会立刻报错：给 tool_choice 指定 type any 或 type tool 会返回 400 invalid_request_error，因为强制调用工具会跳过这个模型一直在做的思考，参数质量也会跟着下降。第2项是安静的那一个。思考块现在会记录它由哪个模型生成，而且只在一个方向上被保留，所以迁到 Fable 5.1 的对话能带着推理继续跑，而路由器或降级回退把它退回上一代时，那一轮就整个丢掉。默认情况下，API会在交给模型之前就把读不了的块丢弃，被丢掉的部分既不计入 input_tokens 也不计费，于是账单上什么都看不到。想让它可见，需要加上 thinking-binding-controls-2026-08-01 这个 beta 请求头。第3项影响面最广：只要改动了位于 Fable 5.1 思考块之前的东西，包括 system 提示词、tools 数组或更早的任何一条消息，它以及它之后的块就全部失效。是否强制生效取决于账户的创建时间，这意味着刚建好的验证环境会失败，而生产环境不会。本文也写清楚了没有变坏的部分：输入仍是每百万token $10，输出仍是 $50，而缓存读取降到 $0.25，即基础输入的0.025倍，其他Claude模型是0.1倍。官方给出的效果是典型工作负载约降低25%，智能体色彩浓的作业最多约降低45%。此外有7个行为不改代码也会变，包括并行工具调用变少、高 effort 下进度播报变少、low effort 下更倾向凭记忆作答；官方一共列了5项新增，其中缓存读取降价单独放在第5章讲，剩下4项里的 beta 功能，正是为了替换破坏性变更所禁止的那些做法而存在的。

Remote Control 把 Claude 手机应用或 claude.ai/code 连到一个已经跑在你自己机器上的 Claude Code 会话上，而多数讲解都漏掉的关键在于：什么都没有搬到云上——代码的执行和文件的访问自始至终留在本地，手机只是窥看那个会话的一扇窗。本文把这个设计带来的好处和代价一条条摊开。本地的文件系统、MCP 服务器、工具和项目配置全都照常可用（敲 @ 补全出来的是本地项目里的路径），对话和子智能体的进度会在终端、浏览器和手机之间保持同步，笔记本睡眠或网络掉线也扛得住，因为 Claude Code 会自动重连并把排队的更新补投过来。使用条件比看上去严格：需要 Pro、Max、Team 或 Enterprise（API 密钥用不了），要用 claude.ai 登录而不是 setup-token，必须直连 api.anthropic.com，而且四个关闭遥测的环境变量一个都不能设——这正是那些出于隐私考虑设了 DO_NOT_TRACK 的人被告知功能未启用的原因。文中覆盖三个入口（用 /remote-control 承接当前对话、claude --remote-control，以及带 --spawn、--capacity 32 和 --continue 的服务器模式），也划出了哪些斜杠命令能远程用、哪些像 /resume 一样仅限本地，还有对权限提示并不生效的 5 分钟对话框超时，以及两个推送开关。安全部分写得很克制：全程不开任何入站端口，网络那一侧的攻击面几乎消失，风险转移到了账号上；二维码只是近路而非认证；默认的门恰好只有已登录的账号这一道，所以设置通行密钥是回报最高的一步。此外还有会话记录的保留期限（5 年或 30 天）、手机丢失时该怎么办、Trusted Devices 的 18 小时登录窗口、服务器模式约 10 分钟的超时、约 4 小时的恢复窗口、远程机器上必须用 tmux 的规矩、按实际错误信息编排的排查表，以及和 Dispatch 的对比。