Claude Code：别再给Claude过多提示词了...

机器之心编辑部

模型能力在变化，使用它的方法也需要跟着更新。

最近，Anthropic Claude Code 团队成员、谷歌前工程总监 Addy Osmani 发了一篇长文，谈到一个许多用户可能都有的习惯：给 Claude 写了太多提示和指令。

文章标题就开宗明义：你大概率一直在「过度提示」Claude。随着新一代模型能力提升，过去那套事事交代、逐步指导的使用方式，也到了重新调整的时候。

• 原文链接：https://x.com/addyosmani/status/2115688494865465370

使用 Opus 5.5 时，Osmani 建议先尝试一种简单的方式：用一条提示说清楚想完成什么，以及 Claude 应该如何检查自己是否完成了任务，然后放手让它去做。推理强度可以从 /effort medium 开始，再根据实际情况调整。

如果用户自己还没想清楚需求，可以先让 Claude 不断提问，直到它掌握的信息足以写出一份需求说明，再新开一个会话，照着这份说明开展工作。

其中，验收标准值得多花些心思。Claude 认为任务结束后，会自行停下来；如果它能够运行检查，用「通过或不通过」来判断结果，或者围绕某个明确的数值目标进行验证，并且能读懂检查报告，就可以根据结果继续修改和检查。

有了可执行的验收标准，模型才能更独立地推进任务，用户也能减少中途介入。对于需要长时间在后台运行的任务，还可以用 /goal 设定条件，由另一个模型在每轮结束后检查是否达成。

至于用户在过程中何时介入，沃顿商学院的管理学副教授 Ethan Mollick 补充了一个建议：在任务中设置阶段性检查点（checkpoint），让模型汇报初步想法或展示原型。

那么提示词可以精简到什么程度？

Osmani 在文中提到，针对 Claude Opus 5 和 Claude Fable 5 等模型，Claude Code 曾删掉超过 80% 的系统提示词，其编程评测表现没有出现可测量的下降。他也建议用户在新模型发布后，拿自己的指令做一次类似实验：先删掉一部分，看看模型在哪些地方遗漏了要求，再把相关指令补回来，/doctor prompt-audit 命令可以帮助找出那些针对旧模型编写的提示。

简而言之，提示词也需要定期清理，长期积累下来的规则可以重新验证一遍。

类似的调整也适用于子智能体，Claude 已经会自行分派工作，通常可以让它自己安排。遇到全面审查、代码迁移这类工作量大、能够独立开展的任务时，再明确要求它拆分并行处理。对于小任务，调用多个子智能体会增加成本和等待时间，因此仍需要看任务本身是否值得拆分。

在 Osmani 看来，子智能体适合并行处理任务、提供第二意见，使用数量需要与任务规模相匹配。根据他的观察，用户自行搭建智能体时，一个配备合适技能的智能体，就可能取得更好的结果，而且成本更低、响应更快。

如果希望合上电脑后任务还能继续，Osmani 推荐使用 Claude 云端会话。用户可以从 claude.ai/code、Claude 应用，或者通过 claude --cloud 启动。云端会话会在独立虚拟机中重新克隆代码仓库，所以开始前需要先把本地提交推送到远端。之后可以用手机查看进展、回答会话中提出的问题，最后检查代码差异并创建 PR。需要用到本机专属资源的任务，则继续留在本地执行。

进一步同时运行多个会话时，管理工作也会随之增加：每个会话在做什么，哪些已经完成，哪些还在等回复，都需要跟踪。因此，Osmani 建议，先让一个会话能够独立完成任务，再考虑同时运行多个会话。如果每项工作都需要频繁介入，多开会话也会增加用户来回切换和协调的时间。

Claude Code 的 Projects 功能，承担了其中一部分管理工作。一个项目相当于一段长期持续的对话，用户可以把陆续出现的问题和任务贴进去，Claude 会为每项工作创建独立线程，通常通过云端会话并行处理。用户交代过的项目要求，会应用到之后的新线程；Overview 总览页则集中展示任务进度、可以审查的 PR，以及等待用户回应的事项。按照文章的介绍，Projects 当时正在面向 Pro 和 Max 用户公开测试。

随着更多执行工作交给模型，用户需要把注意力放到结果核验上。近期版本的 Claude Code 已将自动模式设为交互式终端会话的默认启动方式，由分类器评估 Claude 的操作。Osmani 提醒，自动模式仍有局限，逐次批准权限提示也需要认真判断。他给出的建议是，Claude 汇报完成时，让它展示执行过的命令和输出，或者提供截图，方便核对实际结果。

代码审查也可以先让 Claude 跑一轮。Osmani 透露，在 Claude Code 团队，多数改动都会先由 Claude 至少审查并修正一次，再交给人工查看。用户可以使用 Team 和 Enterprise 套餐中的 Code Review，也可以用更轻量的 /code-review，让一个没看过当前对话的子智能体检查代码差异。另开一个会话、提供需求说明，同样可以获得一次独立审查，审查时可以要求它重点关注需求和功能，把代码风格放在次要位置。

文章最后，Osmani 建议用户每隔几个月，就重新检查一次自己的工作方式：哪些提示已经可以精简，哪些任务能够交给模型独立完成，哪些结果仍需要人工核验。