8个月后再看 Build to Last: 代码越来越便宜，判断越来越贵

最近读到 fast.ai 上的一篇文章，叫 Build to Last。

它不是一篇最新文章，发布于 2025 年 10 月底，到现在已经接近 8 个月。

但我觉得它仍然值得在今天重新读一遍。

因为过去 8 个月，AI coding agents 的能力又明显变强了：它们已经不只是帮你补几行代码，而是可以读代码库、改多个文件、运行测试、修 bug，甚至完成一部分完整开发任务。

也正因为如此，这篇文章的问题变得更尖锐：

当 AI 越来越会写代码，人到底还需要理解什么？

1. 这篇文章在讲什么？

《Build to Last》来自 fast.ai。

文章主体是 Jeremy Howard 和 Chris Lattner 的一场对谈。

Jeremy Howard 是 fast.ai 的创始人，长期关注 AI 教育和实践学习。

Chris Lattner 是 LLVM、Clang、Swift、MLIR 背后的关键人物，也是 Modular 和 Mojo 的创始人之一。

如果说普通应用开发像是在盖房子，Chris Lattner 更像是在参与设计“现代软件世界的地基、钢筋和施工方法”。

所以这篇文章的视角，不是“如何快速用 AI 做一个 demo”，而是：

如何在 AI 时代继续建设真正经得起长期演化的软件。

2. 原文最核心的观点

这篇文章并不是反对 AI 写代码。

它反对的是：

因为 AI 能写代码，所以人不再理解自己在建造什么。

原文讨论了几个核心概念。

第一，software craftsmanship

可以理解为“软件工艺”或“软件匠艺”。

它不是把代码写得很漂亮，也不是工程师的职业自恋。

它更接近一种责任：

• 理解自己在解决什么问题；
• 理解系统为什么这样设计；
• 修 bug 时处理根因，而不是只让报错消失；
• 写出来的东西能被别人理解和维护；
• 每次建设都让系统更清晰，而不是更混乱。

文章强调：AI 可以生成代码，但它不能替团队拥有对系统的理解。

第二，architecture

这里的架构不是画一张复杂的技术图。

更重要的是：

• 一个变化应该发生在哪里；
• 哪些模块可以独立变化；
• 一个 bug 会局限在局部，还是扩散到全系统；
• 新功能加入时，系统是变得更清晰，还是更难维护。

一个坏系统不是马上死掉。

它通常是这样变坏的：

每次都能“临时修一下”，但每次修完都更难理解一点。

最后系统还能跑，但没人敢动。

第三，dogfooding

Dogfooding 指团队自己真正使用自己的产品。

文章用 Swift 和 Mojo 做对比。

一个产品如果长期只在设计稿、会议和测试环境里存在，很容易看起来合理。

但一旦你自己真的每天使用，就会更快撞到那些用户很难描述的问题：

• 哪里慢；
• 哪里难懂；
• 哪个流程反人类；
• 哪个错误提示让人崩溃；
• 哪个功能看起来有用，但真实使用时没有价值。

第四，tight iteration loop

也就是紧密的反馈循环。

不要一次让 AI 改一大堆东西，然后最后才发现全乱了。

更好的方式是：

改一点，运行一下；看结果，理解变化；再改一点，再验证。

文章认为，人应该和系统保持连续接触，而不是把整个过程扔给 AI 黑箱。

3. 8 个月后，这些观点还有多少成立？

我觉得可以分三类看。

仍然有效的部分

1. “能跑”仍然不等于“理解”

AI 现在确实更强了。

但一个功能能跑起来，仍然不代表你理解了：

• 数据从哪里来；
• 状态在哪里变化；
• 权限在哪里判断；
• 错误怎么处理；
• 未来新增功能会不会破坏当前结构。

尤其对独立开发者来说，这一点很重要。

因为一个人做产品，没人替你兜底。

如果项目变成你自己也不敢改的黑箱，它虽然是你发布的，但已经不真正属于你。

2. 验证环境变得更重要

过去我们可能觉得，AI coding 的瓶颈是模型不够聪明。

但现在越来越明显的是：

AI 能否做好，很大程度取决于任务是否清楚、代码库是否结构化、测试是否可运行、错误是否能被反馈回来。

也就是说，未来重要的能力不只是“会不会写 prompt”。

还包括：

你能否为 AI 建立一个清晰、可验证、可迭代的工作环境。

3. 专业判断没有消失，反而更值钱

AI 可以给出很多方案。

但它不能替你判断：

• 这个问题是否值得解决；
• 这个复杂度是否必要；
• 这个技术债能不能接受；
• 现在应该快一点验证，还是慢一点打地基；
• 哪些地方可以糊弄，哪些地方绝对不能糊弄。

当代码变得便宜，判断反而变贵。

被挑战的部分

1. AI 对系统的理解已经比 8 个月前更强

如果文章当时隐含的判断是“AI 还不太理解复杂系统”，那今天需要修正。

现在的 coding agent 已经可以读很多文件、追踪上下文、运行测试、根据错误继续修改。

它们不再只是高级自动补全。

在边界清楚、测试完善、目标明确的任务里，AI 已经能完成相当多实际开发工作。

所以不能再简单说：

“AI 不懂系统。”

更准确的说法是：

AI 能理解一部分显性系统，但仍然难以拥有完整的隐性上下文。

它可以读代码。

但不一定知道：

• 三年前为什么这样妥协；
• 哪个客户依赖一个奇怪逻辑；
• 哪个功能看起来没用但不能删；
• 哪个需求背后其实是商业、合规或组织问题。

2. “build to last”不适合所有阶段

Chris Lattner 做的是 LLVM、Swift、MLIR 这类基础设施。

这些系统天然需要长期、稳定、可演化。

但独立开发者早期做 MVP 时，目标往往不是“十年架构”。

目标是先搞清楚：

有没有人需要？用户是否理解？他们愿不愿意开始使用？这个问题是否值得继续做？

如果一开始就按基础设施级别设计，很容易变成高级拖延。

所以这篇文章不能被理解成：

“任何小产品都要从第一天开始追求完美架构。”

更合理的顺序是：

还不知道值不值得做时，build to learn。确认值得长期做时，再 build to last。

被验证的部分

1. AI 越强，越需要人定义边界

AI 最适合处理边界清楚的任务。

例如：

• 修一个明确 bug；
• 增加一个具体字段；
• 重构一个明确模块；
• 根据失败测试继续修改；
• 解释某段代码为什么出错。

但很多真正重要的问题，边界本来就是模糊的。

例如：

• 用户到底为什么不用？
• 产品定位是否错了？
• 是否应该继续做这个方向？
• 这个功能是必要，还是我在逃避获客？
• 当前最小可行版本到底应该小到什么程度？

这些问题，AI 可以帮你分析，但不能替你承担判断。

2. 只会“让 AI 生成”，会越来越不够

AI coding 降低了做东西的门槛。

这很好。

但也意味着，未来能做出 demo 的人会越来越多。

真正稀缺的可能变成：

• 你能不能定义一个真实问题；
• 你能不能判断什么值得做；
• 你能不能理解系统关键部分；
• 你能不能持续从用户反馈中修正产品；
• 你能不能在速度和质量之间做清醒取舍。

也就是说，AI 时代不是不需要能力。

只是能力的重心变了。

4. 对独立开发者的参考

我觉得这篇文章对独立开发者最有价值的地方，不是叫你把代码写得多优雅。

而是提醒你：

不要做出一个自己不理解、也不敢维护的产品。

可以具体拆成几条建议。

1. 早期先 build to learn

在需求没验证前，不要过度工程化。

你真正要验证的是：

• 用户是否有这个问题；
• 是否愿意开始使用；
• 是否愿意完成关键流程；
• 是否愿意回来；
• 是否愿意付费或推荐。

这个阶段，AI 帮你快速做出来是好事。

不要一开始就追求完美架构。

2. 但关键部分不能完全黑箱

哪怕你不是工程师，也至少要理解：

• 核心数据存在哪里；
• 用户登录怎么处理；
• 权限在哪里检查；
• 哪些信息涉及隐私；
• 出错时怎么定位；
• 部署在哪里；
• 如果数据库错了，会影响什么。

你不一定要亲手写每一行代码。

但你要知道产品的骨架在哪里。

3. 每次让 AI 改小一点

不要经常丢给 AI 一个巨大任务：

“帮我把整个产品重构一下。”

更好的方式是：

“先解释你准备改哪些文件。”“为什么要这样改？”“这个改动如何验证？”“有没有更简单的方案？”“如果这次改错，最可能影响哪里？”

独立开发者不只是 AI 的需求方。

也应该是 AI 的 reviewer。

4. 把 AI 当成学习工具，而不是只当外包工程师

每次 AI 写完重要代码，都可以多问几句：

• 这段代码的作用是什么？
• 为什么放在这个文件？
• 还有哪些替代方案？
• 这里最容易出 bug 的地方是什么？
• 我应该如何自己验证它？

如果每做一个功能，你都多理解一点系统，那么 AI 不只是帮你提高产出，也在帮你积累能力。

如果每次只是复制、运行、报错、再让 AI 修，你得到的可能只是一个项目，而不是能力。

5. 对从业者的参考

这篇文章不只对独立开发者有用。

对产品经理、设计师、工程师也一样。

AI 会让很多执行型产出变得便宜：

• 文案；
• 页面；
• demo；
• 代码；
• 方案；
• 总结；
• 测试用例。

但这也意味着，只会交付这些产出本身，可能不再足够。

更重要的是：

• 你是否能定义正确的问题；
• 你是否能判断用户真正需要什么；
• 你是否能识别方案背后的风险；
• 你是否知道什么时候该快，什么时候该慢；
• 你是否能让团队对系统有共同理解；
• 你是否能对结果负责。

AI 可以提高执行力。

但它不会自动给你判断力。

6. 我自己的理解

这篇文章的标题叫 Build to Last。

但我不想把它理解成“所有东西都要建得很重”。

对独立开发者来说，更现实的版本可能是：

先 build to learn，再 build to last。

先用最快的方式接触真实用户，验证问题是否成立。

如果不成立，就优雅放手。

如果成立，再认真建设：

数据结构、权限、稳定性、可维护性、用户体验、长期路线。

否则会出现两个极端：

一端是过早追求长期主义，结果产品还没验证，自己先被架构困住。

另一端是永远只做一次性代码，最后产品稍微有点用户，就开始变成废墟。

这篇文章对我的提醒是：

AI 可以帮我们建造得更快。

但我们仍然要决定：

什么值得建；为什么这样建；哪些地方可以快；哪些地方不能糊弄；以及这个产品未来是否还能继续生长。

代码可能越来越便宜。

但理解、判断和责任感，可能会越来越贵。