7.3 指标膨胀与质量稀释风险

概述与动机

本主题直接、具体地点名了主题 7.1 所警告的、随着人工智能辅助开发成为标准做法，本书整个框架必须防范的两种失败模式：指标膨胀，数字在上升、却没有相应的真实价值支撑，以及质量稀释，代码质量的渐进式侵蚀，其速度超出了业界目前通过现有评审和测试实践检测它的能力。这些并不是本书尚未点名过的新风险类别，指标膨胀是主题 1.2 的古德哈特定律和主题 1.2 的替代性操纵在规模上的应用，质量稀释是主题 4.2 的覆盖率-有效性缺口和主题 5.1 的逃逸缺陷关切，两者都被加剧了。新的是生成式人工智能能够同时产生这两种失败模式的速度和规模，快过了大多数组织现有护栏所能捕捉到的速度。

本主题所关切的具体机制是微妙的：人工智能生成的代码非常常常看起来是正确的。它遵循熟悉的惯用法，使用言之成理的变量名，通过表面阅读的可靠程度，远高于真正粗心的人工编写代码通常所能达到的程度，恰恰因为它是在一个海量的、看起来正确的代码语料库上训练出来的。这让人工智能生成的缺陷更难被一位人类评审者，通过那种”这看起来对不对”的模式匹配式评审（这种评审能捕捉到许多人为引入的缺陷）捕捉到，因为人工智能生成的版本，在统计意义上，恰恰是被优化来显得正确的，无论它实际上是否正确。

对大团队而言，本主题的这些风险会以一种应当尤其令企业和政府组织担忧的方式随规模累积：跨越数十个团队同时发生的指标膨胀，可能产生一种全组织范围的、生产力已改善的虚假信号，需要花费大量时间和分析才能拆解，恰如主题 7.1 的金融科技案例所展示的那样。超出检测能力的质量稀释，在受监管、安全攸关或涉及公众信任的情境中更加严重，在那里，一个未被检测到的缺陷抵达生产环境的代价，远远超出了直接的工程关切。

核心原则

指标膨胀和质量稀释，是本书已经点名过的风险的加剧版本， 而不是全新的类别；现有的护栏依然适用，只是需要更用力地发挥作用。
人工智能生成代码”看起来正确”的质量，让它对人类模式匹配式评审、专门变得更难被捕捉到细微缺陷。 这是一种与普通人为错误截然不同的风险。
这种转变的速度，可能超过一个组织调整其护栏的能力， 创造出一个真实的、有时限的暴露窗口。
现有的质量指标（第4部分）依然有价值，但可能需要重新校准， 而不是被替换，以应对这种新的风险状况。
检测能力本身需要刻意的投资， 因为本书所涵盖的评审和测试实践，是在这种具体风险以这种规模存在之前被设计出来的。

建议

为大量使用人工智能的工作重新校准变更失败率和逃逸缺陷阈值

在一个团队或代码区域大量采用了人工智能辅助的地方，用提高的敏感度应用主题 2.4 和主题 5.1 的严重程度加权跟踪，至少要维持到你的组织建立起足够的证据（主题 7.2），知道这些指标与真实风险之间的历史性关系，对人工智能辅助工作而言是否依然不变地成立。把这种重新校准当作一种临时的、收集证据的姿态，而不是一种永久的、不加审视的假设，无论方向如何。

专门投资于能抵御”看起来正确”问题的检测能力

传统的代码评审，很大程度上依赖评审者对”看起来对不对”的模式识别，对言之成理却微妙不正确的人工智能生成代码，专门变得薄弱。相应地更多投资于不依赖视觉模式匹配的检测方法：变异测试（主题 4.2），它测试的是真实的行为而不是表象，以及基于属性或基于不变量的测试，它验证的是逻辑上的正确性而不是表面的言之成理，两者都因为这种转变而变得不成比例地更有价值。

留意整条交付流水线上的指标膨胀，而不只是代码生成那一点

来自人工智能辅助开发的指标膨胀，并不局限于编码阶段；它可以通过整条周期时间链条（主题 2.6）传播：更大量的人工智能生成拉取请求，可能虚增拉取请求吞吐量指标（主题 2.9），即使这项指标最初本应捕捉的那个有用信号，也就是真正的团队吞吐量，一旦恰当地核算了评审负担和纠正成本，保持持平甚至下降。审计你完整的指标集，寻找这种传播模式，而不只是最明显、最直接与人工智能相关的指标。

建立一份明确、有时限的重新校准计划，而不是一种永久的怀疑姿态

本主题所建议的提高的审查力度，在一段活跃的采用和不确定时期是恰当的，但它不应该无限期地变成一种永久的、不加审视的对人工智能辅助工作的税负。随着你的组织通过主题 7.2 的测量纪律建立起真实的证据，根据证据实际显示的内容修订阈值和护栏，在风险被证实的地方进一步收紧，在没有被证实的地方放松，而不是要么完全忽视这种风险，要么无论证据如何累积，都对每一份人工智能辅助代码保持永久、不加区分的怀疑。

透明地传达这种风险，而不是把它当作抵制人工智能采用的理由

把本主题的指导定位为对一项真正有价值的新能力的风险管理，而不是一个反对人工智能辅助开发本身的论据。一个清晰地传达这些具体、被点名的风险、并针对它们建立起相称护栏的组织，恰如本书对它所涵盖的每一项其他指标和技术所建议的那样，比一个要么忽视风险、要么把它当作全面抵制一套真正有用工具的理由的组织，更安全、更可持续地采用人工智能辅助。

权衡取舍：利与弊

方案	优点	缺点
不做重新校准，把人工智能辅助工作与人工编写代码同等对待	简单，无需流程变化	错过了一种证据显示已经升高的风险状况
对所有人工智能辅助代码进行全面、永久的加强审查	最大限度地降低短期风险	对一项真正有价值的能力造成不可持续的税负；忽视累积的证据
有时限、由证据驱动的重新校准	平衡了风险管理与可持续的采用	需要持续的测量纪律（主题 7.2）才能知道何时放松审查
投资于能抵御”看起来正确”缺陷的检测方法	直接、持久地解决这种具体的新风险	需要对变异测试和基于属性测试的基础设施进行前期投资

核心张力是谨慎与采用速度之间的张力。过度、永久的谨慎，会浪费掉人工智能辅助开发大部分真正的价值；不足的谨慎，则冒着本主题所点名的指标膨胀和质量稀释的风险，可能在被检测到之前就达到相当大的规模。解决这种张力的办法，是采用本主题所建议的、有时限、由证据驱动的方法：现在提高审查力度，随着主题 7.2 测量纪律所积累的真实证据，向下或向上校准，而不是要么采取一项永久的全面政策，要么不加审视地假定什么都没变。

与团队讨论的问题

我们是否为大量使用人工智能的工作重新校准了变更失败率或逃逸缺陷阈值，还是我们不加改变地套用人工智能出现之前那个时代的阈值？ 如果没有改变，讨论这是否反映了一个刻意的、基于证据的决定，还是仅仅是对这个问题缺乏关注。
我们是否拥有像变异测试这样、不依赖评审者视觉模式匹配的检测方法，还是我们的评审流程完全依赖人类的眼睛来判断代码”看起来对不对”？ 这正是本主题所识别出的具体脆弱性；诚实地对照它评估你当前的检测能力。
指标膨胀是否已经从编码阶段传播到我们的拉取请求或部署指标中，如果发生了，我们目前会注意到吗？ 走一遍你完整的周期时间链条，寻找这种传播模式，而不只是最明显的起源点。
我们目前对人工智能辅助代码的加强审查，如果有的话，是建立在累积证据之上，还是一个从未被重新考虑过的、不加审视的永久默认设置？ 讨论需要积累什么样的证据，你才会考虑放松或进一步收紧当前的护栏。
我们在内部是如何传达本主题这些风险的：作为审慎和相称护栏的理由，还是作为一个反对人工智能采用本身的隐含论据？ 诚实地面对这场对话在你团队中实际上是如何被接受的，因为一个被当作全面抵制来接收的信息，很少能产生本主题所建议的那种相称、基于证据的回应。
如果我们的组织只在达到相当大的规模之后，才发现指标膨胀和质量稀释一直在同时发生、却未被检测到，那会是什么样子？ 这个具体、略带不适的情景，值得被明确点明，作为本主题的护栏所要防止的具体失败。

行业视角

初创公司。 对一个小团队而言，评审能力有限的快速采用，让本主题的风险尤为尖锐；“看起来正确”的检测问题，对更少、专业化程度更低的评审者而言更难捕捉。即使全面覆盖尚不可行，也要及早在你最关键的代码路径上至少投资于轻量级的变异测试。

小型企业。 正式的重新校准流程在这个规模上很可能没有必要，但一种简单、明确的意识，即人工智能生成的代码理应得到比平常略微更持怀疑态度的阅读，恰恰因为它往往看起来比实际情况更自信地正确，不花任何成本，却直接应对了本主题的核心关切。

企业。 指标膨胀和质量稀释在这个规模上都会显著累积，因为一个虚假信号或一个未被检测到的质量问题，一旦同时出现在数十个团队中，其后果远比在单一团队上更严重、也远更难以拆解。刻意投资于全组织范围的检测能力升级（变异测试基础设施、基于属性测试的采用），以及本主题所建议的、由中央跟踪的有时限重新校准纪律。

政府。 在政府系统常见的受监管、安全攸关或涉及公众信任的情境中，未被检测到的质量稀释的后果尤为严重。专门对高后果代码路径中的人工智能辅助变更应用提高的、由证据驱动的审查（主题 6.4 的暴露程度与可利用性加权逻辑在这里同样适用），并做好准备向审计员或监督机构证明，究竟存在什么样的检测能力来对抗这种具体的风险。

案例

企业。 一家保险公司的理赔处理工程团队广泛采用了人工智能编程辅助，六个月后，注意到专门在复杂条件逻辑中出现了一种渐进但可衡量的逃逸缺陷上升，这类代码正是人工智能工具最容易言之成理地生成、也最难仅凭检视被评审者捕捉到微妙错误边界情况处理的地方。一次调查证实了本主题所描述的”看起来正确”模式：有缺陷的代码一贯使用惯用的、看起来熟悉的模式，通过了评审，而没有触发那种一段明显不寻常或笨拙的人工编写代码本可能受到的审查。该团队的应对，是专门在全公司范围内把变异测试针对复杂条件逻辑，这是一种能抵御表面言之成理问题的检测方法，并在两个季度内衡量到这一具体缺陷类别显著减少。

政府。 一家税务机构，为其计算引擎维护工作的一部分试点了人工智能辅助开发，从一开始就建立了本主题所建议的有时限重新校准纪律，设定了一个明确的六个月证据收集期，专门对人工智能辅助的计算逻辑变更提出加强的评审要求。所收集的证据显示，对界定明确、范围狭窄的变更而言，缺陷率没有统计上有意义的差异，但确实证实了对更宽泛、架构上更重大的人工智能辅助变更而言，风险有所升高。该机构由此产生的政策，对狭窄范围的变更类别放松了加强审查，同时对架构上重大的变更保持、甚至加强了审查，这是一个相称的、基于证据的结果，“不做重新校准”和”全面永久审查”这两个极端都不会产生这样的结果。

商业理由：动机、投资回报与总拥有成本

刻意防范指标膨胀和质量稀释的回报，是避免了上面保险公司案例所展示的那种情形：一个未被检测到、逐渐累积的质量问题，事后发现和补救的成本，远高于专门针对最高风险代码的检测投资，也就是变异测试基础设施，主动付出的成本本会是多少。

总拥有成本包括本主题所建议的检测能力投资，以及持续采用基于证据的重新校准、而不是走向任何一个极端（永久怀疑或永久不关注）的纪律。相比一个显著的、规模化的质量问题未被检测到的风险，这份成本是适度、有时限的，而这种未被检测到，恰恰是因为这些工具生成代码的方式，让它被设计成在一个组织现有的评审流程看来是正确的。

反模式与陷阱

不加改变地套用人工智能出现之前那个时代的阈值和检测方法： 错过了一种证据显示已经升高的具体风险状况。
完全依赖人类模式匹配评审来处理人工智能生成的代码： 对本主题所识别的”看起来正确”问题专门脆弱。
错过了代码生成点之外的指标膨胀传播： 一个虚假信号可能未被检测地传播到整条交付流水线中。
永久、不加审视的全面审查，没有基于证据的重新校准： 不可持续地浪费了人工智能辅助开发大部分真正的价值。
把本主题的风险传达为对人工智能采用的全面抵制，而不是相称的风险管理： 同时损害了安全性和采用。
没有专门针对这种新风险状况的检测能力投资： 让组织依赖本主题已经证明专门对它薄弱的评审方法。

成熟度模型

第一级，启动： 对人工智能辅助开发特有的指标膨胀或质量稀释风险没有意识；现有的护栏和检测方法被不加改变地应用。
第二级，发展： 存在一些意识，但重新校准是临时的，也没有针对这种风险专门投资检测能力。
第三级，标准化： 经过重新校准的阈值，以及能抵御”看起来正确”问题的检测方法（变异测试和基于属性的测试），被一贯地应用于人工智能辅助工作。
第四级，管理： 一种有时限、由证据驱动的重新校准纪律，根据累积的数据主动调整审查力度，指标膨胀的传播在整条流水线中被主动监控。
第五级，协奏： 组织对人工智能辅助开发拥有一套成熟的、相称的、持续演进的风险管理姿态，得到透明地传达，既不会因为过度谨慎而浪费它的价值，也不会让组织暴露在未被检测到的质量稀释之下。

讨论思路

我们是否在自己的人工智能辅助代码中，看到过任何”看起来正确”缺陷模式的早期证据？
什么样的检测方法，对我们而言最能直接应对本主题这种具体的风险？
来自人工智能辅助的指标膨胀，是否已经传播到我们下游流水线的任何指标中？
我们目前对人工智能辅助代码的审查，是基于证据的，还是一个不加审视的默认设置？
本主题的指导，在我们团队中实际上是如何被接受的：作为风险管理，还是作为对人工智能采用的抵制？

要点回顾

指标膨胀和质量稀释是本书已经点名过的风险的加剧版本， 需要现有的护栏更用力地发挥作用，而不是需要全新的框架。
人工智能生成代码“看起来正确”的倾向，专门削弱了传统的、模式匹配式的人工代码评审。
投资于能抵御表面言之成理性的检测方法， 尤其是变异测试和基于属性的测试。
采取一种有时限、由证据驱动的重新校准姿态，而不是永久的全面怀疑或永久的不加审视的信任。
把这种风险传达为相称的风险管理， 而不是一个反对人工智能采用的论据，以同时支持安全性和可持续的使用。

参考文献与延伸阅读

Accelerate: The Science of Lean Software and DevOps，Nicole Forsgren、Jez Humble、Gene Kim著（本主题应用于一个新风险类别的速度与稳定性配对纪律）。
Jia, Yue, and Mark Harman, “An Analysis and Survey of the Development of Mutation Testing,” IEEE Transactions on Software Engineering (2011)：本主题论证会变得不成比例更有价值的检测方法。
GitHub关于人工智能结对编程与开发者生产力的研究（关于人工智能辅助开发结果与风险的行业数据）。
The Tyranny of Metrics，Jerry Z. Muller著（指标迷恋与操纵风险，与本主题所点名的指标膨胀关切直接相关）。