Opus 5.5实测：两年前的烂项目，它真给修好了

这三天大模型更新的速度，真的有点让人跟不上了。

先是 Grok 4.7，接着 GPT-6 Sol，Claude Opus 5.5 也来了。

我今天故意没拿什么 Benchmark 刷分，而是给 Opus 5.5 找了个真正的“烂活”。

一个朋友两年前写的 Crypto 数据监控项目。

十几个数据源，接口新旧混杂，被不同模型来回改了不知道多少轮。配置文件对不上，日志每天几百条报错。

最恶心的是——它居然还能跑。

只是经常重复、漏报，偶尔还会把昨天的信号当成今天的。

这种半死不活的老项目，其实特别难搞。

重写吧，容易把原来能用的东西一起干掉；小修吧，又很容易变成“哪里报错改哪里”，最后补丁越打越厚，真正的问题反而没人找。

我没给 Opus 5.5 拆步骤，只扔给它三个要求：

找出重复和漏报的原因。 修完跑完整测试。 交易模块不要碰。

然后让它自己折腾。

刚才回来一看，谈不上什么“AI觉醒”，但结果确实让我有点意外。

它先把抓取、清洗、去重、状态管理到告警的整条链路重新理了一遍。

最后发现，问题根本不是某个接口挂了。

而是：

两个定时任务同时写状态文件 + 一次时区转换错误。

两个问题叠在一起，才造成了重复告警和跨日误报。

中间它也怀疑过缓存。

但对完日志时间戳之后，自己把这个方向排除了，没有抱着错误结论一路乱改。

最后实际改动并不算多，补了几个测试，也没有碰我明确说不能动的交易模块。

这次让我比较明显的感觉不是：

Opus 5.5 突然聪明到换了个物种。

而是它做事情的时候，**没那么容易迷路了。

很多模型其实不是不会写代码。

真正麻烦的是做到一半开始跑偏，改了A又把B搞坏；聊了几十轮之后忘掉最开始的限制；最后洋洋洒洒交出来一堆代码，看起来干了很多活，实际上还是个半成品。

这次至少没有这些毛病。

没乱改、没瞎猜、没忘要求，而且真的把事情收尾了。

所以我现在反而觉得，大模型下一阶段拼的可能已经不只是：

谁突然聪明了一大截？

而是：

谁能少说废话、少返工、少犯低级错误，并且把交代的事情真正做完。

Grok 4.7、GPT-6 Sol、Claude Opus 5.5， 你们最近实际用下来，更喜欢哪个？