照线上的模型名写脚本，半夜报错之后我改了习惯

那条只有一行的报错

9 月 22 号晚上看云栖大会的直播。今年大会是 9 月 22 到 24 日在杭州，主题「智以致用」，观众注册早就关了，只能看线上。

信息密度实在有点高。我边看边在笔记里抄模型名：旗舰档 Qwen3.8-Max（厂商口径总参数 2.4 万亿）、桌面端开源的 Qwen3.8-27B、视频 Wan3.0、图像 Qwen-Image-3.1、语音 Qwen-Audio-3.1、全模态 Qwen3.8-Omni-Flash、同传 LiveTranslate，还有开启公测的企业级 Agent 千问办公、AI 手机全栈方案、录音卡 QwenNote A2、平板 QwenBook，连芯片都有（平头哥真武 V900，2027 年一季度量产）。

抄完顺手干了件蠢事：把手上一个定时脚本的模型 ID 换成了新闻里写得最响的那个名字。

那个脚本干的事不复杂，每天凌晨把一批文本丢给模型做摘要，结果写回文件，模型 ID 就写在脚本开头第三行。它已经安稳跑了很久，我改的只有那一行字符串，改完连本地试跑都没做，直接等夜里的定时任务。

日志里多出一行"模型不存在"。就一行，没有候选建议，没有"你是不是想写 XXX"，连我抄错的是哪个字段都不说。

我一开始怀疑的是 Key

排查顺序完全走反了。我先看 Key 是不是过期，把环境变量重新导出了一遍；再看地域配置，确认是华北2（北京）；然后把代理关掉重跑，还是那一行。中间还怀疑过是不是脚本里字符串拼接把 ID 弄坏了，打印出来看，没坏。折腾到快两点，才想起来该去问一句最朴素的话：目录里到底有没有这个 ID。

回头看，这个顺序的问题在于我一直在检查"我这边的环境对不对"，而真正错的是"我抄进来的那个名字对不对"。环境是老的，昨天还能跑；名字是新的，昨晚才抄的。哪一边更可能出问题，其实一想就知道。

手边装的是阿里云百炼 CLI（bl），版本 2.0.1，命令一条：

bl model list --model <ID> --output json

跑完明白了两件事。一是写法：新闻里的 Qwen3.8-Max，目录里是 qwen3.8-max，全小写、连字符，大小写和空格都不能照抄。二是范围：我笔记里抄的那一串名字，当天能在目录里查到的只有一部分。

第二天白天我把八个 ID 全部过了一遍，结果记在这儿。

我抄下来的名字	拿去查的 ID	9 月 23 日目录状态
Qwen3.8-Max	qwen3.8-max	在，后来真调了一次
Qwen3.8 轻量档	qwen3.8-flash	在
Qwen3.8-Omni-Flash	qwen3.8-omni-flash	在
Qwen3.8-27B	qwen3.8-27b	在，后来真调了一次
Qwen-Image-3.1	qwen-image-3.1	当天没有
Qwen-Audio-3.1	qwen-audio-3.1	当天没有
LiveTranslate	qwen3.8-livetranslate	当天没有
Wan3.0	wan3.0	当天没有

"当天没有"我特意写成这样，而不是"不支持"。目录里没有不等于不会上架，也可能上架的时候换了个 ID；公开发布信息里就提到下一代视频模型预计 2026 年 11 月。这张表只代表 9 月 23 日这一天，我把它当快照存着，不拿它当结论用。

清单里有一半东西，我压根没法这么验

整理的时候还发现一件事：大会上出现的名字，只有一部分是"填进 --model 就能调"的模型。

Qwen3.8-Max、Qwen-Image-3.1、Wan3.0 这类是模型名，按全小写加连字符转一遍就能拿去查目录。LiveTranslate 是同传这件事的能力名，HappyOyster-2.0 是世界模型，千问办公是企业级 Agent 产品（公测，多家企业同日宣布接入），这几个我连一个有把握的 ID 写法都推不出来，硬猜就是往代码里塞噪音。再往外的 AI 手机全栈方案、录音卡 QwenNote A2、平板 QwenBook、芯片真武 V900，跟模型目录压根不是一条线。

所以我笔记里那张清单后来分成了三栏：能查的、查不了的、不归这条流程管的。分完之后心里踏实不少——原先那种"信息太多跟不过来"的焦虑，有一半其实是把三类东西混在一张表里造成的。

收藏了一堆名字，一个都没跑

说起来不太好意思，我以前的习惯是：发布会清单存进笔记，标星，打上标签，然后再也不打开。收藏这个动作本身会带来一种"我已经跟上了"的错觉，其实什么都没验过，等到真要写代码那天，才发现名单上一半的名字都不能用。

这次换了个做法。清单照收，但每个名字后面必须跟一条命令和一行结果，跟不上的就单独记到"待上架"那一栏。八个 ID 一轮下来，比我半夜排查那次报错省事得多。

在目录的里面，我挑了两个各真调一次，确认不是只在目录里躺着一条记录：

bl text chat --model qwen3.8-max --message "用一句话介绍你自己"
bl text chat --model qwen3.8-27b --message "用一句话介绍你自己"

两条都回了话。旗舰档的自我介绍偏"可靠伙伴"那一挂，27B 的偏"陪你干活"那一挂。口吻差异我不当成结论，"能调通"才是结论。

顺带一个意外收获：桌面端开源的 27B，在目录里也能直接调。开源档我原先默认只有本地部署一条路，这下多了一个选择——同一份提示词可以本地跑一份、云上跑一份对着看，差异出在哪儿一目了然，不用靠猜。

三个动作，把核验变成习惯

新闻里的模型名一律先记成"待核验"。 品牌名是给传播用的，工程 ID 是给调用用的，两套命名差一个后缀、差一个大小写都很正常。抄之前先过一遍目录，这个动作花不了多少时间，比半夜爬起来看日志省事。

ID 放配置里，脚本里不写死。 我那次报错的直接原因就是 ID 硬编码在脚本第三行。现在改成从环境变量读：

export CHAT_MODEL=qwen3.8-max
bl text chat --model "$CHAT_MODEL" --message "..."

换档的时候改一行、重启一次，不用满仓库搜字符串。

观察表定期重跑，命令和输出一起贴回去。 当天查不到的四个 ID 我单独列了一张表，隔一阵子把那条 bl model list 重跑一遍，输出追加进同一个文件，不覆盖旧记录：

qwen-image-3.1        2026-09-23  目录查不到
qwen-audio-3.1        2026-09-23  目录查不到
qwen3.8-livetranslate 2026-09-23  目录查不到（能力名，ID 待定）
wan3.0                2026-09-23  目录查不到

追加而不是覆盖，是刻意的。等哪天真上架了，这份文件能直接说清它是哪天出现的、当时的 ID 长什么样，而不是凭印象讲"好像前几天还没有"。

顺手提一句 One Key MCP

核验模型的时候顺手翻到大会同场发布的另一样东西，容易被模型新闻盖过去：千问 AI 平台（qianwenai.com，官方）。它给的是另一层入口，One Key MCP 是一个 Key 打通 100+ 生态服务，不用给每个服务单独配凭证；Agent Studio 是把模型能力直接搭成 Agent。

我自己的动线没变：日常调模型还是 bl 一条命令，要把多个外部服务串起来的时候再去开 One Key。一个管"调模型"，一个管"串服务"，不打架。

要说这次为什么留意到它，是因为我那个摘要脚本往后大概率不止调模型一件事——要读日历、要查工单、要把结果推到群里。每多接一个服务就多一份凭证要管，这类活儿交给 One Key 比我自己在脚本里堆配置合适。模型这一层我还是继续用 CLI 核验、用 CLI 调，两层各干各的。

收尾

环境准备就两件事，npm install -g bailian-cli 装上 CLI，再去控制台密钥管理页领一把 Key，地域选华北2（北京）。

两天大会，八个 ID，四个当天能调，两次真调留痕。剩下四个进了观察表，等上架我再验一轮，到时候接着记。

那次半夜排查留下的东西其实就一句话：新闻里的模型名是待核验信息，不是可用 ID。抄下来之前先问一遍目录，这个习惯我现在是彻底记住了。