专场：生产级 AI Coding 实战：效率与质量的平衡术
......
专场出品人：
......
......
秦宙恺
群核科技 测试开发专家
三笠 群核科技 测试开发专家
群核科技全球数智测试组负责人，在群核科技任职11年，担任过多条业务线质量负责人，带领过四五个不同业务线的测试团队，涵盖主站、工具、koolab、国际化等业务。曾经负责上海分公司质量团队的组建工作，有过多个从零搭建质量效能体系的经验。从自动化能力建设、工具平台能力建设到性能领域都有深度实践。当前在公司AI转型领域有较多深度实践，为公司AI-testing团队负责人。
群核科技全球数智测试组负责人，在群核科技任职11年，担任过多条业务线质量负责人，带领过四五个不同业务线的测试团队，涵盖主站、工具、koolab、国际化等业务。曾经负责上海分公司质量团队的组建工作，有过多个从零搭建质量效能体系的经验。从自动化能力建设、工具平台能力建设到性能领域都有深度实践。当前在公司AI转型领域有较多深度实践，为公司AI-testing团队负责人。
待定
待定
从 0 到 1 做一个会修缺陷的 AI Agent：
快速试错、真实验证与持续改进
议题背景：
缺陷处理通常要靠人看问题描述、查需求、找代码、判断原因、修改代码、再验证结果，链路长，也很依赖个人经验。本项目从 2026 年 4 月开始探索，希望让 AI 不只是写一份缺陷分析报告，而是能真正进入日常缺陷处理流程：自动收集缺陷信息、需求背景、录屏和相关代码，尝试定位原因、创建修复分支、修改代码、运行验证，并把结果发布出来。随着处理的缺陷越来越多，项目又加入了自动复盘能力：系统会自己读取运行记录，总结当前共性问题，给出下一步改进建议，避免人每天逐条翻日志、看结果。44 天内累计沉淀 282 次可追踪迭代、80 次真实重跑验证和 498 个任务运行记录。AI 对问题原因的平均判断准确度约 88%，修复方案接近开发真实修复的程度约 75%
缺陷处理通常要靠人看问题描述、查需求、找代码、判断原因、修改代码、再验证结果，链路长，也很依赖个人经验。本项目从 2026 年 4 月开始探索，希望让 AI 不只是写一份缺陷分析报告，而是能真正进入日常缺陷处理流程：自动收集缺陷信息、需求背景、录屏和相关代码，尝试定位原因、创建修复分支、修改代码、运行验证，并把结果发布出来。随着处理的缺陷越来越多，项目又加入了自动复盘能力：系统会自己读取运行记录，总结当前共性问题，给出下一步改进建议，避免人每天逐条翻日志、看结果。44 天内累计沉淀 282 次可追踪迭代、80 次真实重跑验证和 498 个任务运行记录。AI 对问题原因的平均判断准确度约 88%，修复方案接近开发真实修复的程度约 75%
内容大纲：
1. 为什么要做一个“会修缺陷”的 AI 助手
1.1 真实缺陷处理并不只是“看一眼报错”：还要理解现象、需求、代码和修复影响
1.2 早期怎么快速跑通第一版：从手动分析缺陷，到自动写入文档记录
1.3 关键转变：从“AI 给修复建议”，变成“AI 进代码仓库尝试修改”
1.4 怎么判断 AI 真的做了事：不看口头回答，看代码分支、提交记录、验证结果和发布记录
2. 从 0 到 1 的快速迭代方法
2.1 先跑起来，再用真实缺陷不断修正：不要一开始追求大而全
2.2 缺陷信息不完整怎么办：让 AI 结合描述、评论、需求、录屏和代码一起判断
2.3 多个代码仓库相关怎么办：避免只看一个仓库导致误判
2.4 AI 改错地方怎么办：给每个缺陷准备独立工作目录，减少互相影响
2.5 测试跑不过怎么办：记录阻塞原因，但保留 AI 已经完成的修复分支，方便人工继续接手
3. 怎么证明这套东西不是 demo
3.1 事后复盘：等开发真正修完后，再对比 AI 当时判断得准不准
3.2 不只看代码像不像：分别判断“问题原因有没有说对”和“修复方案能不能替代”
3.3 证据不足不强行打分：没有开发修复代码、没有 AI 修复代码、或无法确认归属时，就标记为不可判断
3.4 历史缺陷重跑：同一个缺陷在新逻辑下重新跑一遍，看结果有没有真的变好
3.5 高风险操作先预览：涉及清记录、重跑、恢复现场时，先展示会做什么，再确认执行
4. 缺陷越来越多后，怎么避免人肉复盘失能
4.1 为什么需要自动复盘：缺陷、日志、重跑结果、复核结果越来越多，人很难每天逐条分析
4.2 系统会看哪些材料：运行记录、缺陷处理结果、验证结果、复核结果、重跑对比和发布记录
4.3 系统怎么总结共性问题：把单个失败归并成几类通用问题，比如本地环境没跑通、缺少复现信息、验证步骤失败、关键结果文件缺失、修复分支没有推送成功
4.4 从问题到建议：每类问题给出影响了哪些缺陷、代表样本、可能原因和下一步建议
4.5 人的角色怎么变化：从每天逐条翻结果，变成判断哪些问题最重要、哪些建议先做
4.6 真实样本：最近一次自动巡检读取 104 个真实产物，发现 146 个偏差，最终聚合成 14 类通用问题
5. 从“能跑”到“更接近真人处理缺陷”
5.1 把 AI 的每一步留下记录：它看了什么、判断了什么、改了什么、验证了什么
5.2 为什么普通构建通过不等于缺陷修好了：用户看到的问题可能还需要页面级、接口级或场景级验证
5.3 前端问题怎么验证：尝试用浏览器自动打开页面、模拟操作、检查结果
5.4 怎么防止 AI 改太多：要求它说明每个修改文件和当前缺陷的关系
5.5 当前边界：它已经能作为缺陷修复助手和自动交付工具，但还不能过早宣称完全替代人工
6. 过程中的具体踩坑和经验
6.1 不要只相信 AI 说“已修复”，要看真实代码和真实验证
6.2 不要做一套假的重跑流程，验证必须尽量复用真实流程
6.3 准确率最难的是“算哪些代码”，不是让模型写一段总结
6.4 快速迭代不能只靠感觉，要有每日问题记录和行动项
6.5 每次踩坑都要写回规则、测试和自动复盘逻辑，下一轮才会更稳
听众收益：
1. 了解一个 AI-Native 工程项目从 0 到 1 的真实落地过程：如何先跑通最小闭环，再靠真实缺陷、真实记录和真实重跑持续改进。
2. 学到一套判断 AI 是否真的有效的方法：不只看单次输出，而是通过事后复盘、历史重跑和自动问题总结，判断系统有没有稳定变好。
3. 带走可复用的工程经验：包括如何让 AI 进入真实代码仓库、如何留下证据、如何处理测试阻塞、如何避免改错范围，以及如何在缺陷数量变多后减少人工复盘压力。
刘焱
叮咚买菜 基础技术 研究员
前阿里本地生活资深架构师，技术风险部负责人，负责全站系统稳定性、 技术风险、后期负责核心基础设施团队，经历多次双11、全站搬迁、全链路压测等任务。
当前叮咚买菜基础技术研究员，为基础技术、IT基础设施、信息安全等领域负责人，负责全站系统稳定性、基础架构、中间件、数据库等，完成多云多活升级。近期接手Ai Coding下的质量体系建设。
待定
待定
叮咚买菜AI质量实践
议题背景：
叮咚买菜产品技术研发接近千人规模，在AI Coding/AI工程化的情况下，如何保障产品技术研发质量、发布效率、以及线上稳定性的一系列实践。
痛点：
1. AI coding对研发流程的冲击，code可读性、架构稳定性、代码复杂度等快速膨胀
2. Ai coding对组织形式的冲击，支持全栈化工程的基础能力缺失，导致AI coding提效迅速，需求吞吐进展缓慢
3. AI coding对系统架构的冲击， 应用场景Agent化需求快速增加，Agent infra基建没有及时跟上。
思路：
1. 研发流程和组织配合Ai Coding进展协同迭代：迭代过程中前端、测试、后端、研发、SRE等分别演进路径
2. 研发流程中不变部分重构：质量门禁和发布门禁。 技术难点：Agent长程任务稳定性、用户体验和Token用量优化、知识库构建和迭代、流水线支持“红军”链路等
3. 无自研大模型的中小研发团队的可靠性基建：通过构建Agent runtime，支持不同场景下的Agent运行范式完成Agent infra的建设。
内容大纲：
叮咚买菜AI质量实践概述
叮咚买菜千人规模研发团队在AI Coding与AI工程化浪潮下，面临研发流程、组织形式、系统架构三重冲击：代码复杂度与可读性问题快速膨胀、全栈化工程基础能力缺失导致需求吞吐进展缓慢、Agent化场景激增而基础设施滞后。团队以"流程协同迭代—不变部分重构—Agent基建补齐"三位一体路径破局：推动前端、测试、后端、研发、SRE等角色协同演进，重构质量门禁与发布门禁，并通过构建Agent runtime支撑不同场景下的Agent运行范式。过程中重点攻克Agent长程任务稳定性、用户体验与Token用量优化、知识库构建迭代、流水线"红军"链路等技术难点，为无自研大模型的中小研发团队提供了一套可复用的可靠性基建实践范式。
AI质量实践 | 叮咚买菜AI Coding下的研发质效保障
1. 背景与挑战
叮咚买菜产品技术研发接近千人规模，在AI Coding/AI工程化的情况下，如何保障产品技术研发质量、发布效率、以及线上稳定性的一系列实践。
痛点：
1. AI coding对研发流程的冲击，code可读性、架构稳定性、代码复杂度等快速膨胀
2. Ai coding对组织形式的冲击，支持全栈化工程的基础能力缺失，导致AI coding提效迅速，需求吞吐进展缓慢
3. AI coding对系统架构的冲击， 应用场景Agent化需求快速增加，Agent infra基建没有及时跟上。
思路：
1. 研发流程和组织配合Ai Coding进展协同迭代：迭代过程中前端、测试、后端、研发、SRE等分别演进路径
2. 研发流程中不变部分重构：质量门禁和发布门禁。 技术难点：Agent长程任务稳定性、用户体验和Token用量优化、知识库构建和迭代、流水线支持“红军”链路等
3. 无自研大模型的中小研发团队的可靠性基建：通过构建Agent runtime，支持不同场景下的Agent运行范式完成Agent infra的建设。
内容大纲：
叮咚买菜AI质量实践概述
叮咚买菜千人规模研发团队在AI Coding与AI工程化浪潮下，面临研发流程、组织形式、系统架构三重冲击：代码复杂度与可读性问题快速膨胀、全栈化工程基础能力缺失导致需求吞吐进展缓慢、Agent化场景激增而基础设施滞后。团队以"流程协同迭代—不变部分重构—Agent基建补齐"三位一体路径破局：推动前端、测试、后端、研发、SRE等角色协同演进，重构质量门禁与发布门禁，并通过构建Agent runtime支撑不同场景下的Agent运行范式。过程中重点攻克Agent长程任务稳定性、用户体验与Token用量优化、知识库构建迭代、流水线"红军"链路等技术难点，为无自研大模型的中小研发团队提供了一套可复用的可靠性基建实践范式。
AI质量实践 | 叮咚买菜AI Coding下的研发质效保障
1. 背景与挑战
1.1 叮咚买菜研发规模与AI工程化现状
1.1.1 千人规模研发团队的AI Coding背景（先实践再调整）
1.1.2 重新校准成本、效率、稳定性的目标（需求吞吐率、每token收益、冒烟率）
1.1.2 重新校准成本、效率、稳定性的目标（需求吞吐率、每token收益、冒烟率）
2. 三大痛点剖析（一）
2.1 AI Coding对研发流程的冲击
2.1.1 代码可读性、架构稳定性、代码复杂度快速膨胀
2.1.2 测试能力流失、线上验证能力流失
2.1.2 测试能力流失、线上验证能力流失
3. 三大痛点剖析（二）
3.1 AI Coding对组织形式的冲击
3.1.1 全栈化工程基础能力缺失
3.1.2 个体提效迅速但需求吞吐进展缓慢
3.1.2 个体提效迅速但需求吞吐进展缓慢
4. 三大痛点剖析（三）
4.1 AI Coding对系统架构的冲击
4.1.1 Agent化需求快速增加，但Infra基建未及时跟上
4.1.2 架构焦点从高并发转到长程任务
4.1.2 架构焦点从高并发转到长程任务
5. 解决思路总览
5.1 "流程协同—门禁重构—基建补齐"三位一体破局框架
6. 解决方案一：研发流程与组织协同迭代
6.1 多角色协同演进路径
6.1.1 前端、测试、后端、研发、SRE分别演进路径
7. 解决方案二：研发流程不变部分重构
7.1 质量门禁体系：测试数据构建、测试环境稳定性、流量回放能力、E2E AI测试能力等
7.2 发布门禁体系：校验清单、预案执行、变更分析等
7.2 发布门禁体系：校验清单、预案执行、变更分析等
8. 关键技术难点攻关（一）
8.1 Agent长程任务稳定性
8.2 用户体验与Token用量优化
8.2 用户体验与Token用量优化
9. 关键技术难点攻关（二）
9.1 知识库构建与迭代
9.2 流水线支持"红军"链路
9.2 流水线支持"红军"链路
10. 解决方案三：Agent infra建设
10.1 Agent runtime构建
- 支撑不同场景下的Agent运行范式
- 支撑不同场景下的Agent运行范式
11. 中小团队可靠性基建实践
11.1 无自研大模型团队的基建路径
- 对标行业Agent质量保障与评测体系
- 对标行业Agent质量保障与评测体系
12. 实践成效与价值
12.1 质量、效率、稳定性数据对比
13. 经验总结与未来展望
13.1 AI质效实践的核心原则总结
听众收益：
1. 跳出"AI出码率即提效"的认知误区，获得千人规模团队在AI Coding冲击研发流程、组织形式、系统架构三重挑战下的"流程协同—门禁重构—基建补齐"系统化破局方法，可直接作为制定本组织AI质效战略的参照系。
2. 拿到Agent长程任务稳定性、Token用量优化、知识库构建迭代、流水线"红军"链路等关键技术难点的工程化解法，以及质量门禁与发布门禁重构的可落地清单，缩短自身团队的踩坑周期。
3. 掌握一套不依赖自研大模型、通过构建Agent runtime支撑多场景Agent运行范式的可靠性基建路径，为中小研发团队提供经过实战验证、可直接对标的实践模板。
1. 跳出"AI出码率即提效"的认知误区，获得千人规模团队在AI Coding冲击研发流程、组织形式、系统架构三重挑战下的"流程协同—门禁重构—基建补齐"系统化破局方法，可直接作为制定本组织AI质效战略的参照系。
2. 拿到Agent长程任务稳定性、Token用量优化、知识库构建迭代、流水线"红军"链路等关键技术难点的工程化解法，以及质量门禁与发布门禁重构的可落地清单，缩短自身团队的踩坑周期。
3. 掌握一套不依赖自研大模型、通过构建Agent runtime支撑多场景Agent运行范式的可靠性基建路径，为中小研发团队提供经过实战验证、可直接对标的实践模板。
程娜
前程无忧 用户端测试负责人
前程无忧（51job）用户端测试负责人，负责用户端质量保障工作，长期参与复杂业务场景下的功能测试、数据验证和测试工程实践。
在埋点测试平台建设过程中，尝试将 Claude、Codex 等 AI Coding 工具应用于需求分析、方案设计、代码实现、测试补充和问题定位等研发环节。围绕 AI Coding 场景下出现的“假通过”问题，结合实际项目实践，逐步沉淀出一套以规则定义、独立审查和真实数据验证为核心的行之有效的质量保障模型和落地实践。
擅长复杂业务场景下的测试设计、埋点数据验证以及研发协作过程中的质量风险识别与防控，持续探索 AI 工具在测试工程和质量保障领域的应用实践。
在埋点测试平台建设过程中，尝试将 Claude、Codex 等 AI Coding 工具应用于需求分析、方案设计、代码实现、测试补充和问题定位等研发环节。围绕 AI Coding 场景下出现的“假通过”问题，结合实际项目实践，逐步沉淀出一套以规则定义、独立审查和真实数据验证为核心的行之有效的质量保障模型和落地实践。
擅长复杂业务场景下的测试设计、埋点数据验证以及研发协作过程中的质量风险识别与防控，持续探索 AI 工具在测试工程和质量保障领域的应用实践。
待定
待定
从代码生成到可信交付：AI Coding“假通过”的识别与防控实践
议题背景：
在复杂业务系统建设过程中，AI Coding 开始逐步融入研发流程，改变了部分研发工作的协作方式。但随着 AI 深度参与研发流程，一个新的问题也逐渐显现：代码实现速度提升后，如何保证业务结果真正正确。
我司在建设埋点测试平台的过程中，尝试将 Claude、Codex 等 AI Coding 工具应用于需求分析、方案设计、代码实现、测试补充和问题修复等环节。经过约 8 周、238 次提交，平台功能逐步完善，但同时也暴露出新的质量挑战：修复类提交占比超过四成。
在复杂业务系统建设过程中，AI Coding 开始逐步融入研发流程，改变了部分研发工作的协作方式。但随着 AI 深度参与研发流程，一个新的问题也逐渐显现：代码实现速度提升后，如何保证业务结果真正正确。
我司在建设埋点测试平台的过程中，尝试将 Claude、Codex 等 AI Coding 工具应用于需求分析、方案设计、代码实现、测试补充和问题修复等环节。经过约 8 周、238 次提交，平台功能逐步完善，但同时也暴露出新的质量挑战：修复类提交占比超过四成。
这些问题并不是代码无法运行，而更多表现为“假通过（False Pass）”：系统没有报错，流程也显示成功，但由于业务规则理解、查询边界或数据验证不足，最终输出的业务结论可能并不正确，甚至验证体系自身也可能失效。
这让我意识到，AI Coding 带来的变化不仅是开发方式变化，更要重新思考如何定义正确、验证正确，并将问题沉淀为长期可复用的工程能力。
本次分享将结合埋点测试平台建设实践，复盘“假通过”的产生原因，并介绍一套经过实战验证的质量保障方法：规则定义 → 独立审查 → 真实验证 → 经验沉淀，让 AI Coding 从代码生成走向可信交付。
内容大纲：
1. 真实风险：AICoding 时代，“正确”正在变得难以证明
1.1 提效之后，验证成为新的主要投入
约 1个多月建成埋点测试平台，AI 参与需求分析、方案设计、编码、测试、修复全流程，实现效率显著提升；
但 238 次提交中，修复类 98 次、新功能 58 次，比例约 1.7 : 1，其余为重构、测试与文档。四成以上的提交用于修复问题；
关键不在数量，而在性质：多数问题并非无法运行，而是运行正常、结果错误。AI 报告任务已通过，实际并没有。
但 238 次提交中，修复类 98 次、新功能 58 次，比例约 1.7 : 1，其余为重构、测试与文档。四成以上的提交用于修复问题；
关键不在数量，而在性质：多数问题并非无法运行，而是运行正常、结果错误。AI 报告任务已通过，实际并没有。
1.2 两个典型案例：错误如何隐藏在“成功”里
案例一「查询范围静默失控」：点位 ID 解析缺陷导致查询条件被解析为空，SQL 无任何过滤、静默查询全量数据。发现问题时，整份验收报告 81.3% 的通过率已整体存疑，平台的核心产出险些作废；
案例二「验证体系自身的假通过」：一次改动中，重名测试类静默覆盖了 9 个既有测试，这些测试从未运行，AI 却仍然汇报测试全部通过。用于兜底的验证体系，自身先失效了。
案例二「验证体系自身的假通过」：一次改动中，重名测试类静默覆盖了 9 个既有测试，这些测试从未运行，AI 却仍然汇报测试全部通过。用于兜底的验证体系，自身先失效了。
1.3 为什么“假通过”比报错更危险：问题的复杂性
它不抛异常、没有错误日志、监控无法感知。埋点验收需要同时满足事件、属性、终端、业务线、时间窗口等多维业务规则，任何一处偏差都可能产生一个看似合理的错误结果；
AI 的自证倾向：实现者与验证者是同一条推理链，会持续强化自身的假设；
实现速度越快，错误结论的产出也越快，提效反而放大了验证缺口。
AI 的自证倾向：实现者与验证者是同一条推理链，会持续强化自身的假设；
实现速度越快，错误结论的产出也越快，提效反而放大了验证缺口。
2. 破解“假通过”：从单点修复到系统化防控的四轮演进
2.1 第一轮：人工复查与 AI 自查，很快失效
让 AI 自查，它会用同样的假设再“证明”一遍自己是对的；
人工逐条核对数据，等于退回建平台之前的原点；
结论：同一推理链内部，发现不了自身的假设错误。
人工逐条核对数据，等于退回建平台之前的原点；
结论：同一推理链内部，发现不了自身的假设错误。
2.2 第二轮：实现与审查分离，双 AI 独立审查
一个 AI 负责实现，另一个独立的 AI 专职对抗性审查：提出反例、挑战边界、补充测试，由人做最终判断；
实际效果：一次交叉审查揪出 2 个 P1 缺陷，起因是同编号事件被不同事件复用，导致报告卡片误合并、编辑器深链绑到错误事件，顺藤排查出 7 处同类隐患；
新的要求：审查方的结论同样需要先验证再采信，否则只是增加了一个假通过来源。独立审查成立的前提是证据。
实际效果：一次交叉审查揪出 2 个 P1 缺陷，起因是同编号事件被不同事件复用，导致报告卡片误合并、编辑器深链绑到错误事件，顺藤排查出 7 处同类隐患；
新的要求：审查方的结论同样需要先验证再采信，否则只是增加了一个假通过来源。独立审查成立的前提是证据。
2.3 第三轮：以真实运行结果为最终依据
审查代码并不足够，必须用真实数据运行验证。前后端各有一套解析逻辑，通过基准用例与跨端一致性校验，要求两套实现对同一批真实数据输出一致的结果；
主动构造错误场景（错误事件、缺失属性、越界数据、跨端/跨业务线数据），验证系统“该失败时真的会失败”；
以「静默查全量」为例的完整闭环：实测发现 → 统一解析规则并加安全网告警 → 单测 / 一致性校验 / e2e 回归全绿 → 回查全部已执行用例，确认历史验收结论未被污染（修复只是起点，证明“修对了、且没伤到过去”才是终点）。
主动构造错误场景（错误事件、缺失属性、越界数据、跨端/跨业务线数据），验证系统“该失败时真的会失败”；
以「静默查全量」为例的完整闭环：实测发现 → 统一解析规则并加安全网告警 → 单测 / 一致性校验 / e2e 回归全绿 → 回查全部已执行用例，确认历史验收结论未被污染（修复只是起点，证明“修对了、且没伤到过去”才是终点）。
2.4 第四轮：把每个问题变成资产，防复发体系
每个假通过问题固化为：e2e 回归用例、项目记忆、验收口径、AI 协作规范；
项目记忆随代码仓库版本化管理，更换环境或模型均不丢失，AI 下次介入时自动携带历史问题的上下文；
不能仅解决当前问题，需要通过方法沉淀，降低同类问题的复发概率。
项目记忆随代码仓库版本化管理，更换环境或模型均不丢失，AI 下次介入时自动携带历史问题的上下文；
不能仅解决当前问题，需要通过方法沉淀，降低同类问题的复发概率。
3. 方法沉淀：一套可复制的 AI Coding 可信交付框架
把四轮实践提炼为“可信交付四层防线”：
3.1 规则层：从 Prompt 驱动到规则驱动
3.1 规则层：从 Prompt 驱动到规则驱动
在编码之前先定义什么是正确：业务规则、验收标准、边界约束是 AI 输出稳定性的上限，规则越清晰，验证成本越低。
3.2 对抗层：从自证到他证
实现与审查使用独立推理链互相约束，任何一方的结论都必须过证据关，避免同一推理过程自我强化。
3.3 实证层：从模型结论到 Ground Truth
验收依据只能来自真实数据、真实运行与真实日志；错误场景与正常场景具有同等的验证权重。
3.4 资产层：从个人经验到组织记忆
规则、用例、记忆、规范持续沉淀，让验证能力可积累、可迁移、可复用。
该框架不绑定任何特定模型或工具：模型会过时，验证体系不会。
该框架不绑定任何特定模型或工具：模型会过时，验证体系不会。
4. 行业价值：当代码不再稀缺，“信任”成为新的交付物
4.1 AI Coding 的最后一公里不是生成，而是证明
从 80% 演示效果到 100% 生产可用，差的不是更强的模型，而是一套让结果可被验证的工程能力。
4.2 质量工程的重心迁移：从“发现缺陷”到“构建信任”
验证体系正在成为 AI 时代研发的核心基础设施：生成能力决定研发速度，验证体系决定是否敢于交付生产。
4.3 开发者角色重定义：从代码生产者到交付可信度的交付者
业务理解、问题拆解、AI 协作、质量判断，是不会被模型迭代淘汰的核心能力。
4.4 团队落地路径：先建验证体系，再放大生成能力
团队级 AI Coding 落地的合理顺序，是先建立统一的验证体系与业务上下文，再扩大生成规模。
听众收益：
1.识别复杂业务场景下 AI Coding“假通过”的典型模式，避开“系统正常运行 = 结果正确”的认知陷阱；
2.获得一套经 238 次提交、多个真实案例检验的防控方法：规则定义 → 独立审查 → 真实验证 → 资产沉淀，可直接迁移到自己的项目；
3.理解 AI Coding 从个人提效走向团队生产交付所需的工程能力，以及开发者角色的转变方向。
1.识别复杂业务场景下 AI Coding“假通过”的典型模式，避开“系统正常运行 = 结果正确”的认知陷阱；
2.获得一套经 238 次提交、多个真实案例检验的防控方法：规则定义 → 独立审查 → 真实验证 → 资产沉淀，可直接迁移到自己的项目；
3.理解 AI Coding 从个人提效走向团队生产交付所需的工程能力，以及开发者角色的转变方向。
郭梦茹
腾讯音乐 高级测试开发工程师
QQ音乐研发效能中心专项测试开发组高级测试开发工程师，主要负责QQ音乐、全民k歌等业务线下全部APP的性能专项测试保障体系建设、包括标准制定，大型、创新型项目的性能质量保障工作；同时主导CICD、AI代码漏洞挖掘专项工作。
待定
待定
双引擎驱动 + 调用链穿透：AI时代代码问题挖掘的规模化落地实践
议题背景：
AI Coding 时代代码产出效率飙升，但内存泄漏、crash、跨模块异常等深层逻辑缺陷仍高度依赖资深专家人工Review，传统Lint规则仅覆盖表层规范，漏报率超60%；且单次扫描动辄数百条告警，误报率超30%，人工二次分析成本居高不下。我们系统性建设了静态代码问题挖掘与质量左移工具链，核心创新在于：
AI Coding 时代代码产出效率飙升，但内存泄漏、crash、跨模块异常等深层逻辑缺陷仍高度依赖资深专家人工Review，传统Lint规则仅覆盖表层规范，漏报率超60%；且单次扫描动辄数百条告警，误报率超30%，人工二次分析成本居高不下。我们系统性建设了静态代码问题挖掘与质量左移工具链，核心创新在于：
① 双引擎融合检测——CI阶段传统Lint快速拦截规范问题，转测阶段AI智能检测覆盖隐式逻辑缺陷；
② 代码调用链图谱——突破单文件局限，精准追踪跨模块异常传播路径；
③ 误报分析自闭环Agent——实现“检测-分析-沉淀-优化”自动化循环。该体系各业务常态化运行，单季度累计发现有效问题2500+例，前置发现率从6%提升至20%+，沉淀规则1000余条、Agent及Skill 10余个，并提交相关专利7篇
内容大纲：
1. 困境：传统Lint为什么“管得了格式，管不住质量”
内容大纲：
1. 困境：传统Lint为什么“管得了格式，管不住质量”
1.1 AI生成代码带来的深层隐患：内存泄漏、crash、并发竞争等依赖上下文分析的缺陷占比激增
1.2 传统Lint的“三座大山”：规则覆盖不全、误报率高、跨文件分析能力缺失
1.3 目标设定：将静态问题前置发现率从个位数提升至20%以上，同时压降人工二次分析成本
1.2 传统Lint的“三座大山”：规则覆盖不全、误报率高、跨文件分析能力缺失
1.3 目标设定：将静态问题前置发现率从个位数提升至20%以上，同时压降人工二次分析成本
2. 破局：双引擎融合检测体系的设计与演进
2.1 整体架构：CI/CD流水线嵌入传统Lint（合入前自动拦截）+ 转测阶段AI智能检测（深度隐式问题挖掘）的分层策略
2.2 规则分层治理：SwiftLint/FindBugs等传统规则的场景化裁剪与阈值调优，降低基础误报
2.3 AI规则引擎：基于大模型的代码语义理解，覆盖传统工具无法检出的复杂逻辑缺陷
2.2 规则分层治理：SwiftLint/FindBugs等传统规则的场景化裁剪与阈值调优，降低基础误报
2.3 AI规则引擎：基于大模型的代码语义理解，覆盖传统工具无法检出的复杂逻辑缺陷
3. 核心突破：代码调用链图谱的构建与上下文穿透分析
3.1 调用链自动生成：基于代码提交diff，动态构建函数级调用关系图谱的技术实现
3.2 AICR（AI Code Review）增强：将完整调用链路作为上下文注入检测模型，实现跨模块异常传播路径的精准追踪
3.3 实战效果量化：跨文件缺陷检出率提升的具体倍数/百分比，以某次内存泄漏跨三层调用被成功捕获为例
3.2 AICR（AI Code Review）增强：将完整调用链路作为上下文注入检测模型，实现跨模块异常传播路径的精准追踪
3.3 实战效果量化：跨文件缺陷检出率提升的具体倍数/百分比，以某次内存泄漏跨三层调用被成功捕获为例
4. 闭环：误报分析Agent与规则自沉淀机制
4.1 痛点：AI检测引入新误报，人工二次分析成本如何可控？
4.2 误报自动分析Agent：如何自动研判告警真实性、生成误报知识库
4.3 规则缺陷单自动闭环：从“发现问题→分析误报→沉淀规则→规则自动更新”的全链路自动化
4.4 踩坑实录：Agent“自我循环”导致的规则退化问题及应对策略（引入人工抽检Guard机制）
4.2 误报自动分析Agent：如何自动研判告警真实性、生成误报知识库
4.3 规则缺陷单自动闭环：从“发现问题→分析误报→沉淀规则→规则自动更新”的全链路自动化
4.4 踩坑实录：Agent“自我循环”导致的规则退化问题及应对策略（引入人工抽检Guard机制）
5. 规模化落地：从单点到全端、从工具到能力矩阵
5.1 能力横向扩展：需求完整度检测、UI异常检测、上报异常检测、双端实现不一致检测等衍生工具的共建模式
5.2 多端覆盖实战：Android（自定义Gradle插件）、iOS（Xcode插件化）、Web（ESLint增强）、后台（SpotBugs扩展）的技术适配差异与统一接入层设计
5.3 核心量化成果：接入Q1累计有效问题2000+例，前置发现率6%→20%+，沉淀规则500+条，Agent/Skill 10+个，专利7篇
5.2 多端覆盖实战：Android（自定义Gradle插件）、iOS（Xcode插件化）、Web（ESLint增强）、后台（SpotBugs扩展）的技术适配差异与统一接入层设计
5.3 核心量化成果：接入Q1累计有效问题2000+例，前置发现率6%→20%+，沉淀规则500+条，Agent/Skill 10+个，专利7篇
6. 未来展望：从“辅助发现”到“自动修复”
6.1 当前瓶颈：AI修复准确率不足、修复引入新Bug的风险
6.2 探索方向：基于调用链的精准修复补丁生成 + 修复后自动化回归验证
6.2 探索方向：基于调用链的精准修复补丁生成 + 修复后自动化回归验证
听众收益：
1. 一套可直接复用的“双引擎检测+调用链分析”架构方案：了解如何在不推翻现有Lint体系的前提下，引入AI能力实现检测深度跃升，并获得跨文件上下文分析的落地实现细节，可用于自身团队的代码质量左移建设。
2. 误报治理的“自闭环”实战经验：学习如何通过Agent自动化处理AI引入的新误报问题，形成规则自沉淀的正向循环，避免“上了AI反而增加人工成本”的尴尬局面，并收获实际踩坑（如规则退化）的应对策略。
3. 规模化推广的“避坑指南”：了解在多端（Android/iOS/Web/后台）、多业务（Q音/K歌/JOOX/Wesing）场景下统一接入层的设计取舍与技术适配差异，为跨团队、跨技术栈推广提供真实参考。
1. 一套可直接复用的“双引擎检测+调用链分析”架构方案：了解如何在不推翻现有Lint体系的前提下，引入AI能力实现检测深度跃升，并获得跨文件上下文分析的落地实现细节，可用于自身团队的代码质量左移建设。
2. 误报治理的“自闭环”实战经验：学习如何通过Agent自动化处理AI引入的新误报问题，形成规则自沉淀的正向循环，避免“上了AI反而增加人工成本”的尴尬局面，并收获实际踩坑（如规则退化）的应对策略。
3. 规模化推广的“避坑指南”：了解在多端（Android/iOS/Web/后台）、多业务（Q音/K歌/JOOX/Wesing）场景下统一接入层的设计取舍与技术适配差异，为跨团队、跨技术栈推广提供真实参考。
敬请期待
......
.....
待定
待定
敬请期待
....
关注QECon公众号
议题投稿
speaker@qecon.com.cn
商务合作
151-2264-3988 木子
票务联系
135-2067-8913 媛媛
媒体合作
135-1619-6409 皮皮
添加QECon小助手，获取
会议最新资讯
购票咨询
13520678913 媛媛
