小红书专场_Agent驱动的质效研发工程探索与实践-2026深圳站

优惠倒计时

早鸟票抢购中

团购享更多优惠

北京站 · 10月16-17日

上海站 · 9月4-5日

深圳站 · 5月22-23日

小红书专场：Agent驱动的质效研发工程探索与实践

AI Agent 正在成为质效研发工程的核心基础设施，推动工程能力从"工具叠加"走向"能力涌现"。当 Agent 架构真正进入质效研发的核心流程，自主规划、自主执行、自主验证的能力开始系统性重塑工程团队的生产力边界。小红书质效研发团队以 AI Native为理念，重塑架构风险分析、变更自动化、智能测试、代码知识化、性能体验测试等领域的工作流程，将过去依赖大量人工协同、高度碎片化的复杂工程问题，逐一转化为系统性的、可持续演进的智能化工程范式。这不是对原有流程的局部优化，而是对研发质效工程底层逻辑的系统性重构。本专场将汇聚小红书质效研发团队的一线实践，深入分享 Agent 架构设计、关键技术突破与规模化落地路径，与行业共同探索 Agent 时代研发质效工程的下一个范式。

专场出品人：白路

小红书搜推广引擎质量负责人

毕业于哈尔滨工业大学计算学部。先后就职于华为、百度，曾负责百度搜索、文心模型等核心产品的质效保障与稳定性能力建设，在引擎算法链路风险治理、研发效能提升、测试智能化及大模型效果评测等领域积累了丰富的实践经验。当前聚焦 Agent 驱动的智能变更管控与稳定性风险治理，探索 AI Native 时代的质效研发新范式。

郝栩彬

小红书 Coding Agent 研发工程师

小红书 Coding Agent 研发工程师，目前主要从事智能体受控长程任务研究工作，在上下文编辑（context editing）、多智能体场景有较多经验，毕业后曾就职于字节跳动和百度，从事 SaaS 、研发工具、及其智能化工作。

待定

亿级Token知识库的Agentic生成：企业级Wiki工程实践

议题背景

这两年，AI Coding 的变化非常快。最早大家感受到的是代码补全、代码解释，再往后是改 Bug、写单测、做 Code Review。到了最近一年，行业的热点已经明显变了：大家不再只关心模型会不会写一段代码，而是关心 AI 能不能像一个工程师一样，在真实开发环境里持续完成一个复杂任务。也正因为如此，“长程智能体”开始成为行业关注的重点。

大家逐渐发现，真正决定效果的，不只是模型本身，还包括模型外面的整套执行机制：任务怎么拆、上下文怎么管理、工具怎么调用、历史信息怎么保留、什么时候回退、什么时候继续下钻。这些问题在简单任务里不明显，但一旦任务持续时间变长、步骤变多、依赖变复杂，就会迅速成为系统成败的关键。

与此同时，行业里也出现了一个非常直观的方向：让 AI 直接“读懂一个仓库”。例如 Devin 的 DeepWiki，会自动为仓库生成文档、架构图、源码链接，并作为后续代码问答和仓库理解的基础设施。这说明行业已经认可：未来 AI Coding 不只是“补全代码”，还包括“理解一个系统”。

但问题也很快暴露出来了。对于一个真实的大型仓库，难点从来不是“让模型解释一小段代码”，而是：

- 仓库太大，模型一次根本读不完
- 问题往往跨模块、跨文件、跨服务
- 只做向量检索，容易只看到局部，看不到全局
- 多智能体一起干活，又很容易重复、跑偏、浪费 token
- 真正贵的不是生成一句解释，而是让 AI 在复杂任务里持续保持方向感

这正是今天这个议题想讨论的问题：当行业从“会写代码”走向“能长期完成复杂软件任务”时，仓库级理解能力会变成长程智能体的基础能力，而 CodeWiki 就是在这个背景下诞生的。

CodeWiki 不是简单把仓库扔给模型做 RAG，也不是只做一个自动文档工具。它要解决的是一个更底层的问题：在上下文窗口有限的前提下，怎样让 AI 分阶段、分层次地读懂一个大型代码仓库。为了解这个问题，我们把“大仓理解”拆成两步：先看全图，再读细节；先做大纲，再写内容。围绕这个目标，我们设计了路径压缩、代码骨架压缩、Glob Pattern 切分、四维度共享记忆、智能退避、应读尽读等一整套方法，最终把“让 AI 一次读完整个仓库”变成“让一组可协作的智能体，各自读懂自己该读的部分，然后拼成一个完整认知结果”。

所以，这个分享既会讲行业前沿，也会讲很具体的工程实践。前沿部分，我们会回答：为什么今天大家开始重视长程智能体；实践部分，我们会回答：当任务真正落到千万行代码仓时，一套能工作的代码理解系统到底应该长什么样。

内容大纲：

1. AI Coding 为什么进入了新阶段：从“写一段代码”到“长期完成任务”

1.1 过去两年的主线变化

1.1.1 代码补全 & 代码解释

1.1.2 Code Review / Bug Fix

1.1.3 仓库问答与自动文档

1.1.4 长程智能体开始进入真实开发流程

1.2 什么是长程智能体，什么是 harness

1.2.1 长程智能体：不是回答一句话，而是持续完成多步任务

1.2.2 Harness：不是模型，而是模型外面的工作机制

1.2.3 为什么 2026 年行业开始关注 harness，而不只是关注模型参数

1.3 为什么“读懂仓库”会成为基础能力

1.3.1 不理解仓库，就无法稳定改代码

1.3.2 不理解上下文，就很难做长期任务

1.3.3 仓库理解是代码问答、自动文档、自动改码的共同底座

2. 为什么传统做法在大仓上会失效

2.1 小任务能做，大任务为什么不行

2.1.1 看 20 行代码很容易

2.1.2 看一个接口全链路就开始变难

2.1.3 看一个大型仓库几乎不可能一次完成

2.2 真正的瓶颈不是模型不会，而是上下文不够

2.2.1 文件太多

2.2.2 路径太长

2.2.3 调用关系太复杂

2.2.4 一次性塞进 Prompt 的方法很快失效

2.3 常见方案的问题

2.4.1 单轮 Prompt：覆盖太少

2.4.2 普通 RAG：容易局部命中、全局失真

2.4.3 单 Agent：容易反复探索

2.4.4 多 Agent：容易重复写、容易跑偏

3. CodeWiki 的核心思路：不要一次读完仓库，而是把它拆成能做的小任务

3.1 两阶段方案

3.1.1 第一阶段：生成大纲，先看清全图

3.1.2 第二阶段：生成内容，再深入细节

3.2 路径压缩

3.2.1 为什么文件路径是隐形 token 黑洞

3.2.2 如何用目录树结构替代长路径

3.2.3 这样做的收益是什么

3.3 代码压缩

3.3.1 为什么大纲阶段不需要看全部实现

3.3.2 只保留类、方法、关键注释的价值

3.3.3 怎样用少量 token 保留结构信息

3.4 Glob Pattern 切分

3.4.1 为什么目录结构本身就代表工程经验

3.4.2 怎样用目录边界切分任务

3.4.3 为什么这样比纯 call graph 更适合很多企业仓

4. 让多智能体真正协作起来：从能跑 Demo 到能进生产

4.1 BFS 式展开

4.1.1 为什么先广度展开，再逐层深入

4.1.2 如何避免一开始就钻进局部细节

4.2 四维度共享记忆

4.2.1 任务目标

4.2.2 上下文背景

4.2.3 当前关注点

4.2.4 避免重复和越界

4.2.5 为什么多智能体最怕“每个人都很努力，但不在一个方向上”

4.3 智能退避

4.3.1 如何处理重复章节

4.3.2 如何避免多个 Agent 写同一件事

4.3.3 如何给过小任务补充上下文

4.4 应读尽读

4.4.1 为什么前面在压缩，最后又要完整阅读

4.4.2 什么时候该省 token，什么时候不该省

4.4.3 如何兼顾全局视野和代码细节

4.5 跟长程智能体趋势的关系

4.5.1 仓库理解本身就是长程任务的一部分

4.5.2 真正的关键不只是模型，而是 harness

4.5.3 CodeWiki 可以看作面向大型代码仓的一种专用 harness 设计

5. 工程实践与收益

5.1 实际踩过的坑

5.1.1 只给代码骨架会幻觉

5.1.2 多 Agent 容易重复探索

5.1.3 任务拆太碎后容易失去整体感

5.1.4 压缩过头会影响最终文档质量

5.2 采取的实践

5.2.1 AST 引用关系注入

5.2.2 四维度共享记忆

5.2.3 语义相似度退避

5.2.4 小模块补充召回

5.2.5 章节级应读尽读

5.3 收益

5.3.1 可以覆盖更大规模仓库

5.3.2 提高 token 效率

5.3.3 提升内容完整度与可读性

听众收益：

听懂 2026 年 AI Coding 的新热点到底是什么不再只看模型会不会写代码，而是理解为什么行业开始重视 harness、长程智能体和仓库级理解。

理解“AI 读懂大仓”到底难在哪里听众会建立一个很直观的认知：难点不是代码生成本身，而是上下文窗口有限、任务跨模块、结构信息复杂、协作成本高。

拿到一套更接近生产的解决思路不管团队是在做代码问答、自动文档、代码搜索还是智能体改码，都可以借鉴“两阶段拆解 + 压缩 + 边界切分 + 协作约束”这套方法。

知道多智能体系统为什么常常做不稳，以及怎么改听众能理解共享记忆、智能退避、应读尽读这些工程机制为什么重要，而不是只停留在“多开几个 agent”。获得一个连接行业前沿和真实落地的案例既能了解 DeepWiki、长程智能体、benchmark 这些前沿趋势，也能看到一套在真实大型仓库中可落地的方法。

李伟

小红书 BC 数据链路质量负责人

小红书BC数据链路质量负责人，长期深耕数据传输跨端传输的数据一致性保障。主导构建BC链路字段血缘采集能力、通用数据测试能力，覆盖常见16种数据协议。近期专注于将 AI Agent 技术应用于广告数据链路变更自动化，主导设计并落地了 ArkAI Prism 系统。

待定

基于Multi-Agent的B/C数据链路变更自动化保障

议题背景：

广告数据链路（投放端 → ADBus → 在线索引）的字段变更是日常高频且高风险的工程动作：涉及跨团队协作、多平台操作、影响面评估、审批流转等多个环节，每次变更都需要多人多天串行推进，极易出现遗漏、错序或影响面评估盲区。

传统方式依赖"人传人、手动改、靠经验"，缺乏系统化的变更追溯和影响面分析能力，变更质量参差不齐。随着广告业务快速迭代，如何让复杂的跨团队链路变更变得可自动化、可追溯、可审计，成为亟待解决的工程难题。

内容大纲：

1. 背景与痛点

1.1 广告 BC 链路三层架构：Adcore → ADBus → Index

1.2 字段变更的现状：多团队、多平台、易出错

1.3 量化痛点：平均一次变更需多人协作、多天完成

2. ArkAI Prism 系统设计

2.1 整体架构：Supervisor + Specialist Agent 分层协作

2.2 Supervisor 层：持有全局上下文与执行计划，动态调度各端专家 Agent

2.3 Specialist Agent：Adcore 端、ADBus 端、Index 端各自专注

2.4 模块化 SKILL 设计：能力热插拔，支持快速扩展新链路

2.5 记忆机制：RAG 驱动跨会话长期记忆 + 短期上下文管理

3. 核心技术挑战与解法

3.1 自动化编排变更流程

3.2 字段血缘自动分析

3.3 影响面自动评估与变更拦截预检

3.4 变更全程留痕与可追溯审计

4. 落地效果与收益

4.1 变更推进效率显著提升

4.2 人工沟通成本大幅降低

4.3 变更遗漏/错序问题归零

5. 经验与展望

5.1 将 Agent 应用于强规则域的设计取舍

5.2 下一步：更多链路接入、变更回归自动验证

听众收益：

1. 可落地的 Multi-Agent 架构设计：Supervisor + Specialist 分层模式在实际工程场景的完整落地经验，可直接借鉴到其他复杂流程自动化场景

2. 字段血缘分析的工程实践：如何从代码库 + 配置中心双源自动构建字段链路图谱，解决数据治理中的血缘追踪难题

3. Agent 应用于强规则域的设计原则：如何在保持 Agent 灵活性的同时，通过硬性规则引擎保障高风险操作的安全边界

4. 群聊驱动的 AI 协同模式：以会话为唯一入口、全程不换平台的工程实践与踩坑经验

5. 量化收益数据参考：具体效率提升和质量改善数据，可作为内部立项依据

肖俊

小红书质效研发工程师

现任小红书-质效研发部-质效研发工程师，目前主要负责小红书服务端质量可测性建设，以及智能化测试的探索与创新实践，致力于将 AI 能力系统性地融入测试研发效能体系。此前也就职于网易游戏、网商银行，负责过多个业务的质量保障工作，在研发效能提升、资损防控、测试智能化等领域积累了丰富的实践经验。

待定

LLM驱动端到端测试体系

议题背景：

随着小红书业务的持续扩张，服务端端到端测试面临日益严峻的挑战。端到端测试天然具有跨域、长链路的特点——以一笔电商订单的测试为例，需要横跨商品域、交易域、支付域、直播域等多个业务域，完成从数据构造、业务流程执行到全链路数据验证的完整闭环。场景稍有变化，测试流程便大幅延伸，而每个环节的参数组合与校验规则都极为复杂。传统自动化方案需要人工提前封装原子化工具、编写编排脚本、维护校验逻辑，开发和维护成本居高不下，导致端到端自动化长期只能覆盖有限的回归场景，测新阶段依然高度依赖手工测试，效率瓶颈难以突破。

端到端测试的本质，是将数据构造、用例执行、数据验证三个环节有机串联。然而，这三个环节在传统方案中各自都面临"工程化刚性"的困境：造数流程跨域复杂，场景灵活多变，脚本难以覆盖；用例执行依赖预定义编排，长链路的流程调整成本高；数据验证规则繁多，横跨 DB、日志、消息、缓存等多个维度，手工校验效率极低。转机在于 LLM 的能力突破：大模型具备强大的推理与规划能力，能够理解自然语言描述的测试需求，结合领域知识库动态生成执行计划，自主串联接口完成各环节工作。这为我们提供了一条系统性构建 LLM 驱动端到端测试体系的可行路径。

本次分享将围绕三个核心环节的实际落地展开。数据构造：利用 LLM 的推理与规划能力，结合子域知识库和工具管理平台，根据自然语言描述的需求动态生成构造计划，自主调用并串联业务接口，灵活覆盖复杂多变的测试数据场景；用例执行：建设基于 LLM 的端到端自动化用例生成能力，从文本用例描述出发，自动生成可执行的接口调用序列，实现长链路测试流程的智能化编排与自动驱动；数据验证：构建全链路数据校验能力，基于trace 和业务单号自动获取 DB、日志、消息、出入参等多维数据，结合 LLM 对校验规则的理解，完成自动化结果验证。三个环节逐步演进、有机整合，最终形成 LLM 驱动的端到端测试完整闭环。

内容大纲：

1. 背景与问题

1.1 端到端测试难点分析：天然跨域，长链路，流程场景，场景
1.2 传统方案的共同困境：「工程化刚性」

1.2.1 造数：依赖其他业务域知识和工具；跨域协作成本高

1.2.2 执行：依赖预定义编排，长链路流程调整牵一发动全身

1.2.3 验证：DB / 日志 / 消息 / 缓存多维度，写 assert 不如端上看界面

1.2.4 结果：自动化只能覆盖有限固定回归场景，测新阶段强依赖手工

1.3 突破口：LM 能做什么

1.3.1 理解自然语言描述的测试需求

1.3.2 推理规划：从需求反推执行步骤，动态生成计划

1.3.3 自主串联接口：不需要预定义流程，按需调用

2. 整体方案

2.1 LLM 驱动的端到端自动化测试体系
2.1.1 LLM 具备强大的推理与规划能力，能理解自然语言需求、结合知识库动态生成执行计划，增强动态性
2.1.2 LLM 具备非常强大的编码和工具调用能力，自主调用&串联业务接口，无需人工封装和提供原子化能力
2.2 测试执行Agent：
2.2.1 以编码 Agent 为核心调度，将端到端测试拆分为用例执行和数据校验两大环节；
2.2.2 建设思路：数据构造作为最小落地场景率先验证，再逐步延伸至执行和验证，分阶段构建完整闭环
2.3 核心架构：编码 Agent（调度核心）+ 用例执行 / 校验 / 用例生成等 Skill（能力模块）+ 知识库 / 脚本资产库 /
接口元信息管理（基础支撑层）

3. 数据构造：

3.1 动态造数：Agent + 逆向链式规划 + 动态执行——从"交付目标"逆向推导前置依赖，跨域长链路自动串联
3.2 渐进加载：知识库 + 元信息渐进加载，减少上下文
3.3 脚本缓存：脚本生成 + “流量回放”验证 + RAG 召回复用——相似需求直接命中执行，降本&提升&更稳定

4. 用例执行与数据验证

4.1 用例执行：基于接口元信息，LLM 将自然语言用例转化为结构化执行计划，自动串联接口完成端到端流程
4.2 数据验证：基于 trace / 业务单号拉取全链路数据（DB / 日志 / 消息 / 缓存），LLM 根据校验点自动判断结果

5. 总结&规划

5.1 效果：
5.1.1 跨域造数从小时级降至分钟级，脚本命中后秒级完成
5.1.2 端到端自动化用例自动生成，覆盖xx业务域示例
5.2 展望&规划
5.2.1 TestAgent：测试分析Agent + 测试执行Agent

听众收益：

1. LLM 驱动端到端自动化测试体系：AI时代，如何利用大模型来建立端到端的自动化测试方案

2. 测试执行Agent的基本框架：使用“AI动态执行“ + “脚本复用”方案，即利用了LLM强大的自主决策、动态规划能力，也利用了用例脚本的高效和确定性

3. 测试执行Agent的上下文控制实践：基于业务子域的动态加载 + 渐进式加载方案，节省上下文

张雨

小红书质效研发工程师

小红书质效研发团队质效研发工程师，目前主要负责小红书性能体验质量领域建设，聚焦端侧性能度量、体验优化与质量保障体系构建，致力于通过工程化与智能化手段持续提升小红书 App 的用户体验与性能表现。毕业后曾就职于美团，专注于大前端智能化测试方向，研究涵盖多模态 UI 意图理解、智能遍历测试、GUI Agent 等领域，主导及核心参与 KuiTest、AUITestAgent 等代表性成果落地，推动 UI 测试从传统脚本驱动迈向大模型认知驱动。

待定

AI 驱动的客户端性能体验全链路保障：

从代码风险预判到用户感知度量

议题背景：

客户端性能体验（启动/页面加载耗时、滑动流畅度、元素交互响应时长等）是社交/内容平台类 App 的核心竞争力之一，直接影响用户留存和使用时长。然而，客户端性能体验测试在实践中长期面临几个棘手的困境：

1. 体验问题发现滞后：测试往往优先保证功能，而体验问题往往被忽略，在代码合入甚至上线后才被发现。定位和修复的成本远高于编码阶段，且已经影响了真实用户体验。

2. 体验度量可观测性难题：预埋性能打点，口径不统一、维护成本高、只能度量"技术意义上的加载完成"，而非"用户视觉感知的加载完成"，人工目测的精度差、成本高，难以规模化。

3. 从代码分析到测试执行的断层：代码白盒分析能发现"可能有性能风险"的代码变更，但分析结果无法自动转化为具体的测试行为——需要人工判断"这个风险需要跑哪些测试用例来验证"，然后手动触发。

4. 缺乏统一的性能体验评价标准：性能测试产出的是一堆零散指标（启动时间、帧率、内存峰值、CPU 占用……），但没有一个能回答"这个版本的整体体验到底好不好"的综合评分，真实用户体验反馈与测试体系也存在脱节。

针对当前困境，我们的核心思路是用 AI 能力贯穿性能测试的全生命周期，构建一个多维度、多层次的闭环体系，具体展开为五个层次：

事前预判：AI 阅读代码 diff，结合性能规则知识做风险预判，在 MR/提测阶段给出预警

智能用例：基于代码分析结果自动生成针对性的性能测试用例，减少人工编写成本

自动化验证：自动化测试 + 性能数据采集系统级指标 + 专项检查（卡顿分析、内存泄漏检测）

感知度量：基于录屏的 AI 视觉分析（传统图像处理 + CV 模型 + VLM 多层融合），从用户视角精确度量体验

体验评分：定义统一的 metrics 体验分标准，将零散指标聚合为可驱动决策的综合评分

众测补充：通过众测平台收集真实用户场景下的体验问题，反哺测试用例库和风险知识库

最终目标是让性能体验测试从"主要由人驱动的评测工作"变为"AI 驱动的持续性保障"。

内容大纲：

1. 性能体验测试的现状与挑战

1.1 客户端性能体验为何重要

1.1.1 内容平台场景下的性能关键路径：冷启动、Feed 加载、图片/视频渲染、页面跳转

1.1.2 性能劣化与用户留存的关系（引用行业数据）

1.2 传统测试方法的局限

1.2.1 埋点度量 vs 用户感知之间的 gap

1.2.2 手工测试的不可复现性和效率瓶颈

1.2.3 工具散落、流程人肉串联的现状

1.2.4 代码分析与测试执行断层

1.2.5 缺乏统一的体验评价标准

1.3 我们的解题思路

1.3.1 一条主线：AI 贯穿全链路

1.3.2 一个闭环：代码变更 → 风险预判 → 用例生成 → 自动验证 → 感知度量 → 体验评分

1.3.3 一个补充：众测反馈持续反哺

2. 技术方案设计与选型

2.1 整体架构：全链路性能测试体系

2.1.1 六层架构：代码白盒层 → 用例生成层 → 自动化执行层 → 专项检查层 → AI 度量分析层 → 体验评分层

2.1.2 外围支撑：众测反馈环 + 埋点数据（规划中）

2.1.3 各层的职责边界、数据流转和当前成熟度

2.2 代码白盒扫描层：AI 驱动的性能风险预判

2.2.1 ReAct模式的代码扫描模式而非独立单文件检查

2.2.2 输入：代码 diff + 文件上下文 + 性能规则库

2.2.3 输出：风险等级 + 风险原因 + 建议修改方案

2.2.4 关键技术决策：

- LLM vs 传统静态分析工具（AST/lint）：语义理解能力、跨文件关联分析、自然语言解释

- 误报率控制：多轮验证、置信度分级

2.3 用例生成层：从代码分析到测试用例的自动转化

2.3.1 核心目标：代码变更 → 影响面分析 → 自动生成性能测试用例

2.3.2 技术思路：

- 代码变更影响面分析：调用链追踪，定位受影响的用户场景（页面/操作路径）

- 场景→用例映射：基于场景库将受影响场景映射为性能测试用例模板

- LLM 辅助用例细化：根据具体代码变更内容调整用例参数和检查点

2.3.3 执行层：生成的用例直接下发到自动化执行层

2.4 自动化执行层：三端GUI自动化 + 性能数据采集 + 录屏

2.4.1 整体框架：底层driver + GUIAgent/脚本 + 性能数据采集

- 自动化执行层以底层 driver 为基础，结合 GUIAgent与脚本实现UI操作，同步采集 FPS、内存、CPU 等性能

指标，并全程录屏以支持问题回溯与定位。

- 性能场景的特殊操作支持弥补GUIAgent能力边界：区别于普通功能自动化，性能测试对操作的真实性和压力

模拟有更高要求。部分典型场景需要特殊的操作手法，例如：快速连续滑动 / 反复进入退出 / 长时间后台/前

台切换。

2.4.2 多维测试矩阵：高/中/低端机分档策略 + 弱网模拟（2G/3G/高丢包/高延迟等），确保性能数据覆盖真实用户

的设备和网络分布

2.5 专项分析层：卡顿分析与内存泄漏检测

2.5.1 针对卡顿与内存泄漏两类核心问题，采用"现象检测 → 代码白盒归因"的两阶段分析路径：运行时先捕获异常

信号（帧率抖动、内存增长），再结合代码层分析与离线快照深度定位根因——Android 基于 hprof + MAT，

iOS 基于 memgraph + leaks 工具，AI 辅助识别典型问题模式并给出问题定位。

2.6 AI度量分析层：录屏分析与性能数据分析

2.6.1 录屏页面加载耗时AI分析：拆帧 -> 简单场景传统图像处理与CV方法筛选 -> 复杂场景MLLM精筛

- 第一层：传统图像处理（SSIM、像素差异）：快速筛选关键变化帧，过滤静态帧。对于静态页面加载场景，

通过 SSIM 相似度曲线直接定位起止帧，计算加载耗时，无需进入后续分析，成本最低。

- 第二层：CV 模型：通过YOLO或OCR方式，针对下拉刷新、触底加载等标准交互场景，检测加载态 UI 元素

（Loading 动画、Spinner、骨架屏等）的出现与消失，精确标定加载开始与结束时刻。该层覆盖大多数有固

定加载态 UI 的通用场景。

- 第三层：MLLM（视觉语言模型）：处理前两层无法覆盖的复杂语义场景，如"首元素是否真正渲染完成"、

"内容区域是否从占位图切换为真实数据"等，依赖模型对页面语义的理解做出判断。仅对第一、二层筛选后

的候选帧调用，控制推理成本。

2.6.2 性能数据AI分析：内存防劣化等

2.7 体验评分层：定义 Metrics 体验分标准输出结论

2.7.1 指标选取：哪些指标真正影响用户体验感知？（启动时间、页面加载耗时、滑动帧率、卡顿频次、内存占用、

崩溃率……）

2.7.2 场景加权：不同场景对用户体验的影响权重不同（如ASR场景要求首字延迟与跟嘴耗时、视频类要看丢帧率等）

2.7.3 劣化判定：什么程度的分数下降需要阻塞发布

2.8 众测评分层：真实用户体验捕获反馈

2.8.1 当前流程：众测平台收集问题与打分 → 人工筛选分类（功能 bug / 体验问题）→ 转需求/缺陷

2.8.2 机器评测是主体，但人感评测不可或缺。指标好看不等于体验好——交互节奏的违和感、响应时机的微妙偏

差等，往往难以被数据直接捕获。众测通过内部同学的主观评测恰好弥补这一盲区，两者定期交叉复盘：机器

评测与人感结论互相印证，持续迭代优化指标体系与场景库。

3. 工程落地与效果

3.1 流水线串联：从代码提交到性能报告

3.1.1 完整的闭环流程：代码提交 → 白盒风险预判 → 智能用例生成 → 自动化执行（录屏、性能数据采集）→

AI 录屏耗时分析与专项检查 → 体验分计算 → 报告输出

3.1.2 流程编排可靠性：任一环节失败时的降级策略——核心链路（自动化执行 + 指标采集）保障优先，增强链路

（AI 分析 + 体验分）允许异步重试

3.2 数据打通与可视化

3.2.1 性能基线管理：如何建立和维护性能基准数据

3.2.2 趋势分析：版本间性能变化的追踪和预警

3.3 已取得的效果

3.3.1 性能体验自动化回归覆盖小红书 100% P0场景，单业务线每周节约1.5pd+人力

3.3.2 上线以来有效拦截 100+ 个性能体验问题

3.3.3 执行3次众测，发现性能问题12个

4. 展望

4.1 埋点 + 运行时 + 视觉分析三源融合：构建最完整的体验画像

4.2 众测智能化：AI 辅助众测问题分类、自动关联已知问题、自动转化为回归用例

4.3 持续迭代人感体验得分的定义与分析方法，覆盖更多人感体验问题的检测场景

听众收益：

1. 获得一套可落地的客户端性能体验测试全链路方案：了解如何将 AI 白盒分析、GUI 自动化、性能数据采集、AI 视觉耗时分析整合为端到端流程，可直接借鉴到自己团队的性能保障体系建设中。
2. 掌握"基于录屏 + AI 视觉分析"度量用户感知耗时的技术方案：学习传统图像处理 + CV 模型 + VLM 三层融合的设计思路，理解每一层的适用场景和成本权衡，解决"埋点度量不等于用户感知"的行业共性难题。
3. 了解 LLM 在代码性能风险预判中的实际效果和局限性：包括代码风险预判、测试用例生成、卡顿/泄漏归因分析等不同环节中 LLM 的应用方式，以及每种应用的实际效果和当前局限性，帮助做出合理的技术选型。
4. 获得性能体验分指标体系设计的思考框架：了解如何从零散的性能指标走向统一的体验评分，包括指标选取、场景加权、基准定义等设计要素，以及避免"刷分"等实际落地中的陷阱。
5. 理解众测在性能保障体系中的定位和价值：了解如何将众测从"独立的问题收集渠道"整合为性能保障闭环的有机组成部分，实现真实用户反馈对自动化测试用例库和风险知识库的持续反哺。

陈圣

小红书测试开发工程师

现任小红书质效研发团队测试开发工程师，主要负责小红书大型活动压测与稳定性保障工作，支撑社区、交易、AGI 等核心业务线在大促及重点活动场景下的服务端容量评估、风险识别与稳定性建设。长期聚焦性能测试、压测体系建设和质量工程化能力沉淀，在复杂业务场景下的流量特征分析、容量边界评估和稳定性风险发现方面积累了较丰富的一线实践经验。此前也曾在百度、字节跳动等公司从事测试保障及相关横向治理工作，持续深耕质量与稳定性领域。

待定

大模型压测数据构造：质量跃迁之路——从能跑到真管用

议题背景：

随着大模型在问答、搜索、Agent、内容生成等场景中的快速落地，压测工作的难点正在从“如何发起压力”逐步转向“如何构造有效数据”。相较于传统服务，大模型系统的资源消耗和性能表现对输入内容高度敏感，请求的长度分布、上下文轮次、输出规模、场景类型、调用路径等因素，都会直接影响压测结果的真实性和参考价值。因此，在大模型场景下，压测数据已不再只是执行压测的输入材料，而是决定压测结论是否可信的关键前提。

实际工作中，一个典型问题是：很多压测数据虽然具备基本可用性，但缺乏对真实业务特征的还原。过于模板化、均质化的数据，往往只能覆盖理想化场景，难以体现真实线上请求在长度、复杂度、场景比例和交互模式上的差异，也难以暴露长尾负载、复杂输入和混合场景下的真实压力特征。最终会导致压测结果“看起来稳定”，但对容量评估、风险识别和优化决策的支撑有限。

因此，本议题希望聚焦大模型压测中的数据构造问题，讨论如何从真实业务出发，提炼影响性能的关键特征，构造兼顾真实性、覆盖性与复杂度的数据集；如何避免“数据能跑但不具代表性”的问题；以及如何让压测数据从简单的请求样本，升级为能够支撑容量评估、风险发现和优化验证的高质量测试资产。希望通过这一议题，推动大模型压测从关注执行过程，进一步前移到对数据构造方法的系统思考。

内容大纲：

1. 大模型压测为何首先卡在“数据构造”

1.1 传统压测数据构造方法在大模型场景下面临失效

1.2 什么样的压测数据才能脱离“可用”的范畴，达到“好用”的标准

2. 问题分析：大模型压测数据构造到底难在哪里

2.1 「像不像」业务真实性难还原

2.2 「全不全」覆盖性难保障

2.3 「分不分」复杂度难分层

3. 解决思路：从“请求样本”转向“负载特征”

3.1 明确数据构造目标：先定义“要模拟什么压力”

3.2 提炼影响性能的关键特征为度

3.3 建立“真实性、覆盖性、复杂度”三层数据框架