TL;DR

容易是近，简单是远。AI 让”容易”触手可及，却让”简单”更难实现。

AI 工具正在前所未有地降低生产门槛，让每个人都能快速生成代码、部署应用、自动化工作流。但与此同时，它也在系统性地隐藏复杂性，制造认知债务，让我们误以为”能跑就行”就是胜利。本文从 Rich Hickey 的经典演讲出发，探讨如何在 AI 时代守住简单性的防线——因为简单才是长期价值的真正来源。

📋 本文结构

  1. Rich Hickey “Simple Made Easy” 演讲回顾
  2. 简单性 vs 容易性的对比分析
  3. AI 让”容易”变得更容易
  4. 但 AI 让”简单”更难
  5. 如何在 AI 时代追求简单性
  6. 反直觉洞察
  7. 实战指导
  8. 结语

1. Rich Hickey “Simple Made Easy” 演讲回顾

2011 年，Clojure 语言的创造者 Rich Hickey 在 Strange Loop 会议上发表了一场足以改变软件工程思维的演讲：“Simple Made Easy”。

这场演讲的核心是一个看似简单的区分：

简单 (Simple)

“Simple” 的词根是 “simplex”，意为单一的、不交织的、一个念头、一个任务、一个角色。

简单性是客观的、关于交织程度的度量：

  • 一个组件只做一件事
  • 各部分之间不纠缠
  • 理解 A 不需要理解 B
  • 可以独立地推理、测试、修改

容易 (Easy)

“Easy” 的词根是 “ease”，意为近在咫尺、触手可及。

容易性是主观的、关于熟悉程度和获取难度的度量：

  • 我知道这个东西，所以对我来说很容易
  • 它就在手边，不用费力去找
  • 教程很多，社区很大
  • 用起来顺手，API 设计符合直觉

关键洞察

Hickey 用一句话点破了程序员的集体幻觉：

“我们选择容易，是因为简单很难。”

我们倾向于使用熟悉的工具（容易），即使它们引入了不必要的复杂性。我们选择能快速上手的技术（容易），却忽视了长期维护的噩梦。我们把”感觉不错”当成”设计良好”。

2. 简单性 vs 容易性的对比分析

让我们用三个维度来深入理解这个区别：

2.1 心智负担 (Mental Burden)

维度 容易性 简单性
短期 低（熟悉就好） 可能较高（需要理解）
长期 累积爆炸（债务利息） 保持稳定（一次理解，永久受益）
团队协作 依赖个人熟悉度 客观可传递

例子：一个使用 50 个 npm 依赖的 React 项目对熟悉 React 生态的人来说是”容易”的。但当其中一个依赖升级导致连锁反应时，理解整个依赖图的交织程度才是真正的复杂度——这就是”简单性”要解决的问题。

2.2 组合性 (Composability)

简单的东西天然可组合。容易的东西往往互相缠绕。

Hickey 指出：

  • 简单组件像乐高积木，可以任意组合
  • 容易的工具往往假设特定上下文，难以抽离重用
  • 真正的复用来自简单性，而非便利性
;; 简单的函数：只做一件事，无副作用
(defn calculate-total [items]
  (reduce + (map :price items)))

;; 容易但不简单的函数：做了太多事，隐藏副作用
(defn process-order [order]
  (let [total (calculate-total (:items order))]
    (save-to-database order)      ;; 副作用
    (send-email (:email order))   ;; 副作用
    (update-inventory order)      ;; 副作用
    (log-audit-trail order)       ;; 副作用
    {:status :success :total total}))

第二个函数用起来”容易”——一行代码搞定所有事。但它把计算、存储、通信、日志全部交织在一起，既不简单，也难以测试和复用。

2.3 认知负载 (Cognitive Load)

认知科学家 John Sweller 的研究表明：工作记忆是有限的。当我们处理交织的系统时，认知负载会迅速超载。

容易性的陷阱：

  • 看起来很顺手 → 实际隐藏着复杂的依赖链
  • API 设计符合直觉 → 背后做了太多魔法
  • 一行代码搞定 → 但不知道它在什么情况下会失败

简单性的价值：

  • 需要更多时间理解 → 但一旦理解，就可以预测所有行为
  • 显式而非隐式 → 没有黑魔法
  • 局部完整 → 不需要在脑子里装下整个系统

3. AI 让”容易”变得更容易

2023 年以来，AI 编程工具的普及正在重新定义”容易”的边界：

3.1 快速生成

  • Cursor / Copilot：几行注释就能生成完整功能
  • Claude / GPT：复杂的算法问题秒级解决
  • v0.dev：一句话描述生成完整 UI 组件

3.2 一键部署

  • Vercel / Railway：Git push 就上线
  • Supabase：数据库 + 认证 + 存储一站式解决
  • AI 生成的 Terraform：基础设施即代码从未如此简单

3.3 自动化工作流

  • n8n / Make：拖拽式自动化
  • AI Agent：自主完成多步骤任务
  • 低代码平台：不写代码也能”开发”

3.4 容易性的新高度

AI 让”容易”达到了前所未有的高度：

你甚至不需要”熟悉”某个技术栈，只需要描述你想要什么。

这对入门者是福音，对生产力是倍增器。但我们必须警惕：当”容易”的门槛降到接近于零，简单性的价值反而更加稀缺。

4. 但 AI 让”简单”更难

这是一个反直觉的事实：AI 在让”容易”变得更容易的同时，正在系统性地让”简单”变得更难。

4.1 隐藏复杂性

AI 生成的代码往往：

  • 工作，但不知道为什么工作
  • 处理了边界情况，但你不知道边界在哪
  • 引入了依赖，但你不知道依赖什么
# AI 生成的代码：看起来很简单
def process_data(df):
    return df.groupby('category').agg({
        'value': 'sum',
        'count': 'count'
    }).reset_index()

# 但背后隐藏着：
# - pandas 的 GroupBy 内部实现
# - 内存使用模式
# - 对 NaN 的处理逻辑
# - 索引的行为变化

你得到了容易（几行代码搞定），但你失去了简单（你无法在脑子里完整推理这段代码的行为）。

4.2 黑盒系统

AI 本身就是最大的黑盒：

  • 你无法知道它为什么给出这个答案
  • 你无法预测它在边界情况下的行为
  • 你无法真正”理解”它生成的代码

当我们把越来越多的系统构建在 AI 生成的代码之上时，我们是在构建一座复杂性债务的金字塔。

4.3 认知债务

认知债务：当下省下的理解成本，未来要连本带利偿还。

AI 编程的最大风险不是代码质量——代码可以工作。风险在于：

  • 你从未真正理解你构建的东西
  • 当需要修改时，你必须从头理解
  • 当 AI 给出的答案冲突时，你无法判断哪个更好
  • 你的”编程能力”实际上在退化，因为你越来越依赖 AI

4.4 复杂性扩散

AI 让每个人都能快速生成代码，结果是：

  • 更多的代码被生产出来
  • 更多的系统被快速搭建
  • 更多的复杂性被制造和传播
  • 而理解这些复杂性的能力没有相应增长

AI 不是在消除复杂性，而是在转移和扩散复杂性。

5. 如何在 AI 时代追求简单性

既然 AI 让简单更难，我们该如何反击？以下是实战策略：

5.1 理解优先，生成其次

规则：在接受任何 AI 生成的代码之前，确保你能向一个 5 岁的孩子解释它在做什么。

实践：

  1. 让 AI 生成代码
  2. 逐行阅读，标记不理解的部分
  3. 追问 AI 直到完全理解
  4. 必要时重写，用你自己的表达方式

5.2 显式优于隐式

规则：宁可多写几行显式代码，也不要依赖”魔法”。

反例（AI 可能生成的）：

# 隐式魔法：你不知道发生了什么
result = magic_pipeline(data)

正例（简单性优先）：

# 显式步骤：每一步都清晰可见
validated = validate_schema(data)
transformed = apply_transforms(validated)
filtered = remove_outliers(transformed)
result = aggregate_by_key(filtered)

5.3 小步快跑，频繁验证

规则：用 AI 生成小的、可验证的单元，而不是大块的黑盒。

实践：

  • 一次只生成一个函数
  • 立即测试它是否按预期工作
  • 理解它的边界情况
  • 然后再生成下一个函数

5.4 保持架构简单

AI 擅长填补细节，但不擅长做架构决策。架构简单性是你的责任：

  • 限制依赖数量：每个依赖都是未来的债务
  • 模块化设计：高内聚，低耦合
  • 单一职责：一个模块只做一件事
  • 显式边界：API 契约清晰，没有隐藏通道

5.5 投资于理解

省下的打字时间，应该投资于思考时间。

用 AI 节省下来的时间：

  • 阅读优秀的代码，学习什么是真正的简单
  • 研究底层原理，理解抽象之下是什么
  • 重构你的代码，让它更简单
  • 写文档，强迫自己对齐理解

6. 反直觉洞察

洞察 1：AI 让差程序员更差

没有能力判断代码质量的程序员，会被 AI 大量生产的低质量代码淹没。

AI 是放大器：

  • 好程序员 → 更快地产出高质量代码
  • 差程序员 → 更快地产出垃圾

洞察 2：简单是防御性策略

在一个 AI 快速变化的世界里：

  • 复杂的、交织的系统难以适应变化
  • 简单的、模块化的系统更容易被 AI 辅助重构
  • 简单性是对抗不确定性的最佳防御

洞察 3：理解比产出更有价值

在 AI 可以无限产出代码的时代：

  • 能产出代码的人不值钱
  • 能理解系统、做出正确决策的人值钱
  • 你的理解能力是你的护城河

洞察 4：简单性需要纪律

AI 让”容易”变得毫不费力，这让坚守”简单”变得更难——但也因此更有价值。

当所有人都在追求速度时，选择深思熟虑就是差异化。

7. 实战指导

场景 1：新项目启动

不要这样做：

  • “帮我生成一个全栈 SaaS 模板”
  • 接受所有推荐的依赖
  • 不理解架构就开始编码

要这样做：

  • 先手写架构决策记录 (ADR)
  • 明确核心领域模型
  • 用 AI 填充细节，但保持架构简单
  • 限制技术栈范围（3-5 个核心技术）

场景 2：功能开发

不要这样做：

  • 直接粘贴 AI 生成的代码
  • 不测试边界情况
  • 不理解就部署

要这样做：

  • 先写测试用例（人类思考，AI 辅助）
  • 让 AI 生成实现
  • 逐行审查，确保理解
  • 重构为更简单的形式
  • 再部署

场景 3：代码审查

关键问题：

  1. 这段代码做了什么？（功能）
  2. 为什么这样做？（意图）
  3. 什么情况下会失败？（边界）
  4. 能否更简单？（简化）

如果无法回答这些问题，不管代码是否”能跑”，都不应该合并。

场景 4：技术选型

评估矩阵：

技术 容易性（短期） 简单性（长期） 决策
框架 A ⭐⭐⭐⭐⭐ ⭐⭐ ❌ 拒绝
框架 B ⭐⭐⭐ ⭐⭐⭐⭐⭐ ✅ 选择
框架 C ⭐⭐ ⭐⭐⭐ ⚠️ 权衡

原则：在容易性和简单性冲突时，选择简单性。

8. 结语

“我们必须接受简单的痛苦，才能避免复杂的灾难。” —— Rich Hickey

AI 时代给了我们前所未有的”容易”。我们可以在几分钟内搭建原型，在几小时内部署产品，在几天内验证想法。这是技术的胜利，也是人类创造力的解放。

但与此同时，我们也面临着简单性被系统性侵蚀的风险：

  • 复杂被隐藏，而不是被消除
  • 理解被外包，而不是被培养
  • 债务被累积，而不是被偿还

选择简单是一种纪律。

它意味着：

  • 在能跑就行的时候，选择理解为什么能跑
  • 在快速迭代的时候，保持架构整洁
  • 在 AI 给出答案的时候，追问背后的原理
  • 在所有人都追求速度的时候，选择深思熟虑

简单不是容易的对立面，而是容易的进化形态。

容易让我们开始，简单让我们走得更远。

在这个 AI 让”容易”触手可及的时代，追求简单，就是追求长期的竞争优势。

📚 延伸阅读

  1. Simple Made Easy - Rich Hickey (2011) - 必看演讲
  2. A Philosophy of Software Design - John Ousterhout - 简单性实战指南
  3. The Pragmatic Programmer - Andrew Hunt & David Thomas - 实用主义编程哲学
  4. Clojure 语言 - Rich Hickey 的简单性实践

“简单是终极的复杂。” —— 列奥纳多·达·芬奇

“在软件中，唯一的好复杂性是不存在的复杂性。” —— Rich Hickey

写在 2026 年初春，AI 编程工具普及一周年之际。愿我们在追求效率的同时，不忘守护简单。