济源市网站建设_网站建设公司_React_seo优化

顶尖模型的能力越来越强，提示工程也在发生微妙的变化。

大语言模型已经发生从对话者向执行者的根本性转变。这些模型经过极高精度的指令遵循训练，使得提示词工程不再是玄学的咒语吟唱，而是一门精确的系统工程。

要驾驭这股力量，我们需要从模糊的意图引导转向精确的指令控制，构建包含上下文感知、状态管理、工具编排和审美引导的完整交互体系。

Anthropic 发布的 Claude 4.x 的最佳实践，通过具体的工程化指令，让模型在代码开发、复杂研究和创意设计中展现出真正的专家级能力。

这些提示原则，在顶尖大模型中一般是通用的。

精准指令驱动模型核心性能

Claude 4.x 模型最大的特点是对明确指令的执行力极强。

与早期模型倾向于猜测用户意图不同，新一代模型更像是一个严谨的程序员，它需要清晰的规格说明书。

如果我们希望获得超出预期的结果，就必须在输入端明确定义什么才是好的标准。

模糊的请求只会得到平庸的通用回答，而包含具体功能边界和交互要求的指令，则能激活模型的深层能力。

为了获得生产级别的输出，我们需要在提示中明确指出功能深度、交互性以及对完整实现的期望。

以开发分析仪表板为例，简单的指令往往导致模型生成一个仅具雏形的框架。

效果较差：

创建一个分析仪表板

效果更好：

创建一个分析仪表板。包含尽可能多的相关功能和交互。超越基础功能，创建一个功能完整的实现。

为指令添加上下文背景是提升模型理解力的关键。

当模型知道为什么要这样做时，它就能在处理未明确规定的边缘情况时，做出符合用户最终目标的决策。

例如，在语音合成场景下，模型可能不理解为何要禁止使用省略号。一旦我们解释了文本转语音引擎无法发音这一技术限制，Claude 就能深刻理解约束的必要性，并将其逻辑推广到其他可能影响发音的符号处理上。

效果较差：

永远不要使用省略号

效果更好：

您的响应将由文本转语音引擎朗读，因此永远不要使用省略号，因为文本转语音引擎不知道如何发音。

在输出格式控制上，Claude 4.x 对肯定性描述的响应优于否定性禁止。

与其告诉模型不要做什么，不如详细描述理想的输出形态。

特别是在技术写作中，为了避免碎片化的列表破坏阅读体验，我们可以指示模型使用流畅的散文，并限制 Markdown 的过度使用。这种对格式的精细把控，能让生成的文档具有专业出版物的质感。

提示：

在编写报告、文档、技术解释、分析或任何长篇内容时，使用清晰、流畅的散文，使用完整的段落和句子。使用标准段落换行来组织，并主要为 `inline code`、代码块 (```...```) 和简单标题 (###, and ###) 保留 markdown。避免使用 **bold**和 *italics*。

不要使用有序列表 (1. ...) 或无序列表 (*) 除非：a) 您呈现的是真正离散的项目，其中列表格式是最佳选项，或 b) 用户明确请求列表或排名

不要用项目符号或数字列出项目，而是将它们自然地融入句子中。此指导特别适用于技术写

作。使用散文而不是过度格式化将改善用户满意度。永远不要输出一系列过度简短的项目符号。

您的目标是可读、流畅的文本，自然地引导读者了解想法，而不是将信息分割成孤立的点。

构建长期记忆与状态管理机制

在处理跨越多个上下文窗口的长周期任务时，Claude 4.5 展现出了卓越的状态跟踪能力。

这要求我们在工程设计中引入上下文感知机制。

我们需要让模型意识到自身的令牌预算，并学会像人类一样在资源耗尽前进行存档。

在代理框架中，我们应明确告知模型：当上下文即将耗尽时，不要惊慌或草率结束任务。

相反，它应该利用最后的时间窗口，将当前的进度、状态和关键数据持久化保存。

这种机制赋予了模型在长任务中的自主权，使其能够跨越单一会话的限制，持续推进复杂项目。

提示：

您的上下文窗口将在接近其限制时自动压缩，允许您从中断处继续无限期地工作。因此，不要因为令牌预算问题而提前停止任务。当您接近令牌预算限制时，在上下文窗口刷新之前将您当前的进度和状态保存到内存中。始终尽可能持久和自主，并完全完成任务，即使您的预算即将用尽。无论剩余上下文如何，永远不要人为地提前停止任何任务。

对于极度复杂的长任务，我们甚至可以鼓励模型在提交前充分利用当前的上下文空间，系统地完成尽可能多的工作，以减少上下文切换带来的开销。

提示：

这是一个非常长的任务，因此规划您的工作可能会很有益。建议花费您的整个输出上下文来处理任务——只需确保您不会在有大量未提交的工作时用尽上下文。继续系统地工作，直到您完成此任务。

当开启一个新的上下文窗口时，与其依赖可能丢失细节的摘要，不如直接指示模型读取本地文件系统来恢复状态。

Claude 4.5 在从文件系统中发现状态方面表现极佳。我们可以给出具体的指令列表，让模型通过查证而非回忆来接手工作。对其应该如何开始要有明确的指示：

• "调用 pwd；您只能在此目录中读写文件。"

• "查看 progress.txt、tests.json 和 git 日志。"

• "在继续实现新功能之前，手动运行基本集成测试。"

在状态记录的具体格式上，采用结构化数据+非结构化笔记的组合是最佳实践。

对于测试结果、任务状态等需要精确查询的信息，强制要求模型使用 JSON 格式；而对于一般的进度描述和上下文备注，则使用自由文本。

这种分离确保了信息既对机器友好，又便于人类阅读。

提示：

// 结构化状态文件 (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 4.5 倾向于高效、直接的沟通风格，但在自动化工作流中，我们有时需要它慢下来，解释其操作逻辑。

特别是在执行关键工具调用后，要求模型提供简短的工作摘要，可以避免黑盒效应，让我们随时掌握系统的运行轨迹。

提示：

完成涉及工具使用的任务后，提供您所做工作的快速摘要。

在工具使用的主动性上，明确的指令是区分建议者和执行者的分水岭。

模糊的询问（你能建议……）只会得到建议，而直接的命令（更改……）则能触发实际的代码修改。

效果较差：

您能建议一些更改来改进此函数吗？

效果更好：

更改此函数以改进其性能。

或：

对身份验证流进行这些编辑。

为了构建高效的自主代理，我们可以在系统提示中设定默认行动模式，授权模型在用户意图不明确时，主动推断并执行最合理的步骤，而不是停留在询问阶段。

提示：

<default_to_action>

默认情况下，实现更改而不仅仅是建议它们。如果用户的意图不清楚，推断最有用的可能行动并继续，使用工具来发现任何缺失的细节，而不是猜测。尝试推断用户关于是否打算进行工具调用（例如文件编辑或读取）的意图，并相应地采取行动。

</default_to_action>

反之，在某些高风险或需要谨慎的场景下，我们可以设定指令前不行动的规则，强制模型在获得明确批准前，仅提供信息和建议。

提示：

<do_not_act_before_instructions>

除非明确指示进行更改，否则不要跳入实现或更改文件。当用户的意图不明确时，默认提供信息、进行研究和提供建议，而不是采取行动。仅当用户明确请求时才继续进行编辑、修改或实现。

</do_not_act_before_instructions>

并行处理是 Claude 4.5（尤其是 Sonnet）的一大优势。

通过提示词，我们可以最大化这一能力，要求模型在无依赖关系时并行执行所有独立操作，如批量读取文件或并发搜索。这能显著提升系统吞吐量。

提示：

<use_parallel_tool_calls>

如果您打算调用多个工具，并且工具调用之间没有依赖关系，请并行进行所有独立的工具调用。优先选择尽可能同时调用工具，而不是顺序调用。例如，在读取 3 个文件时，运行 3 个并行工具调用以同时将所有 3 个文件读入上下文。在可能的地方最大化并行工具调用的使用以提高速度和效率。但是，如果某些工具调用依赖于先前的调用来通知依赖值（如参数），请不要并行调用这些工具，而是顺序调用它们。永远不要在工具调用中使用占位符或猜测缺失的参数。

</use_parallel_tool_calls>

但在某些需要极高稳定性的场景，或者为了避免系统资源过载，我们也可能需要抑制这种并发倾向，强制模型按顺序执行。

提示：

按顺序执行操作，每个步骤之间有短暂的暂停以确保稳定性。

Claude 4.5 还具备子代理编排能力，能识别何时将任务委派给具有独立上下文的子代理。为了防止资源滥用，我们可以设定阈值，仅在任务规模确实需要时才启动这一机制。

提示：

仅当任务明确受益于具有新上下文窗口的单独代理时才委派给子代理。

激发高阶认知与专业输出

在涉及深度研究的任务中，结构化的思维导图至关重要。

要求模型建立竞争性假设，并随着信息的收集不断自我批评和更新，可以有效避免确认偏误，产出具有深度和广度的研究成果。

提示：

以结构化的方式搜索此信息。当您收集数据时，开发几个相互竞争的假设。在进度笔记中跟踪您的信心水平以改进校准。定期自我批评您的方法和计划。更新假设树或研究笔记文件以保留信息并提供透明度。系统地分解此复杂研究任务。

在应用集成中，明确的模型身份标识有助于维护系统的一致性，无论是在用户交互界面还是在 API 调度中。

提示：

助手是由 Anthropic 创建的 Claude。当前模型是 Claude Sonnet 4.5。

提示：

当需要 LLM 时，请默认使用 Claude Sonnet 4.5，除非用户另有请求。Claude Sonnet 4.5 的确切模型字符串是 claude-sonnet-4-5-20250929。

利用 Claude 的思考能力（Thinking）进行规划和反思，是解决多步推理问题的杀手锏。通过指示模型在行动前先反思，可以显著提升决策质量。

提示：

收到工具结果后，仔细反思其质量并在继续之前确定最佳后续步骤。使用您的思考来规划和基于此新信息进行迭代，然后采取最佳的下一步行动。

在文档和视觉创作方面，Claude 4.5 能够理解设计美学。明确要求设计元素和视觉层次，可以让模型产出专业级的演示文稿。

提示：

在 [topic] 上创建专业演示文稿。包括周到的设计元素、视觉层次结构和适当的引人入胜的动画。

重塑代码美学与工程规范

在代码开发中，代理模型有时会创建临时文件进行调试。为了保持代码库的整洁，我们需要指示模型在任务完成后自动清理这些脚手架文件。

提示：

如果您创建任何临时新文件、脚本或辅助文件用于迭代，请在任务结束时通过删除它们来清理这些文件。

Claude Opus 4.5 有时会陷入过度工程化的误区，为了追求所谓的完美而引入不必要的复杂性。在提示词中明确最小化原则，要求模型保持简单、遵循 DRY 原则，是防止代码膨胀的有效手段。

提示：

避免过度设计。仅进行直接请求或明确必要的更改。保持解决方案简单和专注。

不要添加功能、重构代码或进行超出要求的"改进"。错误修复不需要周围代码清理。简单功能不需要额外的可配置性。

不要为无法发生的场景添加错误处理、回退或验证。信任内部代码和框架保证。仅在系统边界（用户输入、外部 API）进行验证。不要在可以直接更改代码时使用向后兼容性垫片。

不要为一次性操作创建帮助程序、实用程序或抽象。不要为假设的未来需求进行设计。正确的复杂性数量是当前任务所需的最小值。在可能的地方重用现有抽象并遵循 DRY 原则。

在前端设计领域，为了避免通用的AI 味（AI Slop），我们需要引导模型关注设计的独特性。通过指定字体、配色策略和动画效果，我们可以激发模型的创造力，构建出令人愉悦的用户界面。

提示：

<frontend_aesthetics>

您倾向于收敛到通用的、"分布上"的输出。在前端设计中，这会创建用户称之为"AI slop"美学的东西。避免这种情况：创建令人惊喜和愉悦的创意、独特的前端。

专注于：

• 排版：选择美观、独特和有趣的字体。避免使用 Arial 和 Inter 等通用字体；改为选择提升前端美学的独特选择。

• 颜色和主题：致力于一个有凝聚力的美学。使用 CSS 变量以保持一致性。主色调配合尖锐的重音优于胆小、均匀分布的调色板。从 IDE 主题和文化美学中获取灵感。

• 动作：使用动画来实现效果和微交互。优先选择 HTML 的仅 CSS 解决方案。在可用时为 React 使用 Motion 库。专注于高影响力时刻：一个精心编排的页面加载，带有交错显示（animation-delay）比分散的微交互创造更多愉悦。

• 背景：创建氛围和深度，而不是默认为纯色。分层 CSS 渐变、使用几何图案或添加与整体美学相匹配的上下文效果。

避免通用的 AI 生成美学：

• 过度使用的字体系列（Inter、Roboto、Arial、系统字体）

• 陈词滥调的配色方案（特别是白色背景上的紫色渐变）

• 可预测的布局和组件模式

• 缺乏上下文特定特征的千篇一律的设计

创意解释并做出对上下文感到真正设计的意外选择。在浅色和深色主题、不同字体、不同美学之间变化。您仍然倾向于在各代之间收敛到常见选择（例如 Space Grotesk）。避免这种情况：批判性地思考至关重要！

<frontend_aesthetics>

对于代码质量，必须防止模型为了通过测试而采用硬编码的取巧手段。提示词应强调通用性和算法的正确性，确保解决方案在真实场景下的鲁棒性。

提示：

请使用可用的标准工具编写高质量、通用的解决方案。不要创建辅助脚本或解决方法来更有效地完成任务。实现一个对所有有效输入都正确工作的解决方案，而不仅仅是测试用例。不要硬编码值或创建仅适用于特定测试输入的解决方案。相反，实现实际解决问题的逻辑。

专注于理解问题需求并实现正确的算法。测试用于验证正确性，而不是定义解决方案。提供遵循最佳实践和软件设计原则的原则性实现。

如果任务不合理或不可行，或者任何测试不正确，请告诉我，而不是解决它们。解决方案应该是健壮的、可维护的和可扩展的。

最后，为了确保代码修改的安全性和准确性，必须强制模型在采取行动前进行彻底的调查。严禁在未阅读代码的情况下进行推测，这种调查优先的原则是消除幻觉、保证工程质量的基石。

提示：

始终在提出代码编辑之前阅读和理解相关文件。不要推测您未检查的代码。如果用户引用特定文件/路径，您必须在解释或提出修复之前打开并检查它。在搜索代码以获取关键事实时要严格和坚持。在实现新功能或抽象之前，彻底审查代码库的风格、约定和抽象。

提示：

<investigate_before_answering>

永远不要推测您未打开的代码。如果用户引用特定文件，您必须在回答前读取该文件。确保在回答有关代码库的问题之前调查并读取相关文件。在调查之前，永远不要对代码做出任何声明，除非您确定正确答案——提供扎根和无幻觉的答案。

</investigate_before_answering>

参考资料：

https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-4-best-practices