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

Dispatch 是这样一个功能：你从手机发出指令，Claude 在你自己的电脑上把这件事做完（测试版，Pro 与 Max）。它不在云端运行，动起来的是你的真实机器，而这一个事实同时决定了它的价值和它的危险。官方帮助写道，你可以从手机给 Claude 发消息、让它在你的桌面电脑上干活，用的是你已经在 Cowork 里配置好的那些连接器、插件和文件访问权限，整件事被 Anthropic 定位成一段从任意一端都能接上的连续对话。运行它要求电脑处于唤醒状态且桌面应用是打开的；电脑操作只支持 macOS 与 Windows，Linux 上没有电脑操作。机制上它沿着三级优先顺序往下走：有连接器就用连接器，没有就驱动浏览器，直接操作屏幕是最后手段，过程中还会截屏以看懂显示的内容。真正的评估从这里开始。会停下来的地方是设计出来的：电脑操作默认关闭，需要在设置的通用一栏里启用；每遇到一个新应用都会请求许可；永久删除文件需要显式许可；投资与交易平台以及加密货币类应用默认就在禁区之内。但也有不会停下来的地方。已批准应用内部的每一次具体操作都不会跟你确认，官方的措辞是 Claude 直接在你的屏幕上点击、输入和跳转，不经过约束其他 Cowork 工具的那套权限检查。文档还补充说，Claude 与你屏幕上的东西之间不存在沙箱，并且在一个应用里做出的操作可能影响到别的应用。最大的风险是提示注入，Anthropic 自己的说法是：网页内容是提示注入攻击的主要途径；一条被操纵的指令、一条意料之外的命令，或者在你浏览器里打开的一个钓鱼链接，都可能连锁引发难以撤销、甚至无法撤销的操作。Anthropic 表示它会扫描模型的激活值来识别这类行为，但那只是把概率压低，并不能替你省掉自己划一条线，指引里仍然要求凡是碰到敏感文件、账户或站点的任务都切到手动审批。Anthropic 把边界写得很明确：不要把电脑操作的权限授予银行、医疗、政务这类敏感应用，并避免用它处理金融账户、法律文件、医疗信息和个人数据。文章还讨论了手机这一侧。手机丢了，漏出去的不是存在手机里的数据，而是能给你的电脑下命令的资格，以及那段还在继续的对话的内容——而 Dispatch 的官方帮助并没有说明如何解除设备配对或设备丢失后怎么办，所以应对手段来自账户那一侧：在设置的账户一栏的活动会话里终止那一个会话；在 claude.ai 上一次性登出所有会话（这个功能在手机应用里不可用，因此需要网页浏览器）；或者干脆掐掉电脑那一侧，关掉桌面应用或让机器睡眠，这其实是最快的，因为 Dispatch 需要电脑唤醒且应用打开。最后文章把 Dispatch 与电脑操作区分成两个各自独立的开关，把两者都和 Claude Code 的 agent view（官方文档同样称其操作为 dispatch）区分开来，并划出一条实用的界线：从你能收得回来的工作开始。

Claude Code 的 agent view 用 claude agents 打开，是一个让你在后台一个接一个启动彼此独立的会话、并在同一块屏幕上管理它们的功能。官方文档把你在那里执行的操作叫作 dispatch，而桌面应用里恰好还有一个同名的独立功能，所以第一件事就是把两者分清楚。文档把 agent view 描述成让你从一块屏幕上调度并管理多个 Claude Code 会话的功能，它属于研究预览，需要 v2.1.139 及以上版本。本文只谈机制与安全模型。第一个意外之处是：你在输入框里打的每一个提示词，都会启动它自己的一个新会话——再打一条，得到的是旁边多出来的第二个会话，而不是给第一个补的一句话。要追加指令，得走用 Space 打开的预览面板，它显示的是最近的输出或者会话正在等的那个问题，而不是完整记录。安全模型的核心是用 worktree 做隔离。在编辑任何文件之前，后台会话会先搬进 .claude/worktrees/ 下一个隔离的 git worktree，于是并行的会话读的是同一份检出，但各自写进自己的那一份——读是共享的，写是分开的。任何会触及主检出的动作都被三道检查切断：通过 Edit、Write、NotebookEdit 进行的文件编辑；工作目录会解析到主检出、或者无法核实其确实待在外面的命令；以及试图用 git -C、--git-dir、GIT_DIR、GIT_WORK_TREE 或在 git 之前先 cd 来把 git 指向别处的做法。判断刻意偏向安全一侧，核实不了的就不放行，而且同样的保护会被会话派生的每一个子智能体继承。不过它并不是操作系统层面的墙：仓库之外的文件和网络都不在范围内，PowerShell 命令也只享有工作目录那一道检查。权限同样不是在调度时当场选的，而是继承自那个目录的 defaultMode，或者继承自被调度的子智能体 frontmatter 里的 permissionMode——这意味着你平时的配置越松，一次就会造出越多无人看管、权限宽松的会话。随后有三样东西会漏出隔离之外。选了「是，以后别再问我」，这条规则会被存进主检出的 .claude/settings.local.json，于是它在主检出和其他每一个 worktree 里都生效，并且在它诞生的那个 worktree 被删掉之后依然留着。在 agent view 里删除会话，会把 Claude 创建的 worktree 一并删掉，未提交的成果随之消失——而 Ctrl+X 第一下是停止，第二下就是删除。还有 .worktreeinclude，它会把 .env 这类被 gitignore 的文件复制进每一个新 worktree，让你的凭据按调度出去的会话数成倍增加。除此之外，配额是随并行度成比例消耗的（十个智能体大约快十倍），会话跑在本地，能挺过睡眠但机器关机就停。文章最后把 agent view 放回官方给出的四种并行做法里，与子智能体、智能体团队和动态工作流并列，并给出调度之前、进行中和结束之后的一套具体流程。

不少人按 Claude Code 的 /compact 时依据的是「每 30 分钟一次」「上下文超过 70% 就按」这类规则，但官方文档推荐的既不是时钟也不是百分比，而是工作的断点——「在工作的自然断点处运行 /compact，例如在任务与任务之间，而不是等自动压缩在任务中途触发」。本文以 2026 年 8 月 8 日的 Claude Code 官方文档（当时最新版 v2.1.226）为一手资料，从规格出发把「该不该手动压缩」这件事讲透。首先是机制：压缩分三层运转——①丢弃旧的工具输出、②自动压缩、③你按下的手动 /compact。②与③是同一套处理，因此自己按下换来的只有两样东西：挑选时机，以及指定保留什么。按得更勤并不会额外省出上下文。接着用一张表说明什么会留下：项目根目录的 CLAUDE.md 与自动记忆会从磁盘重新注入，而带 paths: 的规则和子目录里的 CLAUDE.md 要等匹配的文件被重新读取才回来，调用过的技能正文则受每个技能 5,000 token、合计 25,000 token 的上限约束，超出部分从旧到新丢弃，截断时保留文件开头。关于费用：一次压缩的价格不由上下文的大小决定，而由提示词缓存是否温热决定——工作中途按，前缀从缓存里读，很便宜；在超过缓存存活时间（订阅套餐 1 小时，API 密钥默认 5 分钟）的休息之后按，则要把整段历史当作未缓存输入重新处理，是这条命令最贵的时刻。此外还涵盖 /compact、/clear、/rewind、/recap、/context 的取舍，v2.1.221 起用 /autocompact 把自动触发点在 100K 到 1M token 之间移动的方法与四个设置来源的优先级，只有环境变量接受纯整数（写成 500k 会被读成 500 并被钳到 100K）这个坑，以及 Not enough messages to compact. 与 Autocompact is thrashing 这两条消息的含义和恢复步骤。

想打开 Windows 版 Claude Desktop，弹出来的却是标题为“无法打开这个应用”的对话框，提示你转到 Claude 的高级选项并选择“修复”——照它说的做就能解决，既不用卸载，也不用那个会把数据一起丢掉的“重置”。不过中间有一道坎，正是本文的核心：点了“修复”之后，可能会收到一条提示说应用还在运行，可明明哪儿都没有开着 Claude 的窗口。原因是 Claude Desktop 在窗口关闭后仍然驻留在系统托盘里，那个常驻进程占着包里的文件，修复自然通不过。解法很简单：先明确地结束进程，再点“修复”。而这个事实本身也指向了故障的成因——同一个进程先弄坏了更新，又挡住了修复。本文还回答了大家最先想问的那个问题：会话会不会被清空？答案分三种。claude.ai 的对话记录存在 Anthropic 的服务器上，完全不受影响；Claude Code 的会话存在 %USERPROFILE%\.claude\projects\ 下，位于应用包之外，所以修复、重置乃至卸载都动不到它（一台实机上是 52 个项目、2,977 个文件、约 3.0GB）；唯一有风险的是 %APPDATA%\Claude 里的应用侧设置，而“修复”连这个也保得住——Windows 就在同一个页面上把区别写清楚了：修复不影响应用的数据，重置会删除应用的数据。此外还涵盖只读的 PowerShell 状态检查、备份流程、仍然打不开时的分级处理（确认 vmcompute 与 hns 是否在运行、用 -PreserveApplicationData 重装）、半注册 MSIX 这一推定成因与相关的 GitHub issue（#55465 安装成功却没有生成入口点，以及 #50285、#48437，全部以 closed as not planned 收场，没有官方修复），降低复发概率的做法，以及与旧版安装程序格式的对比——MSIX 最新版与旧格式实机上的版本号同为 1.24012.9。

Claude Code 回答写到一半停住，屏幕上出现「API Error: Connection closed mid-response. The response above may be incomplete.」——这不是提示词的问题，而是承载流式响应的连接在响应传输途中被关闭的传输层事件。本文只依据官方错误参考、官方 CHANGELOG 与带抓包证据的真实 Issue 进行梳理。先讲官方定义：Connection closed 是被切断、Response stalled 是陷入沉默、Server error 是服务端出错，三者的区别；以及已输出内容为何被「刻意」保留——因为重发可能把同样的工具调用执行两遍——而恢复步骤就是回复 continue。接着拆解断连可能发生的三个层次（本机链路与休眠／代理和 VPN 的空闲断开／服务端主动关闭），并给出 Issue #67766 报告者公开的抓包实测值：十次全部是服务端发起的正常关闭，从 FIN 到报错为 3〜105 毫秒，关闭时已收到 7〜20 KB 响应，请求体 1〜2.5 MB，新建连接约 20 毫秒即成功，23 天内共 200 次报错、171 次事件，其中 87 次距上次通信不到 5 秒。本文实用价值的核心，是 CHANGELOG 中真实存在的连接修复时间线（2.1.179 保留已输出内容、2.1.185 停滞提示由 10 秒改为 20 秒、2.1.198 临时网络中断改为带退避重试、2.1.199 流中服务端错误也保留已输出、2.1.214 陈旧连接错误后停用 keep-alive 池），并与报告版本（#69336＝2.1.173／#69415＝2.1.181／#69517＝2.1.183）对照，指出报告集中区间全都早于 2.1.198。此外还包括易触发条件、八步用户检查清单、六条开发者指引、与 Unable to connect 及 Prompt is too long 的区分，以及「症状与对策已官方文档化，但原因的官方说明尚未给出」的确信度划分。

Anthropic 于 2026 年 7 月 24 日发布 Claude Opus 5，官方文档称其相对 Opus 4.8 是台阶式跃升而非渐进式小改，但价格纹丝不动：每百万 token 输入 $5 / 输出 $25，正好是旗舰 Fable 5（$10 / $50）的一半。本文交叉核对官方公告、官方文档与多家媒体报道，梳理核心规格（claude-opus-5、100 万 token 上下文且默认值即上限、128K 最大输出、知识截止 2026 年 5 月）、含缓存费率与高速模式（约 2.5 倍速度、2 倍价格、仅限 Claude API）的价格结构，以及基准测试成绩：Anthropic 在正文中明确写出 Frontier-Bench 超过 Opus 4.8 的两倍、CursorBench 3.2 与 Fable 5 相差 0.5% 以内、ARC-AGI 3 是第二名的三倍、OSWorld 2.0 以约三分之一成本超过 Fable 5；媒体从图表读取的数值则包括 Frontier-Bench 43.3%、ARC-AGI-3 30.2%、GDPval-AA 1,861 与 OSWorld 70.6%。同时也不回避短板：DeepSWE v1.1 上 68.8% 落后于 GPT-5.6 Sol 的 72.7%，攻击性安全与长周期生物学研究仍由 Mythos 5 领先，而且存在 max effort 得分反而低于低档位的情况。随后详解两处 API 破坏性变更（思考默认开启，导致卡得过紧的 max_tokens 被截断；关闭思考仅在 effort 为 high 及以下时允许，xhigh 或 max 会返回 400），五档 effort 的选择方法，对话中途变更工具、512 token 缓存下限、default 回退模式等新功能，以及回答变长、汇报变多、更愿意分派子智能体、不用催就自我验证的性格变化——迁移的要诀是删提示词而不是加提示词——最后给出谁该立刻迁移的判断标准与六步迁移检查清单。

你打开 Hugging Face 想跑本地 LLM，同一个模型却挂着一整墙文件（Q4_K_M、Q5_K_S、GPTQ、AWQ、IQ3_M），然后就懵了。本文实打实回答：到底该下载哪个量化文件才能把它跑起来，把「什么是量化」的概念留给另一篇，专注于选择格式。选择分两步：先选格式（= 用哪个引擎跑），再选位深。最重要的事实是：量化文件只能在支持其格式的引擎上运行。GGUF 是唯一「本地全能」的格式，能在 CPU、Mac 和部分 GPU 上跑（llama.cpp/Ollama）；GPTQ/AWQ/EXL2 以 GPU 为先（vLLM/TGI）；bitsandbytes 在 Transformers 里加载时量化、无需校准。GGUF 命名 Q4_K_M 分三部分：Q4（名义 4-bit，越大越好也越大）、K（在超级块上做的 K-quant；无后缀/_0/_1 是旧式）、M（S/M/L 表示有多少重要张量被升级；有效比特高于标签值，Q4_K 约 4.5 bpw）。IQ 家族（I-quants）在相同位深下更小，但推理更吃力、需要 imatrix（来自校准的重要性矩阵，优先保护关键权重）。GPTQ 最小化逐层误差；AWQ 通过激活值保护关键权重（没有谁绝对更好）。位深上，拿不准就选 Q4_K_M（许多模型的 Ollama 默认值），VRAM 有富余升到 Q5_K_M/Q6_K，Q8_0 近乎无损但不推荐，IQ2/IQ3 只用于硬塞大模型。约 4.5 到 5 bpw 是好吃区间（一个启发式）。找文件可用 library=gguf、bartowski/mradermacher（活跃度会变），或 Ollama 标签 model:size-variant-quant。数字是近似值，会因模型和构建方式而异。

当「问 AI 就行」「让 AI 全部写出来」成为默认时，反过来的问题才更有锋芒：这真的是该用 AI 的场合吗？本文并不是反 AI；它讲的是把「不用它」保留为一个选项，正是为了让你能最大限度发挥 AI 的价值。AI 不是默认要用的东西，而是有意去选择的工具，善用它和选择不用它是一对搭档。六种跳过它反而更好的情形：1. 打基础的学习（以写来思考的过程本身就是目标），2. 输入机密或个人数据（未确认条款和数据保留政策前不要粘贴），3. 出错即致命的最终决断（医疗、法律、安全、金钱不应未经验证就交出去），4. 不值得成本的轻量任务，5. 以人的信任或创造力为核心的工作（道歉、招聘、作者身份），6. 不想再增加单点故障时（业务连续性）。用三个问题快速决定：你能自己验证输出吗、是否只涉及可以分享的数据、这个过程是你现在应该训练的吗。如果能验证、数据可分享、且不需要训练，就用 AI；否则就跳过它，或插入一道人工核查。过度使用的弊端（认知卸载、接受听起来合理的错误、依赖）只作为讨论要点提出，而非确切的数字。刻意跳过 AI 不是刹车，而是让你能在它合适之处全力以赴的另一面技能，也是对过度依赖 AI 的一道对冲。

刚更新完 Claude Desktop（Windows）后启动应用，会弹出"另一个程序正在使用此文件"，应用无法启动——而且在重启电脑之前一直无法修复。这是 Microsoft Store（MSIX）版上的一个已知缺陷（GitHub #53247 等）。关键点：并不一定需要完全重启电脑——很多情况下只要注销 Windows 再重新登录即可恢复（不是重启电脑，也不是退出 Claude 的登录），因为背后的孤立句柄是按 Windows 用户会话为单位残留的。有报告称停掉 CoworkVMService 或重新注册软件包均无效。尽管对话框如此措辞，但已验证不存在用户空间的文件锁（handle.exe / Process Explorer）：真正的失败发生在 AppX/Desktop Bridge 的容器层，即 Job Object → Silo 的转换（0x80070020 = ERROR_SHARING_VIOLATION，事件 215/208）。触发原因有两种尚无定论的解释——服务占用 Job Object（#57221）与启动时崩溃导致清理未执行（#53247）——且官方尚未发布修复。长久的变通办法是改用 Squirrel（安装程序）版。本文基于一台实机（Windows 11 Home 10.0.26200）并与 GitHub issue 相互印证，全文附有置信度标签。

Claude Code 长时间工作时，应答突然反复输出「court」几十到数百次，最后打出「API Error: Response stalled mid-stream. The response above may be incomplete.」而停下。这并非提示词或环境的错误，而是两个独立缺陷连锁触发：①模型不断吐出同一 token 的重复循环（退化），②因此产生的海量输出或连接问题导致的流停止。两者都是 Anthropic 官方仓库有多条 Issue 记录的已知 bug（court 重复带 area:model 标签）。本文基于官方文档与真实 Issue，梳理两层现象的真相、诱发条件、当下止损（Esc → 新会话 / /clear）、面向开发者的预防（读取超时、重复检测、max_tokens 上限），以及与 court/invoke 标签泄漏 bug 的区分。

深度对比 OpenAI 最高端 GPT-5.6 Sol（7月9日）与 Anthropic 定位为"面向公众发布的史上最强"的 Claude Fable 5（6月9日）。与 Opus 4.8 那种同价位段的正面对决不同，这一次的主题是"半价全能型 Sol（$5/$30）"对"贵一倍但为顶级的 Fable 5（$10/$50）"这一成本与实力的权衡。在生产级实战编码的 SWE-Bench Pro 上，Fable 5 以80.3%把 Sol 的64.6%（估算）甩开15pt以上，差距比对阵 Opus 4.8 时更大。此外 Fable 5 能专注于数百万 token 连续自主运行最长12小时，Stripe 在一天内完成5000万行 Ruby 迁移的"完赛能力"是其看家本领。另一方面，Sol 在终端操作的 TerminalBench 2.1（88.8% vs Fable 86.0%）、Agents' Last Exam（53.6 vs 40.5）、Coding Agent Index（80 vs 77.2）上居首位，且凭半价＋token 效率+54%在性价比上更强。本文将从规格速览表、基准详情、OpenAI 未公布 Sol 的 SWE-bench Pro 的"未公开基准问题"、长时间自主、实际成本（以每完成一项任务来看）、强项弱项地图，到按使用场景的选择方法，基于官方与独立基准逐一梳理。

对 2026 年两大 AI 编程巨头的深度对比：Claude Opus 4.8（5 月 28 日）与 GPT-5.6 的最高端 Sol（7 月 9 日）。两者擅长领域几乎相反：Sol 在终端操作与智能体综合能力上领先（TerminalBench 2.1 88.8% vs Opus 78.9%、Agents' Last Exam 53.6、Coding Agent Index 80），而 Opus 4.8 在生产级编程、数学与长上下文上领先（SWE-bench Pro 69.2% vs Sol 64.6%、USAMO 2026 96.7%、GraphWalks 1M 68.1%），并突出诚实性（过度自信降至十分之一、无批判报告缺陷结果 0%）。此外 OpenAI 大量未公布 Sol 的基准（SWE-bench Pro、GPQA、AIME、MMLU），因此在编程的核心阵地上，已披露的 Opus 更占优势。本文涵盖规格速览表、基准详细、未公开基准问题、实际成本（$25 vs $30 单价与 +54% token 效率）、优势/劣势地图、按场景选择，以及双供应商策略。