一名 QFN 用户在所有测试中默认关闭了 preserve_thinking（保留模型思考过程的机制），覆盖 C++ 后端与前端编程；其称至今没有发现性能或智能水平下降，上下文窗口反而更干净。DeepSeek 在其测试的 API 中同样不保留思考内容。

这是什么

这不是一次新模型发布，而是社区对“思考过程是否应该默认保留”的实践反馈。对于会调用模型处理复杂任务的系统，保留中间推理有助于复核过程，但也会占用上下文窗口，并可能增加存储、传输和后续调用成本。

值得关心的是，用户观察与厂商默认设计之间出现了差异。它说明“保留更多推理信息”并非始终等于更高质量，模型是否真正受益，取决于任务类型、框架能力和评测方法。

行业怎么看

一种积极看法是，减少冗余的思考记录可以让长对话保持聚焦，尤其适合持续编程、工具调用和自动化工作流。企业因而可能获得更低的推理成本，以及更容易审计的运行记录。

但也有风险：隐藏或省略中间推理，可能削弱复杂任务中的自我检查，让错误更难定位。单个用户、少量编程测试和特定框架中的结果，也不能直接外推到医疗、金融、科研等高风险场景。社区经验可以提示产品设计方向，但不能替代统一评测。

对普通人的影响

对企业 IT：团队可以开始比较“保留”和“不保留”两套配置下的任务成功率、延迟与成本，而不是默认把更长上下文视为更强能力。

对个人职场：使用编程助手或研究工具时，更短的上下文可能让回答更聚焦；但重要决策仍应保留可核查的依据、来源和过程记录。

对消费市场：如果厂商普遍减少默认保留思考内容，聊天产品可能更省资源、响应更快，用户未必会察觉变化，但复杂任务的稳定性需要持续观察。