Opus 4.7 提示词需重写：7 个修复法

据 God of Prompt 在 X 平台发帖称，Opus 4.7 提示词需要从 Claude Opus 4.6 的写法中迁移。帖文称，Claude Opus 4.7 在 SWE-bench 上达到 87.6%，高于 Opus 4.6 的 80.8%，但旧提示词可能因模型更严格执行字面指令而变窄、变短，甚至输出不完整。

Opus 4.7 提示词为何会失效

帖文的核心判断很直接：Opus 4.7 更按字面执行指令。God of Prompt 称，Opus 4.6 会推断用户意图，并补齐提示词中的空白；Opus 4.7 则更倾向于只完成明确写出的任务。这会让同一段旧提示词得到更窄、更简短的输出。对生产环境而言，这一点重要，因为提示词迁移不再只是替换模型名。团队需要重新检查任务边界、输出格式和验证要求。

删掉旧脚手架，改用更明确的任务描述

第一类修复是减少过时脚手架。帖文建议删除 think step by step 这类固定短语，因为它曾用于弥补 Opus 4.6 的推理空缺，但在高 effort 的 Opus 4.7 中可能浪费 token，甚至拉低输出质量。更合适的做法是提高 effort level。对任务本身，也要把隐含需求写出来。例如，旧写法是 help me with my pitch deck；新写法应明确要求审阅 10 页幻灯片，标出弱钩子、缺失数据和转场混乱，并规定输出格式。换言之，Opus 4.7 提示词不应假设模型会自动补全业务语境。

用 XML 标签和长文档夹心结构稳住注意力

第二类修复是调整结构。God of Prompt 建议把 markdown 标题改为 XML 标签，把上下文、任务、约束和输出格式分别包进 、、 与 <output_format>。帖文称，Opus 4.7 会把这些标签当作注意力锚点。处理长文档时，建议采用任务 — 文档 — 重申任务的夹心结构。即使 1M context 能容纳长输入，任务靠近文档边界仍有助于锁定模型注意力。这一建议反映了长上下文使用中的现实问题：上下文长度变大，不等于指令权重自动稳定。

为简洁输出、agent 调用和事实核验写明规则

第三类修复是把质量控制写入提示词。帖文称，Opus 4.7 默认更详尽；若需要简洁输出，应明确写成 3 个要点、不要开场白、直接输出。针对 agentic prompts，God of Prompt 建议在每次工具调用后加入反思步骤，例如要求模型在 标签中检查结果是否回答了问题，以及下一步该做什么。这可减少 optimistic chaining，即模型未验证工具结果就继续推进。帖文还提醒，不要把自信语气当作可靠性信号。更稳妥的写法是要求每条主张给出来源、在 标签中标记不确定性，并列出验证方式。

effort level 成为 Opus 4.7 迁移变量

God of Prompt 在帖文末尾补充称，Anthropic 官方指导建议编码和 agent 工作使用 xhigh effort，智能敏感任务至少使用 high effort。帖文还提到，Hex CTO 的 benchmark 显示，低 effort 的 Opus 4.7 约等于中等 effort 的 Opus 4.6。由于原帖未提供完整测试细节，这一说法应视为经验性对照，而非可复现实验结论。更保守的结论是：评估 Opus 4.7 时，模型版本、effort level 与提示词结构需要一起记录，不能只比较输出文本。 Opus 4.7 提示词迁移的关键不在于增加更长的指令，而在于把隐含任务显式化，把结构标签稳定化，并把验证步骤内置到工作流中。对使用 Claude 做编码、研究和 agent 自动化的团队来说，这构成了一次提示词资产重构，而不只是一次模型升级。