从 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, CodeSmellFowler 把 code smell 解释为代码表面的信号背后可能藏着更深的问题他也提到这个词来自 Kent Beck 的讨论。Martin Fowler, Refactoring《Refactoring》把 code smells、测试和保持行为不变的重构放在同一套实践里看。AI slopAI 语境里的 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%都是垃圾。
从 Bad Smell 到 AI Slop：程序员的审美没有过时
从 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, CodeSmellFowler 把 code smell 解释为代码表面的信号背后可能藏着更深的问题他也提到这个词来自 Kent Beck 的讨论。Martin Fowler, Refactoring《Refactoring》把 code smells、测试和保持行为不变的重构放在同一套实践里看。AI slopAI 语境里的 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%都是垃圾。
