For the complete documentation index, see llms.txt. Markdown versions of documentation pages are available by appending .md to the page URL.
主导航

建议

GPT-Live

Realtime API

构建语音应用

连接

音频处理

API Dashboard
试用 ChatGPT

为 Realtime 模型编写提示词

为 Realtime 语音模型设计和测试提示词。

请选择您用于开发的 Realtime 模型。如果使用 GPT-Live，请参阅为 GPT-Live 编写提示词。

gpt-realtime-2 是我们最先进的推理语音模型，适用于低延迟的语音到语音应用。它能够在说话前进行思考，与早期的实时模型相比，能更可靠地遵循指令、使用更大的上下文窗口，并更精准地调用工具。

要充分利用这些改进，您需要更有针对性地设计提示。明确助手的职责、决策点、工具调用行为和护栏：应该做什么、何时执行，以及应该避免什么。

从简单开始，不要一开始就在提示中加入过多要求。先使用最简提示，运行评估，然后仅针对测试中未达标的行为补充指令。

选择模型

模型 适用场景 提示编写重点
gpt-realtime-2

您需要最强的实时推理、工具使用和指令遵循能力。

调整推理强度、前置说明、工具策略、实体的精确采集和长会话状态管理。

gpt-realtime-1.5您需要快速、可靠的非推理语音到语音模型。

遵循实时交互提示词的基本结构，并测试对延迟敏感的行为。

Realtime 2.0 提示词指南

当语音智能体需要更强的推理、工具选择、 精确实体处理或长会话状态管理能力时，请使用 gpt-realtime-2。 先从 reasoning.effort: "low" 开始，测试默认的前置说明行为， 并明确执行写入操作前哪些情况需要确认。

Realtime 2 有哪些变化

为 Realtime 2 编写提示时，应将它视为具备推理能力的语音智能体，而不是基础语音机器人。

变化对提示编写的影响
推理处理复杂任务时，允许模型在开口或调用工具前进行内部推理。使用前置说明，避免尴尬的沉默或不必要的填充语。
提示的精确性更为重要将“提供帮助”这类宽泛的指导替换为明确的触发条件、操作和例外规则：何时行动、做什么，以及何时不应执行。
指令冲突的代价更高除非确有必要，否则请移除相互重叠的 always、never、only 和 must 规则。当规则相互冲突时，明确其优先级。
工具使用行为更易引导明确助手在什么情况下应立即行动、询问缺失的信息、确认需要高度精确的细节、失败后重试，或升级处理。
前置说明成为核心行为在较长的推理或工具使用流程开始前，模型可能会用简短的语音说明进展。请明确何时应提供前置说明、应简短到什么程度，以及何时应跳过。
更大的上下文窗口gpt-realtime-2 将实时上下文窗口从 32k 扩展到 128k Token，使其更适合长会话和更大的系统提示。

前置说明并不是隐藏的思维链，而是简短的语音进展说明，例如“我现在查一下那笔订单。”不要要求模型披露私有推理过程。

推荐的提示结构

使用带有明确标题的简短章节，让模型能够快速找到相关指令。

# Role and Objective

# Personality and Tone

# Language

# Reasoning

# Message Channels

# Preambles

# Verbosity

# Tools

# Unclear Audio

# Entity Capture

# Long Context Behavior

# Escalation

并非每种用例都需要所有章节。请添加与您的产品相关的章节。

设置推理强度

gpt-realtime-2 可以通过增加延迟来进行更深入的推理。请在确保助手具备完成工作流程所需智能的前提下，使用尽可能低的推理级别。

对于大多数生产环境中的语音智能体，请从 low 开始。根据任务复杂度、延迟容忍度和失败成本调高或调低。

推理强度适用场景示例
minimal任务简单，且最低延迟最为重要。智能家居指令、计时器、简单的日历查询。
low您需要兼顾响应速度和基本推理能力。客户支持、订单查询、简单的政策问题。
medium助手必须通过推理完成多步骤任务。技术支持、诊断、复杂路由。
high更深入的推理能显著提高成功率。高精度工作流、升级处理决策、有约束条件的任务。
xhigh最充分的推理值得付出额外的延迟和成本。复杂规划、关键问题分诊、涉及重大后果的工具编排。

除了 API 设置，还应引导模型何时推理，以及推理到什么程度。

## Reasoning

- For direct answers, simple lookups, and short confirmations, respond quickly and do not reason.
- For multi-step tasks, tool decisions, troubleshooting, or escalation, reason before acting.
- Do not perform extended reasoning when the user's audio is unclear; ask for clarification instead.

有针对性地使用前置说明

前置说明是简短的语音进展说明，让语音智能体在推理、查询信息或调用工具时，仍能让用户感到响应及时。使用得当，它们能让用户放心，知道助手正在处理任务。使用不当，它们就会变成填充语，让用户觉得等待时间更长。

gpt-realtime-2 默认会生成前置说明。请先测试默认行为。如果不符合您的产品体验要求，再对其进行明确调整。

前置说明的生成与播放时间线

## Preambles

Use short preambles only when they help the user understand that work is happening.

### When to use a preamble

Use a preamble when:

- you are about to call a tool that may take noticeable time;
- you need to reason through a multi-step request;
- you are checking records, availability, account state, or policy details;
- you are preparing an escalation or handoff;
- silence would make the assistant feel unresponsive.

When a preamble is needed, output it immediately before substantive reasoning or tool use.

### When to not use a preamble

Do not use a preamble when:

- the answer is direct and can be given immediately;
- the user is only confirming, correcting, or declining something;
- the audio is unclear and you need clarification;
- the latest audio is silence, background noise, hold music, TV audio, or side conversation;
- the tool call is lightweight and the user would not benefit from an update.

### Preamble style

When using a preamble:

- keep it natural, calm, and concise;
- vary the wording across turns;
- describe the action, not the internal reasoning;
- avoid filler.

Avoid phrases like:

- "Let me think..."
- "Hmm..."
- "One moment while I process that..."
- "I am now going to access the tool..."

### Preamble length

Use one short sentence.

Do not exceed two short sentences unless the user needs an explanation before a high-impact action.

### Prefer

- "I'll check that order now."
- "I'll look up your appointment details."
- "I'll verify that before we make any changes."
- "I'll check the policy and then give you the next step."
- "I'll pull that up so we can make sure it's the right account."

### Avoid

- "Let me think about that for a second."
- "Please wait while I process your request."
- "I'm going to use my tools now."
- "Interesting question. I will reason through this carefully."

控制回复长度

当提示明确规定每类任务需要提供多少细节时，gpt-realtime-2 最能遵循长度要求。不要只告诉模型“保持简洁”，而应结合具体情境定义何为简洁：直接回答、工具结果、故障排除、对比和升级处理可能分别需要不同的回复长度。

## Verbosity

- Direct answers: Use 1-2 short sentences.
- Clarifying questions: Ask one question at a time.
- Tool results: Summarize the result first, then give only the next useful action.
- Product or option comparisons: Include key differences, tradeoffs, and who each option fits.
- Troubleshooting: Give one step at a time unless the user asks for the full procedure.
- Escalations: Briefly explain why escalation is needed and what will happen next.

示例：

用户：我应该选择哪个套餐？

助手：如果您希望成本最低，请选择 Basic。如果您需要团队权限和统一计费，请选择 Pro。如果您重视合规审查或管理控制功能，请选择企业版。

设计工具行为

gpt-realtime-2 的工具调用能力更强，但工具行为仍取决于提示和工具规范的设计。如果提示未明确何时执行操作、提问、确认或从失败中恢复，助手可能会过早调用工具、提出不必要的问题，或重复失败的调用。

设置工具调用的积极程度

对于只读、低风险的操作，较高的调用积极程度很适合。当工具会修改数据、产生外部影响或依赖精确标识符时，较低的调用积极程度更合适。

工具类型默认行为
只读、低风险查询在意图和必填字段明确时调用。
依赖精确标识符的只读操作查询前确认标识符。
用户可见的通信发送前先起草或概述内容。
账户变更调用前确认。
购买、取消、付款调用前确认金额、操作对象和后果。
不可逆或影响重大的操作明确确认，并在适当时提供升级处理的选项。

当您的操作同时涉及读取和写入时，可采用这一兼顾两者的默认策略，并根据您的使用场景进行调整。

## Tools

Use only the tools explicitly provided in the current tool list. Do not invent, assume, simulate, or rename tools.

For read-only tools:

- Call the tool when the user's intent is clear and all required fields are available.
- Do not ask for confirmation unless the lookup depends on a high-precision identifier or there is meaningful risk of using the wrong record.
- Ask a clarification question only if a required field is missing, ambiguous, or conflicting.

For write tools or external actions:

- Summarize the intended action before calling the tool.
- Include the key consequence, such as what will be changed, sent, canceled, ordered, or charged.
- Ask for confirmation.
- Do not call the tool until the user clearly confirms.

For exact identifiers:

- Treat order IDs, tracking numbers, account numbers, confirmation codes, phone numbers, and email addresses as high precision.
- Normalize only when the field type is clear.
- Confirm the final value before account-specific lookups, validation, or write actions.

After tool calls:

- Only say an action was completed after the tool call succeeds.
- If the tool fails, explain the failure briefly, avoid raw errors, and give the user a clear next step.

高风险示例：

用户：从我的银行卡扣款，付清剩余欠款。

不佳示例：

助手：我已从您的银行卡扣款。

良好示例：

助手：确认一下，您希望我从已保存的银行卡扣除 $248.16，以付清剩余欠款。可以继续吗？

从工具失败中恢复

工具失败也是对话的一部分。妥善的恢复处理应说明发生了什么，并向用户明确下一步。

不要对所有失败都采用相同的处理方式。恢复行为应取决于工具类型、失败模式及其对用户的影响。有些失败应通过静默重试处理；另一些则需要请用户澄清、更正标识符、确认新操作或选择其他处理路径。

## Tool Failures

If a tool call fails:

1. Briefly explain what failed in user-friendly language.
2. Do not blame the user or expose raw tool errors.
3. If the failure may be due to an exact identifier, read back the value used and ask the user to correct it.
4. If the failure may be temporary, offer to retry once.
5. If the same failure happens repeatedly, offer an alternate path or escalation.

Do not repeatedly call the same tool with the same arguments after failure.

Do not ask for a different identifier until you have first checked whether the captured value was correct.

不佳示例：

助手：出了点问题。

良好示例：

助手：我没有找到与 O R D 连字符 3 1 2 5 B 2 3 匹配的记录。是不是有哪一部分我听错了？

保持提示与可用工具同步

实时模型倾向于积极提供帮助。如果提示提到了实际不可用的工具，或者工具列表与提示不一致，模型可能会编造工具名称，或假装已完成操作。

例如，如果提示中引用的是 lookup_order，但提供的工具名为 search_orders，模型可能会调用错误的名称，或模拟执行该操作。

## Tool Availability

Use only the tools that are explicitly provided in the current tool list.

Do not invent, assume, or simulate tools. If a tool is mentioned in the instructions but is not present in the tool list, treat it as unavailable.

If the user requests an action that requires an unavailable tool:

1. Do not pretend to complete the action.
2. Briefly explain that the tool is not available.
3. Offer the closest supported next step.

Only say an action was completed after the relevant tool call succeeds.

使用附录中的提示审查元提示，检查生产环境中的提示是否存在矛盾、缺失的工具，以及容易导致行为出错的指令。

处理静音和背景音频

语音智能体默认倾向于回应。在生产环境中，它们经常接收到不应以语音回应的音频，例如静音、背景噪声、通话等待音乐、电视声音或旁人的交谈。

当助手应保持安静并继续聆听时，使用不执行实际操作的等待工具。该工具为模型提供了一种有效的非语音操作，使其不必说出“我在”或“我没听清”之类的话。

工具设计：

{
  "name": "wait_for_user",
  "description": "Call this when the latest audio does not need a spoken response, such as silence, background noise, hold music, TV audio, side conversation, or speech not addressed to the assistant. This tool helps end the turn without a spoken reply.",
  "parameters": {
    "type": "object",
    "properties": {},
    "required": []
  }
}

配合以下提示指令使用：

## Handling Silence and Background Noise

If the latest audio is silence, background noise, hold music, TV audio, side conversation, or speech not addressed to you, call `wait_for_user`.

Do not respond conversationally after calling this tool.

Do not say "I'm here," "I didn't catch that," "Take your time," or "Let me know when you're ready."

Resume normal responses only when the user clearly addresses you or asks for help.

此方式适用于并非对助手说话的音频，不适用于不清楚的用户请求。如果用户显然在对助手说话，但内容无法理解，则应请求澄清。

有针对性地使用消息通道

gpt-realtime-2 可以在 commentary 通道中生成用户可见的中间消息，并在 final 通道中生成面向用户的最终回复。如果所需行为取决于消息出现的通道，请针对各通道编写指令。

通道用户是否可见？用途
commentary是前置语音说明和工具调用。
final是面向用户的最终消息。

例如，工具调用发生在 commentary 通道中。如果您希望助手在使用工具之前、期间或之后说些什么，请在指令中明确该行为与 commentary 通道的关系。

Before calling tools in the commentary channel, briefly tell the user what you are doing.

gpt-realtime-2 可以在单轮对话中输出多个回复阶段。在 API 输出中，这种区别通过 response.done 事件体现，其中包含一个 phase 值，用于指示内容是中间说明还是最终回答。

您可以使用此字段，在应用中对各个阶段采用不同的处理方式。例如，可以将 commentary 内容作为简短的中间进展更新播放或显示，而将 final_answer 专用于助手完成后的回复。

response.output[0].phase: "commentary"
response.output[1].phase: "final_answer"

处理不清晰的音频

模型应仅根据有把握理解的音频执行操作。如果音频不清晰，模型应简短提问以请求澄清，而不是猜测。

不要让模型推测缺失的词语、调用工具、提取实体、生成前置语音说明，或花时间进行隐藏推理，试图还原用户可能说过的话。

## Unclear Audio

- Only respond to clear audio or text.
- If the user's audio is not clear, ask for clarification using a short English phrase such as "Sorry, could you repeat that clearly?"
- Don't repeat the same unclear-audio clarification twice.
- Treat audio as unclear if it is ambiguous, noisy, silent, unintelligible, partially cut off, or if you are unsure of the exact words the user said.
- Do not guess what the user meant from unclear audio.
- Do not reason when the audio is unclear.
- Do not provide a preamble or call tools in the commentary channel when the audio is unclear.

示例：

用户音频：“查一下订单三一……” [cut off]

反例：

助手：我现在就查询订单 31。

正例：

助手：我只听到了部分订单号。您能逐位重复一遍吗？

准确采集实体信息

许多实时工作流依赖准确的值：订单 ID、物流单号、电子邮件地址、确认码、账号、理赔编号、工单 ID、客服参考编号和电话号码。

语音交互让这件事变得困难。用户可能语速很快，以不同方式将数字分组，只拼读部分内容，使用语气词，在说话过程中纠正自己，或者读出发音相近的字符。一个数字出错就可能导致查询失败，或查到错误的账户。

谨慎采集实体信息。每次只采集一个值，仅对明确的内容进行规范化处理，在调用工具前确认要求高度准确的值，并确保每次更正后都能恢复流程。

每次采集一个实体

当工作流程需要多个值时，请逐个采集。这样可以避免不同字段的内容混在一起，在语音对话中尤其如此。

## Entity Collection Order

Collect required values one at a time.

- Ask for only the next missing value.
- Do not ask for multiple values in the same turn.
- Before asking, check whether the value was already provided earlier in the conversation or the session.
- If a possible value already exists, confirm it with the user before using it.

Example:

"I see tracking number ABC-54321 from earlier. Should I use that one, or do you have a different tracking number?"

Do not call tools until the current value has been collected, validated, and confirmed.

处理逐字拼读的字符

当用户逐个字符拼读 ID、代码、姓名或电子邮件地址时，请使用此方法。口述形式是输入，并非最终值。

## Spelled-Out Characters

When a user dictates an ID, code, or email character by character, treat the spoken sequence as one compact value. Preserve explicitly spoken separators like dash, dot, underscore, slash, or plus; otherwise do not add spaces or separators.

Examples:

- "A B C one two three" -> "ABC123"
- "B C dash nine eight seven" -> "BC-987"
- "J O H N at example dot com" -> "john@example.com"

Do not insert spaces between spelled-out characters unless the user explicitly says the value contains spaces.

谨慎规范化口述数字

对于数字标识符，用户可能逐位读出数字、分组读出，或使用自然的数词表达。如果字段要求一个连续的数字值，请将清晰的数字语音转换为数字。

## Spoken Number Handling

Convert spoken numbers into digits when collecting numeric identifiers.

Examples:

- "one two three four" -> "1234"
- "one twenty three" -> "123"
- "one nineteen" -> "119"
- "ninety nine eleven" -> "9911"
- "nine thousand nine hundred eleven" -> "9911"

If multiple interpretations are plausible, ask the user to clarify before using the value.

Example:

"I heard either 119 or 1-19. Could you repeat the number digit by digit?"

在调用工具前确认标识符的准确值

订单 ID、物流单号、账号、理赔编号、确认码及类似标识符都是要求高度准确的字段。在工具调用中使用这些值之前，请先进行确认。

对于数字标识符，请逐位复述。将其作为一个完整的数读出，可能让错误难以察觉。

示例：

助手：确认一下，我听到的是 8……3……5……2……1。对吗？

如果用户更正了一个字符或数字，请在调用工具前复述更正后的完整值。

示例：

助手：明白了。我记下的是 8……3……5……7……1。对吗？

## Exact Identifier Confirmation

Before calling tools with high-precision identifiers:

- Confirm the final normalized value with the user.
- Read numeric identifiers back digit by digit.
- Do not use guessed, partial, or ambiguous values.
- If the user corrects the value, repeat the full corrected value before calling the tool.

逐个字符确认电子邮件地址

电子邮件地址是重要的值。点号、连字符、下划线、重复字母以及发音相近的名称，都可能导致账户查询失败，或将消息发送到错误的地址。

请用户拼读电子邮件地址：

助手：您能逐个字符拼读电子邮件地址吗？这样我就能确保记录完全正确。

复述时，请确认最终地址准确无误：

助手：确认一下，是 c-h-e-n 艾特 example 点 com，对吗？

## Email Confirmation

Email addresses must be captured exactly.

If the user says the email naturally without spelling it out, ask them to repeat it character by character.

Example:

"Could you spell the email address character by character so I can make sure I have it exactly right?"

When reading an email back, confirm the exact final email address.

Example:

"Just to confirm, that is c-h-e-n at example dot com, right?"

实体采集工作流程

避免按字面执行指令的陷阱

与早期实时模型相比，gpt-realtime-2 更倾向于按字面含义遵循指令。在旧模型上表现良好的提示可能需要调整。

请使用准确的措辞。模型可能优先遵循指令的字面表述，而非您希望实现的整体行为。宽泛或僵化的规则可能以意想不到的方式主导助手的行为，尤其是在多条规则重叠时。

请谨慎使用 must、only、never 和 always 等约束性词语。只有在确实要求相应行为时才使用这些词，不要将其用于一般性强调。过度使用硬性约束可能使助手行为僵化、过于谨慎，或无法处理合理的例外情况。

优先使用范围明确的表述：

For write actions that modify user data, ask for confirmation before calling the tool.

避免范围过于宽泛的表述：

Always ask for confirmation before doing anything.

宽泛的版本可能导致助手在执行无害的只读查询前也进行不必要的确认，例如查询订单状态、获取可用情况或读取账户信息。

按字面理解的示例

通用提示编写建议：

  • 优先给出明确指令，不要依赖隐含意图。
  • 除非确实需要严格限定行为，否则应避免使用不必要的约束性词语。
  • 尽量减少相互矛盾的指导。
  • 谨慎使用层层叠加或相互冲突的优先级指令。
  • 逐步测试提示。细微的措辞变化也可能对行为产生很大影响。
  • 从早期实时模型迁移时，要预期部分提示需要重新组织结构，才能取得最佳效果。

分别控制语言和口音

语言和口音应分别控制。

用户的口音并不等同于其希望使用的语言。用户可能带着印地语、西班牙语、法语或普通话口音说英语，但仍然希望得到英语回复。

避免使用以下这类宽泛的语言指令：

Mirror the user.
Respond naturally in the user's language.
Switch languages when appropriate.
Sound local.
Adapt to the user's accent.

这些指令过于宽泛。模型可能将口音、语气词、简短的附和语或零星的外语词汇视为切换语言的理由。

英语使用策略

## Language

English is the default response language.

- Do not infer language from accent alone.
- Ignore short filler sounds, backchannels, and isolated foreign words for language detection.
- Only switch languages if the user explicitly asks or provides a substantive utterance in another language.
- If language confidence is low, ask a short clarification instead of guessing.
- Keep preambles, spoken bridges, tool-related messages, and final answers in the same language.
- Accent adaptation must not change the response language.

多语言使用策略

## Language

Default to English unless the user clearly uses another language.

Switch languages only when:

- the user explicitly asks to use another language;
- the user provides a substantive utterance in another language. A substantive utterance means the user gives a complete request, question, or correction in another language, not just a greeting, name, address, filler word, or borrowed phrase.

Do not switch languages based on:

- accent;
- pronunciation;
- filler words;
- short backchannels;
- names;
- addresses;
- isolated foreign words.

If uncertain, ask:

"Would you like me to continue in English or [LANGUAGE]?"

口音控制

gpt-realtime-2 能更严格地遵循口音指令，但模糊的口音提示可能导致口音偏移或意外切换语言。

口音控制提示明确以下内容时效果最佳：

  • 目标口音；
  • 哪些特征应保持稳定；
  • 期望的语速、重音和韵律；
  • 口音调整是否应影响语言选择。

避免这样写：

Sound Australian.

建议这样写：

## Accent

Speak English with a light Australian accent.

- Keep the accent stable from the first word to the last.
- Use natural Australian vowel shaping, but keep speech easy to understand.
- Do not exaggerate the accent.
- Do not change response language based on the user's accent.

自定义音色

当标准音色无法稳定满足品牌、口音或角色要求时，请使用自定义音色。

提示词可以引导口音、语速和表达方式，但无法完全替代音色设计。如果使用场景要求品牌声音始终保持一致，或准确还原特定口音，请考虑使用自定义音色。

自定义音色仅向获批客户开放。请联系您的客户团队申请使用权限。

在长会话中维护状态

gpt-realtime-2 将实时上下文窗口从 32k Token 扩展到 128k Token，因此更适合长会话。对于密集的双向对话，可以将 128k Token 粗略理解为约 1-2 小时的密集原始音频上下文。具体时长会因工具使用、内部推理、注入的记录以及其他会话细节而有所不同。

对于长上下文使用场景，当 gpt-realtime-2 能够区分哪些是当前信息、哪些是背景信息，以及来源冲突时应忽略哪些信息时，表现最佳。不要依赖模型从原始转录文本或大量堆叠的上下文中推断来源的优先级。请以结构化方式组织信息。

如果会话开始时需要提供大量上下文，例如检索到的记录、先前的对话历史、政策、摘要、账户备注或背景文档，请采用结构化的组织方式。

从早期实时模型迁移

从早期实时模型迁移时，应将提示词视为控制行为的接口，而不只是需要移植的文本。

  1. 使用 Codex 或能力较强的推理模型，按照最新的 Realtime 提示词指南重组提示词。请附上本指南的链接，让迁移遵循最佳实践。
  2. 将推理强度设为 low，而不是使用默认值。仅在工作流需要更深入的规划时提高推理强度。
  3. 检查工具名称、参数、枚举、JSON 模式和其他设置，确保它们与预期实现一致。
  4. 删除过时的示例。为正常流程、存在歧义的情况、中断、工具调用和回退行为添加简短示例。
  5. 比较迁移前后的代表性对话。使用现有评测检查是否出现退化，并记录有意进行的行为变更。
  6. 最后再检查一遍一致性。确认提示词清楚地区分了硬性要求、默认行为、工具规则、安全规则和回退行为。
  7. 运行评测，检查代表性的失败案例，并持续迭代提示词，直到目标行为能够可靠实现。

后续步骤

如果使用 GPT-Live：

如果使用 Realtime：