把最划算的投资放在第一行代码之前——花两周做架构
而真正能避免这些的是什么？
Davidov 的方法很朴素：把最划算的投资放在第一行代码之前——花两周做架构。他直言：“我知道这很无聊，你也想快点发版，但这两周能帮你省去 18 个月的人间炼狱。”
在这两周里，要从一开始就保持规模化思维，先问“到 1 万用户会爆什么”，而不是“100 个用户能不能跑”。数据库查询、文件上传、后台作业等关键路径，第一天就该具备承接 100× 的空间。同时，自动化测试要从 Day 1 上线。如果不能一键确认“没有把别的地方弄坏”，那每次发布都在赌运气。技术栈选“无聊的”更好。React/Node/Postgres 很无聊，但好招人、有 Stack Overflow 答案、不会在凌晨 2 点突然“猝死”。
外部架构评审也要提前到第一周。用他的话说：“在第一周找一个做过这类事的人来审你的架构。别等到第 12 个月才请，那时太晚了。”
之所以要这么早，是因为有一句不太好听却很真实的话——“大多数技术联合创始人和首批工程师都很会写代码，但从未设计过可扩展的架构。这就像你是一位出色的厨师，却从未在晚餐高峰期管理过餐厅厨房一样。”
“Move fast, break things.”（快速行动，打破常规）的原则在 Facebook 这种可以无限烧钱的公司或许有效。但在你的初创公司里，这就是自杀。因此，每个创业的技术团队都可以先自查一下：当前用户量的 10 倍时，系统会崩在哪？有自动化测试吗？数据库能撑 100 倍查询量吗？若用户增长 10 倍，基础设施成本是否也要暴涨到 $50,000/ 月？
如果这些问题里有一个答案是“我不知道”，那你就是在流沙上建房子。
- 把工程一开始就做对，并不一定更贵；
- 可能只需要 3 个强工程师，就能比 20 个便宜外包干得更快、更稳；
- 反之，“便宜但低效”的外包会在几年里堆出一座技术债垃圾山，最后一文不值。
AI 把“先跑起来”的门槛降到了前所未有的低位
AI 把“先跑起来”的门槛降到了前所未有的低位，也把“慢性死亡”的到来大大提前。模型生成的代码常常“看似可用”，却让技术债积累更快、质量更难判断。
LLM 的创造力与破坏力并存：它既能把想法迅速变成代码，也可能把临时脚手架误当成地基，而代价往往要到第 18 个月才集中显形。
