GPT-5.5 能力退化？用分步骤验收法告别 Token 黑洞与盲盒式开发

我说怎么今天用 GPT-5.5 感觉有点弱智。

原因竟然在这里。

今天，ChatGPT 的开发者 Tibo 发了一条 X 说：“我们发现了并修复了两个问题，这些问题可以解释 GPT-5.5 在 Codex 中过去约 48 小时内能力退化的原因。”

！！！！！！

我为什么会觉得 GPT-5.5 能力有些退化？

起因是我这两天一直在用 goal 模式做一些东西。

但是我发现 goal 这玩意，它是 token 黑洞，不管你有多少 token，在 goal 模式下都显得微不足道。

而且 goal 模式下做出来的东西很难把控。

前两天还好，尤其是昨天和今天，我在 goal 模式下做出来的东西一言难尽。

原来是 Tibo 说了 GPT-5.5 有两个 Bug，希望这两个 Bug 修复完成后，GPT-5.5 会恢复智力水平。

这就相当于你跟 Codex 说：“你给我做一个 xxx 东西出来，我只看最后的结果。”

这个最后的结果，往往并不尽如人意。

让模型自己闷头做到最后再给你看，这个操作基本上等于开盲盒了。在开发者广场上，大家也经常吐槽这种“Token 烧了，代码废了”的窘境。

我觉得应该这样做：

分步骤验收。

第一阶段：先强制 AI 出“最小可行计划”，不准写代码。

在这个步骤下，你尽可能输出：

• 你对需求的理解
• 技术方案选型及理由
• 项目模块拆解（树状结构，每个模块一句话说明职责）
• 核心数据流/接口设计（文字描述即可）
• 预计生成的文件清单

确认计划后，不要让 AI 全量开工，开始进入第二阶段，规则如下：

• 每完成一个模块，立刻停下来展示代码和简要说明
• 必须等待我确认之后，才能进入下一个模块
• 如果我说“有问题”，你必须先修复当前模块再继续

遇到“一言难尽”的输出，用固化提问让 AI 自我诊断。

比如：

请检查你刚刚的输出，并回答：

• 需求符合度：你实际满足了原始需求的哪几点？遗漏了哪几点？
• 技术合理性：当前实现有没有过度设计、安全隐患或性能隐患？
• 可维护性：如果其他开发者接手，3 分钟内能看懂的部分占比多少？
• 改进方案：用 3 条以内的修改建议，让它达到生产可用标准。

在人工智能领域，尤其是大语言模型的应用中，这种精细化的 Prompt 设计至关重要。也就是说，你给越清晰的分步验收标准，它产出越惊艳。

你让它自己全权负责到底，它就会在某些节点开始自由发挥。这样不仅 token 账单疯狂燃烧，而且做出来的东西也一言难尽。如果想深入了解，可以参考相关的技术文档优化你的指令。