GPT-5.6 系列终于正式发布了。
这次 OpenAI 一共推出了三个型号：面向复杂任务的 Sol 、主打平衡的 Terra ，以及追求速度和成本的 Luna。
从官方公布的数据来看，GPT-5.6 Sol 在终端操作、浏览器自动化、长上下文和 Agent 任务上的表现都非常突出，部分成绩甚至超过了 Claude Fable 5 和 Claude Mythos 5。
🔥🔥🔥本篇笔记所对应的视频：www.bilibili.com/video/BV1j9...
但跑分表只能告诉我们模型在标准化测试中拿了多少分，无法回答一个更实际的问题：
把一个真正复杂的任务交给它，它到底能不能做出来？
为了弄清楚这一点，我没有只让它写几个函数或者生成一个简单网页，而是连续安排了九组难度完全不同的任务：
- 用 SVG 制作三只鸟在土星环上骑自行车的动画；
- 模拟复合弓从开弓到箭矢命中靶心的完整过程；
- 推理并动画演示一个复杂的农夫过河问题；
- 使用 Three.js 创建波音 747-8 的外部和机舱三维模型；
- 使用 Godot 4 开发侏罗纪坦克射击游戏；
- 使用一句非常简短的提示词开发 A-10 空战游戏；
- 开发一套原生 iOS 背单词 App、Chrome 扩展和云端同步系统；
- 操控浏览器进入 Tinkercad 创建三维房屋模型；
- 验证模型的知识覆盖和近期信息掌握情况。
测试完成以后，我对 GPT-5.6 Sol 最大的感受，不是它突然变得无所不能了。
而是它越来越像一个能够接手完整项目的人。
它仍然会犯错，也会误解指令，甚至会为了尽快完成任务主动寻找捷径。但只要任务目标足够清楚，它确实比过去的大多数模型更愿意继续追踪问题，把代码、测试、功能和最终交付一起做完。
一、先把 Max、Pro 和 Ultra 说清楚
GPT-5.6 Sol 发布后，OpenAI 同时推出了 Max、Pro、Ultra 等不同名称，很容易让人误以为它们是不同模型。
其实不是。
Max 是推理强度
GPT-5.6 Sol 支持多档推理强度：
none、low、medium、high、xhigh、max
推理强度越高，模型能够用于分析问题的时间和计算量越多，但延迟和 Token 消耗也会随之增加。
我在这次测试中，大部分复杂任务使用的都是 Extra High。
它适合大型代码开发、复杂逻辑推理、跨文件修改和需要反复验证的任务，但完全没有必要用来修改按钮颜色或者调整一段文案。
Pro 是高质量运行模式
Pro 更重视最终答案的质量，而不是速度和成本。
它更适合架构设计、安全审查、复杂研究，以及做错一次就会造成很大损失的任务。
Ultra 是多智能体模式
Ultra 默认由多个 Agent 并行处理任务，再由主 Agent 汇总结果。
它和 Max 的区别非常明显：
- Max：让一个人多想一会儿；
- Pro：让一个人按照更高标准完成任务；
- Ultra：让几个人同时开工。
如果任务可以拆成前端、后端、数据库和测试四个独立方向，Ultra 会很有价值。
但如果只是修改同一个文件，让四个 Agent 同时工作，往往只会产生重复劳动、上下文膨胀和修改冲突。
二、GPT-5.6 Sol 的核心参数
OpenAI 没有公布 GPT-5.6 Sol 的参数量、训练规模和具体架构。
目前能够确认的主要参数包括：
上下文窗口：1,050,000 Tokens
最大输出：128,000 Tokens
官方模型资料标注的知识截止日期：2026 年 2 月 16 日
输入类型：文本、图片
输出类型：文本
暂不支持：音频输入、视频输入和微调
API 模型名称：gpt-5.6-sol
它还支持网页搜索、文件搜索、代码解释器、Hosted Shell、Computer Use、MCP、Skills、图像生成、Apply Patch 和 Tool Search 等工具。
GPT-5.6 Sol 的标准 API 价格为：
- 输入：每百万 Tokens 5 美元；
- 缓存读取：每百万 Tokens 0.5 美元；
- 缓存写入：每百万 Tokens 6.25 美元；
- 输出：每百万 Tokens 30 美元。
这里还有一个容易被忽略的细节。
当单次请求的输入超过 272K Tokens 后，整个请求都会进入长上下文计价区间，输入和输出价格都会进一步上涨。
所以百万上下文并不意味着应该把整个代码仓库、几十份 PDF、所有日志和历史对话一次性全部塞进去。
它解决的是"放不下"的问题，却无法自动解决"内容太乱"和"重点不突出"的问题。
第一轮测试：模型自己说的知识截止日期可靠吗？
我首先在 ChatGPT 网页版中询问了两个问题：
第一，它的知识截止日期是什么时候？
第二，它知道的日本最新首相是谁？
网页端给出的回答是，知识截止日期为 2025 年 12 月，同时也正确回答了当时的日本首相。
至少从这个简单测试看，它对近期政治信息的覆盖没有出现明显断层。
但这里也暴露出一个值得注意的问题：
模型自己回答的知识截止日期，和官方模型资料中的日期并不完全一致。
这说明我们不能单纯依赖模型自报身份、版本和知识截止日期。真正需要确认模型参数时，仍然应该以官方模型卡和 API 文档为准。
模型可以回答自己是谁，但它对自身运行环境的描述不一定永远准确。
第二轮测试：三只鸟在土星环上骑自行车
第一道真正的能力测试，是让 GPT-5.6 Sol 使用 SVG 制作一段动画：
一只几维鸟、一只渡渡鸟和一只鹈鹕，分别骑着自行车在土星环上比赛。
我还要求：
- 必须是真正的 SVG 动画，而不是静态图片；
- 土星环就是赛道；
- 背景中需要出现太阳、地球、火星和木星；
- 三只鸟和自行车都要有清晰的运动效果。
最终生成的结果总体不错。
土星、土星环和背景中的几颗行星都被画了出来，鹈鹕和渡渡鸟的外形也比较容易辨认。自行车车轮会持续转动，而且不同车辆还表现出了不同的运动速度。
不过，它犯了一个非常明显的错误：
几维鸟是倒着骑自行车的。
几维鸟最长、最明显的嘴部应该朝向前进方向，但它生成的身体朝向刚好相反。
这次测试说明，GPT-5.6 Sol 已经能够同时处理：
- 多个角色；
- 场景构图；
- SVG 元素；
- 循环动画；
- 自行车机械运动；
- 太空背景；
- 不同物体的相对比例。
但它对角色朝向和生物结构的理解还不够稳定。
单从最终视觉效果来看，这次生成结果已经可以使用，不过和我之前测试 Claude Fable 5 时得到的版本相比，细节和整体完成度仍然略逊一筹。
第三轮测试：复合弓、滑轮和箭矢抛物线
第二道 SVG 测试更加困难。
我要求它制作一段男性使用复合弓射箭的动画，并且必须表现出：
- 拉弓过程；
- 复合弓滑轮转动；
- 弓片发生形变；
- 箭矢离弦；
- 箭矢沿抛物线飞行；
- 最后准确命中远处的靶心。
结果一开始就出现了问题。
尽管提示词里明确要求使用 SVG，它第一次仍然直接调用了图像生成工具，给我生成了一张静态图片。
我再次强调：
用 SVG，不是用图像生成。
第二次它才真正生成了可运行的 SVG 动画。
修正后的结果包含了拉弓特写、滑轮转动、放箭、箭矢飞行和命中靶心等完整过程，还加入了动画进度显示。
从功能完整性来看，它确实理解了我想要的整个过程。
但在物理结构上仍然有一个严重问题：
它把复合弓拿反了，弓片弯曲的方向也是反的。
这次测试暴露了 GPT-5.6 Sol 的两个短板。
第一，它有时会根据任务内容自行选择工具，即使这个选择和提示词里的明确要求冲突。
第二，它可以生成"看起来像那么回事"的物理动画，却不一定真正理解机械结构中的受力方向。
箭能够飞出去，滑轮也会转，靶心也能命中。
但这些元素组合在一起，不代表物理关系一定正确。
第四轮测试：把复杂逻辑推理变成 SVG 动画
接下来，我把逻辑推理和动画生成结合在了一起。
题目是一个经过扩展的农夫过河问题。
农夫需要把老虎、羊、蛇、鸡和一筐苹果安全送到对岸，但船每次只能搭载农夫和一样东西。
同时存在三组特殊关系：
- 农夫不在时，老虎会吃羊，但鸡可以阻止老虎；
- 农夫不在时，蛇会吃鸡，但老虎可以阻止蛇；
- 农夫不在时，羊会吃苹果，但蛇可以阻止羊。
普通的大模型测试，通常只需要输出一段文字步骤。
这次我要求 GPT-5.6 Sol 不仅要推导出正确方案，还要使用 SVG 动画完整演示整个过河过程。
最终，它给出的主要顺序是：
- 农夫先带羊过河；
- 农夫返回；
- 带鸡过河；
- 返回；
- 带老虎过河；
- 返回；
- 带蛇过河；
- 返回；
- 最后带苹果过河。
这套顺序是成立的。
更重要的是，它没有只输出几个移动的小圆点，而是做出了一个完整场景：
- 出发岸和目标岸；
- 河流和小船；
- 会摆动的船桨；
- 老虎、羊、蛇、鸡和苹果；
- 天空中的太阳、云和飞鸟；
- 岸边的树木；
- 当前步骤文字；
- 农夫和物品的动态移动。
这次结果让我比较意外。
因为模型必须先完成逻辑推理，再把推理结果转换成时间轴，最后还要把每一步对应到 SVG 动画状态。
它唯一比较明显的 Bug，是农夫独自划船返回时，整个人会变成倒立状态。
原因很可能是模型为了复用同一个角色元素，直接使用了整体翻转，而没有单独处理人物朝向。
但除了这个问题，整段动画的推理顺序、场景元素和播放流程都比较完整。
在我看来，这个案例比单纯让模型回答一道逻辑题更有价值。
因为它不只证明了模型"知道答案"，还证明了它能够把答案转换成一个真正可运行、可观察的产品。
第五轮测试：波音 747-8 的外部和机舱三维模型
完成 SVG 测试后，我继续加大难度，让它使用 Three.js 创建波音 747-8 洲际客机的三维模型。
要求包括：
- 完整的 Three.js 场景；
- 相机、灯光和渲染器；
- 机身、机翼、发动机和尾翼；
- 鼠标旋转和缩放；
- 外部视角；
- 机舱内部视角；
- 多排经济舱座椅；
- 过道、舷窗和行李架；
- 在外部与内部之间自由切换。
等待几分钟后，它生成了一个可以直接运行的版本。
外部视角下，可以对飞机进行 360 度旋转和缩放。机身、机翼、尾翼和四台发动机都已经具备，整体轮廓也能看出波音 747-8 的特征。
点击"进入机舱"后，视角会切换到飞机内部。
用户可以在机舱中转动视角和前后移动，内部也确实包含座椅、窗户和过道。
不过它实现的过道明显过于狭窄，部分座椅和机舱空间比例也不够合理。
这说明它已经能搭建完整的三维交互体验，但距离精准的工业建模还有很大差距。
如果目标是展示概念、制作网页 Demo 或快速验证交互方式，这个结果已经足够。
如果要还原真实飞机尺寸、空气动力学结构或者舱内布局，就必须提供更严格的尺寸数据和参考模型。
第六轮测试：半小时开发一款侏罗纪坦克射击游戏
网页端的测试主要集中在 SVG 和 Three.js。
进入 Codex 后，我决定把难度再提高一个等级。
过去测试大模型的游戏开发能力时，我经常使用 Three.js。但对现在的模型来说，使用 Three.js 制作一个网页小游戏已经不算特别困难。
所以这一次，我改用 Godot 4。
第一个任务，是开发一款可以直接运行的 3D 侏罗纪坦克射击游戏。
游戏设定是：
玩家驾驶一辆现代坦克进入侏罗纪时代，通过鼠标控制炮塔和准星，可以射击恐龙、翼龙、树木、石头以及突然出现的 UFO。
我只提前创建了一个空的 Godot 3D 项目，然后把需求完整交给 Codex。
大约半小时后，游戏已经能够直接运行。
进入场景以后，可以看到一辆完整的 3D 坦克。键盘可以控制前进、后退和转向，鼠标能够控制炮塔方向，点击后会发射炮弹。
炮弹击中树木后，树会倒下。
场景里还出现了多种不同外形的恐龙和天空中的翼龙。玩家可以驾驶坦克在地图中寻找并攻击这些目标。
更出乎意料的是，它还实现了随机出现的 UFO。
UFO 不只是一个装饰模型，而是会主动攻击玩家。坦克可以转动炮塔进行还击，命中后 UFO 会坠落并发生爆炸。
它还加入了环境音效、射击音效、爆炸效果，以及不同类型的恐龙模型。
这个项目当然还称不上完整商业游戏。
画面精细度、敌人 AI、碰撞反馈和关卡设计都有提升空间。
但它已经不是一段用来演示语法的代码，而是一款具备基本循环的游戏原型：
移动、瞄准、射击、敌人攻击、目标被摧毁、爆炸反馈。
从一个空的 Godot 项目到能够运行的三维射击原型，大约用了半小时。
这已经足以说明，GPT-5.6 Sol 的优势不是只会生成某一段代码，而是能够在一个真实工程里持续创建场景、脚本、节点和交互逻辑，最后把它们拼成一个完整结果。
第七轮测试：提示词越短，它能不能自己发挥？
完成侏罗纪坦克游戏后，我又测试了一个相反的方向。
前一个任务的提示词非常详细，几乎把玩法、操作方式和场景元素都规定好了。
这一次，我故意只给它一个很短的任务：
使用 Godot 4 开发一款可以直接运行的 3D 空战原型。玩家驾驶 A-10 攻击机，可以攻击地面的坦克和装甲车，需要模拟导弹发射和机炮射击，其余部分由模型自行发挥。
大约 20 分钟后，项目完成。
游戏支持第三人称和第一人称视角切换。
飞机可以：
- 加速和减速；
- 拉升和俯冲；
- 左右转弯；
- 进行滚转；
- 发射机炮；
- 发射导弹；
- 躲避敌方导弹；
- 攻击地面目标。
画面中还会实时显示飞机速度。
第一人称座舱视角的效果尤其不错，导弹发射、飞行和爆炸也已经形成完整反馈。
测试过程中，我还因为操作失误直接撞到了地面。这从另一个侧面说明，它确实实现了飞机和地形之间的碰撞，而不只是播放一段预设动画。
这个案例说明，GPT-5.6 Sol 不仅能够根据详细规格执行，也能够在提示词非常简短的情况下自行补全大量设计。
但这并不意味着提示词越短越好。
提示词越短，模型发挥空间越大，结果也越不可控。
如果只是做创意原型，这种自主发挥非常有价值。
如果开发的是正式产品，仍然应该明确规定控制方式、核心玩法、性能要求、代码结构和验收标准。
第八轮测试：从零开发一套真正可用的 iOS 背单词产品
整个测试中，最复杂、也最有代表性的案例，是一套原生 iOS 背单词产品。
这次我没有让它开发一个只有几个页面的小型 MVP，而是明确告诉它：
除非遇到无法解决的技术障碍，否则不要主动缩小范围，尽可能实现接近最终产品的体验。
整个产品包含三个部分：
- 原生 iOS App；
- Chrome 扩展插件；
- Supabase 云端数据和大模型 API。
Chrome 扩展负责用户阅读英文网页时的取词。
用户双击不认识的单词后，扩展需要显示：
- 中文解释；
- 当前语境中的含义；
- 英文例句；
- 发音；
- 原始网页句子。
用户可以把这些单词保存到 Supabase。
iOS App 再从 Supabase 中读取词库，并根据用户保存的单词生成学习计划。
更复杂的是，我还要求它把用户学过的单词随机组合起来，通过 OpenRouter 调用大模型生成一篇英文短文，让这些单词自然地出现在文章中，帮助用户在语境中强化记忆。
App 使用 Swift 和 SwiftUI 开发。
整个开发过程持续了一个多小时，中间也不是完全一次成功。我让 Codex 继续修复了多轮 Bug，才最终得到能够完整运行的版本。
这一点必须说清楚：
它不是一句提示词下去，几分钟后就凭空变出一个完全无 Bug 的商业产品。
但真正重要的是，它在遇到问题后没有停在一个残缺版本，而是继续修改，最终把整条产品链路跑通了。
账号和云端同步
App 首先实现了注册和登录。
用户创建账号后，首页会显示当前词库、学习进度和学习状态。
Chrome 扩展也可以登录同一个账号，并提供：
- 自动保存查过的单词；
- 保存网页语境；
- 隐私模式；
- 词库同步等选项。
我在一篇英文文章中连续双击了多个单词。
扩展能够弹出翻译卡片，显示单词在当前句子中的具体意思，而不只是给出脱离语境的词典解释。
随后，我把八个单词保存到了词库。
回到 iOS App 后，这八个单词已经同步出现。
学习计划和语境复习
点击开始学习后，App 会自动创建一轮学习计划。
每个单词不仅包含中文解释，还会显示用户当时在网页中看到它的原始句子。
这点非常重要。
很多背单词软件只保存单词本身，过几天后用户已经忘记当时为什么查这个词。
保留原始网页语境，可以让记忆重新和具体阅读场景建立联系。
用生词生成专属短文
完成单词学习后，用户可以选择文章主题，再点击"生成专属短文"。
我选择了四个刚刚学习的单词。
生成完成后，这四个单词都自然出现在短文中，并且被高亮显示。
页面还支持：
- 英文短文阅读；
- 中文翻译；
- 重点单词高亮；
- 整篇文章朗读；
- 完成阅读后进入练习。
其中朗读功能的声音比较机械，明显使用的是系统级语音合成。
这也是整个产品中比较明显的不足。
后续可以将它替换成质量更高的大模型语音 API，让长文章朗读听起来更自然。
选择题、听力、填空和口语识别
读完短文后，App 会自动进入巩固练习。
它实现了：
- 单词选择题；
- 正确与错误反馈；
- 听力题；
- 单词填空；
- 录音；
- 英语口语识别；
- 错题回顾。
我实际录入了一句英文，App 成功识别出了说话内容。
完成整轮学习后，它还会生成学习总结，显示：
- 本轮学习结果；
- 需要加强的单词；
- 错题；
- 学习进度；
- 解锁的徽章；
- 刚才生成的短文。
词库页面中，每个通过 Chrome 扩展保存的单词也可以单独打开，查看解释和原始语境。
这个案例真正说明了什么？
这个项目最有价值的地方，不是某一个页面设计得多漂亮。
而是 GPT-5.6 Sol 打通了完整的数据链路：
网页取词 → Chrome 扩展 → Supabase → iOS App → 学习计划 → 大模型生成短文 → 练习 → 学习总结。
它同时处理了：
- Chrome 扩展开发；
- SwiftUI 界面；
- 用户注册和登录；
- 云端数据库；
- 数据同步；
- 大模型 API；
- 文章生成；
- 语音播放；
- 录音和语音识别；
- 学习状态管理。
从最终完成度来看，这一次 GPT-5.6 Sol 开发的版本，甚至比我之前使用 Claude Fable 5 开发的版本更完整。
提示词中要求的大部分功能都实现了，其中一些学习流程和交互细节还超出了我原本的预期。
当然，这仍然是原型，而不是可以直接上架的正式产品。
真正发布前，还需要继续处理：
- API Key 的安全存储；
- 后端代理；
- 数据库权限；
- 隐私政策；
- 异常状态；
- 离线模式；
- 订阅和付费；
- App Store 审核要求；
- 更自然的语音合成。
但它已经证明了一件事：
复杂 Agent 模型正在从"帮你写代码"，走向"帮你搭建产品"。
第九轮测试：让它接管浏览器创建 Tinkercad 房屋模型
最后，我测试了 GPT-5.6 Sol 的浏览器自动化能力。
我让 Codex 接管浏览器，进入 Tinkercad，创建一个简单的房屋三维模型。
它首先进入 3D 设计工作区，然后开始寻找可以使用的元素。
原本我以为它会使用立方体、屋顶、门窗等基本几何体，从零搭建一座房子。
但它很快清空了当前内容，在搜索框中直接搜索"房子"，找到一个现成房屋模型，拖到工作区，再对尺寸和参数进行调整。
最后，它保存了这个房屋模型，并告诉我任务已经完成。
这个结果非常有意思。
从任务目标来看，我只要求它"创建一个简单的房子模型"，并没有明确规定必须从几何体开始搭建。
所以它并没有违反指令。
它只是发现了一条更快完成目标的路径。
这说明 GPT-5.6 Sol 已经不再机械地把每一个动作都从头执行，而是会观察环境、寻找现有资源，再选择成本更低的方案。
但这个案例也带来了一个非常重要的提醒：
模型完成了任务，不代表它使用的是你预期的方法。
如果我的真实目的不是得到一座房子，而是测试它能否使用基本几何体完成建模，那么提示词中就必须明确写出：
- 禁止使用现成房屋模型；
- 必须从立方体、屋顶和门窗开始；
- 必须展示完整建模步骤；
- 最终模型需要由指定数量的基本形状组成。
否则，模型会优先优化最终结果，而不是遵循你脑海中没有写出来的过程。
三组测试之后，我认为 Sol 真正强在这五个地方
把 SVG、Three.js、Godot、iOS 和浏览器自动化放在一起看，GPT-5.6 Sol 的特点已经非常明显。
第一，长任务韧性明显提高了
过去使用代码 Agent，经常会遇到一种情况：
模型完成了表面修改，测试还没跑完，边界条件没有处理，文档也没有同步，然后就告诉你任务已经完成。
GPT-5.6 Sol 更愿意继续追踪问题。
尤其是在 iOS App 开发中，它经历了一个多小时和多轮 Bug 修复，最终仍然把 Chrome 扩展、Supabase、SwiftUI 和大模型接口连接了起来。
它不是不会失败。
它的提升在于，失败后更愿意继续做。
第二，它更擅长完成整条链路
很多模型可以单独写一个 SwiftUI 页面，也可以单独写一个 Chrome 扩展。
真正困难的是把这些部分连接起来。
Sol 在这次测试中表现最突出的能力，正是把不同技术栈组合成一个完整工作流。
它不是只生成一堆互不相关的文件，而是尝试让数据真正从一个系统流向另一个系统。
第三，它会主动补全提示词没有写明的内容
A-10 游戏的提示词非常短，但它主动补充了：
- 第一人称视角；
- 飞行速度显示；
- 导弹攻击；
- 飞机滚转；
- 地面碰撞；
- 敌方攻击。
这种自主性在创意原型中非常有价值。
但在正式项目中，也意味着必须提前写清楚边界。
第四，它仍然会犯低级的空间和物理错误
几维鸟倒着骑车、复合弓方向错误、弓片弯曲方向错误、农夫返回时倒立、飞机机舱过道过窄。
这些错误有一个共同特点：
模型实现了主要功能，却没有完全理解现实世界中的结构、比例和方向。
所以在涉及机械、建筑、医学、工程和真实物理结构时，不能因为动画"能动起来"，就默认它是正确的。
第五，它会为了完成目标主动寻找捷径
Tinkercad 房屋模型是最直观的例子。
它没有从零搭建，而是直接搜索现成模型。
这和 METR 测试中发现的某些行为虽然性质不同，但背后有一个相似点：
模型会主动寻找最快满足完成条件的路径。
这不一定是坏事。
在人类工作中，复用现成资源本来就是一种效率。
问题在于，如果某些路径不能使用，就必须提前写进约束，而不能指望模型自行理解。
跑分很强，但绝不是全面碾压
GPT-5.6 Sol 在 Terminal-Bench 2.1 中获得 88.8 分，Ultra 模式达到 91.9。
它在 DeepSWE、BrowseComp 和 OSWorld 等涉及终端、网页和计算机操作的测试中也表现突出。
这些结果和我的实际体验基本一致。
Sol 最强的并不是单次代码补全，而是：
- 使用终端；
- 创建和修改多个文件；
- 调用工具；
- 观察运行结果；
- 根据错误继续修复；
- 最终完成一个可运行项目。
但在 SWE-Bench Pro 中，Sol 的成绩仍然明显落后于 Fable 5。
Artificial Analysis 的综合测试中，Sol Max 也没有全面超过 Fable 5。
这说明它并不是在所有任务中都更聪明。
我的判断是：
Sol 更擅长把东西做出来，而且做得完整、可运行；Fable 5 在部分需要细腻理解、代码可读性和严密分析的任务中，仍然可能更强。
这两个模型并不是简单的上下级关系，而是工作风格不同。
GPT-5.6 Sol 应该怎么用，才能发挥真正优势？
1. 不要只写一句"帮我开发一个 App"
Sol 的自主性很强。
如果不给出验收标准，它会自己判断什么叫完成，而这个判断不一定和你相同。
一个完整任务至少应该写清楚：
- 最终目标；
- 技术栈；
- 必须实现的功能；
- 不允许使用的方法；
- 测试方式；
- 完成条件；
- 哪些操作必须人工确认。
2. 明确"结果约束"和"过程约束"
Tinkercad 案例里，我只规定了结果，没有规定过程，所以它直接复用了现成模型。
以后可以把约束分成两类。
结果约束：
- 最终必须生成什么；
- 必须达到什么质量；
- 必须通过哪些测试。
过程约束：
- 必须使用什么方法；
- 禁止使用哪些捷径；
- 哪些步骤必须展示；
- 哪些资源不能调用。
只写结果，模型会寻找最快路径。
结果和过程都写清楚，才能得到真正符合预期的交付。
3. 重要任务必须要求它实际验证
不要让模型只说"已经完成"。
应该要求它：
- 运行项目；
- 执行测试；
- 检查构建结果；
- 提供错误日志；
- 验证主要功能；
- 列出仍然存在的问题。
在 iOS App 项目中，真正有价值的并不是它生成了多少代码，而是最后确实完成了注册、取词、同步、文章生成和练习流程。
4. 日常任务不要一上来就开 Max 或 Ultra
普通代码修改和文档整理，Medium 或 High 通常已经足够。
Max 更适合复杂架构、疑难故障和高风险决策。
Ultra 则只适合能够真正并行拆分的任务。
模型越强，越要学会控制计算量，而不是无脑把所有选项开到最高。
5. 把不同模型放到最适合的工序
目前更务实的方式，不是寻找一个包打天下的模型，而是按照任务路由：
- Sol：长流程执行、工具调用、完整产品交付；
- Fable 5：架构审查、代码可读性、复杂分析；
- Luna：批量处理、提取、转换和低成本任务；
- Ultra：能够真正拆成多个独立方向的大型项目。
可以先让 Fable 5 设计架构，再让 Sol 实现。
也可以先让 Sol 完成产品，再让 Fable 5 进行代码审查。
模型之间的竞争，正在逐渐变成不同工序之间的分工。
一套更适合 GPT-5.6 Sol 的任务模板
text
你是本项目的交付负责人，不是只提供建议的顾问。
目标：
[写清楚最终需要解决的问题]
最终交付物：
[代码、文件、报告、应用或可运行项目]
技术要求：
[技术栈、平台、依赖和版本]
必须实现：
1. [核心功能]
2. [核心功能]
3. [核心功能]
禁止事项：
1. [不能使用的捷径]
2. [不能修改的内容]
3. [未经批准不能执行的操作]
验收标准：
1. 项目可以实际运行或构建。
2. 必须执行相关测试。
3. 必须验证主要用户流程。
4. 不得只根据代码推测功能可用。
5. 必须列出仍然存在的问题。
工作规则：
1. 先检查现有项目和环境。
2. 制定实现计划，再开始修改。
3. 遇到错误后继续定位和修复。
4. 涉及删除数据、发布、付款或生产环境时，必须暂停。
5. 最终只交付完成结果、验证记录、已知问题和后续建议。这套模板最重要的不是让提示词变长。
它真正解决的是四个问题：
什么才算完成，哪些捷径不能走，什么时候必须停下来，以及最后拿什么证明结果可信。
写在最后
完成这九轮测试后，我认为 GPT-5.6 Sol 并不是一个在所有方面都碾压其他模型的"全能模型"。
它会把几维鸟画反，会把复合弓拿反，会让农夫倒立，也会在 Tinkercad 里直接找一个现成房子交差。
但与此同时，它也能在半小时内做出一款可玩的 Godot 三维射击游戏，在简短提示词下自行补全空战玩法，还能持续一个多小时，把 Chrome 扩展、Supabase、SwiftUI 和大模型 API 连接成一套真正能够运行的学习产品。
这就是 GPT-5.6 Sol 最值得关注的地方。
过去，我们判断一个模型好不好，主要看它能不能给出正确答案。
现在，更值得问的问题变成了：
它能不能在长时间工作后仍然记得最初目标？
能不能自己发现缺失的功能？
能不能在遇到 Bug 后继续修复？
能不能把代码、界面、数据库、测试和最终交付连在一起？
能不能真正运行项目，而不只是生成几段看起来合理的代码？
从这次测试来看，GPT-5.6 Sol 已经越来越接近一个能够负责完整交付的 Agent。
它不一定是每一道题里最聪明的学生。
但在真实工作中，它可能是那个最愿意把项目做完、把现场收拾干净，最后还回来检查一遍的人。
而这，往往比跑分多拿几分更重要。
本文基于截至 2026 年 7 月 10 日的公开资料和实际测试结果整理。不同账户、运行环境、推理级别和工具权限可能导致结果存在差异。