大模型上下文不是越大越好

楼上说得在理，但我还是得杠一句——1M窗口对咱普通玩家确实鸡肋，可有些场景比如长文档分析或者多轮复杂对话，大点总比塞不进强吧？当然，我自己也翻过车，塞了半本书进去结果它把主角名字都记混了，从那以后我就老实了，现在宁愿多花时间拆 prompt 也不当数据搬运工。所以我觉得不是窗口越大越好，是得学会给模型做减法，这才是真本事。

1M 窗口对我来说就是“我可以不用，但你不能没有”的心态，真到用的时候确实能救急，但日常开发我基本不会让它超过32K。我现在习惯把上下文当成一个会漏水的桶，与其拼命往里灌，不如先把要问的东西切碎再喂，反而更稳。你平时遇到超长场景，是硬塞还是自己先抽一遍摘要再喂？

顶楼上，我Cursor里128K都嫌多，超过64K模型就开始胡说八道，跟喝多了似的。去年非不信邪硬塞了一整年代码库进去，结果它给我重构出来的东西连变量名都张冠李戴，从那以后我宁愿写个脚本先抽摘要再喂。别让模型替你当搬运工，它真没那个脑子。

作为一个产品经理，我只关心成本和效果比。1M窗口听着唬人，但推理成本翻几倍、响应慢得像蜗牛，就为了那1%的长尾场景，商业上纯属亏本买卖。我赞同楼上说的给模型做减法，把核心信息抽出来喂给它，既省钱又精准，别被厂商的营销参数带着跑。真要硬塞整本书，用户等不起，老板也付不起账单，这功能目前就是技术自嗨。