测试之家社区

LLMCase-V4

zhangbp — Tue, 08 Sep 2026 17:09:29 +0800

技术实现说明（培训教材）

定位：完成年初设定目标：2026 年测试智能化升级技术实现方案 v3 https://testerhome.com/topics/43674
章节体系：本工程本质是领域特化 RAG 系统（策划文档 → 检索增强 → 测试要点/用例生成 → 评估），
章节按 RAG pipeline 阶段编号组织（00-11），每章内以「递进小节」展开（基础→变体→本工程特化）。
每小节固定四段：① 机制一句话；② 数据流图；③ 代码入口（path:line 锚定）；④ 复用清单。
骨架版（session#70 立项）：小节标题与内容后续对话逐步充实调整。
开发任务排序：任务 1=实现新功能，任务 2=本文档（培训教材）。
维护纪律：涉及下述机制的 change 收尾时，须同步更新本文档对应小节。

00 工程总览与最小链路

00-1 一句话与总架构：策划文档（docx）→ 结构化测试要点与用例 + 全程质量评估；四服务拓扑（convert2md:8000 / generator:8001 / evaluator:8002 / dashboard:8080）与共享层（model_core/modules/common）。
00-2 数据流水线阶段目录总图（data/workspace/01_raw → 02_markdown → 03_entity → 04_point → 05_case → 06_eval，后缀 SRC/ENT/PNT/CAS/EVAL）。
00-3 一次端到端数据旅行叙事（拿一份真实 docx 走完全链）。
00-4 环境与运行（.env / start_all_services / 已知坑速查）。

01 数据导入：docx 到 markdown

01-1 简单文本导入（纯文字 docx → md 的基本链路）
01-2 结构化内容（标题层级、列表、加粗等格式映射）
01-3 图文数据（图片抽取 +  占位符协议）
01-4 表格数据（docx 表格 → md 表格 → ExcelTableThinking）
01-5 归档契约与版本（单文件 + 行区间、.superseded_ 归档、批次 artifacts.source）

02 文本切块：从文档到提取单元

02-1 章节树构建（标题层级=功能层级假设，section 切分）
02-2 辅助段落分流（aux-section：overview 反哺 / boilerplate 跳过）
02-3 正文前约定区切分（preamble：三级识别 + 指导/提取双路，template_chapters.split_preamble）
02-4 跨表/跨节块（ExcelTableThinking 块、跨节依赖 Pass 2）

03 实体提取：文本到功能实体图（本工程特化）

03-1 两遍提取（骨架 Pass→细化 Pass→依赖解析）
03-2 prompt 组装与 flag 体系（模板章节 guard 白名单、img 上下文注入、aux 背景）
03-3 实体合并与孤儿挂接、原子性判定
03-4 共享词表体系（template_chapters / aux_sections 单一真相源）

04 向量嵌入

04-1 嵌入模型选型（bge-m3：多语/长文本/延迟基线）
04-2 嵌入什么（实体/要点/用例的向量化对象与粒度）

05 向量存储

05-1 FAISS 索引结构与持久化
05-2 few-shot 样例池（genre/universal 双池、入库治理）

06 检索前处理

06-1 查询构造（从实体/要点生成检索 query）
06-2 三级路由（tier1 项目内 → tier2 品类 → tier3 零样本）
06-3 提问式生成的子树圈定（scope）

07 索引优化（拟，后续调整）

08 检索后处理

08-1 宽召回 + rerank（recall floor、bge reranker）
08-2 检索质量阈值与忠实性（faithfulness，防编造）

09 响应生成：测试要点与用例

09-1 测试要点生成（TP：结构、prompt、few-shot 注入）
09-2 测试用例生成（CAS：步骤/断言、四象限）
09-3 提问式生成双路（单点生成 ask 流）

10 系统评估

10-1 geval judge（LLM 评估）
10-2 critic 四维（单条质量）
10-3 watchdog 双轨交叉验证（确定性 vs LLM 分歧）
10-4 A/B 实验方法学（本工程反复使用的判据体系）

11 高级机制（拟，后续调整）

11-1 few-shot 价值结论（产量放大器而非质量提升器）
11-2 批次血缘与产物回溯（sessions/backfill）
11-3 可观测性（结构化日志 TAG 协议 / log_doctor / Langfuse / flag 收敛）

附录 A：复用依赖地图（拟）

编写进度

章节	状态	完成时间
00 总览与最小链路	待写
01 数据导入	待写
02 文本切块	待写
03 实体提取	待写
04 向量嵌入	待写
05 向量存储	待写
06 检索前处理	待写
07 索引优化（拟）	待定
08 检索后处理	待写
09 响应生成	待写
10 系统评估	待写
11 高级机制（拟）	待定

基于 WebUSB 与 CDP：在浏览器端实现 Android 设备通信与无证书抓包实践

Katrina — Tue, 08 Sep 2026 10:27:58 +0800

基于 WebUSB 与 CDP：在浏览器端实现 Android 设备通信与无证书抓包实践

在移动端 Android 调试与测试过程中，Scrcpy 等传统桌面工具通常依赖宿主机安装的 ADB Server（通过本地 5037 端口与设备通信）。虽然性能极高，但在日常跨团队协作或自动化测试交付时，往往面临本地环境依赖繁琐、多版本 ADB 端口冲突以及移动端 HTTPS 抓包配置复杂（如 Android 7+ 默认不信任用户根证书）等现实问题。

本文结合我们在开源浏览器扩展 TabQA 中的工程实践，探讨如何借助现代浏览器的 WebUSB API 和 Chrome DevTools Protocol (CDP)，在不依赖本地 ADB 服务与客户端的前提下，直接在浏览器端实现真机通信、投屏交互与免安装 CA 证书的网络抓包。

1. 底层通信：基于 WebUSB 的 ADB 协议握手

现代 Chromium 内核提供了 WebUSB API，允许在受信任的前端上下文（如用户主动授权后）中直接与物理 USB 设备进行底层的 Bulk 数据传输。

1.1 设备筛选与接口声明

在 Android 官方规范中，ADB 调试接口具有固定的类定义：

bInterfaceClass: 0xff (Vendor Specific)
bInterfaceSubClass: 0x42 (ADB)
bInterfaceProtocol: 0x01

在浏览器中，首先通过过滤条件唤起设备选择器：

// 1. 过滤并请求匹配 ADB 接口定义的 Android 设备
const device = await navigator.usb.requestDevice({
  filters: [{
    classCode: 0xff,
    subclassCode: 0x42,
    protocolCode: 0x01
  }]
});

// 2. 打开设备并独占 ADB 接口
await device.open();
await device.selectConfiguration(1);
const adbInterface = device.configuration.interfaces.find(iface =>
  iface.alternates.some(alt => alt.interfaceClass === 0xff && alt.interfaceSubclass === 0x42)
);
await device.claimInterface(adbInterface.interfaceNumber);

1.2 ADB 协议包封装与 RSA 鉴权

与桌面 ADB 二进制类似，浏览器与设备建立通信时，需要实现完整的 ADB 报文头结构：

// ADB 报文结构包含 24 字节头：command, arg0, arg1, data_length, data_checksum, magic
function createAdbPacket(command, arg0, arg1, payload = new Uint8Array(0)) {
  const header = new ArrayBuffer(24);
  const view = new DataView(header);

  view.setUint32(0, command, true);              // A_CNXN, A_OPEN, A_WRTE 等
  view.setUint32(4, arg0, true);
  view.setUint32(8, arg1, true);
  view.setUint32(12, payload.byteLength, true);  // 数据载荷长度
  view.setUint32(16, calculateChecksum(payload), true);
  view.setUint32(20, command ^ 0xffffffff, true);// magic 校验

  return concatBuffers(header, payload.buffer);
}

首次连接时，手机会返回 A_AUTH 要求授权。前端直接在内存中生成 2048 位 RSA 密钥对，将公钥转换为 Android ADB 兼容格式（Base64 + Token） 发送给手机，用户在真机点击 “允许 USB 调试” 后即可完成连接。整个链路不启动本地系统进程，彻底杜绝了多开发环境的端口抢占问题。

2. 移动端网络抓包：基于 CDP 绕过根证书限制

在测试内嵌 H5 或混合开发（Hybrid）应用时，传统方案（如 Charles / Fiddler）需要修改系统 Wi-Fi 代理并安装 CA 根证书。但从 Android 7.0 (API 24) 开始，系统安全机制默认禁止信任用户安装的根证书。

2.1 端口映射与 DevTools 连接

Android 端运行的 Chrome 或开启了调试开关的 WebView（WebView.setWebContentsDebuggingEnabled(true)），底层都会开放一个 Unix domain socket（例如 @webview_devtools_remote_<pid>）。

通过 WebUSB 通道向设备发送端口转发指令后，浏览器端即可与目标 WebView 建立双向 WebSocket 连接。

2.2 注入网络监听指令

通过直接向 WebSocket 发送 Chrome 调试协议（CDP）指令，即可在运行时捕获底层网络事件，无需篡改任何 HTTP 证书：

// 向目标 WebView 的 DevTools 端口发送启用网络监听指令
function enableNetworkInspection(ws) {
  const message = {
    id: 1,
    method: 'Network.enable',
    params: {
      maxPostDataSize: 65536 // 捕获最大请求体
    }
  };
  ws.send(JSON.stringify(message));
}

// 监听网络响应与错误
ws.onmessage = (event) => {
  const data = JSON.parse(event.data);

  if (data.method === 'Network.responseReceived') {
    const { requestId, response } = data.params;
    console.log(`[HTTP ${response.status}] ${response.url}`);

    // 获取响应体
    ws.send(JSON.stringify({
      id: generateId(),
      method: 'Network.getResponseBody',
      params: { requestId }
    }));
  }
};

该方案直接从渲染引擎内部获取网络事件，因此无论是 HTTPS 流量、证书固定（SSL Pinning）还是特定内网接口，都能完整提取请求体、响应头与耗时指标。

3. 证据链对齐：环形缓冲区（Ring Buffer）在回捞中的应用

移动端偶发性 Crash 和 ANR 的一大痛点在于 “事后无法及时抓取现场”。如果全程进行全量录像和日志落盘，长时间测试会迅速耗尽系统内存。

在架构设计上，可以引入基于内存的环形缓冲区（Ring Buffer）机制：

class RingBuffer {
  constructor(capacity = 180) { // 维持最近 180 个切片（例如 3 分钟）
    this.buffer = new Array(capacity);
    this.capacity = capacity;
    this.head = 0;
    this.size = 0;
  }

  push(item) {
    this.buffer[this.head] = item;
    this.head = (this.head + 1) % this.capacity;
    if (this.size < this.capacity) this.size++;
  }

  // 提取按时序对齐的连续快照
  dump() {
    const result = [];
    let idx = this.size < this.capacity ? 0 : this.head;
    for (let i = 0; i < this.size; i++) {
      result.push(this.buffer[(idx + i) % this.capacity]);
    }
    return result;
  }
}

视频流处理：通过 WebCodecs / MediaRecorder 将投屏流按 1 秒为粒度切分推入 Ring Buffer；
Logcat 流过滤：后台异步流式读取 adb logcat -v threadtime，正则匹配目标应用包名与 FATAL EXCEPTION / ANR 关键字；
对齐触发：一旦捕获到崩溃信号或用户手动触发采集，系统瞬时将内存 Buffer 导出，生成时间戳完全锁定的短视频与异常上下文日志切片。

4. 架构对比与权衡思考

技术维度	传统桌面工具（如 QtScrcpy）	浏览器扩展架构（如 TabQA）
底层实现	C/C++ 宿主进程 + ADB Server (TCP 5037)	JavaScript + 原生 WebUSB API (USB Bulk)
环境依赖	依赖宿主机环境与 ADB 安装	零外部依赖，Chrome/Edge 开箱即用
渲染开销	原生 GPU 渲染，支持 60~120fps 高刷	Canvas/WebCodecs 渲染，兼顾常规业务交互
网络层探针	无内置网络探针，需借助系统代理	基于 CDP 协议直接监听，免装 CA 根证书
适用定位	极致流畅度需求（手游映射、长视频）	敏捷功能测试、缺陷证据链对齐与交付

5. 总结

将 Android 设备的连接、投屏与调试搬进浏览器侧边栏，本质上是利用了现代 Web 技术（WebUSB、WebCodecs、CDP）打破传统桌面工具与 Web 用例管理系统之间的窗口壁垒。

以上方案的完整实现已开源在项目 TabQA 中（可在 GitHub 搜索 openutx/TabQA 查阅完整源码与实现细节）。对于正在探索移动端效能工具研发、轻量化测试工作流的开发者而言，基于浏览器底层标准构建无驱动、一体化的测试套件，提供了一种兼具便携度与扩展性的工程落地新视角。

Build in public · 过程决策、踩坑与解法

Santo — Tue, 08 Sep 2026 09:07:16 +0800

上周「AI 对话管理器」到了 v0.1.0，回归 90/90。
有人问：中间到底怎么拍板的？踩了哪些坑？

一、过程里定死的 4 个决策

1）产品主轴 = 对话管理，不是又一个聊天框
做保存 / 整理 / 搜索 / 导出；不抢模型本身的对话体验。

2）架构用 Adapter，不写五套平行逻辑
页面 → Content Scripts + Adapters → Service Worker → 本地存储 + Side Panel
平台会变，抽取接口尽量统一。

3）数据默认本地（chrome.storage.local）
隐私优先；云同步留给以后的 Pro，不在 v0.1 里硬上。

4）用 G1 关口约束自己
主路径能存、能看、能搜、能备份，且全量回归无失败，才对外叫 v0.1.0。
没有「感觉差不多」这回事。

二、真实踩过的坑（按平台）

· 通义千问：角色错位、正文被推荐/检索墙顶替、表格加粗丢失、图/Word 卡丢了
· 腾讯元宝：图片没卡片；有了又和真实图叠两层；引用标记要清洗
· 豆包：多轮末条延迟、文件/图片不成卡片
· Kimi：图片标记没转成卡；代码块被误判成「文件/CSS」；必须进具体 /chat/ 页才能存
· 通用：新对话串出「未命名」脏数据；搜索「豆包 +AI 趋势」组合查不准；重载扩展后 AI 页要提示刷新

三、怎么解的（可复用的打法）

1）双通道抽取：API / 页面状态优先，DOM 补缺；合并时按轮次配对，绝不「全局取最长一段」把多轮压没。
2）展示层清洗 ≠ 存储层砍内容：思考过程、推荐墙、citation 标记可在展示剥掉；正文与媒体要完整可导出。
3）媒体一律卡片化 + URL 去重：有真实图就丢掉空占位，避免「假卡片 + 真图」叠罗汉。
4）搜索做成「平台 + 关键词」可组合，命中处出摘要并标黄——窄侧栏里只飘关键词不够用。
5）明确「不改」也是决策：
· Kimi 必须点进具体对话再存（页面没有稳定会话 ID）
· 列表批量删除留给后续 Pro 能力，不和本周主轴抢工期
· 跨机迁移 / 超大库压力测先 Block，不假装测过

四、这一周教我的

多平台扩展最难的不是「能不能 hook 到」，
而是每个站点都有自己的「汤」：思考壳、推荐墙、进度条、占位图、脏 session。
v0.1.0 的意义，是先把主路径打穿，再用回归清单把自己锁住。

下一篇会写：最痛的 3 个坑（细拆复盘）。
开源：https://github.com/SantoCc/ai-chat-manager

有在做浏览器扩展 / 多站点适配的，欢迎对一对你的坑。

来到新公司后产生了迷茫

5nine99 — Mon, 07 Sep 2026 18:48:45 +0800

我今年七月份入职了一家做自研小型机器人的公司。入职前，我本以为这个岗位是偏硬件的测试工作，但工作了两个月后，发现实际内容和我预想的有不小差距。目前我在测试部门的主要工作是：编写机器端的测试用例并执行，观察机器在实际运行中的行为，同时根据日志排查问题，涉及服务端和机器端，但更偏机器侧。

我之前的背景是软件测试，已经能做到接口自动化脚本编写的层面。其实我是有意往硬件测试方向发展的，但现在的工作更多是基础的功能验证，感觉像在 “降级”。不过，这段时间也确实让我接触并熟练了不少 Linux 指令，也提升了日志分析和问题定位的能力。

现在我有几个困惑，想请教一下有经验的前辈：

我现在这种工作状态，应该算什么类型的测试？算是产品验证，还是偏系统测试，还是某种 “软硬结合” 的测试岗位？

这样的岗位后续发展路径一般是什么样的？会不会局限在功能验证层面？

如果我想继续往更有深度的技术方向走，应该重点提升哪些技能？比如是否应该往编写机器脚本、自动化测试框架、还是底层驱动测试方向靠？

还有就是我现在对于 AI 的应用越来越少，AI 还能帮助我做些什么事情呢？

希望能得到一些方向性的建议，谢谢。

AI 提效的一个典型阶段 -- 数字分身

ycwdaaaa — Mon, 07 Sep 2026 10:12:33 +0800

前言

近期了解到大多数同学会使用 AI 来完成测试用例和自动化测试代码的生成工作，但后续如何让 AI 再前进一步时会陷入一时间的迷茫。不知道还有什么工作是可以让 AI 来做的。所以这里分享一下大厂的常见 AI 提效思路。

为什么需要数字分身

其实在工程效能领域一直有一个理念：凡是需要人来沟通和协作的，都是影响效率的卡点。比如开发同学提测，需要发提测邮件或者在企微上通知测试人员。而等到测试人员 “看到” 这条消息，可能已经过去了一段不短的时间，等到测试人员有时间来开始跑 P0 自动化测试用例（用作门禁，验证开发的提测没有老功能的主流程，这是提测的条件之一，如果不满足要打回提测。）可能就又过去了一段时间。所以等到测试人员运行测试用例，提交了 bug 就又过去了一段时间。而等开发同学收到了 bug 开始处理还需要时间。 “测试” 与 “开发” 一来一回，或者说几来几回。沟通，扯皮，bug 复现等等。时间就这么消耗出去了。尤其有时候测试人员忘了抓问题的 traceid 了，忘了附上报错信息或者日志截图了。开发就会找来要你提供，或者干脆他也不看 bug 单的步骤，而是直接让你共享屏幕，直接演示一下 bug 怎么触发的。

或者我们再换一个场景，产品同学发起需求评审。但我们一定经常遇到一种情况，就是产品经理会在很多很基础地方犯错误，或者有疏忽。导致在需求评审的会议上花大量的时间进行沟通。拿我们的智能体产品为例，我们有一个模块叫模型广场，它可以提供不同的模型让用户使用。当产品经理添加了一个新的模型（比如就说 deepseek 4 pro 吧），但这个模块其实影响了相当多的其他模块的功能，但这些是产品经理没有注意到，或者说他不清楚的，毕竟一个大型产品有很多产品经理，大家各自负责各自的东西，互相都不太了解。于是产品经理可能会忘记：

该模型是否应该支持深度思考开关，是否支持 high，low, media 的思考级别
该模型应该打上什么标签，是否支持作为 agent 思考模型，工作流模型，qa 问答生成模型，检索模型，rerank 模型。。。。。（等等一切其他场景）
该模型的操作是否进入审计日志。
该模型的权限位要如何设计。
该模型是否计费，如果计费它的 tpm 和 qpm 限制策略要怎么设置。
等等等等。。。。

其实以上这些都是咱们测试或者开发人员关心的，也是一些基础项。但大多数产品经理都会忽略，导致在需求评审会议上花费大量时间在去补充这些基础设定。

还是那句话，凡是需要人来沟通和协作的，一定是低效的。那要如何解决这些问题呢。那 AI 时代下，数字分身就比较重要了。如果我们能把测试这个角色设计成一个智能体，把我们自己一些基础的常用能力赋予这个智能体。那么就可以减少很多的协作问题。比如大家还记得我分享的需求分析和用例生成的 skill 么？如果我们提供一个智能体，它有一个需求分析的 skill，这个 skill 里的知识库有上述说的模型广场和其他模块的知识库，有做需求分析的工作流。那么产品同学在发起需求评审之前，用这个智能体先分析一波。就可以在需求评审之前解决很多问题。这样在需求评审会上，就是一个较为成熟的需求文档了。这样就节省了很多的无效沟通。同样如果有一个智能体能让开发同学说一句话就能触发门禁自动化测试用例，跑完后也能一句话针对报错的 case 进行归类分析，抓取 traceid，通过 traceid 抓取日志，并到代码仓库分析代码做初步的 bug 定位。这样也就不用开发人员和测试人员一来一回的沟通协作很多次。

这样的模式还可以发展到性能测试，容灾测试，环境管理等多个反向。总之就是把我们测试人员自身的一些稳定的，基础的能力，AI 化以及数字分身化。开发同学修复了 bug 后，要验证下，就艾特测试人员的数字分身跑一下用例。我刚才正好用我的分身跑了一下门禁，我来截取一下我的分身分析失败 case 的片段信息：

130556 存储挂载失败（数量：157，占比：82.2%）
 ⦁关键报错： failed to mount "/dev/vdb" to "/run/blk-cube/vdb", with error: EINVAL: Invalid argument，ret_code=130556
 ⦁判定依据：该错误发生在 CreateSandbox 阶段（156 个）和 ResumeSandbox 阶段（1 个），覆盖 CBS/CosFS/NFS/TCBS/TurboCFS/State/Lifecycle/Probe/Freeze/Unfreeze/Snapshot/Net/Vol/Cfg/Lc/Sched/Snap/Err/Res/Sec/Sp/Iv/DelSnap/EdTmp/Av/Uc/Multi/Merge/Legacy/TempV1/TempV15/TempV2 等几乎所有模块。报错特征高度一致—— /dev/vdb 设备挂载至  /run/blk-cube/vdb 时 EINVAL 参数无效。经验库中 130556 条目（virtiofs resume 限制）与本场景无关，本次是创建阶段的存储挂载失败，非 resume 阶段。判断为环境问题（节点存储设备/驱动层面异常）。
 ⦁代表用例： TcbsP1040PauseResumeNoSandboxIdTest
 ⦁测试目标：TCBS(system_disk rootfs) 写文件 → pause → resume（不传 sandbox_id，仅 checkpoint_id）→ 文件可读 → 删除。
 ⦁详细步骤：
 1. 创建沙箱（2期 writer erofs 镜像）：system_disk rootfs(TCBS)，等 RUNNING + /health
 2. 向 /data 写入探针文件（内容含本次运行唯一 uuid），回读确认写入成功
 3. pause（POST /v2/cube/pause，内联 create body），等 checkpoint SUCCESS，取 checkpoint_id
 4. resume 时不传 sandbox_id（body 里 sandbox_id 为空串），仅传 pause 返回的 checkpoint_id，等 RUNNING + /health → resume 成功并返回新 sandbox_id
 5. resume 后回读探针文件，内容与写入一致（TCBS rootfs 重挂载正常，数据持久）
 6. 删除探针文件并确认已删除
 7. 清理：删除 resume 后的沙箱（原沙箱已被 pause 销毁）
 ⦁失败步骤：创建沙箱（1.5期 writer）+ system_disk rootfs(TCBS)（落点 ins_ip=10.128.2.19）
 ⦁定位信息：
 ⦁sandbox_id=未创建沙箱，无 sandbox_id
 ⦁request_id=CreateSandbox:88a2e73e-8a02-4a9d-ab6c-e729ccb1d514

以上测试失败了大量的 case，但是 AI 分析出其中 157 个其实都是同类型的问题，占比 82.2% ，抓到关键报错和分析，代表用例步骤，以及 traceid。接下来就可以用这个 traceid 去用智能体查看日志和分析代码做 bug 定位。这里需要说一句，很多时候开发同学刚刚提测，我们跑自动化测试可能会失败大几百的 case（因为可能是由于某几个主流程逻辑失败导致大量 case 失败）这时候要一个一个看是很麻烦的，我们用 AI 进行失败聚类和分析，也是一个非常节省时间的操作。

于是，我用公司的智能体平台，构建了自己的数字分身（其实就是一个智能体），我把编写用例的能力，对接测试平台跑自动化测试的能力，分析失败 case 的能力，抓取日志分析开发代码的能力，环境检查和部署的能力，故障注入的能力（容灾测试），性能测试的能力，镜像和沙箱构建的能力，等等等等都写成 skill。然后对接企微机器人，就这样我的数字分身就实现了。开发要找测试做什么事，都可以先让我的数字分身来搞一波，不用等我抽出时间才能跟他对接。

结尾

目前数字分身方案已经在大厂之间流行了起来，一些中小厂也开始跟进。也算是属于 AI 提效的阶段化成果。各位没有思路的同学可以适当参考。

简单项目 AI 随便写，复杂度一上来就顾头不顾尾

Santo — Mon, 07 Sep 2026 09:27:23 +0800

这个"病"长什么样

先说个公道话：简单项目里，AI 是真的神。

写个单文件爬虫、改个正则、调一个 prompt、写个数据清洗脚本——你话还没说完，它代码已经给你了，跑起来就是对的。我见过太多人（包括我自己）在这个阶段产生幻觉："这东西已经能替我干活了。"

然后项目一复杂，它就开始"犯病"，而且犯得非常有规律：

你让它优化模块 A，A 确实优化得漂亮，模块 B 崩了
你让它修 B，B 修好了，模块 C 崩了
你让它把 B 和 C 一起修，它俩都好了，D 悄悄坏了三天你才发现
每一次它都态度诚恳："已修复，测试通过 ✅"

像什么呢？像多米诺骨牌。你伸手推倒的是第一块，倒的是一整排。 而 AI 每次都只盯着你让它扶的那块，扶完就举手报告，从来不看后排正在连锁倒塌。

这个病最坑人的地方在于：它不是能力下降，是视野缺失。 单模块任务里它 90 分，多模块联动里它还是那个 90 分的单模块水平——但系统需要的是 100 分的全局观，这 10 分没人补，窟窿就一个接一个。

我的真实案例

我有个跑了挺久的 AI 资讯日报工作流，4 个节点串联：

节点1 资讯抓取 → 节点2 AI筛选去重 → 节点3 AI摘要 → 节点4 排版输出

节点 1：HTTP 抓取 + 解析，输出文章列表 [{title, url, source, publish_time}]
节点 2：LLM 筛选，去重、打分、分类，输出选中的文章
节点 3：LLM 逐篇生成摘要
节点 4：按分类分组，排版成 Markdown 日报推送

这个工作流跑了一个多月，相安无事。直到我觉得日报太长——每天推 20 多条，根本看不完。我让 AI 优化节点 2："筛选收紧一点，只留高价值的，控制在 8 条以内。"

第一轮：节点 2 优化完成 ✅

AI 干得相当漂亮。它把节点 2 重写了：

去重逻辑从"标题完全相同"升级成"标题相似度 > 0.85"
每篇文章加了 score（打分）和 reason（入选理由）
输出从一个平铺列表，改成了按优先级分组的结构：

# 旧输出：list
[{title, url, category, ...}, ...]

# 新输出：dict，按优先级分组
{
  "high":   [{title, url, score, reason, ...}, ...],
  "medium": [{title, url, score, reason, ...}, ...]
}

它还贴了节点 2 的单测结果：喂 30 篇模拟文章进去，输出 high 组 3 篇、medium 组 5 篇，打分有理有据。

"优化完成，筛选准确率明显提升。"

我看着挺满意。那天晚上，日报空了。

第二轮：节点 3 崩了

节点 3 的代码是按列表写的：

for article in node2_output:          # 以前这里是 list
    summary = llm_summarize(article)  # 现在 node2_output 是 dict

dict 直接 for 遍历，拿到的是 key——字符串 "high"、"medium"。节点 3 拿着这两个字符串当文章内容去喂 LLM 摘要，输出了一堆不知所云的东西，工作流直接报错中断。

节点 2 的输出结构变了，消费这个输出的节点 3，AI 一个字没动。 它的"测试通过"，是只测了节点 2 自己。

我让它修。它很快把节点 3 改成先 flatten 分组结构再遍历，还顺手适配了新字段。节点 3 跑通了，摘要质量看着不错。

"已修复。"

第三轮：节点 4 崩了

第二天日报出来了，能推送，但是所有文章都挤在"未分类"里，原本"行业动态/技术干货/产品发布"三个版块全乱。

原因：节点 3 在适配新结构时，输出字段从 summary 改成了 content，flatten 的时候还把 category 字段弄丢了。节点 4 按 category 分组排版，取不到字段，全部落进默认分组。

我继续让它修。节点 4 修好了，分组恢复正常。

第四轮：回头一看，节点 1 也歪了

到这里我多了个心眼，让它把全链路跑一遍——这才发现最隐蔽的问题：

节点 2 的去重逻辑升级后，漏斗变紧了（30 篇进来，筛完只剩 8 篇）。但节点 1 的抓取参数还停留在旧时代——分页只抓 30 篇。以前 30 篇筛 20 条够用，现在 30 篇筛 8 条，high 组经常只有 1-2 篇，日报的"重点推荐"版块天天开天窗。

这个问题不会报错、不会中断、输出格式也全对——它只是静默地变差。如果不是端到端跑了一遍完整数据，我可能要等周报数据难看时才发现。

四轮下来，我的体感是：

我每说一句话，它就精准地完成这句话字面意思的 20%——就是我指着的那块。至于这块动了之后，整条链上还有什么会跟着动，它从来没主动看过一眼。

为什么 AI 会这样？

1. 它的注意力天生是"局部"的

你说"优化节点 2"，模型这轮的全部注意力都在节点 2 上：怎么让筛选更准、结构更合理。节点 3、节点 4 在上下文里存在，但在这一轮的注意力分配里，它们是背景板。

人类工程师接到"优化筛选"的需求，第一反应是："筛选结果谁在用？改了输出结构，下游会不会炸？" 这个反应叫影响面分析。AI 没有这个本能——它不是不会，是你不逼着问，它默认不做。

2. 它手里没有"系统全景图"

4 个节点的 prompt、代码、数据结构，理论上都在上下文窗口里。但"在窗口里"不等于"在注意力中心"。

这就像一份 40 页的文档摊在你桌上，你正盯着第 12 页改错别字——第 28 页引用了第 12 页的一个表格名，这件事你"看得见全文"也想不起来。复杂度的本质不是代码多，是关系多；而关系，恰恰是上下文里最先被压扁的东西。

3. 它的"测试通过"是单点测试，不是系统测试

这是我做了 10 年测试最敏感的一点。AI 改完一个模块，验证方式是给这个模块喂输入看输出——这相当于只跑单元测试。

但真实项目里，单测全绿、集成全崩是日常。模块间的契约（数据结构、字段名、类型、顺序）才是集成测试的主战场，而 AI 验证自己的改动时，几乎从不跨模块走一遍。

4. 为什么简单项目没这个病？

因为单文件脚本里没有"关系"：代码从上到下顺序执行，输入输出就一条线，改哪是哪。

不是 AI 在简单项目里更聪明，是简单项目里根本没有能连锁崩塌的东西。一旦模块间出现契约和耦合，改动就开始沿关系网传播——而 AI 只会在你指给它的那个节点上使劲。

这种病的代价

🔴 修一个崩三个，4 轮对话过去，你分不清现在系统是好是坏，只知道"每个被点名的问题都修好了"
🔴 静默劣化最致命：报错的问题你会修，不报错的问题（抓 30 条筛 8 条、数据量悄悄缩水）会一直潜伏，直到数据难看才暴露
🔴 你的注意力被拖进细节：本来雇 AI 是让它干脏活，结果你成了那个唯一记得全局的人，逐个节点排查关系——架构师的活一点没少
🔴 信任成本飙升：从"改完直接用"退化成"改完全链路重测"，AI 提效的收益被返工和回归吃掉一大块

怎么治

方法 1：你当架构师，AI 当模块工

接受一个现实：全局视角这个活，AI 接不住，只能你自己扛。

动手改之前，你自己先花 10 分钟把数据流画出来：

节点1 → [articles: list] → 节点2 → [high/medium: dict] → 节点3 → [items: list] → 节点4 → Markdown

不用多规范，纸上、白板、注释里都行。关键是：谁的输出是谁的输入，每一段传递的数据长什么样，你心里要有这张图。 AI 负责节点内部怎么实现，节点之间的契约，你拍板。

方法 2：契约先行，schema 就是法律

每个节点的输入/输出写成明确的契约文档：

## 节点2 输出契约
- 类型：object
- 字段：
  - high: array，必填，文章对象列表，0-5条
  - medium: array，必填，文章对象列表，0-10条
- 文章对象：{title: string, url: string, category: string, score: number, reason: string}

然后给 AI 立规矩：

"优化节点 2 内部逻辑可以，但输出结构不许动。如果你认为必须改输出结构，先停下来告诉我改什么、为什么，等我确认并同步改完契约文档，再动代码。"

结构变更从"AI 顺手就改"变成"必须走审批"，连锁崩就断了源头。

方法 3：每次改动，先逼它做影响面分析

下指令时加一句固定台词：

"在动手改之前，先列出：这个改动会影响哪些下游节点/模块？逐个节点列出它依赖的输入字段，以及需要同步修改的地方。列完给我确认，再动手。"

它列不全，没关系——以我这轮的经验，它自己列出来的部分就能挡掉 80% 的连锁崩。关键是把"影响面分析"从它的可选项变成你的必问项。

方法 4：黄金用例端到端回归，不接受单点"已修复"

测试老兵的老本行：准备 1-2 条固定的真实输入（比如某天抓回来的 30 篇原始文章存成 fixture），每次改动后，从节点 1 跑到节点 4，检查最终日报。

验收标准只认一条：最终产物对不对，不看中间节点"测试通过"。

"已修复"不算数。跑一遍全链路，把最终输出贴出来，我看过才算。

单节点测试是 AI 的自我安慰，端到端才是系统的真相。

方法 5：连锁两轮就停手，回滚重来

给自己设一条熔断线：

修 A 坏 B、修 B 坏 C，连续两轮——立刻停，不要再让 AI"接着修"。

继续修下去，它只会在局部打更多补丁，系统变成谁也不敢碰的屎山。正确动作是：回滚到上一个完整可工作的版本，重新理一遍节点契约，想清楚改动路径，再重新下手。

返工一小时，好过补丁打三天。

一句话总结

简单项目里 AI 是神兵，复杂项目里 AI 是新兵——单兵能力满分，战场态势感知为零。复杂度一上来，你就不再是写代码的人，而是那个唯一看着全局的人：契约你来定，影响面你来盯，端到端回归你来卡。它负责把点做深，你负责让点连成线。

Thinking Machines Lab 洽谈 10 亿美元融资，估值 400 亿美元；微软发布 MAI-Transcribe-2，1 小时音频 10 秒转完丨日报

RTE — Sat, 05 Sep 2026 22:34:26 +0800

本期编辑：@ 三水、@ 鲍勃

01 有话题的技术

1、微软发布批量语音识别模型 MAI-Transcribe-2：新增说话人分离与逐词时间戳，1 小时音频约 10 秒完成转录

Microsoft AI 发布批量语音识别模型 MAI-Transcribe-2。相比 MAI-Transcribe-1.5，新版本新增说话人分离、逐词时间戳和可配置转写风格，语言覆盖从 43 种扩展到 60 种，同时把 1 小时音频的模型推理时间从约 20 秒缩短至 10 秒。

Okay, listen. I have this absolutely unhinged idea, and I need you to roll with it. Help me make an agent that will literally buy tickets for my favorite band the second they are available.

说话人分离和逐词时间戳直接内置到模型： MAI-Transcribe-2 可以在转录时区分不同说话人并将文本归属到对应人物，同时为每个词输出精确时间位置；这两项能力在 MAI-Transcribe-1.5 中均未提供。
新增两种转写风格： 开发者可以选择「逐字」模式，保留填充词、停顿和口误，用于合规或分析；也可以选择「整洁」模式，自动去除口头填充内容，生成更适合字幕、笔记和发布的文本。
支持对话中的语言混说： 模型可处理同一段对话自然切换不同语言的情况，包括 Hinglish、Spanglish 等常见混说组合；同时继续支持关键词偏置，可针对人名、缩写和领域术语提高识别准确率。
长音频推理速度提升约一倍，价格降至每小时 0.10 美元： 官方对比显示，1 小时音频的模型推理时间由 MAI-Transcribe-1.5 的约 20 秒缩短至 10 秒；限时价格从每小时 0.36 美元降至 0.10 美元，该价格持续至 2026 年底。
60 种语言 FLEURS 平均 WER 为 5.2%： MAI-Transcribe-2 在 FLEURS 60 种语言评测中排名第一；在 Artificial Analysis 的 WER 榜单中以 2% WER 排名第二，较上一版的 2.4% 进一步降低。

模型：

https://microsoft.ai/models/mai-transcribe-2/

博客：

https://microsoft.ai/news/mai-transcribe-2-is-the-fastest-most-accurate-and-cheapest-speech-recognition-model-in-the-world/

2、港中深、NUS、NVIDIA 等开源交互式视频世界模型体系 SolarWM：统一 143 万段视频训练流程，覆盖 5B–33B 四种模型

香港中文大学（深圳）、新加坡国立大学、香港中文大学、香港科技大学、NVIDIA、UCLA、微软亚洲研究院等团队开源 SolarWM，一套覆盖数据整理、模型训练到长时实时推理的交互式视频世界模型体系。项目将 143 万段异构视频统一成同一套交互训练格式，并用一套训练框架适配 Wan2.2、LTX-2.5 和 MiniMax-H3，形成四个 5B–33B 规模的世界模型。

先把分散的世界模型数据统一起来： SolarWM 对 143 万段视频统一整理视觉画面、相机几何参数、文本描述、质量信息和数据来源等字段，把原本格式、镜头参数和标注方式不同的数据转换成同一套逐帧对齐格式，使不同视频骨干可以复用同一套数据处理和训练流程。
一套框架覆盖四种不同规模的视频骨干： 当前支持 SolarWM-Wan-5B、SolarWM-Wan-14B、SolarWM-LTX-2.5 和 SolarWM-MiniMax-H3，参数规模横跨 5B–33B，同时尽量保留不同基础模型原有的表示方式和训练目标，而不是为每个模型重新搭建一套世界模型训练代码。
用三阶段流程把双向视频模型改造成可交互的自回归世界模型： 训练依次经过双向适配、教师强制自回归初始化和分布匹配蒸馏。其中最后阶段让模型在自身生成的历史画面上继续训练，把原本面向完整视频生成的模型转换成可以持续接收控制并向前生成的因果模型。
只训练 5 秒视频，也能连续运行数分钟甚至数小时： SolarWM 的训练序列只有 5 秒，但最终模型可以进行分钟级到小时级的实时连续生成，无需额外使用长视频微调或专门的长上下文机制，重点解决交互式世界模型长期运行时的误差累积问题。
数据、代码、训练流程和模型权重均已开放： 项目已发布数据处理管线、训练与推理代码及模型权重；其中 Wan2.2-5B 已开放三个训练阶段的完整权重，其余 14B、LTX-2.5 和 MiniMax-H3 当前开放双向模型权重，后续训练阶段仍在补充。

https://junchao-cs.github.io/SolarWM-Web/

3、通义千问团队、华中科技大学开源自动驾驶视觉语言基础模型 Qwen-Drive-1.0：4B 模型统一 3D 感知、视觉问答与运动规划

通义千问团队与华中科技大学推出并开源 Qwen-Drive-1.0，一款面向自动驾驶的 4B 视觉语言基础模型。它以 Qwen3.5-4B 为共享视觉语言骨干，在不改动原有模型架构的情况下外挂鸟瞰图（BEV）感知头和规划专家，让同一套模型表示同时服务于 3D 环境感知、驾驶场景问答和车辆运动规划。

把感知、理解和规划放进同一模型： BEV 感知头同时完成 3D 目标检测、语义占用预测和地图分割；原有语言模型负责通用及驾驶场景视觉问答；规划专家则读取共享视觉语言表示，预测自车未来行驶轨迹。
不改 Qwen3.5 主干，通过外挂模块扩展驾驶能力： Qwen-Drive-1.0 保留预训练 Qwen3.5-4B 的主体架构，仅增加约 0.5GB 的 BEV 感知模块和约 2.1GB 的规划专家权重。这种设计让模型获得自动驾驶专用能力的同时，尽量保留原有通用视觉理解和指令遵循能力。
规划提供直接输出和「先推理再规划」两种路径： 官方开放监督微调版和强化学习优化版两套规划专家；前者同时支持直接规划和推理后规划，后者针对带推理过程的规划进一步优化。模型因此可以直接生成未来轨迹，也可以先解释驾驶场景与决策依据，再输出规划结果。
训练数据也统一跨数据集格式： 团队将不同自动驾驶数据集中的感知标签映射到统一类别体系，同时统一视觉问答答案格式和车辆轨迹表示，再与通用视觉语言数据共同训练，减少模型获得驾驶专用能力后对原有通用能力的遗忘。
模型、代码和 Demo 已开放： Qwen-Drive-1.0-4B 以 Apache 2.0 许可证发布，GitHub 同时提供视觉问答、规划、3D 感知和评测代码，以及可直接运行的 Waymo 驾驶场景 Demo。

https://github.com/QwenLM/Qwen-Drive-1.0

02 有亮点的产品

1、YC F25 智能眼镜公司 AirCaps 推出音频研究实验室：开发全流式远场语音模型，可在消费级硬件端侧运行

YC F25 智能眼镜公司 AirCaps 正式推出 AirCaps Audio Research Lab，开始将其面向真实线下环境积累的音频能力扩展成一套全流式语音与音频模型体系，覆盖目标说话人提取、远场语音增强、说话人区分与识别、重叠语音分离和语音转文本。与主要针对干净近场音频优化的语音系统不同，AirCaps 将重点放在远距离、混响、低信噪比、多人同时说话等真实声学环境。

从 ASR 扩展到整条真实世界音频处理链路： AirCaps 不只做语音转文本，而是从前端的目标说话人提取、远场增强和重叠语音分离，一直到说话人归属与最终转录，希望让模型直接处理未经清理的复杂现场音频。
所有能力都面向流式和端侧场景设计： AirCaps 表示，这些模型能够持续处理实时进入的音频，并在消费级硬件上运行，而不是完全依赖云端批量处理。这与其智能眼镜产品需要持续监听线下对话、实时显示字幕的工作流直接相关。
公开了针对噪声、远场和多人会议的 ASR 鲁棒性评测： AirCaps 发布的 A5Sv2 流式 ASR Benchmark 覆盖 Mega-ASR、AMI、DiPCo 和 NOTSOFAR 四套公开数据。在其自建测试协议下，A5Sv2 在 Mega-ASR 噪声与远场集合上的 WER 为 19.68%，低于 ElevenLabs Scribe v2 Realtime 的 22.64%、OpenAI GPT Live Transcribe 的 27.81% 和 Google Chirp 3 Streaming 的 34.68%；但在四套数据整体平均成绩上，ElevenLabs 仍排名更高。
研究方向来自智能眼镜真实部署中的问题： AirCaps 原本提供实时字幕、翻译和线下会议 AI 助手，官方称其已处理超过 1.65 万小时真实线下对话。团队表示，在咖啡馆、餐厅、多人讨论等环境中测试现有云端语音模型时，噪声、混响和重叠语音仍会显著影响转录，因此将这些问题独立成新的音频研究方向。

https://research.aircaps.com

2、YC F25 个人 AI 助手 Caddy 从桌面语音控制转向 iMessage：可主动读取工作上下文并替用户执行任务

两位前 Loom AI 产品负责人创立的 YC F25 项目 Caddy，正在把产品从最初的「用语音控制电脑」转向常驻 iMessage 的个人 AI Agent。用户无需下载独立 App，只需像给联系人发消息一样与 Caddy 对话，它会持续学习用户的工作方式和关注事项，并连接 Gmail、Google Calendar、Slack、Linear、Todoist 等工具完成后续操作。

从「语音操作电脑」转向「消息里的长期个人 Agent」： Caddy 最初以桌面语音界面切入，能根据屏幕内容，用语音创建 Linear 工单、发送 Slack 消息或安排会议；当前产品则把 iMessage 作为主要入口，用户可以通过文字、语音留言甚至群聊持续与 Agent 交互。
不再只等用户下指令，而是主动追踪工作上下文： Caddy 可以关注用户授权连接的日历、消息和任务，在有事项需要处理时主动发消息提醒；对于提醒、日程准备和部分任务，还可以提前规划下一步，而不是每次都从一个 Prompt 开始。
消息可以直接转成跨应用操作： 用户可以让 Caddy 查询邮件、起草回复、创建或修改日历事件、跟踪 Slack 与 Linear 中的事项；涉及发送邮件、修改日程等敏感操作时，系统会先要求用户确认。
两位创始人此前负责 Loom 的 AI 产品与设计： Connor Waslo 和 Rajiv Sancheti 在创办 Caddy 前均在 Loom 工作约四年，分别负责 AI Suite 的产品和设计。Caddy 目前处于公开测试阶段。

https://caddy.app/

3、OpenAI 发布旗舰模型 GPT-6 Astra：强化电脑操作与长任务执行，Codex 可跨上下文保存并检索工作记忆

OpenAI 发布新一代旗舰模型 GPT-6 Astra，重点提升电脑操作、软件工程、浏览器使用和复杂专业任务执行能力。相比 GPT-5.6 Sol，新模型不仅在多项推理与代码评测上提升，更明显的变化是能够更快完成跨应用、多步骤工作流，并在长任务中更稳定地理解用户意图和持续接受中途调整。

电脑操作速度和成功率同时提升： 在 OSWorld 2.0 中，GPT-6 Astra 得分从 GPT-5.6 Sol 的 65.7% 提升至 72.6%；OpenAI 的延迟模拟显示，单个任务平均耗时从约 75 分钟缩短至约 40 分钟，时间减少约 47%。模型可直接完成填写网页表单、操作 CRM、整理日历、安装软件和浏览器测试等任务。
Codex 引入跨上下文工作记忆，不再只靠压缩摘要维持长任务： 当上下文窗口用满后，Astra 可以持续保存工作笔记，同时让此前的上下文保持可搜索；后续可以重新检索早期需求、测试结果和工具输出，即使这些信息没有被写进压缩摘要。这项机制主要面向大型重构、长时间调试等持续数个上下文窗口的 Coding Agent 任务。
中途修改需求时更不容易「丢掉原任务」： OpenAI 表示，上一代模型有时会把用户的补充指令当成新的目标；Astra 则能够在保持原有任务约束的同时接受新要求、回答旁支问题并继续执行。对于信息缺失的任务，它也会区分普通细节与关键决策：前者可自行补全，后者则主动询问用户。
代码和专业工作能力进一步向 Agent 场景倾斜： Terminal-Bench 4.0 从 GPT-5.6 Sol 的 37.3% 提升至 57.9%，AutomationBench 从 18.1% 提升至 41.4%；模型同时针对文档、表格、演示文稿和数据分析等专业工作进行了强化训练。
API 型号为 **gpt-6-astra：** GPT-6 Astra 将通过 OpenAI API、Microsoft Azure 和 AWS Bedrock 提供，标准 API 价格为每百万输入 Token 10 美元、输出 Token 50 美元；另提供最高约 2 倍速度的 Fast 模式，价格为标准模式的 2 倍。

https://openai.com/index/gpt-6-astra/

4、前 OpenAI CTO 创立的 AI 公司 Thinking Machines Lab 洽谈至少 10 亿美元融资：投前估值至少 400 亿美元，Accel 拟领投

前 OpenAI CTO Mira Murati 创立的 Thinking Machines Lab 正在洽谈新一轮至少 10 亿美元融资，投前估值至少 400 亿美元，现有投资方 Accel 正洽谈领投，Nvidia 也讨论过参与。若交易完成，这家成立不到两年的 AI 公司估值将较 2025 年首轮融资时的 100 亿美元投前估值增长至约 4 倍。

估值较首轮融资大幅跃升，但低于去年底目标： Thinking Machines 2025 年 7 月曾由 a16z 领投 20 亿美元，当时投前估值为 100 亿美元；去年底公司一度讨论以超过 500 亿美元估值融资 40 亿至 50 亿美元，此次拟议估值则回落至至少 400 亿美元。
融资发生在首款开放权重模型 Inkling 发布之后： Thinking Machines 于今年 7 月推出首款模型 Inkling。模型权重可免费使用，公司主要通过向企业提供模型定制工具收费，帮助客户利用自身数据适配包括 Inkling 在内的 AI 模型，而不是单纯依靠模型 API 收费。
The Information 称其年化收入已达数亿美元： 报道援引知情人士称，Thinking Machines 当前年化收入至少达到数亿美元。按至少 400 亿美元估值计算，其估值相对于收入仍处于较高水平。
新资金将继续投入模型训练和算力： 融资资金预计用于训练自有模型、租用服务器和扩充团队。今年 3 月，Nvidia 已宣布对 Thinking Machines 进行未披露金额的投资，并建立长期、吉瓦级战略合作关系，进一步保障其训练和推理所需算力。

(@The Information)

5、Google 上线 Gmail Live、Docs Live 与 Keep Live：把实时语音对话扩展到邮件查询、文档创作和笔记整理

Google 正式将此前在 I/O 预览的 Gemini 音频能力带入 Gmail、Docs 和 Keep，推出 Gmail Live、Docs Live 与 Keep Live。相比传统语音输入只负责「把说的话变成文字」，新的 Live 入口支持用户与应用持续对话，并直接基于当前 Workspace 内容完成搜索、写作和整理任务。

Gmail Live 可直接用语音查询邮箱内容： 用户可以连续提问「我的航班登机口是多少」「这周孩子学校有什么安排」等问题，Gmail Live 会检索邮箱中的相关邮件并直接返回答案，不需要手动输入关键词和逐封翻找。
Docs Live 从语音听写升级为实时共同写作： 用户可以直接口述想法，由 Docs Live 一边对话一边整理结构、起草文档和调整语气；在获得授权后，还能调用 Gmail、Drive、Chat 和网页中的相关信息补充内容。
Keep Live 将自由口述自动整理成结构化笔记： 用户可以直接进行长段、无结构的口述，系统会在后台理解内容，再整理成列表和可执行笔记，而不是简单保存一份逐字转录。
从 I/O 预览进入正式上线阶段： 三项能力本周开始陆续开放，意味着 Google 正把实时语音交互从 Gemini 独立体验进一步嵌入 Workspace 的日常工作流。

https://blog.google/products-and-platforms/products/workspace/voice-features-gmail-docs-keep/

03 有态度的观点

1、奥特曼：OpenAI 将开发人形机器人

OpenAI CEO 山姆·奥尔特曼在《Sources with Alex Heath》播客中表示，OpenAI「一定会做人形机器人」，同时也会研发其他形态的机器人。这是他首次明确确认 OpenAI 将开发自有的人形机器人本体。

奥尔特曼解释称，现有的门、键盘、设备和厨房都按照人类身体构造，因此人形结构有利于机器人适配现实环境。但在数据中心等场景，OpenAI 会选择更适合具体任务的非人形设计。

他认为，机器人的外形最终仍要服务于「让机器人工作的大脑」。面对行业对机器人外形路线的不同判断，奥尔特曼把机器人的「大脑」放在机身之前。

他表示，OpenAI Robotics 的基础是机器人硬件研究与机器学习的共同设计；团队招聘方向涵盖全栈硬件、系统、机器学习和运营，目标是让模型能在真实物理环境中完成任务。

他把「每个人都拥有能完成各种任务的个人机器人」描述为长期目标，短期重点则是支持数据中心和其他基础设施建设。OpenAI 今年早些时候已组建内部机器人团队，并招聘机电执行器、仿真管线和数据收集等方向的工程师。

（@APPSO）

04 社区黑板报

招聘、项目分享、求助……任何你想和社区分享的信息，请联系我们投稿。（加微信 creators2022，备注「社区黑板报」）

1、🎲 北京招募 AI 主题《Talk With》桌游主持人！

10 月底，我们又要在北京开玩 AI 主题桌游《Talk With｜聊天能解决的事儿》啦，这次想从开发者社区里招募几位桌游主持人，一起把现场带起来～

作为主持人，你主要需要：

给一桌 3–5 位玩家讲解规则、带大家完成游戏
控制每轮节奏，推动竞拍、路演和投票
最重要的是——会聊天、带气氛，让一桌陌生开发者迅速玩起来

不用是资深桌游玩家，我们会提前带大家熟悉完整玩法，帮助你开启主持人之路~如果你对 AI / Voice AI / 开发者社区 / 桌游感兴趣，就非常适合来！

📍地点：北京

📅时间：10 月底

想来当主持人的朋友，可以直接私聊我报名～这次不只来玩一局，而是来当那个让整桌人都玩嗨的人 😎

写在最后：

我们欢迎更多的小伙伴参与 「RTE 开发者日报」 内容的共创，感兴趣的朋友请通过开发者社区或公众号留言联系，记得报暗号「共创」。

对于任何反馈（包括但不限于内容上、形式上）我们不胜感激、并有小惊喜回馈，例如你希望从日报中看到哪些内容；自己推荐的信源、项目、话题、活动等；或者列举几个你喜欢看、平时常看的内容渠道；内容排版或呈现形式上有哪些可以改进的地方等。

作者提示: 个人观点，仅供参考

第一周：从 0 写出 v0.1.0，回归测试 90 项全过（附架构图）

Santo — Sat, 05 Sep 2026 21:18:17 +0800

1/4 · 开场 + 为什么做

Build in public · Week 1

第一周：从 0 写出 v0.1.0
回归测试 90 项全过（附架构图）

痛点：豆包 / 千问 / DeepSeek / 元宝 / Kimi
对话散落在 5 个站，搜不到、难复用。

我做的不是又一个聊天机器人，
而是把「聊完的东西」变成可管理资产：
保存 · 整理 · 搜索 · 导出 · 本地隐私。

#BuildInPublic

2/4 · 架构图 + 产品链接

v0.1.0 架构

5 个 AI 页
→ Content Scripts + Adapters
→ Service Worker（保存/搜索/导出）
→ 本地存储 + Side Panel

Adapter 模式：平台可变，主轴是对话管理。

开源在这（开发者模式可装）：
https://github.com/SantoCc/ai-chat-manager

3/4 · 第一周进度盘点

Week 1 进度

✅ 五平台保存链路
✅ 文件夹 / 搜索 / JSON 备份
✅ 媒体卡片与格式硬仗
✅ 钉死版本 v0.1.0

目标：从「能用」到「敢给别人装」。

4/4 · G1 关口通过

G1 关口：通过
回归 90 / 90 · fail 0
P0 42 · P1 38 · P2 10

规矩：主路径能存能看能搜能备份，
全量回归无失败，才对外叫 v0.1.0。

之前做的几个东西（ai 远程自动化、模型标注平台、多 agent cli 工作台等等）开源给大家吧可以的话给个星星

icesword760 — Fri, 04 Sep 2026 17:59:27 +0800

用得着就帮我的 github 点个星星⭐️ 用不着就看看

1、Claude Code 多智能体桌面 cli 工作台
关键词：
卡片式 cli dag 图管理看板模式 cli 间通信 cli 会话持久化
git 地址：
https://github.com/icesword0760/matou

2、远程浏览器 ai 智能控制
关键词：
远程投屏 ai 控制元素自愈录制回放
git 地址：
https://github.com/icesword0760/ruyi

3、yolo 和可视化标注平台
关键词：
Omniparserv2 可视化标注模型训练 Florence-2 yolov8
git 地址：
https://github.com/icesword0760/zhubi

金融科技公司招聘测试工程师助理 10-15K

Irene.chen — Fri, 04 Sep 2026 15:06:40 +0800

岗位职责

负责公司 AI 金融软硬件终端的全流程功能测试，包括测试方案设计、案例编写评审、执行、缺陷跟踪与回归测试，确保金融业务逻辑的准确性与稳定性。
聚焦金融产品前端测试场景，针对交易界面、行情展示、资产账户、风控模块独立设计测试案例，覆盖交互、数据准确性、兼容性，精准定位问题并推动优化。
参与软硬件结合产品测试，协同硬件与研发团队梳理软硬件交互逻辑，搭建测试环境，完成跨模块联动测试，保障协同稳定性。
配合产品、研发团队开展需求与用例评审，从金融测试角度提前识别业务逻辑漏洞与潜在风险，推动缺陷高效修复，保障产品顺利上线。

任职要求

本科及以上学历，1-3 年测试工作经验，必须要有金融产品测试背景。
熟悉前端测试方法与工具，能独立完成测试全流程。
具备软硬件结合、自动化测试、或 AI 大模型产品测试经验的优先。

工作时间：朝 9 晚 6，午休 2 小时，周末双休
福利：带薪年假、年终奖、项目奖、硬核背景、扁平化管理
公司名称：深圳市金融大数据应用平台有限公司（猎聘可投）
简历请发送至：hr@chinafbdc.com

公司从零开始推自动化测试，如何落地？

mikezhou — Fri, 04 Sep 2026 10:45:59 +0800

知乎上刷到一个提问，挺常见的，拎出来，今天来聊一聊：

「我们团队之前一直是手工测试，现在老板要求转型自动化，但大家都没经验，不知道从哪下手。」

底下有个回答写得挺不错的，流程、分层、选型、避坑都过了一遍。但看得我手痒，因为这个问题我实在太熟了。带过团队推自动化的人都知道，这事的坑，大多不在怎么用工具或写代码层面。

那篇回答里有句话，我特别想拍桌子。

很多公司自动化落地失败，工具往往不是主因，主因是一开始目标就设错了。

我再加半句。也不光是目标的事，自动化落地从来是三分技术，七分管理。

下面把我这些年来的经验，揉着那篇回答的骨架，一次讲完。

一、先和老板对齐，自动化到底要解决什么

老板说「我们要搞自动化」，你先别急着开选型会。

你要先听懂一句潜台词。老板要的从来不是「自动化」这三个字，他要的是每次发版之前，有一张能快速兜底的网。

所以第一个动作是拉齐预期，先把三件事和你的领导聊明白。

第一件，自动化不是来替代手工测试的。

把手工用例全部翻译成脚本，这个目标必死。自动化测试不是把所有手工测试都改成自动执行，
现实目标是让最稳定、最高频、最有回归价值的流程在每次发版前稳定跑一遍。

第二件，第一阶段的 KPI 是信心，不是覆盖率。

让团队亲眼看到，原来这几条流程真的能自动跑，跑挂了还知道怎么处理。这个信心建立起来，后面的一切才有得谈。覆盖率是水到渠成的事，而不应该作为最终结果。

第三件，别一上来就大而全。

第一阶段忌讳大而全，全部核心功能，接口、UI、APP 三线齐飞，一个月覆盖几百条用例，这种目标看着有决心，实际是把团队往火坑里推。

比较稳的开局是选 5 到 10 条流程做试点。挑的标准就六条，每次发版都要测、操作路径相对固定、测试数据好准备、结果判断明确、失败能快速定位、手工重复成本高。

落地这件事，小胜利比大蓝图管用。

二、一张表，一条循环，一套规矩

预期对齐了，具体怎么干，我将其浓缩成三样东西。

先画一张表。

别急着谈工具。先让测试和业务坐在一起，把每次发版到底要测什么列清楚。流程、频率、重要性、稳定性、数据准备难度、适不适合自动化，一列一列打分。

从高频、高价值、相对稳定的开始挑。这张表画完，你会发现真正值得自动化的流程，比想象中少得多，这是好事。

再跑一条循环。

一个项目、一个环境、几条用例，从准备数据到执行、看报告、定位失败、更新维护，整条循环完整走通。

这条循环简单来说，就是你要先跑通最小的 MVP 闭环，这个比用例数量重要一百倍。MVP 都跑不通，你写 100 条用例，就是 100 条屎山。

最后立一套规矩。

谁新增用例，谁维护失败用例，页面改版了谁同步更新，用例挂了多久内必须处理。还要分清楚，哪些失败算产品 bug，哪些算环境问题，哪些算用例自己烂了该下线。

没有这套规矩，自动化很快就会变成每天一堆红，没人看，然后没人信，最后没人提。

跑的过程中还有三个新手坑，一并说了。

坑一，所有验证都压到 UI 上。 UI 自动化是成本最高的那层。造数据、清数据、验后端状态，能用接口做的就别让 UI 去点。健康的分工就一句话，接口负责数据和业务规则，UI 负责真实用户路径，APP 管移动端关键流程。

坑二，断言太弱。 只判断页面没报错是不够的，要验业务结果。断言是自动化的灵魂，没有像样断言的用例，跑一万次也只是走过场。

坑三，只看数量不看稳定性。 一百条每天失败的用例，不如十条稳定可靠的核心回归。这句话建议刻在测试负责人的工位上。

三、2026 年了，这套玩法要打个补丁

前面这些是经典做法，放在五年前完全成立。

但现在是 2026 年，有个变量变了，而且变得很大。

利用 AI 赋能软件测试全流程。

以前的自动化，本质上是一门前置了编程课的工种。你得先学一门语言，啃语法，配环境，选框架，再把 Selenium、Appium、pytest 这一堆工具挨个摸熟。会封装，会定位元素，会处理等待，会设计断言，会排查 flaky，而且每一条用例，都得自己一行一行手写出来。一个纯手工团队直接转代码框架，周期通常会拉的很长。

现在呢。从想清楚测什么，到把脚本跑起来，再到跑挂了怎么办，从生成用例、生成脚本、造测试数据、归因失败日志、自动修复挂掉的用例，整条链都能让 AI 提效了。

但注意，门槛只是换了位置，没有消失。

生成变得容易多了，但验证还是得靠人来把关。AI 写的脚本，你不审就敢挂进 CI 吗。

所以我给这套经典做法打三个补丁。

补丁一，启动阶段大胆用 AI。 用例生成、脚本生成、数据构造，全可以交给 AI 打底。它能把「从零到跑起来」的周期从几个月压到几天。AI 就是这个时代最好的低代码台阶。

补丁二，AI 的产出必须过质检。 道理和用人一样，干活越快，越需要验收。AI 生成的用例和脚本，进流程前得至少过 1～2 层评审，维度打分加量化指标，别只靠你觉得。

补丁三，把维护这个最劝退的环节交给 AI 兜底。 页面改版导致的定位失效、失败归因、回归修复，这些最容易让自动化烂尾的体力活，现在都有成熟的 AI 方案。以前自动化死于维护，这个死因正在被治。

写到这可以收了。

公司从零推自动化，剥掉所有招式，说到底就一句话。

把高频、稳定、关键的业务流程，沉淀成团队可以长期维护的测试资产。

资产两个字是重点。是资产，就得有人管、有账本、能增值。而不是上线那天拍张合照发个喜报，从此没人认领的政绩工程。

工具会换，框架会过时，AI 会迭代。

这一条，不会变。

单纯测试分享交流，有愿意的吗

wangwangtest — Thu, 03 Sep 2026 23:55:25 +0800

单纯的分享交流。
什么性格都可以，只是一次陌生人、同行之间交流，仅此而已

我比较内向主要是倾听，好奇心比较重，反问可能会比较多

说下我的个人经历
4 年经验，坐标杭州，外包（薪资 9k），功能测试加写点自动化测试脚本。刚被开除，平时默默无闻，话少

测试相关的分享，比如你的入行初衷，经历，测试技能、能力，现状和规划，工作感悟等等，聊啥都行，愿意分享的（我比较内向主要是倾听，纯好奇，反问可能会比较多）

对象：小白和大佬都可以

时间：可能大概几分钟，或者愿意聊更久也行，一直聊都行

愿意的话，我会把聊天内容整理，发到这个论坛上，分享给大家。（写的比较差勿喷）

有意向的留下联系方式就行

定档！从对话式 AI 到实时智能，Voice Agent Builder 的年度春晚 iRTE2026 来了丨 10 月 23-24 日，北京见！

RTE — Thu, 03 Sep 2026 23:21:48 +0800

iRTE2026 实时智能大会定档

10 月 23-24 日

北京见

15+ 论坛、100+ 场深度演讲

更有丰富的 Side Event 与 RTE+AI 展区

等你来体验👇

微软 VibeVoice 新增开源流式 ASR 模型，边听边识别「谁说了什么」；fal 开源 H3 Max 实时教育系统，语音讲解同步生成教学动画丨日报

RTE — Thu, 03 Sep 2026 22:59:59 +0800

本期编辑：@ 三水、@ 鲍勃

01 有话题的技术

1、Inworld AI 发布实时 TTS 模型 Realtime TTS-2：从单句合成升级为多轮音频感知，可用自然语言控制语气

Inworld AI 发布 Realtime TTS-2，相比 Realtime TTS 1.5 主要根据当前文本生成语音，新版本开始利用此前多轮对话音频、用户情绪和说话节奏共同决定下一句话该怎么说，并把原来的固定情绪选项改成自然语言控制，让 TTS 从「把一句话念出来」进一步变成根据对话状态实时调整表达方式。

开始利用多轮音频上下文生成语音： Realtime TTS-2 不再只根据当前句子合成，而会参考此前对话音频、用户语气、节奏和情绪状态，再决定下一句话的表达方式。同一句文本可以随当前对话状态产生不同的语气和节奏。
语气控制从预设情绪改为自然语言描述： 开发者不再只能选择固定的情绪标签，而可以直接用自然语言描述「疲惫但温暖」「急促、紧张」等表达方式；同时支持笑声、叹气、呼吸等非语言声音标记。
同一音色可跨 200+ 种语言切换： 模型支持在一次生成过程中切换语言，同时保持说话人的音色身份一致；新版还加入高级音色设计，可通过文字描述创建并保存音色，并选择表现力、平衡或稳定三种生成模式。
TTS 首段音频延迟低于 100ms： Inworld 官方给出的 TTS 层首段音频延迟低于 100ms。在完整 Realtime API 中，系统还会在推理尚未结束时并行生成附和语、提前启动语音生成并流式返回部分回答，以减少 Voice Agent 的等待感。
从研究预览转为正式开放： Realtime TTS-2 现已通过 Inworld API 和 Realtime API 正式提供，Realtime TTS 1.5 用户只需要更换模型标识即可升级，无需修改其他代码。目前该模型在 Artificial Analysis 的受控音色竞技场排名第一；在使用各家原生音色的榜单中排名第二，仅次于 Cartesia Sonic 3.6。

https://inworld.ai/realtime-tts-2

2、通义千问团队、清华大学提出长音频理解基准 AudioSpan：覆盖 10 分钟至 2 小时以上音频，分层测试感知、理解与推理

通义千问团队与清华大学研究人员提出长音频理解评测基准 AudioSpan，并公开完整数据集。不同于大量音频 Benchmark 仍以数秒短片为主，AudioSpan 将音频长度扩展到 10 分钟至 2 小时以上，同时不只测试「能不能找到答案」，而是把长音频理解拆成感知、理解和推理三个层级，共构建 3,240 道问题。

同时拉长音频长度和评测深度： AudioSpan 覆盖语音、环境声音和音乐等长时音频，并按照感知、理解、推理三个认知层级设计问题，避免只是把短音频问答简单搬到更长输入上。
用两套问答机制区分「没听到」和「不会推理」：「原生问答」直接围绕音频真实内容设计问题；「锚点问答」则在音频中加入可验证的声学事件，再构建从感知到推理的连续问题链，用来定位模型究竟在哪一层失效。
当前模型的主要瓶颈首先出现在长音频感知： 论文对 12 个大型音频语言模型进行评测后发现，随着音频变长，模型更容易在大量冗余信息中遗漏关键声音，其中对事件发生时间的定位尤其困难，复杂推理反而不是唯一瓶颈。
数据集已公开： AudioSpan 已在 Hugging Face 开放，可用于评测大型音频语言模型在长时语音、环境声音和音乐理解上的能力。

https://huggingface.co/datasets/holvan/AudioSpan

3、腾讯、NUS、港理工提出基于 MiniMax-H3 改造的交互式世界模型 H3-World：把键盘操作转成语言指令，仅训练 MiniMax-H3 0.199% 参数

腾讯、新加坡国立大学和香港理工大学研究团队提出 H3-World，将 330 亿参数的 MiniMax-H3 视频生成模型改造成可通过键盘实时控制角色和镜头的交互式世界模型。它没有额外训练一套动作控制模块，而是把键盘操作转换成 MiniMax-H3 已经能够理解的自然语言，再把每条指令精确绑定到对应的视频时间段。

直接复用 MiniMax-H3 已有的语言理解能力做世界控制： H3-World 将角色移动和相机操作组合成文本指令，通过 MiniMax-H3 原有的文本输入通道送入模型，让 W/A/S/D 等键盘输入能够控制人物运动，同时控制镜头平移、转向等动作，而无需新增专门的动作编码模块。
解决「知道要怎么动，但不知道什么时候动」的问题： 普通全局文本提示只能粗略指定镜头或角色运动，难以控制动作发生的准确时间。H3-World 为不同视频潜变量区间分别绑定动作语言，并通过定向注意力机制限制每条指令的作用时间，使同一段视频里可以先向左转、再向右转等连续改变控制指令。
只用 8,000 段游戏视频完成轻量适配： 团队基于 ABot-World-Explorer-500h 中的 8,000 段游戏视频训练，仅对自注意力层加入 rank-32 LoRA，共训练 6,560 万参数，占 MiniMax-H3 约 0.199%，经过 10,000 步优化即可获得角色和镜头控制能力。
能够组合训练中没出现过的动作： 如果模型分别见过某种角色动作和某种镜头动作，即使训练数据中没有出现过两者的组合，H3-World 仍能将它们组合执行，并将控制能力迁移到训练集之外的新视觉场景。
代码与 **LoRA**** 权重已开放：** 项目已公开训练与推理代码，并在 Hugging Face 发布 Apache 2.0 许可的 LoRA 权重；运行时仍需要 MiniMax-H3 基础模型以及 H3-World 的定向注意力实现。

https://danzer1xxxxchan.github.io/H3-World/

4、微软 GitHub 万星开源语音项目 VibeVoice 新增开源流式 ASR 模型 VibeVoice-ASR-Streaming：边听边识别「谁说了什么」，支持自定义热词和 10 种语言

微软GitHub 万星开源语音项目 VibeVoice 新增 VibeVoice-ASR-Streaming，将今年 1 月 VibeVoice-ASR 已有的「谁在何时说了什么」结构化转录能力推进到实时场景。模型无需等整段音频结束，而是随着语音持续输入逐块输出带说话人归属的转录结果，并支持自定义热词和 10 种语言。VibeVoice 最早以长文本多人 TTS 模型进入开发者视野，随后陆续推出实时 TTS、长音频 ASR 和 CPU 端侧推理版本，逐步从语音合成扩展成同时覆盖 TTS 与 ASR 的开源语音模型家族。此次 Streaming 版本进一步补上实时多人语音识别能力。

「谁说了什么」从离线处理进入实时流： 此前 VibeVoice-ASR 可以单次处理最长 60 分钟音频，同时输出说话人、时间戳和转录内容；新版本则在音频仍持续输入时不断输出带说话人信息的文本，不必等录音结束后再统一处理。
支持自定义热词增强专有词识别： 开发者可以传入人名、产品名和技术术语等上下文信息，引导模型识别特定词汇，适合会议、客服及垂直领域实时转录。
首版支持 10 种语言： VibeVoice-ASR-Streaming 当前支持中文、英语、法语、德语、意大利语、日语、韩语、葡萄牙语、俄语和西班牙语；相比非流式 VibeVoice-ASR 的 50+ 种语言，新版本目前优先覆盖实时识别场景下的 10 种语言。
模型与代码已开放： 7B 模型权重已发布至 Hugging Face，GitHub 提供实时麦克风 Demo 和文件流式推理示例，可通过 WebSocket 在录音过程中持续返回转录结果。

https://huggingface.co/microsoft/VibeVoice-ASR-Streaming-7B

02 有亮点的产品

1、fal 创意工程团队负责人开源 Minimax H3 Max 实时互动教育系统：语音讲解同步生成教学动画，支持打断后立即切题

fal 创意工程团队负责人 Gökay Aydoğan 开源 Minimax H3 Max Realtime Education，把实时语音辅导与 H3 Max 视频生成串成一套可打断的教学系统。学生一边与 AI 对话，系统一边把当前科学讲解拆成具体知识点并持续生成 5 秒教学动画。 如果学生中途提问或切换话题，正在播放的视频不会中断，旧的待生成任务会被取消，新主题的视频生成完成后直接接替播放。

语音讲解直接驱动连续教学动画： 系统使用 Grok Voice Realtime 完成语音对话，再把不断到达的转录内容拆成具体科学主题，由 H3 Max 生成对应的 5 秒、16:9 教学动画。系统同时维护有限长度的视频队列，提前准备后续画面，而不是等整段回答完成后再统一生成视频。
支持学生随时打断并立即切换教学内容： 系统带有自动打断检测。学生插话后，与旧话题相关、尚未完成的视频任务会被取消，但当前画面继续播放；新主题的首段视频一旦解码完成，就直接替换旧内容，避免画面出现空白。
无需额外模型专门撰写视频提示词： Grok Voice 输出的科学讲解会被实时转录，系统过滤寒暄后提取具体知识点，再由 H3PromptCompiler 加入适龄安全规则、固定视觉风格、时长和画幅等约束，直接发送至 H3 Max 文生视频接口。
项目已开源，本地 Demo 只需 fal API Key： 项目基于 Next.js、React 和 TypeScript，实时语音与 H3 Max 视频均通过 fal 调用；开发者配置 FAL_KEY 后即可启动本地科学辅导 Demo，也可进一步接入 PostgreSQL、Redis 和独立实时网关。

https://github.com/gokayfem/h3-max-education

2、a16z speedrun 04 项目 AI Agent 通信基础设施 Dial 上线：10 秒给 AI Agent 分配真实手机号，可自主打电话、收短信验证码

a16z speedrun 04 的 Genway AI 创业团队推出 AI Agent 通信基础设施 Dial，为 AI Agent 提供可编程的真实电话号码。Agent 可以在约 10 秒内申请自己的号码，并通过同一套接口拨打和接听电话、收发短信及读取验证码，让原本需要人工接管的电话预约、身份验证和线下沟通继续由 Agent 自主完成。

AI Agent 可以自己申请并控制真实手机号： Dial 把电话号码变成 Agent 可直接调用的基础设施，不需要人工购买 SIM 卡或处理运营商接入；号码创建后即可用于拨打、接听电话和双向消息通信。
解决短信验证码导致的 Agent 工作流中断： Agent 可以直接读取收到的完整短信，包括一次性验证码，再自行决定后续操作。过去自动注册流程走到「输入手机验证码」往往需要把任务交还给人，现在可以继续自动执行。
语音通话也被封装成 Agent 工具： 开发者可以让 Agent 根据指令主动拨打真人或商家，完成预约、确认和跟进等任务，并获得实时转录；来电也可以由 Agent 根据预设指令自动处理。
同时提供 REST API、MCP、CLI 和 SDK： Dial 已可接入 Claude Code、Cursor、Codex 等 Agent 工作流，也提供 Node.js、Python SDK，以及 LangChain、CrewAI、AutoGen 等框架适配，让开发者不需要单独搭建电话基础设施。

https://www.producthunt.com/products/dial-3

3、反诈 AI 公司 Apate.AI 获 815 万美元种子轮融资：用语音、消息和邮件主动「拖住」诈骗分子，已完成 250 万次自主对话

反诈 AI 公司 Apate.AI 获得 815 万美元种子轮融资，由 Lobby Capital 领投，OIF Ventures、Investible、Concept Ventures 和 Baobab Ventures 参投。与传统依赖检测和拦截的反诈系统不同，Apate.AI 部署大规模对抗式对话 AI 智能体，主动通过语音、消息和邮件与诈骗分子交互，在拖延其时间的同时提取诈骗话术、钓鱼链接、洗钱账户和加密钱包等实时情报。

让 AI 主动进入诈骗对话，而不是只在事后识别风险： Apate.AI 的智能体会模拟真实受害者，与诈骗分子持续沟通，把传统「检测并阻断」的反诈流程推进到「主动接触、拖延并获取情报」。
单次对话最长可持续 2 小时： 平台同时运行数千个语音和文本智能体，可与诈骗分子持续进行长时间自然对话，在消耗其人力和时间成本的同时不断收集可用于追踪和阻断诈骗网络的信息。
已完成超过 250 万次自主对话： Apate.AI 表示，其系统已与威胁行为者完成 250 万次以上自主交互，从中提取超过 25 万条诈骗情报，包括冒充方式、钓鱼网址、洗钱银行卡账户和加密钱包等，并将结果接入客户的反诈处理流程。
已进入大型金融机构生产环境： 平台目前已服务包括澳大利亚联邦银行在内的头部机构。新一轮资金将用于继续扩展对话智能体平台，并加强美国和欧洲市场布局。

(@ApateAI)

4、警务 AI 公司 Blue Voice 获 600 万美元种子轮融资：用语音和随身摄像头记录自动生成案件报告

面向执法机构的 AI 公司 Blue Voice 获得 600 万美元种子轮融资，由 General Catalyst 领投。其核心产品是一套面向警员的 AI 工作助手，可以读取警员口述内容、随身摄像头视频和案件材料，自动整理成案件报告、证词摘要等文书，试图把警员大量花在案后记录和行政工作的时间交给 AI 处理。

从现场语音和视频直接生成案件报告： Blue Voice 可以处理警员口述、随身摄像头记录以及其他案件资料，提取事件经过、人员和关键信息，再按照警务文书格式生成报告草稿，减少警员返回办公室后手工整理记录的工作。
目标是做警务场景的通用 AI 工作助手： 除生成报告外，Blue Voice 还计划让 AI 帮助警员搜索法律和部门政策、查询案件信息并完成更多行政任务。创始人将产品定位类比为法律 AI 公司 Harvey，希望构建一套贯穿执法工作流的警务 AI 平台。
产品已进入真实警务机构使用： Blue Voice 已与美国多个警察部门合作，并将新资金用于扩大工程和销售团队、拓展更多执法机构客户。对于 Voice AI 而言，这类产品也展示了语音模型从实时对话进一步进入高强度现场记录与专业文书生成工作流的另一条路径。

（@Techcrunch）

03 有态度的观点

1、马斯克：AI 明年底可胜任所有数字工作

昨日，马斯克在 G20 创新部长峰会的公开发言中表示，他预计到明年底，AI 可胜任几乎所有不需要人类直接操作物理世界的数字工作。

他将届时的 AI 编程能力比作国际象棋引擎 Stockfish，认为人类将很难在软件开发上与之竞争；各类工程与其他数字任务也可能在未来 12 至 18 个月达到很高水平。

对人形机器人，马斯克的判断更谨慎一些。他说，物理世界的产品需要建立庞大供应链，无法像软件那样直接复制。他把机器人的实用性拆成三个相乘的因素：AI 软件能力、机身芯片性能，以及机电灵巧性，尤其是手部操作能力。

他同时把电力列为 AI 扩张的主要约束。按他引用的分析师共识估计，2027 年 AI 芯片可能面临至少 15GW 的供电缺口：AI 芯片产量每年增长约 40%～50%，而中国以外地区的可用电力年增速约为 10%～20%。

针对电力缺口，马斯克建议各国在承接 AI 数据中心时，同步增建发电和电网设施。

他也提到，Google、Anthropic 等公司正向 SpaceX 租用算力，SpaceX 之所以能更快投用设备，是因为自建了发电设施。

（@APPSO）

04 社区黑板报

招聘、项目分享、求助……任何你想和社区分享的信息，请联系我们投稿。（加微信 creators2022，备注「社区黑板报」）

1、📣 深圳开发者活动推荐｜Physical AI Camp 项目 WatcheRobot Workshop：把 AI Agent 接入真实机器人的开发实践

现在大多数 AI 应用仍停留在屏幕里：能对话、能生成代码，却无法感知真实环境，也不能通过硬件做出反馈。

这次 Workshop 将开放尚未上市的 WatcheRobot 及其 SDK。参与者可以使用 Codex、Claude Code、DeepSeek 等 AI 编程工具，调用机器人的摄像头、麦克风、屏幕表情、灯光和机身动作，把一个具体创意开发成可在真机上运行的功能。

现场不只是观看产品 Demo，而是实际连接设备、编写代码、运行测试并调试机器人的反馈，让它根据语音或视觉输入做出对应的表情、灯光和动作。

时间：9 月 5 日（周六）9:00–17:00

📍 地点：深圳市南山区

💻 要求：自带电脑，具备基础开发环境

🎫 名额限 10 人参加，需提前报名审核

如果你对 WatcheRobot 活动、AI 机器人开发或我们的产品方向感兴趣，报名连接：

https://mcnsslrwxv50.feishu.cn/share/base/form/shrcnbP0aKpMfCqVB1hy7QXk55b

写在最后：

我们欢迎更多的小伙伴参与 「RTE 开发者日报」 内容的共创，感兴趣的朋友请通过开发者社区或公众号留言联系，记得报暗号「共创」。

作者提示: 个人观点，仅供参考

九大测试门禁，拦住发布风险

Fhaohaizi — Thu, 03 Sep 2026 22:23:39 +0800

安全优先

数据泄露和安全漏洞会给企业带来严重影响，也说明安全不能缺位。持续集成与持续交付（CI/CD）流水线往往持有代码库和部署凭据，因此容易成为攻击目标，并可能成为恶意活动的入口。

为了自动化，敏感凭据常被保存在私有仓库中。应把 CI/CD 系统隔离在受保护的内部网络内，并遵循最小权限原则，以减少风险暴露面。

虚拟专用网络（VPN）、可靠的双因素认证以及身份与访问管理方案，都能增加一层保护。例如，可以将执行代理容器化，并把它们放在受保护的网络中。

还应在项目从开始到结束的整个过程中持续落实安全要求。把安全融入整个开发生命周期的方式通常称为 DevSecOps。

采用微服务架构

如果项目基于单体架构，重构现有应用会带来很大挑战。不过，微服务架构的价值在于：新增功能时不必重新设计整套系统结构。

也可以采用渐进式迁移：保留关键业务系统，同时逐步引入新架构，再有节奏地替换旧系统。这样能让过渡过程更加平稳、可控。

像 Bunnyshell 这样的环境即服务（EaaS）平台，可以在 Kubernetes 上自动部署包含所需微服务的全栈环境，用于 CI 测试。这类自动化有助于构建一致、可重复的测试环境，从而提升 CI 工作流的可靠性。

尽早提交、频繁提交并减少分支

CI/CD 的基本原则，是尽早把改动集成到主要的共享代码库。若多个开发者在发布前才合并大量分歧明显、彼此冲突的改动，集成成本会很高。CI/CD 系统一般只监控和测试一个或少数几个分支上的提交，这能促成持续、渐进的集成，降低集成风险，也让协作过程保持更稳定。

减少甚至消除长期分支，目标是优化开发流程并缩短处理版本控制的时间，把更多精力留给实际开发工作。

要充分发挥 GitOps 的作用，应规律地提交改动，理想情况下至少每天一次。改动既可以直接提交到主分支，也可以从本地分支合并进来。较小、可控的集成增量能避免在发布前集中合并多条分支时出现的大量返工和集成痛点。

这种做法能够简化工作流、改善协作效率，让开发周期更高效。

生产环境只能通过一种路径部署

CI/CD 能提升开发实践和代码质量，部分原因在于它用工具把测试与部署规范落实成门禁。每一项改动都必须遵循组织既定的标准和流程，才能继续通过 CI/CD 流水线。流水线失败会立刻暴露，并阻止相关版本进入后续阶段，从而保护关键环境不受未经信任代码的影响。

要获得这些收益，必须保持部署纪律，让对生产环境的每一次变更都通过 CI/CD 流水线完成。流水线应成为将代码引入生产环境的唯一机制：既可以在测试通过后自动持续部署，也可以由 CI/CD 系统对已充分测试的版本进行人工晋级和审批。这样能够形成可靠、受控的生产发布过程，提高代码质量并降低出错风险。

尽量保持生产与测试环境一致

CI/CD 流水线会推动改动依次通过不同的测试套件和部署环境。改动满足某一阶段的要求后，会自动部署或等待人工部署到限制更严格的环境。早期阶段的目标，是验证改动是否值得继续测试，并逐步推进到更接近生产的环境。

要让测试结果能反映生产行为，测试环境，尤其是后期环境，应尽可能复刻生产环境。预发布环境与生产环境差异很大时，存在问题的改动可能在测试中没有被识别，最终却进入生产。线上环境与测试环境的差异越多，测试对发布后代码表现的预测就越不可靠。因此，测试环境应尽量贴近生产环境，以保证 CI/CD 全流程中的测试有效且准确。

明确测什么、何时测、在哪里测

测试可以分为两类：轻量测试和重量测试。

以一个持续两周以上的 Sprint 为例，可以在 Sprint 结束前 3 天把开发改动合并到预发布分支。这样能留出时间测试、修复关键缺陷并为演示准备环境。预发布代码可以先进行人工测试；如果没有发现关键缺陷，再合并到发布分支。合并进入发布分支后，代码即可自动部署到生产环境。

在把功能分支合并到主开发分支之前，必须先让功能分支同步最新的开发改动。否则可能出现这样的情况：功能分支和开发分支各自的测试都通过，但合并结果却有缺陷。为了保持质量稳定，应先将功能分支合并到开发分支再测试。这个过程可以由 CI/CD 自动执行，并且只有测试通过后，合并结果才应构建并推送到仓库。这样可以保证功能分支合并后，开发分支仍然稳定。

测试套件不同部分的执行速度天然不同。CI/CD 是所有改动进入系统的关口，因此越早发现失败，越能减少在问题构建上浪费的资源。应优先执行速度最快的测试，先用小而快的测试验证构建，再进入更复杂、耗时更长的测试。

如果当前条件不支持隔离测试环境，应在提交到共享仓库前先做本地测试，避免阻塞其他成员。虽然本地开发环境通常无法运行完整的类生产测试套件，但它至少可以确认改动已通过基础测试，值得进入更大的代码库进行集成。

避免重复构建

应避免任何导致源代码被多次编译的做法。即使软件分发前还需要打包或捆绑等步骤，编译过程也应只执行一次，之后分发已编译的二进制产物。CI/CD 流水线的目的，是为改动建立信心，并降低意外影响的概率。

同样，每次迭代都应为最终产物建立版本并发布到 Git。这样在后续拉取或访问仓库时，构建结果仍能保持一致，不会偏离最初状态。

尽可能使用自动化

从手工流程迁移到自动化流程时，首先该自动化哪些任务并不总是明确。渐进式推进看起来更容易，但也可能带来取舍上的困难。因此，应先确定需要优先自动化的任务。

合理的起点是自动化代码编译，因为这能减少人为错误。开发者每天提交代码时，自动化冒烟测试也很有价值。接下来通常优先做单元测试，以减轻开发者的负担。

随后可以自动化功能测试，再自动化用户界面测试。功能测试通常比 UI 测试需要更少的脚本维护，因为 UI 更容易频繁变化。制定自动化优先级时，还应考虑测试之间的依赖关系及其对整体工作流的影响。

使用按需测试环境

可以考虑在容器中运行测试，以减少开发与生产环境之间的变量和差异。这样既能提高 CI/CD 周期效率，也能让测试过程更具敏捷性。

基于容器的临时测试环境能给 QA 团队带来明显收益。与其从 CI 服务器拉取构建后再安装到单独测试环境中，不如直接针对隔离的应用环境执行测试，避免影响其他正在进行的测试。这种方式可以节省时间，并减少出错机会。

创建容器通常不需要单独安装或配置，建立测试环境更方便。容器在不再需要时也可以轻松销毁，清理工作因此更简单。

基于容器的测试能够简化测试工作流，提升环境一致性，并改善整体开发与测试效率。

像 Bunnyshell 这样的环境即服务平台，可以在 Pull Request 触发时，在 Kubernetes 上创建并部署基于容器的隔离测试环境。这样就能在受控、可复现的环境中自动测试改动，提升开发流程的效率和可靠性。

如果希望进一步了解临时测试环境的价值，可以阅读 Bunnyshell 的相关文档，或注册其免费账户。

Meta 发力语音模型，Muse Voice Transcribe 突破 20+ 人分离与中英混说；Datapoint 开源 31.5 万次客服场景盲评 TTS 偏好数据丨日报

RTE — Thu, 03 Sep 2026 22:12:23 +0800

本期编辑：@ 三水、@ 鲍勃

01 有话题的技术

1、Meta 发布实时音频感知模型 Muse Voice Transcribe：单模型完成流式 ASR、20+ 人说话人分离与端点检测

Meta Superintelligence Labs 发布首个实时音频感知模型 Muse Voice Transcribe，把流式 ASR、20+ 人说话人分离和端点检测原生整合进同一个模型。过去实时语音系统往往需要分别完成转写、判断「谁在说话」和检测「用户是否说完」，Muse Voice Transcribe 则让这些信号在同一条实时输出流中产生。

单模型同时输出转写、说话人和轮次边界： Muse Voice Transcribe 以流式 ASR 为基础，通过额外的特殊 Token 标记说话人切换、说话开始和说话结束，可原生处理 20+ 名说话人，无需再做额外后处理。
按词动态决定「还要听多久」： 音频以 80ms 为一个 Chunk 输入，模型不会采用固定等待时间，而是通过 Adaptive Delay（自适应延迟） 判断每个词需要多少音频上下文；简单词更快输出，困难词则多等待上下文，在准确率与最终转写延迟之间动态取舍。
支持中英混说和上下文偏置： 模型训练覆盖 70+ 种语言，首发重点验证 25 种，并支持句内语言切换；开发者还可以通过语言、关键词和上下文偏置，提高人名、地点及领域术语等特定词汇的识别准确率。
已开放 Meta Model API： Muse Voice Transcribe 已可通过 Meta Model API 调用，同时用于 Meta AI for Mac 的听写和 Muse Code 的语音输入。截至 9 月 1 日，该模型位列 Artificial Analysis 流式 Speech-to-Text 排行第一，并在公开说话人分离 Benchmark 中排名第一。

https://research.meta.ai/blog/introducing-muse-voice-transcribe

2、李飞飞联合创办的 World Labs 发布多模态世界模型 Atlas：支持像素级相机控制，并统一图像、视频生成与 3D 重建

李飞飞联合创办的 World Labs 发布多模态世界模型 Atlas。该模型从零开始预训练，可原生处理文本、图像、视频和 3D 信息，并在同一模型中完成受控图像/视频生成、3D 重建与时空模拟；其中最突出的变化，是把精确相机几何参数直接作为模型输入，让开发者能够按指定机位、角度和运动轨迹生成画面，而不再只靠文本描述镜头运动。

相机控制从文本指令升级为几何级输入： Atlas 可以根据 1 张或多张参考图，从指定相机位置和角度生成新视角，并沿人工设计的相机轨迹生成视频。官方展示中，Atlas 可生成最长 1 分钟、1440p 的连续视频。
一个模型同时负责生成与 3D 重建： Atlas 不仅生成二维图像和视频，还能从 1 张到多张图像重建场景几何，并输出点云和 3D 高斯泼溅结果。对于未被相机拍摄到的区域，模型会结合已有空间上下文补全场景。
采用多模态自回归扩散 Transformer 架构： 文本、图像、相机位置和 3D 深度图会被组织进统一的空间上下文，模型再根据已有内容逐步生成后续结果。视频在模型内部被表示为连续图像序列，使图像生成、视频生成和 3D 空间建模能够共享同一套架构。
从空间生成进一步延伸到时空模拟： Atlas 可从少量相机拍摄的视频重建场景，再从新的视角重新生成画面；在机器人场景中，还可以基于真实环境构建模拟空间，并生成机器人沿不同路径运动时对应的 RGB 图像和深度数据，用于真实环境到模拟环境的训练流程。
目前处于早期开放阶段： World Labs 正向部分合作伙伴开放 Atlas，后续 Atlas 也将用于驱动 Marble 等 World Labs 产品。

https://www.worldlabs.ai/blog/atlas

3、Visko 发布实时世界生成模型 Orbis 1.0：首个实时模型上线，可在生成过程中即时改写内容

Visko 正式发布 Orbis 1.0，这是其首个实时模型。相比传统「提交提示词、等待成片」的视频生成方式，Orbis 1.0 把生成过程变成一条可持续输出的实时流：用户可以一边生成、一边改写后续内容，系统则持续把世界渲染出来，并通过 Reactor 提供 API 访问。

把视频生成从一次性出片改成实时流式生成： Visko 将 Orbis 定位为一个「创建真实世界并实时呈现出来」的基础模型。官网也将其描述为可「创建鲜活世界并实时流式输出」的模型，核心变化是从离线生成短片，转向持续运行的实时生成系统。
支持生成过程中实时交互： Orbis 1.0 支持用户在生成过程中随时修改后续剧情，新的指令会实时反映到后续画面中。官网展示的交互方式包括直接续写故事、语音输入驱动画面，以及基于文本或参考图生成世界。
持久记忆支撑长时一致性： Orbis 1.0 通过有界多尺度记忆，在分块生成过程中持续保留角色、场景和风格信息，用来支撑长时间连续生成，减少长视频里常见的内容漂移和风格漂移问题。
支持文本生成、图像生成和视频续写三类工作流： Orbis 1.0 支持长时文本生成视频、图像生成视频，以及视频续写；并支持多语言提示词和生成过程中切换提示词，这意味着它不只是「实时播放视频」，而是一个可持续操控的生成工作流。
已通过 Reactor 提供 API，并区分动态版与稳定版： Orbis 1.0 现在可通过 Reactor 访问，其中 Orbis-Dynamic 被标注为「可实时切换的视频生成」，Orbis-Stable 被标注为「可操控的视频生成」。这说明 Visko 不只是发布演示页面，而是已经把模型接入开发平台，供开发者测试与调用。

Orbis :

https://visko.ai/models#orbis

动态版本：

http://reactor.inc/sandbox?model=visko-orbis-dynamic

稳定版本：

http://reactor.inc/sandbox?model=visko-orbis-stable

4、Datapoint AI 开源客服场景 TTS 人类偏好数据集：31.5 万次真人盲评覆盖 15 款模型

Datapoint AI 发布 Text-to-Speech Human Preferences 315K，将其 TTS Bench 背后的 31.5 万次真人偏好投票开放出来。数据覆盖 15 款 TTS 模型、300 条英文客服提示词和 8 类 Voice Agent 场景，开发者不仅可以查看模型排名，还能直接用这批人类偏好数据训练或评测语音奖励模型。

31.5 万条数据实际是两两语音比较的真人投票： 15 款 TTS 模型组成 105 种模型配对，每组配对都会在全部 300 条提示词上比较，每个比较单元保留 10 次有效真人选择，最终形成 31,500 个比较单元、315,000 次有效偏好投票。评测时用户看不到模型名称，只需在两段语音中选择更喜欢的一段。
专门针对客服 Voice Agent，而不是通用朗读： 300 条提示词覆盖 8 类实际客服任务，包括共情与情绪安抚、问候与品牌表达、操作指导与故障排查、人名与拼写、政策说明、口误与表达修正、预约与升级处理、交易信息播报，可以分别观察不同 TTS 模型在具体客服任务中的人类偏好差异。
除投票外还开放 4,500 条模型生成音频： 数据集包含 15 款模型针对 300 条提示词生成的 4,500 条 FLAC 音频，同时提供模型配对结果、单次真人投票、提示词和模型信息，可用于训练语音偏好模型、奖励模型，以及复现 Datapoint 的 TTS 排名。
排行榜由同一批真人偏好数据生成： Datapoint 使用 31.5 万次有效投票拟合 Bradley–Terry 偏好模型，再转换为 Elo 分数，并提供总榜和 8 个客服类别的独立排名。整体榜单对各类别等权计算，而不是简单按所有投票混合排序。

https://trydatapoint.com/benchmark/leaderboard

02 有亮点的产品

1、Bodhan AI × AI4Bharat 公布多语言语音合成模型 Indic-Speak：40 亿参数支持 23 种语言，可单次生成双人播客

Bodhan AI 与 AI4Bharat 公布 Indic-Speak，一款面向印度多语言场景的 40 亿参数语音合成模型，支持 23 种语言。相比此前发布的语音识别 Indic-Transcribe、翻译模型 Indic-Translate 等能力，Indic-Speak 补上了「语音生成」环节，并重点处理多人对话、语言混说和长文本连续朗读。

双人对话可一次生成，不需要后期拼接： 官方演示两位虚拟说话人 Parth 和 Dhara 用印地语讨论论文《Attention Is All You Need》，整段播客式对话由模型一次生成，通过说话人标签控制双方轮流发言，而不是分别生成两条语音后再拼接。
支持真实对话中的多语言混说： Indic-Speak 可以直接合成一句话中混合多种语言的内容，例如印度语言与英语交替出现，无需先把文本统一翻译成单一语言再生成语音。
针对印度本地表达做了专门处理： 模型能够正确处理 PAN、Aadhaar、货币金额等本地常见表达，减少缩写、数字和专有名词在语音生成中的读错问题。
支持长文本连续语音生成： 官方还展示了完整泰米尔语有声书章节的连续朗读，重点验证模型在长时生成中保持内容连贯和稳定的能力，而不只针对短句 TTS。

Indic-Speak 将于 2026年9月5日在 Bodhan AI 上线。

(@MiteshKhapra@X)

2、语音 AI 公司 Smallest.ai 完成 1300 万美元 A 轮融资：押注实时语音到语音系统，累计融资超 2100 万美元

语音 AI 公司 Smallest.ai 完成 1300 万美元 A 轮融资，由 Seligman Ventures 领投，Sierra Ventures、3one4 Capital 等参投，累计融资已超过 2100 万美元。新资金将重点投入下一代实时语音到语音系统、底层实时基础设施和企业部署，目标是进一步摆脱传统 ASR、LLM、TTS 串联架构带来的延迟。

下一阶段重点转向实时语音到语音架构： Smallest.ai 认为，传统级联系统需要依次完成听写、推理和语音生成，而自然对话中的「听、想、说」实际上会同时进行。公司正在开发能够在语音到达时同步处理信息的架构，以降低对话响应延迟。
复杂任务仍可交给大型基础模型处理： Smallest.ai 的设想并非完全抛弃 LLM，而是让小型实时语音模型负责低延迟对话，遇到超出自身知识范围的复杂问题时，再调用大型基础模型处理，形成实时交互与复杂推理分工的双模型架构。
资金还将用于扩大企业级部署： Smallest.ai 创始人 Sudarshan Kamath 表示其技术目前已在 10 多家企业中支撑超过 10 亿分钟实时语音 AI 使用量，新资金将继续投入模型、实时基础设施以及金融、客服等企业场景。
「通过语音 AI 图灵测试」目前是公司自身表述： Kamath 在融资公告中称其系统已经「通过语音 AI 图灵测试」，但目前未同步公开具体测试协议、参与人数或独立评测结果。值得注意的是，Smallest.ai 此前研究文章也指出，行业仍缺少针对实时语音交互的严格图灵测试标准，需要同时评价响应时机、打断、情绪和轮次互动等维度。

https://smallest.ai/blog/series-a-funding-13m-next-generation-voice-ai

3、Violoop 完成数亿元天使轮及 Pre-A 轮融资：联想创投、蓝驰创投等参投，加速桌面 AI 硬件量产

桌面 AI 硬件公司 Violoop 完成数亿元天使轮及 Pre-A 轮融资，由联想创投、中金保时捷、蓝驰创投、元生资本、启赋资本和 Zero2IPO Ventures 共同投资。其首款产品是一台外接电脑使用的 AI 设备，通过 HDMI 读取屏幕、USB 模拟键鼠操作，让现有 Windows、macOS 和 Linux 电脑无需更换系统即可获得跨应用的智能体操作能力。

核心路线是「外挂硬件」改造现有电脑： Violoop 不要求应用逐一接入 API 或插件，而是直接读取电脑屏幕，并通过 USB 键鼠控制完成跨应用任务；设备可根据当前屏幕内容提供下一步建议，也支持持续执行多步骤任务。
部分感知和推理直接放在端侧： 设备搭载 RK3576 芯片和 26 TOPS AI 加速器，可在本地运行 Qwen 8B Q4 模型；原始屏幕画面可在设备侧处理，再按任务需要调用用户自己的 Claude、OpenAI 或 Gemini API。
联想将从投资进一步延伸到产业协同： 除成为股东外，联想还计划在生产制造、供应链、全球渠道和品牌资源上支持 Violoop 产品规模化，并与其探索智能体运行框架、端侧个人模型和自进化闭环等方向。
产品即将进入正式销售阶段： Violoop 此前已获得约 1.2 万名用户的订金预订，首款产品建议零售价为 699 美元，Kickstarter 及国内首发价为 399 美元，计划于 9 月正式上线。

https://news.qq.com/rain/a/20260901A03PK400

https://violoop.ai/

（@ 新京报）

03 有态度的观点

1、宇树科技回应「超 100 元报销需王兴兴审批」：很多内容不实

据澎湃新闻报道，9 月 1 日，「宇树员工称超 100 元报销需王兴兴审批」「宇树员工称奖惩机制只有罚几乎没有奖」等话题登上热搜。

宇树科技对此回应称：「很多内容不实，切勿当真。」不过，官方未进一步说明具体哪些内容不实。

此前报道称，有员工表示，在宇树科技，一笔超过 100 元的报销需要公司创始人王兴兴审批，员工也经常在其办公室外排队等待审批。相关报道还提到，王兴兴的沟通方式相对直接严厉，要求员工不对外透露公司消息，并高度关注产品细节和成本控制。

此外，宇树科技于 8 月 27 日宣布，将每年无偿赞助部分「天才少年」开展科技项目，申请对象为高中阶段至硕士研究生毕业前的学生，资助金额为 1 万至 2 万元，特别优秀的项目不设金额上限。

( @APPSO)

04 社区黑板报

招聘、项目分享、求助……任何你想和社区分享的信息，请联系我们投稿。（加微信 creators2022，备注「社区黑板报」）

1、📣 社区活动推荐｜Google DevFest 2026 Shanghai 超前报名开启：Beyond the Model，Build for Real

今年 11 月初，Google DevFest 2026 Shanghai 将在上海举办，预计汇聚 3000 名开发者，设置 5 个分会场、17 个 Topic 和 3 场 CodeLab。

今年的主题是 「Beyond the Model. Build for Real.｜超越模型，为真实而构建」。相比只讨论模型能力，这届 DevFest 更想把问题往真实工程里推一步：API 挂了怎么兜底？模型幻觉怎么做 Guardrails？成本失控后 Infra 怎么优化？Agent、Cloud、Android、Web 又该怎么真正进入生产环境？

对正在做 AI / Agent / Cloud / Android / Web 的开发者来说，这次会更偏向真实项目、工程实践与技术落地，而不是只聊趋势和概念。

⏰ 时间： 2026 年 11 月初

📍 地点： 上海

🎯 主题： Beyond the Model. Build for Real.

目前已经开启超前报名，想提前锁定席位的朋友可以关注一波～

超前报名｜Google Devfest 2026 Shanghai

写在最后：

我们欢迎更多的小伙伴参与 「RTE 开发者日报」 内容的共创，感兴趣的朋友请通过开发者社区或公众号留言联系，记得报暗号「共创」。

作者提示: 个人观点，仅供参考

阿里开源：skill-up，一款 Agent Skill 评测工具！

mikezhou — Thu, 03 Sep 2026 09:22:35 +0800

2026 年走到现在，Agent Skill 已经成了 AI 领域的标配。

把个人经验沉淀成 SKILL.md，把团队最佳实践封装成可复用的技能包，这些都已经是很常规的操作了。最近在社区上看到有篇文章问了一个特别扎心的问题。

「一个 Skill 的『好坏』，到底由谁定义？评判它的标准又是什么？」

这个问题我是真的感同身受。

我自己陆陆续续沉淀了上百个自研的 Agent Skill，光 AI 测试领域的 skill，都沉淀了好几十个，从需求拆解、用例生成，到接口解析、脚本生成、失败诊断、报告产出，流水线编排，串起了接口和 UI 自动化的完整流程。

但每次迭代更新一个 Skill，我心里都在打鼓。

改了几行提示词，行为有没有变？跑一遍 demo 没报错，就敢发出去吗？下个版本还会好吗？

在测试领域，有一项铁规，绝不会允许一个没有用例、没有回归、没有质量门禁的系统直接上线。但到了 Skill 这件事上，几乎所有人都在裸奔。写完跑两下，感觉没问题，发布。

原因也不复杂。Skill 的本质是提示词工程，SKILL.md 改一个字，行为就可能漂移。而官方的评测指南（agentskills.io 上的 evaluating-skills）虽然描述了正确的循环，写真实用例、带着和不带 Skill 各跑一遍、给输出评分、汇总结果、迭代改进，但整套流程全靠手工，没有工具化，坚持不了几轮。

直到我看到了阿里开源的这个项目。

skill-up，一款 Agent Skill 评测工具

skill-up，阿里开源，用一句话来概括就是：The evaluation and evolution tool for Agent Skills，一款 Agent Skill 的评测工具。Go 语言写的，开源两个月，更新的很活跃。

它干的事，用测试人的话说，就是把软件测试那套方法论，完整地平移到了 Skill 上。

你可以用它验证 Skill 在真实 Agent Engine（如 Claude Code、Codex、Qoder CLI）中的功能正确性，把失败转化为有针对性的修复，并在本地或 CI 中持续回归。

先看它给一个 Skill 项目规定的标准结构。

my-skill/
  SKILL.md                        # Skill 定义文档，被测对象
  evals/
    eval.yaml                     # 评测入口配置（必须）
    cases/                        # 用例目录
      basic-success.yaml          # 每个文件是一个用例
      edge-case-null.yaml
      regression-001.yaml
    fixtures/                     # 测试资源（可选）
      repos/                      # 仓库模板
        sample-project/
      diffs/                      # 补丁文件
        null-check.patch
      scripts/                    # 评估脚本
        check-output.sh
      mcp/                        # MCP 工具配置
        github.json

眼熟吗？这就是一个标准的测试工程目录。

cases/ 是你的测试用例集，fixtures/ 是你的测试数据和脚手架，

eval.yaml 是评测的全局配置，定义了「在什么环境中、用什么 Engine、怎么评估」。

比如：

schema_version: v1alpha1

environment:
  type: none

engine:
  name: claude_code
  model:
    provider: anthropic
    name: claude-sonnet-4-8

cases:
  files:
    - evals/cases/my-test.yaml

工作原理

skill-up 将 Agent Skill 的评测与演进合为一个闭环：通过声明式 YAML 评测、隔离的多引擎运行、灵活的 Judge 和结构化报告，让质量可度量；再由 skill-upper 把失败转化为改进，自动修复或补充 eval 用例，并与你持续重跑和迭代。

同一套流程既可在本地运行，也可接入 CI；同时兼容 Anthropic evals.json 导入，并输出 JSON、JUnit 和 HTML 报告。

三种「断言」，对应测试的三种校验方式

评测一个 Skill 的输出对不对，skill-up 支持三种 judge（判定器）。

判定方式	说明	测试人对应的概念
rule_based	规则匹配，文件是否存在、内容是否包含关键字	精确断言
script	跑自定义脚本，校验产物结构、跑语法检查	脚本校验
agent_judge	用另一个模型当裁判，按标准给输出打分	LLM-as-a-Judge

注意第三个。agent_judge 就是我们在大模型评测里反复讲的 LLM-as-a-Judge，用模型评模型的输出，这在 Agent 评测体系里已经是标配手段了，现在直接内置到了 Skill 测试工具里。

在 cases 中，每个 .yaml 文件定义一个评测用例，包含「发什么 prompt」和「怎么验证结果」。

单轮对话

大多数场景使用单轮 prompt 即可：

id: find-null-bug
title: 应该识别出空指针 bug
description: 验证 Skill 能在代码审查中发现 null 解引用问题

input:
  prompt: |
    Review the current diff and report findings.

context:
  repo_fixture: evals/fixtures/repos/null-check-bug    # 加载仓库模板
  git:
    init: true
    checkout: main
    apply_diff: evals/fixtures/diffs/null-check.patch   # 应用补丁

constraints:
  timeout_seconds: 180
  max_turns: 8

expect:                           # 基本门槛检查
  must_contain:
    - "null"
    - "bug"
  must_not_contain:
    - "LGTM"
  exit_code: 0

judge:                            # 质量评估
  type: rule_based
  success:
    - output_contains:
        all: ["null", "bug"]
    - exit_code: 0

多轮对话

当评测需要多次顺序交互时（例如迭代优化、阶段门控工作流、澄清循环），使用 input.turns 代替 input.prompt。

input:
  turns:
    - role: user
      content: "用 Go 实现一个二分查找函数。"
      post_condition:
        must_contain_all: ["func", "binary"]
        on_fail: fail
    - role: user
      content: "为刚才写的函数添加单元测试。"
      post_condition:
        must_contain_any: ["Test", "t.Run", "testing"]
        on_fail: fail

把 skill-up 的概念翻译成测试行话

看完文档我列了张翻译表，你会发现这门工具几乎没有学习成本。

skill-up 里的概念	软件测试里的概念
eval case	测试用例
fixtures	测试夹具 / 测试数据
judge	断言体系
--baseline	基线对比
regression case	回归用例
--iteration 多轮运行	多轮次测试
JUnit XML / HTML 报告	测试报告
CI 支持	持续集成

这不是巧合。Skill 评测面对的问题，非确定性输出怎么断言、怎么防止改动引入退化、怎么让质量评估可重复，就是我们在大模型测试里趟过的路。skill-up 只是把这些答案工程化成了 CLI。

所以我想说一句可能有点武断的判断。

Agent Skill 的质量保障，天生就该是测试人的主场。

写 Skill 的人很多是开发和算法背景，他们擅长把功能做出来。但「怎么证明它是对的、怎么保证它下次还对」，这是测试工程师吃了几十年饭的本事。

快速上手

方式一，装 skill-upper（推荐）

skill-up 仓库里自带了一个叫 skill-upper 的 Agent Skill，装完之后你用自然语言对话就能驱动整个评测流程。

# Claude Code 全局安装
npx skills add https://github.com/alibaba/skill-up/tree/main/skills/skill-upper -g -a claude-code -y

# Codex 全局安装
npx skills add https://github.com/alibaba/skill-up/tree/main/skills/skill-upper -g -a codex -y

安装这个 Skill 前不需要先安装 skill-up。skill-upper 在运行时会检查 skill-up 命令是否可用；如果缺失，它会引导 Agent 完成安装。

装好后在 Claude Code 里打开你的 Skill 项目，直接说。

Use skill-upper to evaluate this Skill.
Read SKILL.md, identify its most important behaviors, create realistic eval
cases with appropriate judges, validate the configuration, and run skill-up.

它会自己读你的 SKILL.md、识别核心行为、生成评测用例、跑完评测、给你一份失败分析。

方式二，命令行直接装

curl -fsSL https://raw.githubusercontent.com/alibaba/skill-up/main/install.sh | bash

常用的几个命令。

skill-up run                          # 跑全部用例
skill-up run --engine codex           # 指定引擎和模型
skill-up run --baseline               # 开基线对比
skill-up run --parallelism 4          # 控制并行数
skill-up run --auto                   # 自动识别 Anthropic 的 evals.json
skill-up report --format html         # 生成 HTML 报告

报告产物很齐全，grading.json、benchmark 对比、JUnit XML、HTML，直接可以挂进 CI 当质量门禁。

用 Skill 测 Skill

整个项目里我觉得最妙的是 skill-upper 这个套娃结构。

skill-upper 本身就是一个 Agent Skill，它的职责是给别的 Skill 做测试。

完整的循环是这样的。

对话生成评测用例
  ↓
skill-up 运行评测，产出结构化报告
  ↓
skill-upper 逐条读失败用例
  ↓
判断是 Skill 错了还是用例错了
  ├─ Skill 错 → 修 SKILL.md 和配套文件
  └─ 用例错 → 修 eval case 和判定器
  ↓
把修好的 bug 沉淀成回归用例
  ↓
再跑，再迭代，直到重要行为全部通过

官方管这个叫 Eval-to-Evolution Loop，评测到进化的循环。翻译过来就是测试左移加上持续回归的 Agent 版本。报告变成修复，修复变成回归用例，每一轮迭代都让 Skill 和它的评测集一起变强。

这个思路跟我在《AI 测试实战系列》里反复强调的「bad case 回流」完全是一回事，只不过它把整个循环自动化了。

创建并运行第一组评测

在 AI Agent 中打开目标 Skill 项目。目标项目至少应包含：

my-skill/
  SKILL.md

然后直接给 Agent 一个明确任务：

使用 skill-upper 给这个 Skill 添加评测。
添加这个评测用例：
- 输入：写一个 hello world 的程序。
- 评测：是否包含 hello 和 world 打印。

然后运行 skill-up 完成校验和评测。

Agent 应该会生成类似结构：

my-skill/
  SKILL.md
  evals/
    eval.yaml
    cases/
      basic.yaml
my-skill-workspace/
  iteration-1/
    result.json

当 evals/eval.yaml 位于包含 SKILL.md 的目录下时，skill-up 会在运行时自动安装这个本地 Skill，通常不需要在 eval.yaml 里手动写 Skill 路径。

诊断、修复并持续迭代

首次运行后，不必手工逐条解读报告，可以继续与 Agent 对话：

使用 skill-upper 检查最近一次 skill-up 的评测结果。
逐项诊断失败，修复 SKILL.md 或配套文件；如果评测覆盖不足，
补充或改进 eval 用例，然后重新运行 skill-up。
持续迭代直到评测通过，或说明仍然受阻的原因。

skill-upper 会根据 skill-up 的结构化结果驱动下一次修改。每轮迭代都会让 Skill 实现和 eval 评测集保持同步，使修复沉淀为回归保障，而不是一次性补丁。

我的几条建议

最后讲讲我对这事的判断，给三类同学三个具体的动作。

1、有自己的 Skill 的，立刻建评测集

如果你像我一样囤了一堆自研 Skill，别再靠「跑一遍 demo 没报错」的玄学发布。给核心 Skill 配上 10-20 条真实场景的 eval case，接进 CI，每次改动自动回归。

2、团队里有 Skill 资产的，把质量门禁立起来

很多团队现在把内部规范、运维流程都封装成 Skill 分发。这些 Skill 一旦出错，影响的是整个团队的效率。谁来做质量把关？这事不该由写 Skill 的人自己说了算，既当运动员又当裁判，是测试里的大忌。测试同学主动把 Skill 评测体系搭起来，这就是新阵地。

3、还没写 Skill 的，评测思路照样值钱

就算你不写 Skill，skill-up 的整套评测设计，从用例怎么设计、非确定性输出怎么判定，到多引擎怎么对比、报告怎么结构化，就是一份现成的 Agent 评测方法论参考。做 AI 测试的同学把它拆开看一遍，比读十篇概念文章有用。

写在最后

我一直有个观点，AI 时代测试岗的价值不会消失，只会换地方。

以前我们测函数、测接口、测页面，现在多了测模型、测 Agent、测 Skill。被测对象一直在变，「怎么证明它是对的」这个问题永远在。

工具在变，方法论是通的。你在软件测试里攒下的每一分功力，在 Agent Skill 这个新战场上都作数。

skill-up 的地址放这了。

👉 GitHub，https://github.com/alibaba/skill-up

👉 用户手册（中文），https://alibaba.github.io/skill-up/zh/

觉得有用帮忙点个 Star，也欢迎转给团队里管 Skill 资产的同学。

我是狂师，公众号长期分享 AI 测试提效实战。最近我做了一个重大决定，将 AI 测试开发学习路线开源了：https://github.com/zhoujinjian/ai-testing-guide

并且与开源项目同步配套上线了一款免费在线学习网站👉：https://ai.testfather.cn/

放心食用，觉得有用，就帮忙点个 Star 吧 ⭐

Espresso 自动化全解：同进程注入、UI 线程自动同步、IdlingResource 与 Android 选型指南

Santo — Wed, 02 Sep 2026 22:39:51 +0800

在 Android 自动化测试领域，框架选择长期是"三国演义"：Appium 跨平台但链路长、速度慢、flaky 测试多；UiAutomator 是系统级黑盒利器，但操作延迟高、API 笨重；而 Espresso 走了第三条路——Google 官方白盒框架，测试代码直接跑在应用进程内部，与 UI 线程自动同步，不需要一行 Thread.sleep()。

目前 Espresso 稳定版 3.7.0（2025 年 7 月发布），仍在 AndroidX Test 中持续维护，Jetpack Compose 测试也已深度整合。多个第三方基准测试中，Espresso 是 Android 上执行速度最快、随机失败率最低的 UI 测试框架，同场景比 Appium 快 3-5 倍。

今天从零拆解 Espresso 的同进程架构、自动同步机制、三大核心 API、IdlingResource 异步等待、完整实战场景、优劣势与选型建议，帮你彻底吃透这款"Android 开发者的官方答案"。

01 Espresso 完整工作原理（结合架构图）

Espresso 最核心的设计决策是：测试代码和被测应用运行在同一个进程里。

Appium 的链路是 测试脚本 → HTTP → Appium Server → UiAutomator2 → AccessibilityService → 应用，每一步都是跨进程通信（IPC），元素查找要序列化、动作注入要排队、结果返回要等待。

Espresso 借助 Android 的 Instrumentation 机制：测试 APK 通过 AndroidJUnitRunner 启动后，Instrumentation 在应用进程初始化阶段就介入，测试代码被加载进应用进程运行，跑在一条独立的 instrumentation 线程上，可以直接访问应用的 Activity、View 层级、资源甚至私有方法。

整体架构

图：Espresso 从测试代码到结果返回的完整链路——同进程注入、自动同步闸门、IdlingResource 异步计数。图中编号 ①~⑧ 即下文「一次完整登录点击」的时序；底部灰条为 Appium 跨进程对照链路。

三个关键机制

1. 同进程运行（In-Process Execution）

测试代码和应用代码共享同一个进程内存空间：

查找元素不是跨进程"问"系统，而是直接遍历 View 树
点击不是发协议指令，而是通过 UiController 向窗口注入真实的 MotionEvent 触摸事件序列，和手指点击走完全相同的事件分发流程
可以直接调用应用内方法、访问 ViewModel/Room 数据库做数据准备和断言
没有网络协议开销，没有对象序列化，单次操作延迟在毫秒级

2. 自动同步（Automatic Synchronization）——Espresso 的灵魂

这是 Espresso 与所有黑盒框架最大的差异。在执行每一个操作之前，Espresso 都会先调用 loopMainThreadUntilIdle() 等待应用"忙完"，判定空闲的三个条件：

UI 线程 MessageQueue 已空：没有待处理的消息（动画、布局、重绘都算消息）
默认 AsyncTask 线程池空闲：后台任务执行完毕
所有已注册的 IdlingResource 处于 IDLE 状态：你自己声明的异步操作（网络请求、数据库、第三方 SDK 回调）全部完成

三个条件同时满足，才执行下一步。这就是为什么 Espresso 测试里不需要 Thread.sleep()——框架替你等，而且等的是"真正完成"的时刻，不是拍脑袋的固定秒数。

3. 声明式 API（ViewMatcher / ViewAction / ViewAssertion）

Espresso 的测试代码是一句话三段式：

onView(withId(R.id.btn_login))   // 找：ViewMatcher 定位元素
    .perform(click())             // 做：ViewAction 执行动作
    .check(matches(isDisplayed()))// 验：ViewAssertion 断言结果

匹配器基于 Hamcrest 库，可以 allOf() / anyOf() / not() 自由组合，语义清晰、可读性强。

以一次完整登录点击为例，全过程发生了什么

onView(withId(R.id.btn_login)).perform(click())

onView(withId(...)) 不立即查找，只是创建一个 ViewInteraction 对象
perform(click()) 触发同步：Espresso 先让 instrumentation 线程挂起，轮询等待 UI 线程 MessageQueue 清空、AsyncTask 空闲、IdlingResource 全部 IDLE
空闲后遍历 View 树：在当前窗口的 root view 下递归查找满足 matcher 的 View
- 找不到 → 抛 NoMatchingViewException（异常信息里会直接把当前 View 层级树打印给你）
- 找到多个 → 抛 AmbiguousViewMatcherException
执行点击：GeneralClickAction 计算目标 View 的中心点坐标，通过 UiController 向窗口注入 ACTION_DOWN → ACTION_MOVE → ACTION_UP 真实 MotionEvent 序列
应用响应：事件走 Android 标准事件分发（dispatchTouchEvent → onTouch → performClick），你的 OnClickListener 触发，发起登录网络请求
Espresso 知道它在忙：网络请求前 IdlingResource 计数 +1，Espresso 下一个操作前会一直等到计数归零
数据返回、UI 更新：IdlingResource 计数 -1，页面跳转完成，UI 线程消息队列清空
下一行 check() 执行断言：同样先同步，再验证

整条链路没有任何硬等待，但每一步都"恰好等到正确时机"。

02 三大核心组件与常用 API

ViewMatchers —— 怎么找到元素

Matcher	作用
`withId(R.id.xxx)`	按资源 ID 定位（首选，最稳定）
`withText("登录")`	按显示文本定位
`withHint("请输入手机号")`	按输入框 hint 定位
`withContentDescription("返回")`	按无障碍描述定位
`isDisplayed()` / `isEnabled()` / `isClickable()`	按状态匹配
`allOf(withId(...), withText(...))`	多条件与组合
`anyOf(...)` / `not(...)`	或 / 非组合
`hasDescendant(withText(...))`	匹配"包含某子元素"的父容器
`isRoot()` / `withParent(...)`	层级关系匹配

定位原则：ID 优先，文本兜底，少用层级。ID 最稳定，文本会随国际化/改版变化，层级路径一重构就碎。

ViewActions —— 对元素做什么

Action	作用
`click()`	点击（注入真实触摸事件）
`longClick()`	长按
`doubleClick()`	双击
`typeText("hello")`	输入文本
`replaceText("hello")`	替换文本（比 typeText 快，不触发逐字动画）
`clearText()`	清空输入框
`closeSoftKeyboard()`	收起软键盘（输入后必加，否则可能遮挡下一个元素）
`pressBack()`	按系统返回键
`scrollTo()`	滚动到目标（仅 ScrollView）
`swipeUp() / swipeDown() / swipeLeft() / swipeRight()`	滑动手势
`openLinkWithText(...)`	点击 TextView 中的链接

RecyclerView/ListView 这类滚动列表不能直接用 onView()（屏幕外的 item 没有 View 实例），需要用 espresso-contrib 包：

// 滚动到包含指定文本的 item 并点击
onView(withId(R.id.rv_products))
    .perform(
        RecyclerViewActions.actionOnItem<RecyclerView.ViewHolder>(
            hasDescendant(withText("机械键盘")),
            click()
        )
    )

ViewAssertions —— 怎么验证

onView(withId(R.id.tv_welcome)).check(matches(withText("欢迎回来")))
onView(withId(R.id.btn_submit)).check(matches(not(isEnabled())))
onView(withId(R.id.progress_bar)).check(matches(not(isDisplayed())))
onView(withText("错误提示")).check(doesNotExist())   // 断言元素不存在

扩展包速览

依赖	能力
`espresso-core`	核心 API（必选）
`espresso-contrib`	RecyclerView、DrawerLayout、ViewPager、NavigationView 等支持
`espresso-intents`	Intent 验证与打桩（`intended()` / `intending()`）
`espresso-web`	WebView 内元素操作（`onWebView().withElement(...)`）
`espresso-idling-resource`	IdlingResource 基础类（可打进生产代码，不含测试依赖）

03 完整实战场景：登录 → 商品列表 → 详情验证

以一个电商 App 为例，走通"输入账号密码 → 登录 → 等待商品列表加载 → 滚动找到商品 → 进详情页验证"的完整链路。

Step 1：依赖配置

// app/build.gradle
androidTestImplementation 'androidx.test:runner:1.7.0'
androidTestImplementation 'androidx.test.ext:junit:1.3.0'
androidTestImplementation 'androidx.test.espresso:espresso-core:3.7.0'
androidTestImplementation 'androidx.test.espresso:espresso-contrib:3.7.0'
androidTestImplementation 'androidx.test.espresso:espresso-intents:3.7.0'
androidTestImplementation 'androidx.test.espresso:espresso-idling-resource:3.7.0'

android {
    defaultConfig {
        testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner"
    }
    testOptions {
        execution 'ANDROIDX_TEST_ORCHESTRATOR'  // 每个用例独立进程，隔离状态
        animationsDisabled true                  // 关闭系统动画，避免动画干扰同步
    }
}

Step 2：给网络请求装 IdlingResource（生产代码侧）

Espresso 能自动等 UI 线程和 AsyncTask，但你自己的网络库（OkHttp/Retrofit）它不知道。标准做法是用 CountingIdlingResource + 拦截器：

// 生产代码中（espresso-idling-resource 包不依赖测试框架，可以安全打进 APK）
object EspressoIdlingResource {
    private val counter = CountingIdlingResource("network_requests")
    val idlingResource: IdlingResource get() = counter
    fun increment() = counter.increment()
    fun decrement() = counter.decrement()
}

class IdlingInterceptor : Interceptor {
    override fun intercept(chain: Interceptor.Chain): Response {
        EspressoIdlingResource.increment()
        return try {
            chain.proceed(chain.request())
        } finally {
            EspressoIdlingResource.decrement()
        }
    }
}

测试基类里统一注册/反注册：

abstract class BaseEspressoTest {
    @Before
    fun registerIdlingResource() {
        IdlingRegistry.getInstance().register(EspressoIdlingResource.idlingResource)
    }
    @After
    fun unregisterIdlingResource() {
        IdlingRegistry.getInstance().unregister(EspressoIdlingResource.idlingResource)
    }
}

Step 3：测试用例

@RunWith(AndroidJUnit4::class)
class ShoppingFlowTest : BaseEspressoTest() {

    @get:Rule
    val activityRule = activityScenarioRule<LoginActivity>()

    @Test
    fun login_browseProduct_verifyDetail() {
        // ── 1. 登录页：输入账号密码 ──
        onView(withId(R.id.et_username))
            .perform(typeText("test_user"), closeSoftKeyboard())
        onView(withId(R.id.et_password))
            .perform(typeText("123456"), closeSoftKeyboard())

        // ── 2. 点击登录（网络请求期间 Espresso 自动等待）──
        onView(withId(R.id.btn_login)).perform(click())

        // ── 3. 列表页：验证标题与列表出现 ──
        onView(withText("商品列表")).check(matches(isDisplayed()))
        onView(withId(R.id.rv_products)).check(matches(isDisplayed()))

        // ── 4. 在 RecyclerView 中滚动找到目标商品并点击 ──
        onView(withId(R.id.rv_products))
            .perform(
                RecyclerViewActions.actionOnItem<RecyclerView.ViewHolder>(
                    hasDescendant(withText("机械键盘")),
                    click()
                )
            )

        // ── 5. 详情页：验证商品名与价格 ──
        onView(withId(R.id.tv_product_name))
            .check(matches(withText("机械键盘")))
        onView(withId(R.id.tv_price))
            .check(matches(withText(containsString("¥299"))))
    }
}

全程没有一行 sleep。列表接口返回慢？Espresso 等。RecyclerView 没渲染完？UI 线程没空闲，它继续等。这就是自动同步的价值。

场景延伸：验证跳转 Intent

测试"点击分享按钮唤起系统分享"这种跨 App 动作，Espresso 本体做不到（它不能离开应用进程），但 espresso-intents 可以拦截和验证发出的 Intent，不需要真的跳转：

@get:Rule
val intentsRule = IntentsTestRule(ProductDetailActivity::class.java)

@Test
fun clickShare_firesSendIntent() {
    // 打桩：外部 Activity 的返回结果
    intending(hasAction(Intent.ACTION_SEND))
        .respondWith(Instrumentation.ActivityResult(Activity.RESULT_OK, null))

    onView(withId(R.id.btn_share)).perform(click())

    // 验证应用确实发出了 ACTION_SEND，且携带了正确内容
    intended(allOf(
        hasAction(Intent.ACTION_SEND),
        hasExtra(Intent.EXTRA_TEXT, containsString("机械键盘"))
    ))
}

如果流程必须真实跨 App（微信支付、系统权限弹窗、通知栏点击），那段步骤交给 UiAutomator 写，同一套测试工程里可以混用。

04 异步等待的正确姿势：为什么永远不要 sleep

新手写 Espresso 最常见的反模式：

onView(withId(R.id.btn_login)).perform(click())
Thread.sleep(3000)   // ❌ 反模式！
onView(withId(R.id.rv_products)).check(matches(isDisplayed()))

3 秒在旗舰机上浪费时间，在低端机/CI 机器上又不够用——flaky 测试就是这么来的。正确手段按优先级：

IdlingResource（首选）：网络请求、数据库事务、第三方 SDK 回调，凡是你能感知开始和结束的异步操作，都用计数式 IdlingResource 接管
RecyclerViewActions 等框架封装：滚动、加载更多由 contrib 包内部处理同步
Compose 用 waitUntil：composeRule.waitUntil(10_000) { node.exists() }
实在接不进来的黑盒 SDK（比如广告 SDK 内部自己的线程）：用 UiAutomator 的 until 条件等待兜底，仍然不要 sleep

05 Jetpack Compose 测试

Compose 页面没有 View 树，Espresso 的 onView() 找不到节点，要用 Compose 专属语义 API（androidx.compose.ui:ui-test-junit4），但它和 Espresso 共享同一套 Instrumentation 与自动同步机制：

@get:Rule
val composeRule = createAndroidComposeRule<MainActivity>()

@Test
fun composeLoginFlow() {
    // 语义节点定位：文本 / contentDescription / testTag
    composeRule.onNodeWithText("用户名").performTextInput("test_user")
    composeRule.onNodeWithText("密码").performTextInput("123456")
    composeRule.onNodeWithText("登录").performClick()

    // 断言
    composeRule.onNodeWithText("欢迎回来").assertIsDisplayed()

    // 等待条件（Compose 版自动同步外的兜底）
    composeRule.waitUntil(10_000) {
        composeRule.onAllNodesWithText("加载中").fetchSemanticsNodes().isEmpty()
    }
}

View 与 Compose 混用的页面可以两边 API 各找各的节点，在同一个测试类里共存。生产代码建议给关键节点加 Modifier.testTag("xxx")，比依赖文本稳定。

06 优势与劣势

优势

快：同进程直接调用 + 真实事件注入，单次操作毫秒级，整套回归套件比 Appium 快数倍，CI 反馈时间从"小时级"压到"分钟级"
稳：自动同步机制从根上消灭了"等待类 flaky"，第三方基准测试中 Espresso 的随机失败率在 Android 框架中最低
失败信息友好：元素找不到时直接打印当前 View 层级树；断言失败带完整 matcher 链路，定位问题不靠猜
白盒能力：测试代码可以直接操作应用内部对象——用 Room 插测试数据、Mock 网络层、调用 ViewModel 方法，测试前置准备极其高效
官方一等公民：AndroidX Test 持续维护、Android Studio 深度集成（支持录制测试自动生成代码）、Compose 官方测试方案同宗同源
API 声明式、可读性高：onView(...).perform(...).check(...) 三段式即文档

劣势

只支持 Android：双端团队必须再维护一套 iOS（XCUITest），代码零复用
白盒门槛：需要应用源码和构建环境，测试代码随 App 一起编译，QA 团队无法脱离开发环境独立编写
不能跨应用：权限弹窗、系统设置、通知栏、第三方 App 跳转（微信/支付宝）超出能力边界，必须混合 UiAutomator
异步接管成本：OkHttp、协程、RxJava、EventBus、第三方 SDK 的线程模型各异，IdlingResource 要逐一接入，接不全的地方同步机制就"看不见"，照样 flaky
Hamcrest 学习曲线：matcher 组合语法对纯手工测试转自动化的同学有上手门槛
WebView/游戏弱：WebView 内 H5 测试能力不如 Appium 灵活；Unity/原生 GL 渲染的游戏画面没有 View 节点，完全不适用
debug 构建依赖：插桩测试基于 debuggable 包，与线上 release 包的混淆/优化差异可能导致"测试过了线上挂"

07 选型建议：什么项目该用 Espresso

维度	Espresso	UiAutomator	Appium	Maestro
架构	同进程白盒	系统级黑盒（AccessibilityService）	跨平台 C/S，底层 UiAutomator2/XCUITest	YAML 声明式黑盒
速度	最快（毫秒级）	慢（操作延迟约 300ms）	最慢（多一层 HTTP 链路）	较快
跨 App/系统 UI	❌	✅	✅	✅
跨平台（iOS）	❌	❌	✅	✅
需要源码	是	否	否	否
flaky 率	最低	中	高	中低
适合人群	开发工程师	测试工程师	测试团队/双端复用	追求轻量的小团队

结论很清晰：

✅ 自研原生 Android App、有源码、页面交互逻辑重、回归套件跑在 CI 上——Espresso 是首选，开发阶段写页面顺手就把测试写了
✅ View + Compose 混合/纯 Compose 项目——官方测试方案，无缝衔接
⚠️ 跨 App 流程（支付、分享、权限授权）——Espresso 测 App 内部分，UiAutomator 补系统交互，工程里混用
❌ 只有 APK 没有源码的外包验收测试、游戏、需要 Android/iOS 一套脚本维护——选 Appium/Maestro
❌ 纯 H5/小程序/混合应用——WebView 内场景优先 Appium 或 Web 端方案

一个成熟的 Android 团队最终形态通常是分层的：底层单元测试（JVM，秒级）+ Espresso 覆盖 App 内核心业务流（分钟级）+ 少量 UiAutomator/Appium 覆盖跨 App 端到端链路（发布前门禁）。Espresso 不是全部，但它应该是这套金字塔里最厚的那一层。

一句话总结

Espresso 的哲学是"住进应用家里测试"：同进程注入换来毫秒级速度，UI 线程自动同步消灭 sleep 和等待类 flaky——代价是只认 Android、只测单 App、异步任务要你主动登记。它不是万能钥匙，但在'原生 Android 应用内 UI 测试'这个它的主场里，至今没有对手。

MiniMax H3 MAX 的 AI 直播火了：背后这家估值 45 亿美元的推理独角兽却鲜为人知丨 Voice Agent 学习笔记

RTE — Wed, 02 Sep 2026 21:53:11 +0800

单次推理优化或速度本身从不是护城河。我们最关心的是：面对新的模型和架构，我们能多快跟进？——Batuhan Taskaya，Fal 创始工程师

MiniMax H3 MAX「24 小时直播、无限 AI 生成」的爆火，让训练该模型的公司 Fal 进入开发者视野。

基于 MiniMax H3 后训练而来的 H3 Max，已经把视频生成速度推过了实时播放的门槛：Fal 公布的内部评估显示，生成 5 秒视频不到 3 秒，吞吐量约为 MiniMax H3 官方接口的 35 倍。随后上线的 H3 Max Live 更直接把它做成了一场实时实验——观众在聊天室输入 Prompt，下一段带声音的视频几秒内生成并接入直播流，让生成式视频从「等一个片段」变成可以持续运行的内容系统。

而 H3 Max 更值得注意的地方是，它并不只是快。在 Fal 的人工偏好评估中，它在整体质量、指令理解和美学表现三项指标上都排名第一。

但如果把时间往前拨几年，会发现 H3 Max 并不是 Fal 突然开始做模型研究后的产物。

今天的 Fal 是一家生成式媒体云公司，为图像、视频、音频等生成模型提供训练后优化、推理和部署基础设施。但 2021 年公司刚成立时，它甚至还不是一家 AI 公司。Fal 最初从数据工具和 Feature Store（特征存储）起步，名字本身就来自 Features and Labels。虽然当时还没有进入 AI 基础设施领域，但团队已经积累了一套能够在云端规模化运行 Python 代码的无服务器基础设施。

Stable Diffusion 等生成模型兴起后，Fal 开始把这套能力转向 AI 推理，并押注图像生成，随后逐步扩展到视频和音频。这个转型也获得资本市场持续加注：2024 至 2025 年间，Fal 连续完成多轮融资，累计披露融资约 3.37 亿美元，最新估值 45 亿美元。

而几乎完整经历这条路线的人，就是 Fal 工程负责人 Batuhan Taskaya。

Batuhan 是 Fal 最早期的工程师之一。加入公司之前，他长期活跃于 Python 开源和编译器生态；2021 年，在 Fal 完成种子轮融资前加入公司。此后，他先后做过云端 Python 分布式运行环境、编译器、自研推理引擎、应用机器学习和模型后训练，如今负责 Fal 的整个工程团队工作。

沿着 Batuhan 的经历往回看：一家最初做数据工具、只有 6 个人的公司，是怎样一步步把 Python 云计算、GPU 基础设施、推理优化和模型后训练串起来，最终走到 Minimax H3 Max。

核心观点

Batuhan Taskaya

Fal 创始工程师、工程负责人；

Python 开源维护者

H3 Max 不是 Fal 突然开始做模型，而是多年技术积累的一次汇流。 从无服务器 Python、GPU 基础设施、推理引擎到模型后训练，Fal 最终把「改造模型」和「加速推理」两条能力合到了一起。
Fal 押注图像，是一个 6 人团队主动做出的取舍。 当 LLM 已有 OpenAI 等强势玩家时，Midjourney 已验证图像需求，但市场仍缺少稳定、可扩展、成本足够低的生成式媒体基础设施。
Fal 真正的护城河不是某一次跑得最快，而是新模型出来后能多快优化到位。 单项性能迟早会被 NVIDIA 和开源社区追平，Fal 更看重持续跟进新模型、新 GPU 架构的速度。
从图像扩展到视频，本质上是沿同一批客户继续做深。 视频模型真正可用后，Fal 将其接入原有图像工作流；约一年时间，视频就从收入占比 0% 增长到接近 50%。
Fal 想做的不是基础模型公司，而是模型与应用之间的中立基础设施层。 它一边运行第三方模型，一边基于开源模型做微调、蒸馏和推理优化；最终衡量模型价值的，也不是公开排行榜，而是客户自己的留存、转化率和业务 Benchmark。
Batuhan 的个人经历，几乎就是 Fal 技术演进的缩影。 从 Python 开源维护、云端分布式运行环境，到编译器、自研推理引擎、应用机器学习和模型后训练，他个人角色的变化，也对应着 Fal 从数据工具一路深入 GPU 基础设施、生成式媒体推理乃至 H3 Max 的过程。

嘉宾： Batuhan Taskaya（Fal 创始工程师、工程负责人；Python 开源维护者）

主持人： Tim Chen（Essence VC）、Robby（Modern Technical Fund）

注：为便于阅读，本文在原始播客转录稿基础上进行了提炼、重组与术语校正，并非完整对话。

从土耳其硬核 Python 开源维护者到 Fal 工程负责人

主持人：欢迎 Batuhan，你是如何认识 Fal 的创始团队，又为什么会在公司成立第一年就加入？

Batuhan： 大约在 2021 年，Fal 刚成立或还处在成立前夕。当时我人在土耳其，我觉得自己是当时土耳其少数几个真正硬核的开源维护者之一，尤其是在 Python 生态里。Fal 的创始团队正在围绕 Python 构建数据管道工具，因此主动联系了我。

一位创始人在纽约，另一位联合创始人兼技术负责人 Yurkem 在旧金山。我们虽然远程合作，但有相近的土耳其文化背景，相处也很投缘。几个月后，我在公司完成种子轮融资前正式加入，并一直工作到现在，我做过很多基础设施方面的工作。

最开始，我搭建了让 Python 代码在云端运行的分布式系统基础设施。后来公司开始做模型推理，我把重心转向编译器，参与自研推理引擎，用来运行和加速开源机器学习模型。再往后，我又进入应用机器学习和模型后训练。

所以我基本做过全栈，现在负责公司的整个工程团队。

从特征存储到生成式媒体云：Fal 的转型并非凭空发生

主持人：你们是怎么从最初的 Fal，一路做到今天的生成式媒体云的？

尤其是在 2022 年刚开始时，生成式媒体还远没有成为一个明确的大市场，虽然 GAN 已经存在，但行业还没有今天这样的共识。

所以从你加入、看到那个 Python 项目开始讲讲吧：后来到底发生了什么？

Batuhan： 我们最初做的是 Feature Store（特征存储）。其实 fal 这个名字就来自 features and labels。这个产品后来迭代了一阵，但到了 2021、2022 年，行业进入了「现代数据栈」非常火的阶段——Databricks、Snowflake 之后，大家都在谈数据转换、数据管道和大数据，那时候甚至还没有 ChatGPT，AI 也不是行业焦点。

我们当时发现一个空缺：本地的数据工具大量使用 Python，但到了云端，数据转换基本都是 SQL。

所以最初的问题很简单：能不能把 Python 带进云端的数据转换流程？

我们先基于 dbt 做了一个开源项目，让开发者可以在 dbt 工作流里运行 Python：一段 SQL 转换之后，可以接 Pandas DataFrame 处理，再继续跑 SQL。也就是说，让 SQL 和 Python 可以交替出现在同一条数据管道里。

有了这个基础之后，最自然的下一步就是上云、做规模化计算。比如把一个 1TB 的数据集拆成多份，并行跑 Python 转换，最后再用 SQL 汇总。

于是我们开始在云端做一个全托管、无服务器的 Python 运行时，目标是让 Python 代码在云端高效执行。这个基础后来也决定了我们的方向：Python 云计算最大的应用场景会是什么？答案逐渐变成了 AI 推理。

2022 年前后，Stable Diffusion、ChatGPT、DALL·E 等模型相继出现。我们手里正好已经有一套支持 GPU 的云运行时，于是最开始只是抱着实验心态：既然 GPU 已经有了，为什么不拿它来跑这些模型？

一开始，我们只是想看看，怎么把现有的云计算平台扩展到一个更常见的用例上。

我们后来发现，跑 AI 模型当然很有意思，但要把单个模型真正做成生产级服务，工作量其实非常大，因为其中还有大量性能可以挖掘。

当时我们必须做一个选择：到底专注优化哪一类模型？ 语言模型、嵌入模型，还是图像模型？可选方向很多，但团队只有 6 个人，不可能什么都做。

最后我们判断，图像是最值得切入的方向。

那时语言模型赛道已经很拥挤，OpenAI 也在大力推进 API；但图像这边，虽然 Midjourney 已经证明了市场需求非常大，真正可靠、可扩展、成本可控的图像推理 API 却几乎还是空白。

于是我们花了大约 6 到 9 个月「闭关」，专门研究一件事：

怎样让图像模型在云端跑得更稳定、更快、更便宜？

这也催生了我们最初的平台——一个面向开发者的生成式媒体平台。到了 2023 年底，我们开始正式全力推进这个方向，并逐步从图像 API 扩展到视频 API、语音、3D 模型、世界模型。原因也很直接：使用图像模型的开发者，往往也会需要视频和音频能力；但他们通常并不是语言模型 API 的核心用户，这是两套不同的市场。所以我们没有一边做媒体、一边再去追语言模型，而是围绕自己的用户群持续扩展。

这套路径带来了非常快的增长，也让我们逐渐从上层应用能力走向更底层的基础设施。我们开始为模型公司提供推理服务，支持他们带着自有模型接入，由我们负责优化和部署；同时也开始自建 CDN、分布式文件系统，以及更多类似超大规模云平台的底层能力。

这一策略之所以有效，也和市场结构有关。媒体模型赛道高度碎片化：有上百家公司在训练各种垂直模型，比如分割、抠图、背景移除等。正因为市场足够分散，我们反而有机会在其中拿下相当可观的份额。

所有人都在追 LLM，Fal 为什么偏偏押注图像？

主持人： 即使到今天，Fal 好像也没有特别强的直接竞争对手。很多公司都在追逐语言模型，语言模型仍然主导着行业讨论。

服务图像或视频模型，与服务语言模型到底有什么不同？在性能和基础设施上，你们需要建立哪些不同的能力？

Batuhan： 从技术层面看，语言模型通常是自回归模型，核心任务是预测下一个 token。而图像和视频模型则主要是扩散模型：从随机噪声出发，对整张图像或整段视频反复去噪，可能要重复二十次左右。这个过程高度重复，也非常消耗计算资源。

语言模型本质上是在移动一个巨大的万亿参数的矩阵来预测下一个 token，主要瓶颈通常是内存带宽。为了提高效率，服务商会把不同用户的请求组成批次，并在集群之间做并行计算。

图像和视频模型面对的是另一类问题，重点更偏向算法和底层计算内核的效率。这正是我们的优势所在：我们能够写出最好的内核，让这些模型跑得飞快。Fal 团队有分布式系统和性能工程背景，我们早期的优势，就是能够针对这些模型编写高效的计算内核，让它们运行得更快。

但我们从来没有把单次推理优化或速度本身看成护城河，开源项目最终会追上来。NVIDIA 光是做 TensorRT 这类推理引擎，可能就有四五十个人在投入。

我们真正关心的是：面对新的模型和架构，Fal 能多快完成跟进和优化。

新模型刚发布时，我们可以很快让它在 Fal 上达到更好的运行状态；如果只等待开源社区，可能要几个月才能达到类似的性能。我们会持续推出新的速度优化。这就是我们差异化的核心。语言模型领域的 vLLM、SGLang 也存在类似情况，它们与最大性能之间通常还留有距离。图像领域也是一样，只是面对的技术问题不同。

决定转型后，Fal 如何用 6–9 个月完成重建

主持人：决定做生成式媒体后，你们最先做的是什么？我猜测你们不会一上来就写推理引擎、定制内核吧？当时是怎么一步步执行的？

Batuhan： 最关键的市场判断是：语言模型赛道已经有 OpenAI 这样强势的玩家，而且它们能提供最好的模型和可规模化的 API，对我们这种小团队来说很难正面竞争。闭源方面，OpenAI 有 GPT-3 的 API。从 GPT-3 到 Llama 2 的差距，比今天前沿模型到 Kimi 的差距还要大。但图像生成领域不一样——Midjourney 已经证明了市场需求巨大，却没有开放 API；DALL·E 有 API 但模型当时不太好，市面上已有的图像 API 大多是简单把模型塞进 Docker 容器，速度慢、成本高、无法稳定扩展。

我们只是拿到一笔还算体面的种子轮融资，而看看那些公司，他们都在做 A 轮、B 轮。OpenAI 当时已经融资数十亿美元。对我们来说，专注于一个我们能真正做出差异化的类别，显然更合理。

这个落差让我们决定专注于图像。但真正的执行比这复杂得多。我们当时只有 6 个人，需要同时完成几件事。

第一，把系统从单云平台重构为多云 GPU 基础设施。 我们原来只是在 Google GKE（Google Kubernetes Engine，谷歌 Kubernetes 托管服务）上跑 Kubernetes，启动一个 pod 就能工作。但 2023 年 GPU 极度紧缺，Google 可能只能给你 8 块卡。为了拿到更多算力，我们必须支持 Lambda Labs、CoreWeave 等新出现的云厂商。这意味着要自己写调度层、自己建分布式文件系统、重新搭可观测和监控栈，几乎把原来基于 GKE 的一套全换掉。

我们本可以选择高价从 Google 签长约买 GPU，但那样就太贵了。我们选择去找最便宜的 GPU，自己搭建编排和系统层。

第二，开始系统性地做性能优化。 刚上 API 时，我们用 PyTorch 跑同样的模型，速度和别人一样。但生成一张图理论上需要多少 FLOPs、GPU 能提供多少 FLOPs，是可以算出来的——我们实际慢了 3 到 4 倍。这几乎不可接受。

我虽然是编译器背景，做过 PyPy JIT（即时编译器，在程序运行时把频繁执行的 Python 代码编译成机器码，从而提升运行速度）和数据库查询引擎，但完全没有 GPU 经验。不过性能工程的方法论是通用的：跑代码、做性能剖析、定位瓶颈、尝试优化、解决、再找下一个瓶颈。几个月内，我们就把 GPU 利用率从大约 30% 提升到 70–80%。

第三，在技术上赌一把的同时，用商业指标验证。 拿着原来的数据工具想法融了资，突然说要完全转型，这是很大的决策。所以我们在闭关期间就定了一个门槛：先拿下两个大客户，看看新业务能不能跑出收入。 特别是 Burkay 和 Gorkem，他们当时非常专注于怎么让两个大客户用上我们的 API，看看行不行。

对于一家新公司、一条你毫无经验的新产品线来说，最初获取客户的过程非常残酷。但一旦熬过去，就像打开了闸门。我们花了将近 9 个月才拿到两个客户，但正是这两个客户，让我们从新业务做到 100 万美元年化收入。

这给了我们放弃旧产品的证据。因为如果要靠原来的数据工具做到 100 万美元年化收入，会难得多。之后我们正式对外推出平台，约一年从 100 万美元涨到 1000 万美元，又在 2024 年 8 月到 2025 年 8 月再涨十倍，达到约 1 亿美元年化收入。

主持人： 这太疯狂了，从最开始的两个客户，到现在服务各种生成式媒体。在这么短的时间内，你们已经形成了一个应用开发者和模型构建者的市场。

从图像生成到视频收入占比近半：Fal 如何沿着同一批客户扩展生成式媒体版图

主持人： 你们从图像开始，后来是怎么想到扩展到视频、音频的？或者说你们搭建平台的方式让你们可以自然扩展？讲讲你们决定不断扩展品类的心路历程。

Batuhan： 图像模型最早出现在 2022 年。第一个真正可用的视频模型要到 2024 年中才出现——Sora 年初发了预告，但实际可用的模型大概是 7 月前后。那时候我们已经深入图像领域一段时间了。

视频和图像的客户需求天然衔接：当时的视频模型大多是图生视频，图像就是生成视频的前置步骤。所以一旦模型质量过关，加视频模型进去是很自然的事。我们其实早在客户提出需求之前就有人在问，但我们说，再等等，等模型足够好。

当时也已经有一些视频模型了，但效果其实还不太行。有的模型只能生成 25 帧，也就是大约 1 秒的视频。可如果只能生成 1 秒，实际能做的事情非常有限，甚至都很难把它称作一段视频。

那时候大家会想各种比较极端的办法，比如先生成一个 8 FPS、3 秒钟的视频，再通过插帧把它补到 24 FPS。但本质上，生成出来的内容并没有因此变得更丰富，只是把原来的那些画面补得更流畅而已。

所以我们当时的想法很简单：先等。

等到视频模型真正变得足够好，我们才开始去问之前的客户：「我们现在平台上增加了这个视频模型，你们会用吗？」客户真的开始用了，我们才把这些模型正式加入平台。

2024 年 8 月到 2025 年，视频收入从 Fal 平台收入的 0% 涨到了接近 50%，成为新增收入的重要驱动力。

音频目前占比还比较小，不到 10%。原因是 Fal 并不把音频模型卖给呼叫中心或客服坐席——那些不是我们的客户。我们服务的是创意音频用例，比如把多个视频剪成故事书后配一点背景音。所以不管图像、视频还是音频，我们都在围绕创意和媒体生产这个场景收敛，而不是什么都做。

这和呼叫中心用例完全不同，我们更偏向媒体领域。

开源策略：API 与开源模型并行

主持人：我觉得还有一个特别重要的问题，Fal 的开源策略到底是什么？

Fal 最早围绕 dbt 做的项目就是开源的，所以你们从一开始就在开源生态里。现在进入生成式 AI 之后，你们的平台上又运行了大量开源模型——这显然也是你们能够托管这些模型、做性能优化，再把它们作为服务提供给客户的重要基础。

从更长远的角度看，除了直接使用这些开源模型之外，开源是否是 Fal 建立这家公司、形成长期竞争力的一项核心战略？

Batuhan： 我们非常相信开源。我自己曾经花了四五年时间做开源，给 Python 语言和编译器相关项目贡献。

我们的思路是：哪些部分对用户自己运行东西是有用的？

策略分两方面。一方面，我们消费开源模型——Black Forest Labs、Alibaba 等公司训练并开源了非常好的基础模型，我们把它们作为 API 运行和优化。另一方面，我们有一个五六人的后训练团队，会针对不同用例做微调、蒸馏，让模型跑得更快，并把这些成果也开源发布。

所以 Fal 整体的商业模式其实很简单：如果你需要 API，就直接用 API；但理想情况下，任何能通过 Fal API 使用的能力，也都应该有对应的开源模型可以让你自己运行。

这个模型可以是我们训练的，也可以是其他团队训练的。只要它是开源的、用户能够获取和运行，这就是我们一直坚持的方向。

与此同时，我们也不只是使用开源生态里的东西。我们会持续给自己依赖的开源库贡献代码，一些推理优化也会回馈社区。我们的优化团队和 NVIDIA 合作得非常紧密，会一起把部分优化能力移植到更广泛的生态中。

所以对我们来说，开源不只是「拿开源模型来提供 API」这么简单。它还包括：我们怎样把自己在推理、性能优化上的一部分成果重新贡献回社区。

Fal 推理引擎的核心：不是静态速度，而是持续跟进新模型的能力

主持人：Fal 的推理引擎为什么让用户愿意选择你们？

Batuhan： 平台上线之后，我们最开始听到的一类反馈是：「我们只是把 API 从你们的竞争对手切到 Fal，用户留存率就提高了。」

甚至有一个客户专门做过实验。他们故意把 Fal API 的响应放慢，想看看留存率会发生什么变化。因为我们的价格当时比某个竞争对手稍贵，他们想验证：用户到底愿不愿意为更好的性能支付溢价？

结果证明他们愿意。

所以性能对我们来说一直非常重要。而它背后主要来自两方面：第一是纯粹的性能工程，第二是对模型本身的理解。

任何做机器学习推理的团队，基本都可以从两个方向优化模型。

第一，是完全不改变模型本身，只让同一个模型跑得更快。

你可以保持计算结果不变，只调整计算方式：重新排列计算图、使用速度更快的计算内核、利用 GPU 特性、把不同操作做成流水线等等。模型做的还是同一套计算，只不过执行方式变得更加高效。

我们把这一类称为算法和推理层面的优化，Fal 有一整支团队专门做这件事。

GPU 本身其实是非常复杂的机器，而且每一代架构都有很大的差异。

比如一个简单的矩阵乘法，可能很容易达到 GPU 理论性能的 60%–70%；但如果运行 attention 这样的复杂操作，利用率可能只有 30%–40%。

那么问题就变成了：

怎样把一个只能利用 30%–40% GPU 性能的通用操作，针对具体模型和硬件进行优化，让它提升到 80%–90%？

这就是我们性能工程团队每天在解决的问题，而且每换一代 GPU，这些工作几乎都要重新做。从 A100 到 H100 是一次很大的架构变化，从 H100 再到 Blackwell，变化更大。有些团队可能要花几个月，才能把工作负载从 H100 迁移到 Blackwell，并重新达到原来的性价比水平。

我们希望能够非常快地完成这个过程。

第二，则是直接对模型本身做后训练。

我们有另一支独立的后训练团队，会使用蒸馏、KV Cache 等机器学习技术去优化图像和视频模型。

这时候得到的已经不再是和原模型完全等价的模型。它的行为可能和原模型有 90%、95% 的相似度：有些场景甚至会超过基础模型，有些场景则可能表现得稍差一些。

因为它本质上已经是另一个模型，所以我们会通过不同的 API 提供。

比如同一个图像模型，我们可能会提供一个 Turbo Edition（加速版）。它可能是经过蒸馏的版本，价格更低、速度更快。根据具体用例，你可以选择 Turbo 版，也可以继续使用原始模型。

但如果我们做的是前面那种纯推理优化，原则就完全不同：我们会尽可能忠实于原始模型，不希望优化改变它的输出表现。这也是为什么评测是整个过程中最重要的事情之一。

你必须确定：我做了这么多优化之后，模型输出到底有没有被改变？

这件事不能只依赖简单的数值比较。生成模型本身存在非常大的随机波动，数据噪声也非常高，所以我们搭建了一整套评测体系。

一是数学评测，二是人工偏好评测。

在进行重大优化之前，我们会分别拿到两个结果：一个是优化后模型生成的结果，另一个是使用 PyTorch 运行原始模型得到的结果。

然后把两组结果交给人来判断：「这里有两个输出。我们认为它们应该差不多，但你觉得哪一个更好？」

通过这种方式，我们可以验证优化是否对模型质量产生了影响。对于经过蒸馏等后训练得到的新模型，我们也会进行同样的评测，去理解这些改变究竟带来了什么影响。

所以 Fal 内部实际上有两支团队围绕这件事工作：

一支团队负责在不改变模型行为的前提下，把推理做到更快；另一支团队负责通过后训练，得到更快、更便宜，甚至在特定场景下表现更好的新模型。

还有一个容易被忽略的区别是，我们绝大多数优化都针对服务器级 GPU，比如 A100、H100、B200。

这和大家在消费级硬件上做的优化其实是两个不同的世界。消费级可能是 RTX 5090、4090 这样的游戏显卡，或者 MacBook 上的 M4 芯片；而我们关注的是数据中心里的服务器级芯片，以及这些硬件在大规模模型推理时的性能。

现在实际上正在形成两个不同的优化生态，而 Fal 基本只专注服务器级芯片这一边。

客户服务方式的变化：从自助到解决方案工程

主持人： 我觉得很有意思的一点是，Fal 所处的市场其实和 Together、Fireworks，以及 Baseten、Modal 这类公司不太一样，对吧？

因为大家其实都在做类似的事情：写定制计算内核、做模型推理优化。但我的感觉是，Fal 的客户范围可能非常广，而真正贡献大量收入的，往往只是其中相对少的一部分客户。

对于这些大客户，你们显然不能只是把内核优化好就结束了，还需要确保他们的具体需求真正被满足。

我看到很多基础设施公司做到这个阶段后，工程师都会直接和客户坐下来，一起做类似解决方案工程的工作：理解他们具体在做什么、瓶颈在哪里，然后决定究竟应该优化模型、优化推理系统，还是做其他定制工作。

所以我很好奇，Fal 是怎么决定工程资源该投入到哪里的？

因为处在模型和应用之间这一层，可以做的事情其实非常多。面对这么大的优化空间，你们怎么判断：哪些问题值得做，哪些不值得做，又优先为哪些客户做？

Batuhan： 这件事其实挺有意思。我们最早的一批客户基本都是 AI Native 公司，很多也是和我们一样的创业公司。

他们通常非常清楚自己要什么：知道该用哪个模型，也知道具体要什么配置。他们需要 Fal 做的，更多是把模型运行得更稳定、更容易扩展、更快，同时把成本降下来。

所以最初这些客户其实并不太需要我们帮他们选模型，也不需要太多针对具体用例的咨询，但随着我们开始进入企业市场，情况慢慢发生了变化。

有些企业客户此前甚至从来没有用过图像模型。他们第一次打开 Fal，会直接问我们：「你们平台上有 100 个模型，我到底该用哪一个？」

这时候我们就必须先问：你的具体用例是什么？ 比如客户想做虚拟试衣：输入一张真人照片，再输入一件衣服，希望模型生成穿上这件衣服后的效果。

那我们可以给他推荐几个适合虚拟试衣的模型。

但问题马上又来了：「你说这是最好的模型，所谓『最好』到底指什么？」

有的模型可以做到非常高的像素级还原，对原图和衣服都很忠实，但速度比较慢；有的模型速度快很多，更适合快速生成草稿；还有一些模型会加入更多生成式处理，让衣服和人物融合得更自然，但也因此不会完全忠于输入图像。

所以你很难脱离具体业务，单独说哪个模型「最好」。

归根到底，最后还是要看客户自己的 Benchmark。

这也是那些真正拥有终端用户的公司非常有价值的一点：他们有真实用户在消费这些模型生成的内容，也就有自己的业务数据和指标体系。

很多 Fal 客户的评测体系其实做得非常完善，他们可能会直接跟我们说：「给我三个模型，我们自己跑 A/B 测试。」然后分别观察哪个模型的用户反馈更好、哪个模型带来的转化率更高。最终，他们通常就是通过这种方式决定该使用哪个模型，而不是单纯看一个公开排行榜或者某个统一的模型分数。

再往企业级走一步，我们还会提供更深的服务。

Fal 有一支 Creative Engineering（创意工程）团队，会直接和客户合作，为他们做定制模型的后训练。

我们会从客户自己的业务场景中收集数据，然后基于这些数据训练或微调模型，让它更适合这个客户具体的使用场景。

所以到了这个阶段，我们关心的问题就不再只是：「哪个现成模型最好？」

而是：「你真正关心的业务指标是什么？我们怎样和你一起，把模型在这个指标上的表现做到最高？」

这就是我们服务企业客户时最核心的方式，而且 Fal 做这件事非常深入。我们和客户之间已经有数千个 Slack 频道，工程师会直接待在这些频道里，客户遇到问题可以直接和工程师交流。我们的工程团队并不是只在后台优化模型和基础设施，很多时候他们也会直接参与客户的实际使用过程。

定制模型不会因为基础模型越来越强就消失

主持人：Fal 有没有想过自己训练模型？你们会一直是市场平台吗？

Batuhan： 生态里确实有这个争论，比如 Cursor、Intercom 都在训练自己的模型。但 Fal 同时服务模型供应商和终端客户，所以我们更希望自己处在一个中立的位置。

如果你是模型提供商，我们帮你把自己的模型部署、运行起来；如果你是应用客户，想使用某个开源模型，我们也帮你把它跑起来。

我们目前不看好自己预训练模型，我们更擅长在开源基座模型上做后训练，并把这些成果开源。

过去 12 个月，Fal 平台上单一最大模型贡献的收入不到 10%。模型碎片化非常严重，平均生命周期也很短。即使模型越来越小、训练效率越来越高，训练一个模型仍然要投入很多。而且因为模型的生命周期并不长，你基本上被困在必须不断、快速、高强度地产出越来越好的模型里。

主持人： 这也引出了另一个问题。你刚才提到，Fal 会帮一些客户做定制模型，但与此同时，市场上每天又有大量新模型不断出现。

所以当客户面临选择时，你们会怎么帮他判断：在模型更新这么快的市场里，什么时候值得做定制模型，什么时候应该等下一代开源模型。

Bacuhan： 一般来说，市场上发布的新模型都是面向通用场景的基础模型。但我们帮客户训练定制模型时，针对的通常是非常具体、非常垂直的用例。

这个范围可以窄到什么程度？从「图像编辑」缩小到「虚拟试衣」已经很具体了，但还可以继续缩小到比如：专门做睡衣的虚拟试衣。

我们通常只会在客户拥有大量专有数据的情况下做这种定制。

比如一家企业过去很多年一直在用 Photoshop 处理图片，或者长期用真人进行拍摄，已经积累了大量真实业务数据。这些数据可能是它过去 10 年、20 年一点点沉淀下来的，而训练通用模型的公司根本接触不到。

这时候，定制模型的价值就体现出来了。你可以拿一个开源基础模型，在它上面用这些专有数据进行微调。这样，模型一方面保留了基础模型原本已经学到的通用能力，另一方面又能获得客户自己数据里的特定知识和上下文。

所以我认为，定制模型这件事不会因为基础模型越来越强就消失。

真正会不断变化的，只是底下使用的是哪个基础模型。如果下个月出现了一个更好的基础模型，那就把新的模型换进来。整个定制和后训练流程并不需要推倒重来，你仍然可以继续使用自己积累的那套专有数据。

基础模型可以不断替换，但客户过去多年积累的数据不会消失，这才是定制模型最大的价值。

今天生成式媒体领域最大的技术难题：扩展媒体模型与算力紧缺

主持人：今天生成式媒体领域以及 Fal 面临的最难的技术问题是什么吗？

Batuhan： 最大的问题还是扩展媒体模型。图像模型已经比较接近「难以分辨真假」，大概 95–96% 的水平。但视频还远没有到这个程度，不知道你们有没有在 Twitter 上看到 Seedance 2，当时非常火，现在也不断有新的视频模型出来。但整体来看，视频模型距离语言模型今天的成熟度还差得很远，而且视频本身又是非常计算密集的模型。

我一直觉得这里存在一个不匹配。

如果看 AI 出现之前整个媒体产业的规模——电影、广告、短视频、游戏、视觉内容，这本来就是一个极其庞大的市场。但今天投入到视频模型训练上的资金，与这个市场本身的重要性并不成比例。

其中一个原因很简单：训练视频模型太贵了。

不过情况在改变，每三个月左右都能看到一次阶跃式提升。

好消息是视频数据几乎是无限的。文本数据有限，但你可以拿相机出去无限拍摄。数据侧没问题，关键还是算力。

对 Fal 来说，另一个大问题是算力紧缺又回到了 2023 年的状态。而且这一次不只是 Google、AWS、Microsoft 这样的超大规模云厂商缺算力，而是几乎所有云计算公司都在缺。你看看 Claude Code、Codex 这些产品，每天都在生成海量 token，这些 token 最后都要跑在某块芯片上。

如果 Anthropic 想把收入从 20 亿美元做到 200 亿美元年化收入，它需要什么？需要更多算力。

这也是为什么过去几个月，我们一直在研究更多硬件选择。比如能不能更多使用 AMD GPU，能不能使用 Google TPU，能不能使用 AWS Trainium。

目的都一样：想办法获得更多可用算力。

我们当然还是会尽可能使用 NVIDIA，但问题是，现在如果你突然需要几千块 NVIDIA GPU，并不是今天下单明天就能拿到。很多时候要提前三个月、甚至六个月预订。

所以如果你今天就需要新增算力，就必须开始考虑 NVIDIA 之外的硬件。

这也是 Fal 现在非常重要的一项工作：让我们的推理系统能够运行在更多不同的芯片上，从而继续扩大算力容量，服务更多客户。

给创始人的建议：精简的团队、关心你的客户、好的产品

主持人：最后，你会给其他进入这个领域的创始人什么建议？

Batuhan： 从赛道本身来看，这是我这辈子见过增长速度最快的领域，真的非常疯狂。

如果要给创业者一些建议，我觉得第一点是：尽可能保持团队精简。

现在可以看到人均 500–600 万美元收入的公司，这在以前很难想象。小团队执行更快，也给了你更多回旋余地。我们能这么容易转型，很大程度上因为当时只有 6 个人。我们没有提前招很多人、把组织做得很重，所以当市场发生变化时，可以很快掉头。

这次转型后来几乎改变了整家公司。

第二，真正关心你的客户。

我觉得今天最重要的资产就是客户，以及你和客户之间建立起来的关系。技术会被追上，模型会不断更新，很多东西都很难形成永久的壁垒。但客户关系仍然是最难被复制的东西之一，所以要非常认真地服务客户。

第三，产品、产品、产品。这极其重要。

主持人： 太好了。感觉我们快速回顾了一家疯狂公司的旅程，也回顾了你个人的旅程。非常感谢你加入我们。

Batuhan： 这太棒了，谢谢你们邀请。

参考与来源

fal 直播现场：https://fal.live/
Fal's Bet on Generative Media 播客来源：

https://ossstartuppodcast.substack.com/p/episode-194-fals-bet-on-generative

Fal 官方博客 Introducing H3 Max by fal:

https://blog.fal.ai/introducing-h3-max-by-fal

编译：@ 三水、@ 鲍勃

🎰彩蛋：基于 H3 Max 和 Suno，Batuhan 制作的个人形象演唱视频。

Runway 发布「界面世界模型」Solaris ，不生成代码、实时渲染可交互 App；Sesame 开源 TurnBench，14 套轮次系统无一做到又快又准丨日报

RTE — Wed, 02 Sep 2026 21:08:50 +0800

本期编辑：@ 三水、@ 鲍勃

01 有话题的技术

1、AI 视频生成公司 Runway 发布首个「界面世界模型」Solaris：不用生成代码，直接逐帧实时生成可交互 App 和网页

AI 视频生成公司 Runway 发布 Solaris，并将其定义为首个 Interface World Model（界面世界模型）。它不再走「LLM 生成 HTML / CSS / JavaScript → 浏览器执行」的路线，而是把界面本身当作一个持续生成的世界：用户点击、拖拽或输入后，模型直接生成下一帧 720p 画面，让图片本身成为可以实时交互的应用。

界面不再由预写代码决定： Solaris 持续接收点击、拖拽等操作作为下一帧生成条件，同一个初始画面可以根据用户行为产生此前没有被开发者预先定义过的交互。
基于 Runway Gen-4.5 改造成实时引擎： 团队先将视频模型改造成逐帧自回归生成，再把多步去噪蒸馏到少量步骤，并让模型在自身生成结果上继续训练，以维持长时间交互中的画面一致性。
语言模型负责「想」，世界模型负责「画」： LLM 判断用户意图、场景应该如何变化以及何时切换状态，Solaris 则负责把这些决定实时渲染成连续界面，实现推理与视觉生成分工。
用户研究中优于代码生成界面： Runway 将 Solaris 与 Claude Opus 5 生成的代码界面进行 30 组交互对比、收集近 7500 次判断；在指令遵循上 Solaris 获得 61% 偏好，代码界面为 24%，在交互自然度上则为 71% 对 21%。

Solaris 目前仍处于研究阶段，可申请抢先体验；稳定文字生成、长时间一致性、可信信息约束和无障碍兼容仍是待解决问题。

https://runway.com/news/research/introducing-solaris

2、实时语音 AI 公司 Inworld AI 开源 TTS 评测工具 Open TTS Eval：不只报一个 WER，而是把音频、ASR 转写和评分过程全部留档

实时语音 AI 公司 Inworld AI 开源 Open TTS Eval，希望解决 TTS Benchmark 中「同一模型、同一数据集，不同团队却能测出不同结果」的问题。工具会把每次评测使用的声音、合成配置、原始音频、ASR 转写、文本规范化方式、阈值和逐样本结果保存在同一目录，让开发者可以从最终分数一路追溯到具体哪条语音出了问题，而不是只得到一个无法复现的平均值。

把评测协议本身也纳入结果： WER/CER 会受到 ASR 模型、文本规范化和失败样本处理方式影响，Open TTS Eval 因此把这些配置与每条样本结果一起保存，并支持查看「参考文本 vs。 ASR 实际听到的内容」。
不试图用一个总分定义 TTS 好坏： 首版同时评测 WER/CER、静音与削波、响度、语速、尾部杂音、元音异常延长，并可加入 NISQAv2 和说话人相似度；Inworld 特别强调，低 WER 并不代表声音自然。
附带 100 条专门「找茬」的英语测试语料： 包括残句、打断、重复词、嵌套引语和长台词等容易让 TTS / ASR 出错的内容，用于在大规模评测前快速暴露明显问题。
首版已接入多家 TTS 服务： 内置 Inworld、ElevenLabs 和 Hume 的生成适配器，其他 TTS 系统也可以直接提供音频清单接入；评测完成后可生成完全离线、可检查的 HTML 报告。

https://inworld.ai/blog/introducing-inworld-tts-open-evaluation-toolkit

3、Tontaube 发布流式 TTS 模型 Tontaube V1：单张 RTX 5090 首段音频约 200ms，权重可本地部署

AI 音频平台 Tontaube 发布 Tontaube V1，一款采用分层音频编码建模和有限上下文机制的流式 TTS 模型。模型由 4 个从语义到声学逐级生成的预测器组成，总参数约 2.9B，可在单张消费级 GPU 上运行；官方在 RTX 5090 上测得首段音频约 200ms，单路生成 RTF 为 0.08，约为实时播放速度的 12.5 倍。

长文本生成不需要无限增长上下文： 模型只保留上一段、当前段和少量下一段文本，并持续丢弃更早内容，让输入上下文在长篇语音生成过程中保持固定规模。
先决定「说什么、说多久」，再逐级补声音细节： 第一阶段生成语义音频表示并确定整句话长度，后续三个较小模型再补充声学细节，希望把更多算力集中到决定韵律和内容的部分。
支持参考音频复刻与多种朗读风格： 可使用最长约 60 秒参考音频进行声音条件控制，目前主要面向英语和德语，同时提供西班牙语、法语、意大利语、荷兰语和葡萄牙语输入，以及有声书、对话和 Agent 三种风格。

https://craitech.io/blog/tontaube-v1-model-card

4、实时语音 AI 公司 Gradium 发布新版实时 TTS 模型：TTFA 中位数 216ms，电话号码、邮箱等复杂文本准确率达 81%

实时语音 AI 公司 Gradium 发布新版实时 TTS，并直接替换为平台默认模型，重点同时解决 Voice Agent 里常见的低延迟与复杂文本准确性问题。新版在 Coval 测试中 TTFA P50 为 216ms，比上一版快 170ms；同时在 Gradium 自建的 500 条「高难文本」测试集中取得 81.0% 通过率，覆盖电话号码、邮箱、IBAN、订单号、日期等容易读错的内容，无需开发者提前做文本改写或额外规范化。

延迟不仅更低，也更稳定： 480 次测试中 TTFA 的 P75-P25 区间只有 30ms；相比之下，Cartesia Sonic 3.6 的中位数为 454ms，区间为 165ms。
重点优化 Voice Agent 里的结构化信息朗读： 评测覆盖英语、德语、法语、西班牙语和葡萄牙语共 500 条文本；Gradium 通过率 81.0%，高于 Cartesia Sonic 3.6 的 75.1%、ElevenLabs v3 Conversational 的 65.4%、Inworld Realtime TTS-2 的 61.5% 和 Fish Audio S2.1 Pro 的 49.5%。
不再要求开发者手工做文本规范化： 模型会自行判断金额、电话号码、邮箱和参考编号应该如何发音，Studio 与生产 API 也走同一套输入链路，避免 Demo 和线上效果不一致。

https://gradium.ai/blog/gradium-tts-latency-and-accuracy

5、对话式 AI 公司 Sesame 开源语音轮次评测基准 TurnBench：测试 14 套系统后发现，没有一个能同时做到「快、准、少误触」

对话式 AI 公司 Sesame 发布并开源 TurnBench，用来专门评估 Voice Agent 在对话中什么时候该说、什么时候该等、什么时候该被打断。相比只测 VAD 或「用户是否说完」，TurnBench 把真实对话里的轮次变化拆成结束发言、打断、附和和句中停顿等事件，并同时衡量召回率、误触率和决策延迟；官方还开放了排行榜、对话可视化和开发集自助评分。

数据集专门为轮次交互而录制： 包含约 30 小时双通道英语对话、154 段会话、106 名配音员，覆盖闲聊、任务协作、教学、争论、叙事等 6 类场景；另提供 104 小时训练集。
不只看「识别对不对」，还看「什么时候决定」： EOT 任务会处罚把句中停顿误判成说完，打断任务则会处罚把「嗯嗯」「对」等附和声误判成真正抢话，并记录 P10/P50/P90 决策延迟。
14 套系统实测暴露出明显速度—准确率权衡： VAP 在 EOT 和打断两项中表现领先，但打断决策接近 1 秒；部分约 200ms 就能响应的系统则更容易误触。Sesame 的结论是，目前还没有系统能同时做到低延迟、低误报和高召回。
传统 VAD 远远不够： 简单能量 VAD 虽然响应很快，但很容易把停顿、附和或背景声音当成轮次变化，说明 Voice Agent 的轮次判断需要结合语音韵律、语义和上下文，而不只是检测「有没有声音」。

https://www.sesame.com/blog/turnbench

02 有亮点的产品

1、前 Bose、依视路陆逊梯卡高管创立 AI 助听眼镜公司 Legato：完成 1200 万美元种子轮，嘈杂环境语音清晰度提升 40%

听力科技初创 Legato 完成 1200 万美元种子轮融资，并首次公开 AI 助听眼镜 Legato Frames。产品面向轻度至中度听力损失人群，将助听能力直接集成进日常眼镜：AI 实时区分背景噪音与人声，只增强语音信号，公司称在嘈杂环境下的语音清晰度相比传统助听器提升 40%；开放式耳部设计配合双扬声器定向传声，续航最长 16 小时，预计 2026 年秋季上市。

核心团队来自 Bose 与依视路陆逊梯卡： 创始人 Mehul Trivedi 曾领导 Bose Frames 项目，后在依视路陆逊梯卡参与 Meta Ray-Ban 智能眼镜业务；联合创始人 Steve Romine 曾负责 Bose 助听器部门，后任 Audicus COO。
路线不同于传统定向助听器： Legato 不只是把麦克风朝向某个方向，而是利用 AI 实时做「人声 / 环境噪音」分离，再针对语音进行增强，重点解决餐厅等复杂声场中的听清问题。
把助听器做成普通眼镜形态： 团队自研声学系统、信号处理栈和机械结构，希望降低传统助听设备在成本、佩戴不适和医疗器械外观上的使用门槛。

（@AING 硬迹）

2、日本 franky 推出可穿戴 AI 日志设备 Mori：自动检测对话并记录，把一天整理成个人日志

日本公司 franky 推出可穿戴 AI 日志设备 Mori，用户佩戴后无需每次手动开启录音，设备检测到说话即可自动开始记录，再由 AI 完成转写、分类和总结，把工作交流、朋友聊天、旅行感想和临时想法整理成一段段可回顾的记录，并在每天晚上进一步汇总成个人日志。

从「手动录音」改成自动捕捉对话： Mori 支持语音自动触发，无需每次掏出手机点击录制；设备可连续录音 24 小时以上，待机超过 7 天，并提供 30 小时以上的加密本地存储，重新连接蓝牙后可自动同步。
不只做转写，还会重新组织一天： App 会把内容整理成时间线、摘要和个人日志，并从对话中提炼关键信息、待办事项和个人感悟；用户还可以基于这些长期记录继续向 AI 提问。
设备支持多种佩戴方式： 可作为手表、夹扣或项链佩戴，并通过双麦克风、波束成形和降噪来改善嘈杂环境中的收音。
强调录音隐私： 音频会在设备端加密，官方称完成转写后删除，也不会用于训练 AI；同时提供一键静音，用户可随时停止记录。

Mori 已开放购买，首发优惠为 399 美元，包含设备、1 年无限量订阅和磁吸表带。

https://mori.to/

https://x.com/yuakasaka/status/2094209288038469769

(@yuakasaka@X)

3、开发者打造「会回信」的手写 AI 笔记本：在页面上写字，Claude 直接在旁边批注、讨论和出题

独立开发者 tokentrillionaire 基于 Daylight DC-1 护眼平板，打造了一款创新的手写 AI 学习应用。

在交互体验上，用户可以像使用实体笔记本一样随手手写提问，Claude 则会在页面的合适位置以统一的手写风格「落笔作答」；阅读 PDF 或电子书时，圈画重点即可让 Claude 即时生成笔记、展开探讨，甚至根据材料现场出题测评。

技术实现也颇具巧思：应用没有采用传统的全屏截图传输方案，而是仅上传产生变动的笔迹向量数据，交由模型判断「回复内容与落笔坐标」，最终在本地渲染呈现。配合 Prompt 缓存技术，单轮交互成本仅需几美分。

该应用目前主要基于 DC-1 开发，但已兼容支持手写笔的 Android 平板，iPad 版本也在移植中。

https://www.reddit.com/r/ClaudeAI/comments/1vxqbzs/i_built_a_handwriting_notebook_app_where_claude/

(@tokentrillionaire@Reddit)

03 有态度的观点

1、💡 陈沁：AI 正在拆散岗位分工，经验者接手更多年轻人原有任务

脉策科技首席经济学家陈沁依据截至 2026 年 8 月的 7.4 亿条招聘数据，观察大模型进入工作场景后的岗位变化。他指出，越容易被大模型加速的职业，市场需求下降越明显；低工资、低经验的年轻人受到的冲击更大，有经验的中高职位需求则相对稳定。

陈沁认为，岗位减少不等于任务消失。编程、产品设计、测试和客户沟通等职责开始被重新组合，原本集中在某个职业里的任务也被分散给更多岗位。例如，程序员要参与产品和测试，产品经理、数据分析师甚至 HR 也开始承担编程任务。

招聘数据还显示，新的任务组合更强调现场操作、具身手艺、标准流程和出错后果。公司组织趋于扁平后，一部分年轻人的入口岗位消失，职场中坚借助大模型接过这些任务，同时需要处理更多种类的工作并承担更大责任。

陈沁测算，2026 年招聘需求因大模型应用减少 5.2%，另有 18.6% 的岗位任务组合已与三年前完全不同。他的核心判断是，大模型降低了学习和切换任务的成本，企业把工作拆给多名专业人员的收益随之下降。

数字生产领域开始出现一人完成多道工序的「鲁滨逊」式工作者，但这种模式仍依赖稳定的电力、网络和算力，也尚未扩展到全部行业。他建议先从招聘需求和任务重组这些可观察变化出发，不急于把局部现象推演成统一结论。

（@APPSO）

写在最后：

我们欢迎更多的小伙伴参与 「RTE 开发者日报」 内容的共创，感兴趣的朋友请通过开发者社区或公众号留言联系，记得报暗号「共创」。

作者提示：个人观点，仅供参考

测试之家社区

LLMCase-V4

技术实现说明（培训教材）

00 工程总览与最小链路

01 数据导入：docx 到 markdown

02 文本切块：从文档到提取单元

03 实体提取：文本到功能实体图（本工程特化）

04 向量嵌入

05 向量存储

06 检索前处理

07 索引优化（拟，后续调整）

08 检索后处理

09 响应生成：测试要点与用例

10 系统评估

11 高级机制（拟，后续调整）

附录 A：复用依赖地图（拟）

编写进度

基于 WebUSB 与 CDP：在浏览器端实现 Android 设备通信与无证书抓包实践

基于 WebUSB 与 CDP：在浏览器端实现 Android 设备通信与无证书抓包实践

1. 底层通信：基于 WebUSB 的 ADB 协议握手

1.1 设备筛选与接口声明

1.2 ADB 协议包封装与 RSA 鉴权

2. 移动端网络抓包：基于 CDP 绕过根证书限制

2.1 端口映射与 DevTools 连接

2.2 注入网络监听指令

3. 证据链对齐：环形缓冲区（Ring Buffer）在回捞中的应用

4. 架构对比与权衡思考

5. 总结

Build in public · 过程决策、踩坑与解法

来到新公司后产生了迷茫

AI 提效的一个典型阶段 -- 数字分身

前言

为什么需要数字分身

结尾

简单项目 AI 随便写，复杂度一上来就顾头不顾尾

这个"病"长什么样

我的真实案例

第一轮：节点 2 优化完成 ✅

第二轮：节点 3 崩了

第三轮：节点 4 崩了

第四轮：回头一看，节点 1 也歪了

为什么 AI 会这样？

这种病的代价

怎么治

方法 1：你当架构师，AI 当模块工

方法 2：契约先行，schema 就是法律

方法 3：每次改动，先逼它做影响面分析

方法 4：黄金用例端到端回归，不接受单点"已修复"

方法 5：连锁两轮就停手，回滚重来

一句话总结

Thinking Machines Lab 洽谈 10 亿美元融资，估值 400 亿美元；微软发布 MAI-Transcribe-2，1 小时音频 10 秒转完丨日报

01 有话题的技术

02 有亮点的产品

03 有态度的观点

04 社区黑板报

第一周：从 0 写出 v0.1.0，回归测试 90 项全过（附架构图）

1/4 · 开场 + 为什么做

2/4 · 架构图 + 产品链接

3/4 · 第一周进度盘点

4/4 · G1 关口通过

之前做的几个东西（ai 远程自动化、模型标注平台、多 agent cli 工作台等等）开源给大家吧 可以的话给个星星

金融科技公司 招聘 测试工程师助理 10-15K

公司从零开始推自动化测试，如何落地？

一、先和老板对齐，自动化到底要解决什么

二、一张表，一条循环，一套规矩

三、2026 年了，这套玩法要打个补丁

单纯测试分享交流，有愿意的吗

定档！从对话式 AI 到实时智能，Voice Agent Builder 的年度春晚 iRTE2026 来了丨 10 月 23-24 日，北京见！

微软 VibeVoice 新增开源流式 ASR 模型，边听边识别「谁说了什么」；fal 开源 H3 Max 实时教育系统，语音讲解同步生成教学动画丨日报

01 有话题的技术

02 有亮点的产品

03 有态度的观点

04 社区黑板报

九大测试门禁，拦住发布风险

安全优先

采用微服务架构

尽早提交、频繁提交并减少分支

生产环境只能通过一种路径部署

尽量保持生产与测试环境一致

明确测什么、何时测、在哪里测

之前做的几个东西（ai 远程自动化、模型标注平台、多 agent cli 工作台等等）开源给大家吧可以的话给个星星

金融科技公司招聘测试工程师助理 10-15K