技术债（Tech Debt）是为了换取短期交付速度，在代码、架构或流程上主动做出的妥协。它像一笔贷款：本金是当时省下的时间，利息按天计算，计入每一次改动和每一次故障。
一笔装修账
店要赶在周末开业，水电走明管、线槽钉在墙上，三天完工，当天就能做生意。三个月后想挪一下灶台，才发现得先拆半面墙的管线；某天接头渗水，又停业半天。省下的时间是真实的，还回去的时间也是真实的。
软件里是同一笔账。为了赶版本，把一段逻辑复制粘贴到三个地方；不写测试，改动全靠手工点一遍；该拆的模块没拆，一个文件几千行；文档只存在写它的那个人脑子里；依赖长期不升级。这些代码都能跑，甚至跑得很好——这正是危险之处：它们不报错，只是让下一次改动变得更贵。
利息怎么计价
技术债的利息有两个计价点：改动速度和故障率。前者表现为“加个很小的功能要两周，因为要改五个地方、还要手工回归一遍”；后者表现为“上线总出问题，出了问题定位不到在哪”。常见的工程效能度量，比如交付周期（Lead Time）、变更失败率（Change Failure Rate），量化的正是这两件事。
因此判断一笔债值不值，标准不是“代码丑不丑”，而是“这段代码以后还会不会改”。三年没人碰的角落，再乱也构不成债；每天都要动的核心链路，一点将就都在持续付息。
和几个近邻的区别
| 概念 | 是什么 | 与技术债的关系 |
|---|---|---|
| 技术债（Tech Debt） | 用未来成本换当下速度的选择 | 是债务本身，本质上是一笔经济账 |
| 缺陷（Bug） | 现在就表现不对 | 债可能引发缺陷，但债本身能跑 |
| 代码坏味道（Code Smell） | 结构上的可疑信号 | 只是线索，是否成债看它还改不改 |
| 重构（Refactoring） | 不改变外部行为地改进结构 | 还债的手段之一 |
一句话记：缺陷是已经疼了，坏味道是看着不对，技术债是“我先欠着”，重构是还款。
对干活的人意味着什么
借债不丢人，不记账才丢人。至少写下一句“这里为了赶某次上线先这样，条件允许时换成某方案”，让下一个人知道这是选择而非设计。还款顺序也有讲究：优先还改动最频繁的模块，那里利息最高；长期不动的部分可以继续欠着。
对管理者来说，技术债不是工程师的完美主义托词，也不是看不见就不用管的账。它最终会以两种形式浮出水面：需求交付越来越慢，线上事故越来越多。想管它，先让它可见——记录返工工时，记录事故次数。
AI 辅助写代码让这件事更尖锐：生成代码的成本降了，读懂并改对的成本没降。产出变快，如果评审和测试不跟着变快，债也会攒得更快。省下的时间是真的，欠下的也是真的。