DeepSeek V4.1 Flash灰测对比：Godot+Rust框选功能实测

DeepSeek 新模型疑似开启灰度测试。B站 UP 主用真实 Godot + Rust 项目做了一轮对比：同一段提示词，旧版与疑似 V4.1 Flash 的实现质量差距明显。

测试背景：一个接地气的真实项目

这次对比没有用玩具 demo，而是选了一个游戏编辑器场景：在 Godot 引擎配合 Rust 的项目里，实现类似 Blender 的鼠标左键框选功能。提示词很直接——“当前的编辑模式，添加鼠标左键框选功能类似 Blender”。

这类需求对模型的要求不低：既要理解编辑器交互状态机，又要处理“点击选中”与“拖拽框选”两种操作的边界。UP 主用同一段提示词分别跑旧版和疑似 10 月 17 日灰测的 V4.1 Flash，结果差异肉眼可见。

Godot 是一款开源跨平台游戏引擎，支持 GDScript、C# 以及通过 GDExtension 接入的 Rust 等语言。Rust 在游戏工具链中常被用于编写高性能编辑器插件或底层模块，与 Godot 的节点场景系统配合时，需要处理引擎事件循环与 Rust 侧状态管理的桥接。框选（box select）是编辑器类软件的常见交互：按下鼠标记录起点，拖拽超过阈值后绘制选框，释放时选中框内对象；若位移未超阈值则视为点击选中。这种“点击 vs 拖拽”的判定是典型的输入状态机问题，对 AI 编程而言，难点不在语法，而在于准确建模状态迁移与取消逻辑。

旧版实现：点击与拖拽逻辑打架

先看之前的版本。UP 主指出“实现是有问题的”，细看操作过程能发现一个典型 bug：鼠标左键点击时，先选中了物体；拖动后取消这个选中的物体，再进入框选。

这个行为说明模型没有正确区分“点击”和“拖拽”的意图——它把按下鼠标就当成了选中，等到位移超过阈值才回退状态。对用户来说，每次框选都会闪一下选中高亮，体验很割裂。这类状态管理问题恰恰是 AI 编程的常见短板：模型能写出能跑的代码，但交互细节经不起推敲。

V4.1 Flash 灰测版：一次到位

同一段提示词换到疑似 10 月 17 日灰测的 V4.1 Flash，UP 主的评价是“实现得很完美”。虽然原始素材没有逐帧拆解新版代码，但从对比语境看，新版正确处理了点击与拖拽的判定顺序，框选过程不再有误选中的闪烁。

对开发者来说，这个案例的价值在于验证了一件事：模型对“编辑器交互”这类需要状态机思维的任务，理解深度在提升。框选看似简单，背后涉及输入事件分流、拖拽阈值判断、选中集合管理等一串逻辑，能一次写对说明模型对上下文意图的把握更准了。

“灰度测试”指产品在正式发布前，向小范围用户开放新版本以收集反馈的机制。此处“V4.1 Flash”的命名暗示该模型可能属于注重推理速度的 Flash 系列，而版本号 V4.1 则指向 DeepSeek^广告 模型线的迭代。由于官方未确认，社区只能通过实测行为差异来推测版本变化。对开发者而言，灰测版本的价值在于提前观察模型在特定任务上的能力边界，但需注意灰度版本可能随时调整，不应作为生产环境依赖。

对 AI 编程的实际意义

单点测试不能代表全面能力，但 Godot + Rust 这个组合本身有参考价值：它不是主流 Web 栈，训练数据相对稀疏，模型仍能给出可用实现，说明泛化能力在增强。如果你在做游戏工具链或编辑器类开发，这类灰测版本值得关注。

需要提醒的是，目前信息来自单一 UP 主的实测，V4.1 Flash 是否正式发布、具体版本号如何，官方尚无确认。建议把它当作一次有价值的社区信号，而不是定论。

常见问题

V4.1 Flash 是正式版本吗？ 目前仅为 B 站 UP 主发现的疑似灰度测试，官方未公布。

框选功能测试用了什么技术栈？ Godot 引擎配合 Rust，属于游戏编辑器场景。

新旧版本的核心差异在哪？ 旧版点击会先误选中物体再回退，新版正确处理了点击与拖拽的判定。