软件开发者 Jesse Skinner 6 月 8 日写了一篇文章，提醒团队别把 LLM 编码当成无成本提速。

他的比喻很准：失控的 AI 代理，像一批不会记得昨天工作的“摇滚明星开发者”。他们很快，很炫，提交很多，但留下来的系统未必有人能接住。

这件事有意思的地方不在于“AI 会不会写代码”。它已经能写不少代码了。

真正的问题是：团队是不是正在把工程主导权，让给一个只负责把眼前任务做完、却不承担长期维护的人。

传统“摇滚明星开发者”的坑，被 AI 放大了

Skinner 先讲的是老问题。

很多工程团队都遇到过这类高手：能力强，推进快，喜欢新语言、新框架、新构建流程。短期看，他像救火队长。长期看，代码可能只剩他自己懂。

等人离开，团队才发现麻烦来了。

本地环境难跑，依赖关系绕，抽象层一层套一层。新人不敢改，老人也要翻半天。所谓“摇滚明星”，在这里不是纯褒义，而是带着讽刺：高产，但难协作。

AI 编码把这个模式日常化了。

一个真人高手，至少通常有一套自己的设计意图。你可能不喜欢，但还能追问：为什么这么拆模块，为什么引入这层抽象，为什么选这个库。

LLM 生成的代码不一样。

尤其是 vibe coding，一段实现可能来自多轮对话、多个上下文、几次“修一下”“再改一下”“能跑就行”的拼接。它看起来连贯，但未必有统一设计。

开发方式短期收益长期风险关键差异
真人“摇滚明星开发者”推进快，能解决难题难协作，难接手通常还有个人设计意图
LLM / AI 代理生成快，改动多复杂度和依赖快速膨胀可能只是上下文拼接
稳健工程团队速度不一定最快维护成本可控知识留在团队流程里

这就是 Skinner 警告的重点：代码增长很快，但系统可理解性和可维护性下降。

代码库不是仓库，不能只看进货速度。它更像一套长期运转的机器。每加一个零件，都要有人知道它为什么在那儿。

真正危险的不是生成代码，而是生成“没人敢改”的系统

Skinner 并没有说 AI 写代码一定会让项目失败。

他的判断更像经验性警告：当团队持续接受大段生成代码，复杂度可能比团队理解速度更快。到某个点，开发者需要再问 LLM，才能解释上一轮 LLM 写出来的东西。

这才是新的依赖。

不是依赖工具补全几行代码，而是依赖工具维持系统的可理解性。问题在于，工具本身并不真正拥有这个系统。

LLM 还有一个常见倾向：它喜欢给“完整方案”。

多一层抽象，多一个配置，多一个通用接口，多一点防御式写法。放在大型系统里，有时合理；放在一个简单业务需求里，就可能是过度工程。

模型不知道团队现实。

它不知道这个仓库有几个人维护，不知道谁值班，不知道上线窗口多紧，也不知道两年后谁会接这段代码。它只是在当前上下文里，给出一个看起来合理的答案。

对团队负责人来说，这意味着要把 LLM 使用边界写进流程，而不是只看提效数字。

可以直接落到几条动作：

  • 大段业务逻辑进主干前，必须有人说明设计意图。
  • AI 生成的关键代码，要能标记来源或在评审说明里写清。
  • 新依赖、新框架、新架构层，不能由模型一次性拍板。
  • 看不懂的实现，不允许用“模型说可以”通过评审。

对高频使用 LLM 的开发者来说，动作更简单，也更难坚持。

让模型写小函数、测试、样板代码，可以。让它解释局部逻辑，也可以。

但如果你已经说不清这段代码为什么这样拆、为什么要这个依赖、失败时该从哪里查，就该停一下。别继续让模型“修到能跑”。能跑，只是工程的下限。

接下来要看团队流程，而不是模型一次写多少行

AI 编码工具会继续变强。Cursor、GitHub Copilot、Claude Code 这类工具，也已经进入很多开发者的日常工作流。

但对团队来说，接下来最该看的不是模型一次能写多少行，而是流程有没有跟上。

更具体地说，要看四件事。

观察点好信号坏信号
代码评审要求解释设计意图和取舍只看功能是否跑通
依赖管理新库、新框架需要人工批准模型建议什么就装什么
任务粒度LLM 处理小步、局部、可验证任务一次生成大段模块或架构
责任归属人类开发者确认并承担维护出问题时回头问模型

这里也有现实限制。

小团队、赶进度的团队，最容易把 AI 当作“临时多招了几个人”。这很诱人，因为短期产出确实会变快。

但越是小团队，越承受不起没人懂的复杂系统。代码债不会因为是 AI 写的就打折。

我更在意的是，团队有没有能力对“看起来很聪明”的代码说不。

LLM 应该进工具箱，不该坐上架构师的位置。它可以帮人写得更快，但不能替人决定系统应该长什么样。

Skinner 这篇文章的提醒，最后落在一个很老的原则上：软件工艺和最终责任仍在人类开发者手中。

AI 可以生成代码。可维护性不能自动生成。