DeepSeek Harness 的 GitHub 代码仓库中，一个名为 provider.spec.ts 的测试文件出现了三个此前未公开的模型名：deepseek-v5、deepseek-v5-open 和 deepseek-v5-next。它们位于账号登录通路的测试代码中，触发场景是用户登录后，客户端向服务端 /models 接口请求模型清单，再根据清单判断哪些模型可用、哪些需要先更新 DSH 客户端。
这三个名字对应三种不同的发布状态，而不是三款已经上线的模型。
三个模型名分别测试什么
按材料描述，deepseek-v5 没有声明客户端版本要求，但当前版本的内置目录不认识它，所以会被隐藏，调用时返回 MODEL_UNSUPPORTED。deepseek-v5-open 声明的最低客户端版本是 0.0.1，意味着任何版本的客户端都能直接使用，会正常出现在模型列表里。deepseek-v5-next 要求的最低版本是 99.0.0-alpha.1，而目前公开的 DSH 版本还停留在 0.2.x。
99.0.0-alpha.1 显然不是一个正常迭代目标。材料判断，这个版本号的作用是稳定触发“版本不够”的分支，让测试覆盖“当前客户端无法使用新模型”的情况。把它理解成真实版本计划并不准确。
测试文件能说明什么，不能说明什么
这些模型名至少说明，DSH 的模型清单和版本门槛已经具备分级能力：有的模型对所有客户端开放，有的模型要求升级客户端，有的模型在当前目录中不可见。对软件团队来说，这类测试并不罕见。它把上线后可能遇到的兼容性问题提前放进测试用例，避免新模型出现时客户端直接报错或展示错误状态。
但测试文件不等于官方发布公告。模型名可能是占位符，也可能是为未来更新预留的测试数据。材料中提到的网友观点也指出，占位符在软件行业很常见。仅凭 provider.spec.ts 中的一个片段，无法确认 V5 的具体发布时间、能力参数或开放范围。
更值得关注的是发布机制
从工程角度看，三个模型名覆盖了三种典型场景：无需更新客户端即可使用、必须更新客户端才能使用、当前客户端完全不识别。这说明模型上新不只是服务端换一个名字，还涉及客户端版本、模型目录、接口返回和错误提示的配合。
对使用 DSH 或类似客户端的团队来说，这种设计有现实意义。新模型上线时，用户可能停留在不同版本。如果服务端直接返回一个旧客户端不认识的模型，调用会失败；如果模型清单没有版本门槛，用户也可能看到无法使用的选项。测试文件里出现的三种状态，本质上是在验证这些边界。
至于这三个名字是否对应真实的 DeepSeek V5，材料只能提供一个线索：测试代码里出现了 V5 相关命名，并且设计了分级发布分支。它可以被看作发布前的工程准备信号，但不能被当作官方确认。具体模型名称、版本要求和上线时间，仍需以官方发布为准。
对读者而言，更实用的判断是：看到类似“测试文件泄密”的消息时，先区分测试数据、占位符和正式发布信息。测试文件能反映工程思路，却不足以单独支撑产品发布结论。
