Opus 5.5 实战指南：提示、长任务与验收
做法与步骤
- 一次给完整任务并写明完成标准（如「测试通过」「所有端点迁移完」），Opus 5.5 在长链路多步任务上比 Opus 5 更能持续，早期测试者可数小时少监督运行。
- 删掉「think carefully」「think step by step」等提示，因为它每次回复前都会自行决定思考量；测试中删除后回复更快且质量无明显下降。
- 长任务运行中可直接输入后续消息（如「旧端点名保留为别名」），因为现在运行更长，重启代价更高。
- 生成页面或应用时，明确列出不要的设计习惯（如米白背景、斜体强调词、01/02/03 编号、等宽标签、胶囊按钮），泛泛说「避免通用感」只会换一个默认样式。
- 在 CLAUDE.md 写规则界定何时停下询问、何时继续：不需要输入就继续，只在无法继续或破坏性操作前停；若常出现「要我继续吗」，回复 continue。
- 大代码库审计或迁移时，让 Opus 5.5 拆给子代理并行处理并核验证据；长任务让它把清单写进 TASKS.md，读文件而非滚动记录来跟踪进度。
对实践的启示
用 Opus 5.5 要把提示从「教它思考」转向「定义完成线和停止条件」，并接受更长的自主运行；同时保留破坏性操作的权限确认，长任务用文件清单和子代理来管理上下文与验收。
作者承认的反方与局限
作者指出，让模型少停的规则意味着更少的中断，因此需要自己保留风险检查；对破坏性命令仍应开启权限提示。结对编程时可能想要相反做法：开始前一行计划、结束时简短回顾。
原文摘引
Hand over the whole task. Say what “done” looks like and when you want it to stop and ask.
Opus 5.5 always thinks before it replies, and it decides how much.
A rule to keep going means fewer stops, so keep your own check before anything risky or hard to undo.
▸ 展开原文全文（63 段，抓取自 Hacker News）
Playbooks
Getting the most out of Opus 5.5 in Claude and Claude Code
How to prompt Opus 5.5, steer a long run, and check your results in Claude apps and Claude Code.
Opus 5.5 works well with the way you already use Claude. A few things behave differently, though: it works for longer on its own, it tells you plainly what it did, and it thinks before every reply. This guide covers how to work with Opus 5.5 in Claude apps and Claude Code, including how to prompt the model, steer a long run, and check your results.
Three things to try in your first session with Opus 5.5
- Hand over the whole task. Say what “done” looks like and when you want it to stop and ask. Then let it work.
- Delete “think carefully” lines. Opus 5.5 already thinks before every reply.
- When a long run ends, read what it needs from you first.
What to do. Give the whole task in one message. Name the finish line, like “the tests pass” or “every endpoint is migrated.” Then let it cook.
Why it matters on Opus 5.5. Opus 5.5 keeps going on long, multi-part work better than Opus 5 did. Compared to prior Opus models, its biggest gains are on multi-step work, like carrying a change through a large repository until the tests pass. Early testers had it run long coding tasks for hours with little oversight. With a clear finish line, it knows when it’s done.
How. In Claude Code, for example:
PROMPT
Migrate the payment endpoints from the old client to the new one.
Done means: every endpoint uses the new client, the old client is deleted, and the test suite passes.
Stop and ask me only if a test fails for a reason you can't explain.
What to do. Remove “think carefully,” “think step by step,” and similar lines from your prompts and your saved instructions.
Why it matters on Opus 5.5. Opus 5.5 always thinks before it replies, and it decides how much. You don’t need to ask it to think. In our testing in a chat product, removing a “think carefully” line made replies start sooner, with no clear drop in quality.
How. Delete the line. For a quick answer to a simple question, say so: “Answer directly.” To change how much it thinks in Claude Code, change effort.
What to do. If you remember something mid-run, you can type a follow-up while it works.
Why it matters on Opus 5.5. Runs are longer now, so a restart costs more.
How to do it. In Claude Code, type the message and press Enter while Claude works, for example, “Also keep the old endpoint names as aliases.”
What to do. When you ask for a page, an app, or an artifact, list the design habits you want left out.
Why it matters on Opus 5.5. With no design direction, Opus 5.5 falls back on a few default styles. A general instruction like “avoid a generic look” mostly swaps one default for another. A list of specific patterns works much better.
How. Name the patterns:
Build a personal website with placeholder content.
Don't use a cream or off-white background, italic accent words in headings, numbered "01 / 02 / 03" section labels, monospace labels, or pill-shaped buttons.
Then look at what it chose instead. If you don’t like that either, add it to the list and ask again.
What to do. Put a short rule in your CLAUDE.md file about when to stop and ask, and when to keep going.
Why it matters on Opus 5.5. Opus 5.5 keeps you posted as it works. On a long task, it sometimes stops to report instead of going on: a summary that names the next step without taking it, an offer to continue, or a list of choices that don’t block the work. It follows instructions that name these stops. Name the stops you want, too.
How. Add this to CLAUDE.md, and edit it to fit your project:
When a step doesn't need my input, keep going. Put status notes in the same message as your next action.
Stop and ask only when you can't continue without me, or before anything destructive: deleting data, force-pushing, or changing anything outside this repository.
If a run stops with “Want me to continue?” reply “continue.” If that happens often, the rule above will help.
A rule to keep going means fewer stops, so keep your own check before anything risky or hard to undo. The last line of the rule above does that. Keep permission prompts on for destructive commands too.
For pair programming, you may want the opposite: a one-line plan before it starts and a short recap at the end. Say that in your CLAUDE.md instead. Opus 5.5 follows either one.
What to do. For an audit, a migration, or a review across a large codebase, ask Opus 5.5 to split the work across subagents and check each result.
Why it matters on Opus 5.5. Early testers had Opus 5.5 coordinate parallel subagents on long audits and migrations, with little oversight.
How.
Audit every service in services/ for the retry bug in the linked issue.
Give each service to its own subagent. When a subagent reports back, check its evidence before you accept it.
Finish with one table: service, affected yes or no, and the evidence.
What to do. For a run that will take a while, ask Opus 5.5 to keep its task list in a file and update it as it goes. Then read the file, not the scrollback, to see where the run is.
Why it matters on Opus 5.5. Runs are longer now. A long run fills the context window, and Claude Code then summarizes older turns. A list in a file survives that, and it shows you at a glance what’s done and what’s left.
How. “Keep a checklist in TASKS.md. Tick each item when it’s done, and add anything new you find.”
What to do. When a long run ends, look first for anything Claude is waiting on you for, like a decision it left open or a change it wants you to approve. Then read the rest of Claude’s summary.
Why it matters on Opus 5.5. Opus 5.5 reports on its work more clearly than Opus 5. Its updates and its final summary say what it did, what it found, and what it needs from you, in plain language.
How. To change the summary’s format, say so in CLAUDE.md, for example, “End every run with three headings: Blocked on me, Changed, Found.”
What to do. Ask Opus 5.5 to review a diff or a pull request before a person does.
Why it matters on Opus 5.5. One early tester said Opus 5.5 at its lowest effort caught more bugs than Opus 5 at high effort, with fewer false alarms. It also explains its changes in plain language, so its pull request descriptions are easier to review.
How. Feed this prompt to Claude:
Review the diff on this branch against main.
List only problems you'd block the merge for. For each one, give the file and line, why it's wrong, and how to show it fails.
What to do. For research and analysis, ask it to say what it couldn’t find or couldn’t check.
Why it matters on Opus 5.5. “I couldn’t find this” is worth reading, and asking for it makes it easy to find.
How. Add “Mark anything you couldn’t confirm, and say where you looked” to the request. This works in a Claude research report and in Claude Code.
First, check that the model picker says Opus 5.5.
What to do. Attach the chart, diagram, screenshot, or slide. Don’t retype the numbers.
Why it matters on Opus 5.5. Opus 5.5 reads charts, diagrams, and screenshots more accurately than Opus 5, and it needs no extra steps to do it. It’s also better at meaning that depends on where things are in the image: which boxes an arrow connects, what changed between two versions of a diagram, or when a meeting starts and ends in a calendar screenshot.
How. Attach the image and ask a specific question: “Which of these services call the billing API directly?”
What to do. Give it a long plan, report, or deck, and ask it to find mistakes.
Why it matters on Opus 5.5. Opus 5.5 pays more attention to detail than prior Opus models. In our testing, it caught a date that fell on the wrong weekday in a long planning thread, and a chart that didn’t match the numbers in a deck.
How. Submit the prompt: “Check this deck for anything that contradicts itself: numbers, dates and names. Quote each problem and say where it is.”
What to do. When you want a spreadshe