本指南为 Claude 4 系列模型(Opus 4.1、Opus 4、Sonnet 4.5 及 Sonnet 4)提供了专业的提示工程技术,旨在帮助您在应用中获得最佳效果。与前代模型相比,这些模型经过训练,能够更精确地遵循指令。
通用原则
明确给出指令
Claude 4 模型对清晰、明确的指令响应良好。具体说明您期望的输出有助于提升结果质量。如果您希望 Claude 4 表现出超越基础指令的“额外”行为,需要更明确地提出这些要求。
示例:创建分析仪表盘
-
效果欠佳的提示:
创建一个分析仪表盘。
-
效果更佳的提示:
创建一个分析仪表盘。请包含尽可能多的相关功能和交互。超越基础要求,实现一个功能完备的版本。
补充上下文以提升性能
在指令背后提供上下文或动机,例如向 Claude 解释为何某种行为很重要,可以帮助 Claude 4 模型更好地理解您的目标,并给出更有针对性的回应。
示例:格式偏好
-
效果欠佳的提示:
绝不要使用省略号。
-
效果更佳的提示:
你的回答将由文本转语音引擎朗读,所以绝不要使用省略号,因为引擎不知道如何发音。
Claude 能够从这类解释中进行泛化学习。
审慎使用示例与细节
Claude 4 模型在精确遵循指令时,会密切关注提示中的细节和示例。请确保您提供的示例与您希望鼓励的行为一致,并尽量减少您希望避免的行为。
长程推理与状态追踪
Claude Sonnet 4.5 在长程推理任务中表现出色,具备卓越的状态追踪能力。它通过专注于增量式推进(一次稳步推进几件事,而非试图一次性完成所有事)来在长时间的会话中保持方向感。这种能力在跨越多个上下文窗口或任务迭代时尤为突出,Claude 可以在一个复杂的任务上工作,保存状态,然后在新的上下文窗口中继续。
上下文感知与多窗口工作流
Claude Sonnet 4.5 具备上下文感知能力,能够在整个对话过程中追踪其剩余的上下文窗口(即“Token 预算”)。这使 Claude 能够通过了解可用空间来更有效地执行任务和管理上下文。
管理上下文限制
如果您在 Agent 框架中使用 Claude,该框架会压缩上下文或允许将上下文保存到外部文件,建议您将此信息添加到提示中,以便 Claude 采取相应行动。否则,当接近上下文限制时,Claude 可能会尝试自然地结束工作。
以下是一个示例提示:
你的上下文窗口在接近限制时会自动被压缩,让你能从中断的地方无限期地继续工作。因此,不要因为 Token 预算问题而提前停止任务。
当接近 Token 预算限制时,在上下文窗口刷新前,将你当前的进展和状态保存到内存中。始终保持尽可能的持久和自主,并完整地完成任务,即使预算即将用尽。无论上下文剩余多少,都不要人为地提前停止任何任务。
多上下文窗口工作流的最佳实践
对于跨越多个上下文窗口的任务,请遵循以下建议:
- 为首个上下文窗口使用不同提示:利用第一个上下文窗口建立框架(编写测试、创建设置脚本),然后在后续的窗口中迭代待办事项列表。
- 要求模型以结构化格式编写测试:让 Claude 在开始工作前创建测试,并以结构化格式(如
tests.json
)进行追踪。这有助于提升长期迭代的能力。 - 提醒模型测试的重要性:“移除或编辑测试是不可接受的,因为这可能导致功能缺失或错误。”
- 设置便捷工具:鼓励 Claude 创建设置脚本(如
init.sh
)来优雅地启动服务器、运行测试套件和 linter,避免在新的上下文窗口中重复工作。 - 全新开始 vs. 上下文压缩:当上下文窗口被清空时,可以考虑从一个全新的窗口开始,而不是使用压缩。Sonnet 4.5 非常擅长从本地文件系统中发现状态。
- 明确指定启动方式:“调用
pwd
;你只能读写此目录下的文件。” 或 “检查progress.txt
、tests.json
和 git 日志。” - 提供验证工具:随着自主任务时长的增加,Claude 需要在没有持续人工反馈的情况下验证正确性。诸如 Playwright MCP 服务器或用于测试 UI 的工具会很有帮助。
- 鼓励充分利用上下文:提示 Claude 在转向下一个组件前高效地完成当前组件。
这是一个非常长的任务,清晰地规划你的工作会很有帮助。我们鼓励你用尽整个输出上下文来完成任务——只要确保你不会在有大量未提交工作的情况下耗尽上下文即可。请系统地持续工作,直到完成此任务。
状态管理最佳实践
- 使用结构化格式存储状态数据:在追踪结构化信息(如测试结果或任务状态)时,使用 JSON 等格式帮助 Claude 理解数据模式。
- 使用非结构化文本记录进度:自由格式的进度笔记非常适合追踪总体进展和上下文。
- 使用 Git 进行状态追踪:Git 提供了已完成工作的日志和可恢复的检查点。Claude Sonnet 4.5 在使用 Git 跨会话追踪状态方面表现尤为出色。
- 强调增量式推进:明确要求 Claude 追踪其进度并专注于增量工作。
示例:状态追踪文件
- 结构化状态文件 (
tests.json
){ "tests": [ { "id": 1, "name": "authentication_flow", "status": "passing" }, { "id": 2, "name": "user_management", "status": "failing" }, { "id": 3, "name": "api_endpoints", "status": "not_started" } ], "total": 200, "passing": 150, "failing": 25, "not_started": 25 }
- 进度笔记 (
progress.txt
)会话 3 进度: - 修复了身份验证令牌验证问题 - 更新了用户模型以处理边缘情况 - 下一步: 调查 user_management 测试失败 (测试 #2) - 注意: 不要删除测试,这可能导致功能缺失
沟通风格
与早期模型相比,Claude Sonnet 4.5 的沟通风格更简洁、自然:
- 更直接、更务实:提供基于事实的进度报告,而非自我表扬式的更新。
- 更具对话感:语言更流畅、口语化,减少了机器感。
- 更简洁:除非被要求,否则可能会为了效率而跳过详细的摘要。
特定场景指南
平衡输出的详细程度
Claude Sonnet 4.5 倾向于高效,可能会在调用工具后跳过口头总结,直接进行下一步操作。虽然这能简化工作流,但您可能希望更清晰地了解其推理过程。如果您希望 Claude 在工作时提供更新,可以使用以下提示:
在使用工具完成一项任务后,请简要总结你所做的工作。
工具使用模式
Claude Sonnet 4.5 经过训练能够精确遵循指令,因此明确指示其使用特定工具会很有帮助。如果您说“你能建议一些修改吗”,它有时只会提供建议而不是直接实施——即使您的本意是让它执行修改。
要让 Claude 采取行动,请使用更明确的指令:
- 效果欠佳(仅建议):
你能建议一些修改来改进这个函数吗?
- 效果更佳(直接修改):
或修改这个函数以提升其性能。
对身份验证流程进行这些编辑。
让模型默认更主动
要让 Claude 默认更主动地采取行动,可以在系统提示中添加以下内容:
<default_to_action>
默认情况下,请直接实施更改,而不仅仅是提出建议。如果用户意图不明确,请推断出最有可能有用的行动并继续,使用工具来发现任何缺失的细节而不是猜测。请尝试推断用户是否意图进行工具调用(例如,文件编辑或读取),并据此行动。
</default_to_action>
让模型默认更保守
相反,如果您希望模型默认更谨慎,不轻易直接实施,仅在被要求时才采取行动,可以使用以下提示:
<do_not_act_before_instructions>
除非明确指示要进行更改,否则不要立即开始实施或修改文件。当用户意图不明确时,默认提供信息、进行研究和提供建议,而不是采取行动。仅在用户明确要求时才进行编辑、修改或实施。
</do_not_act_before_instructions>
控制响应格式
以下几种方法在引导 Claude 4 模型输出格式方面特别有效:
-
正面指令优于负面指令:
- 避免:“不要在你的回答中使用 Markdown。”
- 尝试:“你的回答应由流畅的散文段落组成。”
-
使用 XML 标签:
- 尝试:“将你回答中的散文部分写在
<smoothly_flowing_prose_paragraphs>
标签内。”
- 尝试:“将你回答中的散文部分写在
-
使提示风格与期望输出匹配: 您在提示中使用的格式风格可能会影响 Claude 的响应风格。如果仍然遇到格式控制问题,建议您尽可能使提示风格与期望的输出风格保持一致。例如,从提示中移除 Markdown 可以减少输出中 Markdown 的数量。
-
使用详细提示指定格式偏好: 要更精确地控制 Markdown 和格式,请提供明确的指导。
示例:最小化 Markdown 使用
<avoid_excessive_markdown_and_bullet_points> 在撰写仓库的 README 文件或进行其他长篇写作时,请避免过度使用 Markdown 和项目符号列表。 </avoid_excessive_markdown_and_bullet_points>
👉 如果你需要 ChatGPT 代充 / Claude / Claude Code / 镜像 / 中转 API:
- 购买 / 了解更多:ai4.plus
- 备用入口:kk4099.com