AI时代如何评价软件的质量

TL;DR

• AI没有解决质量度量的难题，但它让虚假的过程指标彻底露馅
• 有效的技术指标必须能追溯到商业结果——生产成本、销售成本、服务成本
• AI时代软件多了一个新的质量维度：AI可理解性，它和工程可理解性一样重要
• 结果指标过去难持续度量，AI可把「定性」检查收敛成可重复的标准与自动化
• 现代软件工程的首要基础设施，是评价标准与评价工具的建设

上一篇文章写了AI如何改变我们的工作方式——手艺失去了意义，思维成了瓶颈。这篇接着谈一个更具体的问题。当AI改变了工作的方式，我们该如何评价工作的成果？

评价软件的质量，评价团队的效能，评价工程师的能力，一直都是这个行业的老大难。AI并没有直接解决这个问题，但它让那些一直不好使的指标彻底露馅。

过程指标的破产

代码行数、提交次数、合并频率、需求数量、测试用例数量、代码评审通过率……这些过程指标被用了很多年。大家心里都知道它们有问题，但很多场景也在凑合着用。

AI时代，凑合不下去了。

当AI可以在几分钟内生成上千行代码，代码行数还能衡量什么？当AI可以自动拆分出无数个细碎的提交，提交次数还能说明什么？当AI可以一键生成几百条测试用例，用例数量还代表什么？

这些指标的荒谬性从来没有变过，变的是它们再也藏不住了。它们衡量的是”动作”而不是”成果”，是”做了多少”而不是”做对了多少”，是”成本”而不是”产出”。在AI能无限放大输出的今天，继续盯着这些数字只是掩耳盗铃和自欺欺人。

回到商业结果

既然过程指标靠不住，什么靠得住？

答案很朴素，回到商业结果。软件是商业活动的产物，评价软件质量的终极标准只有一个——它对商业结果的贡献。这种贡献体现在三个维度的成本上。

生产成本——把软件做出来要花多少钱。核心是研发人力成本，包括设计、开发、测试、部署全链路投入的人力和时间。

销售成本——把软件卖出去有多难。取决于产品的可用性和易用性——东西好不好用，用户愿不愿意买单。好的产品自己会说话，差的产品再多销售也推不动。

服务成本——把软件持续运转要花多少钱。包括可扩展性（能不能撑住业务增长）、可维护性（改起来痛不痛苦）、部署成本（上线和运维有多贵）。

所有有效的技术指标，都应该能追溯到这三个商业结果之一。追不到的，大概率是无效指标。

结果指标曾经难量，现在可以造尺子

上面这些结果导向的指标，多数带着「定性」气质——好不好用、文档和架构是否可被人和AI共同理解、扩展与维护的代价有多大，过去往往靠专家评审、走查、经验打分。成本高、口径难统一、可重复性差，很难像编译报错那样每天自动跑一遍。过程指标浅，大家并非看不见；真正缺的是一把能量、能复用的尺子，最后只能退回去数提交、数用例。

没有AI的时候，要把这类检查规模化、例行化，几乎等于再养一支「专职评委会」，边际成本降不下来。

现在情况变了。把「什么叫可测的需求」「什么叫可被AI消费的架构说明」「线上缺陷密度按什么口径统计」写成显式标准，让脚本或Agent按同一套规则批跑、批比、批留痕，许多过去只能依赖主观判断的环节，可以收敛成确定性流程。定性不等于不可言传——标准写清楚了，机器就能在同一尺度上重复执行；人仍然要拍板边界和例外，但日常验证不必再绑死在少数专家的时间表上。

有效的技术指标

下面这套技术指标体系来自我的实践经验。每个指标都标注了它对应的能力维度和最终关联的商业结果。其中”AI可理解性”是AI时代出现的新维度——过去我们只关心人能不能读懂代码，现在AI成了开发过程中的重要参与者，软件制品能否被AI准确理解，直接影响AI辅助开发的效率和质量。

这些条目既是「该盯什么」的清单，也是评价标准设计的素材。哪几条要进门禁、哪几条走抽样、哪几条留给发布前的综合评审，可以分阶段落地；能自动化的，尽量交给工具和Agent按标准执行。

需求

需求是软件的起点，需求的质量直接决定了后续所有环节的效率和成本。

• 价值度
  
  ——需求是否解决了用户真正的问题。产品的可用性和易用性取决于此，直接影响销售成本和市场竞争力。
• 可测性
  
  ——需求能否被明确地验证通过或不通过。可测的需求降低验收和回归的人力投入，压低生产成本和服务成本。
• 粒度
  
  ——需求是否被拆解到了可独立开发和验证的大小。合理的粒度减少开发复杂度和估算偏差，压低生产成本。
• 独立性
  
  ——需求是否能完整交付，不依赖其他未完成的需求。独立的需求支持并行开发和独立验收，减少团队间的等待和协调消耗，压低生产成本。
• 可适应性
  
  ——需求的表述能否灵活适应技术方案的变化。适应性差的需求在方案调整时反复返工，推高生产成本和服务成本。

架构

架构是连接需求和代码的桥梁。好的架构让后续工作事半功倍，差的架构让所有人持续还债。

• 可测试性
  
  ——架构是否天然支持自动化测试。回归测试成本低了，持续集成和快速反馈才有保障，生产成本和服务成本都会下降。
• 工程可理解性
  
  ——架构对人类工程师是否清晰可懂。新人上手快、协作摩擦小，生产成本就低。
• AI可理解性
  
  ——架构能否被AI工具准确理解。AI能把握系统整体结构并生成符合架构约束的代码，直接拉低生产成本。
• 可扩展性
  
  ——架构能否以较低成本接入新功能和新模块。支撑业务增长，减少大规模重构的频率和风险，拉低生产成本和服务成本。

开发

开发是将设计转化为可运行软件的过程。AI时代，代码质量的内涵发生了变化——代码不仅要让人读得懂，还要让AI读得懂。

• 测试覆盖率
  
  ——不仅是单元测试，需要涵盖集成测试、功能测试和手工测试的整体覆盖。保障软件运行的可靠性，降低线上故障频率，直接关系到服务成本。
• 工程可理解性
  
  ——代码对人类工程师是否清晰可维护。知识传递和维护成本越低，生产成本和服务成本越低。
• AI可理解性
  
  ——代码能否被AI准确理解意图并高效辅助开发。AI生成高质量补充代码和修改建议的前提是读懂现有代码，这直接影响生产成本。
• 封装合理性
  
  ——模块间的职责划分和边界是否清晰。控制变更的影响范围，降低耦合度，拉低生产成本和服务成本。
• 开放扩展性
  
  ——代码能否在不侵入原有逻辑的前提下扩展新功能。支持功能迭代而无需大面积改动既有代码，压低生产成本和服务成本。

测试

测试是软件质量的最后一道防线，也是持续交付的信心基础。

• 测试覆盖率
  
  ——与开发阶段的覆盖率互补，从全局视角衡量质量保障的完整性。保障产品交付质量，直接关系到服务成本。
• 用例的可维护性
  
  ——系统演进时测试用例能否低成本地跟随调整。测试资产的长期维护成本高低，直接影响生产成本。
• 用例的可扩展性
  
  ——新场景出现时能否快速新增测试覆盖。快速验证新需求的正确性，缩短交付周期，压低生产成本。
• 用例的AI可理解性
  
  ——测试用例能否被AI理解并辅助生成和维护。AI参与测试自动化，降低测试编写和维护的人力投入，压低生产成本。

部署与运维

部署和运维是软件交付价值的最后一环，直接关系到服务成本的高低。

• 上线成功率
  
  ——每次部署是否能稳定完成，不引发新问题。系统稳定性和交付可靠性的直接体现，关系到服务成本。
• 故障恢复时间
  
  ——出问题后多快能恢复正常服务。故障拖得越久，对业务和用户的冲击越大，服务成本越高。
• 线上缺陷密度
  
  ——生产环境中单位功能的缺陷数量。交付质量的终极度量，直接决定服务成本。

评价标准与评价工具

代码仓库、CI流水线、监控大盘当然要紧。但若没有「什么才是好」的共同语言，以及能按这套语言自动验真的手段，AI再能写也只是放大噪声。过程指标破产之后，真正卡住团队的，常常是结果指标能量、能复用、能进流水线。

我把一句话写在这里，当作这篇小文的收束：现代软件工程的首要基础设施，是评价标准与评价工具的建设。 标准回答「量什么、什么叫过关」；工具（含脚本、门禁、评测集、按标准跑的Agent）回答「谁来量、多频、留什么证据」。先把尺子造准，再把尺子接进日常研发节奏，围绕结果指标的改进才有锚点，AI辅助开发也才有可控的反馈回路。

无效的过程指标

以下常见的过程指标在AI时代已经彻底失去参考价值——

• 需求数量
• 代码库数量
• 提交次数
• 合并频率
• 提交行数
• 单元测试纸面覆盖率
• 缺陷数量
• 部署次数
• ……

它们的共同特点是只衡量”量”，不衡量”质”。在AI可以无限放大”量”的今天，它们不仅无效，而且有害——拿它们做考核，等于鼓励所有人利用AI刷数字。

AI并没有解决评价软件质量这个老难题，但它把虚假的指标彻底击碎了。那些有效指标一直都在那里，只是以前被淹没在花里胡哨的过程数据里，又苦于没有廉价、统一的度量手段。现在露出来了，也到了该为它们配齐标准和工具的时候。

剩下的事情很明确——围绕这些指标去度量和改进，并把度量和改进本身做成工程能力。

欢迎交流

如果你觉得文章有帮助，欢迎加我微信或关注公众号，获取更多内容

微信：Leon_Lingrui