本文最初写于 2026 年 7 月 10 日，背景是 GPT-5.6 公开上线与 Codex 和 ChatGPT Work 的应用整合。下文保留当时的价格图、评测与使用观察；其中的数字不是当前报价，模型名称也不是今天的选型清单。
1. 按任务选模型，不只看版本号
GPT-5.6 发布时分为 Sol、Terra、Luna，分别侧重高能力、均衡和快速经济。这样的分工提醒我们：不同任务未必需要同一档模型。
可以先把任务分为复杂设计、日常修改、批量处理，再用实际结果测试哪种模型足够。不要只因名字更新，就替换已经稳定的工作流。
2. 用实际账单评估成本
2026 年 7 月的模型发布集中讨论了能力与成本。下图保留当时的 API 价格对比，后来已有调价，不能拿它估算今天的账单。
估预算时记录完整任务的输入、输出、重试和工具开销，定期复核价格。不要预设价格会继续下降，也不要把 API 单价直接当作订阅消耗。
3. 给更换模型留出空间
当时社区讨论了许多下一代模型的发布时间；未经确认的传闻不能用来安排项目交付。即使发布节奏很快，也没有必要每次发布都迁移。
把模型名集中在配置中，把提示词和业务逻辑分开。新模型通过自己的验证后再替换，并保留退回原方案的办法。
4. 用自己的任务复核榜单
同一批模型在不同评测里可能有不同排序。下图是当时媒体对多个榜单的整理，适合说明评测口径的差异：
固定三五个真实任务，例如典型 bug 修复、新功能和重构。使用相同输入、测试和验收标准，比较通过率、耗时、费用及人工返工量。
5. 先判断任务是否适合并行
GPT-5.6 的 ultra 发布介绍强调多个 agent 并行处理复杂任务。并行可以减少互不依赖的等待，却也会增加协调与检查工作。
把边界清楚、互不修改同一份内容的任务拆开，约定输入、输出和汇总方式。有强依赖的步骤按顺序做，不为增加 agent 数量而拆任务。
6. 工具调用也需要边界
当时介绍的 Programmatic Tool Calling，让模型通过小段程序调用工具、处理中间结果，再把必要信息带回上下文。它减少重复传递数据的思路有价值，但不能保证每项任务都省下固定比例的 token。
交代清楚工具可以读取什么、写入什么，以及出错后的处理方式。自动串联工具之后，仍需核对输出与权限范围。
7. 把界面检查写进验收要求
当时的模型演示包括打开界面、检查渲染与修改细节。能生成代码，不等于页面已经能用。
让 AI 在交付前检查主要屏幕尺寸、按钮、表单和错误状态，并提供实际检查结果。最终仍要由人确认关键流程，不能把模型自评当作验收通过。
8. 简单任务可以测试更低成本的模型
OpenAI 当时公布的 Coding Agent Index 中，Luna 的结果高于 Claude Opus 4.8。这说明价格与某项评测成绩并非简单对应，也不代表 Luna 在所有工作中更好。
方案跑通后，可用自己的评测集尝试更低成本模型；同时比较返工和失败成本。若质量下降，保留原模型，不为降低单价牺牲交付。
9. 长任务需要检查点
Notion 联合创始人 Simon Last 在发布页的评价中，提到 GPT-5.6 能持续专注于较长的任务。这是当时的使用反馈，不是任何任务都能连续运行数天的保证。
把大目标拆成可验收的小任务，写清完成条件，并安排阶段检查。保留代码、文档和测试结果，避免只在最后查看一次输出。
10. 模型分数不能代替人的判断
发布时的 ARC-AGI-3 表格中，Sol 得分为 7.78%。单个评测既不能概括全部能力，也不能说明模型可以独立承担每一种决策。
代码合并、数据删除、资金操作和对外发布等动作，应设置相应的权限与人工确认。让 AI 执行清楚的任务，并把结果放回真实业务条件下检查。
长任务触及用量限制时，可查看 Codex 用量与重置时间指南，按账号实际显示安排后续工作。需要了解额外点数与订阅额度的区别，可读 Codex 点数使用说明。
常见问题
Vibe Coding 是什么？
通常指用自然语言描述需求，让 AI 生成并迭代代码的开发方式。人仍需明确范围、检查代码、运行测试并验收结果。
这篇文章的价格与评测是最新的吗？
不是。本文以 2026 年 7 月 GPT-5.6 发布为背景，图片和数字保留当时语境。当前选型需要重新查看官方信息，并用自己的任务测试。
是不是应该把所有任务交给多个 agent 并行？
不是。适合并行的是边界清楚、相互独立的工作。有强依赖或会同时修改同一内容的任务，需要先安排顺序和协作方式。
模型更省 token，是否意味着订阅一定能多用固定次数？
不能这样换算。完整任务的上下文、工具调用、重试和所用模型都会影响实际消耗，应查看账号用量和重置时间。