Anthropic Claude Code 团队成员、谷歌前工程总监 Addy Osmani 近日发文称，很多用户在使用 Claude 时，仍保留着一套旧习惯：给模型写过多提示和指令。按他的说法，随着新一代模型能力提升，过去那种事事交代、逐步指导的使用方式，已经需要重新调整。
他在文章标题中直接写道，用户大概率一直在「过度提示」Claude。核心观点很明确：模型能力在变化，使用方法也要跟着变。
先把目标和验收标准说清，再让模型自己推进
Osmani 提到，使用 Opus 5.5 时，可以先尝试更简单的方式：用一条提示说明想完成什么，以及 Claude 应该如何检查自己是否完成任务，然后放手让它执行。推理强度可以从 /effort medium 开始，再根据实际情况调整。
如果用户自己还没有想清楚需求，他建议先让 Claude 持续提问，直到掌握足够信息，能够写出一份需求说明。随后再新开一个会话，按照这份说明开展工作。
在这套方法里，验收标准是重点。Claude 判断任务结束后会自行停下；如果它能够运行检查，用「通过或不通过」判断结果，或者围绕明确的数值目标做验证，并且能读懂检查报告，它就可以根据结果继续修改并再次检查。
Osmani 的意思是，只有验收标准具备可执行性，模型才更容易独立推进任务，用户中途介入的次数也会减少。对于需要长时间在后台运行的任务，还可以通过 /goal 设定条件，由另一个模型在每轮结束后检查是否达成。
关于用户应该在流程中何时介入，沃顿商学院管理学副教授 Ethan Mollick 也给出补充建议：在任务中设置阶段性检查点，让模型汇报初步想法或展示原型。
Claude Code曾删掉超过80%系统提示词
Osmani 在文中写道，针对 Claude Opus 5 和 Claude Fable 5 等模型，Claude Code 曾删掉超过 80% 的系统提示词，而编程评测表现没有出现可测量的下降。
他也建议用户在新模型发布后，对自己的指令做一次类似实验：先删掉一部分，观察模型在哪些地方遗漏了要求，再把相关指令补回来。/doctor prompt-audit 命令可以帮助找出那些针对旧模型编写的提示。
按他的总结，提示词本身也需要定期清理，长期积累下来的规则可以重新验证一遍。
子智能体不必默认多开，先看任务值不值得拆
Osmani 认为，类似的调整也适用于子智能体。Claude 已经会自行分派工作，通常可以让它自己安排。只有在全面审查、代码迁移这类工作量大、又能独立开展的任务中，再明确要求它拆分并行处理。
对于小任务，调用多个子智能体会增加成本和等待时间，因此是否拆分，仍要看任务本身是否值得。
在他的观察里，子智能体更适合并行处理任务和提供第二意见，数量需要与任务规模匹配。用户如果自行搭建智能体，一个配备合适技能的智能体，反而可能拿到更好的结果，同时成本更低、响应更快。
云端会话适合离开电脑后继续跑任务
如果希望合上电脑后任务还能继续，Osmani 推荐使用 Claude 云端会话。用户可以从 claude.ai/code、Claude 应用，或者通过 claude --cloud 启动。
他提到，云端会话会在独立虚拟机中重新克隆代码仓库，因此开始前需要先把本地提交推送到远端。之后，用户可以用手机查看进展、回答会话中提出的问题，最后检查代码差异并创建 PR。需要依赖本机专属资源的任务，则继续留在本地执行。
如果要同时运行多个会话，管理成本也会随之上升：每个会话在做什么、哪些已经完成、哪些还在等待回复，都需要持续跟踪。Osmani 的建议是，先让一个会话能够独立完成任务，再考虑同时运行多个会话。要是每项工作都需要频繁介入，多开会话只会增加来回切换和协调时间。
Projects负责长期对话和任务总览
Claude Code 的 Projects 功能承担了部分管理工作。按文章介绍，一个项目相当于一段长期持续的对话，用户可以把陆续出现的问题和任务放进去，Claude 会为每项工作创建独立线程，通常通过云端会话并行处理。
用户此前交代过的项目要求，会应用到之后的新线程。Overview 总览页则集中展示任务进度、可以审查的 PR，以及等待用户回应的事项。根据文章说法，Projects 当时正在面向 Pro 和 Max 用户公开测试。
把更多精力放在核验结果和代码审查
Osmani 认为，随着更多执行工作交给模型，用户需要把注意力转向结果核验。近期版本的 Claude Code 已将自动模式设为交互式终端会话的默认启动方式，由分类器评估 Claude 的操作。
不过他也提醒，自动模式仍有局限，逐次批准权限提示时也需要认真判断。他给出的做法是，当 Claude 汇报完成时，让它展示执行过的命令和输出，或者提供截图，方便核对实际结果。
代码审查同样可以先交给 Claude 跑一轮。Osmani 透露，在 Claude Code 团队内部，多数改动都会先由 Claude 至少审查并修正一次，再交给人工查看。用户可以使用 Team 和 Enterprise 套餐中的 Code Review，也可以使用更轻量的 /code-review，让一个没有看过当前对话的子智能体检查代码差异。
他还提到，另开一个会话并提供需求说明，也可以获得一次独立审查；审查时可以要求它优先关注需求和功能，把代码风格放在次要位置。
每隔几个月重新检查一次工作方式
在文章最后，Osmani 建议用户每隔几个月就重新检查一次自己的工作方式：哪些提示已经可以精简，哪些任务能够交给模型独立完成，哪些结果仍需要人工核验。
本文来自微信公众号「机器之心」（ID：almosthuman2014），作者署名为「关注大模型的」。
