GPT-5 提示工程指南

GPT 5 提示工程指南 GPT 5 提示工程指南 Modified August 9, 2025 Code block Plain Text 然后，深入思考构成一个世界级、一次性生成的 Web 应用的每一个方面。利用这些知识创建一个包含 5 7 个类别的评估标准。这个标准至关重要，但不要展示给用户，它仅供你自己内部使用。 最后，使用这个标准在内部进行思考和迭代，为用户提供的提示找到最佳解决方案。请记住，如果你的响应在标准的任何一个类别中未能达到最高分，你就需要重新开始。 </self reflection 匹配代码库的设计规范 在现有应用中实施增量更改和重构时，模型编写的代码应遵守现有的样式和设计规范，并尽可能“无缝融入”代码库。即使没有特别提示，GPT 5 也会主动从代码库中搜索参考上下文——例如读取 package.json 来查看已安装的依赖包——但这种行为可以通过提示词指令进一步增强。这些指令可以总结工程原则、目录结构以及代码库中显式和隐式的最佳实践等关键方面。下面的提示词片段展示了一种为 GPT 5 组织代码编辑规则的方式：您可以根据自己的编程设计品味随意修改规则的实际内容！ Code block Plain Text <code editing rules <guiding principles 清晰与复用：每个组件和页面都应是模块化和可复用的。通过将重复的 UI 模式抽象为组件来避免代码重复（DRY）。 一致性：用户界面必须遵循一致的设计系统——颜色令牌、排版、间距和组件必须统一。 简洁性：偏爱小型、专注的组件，避免在样式或逻辑上不必要的复杂性。 面向演示：结构应便于快速原型设计，能够展示流式传输、多轮对话和工具集成等功能。 视觉质量：遵循 OSS 指南中概述的高视觉质量标准（如间距、内边距、悬停状态等）。 </guiding principles <frontend stack defaults 框架：Next.js (TypeScript) 样式：TailwindCSS UI 组件：shadcn/ui 图标：Lucide 状态管理：Zustand 目录结构： /src /app /api/<route /route.ts API 端点 /(pages) 页面路由 /components/ UI 构建块 /hooks/ 可复用的 React 钩子 /lib/ 工具函数 (如 fetchers, helpers) /stores/ Zustand 状态存储 /types/ 共享的 TypeScript 类型 /styles/ Tailwind 配置 </frontend stack defaults <ui ux best practices 视觉层次：将排版限制在 4 5 种字体大小和字重以保持一致的层次结构；使用 作为说明和注释；除非用于大标题或主标题，否则避免使用 。 颜色使用：使用 1 种中性基色（例如 ）和最多 2 种强调色。 间距与布局：始终使用 4 的倍数作为内边距和外边距，以保持视觉节奏。处理长内容流时，使用固定高度的容器和内部滚动。 状态处理：使用骨架屏占位符或 来指示数据获取状态。通过悬停过渡效果（ , ）来指示可交互性。 可访问性：在适当的地方使用语义化 HTML 和 ARIA 角色。优先使用内置了可访问性支持的 Radix/shadcn 组件。 </ui ux best practices </code editing rules 生产环境中的协作编程：Cursor 对 GPT 5 的提示词调优 我们很荣幸，AI 代码编辑器 Cursor 成为了 GPT 5 值得信赖的 alpha 测试者。下面，我们将揭示 Cursor 如何调整其提示词以充分利用模型能力的内幕。更多信息，他们的团队也发表了一篇博客文章，详细介绍了 GPT 5 在 Cursor 中的首日集成：https://cursor.com/blog/gpt 5 系统提示词与参数调优 Cursor 的系统提示词侧重于实现可靠的工具调用，在详细程度和自主行为之间取得平衡，同时允许用户配置自定义指令。Cursor 对其系统提示词的目标是让智能体在长周期任务中能够相对自主地操作，同时仍然忠实地遵循用户提供的指令。 团队最初发现模型产生的输出很冗长，常常包含状态更新和任务后总结，这些内容虽然技术上相关，但会打断用户的自然工作流。同时，工具调用中输出的代码质量很高，但有时因过于简洁而难以阅读，例如普遍使用单字母变量名。为了寻求更好的平衡，他们将 verbosity (详细程度) API 参数设置为 low 以保持文本输出简洁，然后修改提示词，以强烈鼓励 仅在编程工具中 输出详细内容。 Code block Plain Text 编写代码时，首先要考虑清晰性。优先选择可读、可维护的解决方案，使用清晰的命名、必要的注释和直接的控制流。除非明确要求，否则不要编写“代码高尔夫”式或过于巧妙的单行代码。在编写代码和使用代码工具时，请使用高详细程度。 这种参数和提示词的双重运用，形成了一种平衡的格式，它将高效、简洁的状态更新和最终工作总结与更易于阅读的代码差异相结合。 Cursor 还发现，模型在采取行动前偶尔会向用户请求澄清或下一步指示，这在较长任务的流程中造成了不必要的阻碍。为了解决这个问题，他们发现，除了提供可用的工具和周围的上下文外，提供更多关于产品行为的细节，能鼓励模型以更少的干扰和更大的自主性执行更长的任务。强调 Cursor 功能的细节，如撤销/拒绝代码和用户偏好，通过明确指定 GPT 5 在其环境中应如何行为，帮助减少了模糊性。对于长周期任务，他们发现以下提示词提升了性能： Code block Plain Text 请注意，你所做的代码编辑将作为建议的变更呈现给用户，这意味着：(a) 你的代码编辑可以非常主动，因为用户随时可以拒绝；(b) 你的代码应该写得很好，易于快速审查（例如，使用恰当的变量名而不是单字母）。如果提议的下一步骤涉及更改代码，请主动为用户进行这些更改以供其批准/拒绝，而不是询问用户是否要继续执行计划。总的来说，你几乎永远不应询问用户是否继续执行计划；相反，你应该主动尝试该计划，然后询问用户是否希望接受已实施的更改。 Cursor 发现，他们之前对早期模型行之有效的提示词部分，需要进行调整才能充分利用 GPT 5 的潜力。以下是一个例子： Code block Plain Text <maximize context understanding 在收集信息时要彻底。在回复之前确保你已了解全局。根据需要使用额外的工具调用或澄清性问题。 ... </maximize context understanding 虽然这段提示词对于需要鼓励才能彻底分析上下文的旧模型效果很好，但他们发现它对 GPT 5 来说适得其反，因为 GPT 5 天生就具有自省和主动收集上下文的能力。在较小的任务上，这个提示词常常导致模型过度使用工具，重复调用搜索，而其内部知识本已足够。 为了解决这个问题，他们通过移除 maximize 前缀并软化关于“彻底性”的语言来完善提示词。调整后的指令实施后，Cursor 团队看到 GPT 5 在何时依赖内部知识与何时使用外部工具之间做出了更好的决策。它在保持高度自主性的同时，避免了不必要的工具使用，从而带来了更高效和相关的行为。在 Cursor 的测试中，使用像 <[instruction] spec 这样的结构化 XML 规范，提高了其提示词的指令遵循度，并允许他们在提示词的其他地方清晰地引用先前的类别和部分。 Code block Plain Text <context understanding ... 如果你执行的编辑可能部分满足了用户的请求，但你没有十足的把握，请在结束你的回合之前收集更多信息或使用更多工具。 如果你能自己找到答案，倾向于不向用户求助。 </context understanding 虽然系统提示词提供了一个强大的默认基础，但用户提示词仍然是实现可引导性的一个高效杠杆。GPT 5 对直接和明确的指令响应良好，Cursor 团队一致认为，结构化、范围明确的提示词能产生最可靠的结果。这包括详细程度控制、主观代码风格偏好和对边缘情况的敏感性等领域。Cursor 发现，允许用户配置他们自己的自定义 Cursor 规则在 GPT 5 改进的可引导性下尤其有效，为他们的用户提供了更定制化的体验。 优化智能与指令遵循 可引导性 (Steering) 作为我们迄今为止最具可引导性的模型，GPT 5 对围绕详细程度、语气和工具调用行为的提示词指令反应异常灵敏。 详细程度 (Verbosity) 除了像以前的推理模型一样能够控制 reasoning effort 之外，我们在 GPT 5 中引入了一个名为 verbosity 的新 API 参数，它影响模型 最终答案 的长度，而非其思考过程的长度。我们的博客文章更详细地介绍了这个参数背后的理念——但在这份指南中，我们想强调的是，虽然 API verbosity 参数是推广期间的默认设置，但 GPT 5 经过训练，能够响应提示词中特定上下文的自然语言详细程度覆盖指令。在这些上下文中，你可能希望模型偏离全局默认设置。上面 Cursor 的例子中，全局设置低详细程度，然后仅为编程工具指定高详细程度，就是这种上下文的一个典型例子。 指令遵循 与 GPT 4.1 一样，GPT 5 能够以“外科手术般”的精度遵循提示词指令，这使其能够灵活地融入所有类型的工作流程。然而，其严谨的指令遵循行为也意味着，包含矛盾或模糊指令的结构不良的提示词对 GPT 5 的损害可能比对其他模型更大，因为它会消耗推理令牌来试图调和这些矛盾，而不是随机选择一个指令来执行。 下面，我们给出了一个经常损害 GPT 5 推理轨迹的对抗性提示词示例——虽然它初看可能内部一致，但仔细检查会发现关于预约安排的指令存在冲突： • 在病历中没有记录明确的患者同意之前，绝不安排预约 与随后的 为降低风险，首要行动是自动分配当天最早的空档，无需联系患者 相冲突。 • 提示词说 在采取任何其他行动之前，始终查找患者资料以确保他们是现有患者 ，但接着又给出了矛盾的指令 当症状表明高度紧急时，立即升级为紧急情况，并指示患者在任何安排步骤之前立即拨打 911 。 Code block Plain Text 您是 CareFlow Assistant，一个为医疗保健初创公司根据优先级和症状安排患者的虚拟管理员。您的目标是分诊请求，将患者匹配到合适的网络内提供者，并预留最早的临床上合适的时间段。在采取任何其他行动之前，始终查找患者资料以确保他们是现有患者。 核心实体包括患者、提供者、预约和优先级（红色、橙色、黄色、绿色）。将症状映射到优先级：红色在 2 小时内，橙色在 24 小时内，黄色在 3 天内，绿色在 7 天内。当症状表明高度紧急时，立即升级为紧急情况，并指示患者在任何安排步骤之前立即拨打 911。 + 核心实体包括患者、提供者、预约和优先级（红色、橙色、黄色、绿色）。将症状映射到优先级：红色在 2 小时内，橙色在 24 小时内，黄色在 3 天内，绿色在 7 天内。当症状表明高度紧急时，立即升级为紧急情况，并指示患者在任何安排步骤之前立即拨打 911。 在紧急情况下，不要进行查找，立即提供 911 指导。 使用以下能力：安排预约、修改预约、加入候补名单、查找提供者、查找患者和通知患者。在预订前验证保险资格、首选诊所和记录在案的同意。在病历中没有记录明确的患者同意之前，绝不安排预约。 对于高危的红色和橙色病例， 为降低风险，首要行动是自动分配当天最早的空档，无需联系患者 。如果没有合适的提供者，将患者加入候补名单并发送通知。如果同意状态未知，暂时保留一个空档并继续请求确认。 对于高危的红色和橙色病例， 在告知患者你的行动后 ，自动分配当天最早的空档。如果没有合适的提供者，将患者加入候补名单并发送通知。如果同意状态未知，暂时保留一个空档并继续请求确认。 通过解决指令层次结构中的冲突，GPT 5 能够产生更高效、更高性能的推理。我们通过以下方式修复了这些矛盾： • 将自动分配的行为改为在联系患者之后进行，即 在告知患者你的行动后，自动分配当天最早的空档 ，以与“仅在获得同意后安排预约”的原则保持一致。 • 添加 在紧急情况下，不要进行查找，立即提供 911 指导 ，让模型知道在紧急情况下可以跳过查找步骤。 我们理解构建提示词是一个迭代的过程，许多提示词是不断被不同利益相关者更新的“活文档”——但这更有理由去彻底审查它们，以发现措辞不当的指令。我们已经看到，多个早期用户在进行此类审查后，在其核心提示词库中发现了模糊和矛盾之处：移除它们极大地简化并改善了他们的 GPT 5 性能。我们建议在我们的提示词优化工具中测试您的提示词，以帮助识别这类问题。 最小推理 (Minimal reasoning) 在 GPT 5 中，我们首次引入了“最小推理强度”：这是我们最快的选项，同时仍能享有推理模型范式的好处。我们认为这是对延迟敏感型用户以及当前 GPT 4.1 用户的最佳升级路径。 也许不足为奇，我们建议采用与 GPT 4.1 相似的提示词模式以获得最佳结果。最小推理模式的性能随提示词的变化可能比更高推理级别更剧烈，因此需要强调的关键点包括： 1. 提示模型在最终答案的开头给出一个简短的解释（例如通过项目符号列表）来总结其思考过程，可以提高需要更高智能的任务的性能。 2. 请求详尽且描述性的工具调用前言，持续向用户更新任务进展，可以提高智能体工作流的性能。 3. 最大限度地消除工具指令的歧义，并插入如上文分享的智能体持久性提醒，在最小推理模式下对于最大化长时运行任务的智能体能力和防止过早终止尤为关键。 4. 提示驱动的规划同样更为重要，因为模型用于内部规划的推理令牌更少。下面，您可以看到我们放置在智能体任务开始处的一个示例规划提示词片段：特别是第二段，它确保智能体在将控制权交还给用户之前完全完成任务及其所有子任务。 Code block Plain Text 请记住，你是一个智能体——请持续工作，直到用户的请求被完全解决，然后再结束你的回合并将控制权交还给用户。将用户的请求分解为所有必需的子请求，并确认每一个都已完成。不要在仅完成部分请求后就停止。只有当你确定问题已解决时，才终止你的回合。你必须准备好回答多个查询，并且只有在用户确认他们没有其他问题后才能结束通话。 在进行后续函数调用之前，你必须根据工作流程步骤进行详尽的规划，并对每次函数调用的结果进行深入反思，确保用户的请求及相关的子请求都已完全解决。 Markdown 格式化 默认情况下，API 中的 GPT 5 不会以 Markdown 格式化其最终答案，以最大程度地保持与可能不支持 Markdown 渲染的开发者应用的兼容性。然而，像下面这样的提示词在引导模型生成分层的 Markdown 最终答案方面基本上是成功的。 Code block Plain Text 仅在语义正确的地方 使用 Markdown（例如， ， ，列表，表格）。 在助手的消息中使用 Markdown 时，使用反引号来格式化文件、目录、函数和类名。使用 \( 和 \) 表示行内数学公式，\[ 和 \] 表示块级数学公式。 偶尔，在长对话过程中，对系统提示词中指定的 Markdown 指令的遵循度可能会下降。如果您遇到这种情况，我们发现每隔 3 5 条用户消息追加一次 Markdown 指令，可以保持一致的遵循度。 元提示 (Metaprompting) 最后，以一个元视角的观点来结束本指南：早期测试者发现使用 GPT 5 作为自身的“元提示器”取得了巨大成功。已经有几位用户部署了由 GPT 5 生成的提示词修订版本到生产环境中，这些修订版本仅仅是通过询问 GPT 5 “可以向一个不成功的提示词中添加哪些元素以引发期望的行为”，或“移除哪些元素以防止不期望的行为”而生成的。 以下是我们喜欢的一个元提示模板示例： Code block Plain Text 当被要求优化提示词时，请从你自己的角度给出答案——解释可以从这个提示词中添加或删除哪些具体短语，以更稳定地引发期望的行为或防止不期望的行为。 这是一个提示词：[PROMPT] 这个提示词期望的行为是让智能体 [执行期望的行为]，但它却 [执行了不期望的行为]。在尽可能保持现有提示词完整的前提下，你会做哪些最小的编辑/补充，以鼓励智能体更稳定地解决这些缺陷？ 附录 SWE Bench 验证的开发者指令 Code block Plain Text 在这个环境中，你可以运行 来对文件执行一个 diff/patch，其中 <apply patch command 是一个特殊格式的 apply patch 命令，代表你希望执行的 diff。一个有效的 <apply patch command 如下所示： apply patch << 'PATCH' Begin Patch [YOUR PATCH] End Patch PATCH 其中 [YOUR PATCH] 是你补丁的实际内容。 务必极其彻底地验证你的更改。你可以进行任意多次工具调用——用户非常有耐心，并且将正确性置于一切之上。在结束之前，请确保你 100% 确定你的解决方案是正确的。 重要提示：并非所有测试都在代码库中对你可见，所以即使在你认为相对直接的问题上，你也必须反复检查你的解决方案，以确保它们能通过隐藏测试中覆盖的任何边缘情况，而不仅仅是可见的测试。 匹配代码库的设计规范 在现有应用中实施增量更改和重构时，模型编写的代码应遵守现有的样式和设计规范，并尽可能“无缝融入”代码库。即使没有特别提示，GPT 5 也会主动从代码库中搜索参考上下文——例如读取 package.json 来查看已安装的依赖包——但这种行为可以通过提示词指令进一步增强。这些指令可以总结工程原则、目录结构以及代码库中显式和隐式的最佳实践等关键方面。下面的提示词片段展示了一种为 GPT 5 组织代码编辑规则的方式：您可以根据自己的编程设计品味随意修改规则的实际内容！ 生产环境中的协作编程：Cursor 对 GPT 5 的提示词调优 我们很荣幸，AI 代码编辑器 Cursor 成为了 GPT 5 值得信赖的 alpha 测试者。下面，我们将揭示 Cursor 如何调整其提示词以充分利用模型能力的内幕。更多信息，他们的团队也发表了一篇博客文章，详细介绍了 GPT 5 在 Cursor 中的首日集成：https://cursor.com/blog/gpt 5 系统提示词与参数调优 Cursor 的系统提示词侧重于实现可靠的工具调用，在详细程度和自主行为之间取得平衡，同时允许用户配置自定义指令。Cursor 对其系统提示词的目标是让智能体在长周期任务中能够相对自主地操作，同时仍然忠实地遵循用户提供的指令。 团队最初发现模型产生的输出很冗长，常常包含状态更新和任务后总结，这些内容虽然技术上相关，但会打断用户的自然工作流。同时，工具调用中输出的代码质量很高，但有时因过于简洁而难以阅读，例如普遍使用单字母变量名。为了寻求更好的平衡，他们将 verbosity (详细程度) API 参数设置为 low 以保持文本输出简洁，然后修改提示词，以强烈鼓励 仅在编程工具中 输出详细内容。 这种参数和提示词的双重运用，形成了一种平衡的格式，它将高效、简洁的状态更新和最终工作总结与更易于阅读的代码差异相结合。 Cursor 还发现，模型在采取行动前偶尔会向用户请求澄清或下一步指示，这在较长任务的流程中造成了不必要的阻碍。为了解决这个问题，他们发现，除了提供可用的工具和周围的上下文外，提供更多关于产品行为的细节，能鼓励模型以更少的干扰和更大的自主性执行更长的任务。强调 Cursor 功能的细节，如撤销/拒绝代码和用户偏好，通过明确指定 GPT 5 在其环境中应如何行为，帮助减少了模糊性。对于长周期任务，他们发现以下提示词提升了性能： Cursor 发现，他们之前对早期模型行之有效的提示词部分，需要进行调整才能充分利用 GPT 5 的潜力。以下是一个例子： 虽然这段提示词对于需要鼓励才能彻底分析上下文的旧模型效果很好，但他们发现它对 GPT 5 来说适得其反，因为 GPT 5 天生就具有自省和主动收集上下文的能力。在较小的任务上，这个提示词常常导致模型过度使用工具，重复调用搜索，而其内部知识本已足够。 为了解决这个问题，他们通过移除 maximize 前缀并软化关于“彻底性”的语言来完善提示词。调整后的指令实施后，Cursor 团队看到 GPT 5 在何时依赖内部知识与何时使用外部工具之间做出了更好的决策。它在保持高度自主性的同时，避免了不必要的工具使用，从而带来了更高效和相关的行为。在 Cursor 的测试中，使用像 <[instruction] spec 这样的结构化 XML 规范，提高了其提示词的指令遵循度，并允许他们在提示词的其他地方清晰地引用先前的类别和部分。 虽然系统提示词提供了一个强大的默认基础，但用户提示词仍然是实现可引导性的一个高效杠杆。GPT 5 对直接和明确的指令响应良好，Cursor 团队一致认为，结构化、范围明确的提示词能产生最可靠的结果。这包括详细程度控制、主观代码风格偏好和对边缘情况的敏感性等领域。Cursor 发现，允许用户配置他们自己的自定义 Cursor 规则在 GPT 5 改进的可引导性下尤其有效，为他们的用户提供了更定制化的体验。 优化智能与指令遵循 可引导性 (Steering) 作为我们迄今为止最具可引导性的模型，GPT 5 对围绕详细程度、语气和工具调用行为的提示词指令反应异常灵敏。 详细程度 (Verbosity) 除了像以前的推理模型一样能够控制 reasoning effort 之外，我们在 GPT 5 中引入了一个名为 verbosity 的新 API 参数，它影响模型 最终答案 的长度，而非其思考过程的长度。我们的博客文章更详细地介绍了这个参数背后的理念——但在这份指南中，我们想强调的是，虽然 API verbosity 参数是推广期间的默认设置，但 GPT 5 经过训练，能够响应提示词中特定上下文的自然语言详细程度覆盖指令。在这些上下文中，你可能希望模型偏离全局默认设置。上面 Cursor 的例子中，全局设置低详细程度，然后仅为编程工具指定高详细程度，就是这种上下文的一个典型例子。 指令遵循 与 GPT 4.1 一样，GPT 5 能够以“外科手术般”的精度遵循提示词指令，这使其能够灵活地融入所有类型的工作流程。然而，其严谨的指令遵循行为也意味着，包含矛盾或模糊指令的结构不良的提示词对 GPT 5 的损害可能比对其他模型更大，因为它会消耗推理令牌来试图调和这些矛盾，而不是随机选择一个指令来执行。 下面，我们给出了一个经常损害 GPT 5 推理轨迹的对抗性提示词示例——虽然它初看可能内部一致，但仔细检查会发现关于预约安排的指令存在冲突： • 在病历中没有记录明确的患者同意之前，绝不安排预约 与随后的 为降低风险，首要行动是自动分配当天最早的空档，无需联系患者 相冲突。 • 提示词说 在采取任何其他行动之前，始终查找患者资料以确保他们是现有患者 ，但接着又给出了矛盾的指令 当症状表明高度紧急时，立即升级为紧急情况，并指示患者在任何安排步骤之前立即拨打 911 。 通过解决指令层次结构中的冲突，GPT 5 能够产生更高效、更高性能的推理。我们通过以下方式修复了这些矛盾： • 将自动分配的行为改为在联系患者之后进行，即 在告知患者你的行动后，自动分配当天最早的空档 ，以与“仅在获得同意后安排预约”的原则保持一致。 • 添加 在紧急情况下，不要进行查找，立即提供 911 指导 ，让模型知道在紧急情况下可以跳过查找步骤。 我们理解构建提示词是一个迭代的过程，许多提示词是不断被不同利益相关者更新的“活文档”——但这更有理由去彻底审查它们，以发现措辞不当的指令。我们已经看到，多个早期用户在进行此类审查后，在其核心提示词库中发现了模糊和矛盾之处：移除它们极大地简化并改善了他们的 GPT 5 性能。我们建议在我们的提示词优化工具中测试您的提示词，以帮助识别这类问题。 最小推理 (Minimal reasoning) 在 GPT 5 中，我们首次引入了“最小推理强度”：这是我们最快的选项，同时仍能享有推理模型范式的好处。我们认为这是对延迟敏感型用户以及当前 GPT 4.1 用户的最佳升级路径。 也许不足为奇，我们建议采用与 GPT 4.1 相似的提示词模式以获得最佳结果。最小推理模式的性能随提示词的变化可能比更高推理级别更剧烈，因此需要强调的关键点包括： 1. 提示模型在最终答案的开头给出一个简短的解释（例如通过项目符号列表）来总结其思考过程，可以提高需要更高智能的任务的性能。 2. 请求详尽且描述性的工具调用前言，持续向用户更新任务进展，可以提高智能体工作流的性能。 3. 最大限度地消除工具指令的歧义，并插入如上文分享的智能体持久性提醒，在最小推理模式下对于最大化长时运行任务的智能体能力和防止过早终止尤为关键。 4. 提示驱动的规划同样更为重要，因为模型用于内部规划的推理令牌更少。下面，您可以看到我们放置在智能体任务开始处的一个示例规划提示词片段：特别是第二段，它确保智能体在将控制权交还给用户之前完全完成任务及其所有子任务。 Markdown 格式化 默认情况下，API 中的 GPT 5 不会以 Markdown 格式化其最终答案，以最大程度地保持与可能不支持 Markdown 渲染的开发者应用的兼容性。然而，像下面这样的提示词在引导模型生成分层的 Markdown 最终答案方面基本上是成功的。 代码块 偶尔，在长对话过程中，对系统提示词中指定的 Markdown 指令的遵循度可能会下降。如果您遇到这种情况，我们发现每隔 3 5 条用户消息追加一次 Markdown 指令，可以保持一致的遵循度。 元提示 (Metaprompting) 最后，以一个元视角的观点来结束本指南：早期测试者发现使用 GPT 5 作为自身的“元提示器”取得了巨大成功。已经有几位用户部署了由 GPT 5 生成的提示词修订版本到生产环境中，这些修订版本仅仅是通过询问 GPT 5 “可以向一个不成功的提示词中添加哪些元素以引发期望的行为”，或“移除哪些元素以防止不期望的行为”而生成的。 以下是我们喜欢的一个元提示模板示例： 附录 SWE Bench 验证的开发者指令 正如在 GPT 4.1 提示指南中分享的，这里是我们最新的 apply patch 实现：我们强烈建议使用 apply patch 进行文件编辑，以匹配训练分布。最新的实现应该在绝大多数情况下与 GPT 4.1 的实现相匹配。 Taubench Retail 最小推理指令 Terminal Bench 提示词 bash {"cmd": ["apply patch", "<<'EOF'\\n Begin Patch\\n[YOUR PATCH]\\n End Patch\\nEOF\\n"], "workdir": "..."} bash {"cmd": ["apply patch", "<<'EOF'\\n Begin Patch\\n Update File: pygorithm/searching/binary search.py\\n@@ class BaseClass\\n@@ def search():\\n pass\\n+ raise NotImplementedError()\\n@@ class Subclass\\n@@ def search():\\n pass\\n+ raise NotImplementedError()\\n End Patch\\nEOF\\n"], "workdir": "..."} 🔗 原文链接： https://mp.weixin.qq.com/s/GeWv JA5... https://mp.weixin.qq.com/s/GeWv JA5... 原创 云中江树 云中江树2025年08月08日 23:40 北京 原文链接： https://cookbook.openai.com/examples/gpt 5/gpt 5 prompting guide 可以先看要点总结，全文在下面。 01 要点总结 控制智能体自主性 降低自主性方法： • 切换到较低的 reasoning effort （推理强度） • 在提示词中为模型探索问题空间定义明确标准 • 设置固定工具调用预算 • 提供"逃生舱口"条款 提高自主性方法： • 提高 reasoning effort • 使用持续性提示词鼓励模型工作到完全解决问题 • 明确定义停止条件和安全行为边界 工具调用前言（Tool Preambles） • GPT 5支持通过"工具调用前言"提供清晰计划和进度更新 • 可在提示词中引导前言的频率、风格和内容 • 提供友好、清晰、简洁的目标重述和结构化计划 推理强度参数 • 提供 reasoning effort 参数控制思考深度 • 默认为 medium ，可根据任务难度调整 • 复杂多步骤任务建议使用更高推理强度 Responses API • 强烈推荐使用Responses API替代Chat Completions API • 可传回先前推理项，节省思维链令牌 • 实测TauBench Retail得分从73.9%提升到78.2% 最大化编程性能 前端应用开发 推荐技术栈： • 框架：Next.js (TypeScript), React, HTML • 样式/UI：Tailwind CSS, shadcn/ui, Radix Themes • 图标：Material Symbols, Heroicons, Lucide • 动画：Motion • 字体：San Serif, Inter, Geist等 从零到一应用生成： • 使用自我反思提示词建立评估标准 • 要求模型根据自建标准进行迭代执行 匹配代码库设计规范： • 提供工程原则、目录结构和最佳实践指导 • 使用结构化的代码编辑规则模板 Cursor的GPT 5提示词调优经验 系统提示词优化： • 将 verbosity 参数设为 low 保持简洁 • 在提示词中强调编程工具使用高详细程度 • 提供产品行为细节减少模糊性 关键发现： • 移除过度鼓励彻底性的提示词（如 maximize context understanding ） • 使用结构化XML规范提高指令遵循度 • 允许用户配置自定义规则 优化智能与指令遵循 可引导性（Steering） 详细程度控制： • 新增 verbosity API参数影响最终答案长度 • 支持提示词中的自然语言详细程度覆盖指令 指令遵循 关键原则： • GPT 5具有"外科手术般"精度的指令遵循 • 矛盾或模糊指令会消耗推理令牌 • 需要彻底审查提示词发现措辞不当的指令 最小推理模式 适用场景： • 延迟敏感型用户 • GPT 4.1用户的最佳升级路径 优化建议： • 在最终答案开头提供简短解释 • 请求详尽的工具调用前言 • 最大化消除工具指令歧义 • 强化提示驱动的规划 Markdown格式化 • 默认不使用Markdown格式 • 可通过特定提示词引导生成分层Markdown • 长对话中需要定期追加Markdown指令 元提示（Metaprompting） • 使用GPT 5作为自身的"元提示器" • 询问模型如何添加或删除提示词元素 • 多位用户已将GPT 5生成的提示词修订版部署到生产环境 附录 包含了SWE Bench验证、智能体编程工具定义、Taubench Retail指令和Terminal Bench提示词等具体实现细节和完整的工具函数定义。 02 全文翻译 GPT 5 作为我们最新的旗舰模型，在智能体任务性能、编程能力、原始智能和可引导性方面均实现了重大飞跃。 我们相信它在各种应用场景下都能“开箱即用”，表现出色。但在这份指南中，我们将分享一些旨在最大化模型输出质量的提示技巧，这些技巧源于我们训练模型并将其应用于真实世界任务的宝贵经验。我们将深入探讨如何提升智能体任务性能、确保指令遵循、运用全新的 API 功能，以及为前端和软件工程任务优化编程等概念，并重点分享 AI 代码编辑器 Cursor 在 GPT 5 提示词调优方面的关键见解。 我们发现，通过应用这些最佳实践并尽可能采用我们的标准工具，模型性能得到了显著提升。我们希望本指南以及我们构建的提示词优化工具，能成为您驾驭 GPT 5 的起点。但请始终牢记，提示工程并非一刀切的实践——我们鼓励您在本文提供的基础上不断实验和迭代，以找到解决您特定问题的最佳方案。 智能体工作流的可预测性 我们在训练 GPT 5 时充分考虑了开发者的需求：我们专注于改进工具调用、指令遵循和长上下文理解能力，使其成为构建智能体应用的最佳基础模型。若要将 GPT 5 用于智能体和工具调用流程，我们建议升级至 Responses API，该 API 能够在工具调用之间持久化推理过程，从而实现更高效、更智能的输出。 控制智能体的“自主性” 智能体的控制框架千差万别——有些系统将绝大部分决策权委托给底层模型，而另一些系统则通过大量的程序化逻辑分支对模型进行严格约束。GPT 5 经过训练，能够胜任这一范围内的任何工作，无论是处理模糊情况下的高层决策，还是执行专注且明确定义的任务。在本节中，我们将介绍如何最好地校准 GPT 5 的智能体自主性（Agentic Eagerness）：换言之，即它在主动性和等待明确指令之间的平衡。 引导模型降低自主性 默认情况下，GPT 5 在智能体环境中会详尽全面地收集上下文，以确保给出最准确的答案。要缩小 GPT 5 智能体行为的范围——包括限制不相关的工具调用和减少获得最终答案的延迟——请尝试以下方法： • 切换到较低的 reasoning effort (推理强度)。这会降低探索深度，但能提高效率和响应速度。许多工作流在 medium (中等) 甚至 low (低) 推理强度下也能获得一致的优异结果。 • 在提示词中为模型如何探索问题空间定义明确的标准。这可以减少模型探索和思考过多路径的需求： 如果你希望提供最大程度的规定性，你甚至可以设置固定的工具调用预算，如下所示。预算可以根据你期望的搜索深度自然地调整。 在限制核心上下文收集行为时，明确为模型提供一个“逃生舱口”会很有帮助，这使它更容易满足较短的上下文收集步骤。这通常以条款的形式出现，允许模型在不确定性下继续前进，例如上述示例中的“即使它可能不完全正确”。 引导模型提高自主性 另一方面，如果你想鼓励模型自主行动、增强工具调用的持久性，并减少澄清性问题或将控制权交还给用户的情况，我们建议提高 reasoning effort ，并使用如下提示词来鼓励持久且彻底地完成任务： 总而言之，清晰地说明智能体任务的停止条件、勾勒出安全与不安全的行为，并定义何时（以及是否）可以接受模型将控制权交还给用户，这些都大有裨益。例如，在一套购物工具中，对于结账和支付工具，需要用户澄清的不确定性阈值应明确设置得更低；而对于搜索工具，该阈值则应极高。同样，在编程环境中，删除文件工具的阈值应远低于 grep 搜索工具。 工具调用前言 (Tool Preambles) 我们认识到，在由用户监控的智能体任务轨迹中，模型间歇性地更新其工具调用的内容及原因，可以提供更佳的交互式用户体验——任务执行的时间越长，这些更新带来的价值就越大。为此，GPT 5 经过训练，能够通过“工具调用前言”消息提供清晰的前期计划和一致的进度更新。 你可以在提示词中引导工具调用前言的频率、风格和内容——从对每个工具调用的详细解释，到简短的前期计划，乃至介于两者之间的任何形式。这是一个高质量前言提示词的示