小红书专场：Agent驱动的研发效率工程探索与实践
AI Agent 正在成为 研发效率工程的核心基础设施，推动工程能力从"工具叠加"走向"能力涌现"。当 Agent 架构真正进入 AGEE 研发的核心流程，自主规划、自主执行、自主验证的能力开始系统性重塑工程团队的生产力边界。小红书 AGEE 团队（Anti-Gravity Efficiency Engineering）以 AI Native 为理念，重塑架构风险分析、变更自动化、智能测试、代码知识化、性能体验测试等领域的工作流程，让工程团队从重复性摩擦中"失重"解放，将过去依赖大量人工协同、高度碎片化的复杂工程问题，逐一转化为可持续演进的智能化工程范式。这不只是对原有流程的局部优化，而是重新定义研发工程的底层逻辑。本专场将汇聚小红书 AGEE 团队的一线实践，深入分享 Agent 架构设计、关键技术突破与规模化落地路径，与行业共同探索 Agent 时代研发工程的下一个范式。
专场出品人：白路
小红书 搜推广效率工程负责人
毕业于哈尔滨工业大学计算学部。先后就职于华为、百度，曾负责百度搜索、文心模型等核心产品的质效保障与稳定性能力建设，在引擎算法链路风险治理、研发效能提升、测试智能化及大模型效果评测等领域积累了丰富的实践经验。当前聚焦 Agent 驱动的智能变更管控与稳定性风险治理，探索 AI Native 时代的质效研发新范式。
郝栩彬
小红书 AI工程架构师
小红书 AI工程架构师，目前主要从事智能体受控长程任务研究工作，在 上下文编辑（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.3.1 单轮 Prompt：覆盖太少
2.3.2 普通 RAG：容易局部命中、全局失真
2.3.3 单 Agent：容易反复探索
2.3.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 这些前沿趋势，也能看到一套在真实大型仓库中可落地的方法。
李伟
小红书 AI工程架构师
小红书 AI工程架构师，长期深耕数据传输跨端传输的数据一致性保障。主导构建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工程架构师
现任小红书 AI工程架构师，主要负责小红书大型活动压测与稳定性保障工作，支撑社区、交易、AGI 等核心业务线在大促及重点活动场景下的服务端容量评估、风险识别与稳定性建设。长期聚焦性能测试、压测体系建设和质量工程化能力沉淀，在复杂业务场景下的流量特征分析、容量边界评估和稳定性风险发现方面积累了较丰富的一线实践经验。此前也曾在百度、字节跳动等公司从事测试保障及相关横向治理工作，持续深耕质量与稳定性领域。
待定
待定
大模型压测数据构造：质量跃迁之路——从能跑到真管用
议题背景：
随着大模型在问答、搜索、Agent、内容生成等场景中的快速落地，压测工作的难点正在从“如何发起压力”逐步转向“如何构造有效数据”。相较于传统服务，大模型系统的资源消耗和性能表现对输入内容高度敏感，请求的长度分布、上下文轮次、输出规模、场景类型、调用路径等因素，都会直接影响压测结果的真实性和参考价值。因此，在大模型场景下，压测数据已不再只是执行压测的输入材料，而是决定压测结论是否可信的关键前提。
实际工作中，一个典型问题是：很多压测数据虽然具备基本可用性，但缺乏对真实业务特征的还原。过于模板化、均质化的数据，往往只能覆盖理想化场景，难以体现真实线上请求在长度、复杂度、场景比例和交互模式上的差异，也难以暴露长尾负载、复杂输入和混合场景下的真实压力特征。最终会导致压测结果“看起来稳定”，但对容量评估、风险识别和优化决策的支撑有限。
因此，本议题希望聚焦大模型压测中的数据构造问题，讨论如何从真实业务出发，提炼影响性能的关键特征，构造兼顾真实性、覆盖性与复杂度的数据集；如何避免“数据能跑但不具代表性”的问题；以及如何让压测数据从简单的请求样本，升级为能够支撑容量评估、风险发现和优化验证的高质量测试资产。希望通过这一议题，推动大模型压测从关注执行过程，进一步前移到对数据构造方法的系统思考。
内容大纲：
1. 大模型压测为何首先卡在“数据构造”
1.1 传统压测数据构造方法在大模型场景下面临失效
1.2 什么样的压测数据才能脱离“可用”的范畴，达到“好用”的标准
2. 问题分析：大模型压测数据构造到底难在哪里
2.1 「像不像」业务真实性难还原
2.2 「全不全」覆盖性难保障
2.3 「分不分」复杂度难分层
3. 解决思路：从“请求样本”转向“负载特征”
3.1 明确数据构造目标：先定义“要模拟什么压力”
3.2 提炼影响性能的关键特征为度
3.3 建立“真实性、覆盖性、复杂度”三层数据框架
4. 技术抉择：数据“从哪里来”，“到哪里去”
4.1 数据来源选择：真实流量、模板生成还是混合构造
4.2 数据集构建方式选择：追求全量仿真还是分场景建模
5. 过程中踩过的坑与关键反思
5.1 只关注平均分布，忽略长尾样本
5.2 数据集构造与压测目标没有强绑定
6. 总结与可复制经验
6.1 核心结论
6.2 启发与展望
听众收益：
1. 建立系统认知：理解大模型压测中，数据构造为何比传统场景更直接决定压测结果的真实性与有效性。
2. 获得分析框架：学习如何从真实性、覆盖性、复杂度等维度分析和构造高质量压测数据。
3. 借鉴落地经验：了解实际推进中的典型问题、技术取舍与避坑思路，提升方案落地效率。
4. 参考工程实践：掌握数据标签化、分层管理、质量校验、版本化沉淀等可复用的工程方法。
肖俊
小红书 AI工程架构师
现任小红书 AI工程架构师，目前主要负责小红书服务端质量可测性建设，以及智能化测试的探索与创新实践，致力于将 AI 能力系统性地融入测试研发效能体系。此前也就职于网易游戏、网商银行，负责过多个业务的质量保障工作，在研发效能提升、资损防控、测试智能化等领域积累了丰富的实践经验。
待定
待定
LLM驱动端到端测试体系
议题背景：
随着小红书业务的持续扩张，服务端到端测试面临日益严峻的挑战。端到端测试天然具有跨域、长链路、组合爆炸三大特点——以买手分账订单为例，需横跨商品域、买手域、交易域、支付域等多个业务域，概念对齐就耗掉大半天，每引入一个新维度，用例矩阵就成倍膨胀，手工造数时间从分钟级飙升至天级。
传统工程化方案采用原子能力封装加流程编排，在主流程回归场景下确实有效，但根本矛盾难以回避——人工预制的编排逻辑是静态的、有限的，真实业务的组合空间是动态的、无穷的。结果是只能覆盖约 20% 的高频路径，剩下依然高度依赖手工测试，且极易腐化。
转机在于 AI 时代的破局思路。我们没有沿用 AI 辅助编排的主流路线，而是让 Agent 直接感知业务接口、自主规划执行链路——流程编排是面向人的思路，AI 时代应该让 Agent 直接理解意图、自主调用。测试执行 Agent 具备两大核心能力：其一，动态规划——通过逆向链式推导实时生成执行计划，无需任何预设编排；其二，自适应执行——有脚本秒级复用，无脚本则"先调试、后编写"，并通过流量回放机制完成全自动自验证。两者结合，以 Plan-and-Execute 保证方向、以 ReAct 保证执行韧性。
在建设成果上，跨域造数从小时级降至分钟级，脚本命中后可实现秒级完成；22 种审核处置场景实现端到端用例全覆盖。我们也沉淀了两条核心认知：提示词质量取决于对业务本质的深度思考（Prompt 是业务题，不是语文题）；记忆能力是决定 Agent 泛化能力与稳定性的关键变量。展望未来，我们将以测试分析 Agent 与测试执行 Agent 的协同，构建下一代智能化测试体系。
内容大纲：
一、现状 & 挑战
端到端测试为什么难：跨域 × 长链路 × 组合爆炸——三大特点叠加，手工造数天级耗时，自动化覆盖率长期停滞不前
工程化方案的理想与现实：原子封装 + 流程编排，解决了重复执行问题，却引入更高的维护成本；根本矛盾——预制编排是静态的，业务组合是动态的
二、技术方案
AI 时代的破局思路：让 Agent 直接理解意图、自主调用——流程编排是面向人的思路
测试执行 Agent 两大核心能力：动态规划（逆向链式推导）× 自适应执行（Debug-first + 脚本复用）
整体架构：Coding Agent + 知识库 / 脚本管理 / 工具列表 / 工具执行 四大工具能力
Agent 思考模式：Plan-and-Execute（保证方向）× ReAct（保证韧性）
三、关键技术实现
看懂业务：
逆向链式推导——从最终交付物反向推导依赖链，动态生成 TODO List
知识库设计：子域目录树结构 + knowledge.md（业务规则）+ tool_list（接口列表）
渐进式加载：RAG → 全量 → 渐进三阶段演进，按依赖关系逐步加载子域知识库
脚本生成：
Debug-first 先调试后编写，基于调试记录一次性生成可执行脚本
经验沉淀：工具级（Debug 经验写回 toolPrompt）× 链路级（成功链路入库 RAG 召回）
流量回放自验证：用真实 I/O 做 Mock，全自动验证脚本正确性
实践总结
认知一：提示词质量 = 业务本质的深度沉淀（Prompt 是业务题，不是语文题）
认知二：记忆能力 = Agent 泛化与稳定性的核心变量（知识库 + 经验库双层记忆）
四、总结 & 展望
数据构造：跨域造数小时级 → 分钟级 → 秒级
用例生成：22 种审核处置场景，端到端自动化用例全覆盖
展望：TestAgent 完整形态——测试分析 Agent × 测试执行 Agent 协同，构建下一代智能化测试体系
听众收益：
一套可落地的端到端 AI 测试工程方案
了解如何基于 Coding Agent 构建测试执行 Agent——从逆向链式推导自动规划测试流程，到"先调试、后编写"生成可执行脚本，再到流量回放全自动自验证，完整还原一套 0 人工介入的端到端用例生成链路。
跨域复杂测试场景下的关键工程决策
结合真实案例拆解三个核心工程问题的解法：子域知识库的组织方式与渐进式加载策略；Debug-first 脚本生成范式与经验沉淀机制（工具级 + 链路级双层 RAG）；以及 Plan-and-Execute × ReAct 混合思考模式在长链路测试场景下的应用。
两条对所有 AI Agent 工程实践有普适价值的认知
提示词质量 = 对业务本质的深度思考，不是语文题而是业务题；记忆能力（静态知识库 + 动态经验库）是决定 Agent 泛化能力与稳定性的核心变量。这两点不局限于测试领域，对构建任何垂直场景的 Agent 均有参考价值。
张雨
小红书 AI工程架构师
小红书 AI工程架构师，目前主要负责小红书性能体验质量领域建设，聚焦端侧性能度量、体验优化与质量保障体系构建，致力于通过工程化与智能化手段持续提升小红书 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. 理解众测在性能保障体系中的定位和价值：了解如何将众测从"独立的问题收集渠道"整合为性能保障闭环的有机组成部分，实现真实用户反馈对自动化测试用例库和风险知识库的持续反哺。
关注QECon公众号
关注QECon视频号
议题投稿
speaker@qecon.com.cn
票务联系
18649077637 Lily
媒体合作
135-1619-6409 皮皮
商务合作
151-2264-3988 木子
购票咨询
18649077637 Lily
