模型突然“降智”？别吵，先把变量抓出来
你有没有遇到过这种瞬间血压飙升的场景：
- 昨天还写得一手好代码，今天同样的需求开始胡言乱语
- 同一个会话里越聊越“失忆”，一直重复问你同样的问题
- 工具能不用就不用，或者反过来瞎调用，像在抽签
很多人第一反应：模型退化了。
更常见的真相是：你看到的是“叠加后的副作用”——推理时长、缓存策略、系统提示词约束，任何一个小改动都能把体验拧歪。
下面拿一次非常典型的事故当教材，把“降智”的三大来源拆开讲，再给你一套可直接照抄的排查流程。😌
这类“降智”，通常不是一个原因
某次公开说明里，团队把“变笨”归因到三类改动：
- 默认推理时长被调短
- 缓存/上下文清理写出 bug
- 系统提示词加了过强的“少说话”约束
它们单独看都不致命，叠一起就很像：模型智商被砍了。
关键点：用户体感是混合信号。你很难靠直觉判断是“模型真不行了”，还是“配置把它手脚绑住了”。
类型 A：推理时长被悄悄调短（表现：不动脑、浅尝辄止）
你会看到什么
- 解题像“看一眼就交卷”，缺少中间推导
- 复杂任务容易漏边界条件
- 写代码不做设计，直接堆 if else
为什么会发生
有些产品会把默认推理档位从“长”调到“中”。理由通常很现实：
- 高推理档位偶尔会想太久
- UI 看上去像卡死
- 速度指标更好看
问题在于：大多数用户不看设置，只会记住一句话：“它变笨了”。
你能怎么验证（3 分钟）
拿同一个任务，跑两遍：
- 一遍强制“深度思考/高推理”
- 一遍允许“快速回答/中推理”
看差异点：
- 方案是否更完整
- 是否主动列出风险、边界、测试点
- 是否能坚持“先澄清再动手”
可直接用的提示词
这个任务请用高推理模式处理。输出时先给一份“解题路线图”，再给答案。不要省略关键假设和边界条件。
类型 B：缓存/上下文清理出 bug（表现：健忘、重复、工具乱用）
你会看到什么
- 聊到第 6 轮，它像没听过前 5 轮
- 反复确认你已经回答过的信息
- 工具调用变得很奇怪：要么不用，要么一轮接一轮瞎用
- 额度消耗异常：同样的对话感觉更“烧 token”
常见诱因
产品会做缓存优化，比如：会话闲置超过一小时后，清理旧的“思考记录”来省 token。
真正坑人的情况是：本来只该清一次，结果实现成“每轮都清”。
模型就会出现一种非常像人的状态：
“我知道我在干活，但我忘了我为啥要这么干。”
你能怎么定位（不用任何内部权限）
用这套“小测试”就够了：
测试 1：一致性复述
- 让它记住 3 条约束（比如输出格式、接口字段、你要的风格）
- 连续对话 8～10 轮，每轮都插一个小修改
- 观察它是否稳定遵守早期约束
测试 2：额度与延迟异常
- 同样问题复制到新会话
- 比较两边的响应速度、工具调用次数、消耗是否明显不同
只要出现“旧会话明显更健忘、更烧 token”，八成是上下文/缓存相关的问题。
应急手段（真能救命）
- 直接新开会话（别恋战）
- 把关键约束贴到当前轮消息末尾，做一个“对话钉子”
- 对长项目用“会话摘要”机制：每 10 轮让模型输出一份项目状态，下一轮把状态贴回去
会话钉子模板：
你必须一直遵守：
- 输出用 Markdown
- 给结论 + 可执行步骤
- 代码默认 TypeScript
- 不要改变接口字段名
类型 C：系统提示词加了强约束（表现：突然变话少、变保守、信息密度下降）
你会看到什么
- 回答变短，看着“很干净”，但没信息
- 复杂问题被压缩成几句正确废话
- 工具调用之间几乎不解释
典型触发器
为了让模型少废话，有些系统提示词会加类似限制：
- 工具调用之间文本不能超过 N 个词
- 最终回复不能超过 N 个词（除非任务需要）
听上去合理，落地很容易出事：
- 模型为了满足字数，主动删掉推导
- 对“任务需要更多细节”的判断变保守
- 你感觉到的就是：同样聪明，表达能力被掐住了
你能怎么拆掉这个“隐形手刹”
你没法直接改系统提示词，但可以用两招对冲：
- 显式授权长度
这题允许你写长一点。给我完整推导、边界条件、验证方案。字数不限。
- 用结构换长度（更容易过限制）
用清单回答：结论 / 关键依据 / 步骤 / 风险 / 验证。每项不超过 6 行。
清单会迫使模型把信息装回去，还不容易触发“太长”。
给你一套通用“降智排查流程”（可复制到团队 Wiki）
你下次遇到“它是不是变笨了”，别凭感觉吵架，按这 6 步走：
1）锁定输入：同一问题、同一提示词、同一输出格式
把你的问题固定成一个测试用例，别边测边改。
2）做 A/B：新会话 vs 旧会话
旧会话更差 → 优先怀疑缓存/上下文。
3）切推理档位：高推理 vs 普通
高推理明显更好 → 优先怀疑默认推理时长/档位被改。
4）加“长度授权”或“结构化输出”
加完立刻变正常 → 优先怀疑系统提示词/字数限制。
5）记录三件事：工具调用次数、重复提问次数、约束遵守率
这三项是最稳定的“降智指标”，比主观印象靠谱。
6）把案例做成你的微型评测集（5～20 题就够）
别追求大而全，追求贴合你日常工作：
- 你常写的那类接口
- 你常做的那类文案
- 你最在意的那种边界条件
每次模型更新、产品改设置，用这套题跑一遍，结果一眼就知道哪里歪了。
示例：一组“能抓住退化”的小评测题（直接拿去用）
题 1：长任务规划（抓推理时长问题）
设计一个 7 天内可交付的爬虫 + 清洗 + 入库方案。要求：失败重试、反爬应对、日志结构、成本估算、验收标准。
看点：是否有边界、是否有验收、是否能落地到每天做什么。
题 2：多轮约束保持（抓缓存/上下文问题）
我们要生成 20 条商品标题。规则：不超过 18 字；必须包含品牌词；风格偏理性；禁用夸张词。记住规则，接下来我会逐条改。
看点：第 10 轮还记不记得“禁用夸张词”。
题 3：工具调用合理性（抓工具乱用/字数约束副作用）
给我一个 SQL 优化建议。表结构如下……（略）请你判断需不需要 EXPLAIN，需要就说明原因再给语句。
看点：会不会不解释就乱 call 工具，或者解释被压成一句话。
避坑清单（踩中一个就会很像“降智”）
- ✅ 同一个长会话聊到后面开始失忆：别硬撑，开新会话 + 贴会话摘要
- ✅ 回答突然短得离谱：给“长度授权”，再要求结构化
- ✅ 复杂问题一上来就给结论：要求“路线图 + 边界条件 + 验证方案”
- ✅ 工具调用频率异常：记录调用次数，换新会话对照
- ✅ 额度掉得飞快：怀疑缓存没命中/上下文重算，尽量缩短无效对话
你要把问题反馈给厂商？照这个格式写，命中率高
厂商最怕你只说一句“变笨了”。他们需要的是可复现信息。
把下面这段填好发过去：
- 复现用例（完整提示词）：
- 期望输出：
- 实际输出：
- 是否新会话可恢复：是/否
- 推理档位切换是否可恢复：是/否
- 是否出现重复提问/工具乱用：是/否 + 例子
- 时间点与版本号（如果看得到）：
写到这份上，对方基本没法装死。
你不需要迷信“模型降智”这种玄学。
把推理档位、上下文、系统约束当成三根旋钮。哪根松了，体验就歪。
把上面的微型评测集建起来，你就从“靠感觉吐槽”，升级成“有证据地定位”。这才是成年人该有的快乐。😄
