GPT-5 提示词：智能体行为、编程与提示优化

GPT-5 发布后获得了褒贬不一的反应，不过我很喜欢使用它。OpenAI 发布了一份提示指南，我想介绍其中关于智能体工作流和编程的建议，然后演示 Playground 中的提示优化器。示例和界面反映的是 2025 年 8 月的情况，具体应用时应结合需求测试。

指南介绍了如何控制智能体的积极程度：它会在返回用户之前进行多少调查、独立做出多少决定。你可以要求它广泛研究和规划，也可以让它集中回答单个问题。合适的程度取决于任务、可用工具和出错的后果。

为了更快地完成范围较窄的工作，指南建议降低推理强度，并说明模型应收集多少上下文。降低强度可能减少延迟和 token 用量，但节省的程度和回答质量取决于任务。这并不能保证减少工具调用或降低回答成本总是足够的。

一个上下文收集示例要求智能体先广泛了解情况，再进行有针对性的查询，避免重复，并在掌握足够信息采取行动时停止。示例包括提前停止的条件，以及信号相互冲突时细化搜索的方法。这些是可以根据工作流调整的指令，并非通用的确定性阈值。

另一个示例限制搜索深度，通常最多允许调用两次工具，同时允许模型在存在不确定性的情况下继续，并报告尚未解决的问题。这种取舍优先考虑速度；死板的预算可能遗漏重要证据。对于需要高度信心的任务，预算和停止条件就需要不同的设置。

在另一端，指南展示了持续执行：继续研究并做出合理假设，而不是动辄将任务交回用户。我也强调要明确停止条件和不安全操作。例如，确认购买或删除文件可能需要将控制权交还用户；自主程度应与操作相匹配。

工具调用前的说明是进度消息，用来解释智能体正在做什么以及为什么这样做。指南给出的示例包括陈述目标和计划、汇报进度以及总结完成的工作。你可以调整更新的详略和频率，让用户在等待时了解情况。

OpenAI 推荐在 GPT-5 智能体流程中使用 Responses API，并报告称，在使用先前响应 ID 传递推理项的设置中，Tau-Bench Retail 的成绩从 73.9% 提升至 78.2%。这是该公司在特定基准和设置下的结果，并不能保证适用于每个应用。复用上下文可以避免工具调用后重新构建计划。

在编程方面，指南列出了一个前端技术栈，包括 Next.js、TypeScript、React、Tailwind CSS、shadcn/ui 和常见图标库。我认为，从熟悉的技术入手可能是不错的选择。我猜测这些推荐反映了相关技术在训练数据中的出现频率；这只是我的解读，并非公开披露的训练数据测量结果。

对于新的 Web 应用，指南给出了一条自我反思提示：要求模型构建涵盖五到七个类别的评估标准，并反复评估自己的工作。OpenAI 报告称，早期用户认为这种提示方式有帮助。这是一种值得测试的技巧，并不能保证质量；独立审查和验证仍然重要。

对于已有代码库，目标则不同：要遵循现有模式和设计规范。指南建议在提供仓库上下文的同时，向智能体说明工程原则、目录结构、技术栈细节和 UI 规则。我把这比作项目级指令文件，它们说明了智能体应如何在特定代码库中工作。

指南讨论了 Cursor 对 GPT-5 的早期调整。Cursor 发现状态消息和总结可能过长，而生成的代码有时会使用简短、难以理解的名称。团队将面向用户文字的 verbosity 参数设为低，同时加入指令，鼓励生成清晰、易维护的代码。

Cursor 还提供了产品背景，让模型了解其修改会交由用户审查。团队发现 GPT-5 的搜索可能过于积极，于是放宽了此前要求尽可能多收集上下文的指令。这里的经验是，应根据实际环境调整提示词，而不是将旧模型的所有指令原封不动地沿用。

回答详略和推理强度控制的是不同的东西：前者影响最终回答的文字量，后者控制推理强度。我也建议检查提示词中是否存在冲突或遗漏的边界情况。模型可以帮助找出含糊的指令，但仍应审查它提出的修改建议。

指南用一个假设的患者预约工作流说明冲突：一条指令要求在预约前记录患者同意，另一条却要求系统在不联系患者的情况下分配时间。另一个冲突涉及是否必须先查询个人资料才能升级处理紧急情况。解决方法是在工作流中明确优先级和例外，然后进行测试。

提示词需要反复调整。运行有代表性的案例，检查实际发生了什么，再修改有冲突或未定义重要行为的指令。这些示例旨在说明提示设计，并非临床指导，也不能证明仅靠修改提示词就能保证医疗工作流的安全。

2025 年的指南还讨论了面向延迟敏感任务的最小推理。指南称，在这一设置下，结果可能更依赖提示词的措辞，并建议提供清晰的工具指令、明确的计划和适当的进度更新。应根据实际任务评估合适的推理强度，而不能仅凭速度做出判断。

在输出格式方面，指南建议在适用时要求使用 Markdown，并说明文件名和代码等内容的格式。指南还介绍了元提示：要求模型建议对提示词进行增删，以更好地引导预期行为。

在 Playground 的演示中，我输入一条开发者消息，要求提供快速、轻量的 Python 解决方案，并提供一个用户任务。我点击 Optimize。工具修改了开发者消息，加入了一份简洁的检查清单，并建议在适当情况下优先使用标准库工具。

界面会解释每项修改建议。我要求优化器让模型详细解释自己的决定，再次运行，并在保存前以差异对比的形式审查结果。优化器可以提出并展示修改建议；修改后的提示词仍需针对预期任务进行测试。