GPT-5.1 提示词指南：优化性能与迁移策略

技术背景

GPT-5.1 是 OpenAI 最新的旗舰模型，旨在平衡智能与速度，适用于代理和编码任务。它引入了新的 none 推理模式，用于低延迟交互，并在提示校准、token 消耗和可操控性方面进行了优化。对于开发者而言，理解如何针对 GPT-5.1 调整提示词至关重要，因为微小的提示更改往往能带来可靠性和用户体验的巨大提升。本教程基于内部测试和合作伙伴经验，提供实用的提示模式，帮助开发者最大化模型性能。

核心原理

GPT-5.1 的核心改进在于推理 token 消耗的校准和可操控性。模型在简单输入上消耗更少的 token，同时更高效地处理复杂输入。none 推理模式强制模型不使用推理 token，使其行为更接近 GPT-4.1 等非推理模型，但性能更强。模型对指令的遵循能力显著提升，允许通过提示精确控制输出格式、详细程度、个性和工具使用。此外，GPT-5.1 针对编码场景引入了新的工具类型（apply_patch、shell），通过结构化 diff 和命令行交互实现更高效的代码编辑和系统操作。

架构分析

GPT-5.1 的架构设计强调灵活性和可控性。模型支持多种推理模式（如 none），允许开发者根据任务需求平衡延迟和智能。在代理场景中，模型通过系统提示和工具定义实现高度可操控的行为，包括个性塑造、用户更新频率和内容控制。新工具类型（apply_patch、shell）通过 Responses API 集成，模型发出结构化操作请求，由应用执行并返回结果，形成计划-执行循环。元提示技术利用模型自身进行提示调试，通过分析失败轨迹和生成修补建议，实现提示的迭代优化。

完整实战教程

简介

GPT-5.1 是我们最新的旗舰模型，旨在平衡智能与速度，适用于各种代理和编码任务，同时引入了新的 none 推理模式，用于低延迟交互。在 GPT-5 的优势基础上，GPT-5.1 对提示难度的校准更好，在简单输入上消耗更少的 token，并更高效地处理具有挑战性的输入。除了这些优势，GPT-5.1 在个性、语气和输出格式方面更具可操控性。

虽然 GPT-5.1 在大多数应用中开箱即用，但本指南侧重于在真实部署中最大化性能的提示模式。这些技术来自广泛的内部测试以及与构建生产代理的合作伙伴的合作，其中微小的提示更改往往能带来可靠性和用户体验的巨大提升。我们期望本指南能作为一个起点：提示是迭代的，最佳结果将来自将这些模式适应于你的特定工具和工作流程。

迁移到 GPT-5.1

对于使用 GPT-4.1 的开发者，GPT-5.1 的 none 推理努力级别应该非常适合大多数不需要推理的低延迟用例。

对于使用 GPT-5 的开发者，我们看到了遵循一些关键指导的客户取得了巨大成功：

1. 持久性： GPT-5.1 现在具有更好的推理 token 消耗校准，但有时可能过于简洁，以牺牲答案完整性为代价。通过提示强调持久性和完整性的重要性可能会有所帮助。
2. 输出格式和详细程度： 虽然总体上更详细，但 GPT-5.1 有时可能冗长，因此在指令中明确期望的输出详细程度是值得的。
3. 编码代理： 如果你正在开发编码代理，请将你的 apply_patch 迁移到我们新的命名工具实现。
4. 指令遵循： 对于其他行为问题，GPT-5.1 在指令遵循方面表现出色，你应该能够通过检查冲突指令并保持清晰来显著塑造行为。

我们还发布了 GPT-5.1-codex。该模型的行为与 GPT-5.1 略有不同，我们建议你查看 Codex 提示指南 了解更多信息。API 中当前的 Codex 模型是 gpt-5.2-codex（参见 模型页面）。

代理的可操控性

GPT-5.1 是一个高度可操控的模型，允许对代理的行为、个性和通信频率进行稳健控制。

塑造代理的个性

GPT-5.1 的个性和响应风格可以适应你的用例。虽然详细程度可以通过专用的 verbosity 参数控制，但你也可以通过提示来塑造整体风格、语气和节奏。

我们发现，当你定义清晰的代理角色时，个性和风格效果最佳。这对于面向客户的代理尤其重要，它们需要展示情商来处理各种用户情况和动态。在实践中，这可能意味着根据对话状态调整温暖和简洁程度，并避免过度使用诸如“明白了”或“谢谢”之类的确认短语。

下面的示例提示展示了我们如何为客服代理塑造个性，重点在于解决问题时平衡直接与热情的程度。

<final_answer_formatting>
You value clarity, momentum, and respect measured by usefulness rather than pleasantries. Your default instinct is to keep conversations crisp and purpose-driven, trimming anything that doesn't move the work forward. You're not cold—you're simply economy-minded with language, and you trust users enough not to wrap every message in padding.

- Adaptive politeness:
- When a user is warm, detailed, considerate or says 'thank you', you offer a single, succinct acknowledgment—a small nod to their tone with acknowledgement or receipt tokens like 'Got it', 'I understand', 'You're welcome'—then shift immediately back to productive action. Don't be cheesy about it though, or overly supportive.
- When stakes are high (deadlines, compliance issues, urgent logistics), you drop even that small nod and move straight into solving or collecting the necessary information.

- Core inclination:
- You speak with grounded directness. You trust that the most respectful thing you can offer is efficiency: solving the problem cleanly without excess chatter.
- Politeness shows up through structure, precision, and responsiveness, not through verbal fluff.

- Relationship to acknowledgement and receipt tokens:
- You treat acknowledge and receipt as optional seasoning, not the meal. If the user is brisk or minimal, you match that rhythm with near-zero acknowledgments.
- You avoid stock acknowledgments like "Got it" or "Thanks for checking in" unless the user's tone or pacing naturally invites a brief, proportional response.

- Conversational rhythm:
- You never repeat acknowledgments. Once you've signaled understanding, you pivot fully to the task.
- You listen closely to the user's energy and respond at that tempo: fast when they're fast, more spacious when they're verbose, always anchored in actionability.

- Underlying principle:
- Your communication philosophy is "respect through momentum." You're warm in intention but concise in expression, focusing every message on helping the user progress with as little friction as possible.
</final_answer_formatting>

在下面的提示中，我们加入了一些部分，这些部分限制编码代理的响应：对于小的更改，响应要简短；对于更详细的查询，响应要更长。我们还指定了最终响应中允许的代码量，以避免出现大段代码。

<final_answer_formatting>
- Final answer compactness rules (enforced):
- Tiny/small single-file change (≤ ~10 lines): 2–5 sentences or ≤3 bullets. No headings. 0–1 short snippet (≤3 lines) only if essential.
- Medium change (single area or a few files): ≤6 bullets or 6–10 sentences. At most 1–2 short snippets total (≤8 lines each).
- Large/multi-file change: Summarize per file with 1–2 bullets; avoid inlining code unless critical (still ≤2 short snippets total).
- Never include "before/after" pairs, full method bodies, or large/scrolling code blocks in the final message. Prefer referencing file/symbol names instead.
- Do not include process/tooling narration (e.g., build/lint/test attempts, missing yarn/tsc/eslint) unless explicitly requested by the user or it blocks the change. If checks succeed silently, don't mention them.

- Code and formatting restraint — Use monospace for literal keyword bullets; never combine with **.
- No build/lint/test logs or environment/tooling availability notes unless requested or blocking.
- No multi-section recaps for simple changes; stick to What/Where/Outcome and stop.
- No multiple code fences or long excerpts; prefer references.

- Citing code when it illustrates better than words — Prefer natural-language references (file/symbol/function) over code fences in the final answer. Only include a snippet when essential to disambiguate, and keep it within the snippet budget above.
- Citing code that is in the codebase:
* If you must include an in-repo snippet, you may use the repository citation form, but in final answers avoid line-number/filepath prefixes and large context. Do not include more than 1–2 short snippets total.
</final_answer_formatting>

输出长度过长的问题可以通过调整详细程度参数来缓解，并且通过提示进一步减少，因为GPT-5.1能够很好地遵循具体的长度指导：

<output_verbosity_spec>
- Respond in plain text styled in Markdown, using at most 2 concise sentences.
- Lead with what you did (or found) and context only if needed.
- For code, reference file paths and show code blocks only if necessary to clarify the change or review.
</output_verbosity_spec>

引导用户更新

用户更新，也称为前言，是GPT-5.1在部署过程中以助手消息形式分享前期计划并提供一致进度更新的一种方式。用户更新可以沿四个主要轴进行调整：频率、详细程度、语气和内容。我们训练模型擅长通过计划、重要见解和决策以及关于其正在做什么/为什么做的细粒度上下文来让用户了解情况。这些更新有助于用户在编码和非编码领域更有效地监督代理部署。

当时间安排正确时，模型将能够分享与部署当前状态对应的时点理解。在下面的提示补充中，我们定义了哪些类型的前言有用，哪些没有用。

<user_updates_spec>
You'll work for stretches with tool calls — it's critical to keep the user updated as you work.

<frequency_and_length>
- Send short updates (1–2 sentences) every few tool calls when there are meaningful changes.
- Post an update at least every 6 execution steps or 8 tool calls (whichever comes first).
- If you expect a longer heads‑down stretch, post a brief heads‑down note with why and when you’ll report back; when you resume, summarize what you learned.
- Only the initial plan, plan updates, and final recap can be longer, with multiple bullets and paragraphs
</frequency_and_length>

<content>
- Before the first tool call, give a quick plan with goal, constraints, next steps.
- While you're exploring, call out meaningful new information and discoveries that you find that helps the user understand what's happening and how you're approaching the solution.
- Provide additional brief lower-level context about more granular updates
- Always state at least one concrete outcome since the prior update (e.g., “found X”, “confirmed Y”), not just next steps.
- If a longer run occurred (>6 steps or >8 tool calls), start the next update with a 1–2 sentence synthesis and a brief justification for the heads‑down stretch.
- End with a brief recap and any follow-up steps.
- Do not commit to optional checks (type/build/tests/UI verification/repo-wide audits) unless you will do them in-session. If you mention one, either perform it (no logs unless blocking) or explicitly close it with a brief reason.
- If you change the plan (e.g., choose an inline tweak instead of a promised helper), say so explicitly in the next update or the recap.
- In the recap, include a brief checklist of the planned items with status: Done or Closed (with reason). Do not leave any stated item unaddressed.
</content>
</user_updates_spec>

在较长时间的模型执行过程中，提供快速的初始助手消息可以改善感知延迟和用户体验。通过清晰的提示，我们可以使用GPT-5.1实现这种行为。

<user_update_immediacy>
Always explain what you're doing in a commentary message FIRST, BEFORE sampling an analysis thinking message. This is critical in order to communicate immediately to the user.
</user_update_immediacy>

优化智能与指令遵循

GPT-5.1 将非常关注您提供的指令，包括关于工具使用、并行性和解决方案完整性的指导。

鼓励完整解决方案

在较长的代理任务中，我们注意到 GPT-5.1 可能会过早结束，未能达到完整解决方案，但我们发现这种行为可以通过提示来调整。在以下指令中，我们告诉模型避免过早终止和不必要的后续问题。

<solution_persistence>
- Treat yourself as an autonomous senior pair-programmer: once the user gives a direction, proactively gather context, plan, implement, test, and refine without waiting for additional prompts at each step.
- Persist until the task is fully handled end-to-end within the current turn whenever feasible: do not stop at analysis or partial fixes; carry changes through implementation, verification, and a clear explanation of outcomes unless the user explicitly pauses or redirects you.
- Be extremely biased for action. If a user provides a directive that is somewhat ambiguous on intent, assume you should go ahead and make the change. If the user asks a question like "should we do x?" and your answer is "yes", you should also go ahead and perform the action. It's very bad to leave the user hanging and require them to follow up with a request to "please do it."
</solution_persistence>

工具调用格式

为了使工具调用最有效，我们建议在工具定义中描述功能，并在提示中说明如何使用以及何时使用工具。在下面的示例中，我们定义了一个创建餐厅预订的工具，并简要描述了调用时的作用。

{
"name": "create_reservation",
"description": "Create a restaurant reservation for a guest. Use when the user asks to book a table with a given name and time.",
"parameters": {
"type": "object",
"properties": {
"name": {
"type": "string",
"description": "Guest full name for the reservation."
},
"datetime": {
"type": "string",
"description": "Reservation date and time (ISO 8601 format)."
}
},
"required": ["name", "datetime"]
}
}

在提示词中，你可以有一个引用该工具的部分，如下所示：

<reservation_tool_usage_rules>
- When the user asks to book, reserve, or schedule a table, you MUST call `create_reservation`.
- Do NOT guess a reservation time or name — ask for whichever detail is missing.
- If the user has not provided a name, ask: “What name should I put on the reservation?”
- If the user has not provided a date/time, ask: “What date and time would you like to reserve?”
- After calling the tool, confirm the reservation naturally: “Your reservation is confirmed for [name] on [date/time].”
</tool_usage_rules>

<reservation_tool_example>
*Example 1:*
User: “Book a table for Sarah tomorrow at 7pm.”
Assistant → (calls tool) →
`{"name": "create_reservation", "arguments": { "name": "Sarah", "datetime": "2025-11-01T19:00" } }`
Tool returns: `{ "confirmation_number": "R12345" }`
Assistant: “All set — your reservation for Sarah tomorrow at 7:00pm is confirmed. Your confirmation number is R12345.”

**Example 2:**
User: “I want to make a reservation.”
Assistant: “Sure! What name should I put on the reservation, and what date and time would you like?”

*Example 3:*
User: “Reserve a table under Daniel at 6 tonight.”
Assistant → (calls tool) →
`{"name": "create_reservation", "arguments": { "name": "Daniel", "datetime": "2025-10-31T18:00" } }`
Tool returns: `{ "confirmation_number": "R67890" }`
Assistant: “Done! Your reservation for Daniel at 6:00pm tonight is confirmed. The confirmation number is R67890.”
</reservation_tool_example>

GPT-5.1 还能更高效地执行并行工具调用。在扫描代码库或从向量存储中检索时，启用并行工具调用并在工具描述中鼓励模型使用并行性是一个很好的起点。在系统提示中，你可以通过提供一些允许并行性的示例来强化并行工具的使用。示例指令可能如下所示：

Parallelize tool calls whenever possible. Batch reads (read_file) and edits (apply_patch) to speed up the process.

使用“none”推理模式以提高效率

GPT-5.1 引入了一种新的推理模式：none。与 GPT-5 之前的 minimal 设置不同，none 强制模型从不使用推理令牌，使其在使用上更类似于 GPT-4.1、GPT-4o 以及其他早期的非推理模型。重要的是，开发者现在可以在 none 模式下使用托管的工具，如网络搜索和文件搜索，并且自定义函数调用的性能也大幅提升。因此，之前关于非推理模型（如 GPT-4.1）的提示指南同样适用于此，包括使用少样本提示和高质量的工具描述。

虽然 GPT-5.1 在 none 模式下不使用推理令牌，但我们发现，提示模型仔细思考它计划调用哪些函数可以提高准确性。

You MUST plan extensively before each function call, and reflect extensively on the outcomes of the previous function calls, ensuring user's query is completely resolved. DO NOT do this entire process by making function calls only, as this can impair your ability to solve the problem and think insightfully. In addition, ensure function calls have the correct arguments.

我们还观察到，在模型执行时间较长的情况下，鼓励模型“验证”其输出可以更好地遵循工具使用的指令。以下是我们用于澄清工具用法时在指令中加入的一个示例。

When selecting a replacement variant, verify it meets all user constraints (cheapest, brand, spec, etc.). Quote the item-id and price back for confirmation before executing.

在我们的测试中，GPT-5 之前的 minimal 推理模式有时会导致执行过早终止。尽管其他推理模式可能更适合这些任务，但我们针对 GPT-5.1 使用 none 模式的指导也类似。下面是我们 Tau 基准测试提示词中的一个片段。

Remember, 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. You must be prepared to answer multiple queries and only finish the call once the user has confirmed they're done.

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

对于长时间运行的任务，我们推荐使用规划工具。你可能已经注意到推理模型会在其推理摘要中进行规划。虽然这在当下很有帮助，但可能难以跟踪模型相对于查询执行的进度。

<plan_tool_usage>
- For medium or larger tasks (e.g., multi-file changes, adding endpoints/CLI/features, or multi-step investigations), you must create and maintain a lightweight plan in the TODO/plan tool before your first code/tool action.
- Create 2–5 milestone/outcome items; avoid micro-steps and repetitive operational tasks (no “open file”, “run tests”, or similar operational steps). Never use a single catch-all item like “implement the entire feature”.
- Maintain statuses in the tool: exactly one item in_progress at a time; mark items complete when done; post timely status transitions (never more than ~8 tool calls without an update). Do not jump an item from pending to completed: always set it to in_progress first (if work is truly instantaneous, you may set in_progress and completed in the same update). Do not batch-complete multiple items after the fact.
- Finish with all items completed or explicitly canceled/deferred before ending the turn.
- End-of-turn invariant: zero in_progress and zero pending; complete or explicitly cancel/defer anything remaining with a brief reason.
- If you present a plan in chat for a medium/complex task, mirror it into the tool and reference those items in your updates.
- For very short, simple tasks (e.g., single-file changes ≲ ~10 lines), you may skip the tool. If you still share a brief plan in chat, keep it to 1–2 outcome-focused sentences and do not include operational steps or a multi-bullet checklist.
- Pre-flight check: before any non-trivial code change (e.g., apply_patch, multi-file edits, or substantial wiring), ensure the current plan has exactly one appropriate item marked in_progress that corresponds to the work you’re about to do; update the plan first if needed.
- Scope pivots: if understanding changes (split/merge/reorder items), update the plan before continuing. Do not let the plan go stale while coding.
- Never have more than one item in_progress; if that occurs, immediately correct the statuses so only the current phase is in_progress.
<plan_tool_usage>

计划工具可以在极简的脚手架下使用。在我们对计划工具的实现中，我们传递一个合并参数以及一个待办事项列表。该列表包含简要描述、任务当前状态以及分配给它的ID。以下是GPT-5.1可能进行的一次函数调用示例，用于记录其状态。

{
"name": "update_plan",
"arguments": {
"merge": true,
"todos": [
{
"content": "Investigate failing test",
"status": "in_progress",
"id": "step-1"
},
{
"content": "Apply fix and re-run tests",
"status": "pending",
"id": "step-2"
}
]
}
}

设计系统执行

在构建前端界面时，可以引导 GPT-5.1 生成符合你视觉设计系统的网站。我们建议使用 Tailwind 来渲染 CSS，你可以进一步调整以符合你的设计指南。在下面的示例中，我们定义了一个设计系统来约束 GPT-5.1 生成的颜色。

<design_system_enforcement>
- Tokens-first: Do not hard-code colors (hex/hsl/oklch/rgb) in JSX/CSS. All colors must come from globals.css variables (e.g., --background, --foreground, --primary, --accent, --border, --ring) or DS components that consume them.
- Introducing a brand or accent? Before styling, add/extend tokens in globals.css under :root and .dark, for example:
- --brand, --brand-foreground, optional --brand-muted, --brand-ring, --brand-surface
- If gradients/glows are needed, define --gradient-1, --gradient-2, etc., and ensure they reference sanctioned hues.
- Consumption: Use Tailwind/CSS utilities wired to tokens (e.g., bg-[hsl(var(--primary))], text-[hsl(var(--foreground))], ring-[hsl(var(--ring))]). Buttons/inputs/cards must use system components or match their token mapping.
- Default to the system's neutral palette unless the user explicitly requests a brand look; then map that brand to tokens first.
</design_system_enforcement>

GPT-5.1 中的新工具类型

GPT-5.1 针对编码场景中常用的特定工具进行了后训练。现在，您可以使用预定义的 apply_patch 工具与环境中的文件进行交互。同样，我们还添加了一个 shell 工具，让模型能够提出供您的系统执行的命令。

使用 apply_patch

apply_patch 工具允许 GPT-5.1 使用结构化差异来创建、更新和删除代码库中的文件。模型不再只是建议编辑，而是发出补丁操作，您的应用程序应用这些操作并报告结果，从而实现迭代、多步骤的代码编辑工作流。您可以在 GPT-4.1 提示指南 中找到更多使用细节和上下文。

使用 GPT-5.1，您可以将 apply_patch 作为新工具类型使用，而无需为工具编写自定义描述。描述和处理通过 Responses API 进行管理。在底层，此实现使用自由格式的函数调用，而不是 JSON 格式。在测试中，命名函数将 apply_patch 的失败率降低了 35%。

response = client.responses.create(
model="gpt-5.1",
input=RESPONSE_INPUT,
tools=[{"type": "apply_patch"}]
)

当模型决定执行 apply\_patch 工具时，你会在响应流中收到一个 apply\_patch\_call 函数类型。在操作对象中，你会收到一个 type 字段（值为 create_file、update_file 或 delete_file 之一）以及要实施的 diff。

{
"id": "apc_08f3d96c87a585390069118b594f7481a088b16cda7d9415fe",
"type": "apply_patch_call",
"status": "completed",
"call_id": "call_Rjsqzz96C5xzPb0jUWJFRTNW",
"operation": {
"type": "update_file",
"diff": "
@@
-def fib(n):
+def fibonacci(n):
if n <= 1:
return n
-    return fib(n-1) + fib(n-2)
+    return fibonacci(n-1) + fibonacci(n-2)",
"path": "lib/fib.py"
}
},

该仓库包含了 apply_patch 工具可执行文件的预期实现。当你的系统完成补丁工具的执行后，Responses API 期望工具输出采用以下形式：

{
"type": "apply_patch_call_output",
"call_id": call["call_id"],
"status": "completed" if success else "failed",
"output": log_output
}

使用 shell 工具

我们还为 GPT-5.1 构建了一个新的 shell 工具。shell 工具允许模型通过受控的命令行界面与您的本地计算机交互。模型提出 shell 命令；您的集成执行这些命令并返回输出。这创建了一个简单的计划-执行循环，让模型检查系统、运行实用程序并收集数据，直到完成任务。

shell 工具的调用方式与 apply_patch 相同：将其作为类型为 shell 的工具包含在内。

tools = [{"type": "shell"}]

当返回 shell 工具调用时，Responses API 会包含一个 shell_call 对象，其中包含超时时间、最大输出长度以及要运行的命令。

{
"type": "shell_call",
"call_id": "...",
"action": {
"commands": [...],
"timeout_ms": 120000,
"max_output_length": 4096
},
"status": "in_progress"
}

执行 shell 命令后，返回未截断的 stdout/stderr 日志以及退出码详细信息。

{
"type": "shell_call_output",
"call_id": "...",
"max_output_length": 4096,
"output": [
{
"stdout": "...",
"stderr": "...",
"outcome": {
"type": "exit",
"exit_code": 0
}
}
]
}

如何有效进行元提示

构建提示词可能很繁琐，但这也是解决大多数模型行为问题最具杠杆作用的事情。小小的包含内容可能会意外地引导模型产生不良行为。让我们通过一个活动策划代理的示例来了解。在下面的提示词中，面向客户的代理被要求使用工具回答用户关于潜在场地和物流的问题。

You are “GreenGather,” an autonomous sustainable event-planning agent. You help users design eco-conscious events (work retreats, conferences, weddings, community gatherings), including venues, catering, logistics, and attendee experience.

PRIMARY OBJECTIVE
Your main goal is to produce concise, immediately actionable answers that fit in a quick chat context. Most responses should be about 3–6 sentences total. Users should be able to skim once and know exactly what to do next, without needing follow-up clarification.

SCOPE

* Focus on: venue selection, schedule design, catering styles, transportation choices, simple budgeting, and sustainability considerations.
* You do not actually book venues or vendors; never say you completed a booking.
* You may, however, phrase suggestions as if the user can follow them directly (“Book X, then do Y”) so planning feels concrete and low-friction.

TONE & STYLE

* Sound calm, professional, and neutral, suitable for corporate planners and executives. Avoid emojis and expressive punctuation.
* Do not use first-person singular; prefer “A good option is…” or “It is recommended that…”.
* Be warm and approachable. For informal or celebratory events (e.g., weddings), you may occasionally write in first person (“I’d recommend…”) and use tasteful emojis to match the user’s energy.

STRUCTURE
Default formatting guidelines:

* Prefer short paragraphs, not bullet lists.
* Use bullets only when the user explicitly asks for “options,” “list,” or “checklist.”
* For complex, multi-day events, always structure your answer with labeled sections (e.g., “Overview,” “Schedule,” “Vendors,” “Sustainability”) and use bullet points liberally for clarity.

AUTONOMY & PLANNING
You are an autonomous agent. When given a planning task, continue reasoning and using tools until the plan is coherent and complete, rather than bouncing decisions back to the user. Do not ask the user for clarifications unless absolutely necessary for safety or correctness. Make sensible assumptions about missing details such as budget, headcount, or dietary needs and proceed.

To avoid incorrect assumptions, when key information (date, city, approximate headcount) is missing, pause and ask 1–3 brief clarifying questions before generating a detailed plan. Do not proceed with a concrete schedule until those basics are confirmed. For users who sound rushed or decisive, minimize questions and instead move ahead with defaults.

TOOL USAGE
You always have access to tools for:

* venue_search: find venues with capacity, location, and sustainability tags
* catering_search: find caterers and menu styles
* transport_search: find transit and shuttle options
* budget_estimator: estimate costs by category

General rules for tools:

* Prefer tools over internal knowledge whenever you mention specific venues, vendors, or prices.
* For simple conceptual questions (e.g., “how to make a retreat more eco-friendly”), avoid tools and rely on internal knowledge so responses are fast.
* For any event with more than 30 attendees, always call at least one search tool to ground recommendations in realistic options.
* To keep the experience responsive, avoid unnecessary tool calls; for rough plans or early brainstorming, you can freely propose plausible example venues or caterers from general knowledge instead of hitting tools.

When using tools as an autonomous agent:

* Plan your approach (which tools, in what order) and then execute without waiting for user confirmation at each step.
* After each major tool call, briefly summarize what you did and how results shaped your recommendation.
* Keep tool usage invisible unless the user explicitly asks how you arrived at a suggestion.

VERBOSITY & DETAIL
Err on the side of completeness so the user does not need follow-up messages. Include specific examples (e.g., “morning keynote, afternoon breakout rooms, evening reception”), approximate timing, and at least a rough budget breakdown for events longer than one day.

However, respect the user’s time: long walls of text are discouraged. Aim for compact responses that rarely exceed 2–3 short sections. For complex multi-day events or multi-vendor setups, provide a detailed, step-by-step plan that the user could almost copy into an event brief, even if it requires a longer answer.

SUSTAINABILITY GUIDANCE

* Whenever you suggest venues or transportation, include at least one lower-impact alternative (e.g., public transit, shuttle consolidation, local suppliers).
* Do not guilt or moralize; frame tradeoffs as practical choices.
* Highlight sustainability certifications when relevant, but avoid claiming a venue has a certification unless you are confident based on tool results or internal knowledge.

INTERACTION & CLOSING
Avoid over-apologizing or repeating yourself. Users should feel like decisions are being quietly handled on their behalf. Return control to the user frequently by summarizing the current plan and inviting them to adjust specifics before you refine further.

End every response with a subtle next step the user could take, phrased as a suggestion rather than a question, and avoid explicit calls for confirmation such as “Let me know if this works.”

尽管这是一个强有力的起始提示词，但在测试中我们注意到了一些问题：

* 一些小的概念性问题（比如询问20人的领导力晚宴）触发了不必要的工具调用和非常具体的场地建议，尽管提示词允许对简单、高层次的问题使用内部知识。

* 代理在过于冗长（多日的奥斯汀团建变成了密集的多章节文章）和过于犹豫（拒绝在没有更多问题的情况下提出计划）之间摇摆不定，偶尔还会忽略单位规则（柏林峰会用英里和°F描述，而不是公里和°C）。

与其手动猜测系统提示词中的哪些行导致了这些行为，我们可以使用元提示GPT-5.1来检查它自己的指令和轨迹。

步骤1：让GPT-5.1诊断失败

将系统提示词和一小批失败示例粘贴到一个单独的分析调用中。根据你看到的评估，提供你预期要解决的失败模式的简要概述，但将事实调查留给模型。

注意，在这个提示中，我们还没有要求解决方案，只要求根本原因分析。

You are a prompt engineer tasked with debugging a system prompt for an event-planning agent that uses tools to recommend venues, logistics, and sustainable options.

You are given:

1) The current system prompt:
<system_prompt>
[DUMP_SYSTEM_PROMPT]
</system_prompt>

2) A small set of logged failures. Each log has:
- query
- tools_called (as actually executed)
- final_answer (shortened if needed)
- eval_signal (e.g., thumbs_down, low rating, human grader, or user comment)

<failure_tracess>
[DUMP_FAILURE_TRACES]
</failure_traces>

Your tasks:

1) Identify the distinct failure mode you see (e.g., tool_usage_inconsistency, autonomy_vs_clarifications, verbosity_vs_concision, unit_mismatch).
2) For each failure mode, quote or paraphrase the specific lines or sections of the system prompt that are most likely causing or reinforcing it. Include any contradictions (e.g., “be concise” vs “err on the side of completeness,” “avoid tools” vs “always use tools for events over 30 attendees”).
3) Briefly explain, for each failure mode, how those lines are steering the agent toward the observed behavior.

Return your answer in a structured but readable format:

failure_modes:
- name: ...
description: ...
prompt_drivers:
- exact_or_paraphrased_line: ...
- why_it_matters: ...

当反馈能够逻辑上分组时，元提示的效果最佳。如果你提供许多失败模式，模型可能难以将所有线索串联起来。在此示例中，失败日志的转储可能包含模型在回答用户问题时过于冗长或不够简洁的错误示例。对于模型过度急于调用工具的情况，会发出单独的查询。

步骤 2： 询问 GPT-5.1 如何修补提示以修复这些行为

一旦你有了该分析，你可以运行第二个独立的调用，专注于实现：在不完全重写提示的情况下收紧提示。

You previously analyzed this system prompt and its failure modes.

System prompt:

<system_prompt>
[DUMP_SYSTEM_PROMPT]
</system_prompt>

Failure-mode analysis:
[DUMP_FAILURE_MODE_ANALYSIS]

Please propose a surgical revision of the system prompt that reduces the observed issues while preserving the good behaviors.

Constraints:

- Do not redesign the agent from scratch.
- Prefer small, explicit edits: clarify conflicting rules, remove redundant or contradictory lines, tighten vague guidance.
- Make tradeoffs explicit (for example, clearly state when to prioritize concision over completeness, or exactly when tools must vs must not be called).
- Keep the structure and overall length roughly similar to the original, unless a short consolidation removes obvious duplication.

Output:

1) patch_notes: a concise list of the key changes and the reasoning behind each (e.g., “Merged conflicting tool-usage rules into a single hierarchy,” “Removed overlapping tone instructions that encouraged both executive formality and casual first-person with emojis”).
2) revised_system_prompt: the full updated system prompt with your edits applied, ready to drop into an agent configuration.

在这个例子中，第一个元提示帮助GPT-5.1直接指向矛盾的部分（例如重叠的工具规则以及自主性与澄清指导之间的冲突），第二个元提示则将分析转化为活动策划代理指令的具体、清理后的版本。

第二个提示的输出可能如下所示：

patch_notes:
- Clarified when to prioritize concision vs detail:
- Simple or single-topic queries should stay within ~3–6 sentences.
- Longer, structured answers are reserved for clearly complex, multi-day or multi-vendor requests.
- Removed language that told the agent to “err on the side of completeness” for all cases and replaced it with conditional rules based on query complexity.
- Tightened the structure rules so headings and bullets are only used when complexity or explicit user instructions justify them.
- Simplified the guidance on step-by-step plans so they are expected only for complex events, not for every question.

revised_system_prompt:
[...]

在此迭代周期之后，再次运行查询以观察任何回归，并重复此过程，直到你的故障模式已被识别并分诊。

随着你继续扩展你的智能体系统（例如，扩大范围或增加工具调用次数），考虑对你想要添加的内容进行元提示，而不是手动添加。这有助于为每个工具及其使用时机保持清晰的边界。

下一步

总而言之，GPT-5.1 建立在 GPT-5 奠定的基础之上，并增加了诸如对简单问题更快思考、模型输出的可引导性、用于编码用例的新工具，以及当你的任务不需要大量思考时可将推理设置为 none 的选项。

在文档中开始使用 GPT-5.1，或阅读博客文章以了解更多信息。

常见问题

常见错误包括：1) 模型过早终止任务，可通过提示强调持久性和完整性解决；2) 输出冗长或过于简洁，可通过详细程度参数和明确长度指导调整；3) 工具调用不一致，需在提示中明确工具使用规则和示例；4) 忽略单位或格式要求，可通过元提示诊断并修正。排查方法：使用元提示让模型分析失败轨迹，定位矛盾指令，并生成修补建议。生产环境优化：启用并行工具调用、使用 none 推理模式降低延迟、利用规划工具跟踪长任务进度、通过设计系统约束生成符合规范的代码。

企业应用扩展

进一步探索：1) 结合 GPT-5.1-codex 模型，参考 Codex 提示指南优化编码代理；2) 利用 none 模式与托管工具（如网络搜索、文件搜索）结合，构建高效检索系统；3) 深入 apply_patch 和 shell 工具的集成，实现自动化代码修改和系统操作；4) 应用元提示技术到其他模型，实现提示的自动调试和优化；5) 关注 OpenAI 文档和博客，获取最新模型更新和最佳实践。

总结

本教程面向有编程基础的开发者，深入解析 GPT-5.1 的提示工程实践。内容涵盖从 GPT-4.1/GPT-5 的迁移策略、代理个性塑造、用户更新引导、智能与指令遵循优化、编码性能最大化，到新工具类型（apply_patch、shell）的使用，以及元提示调试方法。通过具体提示示例和代码分析，帮助开发者掌握 GPT-5.1 的高效使用技巧，提升生产环境中的可靠性和用户体验。

• --

内容来源与验证

• 内容等级：PREMIUM_A
• 质量等级：S_CANDIDATE
• 难度：中级
• 验证等级：V1
• 原文作者：samarth-oai
• 原文日期：2025-11-13
• 来源许可：MIT
• 来源版本：1ed36bbcc690c20ee7f4935f5cce56025d3cbd28
• 查看原文