Claude Opus 4.8：努力档位、工具调用与代码审查提示模式

一句话结论

把任务边界写清楚，再用 effort 控制成本与深度，并把“发现”和“过滤”拆成两步，是 Opus 4.8 在 Agent、编码和代码审查中更稳定的用法。

适用场景

• 适合的任务：长程 Agent、编码、代码审查、知识工作、视觉和需要记忆上下文的任务。

• 不适合的任务：对延迟极敏感且不需要推理的短问答，不必默认使用高档位。

• 适用的模型版本：Claude Opus 4.8（模型 ID claude-opus-4-8）。

• 适用的客户端、Agent 或 API：Claude API、Claude Code、Cowork 及带工具的 Agent；努力档位在客户端和 API/Agent 配置中的具体入口可能不同。

• 推荐的推理档位和参数：编码/Agent 从 xhigh 开始；多数对智能敏感的任务至少 high；成本或延迟敏感的短任务可用 low/medium。需要思考时显式启用 thinking: {type: "adaptive"}，并为思考和可见输出预留足够 max_tokens。

可直接使用的内容

以下是 Anthropic 页面公开的可复制提示片段；它们是不同用途的独立示例，不是必须拼成一个超长系统提示。

控制回答长度

Provide concise, focused responses. Skip non-essential context, and keep examples minimal.

在复杂任务中显式要求思考

This task involves multistep reasoning. Think carefully through the problem before responding.

控制思考触发的边界

Thinking adds latency and should only be used when it will meaningfully improve answer quality — typically for problems that require multistep reasoning. When in doubt, respond directly.

让工具调用更主动但仍有理由

Use the available tools when they materially improve the answer. For each tool, first identify what question it will answer or what state it will change; do not call a tool merely to appear thorough.

代码审查：先覆盖，再交给后续步骤过滤

Report every issue you find, including ones you are uncertain about or consider low-severity. Do not filter for importance or confidence at this stage - a separate verification step will do that. Your goal here is coverage: it is better to surface a finding that later gets filtered out than to silently drop a real bug. For each finding, include your confidence level and an estimated severity so a downstream filter can rank them.

让子 Agent 使用有明确边界

Do not spawn a subagent for work you can complete directly in a single response (e.g. refactoring a function you can already see). Spawn multiple subagents in the same turn when fanning out across items or reading multiple files.

前端设计：先给方向再实现

Before building, propose 4 distinct visual directions tailored to this brief (each as: bg hex / accent hex / typeface — one-line rationale). Ask the user to pick one, then implement only that direction.

测试/工作流步骤

1. 先在首轮消息中写明任务、意图、约束、完成标准和可用工具；不要把关键约束分散到很多轮。

2. 简单、低风险任务用 low 或 medium；编码和 Agent 任务先测 xhigh，质量敏感任务至少 high。

3. API 任务若需要多步推理，显式加入 thinking: {type: "adaptive"}；若发现低档位浅思考，先提高 effort，不要只靠提示词补救。

4. 工具型任务说明何时调用工具、工具要回答的问题和应检查的结果；长任务允许模型给进度更新，不要机械要求“每 N 次工具调用汇报”。

5. 代码审查分成“发现（追求覆盖）→验证/去重/排序（过滤）”两步，再用子集评测 recall 或 F1，避免把“只报高危”混在发现阶段。

6. 前端任务给出具体色彩、字体或先让模型提出 4 个方向；泛泛的“不要米色、要简洁”不如具体替代方案稳定。

原始证据与数据

• 官方指南将 max、xhigh、high、medium、low 分别定位为最高能力、编码/Agent 首选、能力与成本平衡、成本敏感和短/低延迟任务。

• 指南称 Opus 4.8 默认关闭 thinking，需显式设置 thinking: {type: "adaptive"}；同时指出提高 effort 会影响工具使用强度。

• 指南明确记录 Opus 4.8 更偏向推理而非工具调用、默认更少生成子 Agent，并更严格地按字面执行范围；这些行为可通过工具规则、子 Agent 边界和“适用于每一节”的明确范围进行调节。

• 代码审查部分给出“报告所有发现、后续再验证”的完整示例，并建议在评测子集上验证 recall/F1；这是一条可复现的 harness 设计建议，而不是某个公开榜单分数。

适用边界

• 页面给出的是官方行为指导，不是独立复现实验；具体收益依赖工具定义、上下文、max_tokens、客户端和评测 harness。

• 代码块示例应按用途选用；把所有示例无条件拼接可能导致过度思考、过多工具调用或输出过长。

• effort、thinking 和模型版本会影响 token 消耗与延迟；上线前应在自己的任务集上测质量、成本、延迟和工具调用次数。

• 前端部分描述的是观察到的默认审美倾向，不是硬约束；品牌设计仍应提供具体设计系统。

来源摘录或观察（仅做合规短引）

官方指南的核心建议是“编码和 Agent 从 xhigh 开始”，并强调低档位会更严格地把工作范围限制在用户明确提出的内容内。原文也提醒：当复杂问题出现浅层推理时，第一调节杆应是提高 effort。