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 这五种并行方式之间该怎么选。
新模型更聪明但也更贵——一般都会这么想。可是在 GPT-6 Astra 和 GPT-5.6 Sol 的比较里，只看单价是得不出答案的，因为 Astra 用更少的token就能把同样的活干完。第三方机构 Artificial Analysis 的实测显示，把 Astra 开到最弱的 low，每个任务的费用和把 Sol 开到 high 时几乎相同（$0.82 对 $0.81），分数还更高（46 对 42），输出token只有三分之一，回复开始之前的等待时间只有四分之一。本文以2026年9月18日时点的实测值为依据，整理按推理强度划分的费用、token和速度，为什么单价2.5倍而总额仍会打平的明细，Sol 的促销价结束之后的试算，在编程智能体作业上价格差距会缩小这一点，以及拿自己的工作去测量的步骤。
只把制定计划的部分交给聪明的模型，实现交给又快又便宜的模型。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。
在 Gemini 中发送消息后，显示“发生错误 (13)”“Something went wrong(13)”并卡住——对于这个错误的原因，Google 没有在官方帮助中说明。不过，2026年5月的官方故障报告中有这条提示持续出现约4天的记录，原因是数据库资源不足与应用缺陷，临时解决方法为“无”。本文结合这份官方记录，以及编号“13”与 gRPC 的内部错误（INTERNAL）一致这一点（Google 并未明确表示两者含义相同），整理官方社区中常见的4种情形——所有人同时出现、只有长对话、只在附加图片时、只有特定账号。在此基础上，从确认故障信息、接续到新对话、换账号确认，到通过反馈报告，按省事程度给出7步排查顺序。