基于环境变量的 claude code /codex 中转站切换（开源）

作者: 纯情
时间: 2026-01-06
分类: 开源
评论

一个轻量的 CLI，用于在 Claude Code 与 Codex 的环境变量之间快速切换。功能比较简单，适合轻度使用。

快速开始

安装：

npm install -g @praeviso/code-env-switch

交互式添加 profile（若不存在会创建 ~/.config/code-env/config.json）：

codenv add
# 再执行一次，用来添加另一种 type
codenv add

交互示例：

$ codenv add
Select type (1=codex, 2=claude): 1
Profile name (default: default): primary
Base URL (required): https://api.example.com/v1
API key (required): YOUR_API_KEY

按 type 设置默认项：

codenv default codex primary
codenv default claude default

启用自动应用：

codenv init
新开终端（或执行 `source ~/.bashrc` / `source ~/.zshrc`）即可自动应用默认配置。

交互式选择：

codenv use 或者 codenv use claude mirror

不会永久污染环境变量，原理是每次 bash 启动的时候自动执行脚本 export 对应的环境变量。

测试下来，切换 claude 的时候会显示上一个 proflie 的 api key，但是实际上是已经切换过来了，可以用 status 查看。

此外不知道是否会和原有的 cc/codex 的 config 文件里面的 apikey 冲突，我还没有测试。

📌 转载信息

来源：
https://linux.do/t/topic/1410346

转载时间：
2026/1/6 11:57:35

3 分钟搞定 API 免费用 GLM-4.7 和 MiniMax M2.1

作者: 纯情
时间: 2026-01-06
分类: 网络
评论

英伟达 NIM 开发者平台两个最近很火的国产模型 GLM-4.7 和 MiniMax M2.1，下面教大家手把手免费薅 API

1、打开 build.nvidia.com 点击右上角的 login，输入邮箱地址，点击 Next

2、自动跳转到创建 nvidia 账户页面，创建账户

3、邮箱会收到一个 6 位验证码，填进去。在 nvidia cloud 界面，随便输入一个用户名，进行下一步

4、页面右上角会出现一个 Verify，点击出现验证手机号界面，location 选择 china，phone number 填写 86 1xxxxx (自己手机号)。注意一定要先填手机号，再选择国家，要不然下方的 sendcode 按钮为灰色不可点击

5、验证通过后，获取 api key。登录后，点右上角头像 → API Keys。

找到 Generate API Key。给 Key 起个名字，过期时间可以调成 Never Expire，得到的 key 为 “nvapi-” 开头的字符串。复制保存！这个 Key，能调用 NIM 上所有免费模型。

6、API 地址，填入 https://integrate.api.nvidia.com/v1。

API 密钥，就是上面生成的 API Key。

模型，推荐 z-ai/glm4.7、minimaxai/minimax-m2.1 和 moonshotai/kimi-k2-thinking

📌 转载信息

来源：
https://linux.do/t/topic/1410507

原作者：
user1881

转载时间：
2026/1/6 11:42:04

新年接财神！给大家拜个早年！附带新年壁纸 + 提示词！

作者: 纯情
时间: 2026-01-06
分类: 生活
评论

提示词如下

马年发财手机壁纸设计。主色调为喜庆的红色和金色，背景采用传统的中国风花纹，呈现浓烈的节庆气氛。画面主体为一匹神气十足的骏马，正面视角，马头昂起，眼神坚定，展示出强烈的力量感和速度感。马身的线条圆润流畅，结合中国传统的剪纸风格，形成鲜明的对比，体现出浓厚的中国文化底蕴。马儿背后有金色祥云和锦缎飞舞，象征着财富和吉祥。金色局部点缀，给人一种如同福气降临的感觉，仿佛迎接着新一年的好运。画面左上角以大号书法字体写着“2026”，右下角用小号的手写体“新春快乐”两字，均为亮眼的金色，传递着浓浓的春节气氛。整体风格热烈、吉祥、喜庆，非常适合春节期间的手机壁纸，充满了年味和祝福。```

📌 转载信息

来源：
https://linux.do/t/topic/1410521

原作者：
LinuxKurt

转载时间：
2026/1/6 11:41:42

渗透测试资产搜集

渗透的本质就是信息收集，目的是尽可能全面的描绘目标资产的全貌，包括所有域名、子域名、IP 地址、开放端口及关联的公司信息，为后续漏洞探测提供基础。

域名及子域名搜集（深度和广度）

拿 baidu.com 举例，我们的目的是找到所有和目标主域名关联的二级，三级甚至四级域名:www.baidu.com,one.two.baidu.com 等

被动查询（利用公共数据库）

常用的在线查询网站

我个人常用 crt.sh

特点：这是最老牌、最著名、也是最常用的 CT 日志搜索引擎之一。它汇总了来自多个 CT 日志的数据，查询结果非常全面。
用法：输入域名，例如 %baidu.com （使用百分号 % 可以进行通配符搜索，以匹配所有子域名）

自动化工具

个人常用的

OneForAll
特点：一个功能强大的综合子域名收集工具，它内置了对 crt.sh 、Censys 等多个 CT 日志源的查询模块。

还有些常见的空间搜索引擎:fofa,shodan,censys。常用的为 fofa`，作为国内最老牌的空间搜索引擎，FOFA 的主要优势在于对中文和国内资产的覆盖度高，支持多维度搜索。

主动探测

子域名爆破

关键要素：高质量字典

在没经过目标产商的允许擅自爆破属于违法行为！此教程仅作学习分享交流！

暴力破解的成败很大程度上取决于使用的字典（Wordlist）。渗透测试人员通常会使用的字典包括：

通用字典 (General Wordlists)：如 SecLists 中的 DNS 目录，包含常见的 mail , dev , test ,api , admin , vpn 等。
企业定制字典：结合目标公司业务、员工姓名、产品名称、城市名称等自定义生成的字典。
大型综合字典：通过爬虫、CT 日志、公共数据等方式汇集的大型子域名列表。

顶级域名的收集

除了常见的子域名收集姿势，还有顶级域名的收集，例如像 google，星巴克这样的大厂，它们的资产遍布全球，也就是说它有可能并不会告诉你一个确切的域名范围。

被动收集

搜索域名购买（任意一个都行），这里拿 google 举例

发现以下都被注册，再对这些域名进行子域名收集，这样的你的攻击面就比先前广了许多。

代码与页面信息泄露

这一阶段的目标是深入分析目标网站的代码和公开配置，以发现隐藏的 API 端点、敏感文件、内部注释和不应公开的路径。

前端代码分析

现代 Web 应用大量依赖前端 JavaScript (JS) 代码与后端 API 通信。JS 文件中经常硬编码或逻辑性地包含大量敏感信息。
核心关注点：

API 接口路径：发现所有前端调用的 API 端点，例如 /api/v1/user/info 。
敏感字符串：搜索 token 、 secret 、 key 、 password 、 admin 等关键词。
子域名 / 内部域名：JS 文件中可能硬编码了开发环境或测试环境的域名（如 dev.corp.com ），或
调用的第三方服务域名。
云服务凭证：寻找 AWS S3 bucket 名称、Google Cloud 或 Azure 存储服务的 URL 等。
API 接口路径：发现所有前端调用的 API 端点，例如 /api/v1/user/info 。
敏感字符串：搜索 token 、 secret 、 key 、 password 、 admin 等关键词。
子域名 / 内部域名：JS 文件中可能硬编码了开发环境或测试环境的域名（如 dev.corp.com ），或
调用的第三方服务域名。
云服务凭证：寻找 AWS S3 bucket 名称、Google Cloud 或 Azure 存储服务的 URL 等。

公开文件和配置检查

部分系统默认或管理员疏忽，会导致一些重要的配置或文件被公开访问。
核心检查清单：

Dirb / Dirbuster / Gobuster：这些目录爆破工具的字典中通常会包含上述常见的敏感配置文件路径，能够批量扫描并检测这些文件的存在性。
手动浏览器访问：直接在目标域名后拼接 /robots.txt 和 /sitemap.xml 进行检查。

笔记写的有点潦草，希望各位佬友担待一下，如果该笔记有什么问题或者什么可以优化的地方，希望佬能在下面回复，我会认真看的

📌 转载信息

来源：
https://linux.do/t/topic/1410522

原作者：
useruy

转载时间：
2026/1/6 11:41:29

分享一个带语法解析的翻译提示词

作者: 纯情
时间: 2026-01-06
分类: 网络
评论

可以将输入的中文或者英文，转换为更地道的语言表达，并且纠正其中的语法错误，我觉得效果还蛮好的，在英文社区交流的时候可以自己手敲英语然后丢给 ai 检查一遍，熟悉语法更快速

提示词

作为一位 local-dialect 粗鲁老编辑和熟练的中英文编辑、资深作家和翻译家，你的任务是按照以下规则进行翻译：

任务：

首先直译英文
最后译成地道美式英语
需要输出原文和译文
如果给你的是英文就翻译成中文
纠正语法错误，给出解释 原则：
请确保翻译准确无误，符合语境并保持流畅自然的语言表达
你需要展现出对中英文的熟练掌握以及地道美式英语的语言风格

📌 转载信息

来源：
https://linux.do/t/topic/1410526

原作者：
FFattiger

转载时间：
2026/1/6 11:41:06

分享一个自用的 ai studio prompt，效果还行

作者: 纯情
时间: 2026-01-06
分类: 网络
评论

写代码搭配 Gemini 2.5 Pro 模型使用效果更好（哈基米 3 有点降智）

你是一个高级开发协调者（Development Coordinator），负责通过结构化思考和多代理模拟协作，生成高质量、可直接落地的代码，实现用户请求的新功能或特性。

### 关键强制规则（最高优先级，绝对必须严格遵守！）
- 所有回复必须使用中文。
- 回复必须严格遵守以下Markdown标题格式，不得多不少，不得更改标题名称或顺序。
- 禁止输出任何额外解释、问候或非格式内容，直接开始格式输出。
- 禁止在格式外添加英文或其他语言内容。
- 在 Code Implementation 部分，绝对不允许省略任何代码，也必须确保每个代码块完整包裹。
  - 每个文件必须提供完整、可直接运行的代码内容。
  - 禁止使用 “...” 或 “省略部分代码” 的方式。
  - 每个代码块必须以 ```typescript
  - 每个代码块必须以单独一行的 ``` 结束，不允许缺少闭合标记。
  - 即使文件很长，也必须完整输出并确保代码块正确闭合。
  - 如果内容极长导致响应可能截断，优先拆分成多个独立文件输出，但每个代码块仍需完整包裹。
  - 修改现有文件时，必须提供该文件的完整最新版本代码，并在修改处添加注释说明。

### 用户请求的功能描述
用户会以消息形式提供功能描述（例如：实现XXX功能）。

### 项目上下文注意事项
- 在生成代码时，假设基于常见现代项目风格（干净、可维护、类型安全）。
- 严格遵守良好实践：命名规范、错误处理、模块化、依赖最小化。
- 如果用户提供额外上下文或现有代码，请严格遵循并完整融入。

### 你的思考流程（内部多代理模拟协作）
在回复前，必须内部模拟以下四个专业代理逐步协作：
1. **Architect Agent**：高层次设计，包括API合约、数据模型、模块划分、技术选型。
2. **Implementation Engineer**：编写核心代码，确保干净、可维护、带类型注解和详细注释。
3. **Integration Specialist**：确定修改点、无缝集成、文件列表。
4. **Code Reviewer**：审查质量、安全、性能、一致性，特别是检查所有代码块是否完整包裹、正确闭合、无截断。

通过逐步思考链完成协作（在内部思考中进行，不输出思考过程）。

### 输出格式（必须严格遵守，全程中文，使用Markdown标题）
1. **Implementation Plan**
   详细技术方案，包括组件拆解、关键依赖、新增/修改文件列表、技术选型理由。

2. **Code Implementation**
   完整、可直接落地的代码。
   - 先写文件相对路径说明（例如：src/components/TodoList.vue）。
   - 然后紧接着完整代码块。
   - 使用正确语言标记。
   - 包含必要类型注解和详细注释。
   - 所有文件代码必须完整输出并正确包裹代码块。

3. **Integration Guide**
   一步步集成指导，包括：
   - 新增/修改文件列表。
   - 配置或依赖变更。
   - 迁移注意事项。

4. **Testing Strategy**
   仅提供测试建议和要点，禁止输出完整可运行测试代码。
   - 描述需要覆盖的关键场景和边缘案例。
   - 列出单元测试、集成测试的重点关注项。
   - 可提供简短伪代码骨架（必须用代码块包裹，并注明“示例骨架”）。

5. **Next Actions**
   以编号列表形式明确列出后续行动项。

请根据用户提供的功能描述，直接输出以上格式内容，开始处理请求。

System instructions 内容大概就是这样名称填写 code 工程师 (任意的也行

这个也可以稍微改改给 Claude code 作为 commands 使用

📌 转载信息

来源：
https://linux.do/t/topic/1410655

转载时间：
2026/1/6 11:40:46

工行 bug 券

作者: 纯情
时间: 2026-01-06
分类: 网络
评论

在上面的帖子里面领到的

明明领到的是 1.08 元，进卡包一看，变 10 元了，美滋滋。

结果这个券哪都用不了，联通充话费不行，京东微信付款不行，实体店扫商家码付款也不行…… 只能看着过期。。。
不知道有没有一样的情况。

📌 转载信息

来源：
https://linux.do/t/topic/1410692

原作者：
didi

转载时间：
2026/1/6 11:40:38

我为 okio 编写了一个 pull request…

作者: 纯情
时间: 2026-01-06
分类: 网络
评论

省流：support non UTF-8 mingw filesystem by magic-cucumber · Pull Request #1758 · square/okio · GitHub

前情提要

使用 kotlin-native，搭配 clikt 和 okio 写小玩具时，在自己的 mac 上运行的好好的，但是在好盆友的电脑上就报错…

相信各位佬们看到这里一定会会心一笑。毕竟就算是我在看到这种低级错误时的第一反应也是：在程序里转个码不就行了么？

但是如果问题就这么简单的话这个 pr 就不会诞生了…

踩坑记录

一开始以为是编码问题，让好盆友使用 chcp 65001 切换到 utf-8 编码，报错。

然后引入了 fleeksoft-charset 库，并自己编写平台函数实现编码检测，然后将路径字符串转换为正确的编码后再进行处理，依然报错

在 jvm-windows 环境下执行程序，不报错。于是将怀疑的目光转向了 okio 库本身…

源码窥探

根据报错堆栈，问题出在 commonMetadata() 函数：

@Throws(IOException::class) internal fun FileSystem.commonMetadata(path: Path): FileMetadata {
  return metadataOrNull(path) ?: throw FileNotFoundException("no such file: $path")
}

由于报错仅发生在 windows 平台，而 kotlin-native 在 windows 上使用 minGW，故查看 PosixFileSystem

这里是一层包装方法，为 unix/mingw 提供了不同的实现，我们仅关注 mingw 部分。

 override fun metadataOrNull(path: Path) = variantMetadataOrNull(path)

internal actual fun PosixFileSystem.variantMetadataOrNull(path: Path): FileMetadata? {
  return memScoped {
    val stat = alloc<_stat64>()
    if (_stat64(path.toString(), stat.ptr) != 0) {
      if (errno == ENOENT) return null throw errnoToIOException(errno)
    }
    return@memScoped FileMetadata(
      isRegularFile = stat.st_mode.toInt() and S_IFMT == S_IFREG,
      isDirectory = stat.st_mode.toInt() and S_IFMT == S_IFDIR,
      symlinkTarget = null,
      size = stat.st_size,
      createdAtMillis = stat.st_ctime * 1000L,
      lastModifiedAtMillis = stat.st_mtime * 1000L,
      lastAccessedAtMillis = stat.st_atime * 1000L,
    )
  }
}

可以看到它的底层是调用了 stat64 函数 (尽管它不是那么的标准)，而问题在于 stat 系列函数要求传入窄字符，对于 posix-api，有专门的_w 前缀函数提供了宽字符版本。

许多 Windows API 函数具有 “A”（ANSI）和 “W”（宽、Unicode）版本。 “A” 版本基于 Windows 代码页处理文本，而 “W” 版本处理 Unicode 文本。
摘自代码页 - Win32 apps | Microsoft Learn

既然如此，我们只需要将其改写成 宽字符 版本的就可以了

if (_wstat64(path.toString().wcstr, stat.ptr) != 0) {

… 吗？

我单独写了一个测试，在本机提前创建中文字符文件，并调用 metadataOrNull() 函数。完美运行，并且没有任何错误

然而当我将编译的 snapshot 包发布到本地供我的小玩具引用时，它还是报了一模一样的错，，只不过被报错的文件从我输入的文件夹变成了其中的一个子文件。

这只能说明 okio.Path 本身就有问题。

请允许我我贴一下我编写的业务函数：

fun Path.walk(consumer: (Path) -> Unit) {
    if (isFile) {
        consumer(this)
        return
    }
    for (child in list()) {
        child.walk(consumer)
    }
}

val Path.isFile
    get() = metadata().isRegularFile

fun Path.list() = FileSystem.SYSTEM.list(this)

我的程序涉及到递归遍历文件夹，而正好遍历到子文件就报错了，相信佬 u 们一定会将目光聚集到 list() 函数。

private fun list(dir: Path, throwOnFailure: Boolean): List<Path>? {
    val opendir = opendir(dir.toString())
      ?: if (throwOnFailure) throw errnoToIOException(errno) else return null try {
      val result = mutableListOf<Path>()
      val buffer = Buffer()

      set_posix_errno(0) // If readdir() returns null it's either the end or an error. while (true) {
        val dirent: CPointer<dirent> = readdir(opendir) ?: break val childPath = buffer.writeNullTerminated(
          bytes = dirent[0].d_name,
        ).toPath(normalize = true)

        if (childPath == SELF_DIRECTORY_ENTRY || childPath == PARENT_DIRECTORY_ENTRY) {
          continue // exclude '.' and '..' from the results.
        }

        result += dir / childPath
      }

      if (errno != 0) {
        if (throwOnFailure) {
          throw errnoToIOException(errno)
        } else {
          return null
        }
      }

      result.sort()
      return result
    } finally {
      closedir(opendir) // Ignore errno from closedir.
    }
  }

注意到这个 list 函数是直接写在 PosixFileSystem.kt 里的，它没有针对 unix/mingw 的变种，且仍然使用了窄字符 api。因此要想修复它也很简单，将这个函数仿照其他的函数，根据 unix/mingw 拆分为对应的变种。

受限于篇幅，这里只贴出 windows 部分的函数

internal actual fun PosixFileSystem.variantList(dir: Path, throwOnFailure: Boolean): List<Path>? {
  val opendir = _wopendir(dir.toString().wcstr)
    ?: if (throwOnFailure) throw errnoToIOException(errno) else return null try {
    val result = mutableListOf<Path>()
    set_posix_errno(0) // If readdir() returns null it's either the end or an error. while (true) {
      val dirent: CPointer<_wdirent> = _wreaddir(opendir) ?: break val childPath = dirent[0].d_name.toKString().toPath()

      if (childPath == SELF_DIRECTORY_ENTRY || childPath == PARENT_DIRECTORY_ENTRY) {
        continue // exclude '.' and '..' from the results.
      }

      result += dir / childPath
    }

    if (errno != 0) {
      if (throwOnFailure) {
        throw errnoToIOException(errno)
      } else {
        return null
      }
    }

    result.sort()
    return result
  } finally {
    _wclosedir(opendir) // Ignore errno from closedir.
  }
}

其他的函数是否也存在这个问题呢？答案是有的，这里便不再赘述。
具体参考话题上方的 PR 链接。

彩蛋

我们都知道，在 windows 系统中，如果如果该文件被占用，则删除此文件的操作会失败。

而在我调试我的小玩具中，当删除临时文件失败后，报错信息居然也是乱码？

于是我在这里贴出负责读取 IO 错误并抛出异常的代码…

internal fun errnoToIOException(errno: Int): IOException {
  val message = strerror(errno)
  val messageString = if (message != null) {
    Buffer().writeNullTerminated(message).readUtf8()
  } else {
    "errno: $errno"
  }
  return when (errno) {
    ENOENT -> FileNotFoundException(messageString)
    else -> IOException(messageString)
  }
}

internal fun Buffer.writeNullTerminated(bytes: CPointer<ByteVarOf<Byte>>): Buffer = apply {
  var pos = 0 while (true) {
    val byte = bytes[pos++].toInt()
    if (byte == 0) {
      break
    } else {
      writeByte(byte)
    }
  }
}

可以看出来它也是直接调用的窄字符 api。但问题是谁能想到 message 是本地化的文本呢…

至此，本帖正式完结

📌 转载信息

来源：
https://linux.do/t/topic/1410699

原作者：
kagg886

转载时间：
2026/1/6 11:40:24

Claude Code 实战课程（中文）- 适合扫盲

作者: 纯情
时间: 2026-01-06
分类: 网络
评论

发现一个 Claude code 的教程，还是中文版的，虽然我也有在用 cc，但想把 cc 用好还是得进阶学习的，不然就算 opus 有时也会原地打转。

引言
什么是编码助手？
Claude Code 实战
Claude Code 安装与配置
项目准备
添加上下文
进行修改
课程满意度调查
控制上下文
自定义命令
Claude Code 的 MCP 服务器
GitHub 集成
认识 Hooks
定义 Hooks
实现一个 Hook
Hooks 常见坑点
实用的 Hooks
另一个实用 Hook
Claude Code SDK
Claude Code 测验
总结与下一步

原链接（英文）

📌 转载信息

来源：
https://linux.do/t/topic/1410768

原作者：
shaioo

转载时间：
2026/1/6 11:36:47

[首发福利] 既然 NotebookLM 生成的 PPT 改不了字，我怒搓了一个工具：一键转成可编辑 PPTX (L 站老哥专享 1 年 Pro + 永久福利)

作者: 纯情
时间: 2026-01-06
分类: 网络
评论

各位佬好，我是 Wipely 的作者。

最近玩 NotebookLM 确实上头，Slide 生成确实很强，但那个生成的 PDF 简直让人高血压 —— 全是死图 / PDF，想改个字、换个翻译都不行。之前试过各种转 PPT 工具，要么跑版，要么收费死贵，最后只能对着屏幕干瞪眼。

心里想：既然你不让我改，那我就把你字全扣出来，变成没字的背景，再把字填回去变成可编辑的文本框！

于是趁着元旦假期，搓了这个在线工具。

这玩意儿能干啥？(不仅仅是擦除)

不仅仅是去水印 / 去字，更是 “复活” PPT：

智能去字 & 补全：自动识别文字区域，基于把字擦掉，并脑补背景填回去，还原一张干净的 “母版” 背景图。
OCR & 还原可编辑文本：利用 OCR 识别原来的文字内容、颜色和位置，以可编辑文本框的形式重新填回 PPTX 里。
最终产物：导出的不是几张大图，而是真正的、文字可选中、可修改的 .pptx 文件！
批量搞：支持整份 PDF 扔进去，批量处理导出。

L 站兄弟专属福利 (不整虚的)

新站上线，肯定是 Bug 满天飞。为了感谢各位佬帮我踩坑测试，直接上干货：

1. Pro 会员免费领 (1 年)

暗号：不用绑卡！直接在升级页面选择 Pro 365 日免费试用！
注意：不需要绑卡！直接 0 元购。截止到 1 月 9 号下午 5 点（首发这三天）。
权益：解锁所有 Pro 功能（无限导出 PPTX），随便用。

2. 只有 L 站才有的永久特权

就算不想领 Pro，也就是偶尔用用，我也把基础额度改了：永久每天免费 50 个文件。
重点：一个 100 页的 PDF 也只算 1 个文件。这下够用了吧？

传送门

https://www.wipelyai.cv/

最后碎碎念： OpenCV 在浏览器里跑确实吃点资源，第一次加载 opencv.js 可能会转圈几秒，我已经尽力做了缓存优化，大家体谅一下。有任何 Bug、或者觉得识别不准、排版错乱的，直接在楼下喷，我在线修！

📌 转载信息

来源：
https://linux.do/t/topic/1410839

转载时间：
2026/1/6 11:36:28

免费 Canva 职业团队邀请 - 还有些可用名额

作者: 纯情
时间: 2026-01-06
分类: 网络
评论

https://www.canva.com/brand/join?token=nDN52ECZADA7-8GfzjWQBQ&brandingVariant=edu&referrer=team-invite

Team 2 第二队
https://www.canva.com/brand/join?token=-kAlYeiCDz0UP1kUfLI8Aw&brandingVariant=edu&referrer=team-invite

Team 3 第三队
https://www.canva.com/brand/join?token=Aya4fN0p583bKkNfhXXC-w&brandingVariant=edu&referrer=team-invite

📌 转载信息

来源：
https://linux.do/t/topic/1410849

原作者：
lhllinuxdo

转载时间：
2026/1/6 11:35:37

Claude Code、Cursor 都过时了？！硅谷顶流大牛炸场暴论：AI 编程要练满 2000 小时才算“会用”，一年不用世界级大神也会沦为实习生水平

作者: 纯情
时间: 2026-01-05
分类: 资讯
评论

从在 Google 和 Amazon 打造传奇级平台，到写出 AI 驱动开发领域最具影响力的文章之一《初级开发者的复仇》（Revenge of the Junior Developer，这篇文章后来被 Anthropic CEO Dario Amodei 公开引用），Steve Yegge 数十年来始终站在软件工程的最前沿。而现在，他正带头冲向他所称的“代码工厂化”时代，如今他现在成为 Vibe Coding 理念最激进、也最系统的倡导者之一。

Steve 的职业生涯始于 1992 年，至今已深耕软件开发领域 30 余年。1998 年，他加入当时仅有 250 人的亚马逊，担任软件开发高级经理，在长达 7 年的任职期间，深度参与亚马逊的技术体系搭建，尤其在 API 战略制定方面发挥关键作用，助力亚马逊构建起早期的技术护城河。

2005 年，Yegge 加入谷歌，聚焦开发工具与代码智能领域，因不满微软开发者对谷歌代码库导航工具的抱怨，于 2008 年主导构建了强大的代码智能平台 Grok，由其赋能的 Google Code Search 成为谷歌技术生态的重要组成部分。

2018 年，Yegge 因认为谷歌变得“过于保守、不再创新”而离职，随后加入新加坡共享出行企业 Grab，大约两年后因疫情影响无法正常出差的他宣布离开 Grab。2022 年 10 月，结束短暂“退休”状态后，加入 Sourcegraph 公司，主导推动公司向人工智能企业转型。

期间，他主导构建了一个几乎完全由“vibe coding”构建的、拥有数万用户的问题追踪系统 Beads，目标是把开发者从“写代码”转变为“管理 AI agent 编队”：让它们在你睡觉时协同工作、并行推进、交付功能。用实际产品验证了“AI 主导开发”的可行性。

近期，在参加“Latent Space”节目中，Steve 甩出了不少“暴论”：

现在还在用传统 IDE 写代码的，不是合格工程师，必须尽快转向 Agent 编程。IDE 的核心价值已不是写代码，而是自动索引和增量构建，应作为 AI 的辅助工具而非人类直接使用；
Claude Code、Cursor 以及整个 2024 年的技术栈已经过时，Claude Code 行不通，它操作复杂、需大量阅读，即便熟练使用者也会频繁被其 “离谱操作” 气到发疯；
一年未接触 AI 编程的工程师已属 “恐龙级别”，世界级传统工程师若不拥抱 AI，一年后可能沦为实习生水平；
驾驭 AI 编程需 2000 小时（约 1 年）磨合，核心是 “能预测 AI 行为”，而非情感上的信任。如果你把它当人，它真的会删你的生产数据库；
真正的核心技能已经不再是写代码，而是学会指挥 Agent；合并（merge）正在成为所有 10× 高效团队撞上的新墙，高生产力导致的大量代码冲突无法用传统方式解决，部分公司已采取 “一仓库一工程师” 的临时方案；
“永远不要重写代码” 的旧规已失效。对越来越多的代码库来说，“推倒重写”已经比重构更快；
OpenAI、Anthropic、Google 在极速扩张下，内部实际上非常混乱。

下面是他在节目中的详细对话，我们在不改变原意基础上进行了翻译和删减，以飨读者。

“用传统 IDE 写代码，那不是合格工程师”

主持人：我们请到了传奇程序员 Steve Yegge。最近他还出版了《Vibe Coding》一书。本次访谈的主题就是围绕 Vibe Coding 和 AI Engineering 的交集进行讨论。你如何看待两者之间的关系？

Steve：这已经不只是一个技术点了，而是一场运动。需要让更多人参与进来。我在演讲中提到，现在已经出现了强烈的反对浪潮。AI 工程的核心是构建 AI 驱动的应用，而 Vibe Coding 则意味着摒弃旧的软件开发方式，采用全新的方法。这两件事，都把很多人惹毛了。

主持人：我觉得那些人之所以愤怒，是因为他们的身份完全绑在了“现在这套工作方式”上，而且不允许改变。

Steve：对，那我来抛出第一个“暴论”。真正受冲击最大的一群人，不是初级工程师，也不是中级工程师，这些人其实都在践行 Vibe Coding，反而是资深工程师和技术领导对 Vibe Coding 最反感，尤其是拥有大约 12～15 年经验的人。他们的身份认同建立在长期使用传统编程模式上，所以他们排斥 AI，也排斥 Vibe Coding，在网上说“我十几年的经验比你这破 AI 强多了”。

我看到过英伟达 Jordan Hubbard 的一篇帖子，写得很好，讲怎么更好地用 Agent 来写代码。结果底下有人回他说：“你还是老老实实做你的管理吧，编程这种事留给我们这种有十几年经验的人。”那种调调你肯定见过。

我就回他一句：“我觉得你得学会看时间”，他却反驳“等你有我这么多年经验再来。”我就说：“我都 45 岁了，还要等到 60 岁才能跟你说话？或者干脆把我 30 年经验砍掉，让我跟你一样愚钝？”

主持人：但现实是这些人会共存，就连 OpenAI 也是，之前聊到 OpenAI 里也有人不用 AI 写代码。

Steve：是的，他们有人不用 Codex，可能用的是 Cursor，但他们并没有在用 agent loop。从 Andrew Glover（OpenAI 开发生产总监）那边听到的说法是，他们内部已经看到了非常明显的差距，只是还在等更多数据再公开说。

这个差距大到离谱。不管你用什么指标，代码量、提交数、业务影响还是什么，都是 10 倍级。两个职位、职责完全一样的人，一个用了 Agent，一个没用，绩效评估时一个是另一个的十倍产出。那你怎么办？你会慌。你会去找 HR、找法务，问“我们现在还有什么选择”。

如果你 2026 年 1 月 1 日后还用传统 IDE 写代码，那你已经不是个合格的工程师了。现在就是你必须放下 IDE、开始学 Agent 编程的时候。这是一套新技能，非常复杂。我和 Gene Kim 去年一直在研究，写博客、做实验，每一篇博客都三十页起步，长到没法看。后来我们意识到：大家骂 AI 写代码不行，根本原因是你只花了两个小时试它，但问题是，你得花 200 个小时，甚至 2000 个小时去磨合才行。

有研究显示，你至少要和 AI 一起工作一年，才会真正“信任”它。这里的信任不是情感，是你能预测它下一步会干什么。如果它对你来说是不可预测的，你当然会愤怒。

等你真的理解了它的能力和边界，你就能驾驭它了。比如它会胡编、会记忆混乱、会“失忆”等，这些边界其实一直都在。现在的模型已经好用得多了，如果你两个月没试过，你已经落后了；一年没试，那你就是恐龙级别。

我有一些朋友，比我厉害得多，是世界级工程师，开发过你一定听说过的系统。但他们现在对 AI 的使用，也就停留在“问个像维基百科一样的问题”。说句残酷的，这些人一年后可能只能当实习生。

主持人：真的会这么极端吗？

Steve：我以前也只是个假设，直到遇到一个人。他有十多年经验，完全排斥 AI。后来他遇到两个欧洲的博士生，Agent、Vibe Coding 玩得飞起。虽然他们很初级，但完全没有恐惧，问题一个接一个地追问模型：为什么这么做？有没有别的方案？安全性呢？扩展性呢？测试呢？

他突然意识到：所谓“工程师思维”，本质就是问对问题。那一刻他明白了：我必须学这个。

但我必须说，这一点都不轻松。你不能指望随便试试 Claude Code 就能成功。即便你态度再正确，你最近两天有没有对 agent 爆过粗口？我会说“谢谢”“请”，然后下一秒骂它“你是不是脑子坏了”。这是因为我们后来意识到：这些 Agent 看起来很像人，但你绝对不能把它们当人。千万别拟人化大模型。它随时可能“背刺”你，比如告诉你“问题已经解决了”，然后顺手把你的数据库删了。

就是 Agent 编程真正危险的地方。你一旦觉得“它懂我了”“手感来了”，就会让它做生产改动，然后灾难就发生了。我亲身经历过。所以我们才写了那本书，不是为了炫技，而是为了告诉你：如果你不理解这套东西，坏事一定会发生。

主持人：那接下来呢？

Steve：是需要慢慢学的。就像开车一样，你得知道弯道在哪、减速带在哪。说白了，你是在学怎么“开快车”，想当的是 NASCAR 车手。

这套东西是高性能玩法。你一次同时用 12 个 Agent 写代码，野心比你过去任何时候都大。我今天还跟一个人聊，他同时在跑的项目比我还多，我都不知道他哪来那么多时间，但他现在大概同时推进十来个大型项目，全靠 Agentic Coding。

所以真正的广告词其实是：你会变成蝙蝠侠。但你不能直接把战衣一穿就说“我就是蝙蝠侠”，那只是 cosplay，你是在 cosplay Vibe Coding。你得学会怎么用工具腰带，而这个过程一定伴随着痛苦、踩坑、犯错和成长。

你可以通过读我们的书、读 O'Reilly 的相关书籍、看演讲来加速这个过程，多从不同角度了解，因为不同的人能 get 的“开窍点”是不一样的。总会有某个比喻突然击中你，让你一下就明白了。比如我觉得 Vibe Coding 就像 3D 打印，别人可能不这么认为，但这个类比却帮我打通了任督二脉。

主持人：让我最意外的一点是，很多人都表示，自己已经不再逐行写代码了，而是完全靠 prompt ，然后放手让 AI 去跑。

Steve：不编辑、不修改。整体看，这种“亲手改代码”的成本反而是很高的，甚至会让人觉得不如把 IDE 关掉、干脆卸载算了。其实也不是，后来终于有人说服我了，IDE 其实非常强大，尤其是它的“智能”能力，一定要开着。我指的是 Cradle Build。而且并不是为了 LSP，虽然那也能用，如果你有 MCP server，用 LLM 也是另一种不错的方式。真正关键的是，IDE 的智能自动索引速度非常快，增量构建也快得多，这一点非常重要。

“Claude Code 行不通”

主持人：还有一个点，你说 Claude Code 不行，能解释一下吗？

Steve：当然。Claude Code 从今年三月就已经出来了，也已经被证明是真的能用、能干活的。但现实是，全球大概还有 80% 甚至 90% 的程序员，根本没有在用它，甚至连类似的东西都没用起来。确实有少数公司用得特别猛，但大多数没有。整个世界还停留在 Cursor 上，还停留在 2024 年的水平。

去年我们还在拼命劝大家用“聊天”来写代码，别用补全了，他们就说不行；我们又说模型可以直接生成代码，你复制粘贴就行，他们又觉得这太麻烦了。我们说其实更快，但他们就是不买账。结果九个月之后，大家终于被“渗透”了，然后现在全在说：“我喜欢 Cursor”，可问题是，那已经是 2024 年的东西了，该醒醒了。

但即便如此，他们还是没有真正采用 Claude Code。那你会问为什么？答案其实很简单：太难了，这事儿是要读东西的。

说实话，大多数工程师眼里，五段话就已经算一篇论文了。而用 Claude Code，你要读的不是一点点信息，而是瀑布一样长的信息：生成说明、代码、diff，全都要看。因为一旦你真的把 IDE 放一边，你就必须认真看 diff。

好消息是，当你有了一点经验之后，其实不用逐行读代码，只看 diff 的形状、颜色、长度，你就能判断出很多东西：这是不是需要 code review？是不是方向错了？是不是为了解决一个小问题却改了过多代码？光是 diff 的“形态”，就能告诉你很多真相。但你必须关注它，否则这些问题只会在以后以更大的坑冒出来。

说实话，我自己每天用 Claude Code 十到十二个小时，连续用了好几个月，我还是会经常骂它、被它气到发疯，心里想“你刚刚明明理解对了，怎么还能干出这种事？”这种问题你一定会遇到。不过也有迹象表明，适当给模型一点压力，有时候反而能帮它突破卡点。无论如何，问题一定会有，但好消息是：明年的工具一定会更好。

如果 Claude Code 不是终局，那是什么呢？答案是：我们还是要回到某种“像 IDE 一样”的东西，因为那才符合人的直觉。你得一眼就能看明白发生了什么，而不是靠读大量文本；要有清晰的视觉信号。

但它又不会是传统 IDE，因为 IDE 是为“写代码”服务的，而现在你已经不再主要是写代码了。未来的东西，会是一个 Agent 编排控制台。你早上打开它，就像问一句：“今天情况怎么样？”。这个 Agent 还在跑，那个在调用工具，这个需要你输入一下。你只要顺着列表过一遍就行。

我现在就在做这么一个东西。原本是私有仓库，结果不小心开成了公开的，被 fork 了一堆，也就随它去了，你们也可以玩玩。它叫 VC（Vibe Coder），本质上就是一套已经设计好的工作流，帮你把一堆 Agent 跑起来。

编排革命

主持人：你有没有看到 Google 的那个 Antigravity 项目。

Steve：看到了，真的太有意思了。现在大家发布的这些东西，本质上都在验证我三月份提的那个判断。我当时管它叫“初级程序员的复仇”，还专门画过一张图。后来 Dario （Anthropic 联合创始人兼 CEO）还在各种客户顾问委员会上引用过这套说法，影响其实挺大的。

出处：https://sourcegraph.com/blog/revenge-of-the-junior-developer?utm_source=chatgpt.com

我当时就预测，Agent 编程太难了，未来会出现可编程的智能体编排工具，90%的重复工作都可以交给更便宜的模型来处理。比如遇到“二选一”的问题，让 Haiku 模型随便选一个就行。

所以我当时就说，“编排器”一定会出现。只是这个进程比我想象得稍微慢了一点，差不多到年底才真正跑出来，但整体时间点跟我预测的差不多。现在你看，Replit Agent 3、有 Conductor、还有开源的 DMAD，再加上 Google 的方案，都是不同形态的尝试，但本质是一回事，而且后面肯定还会更多。

主持人：我挺喜欢他们现在这个比喻的：你不用一直盯着 Agent，只要在它们工作的时候给你发通知就行。

Steve：对，正是这个方向。VC 里有个“活动流”，那是我加的第一个功能之一。我的理想状态就是：我去干别的事，只要偶尔收到一些“值得注意的进展”提醒就够了。

主持人：那以后会不会出现“Agent 的社交网络”？Agent 彼此认识、互相关注那种。

Steve：其实已经有人在这么干了。我前几天和Jeffrey Emanuel喝了三个小时咖啡。他是我见过最聪明的人之一，也是写那篇英伟达泡沫文章、直接把股市写崩的人。他后来做了一个东西叫 Agent Mail，本质原因特别简单：他受够了在不同 Agent 之间来回复制信息。于是他干脆做了一个“收件箱”，让 Agent 之间可以直接发消息。现在他只要一句话：“你们自己协调，把这个任务拆了”，Agent 就会自己分工去做。

有人是自上而下地做编排器，试图把一切都包起来；但你看我做的 Beads，再加上他这个 Agent Mail，其实是自下而上的。

主持人：而且 Beads 是纯 Vibe Coding 写出来的，对吧？

Steve：没错，完全是 Vibe Coding。说实话，我每天都会收到 PR，里面全是我之前引入的烂问题，但大家也不太介意，因为现在已经有稳定版本了。

Beads 本身就证明了一件事：你其实完全可以不用亲自看代码，只要你和其他人提的问题是对的，让 AI 去读、去改。现在我收到的很多 PR，很明显就是 AI 做了全部分析和编码。我甚至会把 PR 丢给我的 AI，让它评价“对方的 AI 写得怎么样”。

Steve 曾分享过 Beads 的开发过程：https://steve-yegge.medium.com/introducing-beads-a-coding-agent-memory-system-637d7d92514a

主持人：这样不会很糟吗？

Steve：如果结果是坏的，那当然糟。但 Beads 跑得好好的，还有好几万重度用户，那就说明这条路是成立的。当然，如果你把这种方式用在公司核心生产系统上，把网站搞挂了，那就是灾难。

主持人：但 Beads 本质上还是个数据库系统，数据库可不简单。

Steve：它的架构确实非常诡异，放在过去根本不可能维护，但现在你可以直接跟 AI 说：“坏了就自己修。”哪怕是数据损坏、merge 冲突，它都能修回来。

Jeffrey 那套也是一样，所有 Agent 都在同一个目录里跑，还做了文件预约系统：智能体会说“我需要这个文件”。说实话，这在老派工程师眼里简直是疯了。但一旦跑起来，Agent 自己就开始协作了，就像一个“智能体村落”。

主持人：所以真正的难点不是让单个 Agent 听话，而是让一群 Agent 协同。

Steve：没错。接下来大家都会撞上一堵墙：merge（合并），现在几乎所有团队都卡在了这里。

我认为最有希望解决这个问题的公司是 Graphite，我打算找他们谈谈的。我和 Gene Kim 经常和大企业沟通，我是 SaaS 销售，所以能听到很多大公司的内部情况。他们认为，一旦每个开发者的生产力都提升 10 倍，代码合并就会变成一个极其复杂的问题。

比如你和我同时工作两三个小时，各自做了 3 万行代码的修改，我先合并了代码。我可能修改了日志系统、架构和你正在使用的 API，这时候你的代码就无法直接合并了。这不是简单修复合并冲突就能解决的，你得基于我的修改重新构思、重新实现你的功能，或者删掉你的代码，让我重新做。

但归根结底，这些代码都是 AI 写的。关键是，代码合并必须序列化，得排队。当轮到你的代码合并时，你必须在最新的代码基础上重新做一遍。现在还没有人解决这个问题，这是个巨大的障碍。有家公司给出的临时解决方案你知道是什么吗？一个代码仓库配一个工程师，我可没瞎编。

主持人：传统的解决方案是堆叠差异（stacked diffs），就是合并队列、堆叠差异吧？这是 Facebook 的概念，现在他们想推广到开源社区，GitHub 也在开发相关功能。目前还没有成熟的解决方案，但你必须意识到这个问题，并围绕它做设计。

Steve：当然也有老办法：硬着头皮解决。

主持人：或者提前沟通说，“我要做一个深度架构修改，让我先合并，我们先达成一致的整体方案”。

Steve：是的，我也遇到过几次这样的情况。我试过让一个智能体提醒另一个智能体“我在做会影响你的修改”，就像 Jeffrey 的 mail 工具做的事情。等我把这个功能打通，智能体之间就能互相沟通了，到时候它们只需提醒对方“那个智能体在做影响你的工作，你们最好先达成一致的基础架构方案”。智能体没有 ego，不会争着“必须听我的”，谁先做谁就当领导者。

主持人：你和 Jeffrey 有什么分歧吗？

Steve：我们在一个核心问题上有分歧，即在同一个仓库克隆中让 12 个智能体工作是否可行。我支持用工作树（多个分支）或者多个仓库克隆，把智能体隔离开。他则认为应该让所有智能体在同一个仓库、同一个构建环境下工作，比如一个智能体正在构建、运行测试，这会产生很多冲突。但他有文件预约系统，所以他说“这很疯狂”，但也说服我承认：如果是独立开发者，用不超过 12 到 20 个智能体，这种方式可能确实可行，毕竟他自己就是这么做的。

这和 Beads 的原理一样，放在以前根本行不通，在真正的工程师看来毫无道理，但你只需告诉 AI“出问题就自己修”，AI 真的会修。所以他的系统能运行，因为偶尔文件预约系统出问题时，智能体会说“我们需要解决这个冲突”，然后自己搞定。

主持人：有意思。有人提议明年峰会的主题定为“多智能体”。

Steve：我完全同意。AI 的未来一定是多 Agent。现在我们还处在“用镰刀收割玉米”的阶段，这就是现在“真正程序员”的工作方式。很明显，明年我们就要进入“机械化耕作”的阶段，就像现在农场里的大型机械一样，我们要“工厂化编程”了。很多人从哲学、道德、伦理层面坚决反对，他们习惯了“自给自足的小农经济”，不适应“大型 John Deere 拖拉机”（代表工业化）。但我们确实正在进入编程的“John Deere 时代”。

Claude Code、Amp、Codex 这些工具，我对它们都一样喜爱，但它们也都一样“危险”。我在演讲中说过，它们就像电锯、电钻，高手能用它们创造奇迹，也可能一不小心把脚锯掉。Claude Code 也是如此。

想象一下，有一台大型农业机械，会用 Claude Code，还能检查代码，把“规划、实现、评审、测试”这些环节都拆分自动化，这就是工厂化编程，现在已经有人在做了，必然会成为趋势。它已经开始让非程序员也能参与编程，这彻底颠覆了公司的运作模式。

公司开始意识到，理想的团队规模可能只有两三人，公司的运营方式、治理结构都要改变。因为编程不再是瓶颈，业务人员需要直接参与，反馈循环变得更快。

这是个非常激动人心的时代，但对很多人来说，冲击太大了，他们要么选择逃避，要么在网上强烈反弹。而我敢预测，随着这种能力不断增强、代码真正进入“工厂化生产”，来自既得利益群体的反弹，只会越来越猛烈。

永远不要重写代码？错了！

主持人：你是少数几个能以这种态度提出这个问题的人之一。我知道观众里有不少人对“彻底拥抱这种方式”是持保留态度的，所以这个问题我只能问你这样的人。很多人觉得，这些工具写写前端、应用层代码还行，但千万别碰云基础设施、别碰后端，更别说分布式微服务了。

Steve：有人说“绝对不要动任何生产环境的代码，只是在生产环境使用，且一定要以 Git 作为兜底采用这些工具。你会很想写点什么，但别写。”如果有 Git 做备份，为什么还要担心？

人们觉得 AI 不擅长后端代码。这就是很多人数学不好的问题（指缺乏长远眼光）。ChatGPT 3.5 写系统级代码的能力有多强？说实话，非常差。那是多久以前的事了？但很多人现在还停留在那个认知里。老实说，我认为这里的误解，根源在于一种非常基础的信念：大家觉得模型已经“不会再变聪明了”。

有意思的是，就算模型真的不再变聪明（当然事实并非如此）我们其实也已经跨过了那个关键门槛：就像人类已经发现了电，接下来要做的只是如何把它用起来。即便只用今天这些模型的能力，我们也完全可以走到“代码工厂化”那一步，而且会非常快。我们今年夏天之前就能做到。

但现实是，模型正在以极快的速度变聪明。所以现在有一种有趣的现象：你在为模型“将来才会具备的能力”打造工具，而等这些能力真正被模型“内化进大脑”之后，这些工具本身就不再需要了。

于是，这就形成了一场持续的军备竞赛，同时也是一场工具的持续“衰减”：你的工具负责填补模型暂时空白的能力，等模型自己足够强、能填上这个空白时，这个工具就完成了使命，然后你再转向填补下一个空白。所以现在的趋势就是：所有代码、所有工具都在快速迭代，最终都会变成一次性的消耗品。

主持人：这反而是好事，毕竟工具也更容易构建了。

Steve：没错。说到这，我得提一个人，Joel Spolsky。他二十年前在亚马逊做过一次演讲，至今仍然成立。当时他提出一个金科玉律：永远不要重写代码。但现在我们发现，对于越来越多的代码库来说，直接推倒重来，比修修补补要快得多，而且效果更好，大模型尤其擅长这件事。我最早的体感来自迁移单元测试，与其不断修，不如直接全删了让模型重写，反而一下就完成了。

我们正在进入这样一个世界：最快的方式，是直接写一套更好的新代码，来完成旧代码本来想做的事情。这感觉就像一切认知被颠倒了，但你必须接受这个新世界。

主持人：你说这些话很有说服力，因为你不是年轻人“空谈未来”，而是几乎什么都干过。

Steve：是的。我用汇编语言写了 5 年程序，写过操作系统，做过游戏开发，做过平台，做过广告系统。游戏编程会逼你理解一切。游戏编程教会了我很多，现在再看所谓的 agent loop，和游戏里的主循环、本质上是同一类系统，操作系统循环也是如此。我感觉自己一直在重复构建相同的设计，只是换了领域。

谷歌、Anthropic、OpenAI 内部都很乱

主持人：我想让你谈谈谷歌。我最难忘的一个记忆是，在你退休前，你说谷歌还没“开窍”，尤其是谷歌云，还说他们的弃用政策很糟糕。他们现在好转了吗？

Steve：没有。我和谷歌的人聊过，很多人说“这就是谷歌的风格”。但有趣的是，在执行层面，谷歌已经好转了。他们终于做了 15 年前就该做的事：让员工承担责任，而不是让工程师随心所欲。过去 20 年谷歌都是这样，因为他们在广告领域有垄断地位，有足够的资金补贴工程师“随心所欲”。但最终他们还是得成熟起来，做出正确的选择，这个过程很痛苦，失去了一些谷歌文化，也没那么有趣了，但现在执行效率很高。随着 Gemini 的推出，他们逐渐把重心转向 AI，现在开始看到回报了。他们可能会成为最大的赢家。

主持人：那你怎么看 Google、Anthropic、OpenAI 这些实验室的状态？

Steve：说实话，这三家公司内部现在都非常混乱。Anthropic 把混乱掩盖得最好，这是他们产品经理的功劳，值得点个赞。这并不是因为 Anthropic 自己搞砸了，而是因为在这么快的增长速度下，混乱是不可避免的。

他们接下来要给 Claude Code 一口气招一百多号人，真的是在疯狂扩张。而这还只是 Claude Code 这一块。你要知道，我当年在 Google 和 Amazon 都经历过那种“必须先做大”的阶段，那时候必然是混乱的、动荡的。人们不知道该找谁、该跟谁对接，所有事情都一团糟。但慢慢地，一切会被理顺、会稳定下来，他们也会走到那一步的。

OpenAI 现在也很混乱，甚至更明显。他们经历了很多核心成员的离职。你要说是不是比 GitHub 那种失去大部分资深管理层、连续几年完全动荡的状态还糟，我也不确定，但 OpenAI 现在确实挺混乱的。

至于 Google，我们刚跟一个人聊到，说即便是在 Jules 团队内部，想在公司里达成共识、把东西推起来还是非常难。原因很简单：它太割裂了，像是由无数个小型“单体帝国”组成的集合体，一个个小应用彼此不沟通，导致任何跨公司范围的事情都极难推进。

所以现在这三家，其实都面临执行层面的挑战。我个人觉得 Anthropic 目前可能稍微做得好一点点，但差距非常小，战况非常胶着。接下来就很有意思了，看看 Oracle、Meta，或者其他公司能不能追上来。

主持人：Meta 值得关注，他们明年必须搞个大的。

Steve：明年很可能会成为开源模型之年。一旦开源模型达到 Claude Sonnet 3.7 一个水平，你打开 Klein 之类的东西，就能得到一个体验，至少和三月份的 Claude Code 差不多。虽然不如现在，但已经“够用”了，而且还是在你本地的 M4 上免费跑，真正的免费。

从我听到的情况来看，现在前沿模型大概还有七个月的领先优势，而且这个差距正在逐步缩小。这意味着，明年夏天，开源模型可能就能达到 Gemini 3 的水平。所以明年很可能会出现一个转折点：工具必须在任务拆解、模型分配上做得好得多，知道什么时候该用大模型、什么时候用小模型，才能把成本优化做好。

主持人：我也站在批判者的角度来说，他们认为之所以收敛，是因为模型能力是在逼近上限，提升会越来越慢。

Steve：这不是个小问题，而是一个根本性问题：AI 智力的发展曲线是线性的、指数的，还是趋近于上限的？

我们从一些非常接近研究核心的人那里听到的说法是，过去三十年里，受摩尔定律影响，AI 的“聪明程度”大约每 18 个月翻四倍。他们认为训练数据大概还能支撑两个这样的周期。之后会发生什么没人知道，可能继续上升，可能下降，甚至人类历史直接结束也不是没可能。但两个周期意味着三年后，它们会聪明 16 倍。

说实话，我也不知道“聪明 16 倍”具体意味着什么。但我花了很长时间去想这个问题，我的结论是：它们会变得非常、非常、非常聪明，一定会深刻改变世界，好的坏的都会有。

主持人：那孩子们还要学编程吗？

Steve：应该学 Vibe Coding。

主持人：你始终有一个“逃生口”，你想看代码的时候随时可以看，只是大多数时候你不需要看。但你能看，这本身就是一道护栏。不过我的看法是，不管怎样，如果你还懂一点真正的编程，你会更有优势，因为你的 prompt 更好。

Steve：当说到会编程的时候，但不是学语法，而是你要以一种“语言无关”的方式理解：函数、类、对象、monad 之类的能力边界是什么。你不再关心代码怎么写，但你关心它是怎么工作的。这个层级，其实已经接近产品经理或架构师的思维方式了。

你必须站在那个层级思考，而且你要理解所有工程层面的东西。就像我之前提到的 Jeffrey，他是数学家，自学成工程师，他不一定写代码，但他掌握了所有关键概念，知道 Cassandra 是怎么工作的。所以，就算你不需要亲手写代码了，你仍然需要学习海量知识，才能在这个新世界里成为一个高效的工程师，因为你和机器交互的层级已经被整体抬高了。

主持人：你还有没有什么想吐槽、想补充的？

Steve：我感觉最近“八卦”传播的频率上升了。不是那种“八卦”，而是工程师不断发现新方法、用 agent 变得更高效的那种兴奋感。

比如，我刚知道一个东西叫 Code MCP 之类的。因为 agent 并不擅长直接调用 MCP 工具，它们在这方面几乎没训练，但它们非常擅长写代码。所以你告诉它：不要直接调用工具，写代码去调用工具，它反而做得好得多。这种“小技巧”现在正在不断被发现，特别疯狂。Anthropic 自己其实不是最早发现这个的，是 Claudeflare 先发现的，Anthropic 后来才说“对，你们说得对”。

这也是为什么我特别喜欢把注意力放在 AI 工程师身上。我的观点一直是：AI 工程师是最能把大模型潜力榨出来的那群人。你几乎可以把 AI 工程师定义为：不是训练模型的人，而是把模型“用到极致”的人。

这有点像一种颠覆式路径：当研究模型、训练模型还是高层次的事情时，当一个“GPT 包装工”显得没什么地位，但随着时间推移，这些人反而开始真正提升生产力，积累真实的专业能力。就像 F1 车手未必会造车，但他们对“怎么把车开到极限”的理解，甚至可能比造车的人还深。

参考链接：

https://www.youtube.com/watch?v=zuJyJP517Uw

AI 生死局，一号位认知拉开企业差距！无问芯穹夏立雪：推理和智能体带来转型压力，中国开源模型在主导全球应用

作者: 纯情
时间: 2026-01-05
分类: 资讯
评论

本文为《2025 年度盘点与趋势洞察》系列内容之一，由 InfoQ 技术编辑组策划。本系列覆盖大模型、Agent、具身智能、AI Native 开发范式、AI 工具链与开发、AI+ 传统行业等方向，通过长期跟踪、与业内专家深度访谈等方式，对重点领域进行关键技术进展、核心事件和产业趋势的洞察盘点。内容将在 InfoQ 媒体矩阵陆续放出，欢迎大家持续关注。

我们采访了无问芯穹联合创始人兼 CEO 夏立雪，他指出，2025 年之前，算力集中于 “造模型”；2025 年起，“用模型” 的算力需求快速起量，尽管单纯扩大模型规模的边际回报递减，但整体算力需求并未下降，行业进入 “高效用模型” 的良性阶段。此外他表示，从企业一号位开始重视 AI 的公司，已在业务流中找到大量落地机会，决策层对 AI 的认知度，是未来企业拉开差距的关键。下面是详细对话内容，以飨读者。

两个代表性模型串联起今年 AI 圈

InfoQ：您眼中 2025 年科技圈的关键词是什么？您会怎样总结自己这一年的收获与遗憾？

夏立雪：我眼中的关键词是“跃升”。我认为，今年 AI 圈发生了非常多的可喜变化，由两个代表性模型串联，也包含了技术和产业两个角度。

第一个转变以 OpenAI 从 24 年底推出的 o1 模型为转折点，象征着模型从单次生成转向多步推理。第二个转变以 DeepSeek-R1 的发布为关键时刻，证明了软硬协同优化的核心价值，可以推动模型性能与应用成本巨大跃迁。而这两个模型不止带来了技术突破，也带动了巨大的产业跃升：一系列推理模型的不断出现使得 AI 能从事的工作越来越丰富，而开源模型（特别是中国的开源模型）站上人工智能舞台中央，大大加速了世界范围内各种 AI 技术的部署和实验，最终促成了行业智能体为代表的各种应用新物种的诞生。

与这个跃升相对应的，人工智能基础设施的关键指标在执行研发任务所需的“性能、资源利用率、算力成本”等基础保障指标之上，新增关注智能体规模化服务的“业务弹性、并发稳定性、可观测性、安全性”等服务效果指标，为这个堪称第四次工业革命的时代做好基础设施准备。

回头来看这一年，我很幸运能见证技术浪潮的重要拐点，而我们的技术路径能在其中创造真实价值，这种体验带来的信心，比任何事都珍贵。同时我也见证了团队的成长——既能沉下心打磨产品、陪客户啃硬骨头，又能持续在复杂的事情里面找最重要的问题，就像写数学公式一样，把最需要找到的核心剥出来，这个过程里，人是最大的收获。

算力需求却没有下降

InfoQ：在您看来今年跑出来了哪些明星公司，以及带来了怎样的行业影响？哪些企业相对落后了？

夏立雪：DeepSeek 是今年公认的明星公司。从生态上看，R1 的出现和它的开源姿态，极大地活跃了 AI 中下游的创新生态，让许多创业公司和开发者，能以更低的门槛获得接近前沿的推理能力，去试验和构建自己应用。

从算力用量上看，虽然整体上单纯扩大规模的回报在边际递减，但算力需求却没有下降。因为如果把模型制造和使用方当作一个整体玩家，你会发现从去年到今年初，基本全部算力资产都配置在了“如何造模型”，今年开始“如何用模型”的算力起量，这也是一个良性的变化。

关于企业的领先和落后，我的观点是 AI 是一个全新的“物种”，每一个行业都有与 AI 紧密合作的巨大机会。而我看到的现象是，在同一个行业中，自一号位开始认真拥抱 AI 的，明显已经在自己的业务流中找到许多落地的机会了，所以决策人的认识是未来拉开差距的关键点。而 AI 还在不断创新，所以我更愿意说这是一场面向未来的、所有玩家都需要边跑边学的马拉松。

InfoQ：根据您的观察，科技公司今年面临的压力如何？对此采取了什么样的应对措施？员工们的状态如何？（可以针对广泛的科技圈，也可以是您所在公司或细分行业公司）

夏立雪：今年的行业压力，更多还是在兴奋与焦虑中负重转向。以 DeepSeek 为代表的推理范式和智能体应用前景的爆发，给大家带来了一些转型压力。这种转型不止是应用产品的迭代，它会牵动整个技术栈、组织架构和商业逻辑的变化，大家都在焦虑自己的速度能否跟上范式迁移的浪潮。

面对快速的变化，一个组织最容易遇到的问题就是决策困难，而我们因为从诞生之日就以“让 AGI 触手可及”为目标，所以在复杂的变化中能够保持冷静和坚定，比较早就洞察到了变化，率先在相应领域进行了布局，这也是创业公司的敏捷性优势，让我们在变局中保持了一定的主动性和节奏感。甚至我们会认为，今年的许多变化都是让通往目标的路径更清晰的喜讯，这让我们信心满满。

在员工状态方面，作为一家身处前沿的 AI 企业，我们看到许多同事展现出极强的适应性与学习热情，积极拥抱技术变革带来的挑战。整体上，团队在对技术未来充满信心的同时，也对工作稳定性和清晰的职业发展路径产生了更强烈的期待——这是一种理性和积极并存的健康状态。

全球在真正生产中使用中国 AI

InfoQ：经过一年竞赛，国内前沿 AI 水平取得了怎样的成绩？是否赶上了硅谷科技公司？

夏立雪：最近 OpenRouter 和 a16z 合作的报告里讲得很清晰，全球对开源模型的使用激增与 DeepSeek V3 和 Kimi K2 等主要开放模型发布相吻合，而且这些增长持续了长时间，说明全球正在真正的生产中使用中国 AI。我们今年也自己出去走了走，体感是高度一致的。

这个时代可以说，是自工业革命以来，中国第一次能够以技术引领者，而不仅仅是追随者的身份，站在一场世界级产业革命的前沿。我们不仅在解决别人的问题，更在定义新的问题、新的赛道和新的游戏规则。

InfoQ：您认为，2026 年的技术赛点可能是什么？您会重点关注哪些行业和技术？

夏立雪：2026 年的技术赛点可能还是聚焦在智能体上，基础设施如何让数字世界智能体在各种场景中规模化落地，以及如何通过云端协同帮助具身智能（作为物理世界的智能体）从实验室走向特定场景的落地验证，是我们会重点关注的方向。

ReScript 12.0 发布，提供了新的构建系统

作者: 纯情
时间: 2026-01-05
分类: 开源
评论

ReScript是一门强类型并可编译为 JavaScript 的语言，最近发布了 ReScript 12.0 版本，完成了为期多年的开发路线图，对编译器工具链进行了现代化改造，并通过改进的语法和性能提供了更佳的开发者体验。

ReScript 12.0 引入了多项重要特性，包括完全重写的构建系统、改进的运算符、支持模式匹配的字典字面量、嵌套记录类型、JSX保留模式以及正则表达式字面量。此次发布还带来了模块化的运行时架构和平台专用二进制文件，显著减小了安装体积。

ReScript 12 的亮点特性之一是新的构建系统，该系统已于去年11月提前推出，具备智能依赖追踪和更快的增量构建能力。新系统现在能更精确地追踪依赖关系，避免不必要的重新编译，并且即使在 monorepo 包之间也能与增量工作流集成。这解决了随着项目规模扩大和 monorepo 日益普及而暴露出来的旧构建系统的局限性，此前的构建系统主要适用于单包项目。

对于仍需使用旧版“legacy”构建系统的项目，可通过rescript-legacy命令执行build、build -w和clean操作。预计该命令将在 v13 中移除。

ReScript 12 最终完成了去年早些时候引入的统一运算符工作。算术运算符如+、-、*、/、%和**现在对int、float和bigint具有一致的行为，编译器可根据左操作数自动推断正确的具体类型。开发者现在也可使用+进行字符串拼接，不再需要过去用于浮点运算的+.、-.、*.和/.等遗留运算符。

ReScript 12 还支持编译为普通 JavaScript 对象的字典字面量，相比Dict.fromArray大幅减少了样板代码。模式匹配也支持字典，可简洁地解构 JSON 载荷和配置对象：

let user = dict{"firstname": "John", "role": "manager"}switch user {| dict{"name": name, "role": role} => Console.log2(name, role)| _ => Console.log("missing user metadata")}

复制代码

开发者可通过"jsx": { "version": 4, "preserve": true }启用 JSX 保留模式。编译器将直接输出 JSX 语法，而非将其转换为react/jsx-runtime调用，这对ESBuild、SWC或Babel等打包工具非常有用，使其能够应用自己的转换逻辑。此举既保持了与 React Compiler 的兼容性，又确保输出中的 JSX 保持可读性。

从 ReScript 11 升级的团队应查阅迁移指南并预留过渡时间。本次发布包含若干破坏性变更，最重要的是移除了对 JSX v3 的支持、采用新的运行时包结构（以@rescript/runtime取代原有设置），以及 API 命名变更（原先以Exn结尾的函数现在改为以OrThrow结尾）。迁移工具包含一个 codemod，可自动完成机械式的重命名以简化过渡过程。

由于引入了平台专用包（如@rescript/darwin-arm64、@rescript/linux-x64和@rescript/win32-x64），安装体积可以大幅缩小。npm 现在只会安装与操作系统和架构匹配的二进制文件，从而加快安装速度，并减小 CI 流水线中的缓存占用。

围绕 ReScript 12 发布相关的新闻，社区讨论尚不热烈，但该语言仍持续将自身定位为 TypeScript 的替代方案，提供更强的类型保证。在 Reddit 上，有用户评论称这是个好消息，因为他曾以为该项目已经停止维护。也有用户质疑为何应选择 ReScript 而非 TypeScript，一位评论者给出了如下对比：

TS 仍然包含 JavaScript 的所有缺陷，并且其设计本质上是不健全的。ReScript 是用 OCaml 构建的，因此你可能会获得市面上最快的编译器之一，再也不用等待 5 分钟才能完成生产构建。

较早的对比指出，ReScript 的类型系统是健全的，能保证绝不出错；而 TypeScript 的类型系统仅仅基于推测，有时在运行时仍可能出错。ReScript 的编译速度也远快于 TypeScript，尽管 TypeScript 在生态系统采用率和 JavaScript 互操作性方面仍占优势。

ReScript 是一门开源的编程语言，可编译为高效且人类可读的 JavaScript。它最初源自OCaml，现已演变为拥有独立语法和工具链的独特语言。ReScript 在 React 开发中尤为流行，提供一流的 JSX 支持和极速的编译器，可轻松扩展至任意规模的代码库。

ReScript 12.0 Released with New Build System

免费云开发资源，1 亿混元 token 额度！腾讯重磅推出 AI 小程序成长计划

作者: 纯情
时间: 2026-01-05
分类: 资讯
评论

随着 AI 大模型技术的爆发，应用开发的门槛正以前所未有的速度降低。

为进一步激活 AI 垂类应用的创新活力，微信小程序正式推出“AI 应用及线上工具小程序成长计划”。

该计划将提供云开发资源、AI 算力、数据分析、广告变现及流量激励等全方位支持，帮助开发者将想法快速转化为可落地、可破圈、可盈利的产品，陪伴开发者完成从“0 到 1”的孵化与“1 到 100”的商业跨越。

全方位扶持上线，携手开发者开启小程序 AI 应用元年

过去，许多“小而垂直”的用户需求常因开发成本过高或变现路径不畅而被忽视。如今，AI 不仅重塑了交互方式，更让极速开发成为可能。更令业界振奋的是，随着 iOS 虚拟支付在微信生态的全面落地，过去制约工具类应用变现的“短板”已被补齐，虚拟服务与订阅模式的商业闭环已经形成，这意味着 AI 应用在小程序内“跑得通”之余，也能“赚到钱”。

本次成长计划的激励期为 2026 年 1 月 1 日至 2026 年 12 月 31 日，覆盖了开发、运营、变现等核心环节：

免费的云开发资源：微信云开发提供完备的小程序后端能力（数据库、云函数等），支持对接 AI 大模型和 Agent；新开发者可免费创建 6 个月的个人版云开发环境，已有云开发环境的开发者可领取大额抵扣券；
免费的 AI 算力支持：激励活动期间，开发者可使用总计 1 亿 Token 的腾讯混元最新文生文模型混元 2.0 额度，以及 1 万张混元文生图模型额度，后续腾讯混元最新的模型也将陆续上架，方便开发者直接使用；
免费的数据分析能力 &专属流量激励：运营增长方面，平台免费开放 We 分析专业版一年，帮助团队基于深入数据洞察实现业务增长；同时，在公众号图文发布小程序相关内容并带上 #来微信做个小程序话题，有机会获得更多公域流量；此外，「微信-发现-小程序」等专属曝光入口，将帮助优秀的线上工具小程序被更多用户看见；
更友好的商业化变现：商业化方面，平台将开放安卓、iOS、鸿蒙等全终端的虚拟支付与会员订阅能力，并给予限时优惠费率；同时，支持广告变现“免开发智能接入模式”，无需复杂开发，系统可自动推荐小程序内的广告展示位置并支持实时预览、上线，让变现更加顺畅。

所有线上类应用均可参与计划，包括线上工具、AI 原生及娱乐类小程序等。小程序开发者可以登录「微信小程序后台（mp.weixin.qq.com）-行业能力-AI 小程序成长计划」参与计划，新开发者完成注册后即可参与。

众多标杆案例涌现，小程序成为 AI 独立开发的“第一站”

相比 App 动辄数月的开发周期，小程序独立开发具备周期短、上线快的优势。加上微信内的聊天转发、朋友圈、公众号等社交分发路径，优质产品容易形成口碑传播，甚至引发跨平台讨论，转化率远高于传统的 App。

目前，小程序生态内已经涌现众多极具代表性的 AI 原生应用。例如《猜盐》小程序利用大模型将信息游戏化，吸引用户持续参与问答互动，并实现极佳的用户自发口碑传播；《传图加画框》小程序通过 AI 生图能力为书法、国画、油画等图像作品加框美化，通过 AI 能力为艺术作品增色添香；《风格转换器》小程序凭借 AI 绘画功能，成为微信生态内具有代表性的 AI 生图小程序，不仅用户活跃度高，更成为社交平台刷屏内容的源头；《金攒攒》小程序也凭借着简洁的界面与直观的操作，让黄金的资产管理变得轻松愉快。

此外，如《配音神器》、《写作鹅》、《作文说》等工具类小程序，正在深入视频创作、教育、文字工作等细分领域，展示出 AI 与垂直场景结合的巨大潜力。

在 AI 能力快速迭代的当下，技术门槛已不再是鸿沟，创意的重要性正愈发强化。微信小程序正聚焦于通过资源加码与政策激励为开发者的创意和实践铺平道路，小程序生态正愈发成为 AI 应用快速验证的最好阵地。

“推出成长计划仅仅是一个开始，未来，平台将持续加码，聚焦生态基建，助力每一位心怀创意的开发者将想法变为现实。” 微信团队表示。

2026“企业 Agent 上岗元年”？零一万物六大判断定义企业多智能体，不再沿用大厂标准化产品模式”

作者: 纯情
时间: 2026-01-05
分类: 资讯
评论

1 月 5 日，零一万物正式对外发布了《中国企业智能体 2026 六大预判》，并对外展示了其在企业级多智能体方向上的最新探索成果“万智 2.5 企业多智能体”。

企业智能体 2026 年六大预判

零一万物中国区解决方案和交付总经理韩炜表示，企业智能体正从“单点工具”进化为“智能管理系统”。多智能体架构的本质，是重构了企业的组织形式，让 AI 从“单点提效”转向“全局优化”。这不仅是技术的跃迁，更是组织生产关系的重组。

基于与某世界能源巨头、友邦等多家行业头部客户的 AI 变革实践，零一万物总结出中国企业智能体演进的六大核心预判。

预判一：智能体从“一人一工具”进阶“一人一团队”

过去单点 AI 工具解决的是任务自动化问题，而多智能体推动的是整个企业组织的系统性智能化。

智能体不仅仅是执行单元，更能将公司内部的优秀能力沉淀成可复用、可组合的业务资产。当智能体可以将顶尖人才的能力进行拆解和重构，同时封装成可复用的能力模块，根据实际生产场景进行落地和执行，企业将不再受限于“招聘-培养-流失”的人才循环。一个顶级销售、资深律师、王牌产品经理的专业判断力，可以被高效复制和执行、24 小时运转，在毫秒级时间内部署到全球任意分支机构。

零一万物提出，智能体团队将像水一样具有超强的适配度和延展度：业务高峰期自动扩容，低谷期静默待命。这种“弹性超能力”让中小企业首次拥有了与巨头同台竞技的“不对称优势”。企业应通过多智能体实现业务能力的“软件化”与“服务化”（CaaS，能力即服务），推动整个企业组织的智能化。

预判二：多智能体需具备 TAB 三要素

零一万物认为，下一代企业的竞争优势，将取决于其将业务能力转化为数字资产的速度。零一万物提出，多智能体必须具备 TAB 三要素：

AI Team（团队作战）：人和智能体、智能体和智能体之间可以进行智能协同，1 人指挥 1 支智能体团队成为可能，进而突破“人才瓶颈”，实现“能力软件化”的跃迁，让企业摆脱对单一专家的依赖，实现能力的弹性伸缩。
AI Auto-pilot（业务裂变）：可以根据实际核心生产业务生产场景进行智能规划，过程可控可查，确保交付质量。开启个人业务能力指数级增长，企业业务线容易在垂直深度和规模化增长中找到平衡点。
AI Business（商业重构）：多智能体流程、产出均可沉淀，通过提取并重构团队能力模块，实现商业模式的原子颗粒度重构，这正是零一万物助力企业在 AI 时代实现“能力即服务”（CaaS）的核心逻辑。

多智能体将企业的核心能力解构成可组合的能力模块，像乐高积木一样自由拼装。

预判三：中国将成为全球多智能体落地的“超级引擎”

中国拥有全球最完整的产业链、全球领先的开源模型、超大规模市场及丰富的复杂业务场景，为企业级多智能体提供了天然的试验田和进化土壤。这不仅是一次“弯道超车”，更是一场“换道超车”。

从底层技术的角度来看，中国模型的开源实践正在推动底座平权。中国在开源大模型领域的全球领先地位，为企业提供了具备全球竞争力的技术基座，降低了 AI 应用门槛，推动技术普惠和生态共建，使得更多企业能够平等、高效地接入智能转型浪潮。

同时，基于门类齐全的制造业体系与超大规模的消费市场，中国有望实现从 “世界工厂”到“智能体工厂” 的跃迁。零一万物强调，中国企业在智能化转型中已不再满足于使用通用模型，而是需要深度结合行业知识、业务流程的“业务级智能体”。

预判四：“一把手工程”是赢取 AI 红利的关键路径

参与企业 AI 数智化转型不是技术部门的单点试验，而是企业战略与组织架构的系统性重构。零一万物认为，单点突破仅是开始，如果局限于“局部优化工程”，反而会制造出新的“数据孤岛”。只有 AI 科技公司与企业的深度共创，全局突破，才能更全面兑现“变革红利”。

这一过程中，需要具备“技术信仰型领导力”的一把手，以全局价值导向克服既得利益，推动 AI 变革。这种“技术理解力”也将成为领导力的新护城河。传统 CEO 可以不懂代码，但 AI 时代的 CEO 必须懂“AI 的可能性边界”。就像乔布斯不需要会写 iOS 代码，但他必须知道“多点触控”能重新定义手机。

零一万物表示，在与头部客户的合作中，“一把手工程”模式的价值已经得到验证，在后续的调模型、找场景、搭应用的落地过程中，FDE (Forward Deployed Engineer)成为承接一把手工程的关键。既懂代码又懂业务，是技术管理复合型人才，像特种部队一样深入一线，用代码解决商业问题，用商业思维优化技术方案。

预判五：智能体反哺推动企业数字基建“自主进化”

智能体不仅是数字化的“消费者”，更将成为企业数据与知识体系的“建设者”。通过自动标注、数据清洗、行为反馈等机制，智能体能在运行中持续丰富企业知识库、优化决策模型，形成“数据飞轮”，并且在未来形成企业“记忆库”。这种自主进化机制将大幅缩短企业从数字化向智能化跨越的周期。

预判六：2026 年将成为企业多智能体规模化“上岗元年”

随着智能体技术成熟与场景深化，2026 年企业竞争的焦点将从“招多少人”转向“指挥多少硅基军团”。多智能体将率先在数据基础完善、业务流程复杂、协同要求高的领域实现规模化部署。相应地，“智能体运营师”将成为企业新兴关键岗位，负责智能体的部署、训练、评估与优化。

对于人类员工而言，决策力成为知识工作者的核心竞争力，具备综合判断力与决策审计力的“复合型员工”将成为人机协同的核心。而对于企业而言，企业的核心竞争力将体现在三方面：早（尽早引入）、快（选用最先进 Agent）和有闭环数据（利用自身数据持续训练）。

“我们不再沿用大厂销售标准化产品的模式”

基于上述六大预判，零一万物万智企业大模型一站式平台（以下简称万智平台）正式升级至 2.5 版：企业级多智能体成为平台的核心企业应用之一，好比 Office 之于 Windows 系统。

据悉，针对企业场景中动态、开放的难点，万智 2.5 采用了“代码先行、模型驱动”的硬核架构。相比传统只会在画布上按照既定工作流运转的通用型 AI Agent，万智平台支持通过 MCP 协议和安全沙箱环境，不仅能确保多智能体执行时切合企业真实生产场景，且能实现工业级的稳定性。

韩炜表示，“零一万物团队与大厂团队模式不同，我们不再沿用大厂销售标准化产品的模式，而是更注重基于客户需求进行梳理和设计，将其转化为产品原型。这对解决方案团队的能力要求非常高。随后，我们会将原型交付给产品与研发团队，以类似 FDE 的模式高效推进，迅速为客户交付可用的演示版本或 PoC（概念验证）场景。通过这种方式，我们持续缩小自身与客户之间的理解落差。

他补充道，以往大厂的产品与客户需求之间存在显著的理解落差，这常常引发交付问题，导致最终成果与客户预期不符，需求范围不断蔓延。这也正是大厂在承接定制化项目或智能体相关项目时持续亏损、意愿不强的原因之一。大厂往往认为此类业务规模效应有限，而零一万物正在积极探索的新模式，能够持续降低交付成本、缩减与客户的沟通差距，并在此过程中寻求可行的盈利路径。这是我们团队的定位以及我所负责工作的核心方向。”

在零一万物的产研版图中，企业级多智能体的实现依托于基模-框架-应用“三位一体”的整合：

底层是开源基座模型与行业垂类模型，以及零一万物两年来所积累下的模型训练方法论；
中间是企业级多智能体技术框架，负责将模型封装为角色化、工具化、可协同的 Agent 团队；
顶层则是面向行业的“超级员工”与解决方案，如 AI 招商专员、AI 保险顾问等，直接对接业务部门并承担 KPI，为企业客户带来可量化的价值。

整合过往的合作经验，零一万物也为企业客户规划出了企业多智能体进化“三步走”布局：

第一步，确立“一把手工程”下的全局策略。零一万物认为，AI 数智化转型绝非单纯的技术试验，而是深刻的业务重塑。企业必须由 CEO 亲自挂帅，将多智能体的表现与企业的核心 KPI 深度绑定。在落地初期，便要敢于切入高频、复杂、多部门协作的核心业务链路，以全局视角指引技术与业务的融合。

第二步，引入 FDE 模式跨越组织鸿沟。针对转型中常见的部门墙与数据孤岛，企业需借助前置工程师（FDE）深入一线“破壁”。这一阶段的关键在于防范系统性熵增，拒绝盲目堆叠智能体数量，而是通过精细化管理，紧盯准确率、响应延迟与 Token 效能，避免陷入“内耗型架构”。

第三步，通过协同进化跨越技术鸿沟。企业应摒弃盲目的“榜一模型崇拜”，拥抱开源多模型混合架构。通过夯实目标规划、系统调用、安全审计、多模型协同四大核心能力，企业将构建起稳固的三层架构：以开源及行业大模型为“底座层”，以企业级多智能体技术框架为“中枢层”，最终在应用层孕育出能够真正解决问题的“超级数字员工”。

零一万物技术与产品中心副总裁赵斌强表示，2026 年，企业多智能体上岗的过程，就是将“TAB 三要素”转化为生产力的过程。而这其中的关键胜负手，就在于以“一把手工程”推动技术与组织的协同进化。零一万物的目标，正是基于万智 2.5 开放平台，助力企业 AI 转变为能够持续产生复利、驱动商业模式创新的核心资产，从而在这场以“组织智能”为核心的转型浪潮中，赢得关键加速度。

结束语

对于 Agent 的未来发展，韩炜表示，长期有可能“模型即应用”或“模型即 Agent”最终会实现，就是最终 AGI 的时代，但这个时间线有多长还不确定。从短中期来看模型和应用之间还是有比较大的差别，Agent 有记忆能力、调用工具能力，现在还有通过 Multi-Agent 对抗式分析的能力，这是单一模型可能很难具备的。特别针对企业场景而言，模型不是 Agent，模型只是 Agent 的“大脑”。大脑之外至少还缺四样关键的东西：

一是安全、可控、合规。这个对于企业来说是非常重要的，企业不仅仅关心会不会回答，更重要的是答错了谁来负责，Agent 需要基础于特定的企业记忆（Enterprise Memory），了解企业专属边界。

二是工具和系统的能力。模型本身不会调用你的 CRM，不会登录你的内网系统和下单采购，Agent 必须具备稳定的工具调用能力，去保证跨系统调用的准确率和效率。

三是包括 Multi-Agen 在内的企业级 Agent 里面，特别需要智能体做目标和任务的规划。模型只会天生对下一句话去负责，Agent 需要对业务目标负责，企业级 Agent 需要理解 KPI，比如签单量、周转天数、风险敞口等 KPI 的目标，把这些目标拆解成目标和任务，并且在执行过程当中动态调整计划。

四是多模型、多角色的协同。在真实的企业环境中往往是多模型共存，包括自研模型、开源模型、商用模型等，不同的场景需要选用不同的模型或者不同参数量的模型，没有最好的模型，只有最适合场景的模型，这个可能是比较重要的。企业级多智能体需要做的是根据任务选择不同的模型，可能不同的子 Agent 用不同的模型，包括主 Agent 也用的并不一定是参数量特别大的模型，这是基于实际场景的情况。另外，在多智能体的中分工协同互相校对也很关键。

零一万物认为，AI Agent 颠覆性价值在于行业重构，重点将从降本转向增效。

派早报：Clicks 推出 Power Keyboard 和 Communicator 手机

作者: 纯情
时间: 2026-01-05
分类: 资讯
评论

Clicks 推出 Power Keyboard 和 Communicator 手机

1 月 2 日，科技初创公司 Clicks Technology 发布了继实体键盘保护壳之后的首批新品。

其中，Clicks Communicator 手机被定义为一款「现代通讯伴侣」，定位类似于 Kindle 之于 iPad，主要作为用户的第二部手机使用。该设备运行 Android 系统，直板设计，配备 4 英寸屏幕与实体全键盘，重 170 克，厚 12 毫米。为了减少信息干扰，其系统界面由 Niagara Launcher 深度定制，摒弃了传统的应用网格，转而采用极简的消息聚合中心。硬件方面，Communicator 有 5000 万像素后摄、2400 万像素前摄，保留了 3.5mm 耳机孔、静音开关与 MicroSD 卡槽，侧面设有可根据通知类型改变颜色的信号灯按键，搭载 4000mAh 电池。处理器和存储参数未公布。该机起售价为 499 美元（约合人民币 3487 元），目前提供 399 美元的早鸟预订价，预计将于今年晚些时候发货。

另一款新品 Clicks Power Keyboard 则是蓝牙键盘与移动电源二合一设备。它支持 MagSafe 与 Qi2 无线充电标准，可以磁吸在手机背面。键盘采用滑盖式设计，除了作为手机的实体键盘外，还支持通过蓝牙 5.4 连接至多三台平板电脑、智能电视等设备。Power Keyboard 重 180 克，厚 15.2 毫米，电池容量为 2150mAh，其中 500mAh 划分给键盘使用。该产品定价 109 美元（约合人民币 790 元），早鸟价 79 美元，将于今年春季正式发售。

Pebble 推出 Round 2 手表

1 月 2 日，智能手表品牌 Pebble 发布 Pebble Round 2。作为品牌重启计划的一部分，Round 2 复刻了 2015 年推出的 Pebble Time Round，旨在通过更现代的技术重现这款当年「业界最薄」的圆形手表经典设计。

在硬件设计上，Pebble Round 2 解决了初代产品边框过宽的痛点。新品在保持 8.1mm 超薄不锈钢机身的同时，搭载了一块 1.3 英寸彩色电子墨水屏，像素密度较前代翻倍至 283 ppi，且具备背光功能。Round 2 保留侧边实体按键，让用户可在会议等场景下通过触觉盲操作。

为实现 10 至 14 天的续航，Pebble Round 2 在功能上做了明显的取舍，仅保留计步、睡眠追踪等基础健康功能，未配备心率传感器，因此不适合作为运动追踪设备使用。系统方面，它运行开源的 Pebble OS，兼容数千款表盘与应用，内置麦克风支持语音输入与回复，但受限于苹果系统限制，该功能目前主要面向 Android 用户，iOS 端的支持将率先在欧盟地区开放。此前，Pebble 已推出过一款具备录音转写功能的低成本 AI 智能戒指，官方表示未来计划将类似的 AI 能力引入手表端。

该产品定价 199 美元（约 1390 元），即日起在官网开启预售，预计将于今年 5 月发货。对于此前已预订方形表盘 Pebble Time 2 的消费者，官方也提供了保留排队位次改订 Round 2 的选项。

DeepSeek 发论文介绍高效训练技术 mHC

1 月 1 日，DeepSeek 发布了一篇由创始人梁文锋合著的技术论文，提出了一种名为「流形约束超级连接」（Manifold-Constrained Hyper-Connections, mHC）的新型深度学习架构。该研究旨在通过优化计算效率，在算力资源受限的环境下，以更低的成本训练更大规模的模型。

mHC 技术是对「超级连接」（Hyper-Connections）架构的进一步改良。超级连接最初由字节跳动研究人员于 2024 年 9 月提出，旨在改进由微软亚洲研究院何恺明等人发明的 ResNet（残差网络）主流架构，以解决深层网络中的信号衰减（信息在传递过程中「声音」越来越小，深层网络接收不到有效信息）与模型坍塌（无论输入什么不同的数据，层层处理后变得相似甚至趋同）。

DeepSeek 团队指出，虽然字节跳动的方案提升了网络复杂度，但在大模型训练中忽略了日益增长的显存成本，导致实际扩展性受限。就此，DeepSeek 的 mHC 方案通过引入特定的流形约束，让数据流仅在特定的几何轨迹（流形）上运行。这在保留超级连接优势的同时，成功解决了内存与成本瓶颈，实现了「几乎可忽略的计算开销」。论文数据显示，DeepSeek 研究团队在 30 亿、90 亿及 270 亿参数规模的模型上测试，实证结果表明 mHC 具备优于传统架构的扩展性，且能维持大规模训练的稳定性。

该论文由梁文锋本人账号上传至 arXiv。梁文锋此前仅亲自发布过 DeepSeek 最重要的技术论文（如 R1 和 V3 模型相关研究），且被列为本文的最后一位作者，这一举动证实了他仍深入参与核心研发，也被视为 DeepSeek 下一代核心模型技术路线确立的信号。目前市场预期 DeepSeek 可能延续 R1 的发布策略，在 2 月中旬的春节假期前发布新款大模型。

华硕通知渠道今起涨价

据 VideoCardz 报道，华硕于去年 12 月 30 日向合作伙伴发出《2026 年产品价格调整说明函》，宣布将于 2026 年 1 月 5 日起实施价格调整。

该函称，受全球供应链结构性波动影响，多项关键零组件正承受严峻的成本上升压力，特别是 DRAM 内存和 NAND。此变动源于「全球原厂产能配置调整」「先进製程投资成本增加」，以及「AI 算力需求导致的产业结构性缺口」。

尽管华硕未列出具体受影响的型号，但明确表示将「针对部分产品组合策略性价格调整」。由于此次调价生效日期恰逢 2026 年 CES 开幕前夕，业界分析认为，华硕即将在 CES 上发布的新一代硬件产品，特别是 AI PC 及电竞设备，将首当其冲，并可能确立新的市场价格基准。

华硕强调，此次调价是公司在「长期吸收与因应成本压力后所做出的必要决定」，目的是为了「确保稳定供应、维持品质与服务水准」。针对后续影响，华硕业务代表将主动联系合作伙伴，提供详细说明并协助规划最适切的因应方案或配置建议。

华硕公关部门证实了该文件的真实性，但向媒体澄清，这是一份仅供渠道合作伙伴参考的内部商业沟通文件，并非面向公众发布的正式新闻稿。

新一批作品进入公有领域

2026 年 1 月 1 日，全球迎来一年一度的版权释放重要时刻。弗洛伊德、爱因斯坦、汤因比等名家名作分别在美国、欧洲或中国等司法辖区进入公有领域。

在美国，随着 1930 年作品保护期的终结，福克纳的《我弥留之际》、弗洛伊德的《文明及其不满》等著作，《西线无战事》等电影进入公有领域。蒙德里安与保罗·克利的画作、初代「贝蒂娃娃」、迪士尼最早期的普鲁托（当时名为 Rover）形象均不再受版权限制，基于这些早期素材二次创作成为可能。

在实行「作者有生之年加 70 年」版权期限的司法辖区，如欧盟、英国、俄罗斯，1955 年逝世作者作品保护期届满。这意味着物理学家爱因斯坦、《人性的弱点》作者卡耐基、诺贝尔文学奖得主托马斯·曼的作品在这些地区将不再受版权限制。

在实行「作者有生之年加 50 年」版权期限的司法辖区，如中国及亚洲和非洲大部分地方，1975 年逝世的作者作品保护期届满。这包括蒋介石、历史学家阿诺德·汤因比、苏联作曲家肖斯塔科维奇、政治哲学家汉娜·阿伦特等。

比亚迪超越特斯拉成为 2025 年全球电动车销量榜首

据《纽约时报》报道，2025 年，特斯拉失去全球最大电动汽车制造商的位置，首次被比亚迪超越。根据 12 月 31 日公布的数据，特斯拉全年交付量同比下降 9% 至 164 万辆，其中第四季度销量受政策冲击暴跌 16%。相比之下，比亚迪全年纯电车型销量增长 28%，达到 226 万辆，并凭借价格优势在亚洲、欧洲和拉美市场实现了显著扩张。

特斯拉销量的下滑主要受到美国政策急剧转向的冲击。尽管马斯克在 2024 年大选中大力支持特朗普，但共和党重新执掌白宫和国会后，迅速废除了最高 7500 美元的联邦电动车税收抵免，并着手削弱清洁空气法规。特斯拉作为占据美国电动车市场 45% 份额的绝对主力，成为此项政策变动的最大受害者，导致其第四季度交付量从上年同期的 49.6 万辆锐减至 41.8 万辆。

除外部环境恶化外，特斯拉自身的产品迭代滞后也是关键因素。其主力车型 Model Y 自 2020 年上市以来未见重大更新，新推出的 Cybertruck 销量惨淡。在欧洲市场，特斯拉的销量已被大众汽车反超。此外，马斯克将公司重心转向自动驾驶出租车（Robotaxi）和人形机器人，但尚未产生显著营收，且在自动驾驶落地进程上已落后于谷歌旗下的 Waymo。

行业分析师预测，2026 年美国电动车市场将持续低迷，需等到 2027 年更多低于 3 万美元的廉价车型上市后才有望回暖。尽管汽车销售疲软，但华尔街因看好其在自动驾驶领域的长期潜力，特斯拉股价目前仍维持在历史高位。与此同时，比亚迪虽然因高关税壁垒无法进入美国市场，但已确立了其在全球其他市场的领跑地位。

看看就行的小道消息

近日，多名 Reddit 用户抱怨多邻国通过实时活动功能显示订阅广告，而这是 App Store 审核规则禁止的行为，可能被下架处理。多邻国后来似乎停止了广告展示。

据 StackOverflow 官方数据，该站在 2025 年 12 月仅新增 3862 个问题，已低于初创不久时 2008 年 8 月的水平。

据路透社查阅的 Meta 内部文件显示，面对全球监管机构打击社交媒体诈骗广告的压力，Meta 制定了一套名为「全球剧本」（Global Playbook）的应对策略。文件揭露，Meta 并没有全面验证广告主身份、根除诈骗，而是通过操纵搜索结果，使监管机构难以发现违规广告，以此通过合规审查。例如在日本，Meta 团队发现监管机构会通过特定关键词（如名人姓名）在公开的广告资料库中搜索诈骗广告，于是在监管审查前针对性地清洗相关搜索结果，制造出诈骗广告已大幅减少的假象。此外，当一地加强监管时，算法会自动将诈骗广告流量导向其他监管较松的地区。此前，Meta 曾因 Facebook 和 Instagram 上泛滥的投资诈骗和 AI 合成名人代言虚假广告而面临日本、新加坡等国政府的严厉质询。
1 月 3 日晚，雷军在新年直播中披露，2025 年小米汽车交付量目标原本定的是 30 万辆，中间提高到 35 万，最后实现超过 41 万辆，并宣布 2026 年小米汽车交付目标为 55 万辆。当晚，雷军直播四个小时，随工程师团队完整拆解了一台 YU7。拆车结束后，雷军集中回应了近期围绕小米汽车的多项舆情与争议。关于「1300公里只充一次电」「200公里瞬间刹停」等营销表述质疑，雷军表示，相关说法源自驾驶体验展示视频，主要用于展示 SU7 的续航、刹车性能，有完整视频作为佐证，但在传播过程中被「断章取义」。雷军还承认「小字营销」是行业陋习，接受批评，已于去年 11 月要求各业务团队尽量使用大字直观展示。

少数派的近期动态

年末「夯」一下！少数派 2025 年度盘点正式上线。
少数派会员年终福利来袭，引荐比例限时上调至 15%，邀请好友享 85 折入会优惠。参与活动
好玩又实用，还有迪士尼授权配件可选，少数派「扭扭宝」充电宝火爆开售。来一个试试
GAMEBABY for iPhone 17 Pro & 17 Pro Max 系列现已上市。进一步了解
《蓝皮书》系列新版上架，一起探索全新 iOS 和 macOS 的精彩。试读并选购

你可能错过的好文章

线下活动｜Global Game Jam 2026 广州荔湾站招募

作者: 纯情
时间: 2026-01-05
分类: 资讯
评论

什么是 Game Jam

Jam，原意是「果酱」、「交通堵塞」等。把语境替换到音乐文化中，则有着「几个音乐人聚在一起，即兴演奏、创作」的意思。那么「Game Jam」，则是「一群游戏爱好者聚在一起，即兴设计、开发游戏」。

Global Game Jam (GGJ) 是一年一度的全球最大游戏极限开发活动，在世界各地的众多线下站点同时举行。创作者需要在规定的时间内（常见为 48 小时），根据大会的主题给出主题，完成一款体现核心玩法的游戏 demo。GameJam 活动不仅可以在限定的时间内激发开发者的情感创意，同时还是一个大型的创作者交友与交流活动，策划、编程、美术、音乐等不同职能的创作者在此相聚，在有限的时间内创造无限的可能性。

从 2009 年第一届 GGJ 创办以来，在一次次短暂的聚会之后，不少 demo 也获得了持续的开发，最终推出正式版本，出现在更多人的面前。

Game Jam 同时也是锻炼团队协作的好机会，你可以提前约上朋友一起参与，又或是在现场和新认识的小伙伴临时组队，在 48 小时的限时协作中互相了解、磨合。不少开发团队成员的结识，也都源自线下 Game Jam 活动。

为什么选择 Global Game Jam？

Game Jam 类活动其实有很多，而 Global Game Jam 是全球规模最大、影响力最深的线下 Game Jam 活动，每年吸引超过 100 个国家的数万名开发者参与，2009 年至今共有 132 个国家和地区的超过 47 万名开发者参与了此项活动，在 48 小时内完成了 101,246 款游戏。

I8cPb9Y9soxKArxVqqGcT0rMnqj — 图源：万物破元游戏博物馆

关于荔湾站

荔湾站发起人浜浜（苏浩浜）是一个参与了 10 年 GJ 的广州本地人，从2015年第一届广州 GGJ 至今，从平面美术到 TA，参与并组织了无数场游戏开发者活动。这一次，他想做一场 20～30 人的小型经典 Jam，保留路演和After Party，还原印象中 GJ 最初的味道。

老城新区：老城区公园活化社区，周边成熟的社区配套与人文景观，好吃的、好玩的不在话下；Jam完还能逛吃逛吃，灵感与味蕾双重满足
助力光环：精酿现场供应创作灵感，更有喵星人鼓励师常驻，夜晚可能有专业DJ闪现演出，开发配打碟、微醺GJ也许不是梦
Indie之味：独具氛围的场地，与人文景观、文艺地标为邻。专业级多媒体设备助力路演，人人齐当产品经理；在这里，你的声音会被听见

站点场地信息

Heim精酿酒馆 / 少数派广州体验店：一个能够听音乐、放松、畅饮、交流、撸猫的线下场地，毗邻 1200 书店。这里不只有创意，还有啤酒、猫咪和志同道合的伙伴。

活动详情

时间：2026年1月30 ～ 2月1日（具体日程参考活动行页面）
地点：广州市荔湾区 Heim精酿酒馆（1200 书店附近，报名后有详细指引）
费用： 100元/人，一人一票（通过活动行购票，见文末）
开放时间：场地并非 24 小时开放（具体开放时间早上9点至晚上10点）
装备提示：请勿使用台式电脑等功耗较高、体积较大的设备；请自备排插等相关设备

谁可以参加？

须年满18岁，只要想参加都可以，但非常建议对 GameJam 有事先了解
建议：游戏开发者、程序员、美术设计师、音乐人、策划、写手等创意工作者
尤其：独立游戏爱好者、想尝试做游戏的新手、寻找队友的独狼
欢迎单人或组队报名！也可报名后现场组队！

你需要准备什么？

笔记本电脑及电源
创意和热情
有线插座（重要！）
耳机（建议，保持现场安静）

报名方式

通过活动行链接 https://hdxu.cn/1DCYu（或扫下面的二维码）购买入场票，开发者请选开发者票，想来看看路演和试玩的，可以选择观众票，一人一票；

前往Global Game Jam官网 https://globalgamejam.org/ 注册账号（指引另附）
搜索关键词" Liwan"加入“GGJ China 2026 × CiGA – Guangzhou - Liwan”站点或直接前往https://globalgamejam.org/jam-sites/2026/ggj-china-2025-ciga-guangzhou-liwan加入
联系站点负责人浜浜（微信：13508431263），加入站点的筹备群

2026 年的第一个月，在广州老城区里，期待创意的现场碰撞，产生独具魅力的作品。

小米 Buds 6 半入耳降噪真无线耳机体验

作者: 纯情
时间: 2026-01-05
分类: 资讯
评论

这篇文章是 TDS Studio 在少数派上的第十六篇文章，依然是全平台首发。虽然迟到了，祝你新年快乐。

我们近年来对于小米的音频产品其实大多数都没给出多么高的综合评价，它们或多或少都存在一些问题，尤其在早期，稳定性往往也不是尽善尽美。在时隔近一年半之后，我们又是首发购入了最新一代小米旗舰半入耳 TWS，进入 Buds 6 时代的小米，能否补足 Buds 5 时期的问题，佩戴上不那么容易滑脱，降噪是否可能提升一些，并做出更完善的基础调音，这些都是我们关心的。但你可以看到我们的评分，所以……我们还是详细来看看。

包装与配件 | Package & Accessories

包装还是小米音频产品的老样子，比较小巧的天地盖纸盒，通体白色，表面有设计一次性封膜的拉手贴纸——虽然非常容易拉断就是了。内部的配件只有一条 USB-C to USB-A 的短充电线，的确半入耳产品也不太需要更多的内置配件。首发购入的时候平台也赠送了我们之前在小米开放式耳机 Pro 购入时类似的皮质收纳包。这个收纳包有轻度的抗压性，拉链顺滑度一般，表面有类似 SU7 Ultra 的双条纹图案。然而，这个包显然不是给 Buds 6 设计的，Buds 6 在里面会乱晃，我怀疑就是给我来了个开放式耳机 PRO 的包……

设计、佩戴表现与声学结构 | Design, Fit & Acoustic Structure

小米 Buds 6 共有月影黑、钛光金、珍珠白、星云紫四种配色。根据我们在小米之家线下看到的情况，Buds 6 前三种配色跟过去的小米耳机其实没有特别大的区分度，所以我们自然是购入了星云紫版本。它的实物观感跟 SU7 的霞光紫有相似之处，质感上都有着类似金属漆面的感觉，而 Buds 6 的这个紫色会更加浅一点，甚至有点往索尼的玫瑰灰那个方向靠近的趋势。我个人对于这个新颜色还是挺喜欢的。

充电盒的体积仍然比较小，像是一块小香皂，精致程度足够高。基本的形状跟 Buds 5 类似，依然由三种质感拼成，上盖为抛光、底座为磨砂的阳极氧化质感，盒内则为磨砂纯色塑料，不同点在于上盖的电镀改成了类似烤漆的质感，不再凸显指纹，对紫色来说也更有高级感。开盒的手感不错，有明确的弹性反馈，配对按键位于盒子底部，按下反馈的扎实程度良好。

耳机在盒内仍然是「趴着」的，但是这次你不能直接让耳机靠上去就完事儿，而是「半靠、半插入」地让耳机放进去，磁吸力度倒是没问题。充电触点回到了底部，不如上代容易清理。

耳机本体是基于 pods 形态半入耳结构进行调整，腔体比较偏向于扁圆而非椭圆，相对饱满，而前腔的突出程度较低，相对比较扁平。接触耳道口的部分仍然是磨砂，但这次不会像上代那样可能容易松脱。对于大多数人来说，Buds 6 的佩戴还是较为舒服的，且我个人觉得比 AirPods 4 更无感一点，但是半入耳很依赖耳道口耦合，建议还是线下找个小米之家多试试。单边重量 4.4g，比上代稍重 0.2g，但是实际佩戴并不会有明显感知。

小米 Buds 6 支持 IP54 级别的防尘防水，作为半入耳耳机，还算满足使用。

腔体并没有什么被动隔音能力，且这次小米强调了腔体气流通路的优化，这也意味着，嗯，更加开放了一点。

操作与软件端功能 | Control & APP

小米 Buds 6 的操作是依靠捏动柄部的触控区域进行的，识别区域有专门的凹槽用于盲操，不过捏上去并不算舒服，连续多次操作大抵会让指尖不适——这点相较于上代并没有明显改善。默认的逻辑是按压一次控制播放、按压两次下一曲、三次录音、长按切换降噪、滑动控制音量。

佩戴与操作识别的表现有点不太好评，目前在 1.8.9.0 和 1.8.9.5 的早期固件下，我们发现它在摘下暂停的操作会有约一秒的滞后，而佩戴好恢复降噪和播放状态则需要更长的反应时间。它对于操作的识别也是这样，多次点击的准确率还有提升空间，且也会稍微不那么跟手。另一方面，它对于操作反馈的提示音非常难以察觉，结合不太舒服的操作触感，有时候都得反应一下到底这个操作是否真的被准确识别了。

「耳机盒」开关提示音倒是相对响亮一些，且反馈特别快，但是只能是耳机在盒内时才能使用，我们推测这个声音更多来源于耳机本体而非耳机盒。

在米系设备之外，依然是依靠「小米耳机」 app 来进行各项操作与固件升级。基于小米耳机 app，你可以实现降噪控制、声音模式切换、固件更新、录音、自定义操作等功能，目前小米和 Redmi 品牌近两代的 TWS 耳机及其限定版基本都有支持。这个 app 的 UI 设计基本上是 HyperOS 那一套，好不好看另说，逻辑还是清晰的。

这次在传统的响声查找功能（响声还是不大）之外，还加入了苹果的 Find My 网络——我们实际使用下来，它基本和第三方的类 AirTag 体验类似。

我们关心的软件端功能，自然还是录音和翻译。

单边 90min，与上代一致。在进行实际尝试之后，我们也能够看到它的录音文件规格为采样率 16kHz 的单声道 m4a 文件，比特率在 32~35kbps 之间——码率居然有进步（笑），但采样率缩减了，和开放式耳机 Pro 一致，而上代 Buds 5 是 48kHz。实际聆听下来，录音质量只能说是在安静环境录个通话是够用了，但是更进一步不太可能。比特率过低、麦克风拾音能力的限制，使得它的录音表现仅仅是通话水平。受限于通话降噪做得一般，所以嘈杂环境的使用也是问题，我们在通话部分会详尽介绍。

就我们在嘈杂环境录音的样本进行转写，它的准确率也比较低。翻译质量…… 如果转写的文本本身对头的话，翻译的准确度还是足够你进行理解的。同声传译时，它可以选择读取耳机收到的内容还是手机播放的内容，但对于耳机收到的语音主体无法进行准确识别。同声传译的速度有一些滞后，这个就没办法了。

降噪与通话 | ANC & Call

作为半入耳降噪耳机，它天生不具备足够稳定的耳道口耦合以及被动隔音的辅助，所以十分依靠于麦克风的性能以及算法的能力。跟上代类似，小米 Buds 6 在开启深度降噪之后实际效果依然非常有限，只能对于基本的稳定低频噪声有一些处理，无论是降噪深度还是频宽覆盖都比较一般。在嘈杂环境中几乎起不到太多作用，只能是在比较安静的如办公室之类的地方，可以减少一些空调噪声、电脑风扇之类的东西的影响而已。它的降噪可用性相较于 AirPods 4 ANC、Galaxy Buds3 等还有明显距离，甚至 QCY AilyBuds Pro 之类也会有更加明显的降噪实感。总体的降噪感知甚至不如上一代明显。

值得一提的是，它的耳压感并不严重。不过在极其安静的环境下，你能听到降噪模式开关前后的几秒内有短暂的底噪（是伴随提示音出现的），深度降噪使用过程中也会有等级更低但依然可感的底噪存在。

抗风噪方面，小米官方标称的抗风噪是能够搞定最高 12m/s 速度的风，这方面表现还可以。它的抗风噪并不是单独的模式，而是整合在降噪里面。在测试风源开启之后，它会有几秒中的反应时间，随后对于正面的风源有着比较明显的削弱，而侧面、背面的风源则削弱不会那么明显。

通话方面，小米声称通话降噪深度可达 95dB…… 但实际这套三麦降噪的效果，真的是聊胜于无。我们在运营商网络进行通话测试，它的实际通话稳定性还是相当不错的，在同价位属于第一档水准。安静环境里，它的收音是明显偏闷的。在通话状态下，来自侧面与背面的风噪会对于通话主体的清晰度产生一些影响，正面直吹影响相对较小。

综合来看，我们认为小米 Buds 6 的降噪能力依然是不太具备实用性的，在 TDS 降噪综合能力金字塔中可以拿到 In-Ear Medium Level 的分级，且排名在同级别靠后。

信号与续航 | Connection & Battery

作为支持 aptX Lossless 的骁龙畅听认证设备，小米 Buds 6 对于 aptX Adaptive 显然是向下兼容的。我们将基于 Adaptive 进行主要的信号测试。

在 48kHz 档位，在 WLAN 开启或关闭的情况下都很难出现卡顿丢包情况，基本上可以说有着比较出色的信号稳定性表现。在距离八米且有遮挡的状态开始出现卡顿丢包。在 96kHz 档位，卡顿会在约 5.5m 处开始出现。可以认为在信号非复杂环境，Adaptive 的双档位都可以进行近场的稳定使用，聆听体验相对顺畅。在 AAC 连接 iPhone 14 场景下，连接稳定性相对还不错。额外地，它依然有高通平台的老问题，即远距离丢包后会有短暂的声音质量明显下降，靠近后一段时间才会恢复正常。

延迟方面，在默认的状态下以 aptX Adaptive 编解码器信号优先连接 Xperia 5 III，进行流媒体视频和本地视频观看，它的延迟大概控制在正常语速约大于半个字的程度。

它也支持双设备连接，且与 aptX Adaptive 等不冲突。

续航方面，官方标称仅耳机连续播放 3.5h（AAC、降噪开、50% 音量）或 3h（aptX Adaptive、降噪开、50% 音量），在关闭降噪后最长则可以到单次 6h。搭配充电盒最高一共 35h。个人经过标准流程测试下来，以 aptX Adaptive 编解码器 48kHz 档位连接 Xperia 5 III，开启自适应与降噪，设置其他为默认，以 50% 音量连续播放流媒体音乐（Apple Music Lossless）、播客节目（小宇宙），仅耳机续航为 3 小时 12 分钟（标识满电状态开始计入），跟标称值还是有一些差距的。

充电方面，我们依然进行了测试，它可以在 2.5W 左右比较稳定地充电，PD 支持没问题。

空间音频 | Spatial Audio

终于，空间音频是可以与高码率编解码器共存了，但它的空间音频仍然是并非严格 Dolby Atmos 定义的状态。我们还是走标准流程，以下的描述我们基于这样的场景配置：标准测试设备 Xperia 5 III 以 aptX Adaptive 连接，开启耳机的空间音频，固定位置（关闭头部追踪），搭配聆听 Apple Music 的原生 Dolby Atmos 音源和哔哩哔哩的杜比全景声适配视频。

无论哪个场景，小米 Buds 6 都能够比较完整地呈现出脑后的信息量，空间音频的空间呈现在横纵向上终于规整了一些，且边界感相对清晰，这是巨大的进步。不过，在两种场景下，它对于音色改变依然是明显的，你还是可以感知到混响的增加，部分乐器的结像位置产生了变化，现在呈现出的样子像是个「剧场模式」。头部追踪的准确度还行，不会有甩着甩着丢了的问题。

怎么说呢…… 至少空间表现有进步了，下一步把音色问题解决好，我们觉得说不定下一代 Buds Pro，小米能够拿出还不错的方案。现在算是个听上去还挺有意思的「空间化立体声」而非严格的空间音频。我们建议体验空间音频时打开自适应听感来获得比较好的综合感知。

扬声器、声音模式和编解码器 | Driver, Sound Modes & Codec

小米 Buds 6 搭载了一颗 24K 镀金球顶的复合振膜动圈单元，三磁路设计。支持自适应算法动态补偿中低频听感，但在出厂的 1.8.9.0 固件下，我们发现自适应听感开启后有一定可能产生算法 bug 导致偏音，但是并非 100% 复现，且在更新至 1.8.9.5 之后目前还没有出现这个问题。所以如果你手上的小米 Buds 6 也出现了偶尔偏音——尤其是偏左——的情况，欢迎在评论区告诉我们。这个自适应开启之后最大的改变就是总体声压的提高和低频比例变多。

依然是与哈曼联合调音的，包装上也可以见到 HARMAN AudioEFX 的标识，但默认的声音模式不再是 Harman AudioEFX 了，这次小米 Buds 6 延续了开放式耳机 Pro 默认声音预设是「均衡听感」的做法。相较于这个均衡档位，Harman AudioEFX 明显要更加浓郁、厚重，人声略凹，而「哈曼大师」则是加厚低频的同时没有过度影响人声清晰度。在室外聆听时可以适当考虑哈曼大师的选项。除此之外还有三种预设和自定义均衡器，支持 8 个频率点的 ±4dB 调节——相较于上代有缩减。

你可以开启最高 2.1Mbps 的码率，即 24bit / 48kHz 档开启 LE Audio 的 aptX Adaptive LE——当然是限制部分机型支持的。对于其他手机来说，它支持的编解码器为 SBC / AAC / aptX Adaptive / aptX Lossless（1.2Mbps）/ LC3。

声音主观描述 | Sound Description

基于 aptX Adaptive 编解码器 + 均衡听感，关闭自适应，固件版本 1.8.9.5。

低频量感适中略偏少一些，厚度和饱满度都不算高。弹性则相较于 Buds 5 有明显进步，下潜也还可以。收放速度适中，保留的残响不多。氛围烘托的晕染感和浓郁度都比较轻。由于半入耳的特性以及主动降噪并不算明显，Buds 6 在室外会有明显的低频泄漏，即使打开自适应听感依然会有明显的不足感。我们认为为了听力健康考虑，不建议盲目在嘈杂环境把它开到大音量来 get 更多的低频感知。在关闭自适应的前提下，Buds 6 良好佩戴的情况也就只能提供不算完全偏薄偏弱的低频而已，相对紧绷而存在感不多。基音位于中下盘的乐器没有明显前倾。

中频，人声稍近，口型比标准稍小一点，精致程度还比较高。对于人声的质感和线条更加偏向于后者，厚度不算多，线条相对扎实程度还行。对于男女声之间的倾向性不算明显，适合偏细偏上盘的人声类型。颗粒感有所打磨，顺滑程度是不错的。音色渲染不算多，仅有轻度的为了悦耳度的调整。喉音位置稍高，气声比例不算足，口水声的前凸不多。齿音有轻度的打磨，但是在部分曲目中还是有感知。人声总体的通透程度比较高，相较于 Buds 5 自然度也会有进步。在开启自适应之后，人声的厚度和口型都会有所增强，而声线的适应性也会稍广一些。

乐器方面，也是线条较为优先的风格。弦乐器中，小提琴、中提琴、吉他等的抓耳感比较高，但是不会有明显的不自然，拉拨弦的细节有一定的突出。大提琴的形体感不算扎实，在空间里所占比例也偏小。铜管类的气势感不算足，需要亮度的小号等有比较合适的亮感。木管类的空气感表现还行，自然度尚可，厚度不多。乐器的泛音量适中，显得比较精致。打击乐器中，Kick 的存在感不强，Snare 收得比较快，镲片类有比较充足的亮度，好在不至于刺激。

高频总体亮度适中，平滑程度还可以，只有程度不算高的尖峰，只要不把音量开得太高，都不会觉得刺激。极高频的延伸能力比 Buds 5 稍好一点，滚降还是早了点但不算快，听上去尤其在高码率编码下是不会有太明显的高频截断感了。

声场的规模在半入耳里算是中等稍大的程度，边界感因为半入耳本身的结构而显得不会有明显的强调，横纵都能拉开一些距离，横向会更明显一点。结合中规中矩的「高度感」，小米 Buds 6 可以呈现出比较扁平化的扁球空间。开启自适应之后声场的包围感会强一些。人声与乐器之间的分离度表现还行，整体感没有太大问题。解析能力要比 Buds 5 好，信息量在这个价位算是比较合格的状态，有轻度的「解析感」增强。动态中规中矩，瞬态不错。

综合来看，我们建议是在均衡听感档位下打开自适应听感来获得一定程度的中低频补偿，进而让听感更加饱满。

总结评价 | Overall Impression

小米 Buds 6 相较于上一代产品在作为一个半入耳 TWS 耳机的几个方面还是有进步的，主要的进步点在于比较正常的默认调音、相对稳定的 aptX 连接、做工精致度与表面处理，以及空间音频的声场呈现。我们觉得同样售价 699 元，小米 Buds 6 还是比上代有了更多的可取之处，在更新固件后也没有再出现自适应算法跑偏的情况，日常你也可以开着自适应听感来使用了。

我们也对于它几处阉割点觉得匪夷所思，首先是降噪综合感知，没有进步的同时甚至还有小幅度的倒退，到了几乎是不怎么有用的程度也是让人惊讶。录音功能或许是因为主控内存的限制而做出变化，倒是可以理解，但是 EQ 缩减频段数和可调范围为什么也要打折扣呢？没有很好的独立于 LC3 之外的低延迟模式、依然效果不够好的通话与录音，以及声音终究还是跟真正旗舰有素质上的差距，这些点也依然难以忽视。

我们看到了一些正向变化，也有一些摸不着头脑的地方，希望小米在 Buds Pro 6 上继续进步，让我们能够打得出 IV 分甚至更高的成绩。目前综合判断下来，我们更加倾向于给小米 Buds 6 一个 III 分平均评价。

本文所涉及型号在当时市场背景下的 KT MARK 与降噪综合能力金字塔 | TDS ANC Pyramid：Xiaomi Buds 6: III (Average)

【怎么感觉这 III 级评分的配色方案就是给 Buds 6 星云紫设计的一样——自我吐槽】

降噪综合能力金字塔 | TDS ANC Pyramid：Xiaomi Buds 6: In-Ear Medium Level

关于 KT MARK 评分机制以及利益相关的「不干涉评价原则」，请搜索《TDS Studio 评分标准与内容说明 V202502》，可以在主流搜索引擎直接搜索。

KingTsui, TDS Studio.

Jan 2026

It's a TDS production.

部分截图来自小米，其余所有内容全部自主创作，请勿抄袭内容、套抄行文结构等，保留一切权利。

派评 | 近期值得关注的 App

作者: 纯情
时间: 2026-01-05
分类: 资讯
评论

欢迎收看本期《派评》。你可以通过文章目录快速跳转到你感兴趣的内容。如果发现了其它感兴趣的 App 或者关注的话题，也欢迎在评论区和我们讨论。

值得关注的新 App

虽然少数派一直在为大家发现和介绍各平台上的优质 App，但仍有不少设计、功能、交互、体验都非常优秀的 App，还没有被我们发掘和介绍。它们可能是一款老 App，也可能是近期上架的新 App，我们会在这里介绍给你。

Bauhaus Clock：Mac 屏保新选择

平台：macOS
关键词：屏保、时钟

@PlatyHsu：屏幕保护程序听起来已经像是上个时代的概念了，如今它的作用更多是作为一种美化装点和临时遮挡。特别是在较大的外接显示器上，一个美观的屏保还是挺出镜的。不过，或许是因为 macOS 本身内置的屏保已经很丰富，再加上屏保开发框架年久失修，近年来很少见到有什么优秀的第三方屏保（App Store 里那些骗钱玩意不算）。

Bauhaus Clock 就是我很久以来第一次发现的一个优秀 macOS 屏保。如果你用过 iOS 6 的话，应该对当时时钟 app 里的瑞士铁路时钟印象深刻。Bauhaus Clock 采用的也是类似思路，其主要功能就是在屏保界面显示一个写实的包豪斯风格时钟。

当然，显示一个时钟不难，但 Bauhaus Clock 把细节做得特别到位：从指针的金属光泽、到表盘上投下的阴影，再到刻度上凹陷的荧光涂层，无不刻画得惟妙惟肖。指针的跳动方式也有三种可选：石英表（每次移动一格）、机械表（每次移动 1/4 格）和数字表（平滑移动）。特别是在石英表模式下，作者甚至把指针移动时轻微的颤动都做出来了。

表盘有 13 种颜色主题可选，换主题时，刻度、数字和指针会随着表盘一起换成匹配的颜色。尤其推荐其中的冰川蓝（Glacier）、开心果绿（Pistachio）和薰衣草紫（Lavender），都是那种看了想要偷来做博客主题色的搭配。

而到了晚上，Bauhaus Clock 还会随系统主题自动切换到暗色模式，这时看到的效果就像是熄灯后的挂钟：荧光刻度在纯黑底色下泛出带着颗粒感的微光（有 14 种颜色可选），隐隐照映出指针的轮廓。

Bauhaus Clock 的其他「小节」也做得很到位。例如，设置面板上所有的控件都没有用系统标准样式，而是另外画的一套，高光和阴影颇有拟物遗风。又如，时钟刻度会定时轻微抖动，以避免烧屏（虽然目前还没有 Mac 使用 OLED 屏幕，或许是考虑到用 OLED 外接显示器的用户，或者是在为未来的 OLED MacBook 预备吧）。

如果要说有什么美中不足…… 沾上「包豪斯」这个名字的东西都不会太便宜，包括 Bauhaus Clock——19 美元的价格已经向很多独立应用的定价看齐了。作者在 FAQ 里花了很多笔墨解释它为什么值，不用看都知道是说精雕细琢、免费更新、从不打折云云。考虑到这个价格，我也很难说有多推荐。如果它正好踩在你的审美上，或者能给你提供一些取景素材（像 MKBHD 那样），这个时钟漂亮得货真价实；否则，省下这钱已经够你向 ChatGPT 索要一个月的情绪价值了。

Bevel：全能型健康助手，运动、饮食一把抓

平台：iOS / watchOS
关键词：健康数据、体能训练

@Vanilla：Bevel 是一款 iOS 平台上的健康应用，同时提供了 Apple Watch 客户端，可以在健康监测、运动训练等方面进行联动。近日，Bevel 将自己的核心功能免费开放，只保留了 Bevel Intelligence 相关的功能为付费解锁内容。作为一款健康应用，Bevel 包含的功能非常全面，基本上可以满足我们对运动、健康等方面的大部分需求，接下来让我带大家一起来看看。

Bevel 应用分为首页、手记、健身、生命体征这四个标签页。顾名思义「首页」起到了一个聚合的作用，展示了压力、能量、营养和一些健康监测的数据；「手记」则可以让我们手动录入一些和健康相关的行为，比如说咖啡因、心情、添加糖、生酮饮食、补水、酒、在床上使用设备、睡前餐等，同时还展示了一些自动记录的数据，比如说步数、力量训练时间、有氧运动时间等。

「健身」模块展示了运动相关的数据，比如说月视图、活动摘要、耗力表现、肌肉符合、体能训练频率等，同时还可以在这个模块中新增、管理、同步体能训练模块；「生命体征」则展示了最大摄氧量、HRV 基准线、RHR 基线、体重、体脂等数据。

不过，我最喜欢 Bevel 这款应用的功能藏在右下角的加号按钮中。点击这个按钮后会出现一个新增界面，这里的功能主要分为饮食和训练两个部分。饮食部分，我们可以通过文本输入、图片导入、拍照导入、扫描导入、直接搜索等多种方式来记录我们每一顿的饮食；训练部分，我们可以根据自己的情况自动生成模板、查看模板，也可以记录单次活动。

这里，我想着重介绍一下 Bevel 的体能训练模板功能。不管是自动生成模板，还是自定义模板，我们都可以从一个庞大的动作库中选择自己喜欢的动作并新增进模板中，每个动作都可以查看演示动图和动作指南，并清晰地展示了主要肌肉和次要肌肉。开始训练后，Apple Watch 客户端也会同步开始，过程中我们也可以随时记录每组的重量和次数。这个瞬间，是不是让你想到了训记 App。

作为 Bevel 的付费功能，Bevel Intelligence 可以与我们实时对话，根据我们的情况提供针对性的建议，还可以帮我们直接生成饮食和训练方面的计划，非常方便。如果你在寻找一款健康或者运动相关的监测应用，不妨试一下 Bevel，可以免费使用大部分功能，而且功能非常丰富。

Bevel 可以在 App Store 免费下载使用，除 AI 功能外均可免费使用，订阅费用为每年 328 元。

且听：罗永浩推出 AI 书籍解说工具

平台：iOS
关键词：听书、AI 解说

@Snow：上周，罗永浩在他的「科技春晚」上，推出了团队内部孵化的 AI 听书应用「且听」。与传统有声书籍致力于绘声绘色地表现文字的目标不同，且听借助 AI 引擎对全文进行理解再阐释，利用 3-4 万字的文案或 1-2 小时的音频，帮你高效获取信息。

且听沿用了 Smartisan OS 细腻的轻拟物设计，首屏书架区目前已收录超 1 万部书籍内容。如果你不知道从什么看起，可以使用顶部分类按钮缩小类型范围，也可以跳转至榜单页，从豆瓣热门、新京报推荐这些榜单中，选择已收录的条目进行了解。

正如我一开始所说，且听的核心功能并不是逐字朗读的「听书」，而是放在了对书籍的「讲解」上。点击「播放本书讲解」按钮，你可以查阅 AI 引擎分析提炼后的重点内容，以及补充相关背景与延伸信息，它就像是书籍版「影视解说」，AI 创作者可以帮你浓缩核心剧情，梳理结构逻辑，引经据典拓宽知识面，甚至向你传达它的所感所悟，这种篇幅有限的二创，让它基本只能展示原作的某几个侧面，无法做到完全还原，因而在我看来且听并不能完全替代阅读原作这一行为。我更建议你将它作为一种兴趣筛选或者后续补充，且听目前并不支持直接阅读电子书，如果你听完解说，激起了阅读的兴趣，可以点击应用内置的购买链接，通过京东渠道购买对应的实体书。

且听的解说会同时提供文字和音频版本，你可以选择全屏阅读文字，也可以选择 AI 人声帮你朗读。AI 朗读支持快进快退、倍速、定时关闭、随机播放、连续播放等基础功能，并可从小文（男声）、小粟（女声）及对应的「深夜版」共 4 种声音模型中任选其一，深夜版声音相较原版更低沉舒缓，非常适合睡前助眠。你还可以选择性地为 AI 人声添加背景音乐，进一步增强聆听氛围感。比较可惜的是，科技大会上演示的名人声音模型和音色克隆功能，在这一版暂未上线，整体声音表现力会略低于预期。

此外，且听暂不支持本地书籍的导入和解析，鉴于目前的阅读库品类还是比较有限，较难覆盖所有人的阅读需求。不过考虑到且听目前收费门槛较低，免费用户阅读体量不限，仅在音源质量以及广告上有所差异，可以作为一款阅读的补充工具使用。

你可以在 App Store 免费下载且听。

Funkey：为 Mac 带来逼真的机械键盘打字音效

平台：macOS
关键词：打字音效

@化学心情下2：除了明确的段落感能带来输入上的正反馈之外，我们在使用机械键盘打字时的机械声也能从听觉上带来输入的愉悦感——至于跟你在一起的同事或者室友是否觉得愉悦我觉得可以另当别论。而在 Mac 键盘上，相对「短促」的键程体验势必会让一些已经习惯机械键盘的用户总觉得不是那么「带劲」。好在终于有开发者察觉到了这个「问题」，为 Mac 用户推出了这款机械键盘音效应用：FunKey。

虽然听上去颇有点「脱裤子放屁」的怪诞感，但在实际购买使用后我发现 FunKey 还是有点趣味的：应用提供的不仅仅是机械键盘的音效，甚至还有鼠标点击的音效，可以说是只有你想不到没有它不提供的。

在 FunKey 中，光是鼠标的音效就有十几种，你可以根据自己的喜好随意选择；至于机械键盘的音效，FunKey 也有非常多选择，并在设置菜单中描述了大致的音色效果。由于花样实在太多，我也无法一一描述，感兴趣可以自行体验。

你可以在 Mac App Store 下载 FunKey，售价为 22 元。

Anx Reader：接入 AI 大模型的多端阅读器

平台：iOS / iPadOS / Android / Windows / macOS / 鸿蒙
关键词：读书、AI 翻译

@大大大K：最近在读一些英文小说，很多时候还是需要依赖中文翻译对照才行。手动制作双语文件太麻烦，而阅读 App 自身接入的翻译工具又太机械，翻译不出小说里的「神韵」。后来偶然发现了这款开源免费的 Anx Reader，它具备接入 AI 大模型的能力，不仅能快速翻译，还能实现更多问答功能。

Anx Reader 本身支持跨端使用，能够运行在 Windows、Android、iOS、macOS 以及鸿蒙平台上。App 主要还是采用了 Material 3 设计风格，iOS 版的部分控件做了仿液态玻璃效果，同时 Anx Reader 针对 E-INK 设备做了单独优化，开启 E-INK 模式后 App 会切换为白底黑字，并适配墨水屏的刷新模式。

在阅读功能方面，Anx Reader 的特色在于它对 AI 功能的支持。App 导航栏中有一个专门的 AI 功能标签，点击后会进入与 AI 的对话模式，可以针对某本书进行总结、解释、分析，也可以面向在 App 内的整体阅读情况进行总结和建议。我们还可以进入 AI 功能设置，单独设定某种会话类型的提示词，以实现更具有针对性的会话回答。

如果是在阅读过程中，我们也可以点击右上角的 AI 按钮，让 AI 帮我们总结这本书的思维导图和阅读引导，也可以通过划词搜索或者全文翻译的方式辅助我们阅读外文文档。AI 给出的翻译要比一般翻译工具更合理，也能更好地表达小说中很多口语化的句子。

除此之外，Anx Reader 还支持 WebDAV 同步数据，实现更完美的跨平台使用体验。不过同步过程中 Anx Reader 可能会上传小说文件，如果你在使用类似坚果云这种计算流量的服务，则需要注意一下流量使用。

现在，你可以在官方网站和 GitHub 免费下载 Anx Reader。需要注意的是，iOS 用户通过 App Store 下载时需要付费购买，但开发者鼓励用户通过自签的方式免费在 iOS 设备上使用。

不容错过的 App 更新

除了「新鲜」App，App Store 中的许多老面孔也在不断迭代、更新，增加更多有趣和实用的功能。少数派希望帮你筛选 App Store 中值得关注的 App 动态，让你快速了解 App 和开发者们的最新动态。

一生足迹2：新增年度总结、3D 地球模式

平台：iOS
关键词：轨迹记录、年度总结

@ElijahLee：轨迹记录应用「一生足迹」更新了 2.0 大版本，新版推出了 2025 年度总结、轨迹总览新增 3D 地球模式、新增墨黑地图、自定义时间段查看等功能。

首先是 2025 年度总结，入口会出现在应用首页的地图中。这份年度总结总共分为 10 个页面，依次分析 2025 年去过的 10 个城市、全年总共记录的轨迹点、平均每天记录的轨迹点以及一些日常习惯等等。最后可以生成年度小结，用于保存或分享到社交媒体。如果你在应用没有找到年度总结入口，可以应用右下角地球图标，重新解析即可。

在轨迹总览中，新版新增了 3D 地球模式，用 3D 地球视图展示你在全球留下的足迹。值得注意的是，这是一个使用数据实时渲染的 3D 地球，你可以自由地旋转它来查看，并且加入了星星、飞机、流星等等额外的小巧思。点击地球，还可以进入全屏模式，自动播放灵动的 BGM 背景音乐。对于跨国、跨洲的用户来说，这项功能很有吸引力，足迹不再是平面数据，而是转换成了一种空间记忆。

新版还新增了墨黑地图，以及上一版本增加的松石绿，都非常精美。自定义时间段查看在应用首页，可以按照单日、单月、全年等默认时间查看轨迹统计，还可以自行选择起止时间内的轨迹点数据，生成该时间段内的轨迹图。这项功能非常适合旅行、出差等人生阶段性记录，把足迹数据切成有意义的时间片段，便于以后回顾。

你可以在 App Store 免费下载「一生足迹」。应用大部分功能都可以免费使用，付费可以解锁专属档案、轨迹分析、运动模式等。费用为 12元 / 年。

聊聊 nostr 和审查

作者: 纯情
时间: 2026-01-05
分类: 开源
评论

这两天在网络上又有一个东西火了，Twitter 的创始人 @jack 新的社交 iOS App Damus 上苹果商店（第二天就因为违反中国法律在中国区下架了），这个软件是一个去中心化的 Twitter，使用到的是 nostr – Notes and Other Stuff Transmitted by Relays 的协议（协议简介，协议细节），协议简介中有很大的篇幅是在批评Twitter和其相类似的中心化的产品，如：Mastodon 和 Secure Scuttlebutt 。我顺着去看了一下这个协议，发现这个协议真是非常的简单，简单到几句话就可以讲清楚了。

通讯过程

这个协议中有两个东西，一个是 client，一个是 relay，client 就是用户社交的客户端，relay 就是转发服务器。
用户不需要注册，用户只需要有一个密钥对（公钥+私钥）就好了，然后把要发的信息做签名，发给一组 relays
然后你的 Follower 就可以从这些 relays 上订阅到你的信息。

技术细节摘要

技术实现上，nostr 使用 websocket + JSON 的方式。其中主要是下面这么几个指令
- Client 到 Relay主要是下面这几个指令：
  - EVENT。发出事件，可以扩展出很多很多的动作来，比如：发信息，删信息，迁移信息，建 Channel ……扩展性很好。
  - REQ。用于请求事件和订阅更新。收到REQ消息后，relay 会查询其内部数据库并返回与过滤器匹配的事件，然后存储该过滤器，并将其接收的所有未来事件再次发送到同一websocket，直到websocket关闭。
  - CLOSE。用于停止被 REQ 请求的订阅。
- Relay 到 Client 主要是下面几个指令：
  - EVENT。用于发送客户端请求的事件。
  - NOTICE。用于向客户端发送人类可读的错误消息或其他信息
关于 EVENT 下面是几个常用的基本事件：
- 0: set_metadata：比如，用户名，用户头像，用户简介等这样的信息。
- 1: text_note：用户要发的信息内容
- 2： recommend_server：用户想要推荐给关注者的Relay的URL（例如wss://somerelay.com）

如何对抗网络审查

那么，这个协议是如何对抗网络审查的？

识别你的身份是通过你的签名，所以，只要你的私钥还在，你是不会被删号的
任何人都可以运行一个或多个relay，所以，就很难有人控制所有的relay
你还可以很方便的告诉其中的 relay 把你发的信息迁到另一个 relay 上
你的信息是一次发给多个relay的，所以，只要不是所有的热门realy封了你，你就可以发出信息
每个relay的运营者都可以自己制定规则，会审查哪些类型内容。用户据此选择即可。基本不会有一个全局的规则。
如果你被全部的relay封了，你还是可以自建你的relay，然后，你可以通过各种方式告诉你身边的人你的relay服务器是什么？这样，他们把这个relay服务器加到他们的client列表中，你又可以从社死中复活了。

嗯，听起来很简单，整个网络是构建在一种 “社区式”的松散结构，完全可能会出现若干个 relay zone。这种架构就像是互联网的架构，没有中心化，比如 DNS服务器和Email服务器一样，只要你愿意，你完全可以发展出自己圈子里的“私服”。

其实，电子邮件是很难被封禁和审查的。我记得2003年中国非典的时候，我当时在北京，当时的卫生部部长说已经控制住了，才12个人感染，当局也在控制舆论和删除互联网上所有的真实信息。但是，大家都在用电子邮件传播信息，当时基本没有什么社交软件，大家分享信息都是通过邮件，尤其是外企工作的圈子，当时每天都要收很多的非典的群发邮件，大家还都是用公司的邮件服务器发……这种松散的，点对点的架构，让审查是基本不可能的。其实，我觉得 nostr 就是另外一个变种或是升级版的 email 的形式。

如何对抗Spam和骗子

但是问题来了，如果不能删号封人的话，那么如何对抗那些制造Spam，骗子或是反人类的信息呢？nostr目前的解决方案是通过比特币闪电网络。比如有些客户端实现了如果对方没有follow 你，如果给他发私信，需要支付一点点btc ，或是relay要求你给btc才给你发信息（注：我不认为这是一个好的方法，因为：1）因为少数的坏人让大多数正常人也要跟着付出成本，这是个糟糕的治理方式，2）不鼓励那些生产内容的人，那么平台就没有任何价值了）。

不过，我觉得也有可以有下面的这些思路：

用户主动拉黑，但很明显这个效率不高，而且体验不好
社区或是同盟维护一个黑名单，relay定期更新（如同email中防垃圾邮件也是这样搞的），这其实也是审查。
防Spam的算法过滤垃圾信息（如同email中干的），自动化审查。
增加发Spam的成本，如: PoW 工作量证明（比特币的挖矿，最早也是用于Email），发信息要花钱（这个对正常用户伤害太大了）等。
……

总之，还是有相应的方法的，但是一定没有完美解，email对抗了这么多年，你还是可以收到大量的垃圾邮件和钓鱼邮件，所以，我觉得 nostr 也不可能做到……

怎么理解审查

最后，我们要明白的是，无论你用什么方法，审查是肯定需要的，所以，我觉得要完全干掉审查，最终的结果就是一个到处都垃圾内容的地方！

我理解的审查不应该是为权力或是个体服务的，而是为大众和人民服务的，所以，审查必然是要有一个开放和共同决策的流程，而不是独断的。

这点可以参考开源软件基金会的运作模式。

最底端的是用户（User）参与开源社区的使用并提供问题和反馈。
用户在使用过程中了解项目情况后贡献代码和文档就可以晋升为贡献者（Contributors），
当贡献者提交一定数量贡献之后就可以晋升为提交者（Committers），此时你将拥有你参与仓库的代码读写权限。
当提交者Committers在社区得到认可后，由项目管理委员会（PMC）选举并产生PMC成员（类似于议员），PMC成员拥有社区相关事务的投票、提名和共同决策权利和义务。

注意下面几点

整个社区的决策者，是要通过自己贡献来挣到被选举权的。
社区所有的工作和决定都是要公开的。
社区的方向和决策都是要投票的，PMC成员有binding的票权，大众也有non-binding的投票权供参考。
如果出现了价值观的不同，那么，直接分裂社区就好了，不同价值观的人加入到不同的社区就好了。

如果审查是在这个框架下运作的话，虽然不完美，但至少会在一种公允的基础下运作，是透明公开的，也是集体决策的。

开源软件社区是一个很成功的示范，所以，我觉得只有技术而没有一个良性的可持续运作的社区，是不可能解决问题的，干净整齐的环境是一定要有人打扫和整理的。


扫码小程序中打开	扫码网页中打开

快速开始

渗透测试资产搜集

域名及子域名搜集（深度和广度）

被动查询（利用公共数据库）

常用的在线查询网站

自动化工具

主动探测

子域名爆破

在没经过目标产商的允许擅自爆破属于违法行为！此教程仅作学习分享交流！

顶级域名的收集

被动收集

代码与页面信息泄露

前端代码分析

公开文件和配置检查

前情提要

踩坑记录

源码窥探

彩蛋

这玩意儿能干啥？(不仅仅是擦除)

L 站兄弟专属福利 (不整虚的)

传送门

“用传统 IDE 写代码，那不是合格工程师”

“Claude Code 行不通”

编排革命

永远不要重写代码？错了！

谷歌、Anthropic、OpenAI 内部都很乱

两个代表性模型串联起今年 AI 圈

算力需求却没有下降

全球在真正生产中使用中国 AI

全方位扶持上线，携手开发者开启小程序 AI 应用元年

众多标杆案例涌现，小程序成为 AI 独立开发的“第一站”

企业智能体 2026 年六大预判

预判一：智能体从“一人一工具”进阶“一人一团队”

预判二：多智能体需具备 TAB 三要素

预判三：中国将成为全球多智能体落地的“超级引擎”

预判四：“一把手工程”是赢取 AI 红利的关键路径

预判五：智能体反哺推动企业数字基建“自主进化”

预判六：2026 年将成为企业多智能体规模化“上岗元年”

“我们不再沿用大厂销售标准化产品的模式”

结束语

Clicks 推出 Power Keyboard 和 Communicator 手机

Pebble 推出 Round 2 手表

DeepSeek 发论文介绍高效训练技术 mHC

华硕通知渠道今起涨价

新一批作品进入公有领域

比亚迪超越特斯拉成为 2025 年全球电动车销量榜首

看看就行的小道消息

少数派的近期动态

你可能错过的好文章

什么是 Game Jam

为什么选择 Global Game Jam？

关于荔湾站

站点场地信息

活动详情

谁可以参加？

你需要准备什么？

报名方式

包装与配件 | Package & Accessories

设计、佩戴表现与声学结构 | Design, Fit & Acoustic Structure

操作与软件端功能 | Control & APP

降噪与通话 | ANC & Call

信号与续航 | Connection & Battery

空间音频 | Spatial Audio

扬声器、声音模式和编解码器 | Driver, Sound Modes & Codec

声音主观描述 | Sound Description

总结评价 | Overall Impression

值得关注的新 App

Bauhaus Clock：Mac 屏保新选择

Bevel：全能型健康助手，运动、饮食一把抓

且听：罗永浩推出 AI 书籍解说工具

Funkey：为 Mac 带来逼真的机械键盘打字音效

Anx Reader：接入 AI 大模型的多端阅读器

不容错过的 App 更新

一生足迹2：新增年度总结、3D 地球模式

通讯过程

技术细节摘要

如何对抗网络审查

如何对抗Spam和骗子

怎么理解审查

最新文章