千呼万唤 - WWW.YOUINFO.SITE

LinuxDo 最新话题 · 2026-06-04 11:25:32+08:00 · tech

大家吼哇，Kotlin 2.4.0 千呼万唤始出来哇！老规矩，本次更新内容可以在 JetBrains 官方的 What’s new in Kotlin 2.4.0 查阅，我照例挑自己比较感兴趣的一些改动聊聊。剧透首先总结：这次转正的东西不少，新实验特性也挺有意思，尤其是 context parameters 稳定、集合字面量、标准库 UUID 稳定、以及 Kotlin/JS 导出体验继续改进。注意！这次依旧是「我个人」的更新摘要，覆盖不了全部改动；如果你对某个方向特别感兴趣，记得继续深入官方文档喔。文中示例如无特殊说明均来自或改写自官方日志。语言特性一如既往，先来看语言层面的更新。这次比较醒目的有两类：一类是之前几个实验特性终于转正了，另一类是又塞进来了一些新玩具。（嗯…一如既往。）稳定特性首先是几个稳定下来的特性： context parameters 属性上的 @all meta-target use-site annotation targets 的新默认规则显式后备字段 context parameters 稳定这件事着实是特大喜事一件那！毕竟这东西从 context receivers 一路改到 context parameters ，中间变来变去也折腾了不少版本（也让我折腾了半天编译器插件），现在终于算是可以比较放心地在正式代码里试着用起来了。芜湖！不过要注意， context parameters 的「显式 context arguments」和「callable references」还不在这次稳定范围里。也就是说，主干能力稳定了，但边边角角还在继续打磨。 @all 和 use-site annotation targets 的默认规则稳定也挺实用，尤其是你写一些跟 Java 框架互操作的代码时，以前各种 @field: 、 @param: 、 @get: 多个重复的内容写起来还是挺烦的。显式后备字段也稳定了，这个我在 2.3.0 的时候就提过： val city: StateFlow<String> field = MutableStateFlow("") fun updateCity(newCity: String) { city.value = newCity } 以前常见的 _city + city 两个属性组合，在一些场景下可以被简化掉了。好用，爱用。显式 context arguments 书接上文。2.3.20 修改了 context parameters 的重载解析规则之后，如果两个重载只差 context 参数，有些调用会变成歧义。现在 Kotlin 2.4.0 给出了一个新的实验性解法：显式传递 context argument。比如官方给的例子大概是这样： class EmailSender class SmsSender context(emailSender: EmailSender) fun sendNotification() { println("Sent email notification") } context(smsSender: SmsSender) fun sendNotification() { println("Sent SMS notification") } context(defaultEmailSender: EmailSender, defaultSmsSender: SmsSender) fun notifyUser() { sendNotification(emailSender = defaultEmailSender) sendNotification(smsSender = defaultSmsSender) } 这样就可以在调用点明确告诉编译器：我要的就是这个 context 参数对应的重载。我觉得这功能属于“你平时不一定用，但一旦遇到歧义就很救命”的东西。尤其对 DSL 或者库作者来说，这至少比通过改函数名、改参数列表来绕开歧义要优雅不少。语法上来讲，把这东西直接作为具名参数的一员也算符合 context parameters 中的这个 parameters 。目前它还是实验性的，需要添加编译器参数： kotlin { compilerOptions { freeCompilerArgs.add("-Xexplicit-context-arguments") } } 集合字面量哦豁，集合字面量来了！这下代码量又得降上个 30% 了。现在可以用方括号 [] 来创建集合： fun main() { val shapes: MutableList<String> = ["triangle", "square", "circle"] println(shapes) // [triangle, square, circle] } 如果编译器没有足够的类型信息，它会默认推断为 List ： fun main() { val fruit = ["apple", "banana", "cherry"] println(fruit) // [apple, banana, cherry] } 这东西乍一看很像“终于补上了别的语言早就有的语法糖”，但是！Kotlin 的设计里还塞了一个更有意思的点：可以通过 operator fun of 给自定义类型提供字面量构造能力。比如： class DoubleMatrix(vararg val rows: Row) { companion object { operator fun of(vararg rows: Row) = DoubleMatrix(*rows) } class Row(vararg val elements: Double) { companion object { operator fun of(vararg elements: Double) = Row(*elements) } } } 然后就可以这样写： fun main() { val identityMatrix: DoubleMatrix = [ [1.0, 0.0, 0.0], [0.0, 1.0, 0.0], [0.0, 0.0, 1.0], ] } 这就有点意思了。对于矩阵、向量、DSL 配置、甚至一些查询条件构造来说，应该都能玩出花来。能有多少花活儿就…任君想象了~ 不过它目前还是实验性的，而且目前不能用来构造 Java 中定义的集合类型。启用方式如下： kotlin { compilerOptions { freeCompilerArgs.add("-Xcollection-literals") } } 改进编译期常量 Kotlin 2.4.0 还对编译期常量做了一些实验性增强，包括：支持无符号类型操作。支持一些字符串标准库函数，比如 .lowercase() 、 .uppercase() 、 .trim() 。支持计算枚举常量和 KCallable 的 .name 属性。举个感觉上可能会更直观的例子： const val NAME = " Forte ".trim().uppercase() 当然，上面这个只是为了说明用途，具体哪些函数能在编译期求值，还是要以官方支持列表为准。它们还引入了一个 IntrinsicConstEvaluation 注解，用来标记哪些函数可以被编译期求值。有一说一，这些东西真到需要的时候是相当有用的，尤其是无符号类型的常量和字符串常量的函数。这个特性目前也还是实验性的： kotlin { compilerOptions { freeCompilerArgs.add("-XIntrinsic-const-evaluation") } } 改进未使用返回值检查器之前 2.3.0 里提过 -Xreturn-value-checker ，这次又往前推了一步：新增了一个实验性的 returnsResultOf() contract。它的主要作用是帮助检查器分清楚：一个高阶函数返回的结果，到底是不是来自传入的 lambda。比如： import kotlin.contracts.ExperimentalContracts import kotlin.contracts.contract @OptIn(ExperimentalContracts::class) inline fun <T, R> T.customLet(block: (T) -> R): R { contract { returnsResultOf(block) } return block(this) } 这样检查器就可以更准确地判断下面这种情况： fun handleNullablePackageName(packageName: String?, builder: StringBuilder) { packageName?.customLet { builder.append(it) } // 这里返回了一个 String，但结果没被使用，检查器可以报告 warning packageName?.customLet { "kotlin.$it" } } 对于写 DSL 或者工具库的人来说，这个方向其实挺重要的。Kotlin 的表达式和作用域函数太好用了，但也确实容易写出“以为自己返回了，实际上把结果丢了”的代码。虽然这里面有一部分也算是使用者没有仔细了解 API 的锅，但是作为作者，多一些防备和提醒终归是好的。启用参数如下： kotlin { compilerOptions { freeCompilerArgs.add("-Xallow-returns-result-of") } } @IntroducedAt 这个我觉得对库作者很有价值。 Kotlin 2.4.0 新增了实验性的 @IntroducedAt 注解，用来在给已发布 API 添加新的可选参数时，保留二进制兼容性。过去你给一个函数加默认参数，老版本调用方可能就炸了。你要么手写隐藏的兼容 overload，要么上 @JvmOverloads ，但它又可能生成一堆你不一定需要的重载。现在可以这么写： @OptIn(ExperimentalVersionOverloading::class) fun Button( label: String = "", color: Color = DefaultColor, @IntroducedAt("1.1") borderColor: Color = DefaultBorderColor, @IntroducedAt("1.2") borderStyle: Style = DefaultBorderStyle, @IntroducedAt("1.2") borderWidth: Int = 1, onClick: () -> Unit ) { // Function body } 编译器会根据这些版本信息生成对应的隐藏 overload。这对 Compose 风格 API 或者一些公共 DSL 来说应该蛮有用。毕竟这种 API 往往会不断加参数，而且又不想每加一次参数就让用户老版本二进制出问题。兼容性的老大难问题一下子简化了不少，妈妈再也不怕我为了检查 ABI 兼容性而掉光头发了！标准库标准库这次也挺有内容的，其中我比较关注的是 UUID 稳定、排序检查，以及 nullable map 的 fallback API。 UUID API 稳定 Kotlin 2.0.20 引入的 common UUID API 终于稳定啦！之前陆陆续续加过 UUID 解析、格式转换、和 Java UUID 互转之类的能力。到了 2.4.0，除了生成 v4 和 v7 UUID 的那几个函数仍然是实验性的以外，其他大部分 UUID API 都稳定了。这意味着你终于可以在公共 API 里更放心地使用 kotlin.uuid.Uuid 了。好耶，多平台项目里又少一个自己糊类型或者引第三方库的问题。检查是否已排序标准库新增了一组检查集合、数组、序列是否有序的扩展函数： .isSorted() .isSortedDescending() .isSortedWith(comparator) .isSortedBy(selector) .isSortedByDescending(selector) 例如： data class User(val name: String, val age: Int) fun main() { val numbers = listOf(1, 2, 3, 4) println(numbers.isSorted()) // true val users = listOf( User("Alice", 24), User("Bob", 31), User("Charlie", 29), ) println(users.isSortedBy(User::age)) // false } 一个很朴素，但是实用的 API。无符号整数转 BigInteger Kotlin/JVM 现在给 UInt 和 ULong 加了 .toBigInteger() ： fun main() { val unsignedLong = Long.MAX_VALUE.toULong() + 1uL val unsignedInt = UInt.MAX_VALUE println(unsignedLong.toBigInteger()) // 9223372036854775808 println(unsignedInt.toBigInteger()) // 4294967295 } Kotlin: 顺手的事儿。 nullable map 的 fallback API 2.4.0 给 value 可空的 Map 增加了几组实验性的 fallback 函数，用来区分：这个 key 是不存在，还是存在但值就是 null 。新增的函数主要有： .getOrElseIfNull(key, defaultValue) / .getOrPutIfNull(key, defaultValue) .getOrElseIfMissing(key, defaultValue) / .getOrPutIfMissing(key, defaultValue) 来看区别： @OptIn(ExperimentalStdlibApi::class) fun main() { val mapForNull = mutableMapOf<String, String?>("user" to null) val mapForMissing = mutableMapOf<String, String?>("user" to null) mapForNull.getOrPutIfNull("user") { "default_user" } println(mapForNull) // {user=default_user} mapForMissing.getOrPutIfMissing("user") { "default_user" } println(mapForMissing) // {user=null} } 这对缓存场景尤其有用。比如你缓存一个查询结果，而“查到了，但是结果为空”本身也是一个有效缓存，那你就不希望下次又重新查一遍。 @OptIn(ExperimentalStdlibApi::class) fun getCachedResponseOrQuery(key: String): Response? = cache.getOrPutIfMissing(key) { service.query(key) } 以前这种语义经常要自己写 containsKey 判断，现在标准库终于给了更明确的 API。 NULL safe 语言一定要对 NULL 的处理精准而全面！ Kotlin/JVM JVM 这边这次内容不算多，但是有两个点。支持 Java 26 Kotlin 2.4.0 开始支持生成 Java 26 字节码。我现在主要还是稳定在用 Java21/25，对于非 LTS 版本还是涉猎比较少。 metadata 中默认写入注解 Kotlin 2.2.0 的时候，Kotlin Metadata JVM library 支持读取 metadata 中的注解。到了 2.4.0，这个支持默认开启了。也就是说，编译器会把注解信息写入 Kotlin metadata，注解处理器和其他工具可以在 metadata 层面读取这些内容，而不必依赖反射或者源代码。这对框架、代码生成、静态分析工具来说应该很有用。我猜未来很多 Kotlin 原生工具链都会逐渐更依赖 metadata，而不是硬往 Java 反射模型里塞。 Kotlin/Native Native 这次依旧是工程向、Apple 向、Swift 互操作向的更新。我对这块不算熟，所以主要挑几个我看得懂（或者至少能假装看得懂）的点。 CMS GC 默认启用 Kotlin/Native 的 concurrent mark and sweep garbage collector，也就是 CMS GC，现在默认启用了。过去默认的 PMCS 在标记阶段需要暂停应用线程，而 CMS 可以让标记阶段和应用线程并发执行。官方说这会显著改善 GC pause 和应用响应性，尤其对 Compose Multiplatform 这类 UI 应用有帮助。如果遇到问题，也可以在 gradle.properties 里切回旧模式： kotlin.native.binary.gc=pmcs GC 也是一个需要长期演进的艰难课题哇。 Swift export 进入 Alpha Swift export 终于进入 Alpha 了，而且这次重点改善了并发支持。现在 Kotlin 的 suspend 函数可以更自然地导出成 Swift 的 async ： suspend fun hello(): String { delay(1000) return "Hello Swift! This is Kotlin." } Swift 侧： let msg = try await hello() 另外， kotlinx.coroutines.flow.Flow 也可以导出成 Swift 的 AsyncSequence 。这点我觉得挺关键的，因为移动端跨平台里，异步流式数据几乎绕不开。还记得上次对 .d.ts 的导出支持 suspend 吗？这次 swift 也享受到了。 Swift package import KMP 项目现在可以在 Gradle 配置里声明 Swift Package 作为 iOS app 的依赖： kotlin { swiftPMDependencies { swiftPackage( url = url("https://github.com/firebase/firebase-ios-sdk.git"), version = from("12.11.0"), products = listOf( product("FirebaseAI"), product("FirebaseAnalytics"), ) ) } } 如果你以前用 CocoaPods，官方也提供了迁移到 SwiftPM 的文档和工具支持。这类更新就很明显了：KMP 在 iOS 生态里继续往“别那么别扭”的方向推进。 Apple 目标支持变化 Kotlin 2.4.0 提升了 Apple 目标的默认最低支持版本： iOS / tvOS 从 14.0 提升到 15.0 macOS 从 11.0 提升到 12.0 watchOS 从 7.0 提升到 8.0 如果你需要支持更低版本，可以通过编译器参数覆盖。时代在前进，老设备在落泪。我的 intel mac 还能战斗到什么时候？ Kotlin/Wasm Wasm 这次我觉得有两个重点：增量编译默认启用，以及 WebAssembly Component Model 的实验性支持。增量编译默认启用 Kotlin/Wasm 的增量编译从 2.1.0 开始引入，到 2.4.0 稳定并默认启用。这意味着修改代码后，编译器只需要重编受影响的文件，构建速度会更友好一些。如果遇到问题，可以关闭： kotlin.incremental.wasm=false K/Wasm 现在最大的问题之一就是开发体验还需要继续打磨，增量编译默认开肯定是好事。支持 WebAssembly Component Model Kotlin/Wasm 现在实验性支持 WebAssembly Component Model。简单来说，它定义了一套用标准接口和类型组合 Wasm 组件的方式，让 Wasm 不只是一个低层二进制格式，而是更像一个可以跨语言复用和组合的组件系统。这也意味着 Kotlin/Wasm 不只是“跑在浏览器里”，还可以更自然地探索 serverless、FaaS 之类的场景。官方还给了一个 wasi:http 的示例项目。这个方向我挺期待，虽然目前对大多数业务项目来说还偏早。有机会找个小项目体验一把。 Kotlin/JS Kotlin/JS 这次继续围绕 JavaScript / TypeScript 导出体验做改进。说实话，这几次更新下来， K/JS 的互操作正在一点点从“能用”往“像个正经 TS 生态公民”靠近。当然，能靠多近就要看 jb 有多努力了。支持导出 value class 之前只有普通 Kotlin 类能导出到 JavaScript / TypeScript。现在 Kotlin 2.4.0 支持导出 inline value class 了。例如： @JsExport @JvmInline value class Email(val address: String) { init { require(address.contains("@")) { "Invalid email" } } } @JsExport class AuthService { suspend fun login(email: Email): String = TODO() } TS 侧会像普通类一样使用： import { AuthService, Email } from "..." const auth = new AuthService() console.log(await auth.login(new Email("[email protected]"))) value class 本来就是 Kotlin 里很适合做强类型包装的东西，如果导出到 TS 时不能保留这种模型，就会很影响 API 设计。不赖！ inline JS 支持 ES2015 Kotlin 2.4.0 的 js() 内联代码现在完整支持 ES2015 特性，比如： const / let class generator arrow function spread / rest operator template string 比如： fun spreadExample(): dynamic = js(""" const add = (a, b, c) => a + b + c; const nums = [1, 2, 3]; const sum = add(...nums); return { sum }; """) 这个对需要跟第三方 JS 库做细颗粒度互操作的人来说，还是挺舒服的。毕竟 2026 年了，在内联 JS 里还不能好好写现代 JS 确实有点说不过去。不过我本人在 js(“…”) 里写大段 JS 片段的情况还算比较少，所以之前也没怎么体会到问题所在。导出 TypeScript 时保留型变以前 Kotlin 泛型里的 in / out 信息导出到 TypeScript 时会丢掉。现在它会被保留并映射到 TypeScript 的 variance annotations。例如 Kotlin： interface Producer<out T> { fun produce(): T } interface Consumer<in T> { fun consume(item: T) } 生成的 .d.ts 会保留： export interface Producer<out T> { produce(): T; } export interface Consumer<in T> { consume(item: T): void; } 类型系统信息少丢一点，互操作就少一点坑。改进接口导出新的 @JsNoRuntime 注解可以让 Kotlin 接口导出成更普通的 TypeScript interface，不再携带之前那些为了 Kotlin runtime 识别接口所需的 metadata。例如： import kotlin.js.JsNoRuntime @JsNoRuntime expect interface DataProcessor { fun process(data: String): Int } 生成出来就是： export interface DataProcessor { process(data: string): void; } 当然代价也很明确：标记了 @JsNoRuntime 之后，就不能再对这个接口做 is / as 检查、 ::class 引用，也不能作为 reified 类型参数传来传去。这就是一个取舍：如果你想要更像 TypeScript 原生接口，那就别指望它还保留 Kotlin runtime 的那些能力。另外，这次还放宽了 @JsExport 导出接口的限制，现在可以导出带嵌套类和命名伴生对象的接口了。 Gradle & Maven 构建工具这块简单看一下。什么，还有 Maven 的事儿？ Gradle 方面，Kotlin 2.4.0 兼容 Gradle 7.6.3 到 9.5.0 ，最低支持的 Android Gradle Plugin 提升到了 8.5.2 。另外，默认 module name 在各平台之间统一为 {group}:{project_name} ，减少跨平台命名不一致带来的冲突。如果你想回到旧的 JVM module name，可以手动配置： kotlin { compilerOptions.moduleName(project.name) } Maven 方面，这次做了两个比较实用的改进： Kotlin Maven 插件可以自动对齐 Java compiler version 和 Kotlin JVM target。支持 Maven Toolchains，用来统一控制 Kotlin 编译使用的 JDK。虽然我个人还是选择 Gradle，但 Maven 用户看到这个应该会舒服不少。编译器、插件和 Compose klib 编译时同模块 inline 行为更一致 Kotlin/Native、Kotlin/JS、Kotlin/Wasm 现在在生成 .klib 时，会默认对同模块内的 inline 函数进行 inline。这一步是在向 JVM 的行为靠拢，让不同平台对 inline 的兼容性保证更一致。如果遇到问题，可以用： -Xklib-ir-inliner=disabled 未来还计划继续推进跨模块 inline。 OS: 什么，原来之前不会 inline 的吗？ kapt 可以排除 compile classpath 上的注解处理器 kapt 现在支持 includeCompileClasspath 配置，可以排除不必要的 annotation processor discovery。 Maven 里可以这样配： <properties> <kapt.include.compile.classpath>false</kapt.include.compile.classpath> </properties> Power-assert 新 runtime library Power-assert 这次引入了新的 runtime library。新的 @PowerAssert 注解可以让断言函数更容易被编译器插件发现， CallExplanation 也能提供更详细的调用点信息。如果你喜欢写测试，或者想给自己的断言库接入 Power-assert，这个方向值得关注。但是我用的不多，就不过多评价了。 Compose 编译器 Compose compiler 这次主要是让 internal declaration 的增量编译更一致。不过副作用是：当 @Composable 函数使用来自其他文件的 internal 类型作为参数时，产物体积可能会变大。官方说 R8 这类全程序优化工具可以消掉这部分额外开销。此外，一些已经稳定或准备淘汰的 feature flag 也进入新的弃用阶段： StrongSkipping 、 IntrinsicRemember 相关 DSL 提升到 DeprecationLevel.ERROR ，计划 2.5.0 移除。 OptimizeNonSkippingGroups 、 PausableComposition 已弃用，计划 2.6.0 移除。破坏性变更和弃用这次有几个需要注意的兼容性点： Kotlin 2.4.0 不再支持 -language-version=1.9 ，也就是说 K1 编译器正式不再支持。（我的编译器插件终于不用再继续兼容旧编译器了） Kotlin Gradle Plugin 的 binary compatibility validation DSL 做了精简并弃用了一些旧配置。 Maven 插件里的 KotlinScriptMojo 脚本执行支持被移除了。如果你的项目还卡在比较老的语言版本，或者构建脚本里有一堆祖传 Kotlin 配置，这次升级前最好扫一眼官方 compatibility guide。其他官方这次还更新了一堆文档，比如 KMP、SwiftPM 迁移、Compose Multiplatform、Ktor、KSP、Lincheck、Kotlin LSP 等内容。如果你最近正好在折腾这些生态工具，不妨顺手去翻翻。文档，多多益善！尾声这次 Kotlin 2.4.0 给我的感觉是：语言层面继续补语法糖和工具能力，多平台方向继续推进工程化和互操作体验。 context parameters 稳定和集合字面量我是已经期待了很久了，这次也是相当满足。而那个用于兼容性的 @IntroducedAt 则是一个意外之喜，真是令我欢喜！这个要是能支持到 data class 上就更好了，抽空得狠狠体验一把了。你呢？这次 2.4.0 里有没有哪个新玩意儿让你眼前一亮？ 2 个帖子 - 2 位参与者阅读完整话题

GPT-4o又回到了网页端了

LinuxDo 最新话题 · 2026-05-08 16:59:36+08:00 · tech

今天在网页端突然看到这个，不知道算不算新闻了。GPT这个是千呼万唤，又出来么…… 问了一下gpt，说是 Alpha models（实验模型）子菜单。应该是做定时任务的。奇怪的设定。佬友们看到了么？ 3 个帖子 - 3 位参与者阅读完整话题

DeepSeek V4 非专业解读

linux.do · 2026-04-26 16:07:33+08:00 · tech

从 DeepSeek V4 个人技术前瞻继续讨论：终于经过望眼欲穿的等待，DeepSeek-V4千呼万唤始出来，发布以后，回看此前的前瞻，还是有些出入，最期待的也最需要修正的部分是对Engram的预期。从V4技术报告来看，也许笔者的预期过于乐观，在这一代中暂时没有条件落地应用。不过条件记忆、知识检索解耦、模型内部稀疏访问等问题仍然值得长期跟踪，也许在DeepSeek V4.5出现也未可知。回到正题，本次V4的主线围绕百万Context，并降低了训练和推理的综合成本，实实在在的体现了报告标题 Towards Highly Efficient Million-Token Context Intelligence 。具体参数不再赘述，报告的开篇图片就提到了在 1M context 下，V4-Pro 相比 V3.2 只需要 27% 的单Token推理FLOPs和10%的KV cache；V4-Flash 则降至 10% FLOPs 和 7% KV cache。在笔者看来，推理性价比比窗口长度本身更重要。长上下文能力的价值不只取决于最大输入长度，还取决于长输入下的单位任务成本。如此一来，交给Agent做的低难度长历程任务例如代码仓库理解、跨文档分析、多轮搜索、工具调用等，V4使得这些场景在经济上可承受。值得一提的是，本次的发布仍然体现了DeepSeek在模型架构方面的探索和实践，V4的核心架构升级中值得一提的就是CSA/HCA混合注意力。与V3时代以来，业界祖宗之法不可变的DSA（NSA)相比，V4设计了这两种注意力机制交错使用，并加入滑窗注意力保留近期局部依赖。基本思路是把长上下文的信息访问拆开处理。远距离信息通过 HCA 的极致压缩保留全局视野，可能相关的信息通过 CSA 的稀疏选取召回，近期信息通过滑窗保持更高分辨率。这样的混合架构相比于DSA等稀疏注意力机制，等于在模型里嵌入了一个微型多级搜索引擎，对Tokens 的压缩/分块/语义化/分层检索/共享缓存做得非常精细，虽然代价是精度上的取舍。至于架构方面，DeepSeek的看家绝活mHC已经在前瞻中提到不再赘述。尽管本次V4-Pro的预训练规模达到33T tokens、和1.6T总参数，mHC的工程开销仅为overlapped 1F1B pipeline stage 的 6.7%。另外不出意外地是 Muon 优化器在多数模块上取代了 AdamW，作为目前业界的主流趋势的优化器倒也合理。但是由于使用了新的混合注意力机制，并且巨大的参数量，在这次训练过程中V4也遇到了 loss spike 问题，DeepSeek报告中说用了两个奇技淫巧但其理论机制尚未完全理解，选择公开分享以供社区研究。（笔者看不懂这俩技巧没法分析）在Agent时代，模型的后训练变得越来越重要，而本次的V4在后训练方面笔者认为也是非常精彩的，他们把后训练也分为多个阶段，首先是专家训练，这个和V3时代是一致的，但是没有使用GRPO而是跟进了业界的OPD策略；其次是对难验证任务使用了生成式的奖励模型来评估策略；工具调用方面，V4使用了自构建的DSL格式，减少了逃逸风险和工具调用报错，但是也导致首发后出现Skill不调用以及tool call表现差的问题，换用其对应的parser是可以解决的不知道后续会不会在后训练中加上这一部分的映射纠正。此外，本次报告用了相当篇幅描述Agent所需的工程基础设施，为后训练和评估建立了一个数十万并发的沙盒平台以至于被夸赞是业界最强的infra团队。至于硬件方面，很可惜本次还是没有使用国产平台进行训练，希望推理阶段能够加大国产卡应用进一步降低API价格。评测方面社区已经有大量的帖子，基本上是在开源模型中的第一梯队但是离闭源的Opus4.7/GPT5.4 还是有一定距离。在报告中，DeepSeek的内部问卷调查“你愿不愿意把V4当成你日常的首选编程模型”，85人的回答是52%愿意/39%倾向于愿意/9%不愿意。这个反馈也是比较真诚的。不过目前体验下来，Pro 在推理模式下速度偏慢，且开销为同类模型的两到三倍，其实这一点在之前的V3时代已经有体现了，尤其是昙花一现的exp试验版本就是力大砖飞的思路；至于创意写作和非推理任务上笔者认为是略有不足的，虽然有人提到V4-Pro破限任务表现出色，但是笔者认为其创意性受推理能力训练的影响有所失色。相较而言，笔者认为v4-flash是一个不错的干活模型。回看前瞻中的各项判断。mHC确实不出意外, 且长上下文与 Agent系统栈的方向判断基本成立，多模态方面未来可期（打脸了笔者的前瞻，也许是作为一家更偏研究性机构不可避免的训练数据量问题），而最为期待的Engram仍在路上。总的来说，作为一款大家期待已久的国产之光，DeepSeek这次的表现可圈可点，虽然性能还做不到脚踢A 拳打奥特曼，但是成本上确实是非常出色。毕竟百万上下文输入1块钱要什么自行车（PRO也只要3块钱了，恐怖最后笔者非常喜欢DeepSeek的态度，「不诱于誉，不恐于诽，率道而行，端然正己。」作为一个在L站从V2时期折腾Cocopilot + DeepSeek FIM替代copilot的老用户，真心希望他们可以向实现 AGI 的目标不断靠近。 3 个帖子 - 2 位参与者阅读完整话题

就是今天了。

linux.do · 2026-04-24 11:37:46+08:00 · tech

天下苦gpt/claude/gemini久矣。deepseekV4，千呼万唤始出来。 1 个帖子 - 1 位参与者阅读完整话题

千呼万唤始出来

linux.do · 2026-04-24 11:10:35+08:00 · tech

还是那个最强最便宜的DeepSeek，鲸鱼v4终于来了！神你会拯救我吗 1 个帖子 - 1 位参与者阅读完整话题

/tag/千呼万唤