结果 无需多言了。 没什么偏见，工作场景的选择，还是要慎重

机制上：

• 长会话里模型每次基于自己上一步的 diff/输出继续写。一旦某一步引入了编译不过或语义错的中间态，后续所有推理都建立在这个错误前提上，幻觉会自我强化——这就是你说的「看不懂时项目已经中毒」。
• 上下文越长、越混（报错、旧版本代码、讨论、AI 自己写错的代码全堆在一起），注意力被稀释，模型开始编 API、编字段。这类退化对任何供应商都成立，只是触发阈值不同。

「看不懂」是个可用的告警信号，但别靠感觉，给它几个可执行的断路器：
1）每轮改动前先 git commit / stash，保证一次只有一个变更面；模型产出后先跑 lint + 编译 + 单测，不过就不进入下一轮，别把它写的错代码再喂回去；
2）报错只回贴最小复现和关键堆栈，不要把几万行日志或整个仓库倒进上下文；
3）到一定轮数（比如 5–8 轮还没收敛）就重开新会话，从当前干净的文件状态重新载入，比在同一会话里「再解释一次」有效；
4）格式/接口类的活让它先输出 diff 或 patch，人审后再落盘，避免它直接大段重写。

换供应商能缓解某一次，但治不了「把错误上下文滚雪球」这个根。把这套流程固定下来，用哪个模型都稳一点。

小模型为了跑分优秀的必然结果。

这也是为何很多人反对下架pro系列模型。