有一种提速，最后会变慢

很多人第一次认真用 AI 写代码时，都会经历同一种兴奋：昨天还要自己查文档、翻仓库、补测试，今天只要把需求讲清楚，几分钟就能看到一版结果。

问题往往出在第三天。代码是出来了，可你开始不太敢动它。你知道它大概能跑，但说不清为什么这样写，也不确定下次改动会不会把别的地方带崩。Jeremy 这篇最打人的地方，就在这里。它提醒大家：很多看起来像提速的东西，最后会变成更贵的返工。

真正变贵的，是收拾后果

一段代码如果是你自己慢慢写出来的，你至少知道自己哪里不确定。可一段代码如果是 agent 一口气吐出来的，最容易一起消失的就是边界感。

你不知道它顺手改了多少地方，不知道它有没有把旧约束带丢，也不知道它留下的结构是不是你三周后还愿意维护的结构。模型越会生成，越会把这个问题放大。

所以 Jeremy 其实是在讲一件很工程、也很朴素的事：软件从来不只是写出来，更重要的是它能不能被继续改下去。

对开发者来说，哪些能力会重新涨价

这篇最有价值的地方，在于它让你感觉到哪些基本功会在 AI 时代重新涨价。

第一种，是看懂改动的能力。光“看过 diff”远远不够，你得能看出这次改动真正动了哪层假设。

第二种，是控制修改半径的能力。很多时候，真正成熟的做法，是逼自己把问题切到一个小到能验证、小到能撤回的范围里。

第三种，是保持代码库可维护的能力。AI 非常会帮你把今天做完，但不天然保证它也适合下个月继续接着做。

这也是为什么很多团队前两周会觉得 AI 写代码特别顺，第三周开始就陆续出现一种疲惫感。很多时候，真正冒出来的是系统债开始找上门。

把这件事放到产品和测试视角里

产品最容易被 AI 写代码带偏的地方，是看到 demo 很快，就误以为交付也会很快。测试最容易被带偏的地方，则是看到 happy path 顺了，就误以为系统已经稳定。

但现实经常相反。越是快速生成出来的功能，越需要更早问清楚下面这些问题。

  • 它的边界条件是什么。
  • 出错时谁来接管。
  • 这次改动以后谁来维护。
  • 两周后再改一次会不会明显更痛。

这些问题如果没人问，AI 只会把隐患更快地推到后面。

一个很常见的例子，是让 agent 一次把“登录重构 + 埋点补齐 + 表单校验”一起做掉。当天看着进展惊人，第二周产品一改注册流程，测试一补异常路径，整个链条就开始冒出一串和这次需求看起来没关系的问题。你会发现，真正花时间的根本不是第一次生成，后面每一次追着收拾才更耗人。

对 Agent Engineer 来说，这篇其实在讲 durability

如果把 Jeremy 这篇翻成工程语言，它讲的核心词更接近 durability。也就是：这个系统是不是经得起变化，经得起例外，经得起失败和返工。

很多 agent 产品 demo 时都很顺，但一接上真实仓库、真实业务和真实组织，问题就开始出现。真正 durable 的系统，靠的是它能不能长期承载人和 AI 一起不断修改它。

所以比起“怎么让 agent 多写一点”，更值得先问的是“怎么让这套东西以后还改得动”。

一个更稳的小动作

下次再让 AI 帮你写代码时，试试不要一上来就让它完成整个模块。你可以故意挑一个很小的真实任务，比如只改一个接口超时重试、只补一个回归测试、只清一段重复逻辑。做完后再花 5 分钟问自己三件事：这一步我看懂了吗，这一步我敢回滚吗，这一步我下周还改得动吗。

更新附注

  • 版本：v1.1
  • 更新日期：2026-03-20
  • 更新原因：为系列文章补充统一阅读序号，帮助读者按推荐顺序进入工程实践篇章。