SkillNexus 的 Eval 折线又飘了同一批 TestCase、同一个 Skill 版本G1 往下掉一格S2 反而往上跳Skill 正文你一个字都没改。先别急着去改 Skill先把模型通道按住不动——去 TaoToken 的 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 创建一把 Key再把 SkillNexus 里的模型 Base URL 指向 https://taotoken.net/api 通道固定之后再重跑对照才分得清是模型换代还是 Skill 退化。这件事的麻烦在于SkillNexus 已经把「好不好」量化得挺细了雷达图、趋势折线、历史记录都在Eval 还拆成 G 系列和 S 系列八个维度。可它量化的是 Skill 和它的产出量化不了「这次打分用的模型是从哪条路进来的」。通道一换、一抖、一限流分数就跟着飘你看到的是折线读出来的却是噪声。这篇就按排障的路子走先解释分数为什么飘再动手把 SkillNexus 的模型调用改到一条固定的兼容通道上然后重跑同一批 TestCase 做对照最后教你怎么判读 G1/S2 两条曲线。1. 从 ~/.claude/skills/ 目录说起Eval 分数为什么成了唯一的证据1.1 你答不上来的那个问题哪个 Skill 真的好用打开~/.claude/skills/或者项目根目录下的规则文件目录数一数里面躺着多少个文件。十个、二十个还是一堆叫my-prompt-v3-final、my-prompt-v3-final-2的东西Skill 这种载体本身很轻一个 Markdown 文件头部一段 YAML frontmatter 写清name、description、tags下面接自然语言指令装到 Claude Code 的.claude/commands/或 Cursor 的规则目录里就能生效。轻的好处是分发方便坏处是没人替你记账。于是「哪个 Skill 真的好用」这个问题大多数人的答案还是凭感觉。感觉这东西在边界情况下最不靠谱一个 code-review 类的 Skill 在常规 diff 上表现不错遇到大段重构或者边界输入时可能整个失效而你不重跑就永远不知道。SkillNexus 这类平台想解决的正是这一段空白——把 Skill 从生成、建数据集、打分到进化串成一条闭环让「好不好」有数据可查。1.2 G1 掉一格三种可能里只有一种是 Skill 的锅当 Eval 的 G1 从高位掉下来逻辑上只有三种可能。第一种模型换代了Claude 侧换了版本你原先调好的指令在新模型上语义漂移原来能压住的格式约束现在压不住。第二种Skill 本身退化了可能是你改了正文、删了一句话、动了 frontmatter 里的描述。第三种也是最容易被忽略的一种模型调用这条通道本身不稳响应被截断、被限流、被换了后端模型分数自然跟着抖。前两种你还能靠对比版本查出来第三种最阴因为它不报错。请求返回 200内容看着也像那么回事只是质量悄悄降了。所以排查的第一步不是打开 Skill 编辑器而是先把「模型从哪来」这件事固定住。通道固定了变量就少一个剩下的分数变化才好归因。2. 在 SkillNexus 里把模型调用挂到 TaoToken 通道2.1 先去落地页把 Key 建出来这一步替代的是原文里「配置模型来源」那一环。打开 TaoToken 落地页注册登录进控制台创建一把 API Key复制出来。后面所有配置里这把 Key 都写成占位符YOUR_API_KEY你自己填的时候换成实际值就行。顺手在同一个页面看一眼模型广场把你要用来跑 Eval 的模型 ID 记下来——模型 ID 一律以落地页当时的列表为准别人博客里抄来的名字很可能已经下架。注意一点TaoToken 这边只负责给你 Key 和一个固定的 Base URL它不参与 SkillNexus 的评测逻辑也不替你重跑 TestCase。重跑这件事仍然是你自己在 SkillNexus 的 Eval 页面点下去。2.2 自定义供应商那四个字段怎么填SkillNexus 是桌面应用模型来源通常在设置里的供应商/模型配置那一块。不同小版本的字段命名可能略有差异但需要填的信息就四样按下面这张表对字段填什么供应商类型自定义 / 兼容模式以你当前版本的下拉选项为准Base URLhttps://taotoken.net/apiAPI KeyYOUR_API_KEY模型 ID以落地页模型广场当时列表为准Base URL 末尾不要加/v1。有些 SDK 在内部会自己补一次版本路径你手填一次、它再补一次就会拼出两个/v1表现是 404 而不是报「地址写错」很容易查半天。Tail 上也不要有斜杠。2.3 落地页地址和接口地址不是一回事这两个地址长得像用途完全不同混了就会出问题用途地址注册、创建 Key、看模型广场、查用量https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end填进 SkillNexus 的 Base URLhttps://taotoken.net/api落在浏览器里的是给人点的页面落在工具配置里的是给程序请求的接口。带查询参数的那串地址填进 Base URL请求会直接失败因为它不是一个 API 端点。2.4 Skill 最终跑在 Claude Code 里那份 env 也要对SkillNexus 生成的 Skill 最后大概率会装进 Claude Code 的.claude/commands/目录里跑。如果你的评测链路里包含「生成完 Skill 直接拉起来验证」这一步那 Claude Code 这边的模型出口也得指向同一条通道否则 Eval 用的是 A 通道实际执行用的是 B 通道对照就白做了。环境变量写法export ANTHROPIC_BASE_URLhttps://taotoken.net/api export ANTHROPIC_AUTH_TOKENYOUR_API_KEY export ANTHROPIC_MODELYOUR_MODEL_ID想写进配置文件放在~/.claude/settings.json的env里{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_AUTH_TOKEN: YOUR_API_KEY, ANTHROPIC_MODEL: YOUR_MODEL_ID } }YOUR_MODEL_ID同样以模型广场当时列出的可用 ID 为准别自己拼日期后缀。这两处配完之后SkillNexus 打分用的模型和 Claude Code 执行 Skill 用的模型才算真正同源。3. 重跑同一批 TestCase对比模式和三条件基线怎么摆3.1 跑对比之前先锁死的三个变量想用 Eval 的对比模式得出可信结论跑之前先把三个变量按住Testcase 集合不动就用之前那批Skill 版本不动别一边换通道一边顺手改正文评测模式不动上一轮用单次评测这轮也别换成三条件基线。三个都不动这轮和上轮的差异才只剩「通道」这一项。如果上一轮的分数是靠另一条不稳定的通道打出来的那它做基线其实是不合格的。比较稳妥的做法是切到固定通道之后先把同一批 TestCase 连跑两三轮看 G1 和 S2 的波动幅度有多大。同一通道内自己跟自己都飘得厉害那说明抖动的来源不在模型换代上得先解决采样侧的稳定性。3.2 三条件基线能把「通道增益」单独拎出来SkillNexus 的三条件基线是「无 Skill 组 / 当前版本 / AI 生成版」三条并排跑。这个设计在换通道这件事上很好用无 Skill 组给你一个模型裸能力的底当前版本给你带上 Skill 之后的表现两条线的差值才是 Skill 的真实增益。如果换了通道之后两条线的差值明显变大或者变小说明新通道对指令的遵循程度和旧通道不一样而不是你的 Skill 变强变弱了。判读的时候建议把这个差值单独记一笔标上通道名和跑的日期。等模型换代的时候再跑一遍同样的三条件两次的差值放在一起看比看单条绝对分数清楚得多。3.3 TestCase 里有 SQL 的时候别让 Agent 直连生产库很多团队会把「能根据报错定位问题」这类任务写成 TestCase里面难免涉及数据库。这里有一条硬线SkillNexus 和它调用的模型都不应该直连你的生产库去执行任何东西。正确做法是让 Skill 生成诊断用的 SQL你在本地或者 SQL 客户端里手动执行把结果和报错原样贴回对话再由模型解释。这样做有两个好处一是安全生产库不会被一个还在调优中的 Skill 摸到二是可复现每条 TestCase 的输入输出都有明确的人工确认环节Eval 打分时不会因为「执行环境不同」引入新的噪声。把执行这步从自动化里拿出来对照跑的结论反而更干净。3.4 曲线判读三种形状对应三种结论重跑完之后把 G1 和 S2 的历史折线叠在一起看大致会落进三种形状。第一种切到固定通道之后两条线都收敛成小幅波动。这说明之前的飘动主要来自通道不稳Skill 本身没问题回去继续用就行。第二种切通道后 G1 基本没变但 S2 明显变差。这通常是新通道的输出更啰嗦同样的任务多花了不少 token属于成本维度的问题可以考虑用 Evo 里的多目标优化策略在质量和成本之间重新找平衡点。第三种通道固定后 G1 仍然单向下滑而且换成无 Skill 组的基线也在同步下滑。这时候基本可以判定是模型换代引起的Skill 需要针对新模型重调。4. 为什么偏偏盯着 G1 和 S2 看4.1 G1 管结果对不对S2 管 token 花得值不值SkillNexus 的八个维度分成两组。G 系列衡量产出质量G1 是正确性G2 是指令遵循G3 是安全性G4 是完整性G5 是对边界输入的鲁棒性。S 系列衡量 Skill 本身写得好不好S1 是可执行性S2 是成本意识S3 是可维护性。排通道问题的时候G1 和 S2 是最敏感的一对。G1 直接反映「这次算不算做对了」通道被换了后端模型、响应被截断G1 会最先抖。S2 反映输出是不是简洁通道换了之后如果开始出现大段无意义的复述、重复确认、冗长总结S2 会同步掉下去。两条线一个往下、一个往上跳几乎可以确定是出口侧的变化而不是你写的那几行指令。4.2 通道抖动在雷达图上的典型形状单看数字不如看形状。通道不稳的时候雷达图往往不是整体缩小而是某几个角被压扁G1 和 G2 一起往下G4 反而正常G5 忽高忽低。这种偏向性说明模型还能听懂任务但在格式约束和边界处理上打了折扣。对比之下Skill 退化通常是均匀的八个维度一起小幅下滑因为指令本身的信息量少了。拿到雷达图先看形状再去决定下一步是查通道还是改 Skill能省掉不少来回试的时间。5. Evo 和 Trending 在换通道之后要重建的基线5.1 evidence 与 strategy低分条目的来源必须同源Evo 里两个常用的流式进化策略是 evidence 和 strategy。evidence 把评测里的低分条目当证据精准定位问题再修strategy 让你指定优化目标比如希望 G1 和 S2 一起提升由模型给出针对性方案。这两个策略都依赖一件事拿来做证据的低分条目必须和你要提升的目标是同一批、同一通道打出来的分。如果低分条目是旧通道打的新通道下重跑其实不低那 Evo 就是在修一个不存在的问题改出来的新版本可能反而更差。切通道之后的第一件事是把参与进化的 TestCase 全部用新通道重跑一遍确认低分条目依然低分再启动 Evo。后台那几个自动化引擎也是同一个道理。EvoSkill 依赖最差样本、SkillX 依赖高分历史、SkillClaw 做跨会话的失败聚类输入数据里只要混了两种通道的分数聚类出来的「结构性缺陷」大概率是伪信号。5.2 Trending 榜单混进两种通道的历史分会失真Trending 是基于所有历史评测数据按八个维度排名的。它的价值在于长期趋势所以对数据来源的一致性比 Eval 单页更敏感。换通道之前打的分和换通道之后打的分混在一张榜上排出来的名次反映的是通道差异不是 Skill 之间的差异。处理办法不复杂给换通道之后重跑过的 Skill 打个标记或者在团队的记录里留一条时间线注明哪一天开始换的通道。看榜的时候只比较同一条时间线内的分数。历史数据本身不要删它还有用——它就是那次通道切换的现场记录。6. SkillNexus 接通道的报错对照6.1 401Key 没进去或者带上了空格401 基本只和 Key 有关。常见三种复制 Key 的时候尾部多带了一个空格或换行SkillNexus 里同时存了多个供应商配置模型指向了 A 供应商而 Key 填的是 B 的Key 在控制台被删掉或者重建过本地还是旧值。排查顺序先回 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 的控制台确认这把 Key 还在然后重新复制一次粘贴时留意首尾有没有多余字符保存后重启一次 SkillNexus 让配置重新加载。6.2 404Base URL 末尾多写了 /v1这是最常见的一类错。Base URL 填https://taotoken.net/api就够了不需要再补版本路径。有些客户端库会在内部自动追加一次版本段你手填的https://taotoken.net/api/v1会被拼成两段服务端找不到对应路由就返回 404。看起来像「地址不存在」实际是路径重复。判断方法很简单把 Base URL 里的/v1去掉再试一次。如果 404 变成了正常的 401 或者直接成功那就确认是这个问题。6.3 模型不存在模型 ID 抄了别处的旧名字报「model not found」或者类似提示时先别怀疑通道。绝大多数情况是模型 ID 写错了从别的文章里抄了一个带日期后缀的名字或者把展示名当成了调用 ID。正确做法是打开模型广场从当时的列表里挑一个原样复制到 SkillNexus 的模型 ID 字段。如果同一个 Skill 在 Eval 里能跑但装进 Claude Code 后报模型不存在那就去检查~/.claude/settings.json里的ANTHROPIC_MODEL两处填的应该是同一个 ID。7. 对照跑完之后去控制台确认这次调用有没有记上配置保存、TestCase 重跑完、G1 和 S2 的曲线也对照过了最后收个尾回 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 的控制台看一眼这轮评测的调用记录模型 ID 和请求量对得上说明通道这一层已经稳住了后面曲线再动就可以放心往 Skill 和模型换代两个方向归因。想先确认这把 Key 通不通用同一把 Key 去 模型对话页 发一条测试消息最快模型 ID 和 Base URL 有没有配对一条消息就能验出来。Eval 批次跑得密、token 消耗上来之后可以打开 Coding Plan 看看套餐是否够用Key 的增删改查都在 控制台 API Keys。等 Skill 真正落到 Claude Code 里执行时环境变量怎么写对照 Claude Code 接入文档 抄一遍就行。
Eval 分数总飘？SkillNexus 走 TaoToken 通道重跑对照看模型换代
SkillNexus 的 Eval 折线又飘了同一批 TestCase、同一个 Skill 版本G1 往下掉一格S2 反而往上跳Skill 正文你一个字都没改。先别急着去改 Skill先把模型通道按住不动——去 TaoToken 的 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 创建一把 Key再把 SkillNexus 里的模型 Base URL 指向 https://taotoken.net/api 通道固定之后再重跑对照才分得清是模型换代还是 Skill 退化。这件事的麻烦在于SkillNexus 已经把「好不好」量化得挺细了雷达图、趋势折线、历史记录都在Eval 还拆成 G 系列和 S 系列八个维度。可它量化的是 Skill 和它的产出量化不了「这次打分用的模型是从哪条路进来的」。通道一换、一抖、一限流分数就跟着飘你看到的是折线读出来的却是噪声。这篇就按排障的路子走先解释分数为什么飘再动手把 SkillNexus 的模型调用改到一条固定的兼容通道上然后重跑同一批 TestCase 做对照最后教你怎么判读 G1/S2 两条曲线。1. 从 ~/.claude/skills/ 目录说起Eval 分数为什么成了唯一的证据1.1 你答不上来的那个问题哪个 Skill 真的好用打开~/.claude/skills/或者项目根目录下的规则文件目录数一数里面躺着多少个文件。十个、二十个还是一堆叫my-prompt-v3-final、my-prompt-v3-final-2的东西Skill 这种载体本身很轻一个 Markdown 文件头部一段 YAML frontmatter 写清name、description、tags下面接自然语言指令装到 Claude Code 的.claude/commands/或 Cursor 的规则目录里就能生效。轻的好处是分发方便坏处是没人替你记账。于是「哪个 Skill 真的好用」这个问题大多数人的答案还是凭感觉。感觉这东西在边界情况下最不靠谱一个 code-review 类的 Skill 在常规 diff 上表现不错遇到大段重构或者边界输入时可能整个失效而你不重跑就永远不知道。SkillNexus 这类平台想解决的正是这一段空白——把 Skill 从生成、建数据集、打分到进化串成一条闭环让「好不好」有数据可查。1.2 G1 掉一格三种可能里只有一种是 Skill 的锅当 Eval 的 G1 从高位掉下来逻辑上只有三种可能。第一种模型换代了Claude 侧换了版本你原先调好的指令在新模型上语义漂移原来能压住的格式约束现在压不住。第二种Skill 本身退化了可能是你改了正文、删了一句话、动了 frontmatter 里的描述。第三种也是最容易被忽略的一种模型调用这条通道本身不稳响应被截断、被限流、被换了后端模型分数自然跟着抖。前两种你还能靠对比版本查出来第三种最阴因为它不报错。请求返回 200内容看着也像那么回事只是质量悄悄降了。所以排查的第一步不是打开 Skill 编辑器而是先把「模型从哪来」这件事固定住。通道固定了变量就少一个剩下的分数变化才好归因。2. 在 SkillNexus 里把模型调用挂到 TaoToken 通道2.1 先去落地页把 Key 建出来这一步替代的是原文里「配置模型来源」那一环。打开 TaoToken 落地页注册登录进控制台创建一把 API Key复制出来。后面所有配置里这把 Key 都写成占位符YOUR_API_KEY你自己填的时候换成实际值就行。顺手在同一个页面看一眼模型广场把你要用来跑 Eval 的模型 ID 记下来——模型 ID 一律以落地页当时的列表为准别人博客里抄来的名字很可能已经下架。注意一点TaoToken 这边只负责给你 Key 和一个固定的 Base URL它不参与 SkillNexus 的评测逻辑也不替你重跑 TestCase。重跑这件事仍然是你自己在 SkillNexus 的 Eval 页面点下去。2.2 自定义供应商那四个字段怎么填SkillNexus 是桌面应用模型来源通常在设置里的供应商/模型配置那一块。不同小版本的字段命名可能略有差异但需要填的信息就四样按下面这张表对字段填什么供应商类型自定义 / 兼容模式以你当前版本的下拉选项为准Base URLhttps://taotoken.net/apiAPI KeyYOUR_API_KEY模型 ID以落地页模型广场当时列表为准Base URL 末尾不要加/v1。有些 SDK 在内部会自己补一次版本路径你手填一次、它再补一次就会拼出两个/v1表现是 404 而不是报「地址写错」很容易查半天。Tail 上也不要有斜杠。2.3 落地页地址和接口地址不是一回事这两个地址长得像用途完全不同混了就会出问题用途地址注册、创建 Key、看模型广场、查用量https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end填进 SkillNexus 的 Base URLhttps://taotoken.net/api落在浏览器里的是给人点的页面落在工具配置里的是给程序请求的接口。带查询参数的那串地址填进 Base URL请求会直接失败因为它不是一个 API 端点。2.4 Skill 最终跑在 Claude Code 里那份 env 也要对SkillNexus 生成的 Skill 最后大概率会装进 Claude Code 的.claude/commands/目录里跑。如果你的评测链路里包含「生成完 Skill 直接拉起来验证」这一步那 Claude Code 这边的模型出口也得指向同一条通道否则 Eval 用的是 A 通道实际执行用的是 B 通道对照就白做了。环境变量写法export ANTHROPIC_BASE_URLhttps://taotoken.net/api export ANTHROPIC_AUTH_TOKENYOUR_API_KEY export ANTHROPIC_MODELYOUR_MODEL_ID想写进配置文件放在~/.claude/settings.json的env里{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_AUTH_TOKEN: YOUR_API_KEY, ANTHROPIC_MODEL: YOUR_MODEL_ID } }YOUR_MODEL_ID同样以模型广场当时列出的可用 ID 为准别自己拼日期后缀。这两处配完之后SkillNexus 打分用的模型和 Claude Code 执行 Skill 用的模型才算真正同源。3. 重跑同一批 TestCase对比模式和三条件基线怎么摆3.1 跑对比之前先锁死的三个变量想用 Eval 的对比模式得出可信结论跑之前先把三个变量按住Testcase 集合不动就用之前那批Skill 版本不动别一边换通道一边顺手改正文评测模式不动上一轮用单次评测这轮也别换成三条件基线。三个都不动这轮和上轮的差异才只剩「通道」这一项。如果上一轮的分数是靠另一条不稳定的通道打出来的那它做基线其实是不合格的。比较稳妥的做法是切到固定通道之后先把同一批 TestCase 连跑两三轮看 G1 和 S2 的波动幅度有多大。同一通道内自己跟自己都飘得厉害那说明抖动的来源不在模型换代上得先解决采样侧的稳定性。3.2 三条件基线能把「通道增益」单独拎出来SkillNexus 的三条件基线是「无 Skill 组 / 当前版本 / AI 生成版」三条并排跑。这个设计在换通道这件事上很好用无 Skill 组给你一个模型裸能力的底当前版本给你带上 Skill 之后的表现两条线的差值才是 Skill 的真实增益。如果换了通道之后两条线的差值明显变大或者变小说明新通道对指令的遵循程度和旧通道不一样而不是你的 Skill 变强变弱了。判读的时候建议把这个差值单独记一笔标上通道名和跑的日期。等模型换代的时候再跑一遍同样的三条件两次的差值放在一起看比看单条绝对分数清楚得多。3.3 TestCase 里有 SQL 的时候别让 Agent 直连生产库很多团队会把「能根据报错定位问题」这类任务写成 TestCase里面难免涉及数据库。这里有一条硬线SkillNexus 和它调用的模型都不应该直连你的生产库去执行任何东西。正确做法是让 Skill 生成诊断用的 SQL你在本地或者 SQL 客户端里手动执行把结果和报错原样贴回对话再由模型解释。这样做有两个好处一是安全生产库不会被一个还在调优中的 Skill 摸到二是可复现每条 TestCase 的输入输出都有明确的人工确认环节Eval 打分时不会因为「执行环境不同」引入新的噪声。把执行这步从自动化里拿出来对照跑的结论反而更干净。3.4 曲线判读三种形状对应三种结论重跑完之后把 G1 和 S2 的历史折线叠在一起看大致会落进三种形状。第一种切到固定通道之后两条线都收敛成小幅波动。这说明之前的飘动主要来自通道不稳Skill 本身没问题回去继续用就行。第二种切通道后 G1 基本没变但 S2 明显变差。这通常是新通道的输出更啰嗦同样的任务多花了不少 token属于成本维度的问题可以考虑用 Evo 里的多目标优化策略在质量和成本之间重新找平衡点。第三种通道固定后 G1 仍然单向下滑而且换成无 Skill 组的基线也在同步下滑。这时候基本可以判定是模型换代引起的Skill 需要针对新模型重调。4. 为什么偏偏盯着 G1 和 S2 看4.1 G1 管结果对不对S2 管 token 花得值不值SkillNexus 的八个维度分成两组。G 系列衡量产出质量G1 是正确性G2 是指令遵循G3 是安全性G4 是完整性G5 是对边界输入的鲁棒性。S 系列衡量 Skill 本身写得好不好S1 是可执行性S2 是成本意识S3 是可维护性。排通道问题的时候G1 和 S2 是最敏感的一对。G1 直接反映「这次算不算做对了」通道被换了后端模型、响应被截断G1 会最先抖。S2 反映输出是不是简洁通道换了之后如果开始出现大段无意义的复述、重复确认、冗长总结S2 会同步掉下去。两条线一个往下、一个往上跳几乎可以确定是出口侧的变化而不是你写的那几行指令。4.2 通道抖动在雷达图上的典型形状单看数字不如看形状。通道不稳的时候雷达图往往不是整体缩小而是某几个角被压扁G1 和 G2 一起往下G4 反而正常G5 忽高忽低。这种偏向性说明模型还能听懂任务但在格式约束和边界处理上打了折扣。对比之下Skill 退化通常是均匀的八个维度一起小幅下滑因为指令本身的信息量少了。拿到雷达图先看形状再去决定下一步是查通道还是改 Skill能省掉不少来回试的时间。5. Evo 和 Trending 在换通道之后要重建的基线5.1 evidence 与 strategy低分条目的来源必须同源Evo 里两个常用的流式进化策略是 evidence 和 strategy。evidence 把评测里的低分条目当证据精准定位问题再修strategy 让你指定优化目标比如希望 G1 和 S2 一起提升由模型给出针对性方案。这两个策略都依赖一件事拿来做证据的低分条目必须和你要提升的目标是同一批、同一通道打出来的分。如果低分条目是旧通道打的新通道下重跑其实不低那 Evo 就是在修一个不存在的问题改出来的新版本可能反而更差。切通道之后的第一件事是把参与进化的 TestCase 全部用新通道重跑一遍确认低分条目依然低分再启动 Evo。后台那几个自动化引擎也是同一个道理。EvoSkill 依赖最差样本、SkillX 依赖高分历史、SkillClaw 做跨会话的失败聚类输入数据里只要混了两种通道的分数聚类出来的「结构性缺陷」大概率是伪信号。5.2 Trending 榜单混进两种通道的历史分会失真Trending 是基于所有历史评测数据按八个维度排名的。它的价值在于长期趋势所以对数据来源的一致性比 Eval 单页更敏感。换通道之前打的分和换通道之后打的分混在一张榜上排出来的名次反映的是通道差异不是 Skill 之间的差异。处理办法不复杂给换通道之后重跑过的 Skill 打个标记或者在团队的记录里留一条时间线注明哪一天开始换的通道。看榜的时候只比较同一条时间线内的分数。历史数据本身不要删它还有用——它就是那次通道切换的现场记录。6. SkillNexus 接通道的报错对照6.1 401Key 没进去或者带上了空格401 基本只和 Key 有关。常见三种复制 Key 的时候尾部多带了一个空格或换行SkillNexus 里同时存了多个供应商配置模型指向了 A 供应商而 Key 填的是 B 的Key 在控制台被删掉或者重建过本地还是旧值。排查顺序先回 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 的控制台确认这把 Key 还在然后重新复制一次粘贴时留意首尾有没有多余字符保存后重启一次 SkillNexus 让配置重新加载。6.2 404Base URL 末尾多写了 /v1这是最常见的一类错。Base URL 填https://taotoken.net/api就够了不需要再补版本路径。有些客户端库会在内部自动追加一次版本段你手填的https://taotoken.net/api/v1会被拼成两段服务端找不到对应路由就返回 404。看起来像「地址不存在」实际是路径重复。判断方法很简单把 Base URL 里的/v1去掉再试一次。如果 404 变成了正常的 401 或者直接成功那就确认是这个问题。6.3 模型不存在模型 ID 抄了别处的旧名字报「model not found」或者类似提示时先别怀疑通道。绝大多数情况是模型 ID 写错了从别的文章里抄了一个带日期后缀的名字或者把展示名当成了调用 ID。正确做法是打开模型广场从当时的列表里挑一个原样复制到 SkillNexus 的模型 ID 字段。如果同一个 Skill 在 Eval 里能跑但装进 Claude Code 后报模型不存在那就去检查~/.claude/settings.json里的ANTHROPIC_MODEL两处填的应该是同一个 ID。7. 对照跑完之后去控制台确认这次调用有没有记上配置保存、TestCase 重跑完、G1 和 S2 的曲线也对照过了最后收个尾回 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 的控制台看一眼这轮评测的调用记录模型 ID 和请求量对得上说明通道这一层已经稳住了后面曲线再动就可以放心往 Skill 和模型换代两个方向归因。想先确认这把 Key 通不通用同一把 Key 去 模型对话页 发一条测试消息最快模型 ID 和 Base URL 有没有配对一条消息就能验出来。Eval 批次跑得密、token 消耗上来之后可以打开 Coding Plan 看看套餐是否够用Key 的增删改查都在 控制台 API Keys。等 Skill 真正落到 Claude Code 里执行时环境变量怎么写对照 Claude Code 接入文档 抄一遍就行。
