近期不少开发者反映 GPT 5.5 在编码任务上「降智」：简单改动要来回返工、计划不按计划执行、写到一半就说完成。也有人完全无感。本文把这类抱怨拆成服务端变化、客户端配置、任务与心理偏差三层，给出可照着做的归因清单、上下文与提示词管理方法，以及换模型的取舍建议。
同一个账号、同一套提示词，上周还一次过的任务，这几天要来回改三四轮才勉强收尾。最近一段时间，AI 编程工具的用户里反复出现这类抱怨：模型好像悄悄变笨了。有人列出很具体的症状——改到一半就说改完了、自己定的计划自己不遵守、代码里已经有同名变量还要再造一个、简单功能写得异常复杂、上下文用量进度条不见了、额度掉得比以前快。另一部分人则完全无感，日常任务照常胜任。
分歧之所以大，是因为「变笨」是一个混合了服务端行为、客户端配置、任务难度漂移和主观对比的结果。把它整体归因于「服务商偷偷降级」，既无法验证，也找不到改善的着力点。更实用的做法是：先分层归因，再逐项排除，把能自己控制的部分调回来。
先把「降智」拆成三层
第一层：服务端。 模型版本轮换、请求被路由到不同规格的实例、推理预算被压缩、高峰期排队降级、单个账号的配额与限流策略调整，都会让输出质量波动。这部分用户无法直接观测，只能通过「同一提示词、同一任务、多次运行」的对比来间接判断。
第二层：使用侧配置。 推理档位（低/中/高之类的设置）、上下文窗口占用、是否命中缓存、项目规则文件是否被改动、CLI 或插件的版本更新，都会显著改变输出。很多「突然变笨」的案例，最后发现是档位被重置或上下文塞得太满。
第三层：任务与心理。 模型帮你省掉重复劳动后，你自然会接更难的活；任务复杂度上升，返工率也上升。加上人对旧版本的记忆往往偏美化，很容易得出「以前一次就成」的结论。
一份归因自查清单
出现问题时，先对照下表定位，不要急着换工具。
| 观察到的现象 | 更可能的原因 | 先做什么 |
|---|---|---|
| 输出明显变短、草草收尾 | 推理档位被下调，或上下文接近上限 | 确认档位设置，换新会话重跑 |
| 计划不按计划执行、重复造变量 | 会话里堆积了互相矛盾的历史信息 | 精简上下文，把计划写进文件 |
| 只在个别项目触发安全类拦截 | 触发了策略分类器，与模型能力无关 | 换表述、拆小任务，走官方渠道反馈 |
| 额度消耗变快 | 计费规则、缓存命中率或重试次数变化 | 查看用量明细，减少无效重试 |
| 只在某些时段变差 | 高峰期排队或资源调度 | 换时段重试，保留备用方案 |
| 长时间会话后质量下滑 | 上下文污染与「遗忘」 | 单任务单会话，定期收口 |
稳定输出的具体做法
固定档位，做一次 A/B 对比
不要依赖默认配置。显式指定推理档位，并记录当前使用的模型标识；遇到质量波动时，先用完全相同的提示词跑两次，确认是不是配置被改动。如果客户端支持锁定模型快照或版本，升级前后用同一个基准任务对比，比凭感觉判断可靠得多。
控制上下文，别让会话无限延长
这是收益最大的一条。具体可以这样做：
- 一个任务一个会话，任务结束就收口，不要在同一会话里连续做三件不相关的事。
- 用文件承载状态：把计划、待办、已改文件写进
plan.md之类的文档，让模型每轮先读文件，而不是靠对话历史回忆。 - 大型重构拆成「调研 → 计划 → 单点改动 → 验证」四段，每段单独开一轮。
- 接近上下文上限时主动总结并另起会话，不要硬撑到被截断。
把验收标准写进提示词
模型「改到差不多就宣布完成」，往往是因为你没定义什么叫完成。给一个可直接套用的模板：
任务：<一句话描述>
范围：只允许修改 a.go 与 a_test.go，不得改动公共接口
流程：1) 先输出改动计划与风险点，等我确认；2) 再分步修改；
3) 每步运行 go test ./... 并贴出真实输出
完成标准：全部测试通过 + 给出 diff 摘要 + 列出未覆盖的边界情况
遇到阻塞：停下来说明原因，不要自行扩大改动范围
关键点有三个：先计划后执行、每步贴真实命令输出、明确禁止擅自扩大范围。「贴真实输出」这一条尤其有效，它把模型的自我评价变成了可核对的事实。
用外部检查补上模型的自律
再强的模型也会自我感觉良好。稳妥的组合是：
- 测试、lint、类型检查、CI 当裁判，模型只负责改，合不合格由工具说了算。
- 重要改动让另一轮会话或另一个模型做 review，交叉验证。
- 对同一个任务，让两个模型各出一版，比较差异而不是直接采纳。
错峰与备用通道
如果问题只在特定时段出现，先换时间重试，再用同一提示词重复两三次。仍不稳定，就保留一条备用路线：换模型、换客户端或换接入方式。另外，如果你的长任务经常因为网络中断导致会话重连、上下文丢失、从头再来，看起来也像「模型变笨」，可以把这类跑几十分钟的 CLI 会话放到一台长期在线的机器上执行；例如整机放在机房的远程 Mac 租用方案，网络环境相对稳定，适合长时间挂着的编码会话，属于可选做法之一，不是必需。
换不换模型，看任务类型
社区里对「哪家更强」分歧极大。一种观点是某类工具能一次成型，另一种工具修一个 bug 冒出三个；反过来也有人认为后者回答简短、不懂就说不知道，前者话多、容易在同一个地方打转，真正干活时反而低效。
两边说的其实不是同一件事。差异通常来自任务形态：
- 边界清晰、可被测试验证的小改动：更看重一次成型率，选输出克制的。
- 需要长链条推理的架构级改造：更看重计划质量与自洽性，适合先出方案再执行的工作流。
- 探索性、说不清需求的任务：适合能主动追问、肯承认不确定的模型。
与其站队，不如按任务分工：日常修补用一个，复杂重构用另一个，关键节点互相 review。这比反复更换工具更能降低返工率。
几个容易踩的坑
- 把偶发当趋势。 单次失败说明不了什么，至少用同一提示词重复三次再下结论。
- 忽视静默更新。 模型与客户端的更新往往不写进显眼的公告，具体的档位名称、额度规则、可用模型请以官方最新文档为准。
- 迷信第三方中转。 不同接入渠道的差异可能远大于模型本身的波动；共享账号、非官方渠道除了质量不可控，还存在合规与封号风险，不建议使用。
- 只调模型不改流程。 大部分可改善的部分在使用侧：上下文更干净、验收标准更明确、外部检查更严格，往往比换一个模型立竿见影。
小结
「降智」是真实存在的体验波动，但它不是单一原因造成的。先确认档位和版本，再压缩上下文、把验收标准写死、用测试与交叉 review 兜底；只有在这些做完之后仍然明显退化，才值得考虑更换模型或执行环境。这样即使服务端确实在变，你的返工成本也不会跟着一起失控。