未经审视的接口的代价

版本 1.0，2026 年 10 月 11 日。LaTeX PDF：/pdfs/latex/interface-economics.pdf（源文件）。

摘要

本文汇集了在系统各部分之间的交接处发生的故障的已公布代价，并按每个数字的产生方式为其贴上标签。本文不把它们相加成一个总数。

用平常话说

1. 交接处的一些故障有确切的价格，比如一个损失的火星探测器，代价达数亿美元。
2. 更大的全国性数字是来自调查和模型的估计，其中没有一个只统计交接故障。
3. 写下并检查每一方所作的假设成本很低，但做这件事的人付出代价，而所有人都受益，所以这件事往往没人去做。

0. 定义与范围

接口是一种交接，一方的输出越过它成为另一方的输入：从陈述系统应当做什么的人（理论者），到构建系统的人（制造者），再到运行系统的人（使用者），或者在软件与硬件栈的两个层级之间。接口假设是对越过交接的值所施加的一个条件，接收方依赖它来保证自身的正确性，比如单位、范围、类型、版本或运行包络。当一个假设被依赖，却既没有写下也没有被检查时，它就是未经审视的。一大批工程文献，从 Garlan、Allen 和 Ockerbloom 关于架构失配的研究，到 Leveson 把事故视为交互故障的研究，都把许多系统故障定位在这样的假设上 [19, 20]。本文追问这些故障的代价是多少，并且只用原始来源明确给出的数字来回答。每个数字都按种类标注。核算成本是机构或企业报告的实际支出或损失。模型估计是用一种明确陈述的方法，从调查、访谈或二手数据中得出的数字。预测是关于未来的陈述。这三种数字不相加。

单次接口故障的核算成本巨大而具体：包含火星气候探测者号在内的火星勘测者 1998 项目耗资 3.276 亿美元 [1]，ESA 批准了 2.14 亿 ECU，用于挽回在首次 Ariane 5 发射中损失的 Cluster 任务 [4]。模型估计更大，也更宽泛：NIST 估算，美国软件测试基础设施不足造成的年度代价为 595 亿美元 [6]，美国资本设施行业互操作性不足造成的代价为每年 158 亿美元 [7]。CISQ 估算，2022 年美国软件质量低劣的代价不低于 2.41 万亿美元，累积的技术债约为 1.52 万亿美元 [8]。这些数字都不是单独衡量接口故障的。每一个都包含了它。

1. 数字的种类

关于软件故障的经济论断以三种形式流传，它们看起来相似，其实不同。项目预算是会计记录。全国成本估计是一个模型的输出，模型的输入是调查、案例研究和关于规模的假设。预测则两者都不是。本文遵循一条规则：每个数字都带有它的种类、它的来源，以及它实际统计的是什么。

把”接口故障”的代价当作单一年度总数的数字在流传，却没有说明方法。第 3 节中的原始估计没有一个把接口单独分离出来，因此本文不把它们对应到任何单一总数上。

2. 单次故障：核算

火星气候探测者号。 这里的接口是一个单位：以磅力秒为单位的推进器冲量数据被当作牛顿秒读取 [2]。NASA 的项目概况说明给出，火星勘测者 1998 项目的成本为 3.276 亿美元，涵盖探测者号与火星极地着陆器两者：航天器研制 1.931 亿美元，发射 9170 万美元，运行 4280 万美元 [1]。当时的报道称，仅探测者号本身就是一个 1.25 亿美元的航天器 [3]。种类：项目的核算成本，并附有单个航天器的报道数字。

Ariane 501 与 Cluster。 这里的接口是一个包络：从 Ariane 4 复用的软件假设了一个水平速度范围，而新运载火箭超出了这个范围 [5]。四颗 Cluster 卫星损失。ESA 关于挽回工作的记述，记录了其科学计划委员会在 1996 年为各个方案所定的价格，其中包括按原设计重建四颗卫星需 3.51 亿记账单位；1997 年，ESA 以 2.14 亿 ECU 批准了一项挽回任务，即 Cluster II [4, 17]。种类：ESA 所选挽回方案的核算成本，它是损失的下界，而不是卫星的价值或被推迟的科学研究的价值。

这两个案例确定了问题的形状。在每个案例中，每个机构都做好了自己的工作，而代价落在接口上。在每个案例中，本可以发现失配的检查，其成本相对于损失而言都很低。两个案例都不能放大成一个全国性数字，因为单次事故不是样本。

3. 全国估计：模型

软件测试，NIST 2002。 RTI International 受 NIST 委托估算，软件测试基础设施不足使美国经济每年付出 222 亿至 595 亿美元，其中较高的数字是总成本，较低的数字是可行的改进能够消除的部分 [6]。其方法把对两个行业（交通运输制造业和金融服务业）的开发者与用户的调查，同向全国经济的外推结合起来。种类：模型估计。

互操作性，NIST 2004。 Gallaher 及其同事受 NIST 委托，根据对业主、运营者、建筑师、工程师和承包商的访谈与调查，估算美国资本设施行业互操作性不足的代价为每年 158 亿美元 [7]。这里的互操作性是指在软件系统之间交换和使用设计与运营数据的能力，它是摘要所定义意义上的一个接口。报告说明，其数字略去了它无法量化的成本。种类：模型估计，单一行业，被表述为保守估计。

软件质量低劣，CISQ 2022。 信息与软件质量联盟（CISQ）估算，2022 年美国软件质量低劣的代价已增长到至少 2.41 万亿美元，累积的技术债已增长到约 1.52 万亿美元 [8]。报告由若干类别构建出总数：运行故障、失败的项目、遗留系统问题，以及归因于软件漏洞的网络犯罪损失；其大部分输入取自二手来源，其网络犯罪部分是把一项全球预测分摊到美国 [8]。种类：部分建立在其他估计之上的模型估计。它是这一领域有记载的最大数字，而且它是软件质量整体的数字，不是接口的数字。

开发者时间，Stripe 2018。 Stripe 与 Harris Poll 合作开展的一项调查报告，开发者每周约花 17.3 小时在调试和重构等维护工作上，每周约花 4 小时在”糟糕代码”上，报告把后者估值为全球每年近 850 亿美元 [9]。种类：基于调查的估计。

这些数字共有的是一种结构，而不是一个总数。每一个统计的都是一个被依赖而未被检查的假设的代价：一条未经测试的路径，一种无法跨系统传递的数据格式，一个位于边界上的漏洞，一个没有人能重新陈述其契约的遗留系统。一个没有在产生处被检查的失配，会作为格式良好的输入传给它之上的每一个层级，因此它的代价出现在远离其原因的地方，就像火星气候探测者号的导航解那样，它内部自洽，却是错的 [2]。这也是全国估计必须靠模型而不能靠计数的原因。

4. 技术债是一本接口账

Cunningham 在 1992 年提出技术债，指交付其结构尚未与团队所学相匹配的代码所付出的代价，在债务偿还之前，此后的每一次修改都要支付利息 [10]。Sculley 及其同事表明，在机器学习系统中，这种债务的大部分位于模型之外，位于胶水代码、配置、数据依赖和未声明的使用者之中 [11]。用上文定义的术语来说，技术债的很大一部分是记在账上的一笔未经审视的接口假设的余额，其利息是一个未被检查的失配在每一次运行中向它之上的每一个层级收取的代价。

CISQ 估计美国累积的技术债约为 1.52 万亿美元，这是一个存量，以修复成本计量 [8]。第 3 节的年度数字是流量。其经济后果是一个假设，在第 7 节中加以检验：在一个边界上一次性支付的检查，在整个工作负载上的成本，可能低于在故障所到达的每一个层级上反复支付的代价。

5. 标准是市场封闭接口的方式

经济学家以另一个名字研究接口问题已有数十年：兼容性。Katz 和 Shapiro 表明，当一个产品的价值随其可协作的用户数量上升时，企业实现兼容的激励取决于其规模和地位，市场可能提供过少的兼容性 [12]。Farrell 和 Saloner 表明，由于每个用户的选择取决于他人的选择，市场可能停留在旧标准上，也可能过快地转向新标准 [13]。David 关于 QWERTY 键盘的历史研究使路径依赖变得具体 [14]。Baldwin 和 Clark 表明，设计规则，即事先固定的可见接口，正是模块化产业得以形成的前提 [15]。Swann 为英国政府所作的综述总结了标准促进生产率和贸易的证据 [16]。

共同的线索是：接口是一种带有私人成本的公共品。写下一个假设并检查它，会使越过该边界的每一方受益，但成本由动手写的人承担。每一方都有理由把交接当作别人的工作。标准机构、监管者和平台所有者，是历史上承担这一成本的机构。机器检查的表示，比如携带计量单位的类型，或由模型检查器检查的形式化规格 [21, 22]，会把封闭一个接口的私人成本降向运行其检查的成本。

6. 生成的代码跨越同样的接口

由自动生成器产生的代码，跨越的边界与手写代码相同：在规格与实现之间，在库与其使用者之间，在软件与其下方的指令契约之间。每一次跨越都携带着假设，而生成器除非被构建为会检查，否则不会检查这些假设。因此，第 3 节的数字同样关系到自动代码生成。如果软件质量低劣的代价中有很大一部分是边界上未被检查的假设的代价，那么封闭接口的价值可能超过更快写代码的价值。这是一个关于价值所在的假设，而不是一项测量。第 7 节的协议就是测量它的方法。

7. 命题与协议

命题 E1（接口占比）。 在一组具有核算成本的软件故障中，其原因为违反了接口假设（按摘要中的定义）的成本占比，超过其原因完全位于某一个机构内部的成本占比。

协议： 取一个带有成本字段的公开事故语料库，比如机构的事故报告或监管文件。由两名编码员在不知道成本的情况下，按摘要中的定义把每个原因归类为接口原因或内部原因。报告按成本加权的接口占比及其自助法区间，以及编码员之间的一致性。

命题 E2（检查划算）。 对于固定的工作负载，在一个接口上增加一项显式检查的成本，低于它所拒绝的故障的期望代价，后者按故障原本会到达的每一个层级求和。形式化地说，对于一个被跨越 $N$ 次的接口，设 $c$ 为一次检查的成本（以美元计），$\pi$ 为一次跨越违反该假设的概率，$L_m$ 为一次未被发现的违反在它所到达的 $M$ 个层级中的第 $m$ 层所造成的代价（以美元计）。当 $Nc<N\pi {\sum }_{m=1}^M{L}_m$，即 $c<\pi {\sum }_m{L}_m$ 时，检查是划算的。第 2 节的两个核算案例的 ${\sum }_m{L}_m$ 量级为 $10^8$ 美元，因此对于每次跨越成本低于 $10^8\pi$ 美元的任何检查，该条件都成立。

协议： 在一个各层级运行成本已知的系统上，以固定的种子集对每一条已记录的接口假设注入一次违反，记录每项检查的成本，以及每一次未被发现的违反在其落点处的代价。两者都以焦耳报告，并按所述价格以美元报告。

命题 E3（封闭接口会降低其私人成本）。 当接口假设是共享表示的一部分，并且按构造被检查时，单独一方封闭它的成本会降向运行该检查的成本。

协议： 选择组织之间的一次真实交接，比如交给实现者的一份规格。在一个实验组中以散文文档承载它，在另一个实验组中以机器检查的表示承载它。记录交接每一侧的人工工时，以及每个实验组中定位在接口上的故障，并给出 Wilson 95% 区间。

8. 结论

未经审视的接口的代价是真实的、巨大的，而且衡量得很差。单次故障可以精确定价，它们表明，损失落在一个每个机构都以为属于别人的边界上。全国估计是模型，其中最大的那些描述的是软件质量整体。没有任何原始来源单独给出接口故障的代价，本文也不提供这样一个数字。证据所支持的是一种结构：代价在边界上产生，向上传播，并以债务的形式累积，所处的市场对已检查接口这一公共品供给不足。第 7 节的命题说明了如何检验这一结构。

参考文献

[1] NASA Jet Propulsion Laboratory, “Mars Climate Orbiter Fact Sheet,” Mars Surveyor 1998 project. Archived copy: https://web.archive.org/web/20121003073752/http://mars.jpl.nasa.gov/msp98/orbiter/fact.html

[2] Mars Climate Orbiter Mishap Investigation Board, Phase I Report. NASA, 10 November 1999. https://llis.nasa.gov/llis_lib/pdf/1009464main1_0641-mr.pdf

[3] A. Pollack, “Two Teams, Two Measures Equaled One Lost Spacecraft,” The New York Times, 1 October 1999. https://archive.nytimes.com/www.nytimes.com/library/national/science/100199sci-nasa-mars.html

[4] European Space Agency, “Cluster will fly again!,” press release N° 12 1997, 26 March 1997. https://www.esa.int/Newsroom/Press_Releases/Cluster_will_fly_again

[5] J. L. Lions (chair), Ariane 5 Flight 501 Failure: Report by the Inquiry Board. European Space Agency, 19 July 1996. https://esamultimedia.esa.int/docs/esa-x-1819eng.pdf

[6] RTI International for the National Institute of Standards and Technology, The Economic Impacts of Inadequate Infrastructure for Software Testing, Planning Report 02-3, May 2002. https://www.nist.gov/system/files/documents/director/planning/report02-3.pdf

[7] M. P. Gallaher, A. C. O’Connor, J. L. Dettbarn and L. T. Gilday, Cost Analysis of Inadequate Interoperability in the U.S. Capital Facilities Industry, NIST GCR 04-867, 2004. doi:10.6028/NIST.GCR.04-867

[8] H. Krasner, The Cost of Poor Software Quality in the US: A 2022 Report. Consortium for Information and Software Quality, 2022. https://www.it-cisq.org/the-cost-of-poor-quality-software-in-the-us-a-2022-report/

[9] Stripe, The Developer Coefficient, with Harris Poll, September 2018. https://stripe.com/files/reports/the-developer-coefficient.pdf

[10] W. Cunningham, “The WyCash portfolio management system,” OOPSLA 1992 Addendum, ACM SIGPLAN OOPS Messenger 4(2), 1993, pp. 29 to 30. doi:10.1145/157710.157715

[11] D. Sculley, G. Holt, D. Golovin, E. Davydov, T. Phillips, D. Ebner, V. Chaudhary, M. Young, J.-F. Crespo and D. Dennison, “Hidden Technical Debt in Machine Learning Systems,” Advances in Neural Information Processing Systems 28, 2015. https://papers.nips.cc/paper_files/paper/2015/hash/86df7dcfd896fcaf2674f757a2463eba-Abstract.html

[12] M. L. Katz and C. Shapiro, “Network Externalities, Competition, and Compatibility,” American Economic Review 75(3), June 1985, pp. 424 to 440. RePEc:aea:aecrev:v:75:y:1985:i:3:p:424-40. https://www.jstor.org/stable/1814809

[13] J. Farrell and G. Saloner, “Standardization, Compatibility, and Innovation,” RAND Journal of Economics 16(1), 1985, pp. 70 to 83. doi:10.2307/2555589

[14] P. A. David, “Clio and the Economics of QWERTY,” American Economic Review 75(2), Papers and Proceedings, May 1985, pp. 332 to 337. RePEc:aea:aecrev:v:75:y:1985:i:2:p:332-37. https://www.jstor.org/stable/1805621

[15] C. Y. Baldwin and K. B. Clark, Design Rules, Volume 1: The Power of Modularity. MIT Press, 2000. doi:10.7551/mitpress/2366.001.0001

[16] G. M. P. Swann, The Economics of Standardization: An Update. Report for the UK Department for Business, Innovation and Skills, 2010. https://www.gov.uk/government/publications/economics-of-standardisation-update-to-report

[17] European Space Agency, “The Resurrection of the Cluster Scientific Mission,” ESA Bulletin 91, 1997. https://www.esa.int/esapub/bulletin/bullet91/b91cred.htm

[19] D. Garlan, R. Allen and J. Ockerbloom, “Architectural mismatch: why reuse is so hard,” IEEE Software 12(6), 1995, pp. 17 to 26. doi:10.1109/52.469757

[20] N. G. Leveson, Engineering a Safer World: Systems Thinking Applied to Safety. MIT Press, 2012. doi:10.7551/mitpress/8179.001.0001

[21] A. Kennedy, “Types for Units-of-Measure: Theory and Practice,” in Central European Functional Programming School, Lecture Notes in Computer Science 6299, Springer, 2010, pp. 268 to 305. doi:10.1007/978-3-642-17685-2_8

[22] C. Newcombe, T. Rath, F. Zhang, B. Munteanu, M. Brooker and M. Deardeuff, “How Amazon Web Services uses formal methods,” Communications of the ACM 58(4), 2015, pp. 66 to 73. doi:10.1145/2699417