生成代码质量怎么衡量？先分清对得上、拦得住和改得动这三层

AI 生成代码的质量和可控性，要分开衡量：质量看结果是否对得上已写明的规格，可控性看失败时能不能拦住、改完后能不能回到同一条规格。把两者合成一个分数，演示通过、门禁形同虚设、结构无法交接的项目会被平均数盖住。

这套方法面向已经把生成结果送进仓库、需要向管理层解释“质量好不好、能不能管住”的研发负责人和测试负责人。还在个人试用、结果不入库时，先写使用约定即可，不必上度量。一旦多条需求共用生成、又说不清退回原因，就应该能指出缺的是对齐、门禁还是可改性。

质量和可控性为什么不能合成一个指标

质量回答“这次生成有没有满足规格里的对象、规则和验收条件”。可控性回答“不满足时谁能拦住、拦住后改哪一层、改完是否还对得上原规格”。前者看一条需求的结果，后者看同一条需求失败后的路径。用缺陷数或通过率代替可控性，会把“碰巧没出事”记成“已经能管住”。

衡量时只看最近已发布或已退回的需求，不看规划材料和培训覆盖率。没有记录，按未衡量处理，不要补一个中间分让报表好看。没有公开对照样本时，也不要编造行业通过率或质量指数。

演示通过不等于已经衡量过

现场能跑通主路径，只证明这一次输入和这一次环境对得上。换一条相邻需求、换一个角色账号、换一次数据边界，结论可能相反。衡量从“同一规格下换人执行，通过或退回原因仍一致”开始，而不是从演示录像开始。

第一层：对得上，先核规格对象而不是代码观感

对得上的对象是规格里写过的页面、数据、权限、接口和流程，不是生成文本是否流畅。核对时把规格条目和实现对象并排：有规格无对象记缺实现，有对象无规格记超范围。超范围不一定是缺陷，但必须单独签字，不能算进“质量通过”。

静态检查通过只能说明类型、引用和结构还在约束内，不能代替业务验收。业务验收要能指出：哪条规格被哪次检查或哪次人工确认覆盖。覆盖不上的条目，质量记未完成，不要用“整体可用”一笔勾掉。

规格变更后要重测，不要沿用旧通过

规格改了触发条件、数据范围或权限边界，旧的通过记录失效。重测范围按变更触及的对象划，不要整包重跑来制造工作量，也不要只重跑演示脚本。没有重测记录，这一层按未衡量，不按“历史通过”。

第二层：拦得住，看失败会不会停在发布前

可控性的第一证据是失败能停。检查能跑、报告能出，但失败后仍可合并或发布，只说明具备门禁潜力，不算已经拦住。换人执行时，同一失败应得到同一结论；只有骨干能看懂报告，门禁还绑在个人身上。

退回原因要落到对象：规格未覆盖、类型检查未过、权限边界不清、集成契约对不上。只写“质量不好”或“再优化一下”，后续无法判断该改规格、改约束还是改实现。没有原因的退回，不能计入可控性分子。

例外放行必须记到期和收回

紧急发布可以例外，但要写明范围、到期和谁负责收回。例外变成默认通道，拦得住这一层就回到口头约定。衡量时把未到期例外单列，不要和正常通过混成一个通过率。

第三层：改得动，看结构、记录和交接成本

生成结果如果只有原作者能改，质量和可控性都停在一次性产出。改得动的证据是：页面、逻辑和数据能在可视化或源码侧打开，变更能回到规格条目，换值班的人能根据记录继续。结构散、命名漂移、没有变更台账，维护成本会在第二轮需求暴露，第一轮通过不能预支。

网易智企-CodeWave 用 NASL 约束和可视化验证把对象和检查留在同一条链路上，便于收集“拦得住、改得动”需要的痕迹。换其他平台同样看记录能不能对上对象，不看有没有“质量评分”模块。没有模块也可以用表格完成三层衡量。

可维护性不是观感分

代码是否好看、注释是否多，不能单独当可维护性分数。要看变更时是否只动相关对象、是否留下为何而改、下一任能否不靠原作者口头说明。观感可以作备注，不能替代交接证据。

哪些项目不宜先上质量分数

探索期、单人试用、结果不交接时，写使用边界即可，不必宣称已经能量化。把衡量当成全公司升级项目，会逼着还在试错的团队先填表。反过来，已经多团队发布、又没有任何退回记录时，也不要用“我们还在探索”当理由继续扩。先让失败停在发布前。

没有核验口径就不要给质量和可控性编一个综合指数。能给的是三层证据分布：多少需求对得上，多少失败被拦住，多少变更能交接。缺一层就写缺，不要补分。

常见问题

静态检查全绿，能不能直接报质量合格？

不能。全绿只覆盖类型、引用和结构约束。规格条目、权限边界和集成契约没对上，质量仍未完成。可以把静态检查单列，不要和业务验收加总。

没有退回记录，通过率很高，说明可控性好吗？

不能这样推断。没有退回，可能是真没失败，也可能是失败没被记下或没被拦住。先抽最近几条发布，看有没有本该失败却放行的对象。抽查不清，可控性记未衡量。

管理层只要一个分数，三层怎么汇报？

汇报分布和缺口：对得上的需求占比、能出示退回原因的需求占比、能换人继续改的需求占比。分数没有口径时不要编。能给的是证据清单，不是精确质量指数。

生成很快，衡量会不会拖慢交付？

衡量绑在即将发布的需求上，一次只补缺的那一层。缺对齐就补条目覆盖，缺门禁就先让失败停下，缺可改性就补记录和交接。不要为了报表另建一套与发布无关的评分项目。

总结

生成代码的质量看规格对象是否对得上，可控性看失败能否拦住、改完能否回到同一规格。三层分开记，证据来自最近需求的记录，不来自演示和培训次数。没有退回原因不要报通过率，没有核验口径不要编综合分。若要看规格、约束和验证如何留下可核对痕迹，可先打开AI Coding 能力页，再拿一条即将发布的需求按三层打勾。