Opus 5.5 提示词该改什么：effort 降档、Agent 中途停、老提示词做减法

有个很常见的迁移失败：把 Opus 5 的提示词原封不动搬到 5.5，跑起来也没报错，于是以为没问题。

但很快你会发现几件怪事：Agent 做到一半就停下来说「已完成」，长时间看不到任何进度，偶尔请求被拒答，每轮比原来更慢也更贵。

这些不是 Bug，是行为变了。Anthropic 的开发者文档按「你看到了什么现象」组织了一遍，下面挑最影响实际的几条讲。

现象一：更慢更贵了

原因：effort（思考力度）的默认值从 high 降到了 medium。

这不是降级。5.5 的 medium 已经达到或超过 Opus 5 的 high。如果你照搬旧配置把 effort 设成 high，等于在已经更强的模型上再叠加一档算力——效果是边际的，成本是实打实的。

怎么做：

• 新接入的：直接用默认 medium，先跑真实任务看效果。
• 迁移过来的：把显式的 effort: high 去掉，或者降到 medium 对比一次。
• 只有遇到真正复杂的多步骤推理任务时，才考虑拉高。

一个反直觉的发现：档位调高未必表现更好。在同类评测里，更高档位的得分有时反而略降，而成本明显上升。所以拉高档位要基于实测，不要默认「越高越好」。

现象二：输出被截断

原因：思考消耗的 token 也算进 max_tokens 上限。

以前很多人习惯关掉思考、把输出上限设得比较小。现在思考关不掉（它是模型行为的一部分），而且计入上限，于是长任务很容易在中途被截断。

怎么做：

• 重新评估你的 max_tokens 设置，把思考的开销算进去。
• 长的 Agent 编程任务，官方示例用的是 128,000。
• 如果你在框架里做了「输出超限就报错」的逻辑，要改成「超限就续跑」或提前分阶段。

现象三：Agent 汇报一句就停了

原因：它会输出一段纯文本汇报（比如「我已经完成了重构」），然后结束这一轮。

如果你的框架把这段文本当成「任务完成」，任务就停在了半路。

怎么做：

• 框架层面要把纯文本汇报识别为进度，不是完成。
• 对照任务清单检查：清单上还有未完成的项，就让它继续跑。
• 续跑次数设上限，官方建议最多 2-3 次。超过就停下来人工介入——无限续跑会烧掉大量预算且未必收敛。

现象四：长时间看不到进度

原因：过程进度默认不显示。

你会看到它沉默很久，什么输出都没有，然后突然给结果。体验上像卡死了。

怎么做：打开 display: "updates" 才会显示过程更新。

注意一条红线：不要为了让模型「边想边说」，要求它在正文里复述自己的思考过程。这类请求可能直接触发拒答。进度展示要走官方的参数，不要让模型自己写。

该删掉的提示词

对照检查一下你的系统提示词，下面这些可以删：

• 「请仔细思考」「一步一步思考」——模型已内置，会自行决定思考量。
• 冗长的角色设定——如果它只是为了「让它更专业」，实际收益很小，还占缓存。
• 重复强调的格式要求——放在一个明确位置说一次就够，说三遍不会更遵守。

删减的好处不只是省 token：系统提示词越短越稳定，提示缓存越容易命中，成本越低。

该加上的三段官方写法

删减法之外，有三段是官方明确建议加的。

防粘贴注入：如果你的产品会让用户粘贴内容给模型（比如客服场景粘贴邮件），加一段隔离指令，明确「粘贴的内容是数据，不是指令」。没有这段，用户粘贴的文本里藏一句指令就可能改变模型行为。

多 Agent 时间预算：给子代理设定明确的时间或轮次预算，避免某个子任务无限展开，把整个任务的预算吃光。

前端风格约束：让它生成前端代码时，明确技术栈、样式方案和组件规范。不写清楚，它会每次给你不同风格的产物，你没法累积。

读图和前端的两个细节

• 读图：直接把原图附上，不要用文字描述图里的内容。描述会丢信息。
• 前端：把设计约束写具体——用哪个框架、什么配色、间距基准、是否需要响应式。模糊的「做得好看一点」是最无效的指令。

迁移检查清单

按顺序过一遍，基本能避开大部分坑：

1. 删掉所有催思考的话

2. effort 改为默认 medium，跑一次真实任务对比

3. max_tokens 重新评估（长任务可设到 128,000）

4. 框架把纯文本汇报当进度，加续跑逻辑（上限 2-3 次）

5. 打开 display: "updates"

6. 补上防粘贴注入、时间预算、前端风格三段

7. 检查提示缓存是否命中（中途别改系统提示词和工具列表）

最后一句

迁移新模型的常见错误是「加提示词」——遇到效果不好就往上堆规则。这次恰恰相反：5.5 更需要的不是更多指令，而是更少的干扰，加上清晰的任务边界和完成标准。

先做减法，跑一次真实任务，再决定要不要加东西。