Jeremy Howard 真正想保住什么

Jeremy Howard 这篇文章真正想守住的，重点是另一件更现实的事：当生成速度大幅提升之后，什么东西还必须留在团队手里，不能一起外包给模型。答案并不浪漫，理解、判断、反馈和长期维护能力都还得是自己的。

这篇和很多「AI 提效经验帖」的差别，在于它是在问什么样的快法，不会把团队带进一地鸡毛的代码库。它把讨论从「模型强不强」重新拉回「系统以后还改不改得动」。

文章里最硬的几个提醒

  • 软件从来不只是被写出来，更重要的是它以后还能不能被继续改下去。
  • AI 可以显著提高生成速度，但如果团队提前放弃理解、定位问题和控制改动半径，后面的返工成本会更高。
  • 紧密反馈回路仍然是关键，无论是自己真的使用自己的工具，还是让系统在真实场景中持续暴露问题。
  • 这篇反复强调 durability，本质是在问：这套系统经不经得起未来的变化、例外和多人协作。
  • 真正会被重新定价的，「能不能看懂、敢不敢回滚、以后还改不改得动」。

对今天做 AI 产品和工程还有什么意义

对开发者来说，这篇最适合拿来当节奏矫正器。很多人第一次大规模用 AI 写代码时，最容易犯的错就是把「更快」误解成「可以更少理解」。Jeremy 这篇刚好反过来提醒你，真正 durable 的团队会把 AI 用在提速上，但不会把系统理解力一起交出去。

对产品和测试也一样。demo 变快不等于交付更快，happy path 跑通也不等于系统已经稳定。越是高速生成的功能，越需要更早想清楚边界条件、失败处理和维护责任。AI 帮你压缩的是产出时间，不是后续维护的物理成本。

说明

这页是基于原文的中文摘译与导读，不是官方全文翻译。关键表述和细节请以原文为准。

更新附注

  • 版本：v1.1

更新日期：2026-04-02 更新原因：纳入全站文本风格整改的 digest 首批，重写标题、摘要和主体段落动作，减少「AI 提效经验帖」口吻，把重点收回系统可维护性与团队基本功。