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 的資料。我有哪個部分聽錯了嗎？

讓提示詞與可用工具保持同步

Realtime 模型會積極提供協助。如果提示詞提及實際上無法使用的工具，或工具清單與提示詞不一致，模型可能會捏造工具名稱，或假裝已完成動作。

例如，如果提示詞提及 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 還是最終答案。

你可以利用這個欄位，在應用程式中以不同方式處理各個階段。例如，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.

範例：

使用者音訊：「查詢訂單三一——」[中斷]

不佳的做法：

助理：我現在就查詢訂單 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 at example dot 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 擴大至 128k Token，使其更適合長時間工作階段。對於密集的雙向對話，128k Token 大致可視為約 1–2 小時的密集原始音訊上下文。實際容量會隨工具使用、內部推理、插入的紀錄及其他工作階段細節而變動。

在長上下文使用案例中，當 gpt-realtime-2 能分辨哪些資訊是最新資訊、哪些是背景資料，以及來源衝突時應忽略哪些內容，就能發揮最佳表現。請勿依賴模型從原始逐字稿或大量未整理的上下文中推斷來源優先順序。請以結構化方式組織內容。

若工作階段開始時需要提供大量上下文，例如擷取的紀錄、先前的對話歷史、政策、摘要、帳戶備註或背景文件，請採用結構化格式。

從較早的即時模型遷移

從較早的即時模型遷移時，應將提示詞視為控制行為的介面，而不只是要搬移的文字。

  1. 使用 Codex 或能力強大的推理模型，依照最新的 Realtime 提示詞指引重整提示詞。請附上本提示詞指南的連結，讓遷移工作以最佳實務為依據。
  2. 將推理強度設為 low，不要使用預設值。只有在工作流程需要更深入的規劃時，才提高推理強度。
  3. 檢查工具名稱、參數、列舉值、JSON 結構描述及其他設定，確保它們與預期的實作一致。
  4. 移除過時的範例。針對正常流程、語意不明、中斷、工具呼叫及備援行為，新增簡短範例。
  5. 比較遷移前後具代表性的對話。使用既有評估檢查是否出現退步，並記錄刻意調整的行為。
  6. 最後再進行一次一致性檢查。確認提示詞清楚區分強制要求、預設行為、工具規則、安全規則及備援行為。
  7. 執行評估、檢視具代表性的失敗案例，並反覆調整提示詞，直到能可靠地呈現目標行為。

後續步驟

若使用 GPT-Live：

若使用 Realtime：