删掉「仔细思考」，长任务交给 Claude Opus 5.5 怎么跑？

▲ ClaudeDevs 发布 Opus 5.5 使用手册的帖子

最近 Anthropic 发布了一份 Opus 5.5 使用手册，标题是《Getting the most out of Opus 5.5 in Claude and Claude Code》。手册里有一条建议挺有意思：把提示词里的「仔细思考」删掉。

按手册的说法，Opus 5.5 每次回复前本来就会思考，没必要再叮嘱一遍。除了提示词怎么写，手册还聊了几个实际场景：长任务怎么交给 Claude、干到一半频繁停下怎么办、最后交上来的东西怎么检查。

核心思路很直接——把整个任务完整交出去，说清「做到什么程度算完成」和「什么时候需要来问你」；少写「仔细思考」这类叮嘱；长任务结束后，先看哪些事还在等你处理。

▲ 长任务的三个协作阶段

一、需求到底怎么说，Claude 才好干活？

假设你要把项目里的旧短信 SDK 换掉，只说一句「帮我升级一下」够吗？改完依赖版本算不算完成？所有发送入口都要改吗？历史调用方式还要不要兼容？这些都不说，模型只能边做边猜。

需求可以写得更具体一些：

把项目中的短信发送功能迁移到新版 SDK。
所有发送入口都要完成迁移，清理旧依赖，现有测试通过。
如果新版无法兼容现有业务行为，先说明差异，等我决定。

这版需求交代了任务范围、完成标准、需要你介入的情况。接下来查哪些文件、先改哪个入口，交给 Claude Code 根据仓库实际情况判断就行。

「完成」最好是能检查的，别只写一个「做好」。否则它觉得依赖升完了，你觉得业务还没验过，两边理解的「完成」根本不是一回事。

▲ 短信 SDK 迁移提示词的三个要素

需求写完，你是不是还想在结尾补一句「请仔细思考」？以前写 prompt，好像不加这句心里就没底。

Opus 5.5 已经会先思考再回答。官方在聊天产品里试过，去掉这类叮嘱后，回复能更早开始，质量也没有明显下降。你的任务会不会有变化？删掉之后对照着试一轮就知道了。

保存下来的固定指令也顺手翻一遍。比如 CLAUDE.md 里如果还留着「仔细思考」「一步一步想」这类内容，一起清理掉，别只改眼前这一条。

那复杂问题还是想让模型多想一会儿怎么办？在 Claude Code 里，可以通过 effort 设置调整模型在思考上投入的精力。简单问题想快点拿到答案，直接说「直接回答」就行。

▲ 删除思考叮嘱，按需调整 effort

需求发出去了，才想起漏说一件事怎么办？比如代码已经改到一半，你突然想起老的调用方式还得兼容。

可以在 Claude Code 执行过程中直接输入补充要求并按回车。任务越长，重新开一轮的成本越高。发现遗漏就及时补充，没必要憋到交卷才指出来。

让 Claude 做页面时，要求也得具体。光说「别太模板化」，结果可能只是换了套配色，熟悉的味道还是扑面而来。

手册建议直接把不喜欢的具体样式点出来。比如「不用米白背景，标题不要斜体强调词，按钮不要全做成胶囊形」。出了第一版，再针对实际效果追加要求。

「高级一点」留给模型的想象空间太大了。把看不顺眼的地方说清楚，后续才好改。

▲ 把不喜欢的页面样式指出来

二、长任务，怎么避免干一半就停？

需求交代清楚了，Claude 干到一半，突然给你一段汇报，结尾来一句「接下来可以修改剩余文件，需要我继续吗？」活还没干完，当然是继续啊。

如果经常碰到这种停顿，可以把工作规矩写进 CLAUDE.md。结合手册建议和你的项目情况，写成类似这样：

范围内还有能推进的工作，就继续执行，汇报进度时也接着做下一步。
确实缺少我的决定或资料，导致无法推进时，再停下来说明。
删除数据、强推代码、修改仓库之外的内容之前，先征求确认。

你可能会想：干脆加一句「没做完就别停」，不就省事了？普通的查文件、改代码，可以继续往下做。但下一步要是准备删除数据、强推代码呢？这种时候你大概还是希望 Claude 先问一句。所以，该继续的事和该停的事，要一起讲清楚。危险操作的权限确认也得保留，提示词里的约定不能代替权限设置。

▲ 长任务何时继续，何时暂停

如果只是停下来问「要不要继续」，回一句「继续」就行。经常这样的话，就要搞清楚 Claude Code 为什么停。确实缺信息，就把信息补上；只是汇报进度，就在 CLAUDE.md 里说明汇报完继续做，不用每次都等点头。

喜欢边看边改的话，也可以换个约定：让 Claude Code 动手前先用一句话说说计划，做完后再简短回顾。这种偏好同样写进 CLAUDE.md 就好。

遇到要同时排查多个服务的任务，可以让主 Agent 把工作拆给几个子 Agent。比如订单、库存、支付各分一个，分别查完再汇总结果。

几个子 Agent 都查完了，也都说「没问题」，就能放心了吗？先看看这个「没问题」是怎么得出来的。每个 Agent 查了哪些代码、依据是什么，都得交代清楚，主 Agent 收到结果后也要核查。否则你只是多收到几份结论，真要追问哪里查过了，还是说不清。

比如你怀疑几个服务都有重试次数失控的问题，明明设置最多重试三次，实际却一直在发同一个请求，就可以让子 Agent 分别去查：

订单、库存、支付服务各分给一个子 Agent，检查请求失败后的重试次数是否超过配置上限。
每个结果附上重试上限、调用路径和触发条件，找不到证据就明确说明。
你核对结果后，再汇总成表，列出服务、是否受影响及依据。

▲ 子 Agent 分工后由主 Agent 核查证据

任务和进度，聊天记录里不是都有吗？为什么还要专门写一份 TASKS.md？

问题在于，长任务跑起来以后，对话里会不断塞进代码、日志和工具结果。上下文接近上限时，旧内容会被压缩，最早交代的细节就可能不再完整。

所以可以让 Claude Code 把待办写进 TASKS.md，完成一项就更新，发现新问题也补进去。继续往下做之前，先让它读一遍这份清单，确认哪些已经做完、哪些还没动、哪些在等你决定。你想检查进度时，也不用再翻几十屏聊天记录。

▲ 用 TASKS.md 保存并更新任务进度

三、Claude 说做完了，你先看什么？

跑了很久，终于交来一份汇报。你是不是习惯先看「完成了哪些工作」？

不妨先找找有没有什么事还在等你决定。比如缺一份资料，或者有个方案需要你拍板。这些问题要是藏在长篇总结的末尾，你看了半天，才发现接下来该自己接手了。

可以把汇报格式也写进 CLAUDE.md，约定每次结束时分成「待你处理」「已完成」「新发现」三部分。把需要你处理的事理清楚，再检查 Claude 交上来的结果靠不靠谱。

▲ 汇报先看待你处理，再看已完成和新发现

比如代码改完了，还得检查有没有带出新的问题。可以让 Claude Code 先审一轮，再交给人看。提示词可以这样写：

对照 main 分支，审查当前分支的代码变更。
只列出你认为必须修复后才能合并的问题。
每条写清文件名和行号、什么情况下会出错、原因是什么，以及怎样复现。

「这段可能有问题」还不够，得给出能查下去的具体线索。

▲ 代码审查要给出位置、触发条件和验证方法

交上来的是调研报告时，道理也一样。哪些结论有依据，哪些还没查实，报告里要分开写；没查实的再说明已经找过哪里。这样你才能分清哪些可以采用，哪些还得补查。报告排得再漂亮，一个没确认的关键数字，也足够让后面的判断跟着跑偏。

四、在 Claude 应用里，怎么用得更顺手？

如果你主要在 Claude 网页端、桌面端里聊天，下面几条也值得试试。先看一眼模型选择器，确认选的是 Opus 5.5。

看架构图、报表或截图，直接把原图发过去再问具体问题。比如「哪些服务直接调用了支付接口」，比自己把方框、箭头描述一遍省事，也保留了位置关系。这一代对图表细节和位置关系的理解有所改进，图里的箭头连着谁、哪个数字属于哪一栏，都可以直接问 Claude。

图表之外，长文档也可以交给它检查。比如一份方案改了几轮，前面写项目 10 月上线，最后一页还留着 9 月。自己从头翻一遍，真不一定能发现。

提要求时就说清楚，要查日期、数字、名称有没有前后打架。发现问题后，把有矛盾的原句摘出来，再标上段落或页码。这样你拿着原句就能回去核对，比一句「帮我看看」更有着落。

▲ 检查长文档里前后矛盾的上线日期

看完现有材料，还想整理一份表格发给同事？那就明确说要一份文件，把文件格式、列名和每行代表什么说清楚。比如把项目清单整理成 Excel，按负责人和截止日期排列，交付后你就能直接打开检查。

聊得久了，Opus 5.5 有时会重新琢磨前面已经回答过的问题，后续回复因此变慢。如果只是日常跟进，可以在 Claude 项目的指令里加上这段约定：

已经回答清楚的问题，先沿用之前的答案。
优先处理我当前的问题，除非我再次问起或指出问题，否则不用重新分析旧答案。

不过你可能也想到了：后面找到了新材料，发现前面判断错了，难道也不回头看？这种情况当然得复查。所以正在做长篇分析时，先别加这条约定。新材料可能改变前面的判断，这时回头检查，才是在把问题想完整。

▲ 日常跟进和长篇分析采用不同的回查方式

五、聊着聊着，怎么换模型了？

你明明选的是 Opus 5.5，聊着聊着，怎么变成旧模型了？

有些内容触发安全检查后，可能会切换模型，正常请求也有可能被误判。手册明确说，查找源码里的安全漏洞是允许的，日常健康和教育问题也应当能正常处理。而且检查范围不只有你刚发的那句话，前面的消息、文件和搜索结果也算。所以别光盯着最后一句找原因。

在 Claude 应用里，看到「Switched to」和旧模型名称，就说明发生了切换，后续对话也会继续用那个模型。

那在模型选择器里选回 Opus 5.5，不就好了？可以重新选，但还有个地方容易忽略：之前触发安全检查的内容可能还留在这段对话里，切回去以后很可能再次遇到模型切换。如果你认为正常请求被误判了，可以试着新开一个对话再提出需求。

▲ 切回模型不会清空旧对话，仍可能再次触发切换

如果希望换模型前先征求你的意见，可以到 Settings → Capabilities，关闭「Switch models when a message is flagged」。这样遇到原本会自动换模型的情况，对话会先暂停，让你决定接下来怎么办。

在 Claude Code 里，想切回模型就用 /model；修改上一条消息连按两次 Esc。自动切换的偏好可以到 /config 里调整；如果觉得这次是误判，再用 /feedback 反馈。

▲ Claude 应用和 Claude Code 的模型设置入口对照

手册在这里还提到，要求模型逐字公开内部思考过程，也可能触发安全标记或被拒绝。如果提示词或保存的指令里有这类要求，也顺手删掉。

那我想知道 Claude 为什么选了这个方案，还能问吗？当然可以。直接问取舍和证据，比如「这个方案比另外一个好在哪里，你的判断依据是什么」。

六、等回复太慢，能不能快一点？

如果你正在 Claude Code 里来回调代码，每轮都坐在屏幕前等回复，可以试试 /fast。

看到「快速模式」，你可能先想到：是不是换了个更轻量的模型？手册说，用的还是同一个模型。不过速度快了，费用也会更高。目前这个功能处于研究预览，需要开启「额外用量」，同样的 token，用快速模式会更贵。

值不值得开？你一直在旁边等着，少等一会儿可能就值；任务交出去以后本来就要去忙别的，那也不用急着开。

▲ 快速模式使用同一模型，响应更快但费用更高

最后：一份使用检查清单

下次开长任务前，可以顺手过一遍：

• 提需求：写清完成标准，清理提示词和固定指令里多余的思考叮嘱，图表直接附上，设计偏好说具体。
• 跑任务：约定继续和暂停的条件，保留危险操作确认，大任务按需分工，清单及时更新。
• 看结果：先处理等你决定的事，再看审查证据和未确认的信息。
• 看设置：知道当前用了哪个模型，按自己的习惯设置自动切换。

▲ 开始长任务前的四项检查清单

看完先别急着收藏吃灰，找一个最近让你反复催「继续」的任务试试。把怎样算做完、什么情况需要停下来问你补清楚，再跑一轮。最后看看，中途少了几次无意义的停顿，交上来的结果是不是更容易检查。哪条建议对你有用，拿自己的任务试过，比记住整份手册更有感觉。

参考：Anthropic 官方博客 Getting the most out of Opus 5.5 in Claude and Claude Code