朱少民
《软件工程 3.0》作者/CCF 杰出会员/AiDD 技术委员会成员
📖 背景介绍:
AI Coding 的采采已在多数研发组织成为常态,代码产出量在数月内陡增。但企业近半年最真实的焦虑并非"AI 写得好不好",而是"我们还能不能验证它"。行业反复出现一个结构性错位:开发者对 AI 代码的准确性信任并不高(公开调研中信任率长期徘徊在约 29% 量级),却因效率压力而持续采用,形成"高采用、低信任"的张力。与此同时,AI 生成的代码体量把传统评审推到了吞吐极限——Review 数量膨胀、人工评审成为新瓶颈,而"verification gap(验证缺口 / 信任缺口)"导致的线上事故开始显性化。传统的质量门禁(行覆盖率、静态扫描)对 AI 代码部分失灵:测试可能"通过"却测不到语义,覆盖率可能"满分"却全靠空断言。因此,如何重建面向 AI 代码的评审形态、质量门禁与责任追溯机制,已成为企业从"用上 AI"走向"用稳 AI"的分水岭。
💬 关键讨论问题:
1.评审对象变了,评审形态该怎么变? 当多数代码由 AI 生成,Review 的粒度、节奏与责任主体应如何重新设计?"AI 审 AI、人审关键"的边界划在哪里,人是否还有能力审?
2.传统质量门禁是否已经失效? 覆盖率、静态检查对 AI 代码为何部分失灵?我们需要什么样的"新门禁"——例如 AI 贡献溯源、验证证据强制、变更风险分级准入?
3.责任归属与可追溯如何建立? 一旦 AI 生成的代码引发生产事故,"谁负责"如何回答?组织是否需要为每一处 AI 变更建立可审计的"来源—依据—验证"证据链?
4.如何度量 AI 代码质量,而不掉进覆盖率的假象? 除覆盖率外,应引入哪些更能反映真实缺陷发现能力的指标(如变异评分、Oracle 强度、语义覆盖)?谁来对这些指标负责?
5.验证能力如何跟上生成速度? 是否应设立专门的"验证工程 / 质量门禁工程"职能?它与测试、平台、DevOps 团队的边界与协作如何界定?
同济大学特聘教授、CCF杰出会员、全国计算机科学技术名词编委。近三十年来一直从事软件工程的教学与研究工作,先后获得多项省、部级科技进步奖,已出版了二十多部著作和5本译作,代表作主要有《软件工程3.0》、《智能软件工程》、《大模型驱动软件测试》、《软件测试方法和技术》、《全程软件测试》、《软件质量保证与管理》等。曾任思科(中国)软件有限公司QA高级总监、IEEE ICST 2019工业论坛主席、多个IEEE国际学术会议程序委员、《软件学报》和《计算机学报》审稿人等。
闭门研讨会一: AI Coding 时代的代码评审与质量门禁重构