LLM 让写代码更顺，也更容易把没想透的问题伪装成可运行的软件。
原文链接：AI小老六
如果你最近总觉得，开发速度更快了，但很多东西也更虚了，这篇文章正好把那种别扭感说清楚。
写代码最费时间的部分，往往不是打字。
真正吃时间的，是你被机器一次次拦下来：类型不对、边界没处理、状态转换说不通、接口契约不完整。人写代码时常常抱怨这些细节烦，可很多系统最后能站住，恰恰靠的就是这种烦。
现在不一样了。你把一个还没想透的念头丢给 LLM，它也能很快给你凑出一版能跑的东西。页面有了，接口有了，测试甚至也能顺手来一点。速度当然惊人，问题是，原来那些逼你停下来多想半小时的拦路石，被一脚踢开了。
图：当生成速度变快，原本帮助澄清意图的摩擦也一起被拿掉。
这件事真正的危险，不在于模型会胡说八道。那是老问题。更麻烦的是，它会在很多时候说得差不多、写得差不多、跑得也差不多，于是人很容易误以为自己已经把问题定义清楚了。
传统编程最值钱的，恰恰是它的“较真”
传统编程有一种近乎刻薄的较真。你说错一个类型，它就报错；你漏掉一个分支，它就翻车；你把顺序想反了，结果立刻变味。那套机制一点都不体贴，但它有个好处：
当思路不够清楚的时候，系统会先让你难受。
这种难受以前经常被当成低效。现在回头看，未必。很多设计质量并不是在灵光一现里长出来的，而是在你反复解释、重命名、删改和补边界的过程中被磨出来的。代码不只是把想法实现出来，它还会反过来审问这个想法到底站不站得住。
而 LLM 编程，把这层审问变轻了。
轻到什么程度？轻到很多团队已经习惯先让模型把东西铺开，再由人回头修。这个流程不是不能用，但它很容易把“澄清意图”这件最该先做的事，拖到最靠后。等产品、测试、用户甚至线上事故替你指出问题时，代价通常更高。
旧流程里的摩擦，现在被谁吸收了
有些变化已经很明显了：
| 旧流程里的摩擦 | 现在被谁吸收了 | 常见后果 |
|---|---|---|
| 类型和接口先想明白 | 模型先补一版再说 | 接口表面顺，后期返工多 |
| 边界条件提前暴露 | 运行后再慢慢撞出来 | 线上才发现异常路径 |
| 命名和抽象反复推敲 | 先生成，命名随后再改 | 代码能跑，但意图发虚 |
图：模型接住了表达空白，但很多问题只是被延后暴露。
表面看，开发链路更顺了；本质上，很多原本在前期暴露的问题，被推迟到了后期。
这也是为什么不少团队会出现一种新型失真：
- Demo 很快做出来了，但真正进入联调和上线后，返工量反而更大。
- 代码生成得很完整，但一旦追问异常路径，很多地方其实没想透。
- 评审看起来都能通过，可一落到真实业务约束，抽象就开始发虚。
真正该保住的，不是手写代码这件事
所以，真正值得保住的不是“坚持手写每一行代码”这种姿态。很多重复劳动，本来就该交给工具。该保住的是另外几样东西。
第一，需求在生成前就写成一句不含糊的话。
不是“做个用户系统”，而是“支持邮箱登录、组织隔离、管理员冻结账号，冻结后保留审计记录，但禁止 token 刷新”。话写不清，代码十有八九也清不了。
第二，接口契约别偷懒。
输入是什么，输出是什么，失败时怎么退，谁负责幂等，谁负责重试，这些东西不该让模型替你即兴发挥。它可以帮你展开，不适合替你定规矩。
第三，把评审重点从“这段代码像不像人写的”，改成“这里的意图有没有被说死”。
LLM 代码最容易出的问题，不是语法，而是含糊：看着都对，细问就散。
第四，保留一点必要的摩擦。
比如先写简版 spec，先列风险点，先画状态流转，先把异常路径写在注释里。别嫌这几步慢，它们不是多余动作，而是在给后面省时间。
图：在生成之前先把需求、接口和异常路径说清楚，能省掉后面更贵的返工。
交付更快，不等于思考更好
可以把今天很多开发失真理解成一种错觉：交付速度上去了，于是大家默认思考质量也跟着上去了。其实两者没有自动关系。
软件这门活，真正贵的从来不是把代码敲出来，而是把意图说准确。
模型让表达更省力，这当然是好事。可如果省掉的是思考本身，最后省下来的时间，大概率会在联调、返工、线上事故和团队沟通里连本带利还回去。
真正需要保住的，不是手写代码的仪式感，而是那套在表达中校正思路、在约束里发现漏洞的工作习惯。
推荐阅读
业务 Agent 搭建指南：别急着重造 Agent，用知识、工具与评测跑通闭环
当用户觉得 Agent 变笨时，真正退化的往往不是模型
OpenClaw Dreaming 记忆流水线底层架构：状态分层、证据留痕与检索回流
Claude Code 如何压缩上下文：Microcompact、Prompt Cache 与 cache_edits 工程拆解
AI 编程争论变味了：为什么反 AI 情绪开始走向怀旧化
