专场：生产级 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 进入真实代码仓库、如何留下证据、如何处理测试阻塞、如何避免改错范围，以及如何在缺陷数量变多后减少人工复盘压力。
李争鹏
群核科技 开发专家
10年互联网企业工程效率/稳定性领域工作经验，技术专家，长期工作在一线，专注于研发效能提升、敏捷与DevOps平台工程实践落地，目前聚焦 AI Native Dev、AI Coding 基础设施、研发工具链和 DevOps 服务治理。2026 H1 牵头推进公司级 AI Coding 工程化落地，覆盖 AI 编程工具选型、仓库级 AI 研发工作流、MCP / Skills 工具链、本地质量闭环、AI 代码评审治理、Code Agent 评测体系和研发效能数据分析。
待定
待定
生产级 AI Coding 实战：从个人提效到组织级交付闭环
议题背景：
AI Coding 在个人场景中已经证明了提效价值，但进入企业真实研发后，核心问题不再是“能否生成代码”，而是如何在真实仓库、真实流程和真实质量要求下稳定交付。我们在上半年推进公司级 AI Coding 落地时，重点建设了一套面向生产研发的工程底座：将需求澄清、任务边界、工程规范、项目上下文、质量检查、交付证据和效能度量纳入日常研发流程；同时通过 Harness Engineering，把本地启动、接口 / UI 测试、日志报告、失败修复和评测反馈组织成可执行闭环。实践中，AI 代码评审采纳率达到 70%+，核心工具调用量显著增长。分享将重点复盘从工具试用到组织级交付闭环的关键做法、踩坑经验和可复制路径。
AI Coding 在个人场景中已经证明了提效价值，但进入企业真实研发后，核心问题不再是“能否生成代码”，而是如何在真实仓库、真实流程和真实质量要求下稳定交付。我们在上半年推进公司级 AI Coding 落地时，重点建设了一套面向生产研发的工程底座：将需求澄清、任务边界、工程规范、项目上下文、质量检查、交付证据和效能度量纳入日常研发流程；同时通过 Harness Engineering，把本地启动、接口 / UI 测试、日志报告、失败修复和评测反馈组织成可执行闭环。实践中，AI 代码评审采纳率达到 70%+，核心工具调用量显著增长。分享将重点复盘从工具试用到组织级交付闭环的关键做法、踩坑经验和可复制路径。
内容大纲：
1. 从个人提效到生产交付：AI Coding 落地问题的变化
1.1 个人使用阶段的收益与局限
AI IDE、命令行 Agent、Chat 工具已经能显著提升个人编码效率，但“写得快”不等于“交付稳”。当工具分散、上下文分散、经验只停留在个人习惯中时，团队协作、Review 和质量保障都会遇到新的问题。
1.2 企业真实研发中的核心挑战
在真实仓库中，Agent 往往不了解工程规范、接口约定、测试方式和 Review 偏好；需求边界不清会导致大 diff、误改和返工；前后端、多仓库、需求系统、文档、MR、部署平台之间也会形成上下文断点。质量反馈如果仍然滞后在 CI、测试环境和人工 Review，Agent 很难快速迭代。
AI IDE、命令行 Agent、Chat 工具已经能显著提升个人编码效率，但“写得快”不等于“交付稳”。当工具分散、上下文分散、经验只停留在个人习惯中时，团队协作、Review 和质量保障都会遇到新的问题。
1.2 企业真实研发中的核心挑战
在真实仓库中，Agent 往往不了解工程规范、接口约定、测试方式和 Review 偏好；需求边界不清会导致大 diff、误改和返工；前后端、多仓库、需求系统、文档、MR、部署平台之间也会形成上下文断点。质量反馈如果仍然滞后在 CI、测试环境和人工 Review，Agent 很难快速迭代。
2. 仓库级 AI 研发工作流：让 Agent 按工程规则交付
2.1 把关键上下文沉淀到仓库
将目录结构、接口格式、错误处理、权限校验、测试命令等工程规范沉淀到仓库；将目标、范围、out-of-scope、验收标准、风险点等任务上下文前置；将关键决策、验证结果、交付证据和复盘材料纳入过程记录。
2.2 任务分层与流程控制
小问题快速处理，不引入重流程；普通需求先明确 PRD 和验收标准，再进入实现；复杂任务补充设计、实施计划、子任务拆分和风险控制；高质量模块引入 TDD 或强测试约束，先验证问题再修复。
2.3 实践踩坑
不要一开始就追求全自动，应先稳定任务边界和验证路径；仓库规范不能靠“理想化文档”，必须从真实代码和 Review 反馈中沉淀；流程过重会降低采用率，需要按任务复杂度分层。
将目录结构、接口格式、错误处理、权限校验、测试命令等工程规范沉淀到仓库；将目标、范围、out-of-scope、验收标准、风险点等任务上下文前置；将关键决策、验证结果、交付证据和复盘材料纳入过程记录。
2.2 任务分层与流程控制
小问题快速处理，不引入重流程；普通需求先明确 PRD 和验收标准，再进入实现；复杂任务补充设计、实施计划、子任务拆分和风险控制；高质量模块引入 TDD 或强测试约束，先验证问题再修复。
2.3 实践踩坑
不要一开始就追求全自动，应先稳定任务边界和验证路径；仓库规范不能靠“理想化文档”，必须从真实代码和 Review 反馈中沉淀；流程过重会降低采用率，需要按任务复杂度分层。
3. Harness Engineering：把质量反馈前置到 Agent 可执行的位置
3.1 环境、API 与 UI Harness 建设
明确依赖安装、启动命令、环境变量、端口和健康检查，让 Agent 不只知道怎么启动，也知道什么叫启动成功；复用已有接口测试和 UI 自动化能力，明确测试入口、测试数据、报告路径、截图、trace、video 等调试产物，避免重复建设测试体系。
3.2 反馈 Harness 与本地质量闭环
将日志、测试报告、失败用例和常见错误归因结构化，支持 Agent 基于失败结果继续定位、修复和重新验证。从“写完代码等人测”升级为“本地验证、读取反馈、自动修复、输出证据”。
3.3 企业交付链路适配
串联需求来源、设计文档、历史方案、业务术语和规范文档；将 MR、commit、Review comment、变更说明纳入交付过程；接入测试环境创建、服务部署、探活和回归结果；处理前后端分离、多仓库和跨系统任务中的上下文断点。
明确依赖安装、启动命令、环境变量、端口和健康检查，让 Agent 不只知道怎么启动，也知道什么叫启动成功；复用已有接口测试和 UI 自动化能力，明确测试入口、测试数据、报告路径、截图、trace、video 等调试产物，避免重复建设测试体系。
3.2 反馈 Harness 与本地质量闭环
将日志、测试报告、失败用例和常见错误归因结构化，支持 Agent 基于失败结果继续定位、修复和重新验证。从“写完代码等人测”升级为“本地验证、读取反馈、自动修复、输出证据”。
3.3 企业交付链路适配
串联需求来源、设计文档、历史方案、业务术语和规范文档；将 MR、commit、Review comment、变更说明纳入交付过程；接入测试环境创建、服务部署、探活和回归结果；处理前后端分离、多仓库和跨系统任务中的上下文断点。
4. 质量与效能度量：从试点推广到组织级复盘
4.1 质量与效能数据体系
围绕模型用量、Token、成本、用户覆盖、MCP / Skill 调用量、任务完成量、工具链渗透率建立度量体系；同时将 MR 创建 / 更新、构建、部署、单测、静态扫描等指标纳入统一分析。实践中，AI 代码评审采纳率达到 70%+，构建成功率提升 3 个百分点以上。
4.2 Code Agent 评测体系
基于真实 MR 构建私有评测集，使用需求描述作为 Agent 指令，在 base commit 上重新实现，以测试通过和行为正确性作为评分标准，而不是 diff 相似度。同时收集执行轨迹、Token 消耗、成本和失败类型，形成“数据 -> 评测 -> 优化”的闭环。
4.3 试点策略与组织级落地经验
先选 1 个仓库、2-3 位开发者、3-5 个真实任务，优先选择风险可控、能本地验证、Review 反馈明确的任务，避开第一轮就做跨系统大改、强发布依赖和测试基础薄弱的任务。先让 Agent 稳定理解仓库，再追求复杂任务自动化；先跑通本地验证闭环，再谈大规模自治；先建立交付证据和数据度量，再评估 ROI。
围绕模型用量、Token、成本、用户覆盖、MCP / Skill 调用量、任务完成量、工具链渗透率建立度量体系；同时将 MR 创建 / 更新、构建、部署、单测、静态扫描等指标纳入统一分析。实践中，AI 代码评审采纳率达到 70%+，构建成功率提升 3 个百分点以上。
4.2 Code Agent 评测体系
基于真实 MR 构建私有评测集，使用需求描述作为 Agent 指令，在 base commit 上重新实现，以测试通过和行为正确性作为评分标准，而不是 diff 相似度。同时收集执行轨迹、Token 消耗、成本和失败类型，形成“数据 -> 评测 -> 优化”的闭环。
4.3 试点策略与组织级落地经验
先选 1 个仓库、2-3 位开发者、3-5 个真实任务，优先选择风险可控、能本地验证、Review 反馈明确的任务，避开第一轮就做跨系统大改、强发布依赖和测试基础薄弱的任务。先让 Agent 稳定理解仓库，再追求复杂任务自动化；先跑通本地验证闭环，再谈大规模自治；先建立交付证据和数据度量，再评估 ROI。
听众收益：
1. 获得一套企业级 AI Coding 落地框架
1. 获得一套企业级 AI Coding 落地框架
听众可以了解如何从个人工具试用，推进到仓库级工作流、质量闭环、交付证据和效能度量，避免 AI Coding 停留在零散经验和个人技巧层面。
2. 掌握 Harness Engineering 的具体落地方法
分享会拆解本地启动、接口测试、UI 测试、日志报告、失败修复等 Harness 如何建设，以及如何让 Agent 从“生成代码”进一步变成“能验证、能修复、能交付”的研发协作者。
3. 获得可复用的试点与度量经验
听众可以参考我们的试点选择、任务分层、规范沉淀、评测集建设和数据指标设计，用更低风险的方式在自己的团队中推进 AI Coding，并用质量和效能数据判断真实收益。
刘焱
叮咚买菜 基础技术 研究员
前阿里本地生活资深架构师，技术风险部负责人，负责全站系统稳定性、 技术风险、后期负责核心基础设施团队，经历多次双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 从个人提效走向团队生产交付所需的工程能力，以及开发者角色的转变方向。
敬请期待
......
.....
待定
待定
敬请期待
....
关注QECon公众号
议题投稿
speaker@qecon.com.cn
商务合作
151-2264-3988 木子
票务联系
135-2067-8913 媛媛
媒体合作
135-1619-6409 皮皮
添加QECon小助手，获取
会议最新资讯
购票咨询
13520678913 媛媛
