给Claude Opus 4.6装个企业级“围栏”，我看见了幻觉的死角

给Claude Opus 4.6装个企业级“围栏”，我看见了幻觉的死角

上周把Opus 4.6塞进那个跑了三年的Java单体里，本来只想让它帮我做代码重构。接口都调通了，RT稳定在400ms左右，心里还挺美。直到那天下午，产品经理拿着一份两百页的需求文档过来，说要让AI实时比对变更点。

我试着把文档直接喂进去。

说实话，那一刻我才意识到，之前那些测得风生水起的“百万上下文”，在企业级协作场景里，其实是个伪命题。不是模型不行，是我们的接入姿势全错了。

有意思的是，官方文档里大肆宣扬Opus 4.6的“人味”和“全能感”，说它在多模态处理上极具亲和力。但我盯着后台日志看了半天，发现所谓的“实时协作”，在并发写入的时候，幻觉率直接从0.2%跳到了8.5%。

当时我有两个方案选。方案A是保留完整上下文，让模型自己判断重点；方案B是把文档切片，只传增量部分。我脑子一热选了A，觉得既然都买了企业版，就得体现“大模型”的价值。

结果坑死了。

第三天，三个开发者同时编辑同一个配置类，Opus给出的合并建议里，凭空多出两个不存在的接口方法。我问它从哪来的，它信誓旦旦地说在第142页的附录里。我翻遍全文，根本没这回事。

这才是企业落地最隐蔽的坑：不是不会写代码，而是太会“编”代码了。

后来我把方案B跑起来了。把200页文档切成每块5000字，只传当前编辑区的上下文。RT从1200ms降到了300ms，幻觉率也压回了0.3%以下。

但我没敢高兴太久。

因为我在测试里发现了一个更诡异的现象。当你用Opus 4.6做实时协同分析时，模型的“一致性”会变差。简单说，就是它上一秒说这个字段是String，下一秒又说它是Integer，而且它还能自圆其说。

我在Issue里提了这个问题，Anthropic的回复很官方：“建议优化Prompt工程。”

我试了一圈，发现这不是Prompt的问题，是架构问题。

企业端要用这种模型，必须加一层“事实核查层”。我在代码里加了一个校验模块，专门对比模型输出和原始文档的Hash值。凡是Hash对不上的，直接丢弃，不让模型瞎编。

这套逻辑加进去后，整体吞吐量掉了15%，但可用性从92%提到了99.8%。

说实话，当时方案A和B，我选了A因为觉得省事。事后看，在企业级场景里，省事往往意味着返工。

另一个让我意外的是视觉能力。Opus 4.7刚出的时候，很多评测说它视觉准了。我拿了几张模糊的系统架构图让它识别，确实比4.6清楚了不少。但在企业协作里，光看得清没用，你得知道图里的箭头指向的是哪个模块，以及这个模块在数据库里的实际表名。

这点上，4.7和4.6没啥本质区别。它们都能“看懂”图，但都不一定“懂”业务。

我花了一周时间，把业务词典硬编码进System Prompt里，才算把这件事做扎实了。

现在回头看，那些宣称“百万字文档实时协作”的评测，大多是在单人、单线程、低并发的理想环境下测的。一旦放到真实的企业环境里，网络抖动、并发冲突、版本回溯，每一个都能把模型的弱点放大十倍。

我觉得大家高估了模型的“通用性”，低估了工程的“特异性”。

有人可能会问，那为啥还要用？

因为不用更麻烦。

我现在的流程是：文档进来，先过清洗层，再切片进向量库，最后才给Opus。虽然慢了点，但至少它编不出那些子虚乌有的接口了。

昨天又遇到个新情况。有个老同事想把一份手写笔记扫描件转成代码。Opus 4.6识别率很高，但把变量名搞错了。我纠正了它三次，它还是记不住。最后我只能手动改。

这让我们意识到，模型在“记忆”这件事上，依然只是个实习生，而不是专家。

你们在项目里遇到过类似的情况吗？比如模型太自信地胡说八道，而你当时没发现？

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