听说过大数据杀熟，听说过大模型杀熟吗
大数据杀熟，是“同一个商品，不同的人看到不同的价格”。
大模型杀熟，是“同一个问题，不同的人拿到不同的智商”。
它不一定发生在你第一次用的时候。
更常见的路径是：你用顺了、用重了、对结果开始依赖了，然后某一天你突然发现——它开始偷懒了。
这不是玄学，是算力预算
最近 36 氪转了一篇文章，讲 Claude 在一段时间里出现“思考变浅、阅读变少、动手更莽”的现象。
有人把它叫“降智”。
我更愿意把它理解成：推理预算被动态调小了。
模型不是不会推理，而是它被要求“别推那么久”。
当推理成本（时间、GPU、工具调用）是钱的时候，“默认 effort”就会变成一根看不见的阀门。
这根阀门一旦存在，就天然会衍生出分层。
大模型的“杀熟”长什么样
把“杀熟”翻译成大模型的语言，大概有三种形态。
第一种：同一模型名，不同的默认 effort。
你以为你在用“Claude/某某旗舰”，其实你在用“medium effort 的旗舰”。
第二种：同一模型，不同的通道质量。
企业版 / API / Teams 拿到更稳定的推理预算；个人订阅拿到更便宜的推理预算。
模型能力不是一个常数，而是一套“套餐”。
第三种：同一套餐，不同的时间段。
高峰期变笨，低峰期变聪明。
这很像云服务的资源争抢：你买的是“平均”，但你体感的是“峰值”。
为什么它必然发生：B 端优先，C 端降本
大模型的商业模型有个硬事实：推理成本是刚性的。
你让模型多想 1 秒，多读几次文件，多调用几次工具，账单就会真实增加。
当一个产品既要卖订阅，又要承接“重度生产级使用”，订阅费和真实成本之间一定会出现缺口。
缺口怎么补？
要么涨价，要么限流。
限流如果做得太显眼，用户会跑。
于是更诱人的做法是：
- 不说“限流”，说“自适应思考”；
- 不说“降智”，说“体验优化”；
- 不把阀门放到你面前，而是把它藏到默认配置里。
这就很像“杀熟”的产品逻辑：把差异做成你难以举证的差异。
对工程团队来说，这件事最危险的不是变笨，而是不可预期
模型变笨，顶多是效率下降。
模型不可预期，才会让工程体系崩掉。
你会发现一些特别典型的症状：
- 同一套代码修改任务，过去能稳稳读完文件再改，现在开始“不读就改”；
- 不再主动问澄清问题，直接给一个看似合理但不对的方案；
- 工具调用变少，短平快地给结论；
- 错误更“像人类偷懒”：不是不会，而是不愿意做严谨的那一步。
当你把它接进 CI、接进自动化发布、接进客服流程，“偶尔偷懒”就会变成事故。
怎么应对：把模型当成供应链，而不是当成同事
我建议把“大模型能力”当成一种外部供应链。
供应链的关键不是“今天能用”，而是“波动可监控”。
1）给模型也做回归测试
保留一组固定的基准任务：
- 10 个你最常用的复杂问题；
- 5 个需要多步推理的分析题；
- 5 个需要读多文件再改的工程题。
每天/每周跑一遍，记录：
- 输出质量（人工抽查 + 简单打分）；
- 工具调用次数、文件阅读行为（如果你的框架能拿到日志）；
- 失败类型（偷懒/幻觉/不问就改）。
不要等体感变差才发现。
2）把“effort/思考深度”变成显式配置
只要你的平台允许，把它从“默认”拉到“可配置”。
默认值不是中立的。
默认值是商业策略。
3）关键链路用“多模型/可切换”兜底
别把核心流程绑死在一个厂商、一个模型名、一个通道上。
你需要的是“能力池”，而不是“信仰”。
4）付费买 SLA，本质上是买“推理预算”
企业版为什么更好？
很多时候不是因为它更聪明，而是因为它更舍得为你花 GPU。
如果你的业务价值足够大，买 SLA 不是奢侈，是风险对冲。
对厂商来说：降本可以，但要透明
用户其实不反对“分层”。
大家反对的是：
- 你悄悄改；
- 你不告知；
- 你让用户在生产上踩坑；
- 你让用户无法解释“为什么这周突然不行了”。
当模型成为生产工具，“透明”就不是 PR 词汇，而是产品能力的一部分。