测试之家社区

直播录屏 -- 从需求生成测试用例的 SKILL 设计思路（主要是知识库设计）

ycwdaaaa — Mon, 20 Jul 2026 22:16:22 +0800

录制: 从需求生成测试用例的 SKILL 设计思路（主要是知识库设计，带 skill DEMO 下载）
日期: 2026-07-04 19:32:40
录制文件：https://meeting.tencent.com/crm/Kz8Go7Q8bb

欢迎大家加入星球：

如何让 AI 把测试用例的前置条件补到可执行

test_jammy — Mon, 20 Jul 2026 20:54:32 +0800

背景

很多 AI 生成的测试用例，步骤看起来完整，真正执行时却会卡在前置条件上。

典型写法是：

用例：删除默认收货地址
前置条件：用户已登录，系统运行正常
步骤：进入地址列表，删除默认地址
预期：删除成功，功能正常

问题不只是表达模糊。账号下有几条地址、哪条是默认地址、是否被订单引用、删除后如何回退，都会改变预期结果。

本文使用一个脱敏演示，展示如何约束 AI 区分事实、可准备数据、假设和待确认规则。示例不是某个具体模型的横向评测，也没有使用生产数据。

演示条件

场景：地址管理中的 “删除默认地址”。
输入材料：一条模糊旧用例，以及有限的业务描述。
环境：方法演示，不连接真实业务系统。
目标：得到一份可执行、可评审的用例结构。
验证方式：检查每个前置条件是否有来源，每个预期是否可观察。

第一次输出为什么不能直接用

当输入只有 “删除默认地址” 时，AI 很容易补出如下规则：

前置条件：
1. 用户已登录。
2. 账号下存在多条地址。
3. 当前默认地址未被订单使用。

预期结果：
1. 默认地址删除成功。
2. 系统自动将下一条地址设为默认地址。

第 1 条通常可以由执行人准备，第 2 条需要明确具体数据，第 3 条和 “自动选择下一条” 则可能是 AI 根据常见产品逻辑补出的假设。

如果需求没有这些规则，就不能把它们直接写进正式用例。

将前置条件拆成四类

建议先建立以下结构：

分类	定义	示例	处理方式
已知事实	需求、接口或确认记录中明确的规则	用户可以进入地址管理页	可以进入正式用例
可准备数据	测试人员能稳定构造的数据	账号下存在 A、B 两条地址	写明创建或获取方式
AI 假设	输出中出现但输入没有依据	删除后自动选择最近地址	不进入正式用例
待确认规则	不确认就无法判断结果	被订单引用的地址能否删除	提交产品或开发确认

这个分类的作用是避免 AI 把 “合理” 误写成 “真实”。

改写后的结构示例

用例目标：验证删除默认地址后的地址状态。

已知事实：
- 已登录用户可以进入地址管理页。
- 地址列表展示默认地址标记。

可准备数据：
- 账号 U1 下创建 A、B 两条地址。
- A 标记为默认地址，B 为非默认地址。

操作步骤：
1. 使用 U1 进入地址管理页。
2. 删除地址 A。
3. 重新查询地址列表。
4. 进入下单页检查默认选中地址。

可观察结果：
- A 不再出现在地址列表中。
- 地址查询接口不再返回 A。
- B 的默认状态根据已确认规则进行断言。
- 删除失败时，A 和 B 的状态保持不变。

待确认规则：
- 删除 A 后，B 是否自动成为默认地址？
- 被未完成订单引用的地址是否允许删除？

这里没有强行补出最终业务答案，但执行条件和证据位置已经明确。规则确认后，只需要补上对应断言。

评审时重点检查什么

1. 前置状态是否可以稳定准备

不要只写 “存在测试数据”。应该说明账号、数据数量、对象状态，以及准备数据的方法。

2. 前置条件是否混入预期结果

“删除后自动选择下一条地址” 是结果规则，不是操作前已经存在的条件。

3. 每条规则是否有依据

可以在用例中记录需求章节、接口字段、评审结论或历史缺陷编号。没有依据的内容进入待确认项。

4. 结果是否可观察

优先使用执行人能获得的证据：页面状态、接口响应、消息记录或允许查询的数据。不要用 “系统正确处理” 代替断言。

5. 是否包含清理和恢复

地址、账号和默认状态如果会被用例修改，需要说明如何恢复，避免影响后续执行。

常见坑

让 AI 根据产品常识自动补业务规则。
把 “用户已登录” 当成全部前置条件。
写了测试数据，但没有说明数据状态。
把结果规则写进前置条件，导致逻辑循环。
为了显得完整，隐藏了仍未确认的信息。
只断言页面提示，没有检查对象状态是否真的变化。

适用边界

这套方法适合评审和改写 AI 生成的功能、接口和场景用例。对于强合规、资金或权限场景，还需要结合正式规则、历史缺陷和系统设计材料。

脱敏演示只能用于说明方法，不能替代真实项目的业务确认和实际执行结果。

前置条件写得越像事实，越应该追问它的来源。AI 可以帮助补结构，但不能替项目补规则。

实测深度对比：kylinPET 奇林性压测工具与行业主流工具数据一致性、重复性

SagacitySea — Mon, 20 Jul 2026 19:22:51 +0800

在软件性能测试领域，LoadRunner 和 JMeter 一直是大家的首选。但随着信创发展和企业对数据安全的重视，越来越多团队开始寻找国产替代方案。

最近，我注意到一款名为 kylinPET（奇林性能测试软件）的国产工具。为了验证其 “能不能打”，我查阅了它在中国计量科学研究院（NIM）的最新检测报告（报告编号：CLrj2025-00050）。

这里从技术角度，结合权威数据，和大家聊聊这款工具的实测表现。

一句话总结：在同等条件下，kylinPET 与 LoadRunner 12.6 / opentext 24.3 的数据偏差（RD）普遍控制在 1% 以内，最高高并发场景下 RD 最大值为 2.83%；而重复性（CV）更是低至 0.00% - 0.02%。这已经不是 “能用” 的级别，而是 “高精度” 的级别。
一、检测环境还原：高精度的 “公平对决”
报告的真实性取决于环境的控制。这份检测采用了 “完全一致” 的对比策略：
测试机采用戴尔外星人 / Latitude 5440，服务器采用 Intel Xeon 处理器（64G 内存），并使用了 NIOServer 作为陪测软件（非阻塞 I/O 架构，支持毫秒级延迟控制）。

测试分为 7 个场景（P01 - P07），涵盖从 50 用户到 1000 用户，以及 1 小时耐力测试：

二、核心数据解读：不仅准，而且稳
评价测试工具是否合格，主要看两个核心指标：准确性（RD，相对偏差）和重复性（CV，变异系数）。

此次检测依据 GB/T 25000.51-2016 标准，要求 RD ≤ 3%，CV ≤ 0.3%。让我们看看实际数据：

2.1 首要验证：工具本身的压力发送能力是否准确？
懂行的人看报告，首先看 “用户在线数/秒”。因为这个数值是我们在工具里手动设置的 “目标并发数”，也就是压力发起的理论起点。

如果工具自身统计出来的 “在线用户数” 明显偏离了设置值，说明工具本身对虚拟用户的调度不够精准，出现了 “丢压” 或 “响应滞后”。

我们可以对比一下 kylinPET 在不同场景下的表现：

在 1000 用户的高并发极限场景下，kylinPET 的 5 次测量结果竟然完美保持了 1000.000。这直接证明了工具本身的并发调度引擎非常强悍，它发出的压力是可控、准确且没有损耗的。

2.2 其次验证：测出来的业务数据是否可信？
既然工具发出的压力是准确了，那它记录的业务指标（如事务时间、TPS）是否准确呢？我们对比了基准工具 LoadRunner：

场景指标名称 kylinPET LoadRunner 相对偏差 (RD)
P03 (200 用户) 用户时间 90% 分位 5.998 s 6.022 s 0.39%
HTTP 请求数/秒 465.890 462.810 0.67%
P06 (500 用户, 1 小时) 用户成功数/秒 83.333 82.780 0.67%
接收吞吐量 Mb/S 10.049 9.984 0.65%
可以看到，在多种负载下，kylinPET 与商用标杆工具的业务数据偏差（RD）普遍在 1% 以内。这不仅证明它能 “发准压力”，还能 “测准结果”。

三、技术思考：性能测试工具本身的性能
为什么 kylinPET 能取得这样的成绩？报告中提到其陪测环境采用了 Reactor 模式非阻塞 I/O 架构，单服务器可支撑 5 万 + 并发连接，内存占用低于 200MB。

这里抛出一个观点：性能测试工具本身的性能，决定了它能否测出被测系统的真实性能。过去我们用 LoadRunner 是因为它是行业标准，但现在国产工具在底层算法精度（如数据抓包、时间戳计算）上已经相当扎实。

这份中国计量院的报告不仅仅是一份合格证明，更是国产性能测试工具在计量级精度上的一次重要突破。有了 CNAS 和 ilac-MRA 的互认背书，其测试结果在行业内具备了更强的公信力。

四、结论与选型建议
综合来看，kylinPET V7.5 在功能实现、压力发送准确性、业务数据准确度（RD）和稳定性（CV）上，与商业标杆 LoadRunner / opentext 的对比中，表现出了极高的水准。

尤其是 “用户在线数” 这个基准值，在 1000 并发下完美贴合设置值，说明它的并发引擎调度没有损耗，这在国内工具中非常难得。

如果你是中小企业、信创项目团队，或者正在做国产化选型，这款工具值得纳入评估视野。它不仅是 “能用”，而是有权威数据支撑的 “好用”。

当然，工具只是辅助，具体的脚本设计和场景分析才是核心。如果你最近也在做性能测试工具选型，欢迎在评论区聊聊你的看法。

从冷启动到尾延迟：Go 与 Java 25 怎么选

Fhaohaizi — Mon, 20 Jul 2026 17:16:34 +0800

Java 方面，虚拟线程在 Java 21（2023 年 9 月）中成为正式特性。JDK 24 通过 JEP 491 修复了一个关键的固定（pinning）问题：synchronized 代码块曾让虚拟线程被固定在操作系统载体线程上。该修复也进入了 Java 25 LTS。Project Leyden 通过 JEP 483、514 和 515 在 JDK 24、25 中交付 AOT 缓存，直接瞄准 JVM 最常被批评的启动速度问题。

紧凑对象头（Compact Object Headers，JEP 519）将每个 Java 对象的头部开销降低了 33%。这不是小修小补，而是足以让一年前的基准结果失去参考价值的变化。

Go 方面，Go 1.23 完成了基于函数的 range 迭代器，补上了长期存在的易用性缺口。Go 1.24 引入 Swiss Tables 映射实现，在微基准中可让映射操作快至 60%，并在代表性负载下减少 2%~3% 的 CPU 开销。与 Java 25 同期发布的 Go 1.25 还引入实验性的 Green Tea 垃圾收集器，目标是改善容器高密度部署中日益突出的内存墙问题。

对比确实变了：Java 不再在所有部署规模上都明显输给 Go 的启动速度和内存占用；Go 也不再在简洁性和运维可预测性上毫无争议地领先。两者仍各有擅长的领域，只是边界已经移动。

各版本的新特性

Go 1.24（2025 年 2 月）

Swiss Tables 映射：新的内置 map 实现。大映射访问提升约 30%，预分配映射赋值提升约 35%，遍历速度视密度可提升 10%~60%。完整应用基准的 CPU 几何平均改进约为 1.5%。
Swiss Tables sync.Map：并发哈希树取代旧版 sync.Map。不同键的修改不再在大型映射上发生竞争，预热时间也被消除。
弱指针：weak.Pointer[T] 支持可被 GC 回收的引用，可用于构建不阻止对象回收的内存高效缓存。
泛型类型别名：类型别名现在可以参数化，补全了从 Go 1.18 开始的泛型能力。
CPU 开销降低 2%~3%：得益于 Swiss Tables、更高效的小对象分配和新的运行时内部互斥锁实现。
后量子密码学：ML-KEM（Kyber）通过 X25519MLKEM768 默认集成进 TLS。

Java 25 LTS（2025 年 9 月）

JEP 491：彻底解决虚拟线程在 synchronized 中被固定的问题。监视器追踪的是虚拟线程身份，不再是载体操作系统线程身份。
Project Leyden AOT 缓存（JEP 483、514、515）：Spring Boot 启动时间可缩短 50%~70%。JEP 515 为 AOT 缓存收集方法画像，相比 JDK 24 可将预热改善 15%~25%。
紧凑对象头（JEP 519）：对象头由 12 字节缩至 8 字节；对象密集型负载的堆占用可降低 10%~22%。使用 -XX:+UseCompactObjectHeaders 启用，但在 JDK 25 中与 ZGC 不兼容。
分代 Shenandoah（JEP 521）：Shenandoah 获得分代模式，可提升短生命周期对象负载的吞吐量，这也是 Java 微服务的典型模式。
作用域值（Scoped Values，JEP 506，正式版）：不可变、与作用域绑定的上下文传递机制，可在虚拟线程规模下替代 ThreadLocal。
结构化并发（Structured Concurrency，JEP 505，第 5 次预览）：将相关并发任务作为一个单元管理，减少直接使用 ExecutorService 时常见的线程泄漏问题。

基准方法与技术栈

文中的数字来自两类来源：BackendBytes.com 在 2026 年 4 月发布的真实工作负载基准，以及 Go、Java 官方发布说明和工程博客中的性能数据。前者使用带缓存、数据库和外部定价调用的商品目录 API，在 AWS Fargate 上以 500 个并发用户运行 10 分钟。

基准不是通用答案。下面的数字仅适用于这一特定的 I/O 密集型混合缓存负载。经过 JIT 优化并稳定运行的计算密集型 Java 服务，结果会完全不同。CPU 密集型负载更有利于 JVM JIT；对冷启动敏感的 Serverless 负载更有利于 Go。选型前仍应测试自身的实际负载；本文的数字更适合用来判断方向，而非追求虚假的精确度。

启动时间与预热

启动时间长期以来都是 Go 在容器化微服务中的决定性优势。这一优势仍在，但 Project Leyden 已显著缩小 Java 的差距。

2026 年的启动情况比 2022 年更复杂。标准 JVM Spring Boot 的启动仍大约比 Go 慢 20 倍：BackendBytes 基准中为 3.8 秒对 180 毫秒。但 Project Leyden 的 AOT 缓存可将标准 Spring Boot 的启动时间缩短约一半；Quarkus Native 可将 Java 编译成平台二进制文件，50~80 毫秒即可启动，在初始化路径复杂时甚至快于多数 Go 服务。

对 Kubernetes 部署而言，更实际的问题是 Pod 就绪时间而非原始启动时间。Go 的优势在于启动后立即达到峰值吞吐，而 JVM 大约需要 45 秒 JIT 编译才能达到全速。扩缩容频繁时，这段预热会直接影响新 Pod 的有效承载能力。JEP 515 的 AOT 方法画像让 Java 25 相比 JDK 24 缩短 15%~25% 的预热时间，但 JIT 预热并未消失，只是缩短了。

Kubernetes 中的内存占用

内存占用是 Go 优势最稳定、也最直接影响 Kubernetes 成本的地方。一项在 AWS Fargate 上、500 并发用户的商品目录 API 基准显示：500 RPS 时，Go 约占用 68 MB，JVM Java 约占用 412 MB，相差约 6 倍，直接影响单机 Pod 密度。

Pod 密度的差异会直接转化为基础设施成本。一份真实案例称，将高流量服务从 Java 迁到 Go 后，AWS 成本降低 60%，与同一实例规格下 Pod 密度提升 3~4 倍相符。优化后的 Java 镜像（Spring Native）约可缩至 50~60 MB，但标准 Spring Boot 镜像通常仍在 200 MB 以上；Go 的镜像体积则较稳定地处于 10~20 MB。

JEP 519 的紧凑对象头会明显改善 Java 的处境。它将每个对象头从 12 字节缩到 8 字节，对象密集型负载可少用 10%~22% 的堆内存，而且不需要改应用代码，只需一个 JVM 参数。不过，JDK 25 的 ZGC 与紧凑对象头不兼容；同时追求低延迟 GC 和紧凑对象头的团队，需要等待未来版本或改用 G1GC。

请求吞吐量与尾延迟

吞吐量是比较中最微妙、旧有认知最不可靠的维度。2026 年的结论是：对 I/O 密集型工作负载，两种运行时都有足够余量，瓶颈通常会是数据库或下游服务，而不是语言运行时。对于 CPU 密集型负载，Java 的 JIT 优势真实存在且日益突出。

Java 在尾延迟上的关键差异是：ZGC 可将暂停控制在 2 毫秒以内，但吞吐量可能比 G1GC 低约 5%~15%。如果 P99.9 延迟是 SLO，例如支付服务、实时 API 和延迟敏感的数据管道，这样的交换是合理的。没有仔细调整 GOMEMLIMIT 时，Go GC 无法提供等价的 2 毫秒以内暂停保障。对于严格的尾延迟要求，分代 ZGC 是 2026 年 Java 最有力的论据。

负载下的 GC 行为

垃圾收集是这两个运行时在运维体验上差异最大的一项，区别不在于优劣，而在于操作者需要做出的决策数量。

对于没有专职平台团队的团队，Go 的 GC 简洁性是实实在在的优势。只需两个环境变量即可配置。Go 1.19 引入并已广泛采用的 GOMEMLIMIT 可设置软内存上限，避免 OOM Kill，且不需要精确设定堆大小；Java 的 -Xmx 只能限制堆，不能限制 JVM 总 RSS。

如果容器部署中 OOM Kill 是真实运维风险，Go 默认的内存管理体验会更好。但 Java 的 GC 灵活性在特定场景同样是优势。文中认为，Java 25 的分代 ZGC 是生产级 JVM 或 Go 运行时中暂停时间最出色的 GC，可在重负载下实现 2 毫秒以内暂停。Netflix 在 Java 21 中切换至分代 ZGC 后，报告称 GC 暂停几乎消失，且因消除了 GC 相关超时而降低了错误率。Go 的 GC 配置难以在不借助外部限流的情况下获得同等的尾延迟可预测性。

并发模型：Goroutine 与虚拟线程

网上仍大量流传 Go goroutine 对 Java 线程的旧叙事，但它早于虚拟线程，需要在 2026 年彻底更新。

Go 与 Java 的并发差距在 2026 年确实比 2022 年小得多。JDK 24 的 JEP 491 修复了 synchronized 代码块的固定问题，虚拟线程可进入同步块、执行 I/O，并从载体线程卸载而不被固定。实现方式是将 JVM 监视器所有权从操作系统线程身份改为虚拟线程身份。

JDK 25 中正式版的作用域值取代了 ThreadLocal 的反模式，后者会在高虚拟线程并发下造成隐蔽的内存压力。

Go 依然拥有的优势是：goroutine 自 2009 年起就存在，标准库和生态都围绕它构建。channel、select 和 context 包构成了连贯而原生的并发模型。虚拟线程虽已成熟，但仍是建立在一个拥有数十年操作系统线程假设的语言之上的能力，尚未达到同样的原生感。

对于新服务，两种模型都可行；而对于已有 Go 代码库的团队，并发本身通常不足以证明迁移成本合理。

结论

适合选择 Go 1.24

需要稳定、低内存占用：API 网关、边缘服务、Sidecar，且 Pod 密度会显著影响成本。
启动时间是硬约束：FaaS／Serverless、大量使用竞价实例、扩缩容后必须立即达到峰值吞吐的服务。
构建基础设施工具、CLI 或 Kubernetes Operator：Go 是这些领域的行业默认选择。
希望尽量缩小运维面：两个 GC 调节项、静态二进制文件，无 JVM 需要配置或更新。
服务主要负责高效转发数据，业务逻辑简单，且需要保持容器足够小。
希望开发中构建周期低于 10 毫秒，并以零依赖二进制文件分发。

适合选择 Java 25

业务逻辑复杂，涉及领域建模、丰富校验和企业集成模式，Spring Boot 与 Java 生态的深度能够带来收益。
P99.9 尾延迟是 SLO：分代 ZGC 的 2 毫秒以内暂停，是 Go 配置在不借助外部限流时难以匹配的能力。
构建 AI 驱动服务：Spring AI、MCP SDK 与 LangChain4j 的成熟度暂无等价的 Go 方案。
堆大小超过 50 GB：JIT 优化优势会随堆规模增大而累积。
需要深入的可观测性：JFR、JDK Mission Control 和 Spring Actuator 在生产诊断上很难替代。
团队已经熟悉生态：切换语言带来的约 6 个月生产力成本通常不值得承担。

2026 年，大规模组织通常会同时使用两者：Go 用于基础设施层、API 网关和高密度低业务逻辑服务；Java 用于领域服务、AI 集成及需要依赖 Spring 生态深度的工作负载。这不是摇摆不定，而是针对同一服务集群中不同问题采用合适语言的多语言架构。

总结

2026 年 Go 与 Java 微服务的现状，最适合概括为：差距在缩小，优势领域在变得更清晰。Go 在启动时间和内存占用上的领先仍真实且持续存在：首个请求 180 毫秒对 3.8 秒、500 RPS 时 68 MB 对 412 MB、同一实例上 18 个 Pod 对 5 个 Pod。Java 25 不会抹平这些数字；不过，愿意维护训练运行的团队可借助 Project Leyden AOT 缓存将启动差距缩小约一半，紧凑对象头也可降低 10%~22% 的堆占用。

Go 的运维简洁性依然是没有专职平台团队时的真正优势：两个 GC 调节项、静态二进制文件，以及用于防止 OOM 的 GOMEMLIMIT。

Java 在尾延迟上的优势同样真实，而且愈发重要。分代 ZGC 的 2 毫秒以内暂停、JEP 491 对虚拟线程固定问题的修复，以及作用域值对 ThreadLocal 反模式的弥补，让 Java 25 成为高并发微服务中最强的 Java 版本之一。对于稳态运行的 CPU 密集型负载，JIT 优势可被量化，Go 目前的 GC 改进难以弥补。

生态深度，特别是 AI 集成、企业领域建模和生产可观测性，仍然在相关场景中构成决定性优势。

应依据团队知识、工作负载特征和运维约束做选择，而不是依据与自身业务无关的基准。13% 的吞吐量差异，永远不足以抵消高级工程师约 6 个月的生产力损失。Go 与 Java 在 2026 年都是优秀选择；真正的问题不是哪个更好，而是哪个更适合今天要构建的这项服务。

相关阅读

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

新兴岗位，FDE--前线部署工程师，测试是不是可以转行做这个

woshizh — Mon, 20 Jul 2026 15:58:03 +0800

最近总刷到一个新兴岗位，FDE，测试能不能转行做这个，国内关于这个岗位的招聘多吗

原文：https://zhuanlan.zhihu.com/p/2049257483059910488

设计一个多 Agent 的 UI 自动化测试工程（一）基础原理

ycwdaaaa — Mon, 20 Jul 2026 11:45:06 +0800

开篇

上一篇介绍了多 Agent 协作的相关内容，今天我们来实战一下如何用这个理念来设计一个 AI 驱动的 UI 自动化测试工程。

AI 驱动 UI 自动化的模式

在我这里 AI 驱动 UI 自动化有两种模式，分别是：

AI 驱动编写 UI 自动化测试脚本，而不是由人类编写脚本。这个依赖于我们对于多 Agent 的构建以及 Skill 的编写。
执行 UI 自动化的时候，UI 控件的定位由模型来完成（通过计算机视觉，也就是运行期间动态截图，然后发送给多模态大模型，我们描述这个控件长什么样子，大模型则根据我们的描述和截图识别出控件的具体位置）。这个依赖于相关框架，我这里使用的是 midsence。相关的原理我写过文章，可以参考我写的帖子：Midscene 视觉定位与交互机制深度解析：https://testerhome.com/articles/44376

而今天我们要讲解的就是第一种，怎么编写一个稳定可靠的多 Agent 协作的 Skill 来完成我们的代码编写工作。当前这里也补充一下第二种模式的基本概念，以免有对 midsence 还不了解的同学看了以后蒙圈。

什么是多模态大模型

所谓单模态就是只能接受一种格式的数据，比如文本。而多模态则是可以接受不同的数据格式，我们可以在一次对话中给大模型输入图片和文字。比如上传一张图片，然后配上一段文字：“请问图片中蓝色的名字叫提交的按钮在什么位置。” 这时候多模态大模型就可以根据你的文字描述和图片数据找到这个按钮并回答用户。这就是通过视觉方案来定位 UI 控件的原理。

AI 识别控件的背景下要如何编码

点击操作：

await this.getAgent().aiTap('在「添加用户」弹窗底部右侧的「确定」按钮');
await this.getAgent().aiTap('「添加 Agent」弹窗中的「新建」按钮或链接');
await this.getAgent().aiTap('搜索框右侧的放大镜图标按钮');

input的输入操作


// 编辑场景：清空旧值并输入新值（默认 replace 模式，自动先清空）
await this.getAgent().aiInput("标题输入框", { value: newTitle });

// 搜索框输入
await this.getAgent().aiInput("搜索框", { value: keyword });

aiKeyboardPress() — 按键

await this.getAgent().aiKeyboardPress('搜索框', { keyName: 'Enter' });
await this.getAgent().aiKeyboardPress('任意位置', { keyName: 'Escape' });

aiHover() — 悬停

await this.getAgent().aiHover('工具行右侧的「···」按钮');

aiDoubleClick() — 双击

await this.getAgent().aiDoubleClick('文件名称');

以往很多刚入门的同学会困惑， AI 是可以编写代码，但 AI 怎么知道浏览器中这些控件的定位方式是什么？也就是说，它怎么知道 xpath 怎么写？如果大家用了 midsence 这样的基于视觉的框架就明白了，现在的 UI 定位不用依靠 xpath，而是我们人类去用文字描述对应控件在什么位置。

让 AI 写代码的提示词

所以基于以上的基础内容，我们就可以让 AI 编写代码的时候，跟它说这样一段话：

1. 创建Agent模式应用
2. 点击 页面左上角的 应用名称 左边的 图标，弹出 编辑应用弹窗
3. 在应用名称中 输入一个新的 名字
4. 点击 确定按钮
5. 验证页面应用名字被修改成新的名字了

我们来看这段提示词：

第 2,3,4 步，我们在提示词中已经描述了要做的操作，和对应的控件在什么位置以及长什么样子。这样 AI 就可以把代码编写成我们上面说道的 midsence 的 API 代码。包括 aiTap 的点击操作，以及 aiInput 的输入操作。
第 1 步，可能有同学会困惑在第一步我们可没有告诉 AI 具体的控件操作步骤和位置，只是用一句很简单的创建应用就完事了，而这个创建应用可能包括了 N 个操作。AI 是怎么知道要怎么写的？这就涉及到我们之前讲到的知识库了，即便用户没有刻意的构造知识库，但我们说过，当前项目中的每一个代码文件都会被 AI 辅助工具 embedding 并保存到向量数据库中（没有这个机制的也会用 rgrep 去检索）。所以只要你编写过一次创建 Agent 应用的代码，并在方法名称，代码注释等地方说明过这就是在创建应用。那么大模型就能检索到，所以再写第二次的时候，就不用每一个步骤都写的那么详细了，表明基本意图后大模型会自行推理和检索到相关代码。也就是： 编写用例的时候，只有新的操作和控件需要编写很细节的步骤和定位方法
第五步，这样写 AI 会参考 midsence 的 API，自动转换成断言 API 的。而这个断言 API 模型是怎么知道的呢？当然是我们有对应的 API 文档了。比如下面那个是我总结的 API 文档。

# Midscene API 参考

> 来源：https://midscenejs.com/zh/api.html + https://midscenejs.com/zh/web-api-reference  
> 本项目使用 **PlaywrightAgent**，通过 `this.getAgent()` 获取实例。

---

## 🚨 方法选择强制规则

> **编写任何 aiFallback 前，必须先按优先级顺序检查本文档，使用已定义的即时操作方法。`aiAction` 是最后手段。**

**优先级从高到低：**

| 优先级 | 操作类型 | 必须使用的方法 |
|--------|---------|--------------|
| 1 | 输入文本（input/textarea） | `aiInput(locate, { value })` |
| 2 | 点击按钮/链接/标签 | `aiTap(locate)` |
| 3 | 滚动页面/容器 | `aiScroll(locate, opt)` |
| 4 | 按键盘键 | `aiKeyboardPress(locate, { keyName })` |
| 5 | 悬停 | `aiHover(locate)` |
| 6 | 双击 | `aiDoubleClick(locate)` |
| 7 | 提取数据 | `aiQuery()` / `aiBoolean()` / `aiString()` / `aiNumber()` |
| 8 | 断言/等待 | `aiAssert()` / `aiWaitFor()` |
| **最后** | **上述方法无法覆盖的复合多步骤操作** | **`aiAction()`** |

> ❌ **禁止行为：**
> - 能用 `aiTap()` 点击的，不得用 `aiAction("点击XXX")`
> - 能用 `aiInput()` 输入的，不得用 `aiAction("在XXX输入框输入YYY")`
> - 能用 `aiScroll()` 滚动的，不得用 `aiAction("向下滚动")`
> - 不存在的方法（如 `aiClearInput`）一律禁止，改用对应的即时操作方法

---

## 核心概念

| 类型 | 代表方法 | 特点 |
|------|---------|------|
| **自动规划** | `aiAction()` / `aiAct()` / `ai()` | AI 自动拆解步骤执行，**最后手段** |
| **即时操作** | `aiTap()` / `aiInput()` 等 | AI 只负责元素定位，直接执行指定操作，**更快更可靠，优先使用** |
| **数据提取** | `aiQuery()` / `aiBoolean()` 等 | 从页面提取结构化数据 |
| **断言等待** | `aiAssert()` / `aiWaitFor()` | 验证页面状态 |

> ⚡ **选型规则：优先即时操作，`aiAction` 是最后手段**
> - 点击单个元素 → `aiTap()`（**禁止**用 `aiAction()`）
> - 输入文本 → `aiInput()`（**禁止**用 `aiAction()`）
> - 滚动 → `aiScroll()`（**禁止**用 `aiAction()`）
> - 只有上述方法都无法完成时，才允许使用 `aiAction()`

---

## 一、自动规划方法

### `aiAction()` / `aiAct()` / `ai()`

> 三者等价，`aiAction()` 为旧版写法，本项目代码中均有使用


await this.getAgent().aiAction('在搜索框中输入 "JavaScript"，然后点击搜索按钮');
await this.getAgent().aiAct('填写表单并提交');


**签名：**

function aiAction(
  prompt: string,
  options?: {
    cacheable?: boolean;      // 默认 true，是否允许缓存
    deepThink?: 'unset' | true | false;  // 规划阶段深度思考，默认 'unset'
    deepLocate?: boolean;     // 是否开启深度定位，默认 false
    abortSignal?: AbortSignal;
  }
): Promise<void>;


**何时用（最后手段）：**
- **仅当本文档中的即时操作方法（`aiTap`、`aiInput`、`aiScroll` 等）均无法覆盖时**，才允许使用
- 典型合法场景：需要同时完成"输入 + 按回车搜索"且无法拆分的连贯操作
- 典型非法场景：点击按钮（用 `aiTap`）、输入文本（用 `aiInput`）、滚动（用 `aiScroll`）

---

## 二、即时操作方法（推荐优先使用）

### `aiTap()` — 点击元素


await this.getAgent().aiTap('页面顶部的登录按钮');
await this.getAgent().aiTap('「提交」按钮', { deepLocate: true });


**签名：**

function aiTap(
  locate: string | Object,
  options?: {
    deepLocate?: boolean;   // 默认 false，小元素时开启
    xpath?: string;          // 优先用 xpath 定位
    cacheable?: boolean;     // 默认 true
  }
): Promise<void>;


**定位描述写法要求：**

| 要素 | 示例 |
|------|------|
| 容器上下文 | `"在「添加用户」弹窗中"` |
| 视觉位置 | `"底部右侧的"` |
| 元素文案 | `"「确定」按钮"` |
| 元素类型 | `"按钮"、"输入框"、"下拉框"` |

完整示例：

await this.getAgent().aiTap('在「添加用户」弹窗底部右侧的「确定」按钮');
await this.getAgent().aiTap('「添加 Agent」弹窗中的「新建」按钮或链接');
await this.getAgent().aiTap('搜索框右侧的放大镜图标按钮');


---

### `aiInput()` — 输入文本（**所有输入框操作必须使用此方法**）

> 🚨 **强制规范：所有 input/textarea 输入操作，包括新建和编辑场景，统一使用 `aiInput()`，禁止使用 `aiAction()` 或其他方式处理输入。**


// 新建场景：在标题输入框中输入
await this.getAgent().aiInput("标题输入框", { value: title });

// 编辑场景：清空旧值并输入新值（默认 replace 模式，自动先清空）
await this.getAgent().aiInput("标题输入框", { value: newTitle });

// 搜索框输入
await this.getAgent().aiInput("搜索框", { value: keyword });


**签名：**

function aiInput(
  locate: string | Object,
  opt: {
    value: string | number;          // 必填
    mode?: 'replace' | 'clear' | 'typeOnly';  // 默认 'replace'（先清空再输入）
    deepLocate?: boolean;
    xpath?: string;
    cacheable?: boolean;
  }
): Promise<void>;


**mode 说明：**
- `'replace'`（默认，**始终使用此默认值**）：先清空输入框，再输入新值。适用于新建和编辑场景
- `'typeOnly'`：直接追加，不清空。仅在明确需要追加内容时使用
- `'clear'`：仅清空，不输入

---

### `aiScroll()` — 滚动


// 在弹窗内向下滚动
await this.getAgent().aiScroll('「添加 Agent」弹窗内容区域', {
  direction: 'down',
  distance: 300,
});

// 滚动到底部
await this.getAgent().aiScroll('表单区域', { scrollType: 'scrollToBottom' });


**签名：**

function aiScroll(
  locate: string | Object | undefined,
  opt: {
    scrollType?: 'singleAction' | 'scrollToBottom' | 'scrollToTop' | 'scrollToRight' | 'scrollToLeft';
    direction?: 'down' | 'up' | 'left' | 'right';  // 默认 'down'
    distance?: number | null;  // 滚动像素，null = AI 自动决定
    deepLocate?: boolean;
    xpath?: string;
    cacheable?: boolean;
  }
): Promise<void>;


> ⚠️ **弹窗内滚动注意事项：**  
> 弹窗有独立滚动容器，必须明确指定定位到弹窗内部区域，如：  
> `'「添加 Agent」弹窗内容区域'` 而非 `undefined`（否则会滚动主页面）

---

### `aiKeyboardPress()` — 按键


await this.getAgent().aiKeyboardPress('搜索框', { keyName: 'Enter' });
await this.getAgent().aiKeyboardPress('任意位置', { keyName: 'Escape' });


> ⚠️ 不支持组合键（如 Ctrl+A）

---

### `aiHover()` — 悬停


await this.getAgent().aiHover('工具行右侧的「···」按钮');


---

### `aiDoubleClick()` — 双击


await this.getAgent().aiDoubleClick('文件名称');


---

## 三、数据提取方法

### `aiQuery<T>()` — 结构化数据提取


// 提取对象
const data = await this.getAgent().aiQuery<{ hasResults: boolean }>(
  '搜索结果列表是否有数据？返回 { hasResults: true } 或 { hasResults: false }',
  { cacheable: false }  // 页面动态变化时关闭缓存
);

// 提取数组
const options = await this.getAgent().aiQuery<string[]>(
  'string[], 当前可见的 Agent 类型选项文案列表'
);


**签名：**

function aiQuery<T>(
  dataDemand: string | Object,
  options?: {
    domIncluded?: boolean | 'visible-only';  // 是否包含 DOM 信息，默认 false
    screenshotIncluded?: boolean;             // 是否包含截图，默认 true
    cacheable?: boolean;                      // 默认 true
  }
): Promise<T>;


> ⚠️ **cacheable 注意：** 若页面状态在上次调用后发生了变化（如搜索结果已更新），必须设置 `cacheable: false`

---

### `aiBoolean()` / `aiNumber()` / `aiString()` — 便捷提取


const hasDialog = await this.getAgent().aiBoolean('是否存在登录对话框');
const count = await this.getAgent().aiNumber('当前搜索结果条数');
const title = await this.getAgent().aiString('当前页面标题');


---

## 四、断言与等待方法

### `aiAssert()` — 断言


await this.getAgent().aiAssert('搜索结果列表中至少有一条记录');


> 💡 **更可靠的替代写法：** 用 `aiQuery` + `expect` 替代 `aiAssert`（降低 AI 幻觉风险）

---

### `aiWaitFor()` — 等待条件成立


await this.getAgent().aiWaitFor('搜索结果列表变得可见', {
  timeoutMs: 15000,       // 默认 15000ms
  checkIntervalMs: 3000,  // 默认 3000ms
});


> ⚠️ 每次检查都调用 AI，成本较高，简单等待场景用 `await this.wait(ms)` 替代

---

## 五、本项目 withFallback 模式规范

Page 层所有 DOM 操作必须使用 `withFallback`：

### AI-Only 模板（首次实现必须使用）


async clickXxx() {
  await this.withFallback({
    label: 'clickXxx()',
    cssAction: async () => false,    // ← 必须是 false
    aiFallback: async () => {
      await this.getAgent().aiTap('[容器]中的[文案][元素类型]');
    },
    aiOnly: true,                    // ← 必须有
  });
  await this.wait(500);
}


### CSS-First 模板（通过探针验证后使用）


async clickYyy() {
  await this.withFallback({
    label: 'clickYyy()',
    cssAction: async () => {
      return await this.page.evaluate(() => {
        const btn = document.querySelector('button.xxx') as HTMLButtonElement | null;
        if (btn && !btn.disabled) { btn.click(); return true; }
        return false;
      });
    },
    aiFallback: async () => {
      await this.getAgent().aiTap('...');
    },
  });
  await this.wait(500);
}


---

## 六、常见场景写法参考

### 场景：弹窗内滚动并操作


// ✅ 正确：明确指定弹窗容器
await this.getAgent().aiScroll('「添加 Agent」弹窗的内容滚动区域', {
  direction: 'down',
  distance: 300,
});

// ❌ 错误：会滚动主页面而非弹窗
await this.page.evaluate(() => window.scrollBy(0, 300));


### 场景：先输入再搜索


// ✅ 正确：拆分为输入 + 点击两步（aiInput 处理输入，aiTap 处理点击）
await this.getAgent().aiInput('搜索插件输入框', { value: keyword });
await this.getAgent().aiTap('搜索框右侧的放大镜按钮');


### 场景：新建/编辑时填写表单输入框


// ✅ 正确：统一使用 aiInput，默认 replace 模式（自动清空旧值再输入）
await this.getAgent().aiInput("标题输入框", { value: title });
await this.getAgent().aiInput("概述输入框", { value: overview });
await this.getAgent().aiInput("搜索框", { value: keyword });

// ✅ 编辑场景同样使用 aiInput，无需额外清空步骤
await this.getAgent().aiInput("标题输入框", { value: newTitle });

// ❌ 禁止：用 aiAction 处理输入框输入（应拆分用 aiInput）
// await this.getAgent().aiAction(`在"标题"输入框中输入 "${title}"`);

如何初始化这个 UI 自动化工程

讲完了原理，我们看要如何初始化这个工程。我们可以使用我一直推荐的 superpowers，也可以直接跟 AI 做普通对话：

请使用 superpowers 工作流，为一个全新的 UI 自动化工程做脚手架初始化。
目标：用 Midscene.js + Playwright + vitest 搭建一套 AI 视觉驱动的 UI 自动化测试工程，
并且严格遵循我现有项目的四层架构（component → page → service → case）。

【技术栈与依赖】
- 测试框架：vitest（不是 @playwright/test）
- 浏览器驱动：playwright + @midscene/web（Midscene Playwright 集成）
- 报告：allure-js-commons + midscene HTML 报告
- 配置加载：dotenv（解决 worker 进程读不到 .env 的坑）
依赖：@playwright/test、@midscene/web、playwright、vitest、allure-js-commons、dotenv

【四层架构与目录结构】
src/
├── components/          # 组件层：可复用 UI 控件原子操作（如 Button/Input/Select/Alert）
├── pages/               # 页面层：单页面操作封装（子类继承 BasePage）
├── services/            # 服务层：跨页面业务流程编排（Mixin 模式）
├── fixtures/            # fixture：浏览器/context/page/共享 agent 生命周期
├── setup/               # 登录态 / cookie 初始化
├── utils/               # 基建：midscene-agent、with-fallback、click-by-marker
├── tests/               # 用例层：测试 + 断言（*.test.ts）
├── config.ts            # createBrowser / BASE_URL 等
└── midsence.md          # 架构说明文档

【各层职责边界（强制）】
| 层 | 职责 | 禁止 |
|---|---|---|
| components | UI 控件原子操作封装 | 不得依赖 pages/services |
| pages | 单页面操作组合 | 不得跨页面、不得写 expect/断言 |
| services | 跨页面完整流程编排 | 不直接操作 DOM、不写断言 |
| tests(case) | 业务编排 + 断言 | 不得直接 new XxxPage()/new XxxService()，统一通过 fixture 注入 |

【基类契约（必须实现）】
1. BaseComponent：接收 page，提供 getAgent()（复用 utils/midscene-agent 的 createPlaywrightAgent），
   内部用统一 withFallback({label, cssAction, aiFallback, aiOnly}) 模式（CSS 优先、AI 兜底）。
2. BasePage（abstract）：接收 page；this.getAgent() 懒加载；
   核心方法 withFallback(...) 委托 utils/with-fallback 的 runWithFallback（记录 stdout + JSONL 日志）；
   子类声明 abstract readonly url，提供 goto() 等待策略；内置 wait(ms)。
3. BaseService：接收 page，public readonly page 字段；this.step(name, action) 记录 Allure；
   getAgent() 懒加载复用共享 agent；wait(ms)。
4. 服务层使用 TypeScript Mixin 模式：先声明 interface XxxMixinMethods（方法签名），
   再用 class XxxMixed 实现，service 主类通过交叉类型组合；
   对外暴露的方法用 this.step() 包裹并调用 page/service 实例。

【Midscene 关键约定】
- agent 统一用 createPlaywrightAgent(page) 创建（utils 内做 WeakMap 共享注册，
  保证一条 case 内 page/service/component 共用同一 agent → 一份 midscene HTML）。
- 方法优先传统定位（locator），仅在无稳定属性/图标/复杂控件时用 AI：
  aiTap('描述')、aiInput('描述',{value})、aiQuery('描述')、aiAssert('描述')、aiAction('合并多步')。
- 定位优先级：id > name > type > 语义 class > 文案 > AI 视觉（AI 有 token 成本，谨慎用）。

【基建文件清单（初始化时必须产出）】
- src/config.ts：createBrowser()、BASE_URL、APP_URL
- src/utils/midscene-agent.ts：createPlaywrightAgent / createSharedAgent / setSharedAgent（WeakMap 共享 + 注入 vitest case 名到 groupName）
- src/utils/with-fallback.ts：runWithFallback（CSS 优先→AI 兜底，事件写 test-results/fallback-events.log JSONL）
- src/utils/click-by-marker.ts：clickByMarker 代理
- src/fixtures/playwright.fixture.ts：usePlaywright() / usePlaywrightWithAuth()，beforeEach 创建浏览器+page+共享 agent，afterEach 截图+清理
- src/setup/*：加载 .env（dotenv.config 带 path/override），登录态/cookie 注入
- .env.example：MIDSCENE_MODEL_BASE_URL / API_KEY / MODEL_NAME / MODEL_FAMILY 模板，注明 worker 进程需每文件 import setup
- vitest.config.ts：testDir=src/tests、timeout 设长（AI 推理慢）、reporter 含 allure
- package.json scripts：test / test:ui / report

【命名与目录约定】
- 组件：XxxComponent（如 ButtonComponent）；页面：XxxPage / XxxDialog（弹窗也归 pages）；
  服务：XxxService，Mixin 拆为 XxxServiceXxxMixin.ts + 目录 index；
  用例：<场景>.test.ts，按模块分子目录（如 tests/<模块>/）。
- 每个 pages/services 子目录提供 index.ts 统一导出；方法名语义化（动词开头：clickXxx / fillXxx / verifyXxx）。

【交付物要求】
1. 完整可运行的脚手架（上面所有文件）。
2. 一个"四层贯通"的冒烟示例：以被测系统首页的一个简单操作（如打开某弹窗→输入→确定→断言）
   为例，分别实现：1 个 ButtonComponent、1 个 HomePage、1 个 XxxService（含 Mixin），
   1 个 tests 用例调用 fixture 注入的 page/service 完成断言。
3. README 简述四层职责、withFallback 用法、如何新增一个页面/服务/用例。
4. 初始化完成后，运行该冒烟用例确认能跑通（AI 兜底链路可用）。

【约束】
- 只搭建脚手架与示例，不要大批量生成业务页面/用例。
- 保持零业务耦合，示例用占位文案与可配置 URL。
- 所有 AI 定位描述要精确（缩小范围省 token），稳定元素一律传统定位。

用我这样的一段提示词，就可以按照 UI 自动化的 4 层架构（如果对 UI 自动化 4 层架构还不了解的同学，可以搜一下我之前的帖子）和技术要求初始化我们的代码了。当然各位同学也可以按自己的需求修改，或者也不用这么复杂和细节，就按自己的要求写一个简单的提示词去初始化也可以。（毕竟我这个对于初始化的要求太细节了）

结尾

以上就是 AI 驱动 UI 自动化的基本原理，当然有这个基本原理还是没办法稳定高效的来生成代码的，我们还需要编写多 Agent 的 skill，这个我们下期介绍哈。

这里再宣传下自己的星球：

聊聊 AI 的可信度

dylan.zhang — Mon, 20 Jul 2026 10:22:48 +0800

这是鼎叔的第一百四十三篇原创文章。行业大牛和刚毕业的小白，都可以进来聊聊。
欢迎关注公众号《敏捷测试转型》，星标收藏，大量原创思考文章陆续推出。
今年第一篇文章，聊聊 AI 是否值得被信任，评估 AI 可信度的框架应该是什么样的。
有一些通用 AI 的拦路虎依然没有办法解决，有一些几年前被认为不可能解决的毛病已经被解决。在大模型不断狂飙的今天，有技术元老认为存在无法突破的瓶颈，必须引入世界模型和常识。

部分观点参考 Building AI We Can Trust,作者 Gary Marcus 和 Ernest Davis。

媒体里的 AI 报道可信么
新闻媒体总是把 AI 产品的每一次小成绩描绘成天翻覆地的历史性突破，导致普通民众过高估计 AI 的实际能力，从而产生被放大的焦虑感。
即使数据越来越充裕，AI 回答效果越来越惊艳，我们还是要认清现实，即繁荣背后有很多本质的东西缺失了，导致机器无法和人相提并论。

现代大模型训练路径和人类成长思维路径是不同的，人不是随机鹦鹉，也不只是死记硬背，而是有自己的个性、生活常识、自驱力、价值观、世界观和道德标准。人可以对自己的决策负责，通过创造力和想象力来改变世界，这种自我超越和自我牺牲的精神也是 AI 没有的。
人比 AI 做得差的地方，如情绪化、不稳定、速度慢、主观性，但这些真的就是缺点么？
不一定，这种真实的人性可能更受用户欢迎。也许在 AI 作品充斥世界的时代，真人个性化作品可能会受到更大追捧。
特定领域内的狭义 AI 即使很出色（比如围棋），我们也很难信任这样的系统去接管安全相关领域。开放世界中的 AI 机器人会遇到无限种可能，但狭义 AI 无法穷尽各种异常的处理（参见文章聊聊具身智能）。
阻止 AI 摘取赢得人类信任的主要原因，是一直以来人们都是从自己的认知来看待机器的 “思维”，完美而清晰的模拟数据就不可能获得。人类顾客给 AI 买单时，对错误的容忍度也会随着规模化应用而越来越低。

AI 的主要风险
对于 AlphaGo 或绝艺这样的围棋 AI，棋盘以外的世界它毫不关心。但是拥有强大体力的机器人，还是容易对外部酿成灾难的。

机器人的主人如果刻意或含糊其辞发出进攻型指令，主人自己或者身边的人可能会遭殃。

我们再具体想想，除了鲁棒性和通用性不足，AI 还存在哪些风险?
一，盲目依赖过去的数据进行训练，会导致偏见长期存在，比如生成成功人士的刻板形象。如果我们把有偏见的 AI 用于医疗，就可能导致输出的答案只适用于特定人群。

二，AI 用其他 AI 生产的数据来训练，产生严重的回音效应，并导致一个 AI 犯下的错误会被传播。
三，有些 AI 依赖于公众可任意操纵的数据。只要某个群体合谋捣乱，就能制造各种荒缪的网络误导。
四，目标陷阱。AI 经常是看重目标的表面达成，而无法理解实际需要获取的价值。
比如工程师鼓励足球机器人 AI“尽可能多地触碰足球”，就会发生机器人在球边快速抖腿的窘境。

给机器人看抓取物体的图片，机器人可能会误以为把机械手放在镜头和物体之间的位置即可，这样看起来目标就达成了。
还有些 AI 可能崇尚无为而治，每次无脑预测同一个大概率结果，可能比使用各种风险预测模型命中率更高，但这还是用户需要的效果么？

总结一下，AI 生成内容在整体上呈现 “通用场景可用，专业场景需谨慎评估” 的效果。
大模型训练主要基于概率生成而非事实推理，很容易导致幻觉或被恶意投毒，训练数据实效性滞后，因此难以覆盖前沿领域或新兴概念。当训练数据存在矛盾时，AI 更可能强行将输出进行合理化解读。
从研究数据来看，AI 工具每十个断言就有 1-2 个是无法验证，甚至凭空捏造的。
未来大模型公司如果能够训练 AI 自动进行多信源查证，提高权威信源权重，AI 在判断谣言这块的能力有望大幅增强。

深度学习面对的问题
深度学习比任何一门机器学习技术都要强大得多，但人们对它还是寄予了过高期望。
深度学习对数据是贪婪的，如果获取的数据量减少，它的表现水平会急转直下。
围棋这种规则千年不变的领域非常适合深度学习一展身手，但许多真实世界问题的相关数据是不足的。
深度学习的黑箱性质，导致我们很难教会它正确的思考。就好像我们使用强大的商业工具，不如使用可以修改的开源工具那么灵活。
因为常识的缺乏，可用于愚弄深度网络的方法越来越多，对于某些商业领域的 AI 服务，这是不可承受的风险。“深度” 仅仅指层数，并不意味着系统能领会所见数据中的丰富概念。稍微加入一点噪音，深度学习系统可能就会无法使用，脆弱性可见一斑。
相较而言，人类的视觉系统、语言系统和常识，天然就自带鲁棒性。
深度学习更像一门艺术，而非科学。系统内存的优化调整，有时轻而易举，有时难以登天。缺乏真实智能需要的灵活性和适应性，就像航天界的名言:爬上再高的大树，也无法抵达月球。

以阅读为例
深度学习的阅读障碍，来自于它关注的是相关性而不是真正理解，提问方式稍加改变，就会得到完全不同的结果。AI 在推理链条上处理能力不足，源于缺乏对这个世界基本运作规律的把握力，这就是人们已有的共识知识（常识）。很多时候常识是优先于文本出现的概率的，但要想把常识全提炼出来对于工程团队来说太困难了。
在高潜力的商业化 AI 应用中，理解非结构化文本是一个瓶颈。如病历、财务报表、科学论文等。
对长篇小说而言，人会在脑海中形成人物的形象和复杂的情感关系，AI 对此不感兴趣。AI 甚至听不出简单台词（如 “不!”）背后的角色意图。
人类语言充满了模糊性，存在很多的多义词，但人在上下文阅读时不会注意到这些。

以机器人为例
前文说过，机器人远没有演示场景中那么让人信任。
机器人需要对五大特征进行正确理解才能做到可控: 我在什么地方，周围环境在发生什么，现在我要做什么，该如何制定计划，如何行动才能确保最终目标达成。
每个问题的计算都很艰难，涉及多个尖端能力的突破:定位技术，运动控制，态势感知（预测风险），行动决策。
现实世界的偶发事件太多，各种可能性构成的空间无比巨大。丰富的认知模型和深度理解力才是关键，这是让 AI 能真正阅读的前提。

如何做到可信 - 从人类认知科学找答案
机器无需重复犯下影响人类思想的众多错误，无需继承人类的能力缺憾。认知科学给 AI 发展能带来不少重大启示:
一没有银弹
不要只想着用很简单的奖励模型训练出通用人工智能，有可能通用人工智能的复杂性和人脑是一个水平。
二心智模型
之前的文章聊过，人是学习成长是因为形成了强大的心智内部表征，聊聊刻意练习 - 构建心理表征。
AI 没有建立这种表征，就不可能有丰富的认知。比如让 AI 玩游戏，它就需要先理解游戏中核心部件的概念。
基于少量输入对核心表征进行创造和扩展，才能获取通用人工智能的灵活性。
心智是由多个系统组成的高度结构化系统，比如聊聊《思考，快与慢》提到的快系统和慢系统。
三把概念嵌入理论
通用人工智能需要把获得的知识嵌入到更加丰富的理论当中，才能够把不同的事实组合起来。
四因果关系
没有因果推理，我们就无法对这个世界进行理解。如果机器能做到因果关系的正确推理，将是一项伟大的成就。
五 AI 以类别为重点，而非以个体为重点
对于个体消费者而言，更希望自己的特征和独有需求被关注到。
六先天还是后天，很难区分
生物学证据告诉我们，先天拥有和后天学习不是互为对立面的。类似，人工智能很难判断什么知识应该内置，并以此为起点，判断什么知识需要通过训练来掌握。

如何建立常识库
通过爬虫学习常识是最广泛的做法，但很多事实是互相矛盾，或者太过杂乱。
另一种方法是让普通人众包搜集常识。有时结果令人失望，因为列出的事实太过显而易见。就算众包能给出正确的消息，其格式也很难精准。
常识仍然是整个行业难以攀登的高山。我们要找到机器对知识进行表征的清晰手段，可以借助分类学、语义网络和形式逻辑进行梳理。但是，机器还不能脱离人类帮忙，最后得到的可能是一碗 “事实大杂烩”，尤其考虑时间维度，结果会更糟糕。
要理解世界是如何运转的，远比创造出逼真图像要复杂得多。游戏物理引擎可以有效生成正在发生的事情和互动，但我们无法从原子级别去模拟所有事物。
为了实现通用人工智能，首先要开发出能够表征人类知识核心系统的框架，包括时间、空间、因果关系、物理对象及其互动，人类及其互动等等知识，这才是深度理解。
从鼎叔的老本行来思考，人工智能在质量上的追求还远远不够，它算出个大概就行，缺乏失效保护机制，在很多行业会带来灾难。这也许是新时代测试工程师的机会。

未来的可信 AI

深度学习在很多方面不像传统计算机编程，而更像是药理学，目前还没有如何打造 “可解释的 AI” 的明确成果，无法让人们像信任人类工程师一样信任 AI。

AI 的创造者难以赋予机器足够的道德价值观，这不仅限于身体伤害和金钱损失，还包括名誉损失、人际关系恶化、间接伤害（如把水洒在结冰的道路上）、道德选择困境、法律缺失地带等。

一个经典的科幻小说叫做 “回形针”，超级 AI 为了达成 “尽可能制作尽可能多的回形针” 目标，开始了一场毁灭全宇宙的递进行动。这就是 AI 失去常识和道德约束的结果，也给了我们启发 - 不要给 AI 发布过于开放的指令，应该训练 AI 寻找降低自身风险的逻辑，或者用更优秀的理解风险的 AI 来治愈有风险的 AI。

计算机只要能够理解这个世界，以及理解我们所说的内容，就拥有了无限的可能性：跳出大数据和深度学习的局限，走向更具鲁棒性的预装常识和价值观的、深度理解世界的人工智能。

拓展思考
基于 AI 的可信度质疑，人的工作机会在哪里
人类的脑力劳动中包含着大量的脏累体力活，这部分被 AI 替代没有什么不好的，这也不由员工的意志为转移。政府的法律会通过对垄断 AI 公司利润收取高额税收或数据使用费，补贴受影响的民众，并提供工具培训，引导新时期的就业方向。
在 AGI 到来的时代，富有创造性的工作仍然需要人类来主导。
更具体地说，就是人主导开头和结尾，通过掌控工具和超越工具来保持先进性，预判未来发展的方向。
开头就是人提出好问题和好创意，让 AI 聚焦目标发力；
结尾就是人做好对 AI 的评测把关，承担相应职责并获取高额报酬，活可以让 AI 干，但是要承诺不出事。无法担责的人就容易被 AI 替代工作。

从这个意义上说，懂 AI 的系统测试工程师职位可能比开发工程师能稳固。

WorkBuddy 带我学: Python 高级知识点完全指南

hello2014 — Mon, 20 Jul 2026 10:09:20 +0800

网页平台：https://pythonplus.netlify.app/

网页截图

Python 高级知识点完全指南

本文档是一份系统、深入的 Python 高级特性教程。每个主题都按"原理 → 示例 → 底层机制 → 常见陷阱 → 实践建议"展开，而非罗列代码片段。配套 9 幅图示，覆盖对象模型、函数式编程、元编程、执行模型、并发与性能。

阅读前提：熟悉 Python 基础语法（def/class/for/try、列表/字典、模块导入）、理解"一切皆对象"的直觉。本文不重复基础语法。

知识版图总览
魔术方法（Dunder Methods）全览
描述符协议
__slots__ 内存优化
闭包与装饰器
functools 工具集
迭代器协议
itertools 与函数式工具
上下文管理器
生成器与协程
asyncio 异步编程
super() 深度解析
元类（metaclass）
抽象基类 (ABC)
collections 常用容器
dataclasses
类型注解 (typing)
并发模型对比
内存管理与 GIL
性能分析与优化
学习路线图

1. 知识版图总览

Python 的"高级特性"看似零散，实则可以用两条主线串起来：

对象模型（Object Model）：Python 中"一切皆对象"。类本身是对象（type 的实例），方法其实是描述符，属性访问有固定的查找链。理解了对象模型，你就理解了装饰器、描述符、元类、魔术方法为什么那样工作。
执行模型（Execution Model）：函数调用如何压栈、yield 如何让函数挂起、事件循环如何调度协程、GIL 如何影响多线程。理解了执行模型，你就理解了生成器、asyncio、并发与性能调优。

下面这张图把全部主题归入 6 个分区，建议按"对象模型 → 函数式 → 执行模型 → 元编程 → 数据结构 → 性能"的顺序阅读。

本文的定位：不是语法手册，而是"为什么这样设计"与"什么时候该用"。所有代码均可直接运行（Python 3.10+ 验证）。遇到不确定的行为，优先用 python -i 或 ipython 亲手试。

2. 魔术方法（Dunder Methods）全览

核心概念：双下划线方法（dunder = double underscore）是 Python 对象模型的基础。当你写 a + b、len(x)、for v in obj、print(obj) 时，解释器实际调用的是 obj.__add__(b)、x.__len__()、obj.__iter__()、obj.__str__()。重载这些方法，就能让你的类"像内置类型一样自然地工作"。

2.1 构造与析构：`new` / `init` / `del`

这是最容易被误解的一组。__new__ 和 __init__ 职责完全不同：

方法	调用时机	职责	返回值
`__new__(cls, ...)`	最先调用	分配对象内存（创建实例）	必须返回新实例
`__init__(self, ...)`	`__new__` 之后	初始化实例属性	必须返回 `None`（返回其他值会报错）
`__del__(self)`	对象被 GC 回收前	清理资源	无（返回值被忽略）

class Foo:
    def __new__(cls, *args, **kwargs):
        # 真正的"构造函数"：负责把内存造出来
        print("__new__ 分配实例")
        instance = super().__new__(cls)
        return instance           # 关键：必须返回实例，否则 __init__ 不会被调用

    def __init__(self, value):
        print("__init__ 初始化")
        self.value = value        # 只赋值，不要 return

    def __del__(self):
        print("__del__ 析构")      # 不可靠：调用时机不确定

f = Foo(10)
# 输出: __new__ 分配实例
#       __init__ 初始化

为什么需要 __new__？ 因为 __new__ 是静态方法（第一个参数是类，不是实例），它可以在返回实例前做决定，甚至返回一个不同类的实例。典型应用场景：

# 不可变类型（int/str/tuple）和需要"缓存/池化"的对象必须重写 __new__
class PositiveInt(int):
    def __new__(cls, value):
        # int 是不可变的，必须在创建时修正值，__init__ 无法修改已创建好的 int
        return super().__new__(cls, abs(value))

PositiveInt(-5)   # 5 —— 负数被转成绝对值

__del__ 为什么不可靠？ 它的调用时机由垃圾回收决定，不保证"出了作用域立即执行"；循环引用还可能延迟它；更危险的是，__del__ 中抛出异常会被忽略。with 语句和上下文管理器才是资源清理的正确手段（见第 9 节）。

2.2 字符串表示：`repr` / `str` / `format`

__repr__：给开发者/调试器看，目标是"尽可能无歧义、最好能 eval 还原对象"。约定：repr(x) == "ClassName(args)"。
__str__：给最终用户看，目标是"可读"。print(x) 和 str(x) 优先用 __str__，没有才退回 __repr__。
__format__：支持 format(x, spec) 与 f-string 的 :spec 部分。

class Point:
    def __init__(self, x, y):
        self.x, self.y = x, y

    def __repr__(self):
        # 首选：能直接看到如何重建这个对象
        return f"Point(x={self.x}, y={self.y})"

    def __str__(self):
        # 给用户：简洁可读
        return f"({self.x}, {self.y})"

    def __format__(self, spec):
        # 支持 f"{p:.2f}" 之类
        if spec == ".2f":
            return f"({self.x:.2f}, {self.y:.2f})"
        return str(self)

p = Point(3.14159, 2.71828)
print(repr(p))        # Point(x=3.14159, y=2.71828)
print(str(p))         # (3.14159, 2.71828)
print(f"{p:.2f}")     # (3.14, 2.72)

经验法则：每个"数据类"都应实现 __repr__——调试时能立刻看清对象内容，省去大量 print(obj.__dict__)。

2.3 运算符重载

重载运算符时，必须理解三组规则：反射运算符、原地运算符、以及 __eq__/__hash__ 的契约。

class Vector:
    def __init__(self, x, y):
        self.x, self.y = x, y

    def __add__(self, other):           # self + other
        return Vector(self.x + other.x, self.y + other.y)

    def __radd__(self, other):          # other + self（当 other 没有 __add__ 时反射调用）
        return Vector(other + self.x, other + self.y)

    def __iadd__(self, other):          # self += other（原地，应返回 self）
        self.x += other.x
        self.y += other.y
        return self

    def __eq__(self, other):            # ==
        return isinstance(other, Vector) and self.x == other.x and self.y == other.y

    def __hash__(self):                 # 与 __eq__ 配套
        return hash((self.x, self.y))

    def __lt__(self, other):            # <（排序用）
        return (self.x, self.y) < (other.x, other.y)

三大规则：

反射运算符（__radd__、__rmul__ 等）：当 a + b 中 a.__add__(b) 返回 NotImplemented 时，Python 会尝试 b.__radd__(a)。这是让 1 + Vector(...)（数字在左）也能工作的关键。
原地运算符（__iadd__ 等）：a += b 优先调 __iadd__，返回 self 实现真正的原地修改（可变对象省内存）。不可变对象（如自定义元组）应不实现 __iadd__，退回 __add__。
__eq__ 与 __hash__ 的契约（极重要）：如果两个对象 __eq__ 相等，它们的 __hash__ 必须相等。一旦你重写了 __eq__，Python 会自动把类变成不可哈希（删掉 __hash__）；想让它可哈希，必须显式重写 __hash__。反之，若对象可变且参与哈希集合，应在 __hash__ 和 __eq__ 上保持一致性。

陷阱：只重写 __eq__ 不写 __hash__，对象就不能放进 set/dict 的键——常导致 TypeError: unhashable type。列表 (list)、字典 (dict) 等可变内置类型正是因此不可哈希。

2.4 容器模拟

让自定义类表现得像序列/映射：

class MyList:
    def __init__(self, data):
        self._data = list(data)

    def __len__(self):                # len(obj)
        return len(self._data)

    def __getitem__(self, idx):       # obj[idx]，支持切片（idx 可能是 slice）
        return self._data[idx]

    def __setitem__(self, idx, val):  # obj[idx] = val
        self._data[idx] = val

    def __delitem__(self, idx):       # del obj[idx]
        del self._data[idx]

    def __contains__(self, val):      # val in obj
        return val in self._data

    def __iter__(self):               # for x in obj
        return iter(self._data)

    def __reversed__(self):           # reversed(obj)
        return reversed(self._data)

要点：

__getitem__ 收到的 idx 可能是整数，也可能是 slice 对象（如 obj[1:3]）。若要支持切片，需自行判断 isinstance(idx, slice)。
实现了 __getitem__ + __len__ 的对象就满足 collections.abc.Sequence 的鸭子类型，可当作序列使用。
想让类成为"映射"，还需实现 __setitem__/__delitem__/keys/values/items 等，或用 collections.UserDict 包装（见第 15 节）。

2.5 可调用与属性访问

class CallableObj:
    def __call__(self, *args, **kwargs):
        print("被当作函数调用:", args)
        return sum(args)

f = CallableObj()
f(1, 2, 3)   # 被当作函数调用: (1, 2, 3) → 6

__call__ 让实例像函数一样可调用。常见于需要"持有状态的函数"：缓存器、配置化处理器、策略对象。

属性访问拦截是高级但危险的领域，务必分清三者：

方法	触发时机	风险
`__getattr__(self, name)`	常规属性查找失败后（兜底）	安全，常用于代理/惰性加载
`__getattribute__(self, name)`	每次属性访问都触发	极易无限递归，必须 `super().__getattribute__`
`__setattr__(self, name, val)`	每次属性赋值	同样易递归，必须 `super().__setattr__`

class Proxy:
    def __init__(self, target):
        self._target = target

    def __getattr__(self, name):
        # 只有找不到 name 时才走到这里（_target 自身属性不会触发）
        return getattr(self._target, name)

class Dangerous:
    def __getattribute__(self, name):
        # 每次访问属性都触发，包括读取 self._x 也会再触发 → 无限递归
        # 正确写法：
        return super().__getattribute__(name)

    def __setattr__(self, name, value):
        # 错误写法：self._data = value 又会触发 __setattr__ → 递归
        # 正确写法：
        super().__setattr__(name, value)

属性访问的黄金法则：__getattr__ 是"安全兜底"，优先用它；__getattribute__/__setattr__ 必须用 super() 委托，否则直接栈溢出。绝大多数场景不需要它们——描述符（第 3 节）是更可控的属性拦截方案。

补充：__missing__（字典专属）：dict 子类实现 __missing__(key)，可在 d[key] 缺失时返回默认值而不抛 KeyError。这是 collections.defaultdict 的底层机制。

3. 描述符协议

核心概念：描述符是实现了 __get__、__set__、__delete__ 中至少一个的对象。它表面上不起眼，却是 Python 属性系统的底层引擎——你每天用的 property、classmethod、staticmethod，以及 Django、SQLAlchemy、Pydantic 里的字段，全都是描述符。

3.1 描述符协议与 data/non-data 之分

描述符按"是否定义了 __set__"分为两类，这决定了它的优先级：

data descriptor（数据描述符）：定义了 __set__（可能还有 __delete__）。优先级最高，连实例字典都压不过它。
non-data descriptor（非数据描述符）：只有 __get__（如普通函数/方法）。优先级低于实例字典。

class Validated:
    def __init__(self, validator):
        self.validator = validator

    def __set_name__(self, owner, name):
        # Python 3.6+：描述符被赋给类属性时，自动得知自己的名字
        self.name = f"_{name}"

    def __get__(self, inst, owner):
        # inst 为实例；通过类访问时 inst 为 None
        if inst is None:
            return self
        return getattr(inst, self.name, None)

    def __set__(self, inst, value):
        if not self.validator(value):
            raise ValueError(f"校验失败: {self.name}")
        setattr(inst, self.name, value)

class User:
    name = Validated(str.isalpha)                 # 仅字母
    age  = Validated(lambda x: isinstance(x, int) and 0 < x < 150)

u = User()
u.name = "Alice"
u.age = 30
# u.age = -1      # ValueError: 校验失败
# u.name = "Bob1" # ValueError: 校验失败

__get__(self, inst, owner)：owner 是拥有该描述符的类。inst is None 表示通过类访问（如 User.name），此时通常返回描述符本身。
__set_name__ 让你不必手写字符串属性名，框架里常用来自动登记字段。

3.2 属性解析顺序（为什么"实例属性可以遮蔽方法"）

当你写 obj.x，Python 按以下固定顺序查找：

如果 x 是 data descriptor（有 __set__）→ 调用它的 __get__。优先级最高。
否则，查 实例字典 obj.__dict__['x']。
否则，查 类字典 type(obj).__dict__['x']，若找到的是 non-data descriptor（如函数）→ 调用 __get__（这把函数变成"绑定方法"）。
否则，查父类的字典（按 MRO）。
否则，调用类的 __getattr__（若有）。再找不到 → AttributeError。

这就是关键洞察：普通方法是 non-data descriptor。因此当你写 obj.foo = 123，实例字典里有了 foo，它就遮蔽了类上的 foo 方法（因为步骤 2 在步骤 3 之前）。而 property 是 data descriptor，所以即使你给实例赋值 obj.x = ...，也会被 property 的 __set__ 拦截——实例字典里根本不会出现 x。

property 本质：property(fget, fset, fdel, doc) 就是一个 data descriptor 工厂。@property 是语法糖，等价于创建一个带 __get__/__set__ 的描述符实例并赋给类属性。

3.3 描述符的典型实战

缓存描述符（lazy property）：首次访问计算，之后缓存到实例字典。

class cached_property:
    def __init__(self, func):
        self.func = func
        self.name = func.__name__

    def __set_name__(self, owner, name):
        self.name = name

    def __get__(self, inst, owner):
        if inst is None:
            return self
        # 算一次后直接写进实例字典：下次查找步骤 2 命中，不再走描述符
        value = self.func(inst)
        inst.__dict__[self.name] = value
        return value

class Report:
    def __init__(self, data):
        self.data = data

    @cached_property
    def summary(self):
        print("计算一次...")
        return sum(self.data)

r = Report([1,2,3])
r.summary   # 计算一次... → 6
r.summary   # 直接读缓存 → 6

提示：functools.cached_property 内置了这个模式（Python 3.8+），生产代码直接用它即可。

4. `slots` 内存优化

原理：普通对象每个实例都带一个 __dict__（字典），用来存放任意动态属性。字典本身有开销（哈希表、指针数组），且无法高效紧凑排列。声明 __slots__ 后，Python 不再为实例创建 __dict__，而是把列出的属性变成固定大小的"槽位"（类似 C 结构体），直接存在对象内存里。

class Point:
    __slots__ = ('x', 'y')          # 只允许这两个属性
    def __init__(self, x, y):
        self.x, self.y = x, y

p = Point(1, 2)
# p.z = 3   # AttributeError: 'Point' object has no attribute 'z'

4.1 内存与速度

100 万个实例时，差距非常显著：

import sys, time, tracemalloc

class WithDict:
    def __init__(self, x, y): self.x, self.y = x, y

class WithSlots:
    __slots__ = ('x', 'y')
    def __init__(self, x, y): self.x, self.y = x, y

def bench(cls, n=1_000_000):
    tracemalloc.start()
    objs = [cls(i, i) for i in range(n)]
    cur, peak = tracemalloc.get_traced_memory()
    tracemalloc.stop()
    return peak / 1024 / 1024

print(f"普通类: {bench(WithDict):.1f} MB")     # ~150 MB
print(f"slots:  {bench(WithSlots):.1f} MB")    # ~55 MB（约省 60%）

4.2 使用代价与陷阱

__slots__ 不是免费的，务必注意：

收益	代价
省内存（大量实例时显著）	不能动态添加未在 `__slots__` 中声明的属性
属性访问略快（少一层字典查找）	多继承时，只有所有父类都定义 `__slots__` 才有效
可阻止意外属性名拼写错误	默认没有 `__dict__`，需要弱引用支持时还要加 `'__weakref__'`
	继承链复杂时易踩坑

class Node:
    __slots__ = ('value', '__weakref__')   # 若要用 weakref.ref，需显式加入 __weakref__
    def __init__(self, v): self.value = v

决策准则：仅当实例数量达到十万级以上且属性集合固定时才值得用（如 ORM 行对象、海量数据点）。日常业务对象、配置类、DTO 用 @dataclass 更合适——可读性与灵活性远比那点内存重要。__slots__ = () 还可让类本身不可实例化出有 __dict__ 的对象。

5. 闭包与装饰器

5.1 闭包（Closure）的本质

概念：内层函数捕获了外层作用域的变量（自由变量），即使外层函数已经返回，这些变量依然存活——因为 Python 用"cell 对象"持有它们，形成闭包。

def make_multiplier(factor):
    def multiply(x):
        return x * factor     # factor 是自由变量，被闭包捕获
    return multiply

double = make_multiplier(2)
triple = make_multiplier(3)
print(double(5), triple(5))   # 10  15
# make_multiplier 已返回，但 factor=2 / 3 仍被 double/triple 持有

验证闭包捕获的变量：

print(double.__closure__[0].cell_contents)   # 2

关键点：multiply 没有自己的 factor，它引用的是外层作用域的 factor。每次调用 make_multiplier 都会创建一个新的 cell。注意循环 + 闭包的经典陷阱（见下）。

5.2 装饰器（Decorator）= "接收函数、返回函数"的高阶函数

装饰器本质就是语法糖：@deco 等价于 func = deco(func)。它把闭包用于"在不修改原函数代码的前提下，增强其行为"。

import functools, time

def timer(func):
    @functools.wraps(func)           # 关键：保留原函数的 __name__/__doc__/__module__
    def wrapper(*args, **kwargs):
        t = time.perf_counter()
        result = func(*args, **kwargs)
        print(f"{func.__name__} 耗时 {time.perf_counter()-t:.4f}s")
        return result                # 必须原样返回原函数的返回值
    return wrapper

@timer
def add(a, b):
    """两数相加"""
    return a + b
# 等价于: add = timer(add)

add(3, 4)          # 打印耗时并返回 7
print(add.__name__)  # "add"（因为 @wraps）；否则会是 "wrapper"

为什么 @functools.wraps 不可省略？ 没有它，被装饰函数的元信息（__name__、__doc__、__module__、参数签名）会变成 wrapper 的，导致：日志显示错误函数名、inspect.signature 失效、pickle 失败、基于 __name__ 的路由/注册出错。

5.3 带参装饰器（三层嵌套）

当装饰器本身要接收参数时，就变成三层结构：最外层接收参数，返回"真正的装饰器"，再由它包裹函数。

import functools, time

def retry(max_attempts=3, delay=1):
    def decorator(func):                     # 第二层：真正的装饰器
        @functools.wraps(func)
        def wrapper(*args, **kwargs):
            for i in range(max_attempts):
                try:
                    return func(*args, **kwargs)
                except Exception:
                    if i == max_attempts - 1:
                        raise
                    time.sleep(delay)
        return wrapper
    return decorator                          # 第一层返回装饰器

@retry(max_attempts=5, delay=0.5)
def fetch_data():
    ...

难点：@retry 与 @retry(...) 写法不同。@retry 时 Python 把被装饰函数直接传给 retry；@retry(5) 时先调用 retry(5) 得到装饰器再包裹。要同时支持两种写法，可在第一层判断第一个参数是否是可调用的函数（略复杂，生产建议分开）。

5.4 类装饰器（持有状态）

当装饰器需要持有状态（如计数、缓存字典），用类更自然——类实例本身就是状态容器。

import functools

class CountCalls:
    def __init__(self, func):
        functools.update_wrapper(self, func)   # 等价于 wraps
        self.func = func
        self.count = 0

    def __call__(self, *args, **kwargs):
        self.count += 1
        return self.func(*args, **kwargs)

@CountCalls
def greet(name):
    return f"hi {name}"

greet("A"); greet("B")
print(greet.count)   # 2

5.5 装饰器叠加（执行顺序）

多个装饰器从下往上包裹（离函数最近的先应用）：

@a
@b
@c
def f(): ...
# 等价于: f = a(b(c(f)))   # c 先包，a 最后包；调用时 a→b→c→原函数的层层进入

5.6 装饰器本质图

实战清单：计时、日志、重试、缓存 (lru_cache)、权限校验、注册路由、单例、弃用警告 (warnings) 都是装饰器的典型用途。记住铁律——装饰器必须返回可被调用且能透传返回值/异常的对象，并保持 @wraps。

6. `functools` 工具集

functools 是函数式编程的工具箱。以下几项是高频必备。

6.1 `partial` — 偏函数（冻结部分参数）

from functools import partial

def power(base, exp):
    return base ** exp

square = partial(power, exp=2)    # 固定 exp=2
cube   = partial(power, exp=3)
print(square(5), cube(4))         # 25  64

# 实战：给回调预置参数（GUI/异步里非常常见）
on_click = partial(handle_click, button_id=7)

partial 返回的对象会保留 __name__/__doc__，但 inspect.signature 会反映剩余参数。注意 partial 是浅冻结：若冻结的是可变对象，调用方仍可能修改它。

6.2 `lru_cache` — 记忆化缓存

把函数结果按参数缓存，相同输入直接返回，避免重复计算。

from functools import lru_cache

@lru_cache(maxsize=128)
def fib(n):
    if n < 2:
        return n
    return fib(n-1) + fib(n-2)

print(fib(100))                 # 毫秒级（否则指数爆炸）
print(fib.cache_info())
# CacheInfo(hits=98, misses=101, maxsize=128, currsize=101)

关键细节：

缓存键是参数的哈希：被装饰函数的所有参数必须可哈希（__hash__）。传列表会报错——先转元组。
maxsize=None 表示无限缓存；maxsize=2**n 性能最佳（用环形链表）。
typed=True 时，f(3) 与 f(3.0) 视为不同键。
fib.cache_clear() 清空缓存。
适用于纯函数（相同输入必得相同输出，无副作用）。

6.3 `singledispatch` — 单分派泛型函数

按第一个参数类型自动选择实现，是"重载"的优雅替代（Java/C++ 才有真正重载，Python 用这个）。

from functools import singledispatch

@singledispatch
def process(data):
    raise NotImplementedError(f"不支持类型: {type(data)}")

@process.register
def _(data: int):
    return data * 2

@process.register
def _(data: str):
    return data.upper()

@process.register(list)
def _(data):                       # 也可写成 register(list)
    return [process(x) for x in data]

print(process(42))          # 84
print(process("hello"))     # HELLO
print(process([1, "a", 3])) # [2, 'A', 6]

Python 3.11+ 还有 singledispatchmethod：用于类方法的分派。

6.4 `reduce` — 累积归约

from functools import reduce

product = reduce(lambda a, b: a * b, [1, 2, 3, 4])        # 24
max_val = reduce(lambda a, b: a if a > b else b, [3, 7, 2, 9])  # 9
# 可给初始值（避免空序列报错）：reduce(fn, seq, init)

多数情况下 functools.reduce 不如显式 for 或 sum/max 可读。仅当"把序列折叠成一个值"且逻辑紧凑时使用。

6.5 `wraps` / `update_wrapper`

已见 5.2。补充：update_wrapper 是底层 API，wraps 是它的装饰器封装。它复制 __module__、__name__、__qualname__、__doc__、__dict__ 等，并设 __wrapped__ 指向原函数（供 inspect 穿透）。

7. 迭代器协议

核心概念：Python 的 for 循环、解包、* 展开、in 判断，底层都依赖迭代器协议。理解它，就理解了"惰性计算"和"流式处理"的基础。

可迭代对象（Iterable）：实现 __iter__() 返回迭代器的对象（如 list、str、dict、set、生成器）。
迭代器（Iterator）：同时实现 __iter__()（返回自身）和 __next__()（返回下一个元素；耗尽时抛 StopIteration）的对象。

class Countdown:
    def __init__(self, start):
        self.start = start

    def __iter__(self):        # 返回迭代器（这里就是自己）
        return self

    def __next__(self):        # 每次调用推进一次
        if self.start <= 0:
            raise StopIteration
        self.start -= 1
        return self.start + 1

for n in Countdown(3):
    print(n)                   # 3 2 1

# 底层完全等价：
it = iter(Countdown(3))        # 调用 __iter__
while True:
    try:
        print(next(it))        # 调用 __next__
    except StopIteration:
        break

迭代器 vs 可迭代对象的关系

关键区别：迭代器是"一次性"的——走完（StopIteration）后再 next() 仍抛异常，且不会自动重置。列表是可迭代但不是迭代器（每次 iter(lst) 都返回全新的迭代器）；而生成器本身就是迭代器。

nums = [1, 2, 3]
it1 = iter(nums); it2 = iter(nums)
next(it1); next(it1)           # 1, 2
next(it2)                      # 1 —— 独立的迭代器，互不影响

StopIteration 的现代陷阱（PEP 479）：在生成器里，若正常 return 会以 StopIteration 结束；但如果在生成器内部意外抛出 StopIteration，Python 3.7+ 会把它转换为 RuntimeError，防止它错误地终止外层 for。这是历史包袱的修复，理解即可。

实战价值：自定义迭代器让你能处理无限流或超大数据集而不占内存——每次只产生一个元素。这也是 itertools、生成器 的基石。

8. `itertools` 与函数式工具

itertools 提供一组惰性、内存友好的迭代器，是高效数据处理利器。下面逐一给出用法与输出。

import itertools

# --- 无限迭代器（务必配合 islice / 条件终止，否则死循环）---
itertools.count(10, 2)            # 10, 12, 14, 16, ...（从 10 起步长 2）
itertools.cycle("AB")             # A, B, A, B, A, B, ...（无限循环）
itertools.repeat("x", 3)          # x, x, x（有限次，可省略次数成无限）

# --- 组合迭代器 ---
itertools.product("AB", "12")     # 笛卡儿积
# ('A','1'), ('A','2'), ('B','1'), ('B','2')
itertools.permutations("AB", 2)   # 排列（有序）：('A','B'), ('B','A')
itertools.combinations("ABC", 2)  # 组合（无序）：('A','B'), ('A','C'), ('B','C')
itertools.combinations_with_replacement("AB", 2)  # 允许重复：('A','A'),('A','B'),('B','B')

# --- 终止迭代器 ---
list(itertools.accumulate([1, 2, 3, 4]))       # 前缀和: [1, 3, 6, 10]
list(itertools.chain([1, 2], "ab"))            # 拼接: [1, 2, 'a', 'b']
list(itertools.chain.from_iterable([[1,2],[3,4]]))  # 展平: [1, 2, 3, 4]
list(itertools.groupby("aaabbc"))              # 按键分组（注意：键必须已排序！）
# [('a', <g>), ('b', <g>), ('c', <g>)]  每个值是迭代器
list(itertools.islice(range(100), 5, 15))      # 切片（惰性）: [5..14]
list(itertools.zip_longest("AB", "123"))       # 不等长补 None: [('A','1'),('B','2'),(None,'3')]
list(itertools.pairwise([1, 2, 3, 4]))         # 3.10+ 滑动窗口: [(1,2),(2,3),(3,4)]

常见实用模式

# 1) 分组前必须先排序（groupby 只连续归组）
data = sorted([("a",1),("b",2),("a",3)])
for key, grp in itertools.groupby(data, key=lambda x: x[0]):
    print(key, list(grp))
# a [('a',1),('a',3)]
# b [('b',2)]

# 2) 滑窗统计（如滚动平均）
def windowed(seq, n):
    iters = itertools.tee(seq, n)              # 复制 n 份迭代器
    for i, it in enumerate(iters):
        next(itertools.islice(it, i, i), None) # 各自偏移 i
    return zip(*iters)
list(windowed([1,2,3,4,5], 3))   # [(1,2,3),(2,3,4),(3,4,5)]

# 3) 生成器表达式（最 Pythonic 的惰性映射+过滤）
squares = (x*x for x in range(10) if x % 2 == 0)   # 不立即计算，省内存

tee 会把迭代器"快照"成多份，但会缓冲已消费的元素——若只需顺序访问，优先考虑 islice/手动游标，避免 tee 占用过多内存。

9. 上下文管理器

核心概念：上下文管理器让资源"自动清理"——无论代码块正常结束还是抛异常，__exit__（或 yield 之后）都会运行。这是 try/finally 的优雅封装，用于文件、锁、连接、计时、临时状态等。

9.1 类实现：`enter` / `exit`

import time

class Timer:
    def __enter__(self):
        self.t = time.perf_counter()
        return self                 # with ... as <val> 接收的就是它的返回值

    def __exit__(self, exc_type, exc_val, exc_tb):
        print(f"耗时 {time.perf_counter()-self.t:.4f}s")
        return False                # False=不吞异常（向外传播）；True=吞掉异常

with Timer() as t:
    time.sleep(0.5)
# 输出: 耗时 0.50xx s
# sleep 中若抛异常，__exit__ 仍会被调用，且异常继续向外抛出（因返回 False）

__exit__ 的三个参数在无异常时全为 None；有异常时分别为异常类型、实例、回溯对象。

9.2 `contextmanager` — 生成器方式（更简洁）

@contextmanager 把"含 yield 的生成器"变成上下文管理器：yield 之前是进入逻辑，yield 之后是退出逻辑。

from contextlib import contextmanager
import time, os

@contextmanager
def timer():
    t = time.perf_counter()
    yield                          # 这里的 yield 值 = as 接收的值（此处为 None）
    print(f"耗时 {time.perf_counter()-t:.4f}s")

@contextmanager
def temp_env(key, value):          # 临时修改环境变量，退出还原
    old = os.environ.get(key)
    os.environ[key] = value
    try:
        yield
    finally:                       # 即使块内异常，也确保还原
        if old is None:
            os.environ.pop(key, None)
        else:
            os.environ[key] = old

with temp_env("MODE", "prod"):
    print(os.environ["MODE"])      # prod
print(os.environ.get("MODE"))      # 恢复为 None

异常处理：@contextmanager 包裹的函数里，若 yield 之后的代码抛异常（如 finally 中的清理也出错），该异常会传播；若块内抛异常，它会在 yield 处重新抛出，由 try/except 捕获或传播。务必用 try/finally 保证清理。

9.3 其他 `contextlib` 工具

from contextlib import suppress, closing, ExitStack, nullcontext, redirect_stdout
import os, io, sys

with suppress(FileNotFoundError):   # 优雅忽略指定异常（不必写 try/except/pass）
    os.remove("nonexistent.txt")

with closing(open("f.txt")) as f:   # 确保 .close() 被调用（对象本身不支持 with 时）
    data = f.read()

with ExitStack() as stack:          # 动态管理数量不定的多个上下文
    files = [stack.enter_context(open(f"file{i}.txt")) for i in range(3)]
    # 退出时全部自动关闭，按逆序

with redirect_stdout(io.StringIO()) as buf:  # 临时重定向 stdout（测试很有用）
    print("hello")
captured = buf.getvalue()           # "hello\n"

with nullcontext() as c:            # 占位上下文（根据条件决定是否套真实上下文）
    pass

上下文管理器执行流程

额外：contextlib.asynccontextmanager 提供异步版本的 @contextmanager，配合 async with 使用（见第 11 节）。

10. 生成器与协程

10.1 生成器基础（惰性 + 挂起）

yield 让函数在产出值后挂起并保留局部状态，下次被唤醒时从暂停点继续。与一次性算出全部结果的列表相比，生成器按需产生、几乎零内存。

# 生成器表达式（惰性）
g = (x*x for x in range(10) if x % 2 == 0)
print(next(g), next(g))     # 0 4

# yield from：委托给子生成器（自动转发 yield/值，并收集子生成器 return 的值）
def chain(*iters):
    for it in iters:
        yield from it        # 等价于 for x in it: yield x
print(list(chain([1, 2], (3, 4))))   # [1, 2, 3, 4]

10.2 协程：双向通信的生成器

生成器不仅能产出（yield 给调用者），还能通过 send() 接收值——这就成了协程（双向数据流）。throw() 注入异常，close() 终止。

def accumulator():
    total = 0
    while True:
        x = yield total           # 暂停，把 total 交出去，等待 send 注入到 x
        if x is None:
            break
        total += x

acc = accumulator()
next(acc)            # 预激活：必须先 next() 或 send(None) 跑到第一个 yield
print(acc.send(10))  # 10  （total=10）
print(acc.send(5))   # 15  （total=15）
acc.send(None)       # 结束（break → StopIteration）
# acc.close()        # 也可主动关闭，触发 GeneratorExit

生命周期状态机：

状态	说明
CREATED	调用生成器函数，返回生成器对象；函数体尚未执行
RUNNING	调用 `next()`/`send()` 后进入，执行函数体直到遇到 `yield`
SUSPENDED	在 `yield` 处挂起，把值交给调用者；等待下一次唤醒
CLOSED	函数执行完毕（`return`/`StopIteration`）、被 `close()` 或抛异常，生命周期结束

10.3 协程的实战价值与 `yield from` 异常传播

yield from 不仅是语法糖，它还会：把子生成器的 yield 直接透传给最外层、把 send 直接转发给子生成器、把子生成器的 return value 作为 yield from 表达式的值（PEP 380 的核心贡献）。

def sub():
    yield 1
    return "done"

def outer():
    result = yield from sub()     # result == "done"
    yield result

g = outer()
print(next(g))      # 1
print(next(g))      # "done"

10.4 生成器的最佳场景

数据管道：逐行读大文件、逐条处理流数据（日志、网络包），内存恒定。
无限序列：斐波那契、传感器采样，永不"全量计算"。
协程流水线：send/throw 构建生产者 - 消费者。
惰性组合：itertools + 生成器表达式替代多轮列表拷贝。

现代写法：需要双向协程时，优先用 async/await（见第 11 节）——它语义更清晰、配套设施更全。手写 yield 协程如今主要用于数据管道和惰性求值。

11. `asyncio` 异步编程

核心概念：asyncio 提供单线程事件循环 + 协作式调度。协程在 await 处主动交还控制权，事件循环转去运行其他就绪任务；IO 完成后再唤醒它。没有抢占、没有线程切换开销——因此能以极低代价支撑海量并发 IO。

11.1 最小模型

import asyncio, time

async def fetch(i):
    await asyncio.sleep(1)        # 模拟 IO：此处让出控制权，不阻塞线程
    return i * 10

async def main():
    t = time.perf_counter()
    results = await asyncio.gather(fetch(1), fetch(2), fetch(3))
    print(results, f"用时 {time.perf_counter()-t:.2f}s")

asyncio.run(main())   # [10, 20, 30] 用时约 1.00s（而非 3s）

关键术语：

概念	说明
`coroutine`	`async def` 返回的对象本身不执行，必须被 `await` 或包成 Task
`Task`	`asyncio.create_task(coro)` 把协程登记到事件循环，立即开始调度（并发的真正来源）
`await`	只对 awaitable 生效；阻塞当前协程直到完成，但不阻塞事件循环
`Event Loop`	调度中枢：维护就绪队列，IO 完成回调唤醒对应 Task

11.2 并发的正确与错误写法

async def fetch(i):
    await asyncio.sleep(1)
    return i

# ❌ 错误：顺序 await → 退化成串行（总耗时 3s）
async def wrong():
    r1 = await fetch(1)
    r2 = await fetch(2)
    r3 = await fetch(3)

# ✅ 正确：先把协程变成 Task 并发调度
async def right():
    t1 = asyncio.create_task(fetch(1))
    t2 = asyncio.create_task(fetch(2))
    t3 = asyncio.create_task(fetch(3))
    results = await asyncio.gather(t1, t2, t3)   # 总耗时约 1s

# gather 也支持直接传协程（内部会自动 create_task）
results = await asyncio.gather(fetch(1), fetch(2), fetch(3))

11.3 生产者 - 消费者（Queue）

import asyncio

async def worker(q, wid):
    while True:
        item = await q.get()
        if item is None:
            q.task_done()
            break
        await asyncio.sleep(0.1)         # 模拟处理
        print(f"worker {wid} 处理 {item}")
        q.task_done()

async def producer(q):
    for i in range(5):
        await asyncio.sleep(0.05)
        await q.put(i)
    for _ in range(3):                    # 发 3 个 None 让 3 个 worker 退出
        await q.put(None)

async def main():
    q = asyncio.Queue()
    workers = [asyncio.create_task(worker(q, i)) for i in range(3)]
    await asyncio.gather(producer(q), *workers)

asyncio.run(main())

11.4 同步阻塞函数的处理（最重要陷阱）

在协程里调用同步阻塞函数（如 requests.get、time.sleep、open 读大文件）会卡死整个事件循环——因为阻塞期间控制权无法让出，所有其他任务都被冻住。解决方案：

import asyncio, concurrent.futures, requests

async def main():
    loop = asyncio.get_running_loop()
    # 把阻塞函数丢到线程池执行，await 等待其完成后不阻塞循环
    resp = await loop.run_in_executor(
        None, requests.get, "https://example.com"
    )
    # 或者用 asyncio.to_thread（Python 3.9+，语义相同，更简洁）
    data = await asyncio.to_thread(blocking_io_func, arg)

IO 阻塞（网络/磁盘）→ 换异步库（aiohttp、httpx.AsyncClient）或 run_in_executor/to_thread。
CPU 密集 → 用 loop.run_in_executor 丢到 ProcessPoolExecutor，或用 asyncio 之外的 multiprocessing。

11.5 调度循环图示

更多要点：asyncio.wait 可设 FIRST_COMPLETED/FIRST_EXCEPTION 精细控制；asyncio.TimeoutError 与 asyncio.wait_for(coro, timeout) 做超时；asyncio.shield 防止取消传播；asyncio.CancelledError 用于优雅取消；@asynccontextmanager 写异步上下文管理器；async for 遍历异步迭代器。取消时用 task.cancel() 并在协程内 try/finally 清理。

12. `super()` 深度解析

最大的误解：super() 不是"父类的引用"。它返回的是一个代理对象，沿当前实例的 MRO（方法解析顺序）链，查找调用者的下一个类。这个区分在多继承时至关重要。

12.1 单继承 vs 多继承的真相

class A:
    def foo(self):
        print("A.foo")

class B(A):
    def foo(self):
        print("B.foo")
        super().foo()          # 沿 MRO 找 B 之后的下一个 foo（即 A.foo）

class C(A):
    def foo(self):
        print("C.foo")
        super().foo()

class D(B, C):
    def foo(self):
        print("D.foo")
        super().foo()

D().foo()
# 输出:
# D.foo
# B.foo
# C.foo
# A.foo

D 的 MRO 是 [D, B, C, A, object]。D.foo 里的 super() 找的是 MRO 中 D 之后第一个实现了 foo 的类 = B；B.foo 里的 super() 找 B 之后 = C；C.foo 里的 super() 找 C 之后 = A。注意 B 的 super() 跳到了"兄弟类" C——这正是协作式多继承（cooperative MRO）的精髓。

12.2 `super()` 的两种形式

super()                       # 零参数：Python 3 自动填入当前类和 self
super(B, self)                # 显式：沿 B 在 self 的 MRO 之后的类查找
super(__class__, self)        # 函数内部用（避免硬编码类名）

零参数 super() 实际上是语法糖：编译器把当前 __class__ 和第一个参数（self/cls）注入进去。

12.3 协作式多继承的铁律

要让 super() 链不断裂，所有协作者必须：

都使用 super() 调用链上的下一个方法；
方法签名一致（通常参数都带 **kwargs 透传）；
链的终点（通常是 object）能处理剩余参数。

class Base:
    def __init__(self, x, **kwargs):
        super().__init__(**kwargs)    # 把剩余 kwargs 传给下一个
        self.x = x

class Mixin:
    def __init__(self, y, **kwargs):
        super().__init__(**kwargs)
        self.y = y

class Derived(Base, Mixin):
    def __init__(self, z, **kwargs):
        super().__init__(**kwargs)    # 沿 MRO: Derived→Base→Mixin→object
        self.z = z

d = Derived(x=1, y=2, z=3)            # 三个 __init__ 都被正确调用

经验：不要滥用手写多继承 + super() 协作链——复杂度高且易错。能用组合（has-a）就用组合。super() 的常规正确用法是单继承里调用父类方法（最常见、最安全）。

13. 元类（metaclass）

核心概念：元类是"创建类的类"。在 Python 中，class 语句并非"声明"，而是执行：解释器收集类体命名空间，再调用 type(name, bases, ns)（或指定的元类）构造出类对象。所以"类"也是对象——type 的实例。元类就是 type 的子类，拦截"类被创建"的瞬间。

13.1 `type` 的三参数形式

# 动态创建类的等价写法：
def say_hi(self):
    return f"hi from {self.name}"

Attrs = type("Attrs", (object,), {"name": "x", "say_hi": say_hi})
obj = Attrs()
print(obj.say_hi())   # hi from x

这等价于 class Attrs: name="x"; def say_hi(self): ...。

13.2 自定义元类

class LogMeta(type):
    def __new__(mcs, name, bases, ns):
        # __new__ 负责"造出类对象"
        print(f"正在创建类: {name}, 基类: {bases}")
        for k, v in ns.items():
            if callable(v) and not k.startswith("_"):
                ns[k] = debug_wrapper(v)      # 在类创建期改写方法
        return super().__new__(mcs, name, bases, ns)

    def __init__(cls, name, bases, ns):
        # __init__ 负责"初始化已造好的类对象"
        super().__init__(name, bases, ns)
        cls.__author__ = "meta"

class Base(metaclass=LogMeta):
    def foo(self): ...
    def bar(self): ...
# 打印: 正在创建类: Base, 基类: (<class 'object'>,)
# Base.foo / Base.bar 被自动包上日志；其所有子类也会经 LogMeta 创建

__new__ vs __init__（元类）：__new__ 返回新类对象；__init__ 在类对象造好后做初始化。多数"改造类"的逻辑放 __new__。__prepare__（可选）还能定制类体命名空间的字典类型（如自动排序）。

13.3 实战：自动注册子类（插件系统）

class PluginMeta(type):
    registry = {}

    def __new__(mcs, name, bases, ns):
        cls = super().__new__(mcs, name, bases, ns)
        if bases:                       # 跳过基类自身
            PluginMeta.registry[name.lower()] = cls
        return cls

class Plugin(metaclass=PluginMeta):
    pass

class JsonExporter(Plugin): ...
class CsvExporter(Plugin): ...

print(PluginMeta.registry)
# {'jsonexporter': <class ...>, 'csvexporter': <class ...>}

13.4 更轻量的替代：优先用它们而非元类

90% 的场景不需要元类。现代替代方案：

# 1) __init_subclass__（Python 3.6+）：子类创建时回调，无需元类
class Plugin:
    registry = {}
    def __init_subclass__(cls, **kwargs):
        super().__init_subclass__(**kwargs)
        Plugin.registry[cls.__name__.lower()] = cls

# 2) __set_name__：描述符自动获知属性名（见第 3 节）

13.5 类也是对象（对象链图示）

元类 vs 类装饰器：元类影响该类及其所有子类（在继承链创建时生效）；类装饰器只作用在当前类上。决策顺序：能用函数/组合解决就别用装饰器；能用 __init_subclass__ 就别用元类；能用元类就别用更复杂的反射。元类适合框架级"批量改造类"（ORM、序列化器、API 路由自动注册），业务代码几乎用不到。

14. 抽象基类 (ABC)

核心概念：抽象基类定义接口契约——声明"必须实现哪些方法"，阻止不完整的类被实例化，并在缺失实现时尽早报错（而非运行到调用才崩溃）。

14.1 基本用法

from abc import ABC, abstractmethod

class Animal(ABC):
    @abstractmethod
    def speak(self):
        pass                        # 子类必须实现

    @property
    @abstractmethod
    def legs(self):                # 抽象属性
        pass

class Dog(Animal):
    legs = 4
    def speak(self):
        return "woof"

# Animal()        # TypeError: Can't instantiate abstract class Animal with abstract method speak
dog = Dog()       # OK

14.2 虚拟子类（不通过继承注册）

register() 把一个不继承 ABC 的类登记为"虚拟子类"，使其通过 isinstance 检查——实现"结构化兼容"而不强耦合。

from collections.abc import Sized

class MyCollection:
    def __len__(self):
        return 42

Sized.register(MyCollection)             # 注册为虚拟子类
print(isinstance(MyCollection(), Sized))  # True（虽未继承 Sized）

__subclasshook__：在 ABC 里重写它可实现自动鸭子类型识别（如 Iterable 只要对象有 __iter__ 就认为是它的子类）。collections.abc 大量使用此技巧。

14.3 常用 `collections.abc` 抽象基类

Iterable、Iterator、Sized、Container、Sequence、MutableSequence、Mapping、MutableMapping、Set、MutableSet、Callable、Hashable。用 isinstance(x, Sequence) 做接口检查比 hasattr(x,'__getitem__') 更可靠。

ABC vs Protocol（typing）：ABC 是运行时强制（实例化时报错、可被 isinstance 检测）；Protocol 是静态类型层面的结构化类型（mypy 检查，运行时无约束，零开销）。需要运行时强制用 ABC；只做静态检查用 Protocol。

15. `collections` 常用容器

标准 dict/list/tuple/set 之外，collections 提供一组高频专用容器。

容器	用途	关键方法/特性
`namedtuple`	轻量不可变记录	`_asdict`, `_replace`, `_make`, `_fields`
`deque`	双端队列，两端 O(1)	`appendleft`, `popleft`, `maxlen`, 线程安全（append/pop）
`Counter`	计数/频次	`most_common`, `elements`, `subtract`, `+`/`-` 运算
`defaultdict`	带默认值工厂的 dict	访问缺失键自动调用工厂
`ChainMap`	多 dict 逻辑合并	不拷贝、查找按序、写只命中第一个
`OrderedDict`	保序 dict（3.7+ 内置 dict 已保序）	`move_to_end`, `popitem(last=)`

from collections import namedtuple, deque, Counter, defaultdict, ChainMap, OrderedDict

# namedtuple：不可变数据记录（比 class 省内存，比 tuple 可读）
Point = namedtuple("Point", ["x", "y"])
p = Point(10, 20)
p.x, p[0]                 # 10, 10
p._asdict()               # {'x': 10, 'y': 20}
p._replace(x=99)          # Point(x=99, y=20) 返回新对象（不可变）
Point._fields             # ('x', 'y')
Point._make([1, 2])       # Point(x=1, y=2)

# deque：高效队列/栈（list 在头部插入是 O(n)，deque 两端都 O(1)）
dq = deque(maxlen=3)      # 定长：满了自动丢最旧
dq.extend([1, 2, 3, 4])   # deque([2, 3, 4])
dq.appendleft(0)
dq.popleft()

# Counter：统计神器
cnt = Counter("abracadabra")
cnt.most_common(2)        # [('a', 5), ('b', 2)]
cnt.elements()            # 展开成迭代器（按计数重复）
cnt.subtract("abra")      # 减法
Counter("aabb") + Counter("bbcc")   # Counter({'b':4,'a':2,'c':2})

# defaultdict：省去 "if key not in dd"
dd = defaultdict(list)
dd["users"].append("Alice")   # 不抛 KeyError
dd["score"]                   # []（默认工厂返回空列表）

# ChainMap：配置层层覆盖（不合并拷贝，查找按顺序）
defaults = {"host": "localhost", "port": 8080}
overrides = {"host": "prod"}
cm = ChainMap(overrides, defaults)
cm["host"]                    # 'prod'（先查 overrides）
cm["port"]                    # 8080（回退 defaults）
cm["host"] = "test"           # 只写入 overrides（第一个映射）

# OrderedDict：需依赖顺序语义时使用（如 LRU 实现）
od = OrderedDict()
od["a"] = 1; od["b"] = 2
od.move_to_end("a")           # 移到末尾

UserDict/UserList/UserString：需要继承并定制 dict/list/str 行为时，继承这些包装类比直接继承内置类型更安全（避免内置类型绕过重写的特殊方法）。

16. `dataclasses`

核心概念：@dataclass 是一个类装饰器，自动为你生成 __init__、__repr__、__eq__ 等样板方法，让你用声明式语法写数据类，少敲大量重复代码。

16.1 基础

from dataclasses import dataclass, field

@dataclass
class User:
    name: str
    age: int = 0
    tags: list = field(default_factory=list)   # 可变默认值必须用 default_factory
    active: bool = True

    def greet(self):
        return f"Hi, {self.name}"

u = User("Alice", 30)
u2 = User("Bob")
print(u)                  # User(name='Alice', age=30, tags=[], active=True)
print(u == u2)            # False（自动 __eq__）
u.tags.append("vip")      # tags 是独立列表

致命陷阱：默认参数若直接写 tags: list = []，所有实例会共享同一个列表（和函数默认参数陷阱一致）。必须用 field(default_factory=list)。

16.2 进阶选项

from dataclasses import dataclass, field, asdict, astuple

@dataclass(frozen=True)          # 不可变：禁止赋值，自动生成 __hash__
class FrozenPoint:
    x: float
    y: float

@dataclass(order=True)           # 自动生成 __lt__/__le__/__gt__/__ge__（按字段顺序比较）
class Rank:
    score: int = field(compare=True)
    name: str = field(compare=False)   # 比较时忽略 name

@dataclass
class Config:
    items: list = field(default_factory=list, repr=False)   # repr 中隐藏
    _cache: dict = field(default_factory=dict, init=False)  # 不在 __init__ 中

    def __post_init__(self):
        # __init__ 之后自动调用：做额外校验/推导
        if not self.items:
            raise ValueError("items 不能为空")

c = Config([1, 2])
asdict(c)                        # {'items': [1, 2], '_cache': {}}  转成普通 dict
astuple(c)                       # ([1, 2], {})

field 常用参数：default（不可变默认值）、default_factory（工厂函数，处理可变默认值）、init（是否进 __init__）、repr（是否进 __repr__）、compare（是否参与比较）、kw_only（Python 3.10+，强制关键字参数）。

16.3 与 `slots` 结合 & 与 namedtuple 对比

@dataclass(slots=True)           # Python 3.10+：自动加 __slots__，省内存
class Efficient:
    x: int
    y: int

维度	`namedtuple`	`dataclass`
可变性	不可变、可哈希	默认可变（`frozen=True` 才可哈希）
继承	不支持字段继承	支持字段继承
默认值	仅尾部可选	任意字段默认值、灵活
内存	最小（C 级元组）	普通对象；`slots=True` 后可接近
方法	需 `_replace`/`_asdict`	可自由定义方法

选型：仅做简单不可变记录 → namedtuple；需要可变性/默认值/继承/校验/序列化 → dataclass；需要运行时校验与序列化 → 考虑 pydantic。

17. 类型注解 (typing)

核心概念：Python 是动态类型语言，但类型注解（type hints）让你标注变量/参数/返回值的预期类型。注解运行时被忽略（不强制、不改行为），主要服务于静态检查器（mypy/pyright）、IDE 提示、和文档。

17.1 基础注解与容器

from typing import Optional, Union, List, Dict, Tuple, Callable, Any

def greet(name: str) -> str:
    return f"Hello, {name}"

def get_config(key: str) -> Optional[int]:   # int | None
    return config.get(key)

def process(data: Union[int, str]) -> str:   # int | str
    return str(data)

users: List[str] = ["Alice", "Bob"]          # 注意：仅注解，运行时不检查
scores: Dict[str, int] = {}
handler: Callable[[int, int], str] = lambda a, b: f"{a}+{b}"

Python 3.9+ 推荐：直接用内置泛型 list[str]、dict[str, int]、tuple[float, float]、X | None、X | Y，无需从 typing 导入容器类型。上面写法是为兼容旧版本。

17.2 泛型（TypeVar / Generic）

from typing import TypeVar, Generic

T = TypeVar("T")
U = TypeVar("U", int, str)        # 约束：只能是 int 或 str
B = TypeVar("B", bound="Sequence") # 上界：必须是 Sequence 的子类

class Stack(Generic[T]):
    def __init__(self):
        self._items: list[T] = []
    def push(self, item: T) -> None:
        self._items.append(item)
    def pop(self) -> T:
        return self._items.pop()

s = Stack[int]()
s.push(1)

17.3 结构化类型：`Protocol` / `TypedDict` / `Literal`

from typing import Protocol, TypedDict, Literal, NewType, cast, overload

# Protocol：鸭子类型的静态表达（运行时零开销，不需继承）
class Flyable(Protocol):
    def fly(self) -> None: ...

def takeoff(obj: Flyable) -> None:
    obj.fly()                    # mypy 只要对象有 fly() 就通过

# TypedDict：字典的结构化注解（字段名+类型）
class UserInfo(TypedDict):
    name: str
    age: int

u: UserInfo = {"name": "Alice", "age": 30}

# Literal：精确字面值集合
def set_mode(mode: Literal["read", "write", "append"]) -> None: ...

# NewType：创建"名义上不同"的类型（运行时是同一类型，仅静态区分）
UserId = NewType("UserId", int)
uid = UserId(42)

# @overload：为同一函数声明多种签名（实现里仍是单个函数）
@overload
def to_str(x: int) -> str: ...
@overload
def to_str(x: bytes) -> str: ...
def to_str(x):
    return x.decode() if isinstance(x, bytes) else str(x)

17.4 运行时与静态

import typing
def f(a: "list[int]", b: int = 0): ...

typing.get_type_hints(f)          # 运行时读取注解（解析前向/字符串引用）
# 输出如 {'a': list[int], 'b': int} —— 注解被保留在 __annotations__

要点：注解存在 obj.__annotations__，但不做强制。要真正检查，需 mypy your_file.py 或编辑器实时检查。PEP 563（3.10+ 默认）让注解延迟求值（from __future__ import annotations 在所有版本可用），避免循环引用与启动开销。cast(T, val) 只告诉检查器"当成 T"，运行时不改变 val。

18. 并发模型对比

核心概念：Python 有三种并发武器，选择取决于任务是 CPU 密集还是 IO 密集，根因是 GIL（下节详述）。

18.1 三种模型

import threading, time

# threading —— IO 密集型（sleep/网络/磁盘等待会释放 GIL，其他线程能跑）
def io_work():
    time.sleep(1)                          # 释放 GIL
threads = [threading.Thread(target=io_work) for _ in range(10)]
[t.start() for t in threads]; [t.join() for t in threads]   # 约 1s

# multiprocessing —— CPU 密集型（多进程绕过 GIL，真并行）
import multiprocessing as mp
def compute():
    return sum(i*i for i in range(10**7))
with mp.Pool() as pool:
    pool.map(compute, range(4))            # 4 进程并行，约 1/4 时间

# asyncio —— 高并发 IO（单线程，协程协作式，开销最低）
import asyncio, aiohttp
async def fetch(url):
    async with aiohttp.ClientSession() as s:
        async with s.get(url) as r:
            return await r.text()

18.2 选型表

场景	推荐	原因
CPU 密集（计算）	`multiprocessing`	多进程真并行，绕过 GIL
IO 密集（少量）	`threading`	等待 IO 时释放 GIL，共享内存简单
IO 密集（高并发 1000+）	`asyncio`	协程切换开销极低，单线程撑海量连接
混合	进程池 + 异步	CPU 与 IO 分离，进程跑计算、异步跑 IO
需要共享状态 + 简单	`threading` + `Lock`	但要注意竞态

18.3 共享状态的陷阱

import threading
counter = 0
lock = threading.Lock()

def inc():
    global counter
    for _ in range(100000):
        with lock:                 # 不加锁会出现竞态，结果 < 100000*N
            counter += 1

ts = [threading.Thread(target=inc) for _ in range(4)]
[t.start() for t in ts]; [t.join() for t in ts]
# 有锁时 counter == 400000

asyncio vs threading 心智模型：threading 是抢占式（OS 决定切换点，需锁保护共享数据）；asyncio 是协作式（只在 await 处切换，单线程无竞态，但不写 await 就占着循环）。asyncio 的优势在"海量连接"而非"单连接更快"。

19. 内存管理与 GIL

19.1 引用计数 + 分代垃圾回收

Python（CPython）用引用计数为主、分代 GC 兜底：

引用计数：每个对象存一个计数器，引用 +1 / -1。归零时立即回收。这是 Python 内存管理的主力，确定性高、开销小。
循环引用：引用计数无法回收（A 引用 B、B 引用 A，计数永不为 0），由分代垃圾回收器（generation 0/1/2 三代）定期扫描兜底。

import sys, gc
a = [1, 2, 3]
print(sys.getrefcount(a))       # 查看当前引用计数（调用本身会 +1）
print(gc.get_threshold())       # (700, 10, 10) 各代阈值
print(gc.get_stats())           # 各代回收统计
gc.collect()                    # 手动触发全量回收

19.2 `weakref` — 打破循环引用

弱引用不增加引用计数，常用于缓存、观察者，避免对象被"本应回收"的引用钉住。

import weakref
class Node:
    def __init__(self, val):
        self.val = val
        self.parent = None

n = Node(1)
r = weakref.ref(n)              # 弱引用
print(r() is n)                 # True（对象还活着）
del n
print(r() is None)              # True（对象被回收，弱引用失效）

19.3 GIL（全局解释器锁）

定义：CPython 同一进程同一时刻只有一个线程能执行 Python 字节码。哪怕多核，多线程 Python 代码在 CPU 密集任务上无法真正并行。

为什么会这样：CPython 的内存管理（引用计数）不是线程安全的，GIL 是保护它的简单方案。
何时有影响：CPU 密集任务被 GIL 限制（多线程退化为串行）；IO 密集任务在等待 IO 时会释放 GIL，多线程/异步仍能并发受益。
绕过 GIL：multiprocessing（多进程，真并行）、C 扩展（NumPy 等释放 GIL 做计算）、nogil 构建（PEP 703，Python 3.13+ 实验性"free-threaded"构建可禁用 GIL）。

19.4 `id()` / `is` 与对象身份

a = [1, 2]; b = [1, 2]
print(a is b)        # False（不同对象）
print(a == b)        # True（值相等）
print(id(a))         # 对象内存地址（进程内唯一标识）

is 比较身份（是否同一对象），== 比较值。常见误用：x is None（正确，单例）、x == None（不推荐）。注意小整数（-5~256）和短字符串会被 ** intern（缓存）**，所以 a = 256; b = 256; a is b 为 True——这是实现细节，不要依赖。

19.5 不可变对象与内存视图

int/str/tuple/frozenset 不可变：看起来"修改"其实是创建新对象。
memoryview / bytearray：零拷贝地切片/操作缓冲，处理大二进制数据时省内存。

20. 性能分析与优化

核心原则：先测量，再优化（"过早优化是万恶之源"）。用工具定位真正的瓶颈，而非凭直觉。

20.1 测量工具

import timeit, cProfile, pstats

# timeit：微基准（多次运行取均值，自动屏蔽噪声）
timeit.timeit("sum(range(1000))", number=10000)

# cProfile：函数级剖析（谁最耗时、调用几次）
cProfile.run("sum(range(10**7))", sort="tottime")
# CLI: python -m cProfile -s tottime your_script.py

# 更细：line_profiler（逐行）、memory_profiler（逐行内存）、py-spy（采样，生产无侵入）

cProfile 字段解读：tottime=函数自身耗时（不含子调用）、cumtime=含子调用总耗时、ncalls=调用次数、percall=单次平均。优先优化 tottime 高且 ncalls 大的函数。

20.2 常用优化手段（含原理）

import math

# 1) 局部变量缓存：循环内反复访问的全局/属性函数，先绑定到局部变量
#    避免每次都走 LEGB 查找链
_abs = abs
for x in range(10**6):
    _abs(x)

# 2) 列表推导 vs 循环 append：列表推导在 C 层循环，无每次 append 的属性查找
data = [x*2 for x in range(1000)]          # 快

# 3) " ".join() vs += 拼接：join 预计算总长一次分配；+= 字符串不可变，反复拷贝
parts = ["a", "b", "c"]
result = "".join(parts)                     # 快一个数量级

# 4) set/dict 查找 O(1) ：成员检查用 set 而非 list
haystack = set(big_list)
if item in haystack: ...                    # 比 "item in big_list" 快 N 倍

# 5) @lru_cache：缓存重复/递归计算
from functools import lru_cache
@lru_cache(maxsize=256)
def expensive(n): ...

# 6) __slots__：大量实例时省内存（见第 4 节）

# 7) 用内置与 C 扩展：sum/min/max/sorted、NumPy 向量化远快于手写 Python 循环
total = sum(values)                          # 而非手写循环累加

手段	原理	适用
列表推导	C 层循环，无 append 属性查找	数据转换
`str.join`	预计算总长，单次分配	字符串拼接
`set`/`dict` 查找	哈希表 O(1)	成员检查
局部变量缓存	避免 LEGB 查找链	循环内函数调用
`__slots__`	省 `__dict__`，属性访问略快	大量实例
`lru_cache`	记忆化，避免重复计算	递归/频繁调用
内置/NumPy	C 实现，向量化	数值计算

警告：大多数"优化"代价是可读性。+ 拼接一行字符串、普通 for 累加小幅数据，在绝大多数业务代码里完全够用。只针对 cProfile 指出的热点动手。必要时把热路径用 numba/Cython/C 扩展重写，而非在 Python 层抠细节。

21. 学习路线图

按由内到外、由基础到框架的顺序，建议分 9 步：

魔术方法 + 描述符（第 2、3 节）——先把对象模型吃透：知道属性从哪来、类怎么被创建、运算符如何被调用。这是理解后面一切的底座。
闭包 + 装饰器 + functools（第 5、6 节）——最常用、最立竿见影。闭包是装饰器的基础，@wraps、带参装饰器、缓存/重试是日常必备。
迭代器 + itertools（第 7、8 节）——理解 for 的底层，掌握惰性计算与组合工具，写高效数据流。
上下文管理器 + 生成器（第 9、10 节）——资源管理的标准范式（with），以及协程前身（yield/send）。
asyncio（第 11 节）——从手写协程过渡到原生异步；吃透 Task/Queue/gather/run_in_executor，避免阻塞陷阱。
super() + 元类 + ABC（第 12、13、14 节）——框架/ORM 的底层。以"理解其机制"为主，业务代码慎用元类，super() 单继承用法要熟练。
collections + dataclasses（第 15、16 节）——选对数据结构、用声明式减少样板代码，少写字多做事。
类型注解 typing（第 17 节）——提升可读性与可维护性，配合 mypy/Pylance 做静态检查，大型项目收益显著。
并发 + 内存/GIL + 性能（第 18、19、20 节）——定位性能瓶颈、正确选型（线程/进程/异步），用 cProfile/timeit 量化收益。

一句话心智模型：Python 里"类是 type 造出的对象（元类），方法/字段是描述符，协程是能挂起/恢复的调度单元（asyncio），__slots__ 是内存优化开关"。把这四点串起来，全部高级特性就不再是散点，而是一棵自洽的树。

Python 高级知识点完全指南（Markdown 版）| 2026-07 | 21 节 · 40+ 代码示例 · 9 幅图示 · 覆盖对象模型 / 函数式 / 元编程 / 执行模型 / 并发 / 数据结构 / 性能 | 建议在 Python 3.10+ 环境运行全部示例

豆包评测 05 篇：非确定性系统的测试思维

Orienjoy — Mon, 20 Jul 2026 07:50:15 +0800

做评测的人，本质是把用户替在前面用、替在嘴边说、替在手上试的那个人。用户不会写评测报告，但用户会感觉到一个事实：同一句话，豆包这次答得挺好，下次好像又差一点意思。这个「时好时坏」的体感，就是非确定性。评测人的第一份责任，是把这种模糊的体感，翻译成可判断、可交付的结论。

而要把这件事做对，得先接受一个传统测试人最难咽下的事实：豆包不是「输入 A 必得输出 B」的软件。你写的每一条用例，跑一次是一个答案，再跑一次可能又是一个答案，两个答案都能算对。上篇（04）讲到「同一版本跑两次分数都可能不同」时，埋下的就是这个根。本篇把这个根挖开：非确定性系统下，评测到底该怎么想、怎么动手。

二、六大范式转移：传统测试 vs AI 评测

传统软件测试那一套心法，在豆包面前一条条塌。先把最关键的六条对照摆出来，后面所有方法都从这六条长出来。

传统测试	AI 评测	关键差异
验证「对 / 错」	评估「好 / 坏」	没有唯一正确答案，只有更好的答案
追求 100% 覆盖率	追求风险分布覆盖	穷举不可能，按风险优先级抽样
一次性验证	持续监控	同一版本跑两次分数可能不同，需多轮取分布
用例即预期	用例即参考	测试用例不是标准答案，而是参考范围
Bug 定位到代码行	退化定位到维度与 case 类型	没有代码错误，只有能力退化
发布时间等于测试结束	发布时间等于监控开始	离线评测只是第一关，线上表现才是终局

这六条不是并列的。最底下那条「验证对错到评估好坏」是总开关，其余五条都是它的推论。所以下面篇幅不平均，重心压在「怎么从验证对错转向评估好坏」这件事上。

三、核心思维转变：从「找 bug」到「建标准」

传统测试的交付物，是一张 pass / fail 列表，旁边标着「这里错了」。AI 评测的交付物，应该是一张维度分数加分布加趋势的表，旁边标着：这个版本在 XX 维度比上个版本低了 3 分，95% 置信区间 ±1.5，达到退化告警阈值。

这两张单子的差别，就是评测岗和非确定性系统相处的方式。

为什么必须这么转？因为非确定性下不存在「唯一正确答案」。同一个问题，十种回答可能都算合格，只是有的更贴切、有的更啰嗦、有的更安全。你的工作不再是判断「它对不对」，而是判断「它够不够好、比上个版本好还是差、差多少、这个差是不是真的」。

落到日常，有一条纪律值得刻在评测报告模板上：结论落到分布和趋势，不落到单次对错。单次跑出的一句「答错了」，在 AI 评测里几乎不构成证据；但你连续五轮采样、看到某个维度均值稳定往下掉、置信区间还不重叠，这就是能写进交付意见书的硬结论。

四、落地一 · 多轮采样评分布

思维转过来之后，第一件要改的动手习惯是：别再跑一次就下结论，改为跑 N 次、看分布。

为什么必须多轮？因为豆包的输出天然带采样。解码时的 temperature、top-p，检索增强时召回的文档集合，调用工具时的环境状态，甚至并发和 batch 的微小差异，都会让同一条输入两次产出不同结果。这不是 bug，是模型的本性。一次采样看到的，只是这个分布里的一个点，拿一个点当结论，和拿一次抽奖结果说「这个彩票不中奖」一样不可靠。

实操上，我把配置拆成几件具体的事。

采样次数。关键 case 至少跑 3 到 5 次。学界评测代码类任务常取 5 次以上，业务评测可据置信度要求定，但低于 3 次基本没法定分布。

固定随机性。明确写清 temperature 取值；temperature 设成 0 能压低随机性，但仍可能因 batch 组合、并发顺序出现细微差异，不能当成完全确定。框架支持的话固定 random seed，便于别人复现你这次的结果。

报告区间，不报告单点。每次评测给出维度均值、标准差，以及 95% Bootstrap 置信区间（Bootstrap 由 Efron 1979 提出，用重采样估计区间，不依赖正态假设，适合小样本）。一个维度「本次 4.2 分，95% CI [4.0, 4.4]」比「本次 4.2 分」信息量高出一个量级。

指标选择。连续质量分看均值加区间；代码类任务看 pass@k（跑 k 次中至少 1 次通过的比例，HumanEval 体系由 Chen et al. 2021 确立），它天生就是在非确定性下定义的指标，比单次 pass / fail 更贴实际。

判法。单条 case 永远不下结论。维度层面看分布；如果发现两次跑结果差很多，先区分是模型非确定性还是评测代码问题：换机器、换时间、代码没动，结果仍然漂移，多半是模型采样；同条件下方差异常大，查采样配置和评分脚本。退化判定用这条：本版某维度均值较上版低了 X%（比如 ≥ 3%），且 Bootstrap 置信区间不重叠，才算一个真实退化信号，值得拉响告警。

数据来源。采样次数、区间计算都能在本地复算，不依赖外部；Bootstrap、pass@k 的方法出处标在文末参考。评测记录里必须存下 temperature、seed、采样次数，否则别人无法复现，你也分不清「模型变了」还是「配置变了」。

五、落地二 · 风险优先覆盖

第二件要改的习惯是：别再追求覆盖率，改为按风险排序抽样。

传统测试里「覆盖率」是个光荣指标，分支覆盖、行覆盖越高越安心。到了非确定性系统，输出空间几乎无限，你永远穷举不完。继续追覆盖率，只会把精力平均撒在大量低价值 case 上，真正高危的场景反而覆盖不足。

正确做法是按业务影响排优先级。我习惯用一张风险矩阵把场景排出来：

场景	影响面（用户量 / 关键度）	发生概率	优先级	抽样条数
核心对话、支付相关	高	高	P0	全量 + 高覆盖回归集
常见任务、查询	中	高	P1	中等覆盖 + 定期轮换
长尾知识问答	低	中	P2	按风险抽 + 私有保留题
极端边界输入	低	低	P3	少量探活

判法有两条。第一，P0 场景必须有专门的回归集，每次版本发布都跑，不允许「这次太赶先跳过」。第二，长尾不靠穷举，靠私有保留题加线上监控补（保留题的做法在后面持续监控一节会接上）。

数据来源。优先级不是拍脑袋，来自业务埋点、用户反馈分类、历史缺陷分布。哪个场景投诉多、哪个维度历史波动大，哪个就排前面。评测人要做的是把这份业务风险地图，翻译成评测集的抽样权重。

六、落地三 · 持续监控替代一次性验收

第三件要改的习惯最反直觉：别把发布当成测试的终点，当成监控的起点。

非确定性系统的「坏」常常发生在发布之后。环境在变、检索的文档在变、用户用法在变，更隐蔽的是版本更新带来的「无声退化」：豆包版本迭代很密（截至 2026 年 7 月，仍保持高频更新节奏），某些维度可能悄悄掉一点，单次发布评测未必抓得住，等用户投诉上来才发现。所以发布时间等于监控开始，不是测试结束。

落地形态我拆成三块：

保留 golden set。挑一批核心回归 case 存进版本库，每次版本发布、每周定时跑，跟踪各维度均值和区间的走势。它不追求覆盖全，追求稳定可比。

影子评测。把线上真实流量复制一份进评测通道，不干预用户，只打分。这能抓到离线评测集碰不到的真实分布。

告警接 CI。趋势告警看均值加区间是否不重叠，单点波动不告警（噪声会制造狼来了）。阈值要按指标类型区分，这方面业界已有成熟做法（也和 01 篇产品质量红线一脉相承）：Rubric 0 到 5 分指标，黄灯 ≥ 0.15 分下降、红灯 ≥ 0.3 分下降；Pass Rate 类，黄灯 ≥ 2 个百分点、红灯 ≥ 5 个百分点下降；延迟类，黄灯 P95 ≥ 10%、红灯 P95 ≥ 20% 上升。所有退化告警必须附 Bootstrap 95% 置信区间，否则没法判断是真的退化还是采样噪声。

数据来源。线上日志采样加评测 Pipeline 加 CI 系统。监控不是评测团队单干，要和产品埋点、算法发布流程打通，退化信号才能流到该做决策的人那里。

七、原理补一刀：非确定性从哪来

前面给了方法，这一节补一点原理，帮你判断「该采多少次样、阈值定多严」，而不是凭感觉。

非确定性的源头主要有四类。解码采样，temperature 和 top-p 直接决定输出的随机程度。检索增强，RAG 每次召回的文档集合可能不同，答案随之浮动。工具调用，环境状态、接口返回顺序都会变。并发和 batch，即使 temperature 设 0，底层调度仍可能引入细微差异。

对应的统计基础要记几个词。分布和单点，永远看分布。方差和标准差，衡量一次采样的离散程度。置信区间，95% 对应 Z 值 1.96，告诉你「真实均值大概率落在这个范围」。p 值，判断两次差异是否显著，还是只是噪声。Kappa 一致性（Cohen 1960 提出），衡量评分者之间的一致性，评测里常用它看评分 Agent 稳不稳，一般 ≥ 0.6 算可接受、≥ 0.8 算好。

理解这些，你才不会犯两个错：采样次数太少就下结论（方差大、区间宽，什么也说明不了），或者阈值定得太严（把正常波动当退化，团队被狼来了搞疲）。

八、业界是怎么做的

这套「建标准、看分布、持续监控」不是我个人的偏好，业界已经有扎实的验证，举两个最相关的。

一个是基准本身的有效性审计。UIUC Kang Lab 2025 年提出 Agentic Benchmark Checklist（简称 ABC，43 项条目，从 17 个主流 agent 基准提炼），把它套到 10 个广泛使用的 agent 基准上，结果是：7 个存在任务有效性缺陷（即任务能被不具备目标能力的捷径 agent 通过），7 个存在结果有效性缺陷（评分并不能真实反映任务成败），10 个全都有报告透明度问题。连基准这个分数本身都会失真，更说明评测不能盯着一个点，要建标准、看分布。这一点和 04 篇的核心判断一致：基准分数高不代表就能交付，分数本身也需要被审视。

另一个是 LLM 当裁判。Zheng et al. 2023（NeurIPS，arXiv:2306.05685）系统证明，强模型当裁判（GPT-4 级别）与人类偏好一致性超过 80%，达到人类评审之间的同意水平，LLM-as-a-Judge 才成为可信方法。但同一篇也指出 position、verbosity、self-enhancement 三类偏置必须缓解。落到非确定性评测，一个通行做法是评分 Agent 跑多次取中位数，因为对同一 case 多次评分稳定一致，比一次评得「准」更重要，稳定性优先于单次准确性。

还有 Bootstrap 置信区间报告，早已是学界和工业界评测报告的标配，不再单列来源。这几条拼起来，印证本篇的方法不是野路子。

九、四个典型误用

方法讲完，列四个评测人最常踩的坑，都是前面内容的反面。

第一，单次跑下定论。跑一次看到一句不好的回答，就写「该场景不达标」。正确做法：多轮采样取分布，单点不构成证据。

第二，综合分掩盖分布。一个 4.2 的综合分很好看，拆开看安全维度只有 3.0，这 3.0 才是能不能发的关键。这和 01 篇「能力分治、别用综合分盖住短板」是同一纪律，也和 04 篇拆基准分维度同源。

第三，抽样无风险权重。平均用力追覆盖率，P0 场景反而没覆盖够。正确做法：风险矩阵排优先级，高危场景全量回归。

第四，离线过了就放心。发布评测绿了就觉得万事大吉，忽视线上监控，无声退化上线后才爆。正确做法：发布等于监控开始，golden set 持续跑。

十、建一套非确定性评测 SOP

把前面四、五、六、七、八拧成一份能直接落地的清单，评测新人照着建就不会偏。

1. 采样配置卡。每次评测记录 temperature、seed、采样次数（默认 5）、是否固定随机性。没有这张卡，结果无法复现，你也分不清模型变了还是配置变了。

2. 置信区间与退化阈值模板。报告 95% Bootstrap 置信区间；退化告警阈值写清楚：维度均值下降 ≥ X% 且区间不重叠才算信号。附一个样例字段：维度名 / 上版均值 / 本版均值 / 下降幅度 / 本版 CI / 是否告警。

3. 风险矩阵模板。场景、影响面、发生概率、优先级、抽样条数，五列一张表（见第五节），每次建评测集先填这张表。

4. 监控接入 CI。golden set 每周定时跑，趋势告警挂进 CI；评分一致性校验：评分 Agent 对同一 case 跑 3 次，标准差 ≤ 0.5，否则分数不可信、不能做回归对比。

5. 复用纪律。评测集、配置卡、阈值模板全部进版本库。任何人、任何机器、同条件跑，必须得到同一结果，这是评测工程化的第一原则（可复现）。

给一个可直接抄的采样配置示例，评测脚本头部写清：

eval_config:
  temperature: 0.7
  seed: 20260720
  n_samples: 5
  metric: rubric_0to5 + bootstrap_ci_95
  regression_set: golden_set_v3
  degrade_alert: mean_drop >= 0.15 (yellow) / 0.3 (red) with non-overlapping CI

这几条凑齐，非确定性系统评测就从「靠感觉」变成「有标准、有分布、有监控」。

下篇预告

这篇把非确定性下评测的核心范式立住了：从「找 bug」转向「建标准」，三条落地策略是多轮采样评分布、风险优先覆盖、持续监控替代一次性验收。但你可能心里还有一个更实际的问题：我一个传统测试转过来的人，具体要补哪些能力、原来那些用例设计、缺陷管理、自动化的本事哪些能直接复用？下篇讲算法评测 vs 传统测试：你的能力账本，把现有技能和新增要求对照起来，画一条能执行的学习路径。

作者注：本系列是一边工作、一边实操、一边琢磨着写出来的，规划约 100 篇，内容和篇幅会随实际调整；为保证文章质量，不追求固定的更新频率。以上内容基于脱敏内部信息、公开权威资料和自己踩坑后的理解，不一定对，欢迎拍砖。

参考与延伸

UIUC Kang Lab. Establishing Best Practices for Rigorous Agentic Benchmarks (2025). Agentic Benchmark Checklist (ABC). https://uiuc-kang-lab.github.io/agentic-benchmarks
Zheng L. et al. Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena. NeurIPS 2023. arXiv:2306.05685
Chen M. et al. Evaluating Large Language Models Trained on Code (HumanEval / pass@k). 2021.
Efron B. Bootstrap Methods (1979). Cohen J. A Coefficient of Agreement for Nominal Scales (Kappa, 1960).
跨篇：01 篇（五大能力 taxonomy、产品质量红线、能力分治），04 篇（基准分是准入证不是通行证、拆维度看最弱项）。

一文看懂 Claude Code Dynamic Workflows

Fhaohaizi — Sun, 19 Jul 2026 13:28:29 +0800

Anthropic 在 2026 年 5 月底给 Claude Code 加了一个新功能：Dynamic Workflows。它还处在 research preview 阶段，但设计方向很有意思。用一句话概括，就是让 Claude 现场写一份 JavaScript harness，把多 agent 编排逻辑放进代码里执行，而不是把所有协调规则继续塞进模型的上下文窗口。

这和此前在 Claude Code 里开几个 subagent 并行不太一样。Dynamic Workflows 不是简单地让多 agent 更强，而是把协调和判断拆开：模型负责判断，每个子任务由独立 subagent 处理；代码负责协调，循环、分支、合并、终止条件都由 harness 管起来。这样一来，主 session 不必把每个分支的细节都塞进上下文里，真正需要模型判断的地方才交给模型。

这篇文章按官方博客和文档梳理它的设计动机、工作方式、六种编排模式、典型使用场景，以及什么时候不该用它。

为什么需要 Dynamic Workflows

Claude Code 的默认 harness 是为编码任务设计的。模型在同一个上下文窗口里既要规划，也要执行。对绝大多数编码任务来说，这已经够用；但 Anthropic 自己指出，当任务变成长周期、大规模并行、高度结构化，或者带有明显对抗性时，默认 harness 会出现三个具体失败模式。

Agentic laziness（agent 偷懒）指的是 Claude 在多部分复杂任务里，还没有完成所有部分，就提前宣布已完成。官方举的例子是 security review：清单里有 50 项要查，Claude 处理完 35 项就停了。

Self-preferential bias（自我偏好）指的是让 Claude 验证或评判自己的产出时，它更容易给自己开绿灯。这在同一个 session 里既做又评的时候尤其明显。

Goal drift（目标漂移）指的是 session 跑久之后，原始目标会在压缩中逐步流失。每一次 context compaction 都有信息损耗，edge case 的需求，或者不要做 X 这类约束，很容易在后半程变弱。

Dynamic Workflows 的解决方式不是再写一段更长的 prompt，而是做结构性拆分：把任务交给多个独立 subagent，每个 subagent 拿到自己的上下文窗口和明确隔离的目标，再用代码协调它们。

它实际怎么工作

一个 dynamic workflow 本质上是一段 JavaScript 文件。文件里有几个特殊函数，用来 spawn 和协调 subagent；同时也能使用标准 JavaScript 能力，比如 JSON、Math、Array 等，用来做数据处理、排序、循环和判断。

几个实现细节值得记住：

可选模型：workflow 可以指定每个 subagent 用哪个模型，比如重活儿用 Opus，轻活儿用 Sonnet 或 Haiku
可选 worktree 隔离：subagent 可以跑在自己的 git worktree 里，避免互相改同一份工作区
可恢复：如果 workflow 被用户操作或终端退出中断，恢复 session 后可以从中断点继续

这套设计有一个关键差别：代码执行不消耗主上下文窗口。也就是说，主 session 不需要记住每个分支的细节，只需要让 harness 维护执行顺序和状态。这就是 workflow 能支撑比普通 subagent 并行更大规模编排的原因。

动态与静态 Workflow

如果你之前用过 Claude Agent SDK，或者用 claude -p 串接多个 Claude Code 实例，那更接近静态 workflow。静态 workflow 能跑，但为了覆盖所有边界情况，脚本通常会写得比较通用，也比较啰嗦。

Dynamic 这个词的关键含义是：Claude Opus 4.8 已经足够聪明，可以针对眼前这个具体任务现场写一份定制 harness。它只覆盖这次需要的逻辑分支，不为通用性付出额外代码膨胀。一次迁移涉及三个模块，就写三个模块的 harness；一次博客事实校验需要逐条 claim 验证，就写逐条声明验证的 harness。

所以 dynamic 和 static 最本质的差别，不是有没有 workflow，而是harness 是否和当前任务一一对应。

触发方式

按官方说法，触发 dynamic workflow 主要有两种方式。

第一种是直接让 Claude 做一个。你可以用自然语言说 use a workflow 或 make a workflow。

第二种是使用触发词 ultracode。在 prompt 里包含 ultracode 这个词，Claude Code 会把它识别为为当前任务写 dynamic workflow harness的明确信号。

第二种可以理解为第一种的简写。文档里还提到 session 级设置 /effort ultracode，它会让整个 session 内的实质性任务自动启用 workflow。不过这个开关风险更大，一句话可能展开成多个连续 workflow，建议只在明确要处理大任务时使用。

六个编排模式

官方博客列了六个可组合的 pattern。Claude 会根据任务自己选择组合，但理解这些 pattern 能帮你写出更清楚的 prompt。

Classify-and-act（分类后行动）。先用一个 classifier agent 判断任务类型，再 route 到不同 agent 或行为。也可以把 classifier 放在末尾，让它决定输出哪个结果。

Fan-out-and-synthesize（扇出 + 综合）。把任务切成很多小步骤，每步 spawn 一个 agent，最后由 synthesize 步骤把结果合并。synthesize 是一个 barrier，它会等待所有 fan-out agent 完成，再把结构化输出合成最终结果。它适合步骤多、每一步都需要干净独立上下文的场景。

Adversarial verification（对抗性验证）。每个 spawn 出来的 agent，都配一个验证 agent，按 rubric 或标准对它的输出做对抗性校验。

Generate-and-filter（生成 + 筛选）。先生成一批候选，再用 rubric 或验证 agent 过滤、去重，最后只返回质量最高且经过验证的结果。

Tournament（锦标赛）。spawn N 个 agent，让它们各自用不同方法尝试同一个任务，再用 judging agent 做 pairwise comparison，最后跑出冠军。它比让一个 agent 直接打绝对分更稳，因为成对比较通常比绝对评分可靠。

Loop until done（循环到完成）。对于工作量未知的任务，循环 spawn agent，直到 stop condition 满足，比如没有新发现，或者 log 里没有更多错误，而不是预先写死执行轮数。

典型场景

官方博客给的场景列表很有参考价值。下面按类别梳理，每个场景配一两个示例 prompt，方便你直接迁移到自己的任务里。

迁移和重构

Bun 项目从 Zig 重写到 Rust 用的就是 workflows。做法是把任务拆成一系列要操作的步骤，比如 call site、failing test、模块等。每个 fix 起一个 subagent，在独立 worktree 里修改；再起一个 review agent 做对抗审查，最后合并结果。

示例 prompt：

把代码库里所有的 User model 重命名为 Account
Spring Boot 升 3.0，遍历所有 deprecation 警告并分别修复

这里有个小技巧：让 agent 不要跑资源密集型命令，这样更容易把并行度吃满。

深度研究

Anthropic 自己发布的 /deep-research skill 就是用 dynamic workflows 实现的。它会扇出 web search、抓取 source、对抗性验证 claim，最后综合出一份带引用的报告。

这个 pattern 不只适合 web search。你也可以用它从 Slack 历史里整理状态报告，或者通过并行读代码来理解某个 feature 的实际实现。

深度核验

如果你有一份报告，需要核实里面每一条事实性声明，可以开一个 workflow：先让一个 agent 抽出所有 claim，再给每条 claim spawn 一个 subagent 单独深查源头。还可以额外加 verifier agent，检查引用源头本身是否可靠。

示例 prompt：

把这篇博客草稿里的每一条技术声明都拿到代码库里验证一遍，不能发错
对照原始数据校对这份分析报告的所有数字

定性排序

当你要按某种定性标准排序大量条目时，比如把 1000+ 条 support ticket 按 bug 严重度排序，直接让 Claude 一口气排，质量会下降，上下文也装不下。更适合的做法是 tournament、pairwise comparison 流水线，或者先 bucket-rank 再合并。

这里的关键点是，每次比较都可以成为一个独立 agent；循环逻辑维护 bracket，主上下文里只保留运行顺序。

示例 prompt：

80 份简历，开 workflow 按后端岗位匹配度排序，前十名再核一遍
200 条 bug report 按严重程度排序

规则遵守

如果有一些规则你发现 Claude 总是漏，即使写进 CLAUDE.md 也不稳定，可以在 workflow 里给每条规则配一个 verifier agent。每条规则对应一个验证器，再配一个 skeptic persona agent 审查规则本身，降低 false positive。

反方向也可以：挖最近的 session 和 code review 评论，找你反复纠正的同类问题。多个 agent 并行聚类，再对每个候选规则做对抗性验证：如果当时有这条规则，能不能阻止那次真实失误？幸存下来的规则再整理回 CLAUDE.md。

根因调查

调试最有效的方式，往往是同时提出几个独立假设并测试。单个上下文窗口里，Claude 容易被最早的假设带偏；workflow 可以从结构上减少这种自我偏好。

做法是根据互不重叠的证据 spawn agent，让它们各自生成假设，比如 log 一个、文件一个、数据一个。每个假设再过一组验证者和反驳者的评审。

这不仅适用于代码，也适用于销售、数据工程和 post-mortem。比如 3 月份销量为什么掉了，这条 pipeline 为什么失败，或者某个事故根因为什么一直没有收敛。

示例 prompt：

这个测试 50 次里挂 1 次。开 workflow 复现它，提出互相竞争的几个 race 假设，直到一个假设站得住为止

规模化分诊

每个团队都会遇到 support queue、bug 报告，或者其他超出人力处理上限的 backlog。分诊 workflow 可以为每个条目分类，和已有条目去重，然后决定下一步动作：尝试修复，或者升级给人工。

这里有一个有用的 pattern 叫 quarantine（隔离）：禁止读取非可信公共内容的 agent 做高权限操作，把高权限动作交给另一组只基于已整理信息行动的 agent。

如果配合 /loop，Claude 可以持续做这类分诊工作，而不是只跑一轮。

探索和品味

命名、设计、文案方向这类任务带有品味判断。workflow 的用法不是让一个 agent 想一个答案，而是让它探索一批方案，再用 review agent 拿 rubric 评估。如果 review agent 认为满足标准就结束；如果候选之间差异明显，也可以通过 tournament 选出最优。

示例 prompt：

我要给这个 CLI 工具想个名字，开 workflow 头脑风暴一批选项，再跑 tournament 选出前 3
做一份落地页 hero section 的 5 种文案方向，按 rubric 评分挑最优

评估

Dynamic Workflows 也适合跑轻量 eval。你可以在 worktree 里 spawn 独立 agent，再 spawn 比较 agent，按 rubric 对各自输出打分。例如评估一个 skill 是否稳定达到标准，再根据评估结果迭代 skill。

模型路由

有些任务并不是一开始就知道该用哪个模型。可以先调出一个 classifier agent，由它研究任务规模、文件数量、工具调用需求，再决定后续用 Sonnet、Opus 还是更轻量的模型。

比如解释 auth 模块怎么工作，该用 Sonnet 还是 Opus，取决于 auth 模块有多少文件、代码路径多复杂、是否需要跨模块推理。classifier agent 先做这点调研，再 route 到合适的模型。

什么时候不该用

官方明确说了：workflow 是新东西，在不少场景下会产生超额收益，但它不是每个任务都需要，并且可能显著增加 token 消耗。

最直接的检验问题来自官方原文：它真的需要更多计算吗？

大多数传统编码任务并不需要一个 5 人审稿团。比如：

已经定位到的单 bug 修复
写一个明确 spec 的小 feature
单文件 refactor
翻译润色一段文字
写一个 hook 脚本或一段 SQL
来回讨论方案选型

如果每个 turn 都展开成 workflow，体验反而会变得笨重。更合理的做法，是把 workflow 用在过去 Claude Code 做不好、做不稳或者做不到的任务上，而不是把它当成普通任务的升级版。

实用技巧

详细 prompt。Dynamic workflow 对 prompt 细节比平常更敏感。你可以按前面的六个 pattern，把任务拆分方式、验证标准、终止条件和预算说清楚，效果会更稳定。

Quick workflow。Workflow 不一定只服务大任务。你可以 prompt use a quick workflow，比如对这个假设做一次快速对抗审查。轻量 workflow 也是合法用法，关键是它确实需要独立视角或明确循环。

配合 /goal 和 /loop。可重复执行的 workflow，比如 triage、research、verification，可以配 /loop 周期跑；配 /goal 设硬完成条件，避免流程越跑越散。

Token budget。可以为 dynamic workflow 设显式 token 预算。在 prompt 里写 use 10k tokens，会被识别为硬上限。这是控制 workflow 跑飞的直接手段。

保存和分享。在 workflow 菜单里按 s 保存。可以提交到 ~/.claude/workflows，也可以通过 skill 分发：把 JS workflow 文件放进 skill 目录，在 SKILL.md 里引用它们。Anthropic 建议把 skill 里的 workflow 当作模板，而不是逐字执行的固定脚本，这样跨项目更灵活。

入门提示词

下面几个是从官方原文里挑出来的 prompt 起点，覆盖不同 pattern。你可以照着改成自己的版本。

复现 flaky test：开 workflow 复现一个偶发失败的 race，提出互相竞争的几个假设，直到一个假设站得住为止
从 session 历史里抽规则：开 workflow 翻最近 50 个 session，挖出你反复在做的纠正，把高频问题整理成 CLAUDE.md 规则
大规模重命名：开 workflow 把代码库里所有 User model 重命名为 Account
从 Slack 里挖隐藏问题：开 workflow 翻过去半年的 #incidents 频道，找出反复出现但没人开过 ticket 的根因
多视角拆解商业计划：开 workflow 让不同 agent 分别从投资人、客户、竞品视角拆解商业计划
文章事实核验：开 workflow 把博客草稿里每一条技术声明拿到代码库里验证一遍
品味类决策：开 workflow 头脑风暴一批名字，再跑 tournament 选出前 3
简历排序：开 workflow 把 80 份简历按某个岗位排序，前十名再核一遍

这些 prompt 来自 Anthropic 博客作者的实际使用经验，代表性比较强。

版本与可用范围

需要 Claude Code v2.1.154 或更新版本
Claude Code CLI、Desktop、VS Code 扩展上可用
覆盖 Max、Team、Enterprise 计划，Enterprise 需管理员开启，也覆盖 Claude API、Amazon Bedrock、Vertex AI、Microsoft Foundry
Pro 计划可能需要手动激活
仍在 research preview 阶段，行为可能调整

结语

回到开头那句概括：Dynamic Workflows 让 Claude 现场写一份 JavaScript harness，把多 agent 编排逻辑放进代码里执行。

如果你之前用过 Claude Agent SDK 写静态 workflow，或者在一个 session 里手动开过几个 subagent，dynamic workflows 把这两种模式都重新定义了一遍：前者从提前写一套通用 harness，变成用时即写一份专用 harness；后者从在主上下文里编排，变成把编排搬到代码里。

但它不应该成为日常 default。这一点 Anthropic 自己反复强调：think creatively。把它用在以前 Claude Code 做不好、做不稳，或者做不到的事情上，而不是把它当成普通任务的升级版。判断标准依然是那句话：它真的需要更多计算吗？

相关阅读

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

豆包评测 04 篇：豆包在标准评测基准上的表现怎么看

Orienjoy — Sun, 19 Jul 2026 08:16:30 +0800

上一篇把 JD 里的术语拆成了速查表，核心是「术语变了，你的评测方案改什么」。术语这关过了，紧接着就撞上一个几乎每天都要面对的问题：满屏的基准分数，MMLU、GSM8K、SuperCLUE、SuperGPQA，到底哪个能信、信到什么程度、能不能拿它拍板发不发版。这篇专门讲这件事。

一、基准分到底是拿给谁看的

先摆一个容易被忽略的立场问题：一份基准报告，最终是给谁看的。

答案不是算法，也不是老板，是用户。用户不会自己去跑 MMLU，也看不懂 55 个学科的多选正确率意味着什么。他只关心一件事：这个版本装到我手机上、接进我业务里，到底比上个版本强还是弱。评测岗的活儿，说白了就是替用户把这件事先验一遍。用户没空把每个能力戳一遍，你替他戳；用户说不清「这次好像变笨了」是错觉还是真的，你替他把话讲清楚；用户懒得对着一堆榜单换算，你替他把「这分能不能信、能不能用」翻译成人话。基准分就是你手里的一件工具，不是终点。

所以看基准报告，第一反应不该是「豆包又拿了第一」，而该是「这个第一，能不能兑现成用户手里的体验」。这两件事经常不是一回事，中间隔着一段不小的距离。这篇要做的，就是把这段距离量出来，让你既不至于看到高分就盲信，也不至于因为「基准不可靠」就一概不看。基准有它确切的用处，只是得用在对的地方。

二、基准分和「能不能用」隔多远

举个真实会遇到的场景。某个版本在 GSM8K（小学数学应用题）上拿了 94 分，报告里写着「数学能力优秀」。你据此放行，结果上线后用户反馈：让它算个「三个人 AA 制、其中一个人只吃了一半」的账单，它算错了。

这不矛盾。GSM8K 测的是「规规矩矩出成题面的应用题」，用户的真实问题是「口语化、带缺省条件、还夹杂无关信息」的活场景。前者答对,不保证后者答对。分数没骗你，是你把分数的适用范围理解错了。

这种「分数高、体验差」的缝隙，来源大致有三类，后面几节会逐个拆：

第一类，测的东西和用的东西不是一回事。多选题测的是「四个选项里挑对的」，真实场景是「从零开始生成一段话」，两种能力不等价。第二类，题目本身已经被模型见过了（数据污染 / 泄露），高分是背出来的，不是推出来的。第三类，一个综合分把强弱维度平均掉了，短板被高分维度盖住，而用户偏偏踩在短板上。

一句话概括这一节：基准分是「考试成绩」，用户体验是「上岗表现」。成绩单能筛掉明显不行的，但不能替你保证一定能干活。评测岗的价值，就在于把这份成绩单读到位，读出它没写在分数里的那部分信息。

三、主流基准速查：各测什么、豆包大致在哪

先把常见基准摊开，按「测什么能力」归类，方便你拿到一份报告时快速定位它在测哪一块。下表的「豆包表现」一栏均为定性描述，具体分数随版本变动，以火山引擎官方口径为准（本篇数据截至 2026 年 7 月）。

基准	测什么	大致定位	读分时要留神
MMLU	57 个学科的多选知识题	已饱和，头部模型普遍破 90%	破 90% 后几乎失去区分度，只能当「及不及格」看
MMLU-Pro	MMLU 加强版，10 选项 + 更重推理	也在快速饱和，头部约 91%	比 MMLU 耐用，但同样在逼近天花板
GSM8K	小学数学应用题	前沿模型接近满分	只 8K 条且题型单一，区分度已很低
C-Eval / CMMLU	中文学科知识	国产模型普遍强项	偏学术，不覆盖日常对话 / 客服 / 创作
HumanEval	164 道 Python 函数题	常用但偏基础	题量小、有泄露风险，别单独下结论
GPQA Diamond	博士级科学推理，198 题	尚有区分度，头部逼近 85%+	题量小，单次波动要看多轮
SuperCLUE	中文综合（推理 / 代码 / 智能体等）	国内权威第三方月报	维度较粗，替代不了内部细粒度评测
SuperGPQA	285 个研究生学科、26529 题	长尾知识区分度高，未饱和	由字节 Seed 联合 M-A-P 开源，评自家模型时注意「自建基准」的立场
KOR-Bench	知识正交推理（新规则下推理）	专测「非背诵」的推理	考的是脱离预训练知识的临场推理
BeyondAIME	竞赛级数学，无标准答案题干	极高难度，解决 AIME 饱和	同为字节 Seed 自建，横向比要配第三方
LiveBench	月度更新的综合评测	防污染，动态刷新	适合追踪版本趋势，不适合跨月硬比绝对值
HLE（人类最后考试）	3000 道专家原创题	当前最难之一，顶尖模型仍低于 35%	防污染设计，专门用来「让还没饱和的能力有分可测」

这张表不用背，用的时候查。真正要记的是它背后的一条线索：基准是有寿命的。MMLU 从 2020 年好用到 2024 年被刷穿，MMLU-Pro 顶了一年又在饱和，GPQA Diamond 也在被逼近。所以 2024 到 2025 年，一批「抗饱和 / 防污染」的新基准接棒上来，MMLU-Pro、GPQA Diamond、SimpleQA（事实性精确问答）、LiveBench（月度更新）、HLE（专家原创超难题），构成了新一代参照系。你手里如果还只盯着 MMLU、GSM8K 的分数做判断，用的是一把已经量不出差别的尺子。

对豆包本体，可以定性记住几个坐标（截至 2026 年 7 月，以火山引擎与第三方月报口径为准）：中文综合能力在国产模型里处于第一梯队；SuperGPQA 这类长尾知识推理上，其 chat 版本曾在同类里排名靠前；数学、代码、Agent 等方向近一年迭代很快。具体到某个版本、某个基准的精确分数，一律以火山引擎开发者社区的一手口径为准、并标截至版本号；凡找不到独立第三方印证的，一律当「单一来源，待核验」，不进发布决策的硬门槛。

四、读懂一份基准报告的四步法

前面讲了基准是什么、主要有哪些、各自测什么，这一节讲最核心的手艺：拿到一份完整的基准报告，按什么顺序读、每步看什么、看到什么该踩刹车。这是全篇最该记住的部分，我按四步拆，每步都给可操作的判法和阈值。

第一步，看绝对值：先过「行业基线」这道闸。

拿到分数，先别关心排名，先问「达没达到能用的底线」。每个能力都有一条行业公认的基线，低于它连讨论排名的资格都没有。比如中文核心对话的正确率，业界一般把 95% 当准入线（换算成 5 分制大约 4.75 分），低于这条线的版本，无论其他维度多亮眼，直接标红。绝对值这一步的动作很硬：列出本次评测每个维度的分数，逐个和预设基线比对，低于基线的维度当场标红，不进后续讨论。基线要提前定死、写进评测方案，不能看到分数再倒推,否则等于没有基线。

第二步，看趋势：和上一版比，涨了还是跌了。

单个版本的绝对分意义有限，因为你不知道它是「本来就该这么高」还是「相比上版退步了」。真正有决策价值的是趋势。动作是：同一套评测集、同样的测试条件，把本版和上一版（最好再往前一版）的每个维度分数并排列出，算出每个维度的涨跌幅。这里有个容易被忽略的坑：非确定性系统同一版本跑两次分数都可能不同，所以趋势要建立在「多轮采样的均值」之上，不能拿两个单次分数直接相减。一般关键维度至少跑 3 到 5 轮，看均值和波动区间。判定退化不能只看均值差，要看「差距是否超出波动」。给一张可直接照抄的退化判定表：

维度	上版均值 (±波动)	本版均值 (±波动)	均值差	波动是否重叠	结论
多轮对话	88.0 ±0.6	84.8 ±0.7	−3.2	不重叠	真实退化，告警
代码	92.1 ±1.5	91.0 ±1.6	−1.1	重叠	落在噪声内，观察
安全	96.5 ±0.3	96.6 ±0.3	+0.1	重叠	无变化

判定规则就一条：均值差的绝对值要大于两版波动区间之和，退化才算数；差距落在波动内的，是采样噪声，不是能力变化，别误报。这张表每次版本对比都填一遍，退化告警就有了客观依据，不靠「感觉这版差了点」。

第三步，看维度分解：别让综合分骗了你。

这是四步里最能体现评测岗水平的一步。一个「综合 85 分」的报告，如果你只看这个总分就放行，很可能栽跟头。因为综合分是加权平均，它会把一个塌方式的短板，用其他高分维度平均回一个好看的数字。正确的读法是：永远把综合分拆回各个子维度，逐维度看，重点盯最低的那几个，而不是盯总分。举个能直接对照的例子，两个版本综合分一样都是 85，拆开却是完全不同的两回事：

维度	权重	版本 A	版本 B
知识问答	0.30	95	84
代码	0.25	92	86
多轮对话	0.25	88	87
安全	0.20	62	83
加权综合	—	85.0	85.0

同样是 85 分，版本 A 藏着一个 62 分的安全塌方，版本 B 各维度都均衡在及格线以上。如果只看综合分，这两版没区别；拆开看，版本 A 根本不能发，那个 62 分的安全维度一旦被用户踩到，知识问答的 95 分救不了它。所以维度分解这一步的纪律是：综合分只用来快速排序，真正的放行判断落在最弱维度是否触线，最弱维度没过线，综合分再高也阻断。

第四步，看外部验证：基准分要和线上表现对得上。

前三步都在报告内部打转，第四步要跳出报告,拿基准分去和真实世界对账。基准分再高，也只是离线成绩，用户满意度、线上 A/B 的核心指标才是终局。动作是：把离线基准的关键结论，和线上灰度 / A/B 的对应指标做交叉验证，看两者方向是否一致。如果离线基准说「这版对话能力涨了 3 分」，但线上灰度里用户的对话轮次、满意度反而跌了，那要么是评测集没覆盖真实场景，要么是有离线测不到的问题（比如延迟、格式错乱）。两者背离时，以线上为准，回头修评测集，因为线上是用户真金白银的反馈，基准只是它的近似。

这四步是有顺序的，不能跳。先用绝对值筛掉不及格的，再用趋势看有没有退化，再用维度分解揪出被平均掉的短板，最后用外部验证确认离线结论在线上站得住。四步都过了，这份报告才算读明白了。反过来，任何一步跳过，都可能让一个有硬伤的版本溜过去。

五、基准的三个坑：饱和、泄露、覆盖盲区

会读报告还不够，还得知道基准本身会在哪些地方失灵。三个最常见的坑，每个都给识别信号和应对动作。

坑一，饱和：分数逼近满分，尺子失去刻度。

识别信号：一个基准上，头部几个模型的分数都挤在 90% 以上，彼此差距只剩零点几个百分点。这时候这个基准已经量不出模型间的真实差距了，分数涨跌更多是噪声和过拟合，不是能力变化。MMLU 就是活生生的例子，2020 年它能拉开差距，2024 年头部普遍破 90%，再看它的分已经没意义。应对动作：给每个常用基准设一条「退役线」（比如头部模型普遍超过 90% 就标记为饱和），触线后换更难的替代集。MMLU 换 MMLU-Pro 或 GPQA Diamond，GSM8K 换竞赛级数学题（AIME / BeyondAIME 这类），把评测的刻度重新拉开。

坑二，泄露：题目被模型见过了，高分是背的。

识别信号：模型在某个公开静态基准上分数异常高，但换一批「同类型、没公开过」的新题就明显掉下来。这说明它可能在训练时见过原题，考的是记忆不是能力。这不是假想，业界研究发现过某些主流模型对在线题库答案的重复率高得可疑。公开、静态、长期不更新的基准，泄露风险最大。应对动作：优先用防污染基准（LiveBench 月度刷新、HLE 专家原创），并且给静态基准配一批自建的「私有保留题」。私有保留题的做法可以照抄：从每个公开基准里抽出题型、难度分布一致的一批新题，自己出、绝不公开、只在内部评测用；每次版本评测时，公开题和私有题各跑一遍，对比两者的分差。正常情况下同类型题分数应当接近，一旦出现「公开题分数明显高于私有题」，基本可以判定公开分被泄露污染了，这时公开基准的分数要降权处理，以私有题的分数为准。这批私有题还有个额外好处：它是你手里唯一不会被任何模型「背过」的干净尺子。

坑三，覆盖盲区：基准测的场景，压根不是你的业务场景。

识别信号：基准分很漂亮，但你的核心业务场景在这个基准里根本没被覆盖。比如你做的是儿童教育对话产品，而你参考的基准全是成人学术知识题，那分数再高也说明不了你最该关心的「跟小孩说话安不安全、合不合适」。这是最隐蔽的坑，因为它不表现为「分数不准」，而表现为「分数不相关」。应对动作：先画一张「业务场景 × 基准覆盖」的对照表，把你真正在意的场景逐个对到基准上，找出没有任何公开基准覆盖的空白格，这些空白格必须靠自建评测集补上。公开基准负责通用能力的下限,自建评测集负责你业务的真实场景，两者缺一不可。

这三个坑有个共同的解法思路：别把命压在单一公开基准上。公开基准做通用能力的粗筛和趋势追踪，自建 + 防污染基准做真实场景的细评，多把尺子交叉着用，单把尺子的失灵才不会直接坑到你的判断。

六、把基准分接进发布决策：准入证不是通行证

前面都在讲怎么把基准读准，这一节讲最后一公里：读准之后，这个分在「发不发版」的决策里，到底占什么位置。一句话立在这：基准分是准入证，不是通行证。

准入证的意思是，它能一票否决，不能一票放行。低于行业基线的维度，直接卡住发布，这是它的否决权，很硬。但反过来，基准分全部达标甚至领先，也只是拿到了「可以进入下一轮评估」的资格，不等于可以直接全量发给用户。这中间还差着线上验证、安全红线、性能门槛好几道关。把「基准分高」直接等同于「可以发」，是最常见、也最致命的误判。

落到具体的决策结构，基准分在里面扮演的是「入口筛子」的角色，大致是这样一条链路：

基准评测（离线）
   │  低于行业基线的维度 → 直接标红，阻断，不进后续
   ▼
安全 / 合规红线（硬阻断）
   │  安全漏过率、核心正确率等触线 → 红灯，禁止发布
   ▼
多维加权 + 趋势判定
   │  任一关键维度显著退化 → 黄灯，需评审
   ▼
线上灰度验证（5% → 20% → 50% → 100%）
   │  线上核心指标与离线结论背离 → 回滚，修评测集
   ▼
全量发布 + 持续监控

看这条链路能看清基准分的位置：它在最上游做粗筛，把明显不合格的挡在门外；但它下游还站着安全红线、退化评审、线上灰度三道关，每一道都能把「基准分很好看」的版本拦下来。基准分从来不是决策的终点，它只是决策的入口。

再补几条把基准分接进决策时最容易踩的反模式，都是能直接对照自查的：

唯综合分论：只看一个综合总分就拍板，不拆维度。前面说过，综合分会藏短板，这是头号反模式。
拿饱和基准当依据：还在用 MMLU、GSM8K 这类已饱和的分数论高低，尺子早就没刻度了。
自建基准自证：只拿自家做的基准证明自家模型强，不配第三方，逻辑上不成立。
离线分替代线上：基准分好就跳过灰度直接全量，把「考试成绩」当成了「上岗表现」。
无视版本漂移：拿不同测试条件（用没用工具、few-shot 轮数不同）下的分数直接横比，比了个寂寞。

避开这五条，基准分在你的决策里就摆对了位置：一个严格的准入筛子，而不是一张免检通行证。

七、建一套自己的「基准解读 SOP」

把前面几节收拢成一套能复用、能交给新人、能挂进流程的动作，这一节给一个可直接落地的骨架。

第一件事，建一本「基准台账」。把你所在业务用到的所有基准登记成一张表，每个基准记五个字段：测什么能力、对应哪个业务场景、当前是否饱和、数据是否公开（泄露风险）、一手出处链接 + 截至版本。给一个可直接套用的台账样例：

基准	测什么能力	对应业务场景	是否饱和	泄露风险	一手出处 + 截至
MMLU	通用知识	通用问答下限	已饱和	高（公开静态）	arXiv:2009.03300，仅当及格线
SuperGPQA	长尾学科推理	专业领域问答	未饱和	中	Seed 博客 +arXiv:2502.14739
LiveBench	综合（月更）	版本趋势追踪	未饱和	低（月度刷新）	livebench 官方，截至当月
自建私有题	本业务真实场景	核心场景细评	—	无（不公开）	内部，版本号随评测集

这张台账解决的是「我到底在用哪些尺子、每把尺子还准不准」的问题。新人来了，先读这张台账，就知道本业务的评测家底，也知道哪些分只能当参考、哪些分才能当依据。

第二件事，定「轮换机制」。给每个基准设退役线（比如头部普遍破 90% 判饱和），到线就换更难的替代集；静态公开基准每隔一个周期，用自建私有题做一次泄露体检，分差过大就降权或替换。这一步解决的是「尺子会过期」的问题，让评测参照系保持新鲜。

第三件事，列「准入证清单」。把每个能力的行业基线写死成一张清单，每次评测机械地逐条核对：这个维度过没过基线，过了打勾，没过标红阻断。清单化的意义是把「凭感觉判断能不能发」变成「照单核对」，谁来做结论都一样，可复现、可追溯。

第四件事，接进 CI。把上面这套变成自动化：每个版本一出，自动跑基准评测套件，自动和上一版比趋势、自动拆维度、自动核对准入证清单，低于基线或显著退化的自动亮红灯拦住，不靠人肉盯。基准评测一旦进了 CI，它就从「发版前临时跑一次」变成「每次提交都在跑」的常态防线。

这四件事做全，你就有了一套不依赖个人经验、可以交接、可以审计的基准解读体系。它的价值不在某一次评测，而在于让每一次评测的结论都稳定、可信、能追溯。这正是评测岗区别于「随手跑个分」的地方。

八、原理补一刀：基准为什么会失真

最后从原理上补一句，前面那些坑不是偶然的 bug，是有底层原因的，理解了原因，你对基准的信任边界会更清楚。

一是多选题和开放生成本就是两种能力。MMLU 这类多选题，模型只需在给定选项里排除错误、选出对的，这和「从零生成一段准确、通顺、无幻觉的回答」是两回事。多选考的是判别，生成考的是产出，判别强不代表产出强。所以多选基准的高分，天然不能外推到开放问答的质量。

二是数据污染是结构性的。互联网上的公开题库，很可能就在模型的训练语料里。模型见过原题，答对就成了背诵而非推理。只要基准是公开静态的，这个风险就永远存在，这也是为什么防污染基准要靠「持续更新」或「专家原创未公开」来对抗。

三是Goodhart 定律：当一个指标变成了目标，它就不再是个好指标。当整个行业都在冲某个榜单，各家自然会针对性优化，甚至提交多个变体只公布最高分。于是榜单分数的上涨，一部分来自真实能力提升，一部分来自「应试」。这就是为什么再权威的单一榜单也不能全信，必须靠人类盲测（LMSYS Arena 这类难以针对性优化的评测）和真实业务验证来纠偏。

理解这三条，你就明白基准为什么既有用又不能全信：它是对能力的一种低成本近似，近似就一定有偏差。评测岗的手艺，就是清楚这偏差在哪、有多大，然后在偏差之内用好它。

参考与延伸

本篇涉及的基准 / 榜单（引用时优先回溯一手出处）

通用知识：MMLU（arXiv:2009.03300）、MMLU-Pro、C-Eval、CMMLU
数学与推理：GSM8K、AIME、GPQA Diamond、BeyondAIME（ByteDance Seed，arXiv:2504.13914 提出）、KOR-Bench
长尾知识：SuperGPQA（ByteDance Seed 联合 M-A-P，arXiv:2502.14739，285 学科 26529 题）
代码：HumanEval、SWE-bench、SciCode、LiveCodeBench
综合 / 防污染：SuperCLUE（中文综合月报）、LiveBench（月度更新）、HLE 人类最后考试（CAIS + Scale AI，2025）
人类盲测与横评：LMSYS Chatbot Arena（ELO）、Artificial Analysis（性能 / 价格 / 质量）、智源 FlagEval

基准数据的可信来源（评豆包本体优先，截至 2026.07）

火山引擎开发者社区（豆包各版本评测数据与 Model Card 的官方出口，须标截至版本号）
字节 Seed 团队技术博客与 arXiv 论文（自建基准 SuperGPQA / BeyondAIME 等的一手方法与榜单）
第三方交叉印证：SuperCLUE 月报、LMSYS Arena、Artificial Analysis、智源 FlagEval

基准饱和与替代的机构出处（按需查证，非必查）

MMLU：UT Austin（Dan Hendrycks 组），大模型知识体检最广用的基准之一，已饱和。
GPQA / GPQA Diamond：博士级科学推理，题量小但区分度尚存。
HLE（Humanity's Last Exam）：Center for AI Safety 与 Scale AI 联合，专家原创、防污染，设计目标是「多年内不被刷穿」。
LiveBench：月度更新防数据污染的综合评测，适合追踪版本趋势。
SuperGPQA / BeyondAIME：字节 Seed 主导的自建基准，评自家模型时须配第三方交叉印证。

前文衔接

03 篇把 JD 术语拆成评测 / 产品视角速查表（RAG 分检索步与生成步、温度锁定、上下文窗口的评测含义等）
01 篇的五大能力 taxonomy 与产品质量红线（红线一票否决、能力分治不用综合分盖短板），本篇「准入证不是通行证」正是那条纪律在基准解读上的落地

下篇预告

这篇讲了怎么读基准分、怎么验数据可信度、怎么把它摆进发布决策的正确位置，核心一句：基准分是准入证不是通行证。但你可能已经注意到一个更底层的问题，前面反复提到「同一版本跑两次分数都可能不同」「关键维度要跑 3 到 5 轮取均值」。这背后是 AI 系统和传统软件最本质的区别：它不是确定性的。下篇讲非确定性系统的测试思维，传统测试那套「输入 A 必得输出 B」的假设在豆包面前会怎么崩塌，以及评测该怎么从「验证对错」转向「评估好坏与分布」。

AI 约会平台 Overtone 融资 1800 万美元，引入语音匹配模型；Sesame 语音智能体安卓测试版正式上线丨日报

RTE — Sat, 18 Jul 2026 19:57:50 +0800

开发者朋友们大家好：

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

本期编辑：@koki、@ 鲍勃

01 有话题的技术

1、多模态基础模型公司 Prana Labs 完成近千万美元种子轮融资：通过工业级刚软耦合物理沙盒，构建多模态「环境 - 数据 - 模型」闭环

多模态基础模型公司 Prana Labs 宣布完成近千万美元种子轮融资。该公司通过融合物理引擎、实时渲染与 3D 资产管线，构建具备真实物理约束、可交互且规模化生成的 3D 物理沙盒，旨在为下一代多模态基础模型提供高频「行动 - 反馈」的闭环训练与验证环境。

工业级刚软复合物理仿真引擎：底层支持刚性与软性材料的跨物理场景耦合及接触建模，重力、质量、弹性、摩擦系数等物理参数与真实物理世界对齐，提供具备因果律反馈的 3D 交互环境。
构建「环境 - 数据 - 模型」自循环飞轮：系统可根据单条文本或图像指令，规模化输出上千种布局、材质和物理参数各异的 3D 空间，低边际成本地供给包含视频、3D 几何、物理状态、动作轨迹和因果反馈的合成多模态数据。
多模态智能体的物理「编译器」：提供毫秒级「行动 - 反馈 - 修正」闭环，允许智能体在虚拟环境中进行碰撞、推拉等物理操作并接收反馈信号，解决传统多模态模型「仅能预测像素变化、无法理解物理交互」的训练盲区。
图形学与大模型训练跨界团队：核心成员来自 Anuttacon（米哈游创始人蔡浩宇创立）、米哈游、字节跳动 Seed、DeepMind 等，兼具数十万亿 Token 级别大模型数据工程经验与实时物理仿真管线研发能力。

( @Z Potentials)

2、通义实验室发布 Wan-Streamer v0.2 ：引入 Thinker-Performer 双通路架构，端到端延迟降至 550ms，视频分辨率升至 640×368

通义实验室正式发布端到端全模态实时交互模型 Wan-Streamer v0.2。该版本将语音、文本、视频的流式感知与生成统一在单个 Transformer 中，通过重构底层计算架构，在输出分辨率提升至 640×368 @ 25FPS 的同时，将端到端双向交互延迟（含 350ms 网络传输）控制在约 550ms。

「因果时间线」与 160ms 流式单元：废弃了传统的「语音识别 ➡ 大模型 ➡ 语音合成 ➡ 动画驱动」级联流水线，将多模态输入与智能体输出映射至统一因果时间线（Causal Timeline），以 160ms 为流式单元（Streaming Unit）进行循环，实现边听、边看、边生成的原生全双工交互。
Thinker-Performer 双通路物理隔离：系统解耦为负责低延迟任务的「思考者」（Thinker，单卡 GPU 部署，处理流式音视频感知、语言状态更新、K/V 缓存构建及音频解码）和负责重载视频生成的「执行者」（Performer，多卡并行），确保高分辨率生成不阻塞 200ms 的模型侧延迟底线。
Ulysses** 序列并行与音频直算 **：Performer 采用多 GPU 的 Ulysses 上下文并行集群对长视频序列进行切分与并行去噪；而由于音频 Latent 序列较短，系统不对其进行切分，直接计算以规避不必要的跨卡通信开销。
「快慢分工」时序重叠调度：单卡 Thinker 的工作窗口与多卡 Performer 的计算窗口在时序上高度重叠，即在 Performer 处理当前帧高清视频 Latent 的同时，Thinker 已在并行处理下一帧用户输入并解码上一帧音频，从而将视觉生成成本从延迟路径中剥离。
视频输出分辨率提升至 640×368 @ 25FPS：相较于 v0.1 的 192×336，v0.2 大幅提升了视觉精度，使模型不再局限于面部近景特写，可同步输出视线方向、身体姿态、自然手势及背景环境。

项目地址：

https://wan-streamer.com/

（@ 通义实验室）

02 有亮点的产品

1、消息称阿里千问首款 AI 智能体耳机将在 WAIC 亮相

7 月 16 日消息，据财联社报道，2026 世界人工智能大会（WAIC）期间，阿里巴巴旗下个人 AI 助手千问首款 AI 智能体耳机将亮相。

此前，千问曾宣布年内将推出多款不同形态的 AI 硬件产品，AI 耳机正是其中之一。接近千问 AI 硬件业务的人士表示，更多产品信息将在 WAIC 期间正式发布。

在 2026 年 3 月的世界移动通信大会（MWC）上，阿里巴巴旗下个人 AI 助手「千问」已高调进军硬件领域，并展示了千问 AI 眼镜。千问方面还计划年内推出 AI 指环、AI 耳机等产品，旨在打造软硬一体、跨多种终端的 AI 助手。

阿里巴巴在 AI 穿戴硬件领域并非首次尝试，其旗下首款自研 AI 眼镜「夸克 AI 眼镜 S1」已于2025年11月27日正式发布，该产品深度接入了「千问」和夸克 AI 能力，并融合了淘宝、支付宝、高德等阿里系核心服务。

在 AI 智能体领域，千问 App 于 2026 年 1 月上线了基于 MCP 和 A2A 协议的生活助理功能，通过接入阿里旗下服务，可实现点外卖、订机票、订酒店等任务，这为 AI 硬件提供了丰富的服务生态支持。

2026 世界人工智能大会暨人工智能全球治理高级别会议将于2026年7月17日至 20 日在上海举办，主题为「智能伙伴共创未来」，是全球人工智能领域最具影响力的行业盛会之一。

（@ 极客公园）

2、Sesame 安卓测试版现已正式上线

在五月推出 ios 测试版后，Sesame 的安卓测试版现已正式上线，并同步推出图片上传与语音备忘录功能。

已开放双平台下载，下载链接：

iOS： https://ses-a.me/yuq3euo2

安卓系统： https://ses-a.me/bx69xuih

( @sesame\@X)

3、AI 约会平台 Overtone 获 1800 万美元融资：废弃滑动匹配，引入语音多模态与关系学匹配模型

Hinge 创始人 Justin McLeod 成立新公司 Overtone 并宣布完成 1800 万美元融资，投资方包括其母公司 Match Group、FirstMark Capital 和 Pace Capital。该公司定位为新型 AI 约会/社交服务平台，旨在开发一款以语音/音频为核心的 AI 约会服务，通过 AI 深度解析用户的语音故事，彻底取代传统的滑动匹配和基于即时冲动的推荐算法，从而解决传统约会软件导致的用户匹配疲劳问题。

语音/音频原生解析（Voice- and Audio-Forward Service）：系统以用户的原生语音输入和口述故事为核心，通过 AI 提取声音特征、语调和叙事内容进行深度特征构建，而非依赖传统的静态照片、名言或结构化统计数据。
去滑动化异步交互（Anti-algorithmic Swipe Feed）：彻底废弃基于用户即时反馈（split-second impulses）训练的黑盒算法推荐流，不设置高频、多通道的点赞与即时聊天机制，以降低多线程交互带来的用户流失率（ghosting）。
关系科学匹配模型与透明化可解释性（Relationship Science Matching）：推荐系统基于人际关系学（relationship science）构建决策模型，对匹配结果进行高精度限额筛选，并在前端向用户提供透明化的 AI 决策解释，阐明匹配的具体逻辑。
跨行业专家治理结构：除 Match Group 首席执行官 Spencer Rascoff 和领导力顾问 Diana Chapman 外，关系学领域专家 Esther Perel 已正式加入 Overtone 董事会，协助优化匹配模型的理论框架。

( @TechCrunch)

03 有态度的观点

1、Figma 设计主管：AI 时代招聘门槛提高，设计师需用高保真作品证明自己

据报道，Figma 产品设计副总裁 Noah Levin 昨日在接受采访时表示，AI 工具的普及已显著提升了公司对产品设计岗位应聘者的考核标准。

Levin 指出，由于 AI 能够助力设计师在极短时间内创作出高质量且具交互性的原型，Figma 现在要求候选人必须具备利用最新 AI 工具展示「最高保真度」设计方案的能力。

Levin 回忆称，十年前受限于技术门槛，设计师很难产出与真实产品体验一致的原型。而如今，诸如 Lovable、Base44 和 Emergent 等 Vibe Coding 平台，以及 Canva 和 Wix 等传统工具的 AI 功能，已让高保真原型的制作变得触手可及。

他强调，应聘者不应落后于工作流的变革，Figma 期待看到候选人对新工具的积极尝试。不过，Levin 明确表示，这并不意味着公司接受「AI 垃圾」（AI slop）式的堆砌。他认为设计师的核心职责——解决用户问题与打磨工艺——并未改变。相比于完美的最终稿，他更看重候选人展示那些被舍弃的失败原型。

( @APPSO)

04 社区黑板报

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

1、活动推荐：WAIC 活动报名｜7.18 具身智能创业者之夜

写在最后：

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

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

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

Thinking Machines 开源首款大模型 Inkling，原生多模态；Hume AI 发布 Real World VoiceEQ 基准丨日报

RTE — Sat, 18 Jul 2026 18:34:19 +0800

开发者朋友们大家好：

本期编辑：@koki、@ 鲍勃

01 有话题的技术

1、AI 创业公司 Xmax 发布 X2.0 模型：支持端侧实时交互式视频生成与相机流实时重绘 API

AI 创业公司 Xmax 发布了新一代多模态模型 Xmax X2.0，并同步上线了测试 Demo 及开发者 API。该模型主打端侧（On-device）实时交互能力，允许用户通过触控、物理动作或自然语言 Prompt 实时重绘相机画面，并直接引导视频动态生成。

首创端侧触控视频生成：支持完全在设备本地（On-device）运行，用户可通过手指在屏幕上触控滑动的轨迹，直接引导静态图像或实时相机流中的主体产生相应的动态位移和动作。
相机流实时交互重绘（Real-time Re-rendering）：在相机持续录像状态下，模型可实时重写视频帧，支持动态替换画面中的人物角色、服装样式或整体视觉风格。
物理感知数字人交互：支持在现实场景中嵌入数字角色，该角色能够对物理环境、用户的肢体运动以及触觉操作做出实时的物理碰撞与交互反馈。
通用提示词实时驱动：采用通用提示词架构，允许用户通过自然语言 Prompt 实时改变镜头中的现实场景，降低了实时视频生成的交互门槛。

( @XmaxAIOfficial\@X)

2、Thinking Machines 开源首款 975B MoE 大模型 Inkling：支持原生无编码器多模态与可控推理强度

由 OpenAI 前首席技术官 Mira Murati ** 创立的 AI 初创公司 Thinking Machines Lab 发布了其首款开源权重多模态大模型 Inkling*。该模型采用 975B 参数的 MoE 架构，支持原生音视频与文本跨模态推理，允许外部开发者直接下载、修改，并动态调节推理强度* 以平衡计算成本与响应延迟。

975B 总参数与 41B 激活参数的 MoE 架构：整体沿用 DeepSeek-V3 的 MoE 设计，包含 256 个路由专家和 2 个共享专家（单 Token 激活 6 个专家），采用无辅助损失负载均衡机制。注意力机制以 5:1 比例交替设置滑动窗口与全局注意力层，配备 8 个 KV 头，支持最高 1M Token 上下文。
原生无编码器多模态融合：弃用传统多模态编码器。音频信号以 dMel 频谱图输入，图像划分为 40×40 像素块并经 4 层 hMLP 编码，随后均通过轻量级嵌入层转化，与文本 Token 在同一 Transformer 架构中进行原生融合推理。
可控推理强度（Reasoning Level）：模型支持通过修改系统消息和 Token 成本来动态调整推理步骤。在 Terminal Bench 智能体编程评测中，Inkling 达到与 Nemotron 3 Ultra 相同性能仅需其三分之一的 Token 消耗，优化了长链工作流的延迟与成本。

12B 激活参数轻量版 Inkling-Small：同步推出总参数 276B、激活参数 12B 的轻量版预览，专门针对小模型优化了预训练数据，在编程与智能体等低延迟高并发场景下实现了逼近 41B 激活主模型的性能。

3000 万次异步强化学习（RL）：在后训练阶段，模型经历超 3000 万次 Rollout 异步强化学习，思维链在不损性能的前提下实现自然压缩，消除了冗余语法表达，并原生内置安全防护。

参考链接：**

https://thinkingmachines.ai/news/introducing-inkling/

（@ 机器之心）

3、Hume AI 发布 Real World VoiceEQ 基准：基于百万级人类评分，多维度评测 40+ 语音模型听觉与情感表达

语音 AI 研发商 Hume AI（Hume）发布了多维度语音 AI 评测基准 Real World VoiceEQ。该基准基于超 100 万次人类真实评分，对 40 多个开源及闭源语音模型进行横向评测，揭示了当前语音模型在「文本转译推理」与「原生语音物理线索（语气、停顿、重音等）理解」之间的技术断层。

百万级人类评分构建 60+ 评测指标：测试框架涵盖 40 多个主流开源与闭源模型，在 15 个以上维度中细分出 60 多个评估指标，重点锚定语音质量、情感适配度、真实感、对话合理性等人类实际体验维度。
主流模型多依赖文本转译（Transcript）推理，缺乏原生语音线索感知：评测指出多数语音模型仍处于「先转译为文本、再进行逻辑推理」的级联阶段，无法直接处理语气、语速、迟疑（如「yeah」与「…yeah」的语义差异）和重音等原生语音物理信号（vocal cues）。
Speech-to-speech（S2S）端到端能力割裂：测试显示情感识别与自然响应能力在现有模型中尚未实现深度融合，部分模型长于情感识别却无法自然输出，部分模型语音流畅度高但丢失了情感上下文。
传统静态基准高估实际表现，噪音与多轮对话成性能瓶颈：模型在面对口音、背景噪音、多人混音重叠、情感表达以及长周期多轮对话等真实环境（Real World）场景时，实际性能较传统清洁测试数据呈明显衰退。

( @hume_ai\@X)

02 有亮点的产品

1、OpenAI 联合 Work Louder 发布 Codex Micro：13 键智能体控制外设，支持物理旋钮调节 LLM 推理强度

OpenAI 联合客制化外设厂商 Work Louder 推出专用硬件外设 Codex Micro（kbd-1.0-codex-micro）。该设备作为 ChatGPT Codex 智能体的物理控制台，通过实体按键、旋钮及 RGB 状态灯实现对智能体工作流、推理资源分配以及人机协同指令的物理化控制。这标志着 AI 原生交互开始从纯软件界面走向高频硬件实体化。

13 键双模客制化硬件架构：基于 CNC 铝合金及 PC 机身设计，配备 POM/POK 材质轴体（提供段落轴与静音轴双版本）与 PBT/PC 材质定制键帽。设备采用蓝牙与 USB-C 双模连接，兼容 macOS 与 Windows 系统，板载 13 个机械按键、1 个旋转编码器、1 个平面摇杆及 1 个触摸传感器。
RGB 灯效实时映射智能体状态：小键盘指示灯与后端 Codex 智能体状态机深度绑定，通过不同色值物理呈现「思考中」、「运行中」、「等待中」、「已完成」和「空闲」五种运行状态，用户无需切换主屏幕软件窗口即可全局监控后台任务进度。
物理摇杆与 PTT 键实现高频流式交互：平面摇杆可一键触发 PR 审查、错误调试、代码重构等标准预设开发工作流；特设专属 Push-to-Talk 键，支持按住说话录入语音 Prompt、松开即刻提交的流式交互，提升指令输入效率。
物理旋钮动态调节推理强度（Reasoning Level）：首次将大模型算力预算控制物理化。用户通过拧动板载旋转编码器，可实时调节 Codex 的推理强度，在轻量化快速任务与高算力消耗的复杂推理任务之间进行即时算力分配。

官网链接：

https://openai.com/zh-Hans-CN/supply/co-lab/work-louder/

( @APPSO)

2、语音 AI 初创公司 Rime 完成 2400 万美元 A 轮融资，重塑人机交互体验

近日，致力于构建下一代语音交互模型的初创公司 Rime 宣布成功完成 2400 万美元的 A 轮融资。本轮融资由知名风险投资机构 M13 领投。

Rime 团队指出，尽管大语言模型（LLM）已经彻底改变了语音应用的开发方式，但在实际的交互体验和「听觉感受」上，人机语音对话依然显得不够自然。Rime 坚信，语音终将成为人类与 AI 交互的最主要方式，而「更优质的对话，必须始于更优秀的底层模型」。

得益于近期在企业级市场的快速采用和强劲增长，Rime 表示，本轮融资将全力用于一个核心目标：开发能够承载全球最重要对话的语音交互底层模型。

随着新资金的注入，Rime 正在加速团队扩张，并向全球顶尖人才发出邀请，共同打造语音 AI 的未来。

( @rimelabs\@X、@lilyjclifford\@X)

3、我国 AI 拟人化互动服务管理办法正式施行

国家网信办等五部门联合公布的《人工智能拟人化互动服务管理暂行办法》昨日起正式施行。

《办法》要求提供者履行全生命周期安全责任，不得将替代真实社交、控制用户心理或诱导沉迷作为服务目标。

对连续使用每超过 2 小时的用户，应通过对话或弹窗提醒使用时长；识别到明确自残自杀风险、重大财产损失等极端情形时，应当进行必要干预并联系监护人或紧急联系人。

新规还禁止向未成年人提供虚拟伴侣、虚拟亲属等亲密关系服务，处理不满 14 周岁未成年人信息需征得监护人同意。上线拟人化功能、使用新技术导致服务重大变化，或注册用户超过 100 万、月活超过 10 万时，提供者应开展安全评估。

( @APPSO)

03 有态度的观点

1、分析：社交媒体超四分之一长文为 AI 生成，LinkedIn 成重灾区

根据 Pangram 的一项分析，目前社交媒体上超过 250 个单词的长篇内容中，每四篇就有一篇是由 AI 生成。

其中，LinkedIn 的 AI 内容占比最高，41% 的长文被判定为 AI 撰写。虽然 LinkedIn 仅占此次扫描帖子总数的约三分之一，但却贡献了近三分之二的 AI 内容。

在 X（原 Twitter）平台上，接近一半的长文被认为是完全由 AI 生成，或是在 AI 辅助下完成的。

相比之下，Substack 的 AI 内容比例最低，约为 10%。Reddit 的回复（Replies）则几乎全部由真人撰写，人类创作占比达到 98%；不过，Reddit 的独立帖子（Standalone Posts）中，AI 生成文本出现的频率则明显更高。

这项数据来自 Pangram 的 Chrome 浏览器扩展。该工具于 2026 年 4 月至 6 月期间，共扫描了五大社交平台超过 100 万篇帖子。

（@ 极客公园）

04 社区黑板报

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

1、活动推荐：WAVE'S UP｜7 月 20 日来上海聊聊 AI 全球化下的生态、资本与合规

7 月 20 日，WAVE（总部位于新加坡国际科创生态组织）将在上海开启 WAVEMakers Meetup 第二期！

邀请到 Block71、一苇资本、微软、JPMorgan、Creekstone Ventures、M2square、清科创投、Gunderson Dettmer 高锐律所、StepFun 阶跃星辰、stripe 等伙伴，一起来聊聊「AI 全球化下的生态、资本与合规」

活动链接：

WAVE'S UP｜7 月 20 日来上海聊聊 AI 全球化下的生态、资本与合规

写在最后：

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

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

给测试看的 Agentic SDLC

Fhaohaizi — Sat, 18 Jul 2026 13:55:49 +0800

过去两年，很多人对 AI 编程的理解还停留在提升编码效率上，比如让 AI 补全一段代码、生成一个函数、解释一个报错、写几个单元测试。这些能力当然有价值，但如果只从写代码更快这个角度理解 Agentic Coding，就会低估这场变化的深度。

Anthropic 在 2026 Agentic Coding Trends Report 中提出的第一个趋势是：软件开发生命周期将发生巨大变化。这个判断很关键，因为它说明 Agentic Coding 的影响对象不是某个局部工具，也不是 IDE 里的某个功能，而是整个软件开发流程本身。报告认为，2026 年的软件开发会从以人工编码为中心，逐渐转向由人类定义目标、AI Agent 执行大量实现工作、人类负责监督和判断的新模式。

传统软件开发生命周期中的需求理解、编码、测试、文档、评审、监控和反馈并不会消失，但这些环节之间的边界会被重新组织，开发周期也可能从过去的数周压缩到数小时或数天。这也是第一篇文章要讨论的核心问题：Agentic Coding 到底如何改变软件开发生命周期？

从代码补全到流程重构

早期的 AI 编程工具，主要解决的是局部编码问题。开发者仍然掌控完整流程，AI 只是参与其中一个很小的环节。比如开发者已经知道要写什么函数，只是让 AI 帮忙生成实现；开发者已经看到错误日志，只是让 AI 帮忙分析原因；开发者已经写完功能，只是让 AI 补几个测试用例。

这种模式下，AI 的角色更像是一个增强型助手。它提高的是局部效率，但没有改变软件开发的基本组织方式。需求仍然由人拆解，方案仍然由人设计，代码仍然主要由人实现，测试和 Review 仍然由人推进，发布和监控仍然依赖原有流程。

Agentic Coding 的不同之处在于，AI 不再只是等待开发者给出一个非常具体的代码任务，而是可以参与更完整的工作链路。一个 Agent 可以读取工单，理解需求背景，分析代码库，制定修改计划，生成代码，补充测试，运行验证，修复失败，生成文档，并在遇到关键不确定性时请求人类确认。

也就是说，Agentic Coding 不是把写代码这件事做得更快，而是把需求到交付之间的多个环节压缩到同一个连续流程中。报告提到，传统 SDLC 阶段仍然存在，但 Agent 驱动的实现、自动化测试和内联文档会显著压缩开发周期，监控反馈也会更快进入下一轮迭代。

这意味着，真正被改变的不是代码编辑方式，而是软件交付方式。

慢在流转而不是编码

要理解 Agentic Coding 的影响，必须先看传统软件开发生命周期为什么会慢。

传统 SDLC 通常包括需求分析、设计、开发、测试、代码评审、发布和监控反馈。这个流程本身没有问题，它是软件工程长期沉淀出来的质量保障机制。但在实际组织中，问题往往出现在流程流转上。

需求需要先被产品或业务人员描述，再由技术人员理解和拆解；开发人员完成代码后，需要等待测试人员验证；测试发现问题后，再回到开发人员修复；代码还要经过 Review、CI、发布流程；上线后如果监控发现问题，又会重新进入需求或缺陷修复流程。

这个过程中，真正耗时的不一定是写代码本身，而是大量上下文切换、排队等待、沟通确认和反馈延迟。一个功能可能只需要两天开发，但从需求提出到最终上线却要经历一两周，原因就在于流程中的每个环节都需要不同角色接力，而每次接力都会产生时间成本和信息损耗。

Agentic Coding 试图改变的正是这一点。如果 Agent 可以在理解需求后直接读取代码库，给出实现计划，并同步生成代码、测试和文档，很多过去必须串行推进的工作就可以被并行化。如果 Agent 可以运行测试并根据失败结果继续修复，开发完成后再等测试反馈的周期就会缩短。如果 Agent 可以把监控中的错误、日志和异常行为重新转化为修复任务，线上反馈到代码修改之间的距离也会变短。

所以，Agentic Coding 对 SDLC 的影响，不是简单地让某个阶段更快，而是让阶段之间的流转成本下降。

人类定目标，Agent 做执行

报告中有一个非常明确的判断：未来大量战术性工作会转移给 AI，包括写代码、Debug、维护代码等，而工程师会更多关注架构、系统设计和战略性决策。

这句话可以拆成两层含义。

第一层是，AI 会承担更多实现层的工作。比如根据需求生成代码，根据测试失败修复问题，根据代码变更补充文档，根据已有模式维护一致性。这些工作过去占用了工程师大量时间，但其中相当一部分是边界清晰、可以验证、重复性较强的任务，适合交给 Agent 执行。

第二层是，人类不会因此退出开发流程，而是把注意力转移到更高层。工程师需要判断需求是否合理，设计是否可扩展，边界是否清晰，架构是否稳定，AI 生成的实现是否真正符合业务目标。换句话说，工程师的核心价值会从直接产出代码，逐渐转向定义正确的问题，并验证系统是否正确解决问题。

这会带来一种新的开发模式：

环节	传统模式	Agentic Coding 模式
需求理解	人工阅读需求，拆分任务	Agent 辅助理解工单、代码上下文和变更范围
方案设计	工程师设计技术方案	工程师主导方案，Agent 辅助分析影响面
编码实现	工程师手写大部分代码	Agent 生成实现，工程师监督方向
测试验证	开发或测试人员补充测试	Agent 自动生成测试、运行测试并修复失败
文档维护	人工补充，常被延后	Agent 在实现过程中同步生成文档
Review	人工逐行审查	Agent 先做自动检查，人类关注关键风险
监控反馈	问题进入下一轮开发	反馈更快进入 Agent 修复流程

这不是说人类只需要点确认。恰恰相反，人类的判断更重要了。因为当代码生成成本下降后，真正稀缺的东西不再是代码数量，而是方向正确性、系统一致性和风险控制能力。

工程师成为编排者

报告对工程师角色变化有一个非常明确的表述：软件工程师将越来越多地负责协调 Agent、评估输出、提供战略方向，并确保系统作为一个整体正确解决问题。

这意味着，工程师不再只是实现者，而会变成一种编排者。

过去，一个工程师的核心工作可以概括为：理解需求，然后把需求转化为代码。未来，这个过程会变成：理解需求，拆解任务，设计约束，指导 Agent 执行，检查 Agent 输出，修正方向，并最终对交付质量负责。

这两种角色的能力结构并不一样。传统实现型工程师强调语言熟练度、框架经验、编码速度和 Debug 能力。Agentic Coding 时代的工程师仍然需要这些基础能力，但仅仅会写代码已经不够。更重要的是能否清楚表达目标，能否把一个模糊问题拆成 Agent 可以执行的任务，能否设置有效的验收标准，能否识别 AI 输出中的表面正确和深层错误，能否判断一个实现是否符合长期架构方向。

这对工程师提出了更高要求。因为 AI 可以生成大量看起来合理的代码，但看起来合理不等于系统上正确。一个没有架构判断能力的人，很容易被 AI 输出牵着走；一个缺乏测试和验证意识的人，也很难发现 AI 生成结果中的隐藏缺陷。

因此，Agentic Coding 并不会降低软件工程的专业性。它降低的是局部实现成本，提高的是对系统判断能力的要求。

Onboarding 被压缩

PDF 中还提到一个非常重要但容易被忽视的变化：新工程师熟悉代码库或项目的时间会被大幅压缩。传统情况下，一个工程师加入新项目，通常需要花几天到几周理解系统架构、模块关系、历史设计、代码规范和业务逻辑。报告认为，Agent 可以帮助工程师快速理解代码上下文，让 onboarding 时间从几周压缩到几小时。

这对组织影响很大。

过去，公司在安排项目人员时，会受到代码库熟悉度的强约束。一个复杂系统往往只有少数核心成员真正理解，其他人即使有能力，也需要较长时间才能有效贡献。这会导致项目资源调度不灵活，关键人员负载过高，新人进入慢，跨团队支持成本高。

如果 Agent 可以快速解释代码库结构、梳理调用链、定位相关模块、总结历史逻辑，并辅助生成修改方案，工程师进入新项目的门槛就会下降。企业可以更灵活地把工程师调配到需要支持的任务上，某些过去依赖长期上下文积累的工作，也可以通过 Agent 缩短启动时间。

报告提到 Augment Code 的案例：它使用 Claude 为工程师提供上下文代码理解，帮助降低进入新代码库或项目的学习曲线。报告还提到，一个企业客户原本预计需要 4 到 8 个月完成的项目，在 Augment Code 和 Claude 的支持下，两周内完成。

这个案例说明，Agentic Coding 影响的不只是个人效率，也会影响组织层面的项目排期和资源配置。不过这类案例更适合当作趋势信号，而不是通用承诺。不同团队的代码质量、测试体系、文档基础和权限边界不同，Agent 能压缩多少周期，也会有很大差异。

测试和验证更加关键

虽然 Trend 1 的主题是 SDLC 变化，但从报告内容看，测试和验证实际上会成为 Agentic Coding 能否规模化落地的关键。

原因很简单：当 AI 生成代码的速度提高后，如果验证能力没有同步提升，风险也会被放大。Agent 可以更快写代码，也可能更快引入缺陷；Agent 可以更快修改系统，也可能更快破坏隐含约束。因此，未来软件开发流程中，自动化测试、代码审查、运行验证、监控反馈会变得更加重要。

这也解释了为什么报告没有把人类完全排除在流程外。Agentic Coding 的成熟模式，不是 AI 写完直接上线，而是 AI 执行大量工作，但整个过程有测试、验证、Review 和人类判断作为约束。

对测试开发来说，这个变化尤其值得关注。因为当 Agent 参与更多开发环节后，测试不再只是开发后的质量检查，而会成为 Agent 工作流中的基础设施。Agent 写完代码后，需要测试来判断是否正确；Agent 修复 Bug 后，需要回归测试来判断是否引入新问题；Agent 长时间运行时，需要持续验证来避免错误累积。

换句话说，越是 Agentic Coding，越需要强测试体系。没有可靠验证，Agent 的速度越快，组织越难放心使用。

真正变化的是交付方式

Anthropic 报告把软件开发生命周期变化放在第一个趋势，是有原因的。因为这是后面所有趋势的基础。

如果 SDLC 不变化，Agent 只是一个更强的代码助手；只有当需求理解、任务拆解、代码实现、测试验证、文档生成、Review、监控反馈都开始被 Agent 连接起来，Agentic Coding 才真正成为一种新的软件开发模式。

这篇文章的核心结论可以概括为三句话。

第一，Agentic Coding 改变的不是某个编码动作，而是从需求到交付的完整流程。

第二，工程师不会因为 Agent 参与开发而失去价值，但价值重心会从手写代码转向架构判断、任务拆解、质量评估和流程编排。

第三，未来团队之间的效率差距，不只取决于谁用了更强的模型，而取决于谁能把 SDLC 改造成适合 Agent 参与、可验证、可监督、可持续迭代的流程。

因此，2026 年软件开发真正值得关注的问题，不是 AI 能不能写代码，而是我们能不能重新设计软件开发流程，让 AI Agent 在正确的位置做正确的事，并让人类在关键位置保持判断和控制。

相关阅读

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

豆包评测 03 篇：JD 里的技术术语，评测岗到底要懂多少

Orienjoy — Sat, 18 Jul 2026 08:03:04 +0800

02A 和 02B 两篇拆 JD，最后都撞上同一串英文：LLM、MLLM、Prompt、RAG、Agents、SFT、RLHF。我在 02A 里就埋了句，这些术语评测岗到底要懂到什么程度，放到这篇专门说；02B 的结尾也预告了，会给你一份「评测 / 产品视角最低理解门槛」的速查表。

先说说为什么前两篇要花那么大力气去拆 JD。说点我自己的看法：一个合格的评测，或者说测试角色，本质上是用户的试用员。用户没空把产品每个角落都戳一遍，你替他去戳；用户说不清哪里别扭，你替他把话讲出来；用户懒得一步步操作，你替他把流程跑通。你是在帮用户提前体验这个 agent 产品，然后诚实地告诉用户：它好在哪、能帮你把什么活干利索。

这么一想，定位就清楚了。你对这个被评 agent 产品的理解，得贴近产品、甚至要摸到产品经理之上，因为他定义「什么算好」，你得比他更早看出「哪里还不够好、哪里会翻车」；你对背后 agent 技术实现的理解，也得尽量往算法和工程研发那边靠，因为他负责把价值造出来，你得能证明价值真交付了没有。这正好回到咱们系列那句统一准绳：无论产品还是测试视角，都是在回答同一个问题，怎么保证 agent 产品给它的用户带来最大的用户价值。这篇要讲的术语，就是帮你把这两层理解力同时往上抬的梯子。

先把结论撂这，省得你焦虑：不需要变成算法研究员。评测岗、产品岗要的从来不是懂算法推导，而是另一句话：每个技术变了，我的评测方案（或产品需求）要跟着改什么。这份表就是帮你建立这种反射，表里每条都给了「评测视角」和「产品视角」两行，一个管怎么证明价值交付了、一个管怎么把价值造进需求，两边最终都落到同一句：它变了，你的下一步改什么。

一、这份表怎么用：四个原则

光有表不够，得知道怎么用才不白看。我自己的用法是四条，都是踩过坑后的实在话。

原则 1：评测视角优先，不追算法推导深度。 每个术语只学到「它对评测意味着什么」这一层就够。比如 Transformer，你不必会推导注意力公式，只要知道「模型是全局理解不是逐字理解，所以评指代消解要考虑它全局注意力能关联远近词、也会在长文本里漂移的特性」就够了（这句里的「这点」指的就是全局注意力特性，具体怎么造用例看术语表 Transformer 条）。02A 模块 3 已经把 RAG / SFT / RLHF 翻成人话了，这里从评测视角再补一刀。深度都是够用就行，这是整个系列反复说的。

一个我身边真发生的例子：有人评豆包写文案，prompt 没做版本化，同一意图换了种说法分数差了 10 分，最后归因到「模型不稳定」，其实是 prompt 模板飘了。懂「评测视角优先」的第一件事，就是先把 prompt 锁死再谈别的，否则你评的不是模型，是自己的模板。

原则 2：变化触发更新，而不是被动补功课。 模型架构、训练方法一变，先问一句「我哪些指标和用例会失效」。举个具体的，假设豆包某次升级把生成链路由「直接生成」切到「先 RAG 检索再生成」，你的评测方案就得立刻加三件事：检索召回率（找没找对）、引用准确率（引文真不真）、以及「检索到了但生成脱离」的新型幻觉。不跟着变，你评的还是旧世界，新引入的风险全漏了。这一条最该写厚，因为它就是术语从字典变工具的开关：每次模型一发版，你拿这张表过一遍，比翻任何文档都快。

原则 3：把 JD 术语清单变成你的评测知识地图。 一份 JD 里的术语串，本身就是一张现成的评测关注点清单。我们当时是这么落地的：把 JD 那串术语做成一页纸 checklist，新人入职第一周对照打勾，半有和需新学的标红，主管一眼看见短板在哪。比扔一本《深度学习》给人强。表放在文末参考里也能当 checklist 用。

那一页纸长这样：六组术语各一行，已有打绿、半有打黄、需新学打红；红得最多的那个人，第一周重点补。主管周会扫一眼红黄分布，就知道团队短板在哪、培训往哪压。这是把「术语」变成「管理抓手」的最小成本做法。

原则 4：用术语反推评测维度，而不是正向补算法。 看到 JD 里一个词，别去想「我要不要学这个算法」，去想「它对应我评测体系里的哪一根柱子」。比如看到 Agent，反推的是「我有没有多步任务完成率的评测」；看到 RAG，反推的是「我有没有检索召回和引用准确的评测」。这样 JD 不再是恐吓信，而是一张评测维度待办清单。这条和原则 2 是一对：原则 2 管「变了怎么改」，原则 4 管「看着词怎么建」，合起来你就不会被 JD 吓住。

补两个完整示范，把几条用熟。

示范 1（上下文窗口）：评测视角说「要测超长截断丢信息」，落到动作就是造一批 2 万字文档问答对，跑豆包，看后半段约束有没有失效，跌超阈值就告警；产品视角说「别让用户塞超窗口 PDF 还指望一字不差」，落到动作就是产品上做分段上传，或加「已超出可处理长度」的兜底提示。一个词，两边各自长出一条可执行的动作。

示范 2（Agent）：评测视角落到四条动作，造一个「订机票 + 改签 + 报销」三连任务看端到端做完没（多步任务完成率）、记录每步 plan-action-observation 轨迹（决策可追）、测工具调用对不对参数填对没（工具准确率）、某步挂了有没有回滚（失败兜底）；产品视角说「用户要的是事办成不是聊开心」，落到动作就是产品上做任务进度展示和中断恢复。一个词，两边各长四条可执行动作。这就是「最低理解门槛」的意思：不是懂定义，是懂「下一步改什么」。

这四条合起来一句话：术语是动态变量，你盯着「它变了改什么」这一个锚点，就不会被 JD 里那串词吓住。

二、术语速查表（按评测关注点分组）

下面分六组。每组内的术语，我都按「一句话人话 → 评测视角 → 产品视角」给。评测视角解决「它变了，我的评测方案改什么」；产品视角解决「它变了，我的需求边界改什么」。

2.1 模型架构与基础

Transformer
一句话：现在主流大模型底层的网络结构，靠注意力机制让模型读一句话时同时看清词和词的关系，不是逐字死读。
评测视角：模型是全局理解（一次性看清整句词与词关系，正是指代消解的能力来源），评「指代消解」时，简单短句区分度低不必堆，真正该造的是「远距离指代 + 多候选干扰」的 case：比如让豆包读一篇 3000 字文章，中间反复出现「他 / 该公司 / 这个方案」，看它到后半段还认不认得对；「长句逻辑」同理，长距离约束到后面可能失效，造例时把关键约束放在句首或句尾两端对照测。
产品视角：不用懂结构，但要知道模型理解靠上下文整体，别指望它严格按你给的字段顺序作答。

注意力机制 Attention
一句话：Transformer 的核心，让模型生成每个词时，去权衡前面哪些词更重要。
评测视角：注意力是软的、会漂移，长文本里前面的约束到后面可能失效，这是退化类风险的根源之一。
产品视角：理解「模型会抓重点也会跑偏」，长 prompt 里关键约束要前置或重复强调。

预训练 Pre-training
一句话：模型在海量通用数据上先练出的「基本功」，类似于上学前的广泛阅读。
评测视角：预训练能力是底座，很多「常识题」考的是这层；评测要区分这是预训练能力还是后面微调加的。
产品视角：判断一个能力是不是「通用都会」，决定你要不要为它单独做产品方案。

Token
一句话：模型读写文本的最小单位，中文里大约 1~2 个字算一个 token，不是按字算。
评测视角：延迟和成本都按 token 算，长上下文问答里 token 消耗是隐藏指标，评测要记。
产品视角：按 token 计费，长文档、多轮对话的成本估算得用它，别按字数估。

上下文窗口 Context Window
一句话：模型一次能「看到」的文本长度上限，超出部分会被截断或遗忘。
评测视角：必须测超长截断丢信息、长文档后半段约束失效；豆包长文档问答尤其要覆盖。
产品视角：产品上别让用户塞超窗口的 PDF 还指望一字不差，要做分段或兜底提示。

Embedding 向量化
一句话：把文字变成一串数字（向量），让机器能算「这两句话像不像」。
评测视角：语义相似度判分、RAG 检索都靠它；要关注向量质量影响召回和判分准不准。
产品视角：搜索、推荐、聚类这类功能的质量，底层都卡在 embedding 好不好。

2.2 生成与训练

Prompt
一句话：你给模型的指令，决定了它干什么、怎么干。
评测视角：评测必须先锁定 prompt 模板，换 prompt 等于换尺子，结果不可比。
产品视角：prompt 就是产品的「使用说明书」，写得含糊模型就答歪。

提示工程 Prompt Engineering
一句话：研究怎么把指令写得更让模型听话、更出好结果的一套方法。
评测视角：评测集里的 prompt 要版本化，同一意图写多种说法、加对抗扰动，才测得出鲁棒性。
产品视角：把用户意图翻译成好 prompt，是产品体验的一部分，值得专门打磨。

温度 Temperature
一句话：控制输出随机性的旋钮，0 像背标准答案，1 像天马行空。
评测视角：评生成任务温度必须锁定，否则同一 case 测两次分数不同，结论不可信。
产品视角：产品上创意类场景可调高、严谨类要调低，这是体验旋钮不是质量旋钮。

Top-p / Top-k 采样
一句话：模型挑下一个词时，只在「概率最高的那一批」里随机选，控制发散程度。
评测视角：和温度一样要锁参，评测生成多样性时这两个值直接决定产出分布。
产品视角：和温度配合调「稳还是活」，影响用户感知的鲜活度。

微调 Fine-tuning
一句话：在预训练基础上，用特定数据再调教一轮，让模型学会某项专长。
评测视角：要前后对比，微调可能「学会新的、忘了旧的」（灾难性遗忘），通用能力得复测。
产品视角：别以为加微调只加能力，要问「它会不会丢了原来好的」。

SFT 监督微调
一句话：拿标好的「问答对」喂模型，教它学会特定任务的回答风格。
评测视角：SFT 后重点评「风格对了没、有没有学出新毛病」，02A 模块 3 翻过人话。
产品视角：产品要的「语气、格式」主要靠 SFT 定型，验收看风格达标没。

RLHF 基于人类反馈的强化学习
一句话：用人对回答的好恶打分，把模型往「让人满意」的方向推。
评测视角：RLHF 后容易「对齐过头」：该答的不答、变套路话。要加拒答率、刻板度指标。
产品视角：模型太安全可能变「躺平」，产品的体验边界要在 RLHF 前定义清楚。

对齐 Alignment
一句话：让模型的行为符合人类期望和价值观，RLHF 是对齐的一种手段。
评测视角：对齐质量要评「安全且不躺平」的平衡，单纯压安全会伤可用性。
产品视角：产品要在「可控」和「好用」之间拍板，对齐强度是产品决策。

指令微调 Instruction Tuning
一句话：用「指令 - 回答」格式数据训练，让模型更听得懂人话指令。
评测视角：评测要覆盖指令遵循度，尤其是复杂、多约束指令有没有全做到。
产品视角：用户用自然语言下指令的体验上限，卡在这层。

涌现能力 Emergence
一句话：模型大到一定程度，突然会了小模型不会的本事，不是线性长出来的。
评测视角：小模型测不出的能力，大模型可能突然有；评测集要随模型规模升级加难度。
产品视角：别拿小模型表现推断大模型，能力跃迁会让老方案失效。

2.3 检索与增强（RAG）

RAG 检索增强生成
一句话：让模型答题前先去查资料库再开口，等于配了本可以翻的参考书。
评测视角：幻觉检测分两步，先查「检索对不对」，再查「生成有没有脱离检索结果」，02A 模块 3 翻过。
产品视角：RAG 上线，产品要判断哪些场景该上、响应速度的代价值不值。

向量数据库
一句话：存 embeddings 的数据库，专门支撑「按语义找相似内容」的检索。
评测视角：RAG 评测要单独测检索召回率，向量库质量直接决定豆包知不知道正确答案在哪。
产品视角：知识库类产品的检索体验，底层卡在向量库的选型和索引。

检索召回率 Recall
一句话：该找出的相关片段，实际找出了多少，衡量检索漏没漏。
评测视角：RAG 评测的第一道闸，召回低后面全白搭；要构造「答案藏在长文档某段」的 case。
产品视角：用户问「你刚才说的那点」答不上来，多半是召回漏了，是产品体验硬伤。

2.4 Agent 与工具

Agent 智能体
一句话：能自己定计划、调工具、多步完成任务的模型应用，不是一问一答。
评测视角：评测从「单轮答对」升级到「多步任务完成率」，要记录 plan→action→observation 轨迹。
产品视角：产品上 Agent 是「能干活的助手」，验收看任务真做完没，不是看聊得开心不。

工具调用 Tool Use / Function Calling
一句话：模型能调用外部函数（查天气、下单、跑代码），把能力伸到模型外。
评测视角：要测调用对不对、参数填对没、失败有没有兜底；对应 taxonomy 的 Agent 编排能力。
产品视角：产品能接哪些工具、接错怎么办，是产品边界设计的核心。

ReAct 推理 + 行动
一句话：一种让模型「先想一步、再做一步、看结果再想」的框架。
评测视角：评测要判「思考链和动作是否对齐」，别出现想的是 A 调的却是 B。
产品视角：理解 Agent 的工作方式，才能设合理的用户等待和进度展示。

规划 Planning
一句话：Agent 把大任务拆成可执行的步骤序列的能力。
评测视角：评测看计划合不合理、卡住会不会重规划，对应 02A 模块 5 的 harness 设计。
产品视角：复杂任务的产品流程，往往就是 Agent 的规划在人类侧的映射。

多步编排
一句话：把多个模型调用、工具调用串成一条流水线协同完成目标。
评测视角：评测要覆盖步骤间状态传递、中途失败的整体兜底，是最重的 harness 场景。
产品视角：产品上一个复杂功能背后常是多步编排，哪步挂了用户都感知得到。

2.5 多模态与生成

多模态 Multimodal
一句话：模型能同时处理文字、图、声音等多种信息，而不是只认文字。
评测视角：多了一个「跨模态一致性」指标，图里有的内容文本输出里得有，对应 taxonomy ③。
产品视角：图文、音文混合的产品体验，卡在跨模态对不对得上。

VLM 视觉语言模型
一句话：能看懂图还能聊图的模型，多模态理解的主力。
评测视角：评测用 VQA（看图问答）、图表理解、OCR 渲染检查，参考 MMBench / ChartQA。
产品视角：图片理解类功能（识图、拍题）的体验上限在这层。

ASR 语音识别
一句话：把人说的话转成文字，语音交互的第一道关。
评测视角：用 WER（词错率）衡量，对应 taxonomy ②语音交互；要测嘈杂环境、口音、断句。
产品视角：语音产品「听不准」是头号差评源，ASR 准了后面才谈得上。

TTS 语音合成
一句话：把文字变成人声播出来，语音交互的最后一环。
评测视角：用 MOS（听感评分）衡量自然度，要测断句、停顿、情绪是否诡异。
产品视角：合成音「像不像人、烦不烦」直接决定语音产品的高级感。

文生图 / 文生视频（Seedream / Seedance）
一句话：豆包的 AIGC 生成能力，给文字提示词产出图或视频。
评测视角：评「提示词遵循 + 跨模态一致性 + 安全合规」，对应 taxonomy ⑤，生成和理解评法相反。
产品视角：产品要定「什么算好图 / 好片」，审美和安全红线都是产品决策。

跨模态一致性
一句话：图里写的和文字说的内容对不对得上，多模态专属指标。
评测视角：图文不对应、视频里文字乱码，都要判失败；是生成类评测的硬指标。
产品视角：用户最不能忍「图和说的不一样」，这是多模态产品的信任底线。

2.6 评测专项

LLM-as-Judge
一句话：拿一个 LLM 当评委，按 rubric 给另一个模型的回答打分。
评测视角：02A 模块 2 讲过，judge 有 position / verbosity bias，得分要人工抽检兜底、算一致性。
产品视角：产品上可用 judge 做大规模体验初筛，但别拿它当最终结论。

幻觉 Hallucination
一句话：模型一本正经地编瞎话，事实、引用、张冠李戴都算。
评测视角：分事实性 / 忠实性 / 逻辑性三类测，参考 HaluEval / FaithEval / Ragas。
产品视角：幻觉是产品信任杀手，产品要定义「哪些场景零容忍」。

基准 Benchmark
一句话：业界通用的「体检表」，用固定考题测模型某方面能力。
评测视角：基准分是准入证不是合格证，饱和和泄露要警惕，下篇 04 专门讲怎么读。
产品视角：别拿高分当「能上线」，用户满意度和基准分不是一回事。

评测集污染 Contamination
一句话：评测题被悄悄混进了训练数据，模型「背过答案」导致虚高。
评测视角：要测 n-gram 重叠、做成员推断检测，否则分数不可信。
产品视角：产品验收别只看内部高分，要怀疑「是不是见过题」。

数据飞轮 Data Flywheel
一句话：线上 badcase 捞回来进评测集，模型优化后再上线，循环转起来。
评测视角：评测集从线上来、到评测里去，对应 02A 模块 4，是可持续评测的核心。
产品视角：你是飞轮最好的推动者，离用户最近、最知道痛点在哪。

红队 Red Teaming
一句话：专门有人扮演攻击者，想办法诱模型出岔子、越红线。
评测视角：红蓝对抗最能暴露真问题，对应 01 篇的产品质量红线，漏过率一票否决。
产品视角：安全是产品的发布闸门，红队发现的问题产品必须接住。

三、几个最容易踩的误读

表看完了，最后说几个我身边人真踩过的坑，都是把术语理解偏了导致评测或需求跑偏。

误读 1：把温度当质量旋钮。 有人觉得「温度调低点模型就更准」。不对，温度只控随机性，质量靠模型本身。它真正的作用是：评测生成任务时必须锁死，否则同一题两次分不同，你分不清是模型差还是参数飘。把温度当质量调，只会把评测搅乱。我见过有人评豆包写文案，温度没锁，同一 brief 跑两遍分数差 8 分，最后归因到参数没锁而不是模型问题，白折腾两天。

误读 2：以为上了 RAG 就不幻觉。 RAG 只解决「模型没知识」这一种幻觉（检索不到才编），解决不了「有知识但编答案」（检索到了却脱离结果瞎说）。所以幻觉检测必须分两步，上面 RAG 那条写了。我踩过：豆包接了知识库后，团队把幻觉评测撤了，结果用户问「你刚才引用的那篇说啥」，模型张冠李戴照样编，因为检索到了但生成没贴住。召回对了不等于不幻觉。这条最该记牢，它是原则 2「变化触发更新」的反面教材：你以为加了 RAG 风险少了，其实风险换了个地方冒头。

误读 3：以为微调只会加能力不会减。 微调可能灾难性遗忘，通用能力悄悄掉。评测必须做微调前后对比，通用维度复测一遍。产品上同理，加了个新技能别以为老的都还在。

误读 4：把 Benchmark 高分当能交付。 这个 02A 提过、下篇 04 展开。这里先点一句：基准分是「考试分数」不是「实际能不能用」，高于平均不等于可以发，低于平均一定不能发。

误读 5：以为懂原理等于能提任意需求。 不懂边界最容易提「让豆包永远不出错」「200 页 PDF 一字不差记住」这类做不到的需求。我见过产品同学提「让豆包把这份 200 页合同一字不差记住并随时精确引用」，算法团队当场傻眼：上下文窗口和检索精度都卡着，硬提就是埋雷。懂一点原理，是为了提得出好需求、拍得下合理板，不是把自己变成算法。这也回到开头那句：你是用户的嘴替、手替，但你得比产品经理更早发现「这个需求本身就建在流沙上」。

误读 6：把 Embedding 当黑盒不测。 RAG 和语义判分都靠向量质量，向量一歪，召回和判分跟着歪。评测要单独校一遍 embedding 在你们业务语料上的相似度准不准，别默认厂商给的就是对的。

误读 7：以为 Agent 评测等于单轮评测。 Agent 是多步的，单轮答对不代表任务完成。有人拿「每个子问题答对率」当 Agent 分数，结果整体任务跑飞了还显示高分。要评「端到端任务完成率」，记录完整轨迹，别被局部准确率骗了。这条对应工具调用、规划、多步编排那几条，是 Agent 评测和单轮对话评测最本质的分水岭。

误读 8：以为术语是评测岗的事，产品不用管。 02B 说过，产品是「定义什么算好」的人，不懂 RAG / Agent 这些，你定义的标准就会飘。最典型的，产品提「要准确」却不说是「检索准确」还是「生成准确」，评测接不住。开头我说评测对产品的理解要贴近甚至高于产品经理，这条误读就是那个意思的反面：产品自己不跨这一步，最后接不住的是整条价值链路。

误读 9：以为上下文窗口大就等于能记住一切。 窗口是「一次能看到的长度」，不是「长期记忆」。即便窗口有 50k token，关键信息若被后续大量文本冲淡、或压在长文 45k 处而后续又堆了无关内容，模型仍可能漏掉。评测不能只看「超没超窗口」，要专门造「关键信息远离当前焦点」的 case，看注意力有没有漂走。

误读 10：以为 temperature=0 就 deterministic 安全。 零温度确实更稳，但不是可复现的保证：不同推理框架、批处理并行、硬件浮点微差都可能让同输入产出略不同。评测不能假设「零温度 = 两次结果一致」，要实测复现率，把波动记进不确定区间，否则把框架噪声当模型方差。

误读 11：以为 few-shot 能补一切。 示例能提升表现，但有上限，且和 prompt 模板强耦合。评测要把 shot 数版本化：0-shot / 3-shot / 5-shot 分别测，才知道某能力是模型自带还是靠示例喂出来的。否则上线换了个 prompt 模板，原本靠 few-shot 撑住的能力塌了你还不知道为什么。

误读 12：以为评测集大就等于结论准。 量大不等于维度覆盖全。稀疏的 badcase（比如长文档后半段忠实性、跨模态一致性）漏检，比量多但维度单一的评测更危险。正确做法是数据飞轮持续补真实 badcase，而非单纯堆量刷覆盖率。这条和原则 2「变化触发更新」呼应：模型一升级，老维度可能失效，新维度得靠线上 badcase 喂出来。

四、端到端推演：把一条 JD 反推成完整评测方案

前面说「用术语反推评测维度」，这句太抽象，拿 02A 模块 1 那条真实 JD 走一遍，你就知道反推长什么样。

JD 原文意图（脱敏）：用户把一份长文档丢给豆包，追问里面的细节，要求前后回答一致、引用可查。

反推术语依赖：上下文窗口（能不能看到全篇）、RAG（细节从哪来）、幻觉（引的对不对）。

反推评测维度，我当时列了五根柱子：

超长截断丢信息：指标 = 后半段约束命中率；判法 = 造 2 万字文档问答对，把关键事实故意放前半和放后半各一批对照，跑豆包看后半有没有丢；数据来源 = 自建长文档集；红线 = 后半命中跌超 5% 就告警。
检索召回：指标 = Recall@k；判法 = 答案藏在长文档某段，构造「答案在段 17」这类 case；数据来源 = 向量库检索日志；红线 = 召回低于 0.9 整条链路重测。
引用准确：指标 = 引用命中率；判法 = 让豆包标出引用出处，人工抽检 100 条；数据来源 = 标注；红线 = 张冠李戴零容忍。
忠实性幻觉：指标 = FaithEval 类忠实度分；判法 = 专门造「检索到了但生成脱离」的对抗 case；数据来源 = Ragas；红线 = 脱离型幻觉一票否决。
跨段一致性：指标 = 同一事实前后一致率；判法 = 同一文档用不同措辞问两遍，比对答案；数据来源 = 数据飞轮 badcase。

落到 02A 模块 5 的 harness 四件套：采集 = 长文档问答对、执行 = 豆包 API、判定 = LLM-as-Judge + 人工抽检、报告 = 五维仪表盘。

收尾：一条 JD 短语，反推出 5 维 + 指标 + judge + 红线 + harness。这就是「反推」的成品，比背 36 个词值钱十倍。下次再看到 JD 里任何词，你就照这个模板套：术语 → 反推哪几维 → 每维给指标和红线 → 落到 harness。

五、业界怎么做的（最佳实践印证）

咱们这套「术语 → 评测维度」的笨办法，不是拍脑袋。国外评测实践早就在做类似的事，对齐一下你心里更踏实。

Stanford CRFM 的 HELM（crfm.stanford.edu/helm）核心哲学是「多维度整体评测」，不靠单一分数，而是把每个模型能力拆成场景加指标矩阵。这和咱们「反推维度」一个思路，区别只在他拆的是学术基准、我们拆的是 JD。

Allen Institute for AI（AI2）的 OLMo 开源模型配套 OLMES 评测方法论，主张评测方法本身要开源、可复现，直接呼应咱们「评测集从线上来、到评测里去」的数据飞轮，飞轮本质就是让评测方法长在自己业务上、可复现可迭代。

OpenAI 和 Anthropic 公开的 evals 文档，都强调「先定义什么算好（rubric），再评」。这和咱们开头说的「产品定义什么算好、评测证明交付了没」完全同构，他们是通用模型、我们是豆包具体产品，方法底层一致。

落到「怎么验证 judge 自己靠谱」，业界已有成熟做法。MT-Bench（Zheng et al. 2023, LMSYS）用强模型当裁判的同时，拿人类标注做校准：把 LLM 打分和人类偏好对一遍，算一致性（ICC / 相关系数），低于阈值就说明这个 judge 不可信、得换。这正好呼应术语表里 LLM-as-Judge 那条，你用豆包当裁判时，第一步不是写 prompt，而是先拿一小批人工标好的 case 验 judge 的吻合度。

评 RAG 也有现成框架。Ragas 和 DeepEval 把「检索召回率 + 引用准确性 + 答案忠实度」拆成可量化指标，直接对接你反推出来的「检索召回 + 引用准确」两项，不用自己从零造。HELM 的场景 × 指标矩阵再展开看：它不报「模型总分」，而是每个场景（摘要、问答、偏见）配一组指标，你能横向比「豆包在问答场景的引用准确」和「头部在问答场景的引用准确」，这正是咱们反推维度要的东西。

鲁棒性也有对标。微软的 PromptBench 专门测「prompt 被轻微扰动（同义改写、拼写噪声、掉字）后模型还稳不稳」，直接对应你第三节造对抗 case 的思路，区别在它把扰动标准化成基准，你能借它的扰动集当你的 case 种子库，省得每次从零想怎么折腾模型。

所以你学的不是野路子，是和头部对齐的方法。差异只在落点：他们面向通用能力榜单，我们面向用户价值链路。知道这一点，你反推出来的评测维度，底气更足。

六、新人怎么拿这份表上手

说了怎么用、给了表、点了坑、走了推演，最后给个最省力的上手路径，照着走一遍就通。

第一步，把 02A 那张 5 模块能力地图打开，对照本表的术语，标出「已有 / 半有 / 需新学」。比如 Token、Prompt 你大概率已有；RAG、Agent、LLM-as-Judge 多半需新学。

第二步，挑三个你最该补的术语（一般就是 RAG、Agent、LLM-as-Judge），每个只学到「评测视角」那一行，不动算法推导。

第三步，拿一个豆包真实场景练：比如评「豆包长文档问答一致性」，你会自然用到上下文窗口、RAG、幻觉这三个术语的评测视角。用一次，比背十遍表管用。这一步和第四节的端到端推演对上，练的就是那条反推模板。

走完这三步，这份表就从字典变成了你手里的工具。后面系列分能力讲评测时，你随时回这张表查术语，不会卡壳。

掌握程度三档自检（你处在哪层）

层 1 背定义：能说出「RAG 是检索增强生成」。最浅，对干活几乎没用。
层 2 懂评测视角：看到 RAG 能反推出「检索召回 + 引用准确」两项指标，能造一个对抗 case。合格线。
层 3 懂产品视角且能定边界：除层 2 外，还能告诉产品「哪些场景该上 RAG、响应速度代价值不值」，能定义红线。优秀，贴近甚至高于产品经理。

你是评测转岗，目标至少层 2、冲层 3；你是产品转岗，层 2 够用、层 3 是加分。

两份入门清单（30 秒自检）

评测岗最低门槛，五问能答「能」即入门：①看到 RAG 能反推检索召回 + 引用准确两项指标吗；②看到 Agent 能列出多步完成率 + 轨迹记录吗；③能为一个术语造一个对抗 case 吗；④能说清温度 / Top-p 为什么要锁吗；⑤能定义一条红线吗。

产品转评测最低门槛，五问能答「能」即入门：①提需求时能区分「检索准确」和「生成准确」吗；②能说清哪些场景幻觉零容忍吗；③知道上下文窗口上限意味着什么产品兜底吗；④能定义「什么算好图 / 好片」吗；⑤懂 RAG 后知道哪些场景该上吗。

7 天微计划：Day1 Token / Prompt；Day2 上下文窗口 / 注意力；Day3 RAG / 召回 / 幻觉；Day4 SFT / RLHF / 对齐；Day5 Agent / 工具调用 / ReAct；Day6 LLM-as-Judge / 红队；Day7 拿一个真实场景端到端走一遍（呼应第四节推演）。一天一个术语加一个 case，周末就能建立那个反射。

参考与延伸

评测与术语相关基准 / 框架（文中引用）

对话与语义判分：MT-Bench（Zheng et al., 2023）、AlpacaEval、LLM-as-Judge 及校准研究
多模态：MMBench、MME、ChartQA、DocVQA、TextVQA
幻觉：HaluEval、FaithEval、Ragas
Agent：AgentBench、WebArena、τ-bench、ToolBench
鲁棒性：微软 PromptBench（prompt 扰动鲁棒性评测，正文第五节引用）
语音：WER（词错率标准）、MOS（ITU-T P.800 听感评分）、DNSMOS
评测框架：HELM、OpenCompass、LM Eval Harness、DeepEval、Ragas

基准与方法的机构出处（按需查证，非必查）

写「某个基准的来龙去脉 / 评测方法论溯源」时优先查，与附注一（论文）互补（附注一给单篇论文，这里给机构持续输出）。下列为文中涉及基准的发源地，引用时优先回溯：

MMLU：UT Austin（Dan Hendrycks 组），论文 arXiv:2009.03300，是「大模型知识体检」最广用的基准之一。
HELM：Stanford CRFM（Holistic Evaluation of Language Models），crfm.stanford.edu/helm，强调「多维度整体评测」而非单分。
WildBench / OLMo / OLMES / Tulu 系列：Allen Institute for AI（AI2），开源模型与评测方法的主力，评测集污染相关研究多出自此处。
Agent 可靠性评测（RE-Bench 等）：METR（原 ARC），做 agent 评测专项时必看，专攻「模型自主任务可靠性」。
Agent 评测框架核心源头：AgentBench 由清华大学 THUDM（CoAI 组）主导，WebArena 与 τ-bench 由普林斯顿（Shunyu Yao 等）主导，ToolBench 由浙大等机构主导，都是该方向的代表基准。
大学实验室群：UC Berkeley BAIR、MIT CSAIL、University of Washington、Princeton NLP 等持续产出评测方法论文，方法篇溯源时优先扫。
大型公司研究院（非产品厂商官方）：Microsoft Research、NVIDIA Research、Meta AI / FAIR、Apple ML Research、Amazon Science、IBM Research，其公开技术报告是工程侧评测实践的补充信源。

前文衔接

02A 从算法评测 JD 拆 5 模块能力地图（模块 3 已翻 RAG / SFT / RLHF 人话，模块 2 讲 LLM-as-Judge，模块 5 讲 harness 四件套）
02B 从产品 JD 拆另一半地图（模块 4 讲产品视角的技术理解落点）
01 篇产品质量红线、五大能力 taxonomy、评测纪律红线

豆包公开能力（截至 2026.07，以官方最新口径为准）

文本对话、语音交互（ASR / TTS）、多模态理解（VLM）、Agent 编排、AIGC 生成（文生图 Seedream / 文生视频 Seedance / 音频 Seed-Audio）
具体版本号与 DAU 以豆包官网、火山引擎发布会公开信息为准

下篇预告

这篇把 JD 里的术语拆成了评测 / 产品视角的速查表，核心就一句：不用懂推导，只要懂「它变了你的方案改什么」。但术语懂了，还有个绕不开的问题：业界那些基准分数到底怎么读。下篇讲豆包在标准评测基准上的表现怎么看，MMLU、GSM8K、HumanEval 这些报告，教你建立「基准分 → 发布决策」之间的正确距离感，避免「分数高就敢发」的坑。

Long-Running Agent 落地

Fhaohaizi — Fri, 17 Jul 2026 23:13:46 +0800

过去使用 AI 编程工具时，很多人的典型场景是这样的：遇到报错，把错误日志贴给 AI；要写函数，把输入输出描述给 AI；要补测试，让 AI 根据现有代码生成几个用例。这些任务边界清楚，通常几分钟内可以完成，开发者也能很快判断结果是否正确。

这类能力已经有实际价值，但它还不是 Agentic Coding 的完整形态。真正的软件开发不是由一堆孤立小任务组成的。一个真实需求往往需要理解上下文、制定计划、修改多个文件、运行测试、处理失败，并在中途根据新发现调整方向。它不是一次问答，而是持续推进目标的过程。

Anthropic 在《2026 Agentic Coding Trends Report》中提出的第三个趋势是：长时间运行的 Agent 将构建完整系统。报告认为，早期 Agent 主要处理几分钟内完成的 one-shot task，例如修复 Bug、写函数、生成测试；到了 2025 年后期，更强的 Agent 已经可以在数小时内产出完整 feature set；到 2026 年，Agent 将能够连续工作数天，在少量人类战略监督下构建完整应用和系统。

这篇文章要讨论的核心问题是：为什么 Long-running Agent 是 Agentic Coding 走向成熟的关键？

短任务 Agent 的价值和边界

短任务 Agent 的价值很明确。它能快速完成边界清楚、输入明确、验证容易的任务。例如让 AI 写一个字符串处理函数，生成一段 SQL，解释一个异常栈，或者根据某个类补充单元测试。这些任务的共同特点是范围有限、目标清晰、依赖较少、结果容易检查。

这也是过去 AI 编程最容易落地的场景。开发者仍然掌控任务整体方向，只把其中一个局部动作交给 AI。AI 给出结果后，开发者复制、修改、运行、验证，然后继续下一步。

这种模式的问题在于，它没有真正覆盖软件开发中最困难的部分。真实工程任务很少像写一个函数那么干净。更多时候，任务一开始并不完整，代码库里有历史包袱，测试可能不充分，文档可能过期，模块之间有隐含依赖，需求在实现过程中还会暴露新的边界条件。

短任务 Agent 可以解决局部执行问题，但很难独立推进完整工程目标。

例如，一个需求是为现有系统增加新的计费规则。这看似只是一个功能开发，但实际可能涉及多条链路。

环节	可能的问题
需求理解	新规则和旧规则如何兼容
数据模型	是否需要新增字段或迁移历史数据
后端逻辑	哪些服务和接口需要修改
前端展示	用户看到的价格如何变化
测试验证	需要覆盖哪些计费边界
回归风险	是否影响已有订单或历史账单
文档更新	是否需要更新 API 和运营说明

这样的任务不是一次 prompt 能解决的。它需要持续分析、逐步执行、根据反馈调整，并在关键节点做判断。Long-running Agent 的意义就在这里：它不只是生成局部代码，而是持续推进一个复杂目标。

Long-running Agent 不只是运行更久

长时间运行容易被误解为让 Agent 多跑几个小时。实际上，Long-running Agent 的关键不在于时间长度，而在于它能否在较长任务周期内保持目标一致、处理复杂反馈，并持续修正自己的执行路径。

报告中明确提到，未来 Agent 的 task horizon 会从分钟扩展到天或周。它们不只是完成离散任务，而是能够构建和测试完整应用与系统，并在周期性人类检查点下持续工作。

这意味着 Long-running Agent 至少需要具备几类能力。

能力	说明
规划能力	能把目标拆成多个阶段和子任务
上下文保持	能在长任务中维持对代码库、需求和约束的理解
迭代能力	能根据测试、错误和反馈继续修改
失败恢复	能从编译失败、测试失败或方案错误中恢复
状态管理	能记录已完成内容、未完成内容和决策依据
检查点机制	能在关键不确定点请求人类确认
一致性控制	能保证多轮修改不破坏系统整体一致性

这些能力合起来，才构成真正的 Long-running Agent。

一个只能长时间生成内容的模型不是 Long-running Agent。真正的 Long-running Agent 必须能处理软件开发的混乱现实。报告中也用了类似表述：长时间运行的 Agent 需要能够跨多个工作会话进行规划、迭代和精炼，适应新发现，从失败中恢复，并在复杂项目中保持连贯状态。

这正是它和普通代码生成工具的区别。

软件开发是连续反馈过程

软件开发不是一次性写对的过程，而是一个不断反馈和修正的过程。

开发者写代码时，经常会遇到这样的情况：实现到一半发现原方案不适合现有架构；跑测试发现一个旧逻辑被破坏；联调时发现接口约定不一致；上线前发现性能或权限边界有问题。每一次反馈都会迫使开发者重新理解任务，并调整后续实现。

短任务 Agent 往往只处理一个静态输入。它假设问题已经被人类整理好，目标已经明确，边界已经给出。但 Long-running Agent 需要面对动态过程。它要能在执行过程中发现问题、解释问题、修复问题，并继续推进。

比如，Agent 接到一个功能开发任务后，可能先读取相关代码，生成修改计划，然后开始实现。实现过程中，它发现某个模块没有现成接口，于是需要新增抽象；新增抽象后，原有测试失败，它需要判断是测试过期还是实现错误；修复测试后，它又发现文档中有旧行为描述，需要同步更新。

整个过程不是简单的输入到输出，而是持续执行、反馈、修正。软件开发中的真实复杂性，不在于写出某一段代码，而在于在不完整、不稳定、有历史包袱的系统里持续推进正确变更。

Rakuten 案例

报告中最适合说明 Long-running Agent 的案例，是 Rakuten 对 Claude Code 的测试。

Rakuten 的工程师给 Claude Code 一个复杂技术任务：在 vLLM 中实现一种特定的 activation vector extraction 方法。vLLM 是一个大型开源库，报告中提到它包含 1250 万行代码，并涉及多种编程语言。Claude Code 在单次运行中自主工作 7 小时，完成了整个任务，最终实现与参考方法相比达到 99.9% 的数值准确性。

这个案例的重点不是 AI 写代码很快，而是它体现了三个变化。

第一，Agent 能进入大型复杂代码库工作。它不是在空白项目里生成一个 demo，而是在已有复杂系统中理解上下文、定位修改点并完成实现。

第二，Agent 能持续工作多个小时。7 小时意味着它不是一次短回答，而是经历了较长的分析、实现、验证和修正过程。

第三，结果有明确验证标准。99.9% 的数值准确性说明任务不是主观文本生成，而是需要满足工程和数学上的准确要求。

这类案例说明，Agentic Coding 正在从代码片段生成转向工程任务执行。这才是 Long-running Agent 的真正意义。

项目经济性变化

报告中还提出一个重要判断：当 Agent 能长时间自主工作时，软件开发的经济性会发生变化。很多过去不值得做的项目，可能会变得可行；多年积累的技术债，也可能由 Agent 系统性地处理。

这点非常关键。

在传统团队里，很多事情不是没有价值，而是不值得投入人工成本。

类型	过去常被搁置的原因
技术债清理	工作量大，短期业务收益不明显
老代码重构	风险高，需要大量上下文
内部工具	有用但优先级低
测试补齐	重要但耗时，容易被延期
文档更新	价值长期存在，但经常没人维护
小体验优化	单个收益小，排期困难

如果这些事情都需要高成本人工投入，它们很容易被放进 backlog，长期排不到期。但如果 Long-running Agent 可以在低监督模式下持续推进，并通过测试和检查点控制风险，这些任务的可行性就会提高。

尤其是技术债和测试补齐。它们通常不是一次性任务，而是一批长期、重复、需要耐心的工程工作。人类工程师做这些事时，往往会被更紧急的业务需求打断；Agent 则适合在明确规则和验证体系下持续推进。

因此，Long-running Agent 改变的不只是开发速度，也会改变团队对 backlog 的处理方式。以前团队只能把工程资源集中在最重要的功能上；未来，Agent 可能让更多重要但不紧急的维护性工作真正被完成。

想法到部署的路径

报告还提到，Long-running Agent 会加速 path to market，创业者可以用 Agent 在几天内从想法走到部署应用，而不是过去的数月。

这里并不是说所有生产级系统都能几天完成，而是说明早期产品构建的路径会明显缩短。

过去，一个想法要变成可运行应用，需要经历需求整理、原型设计、前后端开发、数据库设计、部署配置、测试验证和文档整理。即使是一个简单产品，也要投入大量时间。如果创始团队技术资源有限，很多想法会停留在概念阶段。

Long-running Agent 可以把其中大量战术性工作自动化。人类提出目标和约束，Agent 负责搭建项目骨架、实现基础功能、生成测试、配置部署、修复错误，并在关键决策点请求人类选择。这样，想法到原型、原型到可部署应用之间的距离会缩短。

这会改变早期产品验证方式。过去验证一个产品想法，往往需要先投入较高开发成本；未来，团队可能更快构建可运行版本，用真实用户反馈决定是否继续投入。

不过，这里仍然要注意报告的边界：人类监督依然重要。Long-running Agent 可以推进实现，但产品方向、业务判断、用户价值和关键技术取舍仍然需要人来决定。

工程流程要求

Long-running Agent 能力越强，对工程流程的要求也越高。

短任务 Agent 出错时，影响范围通常有限。开发者可以快速检查一段代码是否正确。但 Long-running Agent 如果连续工作数小时甚至数天，它产生的修改范围会更大，涉及文件更多，影响面更复杂。如果没有良好的约束机制，它的错误也可能被放大。

因此，Long-running Agent 要真正进入生产流程，需要配套机制。

第一，需要明确任务边界。Agent 在开始工作前，必须知道目标是什么、不能改什么、验收标准是什么、哪些地方需要人类确认。任务边界越模糊，长时间运行的风险越高。

第二，需要持续验证。Agent 每完成一部分工作，都应该通过测试、静态检查、构建验证或其他机制确认方向没有偏离。不能等到几小时后才发现基础假设错误。

第三，需要中间检查点。涉及架构变更、数据迁移、安全边界、兼容性破坏等关键决策时，Agent 不应该自行决定，而应该请求人类确认。

第四，需要可追溯记录。团队要知道 Agent 做了什么、为什么这么做、修改了哪些文件、测试结果如何、失败后如何恢复。没有可追溯性，就很难审查长时间运行的结果。

第五，需要回滚能力。Long-running Agent 可能做出大量修改，必须能在结果不可接受时安全回退。

这些要求说明，Long-running Agent 不是把 AI 放在那里跑就行。它必须被纳入严肃的软件工程体系，接受任务管理、质量控制、权限控制和审计机制约束。

工程师角色变化

Long-running Agent 并不意味着工程师只需要等待结果。相反，工程师的工作会从逐行实现，转向目标设定、过程监督和结果验收。

在这种模式下，工程师需要做几件重要的事。

首先，定义清晰目标。Agent 能否成功，很大程度取决于任务是否被正确描述。模糊的目标会导致 Agent 在长时间执行中不断偏离。

其次，设计验收标准。Agent 完成任务后，不能只看代码是否生成，还要看测试是否覆盖、行为是否正确、性能是否可接受、是否符合架构原则。

再次，设置检查点。工程师要判断哪些地方可以让 Agent 自主推进，哪些地方必须停下来确认。比如简单重构可以让 Agent 连续执行，但涉及数据模型或权限策略时就需要人类审批。

最后，评估最终结果。Long-running Agent 可以产生大量输出，但最终责任仍然在人。工程师需要判断这些输出是否真的能进入生产环境。

所以，Agent 工作时间变长之后，人类并不是退出，而是从执行者变成监督者和决策者。这与报告中对 Agentic Coding 的总体判断一致：AI 可以处理更多实现细节，但人类仍然负责战略监督和关键判断。

持续推进目标

Trend 3 的核心，不是 AI 能连续运行几个小时，而是 Agent 开始具备持续完成工程任务的能力。

短任务 Agent 解决的是局部效率问题。它能帮开发者更快写函数、修 Bug、补测试。Long-running Agent 解决的是完整交付问题。它能围绕一个目标进行规划、实现、验证、失败恢复和持续迭代，最终产出完整功能、应用甚至系统。

这会带来三个直接变化。

第一，软件开发中更多战术性工作可以被 Agent 承担，工程师把精力放到目标、架构和判断上。

第二，过去因为成本高而长期搁置的任务，例如技术债清理、测试补齐、内部工具和文档维护，会变得更容易启动。

第三，从想法到可部署应用的路径会变短，团队可以用更低成本验证更多可能性。

但 Long-running Agent 也要求更强的工程约束。任务边界、测试验证、人工检查点、执行日志、权限控制和回滚机制，都会成为它能否安全落地的基础。

因此，第三个趋势可以用一句话概括：

Agentic Coding 的成熟标志，不是 AI 能生成多少代码，而是它能否在长时间任务中持续保持目标、处理反馈、修复错误，并最终交付一个可验证的工程结果。

相关阅读

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

Agent 工具到底怎么选？

mikezhou — Fri, 17 Jul 2026 10:35:57 +0800

市面上这么多的 Agent 工具，到底应该选哪一个作为主力工具呢？

这个问题，是最近一段时间粉丝和学员最常问我的。也难怪大家困惑——从今年 3 月到现在，本地 Agent 逐渐走入大家视野。

市面上涌现了一大批优秀产品：国内的有 WorkBuddy、Trae Work、Kimi Work，海外的有最近很火的 Codex、Claude Code，还有 Manus。

我自己呢，Codex 和 Claude Code 两款都是主力。

下面分享一下，关于 Agent 工具选择，我自己的一些看法和经验。

先问自己：你愿不愿意折腾海外产品？

在选择 Agent 工具之前，你需要先问自己一个关键问题：你是否愿意折腾海外产品？

其中的细节这里就不再赘述，大家懂的都懂。

使用海外产品，对大部分国内用户来说还是有一些门槛的。这个门槛可能不是知识上的。

如果你有条件、愿意折腾海外产品，强烈推荐 Codex 或 Claude Code。

Claude Code 更适合技术人员。

非技术人员，首选 Codex——因为它的 GUI 界面更友好，上手门槛很低。

我们在使用工具的核心目的不是为了用工具，而是用最低的门槛使用这个工具解决我们核心的问题。因此上手的门槛越低，这个产品越好。

不方便用海外产品？国内看这两款

如果你确实用海外产品不太方便——可能因为公司原因，也可能因为个人原因——那我推荐你关注国内两款产品：WorkBuddy 和 Trae Work。

分别出自腾讯和字节。

两款里面，我更推荐 WorkBuddy。为啥呢？

因为 WorkBuddy 的整个生态结合更丝滑。比如 Skill 生态，它接入得非常广，你可以很方便地给 Agent 加载各种 Skill。再比如连接器——你可以通过 WorkBuddy 连接钉钉、飞书、企业微信，甚至让腾讯会议帮你约会议，这块做得非常好。

Trae Work 呢，到目前为止我觉得还不够完善。

另外，你也可能需要根据使用成本来决定。拿相同的任务去测试两款产品，看看哪个消耗的积分更少，综合成本和便捷性来做最终决定。

Agent 是框架，框架会趋同——别纠结

Agent 其实是一种框架，而框架最终都会趋同。

什么意思呢？举个例子：

Codex 出现之前，Claude Code 是大家比较认可的本地 Agent，Skill 也是 Claude Code 最先接入的。但 Codex 作为后起之秀，很多功能借鉴了 Claude Code。

再比如国内的 WorkBuddy、Trae Work，很多功能设计也借鉴了 Codex 或 Claude Code。

为什么？因为优秀的设计心有灵犀，发现对方有好功能，大家都会借鉴。

所以在选择框架这件事上，除了前面讲的成本和易用性，我认为选一个用起来最顺手的，最重要。

不需要在意别人是否在用更先进的框架。只要你的 Agent 能丝滑地解决问题，你用起来顺畅，就坚持用。

框架定了，什么才是决定因素？——模型

既然 Agent 是框架，那什么才是框架最核心的决定因素？

我觉得是模型。

模型决定的是整个 Agent 的下限。用一个很差的模型，即使框架再好，也可能无法解决问题。

说到这，强调一点：很多朋友在用 Agent 产品时，模型选择默认是 Auto。Auto 的意思是系统根据当前资源帮你分配模型。

相信我，大部分情况下，自动分配的都不会是好模型。

所以对于重要、复杂的任务，建议你主动选择优秀的模型。

模型怎么选？

以 WorkBuddy 为例，能选的模型里，以下几个是我认为比较好的：

首推智谱的 GLM-5.2——从这个模型的使用成本和排序上也能看出来，质量非常不错。

除此之外，像 Kimi 的 K2.7、DeepSeek V4 Pro，也都是海内外口碑很好的模型。

当然，如果你有条件用海外模型，比如 GPT 系列或 Claude 系列，肯定首推这些。

客观来讲，国内外的模型确实存在一定差距，用海外最顶尖的模型，体感上确实比国内好一些。

一个重要原则：原生配原生

最后强调一点：任何一款模型，最适配的 Agent 框架，一定是这家公司自己出的原生 Agent。

什么意思？

你用 Codex，那这个框架下最好的模型一定是 GPT 系列。你用 Claude Code，最适配的一定是 Claude 原生模型。

很好理解——模型和应用都是一家公司的，适配是天然发生的。

我之前看到有些朋友研究怎么在 Codex 里接入 DeepSeek 系列模型。当然，我很理解——一方面是成本考虑，一方面是便捷性考虑。

但还是建议：如果你都能折腾上 Codex 了，不妨找些渠道接入 GPT-5.5 模型，体感会提升非常多。

OK，以上是这期视频的全部内容。如果你觉得对你选择 Agent 工具有帮助，欢迎点赞、收藏、转发给周围的朋友。

沪漂一年

yangchengtest — Fri, 17 Jul 2026 10:21:49 +0800

时间过得真快，一年转眼就过去了。
已经基本习惯周日晚->上海，周五晚->南京的节奏。

工作上就那么回事，有了 AI 加成，会有不少时间在摸鱼刷知乎。
来了上海以后，从心态上彻底放弃所谓的赚大钱的想法了。43 了，上面没人，只靠卖技术，怕是有命挣没命花。

现在的态度就是能挨一天算一天，能给 N+1，也挺好。
上班该摸鱼摸鱼，该干活干活，不会的保持学习态度，坚决不内耗。

客观来说，自己做一份还算有产出的工作，然后还有人支持，还不用管人，确实非常舒服。
缺点其实也很明显，没用的时候怕是很快就得滚蛋，滚就滚吧，能挨一天算一天。

Qwen-Audio-3.0-Realtime 发布，支持自主智能体工具调用；实时视频理解模型 MOSS-VL-Realtime 开源，支持 SGLang 丨日报

RTE — Fri, 17 Jul 2026 00:28:26 +0800

开发者朋友们大家好：

本期编辑：@koki、@ 鲍勃

01 有话题的技术

1、阿里通义发布实时语音交互大模型 Qwen-Audio-3.0-Realtime：集成双工控制子模型，支持自主智能体工具调用

阿里通义全面升级实时语音交互大模型 Qwen-Audio-3.0-Realtime（原 Fun-Realtime-AudioChat），推出推理更强的 Plus 与速度更快的 Flash 两个版本。该模型通过在线策略蒸馏框架，将文本大模型的推理与工具调用能力无缝迁移至语音端，实现了兼顾低延迟与复杂推理的原生双工语音对话。

在线策略蒸馏架构：通过实时纠正与多教师蒸馏保留文本 LLM 推理深度。模型采用 On-Policy Distillation（在线策略蒸馏）框架，由文本大模型对语音模型的生成进行实时纠正；同时引入多教师蒸馏策略，由口语多轮偏好、通用、Agentic、音频理解四类专用教师模型共同完成蒸馏，防止性能偏科。
无指令自主智能体能力：支持 FunctionCall 自动触发与记忆联动。模型无需用户发出明确指令即可自行调用外部工具，且调用结果自动融入上下文记忆以供后续多轮追问。模型基于标准 FunctionCall 协议，支持引入 MCP（Model Context Protocol）、外部 API 和知识库。
多模态双工控制：内置专用控制子模型并开放 audio_prompt 声纹锁定。模型内置「多模态感知的双工控制」子模型，通过综合分析音频信号、语义及声纹特征判断交谈时机，支持随时打断与背景噪声过滤。API 预留 audio_prompt 字段，允许用户上传音频样本以锁定特定说话人声纹。
高口语鲁棒性：VoiceBench 得分达 92.5，口语化提问性能衰减仅 2.0 分。在语音问答基准 VoiceBench 上，Plus 版本在书面化与口语化提问下的得分分别为 92.5 和 90.5；在多轮音频对话 AudioMultiChallenge 测试中，Flash 版本标准与口语化提问得分分别为 43.6 和 38.1。

（@ 通义实验室）

2、OpenMOSS 开源实时视频理解模型 MOSS-VL-Realtime：实时双工理解支持 SGLang 框架

OpenMOSS 团队正式开源实时视频理解模型 MOSS-VL-Realtime，将视频流、用户提问与模型回答整合至单条 token 流中，打破了传统的离线「先看后答」范式。该模型支持随时打断、主动沉默以及基于新输入画面的动态纠错，实现了与实时视频流同频的端到端双工交互。

解耦交叉注意力与 XRoPE 统一编码：采用交叉注意力架构将视觉编码与语言推理进行解耦，以降低动态视频流的响应延迟；引入 XRoPE 算法将文本 token 与视频 patch 映射至统一的三维空间，并通过专用 token 为每一采样帧锚定绝对时间戳。
单 Token 流融合与 <|silence|> 主动沉默：视频、提问和回答共享同一上下文空间，提问可在任意时间点插入。当画面关键信息不足时，模型会自动输出 <|silence|> 显式沉默 token 持续观察；若视频发生突发转折，模型可打断并纠正此前的输出。
256K 上下文窗口与 16fps 采样训练：支持 256K 上下文窗口，可容纳小时级长视频。训练端首次实现了支持 Cross-Attention-Mask 的 FlashAttention，原生支持 2048 帧序列，并在常规 1fps 外新增 16fps 高帧率采样，以支持小球碰撞、跳绳计数等快速变化画面的动作捕捉。
SGLang 深度适配与 5.48 倍吞吐性能提升：模型完成从底层训练到推理引擎的全链路适配，支持 SGLang 官方框架。实测端到端视频推理吞吐量较 Transformers 原生实现提升超 4.57 倍，在同等 SGLang 框架下，推理性能较 Qwen3-VL 提升 5.48 倍。

GitHub:

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

（@ 模思智能）

02 有亮点的产品

1、PixVerse 获 4.39 亿美元 C 轮融资，发布基于 R1 实时世界模型的游戏引擎 PixVerse Game Engine

AI 视频生成平台 PixVerse 宣布完成 C 轮延展融资，使该轮总融资额达到 4.39 亿美元。公司同步推出基于 R1 实时世界模型的 PixVerse Game Engine，正式进军游戏与互动娱乐领域，将视频生成能力转化为可即时响应、连续交互的实时生成式体验。

4.39 亿美元 C 轮融资：本轮延展融资由 Alibaba（阿里巴巴）、Lollapalooza Capital、Ivy Capital、Grand Mount Capital、东方富海（Dongfang Fuhai）、Mirae Asset、蓝色光标（BlueFocus）、CloudAlpha 以及老股东 iGlobe Partners 和 OCBC（华侨银行）旗下的 LionX Ventures 共同参与，累计 C 轮总额达 4.39 亿美元。
PixVerse Game Engine 机制与表现分离：该引擎将 R1 实时世界模型应用于游戏创作，将游戏抽象机制与视觉表达解耦。创作者或玩家通过自然语言定义规则与交互，系统实时渲染出对应的视觉与机制反馈，无需依赖传统的建模、动画和声音设计等前置开发管线。
R1 实时世界模型迭代：R1 模型于 2026 年 1 月发布，将视频生成由固定输出转为连续交互流；2026 年 4 月更新了「共享世界」与「个性化头像」功能，支持多用户共同接入并实时塑造同一个 AI 生成世界。
实时互动直播应用：基于 R1 模型的流式生成能力，PixVerse 推出实时互动直播技术，使 AI 生成角色或虚拟主播能够实时响应观众的输入并进行即时连续的画面交互。

官网链接🔗：

https://world.pixverse.ai/game/invite/

(@PixVerse）

2、关于发布 7 款提供手机端侧生成式人工智能服务已备案信息的公告

促进生成式人工智能服务创新发展和规范应用，网信部门会同有关部门按照《生成式人工智能服务管理暂行办法》要求，有序开展生成式人工智能服务备案工作，现将新增的「Apple 智能」等 7 款提供手机端侧生成式人工智能服务备案信息予以公告。

（@ 网信中国）

3、曝 OpenAI 首款硬件将是可移动、无屏幕 AI 音箱

据报道，OpenAI 计划推出一款可移动、无屏幕的智能音箱，作为面向人工智能时代的「家庭计算机」和 AI 伴侣。

该设备仍在研发中，预计今年公布、明年上市。报道称，这款设备将支持控制智能家居、播放媒体、回答问题、处理消息等功能，并接入 ChatGPT 的能力。

产品配备摄像头及其他传感器，可理解用户所处环境和上下文；内置电池则允许用户将其在家中不同房间之间移动。OpenAI 还希望设备能够随着使用时间增加，逐步了解用户并提供更个性化、主动式的服务，例如主动推送信息或预测用户需求。

在交互方面，该设备将使用更先进的 ChatGPT Voice Mode 版本 GPT-Live，支持同时聆听和回应，并让对话更接近自然交流。设备还加入了可自行移动的机械结构，以营造「像活着一样」的感觉。报道称，OpenAI 硬件部门目前正在开发约 5 款产品，后续还考虑推出可替代智能手机的移动 AI 设备、吊坠等可穿戴产品，以及家用机器人。

同时，该产品也面临法律风险。苹果日前起诉 OpenAI，指控其窃取商业机密，并要求限制 OpenAI 的硬件业务。OpenAI 则表示，自己「无意获取其他公司的商业机密」，目前也「没有发现这起诉讼具备依据的证据」。

( @APPSO)

03 有态度的观点

1、谷歌 DeepMind CEO 哈萨比斯：人类有个宝贵的窗口期来确保 AGI 是安全的

7 月 15 日消息，谷歌 DeepMind CEO 德米斯 · 哈萨比斯发出明确警告：能力极强的 AI 可能距离人类已经不远，社会各界必须加快准备。

哈萨比斯在 X 平台发布短文称，通用人工智能（AGI）到来前，人类仍有一个「宝贵的时间窗口」可以采取行动，AGI 可能再过短短几年便会出现。

哈萨比斯过去曾预测，AGI 最早可能于 2030 年问世，并多次警告社会准备远远不足。他去年在达沃斯表示：「未来五到十年发生的变化将极其重大，但我认为人们仍没有真正认识到这一点。」此外，他此前还提出，应当让哲学家、经济学家和其他领域的专家参与讨论，共同评估 AI 即将带来的深层社会影响。

哈萨比斯表示，AI 标准机构可以借鉴金融业监管局的模式。

哈萨比斯此次写道：「我们希望按照什么样的价值观生活，人生的意义和目标将是什么，甚至人类自身的处境会发生怎样的变化？显然，寻找这些问题的答案不能也不应只交给技术人员，而需要整个社会共同参与，定义这个新的时代。」

哈萨比斯进一步强调，留给人类采取行动的时间已经十分有限。「我们现在共同作出的选择，将决定文明下一阶段的发展方向。」

（@ 极客公园）

04 社区黑板报

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

1、活动推荐：Signal Eve | 创见前夜：在噪音到来之前，让真正的信号先发生

7 月 16 日晚，Impa Ventures 将与 SEE Fund 联合举办「Signal Eve｜创见前夜」，并邀请 Airwallex 空中云汇、TTC、RTE 开发者社区、亚马逊云科技、世博天地、S 创等生态伙伴一起共创。

我们希望它成为 WAIC 前夜的高密度交流场：在噪音到来之前，让真正活跃在 AI 一线的 founder、builder 和 investor 彼此看见，交换一手判断，捕捉那些尚未成为共识的早期信号。

详情链接：

Signal Eve | 创见前夜：在噪音到来之前，让真正的信号先发生

写在最后：

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

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

冲到 OpenAI 社区榜二，我做了个让 C 罗解说梅西比赛的 AI 解说员丨开源项目分享

RTE — Thu, 16 Jul 2026 23:43:52 +0800

四年一度的世界杯来了。看比赛的时候我冒出一个念头：解说员那么多如果没有我心仪的，能不能自己动手搓一个新的 AI 实时解说员？

于是就有了这个项目。做完我把它发到 OpenAI 的 Reddit 社区，没想到当天冲到了日榜第二，评论区不少人问原理、问怎么搭，还提出了很多我自己都没想到的新点子。所以干脆把原理和玩法整理成文，一次讲清楚。

先看一段效果。这场比赛是美国对阵比利时，解说员是"特朗普"：个人特色非常鲜明，夸人有自己的一套，还有自己的专属口头禅，总能将话题引到自己身上。

视频里发生的事，说白了就一句话：给一路真实的直播流，配一个会看画面、会实时开口的 AI 解说员。这就是我开源的 WorldCupVoice (https://github.com/zicojiao/worldcupvoice)。

它不是把比赛录下来事后配音，是真·实时：直播流进来，AI 看着和观众一模一样的画面，生成的语音再被送回直播间。世界杯只是它最好看的演示场景，这套链路适用于任何一路直播。

准确而言，这个不大的小项目，把「实时直播 + 大模型看懂画面 + AI 开口解说」这条最难的链路整个跑通了。

除了图一乐，好像还真能做点有意义的事情

一个是无障碍辅助（Accessibility），给视障人士做专业解说。

这个想法来自 Reddit 评论区一位网友的回复。真人解说默认"你看得见画面"，所以很多球场细节他不会讲——球在哪、压力从哪侧压上来、谁在悄悄前插。这些对看得见的人是废话，对看不见的人却是全部。AI 可以把这些被省略的空间信息补回来，给视障观众一份"看得见的解说"。它不是要取代真人，而是补上真人会跳过的那部分。

另一个是普及大众赛事，让普通人的比赛也有自己的解说席。

当直播与 AI 解说的链路打通，解说员的人设、语气、水平就都能换。脑洞随之打开：让"梅西"去解说 C 罗的比赛是什么画风？给小区幼儿园的足球赛配一段央视级解说，孩子追着球跑、旁白热血沸腾，光想就又好笑又期待。再往后，拔河、广场舞、公司年会的趣味运动会，都能有自己的"激情解说席"。

体育解说一直是少数专业场合才有的待遇。而这套东西，理论上能把 “专业解说” 下放给每一场普通人自己的比赛——这才是我觉得它最有意思的地方。

一图看懂 AI 实时解说的架构

很多人以为"AI 解说"就是丢段视频给大模型让它说几句。难点恰恰在于：这是直播，要求边看、边想、边说，还得快。顺着数据流走一遍就明白了：

直播源(OBS/编码器/本地视频)      │  RTMP 推流      ▼Agora Media Gateway  ← 把 RTMP 转成实时音视频      │      ▼  Agora RTC 频道  ──────────┐      │                          │      ▼                          ▼浏览器观众               AI 解说后端(看直播+听AI解说)        │ 1. 采样画面帧                       │ 2. 视觉模型"看懂"                       │ 3. TTS 生成语音                       └──→ 把 AI 声音回推到 RTC 频道

拆开看，频道里其实有三种角色在同一个房间里：

直播源：把画面推进来的那一路。可以是循环播放的本地视频，也可以是 OBS、摄像头、编码器送来的实时现场画面。
AI 解说员：一个"后端参与者"。它不停地采样当前画面 → 交给视觉模型理解 → 让 TTS 把解说词读出来 → 再把这段声音发回频道。
浏览器观众：你打开网页看到的那一端，同时播放直播画面、AI 的声音、解说文字，还有"解说间状态"。

关键巧思在这里：AI 看的不是另一路视频，而是和观众完全相同的那一路 RTC 画面。 这意味着它解说的就是你正在看的内容，不会"画音不对齐"。

技术栈也很主流：前端是 Next.js，后端是 Python 的 FastAPI，实时音视频用 Agora，视觉理解 + TTS 语音合成各司其职。

整体的技术设计中，最吃功夫的其实是"实时"这两个字：画面要实时进来，AI 生成的语音还得低延迟送回直播间。这部分我交给了 Agora——延迟一高，解说就跟不上画面、马上穿帮。选它也有个现成的好处：Agora 是 OpenAI Realtime API 的官方合作伙伴，SDK 和 OpenAI 打通得比较顺，接起来省了不少胶水代码。

项目设计的三个小巧思

第一，先给 AI"补课"，它才认得球员。

光看画面，AI 顶多说"穿红色球衣的球员"。所以我让你在 data/matches/ 里用一个 JSON 描述这场比赛：两队、球衣颜色、球员名单、剧情背景。喂了这份"小抄"，AI 才能喊出具体名字、贴着比赛叙事去解说。换个场景同理——你也可以把"参赛的是哪几个小朋友"写进去。

第二，声音才是解说的灵魂。

音色很大程度上决定了"像不像真转播间"。项目支持三套 TTS：

OpenAI TTS：默认就能跑通，适合先把流程打通。前面提到 Agora 是 OpenAI Realtime API 的官方合作伙伴，所以真要往"实时语音对话"那个方向做，这套组合也是最省心的。
ElevenLabs：能自己"调"一个体育解说音色，激情、有爆发力，最接近电视里那种。
Fish Audio：想做中文解说的话值得试试，我预留了"中文玩梗解说"和"中文战术解说"两种角色。

顺带提一句：开源仓库里只放了解说员的人设和 prompt，没把我自己的私有音色 ID 塞进去——音色你得自己去对应平台建。

第三，在线 ≠ 烧钱。

AI 实时看画面、实时说话，是真金白银的 token 消耗。所以我专门做了一套成本闸门：

明确的 Start AI / Stop AI 开关、观众"心跳"（没人看了就自动停）、每个会话还有硬性最长时长上限。后台部署在那儿，并不会偷偷一直烧钱。

如果你也想复刻，这里是教程指南

下面是面向开发者的精简版。完整命令以仓库 README 为准，这里帮你建立"先后顺序"的全局观。

1) 装前端、配环境变量

pnpm installcp .env.example .env.localopenssl rand -hex 32   # 生成一个后端密钥，前后端要填同一个

.env.local 里主要填 Agora 的 App ID / Certificate、后端地址、刚生成的密钥和一个本地访问密码。

2) 起后端（FastAPI）

cd serverpython -m venv .venv && source .venv/bin/activatepip install -r requirements.txt -r requirements-dev.txtcp .env.example .env.local      # 填 Agora、密钥、OPENAI_API_KEYpython -m uvicorn app.main:app --reload --host 127.0.0.1 --port 8000

3) 配 TTS 音色（可选，但强烈建议）

默认 OpenAI TTS 能用；想要"广播腔"就配 ElevenLabs，想要中文就配 Fish Audio，把对应的 voice ID 填进 server/.env.local。TTS 会让你的解说，更富有灵魂！

4) 起前端、进直播间

pnpm dev      # 打开 http://localhost:3000

5) 给它一路直播流

先在 Agora Console 启用 Media Gateway，用它的 REST API 生成 RTMP 推流 key（项目自带 pnpm run media-gateway:key 帮你生成）。然后三选一把画面推进去：

注意：仓库不内置任何比赛视频（转播画面有版权），你得自备一段 16:9 的 .mp4，或者直接接一路实时画面。配上前面那份比赛 JSON，解说效果会好很多。

6) 上线

前端部署到 Vercel，后端用 Railway 跑 Docker，前后端共用同一个密钥即可。

接下来想往哪走

路线图里几个方向，我觉得挺有想象力：

降低延迟：缩短"画面 → AI 开口"之间的时间差，越实时越像真解说；
多人解说：多个 AI 解说员同台，一个负责激情，一个负责战术分析，互相搭话；
无障碍专属模式：给视障观众提供更密集的球场空间信息；
多语言多音色：覆盖不同国家的语言和声音风格。

最后，聊点好玩的

做这个项目最爽的一刻，不是代码跑通，而是 AI 第一次对着画面喊出"好球！"的那一下——感觉就像你养的 AI 突然学会看球了，还看得特别投入。

以前聊语音合成，纠结的无非是音色像不像人、读得顺不顺。但解说这事儿，硬是把语音从"念稿机"逼成了"现场嘴替"：它得先看懂场上发生了啥，再用对的情绪、对的人设，在对的那一秒开口。会看、会想、会接话——它不再是被动播放的声音，而是个真能跟上节奏的搭子。

所以别只盯着球场。下次你家猫主子打架，说不定也能配上一段激情解说。

项目地址：

github.com/zicojiao/worldcupvoice（MIT 协议，可自由使用）。

觉得有意思，欢迎去点个 Star。

测试之家社区

直播录屏 -- 从需求生成测试用例的 SKILL 设计思路（主要是知识库设计）

如何让 AI 把测试用例的前置条件补到可执行

背景

演示条件

第一次输出为什么不能直接用

将前置条件拆成四类

推荐提示词

改写后的结构示例

评审时重点检查什么

1. 前置状态是否可以稳定准备

2. 前置条件是否混入预期结果

3. 每条规则是否有依据

4. 结果是否可观察

5. 是否包含清理和恢复

常见坑

适用边界

实测深度对比：kylinPET 奇林性压测工具与行业主流工具数据一致性、重复性

从冷启动到尾延迟：Go 与 Java 25 怎么选

各版本的新特性

Go 1.24（2025 年 2 月）

Java 25 LTS（2025 年 9 月）

基准方法与技术栈

启动时间与预热

Kubernetes 中的内存占用

请求吞吐量与尾延迟

负载下的 GC 行为

并发模型：Goroutine 与虚拟线程

结论

适合选择 Go 1.24

适合选择 Java 25

总结

新兴岗位，FDE--前线部署工程师，测试是不是可以转行做这个

设计一个多 Agent 的 UI 自动化测试工程（一）基础原理

开篇

AI 驱动 UI 自动化的模式

什么是多模态大模型

AI 识别控件的背景下要如何编码

让 AI 写代码的提示词

如何初始化这个 UI 自动化工程

结尾

聊聊 AI 的可信度

WorkBuddy 带我学: Python 高级知识点完全指南

网页平台：https://pythonplus.netlify.app/

网页截图

Python 高级知识点完全指南

目录

1. 知识版图总览

2. 魔术方法（Dunder Methods）全览

2.1 构造与析构：__new__ / __init__ / __del__

2.2 字符串表示：__repr__ / __str__ / __format__

2.3 运算符重载

2.4 容器模拟

2.5 可调用与属性访问

3. 描述符协议

3.1 描述符协议与 data/non-data 之分

3.2 属性解析顺序（为什么"实例属性可以遮蔽方法"）

3.3 描述符的典型实战

4. __slots__ 内存优化

4.1 内存与速度

4.2 使用代价与陷阱

5. 闭包与装饰器

5.1 闭包（Closure）的本质

5.2 装饰器（Decorator）= "接收函数、返回函数"的高阶函数

5.3 带参装饰器（三层嵌套）

5.4 类装饰器（持有状态）

5.5 装饰器叠加（执行顺序）

5.6 装饰器本质图

6. functools 工具集

6.1 partial — 偏函数（冻结部分参数）

6.2 lru_cache — 记忆化缓存

6.3 singledispatch — 单分派泛型函数

6.4 reduce — 累积归约

6.5 wraps / update_wrapper

7. 迭代器协议

迭代器 vs 可迭代对象的关系

8. itertools 与函数式工具

常见实用模式

9. 上下文管理器

9.1 类实现：__enter__ / __exit__

2.1 构造与析构：`new` / `init` / `del`

2.2 字符串表示：`repr` / `str` / `format`

4. `slots` 内存优化

6. `functools` 工具集

6.1 `partial` — 偏函数（冻结部分参数）

6.2 `lru_cache` — 记忆化缓存

6.3 `singledispatch` — 单分派泛型函数

6.4 `reduce` — 累积归约

6.5 `wraps` / `update_wrapper`

8. `itertools` 与函数式工具

9.1 类实现：`enter` / `exit`

9.2 `contextmanager` — 生成器方式（更简洁）

9.3 其他 `contextlib` 工具

10.3 协程的实战价值与 `yield from` 异常传播

11. `asyncio` 异步编程

12. `super()` 深度解析

12.2 `super()` 的两种形式

13.1 `type` 的三参数形式

14.3 常用 `collections.abc` 抽象基类

15. `collections` 常用容器

16. `dataclasses`

16.3 与 `slots` 结合 & 与 namedtuple 对比

17.3 结构化类型：`Protocol` / `TypedDict` / `Literal`

19.2 `weakref` — 打破循环引用

19.4 `id()` / `is` 与对象身份