GPT-5.6 在 2026 年 6 月 26 日以有限预览的形式发布，并在 7 月 9 日正式发布。在 GPT-5.5 时期，我已经订阅了 ChatGPT Plus，并且基本将日常的 AI 编程工作切换到了 Codex App。
另外，Codex 项目的 Engineering Lead Thibault Sottiaux（X.com 上的 @thsottiaux，大家一般叫他 Tibo）经常会因为服务问题、用户增长或者一些活动，给用户重置 Codex 用量。过去一段时间，大家肯定都享受过好几次这样的重置（还有重置卡）。
考虑到 GPT-5.6 应该会消耗更多用量，我在全量发布当天就把 ChatGPT Plus 升级到了 ChatGPT Pro 5x，想着接下来可以放开使用。
GPT-5.6 有三个版本。Sol 是最大的旗舰模型，Terra 是成本和能力比较均衡的版本，Luna 则更快、更便宜。这次更新除了模型，比较重要的是这三个模型都可以在 Codex 和 ChatGPT Work 中使用，他们把两个 App 给统一了。
我之前在五月份也订阅过一次 Pro，但当时用得比较保守。虽然额度已经不少，我还是会担心提前用完，所以经常先判断一个任务是否值得使用最强模型。有些功能会先交给便宜的模型尝试，确定做不下去之后再换模型。
这次我不想再考虑这些事情。我升级 Pro 的主要目的就是保证用量充足，然后集中体验 GPT-5.6，以及新的 Codex 工作方式。
结果过去这一周基本都在写新应用，新功能。
一周内不断重置的 Codex 用量
这一周最明显的感受其实是累。
“无限“续盘的自助餐
GPT-5.6 发布之后，Codex 用户数量一直在增加。Tibo 之前说过，每增加一百万用户会重置一次用量。过去这一周，用户数连续经过六百万、七百万、八百万和九百万，再加上一庆祝活动，实际发生了好几次 reset。
我没有准确统计到底有多少次，大概有五六次，还送了一张重置卡。
同时，ChatGPT 这次的服务也相当稳定。虽然同时使用的人很多，但我没有遇到长时间无法运行的情况。加上官方临时把五小时用量限制也取消了，所以理论上可以在几个小时内用掉原本一周的配额。
这就产生了一个问题。
如果按照平常的速度慢慢使用，可能还没有用掉多少，十几个小时后又迎来一次重置。我就会觉得应该趁现在多做一点，于是不断打开新的项目，或者给已有项目增加新的功能。
这很像一个不断续餐的自助餐。每次觉得今天已经做得差不多了，又看到用量被重新填满，于是继续安排新的任务。那几天醒来刷手机就看到 Tibo 的推文说又重置了，晚上一直熬夜到一两点就是为了睡前布置几个新的任务。
根据模型调用的公开价格粗略计算，我这一周使用的 Token 可能价值一两千美元，就感觉自己付出去的 100 美元就很值了。
模型生成代码的速度很快，但我必须检查它生成的内容。
它说功能已经完成，我需要打开项目确认；它修改了数据结构，我需要看是否影响旧数据；它生成了几份设计文档，我也要判断这些设计是否有必要。几个 Agent 可以同时工作，但我一次只能认真检查一个。
到后面，限制进度的不是 Codex 的用量，而是我已经不想继续看代码了。
WriteLLM 与 规格驱动开发
这一周做得最多的项目是 WriteLLM。
WriteLLM 是我正在开发的一个 Electron 桌面应用，主要用于 AI 辅助的长篇写作。它需要一个支持 Markdown 的块编辑器，也会包括本地文件管理、PDF 和 Office 文档解析、知识库、向量检索、SQLite 数据库以及后台任务队列。
我一开始准备使用 GitHub Spec Kit，尝试比较完整的 Specification Driven Development。
按照 Spec Kit 的流程，需要先根据需求创建 specification。Specification 中会定义功能需求和用户故事，然后生成 implementation plan，再将计划拆分成具体任务。执行过程中还可以不断检查实现是否符合原始需求。
我能理解这种方式的价值。对于团队项目，它可以将需求、技术选择和具体决策保存在文档中。之后增加功能或者更换开发人员时，可以回到原始文档确认当时的设计。
但我实际使用后的体验很差。
首先，这个流程会生成大量文档。Specification、plan 和 task list 都写得很详细，但我没有耐心逐份阅读。如果我不仔细检查，直接让 Codex 按照这些文档继续执行，最后往往会生成很多没有必要的功能。
例如一个原本很简单的模块，模型会提前加入接口层、适配器和兼容逻辑，再为一些尚未确定的需求预留扩展能力。单独看每项设计似乎都有理由，但加在一起后，整个项目会变得很复杂。
界面也有类似的问题。模型会使用常见的 Dashboard 布局和组件组合，功能看起来比较完整，但很容易出现明显的 AI 生成风格。信息很多，层级也很多，真正需要使用的功能反而不够直接。
这次尝试大概持续了十二个小时，几乎用掉一个完整的 Pro 周用量。项目确实生成出来了，但实现方式并不是我想继续维护的状态。
后来我放弃了严格执行 Spec Kit 的完整流程。
现在我的做法是先用 Pro 模型检查项目架构和技术选择，确定一个阶段需要实现的功能，然后交给 Codex 执行。完成之后，我会另外启动一个 Agent，检查当前实现是否遗漏功能、是否出现过度设计，以及代码是否偏离原来的目标。这个过程可能会重复几轮，直到我满意为止。
文档仍然会保留，但形式比较简单。通常是一份 implementation TODO，里面记录当前阶段需要完成的任务，以及几项重要的设计决定。我会阅读和维护这份文档，而不是一次生成大量 specification。
这种方式目前比较适合我。
WriteLLM 现在已经完成了前几个阶段，核心的桌面应用结构、本地存储和部分任务系统已经可以运行。还有一些小问题需要修改，后续也有几个阶段没有开始，但至少目前的代码结构和功能范围仍然在我的控制之内。
处理 Course Handbook
另一个项目是我一直在维护的 CourseDB 平台。
这个项目从 2024 年开始开发，中间使用过很多不同的 AI 编程工具。
平台中有一类数据来自学校发布的 Programme Handbook。每个专业的 Handbook 会列出不同学年的课程安排，包括必修课、选修课类别、学分要求和具体课程。我要将这些内容转换成平台能够导入的 JSON 格式。
这项工作以前主要靠手工处理。
我之前也尝试过让模型直接解析 PDF，但效果不够稳定。Handbook 中包含很多表格，单纯提取 PDF 文字时，很容易丢失行列之间的对应关系。某一门课程可能会被分配到错误的类别，学分要求也可能和上一行或者下一行混在一起。
这次我先给 Codex 提供了一份已经正确转换的 Handbook，包括原始 PDF 和最终的 JSON，让它分析转换过程中需要识别哪些信息。
然后，我只提供原始 PDF，让它自己进行一次转换。转换完成后，我再把正确的 JSON 交给它，让它比较两者之间的差异，检查哪些规则理解错了。
经过几轮之后，Codex 整理出了一套相对固定的处理步骤。我再把其他尚未转换的 Handbook 交给它批量处理。
现在的 Codex 可以直接截取 PDF 页面并查看图像。遇到复杂表格时，它可以根据页面中的实际排版，判断课程名称、课程代码、学分和课程类别分别对应哪一列，而不是只依赖 PDF 提取出来的纯文本。
最后，我在一个晚上处理完了 35 个专业、每个专业四个学年的 Handbook。
我简单检查了生成结果，大部分内容都是正确的。少量格式特殊的专业仍然需要手工修正，但原本可能需要一两周的录入工作已经基本完成。
这部分工作和写代码没有太大关系。Codex 主要负责理解文档、转换数据和检查结果，但它解决了 CourseDB 平台中一个拖了很久的问题。也允许我通过结构化的 Handbook 数据实现了自动选课排课的 Skill。
Gym App 和远程开发
这一周我还开始做一个记录健身训练的 App。
这个 App 的需求比较简单。我需要记录每次训练使用了哪些器械、重量、组数和次数，方便日后追踪同一器械的重量变化（个人的进步）。因为主要在手机上使用，所以界面需要优先考虑手机屏幕。
开始时，我先让 GPT-5.6 Pro 规划项目结构和技术栈，然后让 Codex 直接执行。大概一个多小时后，它完成了第一个网页版本，并部署到了 Cloudflare Workers。
我去健身房时，这个版本已经可以访问。
训练中，我直接使用这个 App 记录数据。发现某个按钮不好操作，就通过手机上 Codex 远程连接和发任务的功能，让它修改按钮位置和交互；发现器械和动作数量不够，就让它继续增加数据；有些动作缺少说明，我也让它补充动作介绍和示意图。
Codex 修改完成后会继续更新代码和数据库。我刷新网页，就可以检查新的版本。
这个体验让我大受震撼。我先做出一个可以使用的版本，然后根据实际训练时遇到的问题不断修改。
最近我又让 Codex 生成了一个 iOS 版本。这个版本目前仍然比较简单，但已经可以安装到手机上使用。
整个过程中，我没有花很多时间亲自写代码。我的工作主要是描述需求、在真实环境中测试，再检查 Codex 的修改结果。
Kimi K3
还在猛用 Codex，7 月 16 日，月之暗面发布了 Kimi K3。
Kimi K3 的总参数规模达到 2.8 万亿，使用 MoE 架构。它支持原生视觉输入和一百万 Token 上下文，主要面向长时间编程、知识工作和推理任务。Kimi 计划在 7 月 27 日发布完整模型权重。
这个参数规模非常大。此前大家讨论的一些大型开源模型还在一万亿参数左右，K3 已经接近三万亿。
K3 发布之前，我考虑订阅其他 Coding Plan 都扭扭捏捏的，得反复比较火山引擎的 Plan 对比 OpenCode Go 是否值得。K3 上线，我看完推特上的评价，脑子一热就直接订阅了 Kimi 的 199 元档计划（Allegretto 连续包月，结果现在官方因为算力问题，已经暂停新开了），准备实际测试一下。
使用后的体验比我预期更好。
GPT-5.6 在过去一周完成了很多任务，但经常会有一些小问题。它有时会声称任务已经完成，检查后却发现仍有遗漏；或者完成了主要功能，但没有处理某些边缘情况。一般不是什么严重错误，不过需要继续补充一两轮任务。
我测试 K3 的任务数量还不算多，但它在检查项目时通常会读取更多文件，也会将发现的问题和修改任务写得更明确。至少在几次代码审查和任务规划中，它给出的结果比 GPT-5.6 更完整。
这让我产生了一个想法。
我可以让 K3 负责分析整个项目和规划任务，作为 orchestrator；再让它直接通过命令行派遣 Codex 负责具体执行。
不过这个实验最后没有开始。
K3 的 Token 消耗很快（价格是 3/15 美元每百万输入/输出），我订阅计划中的周用量已经用完了。
如何使用大量 Token
我有一个朋友连续订阅了两个月 ChatGPT Pro。据他统计，这段时间总共使用了上百亿 Token，一天会使用两亿左右。
最开始听到这个数字时，我觉得很夸张。自己连续使用一周后，我开始理解这些 Token 是怎么被用掉的。
第一种方式就是开最高档思考 + 快速模式，我的第一个五小时在 15 分钟内就用完了。
第二种就是派遣多 Agent。一个 Agent 负责阅读项目和制定计划，几个 Agent 分别修改不同模块，再使用新的 Agent 检查代码和运行结果。只要项目足够多，一天内就可以产生大量调用。GPT 5.6 系列模型其实有一个不存在的 “Ultra” 档位，其实它并不是一个更高的思考档位，而是一个偏高的配置，配合偏向多 Agent 的工作方式，可以在短时间内产生大量调用。
最后是完全的 YOLO。直接让模型执行一个 Vague 的指令（比如用 Rust 重写，帮我把 A 换成 B），放所有的权限，几个小时后回来验收结果。这个过程也可以消耗大量 Token。
但能否用掉大量 Token，并不只是额度问题。
首先需要有足够多可以交给 Agent 的任务。然后要将任务拆分清楚，让多个 Agent 的工作不会互相冲突。完成之后还需要检查结果，决定哪些修改可以保留，哪些应该回退。
这些都是需要学习的。
这一周我尝试了 Specification Driven Development，也尝试过让 Codex 自动执行。前者产生了太多文档，后者又容易让项目出现不必要的设计。现在我使用的方式处于两者之间，但还没有形成固定流程。
模型也仍然会犯错。
我还不能将一个复杂项目完全交给 Agent，几个小时后回来验收结果。做到某个阶段后，我还是需要检查代码，根据实际情况调整计划。有时还要回退已经完成的修改，再换一种方式实现。
目前比较明显的变化是，代码生成速度已经不再是主要问题。
几个 Agent 可以同时执行任务，但我一次通常只能认真检查一个。模型完成任务后，等待 review 的代码和文档会不断积累。即使还有额度，我也不一定有精力继续增加新任务。
最后
过去这一周，我主要在 GPT-5.6 和 Kimi K3 之间不断切换。
WriteLLM 在一次不太成功的 Spec Kit 实验后重新调整了开发方式；Course 平台一次处理完了 35 个专业的 Handbook；Gym App 做出了网页和 iOS 版本，也实际带到了健身房使用。
这些项目都还没有真正完成。WriteLLM 后面还有几个阶段，Gym App 的功能也比较少，CourseDB 还需要持续迭代，和尝试获得用户的 Review。
我也没有得出哪一个模型一定更强的结论。
GPT-5.6 和 Codex 的工具集成更完整，远程，执行长任务都现成提供。Kimi K3 在我测试的几次规划和检查任务中表现很好，但用量消耗很快。199 元套餐（仅次于他们最贵的套餐）都不能敞开用。在后面有更多额度时，我还会继续测试两者配合的方式。
这一周最大的变化，是我开始更频繁地把完整任务交给 Agent，而不是我主动的去拆分任务。
这样做确实可以完成更多事情，不过也需要花更多时间检查结果。模型生成得越快，需要 review 的内容就越多。
到最后，这一周的疯狂烧 token 真的有点累了。感觉该回归研究一段时间了。