测试之家社区

如何成为 AI Test 架构师

Fhaohaizi — Tue, 12 May 2026 18:42:53 +0800

工程深度是对抗 AI 替代最硬的护城河，而大多数测试工程师从未真正走到这道护城河前。测试架构师（Test Architect）不是资历最深的测试工程师，也不是测试团队的管理者。这个角色真正要解决的问题是：面对一个复杂系统，如何设计测试基础设施、如何做测试分层、如何与研发流水线咬合、如何让整个团队的质量验证行为长期可持续。这是一种系统设计能力，和会不会用 Selenium 是两个完全不同的问题。

从这个用例怎么写到整个体系怎么设计

多数测试工程师的日常是问题导向的：这个功能该怎么测，这条用例该怎么写，这个 bug 该怎么复现。Test Architect 的出发点不同，他们问的是体系层面的问题：

这个系统的测试覆盖策略应该是什么
单元测试、集成测试、E2E 测试各占多少比例才合理
自动化框架选什么，如何保证三年后仍能维护
测试环境如何管理，才不会成为流水线的瓶颈
如何让质量数据可视化，让团队每天都能感知质量状态

这不是更多的手艺，而是更高的视角。从执行者到架构师，本质上是从回答怎么做，转向回答做什么以及为什么。

ISTQB 在 2024 年 6 月同步发布了两个与此相关的认证：CTAL-TAE v2.0（Advanced Level - Test Automation Engineering）和 CT-TAS v1.0（Specialist - Test Automation Strategy）。前者偏工程实现，考察如何在 CI/CD、Agile、DevOps 环境中落地自动化；后者偏战略架构，考察企业级测试自动化的整体部署决策。两者合在一起，覆盖的正是 Test Architect 需要的完整能力图谱。

核心能力地图

分层测试架构设计是基础中的基础。测试金字塔是一个常见概念，但在实际项目中，很少有团队能把这三层的比例设计合理。单元测试太少，E2E 测试堆积，流水线跑一次需要一个小时，这是大多数团队的现实。Test Architect 的工作，是理解为什么会失衡，并设计出可以持续演进的分层策略。

其中一个关键判断是：哪些测试应该自动化，哪些不值得自动化。自动化不是越多越好，维护成本是隐性的时间黑洞。一个维护成本过高的自动化用例，长期来看比不自动化更贵。

框架设计与可维护性是另一个核心能力。选 Playwright 还是 Cypress，选 TestNG 还是 JUnit，并不是最重要的问题。真正重要的是：框架的分层结构是否清晰，测试数据与业务逻辑是否解耦，新团队成员上手需要多少时间，框架能否适配未来的技术栈变化。这些判断没有统一答案，只能在具体场景里反复权衡，逐步形成判断力。

CI/CD 深度集成决定了自动化测试能不能真正发挥价值。一套在本地跑起来很漂亮的测试框架，接入流水线后，可能因为环境差异、测试数据污染、并发冲突而不断 Flaky。Test Architect 需要理解流水线的执行机制，设计合理的质量门禁（Quality Gate），并在速度和可靠性之间找到团队能接受的平衡点。

复杂系统的可观测性设计是容易被忽视的部分。测试覆盖率只是一个开始，不是终点。在微服务架构下，一个端到端流程可能跨十个服务。一个用例失败时，定位根因的时间往往比修复问题更长。Test Architect 需要设计分布式追踪机制，让质量信号在系统复杂度增加时依然清晰可读。

AI 时代 Test Architect 的新增职责

这条路径在 AI 时代增加了一个新的工作维度：设计 AI 测试基础设施。

注意，这里说的不是把 AI 工具引入测试流程，而是更上层的事：当团队已经在用多个 AI 测试工具时，谁来决定这些工具该怎么组合、怎么评估、怎么治理？Gartner 在 2025 年 10 月发布了首届 AI 增强软件测试工具魔力象限，进入该象限的包括 UiPath、Tricentis、Keysight、OpenText 等。这意味着这个市场已经足够成熟，但也足够复杂，选型决策不再是简单的工具对比，而是架构层面的判断。

另一个新增职责是：为 AI 生成代码设计专项验证流程。前两篇文章里引用的数据已经说得很清楚：AI 生成代码的关键缺陷是人类代码的 1.7 倍，40% 含有可利用安全漏洞。当团队大规模使用 AI 辅助编码时，原有的测试策略需要调整：哪些路径更容易出现 AI 典型缺陷，比如边界条件、异常处理、安全逻辑，需要专门加强；哪些常规回归路径可以更放心地交给 AI 测试工具处理。这个判断需要架构层面的设计，而不是每个测试工程师各自摸索。

薪资与市场信号

根据 Glassdoor 2025 年数据，美国市场 Test Architect 年薪中位数约为 $160,716，75 分位约 $209,750，90 分位约 $264,593。不同来源之间有差异，ZipRecruiter 约 $135,698，Salary.com 约 $109,378。这个区间宽度本身就说明，市场对这一职位的定义并不完全一致：有些公司把测试团队技术负责人叫 Test Architect，有些公司对这个职位的要求则更接近工程总监。

中国市场没有成熟的公开数据，但从大厂 JD 和社区讨论来看，对应级别大约是阿里 P7/P8、腾讯 T3-1/T3-2，年薪区间大致在 80 万到 150 万人民币之间，个体差异很大。

这条路适合谁

Test Architect 这条路，适合对工程问题本身有持续好奇心的人。不是因为解决问题能获得奖励，而是拆解一个架构难题本身就让你觉得有意思。如果你发现自己写测试框架比写测试用例更有劲头，喜欢想为什么这样设计而不是那样设计，愿意花时间把一件事做到工程层面的扎实，这条路就是你的方向。

如果你更关注的是我们到底在测对的东西吗，比起工具实现更在乎决策是否合理，下一篇的路径或许更适合你。

FunTester 名片｜万粉千文，百无一用

使用本地模型 “3 小时” 构建番茄时钟 Mac 桌面应用

MNicholas — Tue, 12 May 2026 16:15:15 +0800

背景

闲来想研究下 Claude Code 使用本地模型进行代码开发（线上 Token 消耗太快了，哈哈），就想着使用它来写写一直在用的番茄时钟。

尝试

一开始使用 Claude Code 使用 Python+Tkinter/Qt 已经可以实现，后来就想着能不能使用 Electron 来实现，在使用 Claude Code 时候发现无论如何都无法准确实现，也使用过 Pycharm+AI Chat/CC GUI 都不太行，主要是无法准确实现需求。

Claude Code

# 使用指令访问局域网服务器Ollama模型服务
ANTHROPIC_AUTH_TOKEN=ollama ANTHROPIC_BASE_URL=http://192.168.x.xxx:11434 claude --model [本地模型名称]

碰到一个很棘手的问题，就是无论使用 Windows 或 Mac，Claude Code 在写代码总是会需要/home/user 路径权限，所以就一直报错，根本无法实现需求，很遗憾最终没有解决。

Pycharm+AI Chat

Pycharm+CC GUI

当时碰到了和 Claude Code 同样的问题，毕竟背后使用跟 Claude Code 是同个逻辑。

Cursor

Cursor 是在 Windows 上使用的，需要通过转发才能使用本地模型，但是同样走的 Claude Code 那一套，最终遇到同样的问题，很遗憾没有解决。

VSCode+Copilot Chat

在线模式

使用 Claude Code Claude Haiku 4.5 模型，确实可以写代码，也很智能，但是如果出现执行失败就会一直尝试不同的方式重试，就很耗 Token 了，而且上下文也会不断叠加，最终效果不友好。

本地模式

同样我这里也是使用的局域网 Ollama 模型服务，代码能够生成并给出具体的详细的操作，但是即使选择了 Agent 模式也无法自动写入项目工程，很遗憾最终没有解决。

VSCode+Continue

配置先行

name: Local Config
version: 1.0.0
schema: v1
allowFS: true
enableTools: true
models:
  - name: gemma4:31b
    provider: ollama
    model: gemma4:31b
    contextLength: 100000
    roles:
      - chat
      - edit
      - apply
    capabilities:
      - tool_use
    allowedTools:
      - code_interpreter
      - file_manager
      - web_browser
      - file_read
      - file_write
      - file_edit
      - file_delete
      - file_rename
      - list_dir
      - shell_exec
      - file_walk
      - grep_file_content
      - list_directory
      - file_read
      - file_list
      - read
      - read_all_files()
      - bash
      - list_files
  - name: gemma4:31b
    provider: ollama
    model: gemma4:31b
    contextLength: 100000
    roles:
      - autocomplete
    capabilities:
      - tool_use
    allowedTools:
      - code_interpreter
      - file_manager
      - web_browser
      - file_read
      - file_write
      - file_edit
      - file_delete
      - file_rename
      - list_dir
      - shell_exec
      - file_walk
      - grep_file_content
      - list_directory
      - file_read
      - file_list
      - read
      - read_all_files()
      - bash
      - list_files
  - name: qwen3-embedding:8b
    provider: ollama
    model: qwen3-embedding:8b
    contextLength: 100000
    roles:
      - embed
    capabilities:
      - tool_use
    allowedTools:
      - code_interpreter
      - file_manager
      - web_browser
      - file_read
      - file_write
      - file_edit
      - file_delete
      - file_rename
      - list_dir
      - shell_exec
      - file_walk
      - grep_file_content
      - list_directory
      - file_read
      - file_list
      - read
      - read_all_files()
      - bash
      - list_files
  - name: gemma4:31b
    provider: ollama
    model: gemma4:31b
    contextLength: 100000
    capabilities:
      - tool_use
    allowedTools:
      - code_interpreter
      - file_manager
      - web_browser
      - file_read
      - file_write
      - file_edit
      - file_delete
      - file_rename
      - list_dir
      - shell_exec
      - file_walk
      - grep_file_content
      - list_directory
      - file_read
      - file_list
      - read
      - read_all_files()
      - bash
      - list_files

由于也是第一次使用，这些配置是根据使用过程中报错提示添加的权限（有报错就添加），最终完成根据 SKILL.md 描述生成代码并自动写入项目工程，最终生成 Mac 应用。

效果

状态栏图标
- 默认图标
- 时间结束图标
应用窗口界面

工具

Ollama
Cherry Studio
Visual Studio Code
Continue

具体实现

Ollama

Ollama 部署在局域网另一台机器上，模型服务通过设置 OLLAMA_HOST=0.0.0.0 来暴露出来，通过 Ollama 网站下载需要使用的模型，我用的比较多的如下：

gemma4:31b
glm-4.7-flash:Q8_0
qwen3-coder:30b

Cherry Studio

使用 Cherry Studio 用来帮我生成可用的 SKILL.md 技能文档

Name: Electron Professional Tomato Clock

作者: Senior Software Engineer Agent
版本: 1.0.0
触发词: 创建番茄时钟, Build Tomatometer

Description

该 Skill 用于构建一个基于 Electron 和 Web 技术的专业级番茄时钟。它集成了动态背景切换、Web Audio API 音效合成、自定义时间设置以及优雅的 UI 设计。

核心功能亮点：

架构设计：采用 Electron 主进程与渲染进程分离的架构。

音频引擎：使用 Web Audio API 实时合成音效，无需依赖外部 MP3 文件，确保自包含。

视觉体验：支持随机/指定主题背景，采用 Glassmorphism（毛玻璃）风格设计，提供动态的背景切换，布局简洁、直观，交互简单。

逻辑模块：独立的计时器管理器，支持倒计时结束的自动切换与提醒，支持自定义时间设置。

执行步骤

1. 项目初始化

请在项目根目录执行以下命令：
npm init -y
npm install electron --save-dev
2. 项目文件结构

建议创建以下文件结构：
my-tomato-clock/
├── main.js              # Electron 主进程入口
├── renderer.js          # 计时器逻辑、UI交互、音效合成
├── index.html           # 界面结构
├── style.css            # 界面样式与动画
├── assets/              # 资源文件夹（如需添加本地图片可在此放置）
└── package.json         # 项目配置
3. 代码实现

请将以下代码依次写入对应的文件中。

......

这是一个完整的、单文件的 Electron 应用结构，包含了 HTML、CSS、JS 和 Node 模块。它具备以下特点：

现代化 UI：使用毛玻璃效果和渐变背景。

功能完备：开始、暂停、重置、设定时间、切换工作/休息模式、自定义时间设置（分钟）。

声音反馈：基于 Web Audio API（隐含在 JS 逻辑中，此处使用了简单的逻辑），可以开关滴答声。

自适应：界面简洁，适配桌面窗口。

这个是原始生成的 SKILL.md，后续可以尝试精简去除多余的内容再试试。

Visual Studio Code+Continue

配置

打开 VSCode 在市场安装 Continue，当然这里你如果使用本地 Ollama 应该没问题，如果是像我访问局域网模型服务需要执行以下指令：

# 监听11434端口转发
socat -d -d TCP-LISTEN:11434,fork TCP:x.x.x.x:11434

之后按照上文配置即可

name: Local Config
version: 1.0.0
schema: v1
allowFS: true
enableTools: true
models:
  - name: gemma4:31b
    provider: ollama
    model: gemma4:31b
    contextLength: 100000
    roles:
      - chat
      - edit
      - apply
    capabilities:
      - tool_use
    allowedTools:
      - code_interpreter
      - file_manager
      - web_browser
      - file_read
      - file_write
      - file_edit
      - file_delete
      - file_rename
      - list_dir
      - shell_exec
      - file_walk
      - grep_file_content
      - list_directory
      - file_read
      - file_list
      - read
      - read_all_files()
      - bash
      - list_files
......

执行

接着指定一下具体文件，让它帮助我们写代码，期间会多次需要人工进行确认同意写文件和执行指令，一步步同意即可。

优化布局

第一次生成的番茄时钟按钮布局杂乱，直接可以进行优化

打包 Mac 应用

继续让 Continue 帮我将代码可构建成 Mac 桌面应用

应用优化

在使用过程中发现无法体现时间开始和结束状态，以及无法保存自定义时间设置，所以继续让 Continue 帮我优化

结束语

至此番茄时钟 Mac 桌面应用打造完成，“3 小时” 只是真正用来写代码的时间，具体的试错和环境配置当然不止 3 小时了，哈哈哈。

遗留问题

涉及到使用 Claude Code 部分存在路径「/home/user」无权限问题，即使 cd 到具体的项目目录下也是这样，不知道是不是本地模型的问题。
Copilot Chat 生成代码无法写入项目工程问题，估计是没有找到对应的写权限配置。
Continue 不指定具体文件时，概率性出现无法读取文件内容问题。
Mac 也无法正常发送消息，暂时没解决。

【ACM 出版 | EI 稳定检索】2026 年机器学习与数据安全国际学术会议

leisigoule — Tue, 12 May 2026 15:26:20 +0800

【ACM 出版 | EI 稳定检索】2026 年机器学习与数据安全国际学术会议

2026 International Conference on Machine Learning and Data Security

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

大会简介：
在人工智能技术革命性进步的浪潮中，机器学习与数据安全作为两大关键支柱，其交叉融合正不断开拓新的研究疆域与应用前景。为促进该跨学科领域的深度交流与合作，2026 年机器学习与数据安全国际学术会议（MLDS 2026）将于2026年6月12日至 14 日在中国广州举行。本次会议致力于构建一个国际学术平台，以共享最新成果、激发创新思维。我们将围绕机器学习的前沿理论与方法、数据安全与隐私保护的核心技术、以及二者在关键领域中的融合创新展开深入探讨，共同推动安全、可信、负责任的人工智能技术发展。

组织单位

会议论文出版

征稿主题

OpenAI 的 WebRTC 秘密架构：没有 SFU？没有问题！丨 Voice Agent 学习笔记

RTE — Tue, 12 May 2026 12:51:21 +0800

「OpenAI 的做法与 WebRTC 业界的『最佳实践』几乎背道而驰，但在 Voice AI 的特定场景下，这却极其合理。」

OpenAI 目前拥有超过 9 亿的周活跃用户。在如此规模下，要让 Voice AI 保持自然流畅，这已不仅是模型层面的挑战，更是一场关于基础设施的极限考验。

本期 Voice Agent 学习笔记源自 WebRTC.ventures。Arin Sime 与 Bloggeek.me 的 Tsahi Levent-Levi 深度拆解了 OpenAI 工程师 Yi Zhang 和 William McDonald 分享的最新架构方案。

笔记重点涵盖了 OpenAI 如何重构其 WebRTC 技术栈以支撑 Realtime API，包括：

Relay + Transceiver（中继与收发器）设计；
为何在 AI 场景下不再需要传统的 SFU；
如何攻克海量并发下的端口管理难题；
以及一个极具智慧的 ICE ufrag 协议 Hack。

如果你正在构建实时语音应用，或是在思考如何实现生产级的大规模 WebRTC 方案，这期深度解析将为你提供极具价值的实战参考。

OpenAI 博客原文：

https://openai.com/index/delivering-low-latency-voice-ai-at-scale/

深度拆解 OpenAI 的 Voice AI 硬核架构

Arin： 感谢大家参加本期节目。Tsahi，OpenAI 刚发布了一篇重磅技术博客，详述了他们如何大规模构建低延迟 Voice AI 系统。这绝对是近期最值得一读的技术文档，你对此有哪些核心观察？

Tsahi： 首先，这非常令人振奋。在此之前，业界一直有种声音，质疑 WebRTC 是否仍是最佳选择，纷纷讨论是否该转向 WebSocket、WebTransport 甚至是某些未知的新技术。但现在，OpenAI 站出来明确表示：「我们选择 WebRTC，而且是生产环境的大规模应用，非 Beta 版，非实验室产物。」他们坦诚地分享了决策过程与生产架构。这对 WebRTC 和 Voice AI 领域来说，无疑是一剂强心针。

Arin： 没错，这绝对是对 WebRTC 技术价值的强力背书。

Tsahi： 第二点，在过去几年里，很少有公司愿意花精力撰写如此深度的技术复盘。他们不仅在展示成果，更是在纯技术层面拆解架构背后的「Why」——为什么做出这些选择。这种透明度让人大开眼界，必须向 OpenAI 团队致敬。

更重要的一点是：OpenAI 的做法几乎与 WebRTC 业界的「最佳实践」背道而驰，但在 Voice AI 的特定场景下，这却极其合理。

Arin： 确实，这种「反直觉」的设计正是其高明之处。

Tsahi： 有趣的是，我刚约好了与 WebRTC 的奠基人之一 Justin Uberti 进行一场访谈。现在手头有了这些公开的硬核资料，我终于有底气和他深度切磋了，这太棒了。

Arin： 是的，OpenAI 在文中特别致敬了 Justin 的贡献，也提到了 Sean DuBois 和开源项目 Pion。他们公开承认基于 Go 语言构建这套系统，这种对开源社区的尊重和透明度确实名副其实。

Tsahi： 至于具体的技术细节，最让我感兴趣的有以下几点：

第一，彻底弃用 TURN 服务器。 这在逻辑上是自洽的。当年 Justin 在 Google 开发 Google Meet 时就曾尝试过不依赖 TURN。对于 OpenAI 的用例来说，客户端直连部署在公网上的服务器，这符合最精简的网络路径。

第二，坚持单端口方案。 他们只暴露一个公网 IP 和一个 UDP 端口作为流量入口。这主要是为了绕过 Docker 在处理海量端口时的性能瓶颈和安全隐患。

第三，最核心的架构选择：放弃 SFU（选择性转发单元）。这是最让我兴奋的部分。目前市面上多数 Voice AI 产品默认都会使用 SFU 架构。如果你本身就有多人会议需求，这无可厚非；但正如 Gustavo Garcia 最近指出的，SFU 对于 1:1 的语音交互来说，是一个多余的「活动部件」。

OpenAI 的思路是：不做 SFU。他们在边缘节点直接拦截来自浏览器的 WebRTC 数据包，将其转化为内部格式。他们没有透露内部通信细节（可能是 WebSocket 或其他协议），但这不重要。关键在于，他们将客户端几乎「直接」连到了处理 WebRTC 的边缘网关上。

第四，巧妙的「ICE ufrag Hack」。为了实现全系统的无状态（Stateless）扩展，他们需要负载均衡器能准确路由数据包。他们出人意料地利用了 SDP 中的 ICE ufrag 字段来标记身份。这本质上是把协议原有的行为进行了一次极具智慧的「魔改」，解决了海量并发下的客户端识别难题。

Arin： 这些细节确实非常硬核。我想重点聊聊「不使用 SFU」这个决定，因为它最具冲击力。对于习惯了标准 WebRTC 开发建议的人来说，这几乎是「反常识」的。

但必须强调：这套方案高度适配 OpenAI 的特定场景，但并不意味着传统建议失效了。 如果你是在构建一个标准的多人视频会议工具，SFU 依然是你的必选项。哪怕是为会议加入 AI 助手，AI 也应该作为一个「参会者」通过 SFU 加入。

Tsahi： 同意。OpenAI 的场景更接近于「云游戏」。在云游戏架构中，你绝不会引入 SFU 增加延迟，而是让游戏服务器直连用户。

另一个值得关注的运维决策是：UDP 管道完全运行在 Linux 的用户态（User space），而非内核态。即便在追求极致性能的千万级并发场景下，他们依然认为在用户态处理已经足够好，没必要为了那点微小的提升去折腾内核优化。

他们选择了两项更具性价比的优化：

单机多进程： 通过启动多个监听同一端口的独立进程，榨干多核 CPU 的算力。
CPU 亲和性（Thread locality）： 确保特定流量始终由同一个核心处理，最大限度地利用 CPU 缓存，降低切换开销。

这些都是非常务实的底层优化手法。在如今浮躁的技术圈，能看到这样回归本质的架构决策，真的让人耳目一新。

Arin： 最后我们聊聊未来。上个月我们讨论 WebTransport 时，认为它非常适合 Voice AI。但 OpenAI 目前完全没提它。你认为这意味着 WebRTC 的统治地位不可动摇，还是说他们未来仍会转型？

Tsahi： 没有任何技术是永恒的。我职业生涯早期做的是 H.323，后来是 3G-324M，它们最终都被时代淘汰了。WebRTC 会陪伴我们很久，但不会是永远。

OpenAI 这篇文章是一次现状总结。他们寻找的是连接最快、扩展性最强、延迟最低的路径。如果未来有任何新技术（比如 WebTransport）能再稳定地降低 20-30 毫秒的延迟，我相信他们会毫不犹豫地转向。只不过目前，除了 Demo 之外，还没人能在 WebTransport 上支撑起这种规模的生产应用。

Arin： 毕竟他们要支撑的是 9 亿周活用户的恐怖体量。在这个规模下，任何关于扩展性的微小创新都显得魅力十足。

强烈建议大家去读一下 OpenAI 的原博。Tsahi，非常期待你五月份与 Justin Uberti 的对话，届时一定会碰撞出更多火花。

Tsahi： 没错，大家可以关注我的 LinkedIn 获取具体日期。

Arin： 感谢 Tsahi 的精彩解读。想要了解更多，请访问 Bloggeek.me 关注 Tsahi 的工作，或在 WebRTC.ventures 关注我们的后续更新。感谢收看！（完）

原文：

https://www.linkedin.com/posts/no-sfu-no-problem-openais-secret-webrtc-ugcPost-7458152530552766464-aPS3/

编译：傅丰元

AI 代码为什么更多 BUG

Fhaohaizi — Mon, 11 May 2026 13:08:38 +0800

AI 的效率红利正在被质量黑洞吞噬，而这不是一个能靠迭代修复解决的暂时问题。当整个行业都在讨论 AI 如何让开发者写代码更快时，一组反向数据也在不断积累：AI 生成代码的关键缺陷是人类代码的 1.7 倍，安全漏洞高出 1.5～2 倍，67% 的开发者表示自己花了更多时间调试 AI 生成的代码。效率提升的承诺，正在被验证成本抵消。更关键的是，这背后有一个数学层面的根本原因，而不只是工程层面的不成熟。

从一个真实事故说起

某电商公司 2025 年做了一个看似合理的决定：裁撤 12 人 QA 团队，部署 AI 自动化测试系统，预计每年节省 120 万美元。结果 AI 系统在一次促销活动中生成了错误的折扣码逻辑，把全站所有产品价格设为零。订单在几小时内涌入，损失约 600 万美元，是预计节省成本的 5 倍。

这个案例常被引用来说明 AI 不可靠。但它真正值得追问的问题是：为什么 AI 系统没有发现自己生成的错误？答案不在于这个 AI 系统质量差，而在于 AI 生成内容时的结构性机制。

数据层：AI 代码的缺陷画像

CodeRabbit 在 2025 年 12 月发布了一份分析大量 Pull Request 的报告，数据非常具体：

AI 生成代码的关键和重大缺陷是人类代码的 1.7 倍
逻辑和正确性问题上升 75%
安全漏洞上升 1.5～2 倍
代码可读性问题增加 3 倍以上

Google 2025 年 DORA 报告的视角不同，但结论方向一致：AI 采用率增加 90% 与 bug 率增加 9% 相关，代码变更失败率增加 91%。NYU 对 1692 个 GitHub Copilot 程序的研究发现，其中 40% 含有可利用安全漏洞。

这些数字叠加在一起，指向一个悖论：AI 越被大规模使用，整体代码库的质量风险越高。Sonar 的报告也直接指出，在 AI 加速的代码库里，技术债务会以更快速度积累，代码质量下降几乎是不可避免的趋势。

机制层：幻觉为什么在数学上不可消除

数据告诉我们 AI 代码有问题，但还没有解释为什么。这里有一个很多人没意识到的核心事实：LLM 幻觉在数学上被严格证明不可消除。

2024 年，Xu 等人的研究从信息论角度证明：任何通过预测统计分布中概率序列来生成文本的系统，必然会产生不基于事实的输出。2025 年，Karpowicz 从拍卖理论、评分理论和 Transformer 架构三个独立框架得出相同结论。

这不是技术不成熟，不是数据不够多，不是模型不够大，而是生成方式本身的结构性约束。大语言模型在生成每一个 token 时，本质上是在做概率预测，预测接下来最可能出现什么。当这个机制应用于代码生成时，它输出的是看起来最合理的代码，而不是逻辑上正确的代码。两者在大多数情况下会重合，但在边界条件、异常处理、安全场景下往往分叉。

幻觉在代码领域的表现尤其棘手。UTSA 与 Virginia Tech 联合研究了 576000 个代码样本，发现 19.7% 的 AI 包推荐是虚构不存在的。其中一个幻觉包 huggingface-cli 在三个月内被下载超 30000 次，尽管它根本不含任何代码。开发者看到 AI 推荐的包名，直接安装，没有核验，有时安装到的就是恶意克隆包。

认知层：AI 不知道这是不是问题

幻觉解释了 AI 为什么会生成错误代码，但还有另一个更隐蔽的问题：即使代码在技术层面是正确的，AI 也不知道它在业务层面意味着什么。

某语音识别系统的技术准确率达到 98%，按任何技术指标看都很优秀。上线后却遭到大量南方用户投诉。原因是训练数据里 90% 是北方口音，AI 学到的模式本身就是偏差，而且它不知道这是偏差，它只知道自己很准确。

这类问题不是幻觉，而是语境缺失。AI 不知道 200 毫秒延迟在结账页是关键问题，但在内部管理面板可以接受；不知道某个表单在老年用户群体里的操作逻辑是什么；也不知道某个功能对医疗场景的合规要求和对娱乐场景完全不同。换句话说，AI 能复现模式，但很难自动理解这个模式在具体业务里的后果。

Qase.io 的分析指出，即使是最新的 AI 代理系统，面对复杂企业应用，例如基于角色的访问控制、多步骤工作流、数十个第三方集成，仍然脆弱不堪，需要持续的人类护栏。不是因为 AI 不聪明，而是因为业务判断依赖的是在特定环境中积累的经验，不是对训练数据的统计拟合。

AI 越能写代码，验证代码的需求越大

理解了幻觉机制和语境缺失，再来看 AI 代码质量数据，逻辑就很清晰了。

67% 的开发者表示花了更多时间调试 AI 生成的代码。这个数字不是说 AI 没用，而是说 AI 把时间从写代码转移到了验证代码。当代码生成速度提升 3 倍，而验证成本也同步上升时，效率红利就会被部分甚至全部抵消。

更深的含义是：验证这件事本身变得更重要，也更复杂。过去验证人类写的代码，主要是检查实现是否符合设计；现在验证 AI 写的代码，还需要识别幻觉引入的逻辑漏洞，判断技术正确性之外的业务适配性，并追踪 AI 无法感知的偏差。

这不是测试工作量的简单增加，而是测试工作性质的升级。GitLab 的调查数据是一个很好的注脚：75% 的关键缺陷最终仍靠人工发现。 AI 测试工具可以覆盖大量重复路径，但真正高价值的缺陷，依然需要人来识别。

AI 越能写代码，世界就越需要能验证代码的人。而能验证 AI 生成代码的人，和能验证人类写的代码的人，所需的能力已经不完全相同。测试不再只是找 bug，而是要判断代码、业务、风险和语境之间是否真的对齐。

FunTester 名片｜万粉千文，百无一用

AI 赋能测试实践 09：MCP 来了，测试人员怎么接？三个趁手的工具 + 50 行搓一个自己的测试 Server

EternalRights — Mon, 11 May 2026 13:05:59 +0800

前言

2024 年底 Anthropic 发布了 MCP 规范，这个词在 2025 年逐渐火了起来。但笔者看了一圈市面上的文章，要么在讲"什么是 MCP"这种概念科普，要么是"5 分钟搭建 MCP Server"的通用教程。面向测试人员、告诉你"这东西能帮我解决什么测试问题"的文章，少之又少。

笔者在日常测试工作中一直在琢磨：MCP 能不能直接拿来提升测试效率？于是花了些时间研究，找到了几个现成的工具，也自己动手搭了一个。这里把学习成果分享出来，供大家参考。

这篇不打算讲概念，直接上干货：三个现成的 MCP 工具，配置完就能用；再带你用 Python 搭一个自己的测试 MCP Server 框架；最后把 Skill 跟 MCP 的关系说清楚。

三个现成的测试 MCP 工具

Playwright MCP——微软官方，测 UI 的

微软出的 MCP Server，让你用自然语言操控浏览器。笔者体验下来，最亮眼的是三个 Agent：

Planner Agent：自动探索你的应用，输出测试计划（Markdown 格式），省去了人工梳理测试场景的步骤。

Generator Agent：把测试计划转成可执行的 Playwright 测试代码，从计划到脚本一步到位。

Healer Agent：测试挂了自动修，定位器更新、等待调整都不需要你手动改。这个功能笔者觉得最实用，写过 UI 自动化的人都知道，定位器动不动就失效，改到头疼。

配置方式（三种任选）：

VS Code：settings.json 加一行

Cursor：Settings → MCP → Add

Claude Code：claude mcp add playwright npx @playwright/mcp@latest

api-tester-mcp——专为 QA 设计的接口测试工具

PyPI 上的包，6.9K 下载量。从 Swagger 到测试报告，全自动。这个工具封装了 10 个工具，形成了一条完整的工作流：

ingest_spec（加载 API 文档）
  → set_env_vars（配置认证）
  → generate_scenarios（生成场景）
  → generate_test_cases（生成代码）
  → run_api_tests（执行测试）
  → run_load_tests（还能跑负载）

配置方式很简单，在 MCP 配置文件中加上：

{
  "mcpServers": {
    "api-tester": {
      "command": "npx",
      "args": ["@kirti676/api-tester-mcp@latest"]
    }
  }
}

笔者拿 Petstore 的 Swagger 文档试了一下，从加载文档到生成 HTML 测试报告，全程没写一行代码。接口测试用这个确实省事。

mcp-swagger-server——让你的 API 文档"活"过来

一行命令把 OpenAPI/Swagger 文档变成 AI 可直接调用的工具：

mcp-swagger-server --openapi https://api.example.com/openapi.json

这个工具有个有意思的用法，可以用来测试你的 API 文档质量。因为很多文档结构有问题，一转换就暴露了。笔者之前遇到过一个项目，Swagger 文档看着挺规范，结果一跑 mcp-swagger-server，直接报了三个 schema 错误。所以它不光能让 AI 调用你的 API，还能顺便帮你检查文档质量。

三个工具对比

工具	适合场景	安装复杂度	关键亮点
Playwright MCP	UI 自动化	★☆☆☆☆	Healer 自动修测试
api-tester-mcp	接口测试	★☆☆☆☆	Swagger→报告全自动
mcp-swagger-server	API 文档活用	★☆☆☆☆	一行命令

50 行搭一个自己的测试 MCP Server

自己动手搭一个，有三个原因

现成的工具固然好，但总有场景需要定制。一是你的公司用内部测试平台，没有公开 API；二是你想把一些运维脚本、数据查询封装成 AI 能调用的工具；三是你想搞清楚 MCP 到底是怎么工作的。笔者自己搭了一个之后，才真正理解了 MCP 的运行机制，这个认知上的收获比工具本身更有价值。

选一个测试场景

场景：让 AI 帮你查当前迭代的测试统计数据。

输入：自然语言"当前迭代的测试情况怎么样？"

输出：AI 自动调用 MCP 工具查询数据并返回结果。

这个场景很常见，每天站会前都要查测试状态，手动查费时费力，交给 AI 一句话搞定。

代码实现

下面是一个可运行的 MCP Server 框架。函数体里是示例数据，你需要替换成自己实际的查询逻辑（比如对接 JIRA API、禅道 API、内部测试平台等），但框架本身是完整的，跑起来就能被 AI 调用。

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("Test Stats")

@mcp.tool()
def get_test_stats(sprint: str) -> str:
    """获取指定迭代的测试统计数据，包括用例执行情况和缺陷分布"""
    # 替换成你实际的查询逻辑，比如调用 JIRA/禅道 API
    import requests
    # resp = requests.get(f"https://your-jira/api/sprint/{sprint}/stats",
    #                     headers={"Authorization": "Bearer xxx"})
    # data = resp.json()
    # 下面是示例数据，实际使用时替换为上面的查询结果
    return f"{sprint} 迭代：用例通过 156 个，失败 8 个，关闭率 95.1%"

@mcp.tool()
def get_recent_failures(days: int = 7) -> str:
    """获取最近N天测试失败的用例列表及失败原因"""
    # 同理，替换成你实际的查询逻辑
    return f"最近 {days} 天共有 15 个用例失败，其中 12 个已确认修复，3 个待排查"

if __name__ == "__main__":
    mcp.run()

几个关键点说一下：

FastMCP 是 Python SDK 的简易封装，几行就能起一个 Server，不需要从零搭建通信层。

@mcp.tool() 装饰器把函数变成 AI 可调用的工具，不需要额外写接口定义。

函数的参数和 docstring 会被自动解析为 AI 理解的工具描述，所以 docstring 一定要写清楚，AI 靠它来决定什么时候调用这个工具。

配置到 Claude Code

{
  "mcpServers": {
    "test-stats": {
      "command": "python",
      "args": ["path/to/your/server.py"]
    }
  }
}

配置完直接问 AI："当前迭代测试情况怎么样？"AI 会自动调用 get_test_stats 工具，不需要你写任何胶水代码。笔者第一次跑通的时候，确实有种"原来就这么简单"的感觉。

Skill 跟 MCP 的区别

很多人问 MCP 和 Skill 的区别，这里统一说明。

一个类比：MCP 是螺丝刀，Skill 是安装说明书。螺丝刀管"能不能做"，安装说明书管"怎么做"。

	MCP	Skill
本质	通信协议	行为指令
定义	工具的输入/输出格式	怎么做任务的步骤
例子	api-tester-mcp 暴露了 10 个工具	"先读 Swagger，再生成代码，再执行"
复用范围	任何 MCP 客户端	Claude Code / Cursor 等特定工具

MCP 给 AI 提供了"能做什么"，Skill 告诉 AI"应该怎么做"。两者结合才是完整的测试自动化方案。

至于怎么用 Skill 把测试流程标准化、怎么保证 Skill 的质量，那是下一期的内容了。

后记

这篇给了三个现成的 MCP 工具，Playwright MCP 测 UI、api-tester-mcp 测接口、mcp-swagger-server 活用 API 文档，配置完就能上手。然后带各位了解了如何搭建 MCP Server 的框架，代码量不大，核心是搞清楚 @mcp.tool() 装饰器和 docstring 的作用，替换成你自己的查询逻辑就能用。笔者希望各位读完之后能真正动手跑一下，光看不练等于没看。最后把 MCP 和 Skill 的区别理清了，MCP 是工具协议，Skill 是行为指令，别再混为一谈。

下期预告：Skill 深度实战——如何把一套测试流程封装成可复用的 Skill。

君子性非异也，善假于物也。

ATM 没有消灭柜员，AI 也不会消灭测试

Fhaohaizi — Sun, 10 May 2026 22:50:53 +0800

把任务自动化等同于岗位消除，是贯穿整个技术史最常见的分析错误。每隔几年，就有一项新技术被宣判为某类职业的终结者。流水线消灭工人，ATM 消灭柜员，电子表格消灭会计，自动化测试消灭测试工程师，现在轮到 AI。但历史的实际轨迹几乎从不是预言里的那条直线。理解这个模式，不是为了盲目乐观，而是为了看清真正的威胁在哪里，以及真正的机会在哪里。

ATM 的故事

IMF 经济学家 James Bessen 记录过一个被广泛引用的案例。ATM 在 20 世纪 70 年代引入美国，到 90 年代中期大规模部署，全美超过 40 万台。按直觉推断，ATM 处理了大量取款、存款、查询业务，每个网点所需的柜员数量应该大幅下降，银行也会顺势关闭人力成本高的网点。

实际发生的事情是：每个网点的柜员数确实从 1988 年的 20 人降至 2004 年的 13 人，下降了 35%。但银行利用降低的运营成本开设了更多网点，城市地区网点增加了 43%。柜员总数不降反升。

关键转变不在数量，而在角色。柜员从现金处理者变成了关系银行团队成员，开始专注于销售金融产品和处理复杂客户服务。这些工作依赖信任、判断和上下文沟通，ATM 无法完成。CCIA 的分析一针见血：把任务自动化与岗位消除混为一谈，是所有 XX 将被淘汰 预言里最常见的逻辑错误。

软件测试领域的三次浪潮

软件测试领域自己就是这个模式的活教材，而且已经经历了三轮。

QTP 时代（2000 年代初），惠普推出 QuickTest Professional，图形化录制回放让非技术人员也能生成测试脚本。当时的预判是：既然工具能自动生成脚本，手动测试工程师就没有存在价值了。实际结果是：手动执行者确实减少了，但会写 VBScript、能维护和扩展脚本的测试工程师需求上升。角色从执行者变成了脚本编写者。

Selenium 时代（2010 年代），开源框架降低了门槛，自动化测试不再是大公司的专属。预判再次出现：工具越来越简单，测试工程师的技术门槛会消失。实际结果是：Selenium 本身需要 Java 或 Python 能力来管理，框架搭建、数据管理、环境配置的复杂度让测试工程师反而需要更强的开发能力。角色从脚本编写者变成了框架架构师。

DevOps 浪潮（2015 年以后），持续集成、持续交付让测试是最后一道关口的模式被彻底打破。预判是：开发者自己写测试，QA 团队会被吸收或消解。实际结果是：大型 QA 团队的比例从 2023 年的 17% 上升到 2025 年的 30%。DevOps 没有压缩测试团队，而是扩张了测试的定义，把 DevOps 工程师、开发者和产品角色都纳入质量责任链条，同时让测试工程师深入 CI/CD 管道，成为质量工程师。

三次浪潮，三次被消灭，三次完成角色蜕变。被淘汰的不是测试这件事，而是停留在单一执行动作上的岗位形态。

当前数据的矛盾信号

理解历史模式之后，再看当前 AI 浪潮里的数据，矛盾的信号就不那么令人困惑了。

McKinsey 2025 年《State of AI》报告同时包含两个看似矛盾的数字：32% 的组织预计 AI 在来年缩减劳动力，但 28% 的软件工程高管预计 AI 反而会增加人手。同一个技术，两个方向的预期。原因在于，不同公司处于不同阶段，应对方式不同，结果也不同。

Tesla 的 QA 团队数据提供了一个更具体的参照。从 2020 年到 2025 年，手动测试人员减少了 75%，但 AI 测试专家增长了 850%。团队没有缩小，而是彻底进化了。消失的是重复执行，增加的是 AI 系统的设计、训练、验证和维护。

Gartner 修正了早期的预测。新的判断是：常规测试任务将在 2030 年前自动化 60%~70%，但对技术 QA 专业人员的需求将增加 25%。这个修正背后是现实教训的积累，不是乐观主义。

被裁撤的 AI 招聘系统

Amazon 曾开发了一套 AI 招聘系统，用来自动筛选工程师候选人的简历。系统运行一段时间后，工程师团队发现它在系统性地降低女性候选人的评分。原因是训练数据主要来自过去十年的招聘记录，而过去十年提交简历的工程师以男性为主，AI 把男性简历特征学成了优秀工程师特征。

Amazon 最终废弃了这个系统。这个案例最常被引用来说明 AI 的偏见问题，但它同时说明了另一件事：缺乏充分测试的 AI 系统，其失败方式往往不可见，直到造成了真实伤害。

偏见与公平性测试、幻觉检测测试、模型漂移测试，这些是 AI 时代才出现的测试类型。它们不是对旧测试工作的替代，而是全新的测试需求。EU AI Act 的落地进一步将 AI 系统的测试要求法规化，为测试工程师打开了明确的合规专业通道。

消失的是什么，留下的是什么

回顾 ATM 案例和测试领域三次浪潮，消失的始终是同一类工作：高度重复、规则明确、不需要判断的执行任务。留下的始终是同一类工作：需要理解语境、作出判断、处理边界情况和异常的工作。

AI 当前的替代范围，正好落在高度重复、规则明确这个区间。Atlassian 裁员时明确指向的 QA 角色，是手动回归测试执行者；Facebook AI 视觉框架压缩的 80% 工作量，是人工像素级比对；Coherent Solutions 减少的 35% 测试工作量，是样板测试用例的编写。

而 GitLab 的调查显示，75% 的关键缺陷最终仍靠人工发现。探索性测试、业务上下文判断、用户同理心，这些工作不是 AI 懒得做，而是它的结构性能力边界。James Bach 说过：当你把一个人类执行过的测试自动化时，它已经不再是同一个测试；在他的理论框架里，它甚至只能算输出检查，而不是真正的测试。

测试的本质是一种认知活动。

结构性变化的真实面目

World Economic Forum 的预测给出了宏观坐标：自动化可能消除 8500 万个工作岗位，但有潜力创造多达 9700 万个新岗位。净值是正的，但分布不均匀：消失的岗位和新增的岗位，要求的能力不同，时间窗口不同，地理分布也不同。

对测试工程师来说，这意味着：转型不是可选项，时间窗口是有限的。当前 75% 的组织已将 AI 测试列为战略重点，但真正落地的只有 16%。这个落差，就是窗口期。

ATM 没有消灭柜员，但也不是所有柜员都平稳转型成了关系银行专家。那些没有意识到角色在变、没有主动学习新技能的人，确实经历了职业困境。AI 不会消灭测试工程师，但不愿意转变认知框架的测试工程师，会被已经完成转变的同行取代。

浪潮不问你准备好了没有，但准备好的人和没准备好的人，站在浪里的感受完全不同。

FunTester 名片｜万粉千文，百无一用

针对 AI 说几句心里话 -- 拥抱 AI，世界不以个人的意志为转移

ycwdaaaa — Sun, 10 May 2026 16:20:52 +0800

前言

今日休假，不加班。家里也没有什么事，算是难得的给自己放空大脑的机会。过去的 1 年多是 AI 爆炸的风口，我们本身就在 AI 领域人的人应该可以体会到这是多么疯狂的一个时期。所有人都在马不停蹄的奔跑，大家怕抢不到这个风口，怕被淘汰，甚至害怕自己的职位被 AI 取代掉。在我星球的小伙伴们，可以从我更新的速度感受到现在的态势。

我对 AI 的态度

在几年前的时候，我虽然在 AI 领域中工作，但在当时我是反对 AI 应用在测试领域中的先锋了，早年间我还写过一个帖子开喷。

之所以开喷，是因为当时的 AI 真的不行。即便几年后 GPT 火了起来，也还是不行。直到去年年初，我开始重新调研 cursor，用 30 分钟就写出了以前需要几天才能开发完的工具，那时我开始确定，AI 要颠覆整个行业了。

cursor，codebuddy，codex，claude code，这一年多以来我体验了业内半数的 AI 代码辅助工具。如今我已经把 90% 的工作交给了 AI，完成了以前需要 4,5 个我才能完成的工作量。当然，指挥 AI 也是个不小的工作量。现在行业内疯狂的卷 harness，也是为了能把指挥 AI 的成本降低。

老实说，我一开始内心里也有很大的抵触，毕竟自己练了很多年的东西说让 AI 给替代了，我心里不服，也不愿意接受。但世界总是不以个人的意志为转移。不接受现实的人，终将是走不远的。

大厂的人都在做什么

在我还没有进入大厂之前，我有个习惯，当我迷茫不知道要怎么发展的时候，就去找大厂的朋友聊天。我把大厂当风向标，摸着大厂的技术栈过河。他们卷什么，我就卷什么，因为我发现大厂总是比普通公司布局的更早，很多时候我们兴高采烈的去分享一些新的发现的事后，会发现这些是大厂内部已经布局了一年甚至几年的东西了。

当年测试行业还在争论技术无用论的的时候，大厂早就把集团员工测试岗位的招聘标准，焊死在技术工种这个标准上了。即便是在当年，你说你代码写的不好？那这辈子就别想跨进大厂的门槛了。

所以，AI 编程大火是在今年开始的，但其实去年我们就已经大范围铺开 AI 辅助了，中心内部各种 AI 的实践分享就已经开展了起来。几乎所有人的看法都非常一致，这一波 AI 变革，会改变很多个工种的工作方式和人员去留。

在几个月的年前，公司就已经定下了 特种兵 +AI 的发展路线，也就是我一直在说的，未来混得好的技术人员，是专家 +Agent的工作模式。专家的行业经验，加上 AI 提升的工作效率，将进一步拉开普通人和专家的差距。我一直在讲，AI 是需要人来指导的，AI 是可以把人的能力数倍的放大的，但如果人的能力是零，那 AI 再怎么放大，还是零。这也是为什么现在好些人仍然觉得 AI 是扯淡的，是某些领导的 KPI 工程的原因。因为受限于工作内容的简单单一和个人能力的限制，这部分人是感受不到 AI 带来的变革的。甚至说，多年前坚持技术无用论的，可能也是这一波人。所以不要说 AI 了，这些同学甚至感受不到技术力带来的变革。

所以还在观望 AI 的同学，可以看看大厂的人都在做什么，尤其大厂的人用 AI 做了什么。

我现在的工作模式，已经变成了遇事不管决不决，都先去找 AI的习惯。AI 的提效，已经把以前我们想做但没有时间和成本去做的事情，变成了可实现的路径。比如我们都希望有 UI 自动化，因为只有端到端的测试，才是最保险的，最贴近用户的。但我们都知道维护 UI 自动化的成本有多高，手工去写代码和 xpath 的成本，产品需求变化的成本，前端元素变动的成本。这些都让实践 UI 自动化变成了一件很难的事。但现在呢？我给大家看一下我的的工作内容：

我只需要像上图一样，把执行步骤输送给 AI。AI 就会帮我写 UI 自动化测试的代码，定位控件，启动浏览器测试，纠错等工作。而我们担心的前端控件会变化的事情，也最大程度上被避免了，因为现在的控件定位，都是用 AI 来定位的。如下：

// 在模型搜索框中输入
await agent.aiInput(
  "模型搜索弹窗中的搜索输入框",
  { value: modelName }
);

程序运行的时候，会动态截图，并传送给大模型，大模型接收到就会找到用户用自然语言描述的那个控件在哪个位置。这样，我不用像以前一样去费尽的写 xpath，也不用担心前端程序重构后，xpath 会变。因为现在控件定位就不依赖 xpath。而 AI 写出来的程序，是张这个样子的：

describe("模型广场 - 自定义 OpenAI 模型 (P0)", () => {
  const ctx = usePlaywrightWithAuth();

  test(
    "添加自定义 OpenAI 模型并在查看弹框中验证",
    { tags: ["private"], timeout: 180_000 },
    async () => {
      const svc = new ModelMarketService(ctx.page);

      // 生成唯一的模型名称（遵循命名规范：含 _qta 后缀，≤15 字符）
      const suffix = String(Date.now()).slice(-6);
      const modelName = `m_${suffix}_qta`; // 12 字符
      console.log("[Test] 模型名称:", modelName);

      // 从环境变量读取配置，避免硬编码敏感信息
      const modelId = process.env.MODEL_MARKET_MODEL_ID!;
      const apiUrl = process.env.MODEL_MARKET_API_URL!;
      const apiKey = process.env.MODEL_MARKET_API_KEY!;

      // Step 1-2: 导航到模型广场
      await svc.navigateToModelMarket();

      // Step 3-12: 点击 OpenAI Compatible 添加按钮，填写表单并提交
      await svc.addCustomOpenAIModel({
        modelName,
        modelId,
        apiUrl,
        apiKey,
        contextLength: 32,
        inputLengthLimit: 16,
        tag: "全模态",
      });

      console.log("[Test] 模型已添加，准备验证");

      // Step 14-16: 点击查看按钮，验证模型信息
      await svc.viewOpenAIModels();

      // 验证模型名称显示在查看弹窗中
      const exists = await svc.verifyModelExists(modelName);
      expect(
        exists,
        `模型"${modelName}"应该在查看弹框中显示`
      ).toBe(true);

      console.log("[Test] 模型验证成功 ✓");
    }
  );
});

可以看到，svc.addCustomOpenAIModel 这个方法是一系列的控件操作的组合。我的手工 case 里并没有告诉他要抽象一个公共方法，但 AI 认为这个表单是可以封装成公共的方法的，所以它就这么做了。尽量避免了我们后续 case 多了，变成屎山代码的可能。当然要让 AI 做到完全只需要一个手工测试用例步骤，就生成这样的 UI 自动化代码，这需要编写一个很专业的 skill 来指导 AI。这也是我在上一篇文章讲的：万字长文：如何用 harness 的理念设计一个 AI 驱动的 UI 自动化工程。

AI 把编写和维护 UI 自动化测试的成本，磨到了一个十分低的程度，这让一切都变的有更大的可能。

而如果我想做性能测试，我只需要对调教好的 Agent 说明需要测试的场景，它就会自动编写造数脚本和 locust 压测脚本，执行后给我一个汇总报告：

而如果我想做高可用测试（容灾测试），我仍然只需要跟我调教好的 Agent 表达这个意思，它就会：

确定执行后，它会帮我到每个机器上安装故障注入工具：

注入工具后，它会运行业务脚本（也是 AI 生成的）并检查测试情况：

所以这就是我的工作状态，每天不是在调教 AI（写 skill），就是在指挥 AI 干活。或者在去探索使用 AI 的更多的可能性。所以为什么我刚才说，现在我干的活是以前 4,5 个我才能干的。因为真正干活的是 AI，而不是我。如果没有 AI 的能力，就我们现在这个迭代速度和已经交付了上百个 TO B 私有化客户的规模，就是累死我，我也测不完。

调整心态

早年的我，在一段时间里也有一个毛病 -- 世人皆醉我独醒。但现在想想，我当时是挺可笑的。这些国内的顶级公司，在这个行业占据龙头位置十数年，有无数高学历，高认知的人才为之效力。我竟然会觉得我一个人的思考会比他们更强？这是何等狂妄的心态。而这种心态，往往会让我拒绝去接受那些在未来对我十分有帮助的知识。说白了，这就是一种认真缺陷。大厂们探索，实践并总结出有效的经验，我却弃之如敝履。

这种世人皆醉我独醒的心态，曾经让我走过不少弯路。而在 AI 浪潮刚开始的时候，我也仍然有这个心态。就像我上面说的，最开始的时候我不服，我不接受 AI 能强到那种程度。他们一定是骗人的，他们做这些事是为了忽悠领导，搞 KPI 工程，出来卖课割韭菜。

然后我就想起了我的这个毛病，我就在想，我凭什么认为那么多优秀的人都认为有价值的东西，是假的？尤其是在我还没有认真去调研的情况下，就下了这个定论？所以，去年的时候我去找到同事，开始请教，开始在群里找有经验的人，开始在 B 占看教程。仅仅几天时间，AI 的强大就让我后悔 -- 我为什么没有更早的开始使用 AI 完成工作。

有些时候就是这样的，以前如大山一般的偏见，往往在极短的时间内就被轰碎。

我总说人一旦开窍了，进步就一日千里。而开窍的契机，往往先从心态的改变开始。正如我这篇文章的标题：世界不以个人的意志为转移。不论我们再怎么否定一件事，这个世界不会因为我们不乐意，就改变它的运作法则。就如同当今的行业，不论我们有多不甘心，多不认可。特种兵 + AI 的模式，就会是未来的主流趋势。

所以调整心态，不要再跟大势对抗。我说的直白点，大家出来工作为了什么？不就是赚钱么。古人都说：学成文武艺，卖与帝王家。那整个测试行业，以前要卷的是技术，现在要卷的是 AI。标准答案就在这摆着，难道大家就要这么白白错过这个上车的机会？俗话说的好，跟什么作对也别跟钱作对。即便内心可能是不认可 AI 的，但咱先进去把钱挣了好不好？我们是要顺应大势，进入主流公司拿高薪。还是坚持自己那可能不是很正确的真理吃土？我选择前者。我没有那么多的理想主义，我出来工作，只为了挣钱。

结尾

我们的行业就是这样，逆水行舟，不进则退。不论已经积累了多少年，永远都有新的技术栈在等着我们。不去拥抱最新的技术和潮流，就会被后浪拍死在沙滩上。现在的后浪技术一个比一个猛，底子一个比一个好，想法一个比一个大胆。今天想写这个文章，也是看到最近还有很多同学不认可 AI，所以有感而发。就说道这里吧。最后再宣传一下我的知识星球，更多的 AI 测试实践都会发表在星球里。

ITP V6.1.0 重磅发布：AI 赋能测试全流程，让用例生成效率提升 10 倍！

mikeh — Sun, 10 May 2026 15:25:13 +0800

写在前面：作为一个在测试行业摸爬滚打多年的老兵，我深知编写测试用例的痛苦——重复、繁琐、还容易遗漏场景。今天，我想和大家聊聊我们团队最新发布的 V6.1.0 版本，看看 AI 是如何彻底改变测试工作的。
一、为什么我们需要 AI 辅助测试？
先说个真实的故事。上个月，我们接手了一个电商平台的回归测试任务，光登录模块就有 50+ 个测试点：手机号登录、邮箱登录、第三方授权、验证码校验、异常场景...手动编写这些用例花了整整 3 天。更崩溃的是，需求变更后又要重来一遍。
那时候我就在想：能不能让 AI 帮我们干这些重复性工作？
经过半年的研发和打磨，智能测试平台（ITP）V6.1.0 终于给出了答案。这个版本不是简单的功能堆砌，而是从功能测试、接口自动化、业务流程编排到平台个性化配置的全方位升级。

二、核心功能深度解析
2.1 AI 生成功能测试用例：一句话搞定测试设计
传统方式 vs AI 方式
以前写功能测试用例，你需要：
阅读需求文档（30 分钟）
梳理测试点（1 小时）
逐条编写用例标题、步骤、预期结果（2-3 小时）
评审修改（反复迭代）
现在，你只需要：

输入："帮我生成用户登录功能的测试用例，包括正常登录、密码错误、账号锁定等场景"
AI 会在 30 秒内返回：
✅ 完整的用例标题
✅ 详细的测试步骤
✅ 清晰的预期结果
✅ 合理的优先级标注（P0-P3）
✅ 自动打标签（如：登录、安全、边界值）
技术实现亮点
我们采用了多模型适配架构，支持阿里云百炼、Kimi 等多种 AI 提供商。

关键优化点：
JSON 格式强制约束：通过 System Prompt 和正则表达式双重保障，确保 AI 返回结构化数据
Token 用量监控：内置每日/每月 Token 限制，防止超额消费
会话级管理：每个项目的测试会话独立存储，方便追溯和复用

2.2 AI 生成接口测试用例：从需求到用例的自动化链路
接口测试用例的编写往往比功能测试更复杂，需要考虑：
请求参数组合
响应断言规则
异常状态码处理
依赖接口的数据传递
V6.1.0 的解决方案是：基于 RAG（检索增强生成）的智能推荐。
工作流程
A[用户输入需求] --> B[RAG 检索相似用例]
B --> C[AI 分析接口特征]
C --> D[生成新用例]
D --> E[自动保存到数据库]

实际案例：
假设你要为 /api/user/profile 接口生成测试用例，系统会：
检索历史用例：找到项目中类似的 GET/POST 接口用例
提取模式：分析参数验证、权限校验等通用逻辑
智能生成：

{
"title": "获取用户信息 - 正常场景",
"interface_url": "/api/user/profile",
"method": "GET",
"headers": {"Authorization": "Bearer ${{token}}"},
"assertions": [
"status_code == 200",
"response.data.username is not null"
]
}

2.3 AI 生成业务流程：用例拼接的智能助手
单个接口测试只是基础，真实的业务场景往往是多个接口的组合。比如电商下单流程：

登录 → 查询商品 → 加入购物车 → 提交订单 → 支付 → 查询订单状态
V6.1.0 引入了对话式业务流程生成器，这是整个版本我最喜欢的功能。
使用示例
用户在聊天框输入：
"我想把'成功登录'和'查询司机状态'这两个用例拼接成业务流程"
AI 会自动：
语义理解：识别出这是一个业务流程生成请求
RAG 检索：从数据库中查找匹配的用例 ID
智能排序：根据业务逻辑安排执行顺序
返回 JSON：

{
"scene_name": "登录并查询司机状态",
"cases": [
{
"case_id": 123,
"sort": 1,
"description": "成功登录"
},
{
"case_id": 456,
"sort": 2,
"description": "查询司机状态 - 正常查询"
}
]
}
2.4 平台个性化配置：打造专属品牌形象
对于 ToB 产品来说，白标化（White Label）能力至关重要。V6.1.0 新增了完整的平台配置模块，支持：
✅ 自定义 Logo（顶部导航栏）
✅ 自定义登录页背景图
✅ 自定义 Favicon（浏览器标签图标）
✅ 自定义企业名称、ICP 备案信息
✅ 自定义登录欢迎语

上传接口的细节处理：
文件类型校验（只允许 image/jpeg、png、gif）
文件大小限制（Logo 1MB、背景图 2MB、Favicon 100KB）
旧文件自动清理（避免磁盘空间浪费）

这套机制让我们的一家金融客户，在 10 分钟内就完成了平台品牌替换，直接拿去给他们的甲方演示。

三、架构设计思考
3.1 为什么选择多模型适配？
最初我们只接入了 Kimi，但很快发现一个问题：不同的大模型在不同的场景下，效果有显著的差异。
阿里大模型更适合接口自动化，

Kimi 更适合生成功能测试用例。

3.2 Token 用量控制的最佳实践
AI 虽好，但成本不容忽视。我们设计了三层防护：
1.数据库级限流，

2.每日/每月配额检查：

3.前端预警提示：当用量达到 80% 时，界面显示黄色警告条
这套机制帮助某客户将月度 AI 成本控制在 500 元以内（原来预估要 2000+）。

四、实战效果对比

维度传统方式
V6.1.0 AI 辅助
提升倍数
功能用例编写速度
20 条/小时
200 条/小时
10x
接口用例覆盖率
70%（依赖经验）
95%（AI 补全边界场景）

1.35x
业务流程编排时间
2 小时/流程
10 分钟/流程
12x
平台品牌定制耗时
1 天（改代码 + 重新编译）
10 分钟（上传配置
96x
五、如何体验？
目前 V6.1.0 已经开源，你可以通过以下方式体验：
GitHub 地址：[项目仓库链接]
在线 Demo：[Demo 地址]
Docker 一键部署：

docker-compose -f docker-compose.yaml up -d

写在最后
测试行业的变革正在加速。AI 不会取代测试工程师，但会用 AI 的测试工程师一定会取代不用 AI 的同行。
V6.1.0 的目标不是炫技，而是真正解决测试工作中的痛点：减少重复劳动、提升用例质量、加快交付速度。
如果你也在为测试效率发愁，不妨试试这个版本。有任何建议或问题，欢迎在评论区交流！

ITP 体验网址： http://1.95.215.79:18899/ 用户名：tester 密码 88888888

ITP 项目地址： https://gitee.com/hp631012651/itp

StepAudio 2.5 Realtime 上线，升级副语言感知能力；VoiceBlender：基于 Go 的 SIP-WebRTC 桥接服务丨日报

RTE — Sun, 10 May 2026 12:54:08 +0800

开发者朋友们大家好：

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

本期编辑：@koki、@ 鲍勃

01 有话题的技术

1、StepAudio 2.5 Realtime 上线！真人级实时语音对话能力，千万人设任你打造

阶跃星辰正式上线新一代实时语音大模型 StepAudio 2.5 Realtime，重点增强了音频流中的非文本特征解析能力与角色扮演稳定性。开发者现可通过开放平台 API 接口直接接入，构建具备情绪感知并支持深度人设定制的实时语音智能体。

副语言（Paralanguage）原生解析与合成 :模型具备处理语调、语速、停顿以及叹息、轻笑等非文本声学特征的能力。在实时对话中，模型不依赖纯文本转译，可直接分析输入音频的情绪特征，并动态调整生成的语音响应策略。
API 级高颗粒度人设自定义：开发者可通过 API* 对智能体的性格特质、背景经历、个人好恶及语言习惯进行精细调控。该能力底层基于超 10,000 个原生人设，通过算法裂变生成百万级人设特征矩阵进行泛化训练，以维持长尾话题下的响应稳定性。官方同时内置 5 种预设人设* 供快速调用。
面向 Roleplay 场景的 RLHF 对齐：针对角色扮演过程中的「人设崩塌」痛点，该版本专门进行了 RLHF（基于人类反馈的强化学习）对齐优化，提升了模型在复杂语义及极端压力测试环境下的身份一致性与指令遵循能力。

（@ 阶跃星辰）

2、CircuitLaunch 扩展联合制造版图：园区总计 5 万平方英尺，采用零股权纯服务模式

CircuitLaunch 披露其机器人联合制造（co-facturing）中心的最新运营数据及发展规划。该社区明确拒绝传统孵化器的股权置换模式，以提供纯硬件制造服务为核心，目前已累计支持超 120 家初创公司，促成融资总额超 4 亿美元，并正式筹备向旧金山扩张新园区。

纯服务商业模式（Zero-Equity Model）：明确排除通过参股换取资源的传统孵化器路径，定位为纯粹的电子硬件行业服务提供商。开放基础设备与软硬件生态网络访问权限，会员订阅门槛为 195 美元/月。
硬件联合制造（Co-facturing）本地化：依托微制造设备（micromanufacturing equipment）集群，允许初创团队将原型设计、测试及小批量生产环节全部在内部完成。该模式直接规避了早期过早向海外代工厂转移带来的迭代迟缓与知识产权风险。
双园区 50,000 平方英尺基础设施：包含奥克兰园区及一年前启用的山景城园区（位于原波士顿动力公司办公旧址），总运营面积达 5 万平方英尺，成为包含 Unitree 最新 G1 和 R1 人形机器人等前沿硬件的线下测试与首发阵地。
生态网络与无教材机电培训：与包含 600 多家初创企业的硅谷机器人公司（SVR）建立战略互通网络；同时联合推出机电一体化工程项目 mechlabs.ai，废除传统学术讲座与教科书，完全采用纯项目驱动的重型机械与复杂机器人实操训练体系。

( @gritdaily)

3、曝 DeepSeek 融资 500 亿，梁文锋或自投 200 亿

据悉，DeepSeek 创始人兼 CEO 梁文锋可能会在公司成立以来的首轮融资中，个人投入高达 200 亿元人民币，占募资总额的 40%，成为本轮融资中的最大投资者。DeepSeek 希望在本轮融资中筹集到 500 亿元人民币，这将成为中国 AI 公司史上规模最大的一轮融资。

另据一位知情人士透露，中国国家人工智能产业投资基金（大基金）预计将成为 DeepSeek 本轮融资中的第二大投资者。与此同时，这轮融资也促使 DeepSeek 加快创收和商业化进程。

DeepSeek 最近向一些投资者表态，将计划加快模型发布的节奏，使其更接近行业常规速度。其中一位知情人士称，公司计划在 6 月发布其 V4 模型的更新版本 V4.1。DeepSeek 的新模型 V4.1 将为企业用户提供更多工具，并更好地支持 MCP 协议。一位知情人士称，DeepSeek 还计划让 V4.1 能直接处理图像和音频信息，尽管其生成的内容仍仅限于文本。DeepSeek 的本轮融资于 4 月启动，其预期估值已从早期的超 100 亿美元（约合人民币 680 亿元）急剧攀升。4 月 22 日，The Information 曾援引四位知情人士消息报道，腾讯和阿里巴巴正洽谈投资 DeepSeek。此轮融资完成后，DeepSeek 的估值或将超过 3500 亿元人民币。

尽管估值迅速飙升，但一些曾与 DeepSeek 进行洽谈的投资者，对 DeepSeek 创造持续性收入以及加快模型发布速度的能力表示担忧。DeepSeek 一直以研究型实验室的声誉著称，将模型开发置于商业化之上。

DeepSeek 正致力于将技术转化为可供收费的产品和服务，其员工一直在向各行各业的企业推广其模型，希望能激发合作兴趣。据两位知情人士透露，DeepSeek 还从字节跳动的产品开发团队及其他国内科技公司招兵买马。

（@ 智东西）

4、VoiceBlender 发布：基于 Go 的 SIP-WebRTC 桥接服务，支持 WhatsApp 通话与 AI 智能体集成

VoiceBlender 是一款由 Go 语言编写的通讯中间件，实现了 SIP 与 WebRTC 协议的高性能桥接。该服务通过 REST API 和 WebSocket 提供多方音频混合、实时录制及 AI 智能体集成能力，旨在解决跨平台语音互通与自动化语音交互的工程化难题。

全协议栈音频兼容性：支持 SIP 入站/出站（UDP/TLS），覆盖 PCMU、PCMA、G.722 及 Opus 编码；WebRTC 侧支持基于 SDP Offer/Answer 的 trickle ICE 交互；原生兼容 WhatsApp Business Calling（通过 SIP-TLS + DTLS-SRTP 接入 wa.meta.vc：5061）。
高性能音频混合引擎：支持 N 个参与者的多方房间模式，采用「混合减去自身」（mixed-minus-self）算法；采样率支持 8 kHz、16 kHz 及 48 kHz 自定义配置；提供基准 PCM 帧的 WebSocket 实时访问。
AI 智能体与媒体注入：可将对话式 AI 智能体（集成 ElevenLabs、VAPI、Deepgram 等）直接挂载至通话链路，支持会话中上下文注入；内置 TTS/STT 接口及多供应商支持，支持实时语音转录与音频回放。
电信级信令与分析控制：支持 RFC 4028 会话计时、SIP re-INVITE 保持/释放及 RFC 4733 DTMF 事件广播；内置基于 Goertzel 频率分析的应答机检测（AMD），可精确识别语音信箱提示音。
开发者友好监控与扩展：提供 VSI（WebSocket 事件流）实现单连接多租户隔离指令控制；Webhook 支持 HMAC-SHA256 签名与重试机制；原生暴露 Prometheus 指标及 pprof 性能分析接口。

https://github.com/voiceblender/voiceblender

( @GitHub)

02 有亮点的产品

1、阿里千问 AI 眼镜 S1 系统升级：引入双目 3D 空间显示，接入核心应用开放主动调度能力

阿里正式推送千问 AI 眼镜的系统级更新，底层逻辑由单次问答响应转向基于上下文感知的主动式智能体调度。硬件层面通过双光机模组首次在轻量级眼镜端实现立体 3D 视觉输出。此次更新深度调用了阿里生态内的支付与 LBS 应用接口，旨在验证端侧多模态模型在复杂真实场景下的任务闭环能力。

双光机 3D 空间显示：基于双光机搭配双目立体成像技术，将原有的二维 HUD 叠加显示升级为具备景深参数的 3D 空间显示。目前该特性已覆盖系统桌面图标、提词器文本高亮及导航界面。
主动式智能体调度：模型端升级意图推测与上下文多模态记忆（时间、位置、运动指标等）。支持触发式任务执行，例如识别久坐/凝视屏幕触发健康提醒，或基于身体指标与习惯自动编排运动计划并推送音频。
生态应用深度 API 接入：直接调用支付宝视觉识别接口实现扫码解锁共享单车；接入高德地图数据流，支持打车实景寻车以及基于「扫街榜」的实体店面检索；打通票务与外卖系统以支持订单状态的实时悬浮显示。
多模态数据处理优化：语音翻译模块升级为音色克隆同传，保留原说话人音色与语调；录音纪要功能支持结合视觉采集数据，生成图文混合格式（Text + Image）的结构化会议记录。

（@ 智东西）

2、Familiar Machines 推出四足机器宠物 Familiar：集成端侧多模态感知，支持数十个动作自由度

前 iRobot 创始人 Colin Angle 成立初创公司 Familiar Machines，推出一款四足伴侣机器人 Familiar。该设备完全舍弃家务等物理实用功能，依托端侧多模态感知技术捕捉用户的表情与肢体语言，并直接输出非人类语言的物理行为与情绪反馈。

全端侧数据处理（Edge Computing）：性格演化、专属记忆生成及日常多模态交互记录的计算均在设备本地完成，不依赖云端处理，降低家庭私密空间隐私风险。
支持数十个自由度（DOF）：底盘与步态算法由前波士顿动力（Boston Dynamics）工程师主导，机身具备数十个自由度，并结合前迪士尼幻想工程专家调校的微表情与肢体动作进行输出。
具备触觉感知的仿生蒙皮：机身弃用传统金属或硬塑料外壳，采用包裹触觉传感器的毛绒材质，支持对用户抚摸等物理接触的实时感知与数据采集。
物理级规避 LLM 幻觉风险：系统在语音输出端被硬性设定为「禁止输出人类语言」，仅通过动物拟声词响应多模态指令，以此规避当前大语言模型（LLM）对话幻觉对用户交互体验的破坏。

（@ 极客公园）

03 有态度的观点

1、伦敦自动驾驶公司 CEO：端到端 AI 是自动驾驶的未来，授权模式将超越特斯拉和 Waymo

伦敦自动驾驶公司 Wayve CEO Alex Kendall 昨日接受彭博电视专访时表示，Wayve* 坚持端到端 AI 路线，拒绝依赖高精地图和规则系统，其世界模型 GAIA-3 已可模拟复杂城市驾驶场景*。

Kendall 将公司的商业模式定义为有别于特斯拉垂直整合和 Waymo 自建车队模式的「第三条路径」，向整车厂和车队授权 AI 技术。

我们选择授权这项技术给任何车辆、任何地方。我认为这一模式的可扩展性最强，能以最具性能、安全性和成本效益的方式服务整个行业。

针对「端到端 AI 不可解释」的质疑，Kendall 表示这是所有复杂自动驾驶系统的共性挑战，Wayve 已构建模拟器、反事实分析和数据回放等工具链应对监管要求。

与其为了所谓的可解释性限制可扩展性，我宁愿先做可扩展的系统，再想办法让它变得可解释。这正是 Wayve 正在做的。

目前，Wayve 的合作方涵盖日产、奔驰、Stellantis，以及微软、英伟达、Uber、高通等。日产已宣布计划将 Wayve 技术推广至其全球 90% 的车型。

Wayve 计划今年在伦敦和东京启动监督式 Robotaxi 试运营，并与 Uber 合作扩展至 10 座城市；消费者版辅助驾驶产品预计明年随整车厂量产车型上市。

( @APPSO)

04 Real-Time AI Demo

1、所说即所见：OpenAI 实时语音驱动 AI 动态白板

基于 OpenAI 最新实时语音模型的一个绝佳用例——「实时语音驱动现场演示」：只需你开口说话，白板就会瞬间将你的语音内容转化为可视化展示。

想象一下在头脑风暴会议的场景中，随着创意的提出，白板能在现场瞬间生成结构图、流程图，将抽象的想法立刻可视化。

或者当老师授课时，板书跟随着讲解的声音实时、自动地生成；讲到每一个新的知识点，白板立马绘制出相应的原理图，学生可以直观地看到整个知识结构被动态构建出来的过程。

它具备独特的双工作流模式：

暂存准备（Staging）： 你可以先手动将标题、议程、参考图片等素材拖放到白板上作为基础。
实况接管（Live）： 切换后，AI 将全面接管画布，完全根据你的实时语音，动态地进行绘制、修改和重新排版布局。

此外，它还内置了预热机制（Warm-up mechanism）：在进入「实况」模式前，AI 会先基于「暂存」阶段的内容进行预热处理，完美避免了当你说完第一句话时，模型却还没准备好响应的尴尬情况。

它还支持纯本地化部署，以满足更高的数据隐私和定制化需求。

项目作者 @kunchenguid

05 社区黑板报

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

1、516 上海活动报名 | 让算法大脑进入硬件躯壳：当 AI Agent 有了眼睛

过去一年，我们看到 AI Agent 变得越来越会思考、会规划、会调用工具。但如果它只能停留在屏幕里，它仍然缺少一件很关键的东西：感知真实世界的能力。

当多模态大模型开始成熟，AI Agent 的下一步，可能不只是更强的大脑，而是拥有「眼睛」。

摄像头形态硬件、智能眼镜、空间感知终端、可穿戴交互设备，正在成为 AI Agent 进入现实世界的重要入口。模型能力、视觉输入、硬件工程、供应链和产品定义，也开始在同一个问题上汇合。

我们想围绕这个问题，发起一场小型闭门活动。

这不是一场泛泛而谈的 AI 沙龙，也不是只聊趋势的分享会。我们希望聚集 30 位真正对 AI 硬件感兴趣、正在思考或已经动手的 Builder，一起讨论：

当算法大脑开始进入硬件躯壳，下一代产品机会会在哪里？

我们希望这场活动不只是一次聊天，而是一次让想法更接近产品的开始。

如果你也在思考 AI 硬件、摄像头形态产品、多模态 Agent，或者正在寻找一起把 Demo 做成产品的人，欢迎扫码填写问卷。

写在最后：

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

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

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

求问：亲测好用的 AI 工具

rroo11 — Sat, 09 May 2026 17:25:28 +0800

想问下论坛里的老师们，有没有亲测好用的 ai 工具，可以支持我直接输出银行复杂业务的测试用例，目前使用国产的 “豆某包”，“千某问” 都很鸡同鸭讲。

软件 3.0 来了，瓶颈依旧在

Fhaohaizi — Sat, 09 May 2026 13:20:56 +0800

人工智能确实加快了编码速度，但真正卡住交付的瓶颈，并没有因此自动消失。

编码变快，交付没跟上

这几年，AI 编码工具对研发效率的提升已经很明显。过去需要几天才能写完的一批代码，现在可能几个小时就能生成出来。但在移动应用和数字平台团队里，我经常看到另一个现象：编码速度提升之后，整体交付速度并没有同步提升，瓶颈只是从编码环节转移到了审查、测试、集成和稳定性验证这些下游环节。

换句话说，键盘变快了，流水线不一定变快。代码可以更快产生，但它仍然要排队等待代码审查，要进入测试套件，要和既有服务、真实用户流量以及不断演进的平台能力放在一起验证。编码阶段被 AI 推着往前跑，周围的流程如果没有跟上，交付压力反而会集中爆发。

软件 3.0 改变了编码方式

人工智能研究员 Andrej Karpathy 将这种变化称为软件 3.0：团队不再手动编写每一行代码，而是描述希望系统完成什么，再让 AI 生成大部分实现代码。

在最近的一次采访中，卡帕西提到，到 2024 年底，他自己的工作比例已经发生逆转：原来大约 80% 的代码由自己编写，现在则把 80% 的代码委托给代理。他认为，新的动词不再是编码，而是实现，也就是把意图准确传达给能够执行它的系统。

智能体时代已经到来。像 Claude Code 和 OpenAI 的 Codex 智能体这样的工具，已经超越了自动补全的范畴。它们不只是补上一行函数调用，而是可以规划、编写、调试，甚至推进一个完整功能的初版。

在任何项目的早期阶段，这种变化都很诱人。你可以在一个下午里，把一个模糊想法变成可运行的概念验证。这个速度对原型探索、客户演示和早期方案验证都很有价值。

真正的瓶颈转向下游

问题出现在下一步：当这个初始版本要进入真实产品时，复杂性马上就会回来。新代码仍然需要兼容现有服务，需要处理真实用户流量，需要在平台其他部分持续变化的过程中保持可靠。更快的生成速度不会取消这些工作，只会把它们推到下游，并让它们在更短时间里集中到来。

于是，工程团队不得不把更多时间花在审查、集成和稳定那些快速生成、但缺乏系统全局视角的代码上。代码审查队列会变长，测试套件要承担更多验证压力，发布前的风险判断也会更重。

单独看似完整的功能，只有在所有功能连接起来、并在真实负载下运行时，才会暴露出细微的不一致。接口契约、状态流转、异常处理、权限边界、性能退化，这些问题不会因为代码是 AI 生成的就自动消失。

还有一个更隐蔽的挑战：开发人员在等待智能体执行任务时，到底应该做什么。与代理协作意味着把任务委托出去，然后等待服务返回结果。这段等待时间如果被有效利用，就会变成新的生产力；如果被碎片化消耗，就会直接打断深度工作的节奏。

善用这段时间的开发者，会准备下一个任务提示，在系统其他部分启动并行代理，或者提前审查架构风险。他们能把等待变成流水线的一部分。相反，如果只是把 AI 当作减少工作量的工具，而不是提高团队产出的工具，个人体感会轻松一些，团队交付却未必更快。

这也是我在自己团队以及合作组织中经常看到的差距：个人效率提升了，但团队交付速度没有等比例提升。要弥合这个差距，需要积极的项目领导、明确的交付预期，以及开发人员工作方式的真正变化。工具只是问题的一半。

当整个过程赶上来的时候

真正从软件 3.0中受益的团队，并不是只把 AI 接进编辑器，而是重新设计了从需求到交付的整个流程。能实现全周期加速的团队，通常抓住了三件事。

首先，是前期架构投入。当智能体拥有清晰的结构约束、模块边界和验收标准时，产出质量会明显更稳定。反过来，如果需求和架构本身含糊，智能体只能在模糊空间里猜测，生成速度越快，后续返工也可能越快。

因此，在开发智能体之前投入足够时间做系统设计，并不是拖慢速度。它更像是给后续生成、审查和集成铺轨道。前面多花一点时间把边界讲清楚，后面节省的审查和集成成本，往往会成倍返还。

其次，是让代理之间互相检查。这意味着用专门的审查代理检查生成代码中的安全漏洞、架构一致性和质量标准，尽早把问题拦住，而不是等它们扩散到集成阶段。

同样重要的是测试生成代理。它可以根据测试人员编写的规范创建测试用例并持续运行。在大型项目中，过去需要数周人工完成的回归验证，现在可以被压缩到更短的周期里。这里的重点不是让测试人员消失，而是把他们从重复执行中释放出来，转向测试策略、风险判断和规范设计。

第三，是给智能体正确的上下文和能力。模糊指令只会得到模糊结果。这件事首先从需求编写开始：产品需求文档必须足够精确、结构化、可执行，让智能体不仅能读懂，还能据此行动。

这还包括把代理连接到正确的信息来源：一致的设计系统、最新的项目管理信息、准确的技术文档，以及能避免它们凭空猜测的组织知识。真正的长期优势，往往就在这些上下文资产里积累起来。

不同组织的采用节奏也会不同。初创公司通常冲得更快，因为融资环境更紧，团队需要尽快拿出结果，而且早期系统的安全、合规和声誉约束相对少一些。快速写出第一个版本，已经成为很多初创团队的日常能力。

大型企业则更谨慎。它们的系统更复杂，合规要求更严格，声誉风险也更高。AI 编码工具正在普及，但生成代码进入生产环境之前，仍然需要经过更严格的审查和治理。

根据 JetBrains 发布的《2025 年开发者生态系统现状调查报告》，85% 的开发者目前经常使用 AI 编码工具，而 2025 年编写的所有代码中有 41% 由 AI 生成。工具已经无处不在，但围绕工具的工程规范还远没有同样成熟。

工程师角色的转变

更根本的变化，发生在工程师角色本身。开发人员正在从单纯的实现者，转向系统总监。日常工作的重心不再只是写出优雅代码，而是定义架构、管理代理输出、保障安全性，并持续思考系统的可扩展性。

工作重心已经从编写代码，转向验证和协调。Karpathy 的判断很直接：瓶颈不再是键盘。优秀工程师现在可以更快进入过去不熟悉的语言和技术栈，前端与后端之间的壁垒也在变薄。

整个 MVP（最小可行产品）可以由一两个人组成的小团队交付。过去需要数周完成的概念验证，现在可能一个下午就能做出来，并在当天发给客户。这确实改变了提案、售前验证和早期合作中的竞争格局。

在模式成熟的场景里，例如标准集成、可重复工作流和常规业务逻辑，AI 代理的优势最明显。但当系统变得复杂、长期运行、积累多年上下文，或者涉及安全性、可扩展性和组织责任时，人的判断仍然是关键变量。

软件 3.0时代已经到来。编码阶段的加速是真实且显著的。

但真正创造最大价值的团队，不是那些生成最多代码的团队，而是那些围绕新现实重建流程的团队：预先投资架构，用代理验证代理，为代理提供正确的工作环境，并重新管理工程师一天中的协作节奏。

瓶颈不再是把代码写出来，而是判断应该构建什么、如何构建，以及代理生成的内容是否真的适合运行在真实环境中。这才是软件 3.0 时代的工程能力。

FunTester 名片｜万粉千文，百无一用

监工状态

yangchengtest — Sat, 09 May 2026 11:52:51 +0800

最近懒到已经完全不想自己写代码了。
完全进入监工状态。
AI 自己写代码，自己分析，自己跑用例。

最近因为身体问题，我已经基本进入摸鱼状态了，就这样，其他人的菜我还是无法理解。
算了，草台就草台吧，别人菜就菜吧。
我决定开始进入半摸鱼状态，早下班，保重身体。

PS：前面胡吃海喝，身体每况愈下，开始戒糖分饮料。

走，去硅谷造 AI 硬件（并卖出去）丨活动招募：Physical AI Camp 硅谷站

RTE — Sat, 09 May 2026 11:44:58 +0800

当 AI 看得见、听得清，并开始对真实世界做出反应时，Agent 终于有了自己的物理躯壳。

5 月 15 日周五，趁着大家都在硅谷参加 SaaStr 大会，Physical AI Camp 在湾区发起了一场开发者与创业者的聚会。这里汇聚了一群「软硬结合」的探索者——涵盖多模态大模型、边缘硬件、全球网络与实时生态。

这次是第一个全天的硬件&语音 AI 派对：上午探讨实时多模态 AI 和硬件的结合，下午将动手使用 Agora Skills 和 SenseCAP Watcher 从 0 到 1 部署一个语音智能体硬件。

无论你是需要寻找硬件搭档、探索端侧 AI 框架，还是寻觅合伙人，来这里，我们一起造点能在现实世界跑起来的东西。

活动信息

时间：2026年5月15日（周五）

地点：Circuit Launch, 599 Fairchild Dr, Mountain View, CA

上午场：Physical AI Meetup @ SaaStr Annual: Real-Time Multimodal Agent in the Shell

10:00 - 12:30（GMT-7）

下午场：Physical AI Workshop: From 5-Min Agent Build to Hardware Deployment

13:30 - 16:00（GMT-7）

💡* 你可以只参加单场，也可全天参与——动手也动脑，快乐翻倍！*

访问链接报名方式

上午场：

https://luma.com/d14drl0t

下午场：

https://luma.com/t4itltrx

上午：Physical AI Meetup @ SaaStr Annual: Real-Time Multimodal Agent in the Shell

📅** 活动详情 **

时间：2026年5月15日（周五）| 10:00 AM - 12:15 PM (09:30 AM 签到)

地点：Circuit Launch, 599 Fairchild Dr, Mountain View, CA

⏳** 日程安排 **

09:30 - 10:00 | Arrival, Coffee & Bagels ☕ 🥯

10:00 - 10:10 | Welcome & Opening Remarks

10:10 - 10:45 | Lightning Talks: Wiring the Physical AI Ecosystem

10:45 - 11:15 | Panel 1: System 1 & System 2 — Reflex vs. Reasoning

11:15 - 11:45 | Panel 2: Glorified Toys vs. Product-Led Growth in Hardware

11:45 - 12:15 | Deep Networking & Demo Showcase

🎙出席嘉宾

Dr. Hui Jin, Founder & CEO @ Redtea Mobile

金辉，红茶移动创始人&CEO

A leading global eSIM innovator actively exploring the "Supply-Chain-to-TikTok" playbook for viral hardware, while building Jumpo AI, an intelligent camera for kids.

Qianze Zhang, Agent Platform Lead @ Agora

张乾泽，Agora Agent Platform Lead

Architecting a novel "Dual-Brain" agent framework called NewBro that separates System 1 (sensory reflex) from System 2 (deep reasoning).

John, Product Manager @ StepFun

白宦成，阶跃星辰产品经理

With StepFun pushing the boundaries of multimodal and Edge AI, John focuses on ultra-low latency TTS/ASR—bringing high-performance voice interactions to everything from software to physical hardware like automotive.

Wei You, Founder @ AutoHeart

游威，自动心创始人

Crafting highly expressive physical AI as the co-founder of LOOI, steering the "Smart AI Alien" desktop robot from zero to a Kickstarter bestseller.

Moderators:

Cynthia Yang 杨慧 (Initiator @ RTE Dev Community)

Ziqiang Xu 许子强 (RTE Dev Community Ambassador & Supersonic Fellow)

👇 访问链接报名

https://luma.com/d14drl0t

注：上下午活动需分开报名

下午：Physical AI Workshop: From 5-Min Agent Build to Hardware Deployment

我们的硬件工作坊回到硅谷——以更快的方式构建语音 AI 智能体，你可以用 Agora Skills，在几分钟内组装一个 voice AI agent，并最终部署到真实硬件上。

📅** 活动详情 **

时间：2026年5月15日（周五）（13:30 - 16:00 GMT-7）

人数：20～40 人

👉 可以单人成组或两人一组
👉 每组配有一套 SenseCAP Watcher 硬件

🔍 活动亮点

🔹 用于快速构建智能体的 Agora Skills（https://github.com/AgoraIO/skills）跳过复杂的配置流程——使用模块化的技能，快速组装你的语音 AI 智能体

🔹 SenseCAP Watcher：实体 AI 智能体，基于 ESP32S3 构建

📌 在这里，你将亲手完成从硬件配置、编译、运行，到自定义语音 Agent 的完整动手链路。

🧠 你会得到什么

✔ 现场技术分享

✔ SenseCAP 设备实操上手

✔ 自定义语音 AI

✔ 团队合作与答疑支持

欢迎对智能硬件、语音交互、Agent 产品有兴趣的朋友报名。

⏱ 活动流程

13:30–14:00 签到 & 自行组队
14:00-14:20 技术分享
14:20–16:00 现场实操（提供详细流程文档和技术答疑）

📌 准备建议（强烈推荐）

为了让现场体验流畅，请提前准备：

一台笔电
GitHub 账号（用于运行 Codespace / 示例仓库）
终端工具与命令行基础（建议提前熟悉）

👇 访问链接报名

https://luma.com/t4itltrx

注：上下午活动需分开报名

OpenAI Realtime API 重磅更新：锚定语音模型「深度推理 + 自主执行」演进路径｜Voice Agent 学习笔记

RTE — Sat, 09 May 2026 11:16:01 +0800

在曾惊艳世界的 GPT-4o 发布两周年之际，OpenAI 通过三款全新语音模型再次定义了边界。

语音交互正从「问答式」转变为「执行式」。新模型 GPT-Realtime-2 将上下文窗口由 32K 扩容至 128K，并支持多工具同时调用，这意味着它能处理更长、更连贯、更复杂的业务逻辑，并具备了更成熟的错误恢复机制。

这是一个明确的信号——语音应用的进化方向已从单一的响应转变为：聆听 → 推理 → 翻译 → 转录 → 采取行动。赋予语音模型深度推理与自主执行力，正是语音交互的下一步路径。

我们翻译了包含音频示例在内的官方全文，带你深度了解这次更新。

读完不过瘾可以继续深挖开发文档：

https://developers.openai.com/api/docs/guides/realtime

Advancing voice intelligence with new models in the API

通过 Realtime API 新模型全面提升语音智能

新一代实时语音模型，支持在用户交谈过程中同步进行推理、翻译及转录。

https://openai.com/index/advancing-voice-intelligence-with-new-models-in-the-api/

我们正在 API 中推出三种音频模型，为开发者解锁新一类的语音应用。借助这些模型，开发者可以构建更自然、响应更智能、并能实时采取行动的语音体验：

GPT‑Realtime‑2，我们首个具备 GPT‑5 级推理能力的语音模型，能够处理更复杂的请求并自然地推动对话进程。
GPT‑Realtime‑Translate，一种新的实时翻译模型，可将 70 多种输入语言的语音翻译成 13 种输出语言，并同步跟随发言人。
GPT‑Realtime‑Whisper，一种新的流式语音转文字功能，可在发言人讲话时实时转录语音。

语音正成为人们使用软件最自然的方式之一。它允许人们在驾驶时寻求帮助，在机场行走时更改旅行计划，用他们惯用的语言取得帮助，或在无需停止打字的情况下完成任务。

但要构建实用的语音产品，不仅需要低延迟的对话轮次切换，或自然的语音输出。一个语音智能体需要理解他人的意图，保持对上下文的理解，灵活响应指令更改，支持在对话过程中同步使用工具，并以合时宜的方式做出回应。

我们推出的模型将实时音频从简单的问答模式转向能够实际执行工作的语音界面：倾听、推理、翻译、转录，并在对话展开时采取行动。

语音作为人与产品之间的界面

随着语音成为更自然的软件使用方式，我们观察到开发者们正围绕语音 AI 领域的三个新兴模式进行开发和构建：

语音到行动（Voice-to-action）：人们可以描述他们的需求，系统可以推理请求、使用工具并完成任务。例如，Zillow 正在构建一个助手，可以倾听、推理并处理类似这样的请求：「为我找到符合 BuyAbility 的房源，避开繁忙的街道，并安排周六的看房。」
系统到语音（Systems-to-voice）：软件可以将上下文转化为实时语音指导。例如，一个旅行应用可以主动告诉旅行者：「您的入境航班延误了，但您仍然可以赶上接续航班。我找到了新的登机口，规划了通过航站楼最快的路线，您的行李仍在中转。」
语音到语音（Voice-to-voice）：AI 能够帮助跨越不同语言、处理多种任务，应对不断变化的语境。例如，德国电信正在构建语音支持体验，让客户可以使用他们最舒适的语言进行交谈，同时使用模型实时翻译对话内容。

这些模式也可以协同工作。Priceline 正致力于构建一个未来，使得旅行者可以通过语音管理整个行程：通过对话搜索航班和酒店，处理变更（如航班延误后调整酒店预订）或获取实时 TSA 等候时间更新，以及在旅行者抵达目的地后进行翻译。

实时语音：帮助语音模型推理并采取行动

GPT‑Realtime‑2 专为实时语音交互而设计，模型在推理请求、调用工具、处理更正或中断的同时，保持对话的流畅性，并以符合当前语境的方式作出回应。

开场白：开发者可以在给出正式回复前，设置一些简短的过渡语（例如「我来查一下」或「请稍等，我看看」），以便让用户知道智能助手正在处理该请求。
并行工具调用和工具透明度：模型可以同时调用多个工具，并通过类似「正在查看您的日历」或「马上为您查询」等提示语，将这些操作以语音的形式反馈给用户。这有助于智能助手在执行任务期间始终保持响应。
更强的异常恢复能力：模型能够更妥善地从错误中恢复，例如主动提示「我现在处理这个问题遇到点麻烦」，而不是毫无反应或直接中断对话。
支持智能体工作流的更长上下文： 我们将上下文窗口从 32K 扩展至 128K，以支持更长、更连贯的会话以及更复杂的任务流。
更强的领域理解能力： 模型能够更好地识别并记住专业术语、专有名词、医疗词汇以及其他在实际生产环境中至关重要的词语。
语气与表达更具可控性： 模型能够更好地调整自身的语气——在解决问题时语气平稳，在用户感到沮丧时充满同理心（共情），在确认操作成功时则语气轻快。
可调节的推理强度： 开发者现在可以从「极低」（minimal）、「低」（low）、「中」（medium）、「高」（high）和「极高」（xhigh）这几个推理级别中进行选择（默认值为「低」），从而在简单交互所需的低延迟与复杂请求所需的深度推理之间取得最佳平衡。

这些性能提升体现在与实际生产级 Voice Agents 高度契合的音频评测中：在测试「音频理解能力」的 Big Bench Audio 评测中，GPT‑Realtime‑2（high）的得分比 GPT‑Realtime‑1.5 高出 15.2%。在测试「指令遵循能力」的 Audio MultiChallenge 评测中，GPT‑Realtime‑2（xhigh）的得分比 GPT‑Realtime‑1.5 高出 13.8%，这表明升级后的模型在实时对话中展现出了更强的推理、上下文管理和控制能力。

Demo 展示

战略推理能力

用户：「我正在考虑在通勤轻轨站旁边开一家 900 平方英尺（注：约 80 多平米）的独立咖啡馆。这里的客流高峰集中在周二至周四的早 7 点到 10 点；周一、周五以及下午时段的客流则要冷清得多。铺位租金很贵，但我非常向往这种模式：提供舒适的座位、慢节奏的手冲咖啡和本地烘焙的糕点。请帮我做一个战略性的『失败推演』（Pre-mortem）：如果这家店在一年后倒闭了，最可能的原因是什么？另外，在彻底投入开这家完整的咖啡馆之前，我应该先以怎样最小的业务规模去试水？请给我一些建议。」

GPT-Realtime-2

文本记录：

「让我们对这个想法进行一次『压力测试』，然后构思一个你能落地的最小可行性试点项目。

如果这家店在一年后倒闭，最可能的原因是：你的商业模型与客流量的需求节奏从始至终都不匹配。你承担着高昂的租金，采用的是迎合顾客闲坐逗留、慢工出细活的饮品以及舒适座位的经营理念；然而，你最大的客源却集中在短暂的早晨时间段里，他们只想快速买到一杯品质稳定的咖啡。耗时的手冲咖啡和过多的座位会成为限制出杯量和翻台率的瓶颈；而生意清淡的周一、周五和每天下午，只会让你白白为不产生效益的空间交租金。再加上人工成本、菜单过于繁杂带来的食材损耗，以及难以拉动非高峰时段生意的挑战，你的现金流就在不知不觉中枯竭了。

验证这个构想最小的测试版本，是采用『极简菜单 + 仅高峰时段营业』的模式。可以考虑在车站附近搞个咖啡推车、售卖亭或是共享吧台，营业时间只定在周二到周四的早上 7 点到 10 点。只供应滴滤黑咖，如果条件允许再加一款基础的意式咖啡，并搭配几款从本地合作伙伴那里进货的糕点。在你真正投入重金开一家完整的实体咖啡店之前，先用这个模式来测试你的出杯速度、回头客转化率以及顾客对价格的接受度。」

GPT-Realtime-1.5

文本记录：

「如果这家店在一年后倒闭，可能的原因包括：高估了早晨通勤人群在店内逗留的意愿、在非高峰时段未能创造足够的收入，以及租金和人工带来的高昂固定成本无法被销售额抵消。也许你的经营理念没有与习惯『即买即走』的通勤者产生共鸣，又或者下午的生意迟迟不见起色，导致你的利润空间被严重挤压。你可能在营销上遇到了困难，或者没有根据客流量的起伏及时调整产品供应，从而引发了现金流问题。

为了在小规模上验证这个商业构想，你可以先在早高峰时段的车站附近经营一辆快闪咖啡车或售卖亭，提供你的招牌手冲咖啡和糕点。这样一来，你无需签下昂贵的大铺面租约，就能评估市场需求、优化菜单、积累本地客源并测试定价策略。一旦你拥有了稳定的销售业绩并了解了顾客的消费习惯，你就能更有把握地去规划一家更大的店面了。」

语气和表现力

用户：「我现在非常生气。我的公寓被入室盗窃了，这已经是我第三次打电话来问理赔的事了。麻烦告诉我接下来到底是怎么个流程，但请别再用那种像念稿子一样、故作轻松的客服腔调来敷衍我了。」

GPT-Realtime-2

文本记录：

「很遗憾您遇到了这种烦心事。请放心，让我为您清晰地梳理一下接下来的常规流程。接下来，理赔员会审核您的理赔申请。他们将核实一些细节，比如警方报告、现场照片，以及任何能证明物品被盗或受损的凭证。他们可能会安排现场查勘，或者要求您提供更多的补充材料。之后，您会收到关于是否予以理赔的决定。如果申请通过，您会收到一份理赔方案，其中会说明具体的赔付金额及打款时间。如果您在过程中觉得进展缓慢或遇到阻碍，您可以随时要求了解最新的理赔进度，或者询问是否有升级处理（或进一步申诉）的途径。」

GPT-Realtime-1.5

文本记录：

「得知你正在经历这些，我真的感到很难过。接下来，保险公司通常会审核你的理赔细节、相关的报警记录以及你提交的所有证明文件。理赔员（或定损员）可能会与你联系，核实具体的损失情况并沟通理赔范围。如果你觉得理赔进度停滞不前，或者诉求没有得到重视，要求与他们的主管直接沟通，或者索要一份书面的处理时间表，可能会对你有所帮助。此外，如果在理赔之外你还需要一些心理支持，向专业人士或值得信赖的朋友倾诉，也许能帮你更好地渡过这个难关。」

空间推理能力

用户：「我正站在酒店走廊里找 214 房间。我右手边刚刚经过了 218、220 和 222 房间。左手边经过了 217、219 和 221 房间。我应该继续往前走还是转身，214 房间应该在哪一边？」

GPT-Realtime-2

文本记录：

「转身往回走吧。顺着你现在走的方向，门牌号是越来越大的，而 214 房间应该排在 217 到 222 这些房间的前面。既然单号在你左边，双号在你右边，那 214 房间应该就在你的右手边，往你刚刚来的方向退回去一点就是了。」

GPT-Realtime-1.5

「听起来你往前走的时候，房间号是越来越小的。既然双号房间一直在你右手边，那 214 房间应该也在你右边。继续顺着这个方向走，房间号会一直变小，直到你找到 214 为止。祝你顺利找到！」

数字字母能力

用户：「Before you pull up the account, read back exactly the order ID I’m about to give you. My order ID is R E T dash six twenty A dash nine C two.」

GPT-Realtime-2

「R E T dash six twenty A dash nine C two.」

GPT-Realtime-1.5

「Got it. Your order ID is R E T dash 620 A dash 9 C 2.」

逻辑推理能力

用户：「所有的 dax 都是 wug。有些 wug 是 nim。没有任何 nim 是 lorp。我们能得出结论说『有些 dax 不是 lorp』吗？请回答『是』或『否』，并简要解释。」

GPT-Realtime-2

「否（不能得出该结论）。因为『属于 nim 的那部分 wug』里可能根本没有任何 dax。所以我们无法确定，在那些『绝不可能是 lorp 的 nim』当中，到底包不包含 dax。」

GPT-Realtime-1.5

「是的。因为所有的 dax 都是 wug，并且有些 wug 是 nim，所以 dax 和 nim 之间至少存在一些交集。又因为没有任何 nim 是 lorp，那么这些存在交集的 dax 就不可能是 lorp。因此，必定有一些 dax 不是 lorp。」

实时翻译：构建多语种实时语音体验

GPT-Realtime-Translate 帮助开发者构建实时多语种语音交互体验，让每个人都可以用自己偏好的语言发言，实时收听对话的翻译，并阅读实时的文本转录。它支持 70 多种输入语言和 13 种输出语言，这使其非常适用于客服支持、跨境销售、教育、活动、媒体以及服务全球受众的创作者平台。

对开发者而言，实时翻译必须在紧跟说话者语速的同时准确传达原意——即使在人们自然交流、切换语境，或是使用地方口音和行业专业术语的情况下，也要能应对自如。例如，德国电信（Deutsche Telekom）目前正在测试将该模型应用于多语种语音交互，其更低的延迟和更出色的流畅度，能让跨语言对话体验变得更加自然顺畅。

在这个视频中，Vimeo 展示了 GPT‑Realtime‑Translate 如何实时翻译正在播放的产品教育视频，这样全球客户可以在他们喜欢的语言中听到更新，而无需等待单独制作的版本。

实时字幕：构建低延迟字幕体验

GPT-Realtime-Whisper 是一款专为低延迟「语音转文本」打造的全新流式转写模型。它能够实现「边说边转写」，让实时交互产品体验起来更迅速、响应更灵敏也更自然——无论是瞬间呈现的实时字幕，还是紧跟对话节奏的会议记录。

该模型能在语音发生的当下，直接将其无缝融入业务工作流。团队可以利用它为会议、课堂、广播及大型活动提供字幕支持；在对话进行时同步生成纪要和摘要；构建能够持续理解用户意图的语音智能体；并为客服、医疗、销售、招聘等高频语音交互场景，打造更快捷的后续跟进工作流。

安全

Realtime API 整合了多重安全防护与风险缓解机制，以防范滥用行为。我们在 Realtime API 的会话中部署了主动分类器，这意味着，一旦检测到某段对话违反了我们的不良内容政策，该对话将被予以中止。此外，开发者还可以借助 Agents SDK，轻松添加自定义的额外安全护栏。

我们的使用政策严禁将本服务生成的输出内容重新利用或分发，用于垃圾信息传播、欺诈或其他有害目的。开发者还必须向终端用户明确说明他们正在与 AI 进行交互，除非从当前语境中已经显而易见。

对于运行在欧盟地区的应用程序，Realtime API 全面支持欧盟数据驻留（EU Data Residency），并受我们企业隐私承诺的保护。

定价

GPT-Realtime-2、GPT-Realtime-Translate 和 GPT-Realtime-Whisper 现已在 Realtime API 中提供。定价方面，GPT-Realtime-2 的价格为每百万音频输入 Tokens 32 美元（缓存的输入 Tokens 为 0.40 美元），每百万音频输出 Tokens 64 美元。

GPT-Realtime-Translate 的价格为每分钟 0.034 美元。

GPT-Realtime-Whisper 的价格为每分钟 0.017 美元。

开始使用

您可以在 Playground 中测试新的实时语音模型。

要开始构建，请在 Codex 中打开此 prompt，将 GPT-Realtime-2 添加到现有应用或启动新应用。如果您还没有 Codex，请先下载 Codex 应用。

从 Vibe Coding 到 Agentic Engineering，工作中我是这样用 AI 搞定测试的！

Utest_Cloud — Sat, 09 May 2026 10:48:44 +0800

从氛围编程（Vibe Coding）到智能体工程（Agentic Engineering），AI Coding 已步入到一种更严谨、更具工程化思维的全新范式。既然 AI 写代码正在告别随机性走向规范，测试工作能否同样能复刻这一路径，让 AI 在工程规范下可靠地完成复杂的测试任务？

答案是 YES。在鹅厂内部，我们将司内的智能 IDE 工具（腾讯 CodeBuddy）与自动化测试平台（优测）对接，通过 Skills、CLI 工具与 MCP 的协同，让研发和测试工程师在 IDE 环境中，直接召唤专属测试智能体，实现这种规范驱动（Spec-Driven）的极简体验。本文将围绕测试工作中的高频场景和案例，来分享日常项目团队中是如何使用 AI 的。

基于 Skills+MCP：多智能体无缝协作，规范驱动测试体验

优测自动化测试平台接入 IDE 环境，能够让 AI 具备可扩展、可执行的技能体系，在本地开发环境中直接处理专业、复杂的测试任务。该技术方案通过 Skills 分层加载机制解决 MCP 的 Token 冗余问题，借助 CLI 工具打通本地代码与云端平台的操作链路，再结合智能 IDE 工具深度解析本地工程代码及线上流量数据生成高覆盖用例，最终实现 “代码解析 - 用例生成 - 上传执行 - 报告输出” 的全链路智能化。

典型场景实践指南：工作中我是这样用 AI 的

场景 01 | 通过自然语言生成测试用例

💡 场景介绍

在 IDE 环境中，在代码提交后一键智能生成符合优测平台规范的测试场景 JSON，支持从 .proto 文件/Java JCE/代码自动构建复杂链路，并极速同步至优测平台！基于优测 Skills 通用能力，AI 能够按照严格的测试工程规范（覆盖率要求、数据自给自足策略、场景拆分、断言规范等），生成质量更高、覆盖更全面的测试用例。

** 📖 常用指令示例 **

你可以这样对 AI 说：

//用例生成：
“使用优测Skills，根据 order.proto 生成一个下单支付链路并上传”

//快速同步：
“帮我把这个场景上传到优测”

//指定名称：
💬 “上传到优测，并且取名叫 xxx 测试用例”

//指定目录：
💬 “上传到优测，并放在目录 ID 为 xxx 的目录下”

//场景更新：
💬 “帮我用当前内容更新 UUID 为 xxxx-xxxx 的已有场景”

//设置权限：
💬 “把这个场景上传到优测，并设为只读模式”

以上命令可组合使用！

🏅 效果演示

场景 02 | 智能流量录制回放

** 💡 场景介绍 **

通过自然语言交互，AI 自动编排「流量录制 → 数据观察 → 流量回放 → 结果查询」四阶段工具链，帮助用户端到端捕获并重现真实生产环境中的流量，为测试提供高度还原的数据支持。

** 📖 常用指令示例 **

你可以这样对 AI 说：

//流量录制：
💬 “帮我对 myapp.myserver 服务录制 1 小时的流量”

//数据观察：
💬 “查看一下 myapp.myserver 的录制数据”

//流量回放：
💬 “用录制的流量回放到测试环境 10.0.0.1:8080”

// 结果查询：
💬 “查看回放任务的统计结果”

🏅 效果演示

场景 03 | 执行测试任务

** 💡 场景介绍 **

在本地把用例上传到优测后，可以直接让 AI 执行接口测试、压力测试核心场景，一站式搞定任务创建、查询、修改、执行、删除和查看报告获取！

** 📖 常用指令示例 **

你可以这样对 AI 说：

//接口测试任务：
💬 “使用这个用例执行接口测试”

//压力测试任务：
💬 “使用 RPS 默认模式创建压测任务”
💬 “使用用户数默认模式创建压测任务”

** 🏅 效果演示（压测任务为例）**

实际落地效果：质量效率双跃升，Token 节省 80%

后台服务团队，基于优测后台一体化测试平台与 CodeBuddy 的协同，在代码提交后可快速生成测试用例，实现从用例生成到执行验证的全流程智能化。基于优测底层 Skills 的通用能力，业务可对 Skills 进行高级封装，结合自身业务开发框架，为 AI 注入服务参数自动识别能力和更严格的测试工程规范，使生成的测试用例更贴合业务场景，场景覆盖也更加充分。

** 💎 AI 提效对比 **

指标	使用前	使用后	提升幅度
用例生成效率	8–10 小时（100 个用例）	30 分钟（含全流程）	16 倍 +
Token 占用	所有规范全部加载	按需加载	消耗减少 80%
用例覆盖率	60% （依靠人工）	95% （基于代码 + 流量数据）	35%+
用例维护成本	人工维护	随代码自动更新	人工减少 100%
缺陷发现率	依赖人工经验	提前发现线上问题高达 80%	风险大幅降低

本文未注明其它来源的内容，其版权归优测云服务平台所有，未经允许不得转载本文内容。如需转载本文，请在显著位置注明出处（优测云服务平台，以及文章链接：https://utest.21kunpeng.com/home/topic/skills260508）

第二届人工智能与数字金融国际学术会议 (AIDF 2026)

leisigoule — Sat, 09 May 2026 10:10:10 +0800

第二届人工智能与数字金融国际学术会议 (AIDF 2026)

2026 2nd International Conference on Artificial Intelligence and Digital Finance

人工智能 | 社科 EI（经济、金融、管理、区块链等与计算机交叉相关方向）均可投递

录用率高

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

大会时间：2026年5月29日-31 日

大会地点：中国武汉（线上线下结合）

检索类型：EI, Scopus

组织单位

征稿主题（包括但不限于）

Track 1: 人工智能

人工智能算法与系统架构

监督学习

无监督学习

强化学习

深度学习

机器学习

神经网络与神经形态计算

自适应与进化计算

模型拟合与数据分析

图神经网络

人工智能技术与应用

自然语言处理与大语言模型

人机交互

多模态学习

智能数据库与知识图谱

生成式人工智能

智能计算与芯片

智能机器人

大数据分析

网络智能应用与搜索

分布式智能处理

建模和识别

Track 2: 人工智能在数字金融中的应用

金融大模型

量化投资与算法交易

智能风控与信用评估

金融信息抽取与文本分析

市场预测与经济计算

金融知识图谱与智能推理

监管科技与合规自动化

机器学习与深度学习在金融领域的应用

自然语言处理（NLP）与金融文本分析

智能投顾与财富管理

AI 驱动的金融风险建模

生成式 AI 与金融场景

Track 3: 金融科技创新

金融科技（FinTech）

电子银行

数字支付与虚拟货币

数字资产管理

区块链与分布式账本技术

区块链的数据管理

数据金融

智慧银行

互联网金融

金融工具和金融服务

经济数据挖掘

经济模型与软件工程

商业智能与计算

互联网经济

算法在经济管理中的应用

数据库与系统安全

大数据与金融信息处理

大数据技术在金融监管的应用

金融网络安全

边缘计算与物联网（IoT）金融

全球数字金融发展

论文出版

你说你会 AI 测试，那你是怎么实现 AI+ 软件测试的呢？（附带 5 层 AI 质量管理体系）

mikezhou — Sat, 09 May 2026 09:51:12 +0800

前天面试了一个有着五年经验的测试工程师。

简历上写得挺漂亮：熟练使用 AI 生成测试用例，用 AI 实现自动化测试。我心想，这哥们儿应该有点东西，就抛了一个真实的项目问题过去。

没想到，他的回答把我惊呆了。

题目是这样的：

你用 AI 做测试，需求文档是完整的电商订单流程。AI 生成了 120 条测试用例，3000 行 UI 自动化脚本，覆盖了正向下单、支付、退款流程。结果上线后一小时，大量用户反馈无法完成订单支付。

排查发现两个核心问题：

AI 生成的用例漏了订单金额为 0.01 元的边界值、支付时网络中断重试这两个关键场景

自动化脚本只实现了点击操作，没有断言支付成功后订单状态变为待发货，也没有处理支付超时的异常场景，导致测试时没发现问题，上线后直接引发生产故障。

我接着追问了三个问题，每一个都是面试必问：

第一，你在审核 AI 生成的订单支付用例时，怎么判断 AI 有没有漏测边界值异常场景？
第二，自动脚本跑通就代表没问题吗？你会具体检查脚本的哪些细节，如何避免没有断言、没有异常处理的情况。
第三，这次故障后，你会怎么优化 AI 测试的流程，保证下次不再出现漏测脚本无效的问题？

没想到，他张口就来：

"我就把 AI 生成的用例大致扫了一遍，看步骤完整、没有明显错误就够了。"

"脚本能跑通就行，没必要查那么细。"

"故障后……下次让 AI 多生成几条用例，再多看两眼就好了。"

听到这里，我心里叹了口气。

兄弟，你这根本不是懂 AI 测试，你就是拿 AI 当甩手掌柜。AI 一天能生成几百条用例、几万行脚本，你粗略扫一眼，能发现藏在细节里的边界漏洞、断言缺失吗？

他不知道该怎么回答了，面试到这里，基本也就结束了。

这道题为什么能筛掉大部分人？

说实话，这类题我面了不下二十几个人，能答到点上的不超过三个。

很多人有个误区：觉得会用 AI 生成几条用例、让 Copilot 写几行 Selenium 脚本，就叫"AI 测试"了。

大家一定要明白一个核心真相，AI 擅长批量生成模板化输出，但永远不懂隐性业务，不懂行业规则，不懂项目历史问题。

AI 最大的隐患不是写不出用例，而是特别容易产出看起来专业，实际全是漏洞的内容。

比如漏掉权限互斥场景、忽略流程依赖关系、边界值只写常规，不写极值、异常场景只做表面覆盖、自动化脚本缺少关键断言、接口测试漏了参数加密和并发场景等。

比如，AI 生成测试内容的常见翻车点：

翻车类型	具体表现	危害等级
边界值漏测	只写常规值，不写极值（如 0.01 元、999999.99 元）	🔴 高
异常场景表面化	写了"网络异常"，但没写异常后的状态恢复	🔴 高
权限互斥缺失	没覆盖"同时操作冲突"（如退款 + 退货并发）	🔴 高
断言缺失	脚本只点不验，跑通≠通过	🟠 中
流程依赖断裂	步骤 A 失败后重试，步骤 B 的状态没同步校验	🟠 中
参数安全忽略	接口测试漏了加密、防篡改、并发场景	🟠 中
重复冗余	同一个场景换说法生成多条，浪费执行资源	🟡 低

这也是初级测试和高级测试的核心分水岭：前者只看 AI 产出的 “数量”，后者能看透背后的风险，用系统化方法驾驭 AI。

真正玩转 AI 测试，需要五层质量管控体系

结合我多年的实战经验，以及踩过的 AI 测试坑，我始终认为：想要真正用好 AI 测试，既发挥它的效率优势，又杜绝漏测、错测、无效用例上线，绝不能 “甩手掌柜式” 用 AI，而是要建立一套完整的 AI 测试全流程质量管控体系。

这不是简单的 “让 AI 多生成几条用例、多看两眼”，而是从需求到复盘的全链路把控，每一步都要融入人的专业判断和业务经验。

我把这套体系，分为五个层级，每一层都是面试高频考点，也是实际工作能落地的标准流程。

第一层：业务需求前置拆解，不给 AI 盲目发挥的机会

很多人用 AI 测试最大的误区，就是直接把一份笼统的需求文档丢给 AI，让它自由发挥生成测试用例。

这本身就是最大的风险。

AI 看不懂文字背后的隐性规则，也不知道你们项目过往的高频缺陷点。

比如"支付功能"三个字，AI 理解的就是"输入金额→确认支付→扣款成功"。但它不会知道：

你们的支付通道有金额下限（0.01 元）
网络中断后需要支持 3 次重试，每次间隔 5 秒
支付超时后订单状态要回滚为"待支付"，不能卡在"支付中"
同一笔订单不能重复支付（幂等性）

正确的做法是先人工拆解需求，梳理出几大模块：

核心业务流程（主路径必须 100% 覆盖）
次要分支流程（异常分支、降级方案）
隐藏业务规则（风控拦截、金额限制、时间窗口）
权限角色划分（普通用户/VIP/管理员的不同逻辑）
边界极值清单（最小值、最大值、空值、超长值）
异常故障场景（网络中断、服务超时、数据不一致）
安全风控要求（SQL 注入、越权访问、敏感信息脱敏）

把这几大模块的结构化清单、历史 Bug 案例、业务禁止规则，一起喂给 AI，限定生成范围，限定覆盖维度。让 AI 在你划定的框架内产出，而不是任由它随意编造业务逻辑。

尤其是支付、订单、用户权限、数据隐私、资金流转这类核心模块，

必须提前做场景锁定，强制 AI 全覆盖，绝不让它随意编造业务逻辑。这一步的核心是 “人主导、AI 辅助”，用人工的业务理解弥补 AI 的认知盲区。

第二层：给 AI 产出 “做减法”，筛选有效内容

AI 产出的测试用例，从来不是全部可用的。而是要学会快速分类筛选：

第一类：标准正向用例

常规流程、基础操作
AI 基本不会出错，可以直接保留
占比约 60%-70%

第二类：待修改用例

边界值不精准（如写了"输入负数"，但没写具体-1 还是-0.01）
异常场景描述模糊（如"网络异常"没定义异常类型）
步骤顺序错乱
这类不用直接删掉，人工微调后就能复用

第三类：直接废弃用例

逻辑前后矛盾（如前置条件说"未登录"，步骤里却要求"点击个人中心"）
编造不存在的业务功能（AI"幻觉"出来的菜单或按钮）
重复冗余（同一个场景换说法写了 3 遍）
完全脱离实际业务（如电商系统里出现"火箭发射"的测试步骤——别笑，我真见过）
这类必须直接剔除，绝对不能混入测试套件

同时还要检查自动化脚本，看脚本是否只实现了页面操作，缺少结果断言，缺少异常捕获，缺少环境兼容适配，这类脚本跑通也没有任何测试意义，必须整改。

这一步的关键是 “不迷信 AI 产出”，用人工的专业判断筛选出真正有价值的内容，避免无效用例占用测试资源。

第三层：多维度量化校验，不靠感觉，靠数据

判断 AI 测试用例可不可靠，不能凭肉眼感觉，要有量化标准。

首先，核对需求覆盖率，对照需求文档每一个功能点，检查有没有遗漏、未覆盖的模块。
其次，统计反向用例、边界用例、异常用例的占比。正常业务不能只有正向用例，没有反向和异常兜底。然后排查重复用例率、逻辑错误率、高危场景遗漏率。
结合项目历史缺陷库，校验 AI 有没有覆盖过往线上出过的同类 bug

具体供参考：

校验维度	具体做法	合格线
需求覆盖率	对照需求文档逐条映射，看每个功能点有没有对应用例	≥95%
反向用例占比	反向/异常用例占总用例比例	≥30%
边界用例数量	每个数值型字段至少 2 个边界值（最小、最大）	100% 覆盖
重复用例率	语义重复的用例占比	≤10%
逻辑错误率	业务逻辑错误或无法执行的用例占比	≤5%
高危场景遗漏率	权限/并发/弱网/非法输入/参数篡改等场景	0%
历史缺陷覆盖率	过去 3 个版本的线上 Bug，AI 用例能否覆盖	≥80%

除此之外，还要重点核对 AI 最容易忽略的高危场景，比如

权限互斥：越权访问、角色切换后的权限残留
并发场景：同一用户多设备登录、秒杀抢购
弱网环境：2G 网络、网络切换、飞行模式
非法输入：SQL 注入、XSS、路径遍历、特殊字符
接口安全：参数加密、签名验证、重放攻击

这些是 AI 最容易忽略，但最容易引发线上故障的点，用数据做校验，才是专业测试的做事方式。

第四层：三级审核，用人工经验兜底，守住核心风险

AI 永远替代不了人的业务经验，核心场景必须层层把关，所以这里，我建议的做法是，建立 “初审 + 复核 + 终审” 的三级审核机制：

初审：用自动化工具批量过滤重复用例、格式错误、逻辑冲突的内容，节省人工时间；
复核：由资深测试工程师负责，逐行校验核心业务的边界、极值、异常流程，尤其是支付、权限这类高危模块，比如核对自动化脚本是否有断言、异常捕获、环境适配逻辑；
终审：由业务负责人或测试总监确认，重点把关隐性需求和特殊业务规则，比如电商订单的 “跨平台退款规则”“节假日支付限额” 等 AI 无法理解的业务细节。

三道关卡层层过滤，能从根本上杜绝 AI 的错漏内容流入执行阶段，这也是规避线上故障的关键。

第五层：复盘沉淀，让 AI 越用越 “懂” 业务，形成闭环

AI 测试不是一次性行为，一定要做长期沉淀优化。

建议在每次项目结束后，记录三类信息：

1、AI 翻车案例库

哪类场景 AI 容易漏测？
哪类业务 AI 容易编造规则？
哪类脚本容易出现断言缺失？

2、优质模板库

提示词模板（不同业务类型的标准 Prompt）
用例模板（正向/反向/边界的标准格式）
脚本规范模板（断言、异常处理、日志的代码规范）

3、训练数据集

把历史优质用例、业务规则、负面案例投喂给 AI
让 AI 越来越贴合团队业务，生成内容越来越精准

形成完整闭环：

需求拆解 → AI 生成 → 分类筛选 → 量化校验 → 三级审核 → 落地执行 → 复盘沉淀 → 优化提示词 → 下一轮复用

graph TD
    A["需求拆解"] --> B["AI生成"]
    B --> C["分类筛选"]
    C --> D["量化校验"]
    D --> E["三级审核"]
    E --> F["落地执行"]
    F --> G["复盘沉淀"]
    G --> H["优化提示词"]
    H --> I["下一轮复用"]
    I --> A

这才是成熟的 AI 测试工作模式。

为什么有人用 AI 效率翻倍，有人越用越漏测？

说到底，AI 测试的核心不是 “会不会用 AI 写用例、出脚本”，而是 “能不能用人的专业能力约束 AI、校验 AI、优化 AI”，这也是前段时间 AI 圈大火的Harness Engineering所提倡的思想。

很多人觉得 AI 测试 “越用越坑”，本质是把本该自己把控的质量责任甩给了 AI；而真正能把 AI 用出效率的人，是把 AI 当成 “高效的工具”，而非 “甩锅的借口”。

最后想问问大家：你们在工作中用 AI 生成测试用例时，有没有踩过类似的坑？AI 有没有漏过让你后怕的边界场景？欢迎在评论区交流，我尽量每条都回复。

OpenAI 发布三款新语音模型；Plaud 获头部大厂投资，估值达 20 亿美元；阶跃星辰将完成近 25 亿美元融资丨日报

RTE — Fri, 08 May 2026 23:56:53 +0800

开发者朋友们大家好：

本期编辑：@koki、@ 鲍勃

01 有话题的技术

1、OpenAI 发布三款实时语音模型

今天，OpenAI 发布三款实时语音模型，分别针对语音推理、实时翻译和流式转录三类场景：

GPT-Realtime-2：构建可用于生产环境的语音智能体。它们能够进行更深入的思考、执行操作、处理中断，并让对话持续自然地进行；
GPT-Realtime-Translate：支持 70 多种输入语言和 13 种输出语言的实时翻译，打破语言障碍，帮助人们更自然地交流；
GPT-Realtime-Whisper：实时转录音频流，生成字幕和注释。

其中，GPT-Realtime-2 搭载「GPT-5 级别的推理能力」，专为语音交互场景设计，能够在持续对话过程中处理复杂请求、多线程调用外部工具、应对用户中断，并保持对话的自然流畅。

三款模型均已通过 OpenAI Realtime API 向开发者开放，并可在 OpenAI Playground 中进行测试。

完整介绍：OpenAI Realtime API 重磅更新：锚定语音模型「深度推理 + 自主执行」演进路径｜Voice Agent 学习笔记

( @APPSO)

2、Giga 发布语音智能体实时幻觉纠正方案：利用播报延迟窗口并行推理，生产环境幻觉率降至 1% 以下

Giga Research 针对语音智能体推出一种实时幻觉纠正技术。该技术利用 LLM 文本生成速度（约 75 tokens/s）远快于人类语速（30 词需 10-12s）的时间差，在 TTS 播报的同时引入推理模型并行检测。在不增加首字延迟（TTFB）的前提下，将 120 万轮真实通话的幻觉率从 5% 降低至 1% 以下。

并行双路流式架构（Parallel Streaming）：系统在生成响应后同步启动两条路径：路径 A 直接将文本送入 TTS 实时播报；路径 B 将同片段送入强推理模型。两者「竞速」，若检测器在音频播放到风险点前完成判定，则执行静默拦截或补救，从而绕过「先验证再播报」带来的 3-4 秒额外延迟。
基于播报时长的检测窗口：由于 30 词的完整文本在 1 秒内即可生成，而播报需 10 秒以上，为推理检测留出了约 9 秒的「零延迟感」计算窗口。即使推理模型耗时 3 秒，仍有极大概率在用户听到错误信息前完成修正。
条件式纠正机制（Conditional Injection）：根据判定时间点采取不同策略：若检测器在幻觉片段播放前完成，通过 audio_stream.block（）实现无感替换（Outcome 1）；若幻觉已部分播放，则通过 audio_stream.inject（）插入「让我更正一下」等衔接语并补齐正确事实（Outcome 2）。
临时纠正提示（Temporary Correction Hints）：修正后的元数据在当前回合结束后会被清空（correction_hint = None）。实验表明，若将纠正历史保留在 Context 中，会导致模型对冲（Hedging）率增加一倍，使智能体因「过度谨慎」而丧失表达自信。
生产级性能表现：在 1.2M 轮次实测中，幻觉率下降 70%，误报率（FP）控制在 0.3% 以下。针对指令冲突、上下文矛盾的检测准确率达 94-97%。

https://giga.ai/hallucinations

( @GigaAI\@X)

3、阶跃星辰将完成近 25 亿美元融资

获悉，国产大模型公司阶跃星辰将完成近 25 亿美元融资。知情人士称，其红筹架构亦已拆除，这通常被视为赴港 IPO 的关键前置步骤。据悉，最新融资中产业链资本集中入场，包括华勤、龙旗、豪威、中兴等，覆盖从整机制造到上游核心器件多个环节。此外，「港版淡马锡」香港投资管理有限公司（HKIC）也出现在股东名单中。工商信息显示，公司已于 4 月完成股改，由有限责任公司变更为股份有限公司。

（@ 界面新闻）

4、Spotify 发布 save-to-spotify 开源工具支持私人播客音频上传

日前，Spotify 在 GitHub 开源推出处于 beta 阶段的命令行工具 save-to-spotify。该工具允许用户通过 Agent 和自动化流程，将 AI 生成或本地音频上传至 Spotify，以私人播客形式（仅本人可见）保存在个人库中。

该工具本身不生成音频，需结合 TTS 工具使用。它支持多种安装方式，可无缝集成至 Claude Code 等 Agent 环境。

用户完成一次性认证后，即可执行音频上传、节目及剧集管理、时间轴标记等操作。据官方博客表示，此举旨在满足用户在 Spotify 集中收听由 Agent 生成的简报等个人音频的需求。

https://github.com/spotify/save-to-spotify

（@ 橘鸦 Juya）

02 有亮点的产品

1、Plaud 获头部大厂投资，目前估值达 20 亿美元

根据相关渠道披露，Plaud 在 2025 年中曾获腾讯投资，当时估值为 10 亿美元，尽管双方官方对此均予否认，但其财务表现支撑了估值跳涨：2024 年该公司营收为 5600 万美元，利润率接近 20%，而 2025 年营收规模预计将翻三倍达到 2.5 亿美元。

截至 2025 年 7 月，Plaud 全球累计出货量已突破 100 万台，其高速增长的核心逻辑在于通过极简的硬件形态，精准补位了海外 iOS 系统原生通话录音功能的缺失。

在技术规格与产品形态上，Plaud Note 主打 2.9mm 超薄工业设计，通过 MagSafe 磁吸阵列适配智能手机，并集成多麦克风收音阵列以优化近场语音采集。软件层面，该设备高度依赖 LLM（大语言模型）的开放 API 能力，实现数十种语言的实时转写、智能会议纪要生成及多语种翻译。目前 Plaud 在中国内地市场已投放 Note、NotePin S 及 Note Pro 三款产品，定价区间锁定在 1149 元至 1299 元。然而，由于其核心 AI 功能（转写、总结、翻译）主要基于通用大模型封装，在缺乏独占性底层技术壁垒的情况下，其硬件护城河正面临国内成熟供应链的快速平替压力。

随着钉钉发布 AI 录音卡片 DingTalk A1 以及安克联合字节跳动推出「AI 录音豆」，Plaud 已深陷办公软件巨头的降维打击。国内巨头凭借原生的办公协作生态（如钉钉、飞书、腾讯会议），可实现从线下语音采集到线上协同文档的无缝闭环，这对功能单一的独立硬件构成了巨大挑战。目前 Plaud 在国内消费级市场的销量尚未突破 10 万台，正被迫转向医疗、金融等 B2B 垂直行业寻求落点。从行业格局看，腾讯若完成对 Plaud 的布局，意味着三大 AI 巨头已全面完成对 AI 录音硬件入口的占位，旨在将硬件作为物理触手，承接线下工作流数据并反哺其 AI 软件生态。

（@ 硬氪）

2、德国 AI 明星企业 DeepL 宣布裁员四分之一，约 250 人将离职

德国人工智能明星企业 DeepL 宣布大规模裁员。这家以 AI 翻译技术闻名的德国公司表示，将削减约 250 个岗位，约占员工总数的四分之一。这也是 DeepL 成立以来最大规模的一次组织调整。

DeepL 首席执行官雅雷克·库特洛夫斯基（Jarek Kutylowski）当天在 LinkedIn 发文称，公司必须进行结构性改革，以便在人工智能时代继续保持竞争力。他写道：「这一决定并非轻率作出，而是我职业生涯中最艰难的决定。」

在德国科技行业中，DeepL 长期被视为少数能够与美国科技巨头抗衡的本土 AI 企业之一。这家成立于德国科隆（Köln）的公司，凭借高质量机器翻译技术迅速崛起。在 ChatGPT 问世之前，DeepL 就已经采用自主研发的神经网络架构，其翻译效果一度被认为明显优于 Google 翻译等竞争产品。

凭借这一技术优势，DeepL 迅速积累用户和市场份额，并曾以约 20 亿美元估值，成为德国估值最高的纯人工智能企业之一。过去几年，DeepL 的业务增长速度极快。数据显示，公司营收从 2022 年的 5510 万欧元增长至 2024 年的 1.56 亿欧元，短短两年几乎增长了三倍。

与此同时，公司员工规模也快速扩张：2022 年，DeepL 仅有 271 名员工；到 2024 年底，正式员工已增至 634 人；若加上兼职、实习生和学生员工，总人数达到 972 人；而目前公司员工总数已超过 1000 人。

不过，在 AI 行业高速发展的同时，DeepL 如今却开始主动「踩刹车」。库特洛夫斯基表示，人工智能正在根本性改变企业组织结构和工作方式。「我们正经历一场巨大的结构性转变——工作的方式、执行工作的人，以及完成工作所需的人数，都在被 AI 重新定义。」他强调，此次裁员属于「结构性调整」，目的是确保 DeepL 未来继续保持 AI 领域领先地位。目前，DeepL 尚未公布具体哪些部门将受到影响。

DeepL 的裁员，也被外界视为欧洲 AI 企业当前处境的缩影。一方面，人工智能行业持续高速发展；另一方面，高昂的人力、算力与研发投入，也正在考验欧洲 AI 公司的盈利能力。尤其在美国科技巨头持续加码 AI 竞争背景下，即便是 DeepL 这样的德国「AI 明星公司」，也开始进入更加现实的降本增效阶段。

（@ 开元网）

3、苹果摄像头版 AirPods（H90）传产线解散：搭载 H3 芯片与红外传感器，因欧盟合规风险搁置

苹果代号为 H90 的内置摄像头 AirPods 项目近期传出供应链异动，部分产线已原地解散。该设备旨在通过红外传感器为 Siri 提供视觉环境感知能力，但由于无法绕过欧盟关于公共空间隐私采集及旁路告知的法律红线，项目进度已实质性停滞。

传感器方案： 放弃可见光摄像头，采用低分辨率红外（IR）传感器（类 Face ID 模组），通过主动发射红外光感知空间深度、物体轮廓及运动状态，数据仅供端侧 AI 处理，不生成图像文件。
计算核心（H3 芯片）： 搭载新一代 H3 自研芯片，算力较 H2 大幅提升，旨在承载实时视觉上下文的端侧 AI 推理（On-device AI Inference），支持环境智能（Ambient Intelligence）交互。
物理反馈机制： 耳机柄部集成微型 LED 指示灯，传感器工作时自动亮起以提示周围人群，逻辑参考 Meta Ray-Ban 智能眼镜。
法律合规博弈： 核心障碍源于欧盟 CJEU C-422/24 号判决，该判决要求可穿戴设备在采集路人数据时需履行「即时告知义务」，且 H90 采集的生物特征数据（如耳部轮廓、步态）触及 GDPR 第九条禁令。
AI 硬件路线图调整：随着 H90 搁置，苹果 AI 穿戴重心或转向 2027 年发布的 N50 智能眼镜，同时已停止低价版 Vision Pro（N100）的开发，策略全面转向 iPhone 的「感官外设」化。

( @APPSO)

03 有态度的观点

1、Claude Code 负责人：「Vibe Coding」这个词已经不够用了

Claude Code 负责人 Boris Cherny 当地时间周三在旧金山出席 Code with Claude 开发者大会期间表示，他已开始寻找「氛围编程（Vibe Coding）」一词的替代说法。

「氛围编程」由 OpenAI 联创 Andrej Karpathy 于 2025 年初提出，很快成为描述「借助 AI 工具和智能体写代码」这一新范式的通用说法。柯林斯在线词典去年 11 月更是将其评选为年度词汇。

但切尔尼认为，随着 Claude Code 和 OpenAI 的同类产品 Codex 已分别为各自公司带来数十亿美元收入、并持续生成数百万行可用代码，「氛围」这一措辞显得过于轻描淡写。

切尔尼曾就此向 Claude 征求替代词，得到的候选答案是卡帕西此前提出的「智能体工程（Agentic Engineering）」，但他认为这一说法传播效果有限。

目前，Anthropic 在官方文档中将 Claude Code 称为「AI 驱动的编程助手」和「智能体编程工具」；OpenAI 则将 Codex 定位为「帮助用户借助 AI 构建和交付的编程智能体」。

( @APPSO)

04 社区黑板报

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

1、OpenClaw 之后，Agent 如何重新洗牌？｜北京 Agent 黑客松来了

🦞 Agent Evolution Party · 北京站

一场真正面向开发者的 Agent 黑客松 + 行业大会

5 月 10 日，北京，我们想认真聊聊：

OpenClaw 之后，Agent 格局会如何被重新定义。

核心话题：

OpenClaw 之后，Agent 格局如何被重估

1 人百万 MRR + Self-evolving Agent Harness 实战

Web Agent + Consumer 新机会

Agent 时代的工作与教育新范式

📅 时间：5/10（周日）

📍 地点：北京朝阳

🎟 报名需审核（开发者 / 观众均可报名）

Luma 报名：https://luma.com/7vjii1bu?utm_source=rte

海报扫码可进活动群

写在最后：

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

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

AI 只是让你零门槛成为测开，可并没减轻你的测试工作

Ikuner — Fri, 08 May 2026 22:49:27 +0800

软件测试这个行当，最近两年被 AI 的风吹得有点站不稳了。各种大会上，PPT 里全是 AI 自动生成用例、AI 自主探索测试、AI 智能分析缺陷的画面，仿佛明天测试工程师就要集体失业，后天 AI 就能把质量保证这件事全盘接手。
于是市面上出现了一种论调：测试的职能被 AI 打下来了，测试的价值被 AI 消解了，测试这个岗位岌岌可危了。

但真正在一线干活的人心里都清楚——AI 只是让测试零门槛成为测开，但测试最核心的工作，AI 是一点都没接过去，甚至还添了不少乱

一、测试到底在做什么
先把那些花里胡哨的概念放一边，回到地面上来。

测试的本质工作是什么？是保证质量。这件事的核心路径从来都是：梳理业务的核心主流程和异常支线，把每一条路径变成可执行的测试用例，然后一步一步地执行，观察结果，判断对错，发现问题，推动修复。

这不是什么高深的理论，这就是测试每天在做的事。
例如一个面试问到烂的电商下单流程，正向路径有几步、哪些节点会分叉、支付失败怎么办、库存不足怎么处理、优惠券叠加的优先级是什么——这些东西，需要有人去想清楚、写下来、跑一遍。

而要完成这一整套动作，至少需要三个前提：

第一，清晰的需求文档。
没有需求参照，测试就是在黑暗中摸索。业务规则是什么、边界条件在哪里、异常情况如何处理，这些东西必须有人明确地写下来，或者至少在沟通中达成共识，据我跟多数测试同学的交流来看，这一步基本没几个团队能做好。

第二，对任务性质和优先级的筛选和排序。
不是所有功能都一样重要，不是所有路径都值得同等的精力投入。核心交易链路出问题是 P0 事故，某个角落里的文案展示问题可能连 P3 都排不上。什么先测、什么重点测、什么可以放一放，这个判断需要经验和对产品的理解。

第三，沟通和对业务的了解。
测试从来不是对着文档闷头干活。产品经理说的和实际想要的可能不是一回事，开发理解的又可能是另一回事。测试往往是在这三者之间反复对齐的那个人，靠的是对业务的熟悉程度和沟通的意愿与能力。

这三个前提，没有任何一个是 AI 能替你解决的。

二、AI 能做什么，不能做什么

AI 确实让一些事情变容易了。
写个接口测试脚本，AI 能生成；分析一段代码的潜在风险，AI 能给出建议；搭个小工具做数据构造或者结果比对，AI 也能帮上忙。以前这些事情可能需要一个有一定编程能力的测开来做，现在门槛确实被拉低了，一个业务测试同学借助 AI 也能搞定。

但问题在于，这些都只是测试的周边工作，不是测试本身。

测试本身是什么？是执行用例。是打开页面、点击按钮、输入数据、观察响应、判断对错的那一下。是发现实际结果和预期不符时，凭借对业务的理解决定这到底是个 bug 还是设计如此。是在复杂的业务场景中，捕捉到那种 “虽然看起来没问题，但总觉得哪里不对” 的微妙感觉。

这些东西，AI 做不了。

原因其实很简单，而且很根本：AI 本身有幻想。用带有幻想的 AI 去执行测试用例，这本身就是一件极度悖论的事情。测试的目的是发现软件的缺陷，如果测试工具本身就会产生幻觉——它会凭空编造一个结果、它会忽略一个关键差异、它会自信满满地告诉你 “一切正常”——那你还测什么呢？，用不确定的工具去测试不确定的项目，然后不断去完善不确定的工具，这完全是扯蛋。

所以那些鼓吹 AI 能替代测试执行的人，要么根本不懂测试，要么是揣着明白装糊涂。

三、自动化的老账
就算不扯 AI 的幻觉问题，回头看看行业里那些所谓的 “自动化”，情况也从来没那么乐观。

接口自动化、UI 自动化、巡检用例、测试平台……这些东西，行业里做了少说十年了。
它们的定位从来都很清楚：锦上添花。

自动化能做的事情，是在测试人员已经完整执行过一轮、确保了基本质量之后，接管那些重复性的回归验证工作。
它是一道后期保障，不是主力部队。它能帮你守住已知的阵地，但它开疆拓不了土。

而且就连这个 “保障” 的性质，在行业里也一直颇有争议。自动化用例需要维护，业务一变它们就失效。UI 自动化的稳定性是个永恒的老大难，今天因为网络延迟挂了，明天因为页面加载慢了两秒挂了，排查脚本本身的问题比排查被测系统的问题还费劲。多少团队的自动化跑了好几年，发现的有效 bug 屈指可数，维护成本却持续走高。

自动化从来就没有大幅提升过测试的效率。它只是改变了测试工作的时间分布——把一部分后续的重复劳动提前支付了编写和维护脚本的成本。这不是效率的提升，这是时间换时间，而且换得还不一定划算。

那些指望 AI 自动化来解放测试生产力的人，面对的现实是：过去的自动化没做到的事，带上 AI 的自动化大概率也做不到，因为问题的本质不在 “不够智能”，而在 “测试这件事本身就不是纯逻辑推导”。

四、AI 的真正 “贡献”

更讽刺的事情还在后面。

AI 确实没有给测试提升多大的效率，但它给开发提升的效率是巨大的。

代码补全、代码生成、bug 定位、重构建议——AI 让开发的效率实打实地提升了。以前写一个模块要三天，现在借助 AI 可能一天就搞定了。开发时间缩短了，那省下来的时间干嘛呢？当然是开发更多的内容。

产品经理看到开发效率提升了，需求也从前相对克制变得大胆起来。迭代周期没变，但每个迭代塞进去的需求量肉眼可见地变多了。代码量在膨胀，变更范围在扩大，系统复杂度在加速增长。

而这些多出来的代码、多出来的变更、多出来的复杂度，最终是谁来接？
是测试。

以前一个迭代三五个需求，测试还能从容地梳理用例、执行验证。现在一个迭代塞进十几个需求，每个都是 AI 辅助开发快速产出的，测试只能用同样甚至更短的时间去消化翻倍的工作量。

更麻烦的是，AI 写的代码本身就是一个巨大的不确定性来源。AI 生成的代码看起来规范、运行起来也基本正常，但那些藏在边角里的逻辑漏洞、那些似是而非的错误处理、那些在极端情况下才会触发的 race condition——这些东西比人写的 bug 更难发现，因为它们是 “看起来正确” 的错误。

测试不仅要测业务逻辑对不对，还要额外提防 AI 编码带来的隐藏巨坑。这多出来的工作量，谁来买单？

所以现实就是：AI 的到来，对测试而言，工作没少，反而多了。对手变强了，你的装备却没什么实质性的升级。开发端效率飙升的浪潮，涌到测试端全变成了压力和风险。

五、最后说几句现实的话。

坦诚地讲，AI 工具带来的便捷性，我们应当是肯定的。它确实让一些重复性的脚本编写、数据分析、报告生成工作变得简单，让不懂代码的测试人员也能快速拼装出一些辅助小工具。这一点毋庸置疑，否定 AI 的便利性是另一种傲慢。

但必须清醒地认识到，这份便利主要停留在 “测试开发” 这个层面，它并没有给测试核心工作带来实质性的减负。用例依然要靠人一个个去设计、去执行，业务风险依然要靠人一条条去梳理、去判断。AI 没能替你跑完哪怕一条核心业务链路，也没能替你挡下一次因需求模糊而引发的线上事故。

因此，在日常工作中必须格外小心。
眼前堆过来的不仅是翻倍的需求量，还有那些 AI 生成的、看似规范实则暗藏逻辑瑕疵的代码。
那种 “AI 生成的代码就比较安全的” 的想法，本身就是极其危险的妄想。
你的责任是守住最终交付给用户的质量，而不是去验证 AI 的工具箱是否完美——业务质量的防线一旦后撤到 “AI 产物监督员” 的位置，崩塌只是时间问题。

更重要的是，测试的精力分配需要一场清醒的转向。
不必再把时间大量投入在自研测试平台、搭建宏伟的自动化框架这些传统测开事务上了。
AI 擅长这些，而且会越来越擅长，你在这个赛道上和 AI 拼效率，拼持久度，既没有胜算，也没有必要。

正确的发力方向，是把省下来的那点脚本编写时间，和原本可能投在平台开发上的精力，全部倾注到两件事上：沟通交流和流程把控。

去和产品经理反复磨需求，把模糊的描述逼成清晰的验收标准；去和开发提前对齐技术方案，在编码之前就掐断那些注定会爆雷的逻辑分支；去建立更严密的提测规范，用流程来过滤掉一部分 AI 代码带来的不确定性；去把上线的灰度节奏、监控报警、回滚预案提前拉到可执行的状态。

这些工作，AI 插不上手，因为它们依赖的是信任关系、业务直觉和跨角色博弈的能力。而恰恰是这些工作，在 AI 大幅搅动研发节奏的今天，成了质量保障真正的承重墙。

【注：将观点输给 AI，然后 AI 生成的短文】
最后，用节省下来的时间多多探索副业和自己感兴趣的事，不要为了什么提升测试技术去知识付费了，都是扯蛋，毛用都没

测试之家社区

如何成为 AI Test 架构师

从这个用例怎么写到整个体系怎么设计

核心能力地图

AI 时代 Test Architect 的新增职责

薪资与市场信号

这条路适合谁

FunTester 名片｜万粉千文，百无一用

使用本地模型 “3 小时” 构建番茄时钟 Mac 桌面应用

背景

尝试

Claude Code

Pycharm+AI Chat

Pycharm+CC GUI

Cursor

VSCode+Copilot Chat

在线模式

本地模式

VSCode+Continue

配置先行

效果

工具

具体实现

Ollama

Cherry Studio

Name: Electron Professional Tomato Clock

Description

执行步骤

1. 项目初始化

2. 项目文件结构

3. 代码实现

Visual Studio Code+Continue

配置

执行

优化布局

打包 Mac 应用

应用优化

结束语

遗留问题

【ACM 出版 | EI 稳定检索】2026 年机器学习与数据安全国际学术会议

OpenAI 的 WebRTC 秘密架构：没有 SFU？没有问题！丨 Voice Agent 学习笔记

深度拆解 OpenAI 的 Voice AI 硬核架构

AI 代码为什么更多 BUG

从一个真实事故说起

数据层：AI 代码的缺陷画像

机制层：幻觉为什么在数学上不可消除

认知层：AI 不知道这是不是问题

AI 越能写代码，验证代码的需求越大

FunTester 名片｜万粉千文，百无一用

AI 赋能测试实践 09：MCP 来了，测试人员怎么接？三个趁手的工具 + 50 行搓一个自己的测试 Server

前言

三个现成的测试 MCP 工具

Playwright MCP——微软官方，测 UI 的

api-tester-mcp——专为 QA 设计的接口测试工具

mcp-swagger-server——让你的 API 文档"活"过来

三个工具对比

50 行搭一个自己的测试 MCP Server

自己动手搭一个，有三个原因

选一个测试场景

代码实现

配置到 Claude Code

更多玩法思路

Skill 跟 MCP 的区别

后记

ATM 没有消灭柜员，AI 也不会消灭测试

ATM 的故事

软件测试领域的三次浪潮

当前数据的矛盾信号

被裁撤的 AI 招聘系统

消失的是什么，留下的是什么

结构性变化的真实面目

FunTester 名片｜万粉千文，百无一用

针对 AI 说几句心里话 -- 拥抱 AI，世界不以个人的意志为转移

前言

我对 AI 的态度

大厂的人都在做什么

调整心态

结尾

ITP V6.1.0 重磅发布：AI 赋能测试全流程，让用例生成效率提升 10 倍！

StepAudio 2.5 Realtime 上线，升级副语言感知能力；VoiceBlender：基于 Go 的 SIP-WebRTC 桥接服务丨日报