AI 降智怎么判断：5 分钟自检法与会话重置策略
用 AI 干活时最怕遇到这种情况：模型看着很努力，却在错误方向上反复纠错、越改越乱，几个小时耗在一个简单任务上。这篇整理了一套可落地的判断方法：用固定校准题快速体检、识别输出异常信号、设定止损阈值，并给出把上下文整理成简报、重开会话的具体步骤。
用 AI 写代码、改文档、做分析，时间久了几乎都会撞上一种状态：模型看起来依然很配合，输出也依然工整自信，但实际质量明显下滑。你会反复纠正它，它也会认真道歉、认真重写，然后又引入新的错误。一上午过去，一个原本十分钟能搞定的任务还在原地打转。
麻烦的地方在于，这种状态下模型并不“消极”。它不会报错，不会拒绝，反而显得非常努力。单纯用“有没有出错”去判断完全无效，因为状态好的时候它同样会犯错。真正需要区分的，是犯错之后能不能收敛。
犯错不是判据，纠错模式才是
两种状态的表现差异可以这样概括：
| 状态 | 第一轮 | 纠正后 | 总体趋势 |
|---|---|---|---|
| 正常 | 有错误或遗漏 | 定位到问题、修正、向前推进 | 误差逐轮收敛 |
| 异常 | 看起来合理，实际偏了 | 换个方式再错，甚至引入新错误 | 误差震荡甚至发散 |
所以判断的关键不是问“它这次对不对”，而是问“我给了明确反馈之后，它的下一步有没有更接近目标”。如果连续两三轮纠正都在制造新的问题，基本可以判定当前会话已经不值得继续投入。
为什么会进入这种状态
多数情况下这并不是玄学，而是有具体诱因的。按可自查程度排列：
- 上下文被压缩或截断：会话过长后，早期定下的约束、字段名、接口约定被挤掉，模型开始“凭印象”补全。表现是反复问你已经回答过的事。
- 会话被错误污染：连续的失败尝试、大段报错日志堆在上下文里，模型会模仿自己之前的错误路径。
- 需求边界模糊：没有明确输入输出、没有验收标准，模型自由发挥，越改越偏。
- 服务端因素：请求被路由到较小的模型、限流降级、灰度版本切换。这一层用户无法直接观测，也不便断言，具体策略以服务商官方最新说明为准。
- 客户端与网络：流式输出中断后重试拼接、连接抖动导致上下文错乱，常见于长时间挂着的 CLI 会话。
- 本地环境：在本地跑量化过的小模型，或多任务并发把设备压满，响应质量会明显下降。
5 分钟校准题：把“感觉”变成“分数”
最实用的办法是准备一组固定的、答案已知的题目，怀疑时跑一遍。题目要短，但覆盖不同能力维度：
- 多步推理题：需要 2–3 步推导、有唯一数值答案的小题。
- 格式约束题：要求严格输出指定字段的 JSON，检验指令遵循。
- 引用题：贴一段两三百字的材料，问其中一个细节，检验它是否真在读上下文而不是编。
- 纠错题：给一段有明显 bug 的代码或一段有事实错误的文字，看它能否一轮指出并修好。
判读方式：
- 四题基本通过 → 模型状态没问题，问题在你的上下文或需求描述，去整理简报、重开会话。
- 通过但在纠错题上需要两轮以上 → 边缘状态，降低任务粒度，一步一验收。
- 多题失败，且纠正后仍然失败 → 直接判定当前会话不可用，停止投入。
把这四道题存在一个文件里，每次原样粘贴，才有可比性。换题就等于换考卷，分数没有意义。
不用跑题也能看出来的信号
长期使用会形成直觉，一些信号出现时基本可以准备重开了：
- 输出风格突然变化：固定开场白、模板化道歉、莫名的口头禅反复出现。
- 中英文混杂、语气与平时明显不同。
- 无视你明确给出的文件名、字段名、函数名，自行编造一套。
- 同一步骤循环，每轮多一个新错误。
- 大量复述你的话而不推进，看起来在确认需求，实际没有产出。
这些属于经验判断，灵敏度高但容易误判，建议作为“触发跑校准题”的开关，而不是直接下结论。也有人会拿公开基准测试来量化，但对个人日常排障来说成本太高，不划算。
止损与恢复：不要在旧会话里继续纠正
确认状态异常后，最关键的一条是：不要再在原会话里解释一遍。在已经污染的上下文里继续纠正，通常只会让它更偏离。
推荐流程：
- 停下来，把当前进展写成一份简报：目标是什么、硬约束有哪些（技术栈、字段名、接口格式）、哪些结论已经验证过、下一步要做什么。
- 把失败尝试压缩成一句否定项，例如“不要用正则解析，改用解析库”。不要把几百行报错原样贴进去。
- 新开会话，先只发简报，让它复述一遍理解，确认无误再开工。
- 拆小任务，每个子任务单独验收，完成一个再进下一个。
- 把长期约束固化到项目级规则文件里（例如 Claude Code 可用的项目说明文件），这样每次新会话自动携带，不必重复口述。
止损阈值建议提前定好，比如“同一子任务两轮无实质进展就重置”，避免自己在情绪里越陷越深。另外，长时间对着模型刷短句发泄既消耗额度，又会把更多噪声写进上下文，反而加速状态恶化。
交叉验证与备选方案
如果手头有多个模型可用，可以让另一个模型来审阅当前方案，或者干脆把问题交给它重做一遍，对比结论差异。要注意两点：同一服务商、同一时段的模型可能同时受影响；不同模型的提示词习惯不同，直接把原提示词搬过去效果未必好，最好重新表述需求。
还有一个容易被忽略的变量是运行环境。长时间挂着命令行 AI 工具跑任务时，本地笔记本合盖休眠、Wi-Fi 切换、代理抖动都可能造成会话中断重连、上下文拼接异常，看起来就像“模型突然变笨”。如果排查后怀疑是本地环境问题，可以把长任务放到一台长期在线的机器上执行——例如整机托管在机房、按月租用的远程 Mac，通过网络远程连接使用，不随本地设备休眠而中断。这属于可选项，先排除提示词和上下文因素，再考虑环境层面的调整。
注意事项
- 任何单一信号都不足以定论，至少结合“校准题得分 + 纠错收敛情况”两项。
- 判定模型变笨之前，先检查自己的需求描述有没有验收标准。相当一部分“降智”其实是需求含糊。
- 模型版本、路由与限流策略随时可能调整，涉及具体服务的行为请以官方最新说明为准。
- 校准题要固定，且不要泄露到日常会话里，否则失去参照意义。
小结
一套最小可执行流程是：发现异常 → 跑四道固定校准题 → 看纠正后是否收敛 → 不收敛就整理简报、重开会话 → 把这次的约束沉淀进项目规则文件。整套动作五分钟内能完成，比在错误方向上陪模型耗两小时划算得多。
