LLM 编程提速之后，为什么你反而更难想清楚问题？

LLM 让写代码更顺，也更容易把没想透的问题伪装成可运行的软件。
原文链接：AI小老六

如果你最近总觉得，开发速度更快了，但很多东西也更虚了，这篇文章正好把那种别扭感说清楚。

写代码最费时间的部分，往往不是打字。

真正吃时间的，是你被机器一次次拦下来：类型不对、边界没处理、状态转换说不通、接口契约不完整。人写代码时常常抱怨这些细节烦，可很多系统最后能站住，恰恰靠的就是这种烦。

现在不一样了。你把一个还没想透的念头丢给 LLM，它也能很快给你凑出一版能跑的东西。页面有了，接口有了，测试甚至也能顺手来一点。速度当然惊人，问题是，原来那些逼你停下来多想半小时的拦路石，被一脚踢开了。

图：当生成速度变快，原本帮助澄清意图的摩擦也一起被拿掉。

这件事真正的危险，不在于模型会胡说八道。那是老问题。更麻烦的是，它会在很多时候说得差不多、写得差不多、跑得也差不多，于是人很容易误以为自己已经把问题定义清楚了。

传统编程最值钱的，恰恰是它的“较真”

传统编程有一种近乎刻薄的较真。你说错一个类型，它就报错；你漏掉一个分支，它就翻车；你把顺序想反了，结果立刻变味。那套机制一点都不体贴，但它有个好处：

当思路不够清楚的时候，系统会先让你难受。

这种难受以前经常被当成低效。现在回头看，未必。很多设计质量并不是在灵光一现里长出来的，而是在你反复解释、重命名、删改和补边界的过程中被磨出来的。代码不只是把想法实现出来，它还会反过来审问这个想法到底站不站得住。

而 LLM 编程，把这层审问变轻了。

轻到什么程度？轻到很多团队已经习惯先让模型把东西铺开，再由人回头修。这个流程不是不能用，但它很容易把“澄清意图”这件最该先做的事，拖到最靠后。等产品、测试、用户甚至线上事故替你指出问题时，代价通常更高。

有些变化已经很明显了：

图：模型接住了表达空白，但很多问题只是被延后暴露。

表面看，开发链路更顺了；本质上，很多原本在前期暴露的问题，被推迟到了后期。

这也是为什么不少团队会出现一种新型失真：

所以，真正值得保住的不是“坚持手写每一行代码”这种姿态。很多重复劳动，本来就该交给工具。该保住的是另外几样东西。

第一，需求在生成前就写成一句不含糊的话。

不是“做个用户系统”，而是“支持邮箱登录、组织隔离、管理员冻结账号，冻结后保留审计记录，但禁止 token 刷新”。话写不清，代码十有八九也清不了。

第二，接口契约别偷懒。

输入是什么，输出是什么，失败时怎么退，谁负责幂等，谁负责重试，这些东西不该让模型替你即兴发挥。它可以帮你展开，不适合替你定规矩。

第三，把评审重点从“这段代码像不像人写的”，改成“这里的意图有没有被说死”。

LLM 代码最容易出的问题，不是语法，而是含糊：看着都对，细问就散。

第四，保留一点必要的摩擦。

比如先写简版 spec，先列风险点，先画状态流转，先把异常路径写在注释里。别嫌这几步慢，它们不是多余动作，而是在给后面省时间。

图：在生成之前先把需求、接口和异常路径说清楚，能省掉后面更贵的返工。

可以把今天很多开发失真理解成一种错觉：交付速度上去了，于是大家默认思考质量也跟着上去了。其实两者没有自动关系。

软件这门活，真正贵的从来不是把代码敲出来，而是把意图说准确。

模型让表达更省力，这当然是好事。可如果省掉的是思考本身，最后省下来的时间，大概率会在联调、返工、线上事故和团队沟通里连本带利还回去。

真正需要保住的，不是手写代码的仪式感，而是那套在表达中校正思路、在约束里发现漏洞的工作习惯。