Claude Sonnet 4.0 上手：我把它接进那个跑了两年的老服务里，结果有点意思

Claude Sonnet 4.0 上手：我把它接进那个跑了两年的老服务里，结果有点意思

上周五晚上，线上有个接口响应时间突然飙到 2.3 秒，排查下来是下游的文本分类模型拖的后腿。我那个服务用的是 Sonnet 3.5，调用链本来就长，加上业务方又提了新需求——要支持更细粒度的意图识别，原来的 prompt 写得像一坨意大利面，改也不是，不动也不是。

硬着头皮试了一圈，最后把 Claude Sonnet 4.0 接了进去。

说实话，接进去的第一感觉是：这玩意儿快得有点不正常。

快在哪，快多少

我跑了一组对照测试，数据摆在这：

原来的 Sonnet 3.5，同样一段 800 字的客户反馈文本做意图分类，平均 RT 是 1240ms，P99 到 2100ms。换到 Sonnet 4.0，同样的 prompt，同样的输入量，平均 RT 掉到 410ms，P99 卡在 780ms。

不是玄学，我连续跑了三天，每次 200 次调用，取均值。

有意思的是，速度上去的同时，准确率反而高了。原来 3.5 在边界case上的误判率大概是 7.2%，4.0 掉到了 3.1%。这个提升幅度，在业界普遍认知里是不太应该同时发生的——通常模型升级要么更快要么更准，鱼和熊掌兼得的情况不多见。

我当时跟组里另一个做 RAG 的同学聊，他说是因为 4.0 在长上下文窗口里做注意力机制的时候，对中间层信息的召回效率提升了。具体原理我没深究，但实测数据不会骗人。

我踩到的第一个坑：默认参数变了

这个坑踩得我挺懵的。

Sonnet 3.5 的默认 max_tokens 是 4096，我原来的代码里没显式传这个参数，一直靠默认值撑着。换到 4.0 之后，默认值变成了 16384。

看起来是好事对吧？token 多了，能处理更长的输出。但实际问题出在 cost 上。

有个业务场景是纯分类任务，输出就几个字，结果 4.0 默认会多生成一些无关的冗余内容，导致每次调用多消耗大概 200-300 个 token。一天下来，日调用量 50 万次的话，多出来的这部分成本加起来不是小数。

我把 max_tokens 显式设回 512 之后，输出干净了，成本也回来了。但这也暴露了一个问题——很多开发者可能跟我一样，从来不会去仔细看每个模型版本的默认参数变化。

这里我想说一个可能没人提过的点：模型升级带来的隐性成本，很多时候不是推理费用本身，而是默认行为变化导致的过度输出。这个成本在账单上不会单独列出来，只会体现在总 token 消耗上，很容易被人忽略。

第二个坑：系统 prompt 的写法需要重新调整

4.0 对 system prompt 的理解方式跟 3.5 不太一样。

我原来那套 prompt 是典型的"角色+任务+约束"三段式，3.5 执行得很稳。换到 4.0 之后，同样的 prompt 输出反而变得不稳定了——有时候分类准确，有时候会把边界 case 往主流分类上靠，出现了一种我之前没见过的"过度归并"现象。

后来我把 prompt 结构改了，把约束条件从末尾提到中间，效果明显好转。具体改法不展开说了，感兴趣的话可以私下聊。

但这里我想表达一个个人判断：4.0 更适合"对话式"的 prompt 写法，而不适合传统的那种"指令式"写法。3.5 时代我习惯把 prompt 写成一份精确的操作手册，4.0 时代我发现跟它"商量"比"命令"效果更好。这个转变可能跟模型架构的变化有关，但我没有内部资料，只能从现象反推。

实际效果：那个拖后腿的接口救回来了

回到最初的问题——线上接口响应时间飙到 2.3 秒。

接了 4.0 之后，同样的业务场景，平均 RT 从 2300ms 降到了 680ms，P99 从 4100ms 降到了 1200ms。这个改善幅度，直接让那个接口从"需要加缓存"降级到了"可以再观察一段时间"。

业务方不知道背后发生了什么，只知道"怎么突然快了"。我倒是挺满意这个结果的。

还有个细节没多少人提到

4.0 在处理多轮对话时，对中间轮次的记忆保持能力明显强于 3.5。

我手头有个内部工具，用来做代码审查辅助，本质上就是个多轮对话场景。原来用 3.5 的时候，对话超过 8 轮之后，模型开始"遗忘"前面的上下文，经常会出现前后矛盾的判断。换成 4.0 之后，15 轮以内的对话基本没有这个问题。

不过 20 轮以上还是会衰减，这个限制应该跟上下文窗口的实际有效利用有关，不是模型本身的缺陷。

最后说点题外话

说实话，用 4.0 的过程中，我最深的感受是：Anthropic 这次升级的核心变化可能不是"能力"本身，而是"可控性"。

3.5 时代，同样的 prompt 在不同时间调用，输出会有微妙的差异。4.0 时代，这种不确定性明显降低了。对于一个需要在生产环境里稳定输出的服务来说，这个改进的价值可能比速度提升更大。

但可控性提升也带来了一个新问题：当模型越来越"听话"的时候，我们是不是也应该反思一下，自己写的 prompt 是不是太"霸道"了？

这个问题我暂时没有找到答案，留给你们了。

你们在实际用 4.0 的过程中，有没有遇到过什么反直觉的现象？

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