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