技术债务
由Ward Cunningham在1992年提出的隐喻概念，指开发团队为了短期交付速度而做出的技术妥协，会在未来产生额外的维护和修改成本
核心事实
时间轴 (近 90 天)
代码行数（LOC）本身并不是技术债务的可靠代理指标，简洁的实现也可能隐藏深层耦合。
「认知债务」(cognitive debt) 是软件工程研究中对「代码增长快于理解增长」现象的近似说法，与技术债务相区分：技术债务关心代码质量与维护成本，认知债务关心团队对系统的心智模型是否完整。
坎宁安用金融借贷作类比技术债务：短期选择不完善方案未来需偿还本金（重构代码）并支付利息（额外维护成本）
常见的技术债务形式包括缺乏测试覆盖、过度复杂的模块耦合、已过时的第三方依赖以及只有原作者才能理解的"魔法代码"
技术债务叠加会使系统走向工程师口中的"大泥球"（Big Ball of Mud）状态，即没有清晰架构、牵一发而动全身
在产品早期快速验证市场时，有意识地"借"技术债务是合理的权衡，问题在于无意识累积或长期不还债
政府机构的IT系统长期面临技术债务困扰，包括老旧架构、维护不足的代码库和有限的安全审计资源
性能债比功能债更难偿还，重写一个慢接口可能需要重构整个调用链
技术债务概念由Ward Cunningham在1992年提出，指为短期交付速度而选择次优方案所累积的长期维护成本
为了短期速度而牺牲代码质量会在未来的维护、扩展和修复中付出更大代价，构成技术债务的权衡
还有 2 条时间轴事件
全部知识事实 (20)
技术债务概念由Ward Cunningham在1992年提出，指为短期交付速度而选择次优方案所累积的长期维护成本
85%已验证技术债务（Technical Debt）概念由Ward Cunningham在1992年首次提出
80%已验证技术债务（Technical Debt）概念由Ward Cunningham在1992年提出，用于描述为了短期交付而采用的次优方案所积累的隐性成本
80%已验证技术债务指为追求短期交付速度而在代码质量、架构设计上做出的妥协，会在未来以更高的维护成本和重构代价偿还
75%已验证当代码生产成本趋近于零时，AI生成的'看起来合理但存在微妙缺陷'的代码往往比人类手写的明显错误更难发现
65%待验证SonarQube等工具已将技术债务量化为修复所需工时
90%待验证嵌入式产品一旦出货，OTA升级能力有限，线上修复的窗口极为狭窄，技术债务的代价远高于互联网软件
85%待验证硬编码模型名称在代码中会导致切换模型时需要全量代码扫描、回归测试和重新部署
85%待验证在Vibe Coding模式下，技术债务以指数而非线性速度增长，因为开发者不读代码、AI不会主动重构
75%待验证AI Agent时代的技术债出现新形态：用低代码或自然语言快速搭建的自动化流程往往缺乏清晰的错误处理、权限边界和可观测性设计
75%待验证'技术债务'这一比喻由Ward Cunningham提出，将降低代码质量换取短期交付速度的行为类比为借贷
60%待验证代码行数（LOC）本身并不是技术债务的可靠代理指标，简洁的实现也可能隐藏深层耦合。
50%待验证「认知债务」(cognitive debt) 是软件工程研究中对「代码增长快于理解增长」现象的近似说法，与技术债务相区分：技术债务关心代码质量与维护成本，认知债务关心团队对系统的心智模型是否完整。
50%待验证常见的技术债务形式包括缺乏测试覆盖、过度复杂的模块耦合、已过时的第三方依赖以及只有原作者才能理解的"魔法代码"
50%待验证在产品早期快速验证市场时，有意识地"借"技术债务是合理的权衡，问题在于无意识累积或长期不还债
50%待验证坎宁安用金融借贷作类比技术债务：短期选择不完善方案未来需偿还本金（重构代码）并支付利息（额外维护成本）
50%待验证技术债务叠加会使系统走向工程师口中的"大泥球"（Big Ball of Mud）状态，即没有清晰架构、牵一发而动全身
50%待验证政府机构的IT系统长期面临技术债务困扰，包括老旧架构、维护不足的代码库和有限的安全审计资源
50%待验证性能债比功能债更难偿还，重写一个慢接口可能需要重构整个调用链
50%待验证为了短期速度而牺牲代码质量会在未来的维护、扩展和修复中付出更大代价，构成技术债务的权衡
50%