背景

今天读了一篇文章：Vibe coding 为什么容易陷入代码腐烂，感觉内容直插核心，一下子说中了我在开发中感觉奇怪的地方：AI写的代码非常漂亮，结构整齐，bug很少。但在进行了多轮迭代之后，总有一种说不出来的屎山感。

这篇文章从easy和simple不同的含义上切入，说出了看似同义，实则有不同含义的两个单词之间的区别。

Simple Made Easy

2011 年 Rich Hickey 在 Strange Loop 大会做了一个演讲，叫 Simple Made Easy。他是 Clojure 的作者。这个演讲里他区分了两个英文词：simple 和 easy。

Simple 的词源是"一折"，指没有缠绕——一个概念就是一个概念，不和别的东西交织。它的反义词是 complex，“编织在一起”。

Easy 的词源是"躺在旁边"，指手边的、熟悉的、当下顺的东西。反义词是 hard，需要用力。

Hickey 的核心观点是：这两个词在日常英语里被当作同义词，但它们描述的是两件不同的事。Simple 描述的是对象本身的结构——它里面有没有不必要的缠绕。Easy 描述的是对象和使用者之间的关系——使用者熟不熟悉它。

从这个区分出发有一个推论：simple 是客观的，easy 是相对的。一段代码里有没有被不必要地缠在一起的概念，这件事不依赖谁在看。但 easy 依赖谁在看——同一段 Haskell 对老手 easy，对新手 hard。

Hickey 认为软件行业有一个长期的毛病，就是把 easy 当成了 simple。选型时问"好上手吗"、code review 时说"读起来挺顺"，这些标准都在 easy 这一侧。很少有人在问：这段代码里有没有被不必要地缠在一起的东西。

这个区分为什么重要？因为 easy 只在写代码那一刻给收益——“顺手”、“熟悉"都是那一刻的感受。但代码交付之后还要被改、被接手、被长期维护。simple 的收益体现在这些后续阶段，而 easy 不提供这些后续收益。

Hickey 在演讲末尾留了一个词：complect，意思是"把本来可以分开的东西缠到一起”。他认为工程师最重要的能力是能识别代码里这种不必要的缠绕。

AI 时代下工程师更应该注重 complect

在 AI coding 下，工程师和 AI 之间应该有一个明确的分工。

• AI 负责产出。我们没有理由放弃放弃它的速度优势。
• 人负责识别缠绕。

这种分工对工程师的要求和过去不一样。过去工程师的核心价值在"能不能写出这段代码"。在 AI 能快速写出大部分代码的前提下，核心价值转到了"能不能识别这段代码里有没有不必要的缠绕"。

识别缠绕是一种判断力，而不是一种技能。技能可以通过看教程和练习快速获得，判断力只能通过长期维护项目、经历自己的设计错误、承担设计错误的后果来养成。

所以下一阶段工程师之间真正的差距，不会出现在产出速度上。差距会出现在判断力上。能在 AI 产出的代码里识别出哪些缠绕是必要的、哪些是不必要的，能在接受之前做出取舍，这种能力现在看起来很隐性，但它的稀缺性会越来越明显。

能力层面有一个次生问题：识别 simple 和 easy 的差别是一种需要长期维护经验才能养出来的能力，而 AI 让新手可以绕过这种经验直接产出代码。结果是产出速度被 AI 抬起来，但判断力没有跟上。

在 AI 的高速输出中把不必要的缠绕挡在外面。Hickey 十四年前讲过的事，在 AI coding 下变成了一个更紧迫的问题。