GPT-5.6出来之后，我更关心的是：它放进真实工作里，到底能不能真的提高效率。
所以这两天，我拿它做了几类平时真的会遇到的任务：小范围代码修改、产品Demo开发、开发测试验证，以及中文内容输出。
用下来之后，最直接的感受是：
它确实更强，但也真的更慢。
而且这个“慢”，不只是模型输出慢、思考慢。
更明显的问题是：它会把一个原本边界清楚的任务，主动扩展成一整套庞大的执行流程。看起来每一步都很认真，但真正推进任务的部分，可能只占很小一截。
最高档，不等于最适合
一开始我其实很自然地选择了Sol Ultra。
因为过去用模型时，我们很容易形成一个习惯：遇到重要任务，就开更强的模型、更高的推理档位。既然Ultra看起来是最高配置，那它当然应该最稳、最强、最适合处理复杂任务。
但真正用下来，我发现GPT-5.6这套配置不能简单按“越高越强”来理解。
这里至少有三层设置需要分开看。
|
|
|
|
|
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
也就是说，Sol、High、Ultra其实回答的是三个不同问题：
用哪个模型，
让它想多深，
要不要用多智能体并行执行。
Ultra不是“更聪明一点”，而是“动用更多执行角色”。
这也是它容易变慢、变重的根源。
如果把这三件事混成一条简单的能力阶梯，就很容易得出一个错误用法：
既然Ultra最强，那日常就默认开Ultra。
我的实际体验刚好相反。
Ultra不是万能默认档，它更像一把重型工具。
任务足够复杂、边界足够清楚、工作流能够拆开时，它可能有价值；但如果只是日常开发、小步修改、反复验证，它很容易把一个小任务做成大工程。
它不是不会做，是太想做全
我第一次明显感觉不对，是从一个很小的任务开始的。
那个任务本身并不复杂，边界也比较清楚。我原本期待它快速读一下相关代码，定位问题，然后给出修改。
结果Ultra上来就拉起了三个子智能体：
一个读本地文件，
一个分析产品逻辑，
一个梳理项目结构。
整个过程看起来很全面，甚至有点“专业团队开工”的感觉。
但最后它干了二十分钟。
这二十分钟不是完全没有价值。它确实读了东西，也做了分析。
问题在于：这个任务根本不需要这么大的阵仗。
它不是不会做，而是太想把事情做完整。
那一刻我最强烈的感受是：
Ultra很容易把“认真”做成“过度”。
对于边界清楚的小改动，真正重要的是快速定位、快速验证、快速收口。
但Ultra会倾向于先理解全局，再建立上下文，再组织证据。听起来都没错，可一旦任务本身很小，这些动作就会变成启动成本。
小任务最怕的不是能力不够，而是动作太重。
跑了十小时，项目还是没收住
第一次小任务很慢以后，我其实还没有完全失望。
我当时的想法是：既然Ultra擅长拆解复杂问题、调用子智能体，那也许它更适合真正复杂的任务。
于是我做了一个更激进的尝试。
我拿了一个自己设计的产品Demo给它做。
这个Demo大致是一个文本创作工作台。当时产品设计还不完整，前端也没有形成完整闭环。
我给它的任务范围很宽：
先完成产品设计，
再完成技术设计和存储设计，
然后持续开发，
直到整个项目完成。
现在回头看，这个指令本身就有问题。
它同时混合了产品、交互、架构、数据、工程实现和验收，而且没有明确分阶段边界。
但这次尝试也正好让我看到了Ultra在长任务里的风险。
这次运行几乎变成了一次没有明显停顿的超长交互。随着时间推移，产品目标、技术设计、局部实现、验证工作混在一起。
前面确定的内容没有稳定约束后面的开发，后面的改动又不断影响前面的结构。
最后，任务连续运行了大约十个小时。
项目仍然不可用。
这不是“主体完成，还差人工收尾”。
而是产品闭环和工程实现都没有真正收住。
这次经历给我的提醒非常直接：
工作了很久，不等于项目正在稳定接近完成。
更强的并发、更长的运行时间，如果没有清晰边界，可能不是提高效率，而是把混乱放大。
真正拖慢人的，往往不是模型
后来还有一次开发和测试任务，让我重新理解了GPT-5.6的“慢”。
一开始我以为，它慢主要是因为模型本身更重，推理时间更长。
但复盘整个执行过程以后，我发现问题不止在这里。
更大的问题是：它会把有限任务扩张成庞大的流程。
原本的问题可能只是：
执行一次，
发现入口不对，
确认正确入口，
修复，
重新验证。
但Ultra会把它做成一个大型交付项目：
维护候选版本，
记录阶段状态，
补充问题证据，
扩建测试流程，
反复验证环境，
再由主控重新检查一遍。
这些事情单独看都合理。
但全部叠加到一个局部问题上，治理成本很快就超过了业务本身。
这就是GPT-5.6使用中最容易被忽略的地方：它不是偷懒，而是过于完整。
问题在于，不是每个任务都需要完整。
有些任务只需要先跑通最短路径，确认关键问题，再决定是否沉淀成框架。
但模型很容易反过来：
任务被放大
本来只是定位入口、修复、重验，最后变成了调查、记录、建测试、写状态。
验证太早变重
主流程还没跑通，模型已经开始补预检、观察器、恢复场景。
子智能体重复工作
每个智能体都像在做完整调查，并发没有缩短路径，反而增加交接成本。
缺少超时机制
外部操作其实已经失败，但流程还在继续等待。
主控重复验证
子智能体验证过，主控回来又跑一遍，成本被继续叠加。
所以，“GPT-5.6很慢”至少有两种含义。
第一种，是模型本身更愿意思考，等待时间变长。
第二种，是它会主动生成过多流程，让真正工作在整个任务里的占比变低。
很多时候，第二种更致命。
多几个智能体，不等于多几个人干活
Ultra最容易让人误解的地方，是“多个子智能体”。
一听到多智能体，很多人会自然觉得：那应该更快。
我一开始也有类似预期。
但实际用下来，并不是这样。
并发只有在任务彼此独立、资源互不冲突时，才真的能节省时间。
如果测试、环境调查、正式逻辑都争用同一个窗口、同一个账号、同一个外部资源，那所谓多智能体就不是并行，而是多了几个排队的人。
更麻烦的是，子智能体如果继承了过重的任务说明，每个角色都会把自己理解成“做一份完整调查”。
一个去全面探索，
一个去运行取证，
一个去代码对照，
一个去文档沉淀。
结果并发没有缩短关键路径，反而增加了启动、阅读、交接和汇总成本。
所以，是否适合Ultra，关键不是任务看起来大不大，而是能不能真正拆开。
|
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
这里最重要的判断是：
多智能体不等于并行。
它只是多了几个执行角色。
真正决定效率的，不是角色数量，而是任务能不能拆开、资源会不会冲突、每个角色有没有明确边界。
否则，越多智能体，越像一次复杂会议。
大家都很努力，但事情并没有更快。
慢归慢，它确实有几处变强了
说到这里，好像GPT-5.6全是问题。
如果只谈速度，它确实容易让人失望。但真正用它处理复杂工作后，我也能明显感受到一些提升。
第一，中文输出更成熟。
它的表达不是简单更通顺，而是更接近一份可以直接交付的专业稿。结构、语气、解释分寸，都比之前更稳。
很多时候，它给出的不是一个答案，而像是已经完成了一轮编辑和审阅。
第二，架构分析更强。
它更容易同时看到多个层面的问题：
当前实现是什么，
模块边界在哪里，
一个局部修改会影响哪些结构，
短期修复会不会引入长期成本。
这对真实开发很有价值。
因为很多工程问题不是“会不会写代码”，而是能不能识别约束、解释取舍、避免为了修一个小问题埋下更大的坑。
第三，它对不确定性的处理更克制。
它更愿意区分哪些是已经确认的事实，哪些只是推测。面对代码、文档、权限、外部系统这些有边界的事情时，这种克制很重要。
但这里必须分开两件事：
单次分析更稳，不等于长程自治更可靠。
一次回答里边界感更好，不代表把整个产品交给它跑十小时，它就一定不会偏航。
这也是这次体验里最值得记住的一点：
模型能力变强以后，不代表人可以完全退出任务管理。
恰恰相反，能力越强，越要把任务边界写清楚。
别默认拉满，先把任务变小
这几次尝试之后，我对Ultra的用法变得很明确：
它不是默认选项，而是特定场景下才值得打开的重型模式。
如果是日常小改、多轮确认、明确问题，更重要的是快反馈。
如果是复杂架构、疑难问题、重要方案，可以让模型想得更深，但仍然要限制范围。
如果是目标很宽的长任务，不适合直接丢给Ultra持续跑，而应该先拆阶段、定边界、设验收。
可以简单理解成这样：
|
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
重点不是“以后不用Ultra”。
而是：
不再默认Ultra。
真正省时间的，不是永远使用最强模型。
而是让合适的模型，在合适的任务边界里工作。
这类Agent任务，至少需要提前明确几件事：
限定它能看的范围。
让它先跑最短路径验证。
要求它阶段性停止。
定义什么叫完成，什么叫失败，什么叫不确定。
能五分钟确认的问题，不允许它做成三十分钟调查。
AI越强，越不能把任务说得太虚。
AI越强，越需要人会管
所以，我现在对GPT-5.6的态度比较明确。
它不是一次没有代价的升级。
它确实更强。
中文表达更成熟，架构分析更深入，对边界和不确定性的处理也更稳。
但它的代价也很直接：
等待更长，流程更重，而且在目标过宽、阶段不清、验收缺失时，它可能会以更大的规模跑偏。
所以，它不应该被简单理解成“全面替代上一代模型”。
更准确地说，它是一种更强、也更需要管理的工作伙伴。
边界清楚时，它的质量提升是值得的。
目标过宽时，它的强能力反而可能变成风险。
尤其是Ultra。
Ultra不是默认档，也不是“无脑最强档”。
它适合处理真正复杂、可拆解、可并行的任务。
但如果只是日常开发、小步修改、反复验证，它很可能把你带进一套过度完整的流程里。
最后看起来一直在工作，实际上没有更快接近完成。
这可能也是AI工具进入真实生产后，最值得警惕的一件事：
模型越来越强，不代表任务会自动变简单。
更强的AI，不会替我们消灭管理。
它只会让不会管理的问题，暴露得更快。