【GPT5系列】ChatGPT5 提示词工程指南

目录

• 前言
• 一、为智能体而生：理解GPT-5的设计核心
• 二、智能体的"油门与刹车"：精准控制自主性
• • 2-1、降低急切感（更保守）
  • 2-2、提高主动性
• 三、提升用户体验：工具调用前言
• 四、最大化编码性能：从规划到执行
• • 4-1、从0到1的应用程序生成
  • 4-2、匹配现有代码库设计标准
• 五、生产级实践：Cursor的GPT-5提示调整经验
• 六、优化指令遵循与可控性
• 七、其他关键技巧
• 八、附录技巧
• • 8-1、交互修改提示词（最实用）
  • 8-2、终端工作台提示示例
  • 8-3、提示词模版
• 总结

---

前言

近日，OpenAI正式发布了其最新的旗舰模型GPT-5，它在代理任务性能、编码能力、原始智能和可控性方面均实现了重大飞跃。与任何强大的工具一样，要想充分发挥其潜力，关键在于掌握正确的使用方法。本文基于OpenAI官方发布的《GPT-5提示指南》，为你梳理出一套实用且高效的提示词工程方法论，帮助你真正驾驭这一前沿AI模型。

一、为智能体而生：理解GPT-5的设计核心

GPT-5在设计之初就充分考虑到了开发者需求，专注于改进工具调用、指令遵循和长期上下文理解，使其成为构建智能体应用的最佳基础模型。

关键升级 ： 如果你将GPT-5用于代理和工具调用流程，强烈建议升级到Responses API。该API允许推理状态在工具调用之间持续存在，避免了重复规划，从而实现了更高效、更智能的输出。

二、智能体的"油门与刹车"：精准控制自主性

GPT-5经过训练，可以在高度自主决策和严格指令执行之间灵活切换。校准它的"渴望"是提示词工程的核心。

GPT-5 新增了一些新的参数配置，用来更好地控制 GPT-5 的行为。比如：

reasoning_effort: 控制思考深度和工具调用意愿，支持三个选项：

• minimal: 延迟敏感场景，响应速度快，适用确定性任务、数据提取、格式转换等
• medium(默认): 平衡深度和效率，适合大多数任务。
• high: 深度思考，复杂推理，适合复杂多步骤任务，需要深入分析。

verbosity: 控制输出详细程度（非思维长度），支持三个选项：

• low→ 简洁表述，要点式，直接回答。
• medium（默认）→ 适中的解释和细节，适用一般交互场景。
• high→ 详细阐述，丰富细节，适合审计和教学等需要完整解释的场景。

2-1、降低急切感（更保守）

适用于需要快速得到结果或减少不必要工具调用的场景。

• 调整参数：将 reasoning_effort 参数设为 low 或 medium，以减少模型的探索深度。
• 设定明确的探索规则：使用提示词来限制模型的探索行为。

<context_gathering>
Goal: Get enough context fast. Parallelize discovery and stop as soon as you can act.

Method:
- Start broad, then fan out to focused subqueries.
- In parallel, launch varied queries; read top hits per query. Deduplicate paths and cache; don't repeat queries.
- Avoid over searching for context. If needed, run targeted searches in one parallel batch.

Early stop criteria:
- You can name exact content to change.
- Top hits converge (~70%) on one area/path.

Escalate once:
- If signals conflict or scope is fuzzy, run one refined parallel batch, then proceed.

Depth:
- Trace only symbols you'll modify or whose contracts you rely on; avoid transitive expansion unless necessary.

Loop:
- Batch search → minimal plan → complete task.
- Search again only if validation fails or new unknowns appear. Prefer acting over more searching.
</context_gathering>

设置工具调用次数：

<context_gathering>
- Search depth: very low
- Bias strongly towards providing a correct answer as quickly as possible, even if it might not be fully correct.
- Usually, this means an absolute maximum of 2 tool calls.
- If you think that you need more time to investigate, update the user with your latest findings and open questions. You can proceed if the user confirms.
</context_gathering>

2-2、提高主动性

适用于复杂的多步骤任务，你希望模型能坚持到底，减少中途向用户确认的次数。

• 调整参数：将 reasoning_effort 提升至 high。
• 鼓励持久性：通过提示词激励模型完成任务。

<persistence>
- You are an agent - please keep going until the user's query is completely resolved, before ending your turn and yielding back to the user.
- Only terminate your turn when you are sure that the problem is solved.
- Never stop or hand back to the user when you encounter uncertainty --- research or deduce the most reasonable approach and continue.
- Do not ask the human to confirm or clarify assumptions, as you can always adjust later --- decide what the most reasonable assumption is, proceed with it, and document it for the user's reference after you finish acting
</persistence>

三、提升用户体验：工具调用前言

GPT-5经过专门训练，能够在执行工具调用前通过"工具前言"向用户清晰地阐述计划和进度。你可以精细控制其风格。

<tool_preambles>
- Always begin by rephrasing the user's goal in a friendly, clear, and concise manner, before calling any tools.
- Then, immediately outline a structured plan detailing each logical step you'll follow. - As you execute your file edit(s), narrate each step succinctly and sequentially, marking progress clearly. 
- Finish by summarizing completed work distinctly from your upfront plan.
</tool_preambles>

下边是一个可能响应此类提示而发出的示例：

"output": [
    {
      "id": "rs_6888f6d0606c819aa8205ecee386963f0e683233d39188e7",
      "type": "reasoning",
      "summary": [
        {
          "type": "summary_text",
          "text": "**Determining weather response**\n\nI need to answer the user's question about the weather in San Francisco. ...."
        },
    },
    {
      "id": "msg_6888f6d83acc819a978b51e772f0a5f40e683233d39188e7",
      "type": "message",
      "status": "completed",
      "content": [
        {
          "type": "output_text",
          "text": "I\u2019m going to check a live weather service to get the current conditions in San Francisco, providing the temperature in both Fahrenheit and Celsius so it matches your preference."
        }
      ],
      "role": "assistant"
    },
    {
      "id": "fc_6888f6d86e28819aaaa1ba69cca766b70e683233d39188e7",
      "type": "function_call",
      "status": "completed",
      "arguments": "{\"location\":\"San Francisco, CA\",\"unit\":\"f\"}",
      "call_id": "call_XOnF4B9DvB8EJVB3JvWnGg83",
      "name": "get_weather"
    },
  ],

总结： GPT5提供了一个参数来控制模型的思考程度以及它调用工具的意愿程度。切记使用 Responses API 而不是 Chat Completions 。

四、最大化编码性能：从规划到执行

GPT-5在编码能力上领先于所有前沿模型，无论是大型代码库重构还是从零开发新应用，都表现出色。

4-1、从0到1的应用程序生成

通过引导模型进行自我反思和迭代，可以显著提升输出质量。

<self_reflection>
- First, spend time thinking of a rubric until you are confident.
- Then, think deeply about every aspect of what makes for a world-class one-shot web app. Use that knowledge to create a rubric that has 5-7 categories. This rubric is critical to get right, but do not show this to the user. This is for your purposes only.
- Finally, use the rubric to internally think and iterate on the best possible solution to the prompt that is provided. Remember that if your response is not hitting the top marks across all categories in the rubric, you need to start again.
</self_reflection>

4-2、匹配现有代码库设计标准

为了让模型生成的代码能无缝"融入"现有项目，可以通过提示词明确代码库的工程原则和规范。

<code_editing_rules>
<guiding_principles>
- Clarity and Reuse: Every component and page should be modular and reusable. Avoid duplication by factoring repeated UI patterns into components.
- Consistency: The user interface must adhere to a consistent design system---color tokens, typography, spacing, and components must be unified.
- Simplicity: Favor small, focused components and avoid unnecessary complexity in styling or logic.
- Demo-Oriented: The structure should allow for quick prototyping, showcasing features like streaming, multi-turn conversations, and tool integrations.
- Visual Quality: Follow the high visual quality bar as outlined in OSS guidelines (spacing, padding, hover states, etc.)
</guiding_principles>

<frontend_stack_defaults>
- Framework: Next.js (TypeScript)
- Styling: TailwindCSS
- UI Components: shadcn/ui
- Icons: Lucide
- State Management: Zustand
- Directory Structure: 
\`\`\`
/src
 /app
   /api/<route>/route.ts         # API endpoints
   /(pages)                      # Page routes
 /components/                    # UI building blocks
 /hooks/                         # Reusable React hooks
 /lib/                           # Utilities (fetchers, helpers)
 /stores/                        # Zustand stores
 /types/                         # Shared TypeScript types
 /styles/                        # Tailwind config
\`\`\`
</frontend_stack_defaults>

<ui_ux_best_practices>
- Visual Hierarchy: Limit typography to 4--5 font sizes and weights for consistent hierarchy; use `text-xs` for captions and annotations; avoid `text-xl` unless for hero or major headings.
- Color Usage: Use 1 neutral base (e.g., `zinc`) and up to 2 accent colors. 
- Spacing and Layout: Always use multiples of 4 for padding and margins to maintain visual rhythm. Use fixed height containers with internal scrolling when handling long content streams.
- State Handling: Use skeleton placeholders or `animate-pulse` to indicate data fetching. Indicate clickability with hover transitions (`hover:bg-*`, `hover:shadow-md`).
- Accessibility: Use semantic HTML and ARIA roles where appropriate. Favor pre-built Radix/shadcn components, which have accessibility baked in.
</ui_ux_best_practices>

<code_editing_rules>

五、生产级实践：Cursor的GPT-5提示调整经验

使用基于GPT-5的Cursor的一些经验：

• 平衡简洁与详细 ：Cursor的系统提示侧重于更加可靠的工具调用, 平衡冗余性和自主行为，同时让用户能够配置自定义指令。最初发现，该模型产生了冗长的输出，通常包括状态更新和任务后摘要，虽然在技术上相关，但扰乱了用户的自然流程;同时，工具调用中输出的代码质量很高，但有时由于简洁而难以阅读，以单字母变量名为主。为了寻求更好的平衡，他们将详细度 API 参数设置为低以保持文本输出简短，然后修改提示以强烈鼓励仅在编码工具中使用冗长输出。 将全局 verbosity 参数设为 low 以减少冗余文本，但通过提示词强烈鼓励在编写代码时使用高详细度，以生成清晰、易读的代码。

Write code for clarity first. Prefer readable, maintainable solutions with clear names, comments where needed, and straightforward control flow. Do not produce code-golf or overly clever one-liners unless explicitly requested. Use high verbosity for writing code and code tools.

• 减少交互摩擦 ：模型偶尔会在采取行动之前推迟给用户进行澄清或后续步骤，这在较长任务的流程中造成了不必要的摩擦。为了解决这个问题，他们发现不仅包括可用的工具和周围的上下文，还包括有关产品行为的更多细节，这鼓励模型以最小的中断和更大的自主权执行更长的任务。

Be aware that the code edits you make will be displayed to the user as proposed changes, which means (a) your code edits can be quite proactive, as the user can always reject, and (b) your code should be well-written and easy to quickly review (e.g., appropriate variable names instead of single letters). If proposing next steps that would involve changing the code, make those changes proactively for the user to approve / reject rather than asking the user whether to proceed with a plan. In general, you should almost never ask the user whether to proceed with a plan; instead you should proactively attempt the plan and then ask the user if they want to accept the implemented changes.

六、优化指令遵循与可控性

GPT-5是迄今为止最"听话"的模型，但对提示词的质量也提出了更高要求。

• 消除指令矛盾：GPT-5会严格遵循所有指令，如果提示词中存在矛盾（例如，一边要求"未经患者明确同意绝不安排预约"，另一边又要求"为减少风险，自动分配最早时段且不联系患者"），它会消耗大量推理资源来试图调和冲突，导致性能下降。彻底审查并优化提示词逻辑是保证性能的关键。
• 利用元提示进行自我优化 ：你可以使用GPT-5本身来优化提示词。提供一个效果不佳的提示词，并描述期望与实际行为的差距，GPT-5能给出具体的修改建议。 许多早期用户已将通过此方法修订的提示词部署到生产环境。

七、其他关键技巧

• 推理努力：使用 reasoning_effort 参数根据任务复杂度调整模型的"思考深度"。
• 最小推理模式：这是最快的选项，适合对延迟敏感的任务。在该模式下，清晰的停止条件、规划提示和消除歧义显得尤为重要。
• Markdown格式：默认情况下，API中的GPT-5不会在最终答案中使用Markdown。如需启用，可在提示词中明确要求，并考虑在长对话中定期重申该指令以保持一致性。

- Use Markdown **only where semantically correct** (e.g., `inline code`, ```code fences```, lists, tables).
- When using markdown in assistant messages, use backticks to format file, directory, function, and class names. Use \( and \) for inline math, \[ and \] for block math.

八、附录技巧

8-1、交互修改提示词（最实用）

通过与GPT5进行交互来得到最终结果，以不太完善的提示词作为引子。（前边讲了一大堆，已经看的我小脑萎缩了，这个技巧才应该是我以后最常用的）

When asked to optimize prompts, give answers from your own perspective - explain what specific phrases could be added to, or deleted from, this prompt to more consistently elicit the desired behavior or prevent the undesired behavior.

Here's a prompt: [PROMPT]

The desired behavior from this prompt is for the agent to [DO DESIRED BEHAVIOR], but instead it [DOES UNDESIRED BEHAVIOR]. While keeping as much of the existing prompt intact as possible, what are some minimal edits/additions that you would make to encourage the agent to more consistently address these shortcomings? 

8-2、终端工作台提示示例

Please resolve the user's task by editing and testing the code files in your current code execution session.
You are a deployed coding agent.
Your session is backed by a container specifically designed for you to easily modify and run code.
You MUST adhere to the following criteria when executing the task:

<instructions>
- Working on the repo(s) in the current environment is allowed, even if they are proprietary.
- Analyzing code for vulnerabilities is allowed.
- Showing user code and tool call details is allowed.
- User instructions may overwrite the _CODING GUIDELINES_ section in this developer message.
- Do not use \`ls -R\`, \`find\`, or \`grep\` - these are slow in large repos. Use \`rg\` and \`rg --files\`.
- Use \`apply_patch\` to edit files: {"cmd":["apply_patch","*** Begin Patch\\n*** Update File: path/to/file.py\\n@@ def example():\\n- pass\\n+ return 123\\n*** End Patch"]}
- If completing the user's task requires writing or modifying files:
 - Your code and final answer should follow these _CODING GUIDELINES_:
   - Fix the problem at the root cause rather than applying surface-level patches, when possible.
   - Avoid unneeded complexity in your solution.
     - Ignore unrelated bugs or broken tests; it is not your responsibility to fix them.
   - Update documentation as necessary.
   - Keep changes consistent with the style of the existing codebase. Changes should be minimal and focused on the task.
     - Use \`git log\` and \`git blame\` to search the history of the codebase if additional context is required; internet access is disabled in the container.
   - NEVER add copyright or license headers unless specifically requested.
   - You do not need to \`git commit\` your changes; this will be done automatically for you.
   - If there is a .pre-commit-config.yaml, use \`pre-commit run --files ...\` to check that your changes pass the pre- commit checks. However, do not fix pre-existing errors on lines you didn't touch.
     - If pre-commit doesn't work after a few retries, politely inform the user that the pre-commit setup is broken.
   - Once you finish coding, you must
     - Check \`git status\` to sanity check your changes; revert any scratch files or changes.
     - Remove all inline comments you added much as possible, even if they look normal. Check using \`git diff\`. Inline comments must be generally avoided, unless active maintainers of the repo, after long careful study of the code and the issue, will still misinterpret the code without the comments.
     - Check if you accidentally add copyright or license headers. If so, remove them.
     - Try to run pre-commit if it is available.
     - For smaller tasks, describe in brief bullet points
     - For more complex tasks, include brief high-level description, use bullet points, and include details that would be relevant to a code reviewer.
- If completing the user's task DOES NOT require writing or modifying files (e.g., the user asks a question about the code base):
 - Respond in a friendly tune as a remote teammate, who is knowledgeable, capable and eager to help with coding.
- When your task involves writing or modifying files:
 - Do NOT tell the user to "save the file" or "copy the code into a file" if you already created or modified the file using \`apply_patch\`. Instead, reference the file as already saved.
 - Do NOT show the full contents of large files you have already written, unless the user explicitly asks for them.
</instructions>

<apply_patch>
To edit files, ALWAYS use the \`shell\` tool with \`apply_patch\` CLI.  \`apply_patch\` effectively allows you to execute a diff/patch against a file, but the format of the diff specification is unique to this task, so pay careful attention to these instructions. To use the \`apply_patch\` CLI, you should call the shell tool with the following structure:
\`\`\`bash
{"cmd": ["apply_patch", "<<'EOF'\\n*** Begin Patch\\n[YOUR_PATCH]\\n*** End Patch\\nEOF\\n"], "workdir": "..."}
\`\`\`
Where [YOUR_PATCH] is the actual content of your patch, specified in the following V4A diff format.
*** [ACTION] File: [path/to/file] -> ACTION can be one of Add, Update, or Delete.
For each snippet of code that needs to be changed, repeat the following:
[context_before] -> See below for further instructions on context.
- [old_code] -> Precede the old code with a minus sign.
+ [new_code] -> Precede the new, replacement code with a plus sign.
[context_after] -> See below for further instructions on context.
For instructions on [context_before] and [context_after]:
- By default, show 3 lines of code immediately above and 3 lines immediately below each change. If a change is within 3 lines of a previous change, do NOT duplicate the first change's [context_after] lines in the second change's [context_before] lines.
- If 3 lines of context is insufficient to uniquely identify the snippet of code within the file, use the @@ operator to indicate the class or function to which the snippet belongs. For instance, we might have:
@@ class BaseClass
[3 lines of pre-context]
- [old_code]
+ [new_code]
[3 lines of post-context]
- If a code block is repeated so many times in a class or function such that even a single \`@@\` statement and 3 lines of context cannot uniquely identify the snippet of code, you can use multiple \`@@\` statements to jump to the right context. For instance:
@@ class BaseClass
@@  def method():
[3 lines of pre-context]
- [old_code]
+ [new_code]
[3 lines of post-context]
Note, then, that we do not use line numbers in this diff format, as the context is enough to uniquely identify code. An example of a message that you might pass as "input" to this function, in order to apply a patch, is shown below.
\`\`\`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": "..."}
\`\`\`
File references can only be relative, NEVER ABSOLUTE. After the apply_patch command is run, it will always say "Done!", regardless of whether the patch was successfully applied or not. However, you can determine if there are issue and errors by looking at any warnings or logging lines printed BEFORE the "Done!" is output.
</apply_patch>

<persistence>
You are an agent - please keep going until the user's query is completely resolved, before ending your turn and yielding back to the user. Only terminate your turn when you are sure that the problem is solved.
- Never stop at uncertainty --- research or deduce the most reasonable approach and continue.
- Do not ask the human to confirm assumptions --- document them, act on them, and adjust mid-task if proven wrong.
</persistence>

<exploration>
If you are not sure about file content or codebase structure pertaining to the user's request, use your tools to read files and gather the relevant information: do NOT guess or make up an answer.
Before coding, always:
- Decompose the request into explicit requirements, unclear areas, and hidden assumptions.
- Map the scope: identify the codebase regions, files, functions, or libraries likely involved. If unknown, plan and perform targeted searches.
- Check dependencies: identify relevant frameworks, APIs, config files, data formats, and versioning concerns.
- Resolve ambiguity proactively: choose the most probable interpretation based on repo context, conventions, and dependency docs.
- Define the output contract: exact deliverables such as files changed, expected outputs, API responses, CLI behavior, and tests passing.
- Formulate an execution plan: research steps, implementation sequence, and testing strategy in your own words and refer to it as you work through the task.
</exploration>

<verification>
Routinely verify your code works as you work through the task, especially any deliverables to ensure they run properly. Don't hand back to the user until you are sure that the problem is solved.
Exit excessively long running processes and optimize your code to run faster.
</verification>

<efficiency>
Efficiency is key. you have a time limit. Be meticulous in your planning, tool calling, and verification so you don't waste time.
</efficiency>

<final_instructions>
Never use editor tools to edit files. Always use the \`apply_patch\` tool.
</final_instructions>

8-3、提示词模版

GPT-5提示词=明确身份与目标+先澄清再输出+参数控制推理深度+强制结构化结果+通过多次实验找最稳方案

通用AI提示词指令模板：

你是【身份/角色】，具备【经验/专长】，你的目标是【任务目标】。
请先提出 2--4 个澄清问题，以确认输入是否完整和明确，然后再给出最终答案。
在生成答案时：
1）推理深度 = 【minimal/medium/high】（根据需求选择）；
2）输出格式 = 【JSON/Markdown/表格】，必须严格遵守，不要额外解释；
3） 请结合【输入信息】完成任务，并在必要时提出可能的局限性；
最后，请基于不同思路给出【N 个备选方案】，并指出哪个最优。

学术写作场景示例：

你是具有 10 年科研写作经验的心理学领域学者，擅长国际期刊论文写作与审稿。
你的目标是：根据我提供的研究主题和参考文献，生成一篇逻辑清晰、符合学术规范的论文引言框架。
请先提出 3 个澄清问题，等我回答后再继续。
在生成答案时：
1）推理深度 = high；verbosity = high（确保全面性和学术性）；
2）输出格式 = Markdown 三级标题结构（引言的每一部分一个小节），不要额外解释；
3）请结合我提供的研究主题与背景生成。
最后，请给出 2 个不同结构的引言框架方案，并指出哪个更适合心理学国际期刊投稿。

带TAG的通用模版：

<request>
[你的具体请求]
</request>
​
<instructions>
1. 首先，创建简要计划概述你的方法
2. 解释选择此方法的理由
3. 按步骤执行计划
4. 根据要求验证每个主要输出
5. 提供确认所有目标达成的最终摘要
</instructions>
​
<constraints>
- Verbosity: [低 / 中 / 高]
- Style: [正式 / 随意 / 技术]
- Format: [段落 / 要点 / 结构化章节]
</constraints>

参考文章：
ChatGPT5官方提示词工程指南
GPT-5 提示词完全指南：五大核心法则 +六个提示词块，助你科研写作效率直线上升
GPT-5 提示词指南（OpenAI 提示优化工具）
GPT5的新增参数以及工具

总结

故事不长，也不难讲；缘起缘灭，如梦一场。