宣辛欣
美团 技术专家
2016年加入美团，负责过多个业务系统的质量保障工作，从0到1建设了全新的代码覆盖率系统，持续关注研究和实践测试领域的智能化技术。
待定
待定
AI驱动的缺陷检测智能体能力构建
代码缺陷会严重影响我们产品的交付质量，因此需要尽可能的在交付给用户之前拦截发现这些问题，目前发现这种问题是通过测试设计和执行发现（需要较高的时间成本），另外可以通过传统的缺陷扫描工具（sonar）来发现，AI时代下，大模型对代码的逻辑理解能力有显著优势，因此可以利用大模型在项目早期的阶段对变更代码进行缺陷检测，这会大幅降低我们的缺陷发现成本，在测试执行之前就可以前置发现规避问题，但是也会有相应的挑战，如何设计整个检测的流程和策略，如何获取用户的反馈，检测的准确性相关的问题如何治理，以及在上下文上如何做功提升检测的准确和召回等。
内容大纲
技术上要搞定的问题：
1. 缺陷检测工作流的设计思路，通过整体的设计和调优提升准确率
2. 代码上下文的获取，裁剪和组装
3. 代码特征的分类，使用不同的检测策略，提示词的改写
4. 代码运行时的信息加入到检测上下文
5. 通过建设知识库进一步提升复杂规则的检测能力
6. 通过缺陷数据建设和评测建设不断推进系统能力提升
内容大纲
技术上要搞定的问题：
1. 缺陷检测工作流的设计思路，通过整体的设计和调优提升准确率
2. 代码上下文的获取，裁剪和组装
3. 代码特征的分类，使用不同的检测策略，提示词的改写
4. 代码运行时的信息加入到检测上下文
5. 通过建设知识库进一步提升复杂规则的检测能力
6. 通过缺陷数据建设和评测建设不断推进系统能力提升
1. 缺陷检测的背景
1.1 为什么做这个事情
1.2 sonar和LLM
1.3 缺陷检测产品的形态
2. 缺陷检测智能体
2.1 缺陷检测智能体的整体框架
2.2 规划能力-意图感知，任务分析，任务拆解
2.3 记忆能力
2.4 反思能力-验证和总结
2.5 缺陷检测的上下文
2.6 知识库建设
3. 缺陷数据与评测
3.1 缺陷数据库的建设
3.2 缺陷数据的分析定位，类别打标
3.3 缺陷数据的标注
3.4 评测能力搭建
3.5 缺陷检测在实际业务中的效果，采纳率
4. 总结和展望
听众收益
1. 了解缺陷检测产品建设的整体思路和背后的思考
2. 缺陷检测智能体的工作流设计
3. 具体的实施过程中的技术问题，缺陷检测的效果评测方法
龚李迪
bilibili 资深测试开发工程师
哔哩哔哩 质量保障中心 资深测试开发工程师，目前主要负责C端流量业务，推进业务稳定迭代、持续交付、质量提效等质量保障体系的建设。5年互联网从业经验，有丰富的业务质量保障、稳定性治理、自动化测试工具开发经历。
待定
待定
AI驱动的测试用例生成平台建设实践
行业中软件迭代的周期在不断缩短，需求业务的功能性、多样性、历史背景等内容越发复杂，在覆盖更多业务维度功能和对测试高质高效要求之间的矛盾也越发显著。
如今业界AI大模型的技术逐渐走向成熟、准确率不断提高，其在语言理解、逻辑推理、多模态处理等方面的能力已得到广泛应用，使用门槛也不断降低。因此将AI能力引入测试流程，赋能测试工作的智能化与自动化，已是势在必行。
内容大纲
1. 项目背景
1.1 传统编写测试用例问题和痛点
1.2 AI技术的发展趋势和软件测试的应用场景
2. 自动化测试用例生成平台
2.1 平台的整体架构设计、设计思路、测试用例自动化生成流程
2.2 工程中的Multi-Agent协作协同工作机制，prompt与知识库协同规范与收益
2.3 RAG知识库建设中的AI驱动多路混合检索策略与收益
2.4 工程优化中多任务并发、多模型协同、缓存复用带来的效率提升
2.5 工程在多模态融合、UI自动化代码智能生成等未来技术升级路径上的探索
3. 实践效果
3.1 工程实践与运维保障：报告产出、监控告警、用例管理等工程化实践
3.2 落地收益量化分析：用例生成效果、工程效率等关键指标对比
4. 总结与展望
4.1 总结项目整体实践与未来展望
听众收益
了解AI赋能测试用例生成的完整生产过程，以及在落地过程中遇到的成本、效率、技术难点等问题，通过分享可以在原有的工程能力中进行优化迭代，实现端到端的自动化生产流程，提升整体的工程效率。
如今业界AI大模型的技术逐渐走向成熟、准确率不断提高，其在语言理解、逻辑推理、多模态处理等方面的能力已得到广泛应用，使用门槛也不断降低。因此将AI能力引入测试流程，赋能测试工作的智能化与自动化，已是势在必行。
内容大纲
1. 项目背景
1.1 传统编写测试用例问题和痛点
1.2 AI技术的发展趋势和软件测试的应用场景
2. 自动化测试用例生成平台
2.1 平台的整体架构设计、设计思路、测试用例自动化生成流程
2.2 工程中的Multi-Agent协作协同工作机制，prompt与知识库协同规范与收益
2.3 RAG知识库建设中的AI驱动多路混合检索策略与收益
2.4 工程优化中多任务并发、多模型协同、缓存复用带来的效率提升
2.5 工程在多模态融合、UI自动化代码智能生成等未来技术升级路径上的探索
3. 实践效果
3.1 工程实践与运维保障：报告产出、监控告警、用例管理等工程化实践
3.2 落地收益量化分析：用例生成效果、工程效率等关键指标对比
4. 总结与展望
4.1 总结项目整体实践与未来展望
听众收益
了解AI赋能测试用例生成的完整生产过程，以及在落地过程中遇到的成本、效率、技术难点等问题，通过分享可以在原有的工程能力中进行优化迭代，实现端到端的自动化生产流程，提升整体的工程效率。
郑天
字节跳动 资深测试开发架构师
字节跳动 用户增长团队资深测试开发架构师。目前负责智能测试技术探索、测试效能的提升、工具的设计与落地。主导探索实践了包括测试用例生成、接口自动化用例生成、智能保障分级、需求风险智能识别等大模型测试应用，成功孵化多个测试服务落地，获得AI测试相关专利5篇。曾分别负责过客户端业务、服务端业务的质量保障工作。
待定
待定
动态知识驱动LLM的具身智能测试分析提效工程与实践
1. 在智能化测试领域，对业务和需求的理解，是智能化测试的难点
2. 传统静态知识库难以应对需求高频变更
本议题提出动态知识驱动的具身智能测试框架，通过实时演进的业务知识库，赋予 LLM 环境感知能力，实现需求分析、风险分级、测试策略的闭环优化，再通过模型训练，精细化分配测试人力，助力业务仅通过风险分析，提升测试效能30%，为全智能化测试打下夯实基础。
内容大纲
1. 智能测试提效应用的现状与背景
1.1 当前业内AI测试应用的现状，各类测试应用投入的收益情况分析
1.2 我们在测试应用上的探索和成果
2. 动态知识驱动LLM的具身智能测试分析提效方案
2.1 动态知识库构建
2.2 需求测试分析Agent架构与实现
2.3 需求精细化智能测试架构
3. 效果、收益、推进落地
3.1 模型训练评估与评测
3.2 应用落地收益
4. 展望
4.1 人机协作重构与全智闭环自主决策质量保障
2. 传统静态知识库难以应对需求高频变更
本议题提出动态知识驱动的具身智能测试框架，通过实时演进的业务知识库，赋予 LLM 环境感知能力，实现需求分析、风险分级、测试策略的闭环优化，再通过模型训练，精细化分配测试人力，助力业务仅通过风险分析，提升测试效能30%，为全智能化测试打下夯实基础。
内容大纲
1. 智能测试提效应用的现状与背景
1.1 当前业内AI测试应用的现状，各类测试应用投入的收益情况分析
1.2 我们在测试应用上的探索和成果
2. 动态知识驱动LLM的具身智能测试分析提效方案
2.1 动态知识库构建
2.2 需求测试分析Agent架构与实现
2.3 需求精细化智能测试架构
3. 效果、收益、推进落地
3.1 模型训练评估与评测
3.2 应用落地收益
4. 展望
4.1 人机协作重构与全智闭环自主决策质量保障
听众收益
1. 直接复用的框架：动态知识库构建方法、功能点分级保障评估模型训练方法
2. 效能提升路径：测试效率分析方法与收益空间预估思路
1. 直接复用的框架：动态知识库构建方法、功能点分级保障评估模型训练方法
2. 效能提升路径：测试效率分析方法与收益空间预估思路
郑林
百度 资深测试工程师
百度资深测试工程师，拥有10余年测试与测试工具研发经验，现负责API测试智能体和数字员工的设计与实现。长期深耕质量工程领域，曾在QECon、MTSC等行业会议中分享测试技术与实践经验。
待定
待定
API测试智能体：从自动化到智能化的跃迁
随着微服务与云原生架构普及，API成为系统交互核心载体，高频测试需求与复杂维护矛盾凸显。
传统测试模式面临三大矛盾：
1. 高频调用与低效工具冲突（如Postman难以处理多API顺序调用与异步场景）
2. 敏捷迭代与脆弱测试矛盾（人工修复耗时源于字段/路径变更引发的用例失效）
3. 分布式依赖与环境耦合困境（跨服务测试数据隔离困难）
1. 高频调用与低效工具冲突（如Postman难以处理多API顺序调用与异步场景）
2. 敏捷迭代与脆弱测试矛盾（人工修复耗时源于字段/路径变更引发的用例失效）
3. 分布式依赖与环境耦合困境（跨服务测试数据隔离困难）
核心痛点表现为：
1. 多API交互脚本复杂：参数传递、冗余断言及异常分支
2. 高频变更维护失控：非功能变更触发（如字段更名）导致的测试失败频发，灰度发布存在版本路由覆盖缺口，文档用例脱节导致误报率增长
因此传统工具效率滞后于复杂场景需求，亟需智能化升级
内容大纲
1. 智能体核心功能架构
1.1 智能用例生成引擎
1.1.1 基于自然语言的动态场景生成
1.1.2 参数依赖智能推导
1.1.3 自适应断言生成
1.2 执行与自修复引擎
1.2.1 变更感知与用例动态适配
1.2.2 灰度环境智能路由
1.2.3 跨环境一致性保障
1.3 报告与Bug生成中心
1.3.1 多维度测试报告
1.3.2 缺陷自动化诊断
2. 交互层：低代码与自然语言融合
2.1 自然语言驱动测试设计
2.2 可视化编排界面
2.3 协作与知识沉淀
3. RAG智能增强体系
3.1 知识库构建与动态更新
3.1.1 API文档向量化存储
3.1.2 历史缺陷库与解决方案知识图谱
3.2 上下文感知的智能检索
3.2.1 故障模式匹配
3.2.2 测试策略推荐
3.3 自进化学习机制
3.3.1 执行反馈强化模型
3.3.2 领域知识主动补全
4. 落地效果和展望
4.1 落地效果
4.2 展望
听众收益
通过自然语言交互、智能交互与rag构建三大核心技术，给听众提供多重价值：
1. 测试效率革新：测试设计从小时级压缩至分钟级，系统自动适配接口变更，大幅降低维护成本
2. 测试质量提升：全链路回归和智能定位故障，提前发现测试和灰度发布兼容风险
3. 测试门槛降低：通过知识库沉淀使新人培养周期大幅缩短
4. 可复用的流程和协同升级：自动化知识构建，消除不同部门的知识差异
陆钱春
中兴通讯 有线大模型总工程师
知识工程首席专家
中兴通讯大模型总工程师、知识工程首席专家。主导端到端知识体系规范制定、模型设计与工程落地，从技术顶层设计推动有线经营部以大模型为核心的组织转型。
待定
待定
大模型时代：构建端到端知识工程体系，驱动AI智能体高效落地
破解AI智能体落地瓶颈——如何打造「可复用、可推理、可进化」的企业级知识底座？
1. 知识图谱为核：构建连续化、层次化知识体系，实现知识显性学习→结构化生产→标准化复用的闭环
2. 打通知识断点：建立端到端知识模型与规范，夯实AI应用智能体核心支撑
3. 场景化赋能：将离散研发知识转化为可组装、可操作的AI能力，保障安全提智与质量提效双落地
1. 知识图谱为核：构建连续化、层次化知识体系，实现知识显性学习→结构化生产→标准化复用的闭环
2. 打通知识断点：建立端到端知识模型与规范，夯实AI应用智能体核心支撑
3. 场景化赋能：将离散研发知识转化为可组装、可操作的AI能力，保障安全提智与质量提效双落地
内容大纲
1. 知识工程建设目标与原则
企业级知识体系的核心价值锚点
2. 知识工程方法论全景图
从知识建模到工程落地的关键路径
3. 研发提效新范式：AI智能体实战
知识驱动型智能体构建与场景验证
4. 规模化成效验证
效率提升与质量保障的量化实践
听众收益
1. 构建知识驱动型组织，赢战软件工程3.0时代！
2. 管理者：掌握组织级知识工程落地框架，驱动大模型研发提效的规范化转型
3. AI架构师/知识工程设计师： 获取大模型适配的知识建模规范与体系设计方法论
4. 项目实施者： 习得知识建模、规范落地到体系建设的全流程实践技能
5. AI应用者 ： 提升面向大模型的知识生产与消费能力，实现个人与组织协同提效
何汉东
中兴通讯 网元故障运维技术专家
和知识图谱专家
中兴通讯网元故障运维技术专家和知识图谱专家。致力于引领先进数据治理和知识工程理论在复杂网元故障运维领域的创新应用。主导构建了显性化建模、结构化生产、智能化推理、标准化复用、正反馈进化的端到端知识体系，并高效整合海量运维数据，有力推动了AI在故障诊断等场景的实战部署，为有线数据产品打造智能、可靠的运维新范式。
待定
待定
AI双轮驱动｜数据与知识赋能网元故障智能运维
在高速发展的网络运维领域，传统模式在应对海量数据与复杂故障时已显效率瓶颈。本次分享将深入聚焦AI如何统御数据与知识，驱动网元故障的智能化运维变革。将系统性阐述如何高效“激活”知识工程效能，贯通数据与知识的固有壁垒，进而构建协同共振的智能体系，以期显著提升故障处理效率，最终实现从被动响应向预见性主动运维的战略跃迁。
内容大纲
1. 智能化转型：网元故障运维的困境与破局
1.1 剖析传统运维模式在应对海量数据与复杂故障时的核心痛点与挑战
2. 双引擎筑基：构建可信赖的数据与知识体系
2.1 数据治理： 运维数据的全生命周期管理，打破数据烟囱化，定义数据治理标准
2.2 知识工程： 打造端到端知识体系，实现显性化建模、结构化生产与标准化复用
3. AI赋能：驱动数据与知识协同的智能应用实践
3.1 智能化推理： 融合多源异构数据与私域知识，实现高效故障诊断、根因分析与智能辅助决策
3.2 边缘侧部署：推动AI能力向边缘网元下沉，迈向故障的就近感知、自主推理与实时自愈
听众收益
1. 运维管理者： 掌握知识工程优化运维流程的方法，加速 AI 与知识图谱在故障场景落地，提升团队运维效能
2. 技术专家/工程师： 学会构建故障运维知识图谱及知识消费机制，将碎片化经验转化为系统化 AI 能力
3. AI开发者/应用者： 理解运维场景需求，掌握知识驱动型 AI 智能体设计，提升故障处理准确性与效率
1. 运维管理者： 掌握知识工程优化运维流程的方法，加速 AI 与知识图谱在故障场景落地，提升团队运维效能
2. 技术专家/工程师： 学会构建故障运维知识图谱及知识消费机制，将碎片化经验转化为系统化 AI 能力
3. AI开发者/应用者： 理解运维场景需求，掌握知识驱动型 AI 智能体设计，提升故障处理准确性与效率
甘磊磊
浙江大学计算机科学与技术学院
软件学院研究员，工学博士
长期从事自然语言处理、大模型及其赋能学科交叉等方向的研究，相关研究成果发表在ACL、AAAI、EMNLP、NAACL、COLING和TMLR等人工智能领域高水平会议和期刊上，获2024年度中国人工智能学会吴文俊人工智能科学技术奖科技进步一等奖，受邀担任ACL、EMNLP领域主席，TKDE、TDSC、TIFS、TASLP等计算机领域高水平期刊审稿人，以及ACL、AAAI、COLM、EMNLP、IJCAI等计算机领域高水平会议程序委员会委员，承担或参与了国家重点研发计划、国家自然科学基金项目、浙江省“尖兵领雁+X”计划项目、华为MindSpore学术奖励基金、阿里巴巴研究创新计划、华为财经、蚂蚁金服、网商银行等多个国家及企业课题。
待定
待定
数据与知识双轮驱动的行业大模型研究与应用
破解大模型研发与垂直领域应用落地瓶颈——如何实现“数据驱动任务精度提升、知识驱动推理可信增强”的双轮协同？
1. 数据为基，优化大模型行业任务理解：构建高质量的行业数据体系，通过通专协同标注与数据增强，强化大模型对领域专用任务的语义理解，为下游应用奠定坚实基础。
2. 知识为核，增强大模型可信推理能力：通过知识图谱、领域符号知识，将显性知识注入大模型，实现从“统计拟合”到“知识推理”的能力跃迁。
3. 双轮融合，驱动行业大模型高效落地：探索数据与知识的深度耦合，支撑问答、决策、推荐等多场景AI应用，保障安全可控、可解释的智能服务。
内容大纲
1. 数据与知识双轮驱动的战略价值
2. 以数据为中心的行业大模型后训练
3. 领域知识增强的大模型可信推理
4. 双轮融合的行业大模型研发与实战
5. 典型示范应用成效验证
听众收益
构建数据与知识协同的行业大模型构建能力，助力大模型从“通”走向“专”！
1. 管理者：掌握数据与知识协同驱动大模型落地的方法论，推动研发体系的规范化与智能化转型
2. AI架构师/知识工程师：获取数据治理、知识建模与双轮融合的系统设计框架
3. 项目实施者：掌握从数据准备、知识注入到双轮融合应用的全流程实战经验
4. AI应用者：提升面向大模型的高质量数据生产与知识消费能力，实现业务创新与智能提效
1. 数据为基，优化大模型行业任务理解：构建高质量的行业数据体系，通过通专协同标注与数据增强，强化大模型对领域专用任务的语义理解，为下游应用奠定坚实基础。
2. 知识为核，增强大模型可信推理能力：通过知识图谱、领域符号知识，将显性知识注入大模型，实现从“统计拟合”到“知识推理”的能力跃迁。
3. 双轮融合，驱动行业大模型高效落地：探索数据与知识的深度耦合，支撑问答、决策、推荐等多场景AI应用，保障安全可控、可解释的智能服务。
内容大纲
1. 数据与知识双轮驱动的战略价值
2. 以数据为中心的行业大模型后训练
3. 领域知识增强的大模型可信推理
4. 双轮融合的行业大模型研发与实战
5. 典型示范应用成效验证
听众收益
构建数据与知识协同的行业大模型构建能力，助力大模型从“通”走向“专”！
1. 管理者：掌握数据与知识协同驱动大模型落地的方法论，推动研发体系的规范化与智能化转型
2. AI架构师/知识工程师：获取数据治理、知识建模与双轮融合的系统设计框架
3. 项目实施者：掌握从数据准备、知识注入到双轮融合应用的全流程实战经验
4. AI应用者：提升面向大模型的高质量数据生产与知识消费能力，实现业务创新与智能提效
黄立华
华为 GTS测试专家
GTS测试专家，目前主要负责GTSLLM辅助测试设计&AI大模型测试。
待定
待定
基于数据飞轮多轮知识库AI辅助测试用例生成测试实践
1. 产品测试验证挑战：新老特性交互、验证点设计不全
2. 如何提取全面提取测试点避免遗漏？
3. 测试过程如何构建领域测试设计知识库，知识库如何用于LLM辅助测试设计
2. 如何提取全面提取测试点避免遗漏？
3. 测试过程如何构建领域测试设计知识库，知识库如何用于LLM辅助测试设计
内容大纲
1. 测试设计工作模式改变
2. 整体解决方案
3. 关键技术1：DSL切片研发文档
4. 关键技术2：数据质量提升-测试需求分析
5. 关键技术3：多轮prompt输出测试设计方法测试用例
6. 关键技术4：数据飞轮知识库构建
7. 冠军技术5：数据飞轮知识库应用于LLM辅助测试用例
听众收益
1. 解决测试过程中测试领域知识库构建
2. 多轮prompt提升测试用例生成采纳率
3. 数据飞轮知识库如何应用于LLM负责测试用例生成
王旭峰
饿了么 高级测试开发专家
饿了么测试开发专家，目前就职于饿了么技术中心质量效能团队，主要负责研发测试环节质量工具的建设以及效能优化工作，近两年主要专注于AI+领域,包括基于AI的前端自动化工具能力建设、基于AI的客诉故障预警能力建设,在利用大模型解决互联网相关领域的一些问题积累了一些经验。
待定
待定
基于大模型的客诉故障探测方案实践与思考
在互联网平台中，客户投诉不仅是服务质量的“晴雨表”，更是系统故障的重要“哨兵”。传统上用以防范故障的常规监控手段,无论从投入产出比考量，还是业务场景的复杂度考量，很难做到百分之百的覆盖，其中的一部分问题通过客诉的形式最终被发现。
因此，一旦风险被触发后，如果在客诉中及时感知，就能尽快发现问题，解决问题，减小影响范围。
随着大模型技术的快速发展，我们尝试将AI能力引入到客诉数据处理中，探索一条从用户视角自动识别潜在系统问题的新路径。
内容大纲
1. 背景介绍
2. 项目成果：低危故障显著下降
3. 解决方案：利用大模型、视觉模型、Embedding、工具调用，结合工程能力，提升问题召回准确性、排查效率
3.1 总体流程
3.2 能力建设
3.3 工程实践
4. 方案落地：落地策略—>快速迭代优化->大规模推广
5. 问题、未来展望
听众收益
1. 获得通过客诉问题保障生产业务质量的新思路：构建用户反馈-技术干预的闭环机制，替代部分人工监控盲区
2. 了解如何利用大模型技术+工程能力,构建一套可用的、有稳定预期的客诉故障预警系统
3. 启发跨领域协作、共建、落地模式
因此，一旦风险被触发后，如果在客诉中及时感知，就能尽快发现问题，解决问题，减小影响范围。
随着大模型技术的快速发展，我们尝试将AI能力引入到客诉数据处理中，探索一条从用户视角自动识别潜在系统问题的新路径。
内容大纲
1. 背景介绍
2. 项目成果：低危故障显著下降
3. 解决方案：利用大模型、视觉模型、Embedding、工具调用，结合工程能力，提升问题召回准确性、排查效率
3.1 总体流程
3.2 能力建设
3.3 工程实践
4. 方案落地：落地策略—>快速迭代优化->大规模推广
5. 问题、未来展望
听众收益
1. 获得通过客诉问题保障生产业务质量的新思路：构建用户反馈-技术干预的闭环机制，替代部分人工监控盲区
2. 了解如何利用大模型技术+工程能力,构建一套可用的、有稳定预期的客诉故障预警系统
3. 启发跨领域协作、共建、落地模式
李远康
科大讯飞 测试部副总监
五级测试专家，拥有10年+软件测试领域深耕经验，历任测试负责人、测试总监、高级测试工程师，主导教育类、团队管理类等核心系统的质量保障及效能提升项目，为系统稳定迭代提供关键支撑。
深耕测试工具研发与自动化体系搭建，主导开发系统用例管理平台、系统监控平台，实现测试流程数字化与质量风险实时预警；精通端自动化框架实战应用，在元素定位策略、动态页面适配、用例自愈机制等领域有深入研究。
尤其擅长大模型测试工具落地中的 “可控性与稳定性平衡”，曾推动测试团队从 “脚本编写” 向 “用例设计” 转型，显著提升团队质量保障效率与核心竞争力。
深耕测试工具研发与自动化体系搭建，主导开发系统用例管理平台、系统监控平台，实现测试流程数字化与质量风险实时预警；精通端自动化框架实战应用，在元素定位策略、动态页面适配、用例自愈机制等领域有深入研究。
尤其擅长大模型测试工具落地中的 “可控性与稳定性平衡”，曾推动测试团队从 “脚本编写” 向 “用例设计” 转型，显著提升团队质量保障效率与核心竞争力。
待定
待定
智解用例・自生脚本・自愈执行：效率与可控的测试新解
一、行业痛点：大模型自主测试的落地难题
大模型技术在测试领域的应用虽受关注，但 “自然语言描述场景、AI 自动生成执行脚本” 的工具难以常态化落地，核心问题集中在 “不可控” 与 “不稳定”：
语义理解易偏差：大模型对测试用例中的业务术语、隐含条件易产生误判，导致测试逻辑偏离预期；
执行过程黑箱化：全链路自动化模式缺乏人工干预，页面元素变化或操作有前置依赖时，脚本易失效且难定位问题；
结果稳定性差：同一用例在不同场景下执行结果差异大，难以纳入常态化回归流程；
依赖大模型能力：核心功能过度依赖大模型多模态理解效果，复杂场景下识别准确率骤降，通用性不足；
回归测试成本高：页面微调易引发脚本失效，传统工具需人工逐一排查修复，拖累迭代进度。
二、破局思路：平衡效率与可控性，融入 “用例自愈” 能力
解决大模型自主测试落地难的关键，在于平衡效率与可控性，同时应对脚本易失效问题：
植入人工确认锚点：将流程拆分为 “用例分析→步骤生成→人工确认→脚本生成→执行验证”，仅在步骤生成环节人工干预，确保逻辑与业务预期一致；
动态循环执行：摒弃一次性生成完整脚本模式，改为 “单步生成→执行验证→保存成功脚本→循环下一步”，实时适配页面变化，提升稳定性；
工具化封装核心能力：弱化对大模型的依赖，用独立页面分析引擎、优先级定位策略、本地调试环境保障稳定性与可控性；
沉淀成功案例：将经确认且执行成功的脚本存入用例库，供相似场景复用，减少重复成本；
加入用例自愈能力：回归测试中脚本失败时，自动判断失败类型。若为步骤执行失败，立即重新分析页面、生成新脚本并替换原失败脚本，减少人工修复频率。
三、最终目标：推动自然语言测试实用化
通过上述设计，实现三大目标：
从手动编写到自动生成脚本，提升脚本设计效能；
释放测试人员精力，聚焦用例逻辑与异常场景；
支撑常态化回归测试，降低脚本维护成本；
最终达成 “人工仅一次确认，工具自动完成后续流程且具备自愈能力” 的高效模式，让自然语言驱动的自动化测试从 “演示工具” 变为 “生产工具”。
内容大纲
1. 问题分析：大模型自主测试的落地困局与核心挑战
1.1 行业现状：从 “热捧” 到 “遇冷” 的现实落差
1.1.1 大模型在测试领域的应用热潮：自然语言生成脚本的技术愿景与行业期待
1.1.2 落地瓶颈：为何多数工具停留在 “演示阶段”，难以进入生产环境？
1.2 核心痛点拆解（结合真实场景案例）
1.2.1 语义理解偏差：业务术语误判导致测试逻辑失效（如 “最后一项”“提交后” 等隐含条件解析错误）
1.2.2 执行黑箱失控：全链路自动化缺乏干预节点，元素变化后脚本失效且排查困难
1.2.3 结果稳定性差：同一用例在不同页面状态下执行成功率波动（实测数据：某工具相同用例执行成功率
大模型技术在测试领域的应用虽受关注，但 “自然语言描述场景、AI 自动生成执行脚本” 的工具难以常态化落地，核心问题集中在 “不可控” 与 “不稳定”：
语义理解易偏差：大模型对测试用例中的业务术语、隐含条件易产生误判，导致测试逻辑偏离预期；
执行过程黑箱化：全链路自动化模式缺乏人工干预，页面元素变化或操作有前置依赖时，脚本易失效且难定位问题；
结果稳定性差：同一用例在不同场景下执行结果差异大，难以纳入常态化回归流程；
依赖大模型能力：核心功能过度依赖大模型多模态理解效果，复杂场景下识别准确率骤降，通用性不足；
回归测试成本高：页面微调易引发脚本失效，传统工具需人工逐一排查修复，拖累迭代进度。
二、破局思路：平衡效率与可控性，融入 “用例自愈” 能力
解决大模型自主测试落地难的关键，在于平衡效率与可控性，同时应对脚本易失效问题：
植入人工确认锚点：将流程拆分为 “用例分析→步骤生成→人工确认→脚本生成→执行验证”，仅在步骤生成环节人工干预，确保逻辑与业务预期一致；
动态循环执行：摒弃一次性生成完整脚本模式，改为 “单步生成→执行验证→保存成功脚本→循环下一步”，实时适配页面变化，提升稳定性；
工具化封装核心能力：弱化对大模型的依赖，用独立页面分析引擎、优先级定位策略、本地调试环境保障稳定性与可控性；
沉淀成功案例：将经确认且执行成功的脚本存入用例库，供相似场景复用，减少重复成本；
加入用例自愈能力：回归测试中脚本失败时，自动判断失败类型。若为步骤执行失败，立即重新分析页面、生成新脚本并替换原失败脚本，减少人工修复频率。
三、最终目标：推动自然语言测试实用化
通过上述设计，实现三大目标：
从手动编写到自动生成脚本，提升脚本设计效能；
释放测试人员精力，聚焦用例逻辑与异常场景；
支撑常态化回归测试，降低脚本维护成本；
最终达成 “人工仅一次确认，工具自动完成后续流程且具备自愈能力” 的高效模式，让自然语言驱动的自动化测试从 “演示工具” 变为 “生产工具”。
内容大纲
1. 问题分析：大模型自主测试的落地困局与核心挑战
1.1 行业现状：从 “热捧” 到 “遇冷” 的现实落差
1.1.1 大模型在测试领域的应用热潮：自然语言生成脚本的技术愿景与行业期待
1.1.2 落地瓶颈：为何多数工具停留在 “演示阶段”，难以进入生产环境？
1.2 核心痛点拆解（结合真实场景案例）
1.2.1 语义理解偏差：业务术语误判导致测试逻辑失效（如 “最后一项”“提交后” 等隐含条件解析错误）
1.2.2 执行黑箱失控：全链路自动化缺乏干预节点，元素变化后脚本失效且排查困难
1.2.3 结果稳定性差：同一用例在不同页面状态下执行成功率波动（实测数据：某工具相同用例执行成功率
差异达 40%）
1.2.4 大模型依赖陷阱：复杂交互场景（如拖拽、悬浮菜单）中 MCP 识别准确率骤降（低于 50%）
1.2.5 回归测试成本高：页面微调引发批量脚本失效，人工修复占测试周期的 60% 以上
2. 技术抉择：从 “理想方案” 到 “落地可行” 的权衡
2.1 核心设计理念确立
2.1.1 拒绝 “全自动化神话”：为何必须保留 “人工确认锚点”？（从 3 次失败尝试中得出的结论）
2.1.2 “小步快跑” 优于 “一步到位”：动态循环执行的必要性论证
2.2 关键技术路径选择
2.2.1 大模型依赖 vs 工具化封装：为何放弃 “纯大模型生成”，转向独立页面分析引擎？
对比数据：大模型生成脚本在动态页面中的稳定性（65%）vs 工具化定位策略（92%）
2.2.2 定位策略优先级设计：如何平衡 “稳定性” 与 “兼容性”？
技术选型：data-testid→Role→Text→CSS→Xpath 的层级策略（基于 1000 + 页面元素的属性稳定性分析）
2.2.3 自愈能力触发机制：为何仅针对 “步骤失败” 而非 “断言失败”？（功能缺陷与脚本问题的本质区别）
3. 实践踩坑：从 “理论可行” 到 “工程落地” 的避坑指南
3.1 技术实现中的典型问题
3.1.1 页面分析引擎性能瓶颈：首次扫描耗时过长（初期版本单页面分析需 8 秒，优化后降至 1.2 秒）
3.1.2 动态元素定位冲突：同一控件多属性匹配时的优先级失效（如 “确认” 按钮同时存在文本与data-id）
3.1.3 自愈流程死循环：步骤失败后重新生成脚本仍失败，导致无限循环（解决方案：设置 3 次重试上限 +
1.2.4 大模型依赖陷阱：复杂交互场景（如拖拽、悬浮菜单）中 MCP 识别准确率骤降（低于 50%）
1.2.5 回归测试成本高：页面微调引发批量脚本失效，人工修复占测试周期的 60% 以上
2. 技术抉择：从 “理想方案” 到 “落地可行” 的权衡
2.1 核心设计理念确立
2.1.1 拒绝 “全自动化神话”：为何必须保留 “人工确认锚点”？（从 3 次失败尝试中得出的结论）
2.1.2 “小步快跑” 优于 “一步到位”：动态循环执行的必要性论证
2.2 关键技术路径选择
2.2.1 大模型依赖 vs 工具化封装：为何放弃 “纯大模型生成”，转向独立页面分析引擎？
对比数据：大模型生成脚本在动态页面中的稳定性（65%）vs 工具化定位策略（92%）
2.2.2 定位策略优先级设计：如何平衡 “稳定性” 与 “兼容性”？
技术选型：data-testid→Role→Text→CSS→Xpath 的层级策略（基于 1000 + 页面元素的属性稳定性分析）
2.2.3 自愈能力触发机制：为何仅针对 “步骤失败” 而非 “断言失败”？（功能缺陷与脚本问题的本质区别）
3. 实践踩坑：从 “理论可行” 到 “工程落地” 的避坑指南
3.1 技术实现中的典型问题
3.1.1 页面分析引擎性能瓶颈：首次扫描耗时过长（初期版本单页面分析需 8 秒，优化后降至 1.2 秒）
3.1.2 动态元素定位冲突：同一控件多属性匹配时的优先级失效（如 “确认” 按钮同时存在文本与data-id）
3.1.3 自愈流程死循环：步骤失败后重新生成脚本仍失败，导致无限循环（解决方案：设置 3 次重试上限 +
人工介入阈值）
3.2 业务适配中的挑战
3.2.1 复杂业务逻辑拆解困难：如 “多级审批流程” 等长链路用例的步骤拆分准确率低（初期不足 70%）
3.2.2 行业特殊控件兼容：富文本编辑器、日期选择器等非标准控件的操作生成失败（通过定制化控件库解决）
4. 工程实践：构建 “稳定 + 高效” 的自动化测试体系
4.1 流程设计：分阶段闭环机制
4.1.1 用例分析→步骤生成→人工确认→脚本生成→执行验证的全链路拆解
4.1.2 人工确认节点的颗粒度控制：为何仅需 “步骤级确认”，而非 “脚本级干预”？（效率与可控性的平衡）
4.2 核心模块实现细节
4.2.1 页面分析引擎：实时控件提取与结构化存储（基于 Playwright API 的二次开发）
4.2.2 自愈能力模块：失败类型智能判断（断言失败 vs 步骤失败）与自动重试逻辑
4.2.3 用例库沉淀机制：脚本 + 场景 + 环境的关联存储，支持相似场景复用（复用率提升至 65%）
4.3 与现有平台的无缝衔接
4.3.1 用例生成及管理：测试平台提供功能用例生成及管理，使用大模型从需求到用例的生成
4.3.2 执行结果与报告：测试平台提供任务编排及执行能力，并形成测试分析报告，实现从功能用例到脚本生成，
3.2 业务适配中的挑战
3.2.1 复杂业务逻辑拆解困难：如 “多级审批流程” 等长链路用例的步骤拆分准确率低（初期不足 70%）
3.2.2 行业特殊控件兼容：富文本编辑器、日期选择器等非标准控件的操作生成失败（通过定制化控件库解决）
4. 工程实践：构建 “稳定 + 高效” 的自动化测试体系
4.1 流程设计：分阶段闭环机制
4.1.1 用例分析→步骤生成→人工确认→脚本生成→执行验证的全链路拆解
4.1.2 人工确认节点的颗粒度控制：为何仅需 “步骤级确认”，而非 “脚本级干预”？（效率与可控性的平衡）
4.2 核心模块实现细节
4.2.1 页面分析引擎：实时控件提取与结构化存储（基于 Playwright API 的二次开发）
4.2.2 自愈能力模块：失败类型智能判断（断言失败 vs 步骤失败）与自动重试逻辑
4.2.3 用例库沉淀机制：脚本 + 场景 + 环境的关联存储，支持相似场景复用（复用率提升至 65%）
4.3 与现有平台的无缝衔接
4.3.1 用例生成及管理：测试平台提供功能用例生成及管理，使用大模型从需求到用例的生成
4.3.2 执行结果与报告：测试平台提供任务编排及执行能力，并形成测试分析报告，实现从功能用例到脚本生成，
再到报告输出的全流程打通
5. 收益量化：从 “技术创新” 到 “业务价值” 的转化
5.1 效能提升数据（AI听说课堂项目）
5.1.1 脚本设计效率：手动编写（30 分钟 / 用例）→自动生成（5 分钟 / 用例），耗时降低 83%
5.1.2 回归测试成本：人工修复脚本占比从 60% 降至 15%，测试周期缩短 40%
5.1.3 脚本稳定性：动态页面中执行成功率从 65%（传统工具）提升至 92%
5.2 质量保障升级
5.2.1 测试覆盖率：因脚本生成效率提升，回归用例覆盖率从 50% 提升至 85%
5.2.2 缺陷发现时效：线上问题反馈量减少 35%（早期拦截能力增强）
5.3 团队价值释放
测试人员精力分配变化：脚本编写（原 60%）→用例逻辑设计与异常分析（现 70%）
6. 总结与展望
6.1 核心经验：
6.1.1 可控性优先于 “全自动”：在效率与稳定性的博弈中，必须保留 “人工确认关键节点”，用最小化干预换取
5. 收益量化：从 “技术创新” 到 “业务价值” 的转化
5.1 效能提升数据（AI听说课堂项目）
5.1.1 脚本设计效率：手动编写（30 分钟 / 用例）→自动生成（5 分钟 / 用例），耗时降低 83%
5.1.2 回归测试成本：人工修复脚本占比从 60% 降至 15%，测试周期缩短 40%
5.1.3 脚本稳定性：动态页面中执行成功率从 65%（传统工具）提升至 92%
5.2 质量保障升级
5.2.1 测试覆盖率：因脚本生成效率提升，回归用例覆盖率从 50% 提升至 85%
5.2.2 缺陷发现时效：线上问题反馈量减少 35%（早期拦截能力增强）
5.3 团队价值释放
测试人员精力分配变化：脚本编写（原 60%）→用例逻辑设计与异常分析（现 70%）
6. 总结与展望
6.1 核心经验：
6.1.1 可控性优先于 “全自动”：在效率与稳定性的博弈中，必须保留 “人工确认关键节点”，用最小化干预换取
最大化可控（如步骤拆解环节的人工校验，使后续脚本生成准确率提升至 95%）
6.1.2 工具化能力高于 “大模型依赖”：将核心逻辑（如元素定位、失败重试）沉淀为可复用的工具模块，而非依赖
6.1.2 工具化能力高于 “大模型依赖”：将核心逻辑（如元素定位、失败重试）沉淀为可复用的工具模块，而非依赖
大模型的 “黑箱输出”，是应对复杂业务场景的关键（工具化封装后，复杂控件支持率从 58% 提升至 91%）
6.1.3 自愈设计要区分 “脚本问题” 与 “功能缺陷”：仅对 “步骤执行失败” 触发自愈，避免将功能 bug 误判为脚本
6.1.3 自愈设计要区分 “脚本问题” 与 “功能缺陷”：仅对 “步骤执行失败” 触发自愈，避免将功能 bug 误判为脚本
问题，确保测试结果的准确性（该机制使缺陷误判率控制在 3% 以内）
6.2 未来迭代方向：
6.2.1 大模型辅助优化：如何让 AI 在 “人工确认” 环节提供更精准的步骤建议？
6.2.2 跨端适配：扩展至 APP、小程序等场景的技术路径
6.3 行业启示：测试工具的 “务实主义”—— 从 “炫技” 到 “解决问题” 的回归
6.2 未来迭代方向：
6.2.1 大模型辅助优化：如何让 AI 在 “人工确认” 环节提供更精准的步骤建议？
6.2.2 跨端适配：扩展至 APP、小程序等场景的技术路径
6.3 行业启示：测试工具的 “务实主义”—— 从 “炫技” 到 “解决问题” 的回归
唐辉
百度 资深工程师
百度 工程效能部资深工程师，目前主要负责百度内的大模型产品 Comate AI IDE。在百度内先后建设过40+产品，在前端组件库、工程化、性能优化、体验优化等多个方向均有深入实践。在团队内部，长期参与提效工具研发，提升团队交付效率。
待定
待定
多模态模型驱动前端研发变革
当前前端研发面临设计稿转代码效率低、多端适配成本高、UI逻辑一致性维护难三大痛点。设计师与开发者的协作依赖人工标注与重复实现，响应式布局、主题切换等需求加剧了代码冗余。传统低代码平台灵活性不足，难以覆盖复杂业务逻辑。多模态大模型的出现，为“视觉设计稿→可运行代码”的端到端智能生成提供了新路径。
设计稿生成代码配合自然语言生成代码，使得设计转代码的应用场景更为广泛，不仅能生成，还能修改。配合大模型的其他能力，如MCP、Rules，能生成较高质量的代码。
设计稿生成代码配合自然语言生成代码，使得设计转代码的应用场景更为广泛，不仅能生成，还能修改。配合大模型的其他能力，如MCP、Rules，能生成较高质量的代码。
内容大纲
1. 前端的哪些场景适合大模型介入
2. 从设计到代码
2.1 关键技术：多模态模型的“看懂设计”能力
2.2 设计稿解析：从像素到语义（布局树生成、组件意图识别）
2.3 工具链：Figma/Sketch插件 + 自定义解析引擎
3. 自然语言+可视化到代码
3.1 精准识别出元素
3.2 配合Rules、自定义指令、MCP生成高质量的代码
4. 代码调试与问题定位
5. 落地收益
6. 后续展望
听众收益
将大模型用于原型设计、界面开发，提升研发效率。
揭光发（Jeff）
腾讯云 架构师联盟社群管理主席
腾讯 专家工程师
20年研发与团队管理经验，前腾讯云TVP，现腾讯全栈技术专家，公司级低代项目负责人，是IEEE低代码标准及大湾区企业低代码标准的主撰写人；大模型应用早期实践者与布道师，是国内顶级行业/技术峰会相关话題优秀讲师及出品人。在低代码与LLM结合场景有深度的实践，愿景是“人人能编程”。带领团队深度践行LLM对研发提效、探索Vibe coding 在专业程序员与准开发者群体的落地，个人代码全栈AI含量几近100%。
待定
待定
Agent与Flow的共生：开启研发效能新纪元
在大型语言模型（LLM）应用的浪潮中，开发者普遍陷入了一个两难的抉择。
路线一：低代码工作流（Workflow）。 它通过可视化的流程编排，提供了稳定、可控的开发体验，有效规避了LLM的幻觉问题。然而，这种模式下的应用，其工作流程是固化的，泛化能力极低，本质上只是“披着LLM外衣的传统应用”，未能发挥出AI真正的潜力。
路线二：自主智能体（Agent）。 以ReAct为代表的架构虽然强大，但在生产环境中却因其“边想边做”的模式而步履维艰。它缺乏全局规划，导致执行过程低效、成本高昂、且难以调试，像一个“盲目但强大的莽夫”，可靠性极差。
我们不禁反思：是否必须在“僵化的稳定”与“盲目的智能”之间二选一？我们的探索方向是：能否设计一种全新的架构，将工作流的“确定性”与智能体的“涌现能力”完美融合，实现1+1>2的效能跃迁？
内容大纲
1. 两种路线的“尽头”：LLM应用开发的困境
1.1 工作流（Workflow）的局限：稳定但僵化
1.2 自主智能体（Agent）的陷阱：强大但盲目
1.3 深入剖析：ReAct架构在生产环境的 “原罪”
2. 破局之道：Flow of Thought (FoT) 架构解析
2.1 核心思想：规划与执行分离 (Plan then Execute)
2.2 基石一：编译时校验与自修复机制
2.3 基石二：严格的结构化数据契约
3. 共生与跃迁：Agent与Flow的融合范式
3.1 核心魔法：实现人机转换的“语法同构”
3.2 开发与质量：AI辅助开发 & 自动化测试生成
3.3 资产与演进：动态实践固化 & 静态能力封装
4. 总结与未来：迈向自主进化的研发新范式
4.1 FoT的核心优势与实践效果
4.2 未来展望：人机协同的软件工厂
听众收益
1. 架构认知升级： 获得一套全新的、生产级的Agent架构思想（FoT），理解如何从根本上解决主流ReAct架构的诸多痛点；
2. 核心技术洞察： 深入了解“规划与执行分离”、“编译时自修复”、“结构化数据契约”等先进的架构设计原则；
3. 体系化方法论： 学习如何设计一个能让Agent与Workflow双向转化、共生演进的研发体系，将AI能力真正沉淀为组织资产；
4. 可落地场景启发： 收获覆盖AI辅助开发、自动化测试、智能运维等多个环节的六大共生场景，为自身团队的效能提升提供高价值参考。
路线一：低代码工作流（Workflow）。 它通过可视化的流程编排，提供了稳定、可控的开发体验，有效规避了LLM的幻觉问题。然而，这种模式下的应用，其工作流程是固化的，泛化能力极低，本质上只是“披着LLM外衣的传统应用”，未能发挥出AI真正的潜力。
路线二：自主智能体（Agent）。 以ReAct为代表的架构虽然强大，但在生产环境中却因其“边想边做”的模式而步履维艰。它缺乏全局规划，导致执行过程低效、成本高昂、且难以调试，像一个“盲目但强大的莽夫”，可靠性极差。
我们不禁反思：是否必须在“僵化的稳定”与“盲目的智能”之间二选一？我们的探索方向是：能否设计一种全新的架构，将工作流的“确定性”与智能体的“涌现能力”完美融合，实现1+1>2的效能跃迁？
内容大纲
1. 两种路线的“尽头”：LLM应用开发的困境
1.1 工作流（Workflow）的局限：稳定但僵化
1.2 自主智能体（Agent）的陷阱：强大但盲目
1.3 深入剖析：ReAct架构在生产环境的 “原罪”
2. 破局之道：Flow of Thought (FoT) 架构解析
2.1 核心思想：规划与执行分离 (Plan then Execute)
2.2 基石一：编译时校验与自修复机制
2.3 基石二：严格的结构化数据契约
3. 共生与跃迁：Agent与Flow的融合范式
3.1 核心魔法：实现人机转换的“语法同构”
3.2 开发与质量：AI辅助开发 & 自动化测试生成
3.3 资产与演进：动态实践固化 & 静态能力封装
4. 总结与未来：迈向自主进化的研发新范式
4.1 FoT的核心优势与实践效果
4.2 未来展望：人机协同的软件工厂
听众收益
1. 架构认知升级： 获得一套全新的、生产级的Agent架构思想（FoT），理解如何从根本上解决主流ReAct架构的诸多痛点；
2. 核心技术洞察： 深入了解“规划与执行分离”、“编译时自修复”、“结构化数据契约”等先进的架构设计原则；
3. 体系化方法论： 学习如何设计一个能让Agent与Workflow双向转化、共生演进的研发体系，将AI能力真正沉淀为组织资产；
4. 可落地场景启发： 收获覆盖AI辅助开发、自动化测试、智能运维等多个环节的六大共生场景，为自身团队的效能提升提供高价值参考。
赵兵
腾讯云 高级工程师
2019年加⼊腾讯云开发CloudBase团队，⽬前负责云开发AI Toolkit、AI开发套件等模块研发⼯作。主导开发CloudBase AI Toolkit、CloudBase Framework等开源项⽬，微
搭低代码组件和运⾏态能⼒，云开发AI开发套件等项⽬。⻓期从事⼯程提效和开源建设，专注于AI+研发效能领域的技术实践与⽅法论探索，在需求⼯程、代码⽣成、智能化开发流程等⽅⾯有丰富的实战经验。曾担任AI+研发数字峰会、KubeConf、前端早早聊等会议讲师，在技术社区分享AI IDE⼯作流实践获得⼴泛关注，累计阅读量超过20万
搭低代码组件和运⾏态能⼒，云开发AI开发套件等项⽬。⻓期从事⼯程提效和开源建设，专注于AI+研发效能领域的技术实践与⽅法论探索，在需求⼯程、代码⽣成、智能化开发流程等⽅⾯有丰富的实战经验。曾担任AI+研发数字峰会、KubeConf、前端早早聊等会议讲师，在技术社区分享AI IDE⼯作流实践获得⼴泛关注，累计阅读量超过20万
待定
待定
EARS语法驱动的Agent需求⼯程实践
- 从Vibe Coding到⼯程化AI开发的质效跃升
核⼼问题：
当前AI编程领域普遍存在"Vibe Coding"现象：开发者输⼊模糊需求，期待AI直接⽣成完美代码，结果往往是反复试错、效率低下、质量难保证。这种"拉霸式"开发模式让AI编程变成"碰运⽓"⽽⾮"可控⼯程"。
当前AI编程领域普遍存在"Vibe Coding"现象：开发者输⼊模糊需求，期待AI直接⽣成完美代码，结果往往是反复试错、效率低下、质量难保证。这种"拉霸式"开发模式让AI编程变成"碰运⽓"⽽⾮"可控⼯程"。
具体痛点：
1. 需求模糊化：⾃然语⾔描述导致AI理解偏差，⽣成代码与预期不符
2. 过程不可控：缺乏⼯程化流程，难以追溯、复现和优化
3. 质量难保证：没有明确验收标准，测试和维护成本⾼
4. 协作效率低：团队成员对需求理解不⼀致，沟通成本⼤
5. 知识难沉淀：实践经验分散，⽆法形成可复⽤的⽅法论
1. 需求模糊化：⾃然语⾔描述导致AI理解偏差，⽣成代码与预期不符
2. 过程不可控：缺乏⼯程化流程，难以追溯、复现和优化
3. 质量难保证：没有明确验收标准，测试和维护成本⾼
4. 协作效率低：团队成员对需求理解不⼀致，沟通成本⼤
5. 知识难沉淀：实践经验分散，⽆法形成可复⽤的⽅法论
解决思路：
借鉴传统软件⼯程的成功经验，将EARS（简易需求语法）与SBE（示例规格说明）⽅法论引⼊AI Agent开发，构建"需求澄清→技术设计→任务拆分→验收测试"的⼯程化闭环，让AI编程从"拉霸模式"升级为"⼯程模式"。
内容⼤纲
1. AI编程现状诊断
1.1 Vibe Coding现象剖析：从"拉霸游戏"看AI编程困境
1.2 传统软件⼯程vs现代AI开发：为什么成熟⽅法论被遗忘？
2. EARS+SBE⽅法论在Agent中的应⽤
2.1 EARS语法核⼼原理：从"⽤户想要..."到"When...the system shall..."
2.2 SBE在AI场景的适配：如何⽤示例驱动Agent理解需求
2.3 技术选型考量：为什么选择requirements.md + design.md + tasks.md架构
2.4 踩坑经验
3. ⼯程化Spec⼯作流设计与实现
3.1 核⼼架构：三⽂件协同的Agent⼯作流
3.1.1 requirements.md：EARS语法标准化需求
3.1.2 design.md：技术⽅案与架构设计
3.1.3 tasks.md：可执⾏的任务拆分
3.2 关键⼯程实践：
3.2.1 需求评审：⼈机协作的⼆次确认机制
3.2.2 迭代反馈：基于验收标准的持续优化
3.2.3 知识沉淀：可复⽤的Spec模板库
3.3 技术实现细节：如何在不同AI IDE中落地（Cursor/Claude Code/Kiro）
4. 真实案例分析与效果验证
4.1 CloudBase AI Toolkit开发实践对⽐
4.1.1 传统模式：多轮需求澄清，频繁返⼯
4.1.2 Spec模式：标准化流程，⼀次达标
4.2 ⼩程序开发场景验证
4.2.1 开发流程标准化程度显著提升
4.2.2 团队协作效率明显改善
4.2.3 代码质量和维护性⼤幅增强
4.3 度量体系设计与实施经验
4.3.1 如何建⽴适合AI开发的效能度量指标
4.3.2 定量与定性结合的评估⽅法
4.3.3 团队推⼴过程中的挑战与应对策略
5. 可落地的实践指南
5.1 最⼩可⾏⽅案：15分钟快速上⼿Spec⼯作流
5.2 团队推⼴策略：如何在组织内推动⼯程化AI开发
5.3 ⼯具链推荐：开源⽅案vs商业⼯具的选择建议
5.4 效果评估体系：如何量化AI开发⼯程化的提升效果
借鉴传统软件⼯程的成功经验，将EARS（简易需求语法）与SBE（示例规格说明）⽅法论引⼊AI Agent开发，构建"需求澄清→技术设计→任务拆分→验收测试"的⼯程化闭环，让AI编程从"拉霸模式"升级为"⼯程模式"。
内容⼤纲
1. AI编程现状诊断
1.1 Vibe Coding现象剖析：从"拉霸游戏"看AI编程困境
1.2 传统软件⼯程vs现代AI开发：为什么成熟⽅法论被遗忘？
2. EARS+SBE⽅法论在Agent中的应⽤
2.1 EARS语法核⼼原理：从"⽤户想要..."到"When...the system shall..."
2.2 SBE在AI场景的适配：如何⽤示例驱动Agent理解需求
2.3 技术选型考量：为什么选择requirements.md + design.md + tasks.md架构
2.4 踩坑经验
3. ⼯程化Spec⼯作流设计与实现
3.1 核⼼架构：三⽂件协同的Agent⼯作流
3.1.1 requirements.md：EARS语法标准化需求
3.1.2 design.md：技术⽅案与架构设计
3.1.3 tasks.md：可执⾏的任务拆分
3.2 关键⼯程实践：
3.2.1 需求评审：⼈机协作的⼆次确认机制
3.2.2 迭代反馈：基于验收标准的持续优化
3.2.3 知识沉淀：可复⽤的Spec模板库
3.3 技术实现细节：如何在不同AI IDE中落地（Cursor/Claude Code/Kiro）
4. 真实案例分析与效果验证
4.1 CloudBase AI Toolkit开发实践对⽐
4.1.1 传统模式：多轮需求澄清，频繁返⼯
4.1.2 Spec模式：标准化流程，⼀次达标
4.2 ⼩程序开发场景验证
4.2.1 开发流程标准化程度显著提升
4.2.2 团队协作效率明显改善
4.2.3 代码质量和维护性⼤幅增强
4.3 度量体系设计与实施经验
4.3.1 如何建⽴适合AI开发的效能度量指标
4.3.2 定量与定性结合的评估⽅法
4.3.3 团队推⼴过程中的挑战与应对策略
5. 可落地的实践指南
5.1 最⼩可⾏⽅案：15分钟快速上⼿Spec⼯作流
5.2 团队推⼴策略：如何在组织内推动⼯程化AI开发
5.3 ⼯具链推荐：开源⽅案vs商业⼯具的选择建议
5.4 效果评估体系：如何量化AI开发⼯程化的提升效果
听众收益
1. 获得可直接应⽤的⼯程化AI开发⽅法论
1.1 完整的EARS+SBE⼯作流模板，可直接应⽤于团队项⽬
1.2 三⽂件协同架构（requirements/design/tasks），15分钟即可上⼿
1.3 针对不同AI IDE的具体配置⽅案，降低技术⻔槛
2. 深⼊理解EARS语法在现代软件⼯程中的应⽤价值
2.1 从航空航天到AI开发的跨领域⽅法论迁移经验
2.2 结合SBE的需求⼯程最佳实践，适⽤于敏捷开发和DevOps场景
2.3 解决AI时代需求模糊化问题的具体技术⽅案
3. 建⽴可复⽤的团队协作和知识管理体系
3.1 标准化的需求评审和技术⽅案设计流程
3.2 跨⻆⾊协作的沟通语⾔（QA、开发、产品、测试）
3.3 可沉淀的项⽬经验库和最佳实践模板
4. 获得前瞻性的AI+⼯程效能发展洞察
4.1 从Vibe Coding到⼯程化AI的⾏业趋势分析
4.2 ⼤模型时代质量⼯程的核⼼挑战和解决路径
4.3 ⾯向未来的智能化研发⼯具链设计思路
1. 获得可直接应⽤的⼯程化AI开发⽅法论
1.1 完整的EARS+SBE⼯作流模板，可直接应⽤于团队项⽬
1.2 三⽂件协同架构（requirements/design/tasks），15分钟即可上⼿
1.3 针对不同AI IDE的具体配置⽅案，降低技术⻔槛
2. 深⼊理解EARS语法在现代软件⼯程中的应⽤价值
2.1 从航空航天到AI开发的跨领域⽅法论迁移经验
2.2 结合SBE的需求⼯程最佳实践，适⽤于敏捷开发和DevOps场景
2.3 解决AI时代需求模糊化问题的具体技术⽅案
3. 建⽴可复⽤的团队协作和知识管理体系
3.1 标准化的需求评审和技术⽅案设计流程
3.2 跨⻆⾊协作的沟通语⾔（QA、开发、产品、测试）
3.3 可沉淀的项⽬经验库和最佳实践模板
4. 获得前瞻性的AI+⼯程效能发展洞察
4.1 从Vibe Coding到⼯程化AI的⾏业趋势分析
4.2 ⼤模型时代质量⼯程的核⼼挑战和解决路径
4.3 ⾯向未来的智能化研发⼯具链设计思路
冯茂盛
中兴通讯 过程改进总工
中兴通讯，测试总工，主要负责产品的测试域改进和AI提效，包括测试设计、自动化开发和流水线部署，保障产品的功能、性能、安全等交付任务的有序开展。
待定
待定
基于知识工程的全栈AI智能测试体系
测试点设计遗漏导致的故障泄露多；脚本开发和脚本调试耗时，流水线失败脚本分析耗费人力多。
内容大纲
1. 测试设计
1.1 测试域SOP流程细化拆解
1.2 要素化表达的特性因子建设、基于因子组合的测试点生成方法、基于场景模型的测试用例生成
1.3 基于语法规则、测试设计规则、领域业务规则、规范性要求的测试用例自动评审
2. 脚本生成
2.1 关键字参数生成方案
2.2 脚本自动修复
2.3 脚本评审
2.4 语料自动沉淀、知识流水线自动抽取
3. 智能分析
3.1 智能分析流程
3.2 小模型训练提升准确率
3.3 置信度评估，高置信度结果直接采纳、思维链显性化，减少人工分析人力
听众收益
1. 测试域SOP流程细化拆解
2. 要素化表达、特性因子建设
3. 用例和脚本评审
4. 关键字参数替换
5. 语料置信度评估
1. 测试域SOP流程细化拆解
2. 要素化表达、特性因子建设
3. 用例和脚本评审
4. 关键字参数替换
5. 语料置信度评估
伍斌
独立AI应用咨询师
（网名和曾用笔名“吾真本”）作为独立AI应用咨询师，正在创作一系列全民化AI编程的图书。他拥有30多年的IT行业经验，在软件开发、测试、项目管理及工程实践方面打下了扎实的专业功底。在Thoughtworks公司工作的8年间，他协助多家国内大中型企业优化IT部门开发流程，提升了软件质量与开发效率。近两年，他专注于AI技术的应用探索与推广，致力于为企业和个人提供实用的AI解决方案，帮助用户有效应对实际业务挑战。
待定
待定
我没有用Vibe Coding写生产代码，而是先写好测试代码
目前国内企业的测试与开发人员在使用AI生成代码或维护已有系统的生产代码时，需要配套自动化测试进行端到端验证以确保代码质量。然而，让AI编写端到端测试代码时面临三大核心痛点：
1）难以撰写精准的提示词，让AI生成全面覆盖关键测试场景的用例及代码
2）难以确认AI生成的测试代码在"声明层面"是否覆盖了关键测试场景
3）难以验证AI生成的测试代码在"运行时"是否有效覆盖关键测试场景
本演讲提出"声明时两场一表+运行时故障注入"方法（即利用happy path和sad path两类场景结合决策表指导AI生成有效的测试代码，并通过故障注入验证测试代码的运行时有效性），为解决这些痛点提供了全新思路。这使测试与开发人员能通过自然语言与AI对话生成实用有效的测试代码，从而有效保障生产代码质量。
1）难以撰写精准的提示词，让AI生成全面覆盖关键测试场景的用例及代码
2）难以确认AI生成的测试代码在"声明层面"是否覆盖了关键测试场景
3）难以验证AI生成的测试代码在"运行时"是否有效覆盖关键测试场景
本演讲提出"声明时两场一表+运行时故障注入"方法（即利用happy path和sad path两类场景结合决策表指导AI生成有效的测试代码，并通过故障注入验证测试代码的运行时有效性），为解决这些痛点提供了全新思路。这使测试与开发人员能通过自然语言与AI对话生成实用有效的测试代码，从而有效保障生产代码质量。
内容大纲
1. 使用Vibe Coding生成端到端测试代码的现实挑战
1.1 难以撰写精准提示词，使AI生成全面覆盖关键测试场景的用例及代码
1.2 难以确认AI生成的测试代码在"声明层面"是否充分覆盖关键测试场景
1.3 难以验证AI生成的测试代码在"运行时"是否有效覆盖关键测试场景
2. "声明时两场一表+运行时故障注入"方法应对挑战
2.1 结合happy path和sad path两类场景与决策表，指导AI生成有效测试用例与代码
2.2 AI辅助审核AI生成的测试用例的完备性以及测试代码声明的准确性
2.3 通过故障注入验证测试代码的运行时有效性
3. 实战：利用Vibe Coding生成并验证Saleor Commerce开源电商系统的端到端测试
3.1 实战案例背景与测试需求分析
3.1.1 Saleor Commerce系统介绍：GitHub 2.2万星标的API优先电商平台，基于GraphQL API的现代化架构
3.1.2 复杂业务规则挑战：促销系统包含catalogue promotions（目录促销）和order promotions（订单促销），
支持复杂的嵌套条件组合
3.1.3 测试覆盖难点：传统人工测试分析难以覆盖多维度业务规则组合，容易产生测试盲点
3.1.3 测试覆盖难点：传统人工测试分析难以覆盖多维度业务规则组合，容易产生测试盲点
3.2 基于实战案例，应用happy path和sad path场景结合决策表指导AI生成测试用例与代码
3.2.1 Happy Path场景设计：GraphQL API完整购买流程
用户认证API → 商品查询API → 购物车操作API → 促销规则应用 → 订单创建API → 支付完成验证
3.2.2 Sad Path场景设计：GraphQL异常处理验证
语法错误查询 → 字段不存在错误 → 权限不足异常 → 业务规则冲突 → 数据验证失败处理
3.2.3 决策表技术应用演示：促销规则组合测试
展示促销规则决策表矩阵
用户认证API → 商品查询API → 购物车操作API → 促销规则应用 → 订单创建API → 支付完成验证
3.2.2 Sad Path场景设计：GraphQL异常处理验证
语法错误查询 → 字段不存在错误 → 权限不足异常 → 业务规则冲突 → 数据验证失败处理
3.2.3 决策表技术应用演示：促销规则组合测试
展示促销规则决策表矩阵
3.3 针对实战案例，用AI辅助审核AI生成的测试用例的完备性以及测试代码声明的准确性
3.4 针对实战案例，用AI辅助通过故障注入验证测试代码的运行时有效性
3.4 针对实战案例，用AI辅助通过故障注入验证测试代码的运行时有效性
3.4.1 核心理念：Test the Tests（测试测试本身）
3.4.2 通过在Saleor业务代码中主动引入错误，验证AI生成的测试代码是否能准确捕获这些错误，从而证明测试的
3.4.2 通过在Saleor业务代码中主动引入错误，验证AI生成的测试代码是否能准确捕获这些错误，从而证明测试的
运行时有效性。
4. 总结
从AI生成端到端测试代码的三大痛点出发：提示词撰写难、声明覆盖难确认、运行时有效性难验证。通过以Saleor Commerce开源电商系统为例的"声明时两场一表+运行时故障注入"方法实战演示，展示Happy Path + Sad Path + 决策表的组合能够覆盖软件功能测试80-90%的关键场景，为这些长期困扰测试与开发人员的问题提供了系统性解决方案。特别是在GraphQL API和复杂业务规则系统中，决策表技术显著提升了AI生成测试的精准性和完整性。
从AI生成端到端测试代码的三大痛点出发：提示词撰写难、声明覆盖难确认、运行时有效性难验证。通过以Saleor Commerce开源电商系统为例的"声明时两场一表+运行时故障注入"方法实战演示，展示Happy Path + Sad Path + 决策表的组合能够覆盖软件功能测试80-90%的关键场景，为这些长期困扰测试与开发人员的问题提供了系统性解决方案。特别是在GraphQL API和复杂业务规则系统中，决策表技术显著提升了AI生成测试的精准性和完整性。
听众收益
1. 掌握系统化AI测试方法：获得"声明时两场一表+运行时故障注入"的完整方法论，学会用决策表技术系统化分解复杂业务规则，可立即在GraphQL API项目和传统REST API项目中应用。
2. 提升AI协作效率：学会构建基于决策表的精准提示词，将AI测试生成的功能覆盖率从传统手工的40-50%提升到80-90%，减少与AI多轮对话的时间成本，显著提高一次性生成有效测试代码的成功率。
3. 建立质量保障体系：掌握从声明时覆盖性检查到运行时有效性验证的双重保障机制，学会识别和避免"测试覆盖率虚高"的风险，建立可信赖的自动化测试体系，特别适用于微服务架构、API优先电商和现代化API系统。
范雨欣
蚂蚁集团 算法工程师
蚂蚁集团行业技术团队算法工程师，负责行业智能体评测工作。主要研究方向为合成数据与数据质量，致力于为智能体构造全流程提供海量多样化高质量数据支撑。
待定
待定
面向行业智能体评测的高质量数据合成技术
数据资源是推动智能体（Agent）性能持续优化的核心驱动力。然而，当前在Agent项目落地与应用过程中，普遍面临高质量训练数据与评测数据短缺的挑战。尤其是在现实世界知识高质量数据获取受限的背景下，难以满足大规模Agent系统对数据多样性与丰富性的需求。针对此问题，合成数据技术已成为提升智能体能力和促进系统迭代的重要手段。通过系统性生成大规模、高质量的合成数据，可以有效支持Agent的训练与评估流程，为模型能力提升提供坚实的数据基础。
在此背景下，我们聚焦于多个关键技术方向：包括面向Agent个性化需求的数据合成流程设计，具备高吞吐能力的自动化数据合成框架构建，以及高质量数据生成与低质量数据自动筛除等技术。围绕上述方向，旨在解决合成数据过程中普遍存在的复杂数据场景覆盖不足、生成效率瓶颈和数据质量难以保障等核心问题，从而助力Agent系统在实际应用中的性能突破与创新发展。
内容大纲
1. 行业智能体评测流程及痛点分析
2. 合成数据技术介绍
3. 个性化数据合成框架
4. 高质量数据生成与管控
听众收益
1. 智能体评测全流程
2. 合成数据技术
3. 高效合成数据框架
4. 高质量数据分析理论
梁慧
阿里巴巴 测试开发专家
目前主要负责AliExpress泛导购及大促质量保障工作，专注于保障招选搭投核心业务场景的高可用性与稳定性。在面向电商大促的质量保障方面，有丰富的实战经验，建设多场景巡检、AI用例规划执行及断言能力实现一周内完成3万个大促场景的验证。同时，在自动化测试及工具平台建设方面有较深入的实践，致力于通过高效的工具链提升测试效率和质量保障能力。此外，还具备资金安全和性能压测领域的丰富经验，能够从系统到业务层面全面保障平台的可靠性与稳定性。
待定
待定
电商多场景AI巡检
对AliExpress导购巡检平台建设进行分享，分享在业务场景多、动态变化的场域通过巡检实现图片内容检测、日志和数据检测的自动化测试过程。
从导购域当前背景与挑战出发，思考问题的解决思路，介绍具体的实现方案，包含利用AI大模型诊断图片问题、通过日志和数据白盒化诊断问题，最后将巡检平台成功落地。基于当前AI大模型发展迅速，视觉模型准确度明显提升，分享巡检平台结合AI大模型进行后续扩展的方向。
内容大纲
1. 前言
2. 背景与挑战
2.1 业务背景
2.2 质量挑战
3. 解决思路
4. 实现方案
4.1 技术架构
4.2 核心流程
4.3 问题分析
4.4 检测能力建设
4.4.1 静态图片AI检测类
4.4.2 动态交互AI检测类
4.4.3 日志检测类
4.4.4 数据检测类
5. 落地效果
5.1 平台效果
5.2 成果数据
6. 结合AI后续扩展
6.1 扩展方向
6.2 实现思路
6.2.1 AI规划执行
6.2.2 AI用例断言
6.2.3 实现效果
听众收益
巡检自动化、AI用例执行建设可借鉴
从导购域当前背景与挑战出发，思考问题的解决思路，介绍具体的实现方案，包含利用AI大模型诊断图片问题、通过日志和数据白盒化诊断问题，最后将巡检平台成功落地。基于当前AI大模型发展迅速，视觉模型准确度明显提升，分享巡检平台结合AI大模型进行后续扩展的方向。
内容大纲
1. 前言
2. 背景与挑战
2.1 业务背景
2.2 质量挑战
3. 解决思路
4. 实现方案
4.1 技术架构
4.2 核心流程
4.3 问题分析
4.4 检测能力建设
4.4.1 静态图片AI检测类
4.4.2 动态交互AI检测类
4.4.3 日志检测类
4.4.4 数据检测类
5. 落地效果
5.1 平台效果
5.2 成果数据
6. 结合AI后续扩展
6.1 扩展方向
6.2 实现思路
6.2.1 AI规划执行
6.2.2 AI用例断言
6.2.3 实现效果
听众收益
巡检自动化、AI用例执行建设可借鉴
徐志刚 / 苗悦莹
bilibili
资深开发工程师 / 高级测试开发工程师
徐志刚：曾就职于网易游戏测试工具中台，负责测试工具开发。现在哔哩哔哩工程效率团队担任资深测试开发工程师，主要负责移动端测试工具建设，包括智能Monkey遍历引擎、兼容性测试框架以及AI在自动化测试中的应用探索，期望基于大模型多模态技术构建自然语言UI自动化平台，支撑B站各业务的测试效能提升。
苗悦莹：2021年加入哔哩哔哩，目前担任OGV业务的测试负责人，涵盖pgc播放、动画&影视频道页以及短剧业务等，保障业务迭代质量，达成交付的同时建立健全业务线的质量体系。有丰富的业务质量保障、稳定性治理、测试效能平台工具开发经验。
待定
待定
基于AI录制回放的自动化探索与实践
本议题聚焦： 如何利用大模型（特别是其多模态能力）构建一套新型的UI自动化测试框架，实现自然语言驱动的、跨平台的UI自动化，解决传统方案的碎片化、高成本、脆弱性问题。
1. 核心痛点：UI自动化测试的“碎片化”困境
1. 核心痛点：UI自动化测试的“碎片化”困境
1.1 平台/技术栈割裂： Android, iOS, 鸿蒙原生、Flutter, React Native, H5, 小程序... 每种平台和技术栈都需要特定的自动化框架（Appium, Airtest, UIAutomator, Puppeteer等）和适配代码，测试脚本无法复用，维护成本指数级增长。缺乏一种真正“一次编写，到处运行”的UI自动化解决方案，难以应对当前混合应用、跨平台框架和小程序生态的复杂性。
1.2 开发与维护成本高昂： 测试工程师需要精通多种框架和编程语言（Java, Python, JavaScript等），学习曲线陡峭。脚本严重依赖XPath, ID, Accessibility ID等属性定位元素，UI结构、属性值的微小变化（如资源ID动态生成、布局调整）极易导致脚本执行失败，稳定性差。UI元素频繁变更导致脚本大规模失效，需要投入大量人力进行脚本维护和调试。
1.2 开发与维护成本高昂： 测试工程师需要精通多种框架和编程语言（Java, Python, JavaScript等），学习曲线陡峭。脚本严重依赖XPath, ID, Accessibility ID等属性定位元素，UI结构、属性值的微小变化（如资源ID动态生成、布局调整）极易导致脚本执行失败，稳定性差。UI元素频繁变更导致脚本大规模失效，需要投入大量人力进行脚本维护和调试。
2. 思考方向：拥抱AI，回归“自然”
2.1 大模型多模态能力：大型语言模型（LLM）理解自然语言指令的能力，结合计算机视觉（CV）模型理解屏幕内容（文本、图像、控件）的能力，为解决上述痛点提供了全新可能。
2.2 “所想即所得”的自动化： 能否让测试人员像描述给真人测试员一样，用自然语言（如“点击登录按钮”，“在搜索框输入'手机'并搜索”，“验证购物车里有1件商品”）直接驱动自动化执行。
2.3 跨平台统一入口：基于视觉和语言理解，理论上可以屏蔽底层平台差异（Android/iOS/HarmonyOS）和前端技术栈差异（原生/Flutter/H5/小程序），提供一个统一的自动化交互界面。
2.4 降低门槛，提升效率：让不懂编程的业务测试人员也能快速创建和执行自动化用例，释放专业测试人员的生产力，专注于更复杂的场景设计和质量分析。
2.2 “所想即所得”的自动化： 能否让测试人员像描述给真人测试员一样，用自然语言（如“点击登录按钮”，“在搜索框输入'手机'并搜索”，“验证购物车里有1件商品”）直接驱动自动化执行。
2.3 跨平台统一入口：基于视觉和语言理解，理论上可以屏蔽底层平台差异（Android/iOS/HarmonyOS）和前端技术栈差异（原生/Flutter/H5/小程序），提供一个统一的自动化交互界面。
2.4 降低门槛，提升效率：让不懂编程的业务测试人员也能快速创建和执行自动化用例，释放专业测试人员的生产力，专注于更复杂的场景设计和质量分析。
内容大纲
1. 引言：传统UI自动化的困局与AI带来的曙光
1. 引言：传统UI自动化的困局与AI带来的曙光
1.1 快速回顾现有主流UI自动化技术及其痛点（碎片化、高成本、脆弱性、高门槛）。
引出大模型（LLM + CV）在理解和执行自然语言指令、理解屏幕内容方面的潜力。
提出核心愿景：自然语言 -> 自动化执行。
引出大模型（LLM + CV）在理解和执行自然语言指令、理解屏幕内容方面的潜力。
提出核心愿景：自然语言 -> 自动化执行。
2. 整体架构设计：构建AI驱动的自动化引擎
2.1 核心组件：
视觉感知层 (CV Module): 基于YOLOv5等目标检测模型实时识别屏幕截图中的控件（按钮、输入框、文本标签等）及其位置、类型、文本内容。生成屏幕的“结构化描述”（控件列表、位置、属性）。
自然语言理解层 (LLM Module): 接收测试人员的自然语言指令或录制的用例描述。理解指令意图（操作类型：点击、输入、滑动、验证？）和目标对象（哪个控件？）。
意图-控件匹配与坐标生成层 (Alignment & Planning): 将LLM理解的意图（操作+目标描述）与CV层识别的控件列表进行匹配。将匹配到的控件位置转换为设备屏幕上的可执行坐标（或控件引用）。
执行引擎层 (Execution Engine): 调用底层自动化框架（如ADB/SCRCPY/WDA, 或自研轻量级驱动）执行坐标点击、输入文本、滑动等操作。处理断言逻辑。
缓存与优化层 (Cache & Optimizer): 关键组件，提升效率和稳定性。
2.2 核心挑战与“踩坑”经验：
挑战1:执行效率低，token消耗大：视觉模型接口请求慢（10-20s/次），输入包括截图编码，导致token消耗比较多。解法：增加缓存机制，将执行过的步骤和图片缓存，通过图片相似度匹配历史操作步骤，命中则直接复用结果，提升执行效率，同时降低token的消耗。
挑战2：测试用例的描述影响测试用例的执行，例如在测试用例执行步骤：“点击书架”，当图片中有多个“书架”空间的时候，就有可能执行失败。解法：在描述测试步骤的时候，给出空间的大概位置，比如“点击左下角的书架按钮”，“点击第一个视频封面等”
挑战3：部分空间无法定位，一些APP特有的图标，而且没有文字说明的图片，大模型可能无法准确识别。解法：在提示词中加入这些特定信息，比如“向上向外的箭头表示分享按钮”
挑战4：由于大模型的缓存机制，导致测试用例在不同分辨率的设备上执行，返回相同的坐标，比如测试用例在A设备上执行成功之后，在B设备上执行的时候，大模型会直接返回在A设备上识别的结果，导致在B设备上执行失败。解法：将坐标识别替换成空间序号识别，在图片上标注出所有的控件，以及控件的序号，大模型在识别成功之后，直接返回控件的序号，这样就避免了由于大模型的缓存机制导致执行失败的问题。
挑战5：缓存假命中问题。当用例执行时，根据整体图片相似度（如95%）判断缓存命中。但若两张图整体相似度高，而局部关键操作区域不同（如按钮图标变化），导致使用错误的缓存坐标，操作失败。解法：在整体图片相似度判断的基础上，增加对关键区域的局部相似度校验。具体方法：根据上一次执行该步骤时的操作坐标，在缓存图片和当前图片的相同区域（以坐标为中心，扩展一定区域）分别截取子图，计算子图相似度。只有整体相似度和局部区域相似度都满足阈值，才认为缓存命中。否则，重新调用CV模型识别。
视觉感知层 (CV Module): 基于YOLOv5等目标检测模型实时识别屏幕截图中的控件（按钮、输入框、文本标签等）及其位置、类型、文本内容。生成屏幕的“结构化描述”（控件列表、位置、属性）。
自然语言理解层 (LLM Module): 接收测试人员的自然语言指令或录制的用例描述。理解指令意图（操作类型：点击、输入、滑动、验证？）和目标对象（哪个控件？）。
意图-控件匹配与坐标生成层 (Alignment & Planning): 将LLM理解的意图（操作+目标描述）与CV层识别的控件列表进行匹配。将匹配到的控件位置转换为设备屏幕上的可执行坐标（或控件引用）。
执行引擎层 (Execution Engine): 调用底层自动化框架（如ADB/SCRCPY/WDA, 或自研轻量级驱动）执行坐标点击、输入文本、滑动等操作。处理断言逻辑。
缓存与优化层 (Cache & Optimizer): 关键组件，提升效率和稳定性。
2.2 核心挑战与“踩坑”经验：
挑战1:执行效率低，token消耗大：视觉模型接口请求慢（10-20s/次），输入包括截图编码，导致token消耗比较多。解法：增加缓存机制，将执行过的步骤和图片缓存，通过图片相似度匹配历史操作步骤，命中则直接复用结果，提升执行效率，同时降低token的消耗。
挑战2：测试用例的描述影响测试用例的执行，例如在测试用例执行步骤：“点击书架”，当图片中有多个“书架”空间的时候，就有可能执行失败。解法：在描述测试步骤的时候，给出空间的大概位置，比如“点击左下角的书架按钮”，“点击第一个视频封面等”
挑战3：部分空间无法定位，一些APP特有的图标，而且没有文字说明的图片，大模型可能无法准确识别。解法：在提示词中加入这些特定信息，比如“向上向外的箭头表示分享按钮”
挑战4：由于大模型的缓存机制，导致测试用例在不同分辨率的设备上执行，返回相同的坐标，比如测试用例在A设备上执行成功之后，在B设备上执行的时候，大模型会直接返回在A设备上识别的结果，导致在B设备上执行失败。解法：将坐标识别替换成空间序号识别，在图片上标注出所有的控件，以及控件的序号，大模型在识别成功之后，直接返回控件的序号，这样就避免了由于大模型的缓存机制导致执行失败的问题。
挑战5：缓存假命中问题。当用例执行时，根据整体图片相似度（如95%）判断缓存命中。但若两张图整体相似度高，而局部关键操作区域不同（如按钮图标变化），导致使用错误的缓存坐标，操作失败。解法：在整体图片相似度判断的基础上，增加对关键区域的局部相似度校验。具体方法：根据上一次执行该步骤时的操作坐标，在缓存图片和当前图片的相同区域（以坐标为中心，扩展一定区域）分别截取子图，计算子图相似度。只有整体相似度和局部区域相似度都满足阈值，才认为缓存命中。否则，重新调用CV模型识别。
3. 应用AI录制回放的自动化实践
3.1 项目选型介绍：
埋点测试介绍：介绍埋点的定义与价值，埋点测试的核心特点，pgc播放业务核心埋点介绍，埋点测试过程介绍，埋点测试的困境
埋点自动化方案选型调研：传统UI自动化方案痛点，基于埋点自动化特点，拥抱新技术，思考采用ocr或者AI的方案进行测试，通过对比ocr和AI的特点，介绍AI录制回放的优势，
AI录制回放与埋点的结合：介绍PGC播放场景的操作特性，用户操作高度标准化，核心行为为高频基础操作，播控识别操控等。选型AI录制回放，解决元素定位脆弱性和跨端可用性问题
3.2 埋点自动化框架设计:
埋点自动化框架采用分层设计，分为测试数据层，基础服务层，用例层，数据断言层和结果层。基于AI驱动的自动化引擎，进行测试用例录制作为埋点的用例步骤，通过DOM语义理解引擎解析自然语言测试步骤，定位目标元素并模拟交互行为。
核心设计：
用例组织设计：埋点自动化用例分为数据前置准备（mock操作，预期结果准备），执行埋点操作的步骤，埋点的断言。使用了BDD模式，通过自然语言书写自动化用例，映射到steps来调用代码。Given对应是前置埋点数据准备，通过mock服务固化初始条件，不同的测试用例对应不同的mock规则，统一使用mock服务管理。When对应是埋点的测试用例步骤的实现，测试步骤为AI执行用例的步骤，可重复使用用例步骤。Then对应是埋点上报的断言实现。
用例执行设计：基于AI驱动的自动化引擎做用例录制和用例执行组件，执行埋点操作步骤。解决核心问题：
1 )元素根据实际当前界面的实际情况智能识别, 不会因为元素的微小变动导致定位失败
2) 跨端只需使用一套用例
断言模块设计：平台提供断言模块，识别元素在页面展示，例如进入页面和退出页面成功等操作，框架设计基于埋点上报特性，可自定义断言模块，增加数据校验模块。
3.3 核心挑战与“踩坑”经验：
挑战一：跨平台操作模块AI录制回放可以解决跨平台录制问题，但无法解决不同平台初始化代理的操作步骤不同，所以不同平台的驱动需要统一管理。利用跨平台模块，根据环境变量初始化，对驱动进行统一管理。调用时自动调用对应平台的底层操作，操控使用同一套测试用例，只在测试步骤进行区分。
挑战二：AI执行用例失败的重试机制基于埋点执行失败报告的截图以及日志，进行反复尝试，寻找最优解，如何描述用例使AI录制和执行成功的探索，加重试机制。通过日志和报告分析，得出失败的原因，重新优化case描述，重新执行，不断提高通过率。
3.4 实践结果展示
支持端的情况、支持场景、准确率和通过率等实践结果
埋点测试介绍：介绍埋点的定义与价值，埋点测试的核心特点，pgc播放业务核心埋点介绍，埋点测试过程介绍，埋点测试的困境
埋点自动化方案选型调研：传统UI自动化方案痛点，基于埋点自动化特点，拥抱新技术，思考采用ocr或者AI的方案进行测试，通过对比ocr和AI的特点，介绍AI录制回放的优势，
AI录制回放与埋点的结合：介绍PGC播放场景的操作特性，用户操作高度标准化，核心行为为高频基础操作，播控识别操控等。选型AI录制回放，解决元素定位脆弱性和跨端可用性问题
3.2 埋点自动化框架设计:
埋点自动化框架采用分层设计，分为测试数据层，基础服务层，用例层，数据断言层和结果层。基于AI驱动的自动化引擎，进行测试用例录制作为埋点的用例步骤，通过DOM语义理解引擎解析自然语言测试步骤，定位目标元素并模拟交互行为。
核心设计：
用例组织设计：埋点自动化用例分为数据前置准备（mock操作，预期结果准备），执行埋点操作的步骤，埋点的断言。使用了BDD模式，通过自然语言书写自动化用例，映射到steps来调用代码。Given对应是前置埋点数据准备，通过mock服务固化初始条件，不同的测试用例对应不同的mock规则，统一使用mock服务管理。When对应是埋点的测试用例步骤的实现，测试步骤为AI执行用例的步骤，可重复使用用例步骤。Then对应是埋点上报的断言实现。
用例执行设计：基于AI驱动的自动化引擎做用例录制和用例执行组件，执行埋点操作步骤。解决核心问题：
1 )元素根据实际当前界面的实际情况智能识别, 不会因为元素的微小变动导致定位失败
2) 跨端只需使用一套用例
断言模块设计：平台提供断言模块，识别元素在页面展示，例如进入页面和退出页面成功等操作，框架设计基于埋点上报特性，可自定义断言模块，增加数据校验模块。
3.3 核心挑战与“踩坑”经验：
挑战一：跨平台操作模块AI录制回放可以解决跨平台录制问题，但无法解决不同平台初始化代理的操作步骤不同，所以不同平台的驱动需要统一管理。利用跨平台模块，根据环境变量初始化，对驱动进行统一管理。调用时自动调用对应平台的底层操作，操控使用同一套测试用例，只在测试步骤进行区分。
挑战二：AI执行用例失败的重试机制基于埋点执行失败报告的截图以及日志，进行反复尝试，寻找最优解，如何描述用例使AI录制和执行成功的探索，加重试机制。通过日志和报告分析，得出失败的原因，重新优化case描述，重新执行，不断提高通过率。
3.4 实践结果展示
支持端的情况、支持场景、准确率和通过率等实践结果
4. 未来展望
4.1 技术能力提升：更精准、更稳定、更智能
更精准：识别控件更贴合业务语义：
提升通用控件识别准确率，支持多语言、多样式 UI。针对业务特有控件（如播放页定制按钮、图标型功能键等），通过建立控件知识库或训练小型专用模型，实现高精度识别与标注。融合图像、文字、布局等多模态信息，提升语义级控件识别能力。
更稳定：跨设备自动适配，减少环境依赖：
引入空间结构匹配机制，构建控件的相对位置模型，适配不同设备界面布局。
支持控件语义级识别与引用，不依赖像素级坐标，避免因分辨率、DPI 差异导
致的误操作。实现一次录制、多端回放，增强用例迁移能力，显著降低维护成本。
更智能：操作更可靠，系统具备自我校正能力
多个相似控件（如多个“播放”按钮）共存时，系统可结合上下文、位置信息、历史操作等，智能推理正确目标。增强模型对错误执行的感知与修正能力，例如通过断言失败自动重试、提示词重构、切换备选控件等方式提升稳定性。逐步构建“反馈-优化-再执行”的闭环，让系统在执行中持续学习和进化。
4.2 测试用例自动生成：从“人写”到“AI写”
基于探索式执行生成用例：AI在应用中模拟用户操作，自动点击、滑动、跳转等，通过视觉感知与语义理解自主探索页面逻辑，记录每一步操作路径。将探索过程中形成的“操作轨迹”结构化为标准测试用例，包含：步骤描述、控件引用、预期结果、断言逻辑等。
基于操作日志回溯生成用例：结合用户真实操作行为（如点击轨迹、页面跳转、输入内容等）自动生成标准化的测试用例。可广泛应用于冒烟测试、回归测试等。
自然语言生成测试用例描述：测试人员只需用自然语言描述业务流程，如“打开播放页并点击第一个视频”，系统即可自动生成对应的结构化测试用例，包括控件匹配、坐标规划、断言逻辑等。
4.3 自动化测试覆盖更多场景
全链路业务流程自动化：不仅限于前端 UI 操作，也将逐步融合后端接口测试、埋点校验、数据一致性校验，实现完整链路的端到端验证。
更精准：识别控件更贴合业务语义：
提升通用控件识别准确率，支持多语言、多样式 UI。针对业务特有控件（如播放页定制按钮、图标型功能键等），通过建立控件知识库或训练小型专用模型，实现高精度识别与标注。融合图像、文字、布局等多模态信息，提升语义级控件识别能力。
更稳定：跨设备自动适配，减少环境依赖：
引入空间结构匹配机制，构建控件的相对位置模型，适配不同设备界面布局。
支持控件语义级识别与引用，不依赖像素级坐标，避免因分辨率、DPI 差异导
致的误操作。实现一次录制、多端回放，增强用例迁移能力，显著降低维护成本。
更智能：操作更可靠，系统具备自我校正能力
多个相似控件（如多个“播放”按钮）共存时，系统可结合上下文、位置信息、历史操作等，智能推理正确目标。增强模型对错误执行的感知与修正能力，例如通过断言失败自动重试、提示词重构、切换备选控件等方式提升稳定性。逐步构建“反馈-优化-再执行”的闭环，让系统在执行中持续学习和进化。
4.2 测试用例自动生成：从“人写”到“AI写”
基于探索式执行生成用例：AI在应用中模拟用户操作，自动点击、滑动、跳转等，通过视觉感知与语义理解自主探索页面逻辑，记录每一步操作路径。将探索过程中形成的“操作轨迹”结构化为标准测试用例，包含：步骤描述、控件引用、预期结果、断言逻辑等。
基于操作日志回溯生成用例：结合用户真实操作行为（如点击轨迹、页面跳转、输入内容等）自动生成标准化的测试用例。可广泛应用于冒烟测试、回归测试等。
自然语言生成测试用例描述：测试人员只需用自然语言描述业务流程，如“打开播放页并点击第一个视频”，系统即可自动生成对应的结构化测试用例，包括控件匹配、坐标规划、断言逻辑等。
4.3 自动化测试覆盖更多场景
全链路业务流程自动化：不仅限于前端 UI 操作，也将逐步融合后端接口测试、埋点校验、数据一致性校验，实现完整链路的端到端验证。
杨奕
华为云 HCC云服务产品部 技术规划专家
当前供职华为云HCC云服务产品部担任技术规划专家。其工作范围主要聚焦混合云智能监控运维，服务治理，等方面的前沿技术方向的规划和研发。其主要贡献包括：设计了华为云HCS全栈运维解决方案，大幅简化了政企客户在混合云全栈运维场景下的运维难度；其同时创立并主导CNCF 开源项目Sermant，推动混合云云原生技术向无代理（Proxyless）架构演进。在智算时代，主要负责探索打造混合云运维智能体，使能L5级别的混合云自主运维能力。
待定
待定
华为云Stack全栈运维智能体的准确率提升之路
在私有云场景领域，一个典型痛点是在运维人员数量和公有云差百倍的情况下，如何简化全栈云的运维难度，降低运维人员水平要求。运维智能体产品正好因能较好解决此类问题而兴起。本议题详细叙述华为云Stack在运维领域如何借助知识图谱、大小模型协同计算等相关技术，在知识问答、数据检索、故障诊断等领域，大幅提升智能体在各场景的准确度，并最终帮助用户提升全栈云的运维效率。
内容大纲
1. 阐述私有云和公有云在运维场景的差别，说明为什么运维智能体在私有云尤为重要
2. 说明私有云在运维领域的三个主要场景：知识问答，数据检索，故障诊断，以及场景下的运维智能体的技术挑战和解法
内容大纲
1. 阐述私有云和公有云在运维场景的差别，说明为什么运维智能体在私有云尤为重要
2. 说明私有云在运维领域的三个主要场景：知识问答，数据检索，故障诊断，以及场景下的运维智能体的技术挑战和解法
2.1 阐述知识问答的场景和其在传统RAG技术下的挑战
2.2.1 介绍团队采用Graph-RAG来解决的思路，以及相对业界Graph-RAG做法，团队采用的主要亮点技术
2.2.2 阐明最终效果：图谱构建效率比传统GraphRAG方法提升10倍，召回性能相比传统RAG提升3倍，且绝对准确率比传统RAG提升20%
2.2.2 阐明最终效果：图谱构建效率比传统GraphRAG方法提升10倍，召回性能相比传统RAG提升3倍，且绝对准确率比传统RAG提升20%
2.2 阐述数据检索的场景主要是多源数据查询，以及其核心挑战
2.2.1 讲述如何通过模型自驱修复方法，快速修复元数据描述的方法
2.2.2 讲述如何面向不通数据源构建NL2ES、NL2SQL、NL2API原子查询能力
2.2.3 讲述如何通过元数据知识图谱，构建基于Graph-COT的多源数据查询思维链
2.2.4 展示最终实践结果，数据检索能有效满足各类运维、运营数据、和复杂关联数据的查询，且能满足一定的查询精度
2.2.2 讲述如何面向不通数据源构建NL2ES、NL2SQL、NL2API原子查询能力
2.2.3 讲述如何通过元数据知识图谱，构建基于Graph-COT的多源数据查询思维链
2.2.4 展示最终实践结果，数据检索能有效满足各类运维、运营数据、和复杂关联数据的查询，且能满足一定的查询精度
2.3 阐述故障诊断的场景切入点：告警聚合和告警根因定界
2.3.1 说明如何通过全栈拓扑和告警映射，驱动大模型做根因定界
2.3.2 如果通过小模型的提前聚类，加速大模型的根因定界性能
2.3.3 展示最终实践结果，表明该方法有能有效解决大规模场景下的告警根因定界
2.3.2 如果通过小模型的提前聚类，加速大模型的根因定界性能
2.3.3 展示最终实践结果，表明该方法有能有效解决大规模场景下的告警根因定界
3. 讲述未来工作，包括面向A2A的运维场景的探索，等
听众收益
1. 了解全栈云在基于大模型的AIOps领域的阶段性实现思路
2. 了解Graph-RAG的优化方法和实践
3. 了解如何面向多源数据检索的查询场景，构建元数据知识图谱，并解决复杂关联查询问题
4. 如何通过大小模型协同计算，解决面向全栈云的快速告警根因定界
听众收益
1. 了解全栈云在基于大模型的AIOps领域的阶段性实现思路
2. 了解Graph-RAG的优化方法和实践
3. 了解如何面向多源数据检索的查询场景，构建元数据知识图谱，并解决复杂关联查询问题
4. 如何通过大小模型协同计算，解决面向全栈云的快速告警根因定界
吴婷
阿里巴巴淘天集团 高级测试开发工程师
阿里巴巴淘天集团用户技术团队高级测试开发工程师，目前主要负责淘宝广告外投业务全域的质量和稳定性保障，在端到端、稳定性、真机体验等专项上有一些创新。毕业后曾就职于网易（杭州）网络有限公司、有赞科技有限公司，对前中后台的质量保障都有一定积累。
待定
待定
数据驱动下的广告可见性和真机体验实践分享
在业界的广告投放中，广告主能通过数据埋点得到流量、转化、成本等关键指标，从而更好地决策分人群和场景的投放，最优思路是多维数据驱动下极致精准的人-货-场匹配。但因为缺乏对广告曝光的“视觉”可见，无法感知到真实广告呈现-广告承接全流程中用户可能遇到的问题，数据的绝对“理性”无法回答：“感性”的用户为何不点击不停留不购买的问题。为此，我们引入了一套数据驱动下的广告真机可见性的方案来模拟用户与广告的交互，结合AI大模型等新技术，判定广告端到端的体验上存在的问题。
内容大纲
1. 广告可见性：先解决能看得见广告的问题
1.1 广告可见白名单设备
1.2 简化广告召回策略、裁剪不必要的定向逻辑，透出指定条件的素材或者承接参竞
1.3 参竞提价确保竞胜
2. 真机体验：再解决广告视觉的问题
2.1 广告挖掘：白名单设备使用ADB运行脚本，OCR+大模型判定找到目标广告
2.2 已知点位：脚本步骤编排化
2.3 未知点位：基于移动端Agent的元素识别和元素遍历
2.4 真机上报：端外曝光图片/视频、广告上下文、广告文本、端内承接页截图、点击唤端视频
3. 大模型判定：最后分析广告端到端存在的问题
3.1 用Prompt+知识库的方式搭建基于自然语言的Agent，基于大模型的视觉和思维推理能力，从多方面识别潜在的问题
3.2 素材可能的问题：尺寸不匹配、拉伸、截断、留白、元素不一致等
3.3 投放和承接一致性可能的问题：曝光商品在承接页面未还原、曝光素材中商品价格和承接页面商品价格不一致、
内容大纲
1. 广告可见性：先解决能看得见广告的问题
1.1 广告可见白名单设备
1.2 简化广告召回策略、裁剪不必要的定向逻辑，透出指定条件的素材或者承接参竞
1.3 参竞提价确保竞胜
2. 真机体验：再解决广告视觉的问题
2.1 广告挖掘：白名单设备使用ADB运行脚本，OCR+大模型判定找到目标广告
2.2 已知点位：脚本步骤编排化
2.3 未知点位：基于移动端Agent的元素识别和元素遍历
2.4 真机上报：端外曝光图片/视频、广告上下文、广告文本、端内承接页截图、点击唤端视频
3. 大模型判定：最后分析广告端到端存在的问题
3.1 用Prompt+知识库的方式搭建基于自然语言的Agent，基于大模型的视觉和思维推理能力，从多方面识别潜在的问题
3.2 素材可能的问题：尺寸不匹配、拉伸、截断、留白、元素不一致等
3.3 投放和承接一致性可能的问题：曝光商品在承接页面未还原、曝光素材中商品价格和承接页面商品价格不一致、
曝光页面和承接页面没有关联等
4. 数据驱动反哺体验和工程建设
4.1 通过真机上报数据中的问题点位特征，归类同类型风险点位，增加问题发现广度
4.2 通过大模型判定数据与真实评测结果的不断校准，提升prompt覆盖完备度，并分解成链式multi agent提升判定精确度
4.3 通过真机上报数据沉淀广告位物理尺寸资产集，作用于工程建设中的素材生产和圈选，提升广告投放准确度
5. 效能和收益
5.1 将广告体验和问题挖掘的人工操作全自动化，节约人工巡检人日
5.2 将纯工程处理的问题判定简化为大模型的自然语言规则，提升规则匹配的人效
5.3 发现典型问题包括但不限于：
5.3.1 参竞素材站外曝光时被替换
5.3.2 广告版位信息维护错误
5.3.3 营销氛围过期素材投放
5.3.4 曝光商品在承接页面无法还原、价格不一致等
4. 数据驱动反哺体验和工程建设
4.1 通过真机上报数据中的问题点位特征，归类同类型风险点位，增加问题发现广度
4.2 通过大模型判定数据与真实评测结果的不断校准，提升prompt覆盖完备度，并分解成链式multi agent提升判定精确度
4.3 通过真机上报数据沉淀广告位物理尺寸资产集，作用于工程建设中的素材生产和圈选，提升广告投放准确度
5. 效能和收益
5.1 将广告体验和问题挖掘的人工操作全自动化，节约人工巡检人日
5.2 将纯工程处理的问题判定简化为大模型的自然语言规则，提升规则匹配的人效
5.3 发现典型问题包括但不限于：
5.3.1 参竞素材站外曝光时被替换
5.3.2 广告版位信息维护错误
5.3.3 营销氛围过期素材投放
5.3.4 曝光商品在承接页面无法还原、价格不一致等
听众收益
通过数据驱动的方法解决广告可见性的问题、用端上Agent的方式广泛识别广告点位、用OCR+大模型的方式识别广告真机体验链路可能存在的问题。让广告变得：可见、可寻、可知。
通过数据驱动的方法解决广告可见性的问题、用端上Agent的方式广泛识别广告点位、用OCR+大模型的方式识别广告真机体验链路可能存在的问题。让广告变得：可见、可寻、可知。
齐佩之
华为 GTS业务体验领域测试专家
华为技术有限公司 GTS业务体验领域测试专家（首席），长期在测试技术和测试工程能力领域深耕，构建Web UI自动化测试框架，先后实现Web低码和无码自动化写作、LLM辅助自主探索测试、基于意图的自主测试Agent，在公司多个领域广泛使用。
待定
待定
基于模型的自主遍历测试Agent
Web类产品，界面变更快，页面功能组合多，传统基于xpath的UI界面自动化写作成本高且维护工作量大，传统基于算法的web界面探索测试没有测试意图，测试覆盖范围无法准确评估，如何让自主遍历和人的测试设计结合直接到测试执行实现跨越？
内容大纲
整体方案：
基于模型的自主测试能力，用户输入测试意图，Agent基于页面感知自动规划执行任务，基于执行任务自动输出具体的操作指令，自主进行页面的操作执行。
关键技术：
1. 构建Web操作指令集：一套支持浏览器操作相关的指令集，可操作页面各种元素，具备结构简单，执行稳定，可读性强的特点；
2. 基于意图的任务生成：用户输入意图，基于意图创建执行任务和步骤，实现任务规划；
3. 基于任务的步骤执行：基于任务步骤规划调用原子能力，进行步骤执行，每个任务执行可遍历所有步骤的数据组合，实现基于任务的自主遍历测试执行；
4. 基于预期结果和故障模式库的问题检测：根据意图结果和40+种故障模式库进行Web界面问题检测。
听众收益
Web界面测试自动化还需要写具体的用例吗，还需要写自动化脚本吗，或许可以尝试改变了。
陈军
美团 技术专家
美团质效技术部技术专家，目前主要负责美团质效工具建设，对数据构造、精准测试方向有一定的落地实践，AI在质效领域的工程化应用方向上（智能体设计、知识图谱构建）也做了相关的研究与探索。16年加入美团，从事测试开发方向工作。
待定
待定
代码AI Agent在变更影响分析领域的探索与实践
传统测试范围评估的挑战：
1. 高度依赖人工经验（效率低、知识断层、专家资源瓶颈）
2. 复杂依赖难识别（跨服务接口、隐式配置依赖）
3. 测试覆盖盲区（用例设计不完善、多环境差异）
4. 过程资产难沉淀（缺乏可复用知识库）
1. 高度依赖人工经验（效率低、知识断层、专家资源瓶颈）
2. 复杂依赖难识别（跨服务接口、隐式配置依赖）
3. 测试覆盖盲区（用例设计不完善、多环境差异）
4. 过程资产难沉淀（缺乏可复用知识库）
AI时代的新风险：
1. AI生成代码的不可预知性（逻辑偏差、隐式依赖）
2. AI修改代码的回归测试危机（非目标模块被修改、新逻辑分支缺乏覆盖）
3. 研发评估准确度降低（代码风格多变，传统方式失效）
解决方向：
通过构建代码知识图谱和AI智能体，实现变更影响的自动化分析，结合工程编码与AI泛化能力，提升测试范围评估的精准性。
内容大纲
1. 背景与挑战
1.1 线上问题分布数据（大量问题均由变更影响评估不到位导致）
1.2 传统评估痛点 vs AI时代新风险
2. 代码知识图谱构建
2.1 目标：精准代码关系 + 高效查询能力
2.2 关键技术：代码解析、业务特征工程、图数据库优化
2.3 业务知识挖掘：AI辅助特征清洗/总结/校验
3. 智能体构建与交互
3.1 架构分层：数据层（MySQL/ES/Graph）、基础设施层（AST/链路算法）、应用层（意图识别/流程规划）
3.2 核心能力：意图识别、多轮对话管理、动态工具编排
3.3 交互流程：用户输入→意图识别→工具执行→结果聚合
4. 阶段成果与演进方向
4.1 拦截缺陷分布；
4.2 未来优化：知识处理增强、多语言支持、需求-代码追踪矩阵
听众收益
1. 直接成效：
1.1 降低测试逃逸率：通过精准影响范围分析，拦截变更相关问题（如配置遗漏、兼容性风险）
1.2 提升效率：AI智能体实时生成测试建议，减少人工评估时间
2. 可复用的技术经验：
2.1 业务特征工程：AI辅助打标业务属性（如接口含义、风险特征），增强图谱实用性
2.2 智能体设计：分层Prompt管理、规则引擎消解模糊意图、动态工具编排（DAG优化）
2.3 知识沉淀：将分析结论转化为数字资产，解决知识传承难题
3. 量化数据参考：
3.1 拦截问题分布
3.2 关键指标：意图识别准确率、召回率周级监控机制
4. 风险防控实践：
4.1 覆盖AI生成代码的隐式依赖检测，解决“回归测试危机”
4.2 通过图谱追踪数据流完整性，预防跨服务链路异常
邵楠
中兴通讯 高级系统工程师
专注于云原生网络转型与AI驱动的智能运维体系建设。主导完成运维中心智能化改造，通过AI智能体实现故障预测准确率提升，自动化处置率超85%；构建AIOps平台，将部署效率提升60%，并落地沃达丰跨国云化验证。拥有多项云原生与AI融合专利，输出多份AI提效最佳实践，推动团队研发流程智能化升级。专长领域：云原生、AI工程化、智能运维中台、LLM应用落地及高可用架构设计。
待定
待定
伴随式AI代码评审最佳实践—基于IDE插件+AI的即写即检质量守护
代码评审是保证代码质量的重要环节，传统评审活动治理周期长、AI评审不准确、项目规范难落实，严重拖累效率质量。
本实践所述的技术方案正解决上述问题，提出了一种基于前后端分离的伴随式AI代码评审系统及方法。将评审插件和规则分离实现规则热更新，通过伴随式代码评审智能体实现评审状态左移，让开发人员在编码过程中就能一时间确认结果，缩短反馈周期，提升效率与质量。
内容大纲
本实践所述的技术方案重塑代码评审流程，引入伴随式自动代码评审，实现“即写即检查”。主要实践点如下：
1.架构创新：采用"前端上下文感知+后端规则服务化"的分离架构，前端通过AST解析器（支持20+编程语言）标准化代码特征提取，后端构建弹性规则服务，实现规则与IDE环境的解耦升级
2.伴随式评审智能体：与编码环境深度结合，实时监测代码质量，快速反馈潜在问题，大幅减少修改验证的周期
3.原子化规则评审服务：智能规则引擎预筛待检项，AI语义分析+静态检查双轨复核，实现缺陷行级精确定位，支持项目级/领域级/团队级自定义检查规则，通过静态+AI混合规则（如"当检测到内存释放接口，触发AI模型进行指针解引用分析"）
4.知识进化机制：基于项目代码构建代码图谱，补全评审上下文。结合用户反馈持续形成轨迹数据，形成数据飞轮持续优化AI应用，提升代码评审准确率
从而实现“即写即检查”。开发人员在编码阶段可第一时间确认结果，缩短反馈周期，提升效率与质量。
本实践所述的技术方案正解决上述问题，提出了一种基于前后端分离的伴随式AI代码评审系统及方法。将评审插件和规则分离实现规则热更新，通过伴随式代码评审智能体实现评审状态左移，让开发人员在编码过程中就能一时间确认结果，缩短反馈周期，提升效率与质量。
内容大纲
本实践所述的技术方案重塑代码评审流程，引入伴随式自动代码评审，实现“即写即检查”。主要实践点如下：
1.架构创新：采用"前端上下文感知+后端规则服务化"的分离架构，前端通过AST解析器（支持20+编程语言）标准化代码特征提取，后端构建弹性规则服务，实现规则与IDE环境的解耦升级
2.伴随式评审智能体：与编码环境深度结合，实时监测代码质量，快速反馈潜在问题，大幅减少修改验证的周期
3.原子化规则评审服务：智能规则引擎预筛待检项，AI语义分析+静态检查双轨复核，实现缺陷行级精确定位，支持项目级/领域级/团队级自定义检查规则，通过静态+AI混合规则（如"当检测到内存释放接口，触发AI模型进行指针解引用分析"）
4.知识进化机制：基于项目代码构建代码图谱，补全评审上下文。结合用户反馈持续形成轨迹数据，形成数据飞轮持续优化AI应用，提升代码评审准确率
从而实现“即写即检查”。开发人员在编码阶段可第一时间确认结果，缩短反馈周期，提升效率与质量。
听众收益
本演讲为听众带来三大核心价值：
1. 可直接落地的技术方案，提供前后端分离的IDE插件架构和规则热更新机制，支持快速部署；
2. 创新性的"静态分析+AI语义"双轨评审模式，显著降低误报率40%以上，评审准确率达95%+；3）经过验证的效能提升路径，实现评审效率10倍提升和缺陷修复成本降低60%。
听众可借鉴我们的代码图谱构建方法和数据飞轮机制，避免AI模型训练和规则迭代中的常见陷阱，快速构建自己的智能评审体系。
本演讲为听众带来三大核心价值：
1. 可直接落地的技术方案，提供前后端分离的IDE插件架构和规则热更新机制，支持快速部署；
2. 创新性的"静态分析+AI语义"双轨评审模式，显著降低误报率40%以上，评审准确率达95%+；3）经过验证的效能提升路径，实现评审效率10倍提升和缺陷修复成本降低60%。
听众可借鉴我们的代码图谱构建方法和数据飞轮机制，避免AI模型训练和规则迭代中的常见陷阱，快速构建自己的智能评审体系。
张冲
群核科技 技术支持专家
先后就职于东软集团股份有限公司、杭州有赞科技有限公司以及杭州群核信息技术有限公司，拥有超过 10 年的软件开发及技术支持经验。目前就职于群核科技，技术支持创新驱动团队负责人，参与了群核科技技术支持团队的组建和变革，致力于提升团队效能和服务体验。
待定
待定
AI驱动的线上问题解决与客户服务能力升级
在传统客户服务和问题解决流程中，大量重复性工单处理和复杂业务带来的高学习与知识沉淀成本，导致响应缓慢、效率低下，客户满意度难以保障。随着企业业务日益多元，如何快速、高效地处理海量工单、提升问题定位与解决速度成为亟待突破的难题。近年来，人工智能技术尤其是大模型和知识库的融合，为构建智能化、自动化的客户服务体系带来了全新可能。本文聚焦基于AI的多渠道问题收集、智能预处理、工单自动分类路由、辅助排查、知识库自动生成及智能故障预警等核心能力，探索如何实现线上问题解决的全链路协同升级，显著提升服务质量、效率和用户体验，为企业数字化转型注入新动能。
内容大纲
1. 传统痛点与AI赋能机遇
1.1 客户服务面临的挑战
1.1.1 重复工作量大、响应周期长
1.1.2 业务多样化，知识沉淀难
1.1.3 人工处理力不足导致效率和质量瓶颈
1.2 AI技术变革带来的突破口
1.2.1 大模型与知识库驱动的智能答复
1.2.2 数据流通打通，实现信息闭环
1.2.3 多渠道融合，用户接入更加便捷
2. 全链路AI驱动解决方案架构
2.1 多渠道问题收集与预处理
2.1.1 支持群聊、单聊、企业IM多入口
2.1.2 智能意图识别与相似工单推送
2.2 工单智能生成与分派
2.2.1 高准确率工单分类模型
2.2.2 灵活路由规则自动派单
2.3 AI辅助排查与问题诊断
2.3.1 调用多工具SOP支持快速排查
2.3.2 实时排查结果反馈工单系统
2.4 知识库自动生成与闭环优化
2.4.1 NLP自动提炼排查经验形成知识文档
2.4.2 人机协同不断优化知识库质量
2.5 智能故障预警与应急协同
2.5.1 多维异常检测和聚类分析
2.5.2 一键拉群与语音会议加速故障响应
3. 核心AI技术亮点与实践成效
3.1 基于大模型的智能问答与多轮对话支持
3.2 快速高效的工单分类与自动路由机制
3.3 AI排查工具链与排查场景自动匹配
3.4 知识图谱增强的自动知识生成技术
3.5 故障预警动态阈值自适应和智能分级处置
4. 实际应用收益与案例分享
4.1 提单效率提升与响应周期缩短
4.2 问题解决速度提升70%、准确率提升50%
4.3 AI问答成功率从60%提升至85%以上
4.4 渲染类工单排查时间由30分钟降至3分钟
4.5 故障预警提前发现，影响范围缩减60%
5. 未来展望与持续发展
5.1 与MCP等平台深度融合，实现更广泛服务场景AI应用
5.2 强化智能分析和个性化推荐能力
5.3 推动跨系统知识共享和生态协同
5.4 探索人机协同最佳实践，兼顾智能与人为体验
听众收益
1. 理解传统客户服务面临的核心痛点及AI赋能的突破点
2. 掌握构建AI驱动客户服务全链条解决方案的关键能力和技术路径
3. 学习具体实践案例，借鉴高效工单处理、智能排查与知识库管理的新方法
4. 获得切实提升服务质量与效率的创新思路，助力数字化转型降本增效
5. 避免项目实施中常见的技术和组织瓶颈，少走弯路快速落地
内容大纲
1. 传统痛点与AI赋能机遇
1.1 客户服务面临的挑战
1.1.1 重复工作量大、响应周期长
1.1.2 业务多样化，知识沉淀难
1.1.3 人工处理力不足导致效率和质量瓶颈
1.2 AI技术变革带来的突破口
1.2.1 大模型与知识库驱动的智能答复
1.2.2 数据流通打通，实现信息闭环
1.2.3 多渠道融合，用户接入更加便捷
2. 全链路AI驱动解决方案架构
2.1 多渠道问题收集与预处理
2.1.1 支持群聊、单聊、企业IM多入口
2.1.2 智能意图识别与相似工单推送
2.2 工单智能生成与分派
2.2.1 高准确率工单分类模型
2.2.2 灵活路由规则自动派单
2.3 AI辅助排查与问题诊断
2.3.1 调用多工具SOP支持快速排查
2.3.2 实时排查结果反馈工单系统
2.4 知识库自动生成与闭环优化
2.4.1 NLP自动提炼排查经验形成知识文档
2.4.2 人机协同不断优化知识库质量
2.5 智能故障预警与应急协同
2.5.1 多维异常检测和聚类分析
2.5.2 一键拉群与语音会议加速故障响应
3. 核心AI技术亮点与实践成效
3.1 基于大模型的智能问答与多轮对话支持
3.2 快速高效的工单分类与自动路由机制
3.3 AI排查工具链与排查场景自动匹配
3.4 知识图谱增强的自动知识生成技术
3.5 故障预警动态阈值自适应和智能分级处置
4. 实际应用收益与案例分享
4.1 提单效率提升与响应周期缩短
4.2 问题解决速度提升70%、准确率提升50%
4.3 AI问答成功率从60%提升至85%以上
4.4 渲染类工单排查时间由30分钟降至3分钟
4.5 故障预警提前发现，影响范围缩减60%
5. 未来展望与持续发展
5.1 与MCP等平台深度融合，实现更广泛服务场景AI应用
5.2 强化智能分析和个性化推荐能力
5.3 推动跨系统知识共享和生态协同
5.4 探索人机协同最佳实践，兼顾智能与人为体验
听众收益
1. 理解传统客户服务面临的核心痛点及AI赋能的突破点
2. 掌握构建AI驱动客户服务全链条解决方案的关键能力和技术路径
3. 学习具体实践案例，借鉴高效工单处理、智能排查与知识库管理的新方法
4. 获得切实提升服务质量与效率的创新思路，助力数字化转型降本增效
5. 避免项目实施中常见的技术和组织瓶颈，少走弯路快速落地
王玉玺
群核科技 测试开发资深工程师
群核科技（酷家乐） 测试开发资深工程师，积累了极为丰富的质量保障及效能优化经验。在职期间，凭借扎实的专业能力，主导构建了测试管理系统、故障管理系统以及工单系统，有力提升了内部管理流程的规范性与高效性。同时，积极投身于研发效能工具、核心服务分桶开关系统的开发与维护工作，以卓越的技术贡献，为各系统的高效、稳定运行筑牢坚实根基 。
待定
待定
测试左移体系化实践与AI赋能 - 群核科技的探索与实践
在软件研发迭代速度持续加快的当下，传统测试模式已难以应对高质量交付需求。测试左移作为将质量保障环节向研发早期迁移的理念，正成为解决行业痛点的核心路径。本次分享将结合群核科技的实践，详解如何通过体系化建设与 A1赋能，构建全链路左移测试体系，为业界提供可复用的实践经验。
内容大纲
1. 左移背景:从行业共性到企业特性的痛点剖析
1.1 行业共性痛点:质量与效率的双重困境
1.2 群核科技的具体挑战:业务特性带来的独特难题
1.3 解题思路:构建全链路左移测试体系
2. 左移探索全景与分阶段实践
2.1 左移探索全景图
2.2 阶段一:功能用例研发自测-卡住功能质量基本盘
2.3 阶段二:研发单分支自动化测试-深化分支级质量保障。
2.4 阶段三:自动化用例研发自测-提升效率与覆盖
2.5 阶段四:专项能力左移 -- 性能左移
3. AI 赋能测试左移
3.1 Al 赋能全景图
3.2 左移功能用例引入 AI 生成
3.3 左移自动化失败引入 AI 诊断
3.4 性能左移引入结果 AI 分析
4. 阶段性成果与价值
4.1 接口自动化左移成果
4.2 性能左移成果
5. 未来展望
5.1 深化左移能力
5.2 AI 赋能探索
罗曼
群核科技 测试开发专家
群核科技 测试开发专家，先后就职于新浪、51信用卡、群核科技等公司，现为杭州群核科技平台网站组测试负责人，自动化能力建设负责人。从事软件测试行业10余年，参与自动化相关工作6年多。
待定
待定
群核科技接口自动化能力的发展
接口自动化已经成为业内日常回归测试的标配方式，但自动化用例的编写和维护成本依然很高，成为制约效率提升的瓶颈。群核科技深刻洞察这一痛点，致力于通过技术创新提升自动化的人效比。我们整合了现有的测试平台，结合强大的AI能力，实现了自动化能力的升级。不仅帮助自动生成和维护测试用例，还能精准定位问题，大幅减少人工干预，实现更高效、更稳定的测试执行。通过这些举措，群核科技成功用更少的人力投入撬动了更大的自动化价值，极大提升了测试团队的生产力和质量保障能力。
内容大纲
1. 群核科技接口自动化建设的发展与挑战
1.1 从脚本化到平台化的演进
1.2 遭遇的瓶颈与痛点
2. 接口自动化与流量录制回放的协同应用
2.1 流量录制回放的初衷
2.2 从Kudiffy到Kurepeater的探索
2.3 Kurepeater替代接口自动化的局限
2.4 接口自动化与流量录制回放的优势互补
3. 自动化平台能力进一步提升策略
3.1 自动化人效的进一步提升
3.2 AI能力的集成与探索
4. 收益总结与未来展望
4.1 已取得的成效
4.2 下一步规划
听众收益
该分享内容是群核科技一步步走过来的历程，希望可以给同行一些启发和借鉴。
内容大纲
1. 群核科技接口自动化建设的发展与挑战
1.1 从脚本化到平台化的演进
1.2 遭遇的瓶颈与痛点
2. 接口自动化与流量录制回放的协同应用
2.1 流量录制回放的初衷
2.2 从Kudiffy到Kurepeater的探索
2.3 Kurepeater替代接口自动化的局限
2.4 接口自动化与流量录制回放的优势互补
3. 自动化平台能力进一步提升策略
3.1 自动化人效的进一步提升
3.2 AI能力的集成与探索
4. 收益总结与未来展望
4.1 已取得的成效
4.2 下一步规划
听众收益
该分享内容是群核科技一步步走过来的历程，希望可以给同行一些启发和借鉴。
胡涛
中国银联 高级研发工程师
主要负责中国银联测试工具体系与技术平台的构建，涵盖测试资产管理、环境全链路实时监控、功能/性能/高可用性测试自动化等核心模块的平台化整合与工具链研发。通过平台化、自动化、智能化技术驱动测试转型，为核心交易转接清算关键金融系统提供全链路的质量保障。
待定
待定
用智能测智能 - 智能体测试工具体系建设实践
面对以AI Agent（智能体）为代表的智能应用的应运而生，智能体的非确定性输出（如多轮交互中的幻觉累积）、动态环境感知（跨模态决策）、持续自优化行为等特性，使得传统的测试工具和方式无法量化概率性行为，难以覆盖伦理偏见、多轮幻觉等长尾场景。因此需要利用人工智能，构建具备同等智能水平的测试体系，以动态闭环实现“以智治智”。
内容大纲
1. 智能体系统的质量挑战深度解构
1.1 动态行为：非确定性输出、多轮交互依赖、环境感知决策
1.2 认知复杂度：意图理解、规划反思（Plan-Reflect）、多智能体协作
1.3 多模态依赖：文本、视觉、工具调用的融合能力验证
2. 智能体测试的评价体系
2.1 量化评价模型（准确性、可信性、效能）
2.2 动态评价实施框架
3. 测试工具的智能化实现
3.1 测试智能体集群自治架构
3.2 调度执行智能化引擎
3.3 “执行→分析→进化”闭环迭代
4. 落地实践与价值验证
4.1 金融场景下的落地实践
4.2 量化收益和质变价值
5. 总结&展望
听众收益
1. 对测试智能体的工具建设有启发
2. 提供用智能测智能的工具建设方法
刘伟明
中兴通讯 FM研发中心软件开发资深专家
中兴通讯FM研发中心软件开发资深专家，管理教练，15年通信行业软件研发经历，目前主要负责研发中心AI研发提效整体规划、管理及运作，驱动软件研发由数字化向智能化演进，聚焦基于大模型的研发领域智能体应用有效性提升及端到端智能体网络的全流程贯通。
待定
待定
AI大模型加持下的研发效能度量
问题：AI大模型在软件研发上的增强和替代，给我们带来了哪些正向收益，如何去衡量AI的产出以及对产能带来的增量
痛点：
痛点：
1）AI应用的产出缺少统一的度量算法；
2）生产数据分布在多个研发系统，采集及呈现困难；
3）AI应用的落地和产能没有明确的映射关系
思考：
思考：
1）从内容域上区分人和AI的产出；
2）统一数据拉取接口，建立组织级看板；
3）效能目标和AI的投入产出比进行映射
内容大纲
1. 问题：AI大模型在软件研发上的增强和替代，给我们带来了哪些正向收益，如何去衡量AI的产出以及对产能带来的Δ增量
2. 痛点分析
2.1 AI应用的产出缺少统一的度量算法
2.2 生产数据分布在多个研发系统，采集及呈现困难
2.3 AI应用的落地和产能没有明确的映射关系
3. 解决思路
3.1 统一度量衡和数据获取方法
3.2 统一组织级度量看板
3.3 能耗的估算模型
4. 实践情况
4. 实践情况
4.1 AI应用全景及指标定义
4.2 生产数据的抓取及基于grafana的看板
4.3 研发能耗分布及AI效能映射逻辑
5. 价值收益：24年提效情况，25年提效展望
5. 价值收益：24年提效情况，25年提效展望
听众收益
1. AI应用的指标如何定义
2. AI应用的度量看板如何建立
3. AI应用的产出和效能如何映射
王欢
东方证券 研发效能负责人
东方证券研发效能负责人、质控管理专家，FinEU发起人。10年+研发管理经验，精通PMO流程优化、质量控制体系搭建，作为国内最早一批（2019年）研发效能平台建设的领航人，有着丰富的效能平台建设经验，平台曾获得多次行业联盟协会奖项、优秀讲师等荣誉，并已在知名期刊发表多篇学术论文。作为核心专家参与金融人才协会联盟发起2025年《金融行业研发效能数智化白皮书》及后续撰写工作。曾就职于兴业银行、阿里系等公司，并作为DevOps Master、CISP、ISO26262、ISO9001内审等多个领域证持专家。
待定
待定
数据能对话，治理有AI：大模型破解效能度量深水区
近年来，在经济环境驱动下，提质增效的浪潮席卷各行各业，效能度量成为企业管理的 “必答题”，几乎所有团队都投入到度量工作中。然而，现实却不尽如人意 —— 真正能从效能度量中获得满意产出的案例少之又少。
当前效能度量面临三大核心痛点：一是领导关注度 “降温”，初期的重视逐渐淡化，精心搭建的效能平台数据鲜少被主动查看，仅在汇报时才被临时关注；二是副作用显现，度量指标反而导致团队氛围紧张，甚至出现 “为指标而工作” 的异化行为；三是度量与改进脱节，数据停留在统计层面，缺乏有效的跟踪机制和推动力量，难以转化为实际的效能提升。
面对这些困境，本次演讲将聚焦破局思路：如何通过强化可视化让数据 “主动说话”，如何联动 EPG 与质控力量推动持续改进。同时，还将分享如何借助大模型技术破解度量副作用，比如用大模型检测重复代码、推动代码治理，让效能度量真正实现从数据到价值的跨越。
内容大纲
1. 效能度量基石：科学指标设计与实战解析
1.1 告别盲目Copy，设计贴合业务的指标
1.2 关键方法论实战：价值流穿透、组合制衡、GQM法
1.3 实战案例：指标如何驱动实际改进
2. 效能度量跃升：数据可视化驱动决策
2.1 痛点突破：让领导“一眼看懂”现状与决策点
2.2 策略：选对图表、聚焦结论、打造“决策点”
2.3 目标：从数据堆砌到有效决策支撑
3. 闭环落地：度量-改进的最后一公里（EPG驱动）
3.1 核心挑战：如何推动改进？解决人手不足？
3.2 解决方案：报团取暖，EPG闭环机制 - 问题归口、跟踪协调、反馈验证
3.3 成果：建立效能提升正循环
4. 技术赋能：AI驱动代码质量治理
4.1 创新实践：大模型自动化代码重复度深度检测
4.2 驱动改进：基于量化报告，精准治理技术债
4.3 目标：构建代码质量持续改进动力
听众收益
1. 开箱即用的指标设计及实践
避免指标设计的盲目性。我将提供实用的指标设计工具和方法，例如如何进行指标制衡设计、如何运用GPQ法（目标-问题-指标法） 精准定义指标，以及如何避免盲目照搬大厂指标，确保您的指标体系贴合实际、有效可用。
2. 从“给领导看数字”到“让领导一眼看到决策点”
告别枯燥的数据堆砌。将提供效能度量结果的可视化解决方案（包含数据、表格、图表），并提炼关键结论，让领导层能直观、快速地理解现状、识别问题核心，从而高效做出有数据支撑的决策。
3. 打通“度量-改进”闭环，解决执行难题
度量发现问题只是起点，推动改进才是关键。我将分享一套利用EPG（工程过程组）推动持续改进的落地机制。这套机制能有效解决“人手不足”的痛点：度量发现的问题自动归口到EPG进行跟踪、反馈和闭环管理，确保改进措施有效执行，真正实现效能提升的“最后一公里”。
4. 用AI驱动代码质量提升
我将介绍如何利用大模型自动化进行代码重复度检测，并基于客观、量化的检测结果，主动驱动项目组进行代码优化和重构，形成持续改进的技术驱动力。
1.1 告别盲目Copy，设计贴合业务的指标
1.2 关键方法论实战：价值流穿透、组合制衡、GQM法
1.3 实战案例：指标如何驱动实际改进
2. 效能度量跃升：数据可视化驱动决策
2.1 痛点突破：让领导“一眼看懂”现状与决策点
2.2 策略：选对图表、聚焦结论、打造“决策点”
2.3 目标：从数据堆砌到有效决策支撑
3. 闭环落地：度量-改进的最后一公里（EPG驱动）
3.1 核心挑战：如何推动改进？解决人手不足？
3.2 解决方案：报团取暖，EPG闭环机制 - 问题归口、跟踪协调、反馈验证
3.3 成果：建立效能提升正循环
4. 技术赋能：AI驱动代码质量治理
4.1 创新实践：大模型自动化代码重复度深度检测
4.2 驱动改进：基于量化报告，精准治理技术债
4.3 目标：构建代码质量持续改进动力
听众收益
1. 开箱即用的指标设计及实践
避免指标设计的盲目性。我将提供实用的指标设计工具和方法，例如如何进行指标制衡设计、如何运用GPQ法（目标-问题-指标法） 精准定义指标，以及如何避免盲目照搬大厂指标，确保您的指标体系贴合实际、有效可用。
2. 从“给领导看数字”到“让领导一眼看到决策点”
告别枯燥的数据堆砌。将提供效能度量结果的可视化解决方案（包含数据、表格、图表），并提炼关键结论，让领导层能直观、快速地理解现状、识别问题核心，从而高效做出有数据支撑的决策。
3. 打通“度量-改进”闭环，解决执行难题
度量发现问题只是起点，推动改进才是关键。我将分享一套利用EPG（工程过程组）推动持续改进的落地机制。这套机制能有效解决“人手不足”的痛点：度量发现的问题自动归口到EPG进行跟踪、反馈和闭环管理，确保改进措施有效执行，真正实现效能提升的“最后一公里”。
4. 用AI驱动代码质量提升
我将介绍如何利用大模型自动化进行代码重复度检测，并基于客观、量化的检测结果，主动驱动项目组进行代码优化和重构，形成持续改进的技术驱动力。
汪志贞
阿里巴巴 高级测试开发专家
阿里15年测试经验，主要在电商领域，对于自动化提效、系统稳定性、大促质量保障等方面经验丰富。目前是阿里巴巴跨境电商AliExpress（简称AE）交易链路及营销的测试主管，同时负责AE全站资损防控工作。
待定
待定
AI助力的资损防控体系化解决方案
以跨境电商AliExpress的实践为例，核心介绍资损的定义以及基于AI的体系化资损防控的解决方案，包括资损风险识别、资损问题发现、应急、快恢的智能化能力建设，并与项目流程自动化管控结合，以及度量、文化建设和收益。
内容大纲
1. 破题：资损的定义及防控难点
1.1 资损的危害：公司收益、体验的损失及举例
1.2 资损的广义及狭义定义
1.3 防控的现状及难点
2. 解决方案：AI助力的资损防控体系
2.1 资损防控体系化方案大图
2.2 风险识别：资损风险的智能识别及场景生成【创新】
2.3 问题发现：资损对账自动生成及告警【创新】
2.4 应急响应：防控应急SOP
2.5 资损保鲜：自动化攻防【创新】
2.6 项目流程：项目标准化防控流程再造
2.7 防控底座：度量及组织文化
3. 落地成效及未来思考
3.1 量化收益
3.2 未来思考
听众收益
1. 资损防控从单点的对账到体系化的可复用的解决方案
2. 了解AI在资损防控领域的使用实践
3. 可有效减少企业的资金及用户体验损失
内容大纲
1. 破题：资损的定义及防控难点
1.1 资损的危害：公司收益、体验的损失及举例
1.2 资损的广义及狭义定义
1.3 防控的现状及难点
2. 解决方案：AI助力的资损防控体系
2.1 资损防控体系化方案大图
2.2 风险识别：资损风险的智能识别及场景生成【创新】
2.3 问题发现：资损对账自动生成及告警【创新】
2.4 应急响应：防控应急SOP
2.5 资损保鲜：自动化攻防【创新】
2.6 项目流程：项目标准化防控流程再造
2.7 防控底座：度量及组织文化
3. 落地成效及未来思考
3.1 量化收益
3.2 未来思考
听众收益
1. 资损防控从单点的对账到体系化的可复用的解决方案
2. 了解AI在资损防控领域的使用实践
3. 可有效减少企业的资金及用户体验损失
赖洪水
中兴通讯 大型项目DevOps负责人
中兴通讯 大型项目基础设施团队负责人，负责项目效能平台建设，涵盖DevOps、工具、资源环境，为项目提供研发效能服务。从业20年，同时作为敏捷教练，为多个项目进行敏捷及DevOps赋能。
待定
待定
基于知识工程的流水线失败脚本AI智能分析实践
问题痛点：项目交付产品多，多分支并行开发，且大型项目（450+），横跨6地，流水线执行失败后，环境问题、版本问题、脚本问题定界定位链条长，涉及人员多，跨地区沟通协作成本高，自动化的反馈能力无法匹配项目快速判定版本/补丁是否可交付的诉求。
思考方向：基于代码价值流模型，从等待时间、运行时长、准确率识别业务流关键活动，结合能耗、风险确定AI应用的建设逻辑。借助大模型能力，构建AI应用，失败脚本智能分析，问题自动修复，环境问题一键提单，功能问题一键提故障单，促进问题快速闭环，助力研发提效。
内容大纲
1. 问题提出：
1.1 痛点识别及AI提效点分析： 基于项目痛点，通过DevOps代码价值流模型识别提效点
1.2 改进目标：
2. 解决思路
2.1 整体方案：介绍失败脚本智能分析AI应用的整体方案
2.2 能力建设：介绍知识工程、应用范式、工具支撑和质量提升四个维度介绍AI能力建设的整体思路
3. 实践落地
3.1 知识体系建设：介绍流水线问题定界定位的知识分类和定义、知识图谱的构建，知识规范的制定和治理（如流水线标准化、环境标准化、日志规范化等）、知识工程流水线建设
3.2 应用范式：介绍如何基于Prompt+RAG+Tools构建AI应用，包括提示词、语料收集、知识库建设、流程编排框架、触点设计
3.3 工具能力建设：介绍构建AI应用使用到的工具，如日志采集及解析、脚本标签解析、报告聚合、邮件发送、环境巡检、一键提交环境运维工单、一键提交故障单等
3.4 质量提升：介绍提升AI应用质量和效率的实践，如度量看板、知识评估、准确率提升专项改进、性能优化，问题自动修复等
4. 效果评价
4.1 从分析准确率、分析及时度、质量、人员提效等几个维度介绍时间效果
听众收益
系统性：本实践知识工程、应用范式、工具支撑和质量提升四大维度，系统性的介绍了如何构建AI应用能力以及相关实践，整体思想可用用于各类AI智能体
可借鉴性：流水线基于Jenkins、测试框架RF框架，均是业界通用的工具，可借鉴性广
王珍懿
蚂蚁集团 测试开发专家
蚂蚁集团测试开发专家，所在团队从事支付宝商家域AI应用的评测工作，本人主要负责评测提效方法在垂类领域的落地应用和算法创新，保障评测工作的高效、全面、及时，降低人力成本投入。有多篇相关顶会论文已录用或审稿中。
待定
待定
基于大模型的智能交互产品评测
随着人工智能技术的快速发展，智能交互产品（如智能客服、语音助手、聊天机器人等）在各领域的应用日益广泛。然而，如何全面、准确地评测这些产品的性能和用户体验，成为行业面临的重要挑战。传统评测方法依赖人工标注和简单指标，效率低下且难以覆盖复杂场景和多维度需求。尤其在AI算法快速迭代的背景下，传统方法已无法满足高效、精准的评测要求。为此，我们提出了一种基于大模型的综合智能评测方法，结合传统NLP/CV技术和大模型的强大能力，对内容质量、对话流畅度、安全性、自我认知等多维度进行全面评估，并对齐人工偏好。该方案不仅提升了评测效率，还显著增强了评测的全面性和准确性，为智能交互产品的优化提供了强有力的支持。
内容大纲
1. 垂类智能交互产品评测的现状与痛点
1.1 传统评测方法的局限性：评测需求承接落地+人工标注效率低、成本高；简单指标难以全面反映实际效果
1.2 评测面临的挑战：产品迭代、算法更新速度快，人力手工投入评测难以跟上节奏；垂类场景复杂，评测维度不足
2. 基于多模态大模型的评测方案
2.1 技术框架：基于大模型全链路提效的设计思路。
2.2 提效能力重点：评测集自动生成与评估；自动标注替代人工审核；badcase归因分析。
3. 支付宝垂类智能应用的评测实践
3.1 2B/2C垂类应用的自我认知：从输入扰动获取富有多样性的可靠生成：场景评测集的快速构建
3.2 AI产品的真机评测：自动采集+图像分割+目标检测+智能标注=高效双盲评审
听众收益
了解如何利用大模型+传统深度学习算法，解决智能交互产品评测中的效率与全面性问题。了解垂类产品多维度评估的方法论，快速应用于自身业务场景。
内容大纲
1. 垂类智能交互产品评测的现状与痛点
1.1 传统评测方法的局限性：评测需求承接落地+人工标注效率低、成本高；简单指标难以全面反映实际效果
1.2 评测面临的挑战：产品迭代、算法更新速度快，人力手工投入评测难以跟上节奏；垂类场景复杂，评测维度不足
2. 基于多模态大模型的评测方案
2.1 技术框架：基于大模型全链路提效的设计思路。
2.2 提效能力重点：评测集自动生成与评估；自动标注替代人工审核；badcase归因分析。
3. 支付宝垂类智能应用的评测实践
3.1 2B/2C垂类应用的自我认知：从输入扰动获取富有多样性的可靠生成：场景评测集的快速构建
3.2 AI产品的真机评测：自动采集+图像分割+目标检测+智能标注=高效双盲评审
听众收益
了解如何利用大模型+传统深度学习算法，解决智能交互产品评测中的效率与全面性问题。了解垂类产品多维度评估的方法论，快速应用于自身业务场景。
易龙
vivo 大数据专家
vivo 互联网，大数据专家，目前是 数据集成 团队负责人，以及高质量多模态数据项目技术负责人。硕士，毕业后曾就职于华为2012实验室 和腾讯，深耕数智化领域11年，交局12篇相关专利。
待定
待定
业务价值驱动有效构建高质量数据的方法和实践
在数字化时代，数据是企业核心资产，数据质量关乎企业生存发展，数据驱动决策成主流，但全链路数据质量问题是企业严峻挑战。
大数据、AI、云计算技术发展使数据量激增、类型复杂，市场竞争加剧让企业需精准数据分析，低质量数据会致决策错误、企业竞争力下降。
大模型时代，高质量数据是大模型训练的基石，也是行业场景化应用成功落地的关键。高质量数据不仅是技术竞争的“护城河”，更是推动社会智能化升级的战略资源。企业需以业务价值为导向，构建覆盖数据全生命周期的治理体系，同时借力政策与技术创新，实现从“数据成本”到“数据资产”的跃迁。未来，随着标准化、智能化技术的普及，高质量数据将加速赋能千行百业，成为人工智能持续突破的核心引擎。
实际在企业内部数据全链路生态系统中，因部门壁垒、技术差异、数据标准不统一等，数据常出现缺失、错误、不一致等质量问题，影响分析准确性、业务流程，带来业务损失。高质量数据的工作重要性虽有行业共识，但如何有效关联和支撑到业务价值却并非有广泛共识，另外，如何有效进行数据质量提升也是一个经常会困扰大家的问题，这导致很多企业投入了很多资源做数据质量相关工作的结果并不见效ROI不高，得不到更多的支持与认可。
本演讲题目旨在通过业务价值导向，建立业务价值和数据质量的映射，进行全链路数据质量提升，保障数据在各环节的稳定性和高质量，实现 “数据高质量→决策高精准→业务高收益” 的闭环。
内容大纲
1. 引言：新时代的数据挑战与破局
1.1 背景与痛点
1.2 破局思路
2. 理论框架：价值驱动数据质量提升 VDDQI(2-4-X)
2.1 框架介绍
2.2 落地建议
3. 关键方法与技术
3.1业务价值流与数据流剖析方法
3.2业务价值与数据质量映射引擎
3.3全链路数据质量提升方法
3.4价值验证方法
4. 业务场景实践案例
听众收益
1. 分享基于业务价值导向的思维方式，学会将数据质量提升与企业战略和业务目标紧密结合。
2. 分享从全链路视角出发，保障数据在各环节的稳定性和高质量，支撑企业战略决策和业务发展。
3. 熟练掌握提升数据质量的有效方法与实践技巧，能运用并解决实际工作中的复杂数据质量问题。
大数据、AI、云计算技术发展使数据量激增、类型复杂，市场竞争加剧让企业需精准数据分析，低质量数据会致决策错误、企业竞争力下降。
大模型时代，高质量数据是大模型训练的基石，也是行业场景化应用成功落地的关键。高质量数据不仅是技术竞争的“护城河”，更是推动社会智能化升级的战略资源。企业需以业务价值为导向，构建覆盖数据全生命周期的治理体系，同时借力政策与技术创新，实现从“数据成本”到“数据资产”的跃迁。未来，随着标准化、智能化技术的普及，高质量数据将加速赋能千行百业，成为人工智能持续突破的核心引擎。
实际在企业内部数据全链路生态系统中，因部门壁垒、技术差异、数据标准不统一等，数据常出现缺失、错误、不一致等质量问题，影响分析准确性、业务流程，带来业务损失。高质量数据的工作重要性虽有行业共识，但如何有效关联和支撑到业务价值却并非有广泛共识，另外，如何有效进行数据质量提升也是一个经常会困扰大家的问题，这导致很多企业投入了很多资源做数据质量相关工作的结果并不见效ROI不高，得不到更多的支持与认可。
本演讲题目旨在通过业务价值导向，建立业务价值和数据质量的映射，进行全链路数据质量提升，保障数据在各环节的稳定性和高质量，实现 “数据高质量→决策高精准→业务高收益” 的闭环。
内容大纲
1. 引言：新时代的数据挑战与破局
1.1 背景与痛点
1.2 破局思路
2. 理论框架：价值驱动数据质量提升 VDDQI(2-4-X)
2.1 框架介绍
2.2 落地建议
3. 关键方法与技术
3.1业务价值流与数据流剖析方法
3.2业务价值与数据质量映射引擎
3.3全链路数据质量提升方法
3.4价值验证方法
4. 业务场景实践案例
听众收益
1. 分享基于业务价值导向的思维方式，学会将数据质量提升与企业战略和业务目标紧密结合。
2. 分享从全链路视角出发，保障数据在各环节的稳定性和高质量，支撑企业战略决策和业务发展。
3. 熟练掌握提升数据质量的有效方法与实践技巧，能运用并解决实际工作中的复杂数据质量问题。
敬请期待
......
.....
待定
待定
敬请期待
....
关注QECon公众号
议题投稿
lijie@qecon.net
商务合作
151-2264-3988 木子
票务联系
135-2067-8913 郭梦媛
媒体合作
135-1619-6409 皮皮
添加QECon小助手，获取
会议最新资讯
购票咨询
13520678913 郭梦媛
