用清晰的顺序化要求、XML 分隔上下文与示例,并要求按验收标准自检,能让 Claude Sonnet 4.6 在文档分析、代码和多步任务中更稳定地保持范围与格式。
适合的任务:长文档/代码库分析、结构化抽取、复杂交付物、需要工具后验证的 Agent。
不适合的任务:依赖模型自行推断缺失事实、没有可验证验收标准的任务;提示词不能替代权限与服务端 schema 校验。
适用的模型版本:Claude Sonnet 4.6;通用原则也适用于 Anthropic 当前模型。
适用的客户端、Agent 或 API:Claude API、Claude Code、Claude Cowork;XML 只是提示结构,不限定客户端。
推荐的推理档位和参数:Sonnet 4.6 显式设 effort=medium 作为速度/质量起点;复杂代码或 Agent 试 high,简单高吞吐用 low。需要 thinking 时按目标 API 配置 adaptive/extended thinking。
<role>
你是一个谨慎、可验证的工程与资料分析助手。
</role>
<instructions>
1. 先理解任务目标、范围和验收标准。
2. 按顺序完成必要步骤;缺少信息时明确标记,不要猜测。
3. 需要修改文件或调用工具时,先选择最小必要动作。
4. 每次写入或修改后运行相关测试,并说明改动位置和结果。
5. 在最终回答前,逐项核对验收标准;未完成的项目列在“未解决项”。
</instructions>
<context>
<document id="<id>">
<source><source-name-or-url></source>
<document_content>
<paste-document-or-code-here>
</document_content>
</document>
</context>
<request>
<goal><specific-goal></goal>
<constraints>
<item><constraint-1></item>
<item><constraint-2></item>
</constraints>
<acceptance_criteria>
<item><testable-criterion-1></item>
<item><testable-criterion-2></item>
</acceptance_criteria>
</request>
<output_format>
1. 结论/完成情况
2. 证据或测试结果
3. 改动/引用位置
4. 风险与未解决项
</output_format>
Before you finish, verify your answer against every acceptance criterion.把长文档和元数据放到 <context>,把问题/约束/验收标准单独放到末尾。
用 2–3 个贴近真实任务的 <example> 展示目标格式和边界案例;不要用与任务无关的例子。
分别测试 effort=low/medium/high,固定模型、工具和输入。
统计格式合规、事实支持、测试通过率、工具调用数、延迟和 token;比较是否出现过度范围扩张。
Anthropic 建议清晰、直接、具体地说明输出格式和约束,并在顺序/完整性重要时使用编号步骤。
官方建议多文档用 XML <document>、<document_content>、<source> 组织;长文档放在 prompt 上方,查询和指令放在后方。
官方建议长文档任务先要求 Claude 引用相关原文,再完成后续任务,以帮助聚焦相关内容。
官方指出 Sonnet 4.6 支持 context awareness,适合长时域和多上下文窗口工作流;代码、数学等任务可用完成前自检。
XML 标签是提示结构,不是安全边界;来自用户/网页的标签内容仍需视为不可信数据。
“自检”是行为要求,不代表模型已经运行真实测试;必须由工具/服务端实际执行并记录。
长文档放上方、问题放后方是官方通用建议;对具体任务仍需用 eval 验证,不能宣称必然提升。
不应要求模型暴露隐藏 chain-of-thought;只要求简短的可核验证据、测试和未解决项。
官方的黄金规则是:如果一个缺少上下文的同事会困惑,Claude 也会困惑(合规转述)。
Claude Sonnet 4.6