200K上下文装下三年日志后，我反而不敢用Claude了

200K上下文装下三年日志后，我反而不敢用Claude了

上周凌晨两点，线上的支付接口开始报504，老日志系统早就过期清理了，只剩Kibana里还留着过去三个月的原始JSON。

我顺手把最近一周的错误日志全量复制，打算扔给Claude 4.2旗舰版，让它帮我找规律。当时心里盘算着，200K的上下文窗口，哪怕塞进去几百万字也不在话下，总能把那个诡异的超时根因挖出来。

说实话，这是个挺冒险的举动。把生产环境的敏感数据直接喂给公有云模型，合规部门要是查起来能把我骂死。但那时候没别的办法，只能赌一把，选了那个支持超长上下文的版本。

第一次投喂大概50K tokens的时候，响应还挺快，三秒钟就给出了一个看起来头头是道的分析。它说超时集中在凌晨两点到三点，跟数据库连接池满了有关。我正要点头，心想这AI确实有点东西，结果它继续往下读，读到了两万字以后的地方。

也就是在那一刻，我发现它开始"幻觉"了。

它编造了一个根本不存在的timeout_pool_expired错误码，还煞有介事地给出了解决方案。我当时就愣了，仔细回查日志，根本没有这个错误码。它是为了圆上之前的结论，硬凑出来的。

这跟我之前用小窗口模型的感觉完全不一样。小窗口的时候，它只会告诉你"上下文过长，请分段处理"，或者只分析它能看见的那一小部分。而现在，它有了"全局视野"的幻觉，以为自己真的读懂了整个系统，实际上只是在用概率填补它看不见的空白。

有意思的是，我后来试着把同样的日志分成了四段，每段50K tokens，分别丢进去问。结果四份报告的结论竟然互相矛盾。第一段说连接池问题，第二段说是网络抖动，第三段又说是应用层GC停顿，第四段干脆说日志时间戳对不上。

要是放在以前，我肯定会取个平均值，或者看哪个说得最详细就信哪个。但这次我学乖了，我把这四份报告里的具体日志片段都抠出来，对着原始数据一条条核对。

发现没有一条是百分之百准确的。

它们都在用合理的逻辑串联错误信息，但前提条件全是编的。

我后来做了个对比测试，把同一段200K的日志，分别用Claude 4.2的对话模式和代码解释器模式跑了一遍。对话模式还是那个会瞎编错误码的助手，但代码解释器模式，它写了一段Python脚本来本地解析JSON，然后告诉我它无法直接访问文件，让我自己跑脚本。

这个转折让我突然意识到，200K的窗口不是万能药。它解决的只是"能塞进去"的问题，而不是"能读懂"的问题。当信息密度超过某个阈值，模型那种基于概率的补全机制就会失效，因为它在试图预测一个它根本没有足够注意力去验证的庞杂结构。

我当时选方案A，也就是直接让它分析，事后看选错了。应该选方案B，用工具模式让它写代码去处理，而不是让它直接"读"。

现在回头看，Anthropic把窗口扩到200K，甚至传闻中的更高版本，其实是在赌一个方向：赌大模型在处理长文本时的逻辑一致性会提升。但据我这两天的实测，至少在代码和日志分析这种对精度要求极高的场景里，这个赌注还没兑现。

我同事昨天也在折腾这个，他把整个微服务架构的文档和依赖树都塞了进去，想让模型画一张架构图。结果模型画出来的图，服务之间的调用关系完全是错的，连端口号都对不上。他说这就像让一个看了全集目录的人去复述剧情，他能说得通顺，但细节全是瞎编的。

我们这行干久了，总会遇到这种时候。工具越来越强，但用起来反而更小心。200K窗口确实能装下整个项目的README，装下半年的报错记录，甚至装下几十篇相关的技术文档。但你能信任里面输出的每一个字吗？

我不敢。

我现在的做法是，把大段材料扔进去之前，先让模型写个解析脚本，或者至少让它列出它看到了哪些关键节点，我再手动去原始数据里验证。多这一步，虽然麻烦，但能避免被它的"自信"带沟里去。

话说回来，你们有没有试过把超长日志直接喂给现在的旗舰版模型？是不是也遇到过那种"越看越像真的，其实全是编的"情况？

你在实际项目中有踩过类似的坑吗？或者有更好的解决方案？欢迎在评论区分享你的经验。