Mingyu's Library主页
2026年9月23日

第 35 课:新功能速用 —— v2.1.280(Opus 5.5 默认切换、effort 封顶、plugin eval)

📅 2026-09-23 上一课(第 34 课)讲的是 v2.1.277 / v2.1.278。这一课覆盖 v2.1.280(09-22)——这一版的核心变化不是某个具体命令,而是默认模型换了:Pro / Team Standard 套餐的默认模型从 Sonnet 改成 Opus,且默认 Opus 版本升级到了刚发布的 Claude Opus 5.5。如果你没主动确认过,这周的账单曲线可能会让你意外。 前置:第 15 课(成本控制)、第 17 课(插件与 Marketplace)。

技巧 1(入门):先确认你今天到底在用哪个模型

是什么:v2.1.280 把 Pro / Team Standard 套餐的默认模型从 Sonnet 改成了 Opus,并把默认 Opus 版本切到刚发布的 Claude Opus 5.5(\$4/\$20 每 Mtok,比 Opus 5 便宜约 40%,但仍然比 Sonnet 贵不少)。这不是一个需要你手动开启的功能,而是静默生效的默认值变化——尤其如果你是从更早版本自动更新上来的,很可能自己都没意识到模型已经换了。

怎么确认:

# 1. 确认 CLI 版本已经在 v2.1.280 或之后
claude --version

# 2. 会话里直接看当前用的是哪个模型
/model

# 3. 如果只是想临时切回 Sonnet(比如做低复杂度的批量任务)
/model sonnet

判断标准:如果你的日常工作以"读代码 + 小改动 + 跑测试"为主,Opus 5.5 的推理质量大概率是过剩的,/model sonnet 切回去更划算;如果是"复杂重构 + 多步骤规划",默认换成 Opus 5.5 反而是免费的升级——先看一眼 /model,再决定要不要管它。

📎 Claude Opus 5.5 迁移指南 · v2.1.280 Release Notes

技巧 2(进阶,承接第 15 课):用 maxEffortLevel 给 effort 设个天花板

背景:Claude Code 的 effort 档位从 low 一路到 max,档位越高、思考越深、花的 token 也越多。默认模型换成 Opus 5.5 之后,如果团队里有人习惯手动拉满 /effort xhigh 或 max 去处理日常小任务,叠加更贵的默认模型,成本曲线会翻得比预期快。Week 37(09-07~09-11)新增的 maxEffortLevel 设置,可以在配置层面直接封顶,不管谁在会话里怎么调,都不会超过这个上限。

怎么用——在项目或用户级 settings.json 里加一行:

{
  "maxEffortLevel": "high"
}

设置之后,团队里任何人在会话内执行 /effort xhigh 或 /effort max 都会被自动压到 high,/status 里会提示当前 effort 被配置封顶。

判断标准:这条适合团队 / CI 场景先用起来——个人日常会话里手动盯 /cost 就够了,但一旦是多人共享的项目配置或跑在流水线里的无头会话,maxEffortLevel 能防止"有人手滑开了 max 档位、账单月底才发现"这种事。

📎 Week 37 更新日志 · 第 15 课:成本控制

技巧 3(进阶):claude plugin eval —— 装插件前,先让它跑一遍测试集再决定要不要留

解决的问题:第 17 课讲过插件的"安装—评估—淘汰"闭环,但"评估"这一步过去基本靠手感——装上试用几天,感觉不对再卸。Week 37 新增的 claude plugin eval 把这一步变成了可重复的自动化流程:给插件定义一组测试用例和评分标准,跑出结果后和不装这个插件的基线做对比,用数字而不是直觉决定要不要留。

怎么用:

# 1. 让 Claude 帮你起草测试用例和评分器(基于插件的功能描述)
claude plugin eval init <plugin-name>

# 2. 编辑生成的用例文件后,正式跑一遍评测
claude plugin eval run <plugin-name>

# 输出会包含:装插件 vs 不装插件的任务成功率对比、
# 额外消耗的 token/上下文占用、以及每条用例的具体差异

为什么值得做:这次更新和 09-21 那节课讲的 Plugin4Shell 供应链风险本质上是同一件事的两面——一个管"这个插件是不是安全的",一个管"这个插件是不是真的有用"。装了但从没验证过收益的插件,既占上下文、又是一条打开的自动更新通道,plugin eval 让你在决定"留 or 卸"时有个真实依据,而不是纯粹靠印象。

📎 Week 37 更新日志 · 第 17 课:插件与 Marketplace

技巧 4(进阶,MCP 场景):MCP 工具描述被截断?CLAUDE_CODE_MAX_MCP_DESCRIPTION_LENGTH 能救

解决的问题:Claude Code 对每个 MCP 工具的 description 字段有 2,048 字符的默认上限,超出部分会被静默截断。平时问题不大,但如果你接的是那种工具描述里塞了完整 JSON Schema 示例、多语言说明或详细参数表的 MCP server(常见于自建的企业内部 MCP),截断会导致 Claude 拿到的工具说明不完整,进而更容易调错参数或漏用某个可选字段。v2.1.280 新增的环境变量 CLAUDE_CODE_MAX_MCP_DESCRIPTION_LENGTH 可以直接调整这个上限。

怎么用:

# 把上限从默认 2048 提到 6000 字符,适合工具描述特别长的内部 MCP server
export CLAUDE_CODE_MAX_MCP_DESCRIPTION_LENGTH=6000

# 也可以写进项目的 .env 或 settings.json 的 env 字段,让团队都生效

判断标准:先用 /mcp 看一眼有没有工具描述在面板里显示不全、结尾像是被硬切断;如果有,再调这个变量,不要一上来就无脑调大——描述越长,每次工具调用前塞进上下文的 token 也越多,和第 15 课"上下文即成本"的原则是一回事。

📎 v2.1.280 Release Notes

今日实操(10-20 分钟)

  1. 在任意一个正在用的项目里执行 /model,确认当前默认模型是不是已经变成 Opus 5.5;如果你的日常任务偏简单,顺手 /model sonnet 切回去看看响应速度和质量差异。
  2. 给一个团队共享的项目 settings.json 加上 "maxEffortLevel": "high",重开一个会话确认 /effort max 会被自动压到 high。
  3. 挑一个你最近新装、但还没认真验证过收益的插件,跑一次 claude plugin eval init + claude plugin eval run,看结果是不是符合你的预期——不符合就卸掉。

验收标准:你能说清楚"现在这个项目默认用的是什么模型、effort 上限是多少",并且手上至少有一份插件的真实评测数据,而不是"感觉还行"。

本课速查

想做的事 动作
确认当前默认模型/临时切换 claude --version 确认 ≥2.1.280;会话内 /model 查看,/model sonnet 临时切回
防止 effort 被手滑拉满导致超支 settings.json 里加 "maxEffortLevel": "high"(或团队能接受的档位)
用数据决定插件留不留 claude plugin eval init <name> → claude plugin eval run <name>
MCP 工具描述被截断 export CLAUDE_CODE_MAX_MCP_DESCRIPTION_LENGTH=6000(按需调整)

第 35 课 · 2026-09-23 · 上一课:第 34 课「新功能速用 —— v2.1.277 / v2.1.278」(2026-09-21)