24个月，从写第一行代码到破产：一位架构师在47个“死亡”项目里，看到的共同陷阱

跑得快，不等于跑得稳。

许多初创公司并非倒在市场竞争的路上，也不是因为“钱花光了”，而是产品无法扩展，被自身积累的代码和混乱的架构困住，最终陷入慢性死亡的绝境。过去 3 年，一位架构顾问审阅了 47 家在“产品无法扩展”节点上求助的初创公司的代码库，惊人地发现它们几乎都沿着同一条时间线走向停滞。

初创公司技术债：死亡时间线 

Gliltech Software 的创始人兼 CEO Meir Avimelec Davidov，专门在初创公司陷入技术危机时介入“救火”。Davidov 明确指出，这些初创公司找到他，往往不是因为他们“烧光了钱”，而是因为他们的代码库和技术栈扩展危机：“产品彻底无法规模化，但却不知道原因何在”。

他发现，在这种情况下，那种导致失败的模式总是会重复出现，无一例外：

第 1–6 个月：一切顺利，节奏很快、疯狂发版、客户开心、生活美好。

第 7–12 个月：开始变慢，出现诡异的 bug，“以后再修”成了团队口号。

第 13–18 个月：任何一个新功能的合入几乎都会牵动三处旧功能；每次部署都压力山大。

第 19–24 个月：又多招了 3 个工程师，他们只是在维护现有一团乱麻，没有人在做新东西。

二十四个月之后，现实把选择压缩成两条：要么从零重写，要么看着系统慢动作地凋亡。

他之所以敢下如此概括，是因为在四十七个代码库里看到的“地基病”高度同质。

最触目的是数据库层面。“大约 89% 完全没有数据库索引。完全没有。” 应用之所以慢，并非离奇 bug 作怪，每次请求都在 100,000 条记录里扫描。资源侧也同样刺眼。约 76% 的公司在云上“买了八倍的机器”，平均利用率只有 13%，“你为一百台付费，却只在用十三台”，每月白烧三千到一万五千美元。

安全侧也很脆弱。将近七成的系统存在足以让安全工程师“心梗”的鉴权漏洞。至于质量保障，最致命的常常不是覆盖率数字难看，而是纯粹的缺席：91% 的团队没有任何自动化测试，于是每一次上线都像玩轮盘赌，没人能“一键确认没把别的地方弄坏”。

如果要换算成本的话，按一名工程师年薪十二万美元来估计，Stripe 的研究表明，开发人员花费 42% 的时间来处理糟糕的代码，所以对于一个 4 人团队来说，3 年内就是 60 多万美元的浪费。在维护垃圾代码的基础上，再加上 20-40 万美元的重建费用，以及重建期间 6-12 个月的收入损失，每家公司的总损失：200-300 万美元。

而很多创始人直到第 18-24 个月才意识到这一点。此时他们刚好凭借漂亮的增长曲线融完 A 轮，却没意识到“增长即将散架”。

“两周架构，十八个月不崩” 

而真正能避免这些的是什么？

Davidov 的方法很朴素：把最划算的投资放在第一行代码之前——花两周做架构。他直言：“我知道这很无聊，你也想快点发版，但这两周能帮你省去 18 个月的人间炼狱。”

在这两周里，要从一开始就保持规模化思维，先问“到 1 万用户会爆什么”，而不是“100 个用户能不能跑”。数据库查询、文件上传、后台作业等关键路径，第一天就该具备承接 100× 的空间。同时，自动化测试要从 Day 1 上线。如果不能一键确认“没有把别的地方弄坏”，那每次发布都在赌运气。技术栈选“无聊的”更好。React/Node/Postgres 很无聊，但好招人、有 Stack Overflow 答案、不会在凌晨 2 点突然“猝死”。

外部架构评审也要提前到第一周。用他的话说：“在第一周找一个做过这类事的人来审你的架构。别等到第 12 个月才请，那时太晚了。”

之所以要这么早，是因为有一句不太好听却很真实的话——“大多数技术联合创始人和首批工程师都很会写代码，但从未设计过可扩展的架构。这就像你是一位出色的厨师，却从未在晚餐高峰期管理过餐厅厨房一样。”

“Move fast, break things.”（快速行动，打破常规）的原则在 Facebook 这种可以无限烧钱的公司或许有效。但在你的初创公司里，这就是自杀。因此，每个创业的技术团队都可以先自查一下：当前用户量的 10 倍时，系统会崩在哪？有自动化测试吗？数据库能撑 100 倍查询量吗？若用户增长 10 倍，基础设施成本是否也要暴涨到 $50,000/ 月？

如果这些问题里有一个答案是“我不知道”，那你就是在流沙上建房子。

同样的问题，一家接一家 

尽管 Davidov 指出的坑听上去很“低级”（也因此受到一些质疑），但评论区里不少一线从业者认可其普遍性。

有读者直言，自己与 Davidov 的工作相近，这些坑“只是冰山一角”，尤其在 AI 爆发后，因为任何能使用类似 Claude Code（指代 AI 编码工具）的人都在快速推出产品。

“看上去光鲜的产品，翻进去就是一地未测试的代码、没人负责、‘不需要文档’，基本不存在架构设计”。他感叹，工程里最有价值的东西常被忽视，“研究与实战都在说别逃避测试”，但不少初创“并不这么想”。

另一位开发者也给出“我也见过”的现场证词。

他目睹过公司花三年做一个六个月就该完成的产品，结果因为初始设计太差，成品只能推倒重来。他还见过一个极可能大卖的软件项目，团队却在上线前按下停机键——不是市场问题，而是架构导致单用户成本过高，“同样的功能，因为坏架构需要 50× 的服务器”。他的总结很现实：

• 把工程一开始就做对，并不一定更贵；
• 可能只需要 3 个强工程师，就能比 20 个便宜外包干得更快、更稳；
• 反之，“便宜但低效”的外包会在几年里堆出一座技术债垃圾山，最后一文不值。

也有人这就是现实本身，并不深奥，归根到底就是自律与基本功。

兄弟，这是我这几周在这儿看到最好的一篇，认真的——句句都是真创始人的伤疤，不是纸上谈兵。但说实话，大多数早期创始人还是不会听：他们会继续用胶带粘功能，嘴上说“以后再重构”，然后当一条两秒的查询把他们 $30k 的 AWS 账单炸穿时再哭。

最离谱的是：这甚至不是什么深奥技术建议，就是基本功和自律——写测试、把表名起好、给查询加索引、别追新闪亮框架。我见过有人在只有 500 个用户时还在吹“我们遇到扩展性问题”，但真相是：他们根本没用后台任务队列或缓存层。

评论区还有人提出了一个灵魂问题：“写得真好。氛围编码在这一切中扮演了什么角色？你现在审计的代码里，有多少是 AI 写的？”这正戳中当下的关键，AI 把“先跑起来”的门槛降到了前所未有的低位，也把“慢性死亡”的到来大大提前。模型生成的代码常常“看似可用”，却让技术债积累更快、质量更难判断。

LLM 的创造力与破坏力并存：它既能把想法迅速变成代码，也可能把临时脚手架误当成地基，而代价往往要到第 18 个月才集中显形。

参考链接：https://old.reddit.com/r/Entrepreneur/comments/1o4jup6/i_audited_47_failed_startups_codebases_and_the/

本文来自微信公众号“InfoQ”，作者：Tina，36氪经授权发布。