- Authors
- Name
- Youngju Kim
- @fjvbn20031
- 为什么 GPT-5 会改变开发工作流
- GPT-5 实际改变了什么
- 该怎么选模型规模
- 控制参数什么时候降、什么时候升
- 智能体编程中发生了什么变化
- 自定义工具和格式约束如何搭配使用
- Responses API 和 Chat Completions API 该什么时候用
- 该如何降低成本和延迟
- 生产环境上线检查清单
- FAQ
- References
为什么 GPT-5 会改变开发工作流
OpenAI 于 2025 年 8 月 7 日在 Introducing GPT-5 for developers 中，将 GPT-5 介绍为面向编程与智能体任务的最佳模型。这次发布的核心，不在于多了一款更好的聊天模型，而在于开发者使用模型的方式，从「把提示词写好」这一层，提升到了同时设计工具调用、输出约束、延迟、成本、智能体执行这一整套体系的层次。
以往的开发工作流通常是这样的顺序。
- 挑一个模型
- 写提示词
- 祈祷 JSON 能正常输出
- 工具调用出错就事后修补
- 成本和速度留到后面再说
GPT-5 把这套流程变得更明确了。现在开发者不仅要决定让模型做什么，还要一起决定回答要多长、要想多深、用什么格式输出、用什么约束调用哪些工具。结果就是，在智能体编程和运营自动化上，这比单纯打磨提示词要稳定得多。
GPT-5 实际改变了什么
GPT-5 在实务中之所以重要，与其说是单纯的性能提升，不如说是开发者能控制的范围变宽了。
1. 擅长编程与智能体任务
OpenAI 把 GPT-5 描述为在代码修改、修 bug、复杂代码库问答、跨工具的智能体任务上尤其出色的模型。也就是说，它更适合执行任务，而不只是生成单次回答。
2. 控制参数更清晰
实务中首先要掌握的控制参数有两个。
verbosity：调整回答的长度和说明的详尽程度reasoning_effort：调整模型思考的深度
大体上，verbosity 改变的是输出格式和阅读体验，reasoning_effort 改变的是准确率、延迟和 token 用量之间的平衡。
3. 自定义工具更灵活
GPT-5 的自定义工具不仅能接收 JSON，还能通过 plaintext 输入调用工具。这一点在 SQL、DSL、shell 风格命令、专有内部格式这类硬塞进 JSON 会显得别扭的场景中格外好用。
4. 格式约束更强
如果需要，可以用正则表达式限制输出格式，要求更严格时还可以用 CFG。实务中，比起「看起来差不多对」，往往必须严格符合格式更重要，这项能力能大幅提升智能体的可靠性。
5. 可以在多个 API 界面上使用
GPT-5 既能在 Responses API 上用，也能在 Chat Completions API 上用，还自然地融入了 OpenAI Codex CLI 的默认开发工作流。也就是说，一套摸索出来的运营原则，可以在交互式聊天、代码智能体、批处理式任务之间复用。
该怎么选模型规模
GPT-5 系列通常分为 gpt-5、gpt-5-mini、gpt-5-nano 来考虑更方便。选择标准不是「最聪明的模型」，而是任务的风险程度和重复程度。
| 模型 | 推荐用途 | 优点 | 注意点 |
|---|---|---|---|
gpt-5 | 复杂代码修改、智能体循环、架构判断、高难度调试 | 推理与任务执行能力最强 | 成本和延迟相对更高 |
gpt-5-mini | 常规产品功能、中等难度的工具调用、对话式编程辅助 | 均衡易用，适用面广 | 在最难的问题上可能显出局限 |
gpt-5-nano | 分类、抽取、路由、超低延迟任务、大批量处理 | 最快最便宜 | 不适合复杂推理 |
实务上的经验很简单：核心路径用 gpt-5，辅助路径用 gpt-5-mini，大批量预处理用 gpt-5-nano，这样划分后设计会轻松很多。
控制参数什么时候降、什么时候升
把 GPT-5 用好的团队，靠的不是「好提示词」，而是好的默认值。按下面的标准来定初始值，运营会轻松不少。
| 控制参数 | 降低的场景 | 提高的场景 |
|---|---|---|
verbosity | 只想在 UI 上展示简短回答、只需要结构化结果时 | 需要代码评审说明、调试讲解、用户教育文档时 |
reasoning_effort | 简单分类、简短摘要、追求快速首次响应时 | 复杂 bug 修复、多步骤智能体任务、工具选择很关键时 |
推荐的思路是这样的。
verbosity调整的是用户阅读的感受reasoning_effort调整的是模型工作的深度
一开始就把两者都调高，质量看起来会不错，但成本和延迟会急剧上升；反过来两者都调得太低，速度是快了，但智能体解不透问题。
智能体编程中发生了什么变化
比起一次性的代码生成器，GPT-5 更像是一起读代码库的协作者。所以实战中重要的不是「能不能一次写好代码」，而是下面这条流程。
- 是否充分理解任务范围
- 是否恰当选取所需的文件和工具
- 是否边说明中间结果边推进
- 变更之后是否自行验证
- 失败后是否保留上下文重新尝试
在这类任务里，gpt-5 最合适，尤其在下面这些场景中更有优势。
- 需要在遗留代码库里做局部修改
- 需要同时改动多个文件并追踪原因
- 需要同时完成写测试、重构、更新文档
- 需要反复调用工具并随之调整计划
反过来，规则简单的小任务或大批量分类，不必上最高级的模型。这时优先考虑 gpt-5-mini 或 gpt-5-nano 会更划算。
自定义工具和格式约束如何搭配使用
自定义工具的核心价值，不在于「模型能调用工具」，而在于可以按任务调整工具输入的形式。
例如下面这些任务，用 plaintext 更自然。
- 执行 SQL 查询
- 校验公司内部 DSL
- 生成配置文件草稿
- 传递 shell 风格命令
而当格式很重要时，就加上输出约束。
- 正则表达式适合固定简单的模式。
- CFG 适合更复杂的语言语法或内部格式。
实务中可以这样组合：
- 工具输入用 plaintext 简化。
- 工具输出或模型响应用 regex 或 CFG 限制。
- 失败时留下人类可读的错误信息。
这种方式能让智能体给出的不是「大致对的答案」，而是真正可以执行的答案。
Responses API 和 Chat Completions API 该什么时候用
GPT-5 在两个 API 上都能用，但实务中的角色略有不同。
Responses API
新功能和智能体型工作流更适合用 Responses API。原因是它在工具使用、流式输出、结构化流程、长周期智能体设计上更契合。
Chat Completions API
如果与现有代码库的兼容性很重要，或者服务已经围绕 Chat Completions 搭建起来了，可以逐步保留下去。不过如果是新项目，长期来看 Responses API 更容易运营。
简单来说：
- 新的智能体产品优先用 Responses API
- 既有的遗留服务保留 Chat Completions，或分阶段迁移
该如何降低成本和延迟
GPT-5 很强大，但用不好成本也会轻易膨胀。实务中最有效的两个方法是提示词缓存和 Batch API。
提示词缓存
如果系统提示词、工具说明、公共示例这类重复出现的前缀很长，提示词缓存会带来很大帮助。尤其是智能体应用会在多次请求中反复使用相同的策略和工具说明，缓存命中率通常表现很好。
好的模式大致是这样。
- 把固定指令放在前面。
- 把用户个别输入放在后面。
- 不要频繁改变工具列表和示例的顺序。
Batch API
不需要即时响应的大批量任务，很适合用 Batch API。例如下面这些任务就很适合批处理。
- 大批量分类
- 日志摘要
- 数据抽取
- 离线评估
Batch API 处理的是异步请求组，因此在延迟不那么重要的任务上，无论成本还是吞吐量都更有利。
实战标准
- 需要即时响应时，用在线请求。
- 相同前缀反复出现时，用提示词缓存。
- 不需要立即展示结果时，用 Batch API。
生产环境上线检查清单
把 GPT-5 投入生产环境时，运营设计比模型性能更重要。
- 把核心任务和辅助任务分开。
- 不要把
gpt-5、gpt-5-mini、gpt-5-nano混用于同一用途。 - 以团队为单位确定
verbosity和reasoning_effort的默认值。 - 统一自定义工具的输入格式。
- 提前找出需要 regex 或 CFG 的位置。
- 固定住能让提示词缓存生效的前缀。
- 把可以交给 Batch API 的任务拆分出来。
- 同时关注失败日志、延迟和 token 成本。
- 对智能体产出的结果做自动校验，或转交人工审核。
- 保持接口可以轻松更换模型。
这份清单的目的不是一次性做出完美的智能体，而是先搭好一条小而稳定的路径，再逐步扩展。
FAQ
GPT-5 最适合哪些任务
最适合复杂代码修改、跨工具的智能体任务、代码库理解、多步骤调试。
gpt-5-mini 和 gpt-5-nano 该怎么选
gpt-5-mini 适合通用产品功能和均衡型工作负载，gpt-5-nano 适合分类、抽取这类超低成本任务。
reasoning_effort 什么时候该调高
在追踪 bug 原因、工具选择困难的任务、需要经过多个步骤的智能体循环中，调高会更好。
为什么 verbosity 很重要
即使答案相同，长度和说明详尽程度不同，UI 体验和运营效率也会有很大差异。只需要简短 JSON 或操作结果时，调低会更合适。
新项目该从 Responses API 还是 Chat Completions API 开始
新项目更适合从 Responses API 开始。如果与现有服务的兼容性要求很高，可以先保留 Chat Completions，再分阶段迁移。