11-02 版本复核：Qwen Code v0.26.5 是本轮唯一新 stable，五家无变化

要点

• 本轮唯一的新 stable 是 Qwen Code v0.26.5（tag 时间戳 2026-11-01T03:22:50Z，prerelease: false），接替 10-29 的 v0.26.4。官方 Breaking Changes 一节写明「No known breaking changes」（沿用本站判据：照抄原文措辞，并提醒这是「未见已知」而非「没有」）。
• 同日另有 desktop-v0.26.5（2026-11-01T03:59:58Z，prerelease: false）与 cua-driver-rs-v0.27.0（2026-10-30T06:32:17Z，prerelease: true）。
• 本版真正的「默认值迁移」是 Generated UI 默认开启："Enables Generated UI by default and lets users continue chatting with interactive card values attached as removable context above the composer." 配置不用改，行为照样变。
• /autofix-pr 新增重试预算："Adds a retry budget to /autofix-pr so a check left failing after three fix pushes is handed to a human and shown in /autofix-pr status." —— 三次修复推送后仍在失败的检查，交给人。
• 其余五家连续多轮无新 stable：Claude Code v2.1.316、Codex rust-v0.166.0、Gemini CLI v0.66.0、Ollama v0.40.13、OpenCode 1.x v1.19.5 / 2.x v2.2.5。
• Kimi Code CLI 已推进到 @moonshot-ai/kimi-code@2.4.1（2026-10-30T09:50:16Z，prerelease: false），此前本站记录为 2.3.1。

七条版本线当前位置（2026-11-02 逐 tag 核对）

Gemini CLI 的 v0.67.0 仍未转正：本站用 /releases/tags/v0.67.0 核对，返回 404；/tags 上只有 v0.67.0-preview.0 与一串 nightly。这是本站第七次确认该状态——「有 tag、有 nightly、没有 Release」不等于已发布，判 stable 必须读 Release 的 prerelease 字段。

背景与分析

Qwen Code v0.26.5：两个「默认值 / 判定」层面的变更

这一版 Features 列了二十多条，但真正需要单独拎出来的只有两条，而且都不是新功能：

其一，Generated UI 默认开启。 原文还说明了新交互：卡片里的值会作为可移除的上下文挂在 composer 上方，用户可以直接带着它继续聊。这条对既有工作流的含义是——你没改配置，但 UI 行为变了；更重要的是「可移除的上下文」这个概念：会话里现在可能多出一块你没显式写入、但会参与后续轮次的上下文。做上下文审计（/context、memory 相关）时要把这块算进去。

其二，/autofix-pr 的重试预算。 这是本站近期反复命中的同一类模式：官方在改变「什么算完成、什么该停下」的判定。以前的隐含假设是「修到绿为止」，现在明确是三次推送后仍在失败就交给人，并在 /autofix-pr status 里显示。同一个 PR 的自动化流水线，行为从「可能无限重试」变成「三次后停止并标记」。本站未取得该预算是否可配置的一手说明，列为待核实。

另有一条与 PR 工作流相关：/verify-pr 的本地流程只在当前工作树是 PR head 的干净检出时才复用它，否则重新准备（"reuses the current working tree only when it is a clean checkout of the PR head"）。用脏工作树跑 /verify-pr 的人，升级后会多一次准备步骤。

「五家无新 stable」本身就是信号

本站已连续多轮记录到六家 CLI 的 stable 版本不动。这次七条线里只有一条动了。两种解释都可能，本站不替任何一方定性：

• 一种是收敛——各家在这轮周期里把精力放在护栏（写入边界、策略分层、权限拆分）而不是功能扩张上，小步修 Bug 不值得发 stable；
• 一种是节奏差异——Qwen Code 的 v0.26.x 是高频小版本线（10-24 至 11-01 八天内 0.26.1 → 0.26.5 五个版本），与其它家的节奏天然不同。

不要从「没发版」推出「没变化」。反例就在本期：Claude Code 停在 v2.1.316，但同期发生了 Cursor 扩展市场投毒事件——版本号没动，安全状态变了。

把「版本号真伪」做成日常动作

上一条正好接上这次的判据沉淀。本站 10-29 起因 OpenCode 2.x 事件定下的规矩是「判断某条大版本线是否存在，必须同时看 /releases 与 /tags」。这次的事件补上了另一半用途：

• v2.1.312 官方有、市场里的同名包是脏的 → 版本号真实不等于包干净；
• v2.1.313 官方根本没有（/releases/tags/v2.1.313 返回 404）→ 市场里出现一个官方不存在的版本号，本身就是异常信号。

所以核对动作应该是两步：先查这个版本号官方有没有发过（404 判定），再比内容哈希（官方公告给的 SHA-256）。第一步几乎零成本，能挡掉一整类。

行动建议

1. 用 Qwen Code 的：生产可改钉 v0.26.5。升级后先看两处——① Generated UI 默认开启后 composer 上方的上下文卡片；② 依赖 /autofix-pr 的流水线，确认「三次后交给人」的新行为与你的机器人账号权限是否匹配。
2. 用 Gemini CLI 的：继续钉 v0.66.0。别被 nightly 的版本号带跑——v0.67.0-nightly.* 数字更大但不保证稳定，v0.67.0 的 Release 还不存在。
3. 用 Cursor 扩展市场装 Claude Code 的：版本不是这件事的重点，先按 投毒事件资讯 跑自查命令。
4. 所有人：把「查 /releases/tags/<tag> 是否 404」加进升级前的例行核对。

待核实

• /autofix-pr 的重试预算是否可配置（"three fix pushes" 是硬编码还是默认值）：官方 Release Notes 未说明。
• Generated UI 默认开启后，卡片上下文的移除方式 / 是否参与 /context 统计：官方原文只说「可移除」，未展开。
• cua-driver-rs-v0.27.0 的用途：自 10-21 起一直为 prerelease，官方未说明，本站继续不作断言。
• Codex rust-v0.167.0-alpha.2 的变更内容：alpha 线未转正，本站不对其内容作断言。
• Kimi Code 2.4.0 → 2.4.1 的变更内容：本站本次只核对到 tag 时间戳与 prerelease，未取 Release Notes 正文。

相关

• Qwen Code 工具卡
• Claude Code 工具卡
• Gemini CLI 工具卡
• OpenCode 工具卡——双版本线并存时的取版本判据
• 2026-10-29 版本复核资讯

AI 之家 观点

这一轮最值得说的不是「谁发了新版」，而是**「版本号没动」和「安全状态变了」可以同时发生**。

本站这几个月一直在强调读 Changed / Deprecated / Bug Fixes 里的行为变更，方向是纵向的——同一个工具，升级后行为怎么变。Cursor 投毒事件把这个视角补成了横向的：版本号完全没变，你装的却可能不是官方那份。纵向靠读 Release Notes，横向靠查版本号真伪 + 比哈希，两者缺一不可。

还有一个更朴素的建议：别把「自动更新」当成免费的便利。它同时是补丁通道和投毒通道，区别只在于来源可不可信。团队环境里值得为「允许哪些来源」单独画一条线，而不是简单地开或关。