GPT-5.6 试用了半天：强，但真的慢
古董级程序员，大厂出来后一直在创业公司，现在仍在一线做 AI 相关开发。更完整的技术记录写在微信公众号「字与码」：AI 编程、工程实践、新工具试用和这些年踩过的坑，会不定期发在那里。若这篇对你有用，欢迎顺手关注。
先说最直接的感受：慢，真的慢。
我不是在跑一个几十万行代码库，也不是让它自主工作两小时。只是让 GPT-5.6 Sol 审查一段 11 行的异步 Python，单次等待就在 21 到 44 秒之间。把任务换成搜资料、读飞书文档、生成配图、写中英文文章并构建网站以后，那种“模型还在想”的停顿会被不断放大。
但它也确实强。对事务边界、行锁、阻塞 I/O、异常回滚、缓存一致性这些容易被普通代码审查漏掉的问题，Sol 的四个推理档位都找全了。问题不在于它会不会做，而在于什么任务值得等。
这篇文章就是一次完整试用记录。它没有拿官方 benchmark 代替体验，而是把我这次看到的耗时、token 和成本都摊开。
我现在用到的 GPT-5.6 是什么
OpenAI 在 2026 年 6 月 26 日先发布了 GPT-5.6 的有限预览，系列里有三个长期档位：Sol 是旗舰模型，Terra 平衡能力与成本，Luna 主打速度和低价。到了我写这篇文章的 7 月 10 日，GPT-5.6 已开始向符合条件的 ChatGPT 套餐逐步开放；官方帮助页同时写明，Codex CLI 至少需要 0.144.0。
我的环境是：
Codex CLI: 0.144.1
默认模型: gpt-5.6-sol
默认 reasoning effort: medium
日期: 2026-07-10
时区: Asia/Shanghai这点很重要。GPT-5.6 仍在滚动开放，别人暂时看不到，不一定是命令写错，也可能是套餐、账号或 workspace 权限还没开。
官方资料：
同一道题，先测 Sol 的四个推理档位
测试方法
我准备了一段 11 行的异步 Python。里面人为放了 7 类问题：同步 HTTP 阻塞事件循环、异常路径未回滚、提前返回未清理事务、远程 I/O 跨越事务和行锁、缓存先于数据库提交、用户不存在未处理、响应 JSON 未校验。
四次调用使用完全相同的提示词，只修改：
model = gpt-5.6-sol
model_reasoning_effort = low | medium | high | xhigh测试通过 codex exec --ephemeral --json 串行执行。串行是为了避免四个请求同时抢本机与服务端资源。耗时取墙钟时间，token 取 Codex 返回的 turn.completed.usage。这是一次真实冷启动观察，不是多轮统计 benchmark。
实测结果
| 推理档位 | 耗时 | 输入 token | 缓存输入 | 输出 token | reasoning token | 得分 | API 等价成本 |
|---|---|---|---|---|---|---|---|
| low | 27.28 秒 | 19,155 | 8,960 | 793 | 331 | 7/7 | $0.0792 |
| medium | 21.26 秒 | 17,441 | 8,960 | 749 | 268 | 7/7 | $0.0694 |
| high | 43.92 秒 | 17,416 | 8,960 | 1,260 | 783 | 7/7 | $0.0846 |
| xhigh | 36.18 秒 | 17,416 | 8,960 | 1,466 | 1,034 | 7/7 | $0.0907 |
四次合计 75,696 token，按 GPT-5.6 Sol 官方标准 API 价格折算约 $0.3239。计算方式是：未缓存输入 $5/1M、缓存读取 $0.50/1M、输出 $30/1M。reasoning token 已包含在输出 token 中，不重复计费。
最有意思的不是 high 最慢，而是 medium 反而最快。这不代表 medium 永远比 low 快，只能说明档位不是延迟的唯一变量。排队、缓存命中、输出长度、请求路由以及额外安全检查，都会让单次结果抖动。
这道题上，high 和 xhigh 花了更多 reasoning token，却没有换来更高得分。我的结论很简单：日常代码审查先用 medium；问题真的复杂、需要跨文件推演或多轮验证，再提高档位。不要因为下拉框里有更高档，就每次都拉满。
再测 Sol、Terra、Luna
GPT-5.6 的“档次”还可以指模型家族本身。于是我把 reasoning effort 固定为 medium，再让三个模型回答同一道题。
| 模型 | 耗时 | 得分 | 输入 token | 缓存输入 | 输出 token | API 等价成本 |
|---|---|---|---|---|---|---|
| Sol | 21.26 秒 | 7/7 | 17,441 | 8,960 | 749 | $0.0694 |
| Terra | 23.43 秒 | 7/7 | 17,416 | 9,472 | 836 | $0.0348 |
| Luna | 31.44 秒 | 6/7 | 16,225 | 8,960 | 1,406 | $0.0166 |
价格来自官方公布的每百万 token 标准费率：Sol 为 $5/$30，Terra 为 $2.50/$15，Luna 为 $1/$6，分别对应输入和输出；缓存读取是输入价的 10%。
这次 Luna 不但没有最快，还漏掉了“响应 JSON 结构与 name 字段需要校验”，转而指出了响应对象释放问题。后者也合理，但不在预设的 7 项评分点里，所以记为 6/7。
不要根据这一轮就断言 Luna 比 Sol 慢。更可信的判断是：
- Sol 适合难题和长链路工程任务，但等待感最明显，输出也贵。
- Terra 在这次小样本里保住了正确率，成本约是 Sol 的一半，是我更愿意日常使用的档位。
- Luna 的价格最低，适合格式转换、简单修改和批处理；碰到事务、并发和隐蔽正确性问题时，最好加验证或换高一级模型。
慢，慢在哪里
模型吐字速度只是一部分。Codex 做完整任务时，时间还花在这些地方：读取仓库规则、发现和加载技能、访问外部文档、调用浏览器或插件、生成图片、运行测试与构建，以及在结果不确定时回头验证。
GPT-5.6 的官方发布说明还提到两件事：Sol 新增更深的 max reasoning effort；ultra 会借助 subagents 处理复杂工作。它们不是我这次 CLI 四档单题测试的一部分，也不能直接和 xhigh 画等号。产品界面、API 参数和 Codex 配置里的档位名称可能不同，写自动化脚本时最好以当前客户端实际支持的配置为准。
另一个容易忽略的因素是安全检查。官方说明，部分生物和网络安全请求可能触发额外检查，响应会明显变慢。我的题只是正常代码审查，没有出现提示，但“慢”不总是纯推理造成的。
用 Codex Sites 做网站：这次走到哪了
我还让 Codex Sites 生成了一个“城市气象观察站”：前端展示天气、空气质量和七日预报，服务端计划通过 QVeris 动态发现并调用工具，而不是把某个 tool_id 写死。
这个场景很适合 Sites。它不是一张静态 landing page，而是需要环境变量、服务端 API Route、缓存、错误状态、移动端适配、真实工具调用和发布地址的完整小应用。
官方把 Sites 描述为由 ChatGPT 创建、托管、迭代和分享网站的能力。每一个部署 URL 都是生产部署；发布时可以选择仅自己、workspace 成员或任何拿到链接的人访问。详情见 OpenAI Sites 文档。
本轮真实结果
Sites 最终不是从 codex plugin list 里找到的。它出现在支持该能力的 Codex App 界面中，不是一个带独立 sites 命令的 CLI marketplace 插件。把完整 Prompt 交给 Sites 后，它生成了 React/TypeScript 网站，并部署到：
https://city-weather-lab-qveris.ax2675996.chatgpt.site/
刚部署时，匿名访问会返回 401，要求使用 ChatGPT 登录。把分享范围改成“互联网中的所有人”后，无登录、无 Cookie 的请求返回 200，可以直接拿到完整页面。它仍带有 X-Robots-Tag: noindex, nofollow，所以属于“任何拿到链接的人可以访问”，并不是会被搜索引擎主动收录的普通公开站点。
托管由 OpenAI Sites 管理，域名属于 chatgpt.site，外层经过 Cloudflare CDN。响应里的 Cloudflare 节点只能说明本次请求从哪个边缘节点进入，不能据此推断源站物理位置。
网站生成和发布已经成功，但实时数据还没有打通。我直接请求北京、新加坡和伦敦的 /api/weather，三个接口都返回 200；响应中的 source.demoMode 均为 true，toolId 是 demo-weather-current。这说明目前展示的是 Sites 生成的演示数据，不能当成 QVeris 真实调用结果。下一步仍需在 Sites 设置中配置托管环境变量，重新部署，再核对脱敏后的 tool trace。
当前验收结果
| 验证项 | 本轮结果 | 后续验收标准 |
|---|---|---|
| Sites 入口 | Codex App 中可用，CLI 插件列表不可见 | 两种入口不要混为一谈 |
| 网站生成 | 已完成 | React/TypeScript 页面可正常返回 |
| 在线地址 | 已完成 | 匿名访问返回 200，分享范围为互联网中的所有人 |
| QVeris 调用 | 未完成，当前 demoMode: true | 北京、新加坡、伦敦返回真实天气；页面展示脱敏后的 tool_id 与耗时 |
| 凭证保护 | 页面和接口响应未发现 API Key | 配置托管 secret 后再次检查浏览器源码、网络响应和构建产物 |
| 响应式 | 待补 | 1440px 与 390px 截图无重叠、遮挡和横向溢出 |
| 异常降级 | 页面已预留状态，真实调用尚未验证 | 天气、预报、空气质量可独立失败，保留最近一次成功数据 |
这次已经拿到了 URL，也确认了公开分享行为；剩下最重要的不是再截几张漂亮界面，而是把演示数据换成真实 QVeris 调用。真正完成的标准仍然包括实际 tool_id、调用耗时、失败切换、凭证检查，以及桌面和移动端的视觉验收。
这篇文章本身花了多少
我把统计窗口固定为收到需求到第一次完整本地构建通过：2026-07-10 12:16:51 至 12:27:42（Asia/Shanghai），墙钟时间 10 分 51 秒。
| 部分 | token |
|---|---|
| 主写作线程 | 4,005,615 |
| 4 次 Sol reasoning effort 实测 | 75,696 |
| Terra medium 实测 | 18,252 |
| Luna medium 实测 | 17,631 |
| 合计 | 4,117,194 |
合计包含 4,093,319 个输入 token（其中 3,792,640 个为缓存输入）和 23,875 个输出 token；reasoning token 已包含在输出中。主线程按 Sol 费率计价，六次独立测试按各自 Sol、Terra、Luna 费率计价，合计 API 等价成本约 $4.0148。
这里的金额只是按 GPT-5.6 Sol 标准 API token 价格计算的等价原始成本，不是 ChatGPT 或 Codex 订阅账单。当前会话还调用了飞书文档、网页检索、图片生成和本地构建；第三方工具、图片与订阅权益不包含在这个 token 金额里。
我的暂时结论
GPT-5.6 给我的第一印象不是某个 benchmark 又高了几分，而是它更像一个愿意把复杂工作做完的工程搭档。代码审查里，它能稳定看到事务和缓存之间的关系；写文章时，它也能把来源核对、实测、配图和构建串起来。
代价就是等待。简单任务用 Sol 的 high 或 xhigh，常常是在花更多时间确认一个 medium 已经能答对的答案。Terra 可能是更实用的日常档位，Luna 则需要更明确的验收条件。
所以我的用法会是：默认 Terra 或 Sol medium；难题再升档；批处理交给 Luna；任何一次看起来很漂亮的结果，都用测试和真实调用收尾。
微信公众号
欢迎关注「字与码」
如果这篇文章对你有用，也欢迎在微信里继续关注后续更新。
X / Twitter
关注 @ax2_zicode
更即时的技术观察、新文章提醒和一些短想法会发在 X 上。
