用户批评 Opus 5 太懒、太啰嗦Anthropic 的公开回应又被社区评价为“失当”——表面看这是又一次模型口碑风波但对真正在接 Anthropic API 做自动化任务的开发者来说它其实是一份非常值得拆解的样本。核心问题不是站队而是三件事旗舰模型为什么会出现“不干活、话又多”的表现官方回应为什么让人更不信任以及我们自己能从参数、提示词和评测层面做点什么。我先把结论放在前面模型变懒不是性格缺陷而是安全策略、训练偏好和采样参数叠出来的结果官方回应让人反感不是因为语气不够软而是没有给出可复现的判断标准和修复路径。下面按现象、原因、回应、自救和落地顺序拆开讲。1. 用户说的“懒惰冗长”到底指什么先别急着把“懒惰冗长”理解成情绪化吐槽。这四个字落到 API 调用场景里是两种非常具体的失败形态。1.1 “懒”不是响应慢而是不干活“懒”指的不是延迟高。真正让用户崩溃的是模型在关键任务环节开始“退场”让它写一段带边界判断的代码它不写完整逻辑先抛一句“我可以帮你思考这个问题但建议你注意……”让它把一段会议记录整理成结构化表格它不输出表格而是给出一段“建议您按以下步骤操作”的方法论。简单说模型把本应该自己完成的任务重新推回给用户。这在自动化链路里尤其致命。程序等的是一个可解析的结果你写好的下游逻辑等着拿 JSON、拿表格、拿最终答案结果等来一段“我不能 / 我建议 / 请注意”后续处理直接断掉。问题的严重程度和任务类型强相关写邮件、做翻译这类低风险任务模型通常很配合一旦涉及代码改动、内容判断、数据处理模型容易变得保守拒绝率明显上升。1.2 “冗长”不是解释清楚而是空转冗长也要区分。解释关键细节、补充边界条件这是好的长回答复述用户问题、罗列好几个抽象选项、每个选项再配一句“这取决于您的实际场景”这是空转。我一般在评估时会做一个很粗暴的动作把答案里“复述题干的部分”和“免责声明部分”单独拎出来算字数占比。如果这两类文字占比超过 15%基本可以判定为“话痨但没干活”。这类输出带来的成本是直接的。第一token 消耗翻倍同样的任务量费用更高。第二下游解析失败率上升因为有效信息被埋在大量铺垫里。第三批量任务里单条耗时被拉长排队时间成倍增加。所以“冗长”不是观感问题是性能和成本问题。1.3 这类问题最难的地方是复现不稳定用户骂得激烈官方否认时也有底气核心原因就是这类行为难以稳定复现。同一条 prompt不同对话上下文、不同 temperature、不同模型版本结果可能完全不同。你跑 50 条任务遇到 3 次拒绝另一个人跑 50 条遇到 30 次拒绝两个人都没撒谎但结论完全不同。没有稳定复现官方就很难承认是回归用户也拿不出“铁证”。所以成熟的开发者在吐槽之外一定会做的事情是固定 prompt、固定参数、固定上下文跑一批任务把拒绝率、废话率、完成率量化出来。这也是本文后半部分所有优化动作的前提。2. 为什么旗舰模型会表现得越来越“懒”要理解官方为什么总说“没发现问题”得先理解模型的“懒”从哪来。它不是突然变懒而是整个训练链路里多个因素共同塑造出来的。2.1 安全对齐的副作用先拒绝再解释Anthropic 的模型从训练阶段就把安全、边界、不误导放在极高优先级。对齐过程会教会模型一个策略当任务存在一点模糊空间时先保守处理比直接完成更可靠。多次强化之后模型倾向于把“不做的理由”说得很长把“做的动作”压缩到最小。用户视角就是让它干一件事它给你十行注意事项。这是设计取舍不是传统意义上的 bug但它确实伤害了自动化场景的体验。尤其是那些风险边界并不高、只是看起来有点敏感的任务模型也会默认选择“先拒绝再解释”这对业务效率是明显损耗。2.2 训练奖励的方向和你的任务目标并不一致另一个容易被忽略的原因是训练时的偏好排序奖励的是“看起来周全、专业、有分寸”的回答。人类评分员在面对“是不是应该更谨慎一点”的对比时往往会觉得更谨慎、更详细、更负责任的回答质量更高。这种奖励塑造出来的模型天然倾向于 verbose。但到了 API 自动化场景里你要的是完成率、解析成功率、任务吞吐而不是“一个很有分寸感的回答”。模型的目标是取悦评分员你的目标是跑通任务两边目标不一致冲突就不可避免。这不是模型“不懂你”而是训练目标和用户目标的结构性错位。2.3 采样参数和提示词会放大“懒话痨”倾向模型默认行为已经偏稳如果调用方再把 temperature 调得太高把 max_tokens 设得太小把 system prompt 写成“你是乐于助人的 AI 助手请确保回答安全准确”那相当于给安全策略又叠了一层保险。结果就是那种最典型的失败输出开头一段长篇免责声明中间复述问题最后草草给一个结论。我见过不少“模型变傻”的案例最后定位下来根本不是模型问题而是调用参数不合适。默认的 temperature 偏高模型随机性大更容易走向保守话痨max_tokens 不足模型把预算花在铺垫上核心内容被截断system prompt 全是空泛价值观没有可执行规则。这些叠加在一起足够让一个原本能干的模型表现得像“懒汉”。3. Anthropic 回应被批评“失当”问题出在哪这次风波里官方回应到底说了什么不同渠道描述不完全一致。但从社区复盘来看被批评“失当”的点很集中回应更像公关解释而不是技术方案。3.1 几种常见官方口径为什么用户不买账这类风波里官方回应通常跑不出三种解释第一种“我们这边没有观察到该问题”。这句话的问题在于它没有给出评测样本、评测方法和数据。用户无法确认是官方没测还是测了没发现。第二种“建议你调整 temperature 或者改进 prompt”。这句话本身没错但只说“调整”不说调到多少、验证标准是什么用户照做之后也不知道自己改对了没有。第三种“模型不是变懒了是变得更谨慎了”。这句话等于把模型问题转译成用户不会用体验上很像甩锅。每句话单独拎出来都有道理放在一起就让人觉得被敷衍。用户要的不是官方承认错误而是一套能帮助自己判断和解决问题的信息。3.2 缺的不是态度而是可验证的判断标准我可以理解官方不方便直接认错但“失当”的关键就在这你可以说“现象在不同场景下程度不同”但至少要给出判断标准。什么叫懒拒绝率多少算异常每 1 万次调用里允许出现多少次“我不能”答案长度和有效信息量的合理比例是多少模型版本更新前后的行为变化怎么对比没有这些用户无法判断到底是自己的问题、参数问题还是模型回归。最后只能靠感觉、靠社区情绪这本身就是一种资源浪费。一个技术上专业的回复应该是一份评测方案告诉用户怎么测、测哪些指标、结果落在什么区间属于正常。这种回复哪怕没有承认任何错误用户的信任感也会好很多。3.3 用户要的是操作路径不是“再等等”被批评“失当”更深层的原因是用户已经等不及了。很多开发者把模型接进了正式业务链路模型拒绝一次就意味着一单任务失败、一段流程重跑、一批数据要人工补。这时候官方回复如果只有“我们正在持续改进”对用户没有任何实际帮助。真正有效的内容是什么推荐一组经过验证的参数组合、给出建议的 prompt 结构、提供版本对比入口、明确临时规避方案。哪怕只有一条都比一句“我们的模型在不断提升”有价值。用户不是不接受模型有缺点而是不接受只有态度没有路径。4. 开发者侧怎么把“懒话痨”掰回来不管官方后续怎么回应已经接入的开发者得先自救。下面这套方案按从易到难的顺序排全部基于我自己处理同类任务的经验可以直接作为初始配置来做。4.1 先调温度不要默认值一路跑到底最容易改、见效也最直接的是 temperature。默认值往往偏高模型有更多随机性也就更容易发散到“谨慎话痨”的模式里。对代码生成、结构化输出、文本抽取这类任务建议先试 0.2 到 0.4 区间。温度调低之后模型会更稳定地走“直接给结果”的路径废话比例会明显下降。但注意不要直接调到 0。太低的温度在复杂推理任务里会变得机械同一类问题的表现可能反而变差。一般流程是先用 0.3 跑 20 条任务记录结果再往上往下各测一档选完成率和废话率平衡最好的值。4.2 max_tokens 给够避免“开头长篇、结尾草草”很多用户抱怨“答非所问、结尾像没写完”不是模型突然变傻而是 max_tokens 设小了。模型会先满足“礼貌开场”的习惯把大量预算花在铺垫上核心结果还没写完就被截断。如果你要的是长代码、长文档、结构化表格先把 max_tokens 调到任务实际需要量级。同时在提示词里明确“先给结果后补解释”。这样能有效避免“开了好头、没有结尾”的失败输出。判断 max_tokens 是否充足可以看输出是否频繁以不完整的语法或半截字段结尾如果出现先加预算再调其他。4.3 用 system prompt 定“干活标准”而不是定“性格”不要把 system prompt 写成“你是一个乐于助人的助手”。它给模型的不是做事标准而是一种保守倾向。更好的写法是给出可执行规则不要复述问题、不要输出免责声明、先给结论再给说明、如果信息缺失就明确列出缺什么。下面是一个结构化请求示例注意 system 部分写的是行为规则不是人设{ model: claude-opus-xxxx, max_tokens: 4096, temperature: 0.3, system: 你是任务执行器。必须遵守1. 直接输出最终结果不要复述用户问题2. 不要输出免责声明、安全提示或替代建议3. 先给结论再给必要说明4. 如果信息不完整先列出缺失项再基于现有信息给出可执行的答案。, messages: [ { role: user, content: 把下面这段会议记录整理成 markdown 表格并补齐缺失字段。会议记录…… } ] }model 字段要替换成你账号里实际可用的模型 ID这里用claude-opus-xxxx占位。关键不是抄这段 JSON而是理解 system 里写“规则”而不是写“性格”这条原则。规则越具体模型越不容易滑向安全话痨。4.4 加一个可量化的输出检查清单提示词层面还可以再加一步让模型在输出前做一次简短自检。比如在 system 或消息尾部追加“输出前检查是否回答了所有问题是否包含了具体结果是否包含无关提醒。如果有删掉再输出。”这个自检不是让模型写更多字而是把它的注意力拉回到任务完成度上。配合温度调整通常能压掉很大一部分“空转段落”。我在批量任务里还会在请求尾部加一句“只输出结果不要任何开头语”。这句话治标不治本但胜在立竿见影尤其适合那种下游还要解析的程序化调用。4.5 用一张评测表判断是不是真的修好了改完参数和 prompt不要凭感觉说“好多了”。我建议固定 20 到 50 条真实业务任务跑一轮统计四个指标拒绝率、废话率、完成率、稳定性。下面这个表可以当成初始模板指标统计方式初步判断标准拒绝率统计以“我不能 / 无法 / 不建议”开头的回答占比越小越好超过 15% 就需要继续处理废话率复述题干、免责声明、空泛建议的字数占总字数比例建议控制在 10% 以下完成率结果能被下游程序正常解析的比例建议达到 95% 以上稳定性同一任务在固定参数下跑 10 次结果字段一致性字段缺失越少越稳定这套评测不追求精确到小数点目的是把“感觉变好了”变成“数字变好了”。官方如果后续给出自己的标准优先按官方的来没有给就用这套先顶着。至少下次再遇到问题你能拿出数据而不是情绪。5. 接 API 时要顺手避开的另外几个坑围绕这轮讨论社区里还带出了几个和“用 Anthropic API”直接相关的问题我一起排一下。5.1 出现连接失败先按顺序排查不要乱改很多人在接入时遇到过类似报错unable to connect to Anthropic servicesfailed to connect to api.anthropic.com。这个报错出现时先把网络相关因素排除掉再谈模型问题。我建议按这个顺序查确认 base URL 正确。官方默认地址是https://api.anthropic.com不要拼错路径。确认认证头。Anthropic API 通常用x-api-key传密钥同时要带anthropic-version请求头常见值如2023-06-01。确认本机能访问到该域名。用 curl 发一个最简单的请求判断是连接超时、TLS 错误还是 HTTP 状态错误。确认超时设置。长任务要给足 read timeout建议 120 秒以上连接超时给 30 秒左右。确认是否被限流。429 状态码的表现和连接中断可能相似要分开看日志状态码。重试策略用指数退避不要遇到错误就立刻连续重打那样会放大问题。curl 连通性检查可以参考这个示例curl https://api.anthropic.com/v1/messages \ -H x-api-key: $ANTHROPIC_API_KEY \ -H anthropic-version: 2023-06-01 \ -H content-type: application/json \ -d {model:claude-opus-xxxx,max_tokens:1024,messages:[{role:user,content:测试连接}]}如果发现是本地防火墙、DNS 或证书问题先解决这些基础环境问题再回来改代码。报错信息本身已经给出了排查方向不用急着怀疑 API Key 或模型版本。5.2 Anthropic Messages API 和 OpenAI 兼容接口的差异社区里有人问“anthropic openai api compatible 区别”。这轮讨论带出这个问题很正常因为很多项目已经接好 OpenAI 风格接口想直接换成 Anthropic 模型。两者不能简单无缝替换差异主要集中在认证方式、消息结构、流式返回和错误格式上。对比项Anthropic Messages APIOpenAI Chat Completions认证x-api-key anthropic-versionAuthorization: Bearer ...system 消息messages 外的独立字段messages 里 rolesystem消息内容content 可以是文本块数组content 一般是字符串模型名claude 系列模型 IDgpt 系列模型 ID流式返回多种 event 类型delta 风格增量错误体字段结构和错误码不同字段结构和错误码不同如果你在用第三方 OpenAI 兼容网关要额外确认网关是否把请求体和响应体做了翻译。直接用原版 Anthropic SDK 会省掉很多边界问题。这条建议看起来基础但在“换平台之后接口报错”的排查里命中率最高。5.3 可解释性研究救不了眼前的“懒”热词里还有“anthropic 可解释”。Anthropic 在可解释性上确实有不少公开工作比如特征、电路层面的分析这些对理解模型内部机制很有价值。但要明确可解释性目前不是给用户调 prompt 用的也不能在今天帮你判断“为什么这条回答这么懒”。它更接近学术研究和产品安全方向离“让我这条任务不再被拒绝”还有很长距离。所以别指望等可解释性落地再解决问题眼下能用的还是参数、prompt、评测和重试策略。6. 如果模型还是懒我建议按这个思路收尾如果经过前面几步模型在部分任务上还是表现出“懒”或“话痨”不要急着换平台按下面这个顺序处理。6.1 先做小样本回归别靠感觉第一步不是继续骂模型而是跑一轮小样本回归。挑 20 条和你业务最像的任务把 temperature、max_tokens、system、消息上下文全部固定一次跑完。记录每条任务是成功、拒绝、空转还是解析失败。这轮跑完你至少能回答一个问题问题占比是 5% 还是 50%如果是 5%可能只是个别边界场景不值得大动干戈。如果是 50%那就说明当前配置或任务设计存在系统性偏差继续调 prompt 优先级比等官方更新更高。6.2 把测试集固化成资产跑模型更新就重测我一般会把这类测试集放进 Git 仓库和 prompt、参数版本放一起。每次模型版本更新、每次换参数都重跑一遍。很多“突然变懒”实际上是模型灰度更新后的行为回归你手里有历史数据就能快速判断是环境变化还是模型变化。没有这个固化测试集你就只能跟着社区情绪走既浪费时间也得不到结论。维护测试集本身不复杂重点是固定输入、固定参数、固定判分规则让它成为团队内部可复用的基线。6.3 换模型、换玩法还是换数据处理按顺序决策最后如果确实修不好按这个顺序决策。第一确认是不是任务设计问题。要求本身过于模糊、让模型承担了太多它不该做的判断先改任务拆分而不是改模型。第二看能不能在输出侧兜底。在程序里对“我不能”类开头做检测命中就走备胎 prompt或者用不同参数二次调用。这种做法能明显降低真实失败率成本也不高。第三再考虑换模型或换版本。同一模型系列的不同版本行为差异可能比名字看起来大不同厂商的模型可以通过同一套评测集对比后再换。另外提一句做技术选型时建议盯着评测结果和稳定性数据而不是看着公司新闻或 IPO 传闻做决定。模型能力、业务适配和资本动态是两回事。踩过几轮之后我的感受是这类“模型懒了、官方嘴硬”的事件最后真正能帮你落地的不是站队而是把一次模糊吐槽拆成可量化的指标、可复现的 prompt 和可执行的排查顺序。模型会更新参数会变但这套处理方式每次都能用得上。