JeecgBoot AI专题研究 | 从提需求、跑任务到验收结果，拆解 Anthropic 官方 Opus 5.5 使用手册里最值得照做的协作习惯
写在前面：为什么一份"使用手册"值得逐条读
新模型发布，大家最先关心的往往是跑分；但真正决定日常体验的，常常是"怎么跟它配合"。Anthropic 官方开发者账号近期发布了一份 Playbook——《Getting the most out of Opus 5.5 in Claude and Claude Code》，篇幅不长，却把很多人每天都会碰到的别扭之处讲得很透：
官方给出的三句话可以当作全文提纲：
- 把完整任务交出去，说清楚什么叫"做完"，以及什么时候该回来找你；
- 把"仔细思考（think carefully）"这类叮嘱删掉，模型本来就会先想再答；
- 长任务跑完后，先看还有哪些事在等你处理。
我们团队在 JeecgBoot 低代码项目里日常用 Claude Code 做代码迁移、批量改造和代码审查，下面结合这份手册和实际踩过的坑，按"开工前 → 执行中 → 收工后 → 环境设置"的顺序重新梳理一遍。
开工前：需求写成"可验收"的样子
一句"帮我升级一下"，模型只能边做边猜
设想一个很常见的场景：项目里的短信 SDK 要换成新版本。如果只丢一句"帮我升级一下"，那么改完依赖版本算不算完？所有发送入口都要动吗？老的调用方式要不要兼容？这些问题你没说，模型就只能靠猜，而猜错的代价往往要等到联调时才暴露。
手册推荐的写法，是在一段话里同时交代任务范围、完成标准和暂停条件：
把项目中的短信发送功能迁移到新版 SDK。
所有发送入口都要完成迁移，清理旧依赖，现有测试通过。
如果新版无法兼容现有业务行为，先说明差异，等我决定。
注意这段需求里没有规定先查哪个文件、先改哪个入口——这些交给 Claude Code 结合仓库结构自己判断。人负责定义"终点"和"红线"，路径让模型去规划，这是分工最顺的方式。
一个实用的自检标准是："完成"必须能被检查。"测试通过""旧依赖清理干净"可以验证，"做好""弄完善"则不行。否则模型以为依赖升完就收工，你却认为业务还没验，双方说的根本不是一件事。
给提示词"瘦身"：删掉"请仔细思考"
很多人写 prompt 有个肌肉记忆——结尾补一句"请仔细思考""一步一步想"，好像不加就不放心。手册的说法很明确：Opus 5.5 每次回复前本来就会思考，再叮嘱一遍属于多余。官方在聊天产品里做过对比，去掉这类话之后，回复能更早开始输出，质量没有明显下降。
这里有两个容易遗漏的地方：
- 固定指令也要清理。除了眼前这条 prompt，
CLAUDE.md、项目指令、团队共享的提示词模板里，很可能也残留着"仔细思考"之类的旧习惯，建议一次性翻一遍。 - 想让它多想，就调 effort。真遇到复杂问题，在 Claude Code 里通过 effort 设置调整模型投入思考的力度；反过来，简单问题想快点拿结果，直接说"直接回答"即可。
实践建议：清理前后各拿两三个你自己的典型任务跑一轮对照，比单纯相信结论更踏实——不同任务的敏感度并不一样。
做页面时，把"不喜欢"具体化
让 AI 做前端页面，最常见的反馈是"太模板化了"。可如果你只说"别太模板化""高级一点"，结果大概率只是换了一套配色，那股熟悉的 AI 味儿依旧扑面而来。
手册的建议是直接点名你不想要的样式，例如："不用米白背景，标题不要斜体强调词，按钮不要全做成胶囊形。"先出第一版，再针对实际效果追加要求。模糊的审美词留给模型的猜测空间太大，而具体的"负面清单"几乎一次就能生效。
执行中：让长任务不半途"等你点头"
把"何时继续、何时停"写进 CLAUDE.md
长任务最让人抓狂的场景是：Claude 干到一半，汇报一大段进度，结尾问一句"接下来可以修改剩余文件，需要我继续吗？"——当然要继续，活还没干完呢。
如果你经常碰到这种停顿，手册建议把工作规矩沉淀到 CLAUDE.md 里，结合项目情况写成类似这样：
范围内还有能推进的工作，就继续执行，汇报进度时也接着做下一步。
确实缺少我的决定或资料，导致无法推进时，再停下来说明。
删除数据、强推代码、修改仓库之外的内容之前，先征求确认。
为什么不干脆写一句"没做完就别停"？因为该继续的事和该停的事必须一起讲清楚。查文件、改代码可以一路往前推，但删除数据、强推代码这类不可逆操作，你肯定还是希望它先问一句。另外要强调：提示词里的约定不能替代权限设置，危险操作的权限确认在工具层面也要保留。
如果模型只是礼貌性地问"要不要继续"，回一句"继续"就行；但如果频繁出现，就值得排查原因：缺信息就补信息，只是汇报习惯就在 CLAUDE.md 里说明"汇报完接着做，不用等确认"。反过来，喜欢边看边改的人，也可以约定"动手前先用一句话说计划，做完后简短回顾"——偏好不同，写进去的规则自然不同。
多 Agent 分工：结论要附证据
需要同时排查多个服务时，可以让主 Agent 把工作拆给几个子 Agent。比如怀疑订单、库存、支付几个服务都存在"重试次数失控"——明明配置了最多重试三次，实际却在不停重发同一个请求：
订单、库存、支付服务各分给一个子 Agent，检查请求失败后的重试次数是否超过配置上限。
每个结果附上重试上限、调用路径和触发条件，找不到证据就明确说明。
你核对结果后，再汇总成表，列出服务、是否受影响及依据。
关键在第二、三行。几个子 Agent 都回复"没问题"并不能让人放心，你需要知道这个"没问题"是怎么得出来的：查了哪些代码、依据是什么，主 Agent 还要对结果再做核查。否则你只是多收了几份结论，真被追问"哪里查过了"，依然说不清楚。
用 TASKS.md 对抗"上下文压缩"
聊天记录里明明都有任务和进度，为什么还要单独写一份 TASKS.md？
原因在于长任务跑起来后，对话里会持续塞进代码、日志和工具输出。上下文接近上限时，旧内容会被压缩，最早交代的细节就可能变得不完整。把待办落到文件里，相当于给任务做了一份"外部存档"：
- 完成一项就更新状态，发现新问题就追加；
- 继续工作前先让 Claude Code 重读清单，明确哪些已完成、哪些没动、哪些在等你决定；
- 你想检查进度时，不用再翻几十屏聊天记录。
在 JeecgBoot 这类模块多、改动面广的项目里，我们的经验是把
TASKS.md按模块分组（如 system、online 表单、报表），每项注明涉及的包路径，跨天续做时效率提升非常明显。
中途想起遗漏？直接插话
代码改到一半，突然想起老的调用方式还得兼容——不用等它交卷。在 Claude Code 执行过程中可以直接输入补充要求并回车。任务越长，推倒重来的成本越高，发现遗漏就及时说。
收工后：先看"待你处理"，再看"已完成"
汇报格式也可以约定
跑了很久终于交来一份汇报，多数人第一反应是看"完成了哪些工作"。手册建议反过来：先找有没有事在等你决定——缺一份资料、一个方案需要拍板。这些内容要是藏在长篇总结末尾，你读了半天才发现接下来该自己接手了。
所以可以在 CLAUDE.md 里约定汇报结构，每次结束时分成「待你处理」「已完成」「新发现」三部分。
代码审查：要能"查下去"的线索
代码改完，还要确认有没有引入新问题。可以先让 Claude Code 自审一轮，再交给人看：
对照 main 分支，审查当前分支的代码变更。
只列出你认为必须修复后才能合并的问题。
每条写清文件名和行号、什么情况下会出错、原因是什么，以及怎样复现。
"这段可能有问题"这样的反馈价值很低，位置 + 触发条件 + 复现方法三件套齐全，审查结论才可复查。另外"只列必须修复的问题"这一句也很重要，它能有效过滤掉风格类的噪音意见。
调研报告同理：有依据的结论和尚未查实的推测要分开写，没查实的还要说明已经找过哪里。报告排版再漂亮，一个未经确认的关键数字，就足以让后续判断整体跑偏。
在 Claude 应用里：几个顺手的小技巧
如果你主要在 Claude 网页端或桌面端使用，先确认模型选择器里选的是 Opus 5.5，然后可以试试这些做法：
- 图直接发，问题问具体。架构图、报表、截图直接上传，问"哪些服务直接调用了支付接口"，比自己用文字描述方框和箭头省事得多，还保留了位置关系。新一代模型对图表细节和空间关系的理解有所改进，箭头连着谁、数字属于哪一栏都可以直接问。
- 让它查长文档的前后矛盾。一份方案改了几轮，前面写"10 月上线"，最后一页还留着"9 月"，人工通读很难发现。提要求时明确说"检查日期、数字、名称是否前后矛盾，把矛盾原句摘出来并标注段落或页码"，你拿着原句就能回去核对。
- 要文件就说清格式。比如把项目清单整理成 Excel，写明列名、每行代表什么、按负责人和截止日期排序，交付后直接打开就能检查。
- 长对话里避免"反复回头想"。聊得久了，Opus 5.5 有时会重新琢磨已经回答过的问题，导致回复变慢。日常跟进类对话，可以在项目指令里加上：
已经回答清楚的问题，先沿用之前的答案。
优先处理我当前的问题，除非我再次问起或指出问题，否则不用重新分析旧答案。
不过这条约定不适合长篇分析：新材料可能推翻之前的判断，这时候回头复查恰恰是在把问题想完整。按场景决定要不要加，而不是一刀切。
模型怎么突然换了？理解自动切换机制
明明选的是 Opus 5.5，聊着聊着却变成了旧模型——这通常是触发了安全检查后的自动切换，而正常请求也存在被误判的可能。手册特别说明：查找源码中的安全漏洞是允许的，日常健康、教育类问题也应当能正常处理。
排查时要注意两点：
- 检查范围不只是最后一句。之前的消息、上传的文件、搜索结果都会被纳入，别只盯着刚发的那句话找原因。
- 切回去不等于清零。在 Claude 应用里看到「Switched to」和旧模型名，说明已经切换，后续对话会沿用该模型。你可以在模型选择器里手动选回 Opus 5.5，但之前触发检查的内容还留在对话里，可能再次触发。如果确认是误判，更稳妥的做法是新开一个对话重新提出需求。
相关设置入口对照如下：
| 操作 | Claude 应用 | Claude Code |
|---|---|---|
| 切回模型 | 模型选择器 | /model |
| 调整自动切换偏好 | Settings → Capabilities，关闭「Switch models when a message is flagged」 | /config |
| 反馈误判 | — | /feedback |
| 修改上一条消息 | — | 连按两次 Esc |
关闭自动切换后，遇到原本会换模型的情况，对话会先暂停，由你决定怎么处理。
还有一个细节：要求模型逐字公开内部思考过程，也可能触发安全标记或被拒绝。如果你的提示词或保存的指令里有这类要求，建议顺手删掉。想了解它为什么选某个方案，直接问取舍和依据即可，比如"这个方案比另一个好在哪里，判断依据是什么"。
要不要开 /fast？算一笔时间账
在 Claude Code 里来回调代码、每轮都盯着屏幕等回复时，可以试试 /fast 快速模式。它用的还是同一个模型，只是响应更快——代价是费用更高：该功能目前处于研究预览，需要开启「额外用量」，同样的 token 在快速模式下更贵。
判断标准很简单：你是否正坐在电脑前等结果。交互式调试、结对式开发时，少等几秒就能保持思路连贯，值得开；把任务交出去后本来就要去忙别的，那就没必要花这个钱。
总结：一份可直接照抄的开工检查清单
把手册的建议压缩成四项，下次开长任务前过一遍：
- 提需求：写清完成标准；清理提示词和固定指令里多余的"仔细思考"；图表直接附上；设计偏好具体到"不要什么"。
- 跑任务：约定继续与暂停的条件；保留危险操作的权限确认；大任务按需分工并要求附证据；用
TASKS.md及时更新进度。 - 看结果：先处理等你决定的事，再看审查证据和尚未确认的信息。
- 看设置：知道当前用的是哪个模型，按习惯配置自动切换和快速模式。
与其收藏整份手册，不如挑一个最近让你反复催"继续"的任务，按上面的方法把"怎样算做完、什么情况要停下来问你"补清楚，再跑一轮。对比一下中途少了几次无意义的停顿、交付物是否更容易检查——亲手验证过的那几条，才会真正变成你的工作习惯。
官方原文可参考：https://claude.dev/blog/getting-the-most-out-of-opus-5-5/
本文为 JeecgBoot AI 专题研究系列文章。
浙公网安备 33010602011771号