两个月前接了个活儿——帮一家创业公司梳理技术文档生成方案。对方要求处理上百页的API文档、技术博客和内部Wiki，输出结构化的知识库。我当时的第一个反应是：这玩意儿哪个模型能扛住？
于是花了两周时间，把手头能调到的Claude版本（3 Opus、3.5 Sonnet、3 Haiku）挨个跑了一遍。测试过程中顺手在我家的平台上同时调了这几个版本做对比——这种聚合平台国内直连就能一键切换模型，省去了反复换账号的麻烦。结果挺有意思：每个版本的长文本表现差异大到让我怀疑它们不是同一个爹生的。
先说结论：别迷信版本号，看你的真实场景
Claude 3 Opus：理论上是旗舰，但在长文本场景里有点“太认真”。我丢给它一份150页的技术文档，它能把每个章节的细节都抓出来，输出内容极其详尽。但问题来了——它经常陷入过度分析，一个简单的问题回你3000字，反而淹没了关键信息。
Claude 3.5 Sonnet：这个版本最均衡。它会在回复开头先给你一个“执行摘要”，然后再展开细节。实测中处理80页的API文档，它能准确识别出哪些接口描述存在矛盾，并主动问“你确定要保留这两个版本的差异吗？”——这种提问方式很加分。
Claude 3 Haiku：速度最快，但明显为短文本优化的。处理超过50页的文档时，它开始出现“遗忘”行为——前半段提到的关键信息，后半段就不记得了。
· Opus：适合需要深度分析的场景，但要接受输出啰嗦
· Sonnet：日常开发首选，速度和质量的平衡点
· Haiku：短文本、实时对话场景，长文本别碰
实测数据：一个真实的切片
我设计了一个标准测试：一份62页的技术设计文档，包含架构图描述、接口定义、异常处理流程、数据库schema四部分。要求模型回答“这个设计中最大的三个风险点”。
结果如下：
Opus用了47秒，输出了2800字。它指出了6个风险点，其中两个确实是我没意识到的——比如“缓存策略和数据库事务隔离级别不匹配”。缺点是读起来太累，需要自己提炼重点。
Sonnet用了23秒，输出1200字。三个风险点全中，还额外标注了“你文档里第34页的异常码定义和第12页不一致”。这个效率是最舒服的。
Haiku用了11秒，输出800字。只抓住了两个风险点，第三个答偏了——它把“没有做幂等处理”说成了“接口超时设置不合理”。
坦白说，Sonnet这次的表现让我觉得Claude团队确实在优化“开发者体验”这件事。
选型的一个实用框架
如果你也在做长文本开发选型，我建议你先问自己三个问题：
-
你的文档平均多长？超过100页就优先考虑Sonnet或Opus
-
你需要的是“提炼”还是“深度审查”？前者选Sonnet，后者选Opus
-
对响应时间敏感吗？敏感的话直接排除Opus
我现在的使用习惯是这样：日常代码审查和技术文档整理用Sonnet，每周一次的系统架构评审用Opus过一遍，Haiku只在写周报摘要或者快速问答时才开。
一个容易被忽略的点
长文本场景里，真正卡脖子的不一定是模型能力，而是你的“提问方式”。同样的文档，你问“总结一下”和“请找出所有不一致的地方”，Sonnet给出的答案质量能差两倍。
另外提醒一件事：别忘了考虑成本。Opus调用一次的价格差不多是Sonnet的五倍，如果只是日常开发，用Opus属实有点奢侈。
你目前在用什么模型处理长文本？踩过哪些坑？
