企业官网建设流程全解析

从 Bad Smell 到 AI Slop：程序员的审美没有过时

摘要：AI 能把代码和文章写得又快又完整，但真正该警惕的是顺滑背后的低密度和不可维护。程序员的价值，正在从亲手写，转向闻出坏味道、删掉不值得留下的东西。

AI 写代码这件事，已经过了新鲜劲。

以前一个接口要写半天，现在几分钟能起一个能跑的版本。写测试、补类型、查 SDK、搭页面、改样式，这些碎活也能交给 AI。效率是真的高，回不去了。

但另一个问题也越来越明显：

代码是多了，东西也跑起来了，可味道不对，我遇到最多的是过度设计、过度兼容。

以前我们管这种东西叫 bad smell。现在换到 AI 时代，它有了一个更粗糙也更准确的名字：slop。
当年《重构》可是奉为圭臬，几乎人手一本。好像不看这本书，就写不了好的代码。

程序员早就知道，代码会有味道

软件工程里有个经典词：Code Smell。以前我们人工做 Code Review 的时候，会尤其关注代码中的坏味道。

它不是说代码已经坏了，也不是说代码一定有 bug。它说的是：这段代码现在能跑，但你一看就知道，后面会出事。

比如一个函数越写越长，一个类什么都管；改一个小需求，要同时动十几个地方；变量名像临时糊上去的；业务逻辑、异常处理、日志、权限、缓存、展示逻辑全堆在一起。这时候就意味着，要重构了。所以，《重构》那本书，当年也被奉为圭臬。我记得有两本，一本就是 Martin Fowler 《重构 改善既有代码的质量》，还有一本是讲通过各种设计模式来做重构的，忘了名字。后来还有重构第二版，早就没有了初版昔日的辉煌和影响力。

所以，当年在鹅厂，还有一门很好的课程《边重构，边生活》，记忆深刻。

这些代码不一定马上报错。上线后也可能稳定跑一阵子。

但有经验的程序员会闻到味道。

bad smell 的可怕之处就在这里。它不是故障本身，而是故障的前兆；它不是 bug，而是未来 bug 容易长出来的土壤。

Martin Fowler 在《Refactoring》里讲 code smell，本质上不是教你洁癖式地追求“代码好看”。他讲的是一件很朴素的事：代码不是写完就结束了。

它会被修改，被扩展，被接手，被排查，被回滚。后来的人会反复进入它。

所以真正好的代码，不只是今天能跑，而是明天还能被人理解。

bad smell 冒犯人的地方，是不可信

很多人对代码质量有误解，以为好代码就是格式漂亮、命名优雅、设计模式多。

不是。

好代码的核心是可信。

我看到这个函数，知道它只做一件事。我看到这个模块，知道边界在哪里。我改这里，不担心别处突然炸掉。我删掉一段逻辑，不需要先考古三天。

我接手这个系统时，不会感觉自己走进一间堆满杂物、灯还忽明忽暗的地下室。

bad smell 真正冒犯程序员的地方，不是它“不美”，而是它让人失去掌控感。

你能跑，我承认。

但我不信你。

AI 让 bad smell 批量生产

AI 写代码带来的最大变化，不是它能写，而是它写得太快。

过去一个人一天只能制造有限的 bad smell。现在一个人带着 AI，一下午可以制造一个小型垃圾场。

它会帮你生成 service、controller、DTO、hook、utils、test、mock、README。目录结构看起来完整，注释也有，类型也有，try-catch 也有。

问题是，很多代码只是“像工程”，不是“是工程”。

它能跑，但说不清为什么这样设计。

它有抽象，但抽象没有边界。

它有分层，但层与层之间互相漏水。

它有测试，但测试只是在证明 mock 没写错。

它有注释，但注释解释的是语法，不是决策。

传统 bad smell 往往是一块地方慢慢坏掉。AI slop 更麻烦，它会一层一层铺满。

代码里的 AI slop 长什么样

我现在 review AI 生成代码，最怕的不是语法错。语法错反而好办，编译器和测试会骂你。

真正麻烦的是那种看起来很完整、很专业、很顺滑的代码。

第一，代码很完整，但没有设计理由。

它能给你生成一整套目录结构，看起来像大厂模板。可你追问为什么要这么分层，为什么这个状态放这里，为什么这个逻辑不下沉，为什么这里需要一个 manager，答案就开始变虚。

第二，代码很顺滑，但没有取舍。

真正的工程一定有取舍：性能和可读性，灵活性和简单性，短期交付和长期维护，统一抽象和局部特例。AI 很容易给你一个“都要”的版本。

结果是，什么都照顾到了，什么都没负责到底。

第三，代码很多，但信息密度很低。

一个很小的功能，被拆出一堆 helper、adapter、mapper、handler、config。每个文件都有内容，但关键判断只有三行。你读了很多，最后发现自己只是绕了一圈。

第四，代码能跑，但和系统不合群。

成熟工程有自己的脾气：错误处理方式、日志习惯、状态管理方式、模块边界、命名约定、测试策略。AI 生成的代码很容易像外来物。坏不在语法，坏在气质不对。

第五，代码看起来专业，但没人真正理解。

提交 PR 的人说：“这是 AI 生成的，我大概看过了。”

Review 的人说：“看起来没问题，测试也过了。”

上线之后，出问题没人敢动。

这就不是提效了。这是把债务包装成资产。

文字类 slop 也是同一种东西

代码只是表达方式之一。

文字类 slop 更常见。

现在网上大量文章、笔记、短视频文案，都有一种熟悉的味道：

“在这个快速变化的时代……”

“真正厉害的人，都懂得……”

“不是 A，而是 B……”

“底层逻辑、认知升级、闭环、赋能、抓手……”

每句话都通顺。每一段都像有道理。

但读完以后，什么也没留下。

它没有具体经验，没有真实场景，没有判断代价，没有人味。它的问题不是错，而是空。

更麻烦的是，它会伪装成高质量。

结构完整，语气自信，标题清晰，排版漂亮。但没有重量。

这和 AI 代码 slop 很像。代码能跑，但没有设计。文章能读，但没有思想。PR 很完整，但没有判断。段落很顺滑，但没有经验。

程序员开始嫌弃机器味，不是矫情

过去很多程序员嫌弃人写的代码。

变量名乱，结构差，风格不统一，抽象随意，注释过期。

于是我们搞规范、review、重构、lint、架构设计、单元测试。说到底，是想把代码从泥地里往工程上拉。

现在 AI 来了。

它把代码写得更快、更顺、更完整。程序员却又开始嫌弃另一种东西：机器生产的千篇一律。

这不是矫情。

这是职业审美在起作用。

真正的程序员并不只是想要代码“有”。他想要代码“对”。

不只是语法对，不只是测试对，而是边界对、责任对、抽象对、取舍对。

写文章也一样。

人不是讨厌 AI 写作。人讨厌的是那种没有观察、没有经历、没有判断、没有摩擦感的惯性表达。

机器可以生成语言。语言有没有重量，是另一回事。

审美没有变，只是对象变了

bad smell 和 AI slop，看起来是两个时代的词。

一个属于传统软件工程，一个属于生成式 AI。

但它们背后的审美是同一种东西。

我们不喜欢失控，不喜欢堆砌，不喜欢假装专业，不喜欢没有判断的完整，不喜欢看起来什么都有、实际上没人负责。

代码的优美，不是炫技。

它是去掉 bad smell 之后留下的清爽结构。

一个模块该做什么，不该做什么，很清楚。一个函数为什么存在，为什么这样写，能说得通。一个架构为什么这么分层，为什么不继续抽象，为什么不提前复杂化，有判断。

文章的优美，也不是辞藻。

它是去掉 slop 之后留下的真实密度。

有具体问题，有真实场景，有自己的判断。有一句话能让人停下来，而不是从模板里复制出来。

AI 时代，人的价值不是手写每一行

所以这不是一篇反 AI 的文章。

我反而认为程序员应该用 AI。不用 AI，很多时候就是低效。

只是用 AI 之后，人的价值会从“亲手写”转向“判断什么值得留下”。

AI 可以把可能性铺得很开，但哪些代码该进主干，哪些段落该删掉，还是得由人拍板。

代码先跑起来不难，难的是把坏味道闻出来，把边界切回去，把设计重新拉回系统里。文章也是一样，初稿可以让 AI 起，但废话要删，空话要压，真实经验要补进去。

未来好的程序员，不一定是最能手写代码的人。

但一定是能闻出味道的人。

他知道这段代码哪里不对，知道这个抽象为什么虚，知道这个模块为什么迟早会炸。也知道这篇文章为什么看起来漂亮，却没有信息量。

更重要的是，他知道什么时候该让 AI 继续写，什么时候该停下来重构，什么时候该直接删掉重来。

最后稀缺的，还是审美

每一轮技术革命都会制造新的垃圾。

博客时代有 SEO 垃圾，移动互联网时代有洗稿垃圾，短视频时代有模板化鸡汤，AI 时代有 slop。

这不奇怪。

Sturgeon’s Law 早就说过，任何事物（特别是用户创造的内容），90%都是垃圾。AI 没有改变这个规律，它只是把生产速度提高了几个数量级。

所以真正的问题不是 AI 会不会写代码、会不会写文章。

真正的问题是：当它什么都能生成时，你还能不能判断什么不该留下？

代码审美、架构审美、文字审美，本质上都是同一种能力：判断什么不该留下。

它要求你看见多余的东西，闻到不对的味道，删掉顺滑但空洞的表达，也拒绝完整但虚假的工程。该简单的地方别装复杂，该复杂的地方别偷懒；每一行代码和每一句话，都要有存在的理由。

AI 会继续变强。代码会越来越容易生成，内容会越来越便宜。

越是这样，人的审美越值钱。

因为机器可以生产“像样的东西”。

但什么是真正好的东西，最后还是要有人判断。

参考资料

• Martin Fowler, CodeSmell：Fowler 把 code smell 解释为代码表面的信号，背后可能藏着更深的问题；他也提到这个词来自 Kent Beck 的讨论。
• Martin Fowler, Refactoring：《Refactoring》把 code smells、测试和保持行为不变的重构放在同一套实践里看。
• AI slop：AI 语境里的 slop，通常指低质量、低价值、批量生产的 AI 生成内容。
• arXiv, An Endless Stream of AI Slop: How Developers Discuss the Burden of AI-Assisted Software Development：这篇 2026 年论文讨论 AI 生成内容对代码、PR、文档和 bug report 的影响，提到 review friction、quality degradation 和 systemic incentives。
• Sturgeon’s Law：这里引用的是那句常见说法：任何事物（特别是用户创造的内容），90%都是垃圾。