Worse is Better 的重新审视：AI 时代的好与坏

TL;DR

本文核心观点：

Worse is Better 不是妥协 — 它是系统设计的元策略，在约束条件下追求最优解

AI 正在加速这一范式 — 生成代码的”足够好”哲学，让迭代速度超越完美主义

好代码 vs 快代码是伪命题 — 真正的问题是”在什么阶段追求什么质量”

系统演进的新逻辑 — 从”设计完美系统”到”设计能进化的系统”

Richard Gabriel 的经典论述回顾

1989 年：Lisp 社区的惊天论战

故事要从 Lisp 和 C 的恩怨说起。

1989 年，Richard Gabriel（Lisp 程序员、诗人、Sun 公司工程师）写了一篇引发轩然大波的文章：《Lisp: Good News, Bad News, How to Win Big》。

在这篇文章中，他提出了一个令 Lisp 社区震惊的观点：

C 语言之所以赢了，正是因为它”更糟”。

当时的争论

Lisp 阵营的观点（The Right Thing）：

正确性第一：设计必须完美无缺
完整性优先：所有功能必须完整实现
一致性至上：整体风格统一
复杂性可接受：为了正确性，复杂一点没关系

C 阵营的”胜利”（Worse is Better）：

简单性第一：实现简单比界面简单更重要
正确性其次：大致正确即可
一致性再次：局部一致就行
完整性最后：不完整也没关系

Gabriel 观察到：Unix 和 C 正是靠着这种”将就”的设计哲学，击败了技术上更优雅的 Lisp 系统。

💡 Key Insight

技术的胜利不取决于技术本身的优雅程度，而取决于它的传播速度和适应能力。

一段被误解的历史

Gabriel 的原文标题其实是讽刺性的。他后来澄清：

“Worse is Better 是一种描述，不是处方。我在描述 Unix 为什么成功，不是在说’你们都应该这么做’。”

但历史开了一个玩笑——这个概念被广为传播，并被许多人当作设计准则。

我们的问题是：在 AI 时代，这个概念需要重新审视。

Worse is Better 的核心逻辑

四个维度的权衡

Gabriel 提出了软件设计的四个核心属性：

属性	The Right Thing	Worse is Better	含义
简单性	界面简单	实现简单	用户易用 vs 开发者易实现
正确性	完全正确	大致正确	无缺陷 vs 可接受缺陷
一致性	整体一致	局部一致	全局统一 vs 部分统一
完整性	功能完整	覆盖主要场景	100% 完整 vs 80/20 法则

元策略的本质

Worse is Better 真正的洞见在于：

它识别了”适应度景观”（Fitness Landscape）中的局部最优陷阱。

想象你在爬山：

The Right Thing 的问题：追求完美设计需要太多前置信息，等你设计完，市场已经变了。

Worse is Better 的智慧：快速获得一个可用的版本，在真实世界中学习，然后迭代。

Fitness Landscape: Worse is Better vs The Right Thing

图 1：Fitness Landscape——Worse is Better 接受局部最优，快速迭代；The Right Thing 追求全局最优，但路径更长、风险更高。

Iteration Flywheel: Worse is Better + AI

图 2：Worse is Better 迭代飞轮——快速发布 → 获取反馈 → AI 迭代 → 持续进化，代码生成成本趋近于零使快速试错成为主动策略。

复利效应

为什么”更糟”的系统往往最终”更好”？

这不是妥协，这是复利。

每次迭代的反馈都会让下一轮迭代更精准。AI 生成代码后，用户行为告诉你哪些功能真正被使用，错误日志告诉你哪些路径需要加固。这些真实世界的信号会以复利的方式累积——每一次迭代都比上一次更贴近用户需求。

关键在于适应度景观的形状在改变。没有 AI 时，迭代成本高，每一次”将就”都在增加以后的修改负担。但当代码生成成本趋近于零时，迭代本身变成了优势：你在真实环境中学习的次数越多，你的系统适应度越高，而竞争对手还在设计室里打磨”完美架构”。

复利的另一层含义是能力积累。你的团队在使用 AI 工具快速验证的过程中，学会了三件事：什么功能用户真正需要、什么代码模式 AI 最擅长、什么错误会反复出现。这三种知识形成组合效应，让后续每一轮迭代都更快、更准。技术债在这个过程中不是被”还掉”，而是被”用掉”了——你用真实反馈换来了更有价值的东西。

💡 Key Insight

Worse is Better 的复利来自真实反馈的累积。AI 让迭代成本趋近于零，所以迭代次数越多，系统越适应，复利效应越明显。

AI 时代的重新审视：好代码 vs 快代码

被混淆的两个维度

在讨论代码质量时，我们经常混淆两个独立维度：

关键洞察：Worse is Better 不是右下角（烂代码+快），而是右上角（够好+快）。

AI 如何改变游戏

在 AI 时代，情况发生了根本性变化：

变化 1：生成成本趋近于零

在传统时代，每一行代码都需要人工编写，生成成本高昂；而在 AI 时代，生成代码的成本趋近于零，我们可以快速生成大量代码并进行实验。

传统时代，代码由人工编写，每一行都有成本——你不可能快速生成十个版本的代码去测试哪个方向是对的。

AI 时代，代码生成成本趋近于零，你可以同时尝试十个方向，让真实反馈来筛选，而不是靠直觉猜测。

变化 2：迭代成本大幅降低

传统时代，”先发布再迭代”是有成本的：代码写得烂意味着以后改起来痛苦，架构设计差意味着重构需要大规模改动，测试覆盖低意味着不敢轻易修改。每一次将就都在增加未来的修改负担。

AI 时代，这个成本曲线完全逆转：代码写得烂？让 AI 重构，两小时完成。架构设计差？让 AI 重新设计，原有代码可以作为上下文参考。测试覆盖低？让 AI 生成测试，批量补齐。

这不是”将就”，而是”主动选择迭代作为策略”——因为迭代的成本从”高代价”变成了”低成本”。

💡 Key Insight

AI 让 Worse is Better 从”无奈之选”变成了”主动策略”。我们不再因为”改不起”而将就，而是因为”改得起”而快速试错。

案例分析：初创公司的技术债陷阱

场景 A：传统思维

某初创公司 founder 是技术大牛，坚持”The Right Thing”：

花了 3 个月设计完美的微服务架构
每个服务都有完整的测试覆盖
代码规范严格执行
文档齐全

结果：

6 个月后才发布 MVP
市场验证失败，产品方向错误
所有”完美设计”都变成了沉没成本

场景 B：Worse is Better + AI

另一家初创公司：

用 AI 1 周生成 MVP
代码质量一般，但核心功能可用
快速投放市场，获取用户反馈
发现产品方向错误
用 AI 1 周重写核心模块
再次验证，找到正确方向

结果：

3 个月内完成市场验证
产品方向正确，获得融资
随后逐步重构核心系统

反直觉结论：场景 A 的”完美代码”最终一文不值，场景 B 的”将就代码”创造了真实价值。

AI 生成代码的”足够好”哲学

什么是”足够好”（Good Enough）

“足够好”不是”随便就行”，而是：

“足够好”的标准：

核心功能可用
无明显 bug
性能可接受
安全无漏洞
可维护性及格

不需要：

代码风格完美
架构设计优雅
测试覆盖 100%
文档事无巨细

AI 生成代码的现实

让我们看看实际场景：

场景：开发一个用户管理系统

AI 生成的第一版代码： 传统思维：这代码不能用！有这么多 TODO，太不专业了！

Worse is Better + AI 思维：

核心功能可用 ✅
先发布，获取反馈
用 AI 逐步修复 TODO

修复后的版本： 关键区别：传统思维要求第一版就完美，Worse is Better 允许渐进式完善。

“足够好”的三个层次

层次	标准	适用场景	质量目标
Level 1: 原型	能跑通主流程	内部测试、概念验证	无崩溃，核心功能可用
Level 2: Beta	无明显 bug	小范围用户测试	边界情况处理，基本安全
Level 3: 生产	可靠可维护	正式用户	完整测试、监控、文档

反模式：每个层次都追求生产级别的质量。

💡 Key Insight

“足够好”不是降低标准，而是重新定义了在什么阶段追求什么质量。Level 1 的”够好”和 Level 3 的”够好”是不同的标准。

迭代速度与系统质量的平衡

误解的澄清

Worse is Better 经常被误解为”为了速度牺牲质量”。

正确的理解：

关键洞察：AI 让我们可以同时在两个维度上提升。

新的平衡公式

传统时代的权衡：提升质量必然降低速度，反之亦然。

AI 时代的新公式：当 AI 辅助系数足够大时，质量和速度可以同时提升。

实战中的质量关卡

即使在追求速度时，也需要守住底线：

红线（不可妥协）：

数据安全（密码加密、SQL 注入防护）
核心功能正确性（关键业务逻辑无 bug）
系统稳定性（不会无故崩溃）
法律合规（隐私、版权）

黄线（可以将就）：

代码风格一致性
测试覆盖率
文档完整性
架构优雅度

绿线（无需关注）：

性能优化（除非有瓶颈）
功能完整性（MVP 可以砍功能）
界面美观（能用就行）

案例：Cursor 团队的实践

Cursor（AI 代码编辑器）团队在早期的发展中展示了这种平衡：

阶段 1：原型期（Week 1-2）

用最快的方式实现核心功能
代码质量一般，但核心 AI 功能可用
目标：验证用户是否真的需要这个产品

阶段 2：验证期（Week 3-6）

获得用户反馈，发现方向正确
开始逐步重构核心模块
同时保持快速迭代新功能

阶段 3：增长期（Month 2-6）

代码质量提升到生产级别
完善测试和监控
但核心架构保持稳定（因为早期选对了）

结果：从想法到市场验证只用了 6 周，从验证到规模化用了 6 个月。

💡 Key Insight

当 AI 辅助系数足够大时，质量和速度可以同时提升——这打破了传统项目管理中”质量vs速度”的零和博弈。

反直觉洞察

洞察 1：完美是完成的敌人

帕金森定律的变体：

“完美代码会膨胀，直到填满所有可用时间。”

传统项目管理追求的是”先把设计做对”，这需要大量前期投入和完整信息。但在真实世界中，信息永远是不完整的，需求永远在变化。当你在设计阶段追求完美时，你其实是在用不确定的未来需求来指导当前的决策——这是一场注定输掉的赌局。

Worse is Better + AI：当你知道修改成本很低时，你就不追求完美了。因为完美不是一个状态，而是一个过程。AI 让这个过程变得低成本、高速度，所以你不需要在起点就达到完美，你只需要在路径上持续逼近。

💡 Key Insight

帕金森定律在 AI 时代被改写：代码不再膨胀到填满所有时间，而是膨胀到刚好够好——因为 AI 让”够好”和”改掉”同样便宜。

洞察 2：技术债是战略投资

传统观点认为技术债是坏事，要尽快还清。但这种观点的前提是：还债有成本，不还债会累积利息。在没有 AI 的时代，这个逻辑是对的——改烂代码比重写还痛苦，重构差架构要大规模动工。

Worse is Better 的观点更微妙：不是所有技术债都是坏事。有些债务是故意的，是为了快速验证方向而付出的代价，这种债叫”战略债务”。有些债是偷懒的结果，这种债叫”愚蠢债务”。两种债的处理方式完全不同。

AI 时代的不同在于：战略债务的成本大幅降低了——以前你说”先这样，以后改”，这个”以后”可能要花两周；现在 AI 重构可能只需要两小时。愚蠢债务也减少了——AI 不偷懒，生成的代码至少是规范、可读的。同时，AI 还能帮你发现那些你自己都没意识到的意外债务（代码异味、潜在安全漏洞、过时依赖）。

战略债务的成本降低了（AI 帮你还债）
愚蠢债务减少了（AI 不偷懒）
意外债务更容易发现（AI 帮你审查）

洞察 3：”好代码”的定义正在改变

传统定义的好代码：

遵循设计模式
高内聚低耦合
易于人类阅读
完美注释

AI 时代的新定义：

易于 AI 理解和修改
意图表达清晰
上下文完整
测试覆盖关键路径

关键变化：代码的主要读者从”其他程序员”变成了”AI 助手”。

💡 Key Insight

当你知道代码会被 AI 重构时，你写的不再是”终极版本”，而是”意图的表达”。可读性让位于可修改性，优雅让位于明确。

洞察 4：系统设计的终点不是设计，是演化

The Right Thing 思维假设：

我们可以预见所有需求
完美的初始设计可以减少后期修改
一次做对是最有效率的

现实：

需求永远在变
初始设计总是部分错误
能快速演化的系统胜过完美但僵化的系统

AI 时代的启示

AI 正在从根本上改变 Worse is Better 的运作方式。在传统软件工程中，”将就”意味着未来要付出代价——改烂代码比重写还痛苦，重构差架构要大规模动工。但 AI 让这个代价曲线发生了逆转：生成成本趋近于零，修改成本同样趋近于零。

这意味着什么？意味着 Worse is Better 从”无奈之选”变成了”最优策略”。你可以主动选择快速推出一个”够好”的版本，在真实世界中学习，然后让 AI 把学到的东西快速迭代进去。每一次循环都比上一次更接近用户真正需要的东西——而你的竞争对手可能还在设计室里追求”完美初始设计”。

三个具体变化值得注意：

第一，”足够好”的标准在上移。 因为 AI 让修复成本变低，你可以在更早的阶段接受更粗糙的版本。以前需要”基本可用 + 测试覆盖 80%”才敢发布，现在”核心功能跑通 + 无致命 bug”就足够了。

第二，技术债的性质在改变。 以前技术债是偷懒的代价，现在技术债是学习的燃料。你欠下的每一笔债，都变成了真实反馈，变成了下一轮迭代的方向。

第三，质量守门员从人变成了 AI。 以往质量需要靠人工 review 来保障，现在 AI 可以持续扫描、自动修复、批量重构。人的精力从”检查代码”转向”定义标准”——你决定什么是够好，AI 确保够好。

但核心逻辑没有变：技术在真实世界中的适应度，决定了它能否存活。AI 只是把这个过程加速了 10 倍。

实战指导

如何在团队中实践 Worse is Better

原则 1：定义”够好”的标准

不要空谈”质量”，要明确定义每个阶段的退出标准：

原则 2：建立快速反馈循环

每次迭代控制在 1-2 小时内：太长会失去迭代节奏，太短无法完成有意义的改进。但时间盒只是形式，真正的目的是让真实反馈驱动方向。

具体的反馈来源优先级：用户行为数据 > 用户直接反馈 > 错误日志 > 代码指标。不要拍脑袋猜用户想要什么——让数据告诉你。

一个实用的做法是”48 小时验证规则”：任何新功能发布后，48 小时内必须有可量化的反馈信号。如果这个信号没有出现，说明这个功能要么没人用，要么埋得太深没有被发现。AI 在这里的作用是帮你快速搭建”反馈收集”的最小路径——A/B 测试框架、事件埋点、错误告警，这些以前需要专门工程资源的东西，现在可以让 AI 帮你配置。

原则 3：保留重构时间

在排期中明确预留技术债偿还时间：每次 sprint 留 20% 的工程容量专门处理技术债，这是对抗”债务累积失速”的最直接手段。

AI 让重构变得前所未有的低成本——以前你需要高级工程师花两天才能把一个烂模块重构好，现在 AI 可以在一小时内完成基础重构，你只需要做 review 和验收。但 AI 重构也有边界：涉及业务逻辑的部分仍然需要人判断，AI 擅长的是代码风格、命名规范、架构模式的标准化，擅长的是把一段”能跑但写得烂”的代码变成”能跑且可读”的代码。

一个实用的比例是：20/10 法则。每个迭代周期，20% 的时间用于新功能，10% 的时间专门用于重构和还债。如果某个模块连续两个迭代都需要在还债时间处理同一个问题，这是一个信号——要么这个模块需要重新设计，要么它的职责边界需要调整，应该从”还债”转向”重写”。

还债优先级的排序：影响核心业务流程的错误和性能问题 > 导致开发速度持续下降的慢性债务 > 纯审美性质的代码美化。

原则 4：使用 AI 作为质量守门员

让 AI 帮你守住底线：质量关卡不能依赖人的自觉，需要系统化。

具体做法：设置 AI 审查的自动触发条件——每次 PR 合并前必须通过 AI review，任何包含 password、eval、innerHTML 等危险模式的代码立即报警，测试覆盖率低于 60% 的模块禁止进入主分支。这些规则可以用 AI-as-reviewer 的工具配置，不需要手工一个个检查。

关键是把”够好标准”变成可执行的东西。以前”够好”是一种主观判断，现在你可以把它翻译成具体的指标：安全扫描通过、类型检查通过、核心路径测试覆盖率 80% 以上、没有高危依赖漏洞。AI 的作用是把这些检查自动化，让你从”手工 review 每一个 PR”中解放出来，专注于判断”这个方向对不对”这种需要人来做的事情。

一个有效的实践是”AI review + 人工复审”的双层机制：AI 做第一层扫描，处理安全、风格、性能等标准化问题；人工做第二层复审，关注业务逻辑、架构选择、边界情况。当 AI 帮你过滤掉 80% 的标准化问题后，人工 review 的效率会大幅提升，你也有精力关注真正重要的事情。

原则 5：建立”还债日”

每周固定时间偿还技术债：推荐每周四下午为”还债日”，选择周四是因为离周末还有两个工作日，如果还债过程中发现了需要跟进的问题，还有机会在周五之前处理。

还债日的内容不要从零开始——每周一生成一份技术债清单，包括：上周积累的 TODO 注释、代码审查中发现的慢性问题、性能监控暴露的瓶颈、依赖项的安全通告。这份清单就是还债日的议程，不需要临时找内容。

AI 在还债日的作用是加速执行而不是发现债务。你告诉 AI “把 src/services/user.ts 里的 TODO 全部处理掉”，AI 生成候选修复方案，你做决策和验收。以前需要高级工程师花半天处理的债务，现在 AI 可以在两小时内生成修复候选，留出时间让人做判断。

还债日的成效衡量：用”技术债指数”跟踪——每周统计未解决的代码异味、 TODO 数量和测试覆盖率变化。如果连续四周指数没有下降趋势，说明还债日被新功能开发挤占了，需要调整时间分配比例。

决策框架：什么时候该完美，什么时候该将就

决策树：

这是核心功能吗？
- 是 → 追求完美
- 否 → 继续下一步
修改成本高吗？
- 是 → 战略债务，谨慎将就
- 否 → 快速实现，有问题再改
业务价值明确吗？
- 是 → 重构优化
- 否 → 实验功能，快速验证

常见陷阱与规避

陷阱 1：”先用 AI 生成，以后再说”变成永远不说

症状：

代码里满是 TODO 注释
没有重构计划
技术债持续累积

解药：

每个 TODO 必须有截止时间和负责人
每周审查技术债清单
超过 1 个月的 TODO 必须解决或删除

陷阱 2：AI 生成的代码质量太差，改不动

症状：

一团 spaghetti code
修改引入更多 bug
重构成本高于重写

解药：

设置最低质量标准（AI 生成的代码必须可审查）
关键模块人工 review
复杂逻辑用 AI 生成多个版本，择优

陷阱 3：在错误的时间追求完美

症状：

MVP 阶段讨论微服务架构
原型期写完整的单元测试
用户量 100 时优化数据库分片

解药：

明确当前阶段的目标
问自己：”如果不做这件事，最坏结果是什么？”
拥抱”够好就行”的心态

结语

回到原点

30 多年前，Richard Gabriel 写下那篇引发争议的文章。

他当时想说的是：技术的成功取决于演化能力，而非初始设计的完美程度。

今天我们重新审视这个概念，发现它比我们想象的更有预见性。

在 AI 时代：

演化成本大大降低
迭代速度大幅提升
“够好就行”从妥协变成了策略

三个核心教训

教训 1：完美是动词，不是形容词

完美不是一次达成的状态，而是持续改进的过程。

AI 让这个过程加速了 10 倍。

教训 2：技术是手段，价值是目的

不要为了优雅而优雅，不要为了质量而质量。

代码的价值在于它解决的问题，而非它本身的美学。

教训 3：系统会死去，能力会留下

任何具体的技术决策都可能过时：

你选的框架会过时
你的架构会被推翻
你的代码会被重写

但你在快速迭代中培养的能力不会过时：

识别核心需求的能力
快速验证假设的能力
在约束中做决策的能力

给 AI-Native 开发者的建议

拥抱”够好就行”：第一版不需要完美，需要可用
投资迭代能力：让系统易于修改，比让系统完美更重要
守住底线：知道什么可以妥协，什么不可以
利用 AI：让 AI 处理重构和优化，你专注方向和价值

💡 Key Insight

实战指导的核心不是”如何更快”，而是”如何建立让 AI 帮你迭代的循环”。单个技巧不重要，循环一旦建立，每一圈都在加速。

最后的话

Worse is Better 不是给懒惰的借口，不是对质量妥协的辩护，不是技术债务的免责条款。

它是对复杂现实的诚实承认：

我们无法预见所有未来，我们无法一次设计完美，我们只能在迭代中逼近目标。

AI 给了我们前所未有的迭代能力。别把它浪费在追求完美上。

深度阅读时间：约 22 分钟

💡 最后的 Key Insight

在 AI 时代，Worse is Better 的终极形态是： “第一版够好就行，因为我们知道，如果有需要，AI 可以在 5 分钟内让它变得更好。”

这不是降低标准，这是重新定义了什么是”好”。

系列关联阅读：

Published on 2026-03-15