本文基于 Anthropic 官方文档（Prompting Claude Opus 4.8、Effort、Claude Code 最佳实践）整理，并标注了每节出处，便于核验。

一个核心判断

Opus 4.8 最该被记住的一条特性，官方称之为 “more literal instruction following”（更字面化的指令遵循）：它会按你明确写出的内容执行，不会把一条指令”悄悄”推广到其他对象上，也不会替你补全你没提出的需求（来源）。

这带来两个直接后果：

  • 好处：精确、可预测、少返工。对结构化抽取、流水线、参数化调用尤其友好。
  • 代价：含糊的提示词不会被”善意脑补”。你说”统一一下格式”，它可能只处理它确认你要它处理的范围；你想让它覆盖全文，就得显式写出范围——官方给的原话示例是 “Apply this formatting to every section, not just the first one”。

所以为 4.8 写提示词的目标不是”写得复杂”，也不是”写得长”，而是把任务当成一份规格（spec）来写：范围、标准、边界、交付物各就各位。下面分七个主题展开。

从含糊方向到任务规格的提示词升级路径
Opus 4.8 更适合被交付规格，而不是被交付一句模糊方向。

一、把”做什么 / 不做什么 / 范围”分开写

模糊指令（如”帮我优化一下”）的问题在于：它没界定对象、范围和禁区。改写成规格的样子：

请优化这篇文章的"语言表达"，目标是让普通读者读起来更自然。

边界：
- 保留原文核心观点和整体结构；
- 不新增论点，不改成营销口吻。

具体处理（适用于全文，不只是开头）：
1. 删除重复表达；
2. 把书面、绕口的句子改顺；
3. 让段落过渡更自然。

注意第三块特意写了 “适用于全文”——因为 4.8 不会自动把”开头几段的处理方式”推广到全文，这是它字面化遵循的直接体现（来源）。

任务规格里需要同时写清范围边界和交付物
一个好 Prompt 至少要把范围、边界和交付物拆开写。

代码任务同理，把边界写死：

修复这个 bug，只做解决问题所需的最小改动。
不要重构无关代码，不要改现有 API，不要顺手改命名或文件结构。
完成后说明：(1) 根因；(2) 改了什么；(3) 为什么这样能解决。

一个被官方反复强调的小技巧：约束输出时，正面示例比负面禁令更有效。“请这样精简地表达（给个范例）“通常比堆一串”不要……”管用（来源）。

二、effort：4.8 最重要的一个旋钮

effort 参数控制模型在一次响应里愿意花多少 token，本质是”能力 ↔ 速度/成本”的权衡。官方明确指出：effort 对这一代模型的重要性超过以往任何 Opus，升级后值得主动调它（来源）。

几个容易被误解、但很关键的事实：

  • 默认就是 high（API 和 Claude Code 都是），设 high 等同于不传这个参数。不是”需要时才调高”，而是默认已经不低。
  • 编码 / agent 任务的推荐起点是 xhigh，不是 high——这是官方原话：“Start with xhigh for coding and agentic use cases.”
  • 高 effort 不是越高越好：max 在部分任务上收益递减，甚至会”想太多”（overthinking）。把 max 留给真正前沿的难题。
档位适用场景
max需要极限推理深度的硬问题（注意可能过度思考）
xhigh编码、复杂 agent、需反复调工具/深度检索——编码首选
high（默认）复杂推理、细致分析，质量优先于速度成本
medium成本敏感、可接受能力折扣的 agent 任务
low短小、范围明确、对延迟敏感且不吃智力的任务

来源：Effort 文档 · Recommended levels for Opus 4.8

effort 参数在速度成本和任务复杂度之间做权衡
effort 是 4.8 的关键旋钮：低复杂度看速度，高复杂度给空间。

两条实操建议：

  1. 如果在复杂问题上看到推理变浅，第一反应是调高 effort，而不是用提示词去绕。若因延迟必须保持 low，再用一句话补救：“This task involves multi-step reasoning. Think carefully before responding.”
  2. 跑 xhigh / max 时，把 max_tokens 设大（官方建议从 64k 起调），给模型在思考、子代理、工具调用之间留出空间。

关于”思考”：4.8 用的是 adaptive thinking——默认关闭，需显式设 thinking: {type: "adaptive"} 才开；旧的 budget_tokens 手动模式在 4.8 上会直接报 400 错误。开启后，在 high/xhigh/max 档位模型几乎总会深度思考（来源）。普通用户在网页/App 里不直接碰这些参数，但理解这层机制有助于判断”何时该把任务交给更高 effort 的入口”。

三、长度不是”短一点 / 长一点”，是”保留什么 / 省略什么”

4.8 会按它判断的任务复杂度自动校准篇幅：简单查询答得短，开放分析答得长。所以单说”简洁”或”详细”效果有限，需要约束信息取舍（来源）。

想更短，官方给的示例就是直接说清省略什么：

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

想要”详细”，则要定义详细的结构而非”话变多”：

请给完整分析，不要只给结论。包含：
1. 主要判断；2. 判断依据；3. 可能的反对意见；
4. 不确定之处；5. 最终建议。

四、工具调用、进度汇报：4.8 的默认行为已经变了

这两点很多旧教程的方向值得修正，以官方为准：

1. 工具调用——4.8 倾向”先推理，后调工具”。 多数情况下这样结果更好。如果你希望它多用工具（尤其知识检索），最有效的杠杆是调高 effort（high/xhigh 会显著增加工具使用）；其次才是在提示里明确”何时、为何要用某个工具”（来源）。

2. 进度汇报——4.8 在长任务里本就会给高质量的阶段性更新。 官方建议：如果你之前加了”每 3 步汇报一次”这类脚手架，先把它删掉试试——旧约束反而可能让输出变碎。只有当默认更新的长度/内容不合你的场景时，才显式描述”更新应该长什么样”并给例子（来源）。

这与许多旧教程”主动要求模型按节点汇报”的建议相反——对 4.8，默认行为已经够好，过度脚手架是负优化。

五、代码审查：把”发现”和”筛选”拆成两步

这是 4.8 上一个反直觉但有官方明确说明的点。

4.8 找 bug 的能力比前代更强（召回、精确率内部评测都更高）。但如果你的审查提示里写了 “只报高危问题""保守一点""别挑刺”，4.8 会比旧模型更忠实地执行：它照样深入查、照样找到那些中低危 bug，然后因为你设的门槛而不报出来。表现就是”调查深度没变，但报出来的发现变少了”——这是 harness 配置问题，不是能力退化（来源）。

正确做法：让发现阶段只管覆盖率，把筛选挪到独立步骤。 官方推荐的提示原文：

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.

如果一定要单轮内自筛，别用”重要”这种定性词，要给具体的线：例如”只报会导致行为错误、测试失败或结果误导的 bug；纯风格/命名偏好这类 nits 可省略”。

Claude Code 最佳实践还补充了一个互补原则：用独立上下文做审查（Writer/Reviewer 或子代理模式），让审查者不偏向自己刚写的代码（来源）。“两步法”由此成立：第一步独立 + 全覆盖，第二步按明确标准排序筛选。

代码审查先全量发现问题再独立筛选排序
审查不要一上来就筛掉不确定项：先覆盖，再排序。

六、设计任务：绕开 4.8 的”默认家居风”

4.8 有很强的设计本能，但有一套持续出现的默认审美：暖奶油/米白底（约 #F4F1EA）、衬线标题（Georgia / Fraunces / Playfair）、斜体词缀、陶土/琥珀色点缀。它适合编辑、民宿、作品集类，但用在仪表盘、开发者工具、金融、医疗、企业应用上会明显违和——而且 PPT 里也会冒出来（来源）。

关键是：泛泛地说”别用奶油色""做干净点”没用，只会让它换到另一种固定风格，而不是产生多样性。两种可靠做法：

做法 A——给具体规格。 4.8 对明确规格执行得很精确：写清配色 hex、字体类型与字距、圆角数值、栅格与留白、hover 过渡时长等。

做法 B——先出方向，再开做：

开始前，请针对这个 brief 给 4 个不同的视觉方向
（每个写成：背景 hex / 强调色 hex / 字体 —— 一句理由），
让我选一个，然后只实现选中的方向。

顺带：4.8 比旧模型更不需要长篇”避免 AI 味”的咒语就能产出有辨识度的前端。一个简短的 <frontend_aesthetics> 片段（禁用 Inter/Roboto、紫渐变等套路）配合上面的”先出方向”即可（来源）。

设计任务先生成多个视觉方向再选择一个执行
设计任务不要只说“高级一点”，先让模型给出可选择的视觉方向。

七、可复用的提示词骨架

适合 4.8 的结构，本质是一份轻量 spec：

任务：______
目标读者/用户：______
最终用途：______
重点处理：______
明确不要做：______（用正面示例替代纯禁令更佳）
输出格式：______
信息不足时：请说明缺什么，不要编造。

对交互式编码/agent 场景，官方额外强调一条：把任务、意图、约束在第一轮就说全。4.8 比前代更自主，首轮规格越完整，后续来回越少、token 效率和效果越高；反过来，把需求拆成多轮含糊补充，反而更费 token（来源）。

轻量任务规格骨架包含任务目标用户用途边界输出和缺失信息处理
可复用提示词骨架的价值，是让每次任务都先变成可执行规格。

小结：为 4.8 写提示词的五条底线

  1. 它按字面执行——要全覆盖就显式写范围，别指望脑补。
  2. effort 是第一旋钮——默认 high，编码起步 xhigh；推理变浅先调它，而不是绕。
  3. 长度靠”取舍”约束，不靠”长/短”两个字。
  4. 默认行为已变好——工具调用、进度汇报别再套旧脚手架。
  5. 审查先全覆盖再筛选；设计给规格或先要方向，别用”严重一点""高级一点”这类定性词。

一句话：和 4.8 配合，最好的提示词不是最长的，而是最像一份规格的。

参考链接