技术债不是慢慢还的，是按复利收的：早期项目最贵的拖延

几乎每个创始人都说过同一句话：「先上线，回头再重构。」说这话的时候大家都觉得自己在借一笔便宜的钱——用三周的工程时间换早上线。问题在于，技术债的利息不是固定的，是复利的：你在这块摇摇晃晃的地基上每盖一层新功能，旧账的利率就往上抬一次。

这不是修辞。Stripe 的开发者系数报告调查了几千名工程师，结论是开发者平均把超过三分之一的时间花在处理技术债和烂代码上，而不是写新功能。CISQ 估算过，仅美国一年劣质软件造成的成本就超过 2.4 万亿美元。换算到早期团队的尺度：你第一年省下的三周，第二年通常要还四个月。

一笔真实的拖延账

去年我们接手过一个 AI 工具项目的「中途救援」。创始人一开始图快，让外包把提示词逻辑直接写死在六个前端页面里，没有抽象层，没有测试。前六个月确实快，每周都在发新功能。

第八个月，客户要求接入第二个大模型。这本该是一周的事，结果改动牵出四十多处硬编码，前端后端缠成一团，没人敢说哪块动了不会炸。最后重构花了十一周——这期间新功能全部冻结，客服只能跟客户说「再等等」，两个意向客户在等待期流失，竞争对手正好在这个窗口发了同类功能。

算账：当初「省下」的架构时间大约三周，按当时的外包价格值不到两万美元。后来的代价是十一周重构费、八周增长停滞、两个客户。复利不是比喻，是结算单。

技术债什么时候该还

不是所有债都要马上还，早期项目背着合理的债跑是常态。但出现下面三个信号，说明利率已经高到必须处理了：

• 工期估算越来越不准。以前两天的活现在总要一周，而且没人说得清为什么——说明每行新代码都在为旧结构付过路费。
• 某块代码只有一个人敢动。这个人休假，那块功能就等于停摆。知识单点是技术债最危险的存在形式。
• 修一个 bug 带出两个。回归率持续上升，意味着模块之间的隐性耦合已经超过团队的理解能力。

怎么还才不伤业务

最差的还法是「停线重写」——业务冻结几个月，重写版还没追上旧版的功能，公司先断了粮。我们给陪跑项目的建议是三件事：

• 每月固定拿 15% 到 20% 的研发容量还债。像还信用卡一样还最低还款额以上，不让本金继续滚。这个比例要在排期表里写死，否则永远会被新功能挤掉。
• 新代码不许产生新债。老账可以分期，新账零容忍——否则还债速度永远赶不上欠债速度。
• 先还「利息最高」的那笔。改动最频繁、依赖最多的模块先处理，冷门代码的债可以背着，热门路径的债每天都在收息。

这也是 51Kaifa 做「2 周 MVP」时坚持先过一遍架构评审的原因：快和糙是两回事。两周可以做出一个闭环完整、接口干净的产品，让第一批用户进来验证；但地基必须是直的——因为后面每一块砖，都会压在这块地基上复利计息。

← 返回资讯中心