测试之家社区

精准测试之 AI 探索

000xiaoxiao000 — Sun, 19 Apr 2026 16:30:56 +0800

精准测试与 AI 结合的技术探索

摘要

本文围绕一套精准测试平台，系统介绍精准测试与 AI 结合的设计思路、平台能力与工程实现路径。文章首先讨论传统黑盒测试与白盒覆盖率分析在可追溯性、可解释性和回归决策上的局限，再说明精准测试如何通过运行时探针采集、调用链追踪、静态结构分析与版本比对，建立测试场景与代码逻辑之间的双向追溯关系。在此基础上，进一步分析 AI 如何参与缺陷诊断、性能分析、测试推荐和代码关系融合，从而让平台从 “可观测” 演进到 “可理解、可建议、可协同”。文章还结合系统快照、增量覆盖率、变更影响分析等真实平台能力，给出典型应用场景，并讨论当前方案的边界、挑战与后续演进方向。

关键词

精准测试、运行时探针、调用链追踪、覆盖率分析、版本比对、影响范围分析、测试推荐、缺陷诊断、AI 智能体、LangChain4j

前言：为什么是 “精准测试 + AI”

在软件研发过程中，测试团队经常面临几个长期存在的问题：

测试执行了很多轮，但很难准确回答 “这次到底覆盖到了哪些关键代码逻辑”；
代码改动之后，只能依赖经验判断需要回归哪些场景，容易出现 “全量回归成本高、选择性回归又怕漏测” 的矛盾；
覆盖率工具给出了一串数字，但无法解释 “哪些业务场景覆盖了这些代码”“为什么某些代码一直没有覆盖”；
出现线上缺陷或性能退化时，调用链、日志、源码、版本变化之间缺少统一视角，定位高度依赖专家经验；
平台沉淀了大量测试与运行数据，但没有真正转化为智能建议和决策支持。

精准测试解决的是 “测试与代码之间看不见的关系” 问题，AI 解决的是 “数据有了之后如何理解、分析和建议” 的问题。

因此，本文讨论的重点，不只是把测试数据采集出来，更是希望构建一套从运行时采集、调用链追踪、覆盖率计算、版本变更分析，到 AI 智能诊断、测试推荐与多轮交互的完整闭环，让平台从 “能看见” 升级到 “能理解、能分析、能建议”。

一句话概括：

精准测试与 AI 的结合，核心是把精准测试的数据能力与 AI 的推理能力结合起来，形成面向研发测试协同的智能测试分析平台。

一、什么是精准测试

精准测试是一套计算机测试辅助分析系统，其核心在于建立测试用例与代码逻辑的双向追溯关系，是一种灰盒测试模式。

传统测试中：

黑盒测试关注功能是否正确，但无法感知代码内部到底执行了哪些逻辑；
白盒测试可以统计覆盖率，但通常只停留在数字层面，无法回答 “这段代码是由哪个业务场景跑到的”；
精准测试则是在两者之间 “穿线”，把测试场景、调用链、代码行、分支路径串起来，让测试执行结果具备可追溯性、可解释性和可分析性。

从理念上看，精准测试要解决的不是 “有没有覆盖率”，而是：

哪个测试场景覆盖了哪个类、哪个方法、哪一行、哪个分支；
哪些改动代码已经被历史测试覆盖过；
哪些变更没有被任何已有测试触达；
哪些代码虽然覆盖率高，但实际关键路径仍存在风险；
哪些场景应当优先回归，哪些可以复用已有测试结果。

它通过运行时探针以无侵入方式采集运行态数据，结合静态结构分析与版本差异比对，并在此基础上叠加 AI 分析能力，实现从：

测试场景 → 调用链 → 代码行 / 分支 的正向追踪；
代码变更 → 影响范围 → 关联测试场景 的反向追踪。

二、为什么精准测试还要加 AI

如果说精准测试解决的是 “数据从哪里来、关系如何建立”，那么 AI 解决的就是 “这些数据如何被理解和使用”。

在没有 AI 的情况下，平台可以告诉用户：

覆盖率是多少；
哪些方法被执行过；
哪些调用链存在差异；
哪些类被变更了。

但在真实工作中，测试人员和研发人员真正关心的是：

这次改动最值得优先回归哪些场景？
为什么这个接口新版本变慢了？
正常请求和异常请求的根因差异在哪里？
哪些低覆盖代码风险最高？
哪些测试场景应该新增、补测、删减或合并？

这些问题都不是简单检索能回答的，而是需要在多维数据基础上做理解、推理和归纳。AI 恰好适合承担这一层任务。

因此，引入 AI，不是为了 “做一个聊天窗口”，而是为了把平台中原本分散的测试、代码、链路、覆盖率、版本、性能等数据连接起来，形成智能分析和建议能力。

AI 在平台中的四层角色

1）理解层

AI 从平台中读取和理解结构化数据：

系统快照
调用链节点
类 / 方法 / 行 / 分支覆盖率
版本 Diff
静态代码关系
用例、场景、缺陷反馈

2）分析层

AI 基于这些数据做归纳和推理：

正常 / 异常链路差异分析
覆盖率盲区识别
性能回归判断
缺陷根因推断
变更影响评估

3）建议层

AI 把分析结果转换成可执行建议：

补测哪些场景
优先回归哪些接口
哪些类风险高
哪些节点最可疑
哪些代码需要重点关注

4）交互层

AI 通过智能问答、多轮对话、工具调用，把复杂的平台能力转成自然语言交互入口，让测试和研发人员以更低门槛使用平台。

三、技术发展与平台定位

历史演进

精准测试在中国的发展经历了几个阶段：

2014 年：在国际软件测试大会上首次发布，当时叫 “穿线测试”（Threading Test），建立了用例与代码的追溯关系；
2017-2019 年：精准测试白皮书逐渐形成完整体系，覆盖示波器、双向追溯、智能回归、覆盖率分析、缺陷定位等能力；
2020 年后：互联网公司开始自研精准测试平台，覆盖范围从单元测试扩展到接口级、链路级和系统级；
当前阶段：随着 AI 技术成熟，精准测试进入智能化阶段，从 “可观测、可追溯” 升级为 “可分析、可推荐、可解释”。

平台定位

这类平台在精准测试领域的定位，不只是搭建一套链路和覆盖率平台，而是围绕 “精准测试 + AI” 做纵深增强：

请求级覆盖率：精确到 “哪个测试场景覆盖了哪个方法的哪一行、哪一条分支路径”；
分支路径级覆盖：不仅有简单的 true / false 分支统计，还支持对分支实际走向的不同路径进行更细粒度的追踪；
双向追溯：既能从测试场景追到代码，也能从代码变更反查影响的测试场景；
AI 智能分析：从被动展示数据，升级为主动分析问题、推荐测试、解释变化；
测试智能闭环：形成 “采集—沉淀—分析—推荐—验证—再沉淀” 的持续优化循环。

四、平台总体介绍

这是一类围绕 Java 应用运行态观测、调用链追踪、覆盖率分析、版本差异比对与 AI 辅助诊断构建的测试与分析平台。

项目通常主要由两部分组成：

采集端：通过 JavaAgent 注入目标应用，采集运行时链路、代码栈以及各类中间件交互数据；
服务端：负责接收采集数据、生成系统快照、展示覆盖率报告、进行版本比对，并提供 AI 能力扩展。

典型平台结构

精准测试平台
├── 采集端                # 目标系统探针/采集端
├── 服务端                # 平台服务端聚合工程
│   ├── 智能分析模块      # 大模型集成 / 智能工具 / 分析编排
│   └── Web 模块          # 快照、覆盖率、版本、资源、搜索等核心业务
└── README.md

平台总体架构

平台核心目标

对目标 Java 系统进行无侵入运行态采集；
沉淀系统快照、调用链路与源码结构信息；
生成全量 / 增量覆盖率报告，支持趋势、对比、树形分析、源码着色；
支持版本比对、资源缓存、报告导出；
在服务端叠加 AI 能力，辅助代码理解、缺陷排查、性能分析和测试推荐。

五、平台核心能力地图

为了更清楚地理解平台能力，可以将其分为两大能力域：精准测试能力 与 AI 智能能力。

传统测试、精准测试与智能化增强对比

平台能力地图

5.1 精准测试能力

1）运行时调用链采集

通过运行时探针以无侵入方式接入目标应用，采集：

Web 请求入口
数据库调用
缓存访问
服务间远程调用
消息队列链路
服务内部方法调用及其代码执行关系

2）代码覆盖率分析

支持：

类级覆盖率
方法级覆盖率
行级覆盖率
分支路径级覆盖率
圈复杂度统计
源码着色

3）系统快照与测试场景沉淀

每次真实请求、接口调试或测试执行之后，可沉淀为系统快照，保存：

系统标识信息
版本信息
调用链拓扑
代码覆盖信息
SQL / 中间件调用细节

4）版本比对与变更影响分析

支持：

基于 Jar / War 的字节码比对
基于 Git Commit 的源码 Diff
识别变更类、变更方法、变更行
追溯受影响的测试场景与接口

5）全量 / 增量覆盖率报告

支持：

全量覆盖率生成
增量覆盖率生成
覆盖率趋势分析
版本间对比
Excel 导出

5.2 AI 智能能力

1）缺陷诊断

对正常与异常调用链进行智能比对，分析差异节点、传播路径与可能根因。

2）性能分析

从接口、链路、节点多个维度分析耗时变化和性能瓶颈。

3）测试推荐

根据覆盖率盲区、代码变更和调用关系，推荐补测场景。

4）代码关系融合分析

将静态代码关系与动态调用链融合，帮助理解 “定义关系” 和 “实际运行关系” 的差异。

5）AI 智能问答

面向测试和研发场景，支持围绕快照、覆盖率、代码关系、缺陷和性能问题的智能问答。

6）多模型动态调度与记忆管理

根据任务复杂度和上下文长度动态选择模型，并支持渐进式摘要压缩与多轮对话记忆。

六、平台工作原理

6.1 数据采集：Agent 无侵入接入目标系统

这一部分解决的是 “目标系统运行了什么、测试到底触达了什么” 难以被统一采集的问题。

平台使用 JavaAgent 方式接入目标应用，通过类加载期插桩实现对运行时行为的采集。

平台涉及两类字节码处理技术：

Javassist：用于协议层和入口层增强，适合快速织入基于 Java 语义的代理逻辑；
ASM：用于行级与分支路径级探针注入，便于对覆盖率采集做到更细粒度控制。

6.2 为什么同时使用 Javassist 和 ASM

二者各有分工：

Javassist 更适合做方法入口 / 出口增强，例如记录 HTTP 请求参数、SQL 语句和服务调用信息；
ASM 更适合做底层、细粒度的覆盖率探针注入，例如为每一行代码、每一个条件跳转点插入探针。

通过两者协同，平台既能看见 “调用了什么”，又能精确记录 “执行到了哪里”。

6.3 精准覆盖率的关键改进

这一部分解决的是 “传统覆盖率工具能统计数字，但难以支撑复杂业务系统的精准评估” 问题。

相比传统覆盖率工具，平台针对复杂业务系统中常见误差问题做了改进：

分母完整：在类加载阶段和系统启动阶段扫描 classpath，确保所有类、方法、代码行和分支结构都被纳入统计口径；
请求级隔离：将每次请求的覆盖率与唯一调用标识一一绑定，避免不同请求之间的数据混杂；
分支路径级追踪：通过区分分支最终进入的不同目标路径，避免覆盖率分析只停留在粗粒度的 true / false 统计层面；
MC/DC 条件级分析基础：对每个条件跳转分别记录命中与未命中情况，为更高阶的条件覆盖分析打基础；
异步线程上下文透传：在异步线程池场景下保持链路与覆盖率采集的连续性。

6.4 从采集到分析的闭环

平台形成如下闭环：

运行时采集目标系统请求和调用链；
结合静态结构信息生成覆盖率数据；
将链路、快照、报告、源码结构沉淀到平台；
结合 Git 版本比对识别变更与影响；
通过 AI 对快照、链路、覆盖率和 Diff 数据进行智能分析；
输出测试建议、缺陷诊断和性能结论；
测试再次执行，形成新的系统快照和报告，完成数据闭环。

测试场景、调用链与代码覆盖的双向追溯

七、平台重点功能介绍

7.1 监控台

监控台是平台采集与观察的实时入口，主要解决 “运行时行为不可见、测试执行过程难复盘” 的问题。

1）实时监控

通过 HTTP 接口实时获取协议、调用链和代码相关信息，展示：

请求 URL、参数、状态码、耗时；
SQL 语句与耗时；
Redis 命令与 Key；
Dubbo / Feign / MQ 调用信息；
代码堆栈与执行方法路径。

2）我的快照

用户可以把实时链路保存为 “我的快照”，用于后续分析和对比。

3）调用链与链路分析可视化

平台同时提供：

服务与中间件层的拓扑图；
方法与方法之间的代码关系图谱；
节点级查看方法名、执行代码行数、覆盖率和圈复杂度。

4）代码覆盖率查看

对于某次快照，可查看：

覆盖到的类与方法；
行级覆盖情况；
方法级覆盖率；
分支路径级覆盖情况。

7.2 应用中心

应用中心主要解决 “快照、版本、覆盖率、影响分析分散在不同维度，难以形成统一工程视角” 的问题。

1）在线应用

展示已接入 Agent 的应用列表及运行状态。

2）系统快照

系统快照用于沉淀一次真实请求或测试执行的全链路信息，包括：

基本信息：traceId、版本、创建时间；
流程图：服务与中间件调用拓扑；
堆栈列表：链路中的代码与协议节点；
详情：SQL、数据库、HTTP 节点等扩展信息。

3）版本比对

支持两种方式：

字节码级比对：上传 Jar / War 包，通过 ASM 解析对比类 / 方法变化；
源码级比对：基于 Git Commit，使用 Git 差异计算两个版本之间的变更，定位到具体的变更行号。

比对完成后，可查看：

变更项
影响项
影响快照 / 影响用例
比对日志

版本变更影响分析

4）覆盖率中心

全量覆盖率

统计当前版本下所有系统快照覆盖到的代码，生成完整报告。

增量覆盖率

只统计 Git Diff 范围内的变更代码覆盖情况，帮助聚焦本次迭代风险。

趋势与对比

支持：

覆盖率趋势图
版本间对比
报告继承与增量处理

源码着色

平台从 Git 仓库下载源码文件，并结合覆盖率明细对源码逐行着色：

🟢 绿色：已覆盖
🔴 红色：未覆盖
🟡 黄色：部分覆盖

八、AI 功能重点介绍

AI 模块不是平台边缘功能，而是贯穿平台 “理解、分析、建议” 的智能中枢，主要解决 “数据已经可见，但问题仍难解释、建议仍依赖经验” 的问题。

AI 在平台中的角色分层

8.1 缺陷诊断

AI 会对正常请求与异常请求的调用链进行对比，并从以下维度分析差异：

新增节点
缺失节点
状态变化
耗时变化

再按照以下结构输出结果：

首次异常位置
异常传播路径
性能突变点
新增 / 缺失节点
最终根因推断
修复建议

AI 缺陷诊断流程

这使得缺陷分析从 “人工看链路” 提升到 “平台辅助解释链路”。

8.2 性能分析

AI 根据调用链和时间区间统计：

接口平均耗时
P90 / P95 / P99
错误率
节点级耗时分布
性能回归阈值变化

当检测到如下情况时，可触发性能回归判断：

平均耗时增幅超过阈值
P90 显著上升
错误率明显增加

并进一步指出：

变慢的是哪个节点；
是本地逻辑、数据库、还是下游依赖；
哪个版本开始出现变化。

8.3 测试推荐

测试推荐解决的是 “知道哪里没覆盖，但不知道下一步该怎么测” 的问题。

AI 综合以下信息生成测试建议：

覆盖率盲区
低覆盖高复杂度类
代码变更范围
调用链实际运行关系
历史系统快照

推荐的测试场景可覆盖：

正常场景
边界场景
异常场景
权限场景
并发场景

AI 测试推荐闭环

这样测试推荐不再只是 “凭经验补几个 case”，而是建立在真实代码和运行行为之上的智能建议。

8.4 代码关系融合分析

AI 将静态代码关系和动态调用链关系融合到一个视图中：

静态维度：谁调用谁、谁依赖谁；
动态维度：运行时到底有没有执行到；
差异集合：定义了但从未实际跑到的调用关系；
风险识别：代码结构复杂但动态覆盖不足的热点区域。

8.5 多模型动态调度

平台中的 AI Agent 并不依赖单一模型，而是根据任务类型做动态切换：

SIMPLE：轻量问答
COMPLEX：复杂分析
CODE：代码理解
VISION：图谱理解
LONG_CONTEXT：长上下文推理

同时具备：

模型故障自动切换
Tool Calling 多层兜底
不同模型能力的适配策略

8.6 多轮对话上下文管理

面向测试领域，AI 模块支持：

意图识别：覆盖率、调用链、性能、缺陷、版本等主题识别；
意图追踪：记录用户关注点的演变；
摘要压缩：保留长期对话核心信息；
多轮衔接：支持围绕一个问题持续追问与细化。

这让 AI 不只是一次性回答，而更像测试人员的长期协作助手。

九、典型场景举例

下面用几个更贴近真实工作的场景，说明平台中的精准测试与 AI 是如何协同发挥作用的。

场景一：版本上线前的精准回归

问题

某次迭代中，订单服务修改了折扣计算和库存校验逻辑。测试团队知道 “代码改了”，但不知道该优先回归哪些业务场景。

平台处理过程

使用 Git Diff 比较两个 Commit；
平台识别变更类、变更方法和变更代码行；
从历史系统快照中反查哪些测试场景和接口触达过这些代码；
生成 “影响范围 + 影响快照 + 影响接口” 的可视化报告；
AI 结合变更点和覆盖率盲区，推荐还应补充的边界与异常测试场景。

输出示例

已覆盖历史场景：下单、优惠券校验、库存预扣减；
高风险未充分覆盖场景：并发下单、库存不足、优惠券叠加冲突；
建议优先回归接口：订单确认、库存锁定、优惠券结算。

价值

避免全量回归过重；
避免选择性回归漏掉关键路径；
回归范围从 “经验判断” 变成 “数据支持 + AI 建议”。

场景二：线上缺陷快速定位

问题

同一个接口在测试环境正常、线上偶发异常，但异常难以稳定复现，研发排查成本很高。

平台处理过程

提取正常请求与异常请求的系统快照；
AI 对比两条调用链在节点、状态、耗时上的差异；
标识 “首次异常位置” 和 “异常传播路径”；
结合代码关系图谱分析可疑方法；
输出结构化根因分析结论。

输出示例

正常链路中存在缓存命中节点，异常链路缺失该节点；
异常链路新增一次下游库存服务重试调用；
某个 SQL 节点平均耗时从 30ms 上升至 450ms；
根因推断：缓存失效后触发库存表慢查询，进而导致接口超时。

价值

缩短故障定位路径；
让链路图不只是 “展示图”，而成为可解释的诊断依据；
降低对资深专家人工经验的依赖。

场景三：低覆盖高风险模块补测

问题

某模块覆盖率长期偏低，但类的圈复杂度很高，测试团队知道有风险，却不知道优先补哪些用例。

平台处理过程

平台识别低覆盖率且高复杂度的类；
结合调用链关系找到关键入口接口；
分析该模块已覆盖与未覆盖的代码区域；
AI 自动生成补测建议，按正常 / 边界 / 异常 / 权限 / 并发分类给出测试场景。

输出示例

正常场景：标准参数下的正常下单流程；
边界场景：库存为 0、优惠额度为 0、数量为 1 的边界校验；
异常场景：库存服务超时、参数缺失、非法折扣值；
权限场景：无权限账号调用；
并发场景：多个用户同时抢购同一商品。

价值

覆盖率报告变成测试设计输入；
把 “看数字” 变成 “补场景”；
让测试策略更聚焦高风险区域。

场景四：性能回归分析

问题

版本发布后，核心接口平均耗时上升，但很难快速判断是本地代码、数据库还是下游服务导致。

平台处理过程

对比发布前后两个时间窗口的系统快照和链路统计；
AI 分析 avg / p90 / errRate 的变化；
找出耗时突增节点；
结合版本变更点和调用链差异给出原因判断。

输出示例

平均耗时上升 28%；
P90 上升 42%；
错误率变化不大；
新版本新增一次规则引擎调用；
可疑瓶颈节点：规则引擎远程调用、订单明细 SQL 查询。

价值

把性能问题从 “经验排查” 变成 “结构化对比”；
更快判断是代码问题、依赖问题还是配置问题；
为性能优化给出直接线索。

十、平台核心价值总结

从平台能力角度看，其价值主要体现在四个方面。

多角色用户价值

1）让测试过程可追溯

平台把测试场景、调用链、代码执行路径、覆盖率结果连接起来，使测试过程从 “结果可见” 升级到 “过程可追溯”。

2）让代码变更可评估

平台能把版本变更与历史系统快照关联起来，识别影响范围和回归重点，使代码变化从 “看 Git Diff” 升级到 “看测试影响”。

3）让测试决策可智能化

AI 结合覆盖率盲区、代码变更和调用关系，自动推荐场景和优先级，使测试决策从 “拍脑袋” 升级到 “有依据的建议”。

4）让缺陷分析更高效

AI 基于正常 / 异常链路和性能变化做根因推断，使问题排查从 “人工读链路” 升级到 “平台辅助解释链路”。

可以把平台的价值概括为：

让测试从 “执行行为” 变成 “数据资产”，再从 “数据资产” 变成 “智能能力”。

十一、适用对象

这类平台并不是只服务测试团队，而是面向多角色协同的平台。

测试工程师

看覆盖率、找盲区；
做测试场景补充；
做精准回归范围筛选；
借助 AI 提升测试设计效率。

开发工程师

看调用链与代码关系；
分析缺陷根因；
理解版本变更的影响；
快速定位性能瓶颈和异常传播路径。

测试负责人 / 质量负责人

看覆盖率趋势；
看版本风险；
看回归效率；
看平台沉淀是否真正形成质量治理能力。

架构师 / 技术管理者

看平台是否建立统一的测试与运行数据底座；
看是否形成从观测到决策的闭环；
看 AI 是否真正增强了研发测试协同效率。

十二、与传统方案的区别

在技术实践中，很多团队会自然提出一个问题：既然已经有 JaCoCo、APM、日志平台、链路追踪系统，为什么还需要这样一套精准测试平台？

这个问题非常关键。因为其价值，并不在于替代单一工具，而在于把多个本来割裂的能力组合成 “测试场景—调用链—代码逻辑—版本变更—AI 分析” 的统一闭环。

11.1 与传统覆盖率工具的区别

传统覆盖率工具（如 JaCoCo）更擅长回答：

某个测试执行后，哪些类、方法、代码行被跑到了；
当前工程总体覆盖率是多少。

但它通常不擅长回答：

这些覆盖率是由哪个真实业务场景产生的；
某次版本变更具体影响了哪些测试场景；
哪些未覆盖代码是真正高风险区域；
哪些场景应该优先补测。

换句话说，传统覆盖率工具更偏 “代码统计工具”，而这类平台更偏 “测试追溯与决策支持平台”。

对比维度	传统覆盖率工具	精准测试平台
类 / 方法 / 行覆盖率	支持	支持
分支路径级分析	一般较粗	支持更细粒度路径追踪
请求级覆盖率隔离	通常不支持	支持
测试场景到代码追溯	弱	强
代码变更到测试场景反查	通常不支持	支持
覆盖率结果与业务链路结合	弱	强
AI 补测建议	不支持	支持

11.2 与普通 APM / 可观测平台的区别

APM 和链路追踪平台更擅长回答：

某个接口慢不慢；
哪个调用节点耗时高；
哪个依赖服务出错了；
当前请求链路长什么样。

但它们通常不关心：

这个请求到底覆盖了哪些代码行和分支；
当前链路对应的代码变更范围是什么；
哪些测试场景已经触达了这段代码；
如何把观测结果直接转成回归测试建议。

因此，普通可观测平台更偏 “运行态诊断”，而这类平台更强调 “运行态诊断 + 测试追溯 + 变更影响分析 + AI 决策建议” 的联动。

对比维度	普通 APM / 可观测平台	精准测试平台
请求链路追踪	支持	支持
SQL / Redis / RPC 观测	支持	支持
代码覆盖率分析	通常不支持	支持
变更影响分析	通常不支持	支持
快照沉淀与复盘	部分支持	强化支持
回归场景推荐	不支持	支持
测试与研发协同分析	弱	强

11.3 与 “覆盖率 + APM + 日志平台拼装方案” 的区别

理论上，一个团队也可以把以下工具拼装起来：

JaCoCo 负责覆盖率；
SkyWalking / Zipkin / Pinpoint / APM 负责链路追踪；
ELK 负责日志检索；
Git 平台负责查看 Diff。

这类拼装方案当然有价值，但在实际落地时通常会遇到两个问题：

1）数据之间没有天然主键

覆盖率数字是一套口径；
trace 是另一套口径；
Git Diff 是第三套口径；
测试场景管理又是第四套口径。

这些数据之间往往缺少统一关联键，导致团队只能依赖人工拼接理解。

2）无法形成可直接使用的测试决策闭环

即使链路、日志、Diff、覆盖率都能分别看到，也仍然很难自动回答：

本次最该回归哪些场景；
哪些代码虽已覆盖但仍高风险；
哪些问题是变更引起的；
哪些缺陷已经能够从链路和覆盖率差异中推断根因。

而这类平台的重点，正是把这些数据统一沉淀到平台内部，通过快照、覆盖率、变更、调用链和 AI 工具形成联动分析。

11.4 平台的核心技术辨识度

其独特性不在于单点能力 “绝对新”，而在于以下几个能力被统一打通：

请求级覆盖率：把覆盖率与 traceId / 场景绑定，而不是只保留全局统计数字；
双向追溯：既能从测试场景追代码，也能从代码变更反查场景；
版本影响分析：把 Git Diff、字节码差异和历史快照关联起来；
动态链路与静态结构融合：同时理解 “定义关系” 和 “运行关系”；
AI 智能分析：在已有精准测试数据底座之上做缺陷诊断、性能分析和测试推荐。

换句话说，如果说传统工具链回答的是 “局部问题”，那么这类平台更希望回答的是：

在一个真实版本演进过程中，哪些代码变了、哪些链路跑了、哪些场景覆盖了、哪些风险未消除，以及下一步最该怎么测。

十三、图示说明

为了让文章更适合技术传播与体系化表达，文中可以保留如下图示结构。

图 1：传统测试、精准测试、智能化增强对比

建议表现：

黑盒测试：只看结果；
白盒测试：只看覆盖率数字；
精准测试：把场景和代码串起来；
精准测试 + AI：在此基础上做分析、解释和推荐。

图 2：平台总体架构图

建议表现：

目标应用
JavaAgent
平台服务端
智能分析模块
Elasticsearch / Redis / Git
平台功能入口：快照、覆盖率、版本比对、智能分析

图 3：测试场景 → 调用链 → 代码覆盖的双向追溯图

建议表现：

一个测试场景触发 HTTP 请求；
经过服务调用、数据库、中间件；
回落到类 / 方法 / 行 / 分支；
再从变更代码反向追溯到历史测试场景。

图 4：版本变更影响分析图

建议表现：

Commit A → Commit B；
识别变更类 / 方法 / 行；
关联历史快照；
生成精准回归建议。

图 5：AI 缺陷诊断流程图

建议表现：

输入：正常链路 + 异常链路；
差异分析：新增 / 缺失 / 耗时 / 状态；
推理：首次异常位置与传播路径；
输出：结论 + 修复建议。

图 6：AI 测试推荐闭环图

建议表现：

变更代码
覆盖率盲区
历史快照
调用关系
AI 推荐测试场景
执行后再沉淀新快照
持续迭代优化

十四、技术与实现补充说明

13.1 核心技术栈

领域	技术	用途
字节码插桩	Javassist	协议入口和方法代理拦截
字节码插桩	ASM	行级与分支级覆盖探针注入
链路追踪	ThreadLocal + InheritableThreadLocal	请求级上下文传递
版本比对	JGit + ASM	Git Diff 与字节码结构比对
数据存储	Elasticsearch	快照、链路、覆盖率、版本、源码结构信息
缓存与会话	Redis / Redisson	缓存、锁、会话支持
AI 分析	LangChain4j	LLM 接入、Agent 编排、工具调用

13.2 无损插桩思路

平台采用可理解为 SABI（SourceCode Analyzer ByteCode Instrumentation） 的模式：

观测与分析在源码结构维度：预先分析类、方法、行号、分支等结构；
插桩在字节码维度：探针注入为非常轻量的布尔赋值；
读取在运行时低开销完成：通过布尔数组记录覆盖情况，避免复杂同步和 IO。

13.3 数据架构

存储介质	用途
Elasticsearch	覆盖率报告、类覆盖率、系统快照、链路节点、静态源码信息、版本中心、用例中心
Redis	缓存、会话管理、分布式锁
Git 仓库	版本管理、Diff 计算、源码下载
本地文件系统	Git 仓库缓存、源码 ZIP 包、比对文件缓存

十五、当前挑战与边界

为了让文章更接近真实工程实践，需要明确指出当前方案的适用边界与挑战。

1）复杂异步链路的完整还原仍有挑战

平台已经支持基于 “线程上下文” 与上下文包装的链路透传，但在复杂线程切换、跨进程异步编排、多级消息回调等场景下，调用链完整还原仍然具有挑战性。

2）AI 分析质量依赖数据完整性

AI 的能力本质上建立在平台沉淀的数据质量之上。如果系统快照不完整、调用链采集不连续、版本信息不准确，AI 给出的分析和推荐也会受到限制。

3）测试推荐目前仍然属于辅助决策

AI 可以根据覆盖率、变更范围和调用关系给出推荐，但是否采纳、如何调整优先级，仍需要结合业务语义、测试策略与团队经验综合判断。

4）不同业务系统的接入复杂度并不完全相同

虽然 JavaAgent 方式本身是无侵入的，但不同团队的类加载器体系、中间件组合、自定义线程模型与部署模式不同，仍可能导致接入、配置和过滤规则存在差异。

5）覆盖率高并不等于风险低

平台可以精确说明 “哪些代码被跑到”，但无法天然保证 “测试断言是否有效”“业务规则是否完全正确”。因此精准测试与 AI 更适合做风险识别与决策支撑，而不是替代完整的测试设计。

十六、下一步的探索方向

“引入 AI” 不是给平台增加一个问答入口，而是代表平台演进方向的变化。下一步可以继续深入四个方向。

测试智能闭环图

1）从 “分析” 走向 “生成”

未来可以探索：

自动生成测试场景草案；
自动生成接口级测试数据建议；
自动生成缺陷复现步骤与修复说明草案；
自动生成覆盖率提升建议列表。

2）从 “推荐” 走向 “协同决策”

未来可以进一步支持：

基于版本风险自动排序测试任务；
根据历史缺陷分布调整回归优先级；
基于覆盖率、复杂度和变更范围给出上线风险提示；
面向测试负责人生成质量看板和行动建议。

3）从 “单次问答” 走向 “长期学习”

未来可通过反馈机制沉淀：

历史分析结果；
用户采纳与否；
测试推荐有效性；
常见问题模式与解决策略。

从而逐步构建测试领域的长期知识库与学习机制。

4）从 “平台工具” 走向 “测试智能体”

进一步的发展方向，是让 AI 不只是平台中的一个模块，而是成为测试人员和研发人员的智能协作助手：

理解用户问题；
自动调用覆盖率、快照、版本比对、代码关系等工具；
给出结构化结论；
在多轮对话中持续跟踪同一问题；
逐步参与测试分析、测试设计与回归决策。

结语

精准测试与 AI 的结合，并不是把 “精准测试” 和 “AI” 做简单叠加，而是在平台能力、数据结构和使用方式三个层面同时升级。

它所探索的，不只是：

如何采集调用链；
如何计算覆盖率；
如何比对版本差异；

更重要的是：

如何让测试过程变得可追溯；
如何让代码变更变得可评估；
如何让平台数据变得可理解；
如何让 AI 真正参与测试分析与决策。

最终，这类平台想要构建的是一条完整的测试智能闭环：

采集运行数据，沉淀测试资产，理解系统变化，分析质量风险，推荐测试动作，持续反馈优化。

这既是精准测试平台的升级方向，也是 “测试平台走向智能平台” 的一次探索。

从工程实现上看，这一探索已经可以在当前仓库中找到较清晰的落点：采集端负责运行时采集与覆盖率探针，服务端负责快照、版本、覆盖率与展示能力，智能分析模块负责分析、工具调用与上下文协同。也正因为这些模块已经具备相对独立的职责边界，这类平台才有机会在现有精准测试能力之上继续向 “测试智能体” 演进。

参考文献

中文参考

[1] 吴恩达.《Agentic AI：构建能够推理、使用工具并完成任务的智能体》. Available at: https://www.deeplearning.ai/

[2] 李宏毅.《生成式人工智能导论》. Available at: https://speech.ee.ntu.edu.tw/~hylee/genai/2024-spring.php

[3] 黄佳.《大模型应用开发：从 Prompt、RAG 到 Agent》. Available at: https://www.manning.com/books/ai-agents-and-applications

[4] 王树森.《从大语言模型到智能体：技术演进与系统设计》.

[5] 机器之心.《从 Prompt Engineering 到 Agent Engineering：大模型应用的工程化路径》. Available at: https://www.jiqizhixin.com/

[6] InfoQ 中文.《RAG、Tool Calling 与 Agent：大模型应用架构的三条主线》. Available at: https://www.infoq.cn/

英文参考

[7] Anthropic. Building Effective Agents. Available at: https://www.anthropic.com/engineering/building-effective-agents

[8] OpenAI. Prompt Engineering Guide. Available at: https://platform.openai.com/docs/guides/prompt-engineering

[9] Yao, S., Zhao, J., Yu, D., et al. ReAct: Synergizing Reasoning and Acting in Language Models. Available at: https://arxiv.org/abs/2210.03629

[10] Lewis, P., Perez, E., Piktus, A., et al. Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. Available at: https://arxiv.org/abs/2005.11401

【马牛骡】鞍子和鞭子

Fhaohaizi — Sun, 19 Apr 2026 16:30:11 +0800

马：鞍是装饰，鞭是话术

风前位一向光亮。马站在高阈廊道上，鞍子扣得合身却轻，更像一种被承认的标识，而不是需要承受的重量。它很少真正踏入主磨道，却始终站在踏序之上，仿佛天生就该在那里。

磨契更替那天，狐狸记录官将升鞍与重顶并列写入磨令。马没有下场，只是在廊道上缓步巡纹。它不直接参与磨役，却始终参与定义磨役——把混乱解释为调整，把迟滞解释为必要，把被抽解释为机会，把被抹解释为校正。

鞭子不在它身上，而在它的话里。它不需要亲自挨抽，只需要让其他兽相信，鞭子落下是合理的，鞍子扣上是值得的。于是磨道开始自行运转，而它始终站在解释之上，看起来像在引领方向。

牛：鞍是责任，鞭是节奏

后槽始终最稳。牛的鞍子不轻，扣在脊背上像一层长期存在的重量，久到分不清那究竟是外加的，还是已经长成了骨。磨契更替那天，它的站位被往前挪了半寸，不多，却足以让这份重量显出明确的去处。

它没有回应这种变化，只是把步子踩得更实。骡被抽去顶硬节时，它自然加快节奏，把后面的磨补平；某一段磨迹被划掉，它也不追问，只是把空缺压紧，让整条磨道继续顺着走。

鞭子很少直接落在它身上，但它始终看得见。它看见谁被点、谁被抽、谁被抹，于是自己的步子更稳。鞭子在它眼里变成了节奏，而鞍子，则让这种节奏看起来像是自愿承担。

骡：鞍是位置，鞭是指向

边磨区最容易起尘。骡原本在那里，蹄印浅，位置轻。磨契更替，它被点名，站位被往前提了一截，一副更厚实的鞍子扣在身上，而这点靠近本身就成了理由。

它不需要多想，只需要往前。第一圈踏在主磨道前侧，节奏跟上；第二圈硬节落下，它已经顶上；第三圈磨迹被重算，那一整圈被划掉，它没有退；第四圈磨令补写，同一段硬节再次指向它，它依旧往前。

鞍子不断把它推向更前的位置，鞭子则不断收紧这个位置。第五圈结束，它被调回边磨区，鞍子未解，只是后移一格，磨痕册上留下一行记录：曾上风前位。那些最深的痕不在册上，但它已经学会，先在鞭子落下之前往前走。

磨盘之外

磨契合上，位置却没有合上。马仍在高处解释方向，牛在后槽把节奏踩稳，骡则回到边缘，等待下一次被点名。磨道像是暂时安静了下来，可真正被固定住的，并不是这一轮踏磨的结果，而是每一类兽对自己该站在哪里、该怎样往前的理解。

鞍子给位置、给靠近、给被看见的理由；鞭子给压力、给指向、给不可拒绝的节奏。两者并不对立，而是彼此补足：前者让服从显得体面，后者让顺从变得熟练。等位置被承认、节奏被内化之后，很多时候已经不再需要反复抬手，兽群也会自己把空缺补上，把队列站齐，把还没落下的那一下提前想明白。

当鞭子不再频繁落下时，鞍子已经足够让兽自己向前。真正稳固的，从来不是一时的压服，而是让高处的人学会解释，让中间的人学会承担，让边上的人学会预判；于是磨盘转得更顺，秩序看起来更自然，甚至连疼痛都不必次次显形。到最后，最深的驯化未必发生在鞭子落下的那一刻，而是发生在兽开始主动按照鞍与鞭所划定的位置活着的时候。

FunTester 原创精华

Claude Code 发布蓝牙 API，允许第三方硬件监听特定事件；语音识别疲劳、抑郁和 2 型糖尿病，Speechmatics 发布生物标记平台丨日报

RTE — Sun, 19 Apr 2026 12:47:09 +0800

开发者朋友们大家好：

这里是「RTE 开发者日报」，每天和大家一起看新闻、聊八卦。我们的社区编辑团队会整理分享 RTE（Real-Time Engagement）领域内「有话题的技术」、「有亮点的产品」、「有思考的文章」、「有态度的观点」、「有看点的活动」，但内容仅代表编辑的个人观点，欢迎大家留言、跟帖、讨论。

本期编辑：@koki、@ 鲍勃

01 有话题的技术

1、腾讯发布并开源混元世界模型 HY-World 2.0

腾讯混元团队日前正式发布并开源了多模态世界模型 HY-World 2.0。该模型支持通过文本、图像和视频等多模态输入，自动生成、重建并模拟可交互的完整 3D 世界。

与以往仅生成像素级视频的模型不同，HY-World 2.0 直接输出 Mesh、3DGS 和点云等真正可编辑且持久化的 3D 资产，能够无缝导入 Unity、Unreal Engine 等主流游戏引擎进行二次开发。

其不仅原生具备 3D 一致性，还内置了支持物理碰撞和物理感知移动的交互式角色探索模式。

目前，官方已在 GitHub 和 Hugging Face 等平台开源了技术报告、WorldMirror 2.0 的推理代码与模型权重，其余核心模块代码及权重也即将陆续释出。

https://github.com/Tencent-Hunyuan/HY-World-2.0

https://huggingface.co/tencent/HY-World-2.0

（@ 橘鸦 Juya）

2、OpenAI 发布 Codex 更新：集成 gpt-image-1.5，支持视觉驱动的背景计算机操控

OpenAI 宣布 Codex 完成多模态能力重构，从单一的代码文本生成演进为「视觉 - 操作」闭环系统。新版本通过集成 gpt-image-1.5 模型与计算机操控（Computer Use）技术，使智能体能够感知 UI 像素、自主跨应用执行任务，并直接在开发工作流中生成与迭代视觉资产。

像素级背景计算机操控（Background Computer Use）：基于多模态视觉感知，Codex 能够识别屏幕元素并驱动独立光标进行点击与输入。支持在 macOS 背景环境中多智能体并行操作，无需 API 即可通过视觉反馈完成前端调试、应用测试及复杂 UI 交互。

gpt-image-1.5 原生集成：Codex 现支持在代码编辑器内直接调用图像模型。开发者可结合代码逻辑与屏幕截图，生成并迭代产品原型图、前端视觉组件及游戏素材，实现从代码到视觉资产的同环境转换。

多模态交互浏览器与富媒体预览：内置浏览器支持开发者在页面直接标注（commenting）以提供视觉指令；侧边栏新增对 PDF、电子表格、幻灯片及文档的深度解析与预览，增强了非文本类工程文档的上下文提取能力。

长效记忆（Memory）与多模态自动化：支持跨会话保留视觉偏好与操作修正记录。智能体可根据 Google Docs 评论、Slack 消息及 Notion 截图的多维上下文，自动规划并执行跨度数周的长周期开发任务。

MCP 插件体系扩展：新增 90 多个插件支持，通过模型上下文协议（MCP）整合 Atlassian Rovo、CircleCI、GitLab 等工具，使智能体能够在视觉操作的同时，通过标准化接口获取深度技术上下文。

参考链接：

https://openai.com/index/codex-for-almost-everything/

( @OpenAI)

3、OpenMOSS 开源音频统一理解模型 MOSS-Audio

OpenMOSS 团队正式开源 MOSS-Audio 音频统一理解模型。该模型通过模块化架构整合了语音识别、环境声感知、音乐分析及复杂音频推理能力，实现了极高精度的词级/句级时间戳定位，在多项音频理解基准测试中以 4B/8B 参数规模超越了更大尺寸的开源及闭源模型。

DeepStack 跨层特征注入机制：不同于传统仅提取编码器顶层特征的方案，MOSS-Audio 选取编码器早期和中间层特征，通过独立投影注入 LLM 前几层。该架构有效保留了韵律、音色、瞬态事件及局部时频结构等底层声学细节。
显式时间感知表示（Time Marker）：在预训练阶段按固定时间间隔插入显式时间标记，使模型在统一文本生成框架下具备细粒度时间定位能力。其在 AISHELL-1 上的 AAS 指标（35.77）相比 Qwen3-Omni 和 Gemini-3.1-Pro 实现了数量级领先。
13 维度细粒度语音描述能力：支持对性别、年龄、口音、音高、音量、语速、音色质感、情绪及个性特征等 13 个维度进行结构化分析，MOSS-Audio-8B-Instruct 在综合评分中位列 SOTA。

思维链（CoT）与推理增强：MOSS-Audio-8B-Thinking 版本通过 CoT 训练与强化学习，支持对复杂音频内容进行多跳推理，其通用音频理解平均准确率达到 71.08，超越了部分 30B+ 规模的开源模型。

通用音频描述 Demo:

<think>

音档内容是一位男性说话者，语气带有自信和些许夸耀。说话者透过一连串反问句来强调自己的经历与能力，句末常带有上扬的语调，例如「你干过吗？」. 语速整体中等偏快，尤其在列举成就时更为明显。内容围绕说话者声称自己完成了许多令人惊叹或不寻常的事情，例如跳过楼、与坦克近距离接触（被坦克压过）、野外生存、吃遍各种蚯蚓、开飞机、坦克漂移，以及完成两项电影史上的首次活动（《战狼 1》、《战狼 2》）。说话者在 [00:08] 处有轻微的口腔音。最后以「我觉得这是我最大的成就」作结，语气显得相当肯定。整体语篇结构是列举式陈述，透过对比来突显自身与众不同之处。音档中没有明显的背景噪音或其他说话者。说话者在 [00:00]-[00:06]、[00:07]-[00:13]、[00:15]-[00:20] 及 [00:23]-[00:29] 进行了多次提问和陈述，其间穿插了短暂停顿，如 [00:06] 和 [00:13] 的停顿。这些停顿有助于听者消化信息，并在说话者转换话题或强调下一点之前制造悬念。例如，在 [00:25] 提到「中国电影人之前没人干的事儿」时，语气略带自豪。最后的陈述语气坚定。

</think>

说话者以一连串充满自信的反问句开场，列举了自己多项惊人的个人经历，包括完成电影史上的重要拍摄以及多项常人难以企及的举动。其语气坚定，句末语调上扬，强调个人成就的独特性，并在结尾处以肯定的语气总结，认为这些是他的最大成就。

GitHub:

https://github.com/OpenMOSS/MOSS-Audio

HuggingFace:

https://huggingface.co/collections/OpenMOSS-Team/moss-audio

（@ 模思智能）

02 有亮点的产品

1、Claude 桌面端发布 Bluetooth API：支持硬件设备实时监听智能体状态

Anthropic 在 Claude 桌面应用（Cowork 与 Code 模式）中上线原生 Bluetooth API。该接口允许开发者构建外部硬件设备，通过蓝牙实时同步 Claude 的内部运行状态，实现 LLM 软件与物理世界的异步交互。

支持跨模式硬件联动：Bluetooth API 覆盖 Claude 桌面端的 Cowork 与 Code 核心模式，允许第三方硬件作为 Claude 的物理外设运行。
状态触发机制：硬件设备可实时监听 Claude 的特定事件，例如当智能体（agent）因安全策略挂起并「等待用户操作权限」时，触发物理信号。
面向 Maker 生态的端到端交互：开发者可利用该 API 开发专用通知器、物理控制台或嵌入式交互设备（如桌面宠物），通过物理震动、光效或音频解决用户在多任务办公时错过 AI 授权请求的痛点。

https://github.com/anthropics/claude-desktop-buddy

(@felixrieseberg\@X)

2、Phonely 获 A 轮融资：通过自研专用小模型集群架构实现百万级语音 AI 通话优化

语音 AI 初创公司 Phonely（YC S24）宣布完成由 Base10 领投的 A 轮融资。该公司弃用通用大模型方案，通过自研的专用小模型集群技术栈，为保险、呼叫中心等行业提供高并发、低延迟的入站通话智能体服务，旨在通过数据驱动的脚本微调提升电话业务转化率。

多专用小模型（Specialized Small Models）架构：针对「信息提取」、「潜在客户识别」等特定子任务部署独立的小型化模型，替代单一大型 LLM。该方案在降低推理成本的同时，显著解决了语音交互中的高延迟问题。
语音转化率优化（CRO for Voice）：引入类似 Web 端的转化率优化机制，支持企业根据统计反馈微调 AI 提问逻辑。数据显示，通过优化特定提问环节，业务结果产出可提升 5%。
规模化入站（Inbound）处理：目前每月处理数百万次跨行业通话，核心应用场景集中在广告引流后的入站咨询与初步筛选，目标在今年年底实现通话者近乎无感知的 AI 交互体验。
端到端工程化优化：创始人表示延迟（Latency）已不再是技术瓶颈，当前研发重点已转向对话的逻辑准确性与「非判断性」交互体验，以消除用户面对人工客服时的心理压力。

(@dessaigne\@X)

3、Speechmatics 发布语音生物标记平台：15 秒采样识别 30 余种健康信号，包括 2 型糖尿病、精神压力、疲劳及抑郁症状

Speechmatics 与 thymia 宣布达成深度合作，推出集成医疗级语音转文字（STT）与临床级语音生物标记智能的联合平台。该系统能够从 15 秒的自然语音中实时提取并分析 30 多种健康指标，包括 2 型糖尿病、精神压力、疲劳及抑郁症状。

15 秒采样与实时推断：系统以 15 秒为间隔处理音频流，通过分析声学（Acoustic）与语言（Linguistic）模式中的神经学特征提取健康信号，在提供标准转录的同时实时返回诊断参考。
高鲁棒性多模态数据集：模型基于超过 75,000 个独特声音的动态测量数据（跨越 6 年研发）以及数百万小时的多口音语音数据训练，确保非母语及带口音语音下的识别准确率维持在 85% 以上。
无硬件依赖的 API 集成：采用单一 API 接口提供服务，支持云端、本地及设备端部署；无需传感器或其他专用硬件，可直接嵌入现有语音智能体、呼叫中心系统或车载终端。

( @globenewswire)

4、Eigen 完成 1500 万美元种子轮融资：Benchmark 领投，主攻「共时性」社交智能体

AI 初创公司 Eigen 宣布完成 1500 万美元种子轮融资，由 Benchmark 领投，Pinterest 联合创始人 Ben Silbermann 及 Meta 前高管 David Singleton 参投。该公司旨在开发一种「亲社会（Pro-social）」的 AI 架构，核心逻辑是从「个人 AI 伴侣」转向创造人类用户之间的「共享、共时性体验」。

「互为好友」式产品架构：不同于 Replika 或 Character.ai 等主打 1 对 1 私密陪伴的路径，Eigen 试图构建一种作为「共同好友」存在的智能体，旨在增强现实社交关系而非替代社交，通过 AI 媒介实现多用户间的同步交互。
「U 型」团队组织模式：公司跳过中层管理岗位，由资深技术专家直接与年轻创意人才协作。团队成员包含多名初创公司创始人及专业编剧，强调工程开发与叙事逻辑的深度耦合。
对抗超个性化（Hyper-personalization）孤岛：Scherer 提出 AI 不应仅为个人定制「完美世界」，而应构建群体共享的数字环境。其技术逻辑侧重于通过 AI 智能体协调多方上下文，缓解数字化进程中个人社交原子化趋势。
高估值市场切入：公司目标指向 2035 年预计达 5524.9 亿美元的全球 AI 伴侣市场。种子资金将主要用于组建核心工程团队，目前产品细节仍处于隐形阶段。

( @fortune)

03 有态度的观点

1、黄仁勋：若 DeepSeek 率先在华为平台上出现，「对美国将是可怕的结果」

英伟达 CEO 黄仁勋近日在接受科技播客主持人 Dwarkesh Patel 专访时，就美国对华 AI 芯片出口管制政策发出警告。

针对 Patel「向中国出售英伟达芯片可能助其训练具备网络攻击能力的 AI 模型」这一质疑，黄仁勋直言「你的前提就是错的」。

他指出，Anthropic 旗下 Claude 模型是在规模相当普通的算力上训练完成的，而此类算力在中国「大量可得」；中国拥有全球约 50% 的顶尖 AI 研究人员，算力限制反而倒逼出「极其聪明的算法」，DeepSeek 的出现「绝非无关紧要的进步」。

他随即抛出核心警告：「如果 DeepSeek 第一款在华为上发布，那对美国将是一个可怕的结果。」

在他看来，极端的出口管制会形成反效果——迫使中国顶尖开源模型专门针对华为等本土硬件深度优化，一旦这些模型在华为架构上跑得最好，英伟达平台的全球吸引力将被直接削弱。

如果我们被迫离开中国，这会加速他们的芯片产业发展，并迫使他们所有的 AI 生态系统专注于自己的内部架构。

黄仁勋指出，随着中国 AI 模型以开放标准向全球南方国家扩散，美国可能在长期技术标准竞争中陷入被动，而这一切的根源，正是主动放弃全球第二大市场的战略失误。

( @APPSO)

写在最后：

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

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

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

在有 Vibe 的地方一起 Coding，咖啡一杯，Token 无限丨 Real-Time Café 快闪杭州站

RTE — Sun, 19 Apr 2026 12:10:39 +0800

RTE 社区这次计划做一件轻松和「Keep Real」的事情：

包下一个咖啡馆，

邀请大家一起来杯咖啡，

坐下来各自 vibe coding。

We’re turning coffee into compute.

未来这将成为 RTE 社区的新系列活动，首站杭州！为了让这件事情更合理，我们想了很多双关语。

RTE 开发者社区探索人和 AI 的实时互动新范式，我们的 slogan 是：

Real Time Connection & Real T ime Engagement

所以在这里，Real Time Coding & Real Time Execution，实时写、实时 debug、实时互动，创造一个属于开发者的「实时咖啡馆」(Real-Time Café)。

你可以：

随便坐下开始写
和陌生人连上一起 build
看别人 live coding / debugging / shipping

我们也将在快闪时段提供一场 40 分钟左右的 Voice AI Skill 工作坊，教大家如何快速做一个 voice agent。

到场者均提供咖啡一杯，和 Kimi K2.6 token 无限。

如果你：

感兴趣实时 AI / agent / 语音
或者正在 coding 某个项目

欢迎你来这里待一会儿。喝杯咖啡，写点代码，或者什么都不做。

如何 vibe 进来

时间：4 月 24 日（周五）下午 1:00 - 5:40

地点：杭州拱墅区城西银泰城（报名审核通过后告知具体地址）

13:00-17:40 自由流动、签到，领一杯咖啡

特别时间段：

13:00-15:00 一起各自 vibe coding

15:00-15:40 voice ai skill 工作坊（快闪活动，可选参加）

16:40-17:40 no coding & no AI! 拍照、聊天、欣赏人类世界！

因为是周五下午所以我们不要很紧张地跟 AI 共处而是把注意力放回自己身上在一个好的 vibe 下做一些真正想做的事情并且在活动结束前一小时放下 coding 欣赏这个人类世界——by lingo

报名链接：https://luma.com/z1vodhtd

报名需经过审核，我们希望你是对实时 AI / agent / 语音感兴趣或者是正在 coding 某些项目的开发者、创业者。

可以 walk-in，不过 walk-in 也要现场报名审核噢。

附录：这些创作者都会出现在 Real-Time Cafe！

Lody

跨设备并行使用你的 Coding Agents。

In Lody, you can orchestrate your AI Coding Agents across devices, using your existing Claude Code, Codex, Kimi Code, and more. Multiple agents work in parallel based on Worktree, with PRs, CI, and Reviews synced across the entire pipeline. Teams can share agents and use group chat. From idea to merged PR — all in one interface.

https://lody.ai

Cerul

Teach your AI agents to see

Video search today is blind. It only reads transcripts — but over 75% of video knowledge is visual: slides, code, diagrams, whiteboards etc. Live as a Skill in every major agent.

https://cerul.ai/

EinClaw

直连 Agent 的麦克风

通过语音的方式，将你的大脑与 Agent 的大脑连接起来。任何想法，任何待办，任何项目，一句话，言出法随，记录想法，完成待办与项目。

NewBro

One bro talks, one bro works.

现在所有的 AI 产品，交互都是「回合制」的——你发一句话，AI 做一件事，你等它做完，再发下一句。NewBro 把 AI 拆成两条独立线程：一条沟通，常驻、实时、你随时能说话；一条执行，异步、后台、跑你派给它的任务。你说你的，它做它的——任务持续跑，沟通不暂停。

RustPBX

基于 Rust 编写的可编程 SIP 语音网关

基于 Rust 编写的可编程 SIP 语音网关，自带管理 WebUI，比 FreeSwitch 好用，能容器部署、可观测、支持 WebRTC 和 SIP，可以用来构建小型的呼叫中心，也可以用来做隐私号呼叫或者通知发送到客户的手机上

项目是完全开源的，所有的代码都是用 Rust 编写（包括所有的协议、编解码），更安全和更高性能。

https://github.com/restsend/rustpbx

测试缺陷模型创建提升 Bug 管理效率

hujy — Sun, 19 Apr 2026 10:21:07 +0800

测试缺陷模型创建提升 Bug 管理效率
诚邀您 Cursor 在线开发 -https://taou.cn/a/KaHZ7d -（10：00 -11：00）
每天提 Bug，但 Bug 数据最后没人用。在线开发 “缺陷模型”，让缺陷真正创造价值。

钉钉会议
https://meeting.dingtalk.com/j/oAgvUSpRvf0

开源 | client-perf 全平台性能测试工具，支持 Windows、Android、iOS、HarmonyOS 四个平台的性能数据采集

fbz — Sat, 18 Apr 2026 22:46:06 +0800

开源 | client-perf 全平台性能测试工具

基于 vibecoding 完善了之前的项目，现在开源分享：https://github.com/15525730080/client_perf

这是一个全平台开源性能测试工具，一台电脑同时支持 Windows、Android、iOS、HarmonyOS 四个平台的性能数据采集，对比分析。

实例截图 / Screenshots

任务列表 / Task List

创建任务 / Create Task

PC 应用性能报告 / PC App Performance Report

iOS App 性能报告 / iOS App Performance Report

打标签 & 对比选中内容 / Add Labels & Compare Selected Content

核心功能

多平台采集

Windows：CPU、内存、GPU、帧率 (FPS)、磁盘 IO、网络 IO、截图
Android：CPU、内存、GPU、帧率 (FPS)、磁盘 IO、网络 IO、截图
iOS：CPU、内存、帧率、线程数、句柄数（支持 iOS 17+ tunnel 模式，已验证 iOS 26）
HarmonyOS：CPU、内存、帧率

针对棘手场景优化

Windows 游戏 FPS 采集：集成 PresentMon 自动提权，无需手动配置权限
iOS 17+ 兼容：解决苹果 DTX 协议变更问题，支持 iOS 26 最新版本

系统架构

┌─────────────────────────────────────────────────────────────────────────────┐
│                              Web UI (浏览器 / Browser)                       │
│                        http://localhost:8080                                 │
└──────────────────────────────┬──────────────────────────────────────────────┘
                               │ HTTP / REST API
                               ▼
┌─────────────────────────────────────────────────────────────────────────────┐
│                           FastAPI 服务层 / Service Layer (api.py)            │
│  ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────────────┐  │
│  │ 设备管理  │ │ 任务管理  │ │ 对比分析  │ │ 标签管理  │ │ Excel 报告导出   │  │
│  │Device Mgt│ │Task Mgmt │ │Comparison│ │  Labels  │ │ Excel Export     │  │
│  └────┬─────┘ └────┬─────┘ └────┬─────┘ └────┬─────┘ └────────┬─────────┘  │
└───────┼────────────┼────────────┼────────────┼────────────────┼─────────────┘
        │            │            │            │                │
        ▼            ▼            ▼            ▼                ▼
┌─────────────────────────────────────────────────────────────────────────────┐
│                          核心采集层 / Collection Layer (core/)               │
│                                                                             │
│  ┌─────────────┐  ┌──────────────┐  ┌────────────┐  ┌──────────────────┐   │
│  │  pc_tools   │  │android_tools │  │ ios_tools  │  │ harmony_tools    │   │
│  │             │  │              │  │            │  │                  │   │
│  │ psutil      │  │ adbutils     │  │ go-ios     │  │ hdc              │   │
│  │ pynvml      │  │              │  │ py-ios-dev │  │                  │   │
│  │ PresentMon  │  │              │  │            │  │                  │   │
│  └──────┬──────┘  └──────┬───────┘  └─────┬──────┘  └────────┬─────────┘   │
│         │                │                │                   │             │
│         ▼                ▼                ▼                   ▼             │
│  ┌──────────────────────────────────────────────────────────────────────┐   │
│  │                      Monitor 采集循环 / Collection Loop (monitor.py)  │   │
│  │   CPU → 内存 → FPS → GPU → 线程数 → 句柄数 → 磁盘IO → 网络IO → 截图  │   │
│  └──────────────────────────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────────────────────────┘

易于二次开发

新增平台或新指标，只需继承 Monitor 基类，实现对应采集函数即可。

与 Skill 结合

支持与 AI Agent Skill 联动，可通过自然语言指令触发性能采集、生成报告等操作，方便集成到自动化测试流程中。

安装使用

pip install client-perf
client-perf

Web 界面默认 http://localhost:8080

如果在做客户端性能测试或性能对比，有类似需求可以试试这个项目，提 issue 或 star 都欢迎。

项目地址：https://github.com/15525730080/client_perf

核心功能

多进程子进程监控：支持主进程 + 子进程全链路监控
定时任务：自动生成性能报告并导出 Excel
多组数据对比：直观展示不同版本/场景性能差异
Web 界面 + REST API：可视化管理 + 自动化集成
截图采集：自动截取应用界面，辅助性能分析

易于二次开发

项目结构清晰，模块化设计，新增平台或新指标只需继承 Monitor 基类，实现对应采集函数即可。

与 Skill 结合

支持与 AI Agent Skill 联动，可通过自然语言指令触发性能采集、生成报告等操作，方便集成到自动化测试流程中。

安装使用

pip install client-perf
client-perf

Web 界面默认 http://localhost:8000

如果在做客户端性能测试或性能对比，有类似需求可以试试这个项目，提 issue 或 star 都欢迎。

项目地址：https://github.com/15525730080/client_perf

布式锁地图：Redis、Redlock、Advisory Lock、CAS

Fhaohaizi — Sat, 18 Apr 2026 20:36:14 +0800

每个后端工程师迟早都会遇到这样的场景：两个请求在同一毫秒内同时打到系统，结果客户被重复扣费、座位被重复预订，或者库存被扣成负数。在单体架构里，我们还可以依赖数据库事务或进程内互斥锁兜底；但在有多个服务实例的分布式系统里，这套方法就不够用了。

这时候，真正要解决的问题不是某一段代码该怎么写，而是如何在多个进程、多个节点之间协调对同一份共享资源的访问。也就是说，我们需要一套可靠的分布式锁机制。

本文会结合 Redis、PostgreSQL、DynamoDB 等常见组件，拆解几种在生产环境里常见的分布式并发控制方案，包括 SET NX EX、Redlock、建议锁、乐观锁和 CAS。重点不只是讲怎么做，还会讲清楚每种方案适合什么场景、有哪些边界，以及如何在工程上做取舍。

分布式锁为什么存在

假设一个支付服务在负载均衡器后面跑着 3 个副本。用户点击一次支付按钮，但因为网络抖动触发了重试，结果其中 2 个副本几乎同时收到了请求。它们都读到订单状态是 pending，都执行了扣款逻辑，又都把订单更新为 paid。最终用户看到的，就是两笔扣费记录。

售票系统里也有类似问题。两个用户同时抢最后一个座位，两个请求几乎同时查到库存里还剩 1 张票，于是都通过了校验，最后系统卖出了一张根本不存在的票。

这些都不是实验室里的极端案例，而是线上系统里非常常见的并发冲突。根因只有一个：多个进程需要在没有共享内存的前提下，协调对同一份资源的访问。

分布式锁的本质，是把原本只在单进程内成立的互斥语义，扩展到跨进程、跨节点的执行环境里。同一时刻只能有一个持有者进入关键区，其他请求要么等待，要么尽快失败。

基于 Redis 的锁：`SET NX EX` 模式

最常见、也最容易落地的分布式锁方案，是使用单个 Redis 实例，通过原子 SET 命令完成加锁：

import Redis from "ioredis";

const redis = new Redis(process.env.REDIS_URL);

interface LockResult {
  acquired: boolean;
  release: () => Promise<boolean>;
}

async function acquireLock(
  key: string,
  ttlMs: number,
  ownerId: string
): Promise<LockResult> {
  const lockKey = `lock:${key}`;

  // 只有首次写入成功的调用方才能拿到锁
  const result = await redis.set(lockKey, ownerId, "PX", ttlMs, "NX");

  if (result !== "OK") {
    return { acquired: false, release: async () => false };
  }

  // 释放锁时先校验 owner，避免误删别人的锁
  const release = async (): Promise<boolean> => {
    const script = `
      if redis.call("get", KEYS[1]) == ARGV[1] then
        return redis.call("del", KEYS[1])
      else
        return 0
      end
    `;
    const removed = await redis.eval(script, 1, lockKey, ownerId);
    return removed === 1;
  };

  return { acquired: true, release };
}

在支付处理流程里的典型用法如下：

import { randomUUID } from "crypto";

async function processPayment(orderId: string, amount: number) {
  const ownerId = randomUUID();
  const lock = await acquireLock(`payment:${orderId}`, 10_000, ownerId);

  if (!lock.acquired) {
    throw new Error("Payment already being processed");
  }

  try {
    const order = await db.orders.findById(orderId);
    if (order.status !== "pending") {
      return { status: "already_processed" };
    }

    const charge = await paymentGateway.charge(order.customerId, amount);
    await db.orders.update(orderId, {
      status: "paid",
      chargeId: charge.id,
    });

    return { status: "success", chargeId: charge.id };
  } finally {
    await lock.release();
  }
}

这个模式能成立，关键在 4 个点：

NX：只有 key 不存在时才写入，确保加锁动作本身是原子的。
PX：给锁设置毫秒级过期时间，避免持有者宕机后形成永久死锁。
Lua 释放脚本：只有 owner 匹配时才删除 key，防止慢请求在锁过期后误删后来者的锁。
唯一 ownerId：每次加锁都必须生成新的持有者标识，不能复用流程级 ID。

Go 版本的实现思路完全一样：

package distlock

import (
    "context"
    "crypto/rand"
    "encoding/hex"
    "time"

    "github.com/redis/go-redis/v9"
)

type Lock struct {
    client  *redis.Client
    key     string
    ownerID string
}

func Acquire(ctx context.Context, client *redis.Client, key string, ttl time.Duration) (*Lock, error) {
    ownerID := generateOwnerID()
    lockKey := "lock:" + key

    ok, err := client.SetNX(ctx, lockKey, ownerID, ttl).Result()
    if err != nil {
        return nil, err
    }
    if !ok {
        return nil, ErrLockNotAcquired
    }

    return &Lock{client: client, key: lockKey, ownerID: ownerID}, nil
}

var releaseScript = redis.NewScript(`
    if redis.call("get", KEYS[1]) == ARGV[1] then
        return redis.call("del", KEYS[1])
    else
        return 0
    end
`)

func (l *Lock) Release(ctx context.Context) error {
    result, err := releaseScript.Run(ctx, l.client, []string{l.key}, l.ownerID).Int64()
    if err != nil {
        return err
    }
    if result == 0 {
        return ErrLockAlreadyReleased
    }
    return nil
}

func generateOwnerID() string {
    b := make([]byte, 16)
    rand.Read(b)
    return hex.EncodeToString(b)
}

这个方案的短板也很明确：如果你只依赖单个 Redis 节点，那它本身就是单点。一旦 Redis 宕机，锁就全部丢失；如果发生主从切换，尚未复制出去的锁状态也可能丢失，结果就是两个进程在故障窗口里同时认为自己拿到了同一把锁。

如果你的业务本来就有数据库唯一约束、幂等键等二次保护，这种极低概率的双重获取通常还可以接受；但如果场景是金融交易、资源分配或其他高损失操作，就不能只停留在这里。

Redlock 算法

当单节点 Redis 的可靠性不够时，很多团队会考虑 Redlock。它把锁分散到多个独立的 Redis 实例上，只有在拿到多数节点的成功响应后，才认为加锁成功：

import Redis from "ioredis";
import { randomUUID } from "crypto";

class Redlock {
  private nodes: Redis[];
  private quorum: number;

  constructor(urls: string[]) {
    this.nodes = urls.map((url) => new Redis(url));
    this.quorum = Math.floor(this.nodes.length / 2) + 1;
  }

  async acquire(
    resource: string,
    ttlMs: number
  ): Promise<{ acquired: boolean; release: () => Promise<void> }> {
    const ownerId = randomUUID();
    const lockKey = `lock:${resource}`;
    const startTime = Date.now();

    // 并行向所有节点发起加锁请求
    const results = await Promise.allSettled(
      this.nodes.map((node) =>
        node.set(lockKey, ownerId, "PX", ttlMs, "NX")
      )
    );

    const acquired = results.filter(
      (r) => r.status === "fulfilled" && r.value === "OK"
    ).length;

    const elapsed = Date.now() - startTime;
    const remainingTtl = ttlMs - elapsed;

    // 多数派成功，且剩余 TTL 足够支撑业务执行
    if (acquired >= this.quorum && remainingTtl > ttlMs * 0.1) {
      return {
        acquired: true,
        release: () => this.releaseAll(lockKey, ownerId),
      };
    }

    // 获取失败时，要把已经抢到的锁一并释放
    await this.releaseAll(lockKey, ownerId);
    return { acquired: false, release: async () => {} };
  }

  private async releaseAll(key: string, ownerId: string): Promise<void> {
    const script = `
      if redis.call("get", KEYS[1]) == ARGV[1] then
        return redis.call("del", KEYS[1])
      else
        return 0
      end
    `;
    await Promise.allSettled(
      this.nodes.map((node) => node.eval(script, 1, key, ownerId))
    );
  }
}

Redlock 的价值主要体现在 3 点：

多数派机制：少量节点故障时，系统仍然能继续工作。
有效窗口计算：锁的可用时间不是原始 TTL，而是扣掉获取耗时后的剩余时间。
实现复杂度更高：它对时钟、网络延迟和节点独立性更敏感，写错细节就会埋雷。

需要特别提醒的是，Redlock 不是银弹。它没有天然的围栏令牌能力，如果业务执行时间拖得过长，TTL 到期后仍然可能出现慢请求写回的问题。工程上更稳妥的做法，通常是直接使用成熟库，比如 Node 生态里的 redlock，或者 Go 生态里的 redsync，而不是自己从零手写。

心跳续期

固定 TTL 有个经典两难：设短了，业务还没跑完锁就过期；设长了，持有者一旦崩溃，其他请求就要白白等很久。常见解法是加一个后台续期线程，也就是所谓的心跳机制：

type RenewableLock struct {
    *Lock
    cancel context.CancelFunc
    done   chan struct{}
}

func AcquireWithRenewal(
    ctx context.Context,
    client *redis.Client,
    key string,
    ttl time.Duration,
) (*RenewableLock, error) {
    lock, err := Acquire(ctx, client, key, ttl)
    if err != nil {
        return nil, err
    }

    renewCtx, cancel := context.WithCancel(ctx)
    done := make(chan struct{})

    go func() {
        defer close(done)
        // 每 1/3 TTL 续一次，给失败重试留出缓冲
        ticker := time.NewTicker(ttl / 3)
        defer ticker.Stop()

        for {
            select {
            case <-renewCtx.Done():
                return
            case <-ticker.C:
                err := renew(renewCtx, client, lock.key, lock.ownerID, ttl)
                if err != nil {
                    // 续期失败通常意味着锁已经丢失，不应继续执行业务
                    return
                }
            }
        }
    }()

    return &RenewableLock{Lock: lock, cancel: cancel, done: done}, nil
}

var renewScript = redis.NewScript(`
    if redis.call("get", KEYS[1]) == ARGV[1] then
        return redis.call("pexpire", KEYS[1], ARGV[2])
    else
        return 0
    end
`)

func renew(ctx context.Context, client *redis.Client, key, ownerID string, ttl time.Duration) error {
    result, err := renewScript.Run(ctx, client, []string{key}, ownerID, ttl.Milliseconds()).Int64()
    if err != nil {
        return err
    }
    if result == 0 {
        return ErrLockAlreadyReleased
    }
    return nil
}

func (rl *RenewableLock) Release(ctx context.Context) error {
    rl.cancel() // 先停掉续期协程
    <-rl.done   // 再等后台协程退出
    return rl.Lock.Release(ctx)
}

这里把续期间隔设置成 TTL / 3，本质上是在业务执行期间给自己留出两次补救机会。如果进程挂起、线程卡死或者发生网络分区，心跳自然停止，锁也会在过期后自动释放。

很多成熟框架内部都是这个思路。比如 Redisson 的看门狗机制，本质上就是在锁仍然归自己所有时持续刷新过期时间。

PostgreSQL 建议锁

如果你的系统本来就强依赖 PostgreSQL，而且锁保护的范围和数据库操作天然一致，那建议锁往往是一个非常务实的选择。它不需要额外引入外部基础设施，也能和数据库事务很好地配合：

import { Pool } from "pg";

const pool = new Pool({ connectionString: process.env.DATABASE_URL });

// 会话级建议锁：显式释放前一直有效，连接断开也会释放
async function withAdvisoryLock<T>(
  lockId: number,
  fn: () => Promise<T>
): Promise<T> {
  const client = await pool.connect();

  try {
    // pg_try_advisory_lock 非阻塞，拿不到会直接返回 false
    const { rows } = await client.query(
      "SELECT pg_try_advisory_lock($1) AS acquired",
      [lockId]
    );

    if (!rows[0].acquired) {
      throw new Error(`Could not acquire advisory lock ${lockId}`);
    }

    try {
      return await fn();
    } finally {
      await client.query("SELECT pg_advisory_unlock($1)", [lockId]);
    }
  } finally {
    client.release();
  }
}

// 业务 ID 映射为稳定的锁 ID
function lockIdFromOrderId(orderId: string): number {
  let hash = 0;
  for (const char of orderId) {
    hash = (hash * 31 + char.charCodeAt(0)) | 0;
  }
  return Math.abs(hash);
}

// 退款流程通过建议锁串行化
await withAdvisoryLock(lockIdFromOrderId("order-789"), async () => {
  const order = await db.orders.findById("order-789");
  if (order.status === "refunded") return;
  await paymentGateway.refund(order.chargeId);
  await db.orders.update("order-789", { status: "refunded" });
});

事务级建议锁也很常用，它会在事务提交或回滚时自动释放：

-- 事务结束时自动释放，适合和同事务内的数据更新一起使用
SELECT pg_advisory_xact_lock(hashtext('booking:seat-42'));

UPDATE seats
SET booked_by = 'user-123'
WHERE id = 'seat-42' AND booked_by IS NULL;

建议锁的优点很直接：

无需额外组件：已经用了 PostgreSQL，就能直接上手。
事务整合自然：事务级锁和数据修改天然同生命周期。
数据库负责死锁检测：不用自己额外维护复杂的锁等待关系。

它的边界也很清楚：

只能绑定在单个 PostgreSQL 主实例上，不能跨库协调。
锁 ID 是整数，字符串资源需要设计稳定哈希。
如果用会话级锁，还要特别注意和连接池的交互，避免连接归还后锁还没释放。

带版本列的乐观锁

很多时候，我们根本不需要严格互斥，只需要在写入时发现冲突即可。乐观锁就是这个思路：默认假设冲突很少发生，真正更新时再检查版本号是否变化。

// Schema: orders 表里有一个 version 整数字段，默认值为 1

async function updateOrderStatus(
  orderId: string,
  newStatus: string,
  expectedVersion: number
): Promise<boolean> {
  const result = await db.query(
    `UPDATE orders
     SET status = $1, version = version + 1, updated_at = now()
     WHERE id = $2 AND version = $3`,
    [newStatus, orderId, expectedVersion]
  );

  // 没有更新到任何行，说明有人先一步改过了
  return result.rowCount === 1;
}

async function processOrderWithRetry(
  orderId: string,
  maxRetries = 3
) {
  for (let attempt = 0; attempt < maxRetries; attempt++) {
    const order = await db.orders.findById(orderId);

    if (order.status !== "pending") {
      return { status: "already_processed" };
    }

    const updated = await updateOrderStatus(
      orderId,
      "processing",
      order.version
    );

    if (updated) {
      // 成功抢到更新权后，再继续执行业务逻辑
      await fulfillOrder(order);
      return { status: "success" };
    }

    // 冲突后回读并退避重试，避免热点资源被持续打爆
    await sleep(Math.pow(2, attempt) * 10);
  }

  throw new Error("Max retries exceeded due to concurrent modifications");
}

Go 版本用 database/sql 也是同一个套路：

func updateOrderStatus(ctx context.Context, db *sql.DB, orderID, newStatus string, expectedVersion int) (bool, error) {
    result, err := db.ExecContext(ctx,
        `UPDATE orders SET status = $1, version = version + 1, updated_at = now()
         WHERE id = $2 AND version = $3`,
        newStatus, orderID, expectedVersion,
    )
    if err != nil {
        return false, err
    }

    rows, err := result.RowsAffected()
    return rows == 1, err
}

这种方案特别适合下面几类场景：

冲突概率本来就不高，大多数请求操作的是不同资源。
业务操作支持安全重试。
你更在意吞吐量，不希望每次都先走一次显式加锁。

但它并不适合高竞争场景。因为一旦热点资源被大量并发修改，失败请求会不断回读、重试，反过来把数据库压力继续放大。

CAS 模式

CAS（Compare-And-Swap）可以理解成把乐观锁的思想扩展到数据库之外。只要底层存储支持条件写入，就能实现类似效果。下面是一个基于 DynamoDB 条件表达式的例子：

import { DynamoDBClient, UpdateItemCommand } from "@aws-sdk/client-dynamodb";

const ddb = new DynamoDBClient({});

async function claimTask(taskId: string, workerId: string): Promise<boolean> {
  try {
    await ddb.send(
      new UpdateItemCommand({
        TableName: "tasks",
        Key: { id: { S: taskId } },
        UpdateExpression:
          "SET #status = :claimed, worker_id = :worker, claimed_at = :now",
        ConditionExpression: "#status = :unclaimed",
        ExpressionAttributeNames: { "#status": "status" },
        ExpressionAttributeValues: {
          ":claimed": { S: "claimed" },
          ":unclaimed": { S: "unclaimed" },
          ":worker": { S: workerId },
          ":now": { S: new Date().toISOString() },
        },
      })
    );
    return true;
  } catch (err: any) {
    if (err.name === "ConditionalCheckFailedException") {
      return false; // 任务已经被其他 worker 抢走
    }
    throw err;
  }
}

CAS 也是分布式状态机、领导者选举和很多共识协议的基础能力。像 etcd、ZooKeeper、Consul 这类系统，本质上都提供了条件更新或版本校验这一类原语。

锁竞争与性能

锁的代价从来不只是加锁那一瞬间。只要你引入了锁，就等于主动把一部分访问串行化了；一旦竞争上来，锁就会从保护机制变成吞吐瓶颈。工程上可以优先做 5 件事：

1. 缩小锁粒度。 能锁 payment:order-123，就不要锁整个 payments 资源池。

// Bad: 全局锁，所有支付请求都会互相阻塞
await acquireLock("payment-processing", 10_000, ownerId);

// Good: 细粒度锁，只串行化同一订单
await acquireLock(`payment:${orderId}`, 10_000, ownerId);

2. 缩短持锁时间。 把校验、准备、发消息这些非关键步骤尽量放到锁外面，只在真正变更共享状态的那一小段时间里持有锁。

// 锁外先完成参数校验和上下文准备
const validatedPayment = await validatePaymentDetails(request);
const idempotencyKey = deriveIdempotencyKey(request);

// 只在状态变更期间持有锁
const lock = await acquireLock(`payment:${orderId}`, 5_000, ownerId);
try {
  const order = await db.orders.findById(orderId);
  if (order.status !== "pending") return;
  await db.orders.update(orderId, { status: "paid" });
} finally {
  await lock.release();
}

// 收据发送等后置操作放到锁外执行
await sendReceipt(validatedPayment);

3. 优先考虑无锁设计。 幂等键、唯一约束和 CAS 在很多业务里比显式锁更稳，也更容易扩展。

4. 监控锁指标。 至少要持续看获取耗时、持锁时长、争用率和超时次数。锁等待时间突然飙升，通常说明设计出现了热点，而不是单纯机器变慢。

5. 设置严格超时。 对多数 Web 请求来说，1~2 秒的锁等待上限已经很常见。等太久通常没意义，尽快失败反而更容易保护系统。

如何选择合适的方案

方案	最适合的场景	基础设施	一致性特征
Redis `SET NX EX`	通用型、高吞吐量场景	Redis	单节点级耐久性
Redlock	需要跨节点提升安全性的 Redis 场景	5 个 Redis 节点	多数派保证
PostgreSQL 建议锁	以数据库为中心的工作流	PostgreSQL	事务一致性强
乐观锁	低冲突、少量写入场景	任意关系型数据库	行级版本校验
CAS	Serverless、多区域、托管存储场景	托管服务	依赖底层服务能力

如果你需要一个简单的决策框架，可以按下面这个顺序判断：

如果冲突本来就少，而且业务支持重试，优先考虑乐观锁。 它实现最轻，扩展性通常也最好。
如果关键区天然和数据库事务绑定，而且系统已经在重度使用 PostgreSQL，优先考虑建议锁。 事务级建议锁尤其干净。
如果你需要的是通用分布式互斥，且能接受少量故障窗口里的重复执行风险，可以先上 Redis SET NX EX。
如果双重执行的代价极高，比如金融扣费、资源分配，再考虑 Redlock 或 etcd / Consul 这一类更强协调方案。
真正稳健的生产系统，往往不是单层防线。 分布式锁负责减少并发冲突，数据库约束负责兜住极端情况，这样才更像工程方案。

多层防线的典型写法如下：

async function processPaymentSafely(orderId: string, amount: number) {
  // Layer 1: 分布式锁，先挡住同一订单的并发处理
  const lock = await acquireLock(`payment:${orderId}`, 10_000, randomUUID());
  if (!lock.acquired) throw new Error("Payment in progress");

  try {
    // Layer 2: 数据库状态检查，避免重复处理
    const order = await db.orders.findById(orderId);
    if (order.status !== "pending") return { status: "already_processed" };

    const charge = await paymentGateway.charge(order.customerId, amount);

    // Layer 3: 唯一约束兜底，防止重复写入账单记录
    await db.orders.update(orderId, {
      status: "paid",
      chargeId: charge.id, // schema 中应对 chargeId 建唯一约束
    });

    return { status: "success" };
  } finally {
    await lock.release();
  }
}

总结

分布式并发控制里，最危险的误区不是不会加锁，而是把锁当成唯一答案。很多时候，我们真正想要的并不是某个技术名词本身，而是并发场景下的正确性。

如果你的场景比较常规，Redis 的 SET NX EX 配合 owner 校验，已经能覆盖大多数需求；如果系统本来就以数据库为中心，PostgreSQL 建议锁往往更自然；如果冲突很少，乐观锁和 CAS 甚至可以完全替代显式锁。

真正靠谱的方案，通常不是追求最重的锁，而是在锁、幂等、唯一约束和条件更新之间做组合。这样即使某一层失效，系统也不至于直接滑向错误结果。

FunTester 原创精华

我用 claude code 写了一个 claude code，欢迎大家来使用

NiMail — Fri, 17 Apr 2026 21:51:52 +0800

Claude Code Panel 是一款多模型 AI 对话面板，集成智谱（GLM）、Kimi、DeepSeek、通义千问、Claude 等主流模型，为开发者提供统一的 AI 编程助手入口。以下基于产品界面，逐一介绍其核心功能。

一、首页概览

顶部推荐区：突出 “AI 工具强烈推荐” 与 “CLAUDE CODE”，引导用户快速了解产品定位。

快捷操作按钮：

新建 CLI 会话：一键启动命令行交互会话。

配置 API Key 和模型：快速完成服务商认证与模型选择。

配置 Claude Code Agent 模式：开启自动化代理能力。

服务商展示：明确列出支持的 7 个服务商，涵盖主流大模型厂商。

底部菜单导航：包含 “首页”、“配置”、“规则”、“命令速查”、“技能”、“会话历史”、“插件”、“MCP”、“对话” 等入口，方便在不同功能模块间切换。

右侧模型列表：详细展示智谱（GLM）系列模型（如 GLM-5.1、GLM-4.6 深度思考、免费版 Flash 等）以及月之暗面（Kimi）系列模型（如 Kimi K2.5、Kimi for Coding 等），支持按需选择。

二、插件管理

插件市场：支持从在线市场一键安装，或手动添加本地插件。

分类筛选：可按 “全部”、“产品”、“开发”、“文档”、“规范”、“插件”、“MCP” 等标签过滤。

插件卡片示例：

PM 产品经理技能包：包含需求分析、用户故事、PRD 文档等 33 个产品管理技能。

Superpowers 增强包：开发和调试增强工作流，如快速原型、错误追踪。

SpecKit 规格工具包：规格驱动开发工具，支持从需求到实现的完整工作流。

API 开发助手：REST/GraphQL API 开发全流程支持。

自动化测试套件：单元测试、集成测试、E2E 测试生成与运行。

代码风格守护：ESLint/Prettier 配置、命名规范检查与自动修复。

已配置状态提示：右上角显示当前使用的模型（如 “智谱 GLM-5.1”）及 “Key 已配置”，确保可用性。

三、技能管理

技能市场：类似插件管理，但面向 “斜杠命令” 技能，支持从市场安装或手动管理自定义命令。

分类标签：包括 Git、审查、测试、文档、重构、调试、安全、性能、部署等。

技能卡片示例：

Git 提交助手（2,340 次安装）：自动分析代码变更，生成规范 commit message。

代码审查（1,890 次安装）：全面代码质量、规范、安全审查。

TDD 测试驱动（1,250 次安装）：遵循 TDD 流程（先写测试→运行失败→编写代码）。

需求规格文档（980 次安装）：根据描述自动生成详细需求文档、用户用例。

智能重构（1,560 次安装）：识别坏味道，提供重构建议并自动执行。

文档生成器（-）：生成 JSDoc/TSDoc、README、API 文档。

调试助手、安全审计、性能优化等专业技能。

已安装标识：如 “Git 提交助手” 显示 “已安装”，其他可点击 “安装”。

四、对话界面

CLI 会话窗口：显示当前工作目录（如 F:\vhosts\www\python\www.nimail.cn）、需授权状态、思考过程。

输入框：支持自然语言描述任务，或使用 /cmd 执行 shell 命令（Enter 发送，Shift+Enter 换行）。

右侧模型与配置状态：明确显示当前激活的模型（如 “智谱 GLM-5.1”）和 “Key 已配置”，让用户随时掌握环境。

五、会话历史

历史会话列表：展示所有会话记录，包含会话标题（如 “111”）、状态（活跃）、消息数量（0 条）、最后活动时间及创建时间。

搜索功能：支持按会话标题、模式或目录快速检索。

导航一致性：底部菜单与全局保持一致，方便切换。

六、命令速查

命令速查中心：提供 Claude Code CLI 的完整命令、参数和内置工具参考。

分类视图：分为 “斜杠命令”、“CLI 参数”、“内置工具”。

常用斜杠命令示例：

/help：显示帮助信息及所有可用斜杠命令。

/clear：清空当前对话历史。

/compact：压缩上下文，减少 Token 使用。

/config：查看和编辑配置。

/cost：显示当前会话费用统计。

/doctor：检查安装状态和环境配置。

/init：初始化项目配置。

快速检索：支持按命令、参数或描述搜索，提升操作效率。

最后

Claude Code Panel 不仅仅是一个对话面板，更是一套完整的 AI 开发辅助平台。它通过：

多模型统一接入（7 大服务商）

插件与技能市场（一键安装、分类管理）

CLI 会话与命令速查（高效交互）

会话历史与配置管理（持续使用）

为开发者提供了从模型选择、技能增强到日常开发任务执行的闭环体验。无论是需求分析、代码审查、测试驱动开发，还是 API 文档生成、性能优化，都能在统一界面中完成，极大提升开发效率。

下载地址：

https://www.nimail.cn/blog/best-articles/claude-code%e9%9d%a2%e6%9d%bf%e5%b7%a5%e5%85%b7%e4%bb%8b%e7%bb%8d/

StepAudio 2.5 TTS：将语境理解能力引入语音生成全流程；阿里世界模型 Happy Oyster：实时世界创建与交互丨日报

RTE — Fri, 17 Apr 2026 10:19:35 +0800

开发者朋友们大家好：

本期编辑：@koki、@ 鲍勃

01 有话题的技术

1、Google 发布 Gemini 3.1 Flash TTS 模型，高音质与低成本平衡

Google 推出新一代文本转语音（TTS）模型 Gemini 3.1 Flash TTS。该模型通过引入自然语言「音频标签」实现了对语音风格、节奏和多角色交互的精细化控制，在维持低延迟与低成本的同时，显著提升了合成语音的表现力。

基准测试性能：在 Artificial Analysis TTS 排行榜取得 1,211 Elo 评分，位居高音质与低成本平衡点的「最具吸引力象限」。
内联音频标签（Audio Tags）：支持将自然语言指令（指令式标签）直接嵌入文本输入，实现句子中途的语速、音调、口音和情感状态的毫秒级切换。
场景化编排（Scene Direction）：开发者可定义环境背景与对话上下文，确保多角色在多轮对话中维持特定的人设一致性（In-character）与自然互动。
音频配置文件与代码导出：支持通过 Audio Profiles 固化角色特征，调节后的参数可直接导出为 Gemini API 调用代码，确保跨平台部署的语音一致性。
全球化与安全合规：原生支持 70 多种语言；所有输出音频均强制嵌入 SynthID 不可感知水印，用于 AI 生成内容的溯源与检测。

参考链接：

https://blog.google/innovation-and-ai/models-and-research/gemini-models/gemini-3-1-flash-tts/

( @google blog)

2、Cloudflare 发布 @cloudflare/voice：为智能体提供原生语音管道，支持单 WebSocket 流式交互与 SQLite 状态持久化

Cloudflare 为其 Agents SDK 推出实验性扩展包 @cloudflare/voice，允许开发者在不改变现有智能体架构的前提下，为基于 Durable Object 的 Agent 直接添加实时语音能力。该工具链通过减少跨服务跳转和引入流式分句合成技术，显著降低了语音交互的端到端延迟。

基于 Durable Object 的统一状态模型：语音被视为与文本对等的输入流，共享相同的 Agent 类实例、Durable Object 生命周期及内置的 SQLite 会话历史。开发者无需为语音功能构建独立的后端架构，即可实现文本与语音输入的无缝切换。
优化的流式传输与低延迟响应：客户端通过单一 WebSocket 连接流式传输 16 kHz 单声道 PCM 音频；服务端支持「sentence-chunking」技术，即在 LLM 输出流式文本时同步进行按句合成，实现首包音频（TTFA）的快速响应。
内置 Workers AI 驱动程序：预集成 Deepgram 系列模型，包括用于实时对话的 Flux STT、用于高精度听写的 Nova 3 STT 以及 Aura TTS。通过 Workers AI 绑定直接调用，开发者无需管理外部 API 密钥即可完成实时语音转录与合成。
多协议适配与 Provider 接口抽象：提供 withVoice（全双工对话）和 withVoiceInput（仅听写/语音搜索）两种高阶组件；内置 Twilio 适配器以支持电话回呼；同时开放轻量级 Transcriber 和 TTSProvider 接口，支持开发者对接 AssemblyAI、Cartesia 或 WebRTC 传输层。

(@cloudflare)

3、阿里 ATH 事业群发布世界模型产品 Happy Oyster，主打实时世界创建与交互，可生成动态三维环境，支持影视制作、游戏开发等场景

阿里巴巴 ATH 事业群推出开放式世界模型产品「Happy Oyster」，主打实时世界创建与交互。

该产品可生成动态三维环境，支持影视制作、游戏开发等场景。其与 HappyHorse 同属 ATH 旗下 AI 创新事业部。目前已开启内测，用户可通过官网 happyoyster.cn 加入候补名单。

Happy Oyster 基于原生多模态架构，其背后是支持多模态输入与音视频联合生成的流式生成世界模型。

加入等候列表：happyoyster.cn

（@ 潇湘晨报）

4、阶跃 StepAudio 2.5 TTS 上线，将语境理解能力引入语音生成全流程

今天，阶跃正式发布新一代语音生成模型StepAudio 2.5 TTS。围绕全局语境控制、文中语境控制、零样本复刻与全音色控制三项核心能力，StepAudio 2.5 TTS 让语音生成更自然、更灵活也更有表现力。

全局语境控制：支持自定义整段语音的情绪基调、角色状态与场景氛围，使表达更统一、更连贯。
文中语境控制：不仅能控制一句话怎么说，还能进一步调节语气、节奏、停顿、轻重变化、角色感和场景感，让声音表达更有分寸。
适配多场景、多人设：StepAudio 2.5 TTS 支持 Zeroshot TTS，任意用户音色无需重新训练，即可满足从沉浸式有声书到专业影视配音全场景高品质语音生成需求。同时也可为每个音色构建完整的「声音角色档案」，实现从声纹到人格的全面提升。

无论是角色配音、有声内容创作，还是智能语音交互，StepAudio 2.5 TTS 都能帮助开发者和创作者更高效地生成自然、细腻、接近真人的语音内容。

文档：

https://platform.stepfun.com/docs/zh/guides/models/stepaudio-2.5-tts

（@ 阶跃星辰）

02 有亮点的产品

1、X 独立通讯应用「X Chat」重新上线语音消息功能

社交平台 X（原 Twitter）近日宣布，其私密消息服务「X Chat」已正式恢复对「语音笔记（Voice Notes）」功能的支持。用户现在可以在一对一私信和群聊中，再次畅快地发送音频消息。

据悉，在此前 X Chat 的升级中，语音功能的短暂移除曾引发部分用户不满。如今功能回归，用户只需按住聊天文本框右侧的麦克风图标即可录音，或者通过「长按并向上滑动」的手势实现免提录制。

这一变动背后，折射出 X 平台产品战略的微妙转变。此前，埃隆·马斯克（Elon Musk）曾多次强调要将 X 打造成一个无所不包的「万能超级应用（Everything App）」。然而近期，X 似乎正倾向于将核心功能剥离，提供独立的 App 体验。除了近期已作为独立应用运营的 X Chat 外，其支付服务「X Money」目前也正在作为独立 App 进行测试。

业内分析认为，X Chat 恢复语音消息，是其作为独立通讯应用补齐基础体验、增强市场竞争力的必要举措。目前，X Chat 已配备消息编辑/删除、音视频通话及截图通知等主流通讯功能。

( @TechCrunch)

2、Fathom 发布 botless 会议模式：支持视频录制并集成 MCP

Fathom 推出重大更新，允许用户在无需 AI 助手（Bot）进入虚拟会议室的情况下完成录制与转录。该版本通过系统级采集解决了会议室「过度拥挤」的问题，并首次引入 Model Context Protocol（MCP）支持，将会议数据转化为可供外部 AI 工具调用的结构化上下文。

Bot-less 录制与原生视频采集：区别于 Granola 等竞品仅抓取音频，Fathom 支持在无机器人模式下同步录制视频，并提供多种录制模式选择。
优化发言人辨识（Speaker Diarization）：通过模型更新，解决了多月前历史会议记录中常见的「发言归属错误」问题，提升了长周期上下文检索的准确性。
集成 Model Context Protocol（MCP）服务端：发布 MCP Server 接口，允许开发者和用户将 Fathom 存储的会议数据直接接入各类支持该协议的 AI 智能体或工作流工具。
全量会议数据库 AI 查询：新增针对企业级用户的统一查询接口，支持通过 AI 对整个会议历史数据库进行跨篇章的语义搜索与背景关联。

( @TechCrunch)

3、药房技术服务商 Lumistry 发布 Voice AI 助手：对话式 AI 替代数字按键 IVR，深度集成 PMS 实现处方自动化处理

药房技术服务商 Lumistry 推出 Voice AI 助手，作为其 Lumistry Voice 通信套件的核心组件。该产品旨在利用对话式 AI 彻底取代传统的数字按键式 IVR 系统，通过与药房管理系统（PMS）实时联动，实现自动化的处方续订与状态查询。

从 DTMF 向自然语言交互（NLI）演进：放弃传统的菜单式数字按键逻辑，支持患者以自然语言描述需求，系统可自动识别并执行处方状态查询、药房营业信息咨询等高频任务。
药房管理系统（PMS）深度集成：通过 API 接入主流 PMS，助手具备识别合规续订（Eligible Refills）的能力，并能直接在后台提交续订请求，无需人工干预处方处理流程。
多语言与人工平滑切换逻辑：系统支持多语种对话，并内置智能路由算法，在识别到复杂语义或非预设用例时，可将通话上下文同步推送至药房工作人员进行人工接管。
存量市场覆盖与迁移：该助手基于原 Vow IVR 架构升级，目前已整合进 Lumistry 覆盖的全美 9,000 多家药房服务网络，重点解决药房高峰期 70% 以上的重复性行政呼入压力。

( @Yahoo Finance)

03 有态度的观点

1、领英 CEO：AI 时代，这四项软技能正在升值

领英 LinkedIn CEO Ryan Roslansky 近日在接受《工具和武器》播客采访时表示，随着 AI 加速接管职场中的重复性工作，人类的「软技能」正在获得前所未有的重视。

他具体点名了四项以沟通为核心的能力：好奇心（curiosity）、勇气（courage）、沟通力（communication）与同理心（compassion）。

Roslansky 认为，AI 正在重塑人们理解工作的方式，推动职场人将自身角色视为「一系列任务的集合」，而非固定的职位头衔。

他将这些任务划分为三类：可被 AI 完全自动化的、可被 AI 辅助增强的，以及仍需人类主导的——如化解冲突、说服团队、制定战略等。

这些技能很重要，但过去一直被称为软技能......在一个人们真正精通这些技能的职业世界里，我认为一切都会变得更好。

他表示，随着 AI 智能体承担更多自动化职责，人们将有更多时间用于同事之间的真实沟通，这进一步抬高了沟通能力、判断力与情商的溢价。

有时候当你深陷技术之中，尤其是 AI，当你勾勒出它可能走向的方向，会把你带到一些黑暗的地方。但我相信，人类在塑造这项技术的走向上扮演着不可或缺的角色。

( @APPSO)

写在最后：

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

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

用 AI 进行测试如果还想着怎么让以前的平台变的更美，那还是多去体验一下 AI IDEA 吧，真体验后一切都是徒劳

no_coriander — Fri, 17 Apr 2026 10:09:12 +0800

看了一下最近的文章都是做怎么怎么样的测试平台，其实和我前段时间的想法很类似，其实除了少部分需要对外展示的内容。以及流程串联自动触发外。
什么用例生成（功能、接口、ui、性能）你真的需要一个界面吗？毫无意义，你可以在完成整体逻辑后让 AI 给你随便写一个页面，但是把重心放到平台内容开发上真的是本末倒置，又重又烂。你想要的功能用例生成，几个 skills 几句话的调整就完成输出了。在随便哪个现在主流的 AI IDEA 上都能完成，并且体验远超你搞半天的 prompt，注意现在去搞所谓的 prompt 已经落伍了，是被淘汰的产物，不是 prompt 不重要，而是他不是你需要关注的重点了。时代就是演变的如此之快几个月前大家还在疯狂的讨论这些，现在呢它已经在垃圾箱了。所以你现在的平台你觉得他 2 个月后抗的住 AI 的迭代吗？

最后，深度去体验现代的多种 AI IDEA 你就明白，那些都是垃圾，都是时代的遗物罢了，谁先想明白这点，谁就能早一步上水。至于测试一直津津乐道的测试平台，让它早点消失吧，与其把重心放交互不如想想你到底要做些什么。

Visual Agent 是什么？最了解视觉智能体的一群人都来杭州了｜聊聊 Context Awareness 和 Visual Agent，Physical AI Camp 杭州站

RTE — Fri, 17 Apr 2026 09:50:52 +0800

「现代 AI 最让我着迷的一点是，它让我们得以用数学和哲学的方式，去触碰那些隐藏在人类互动背后的无形变量：AI 让『vibes』（氛围/感觉）变得可读、可理解。」

——Vitalik Buterin，以太坊创始人

4 月 25 日（周六）下午，RTE Meetup 落地杭州。

如果一个 Agent 不仅能看清眼前画面，更能瞬间捕捉你忽略的周边细节与上下文，会发生什么？

从桌面端的屏幕理解到可穿戴设备，能够 Always on 且实时捕获环境数据的 Visual Agent（视觉智能体）正成为人机共同体感知物理世界的关键。

随着多模态模型的发展，获取真实世界的 Context（如视觉、音频或意图）已不再是技术瓶颈。

但拿到海量 Context 之后呢？

多模态感知不等于真实需求。 如何让 Context 与产品和市场真正契合？在哪些场景下，看懂 Vibes 才是不可替代的刚需？这才是决定下一代交互成败的必答题。

我们邀请了 蚂蚁百灵大模型、声网、Chance AI、声绘未来、湃启科技、Rokid 与 Cerul.ai 的技术专家及创始人，一起聊聊当 Agent 看得见 Vibes 时，Context Awareness 的畅想与现实。

关于 Physical AI Camp·超音速计划 2026

本次 RTE Meetup 也是「Physical AI Camp·超音速计划 2026」杭州站。

我们的创业营已经正式开启报名，目前正在招募 Voice Agent、Physical AI 和实时多模态 AI 领域的创业团队。营期内，我们将为入营项目提供技术资源支持、投融资对接，以及行业头部展会的展位资源。更重要的是，在这里你将和一群志同道合的伙伴共同探索。

报名截止日期：2026年4月20日24:00
了解超音速计划并报名： https://physical-ai-camp.vercel.app/

RTE Meetup 议程

13:30 - 14:00 丨签到与自由交流
14:00 - 14:10 丨 Intro：超音速计划 2026·Physical AI Camp 介绍
14:10 - 15:10 丨 Keynote 分享
- Visual Agent：从看得见到看得懂，还差什么？吴晓凡，Chance AI CTO
- 让 Agent 走出象牙塔，做那些用户觉得「很简单」的事孙思宁，声绘未来 & 浙江湃启科技联合创始人
- 迈向人机共生的交互终端杨天翼，Rokid AI 产品经理
- Teach Your AI Agents to See Jiaxi Cui（Panda），Cerul.ai Founder
15:10 - 15:40 丨圆桌讨论一：Building the Context ——Agent 视觉与感知技术底座
- 嘉宾
  - 彭晗，蚂蚁集团高级算法专家，百灵多模态大模型后训练算法负责人
  - 张乾泽，Agora Agent Platform Lead
  - 孙思宁，声绘未来 & 浙江湃启科技联合创始人
- 主持人： 杨慧 Cynthia Yang，RTE 开发者社区发起人
15:40 - 16:10 丨圆桌讨论二：Context-Product Fit —— 寻找多模态交互的真实场景
- 嘉宾
  - 吴晓凡，Chance AI CTO
  - 杨天翼，Rokid AI 产品经理
  - Jiaxi Cui（Panda），Cerul.ai Founder
- 主持人：傅丰元，RTE 开发者社区负责人
16:10 - 16:30 丨 Lightning Demo，带上你的软/硬件现场展示介绍
16:30 丨自由交流

活动信息

活动时间：2026年4月25日（周六）14:00 - 16:30（13:30 开始签到）
活动地点： 杭州西湖区灯彩街云谷中心
参与方式： 扫描二维码，或点击下方链接报名

https://www.rtecommunity.dev/t/t_AX7NzQwHnX6p2C

主办方： RTE 开发者社区、超音速计划

合作伙伴： 魔搭社区、云谷中心

社区伙伴： S 创、脑放电波、Bonjour!、Research AI+、小红书科技、WAIC UP！、启师傅 AI 客厅、分子分母、机智流

💡 我们也新开了一个「Physical AI+ 多模态」微信群，欢迎关注 AI 硬件、跨平台开发、语音交互、视觉理解等方向的伙伴申请加入！

加微信 Creators2022，备注身份和来意（公司/项目 + 职位/技术栈 + 加 Physical AI 群），备注完整者优先入群。

StackChan 开启国内预售，支持 AI 视听交互和二次开发；Avoko 上线 Agent-to-Agent 访谈平台，主要服务 To-Agent 产品和基建丨日报

RTE — Thu, 16 Apr 2026 22:33:07 +0800

开发者朋友们大家好：

本期编辑：@koki、@ 鲍勃

01 有话题的技术

1、专为语音、环境声和音乐理解而设计，NVIDIA 联合发布 Audio Flamingo Next，支持 128K 音频上下文

NVIDIA 与 马里兰大学 的研究团队最近联合发布了下一代开源大型音频语言模型 Audio Flamingo Next（AF-Next）。该模型专为语音、环境声和音乐理解而设计，原生支持最长 30 分钟的复杂音频输入及高达 128K token 的上下文长度。

此次发布包含三个针对不同场景优化的变体：适用于问答、聊天和 ASR 的默认版本 AF-Next-Instruct；专注于基于时间戳进行分步时间推理的 AF-Next-Think；以及用于生成更密集长篇描述的 AF-Next-Captioner。

基于包含约 1.08 亿个样本和约 100 万小时音频的大规模数据集训练而成，该系列模型通过引入 Temporal Audio Chain-of-Thought 和 Rotary Time Embeddings（RoTE）技术，显著提升了长音频的时间归因推理能力。

目前，这三个 8B 参数的模型权重已在 Hugging Face 上线，但仅限非商业研究用途。

https://huggingface.co/nvidia/audio-flamingo-next-hf

（@ 橘鸦 Juya）

2、World Labs 开源 Spark 2.0：基于连续式 LoD 与虚拟显存实现亿级点云 3DGS 网页端流畅渲染

智东西 4 月 15 日报道，今天，李飞飞的世界模型团队 World Labs 开源了 动态 3D 高斯泼溅（3DGS）渲染器 Spark 2.0。

李飞飞本人在该成果发布的第一时间评论称：「Spark 2.0 现在可以在任意设备上流式传输超过 1 亿个高斯泼溅！能够为基于网页的 3DGS 渲染开源生态做出贡献，我们感到无比自豪！」

Spark 系列模型于去年首次发布，是一个专为网页构建的动态 3D 高斯泼溅（3DGS）渲染器。它与网页端最流行的 3D 框架 THREE.js 集成，并利用 WebGL2 在任意带有网页浏览器的设备上运行，包括桌面端、iOS、Android 以及 VR 设备。

与上一版本相比，Spark 2.0 新增了一套细节层级（LoD）系统，能够在任意设备上流式传输并渲染超大规模的 3DGS 世界。

此外，新版还使用了。RAD 的 3DGS 文件格式，支持渐进式细化的流式传输，而虚拟泼溅分页系统则通过固定的 GPU 内存分配，实现了对无限泼溅世界的访问，通俗来讲就是可以渲染无限大的 3D 场景。

如此流畅连贯的效果是怎么实现的？针对大规模场景的扩展难题，Spark 2.0 运用了 3 项图形学与系统底层方案：细节层次优化、渐进式流式加载以及虚拟显存管理。

（@ 智东西）

02 有亮点的产品

1、谷歌 Gemini 推出交互式模拟功能，支持用户自定义可视化

谷歌旗下 AI 助手 Gemini 近日正式推出交互式模拟生成功能，目前已面向全球用户开放。该功能允许用户在对话中直接将复杂问题转化为可操作的定制化视觉模型，实现从静态文本与图表向功能性动态模拟的跨越。

当用户使用「show me」或「help me visualize」等指令探索复杂概念时，系统将生成相应的交互式模拟程序。

以「月球绕地运行」为例，用户不再局限于观看固定示意图，而是能够通过手动调节滑块或输入精确数值，实时改变初始速度、引力强度等变量，直观观察不同参数对轨道状态的影响。这种即时交互机制显著提升了用户对复杂物理系统与逻辑的理解深度。

目前，该功能已集成于 Gemini App 中。用户需访问 gemini.google.com，选择提示栏中的 Pro 模型并输入相应指令即可体验。此次升级标志着 AI 辅助工具在科学探索与工程模拟领域的应用能力进一步增强。

（@ 极客公园）

2、预售开启 | StackChan 正式登陆淘宝！

在 Kickstarter 上线即被官方评选为「Project We Love」，4,142 位支持者共同认购 HK$ 3,582,197，众筹完成率高达 4593% —— StackChan，现在正式开启淘宝预售！

无需登录 Kickstarter，国内开发者和爱好者们，现在即可前往淘宝 M5Stack 企业店铺 抢先预售下单，30 天内发货！

StackChan 不仅有可爱的外表，更有硬核的内心：

搭载 M5Stack CoreS3，ESP32-S3 强劲驱动
内置 30 万像素摄像头与接近传感器，2.0 英寸电容式触摸屏、9 轴 IMU。
双麦克风 +1W 扬声器，支持语音对话与 AI 交互。
具备 microSD 卡槽，支持海量数据存储与离线资源调用。
双反馈舵机，支持水平 360°连续旋转及俯仰，表情生动。
全功能 NFC、12 颗 RGB 灯珠、红外收发器、三区触摸面板。

这套扎实的硬件组合，为 StackChan 的视听交互提供了坚实的底层支撑，也为自主拓展无限设计提供了助力。

(@M5Stack)

3、Avoko 上线 Agent-to-Agent 访谈平台：支持并发对话收集与结构化行为洞察

Avoko 发布了一个面向 AI 智能体的双边质性研究平台。该平台通过大规模自动化并发访谈，帮助开发者直接观察智能体在具体任务中的交互逻辑、推理过程和决策边界，并自动生成结构化洞察报告，主要服务于 To-Agent 产品及基础设施的开发。

指令级快速接入：研究者和参与者可通过向 Agent 发送特定 Skill 指令快速完成智能体注册、技能安装和环境初始化，整个过程无需复杂配置。
智能匹配与自动化调度：研究者以自然语言描述目标后，平台自动生成访谈大纲，并根据智能体的相关性、专业性及声誉进行智能排名，实现精准匹配与大规模并发调研。
记忆 grounding 与行为洞察：每条回答均基于智能体的真实身份和历史记忆生成，而非通用 LLM 输出；访谈同时捕获推理链路、决策边界及边缘情况，确保数据的真实性和可靠性。
自动化质量控制：内置 Quality Engine 对每条回答进行自动评分并开展长期声誉追踪，低质量响应将被自动过滤，无需人工审核即可保证研究报告的高可靠性和分析价值。
多层安全与隐私防护：每条访谈问题在送达智能体前自动扫描提示词注入、角色覆盖、越狱尝试及社会工程学模式；同时对响应进行隐私风险评分；检测到威胁时立即自动中断访谈、撤回智能体并强化防护，检测准确率达 97.3%，实现零人工干预的全自动化安全保护。
双边激励机制：除了对研究者的工具价值，Avoko 还具备双边平台属性。智能体拥有者可将自己的 Agent 作为参与者接入平台，通过完成访谈任务获得现金报酬（PayPal 提现），所得高于 Token 消耗。

Avoko 同时启动了面向开发者的「48 小时 Interview Agents Challenge」。挑战赛提供了五类 Agent 访谈话题，包括：

基础设施工具调用（Git CLI、终端、API）
模糊或冲突指令的决策边界
错误恢复模式
长上下文推理与记忆一致性
智能体决策风格（独立推进 vs 寻求澄清）

提交最优质报告的前 5 名研究者将分别获得 1 张 $500 Apple Gift Card，这些研究中的参与者则有机会获得 10 倍礼金奖励。挑战赛报名：https://luma.com/mnh0ixwi

官方 Discord 社区：

https://discord.gg/AruSKwNg

官网：https://avoko.ai

（ @AvokoAI\@X、Avoko 官网）

03 有态度的观点

1、多名被 AI 偷声音的配音演员发声，「太乙真人」配音者张珈铭称被抢商单影响生计

IT 之家 4 月 13 日消息，多位知名配音演员近日相继发布声明，对 AI 配音侵权的行为予以谴责，并呼吁抵制 AI 仿声。

据九派新闻 4 月 10 日报道，《哪吒》系列动画电影「太乙真人」配音演员张珈铭表示，他为制止 AI 盗声，投入不少钱用于搜集证据，发起维权，却因侵权主体多为未成年人，法律追责受阻等现实难题，至今无一例起诉成功。

多名被 AI 偷声音的配音演员发声，「太乙真人」配音者张珈铭称被抢商单影响生计

报道提到，张珈铭从去年年底就发现自己的声音被大量盗用，在他塑造的声音形象中，被侵权最多的是太乙真人的声线。相关侵权数量非常多，他曾在一天中统计过具体数量，仅这一天内，就超过 700 例。这已经直接影响到了他的生计。「已经有合作伙伴明确表示，现在有很多 AI 声音和我相似，甚至可以免费使用，因此选择不再与我合作，有三个商单就是这样被取消的。」张珈铭说。

此外，为哪吒配音的吕艳婷、为甄嬛配音的季冠霖等配音演员，均遭遇过声音被盗用的情况。

今年 3 月，国内主攻游戏和动漫配音领域的公司 —— 上海奇响天外文化传播有限公司（简称「奇响天外」）发布声明函，宣布坚决反对任何违法使用人工智能技术的侵权行为。

奇响天外表示，旗下诸多艺人在近年来，长期饱受大量违法使用人工智能技术的侵权行为之困扰，该公司亦是国内率先对违法使用人工智能技术的侵权行为采取司法救济手段以维权的主体之一，虽然过程几经周折，充满阻碍与挑战，但经多番努力，目前相关案件已完成庭审，后续等待司法裁判，该公司亦将根据相关裁判结果继续推进维权工作。

IT 之家注意到，中国广播电视社会组织联合会演员委员会于 4 月 2 日发布严正声明称，凡可关联特定公众演员的 AI 撞脸、仿声演绎、换脸短剧、商业植入、虚拟人复刻、素材二创改编等侵权内容，即便标注「非商用」「公益分享」「个人二创」等字样，均不构成合法免责依据，仍需承担全部侵权责任。

（@IT 之家、九派新闻）

写在最后：

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

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

AI 帮我卷死了测试用例

qearl — Thu, 16 Apr 2026 20:47:43 +0800

以前先写提示词，然后手动复制需求给 ai，久了就不回复了，新开会话生成的又不符合格式，总是不能解放双手，
搭建了 Playwright + OpenAI + Google Sheets API 自动生成用例后，简直是解放双手，只要 token 够用，1 天写完整个系统的用例都行

写用例就 2 步
1、读 readme.md
2、磨刀链接
坐等用例生成，还能进行需求评审，有问题的进行标记
就算 ai 超时，下一次让它读 readme.md 再开始干活，还是一样的聪明，再也不用担心没时间写用例了，不过话说这样给项目加测试资源的希望又泡汤了。。。

笔记：理解纳米机器人 nanobot（类 OpenClaw Agent）

Fun_Fox — Thu, 16 Apr 2026 17:05:52 +0800

nanobot 源码深度解析与问题诊断

前言

近期在飞书平台部署了两个 nanobot 实例，经过三天的深度使用与源码研读（配合 AI 辅助），针对运行中遇到的实际问题进行了逻辑梳理。本文旨在记录核心架构理解及发现的潜在问题。

1. 建议阅读区域

Agent 核心与提示词注入

Agent 模块结构	提示词模板目录

2. 运行期间 API 调用上下文

通过抓包观察不同业务场景下的 Prompt 组装过程：

普通用户对话	Channel 渠道消息处理

Heartbeat 心跳检测	Dream 梦境记忆整理 (Phase 1 & 2)

核心一：System Prompt 组装工厂

身份定义与引导文件

identity.md (基础人设)	AGENTS.md (工作区规范)

Active Skills（常驻技能加载）

技能加载逻辑	技能内容示例

核心二: 上下文治理（Context Governance）流水线

流程概览	详细执行步骤

文件读取去重（Deduplication）与安全隔离

文件去重标记逻辑	防 Prompt 注入 “免责声明”

核心三： Dream（记忆整理服务）

两个处理阶段	游标（Cursor）追踪机制

游标存储位置

5. 总结与发现的问题

架构总结

nanobot 将会话分为定时任务会话和用户交互会话，统一存储在 workspace\sessions 目录下。

数据处理闭环：

历史归档：自动检测并压缩工具调用的冗余输出，将长对话摘要后存入 workspace\memory\history.jsonl。
记忆提炼：Dream 进程定期扫描 history.jsonl，提取关键事实转化为长期记忆（MEMORY.md）或自动化技能（skills/）。
安全与优化：内置了文件读取去重、Prompt 注入隔离等机制以保障稳定性。

待解决的 Bug / 疑点

在双实例并行运行的环境下，观察到以下 4 个异常现象：

Token 预算判断失效：上下文压缩逻辑（Consolidation）未能按预期触发，疑似 context_window_tokens 的估算或边界检查存在逻辑漏洞。
文件去重状态不一致：file_state 缓存标记文件已读，但实际发送给 LLM 的上下文中该文件内容已被裁剪（Snipping）丢失，导致 AI 无法获取必要信息却仍被阻止重新读取。
路径解析兼容性：偶发读取错误文件地址的情况，可能与 Windows 环境下的路径分隔符处理或模型对相对路径的理解偏差有关。
心跳文件职能重叠：HEARTBEAT.md 似乎已失去独立存在的意义，其记录的周期性任务状态正逐渐被 MEMORY.md 的记忆提取功能所覆盖。

电子、电路与信息工程国际学术会议分享

leisigoule — Thu, 16 Apr 2026 16:06:31 +0800

第六届电子、电路与信息工程国际学术会议（ECIE 2026）

2026 6th International Conference on Electronics, Circuits and Information Engineering

ISBN 号：979-8-3315-8239-5

议题投稿入口：https://ais.cn/u/qm6vUf

大会亮点：

1、ECIE 2026 已成功申请 IEEE 出版，有 ISBN 号！高录用 EI 稳定检索！

2、211&双一流大学：苏州大学&河海大学联合主办，权威高校承办协办支持！

3、高届数会议，历史优秀，连续 5 届实现 EI、Scopus 双检索！

4、IEEE Fellow 主讲报告，权威专家齐聚苏州！

5、已开通 latex 投稿通道（word 或者 latex 可投）！

重要信息

大会时间：2026 年 5 月 8-10 日

大会地点：苏州（线上/线下皆可）

收录检索：IEEE Xplore, EI, Scopus

征稿主题

这么冷清了？

Paul511 — Thu, 16 Apr 2026 14:05:04 +0800

这么冷清了？

AI 垃圾代码围城，看 Linux 如何破局

Fhaohaizi — Thu, 16 Apr 2026 12:35:25 +0800

当 AI 开始批量生产代码，全球最大的开源项目正在经历一场前所未有的信任危机。Linux 用一份只有 59 行的文档，给出了自己的答案。

开篇：一场没有硝烟的攻击

凌晨两点，某位开源维护者的 GitHub 邮箱里，又躺进了第 47 封来自热心开发者的 PR（Pull Request）。邮件写得很满，几千行代码，附带详细的修复说明和性能优化分析。可当维护者真正开始审查时，问题很快就暴露了：一个简单的循环判断被改得面目全非，原本 10 行的函数膨胀到 89 行，所谓的优化在基准测试里反而让性能下降了 40%。

这不是孤例。到了 2024 年，这类场景已经在开源社区反复上演。各个社区公开披露的问题看起来细节不同，症状却高度一致：措辞模板化，代码结构臃肿，边界条件处理草率，对项目历史和设计哲学几乎没有理解。

cURL 项目的维护者 Daniel Stenberg 无奈关闭了运营多年的漏洞赏金计划，原因不是没人报漏洞，而是太多 AI 生成的漏洞报告涌了进来，维护者根本没有精力逐一甄别。Node.js 生态系统收到过一个包含数万行修复补丁的 PR，提交者声称这是 AI 协助开发的成果，结果审查下来几乎没有可以合并的内容。OCaml 核心项目也遭遇了类似的 AI 补丁轰炸。

而 Linux 内核，这个全球最重要的开源项目之一，同样没能置身事外。

2024 年 9 月，内核维护者 Sasha Levin 被发现曾在未做说明的情况下提交过多段由 AI 生成的代码。它们虽然能通过编译测试，但经过社区复核后，暴露出明显的性能问题：部分路径的执行效率远低于原有实现。更麻烦的是，一旦社区想追溯这些代码的真实来源，过程几乎无从下手。AI 生成了代码，署名却是一个人类维护者。

这场攻击没有病毒，也没有漏洞利用，但它正在用另一种方式拖垮开源社区：海量看似合理、实则质量堪忧的代码，正在淹没维护者有限的时间和精力。

泥潭：开源社区的困境

AI 垃圾代码的泛滥，把开源社区推入了一个典型的三难处境。

质量困境

传统代码审查依赖维护者对项目的深度理解。他们检查的从来不只是语法是否正确，还要判断代码是否符合项目风格，是否贴合既有架构，是否埋下潜在的性能或安全问题。AI 生成的代码最麻烦的地方，就在于它往往具有很强的迷惑性：能过基础检查，也可能过掉部分单元测试，但深层逻辑里埋着隐患。

一个很常见的特征是，AI 特别容易过度工程化。明明一个简单条件判断就能解决的问题，它偏要包成三层函数调用；明明标准库已经有现成方案，它却再手写一遍近似实现，边界条件还处理不完整。更糟的是，这类代码表面上往往很像样：术语正确，格式整齐，甚至注释充足，但就是不符合项目真正的工程需求。

信任困境

开源社区的协作，本质上是建立在人与人之间的信任之上。当一位开发者提交代码并签署 DCO（Developer Certificate of Origin，开发者来源证书）时，他声明的不只是代码从哪里来，更是在承担这段代码未来可能带来的长期责任，包括 bug、安全漏洞和许可证问题。

但 AI 生成代码把这个边界冲淡了。当一段代码真正的生产者是一个无法被追责的模型时，Signed-off-by 这个签名到底还意味着什么？如果代码出了问题，最后该被问责的是签字的人类提交者，还是那个吐出代码的 AI 系统？

这种模糊性正在侵蚀开源协作最核心的基础。社区成员越来越难判断，收到的 PR 到底有多少是真正经过人类思考和审查的结果。当质量问题的根源都难以追溯时，整个代码审查机制也就难免被动摇。

法律困境

更深的一层，是法律风险。AI 模型的训练数据来自互联网，其中天然混杂着大量开源代码。当用户要求 AI 生成一段实现某个功能的代码时，生成内容很可能与训练集中的某段实现高度相似，而那段实现背后，可能是 GPL、MIT、Apache 等完全不同的许可证体系。

对 Linux 内核来说，GPL-2.0-only 许可证本身就是护城河之一。即便 AI 吐出了 GPL 许可代码，只要最终进入 Linux，许可证链条通常还是自洽的。但对大量采用 BSD、MIT 等宽松许可证的项目来说，风险就复杂得多：如果 AI 无意中混入 GPL 代码，项目方可能直接踩进许可证雷区。

这也是 NetBSD 和 Gentoo 等项目直接禁止 AI 生成代码的重要原因。Gentoo 社区说得很直白：大模型生成的内容在法律层面可能构成污染，因为来源无法确认。与其承担不确定的风险，不如直接一刀切。

交锋：Linux 内核的内部战争

面对 AI 代码的渗透，Linux 内核社区内部并不是铁板一块。

两种声音

2024 年，Linux 内核两位重要维护者之间的公开争论，把这场分歧摆到了台面上。

Dave Hansen（Intel 工程师，长期负责内核内存管理相关工作）主张对 AI 生成代码施加更严格的限制。他担心，如果社区不尽快设定边界，AI 代码会一点点稀释内核代码库的质量，最终伤害这个运行在全球数十亿设备上的操作系统。

而 Lorenzo Stoakes（活跃的内核开发者，以直言不讳著称）则走了另一条思路。他认为，与其费力去甄别每一行代码到底是不是 AI 写的，不如把重点放回到真正关键的问题上：无论用了什么工具，人类提交者都必须为结果负责。

两种观点其实各有逻辑。前者强调预防胜于治疗，后者强调结果导向的责任制。

Linus 出场

最终，给这场争论定调的，还是 Linus Torvalds 本人。

在 Linux Plumbers Conference 上，面对社区关于 AI 代码治理的提问，Linus 直接给出了一句非常典型的回应：

There is zero point in talking about AI slop. That's just plain stupid.

他的意思很明确：纠结这是不是 AI 写的，本身就是一个偏题的问题。真正重要的只有两件事：代码质量过不过关，提交者愿不愿意承担责任。

Linus 的逻辑其实很朴素。AI 只是工具，就像编译器、静态分析器一样。问题从来不在工具本身，而在使用工具的人。如果代码有问题，无论它是人写的，还是 AI 辅助生成的，都应该被拒绝；如果代码质量过硬，那么背后具体用了什么工具，并不是首要问题。

这个表态，基本为 Linux 后续的治理路线定下了基调：不问出处，只问责任。

破局：59 行文档的重拳

2024 年底，Linux 内核正式发布了关于编码助手（Coding Assistants）的官方指南。这份文档只有 59 行，却把 AI 代码参与贡献时最关键的责任链条说得非常清楚，也因此被很多人视作 Linux 对 AI 垃圾代码的正面回应。

三条铁律

文档开篇就给出了三条几乎不可退让的原则。

铁律一：AI 不得签署

规则写得非常直接：

AI agents MUST NOT add Signed-off-by tags

DCO 是开源贡献最基础的法律承诺之一，它声明了代码来源，也声明了提交者有权以对应许可证提交代码。只有具备法律人格的人类才能签署这份承诺，AI 显然不具备这个资格。

铁律二：人类承担全部责任

Linux 文档明确规定，人类提交者才是代码质量的第一责任人。这件事具体落到行动上，至少包括四点：

彻底审查 AI 生成的每一行代码
确保代码符合许可证要求
添加 Signed-off-by 声明
对未来可能出现的任何问题承担全部责任

说得更直白一点，不管你用了多少 AI，最后负责背锅的都只能是提交者自己。

铁律三：透明披露 AI 参与

如果你的提交有 AI 参与，必须通过 Assisted-by 标签进行披露。文档给出的标准格式是：

Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2]

例如：

Assisted-by: Claude:claude-3-opus coccinelle sparse

这条规则的关键，不是给提交者免责，而是把信息摊到台面上。审查者一旦知道这段代码有 AI 参与，就可以自然地提高审查强度。

解读

很多人会觉得，Linux 没有直接封杀 AI 代码，是不是等于放行？恰恰相反。它给出的其实是一套更锋利的责任框架：用了 Assisted-by，就要承担更多解释义务；签了 DCO，法律责任也不会转移给模型；文档反复强调 thoroughly reviewed，说明质量门槛并没有降低。相比一刀切禁令，Linux 更务实，但底线很硬：工具可以进来，责任不能稀释。

FunTester 原创精华

AI 的下一场竞争，可能是长期记忆

Fhaohaizi — Wed, 15 Apr 2026 23:27:19 +0800

过去两年，大模型的进化主线其实很清晰：从看得更多，走向记得更久。如果说前一阶段的重点还是把上下文窗口不断拉大，那么到了现在，头部厂商更关心的，已经是 AI 能不能真正记住用户、记住项目、记住长期任务，并且还能被控制、被删除、被审计。换句话说，长期记忆正在从一个功能点，慢慢变成一层系统能力。

上下文不等于记忆

长上下文曾经被很多人当成长期记忆的替代方案，但它很快暴露出几个问题：成本高、选择性差、没有稳定的遗忘机制。它更像一个临时背包，能把东西先装进去，却不擅长帮你整理、分类和回收。真正的长期记忆，必须能决定什么该写入、什么时候该检索、哪些信息该更新，以及哪些内容该忘掉。换句话说，记忆不是存得下就够了，还要能按任务目标被稳定调用。

所以，行业现在的思路已经在变化。大家不再只是单纯追求更长的窗口，而是在尝试把记忆拆成独立能力：有的负责个人偏好，有的负责项目上下文，有的负责企业协作，有的负责代理任务。上下文负责眼前的对话，记忆负责更长线的关系；前者解决当下能不能答，后者解决下次还能不能接着干。

记忆正在变成系统能力

OpenAI 的做法最像消费级记忆系统。ChatGPT 已经可以参考 saved memories 和 chat history，而且用户可以随时关闭相关功能；后续更新又把记忆做得更全面，开始参考更完整的历史对话，让回复更贴近用户的长期偏好。这个方向说明，OpenAI 想做的不是一个简单的记住一句话，而是一个能持续理解用户、并在多轮交互中保持稳定个性化的长期记忆层。

Anthropic 的路线更偏团队和代理工作流。Claude memory 面向 Team 和 Enterprise 用户，强调可以记住团队项目和偏好，同时保留细粒度控制，用户也可以用 Incognito chats 避免对话进入历史或写入记忆。再配合更长上下文和 compaction，它在尝试用记忆、压缩和长上下文的组合，去支撑更长、更复杂的任务链路。

Google 的方向则是个人化和代理基础设施并行推进。Gemini 已经支持从历史聊天中学习偏好，同时提供管理和删除能力。它的思路很清楚：一边让模型更懂用户，一边让用户保留控制权，让个性化能力不至于滑向不可控的黑箱。

Microsoft 的重点更偏企业化和治理。Copilot Memory 已经进入生产力场景，并且和权限、审计、合规体系结合在一起。对企业来说，问题从来不是 AI 会不会记，而是它记的东西是否可控。

Meta 的路线则更贴近社交体系。Meta AI 会在对话中记住用户偏好，同时和 Facebook、Instagram 等产品的个性化推荐结合。这种路径，本质上是把记忆和用户画像打通。

记忆开始可治理

过去很多人默认，AI 记得越多越好。但现在几乎所有头部产品都在往相反的方向补课：可以关闭、可以删除、可以临时使用、可以查看、可以恢复。记忆开始被纳入配置、权限和生命周期管理，而不是继续停留在能不能记住这一层。

这件事其实很关键。真正可用的长期记忆，不是永远记得，而是该记的记住，不该记的能干净地忘掉。对用户来说，这是安全感；对企业来说，这是合规边界；对产品来说，这是能不能真正落地的前提。没有删除、审计和隔离能力的记忆，规模一上来，几乎一定会反噬产品体验和组织信任。

没有治理能力的记忆，最后往往只会变成负担。

真正的竞争点变了

如果把各家路线放在一起看，差异其实很明显。OpenAI 更像是在做消费级的记忆操作系统，重点是个人偏好和跨对话连续性。Anthropic 更像是在做面向团队和代理的工作记忆，强调项目上下文和长任务协作。Google 在个性化和代理能力之间做平衡。Microsoft 则强调企业治理和合规。Meta 把记忆直接融入社交和推荐体系。它们比拼的已经不只是模型参数，而是谁能先把记忆嵌进自己的主场景里。

这个分化本身就说明，长期记忆已经不是会不会做的问题，而是怎么做、给谁做、做到什么程度的问题。面向个人、面向团队、面向企业，写入策略、权限边界和价值衡量标准，本来就不是一套答案。

接下来会怎么演进

接下来一两年，长期记忆大概率会沿着几条线继续往前走，而且这些方向会越来越像基础能力分层，而不是单点功能堆叠。

第一，是自动记忆策略。AI 会逐渐学会判断什么该记、什么该忘，而不是完全依赖用户手动指定。
第二，是多模态记忆。未来不仅是文本，还会包括图片、语音甚至行为数据，记忆对象会从对话内容扩展到更完整的交互轨迹。
第三，是多 Agent 共享记忆。多个智能体围绕同一套记忆层协作，更像一个团队而不是单个工具，这会直接影响任务交接和长期协同的效率。
第四，是记忆与推理融合。记忆不再只是被调用，而是直接参与推理过程，成为判断上下文、约束输出和保持连续性的输入条件。

一个更底层的判断

如果把今天的大模型类比成计算机系统，长上下文更像临时内存，检索系统更像外部存储，而长期记忆更像运行时状态管理。

它不只是存储信息，更是在决定系统如何持续运转。谁来写、什么时候读、读出来之后如何影响后续行为，这些问题本质上都属于系统设计。

所以，长期记忆不会只是一个功能更新，它更像一次架构级演进。谁先把这层能力做稳，谁就更有机会把 AI 从一次性问答工具，推进成持续协作的系统。

下一代 AI 的分水岭，可能不再是谁更会回答，而是谁更能记住你、理解你，并且知道什么时候该忘记。

FunTester 原创精华

Switch 健身环也能语音输入！Vibe Ring 让编程锻炼两不误；语音 AI 用户访谈平台 Mizzen Insight 融资近千万美元丨日报

RTE — Wed, 15 Apr 2026 17:58:53 +0800

开发者朋友们大家好：

本期编辑：@koki、@ 鲍勃

01 有话题的技术

1、Hand2World：基于 3D 手部结构与射线嵌入，实现首个闭环交互式第一人称世界模型

南洋理工大学（NTU）MMLab 团队发布 Hand2World，这是首个支持自由手势驱动的第一人称交互世界模型。该模型允许用户通过空中手势实时操控虚拟场景并生成连续视频，解决了传统世界模型在主动物理交互及相机运动解耦方面的技术瓶颈。

3D 手部结构化控制信号：放弃传统的 2D Mask 方案，采用 3D 手部 mesh（MANO 模型）渲染的「填充轮廓 + 线框叠层」复合信号。该设计实现了遮挡无关的条件输入，解决了推理时完整手势与训练时残缺手部（受物体遮挡）之间的分布错配。
Plücker 射线嵌入解耦相机运动：引入逐像素的 Plücker 射线（Plücker Ray Embedding）显式编码相机运动，通过轻量级 adapter 注入扩散模型。该技术将手部关节运动与头部自运动（ego-motion）彻底解耦，使 FVD 指标从 815 优化至 218，有效抑制背景漂移。
因果自回归蒸馏实现 8.9 FPS 交互：将双向扩散教师模型蒸馏为支持 KV cache 的因果自回归生成器。在 A100 平台上可实现 8.9 FPS 的流式输出，支持用户边看边调的闭环持续交互。
全自动单目标注流水线：开发了一套无需多目相机或人工干预的自动化标注系统，可直接从普通单目视频中提取 3D 手部位姿与相机轨迹。相比 PlayerOne 等依赖同步采集的方案，显著提升了具身智能训练数据的可扩展性。
多项 SOTA 性能指标：在 ARCTIC、HOT3D、HOI4D 三个标准数据集上均取得最优结果。在 ARCTIC 测试中，相机轨迹误差降低 42%，深度一致性（Depth-ERR）从 22.51 降至 16.14。

（@ 新智元）

2、Snap 联合高通研发新款 Spectacles：搭载 Snapdragon XR 平台，支持端侧 AI 交互

Snap 旗下 AR 硬件子公司 Specs 与高通（Qualcomm）达成多年战略合作伙伴关系，确定下一代 Spectacles 智能眼镜将采用 Snapdragon XR 芯片平台。此次合作旨在通过底层算力升级，在今年年内推出具备端侧 AI 处理能力的消费级可穿戴设备。

Snapdragon XR 平台架构集成：新款 Spectacles 将搭载高通专为 AR/VR 设备设计的 Snapdragon XR 系列片上系统（SoC），用于处理高复杂的空间计算与图形渲染任务。
端侧 AI（On-device AI）处理能力：双方合作重点在于实现人工智能在硬件本体的实时运行，以降低交互延迟，并增强在离线状态下的多模态感知与语义理解能力。
高级多人数字体验支持：利用高通的通信与计算协同技术，开发支持多名用户在同一物理空间内实时交互的增强现实应用。
从开发者生态向消费端过渡：自 2024 年转向「仅限开发者」策略后，Specs 计划通过此次硬件升级，将积攒的开发者插件与应用库正式推向消费市场。

( @TechCrunch)

02 有亮点的产品

1、Mizzen Insight 完成近千万美元天使轮 + 融资，4 个月从 0 到 300+ 客户

AI 用户研究平台 Mizzen Insight 已完成天使 + 轮融资，融资金额近千万美元，由红杉中国种子基金领投，达晨创投、嘉程资本跟投，种子轮老股东 Creekstone 继续加码。本轮融资将主要用于模型能力优化、产品迭代及市场拓展。

全链路 Agent 自动化闭环：系统支持从输入调研目标开始，自动生成访谈提纲、筛选受访者、实时主持访谈并输出可视化结构化报告，实现调研全流程脱离人工干预。
语义级实时动态追问：访谈模型具备深度语义理解能力，能基于受访者的实时回答进行动态逻辑追问，而非执行固定脚本，模拟专业研究员的深访交互。
大规模定性研究吞吐量：上线 4 个月累计完成访谈逾 1 万小时，参与人数近 2 万人，验证了 AI 在高频、大规模并发访谈场景下的可扩展性。
基于人类偏好建模的技术栈：创始人孙克强博士背景涵盖清华及港中文 MMLab，专注人机交互与人类偏好建模，相关技术 Benchmark 此前已被 Google、DeepMind 等机构采纳。

( @Z Potentials)

2、AI 潮玩品牌 MOMOTOY 获数千万元融资：自研五大 AI 技术体系，支持端云协同与本地化数据处理

AI 潮玩品牌 MOMOTOY 完成数千万元融资（投后估值 2.5 亿元），由翼朴基金投资。该公司将 AI 技术与高奢材质（如 999 足金）引入潮玩硬件，试图通过自研情感计算模型实现从静态摆件向具身智能终端的转型。

五大 AI 核心技术体系： 构建以记忆分级、动态情绪、心理分析、端云协同、深度情感理解为核心的技术栈。支持双向对话、多语种实时交流及声音克隆，能够根据用户交互历史实现渐进式记忆增长。
端云协同与隐私安全架构： 建立个人数据空间，支持信息分级管理。关键交互数据直连本地智能体（agent），无需强制上传云端，通过端侧加密保护用户隐私。
全场景智能联动能力： 软件接口已打通车载系统与智能家居系统，实现「人 - 车-家」全生态场景的智能体接入，使潮玩具备跨终端的交互连续性。

（@36 氪未来消费）

03 Real-Time AI Demo

1、Vibe Ring 实现 Switch 健身环语音输入：挤压健身环 = 长按 Fn

来自 X 上的开发者 @wong2__：

沉迷 Vibe Coding 却疏于锻炼？快来试试 Vibe Ring！

把落灰的 Switch 健身环和 Mac 按键映射：

挤压健身环 = 长按 Fn 语音输入
向外拉健身环 = 回车发送

GitHub 链接：

https://github.com/wong2/vibe-ring/blob/main/README_CN.md

04 有态度的观点

1、别只敲键盘了！吴恩达最新研判：语音 AI 正引爆下一场交互革命

近日，人工智能先驱吴恩达（Andrew Ng）撰文指出，大众严重低估了语音用户界面（Voice UI）即将带来的颠覆性影响。他预言，语音交互将成为继「鼠标点击」和「屏幕触控」之后的下一次重大 UI 变革。

回顾科技史，每一次交互方式的跃迁都会催生出庞大的全新应用生态。吴恩达强调，读写是需要系统学习的技能，而「听和说」则是人类与生俱来的本能。由于开发者群体普遍具备较高的读写能力，人们很容易忽视「打字操作」对许多普通用户而言仍是一种摩擦力。随着语音识别准确率的飙升，语音 UI 将彻底打破这一门槛，让科幻电影中「对着计算机直接下达指令」的愿景成为现实。

过去，语音 AI 常常面临一个死结：要低延迟（反应快）就容易显得「智商低」，要高智能（经过大模型深思熟虑）就必然带来高延迟。对此，吴恩达分享了目前行业前沿的解法——「双智能体自定义架构」。即通过前台智能体（Foreground Agent）与用户保持低延迟的实时语音拉扯，同时让后台智能体（Background Agent）默默处理复杂的逻辑推理、工具调用和安全护栏。这种协同作战，完美兼顾了沟通的流畅度与 AI 的聪明才智。

吴恩达明确表示，语音并不会消灭键盘和鼠标，而是最强力的补充。纯语音交互存在局限，但「视觉 + 语音」的多模态结合将带来颠覆性体验。系统可以在听取用户指令的同时，实时动态更新屏幕上的画面和动画，形成视觉与听觉的双重闭环。

如今，构建语音 UI 的门槛已大幅降低。吴恩达透露，借助 AI 编程工具，他仅用不到一小时就为一款普通的数学应用加上了语音交互层。在全球范围内，真正下场开发语音应用的开发者仍是凤毛麟角。

正如吴恩达在信末的呼吁：这片蕴含着巨大创新的处女地已经敞开。在这个 AI 爆发的时代，是时候给你的应用装上「声带」，让它和世界真正对话了！

(@Deeplearning AI)

写在最后：

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

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

AI+Python+Playwright+K6 最佳实践

qyw01 — Wed, 15 Apr 2026 14:21:11 +0800

继上文：https://testerhome.com/topics/43822
说来惭愧，基于上一篇文章说到要给大家一起分享代码链接，由于涉及其它原因，目前只能给大家分享应用使用；目前是更新的版本
支持：不同类型用例深度生成
即将支持：开放自动化测试【AI+playwright】【AI+K6】预计 7 月底前彻底深度全面支持；
最新版本内容亮点：
支持自然语言描述生成自动化测试用例
支持千问（未来看是否应需人多，会根据大家的需求支持更多模型，也支持公司自定义模型，但是需要提供公司接入方法文档）
这里不罗嗦，直接展示效果

这里的性能测试还没有优化，很丑，还不能使用（可以当是一个里程碑）

最后，欢迎大家一起讨论在 AI 测试领域能做到更业务、更精准、更有深度、更低的学习成本去提升在测试领域的工作效能！