专场：AI 质量管控：从左移到右移的全链路实践
随着AI编码工具的快速普及，生成代码已成为开发日常，但随之而来的幻觉、缺陷和安全隐患也越来越突出，传统的质量保证方式已明显跟不上节奏。 本专场探讨在AI时代，如何建立一套真正适配的全链路质量保障体系：从开发早期就做好针对AI代码的评审和幻觉检测，到引入适合AI原生应用的新型测试方法，再到利用智能工具加强安全扫描和生产阶段的持续监控，实现从左移预防到右移验证的完整闭环。结合当前行业面临的实际挑战与最新实践，分享如何在加快交付的同时，切实把控住代码质量和风险，帮助团队平稳完成向AI驱动开发的转型。
专场出品人：陈磊
前京东测试架构师
阿里云 MVP ，华为云 MVP 。著有图书《接口测试方法论》、《持续测试》、《大模型测试技术与实践》、《现代软件测试技术权威指南》、《软件研发效能权威指南》等。极客时间专栏《AI 重塑测试开发系统实践》、《接口测试入门课》作者、拉勾教育《软件测试第一课》作者。多年质量工程技术实践经验，专注于研发质量效能提升、智能化测试等方向，公开发表学术论文近30篇，专利20余篇，国内多个技术峰会的演讲嘉宾、出品人。
王美君
平安人寿保险 测试经理
5年以上金融保险行业研发与质量保障经验，毕业后在腾讯、华为、平安三家公司任职，当前在平安寿险质量部门担任测试分组经理。与工具团队共建集团级AI质量平台，协助推动AI智能化测试体系核心业务落地。擅长AI赋能测试体系搭建和落地、智能缺陷检测、研发效能提升。负责平安寿险AI代码静态扫描挖掘缺陷工具的设计和工程化落地，覆盖50+系统
待定
待定
基于业务的缺陷扫描测试左移实践
—— 从传统左移到 AI Agent 时代的业务逻辑缺陷预发现
议题背景：
AI编程普及后，开发产能大幅提升（从100-200行/人/天跃升至5000+行/人/天），测试产能面临巨大挑战。AI生成代码的缺陷密度是人工的2.3倍，传统代码评审聚焦语法规范层面，无法识别业务逻辑缺陷，传统的静态扫描工具和AI静态扫描准确率低漏报率高、且未与实际业务结合发现缺陷类型有限，实际研发流程中开发测试无精力逐个问题分析，质量风险高。
核心痛点：①传统扫描工具误报率高；②缺乏有效的结合业务的缺陷扫描工具；③测试阶段测试执行等动作介入太晚，错过早期质量把控窗口。
创新方向：融合代码上下文工程、Multi-Agent智能体编排、三层噪声过滤、历史缺陷知识库、测试用例推荐等技术，构建面向业务逻辑缺陷的AI缺陷挖掘体系，实现从传统左移到AI Agent时代的左移手段升级。
内容大纲：
1. 发现问题：AI时代质量与效率的挑战
AI编程普及后，开发产能大幅提升（从100-200行/人/天跃升至5000+行/人/天），测试产能面临巨大挑战。AI生成代码的缺陷密度是人工的2.3倍，传统代码评审聚焦语法规范层面，无法识别业务逻辑缺陷，传统的静态扫描工具和AI静态扫描准确率低漏报率高、且未与实际业务结合发现缺陷类型有限，实际研发流程中开发测试无精力逐个问题分析，质量风险高。
核心痛点：①传统扫描工具误报率高；②缺乏有效的结合业务的缺陷扫描工具；③测试阶段测试执行等动作介入太晚，错过早期质量把控窗口。
创新方向：融合代码上下文工程、Multi-Agent智能体编排、三层噪声过滤、历史缺陷知识库、测试用例推荐等技术，构建面向业务逻辑缺陷的AI缺陷挖掘体系，实现从传统左移到AI Agent时代的左移手段升级。
内容大纲：
1. 发现问题：AI时代质量与效率的挑战
1.1 缺陷发现越晚，修复成本呈指数级增长
1.2 传统开发自测手段难以覆盖复杂业务逻辑
1.3 AI时代核心矛盾从产能不足转向质量跟不上速度
1.4 测试左移四代演进，大模型开启新机遇
1.2 传统开发自测手段难以覆盖复杂业务逻辑
1.3 AI时代核心矛盾从产能不足转向质量跟不上速度
1.4 测试左移四代演进，大模型开启新机遇
2. 探索与解法：从传统左移到AI Agent的技术演进
2.1 踩坑分析，全量代码分析路径验证失败，
2.2 分类降级+噪声过滤突破瓶颈，召回率从15%提升至50%
2.3 从Demo验证到平台化，三步工程化落地路径
2.2 分类降级+噪声过滤突破瓶颈，召回率从15%提升至50%
2.3 从Demo验证到平台化，三步工程化落地路径
3. 最终方案设计：核心架构与关键技术方案
3.1 基于多源融合的业务缺陷预发现六层架构设计
3.2 代码上下文工程：AST解析、依赖分析、智能摘要
3.3 推荐调用树定位关键链路，三层噪声过滤累计屏蔽95%
3.4 ReAct智能体+有状态编排，反馈闭环驱动持续进化
3.5 历史缺陷库与测试用例推荐形成端到端闭环
3.2 代码上下文工程：AST解析、依赖分析、智能摘要
3.3 推荐调用树定位关键链路，三层噪声过滤累计屏蔽95%
3.4 ReAct智能体+有状态编排，反馈闭环驱动持续进化
3.5 历史缺陷库与测试用例推荐形成端到端闭环
4. 落地与成果：双轨交付实践与价值度量
4.1 独立系统与AI平台Skill双形态灵活落地
4.2 CI/CD流水线集成，实现缺陷提测前自动拦截
4.3 实践成果展示
4..4 商业价值量化：缺陷逃逸率下降、人工评审效率提升
4.2 CI/CD流水线集成，实现缺陷提测前自动拦截
4.3 实践成果展示
4..4 商业价值量化：缺陷逃逸率下降、人工评审效率提升
5. 未来规划
5.1 构建领域功能代码链路地图
5.2 实时变更影响链路推荐与智能修复
5.3 集团多业务线规模化推广
5.2 实时变更影响链路推荐与智能修复
5.3 集团多业务线规模化推广
听众收益：
1. 如何构建面向业务逻辑缺陷的AI静态扫描缺陷检测体系：
从架构设计、技术选型到工程化落地的完整实战经验，包括代码上下文工程、Multi-Agent编排、三层噪声过滤等核心技术方案。
2. AI质量保障从Demo到生产可用的关键跨越：
全量分析不可行的教训、踩过的坑（误报率80%→28%）、召回率从15%提升至50%的核心突破路径。
3. 历史缺陷知识库+测试用例推荐的落地方法：
如何让AI不仅发现新缺陷，还能防止旧缺陷复发，并通过智能用例推荐形成发现→验证→闭环的完整流程。
1. 如何构建面向业务逻辑缺陷的AI静态扫描缺陷检测体系：
从架构设计、技术选型到工程化落地的完整实战经验，包括代码上下文工程、Multi-Agent编排、三层噪声过滤等核心技术方案。
2. AI质量保障从Demo到生产可用的关键跨越：
全量分析不可行的教训、踩过的坑（误报率80%→28%）、召回率从15%提升至50%的核心突破路径。
3. 历史缺陷知识库+测试用例推荐的落地方法：
如何让AI不仅发现新缺陷，还能防止旧缺陷复发，并通过智能用例推荐形成发现→验证→闭环的完整流程。
胡延军
CMMI 研究院 中国特邀专家
CMMI研究院中国特邀专家、CMMI高成熟度评估师／讲师，AI-Native、AI4SE、IPD、Scrum、SAFe、DevOps、Six Sigma 领域资深专家。深耕精益与敏捷开发、项目与过程管理、产品与系统架构设计，精通 DevOps 体系搭建、质量与绩效管理优化、研发效能度量分析。拥有美国硅谷近十年工作经历，曾任 Angel Engineers Inc 高级副总裁、ACTEL 公司高级项目经理及工程师，主导并参与百余个大中型研发与交付项目，服务伟世通、中国人寿、中车集团、海康威视、京东方、潍柴动力、富士康、光大银行等数十家行业领军企业。
待定
待定
CMMI AIM 实践地图：AI 研发质量如何保障？
议题背景:
AI 正在把研发产出速度成倍提高，质量保障体系却没有同步升级，三道缺口随之出现：幻觉缺陷，AI 产出逻辑自洽但事实未必可靠，传统评审经验识别不出来；评审跟不上，产出量倍增而评审人力不变，评审从质量关口退化为走过场；责任边界模糊，AI 参与产出之后，缺陷归属与追溯链路断裂。
更深的缺口在组织侧：管理者说不清 AI 能力建设到了哪一步、还缺哪一块，工程师说不清自己手上的实践放进 AI 场景要改什么，两边讲不到同一件事上。本次分享的思考方向，是把零散的 AI 工具体验，转化为可定位、可评估、可演进的组织能力。
内容大纲:
1. 开场：AI 提速之后，质量链条断在哪一环
AI 正在把研发产出速度成倍提高，质量保障体系却没有同步升级，三道缺口随之出现：幻觉缺陷，AI 产出逻辑自洽但事实未必可靠，传统评审经验识别不出来；评审跟不上，产出量倍增而评审人力不变，评审从质量关口退化为走过场；责任边界模糊，AI 参与产出之后，缺陷归属与追溯链路断裂。
更深的缺口在组织侧：管理者说不清 AI 能力建设到了哪一步、还缺哪一块，工程师说不清自己手上的实践放进 AI 场景要改什么，两边讲不到同一件事上。本次分享的思考方向，是把零散的 AI 工具体验，转化为可定位、可评估、可演进的组织能力。
内容大纲:
1. 开场：AI 提速之后，质量链条断在哪一环
1.1 三个断点
1.2 一个共同缺口：组织缺少共同坐标
2. CMMI AIM 实践地图怎么读
2.1 从 CMMI 到 CMMI AIM
2.2 地图骨架 4 类别·12 能力域·31 实践域
2.3 用同行评审演示一次定位
2.4 AI 上下文专属信息（AI CS）的两层注入
2.5 AI 应用场景的四种形态
2.6 视图组合
2.7 评估范围界定五步法
3. 保障体系怎么搭
3.1 实施框架总图
3.2 技术抉择一：AI 增强与 AI 原生分场景并行，而不是二选一
3.3 技术抉择二：场景适配矩阵
3.4 度量支撑 DM+DQ+MPM
3.5 工程实践：四道质量门禁
3.6 踩过的坑（一）不分场景一刀切
3.7 踩过的坑（二）只改流程不落数据
3.8 踩过的坑（三）度量口径与考核挂钩
3.9 三阶段落地路线
4. 案例：同行评审从"人评人"到"人机共审"
4.1 为什么选 PR
4.2 PR 的实践要求与价值主张
4.3 形态一 AI 当评审助手
4.4 形态二 AI 产出作为被评审对象
4.5 形态三 AI 当评审者
4.6 人在环路模式的抉择
4.7 评审数据采集口径设计
4.8 改造前后对照：量化收益
5. 带走什么
5.1 落地检查单
5.2 度量指标清单
5.3 三个起步动作
听众收益：
1. 一张能对上自己团队现状的坐标。 听完可以把团队正在做的 AI 质量动作放到 CMMI AIM 地图上，判断当前缺的是评审环节、度量环节还是治理环节，而不是继续在工具层面反复试点；也能借助视图组合，判断几十人到几百人规模的组织该从哪里起步。
2. 一个完整可复制的改造样例。 同行评审从人评人走向人机共审的全过程，包含三种 AI 形态的适用判断、三种人在环路模式的选型依据、评审数据采集口径的设计方法，以及三类高频坑的规避方式。
3. 一份可直接使用的检查单与指标清单。 落地检查单可现场拍照带走，评审度量指标清单可用于设计本团队的度量口径；同时把"AI 评审出来的问题责任算谁的"讲清楚。
李明慧
bilibili 高级测试开发工程师
2024年加入哔哩哔哩，目前部担任Caster容器发布平台业务的测试负责人，涵盖容器发布、回滚、水平自动扩缩容、流量治理、服务注册等场景，保障发布链路稳定性。在测试过程中主动联动研发、产品和上下游组件方，推动问题闭环和机制优化。拥有独立搭建测试环境、验证复杂链路、风险识别与自动化建设能力。积极探索AI 在测试提效、稳定性治理等方面的应用。
待定
待定
流水线信息蒸馏和自愈
议题背景：
解决的问题：将流水线的测试信息从“噪声”变成“结论 + 归因 + 推送”。
核心痛点：
1. 流水线的测试失败信息分散且没有去重；
2. 原始内容噪声大、重复多、上下文不完整；
3. 研发和测试经常需要在多处来回切换才能确认“失败了什么、为什么失败、是不是持续失败、是否需要立即处理”。
思考的方向：不是单纯做告警通知，而是把“失败分析 + 自愈修复”做成一条工程链路：
解决的问题：将流水线的测试信息从“噪声”变成“结论 + 归因 + 推送”。
核心痛点：
1. 流水线的测试失败信息分散且没有去重；
2. 原始内容噪声大、重复多、上下文不完整；
3. 研发和测试经常需要在多处来回切换才能确认“失败了什么、为什么失败、是不是持续失败、是否需要立即处理”。
思考的方向：不是单纯做告警通知，而是把“失败分析 + 自愈修复”做成一条工程链路：
1）先保证信息稳定接入，再把报告加工成结构化结果；
2）进一步结合历史失败情况判断稳定性，结合AI进行失败分析；
3）最后决定是否推送、如何推送、是否可自动修复。核心目标是同时解决看不懂、找不全、重复吵、难复盘、修不动这几类问题。
基于以上背景，我们希望把失败报告接入统一处理链路，通过任务化、结构化蒸馏、稳定性判断、业务知识库和AI分类，把原始失败信息转成可直接行动的结论；对其中可规则化、可确认的失败，再进一步自动触发自愈与重试，减少人工排查和重复修复成本，并用 MySQL 沉淀任务、结果和推送状态，形成稳定、可追溯、可迭代的闭环。
内容大纲：
1. 背景与痛点：
2）进一步结合历史失败情况判断稳定性，结合AI进行失败分析；
3）最后决定是否推送、如何推送、是否可自动修复。核心目标是同时解决看不懂、找不全、重复吵、难复盘、修不动这几类问题。
基于以上背景，我们希望把失败报告接入统一处理链路，通过任务化、结构化蒸馏、稳定性判断、业务知识库和AI分类，把原始失败信息转成可直接行动的结论；对其中可规则化、可确认的失败，再进一步自动触发自愈与重试，减少人工排查和重复修复成本，并用 MySQL 沉淀任务、结果和推送状态，形成稳定、可追溯、可迭代的闭环。
内容大纲：
1. 背景与痛点：
1.1 流水线信息原始内容噪声大、重复多，无法获取核心关键信息；
1.2 测试人员需要手动定位失败信息和日志，确认为什么失败。
1.2 测试人员需要手动定位失败信息和日志，确认为什么失败。
2. 总体思路：把失败处理做成闭环
2.1 这套方案不是单点优化，而是围绕“接入—分析—决策—推送—自愈”五个环节做闭环设计；
2.2 入口上同时保留 webhook 和定时 scanner，两路互补，当webhook不工作时，scanner作为兜底；
2.3 处理上由 worker 统一消费任务，拉取 report/detail，抽取失败 case、断言、响应片段和步骤信息，再交给蒸馏模块做结构化整理；
2.4 决策上结合稳定性历史、业务知识库、规则分类和 AI 分类，判断这次失败属于“新问题、持续问题、偶发问题”还是“可自动修复问题”；
2.5 输出上分成两条线，一条是企业微信推送，另一条是自愈重试任务。这里 MySQL 不是简单存结果，而是承担任务队列、状态流转、结果沉淀和去重状态的中心角色，保证链路可追踪、可恢复、可重放。
2.2 入口上同时保留 webhook 和定时 scanner，两路互补，当webhook不工作时，scanner作为兜底；
2.3 处理上由 worker 统一消费任务，拉取 report/detail，抽取失败 case、断言、响应片段和步骤信息，再交给蒸馏模块做结构化整理；
2.4 决策上结合稳定性历史、业务知识库、规则分类和 AI 分类，判断这次失败属于“新问题、持续问题、偶发问题”还是“可自动修复问题”；
2.5 输出上分成两条线，一条是企业微信推送，另一条是自愈重试任务。这里 MySQL 不是简单存结果，而是承担任务队列、状态流转、结果沉淀和去重状态的中心角色，保证链路可追踪、可恢复、可重放。
3. 核心链路：从原始报告到可行动结论
3.1 第一步是接入与入队。系统收到测试失败通知后，会先做幂等校验，再把 report_id、plan_id、触发来源、通知策略等信息写入 MySQL 的任务表，避免同一失败被重复消费。
3.2 第二步是详情拉取与蒸馏。worker 会根据 report_id 拉取报告详情，识别失败 case，提取步骤、断言、请求响应、错误码等关键字段，并整理成统一的结构化结果。
3.3 第三步是分类与稳定性判断。系统会结合最近 N 次报告的历史失败情况，判断 case 是稳定失败、间歇失败还是新失败，同时把业务知识库、样本召回和规则分类一起用于归因。
3.4 第四步是推送和去重。只有满足通知条件的报告才会进入推送，且要和上次推送的失败集合做比较，避免相同失败在短时间内反复刷群。
3.5 第五步是自愈。对于明确的参数漂移、断言变化、请求结构变化等场景，系统会进入自愈流程，生成修复动作或重试任务，让一部分失败在机器侧先闭环。
3.2 第二步是详情拉取与蒸馏。worker 会根据 report_id 拉取报告详情，识别失败 case，提取步骤、断言、请求响应、错误码等关键字段，并整理成统一的结构化结果。
3.3 第三步是分类与稳定性判断。系统会结合最近 N 次报告的历史失败情况，判断 case 是稳定失败、间歇失败还是新失败，同时把业务知识库、样本召回和规则分类一起用于归因。
3.4 第四步是推送和去重。只有满足通知条件的报告才会进入推送，且要和上次推送的失败集合做比较，避免相同失败在短时间内反复刷群。
3.5 第五步是自愈。对于明确的参数漂移、断言变化、请求结构变化等场景，系统会进入自愈流程，生成修复动作或重试任务，让一部分失败在机器侧先闭环。
4. 技术抉择：为什么这样设计
4.1 服务采用容器化方式部署，保障了高可用、易扩缩、易重启、易观测。避免单点进程挂掉导致整条链路失效。
4.2 多处使用缓存：这个系统里很多信息是高频复用的，比如业务知识、分类结果、样本召回结果等；如果每次都实时查外部接口或重复计算，成本高且容易被短时抖动拖慢。缓存是为了降低外部依赖压力、减少LLM调用次数、提升链路稳定性。我们把“高频读、低频变”的内容前置下来，既减少接口调用次数，也降低 AI 分类和蒸馏链路的延迟。
4.3 为什么需要样本库，为什么用 BM25检索：样本库的作用不是“给 AI 凑上下文”，而是把历史上已经人工确认过的失败模式沉淀下来，作为分类和归因的参照系。没有样本库，AI 很容易只看当前 case 的表面特征，缺少业务语义和历史类比，分类会飘。BM25 的选择是因为它简单、可解释、稳定，适合在样本规模不算特别大、但需要快速做关键词和语义近似召回的场景里使用。它比纯手写规则更灵活，比直接上复杂向量检索更轻量，尤其适合这个项目里“先召回少量高相关样本，再交给 prompt 进一步判断”的工作方式。
4.4 为什么要用文件存储: 文件存储更适合放大一些、非强事务但需要持久化的对象数据，比如样本内容、历史归档、结构化结果快照或一些需要跨进程共享的 blob 数据。它和 MySQL 的分工是清楚的：MySQL 管索引、状态和查询主路径，文件存储 管较大的内容体和归档体。这样做可以避免把大 JSON、历史样本、反馈材料全压在 MySQL 里，保持主库表结构更轻，也方便后续做冷热分层和批量处理。
4.2 多处使用缓存：这个系统里很多信息是高频复用的，比如业务知识、分类结果、样本召回结果等；如果每次都实时查外部接口或重复计算，成本高且容易被短时抖动拖慢。缓存是为了降低外部依赖压力、减少LLM调用次数、提升链路稳定性。我们把“高频读、低频变”的内容前置下来，既减少接口调用次数，也降低 AI 分类和蒸馏链路的延迟。
4.3 为什么需要样本库，为什么用 BM25检索：样本库的作用不是“给 AI 凑上下文”，而是把历史上已经人工确认过的失败模式沉淀下来，作为分类和归因的参照系。没有样本库，AI 很容易只看当前 case 的表面特征，缺少业务语义和历史类比，分类会飘。BM25 的选择是因为它简单、可解释、稳定，适合在样本规模不算特别大、但需要快速做关键词和语义近似召回的场景里使用。它比纯手写规则更灵活，比直接上复杂向量检索更轻量，尤其适合这个项目里“先召回少量高相关样本，再交给 prompt 进一步判断”的工作方式。
4.4 为什么要用文件存储: 文件存储更适合放大一些、非强事务但需要持久化的对象数据，比如样本内容、历史归档、结构化结果快照或一些需要跨进程共享的 blob 数据。它和 MySQL 的分工是清楚的：MySQL 管索引、状态和查询主路径，文件存储 管较大的内容体和归档体。这样做可以避免把大 JSON、历史样本、反馈材料全压在 MySQL 里，保持主库表结构更轻，也方便后续做冷热分层和批量处理。
5. 工程实践：把“能跑”做成“长期能跑”
这套系统里有几个关键工程实践:
1) 第一是幂等设计，所有任务围绕 idempotency_key 建模，避免 webhook 重复投递、scanner 重复补入造成双重处理。
2) 第二是状态机设计，任务从 pending 到 processing，再到 done 或 failed，每一步都能回溯。
3) 第三是退避重试，短暂抖动不会让任务直接失败，而是按 next_run_at 延后重试。
4) 第四是推送去重，使用 last_notified 记录上次失败集合和时间窗口，既避免刷屏，也保留持续失败的再次提醒。
5) 第五是知识沉淀，业务知识库和 few-shot 样本池不是一次性配置，而是持续更新的，用户可以针对每次的AI分类进行反馈，反馈内容回流进样本库。
6) 第六是自愈分层，把“可自动修复”的问题单独识别出来，不和普通告警混在一起，保证修复动作不会污染主链路。
1) 第一是幂等设计，所有任务围绕 idempotency_key 建模，避免 webhook 重复投递、scanner 重复补入造成双重处理。
2) 第二是状态机设计，任务从 pending 到 processing，再到 done 或 failed，每一步都能回溯。
3) 第三是退避重试，短暂抖动不会让任务直接失败，而是按 next_run_at 延后重试。
4) 第四是推送去重，使用 last_notified 记录上次失败集合和时间窗口，既避免刷屏，也保留持续失败的再次提醒。
5) 第五是知识沉淀，业务知识库和 few-shot 样本池不是一次性配置，而是持续更新的，用户可以针对每次的AI分类进行反馈，反馈内容回流进样本库。
6) 第六是自愈分层，把“可自动修复”的问题单独识别出来，不和普通告警混在一起，保证修复动作不会污染主链路。
6. 总结与展望
6.1 实际效果总结：这套方案的价值不只是“自动发消息”，而是把失败处理变成了一条可持续演进的工程链路。
6.1.1 失败信息从原始通知变成了结构化结论，排查路径明显缩短，
6.1.2 推送去重，减少相同失败测试的内容通知，使重复噪声也得到了有效控制；
6.1.3 利用AI进行失败归因，使分类准确率相比规则分类有了明显提高，能够覆盖更多常见失败模式；
6.1.4 自愈能力则把部分可规则化、可确认的失败前移处理，减少了人工重复介入。
6.1.2 推送去重，减少相同失败测试的内容通知，使重复噪声也得到了有效控制；
6.1.3 利用AI进行失败归因，使分类准确率相比规则分类有了明显提高，能够覆盖更多常见失败模式；
6.1.4 自愈能力则把部分可规则化、可确认的失败前移处理，减少了人工重复介入。
6.2 未来规划：
6.2.1 继续扩展自愈能力，把目前已验证有效的规则化处理经验推广到更多失败类型和业务线；
6.2.2 持续完善业务知识库和样本库，提升 AI 分类的准确率和稳定性；
6.2.3 推动系统从单一工具演进为统一的平台能力，逐步承接更多测试和质量信号，形成更完整的分析、修复和度量闭环。
听众收益：
1. 获得一套可复用的测试失败治理思路：听众可以看到如何从“失败通知”升级到“接入、蒸馏、归因、推送、自愈、复盘”的完整链路，而不是只做一个告警机器人。对于已有自动化测试体系的团队，可以直接借鉴其中的任务化、幂等、去重、稳定性判断和失败分类设计。
2. 理解 AI 能力在工程系统中的落地边界：分享会重点讲为什么没有把失败归因完全交给大模型，而是采用“规则兜底 + 样本库 + BM25 召回 + AI 分类”的组合方案。听众可以获得一套更务实的 AI 工程化经验：哪些场景适合 AI 增强，哪些地方必须保留确定性逻辑，如何处理格式漂移、分类不稳定和业务知识缺失等问题。
3. 学习一个长期可运维系统的技术取舍：通过 K8s 容器化部署、MySQL 与 BOSS 的职责划分、多级缓存、自愈任务隔离、推送去重和可观测性建设，听众可以看到一个内部效率工具如何从脚本演进为长期运行的服务。这部分对有一定经验的技术同学更有价值，因为重点不是“功能怎么写”，而是“系统为什么这样设计、如何避免线上跑不稳”。
1. 获得一套可复用的测试失败治理思路：听众可以看到如何从“失败通知”升级到“接入、蒸馏、归因、推送、自愈、复盘”的完整链路，而不是只做一个告警机器人。对于已有自动化测试体系的团队，可以直接借鉴其中的任务化、幂等、去重、稳定性判断和失败分类设计。
2. 理解 AI 能力在工程系统中的落地边界：分享会重点讲为什么没有把失败归因完全交给大模型，而是采用“规则兜底 + 样本库 + BM25 召回 + AI 分类”的组合方案。听众可以获得一套更务实的 AI 工程化经验：哪些场景适合 AI 增强，哪些地方必须保留确定性逻辑，如何处理格式漂移、分类不稳定和业务知识缺失等问题。
3. 学习一个长期可运维系统的技术取舍：通过 K8s 容器化部署、MySQL 与 BOSS 的职责划分、多级缓存、自愈任务隔离、推送去重和可观测性建设，听众可以看到一个内部效率工具如何从脚本演进为长期运行的服务。这部分对有一定经验的技术同学更有价值，因为重点不是“功能怎么写”，而是“系统为什么这样设计、如何避免线上跑不稳”。
谢檬檬
百度 资深工程师
现负责百度 APP质量治理与技术体系建设，聚焦移动端复杂业务场景下的稳定性风险与用户体验保障，持续推动质量管理从单点监控向覆盖问题发现、影响评估、智能分析、根因定位、快速止损、值班协同和复盘进化的全链路体系演进。主导建设智能监控、故障定位、AI 值班及质量自进化等关键能力，探索将趋势数据、代码上下文、变更信息和协同过程统一纳入故障治理闭环。擅长大型质量平台架构、智能化策略设计、复杂系统工程落地和跨团队协作，致力于以工程能力与数据智能驱动质量治理持续进化，提升百度 APP 的可靠性、研发效率与用户体验。
待定
待定
AgentLoop 落地移动端：百度APP AI 全链路质量自进化体系构建
议题背景：
百度 APP 线上质量问题具有规模大、类型多、变化快、影响面广等特点，复杂的业务生态与高频交付节奏对全链路质量保障提出了极高要求。传统依赖人工经验的治理方式存在故障采集分散、定位效率不足、值班决策依赖个人、经验难以复用等痛点。本议题以 AgentLoop 为核心，建设 AI 值班驱动的全链路质量自进化体系：自动采集故障事实、代码上下文与处置轨迹，智能完成监控分析、根因定位、风险定级、止损决策和通告跟进；在故障闭环后基于可执行反馈自动反思，生成并验证策略、规则乃至代码级改进，通过测试、评估和可回滚机制持续迭代报警条件、报警策略、定位策略与处置流程，让管理系统能够“自我诊断、自我修改、自我验证”，实现从“发现问题”到“解决问题”，再到“系统自主提升治理能力”的真正闭环。
百度 APP 线上质量问题具有规模大、类型多、变化快、影响面广等特点，复杂的业务生态与高频交付节奏对全链路质量保障提出了极高要求。传统依赖人工经验的治理方式存在故障采集分散、定位效率不足、值班决策依赖个人、经验难以复用等痛点。本议题以 AgentLoop 为核心，建设 AI 值班驱动的全链路质量自进化体系：自动采集故障事实、代码上下文与处置轨迹，智能完成监控分析、根因定位、风险定级、止损决策和通告跟进；在故障闭环后基于可执行反馈自动反思，生成并验证策略、规则乃至代码级改进，通过测试、评估和可回滚机制持续迭代报警条件、报警策略、定位策略与处置流程，让管理系统能够“自我诊断、自我修改、自我验证”，实现从“发现问题”到“解决问题”，再到“系统自主提升治理能力”的真正闭环。
内容大纲：
1. 背景：移动端质量治理面临的新挑战
1.1 百度 APP 线上质量问题的复杂性
1.2 传统质量治理模式的核心痛点
1.3 需要解决的核心问题
1.2 传统质量治理模式的核心痛点
1.3 需要解决的核心问题
2. 总体方案：以 AgentLoop 构建质量自进化闭环
2.1 AgentLoop 的核心思想
2.2 自进化的定义
2.3 质量管控场景Loop系统的关键组成
2.2 自进化的定义
2.3 质量管控场景Loop系统的关键组成
3. AI 值班：从故障发现到问题闭环
3.1 故障事实自动采集
3.2 值班动作自主决策
3.3 AI 值班的工程实践与踩坑
3.2 值班动作自主决策
3.3 AI 值班的工程实践与踩坑
4. 智能定位：从初步结论到动态定位
4.1 为什么定位是全链路关键
4.2 workflow 和 react 双模引擎
4.3 智能定位中的工程实践与踩坑
4.2 workflow 和 react 双模引擎
4.3 智能定位中的工程实践与踩坑
5. 自动反思：从故障处理过程提炼治理经验
5.1 为什么不能只分析 Agent Trace
5.2 多源故障反思
5.2 多源故障反思
6. 系统进化：从经验沉淀到策略和代码自我修改
6.1 报警条件和报警策略进化
6.2 定位策略进化
6.3 值班流程进化
6.4 自进化的安全边界
6.2 定位策略进化
6.3 值班流程进化
6.4 自进化的安全边界
7. 进化评估：如何证明系统真的变好了
7.1 离线历史回放
7.2 在线灰度验证
7.3 评估指标
7.4 进化有效性的判断标准
7.2 在线灰度验证
7.3 评估指标
7.4 进化有效性的判断标准
8. 案例：一次故障如何推动系统能力升级
9. 总结：从处理故障到让系统从故障中学习
听众收益：
1. 获得一套可落地的 AI 质量治理方法论
理解如何以 AgentLoop 串联故障采集、智能定位、值班处置、自动反思和系统进化，构建从发现问题到持续优化的完整闭环。
2. 掌握复杂故障场景下的智能定位实践
了解 Workflow 与 ReAct 双模编排、群聊上下文采集、定位结论动态刷新，以及如何结合趋势、源码、CR 和变更单提升定位效率与准确性。
9. 总结：从处理故障到让系统从故障中学习
听众收益：
1. 获得一套可落地的 AI 质量治理方法论
理解如何以 AgentLoop 串联故障采集、智能定位、值班处置、自动反思和系统进化，构建从发现问题到持续优化的完整闭环。
2. 掌握复杂故障场景下的智能定位实践
了解 Workflow 与 ReAct 双模编排、群聊上下文采集、定位结论动态刷新，以及如何结合趋势、源码、CR 和变更单提升定位效率与准确性。
3. 了解 AI 系统自我进化的工程实现路径
学习如何将故障复盘转化为报警规则、定位策略、流程配置乃至代码改动，并通过历史回放、自动化测试、灰度发布和可回滚机制验证进化效果。
学习如何将故障复盘转化为报警规则、定位策略、流程配置乃至代码改动，并通过历史回放、自动化测试、灰度发布和可回滚机制验证进化效果。
庞可盈
中兴通讯 AI 研发工程师
AI 研发工程师，5 年以上 AI 工程化与代码质量领域经验。
现负责 AI 代码评审系统架构设计与持续演进，主导构建了覆盖 10 门语言、184 条规则 + 215 条检测器 的多引擎 AI 评审体系，支持多种引擎即插即用与横向对比。系统上线 12 个月，累计完成 30 万+ 次评审，覆盖 33 个团队、115 个仓库、2,526 名开发者，月活 1,480 人，峰值月评审量 5.2 万次，可用率 99.8%。同时构建了 checker 级数据驱动自演进闭环：通过补充 多 个 checker 的检测规则、优化上下文判断逻辑，将优化后规则的复现率降至 0%、准确率达到 100%，让 AI 评审从"能用"走向"审得准、可信赖"。
现负责 AI 代码评审系统架构设计与持续演进，主导构建了覆盖 10 门语言、184 条规则 + 215 条检测器 的多引擎 AI 评审体系，支持多种引擎即插即用与横向对比。系统上线 12 个月，累计完成 30 万+ 次评审，覆盖 33 个团队、115 个仓库、2,526 名开发者，月活 1,480 人，峰值月评审量 5.2 万次，可用率 99.8%。同时构建了 checker 级数据驱动自演进闭环：通过补充 多 个 checker 的检测规则、优化上下文判断逻辑，将优化后规则的复现率降至 0%、准确率达到 100%，让 AI 评审从"能用"走向"审得准、可信赖"。
待定
待定
规模化 AI 代码评审的质量保障实践：
10 语言、30 万次评审的工程之道
议题背景：
AI 代码评审的落地难点不在于"能不能审"，而在于规模化之后能不能让开发者信、让质量可控。我们的系统运行 12 个月，完成 30 万次评审，覆盖 33 个团队、2,526 名开发者——这背后不是简单接了一个模型，而是一整套让 AI 评审从"工具"变成"质量基础设施"的工程体系。
核心包括三件事：
AI 代码评审的落地难点不在于"能不能审"，而在于规模化之后能不能让开发者信、让质量可控。我们的系统运行 12 个月，完成 30 万次评审，覆盖 33 个团队、2,526 名开发者——这背后不是简单接了一个模型，而是一整套让 AI 评审从"工具"变成"质量基础设施"的工程体系。
核心包括三件事：
1）多引擎可插拔架构 + 10 语言 × 184 规则 × 215 Checker 的结构化规则体系，确保评审覆盖度而非依赖单一模型；
2）上百个标准评测用例 + Checker 级自演进闭环，新规则上线前必须通过评测、薄弱 Checker 自动识别定向优化，让准确率可量化、可追溯；
3） 从命令行到 Gerrit CI 门禁的全流程嵌入，让 AI 评审成为代码合入决策的一环而非可有可无的参考。
内容大纲：
1. 为什么 AI 评审是质量保障的必选项
内容大纲：
1. 为什么 AI 评审是质量保障的必选项
1.1 人工评审困境：覆盖不均、响应延迟、知识流失——33 个团队的共同痛点
1.2 AI 评审定位：不是替代人工，而是填补"没人审、审不全"的质量空白
1.3 核心判断：从"AI 能不能审"到"开发者用不用"——信任是质量保障的前提
1.2 AI 评审定位：不是替代人工，而是填补"没人审、审不全"的质量空白
1.3 核心判断：从"AI 能不能审"到"开发者用不用"——信任是质量保障的前提
2. 工程架构：构建可扩展的 AI 评审系统
2.1 多引擎可插拔架构：Skill Registry 统一注册，不同引擎一键切换，解决"绑定单一模型"风险
2.2 规则体系：Rule（审什么）→ Checker（怎么审）双层解耦，10 语言 × 184 规则 × 215 Checker × 6 大缺陷类别
2.3 Claude Code 插件生态集成：从命令行到 Gerrit CI 门禁自动触发——嵌入研发主流程
2.4 6 步标准化评审流水线：预备→同步规则→获取变更→拆分任务→并行评审→格式化报告，每步产物可审计
2.2 规则体系：Rule（审什么）→ Checker（怎么审）双层解耦，10 语言 × 184 规则 × 215 Checker × 6 大缺陷类别
2.3 Claude Code 插件生态集成：从命令行到 Gerrit CI 门禁自动触发——嵌入研发主流程
2.4 6 步标准化评审流水线：预备→同步规则→获取变更→拆分任务→并行评审→格式化报告，每步产物可审计
3. 让评审结果可信：质量保障的四个关键机制
3.1 事前拦截——标准化评测集：7 类 （Badcase 回归/Goodcase 检出/对抗样本/挑战/边界/业界基准/端到端），规则上线前必过评测
3.2 事中约束——上下文装配控制：调用链追溯深度取舍、评审范围刚性约束（变更行 ±0 行）、规则版本冲突自动检测
3.3 事后量化——反馈数据闭环：每条评审意见独立追踪开发者 Accept/Reject，按 Checker_id 聚合识别薄弱点
3.4 持续演进——Checker 级自优化：三板斧定向优化 + 评测集复验，降低Badcase复现率、提升评审准确率
3.2 事中约束——上下文装配控制：调用链追溯深度取舍、评审范围刚性约束（变更行 ±0 行）、规则版本冲突自动检测
3.3 事后量化——反馈数据闭环：每条评审意见独立追踪开发者 Accept/Reject，按 Checker_id 聚合识别薄弱点
3.4 持续演进——Checker 级自优化：三板斧定向优化 + 评测集复验，降低Badcase复现率、提升评审准确率
4. 工程踩坑：规模化落地的 5 个关键教训
4.1 规模化下的质量保障：多引擎横向对比 + 评测集复验，确保每次规则变更的质量基线不退化
4.2 规则膨胀陷阱：184 条规则的维护成本线性增长，分级管理（核心/推荐/实验）策略
4.3 上下文窗口博弈：AI 一次能看多少？多了失忆、少了漏报——按文件拆分 + 调用链按需追溯的平衡
4.4 多引擎适配代价：流程步数差异大（2~6 步），统一 skill_calls.json 协议避免 N×M 适配爆炸
4.2 规则膨胀陷阱：184 条规则的维护成本线性增长，分级管理（核心/推荐/实验）策略
4.3 上下文窗口博弈：AI 一次能看多少？多了失忆、少了漏报——按文件拆分 + 调用链按需追溯的平衡
4.4 多引擎适配代价：流程步数差异大（2~6 步），统一 skill_calls.json 协议避免 N×M 适配爆炸
5. 落地效果与演进方向
5.1 12 个月数据：303,101 次评审 / 2,526 开发者 / 33 团队
5.2 AI 评审的工程价值：填补人工评审空白、统一评审标准、沉淀团队代码规范知识
5.3 下一步：从"人触发评审"到"待办驱动 Agent"——自动感知变更、匹配规则、评审、人工确认闭环
5.2 AI 评审的工程价值：填补人工评审空白、统一评审标准、沉淀团队代码规范知识
5.3 下一步：从"人触发评审"到"待办驱动 Agent"——自动感知变更、匹配规则、评审、人工确认闭环
听众收益：
1. 获得一套规模化落地 AI 代码评审的工程架构参考不是"选个模型跑评审"的入门教程。包括：多引擎可插拔架构（Skill Registry 模式）、规则体系双层解耦（Rule → Checker）、6 步标准化评审流水线产物审计、插件生态下的 CI/CD 集成方案。可直接参考搭建自己的 AI 评审系统。
2. 掌握让 AI 评审被开发者信任的实战策略核心问题不是"AI 能不能审"，而是"审了开发者用不用"。分享信任建设机制：事前对抗样本 + 标准评测集拦截误报；事中上下文控制 + 范围约束防止 AI 跑偏；事后反馈数据闭环驱动 Checker 级精准优化。每个策略有数据和案例支撑。
3. 带走 3 个规模化落地 AI 评审的真实教训
1）规则越多越难维护：184 条规则的分级管理策略（核心/推荐/实验），避免成本失控
2）AI 一次看太多 → 失忆，看太少 → 漏报：按文件拆分 + 调用链按需追溯的粒度平衡
3）多引擎接入成本高：统一协议，每加一个引擎零适配
1. 获得一套规模化落地 AI 代码评审的工程架构参考不是"选个模型跑评审"的入门教程。包括：多引擎可插拔架构（Skill Registry 模式）、规则体系双层解耦（Rule → Checker）、6 步标准化评审流水线产物审计、插件生态下的 CI/CD 集成方案。可直接参考搭建自己的 AI 评审系统。
2. 掌握让 AI 评审被开发者信任的实战策略核心问题不是"AI 能不能审"，而是"审了开发者用不用"。分享信任建设机制：事前对抗样本 + 标准评测集拦截误报；事中上下文控制 + 范围约束防止 AI 跑偏；事后反馈数据闭环驱动 Checker 级精准优化。每个策略有数据和案例支撑。
3. 带走 3 个规模化落地 AI 评审的真实教训
1）规则越多越难维护：184 条规则的分级管理策略（核心/推荐/实验），避免成本失控
2）AI 一次看太多 → 失忆，看太少 → 漏报：按文件拆分 + 调用链按需追溯的粒度平衡
3）多引擎接入成本高：统一协议，每加一个引擎零适配
关注QECon公众号
关注QECon视频号
商务合作
151-2264-3988 木子
票务联系
159-0126-5561 小娟
媒体合作
135-1619-6409 皮皮
购票咨询
小娟 15901265561
