拒绝“代码浆糊”:别让 AI 成了你的技术债放大器

软件开发，归根结底还是“思考”的事儿

如果是专业的程序员，AI 用的越多，就会发现很多时候 AI 为了完成一个功能会到处“拉屎”，把系统或者某些模块的结构搞乱，这些可以通过提示词、skills、约束文件解决，但是你还是要付出一些精力去调整。你也需要知道想要什么，什么是好的设计。

软件开发的本质一直没变：把那些模棱两可的人类需求，提炼成精确、严丝合缝的系统。真正的“手艺”全在拆解上：该建立什么样的抽象？边界应该划在哪儿？各个模块之间该如何对话？

现在用 AI 写代码，很容易掉进一个新的陷阱：只有速度，没有结构。

代码生成的确实快，但如果缺乏清晰的系统架构——那些真正的边界、核心的不变量、底层的抽象——你得到的不过是一堆暂时能跑、迟早要崩的“代码堆”。因为底下没有连贯的心智模型支撑，这东西本质上就是一坨“浆糊”（slop）。

AI 并没有取代系统性思维，反而是放大了“不思考”的代价。

如果你自己对结构没数，AI 就会拿它见得最多的套路去填空。结果就是：你用通用的汤底去解具体的问题；本来该泾渭分明的地方，它给你写成了耦合代码；本来一种写法就能搞定，它给你整出三种花样，因为你从来没规定过那个“唯一解”。

随着 Cursor 这类工具开始处理更长的任务链，“大概方向是对的”和“精确理解系统”之间的裂痕会指数级扩大。当 Agent 一口气执行 100 步而不是 10 步时，你的角色非但没有被边缘化，反而变得更关键了。

现在的技能树已经变了：不再是“敲出每一行代码”，而是“在脑海中构建整个系统，并精准传达其精髓”：

• • 定义边界——核心抽象是什么？这个组件该知道什么，不该知道什么？状态到底存在哪？
• • 明确不变量——什么必须永远为真？让系统稳定运转的常量和默认规则是什么？
• • 引导拆解——这事儿该怎么切分？自然的结构长什么样？哪些是稳态，哪些是易变的？
• • 保持连贯——AI 生成的代码越多，你越要盯着它，确保它符合心智模型，遵循既定模式，严守边界。

这正是优秀的架构师和设计师一直在做的事：他们不亲自写每一行代码，但他们把控着系统设计，引导整体走向连贯。你就把 Agent 想象成是一个手速极快、但脑子很直（literal）的团队成员。

真正的危险在于，AI 让你产生了一种“思考可以选修”的错觉，从而跳过了这一步。人们靠写 Prompt 堆出了自己压根看不懂的代码库。没法调试，因为这东西从来就不是“设计”出来的；没法扩展，因为根本没有结构，只有功能的堆砌。

反过来说，那些真正对系统有深度思考的人，现在能跑得比以前快 100 倍。

你把时间花在硬骨头上——理解到底在建什么、为什么要这么建——而把机械的翻译工作交给 AI。既然不被语法细节缠身，你就能在架构层面上停留得更久。

未来的图景不是“AI 取代程序员”，也不是“人人都能写代码”。

真相是：“思路清晰的人能以惊人的速度构建系统，而思路不清的人将通过 AI 批量制造垃圾。”

未来的核心能力在于：驾驭复杂度，干净利落地拆解问题，精准地传达结构。

少一点语法，多一点系统。
少一点实现，多一点架构。
少写点代码，多设计点连贯性。

人类擅长发现模式、权衡利弊、判断事物该如何咬合。
AI 救不了混乱的逻辑——它只会让你的“想不清楚”跑得更快而已。

文章翻译自 Ryo Lu ^[1] ：

引用链接

[1] : https://x.com/ryolu_/status/2019089085034586239?s=20