Worse is Better 的重新审视：AI 时代的好与坏
TL;DR
- Worse is Better 不是妥协 — 它是系统设计的元策略，在约束条件下追求最优解
- AI 正在加速这一范式 — 生成代码的”足够好”哲学，让迭代速度超越完美主义
- 好代码 vs 快代码是伪命题 — 真正的问题是”在什么阶段追求什么质量”
- 系统演进的新逻辑 — 从”设计完美系统”到”设计能进化的系统”
📋 本文结构
- Richard Gabriel 的经典论述回顾
- Worse is Better 的核心逻辑
- AI 时代的重新审视：好代码 vs 快代码
- AI 生成代码的”足够好”哲学
- 迭代速度与系统质量的平衡
- 反直觉洞察
- 实战指导
- 结语
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 思维：
先爬上一座小山，获得视野，再找更高的山
🏔️ 🏔️
/ \ / \
/ \/ \
/____________\_
局部最优 → 迭代
The Right Thing 的问题：追求完美设计需要太多前置信息，等你设计完，市场已经变了。
Worse is Better 的智慧：快速获得一个可用的版本，在真实世界中学习，然后迭代。
复利效应
为什么”更糟”的系统往往最终”更好”？
时间 →
完美设计系统：
设计 6 个月 → 发布 1.0 → 难以修改 → 逐渐落后
Worse is Better 系统：
设计 6 周 → 发布 0.1 → 快速迭代 → 持续进化
↓
用户反馈
↓
发布 0.2 → 更多反馈 → 发布 0.3...
↓
一年后：功能丰富、用户众多、生态繁荣
这不是妥协，这是复利。
AI 时代的重新审视：好代码 vs 快代码
被混淆的两个维度
在讨论代码质量时，我们经常混淆两个独立维度：
高代码质量
│
理想状态 │ "过度工程"
(高效+优质) │ (完美但慢)
│
低迭代速度 ──────┼────────── 高迭代速度
│
"技术债务" │ Worse is Better
(烂代码快) │ (快但"够好")
│
低代码质量
关键洞察：Worse is Better 不是右下角（烂代码+快），而是右上角（够好+快）。
AI 如何改变游戏
在 AI 时代，情况发生了根本性变化：
变化 1：生成成本趋近于零
传统时代：
写 1000 行代码 = 2 天工作量
重构 1000 行代码 = 1 天工作量
重写 1000 行代码 = 2 天工作量
AI 时代：
写 1000 行代码 = 5 分钟（AI 生成）
重构 1000 行代码 = 10 分钟（AI 重构）
重写 1000 行代码 = 5 分钟（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 生成的第一版代码：
// 用户注册接口
app.post('/api/register', async (req, res) => {
const { email, password } = req.body;
// TODO: 需要添加输入验证
// TODO: 需要检查邮箱是否已存在
// TODO: 需要密码强度检查
// TODO: 需要密码加密
const user = await User.create({ email, password });
res.json({ success: true, userId: user.id });
});
传统思维：这代码不能用！有这么多 TODO，太不专业了！
Worse is Better + AI 思维：
- 核心功能可用 ✅
- 先发布，获取反馈
- 用 AI 逐步修复 TODO
修复后的版本：
// 经过 AI 多轮迭代后的版本
app.post('/api/register', async (req, res) => {
const { email, password } = req.body;
// 输入验证
if (!email || !password) {
return res.status(400).json({ error: 'Missing required fields' });
}
if (!isValidEmail(email)) {
return res.status(400).json({ error: 'Invalid email format' });
}
if (password.length < 8) {
return res.status(400).json({ error: 'Password too short' });
}
// 检查邮箱是否已存在
const existing = await User.findOne({ email });
if (existing) {
return res.status(409).json({ error: 'Email already registered' });
}
// 密码加密
const hashedPassword = await bcrypt.hash(password, 10);
const user = await User.create({
email,
password: hashedPassword,
createdAt: new Date()
});
res.json({ success: true, userId: user.id });
});
关键区别：传统思维要求第一版就完美，Worse is Better 允许渐进式完善。
“足够好”的三个层次
| 层次 | 标准 | 适用场景 | 质量目标 |
|---|---|---|---|
| Level 1: 原型 | 能跑通主流程 | 内部测试、概念验证 | 无崩溃，核心功能可用 |
| Level 2: Beta | 无明显 bug | 小范围用户测试 | 边界情况处理，基本安全 |
| Level 3: 生产 | 可靠可维护 | 正式用户 | 完整测试、监控、文档 |
反模式：每个层次都追求生产级别的质量。
迭代速度与系统质量的平衡
误解的澄清
Worse is Better 经常被误解为”为了速度牺牲质量”。
正确的理解：
高质量系统
│
│ 🎯 目标区域
│ (高迭代 + 高质量)
│
│
低迭代 ───────┼──────── 高迭代
│
│ ❌ 陷阱区域
│ (为了速度牺牲质量)
│
低质量系统
关键洞察：AI 让我们可以同时在两个维度上提升。
新的平衡公式
传统时代的权衡：
质量 × 速度 = 常数
提升质量必然降低速度，反之亦然。
AI 时代的新公式：
质量 × 速度 = AI 辅助系数 × 团队能力
当 AI 辅助系数足够大时，质量和速度可以同时提升。
实战中的质量关卡
即使在追求速度时，也需要守住底线：
红线（不可妥协）：
- 数据安全（密码加密、SQL 注入防护）
- 核心功能正确性（关键业务逻辑无 bug）
- 系统稳定性（不会无故崩溃）
- 法律合规（隐私、版权）
黄线（可以将就）：
- 代码风格一致性
- 测试覆盖率
- 文档完整性
- 架构优雅度
绿线（无需关注）：
- 性能优化（除非有瓶颈）
- 功能完整性（MVP 可以砍功能）
- 界面美观（能用就行）
案例：Cursor 团队的实践
Cursor（AI 代码编辑器）团队在早期的发展中展示了这种平衡：
阶段 1：原型期（Week 1-2）
- 用最快的方式实现核心功能
- 代码质量一般，但核心 AI 功能可用
- 目标：验证用户是否真的需要这个产品
阶段 2：验证期（Week 3-6）
- 获得用户反馈，发现方向正确
- 开始逐步重构核心模块
- 同时保持快速迭代新功能
阶段 3：增长期（Month 2-6）
- 代码质量提升到生产级别
- 完善测试和监控
- 但核心架构保持稳定（因为早期选对了）
结果：从想法到市场验证只用了 6 周，从验证到规模化用了 6 个月。
反直觉洞察
洞察 1：完美是完成的敌人
帕金森定律的变体：
“完美代码会膨胀，直到填满所有可用时间。”
传统项目管理：
预计 2 周完成 → 实际 4 周 → 因为"可以做得更好"
Worse is Better + AI：
预计 2 天完成 → 实际 2 天 → "够好就行，有问题再改"
当你知道修改成本很低时，你就不追求完美了。
洞察 2：技术债是战略投资
传统观点：技术债是坏事，要尽快还清。
Worse is Better 观点：
技术债类型：
战略债务 ✅ 好的债务
- 为了抢占市场而妥协
- 明确的还款计划
- 收益 > 利息
愚蠢债务 ❌ 坏的债务
- 因为懒惰而妥协
- 无还款计划
- 利息 > 收益
意外债务 ⚠️ 不可避免
- 认知局限导致
- 边做边还
- 学习成本
AI 时代的不同：
- 战略债务的成本降低了（AI 帮你还债）
- 愚蠢债务减少了（AI 不偷懒）
- 意外债务更容易发现（AI 帮你审查）
洞察 3：”好代码”的定义正在改变
传统定义的好代码：
- 遵循设计模式
- 高内聚低耦合
- 易于人类阅读
- 完美注释
AI 时代的新定义：
- 易于 AI 理解和修改
- 意图表达清晰
- 上下文完整
- 测试覆盖关键路径
关键变化：代码的主要读者从”其他程序员”变成了”AI 助手”。
💡 Key Insight
当你知道代码会被 AI 重构时，你写的不再是”终极版本”，而是”意图的表达”。可读性让位于可修改性，优雅让位于明确。
洞察 4：系统设计的终点不是设计，是演化
The Right Thing 思维假设：
- 我们可以预见所有需求
- 完美的初始设计可以减少后期修改
- 一次做对是最有效率的
现实：
- 需求永远在变
- 初始设计总是部分错误
- 能快速演化的系统胜过完美但僵化的系统
AI 时代的启示：
传统系统架构：
设计 → 实现 → 维护 → 重写
↓
修改成本高 → 系统僵化
AI-Native 系统架构：
设计 → 实现 → 演化 → 持续演进
↓
AI 辅助修改 → 系统保持活力
实战指导
如何在团队中实践 Worse is Better
原则 1：定义”够好”的标准
不要空谈”质量”，要明确定义每个阶段的退出标准：
## 原型阶段退出标准
- [ ] 核心用户流程可完整走通
- [ ] 无导致崩溃的严重 bug
- [ ] 基本的安全防护（SQL 注入、XSS）
- [ ] 数据不会丢失
## Beta 阶段退出标准
- [ ] 边界情况处理
- [ ] 基本监控和告警
- [ ] 用户反馈渠道
- [ ] 回滚方案
## 生产阶段退出标准
- [ ] 完整测试覆盖（关键路径）
- [ ] 性能基准测试
- [ ] 运维文档
- [ ] 灾难恢复方案
原则 2：建立快速反馈循环
想法 → AI 生成 → 测试 → 反馈 → 改进
↑ ↓
└──────── 小步快跑 ─────────────┘
每次迭代控制在 1-2 小时内：
- 太长：失去迭代节奏
- 太短：无法完成有意义的改进
原则 3：保留重构时间
在排期中明确预留技术债偿还时间：
传统排期：
Week 1-4: 开发新功能
Week 5: 修复 bug
Week 6: 发布
Worse is Better 排期：
Week 1-2: 快速原型
Week 3: 验证 + 重构核心模块
Week 4-5: 功能完善
Week 6: 代码审查 + 重构 + 发布
原则 4：使用 AI 作为质量守门员
让 AI 帮你守住底线：
# 代码审查提示词模板
cat > review-prompt.txt << 'EOF'
请审查以下代码，检查：
1. 安全风险（SQL 注入、XSS、CSRF）
2. 明显的逻辑错误
3. 性能陷阱（N+1 查询、内存泄漏）
4. 错误处理缺失
如果是红线问题，必须修复。
如果是黄线问题，可以标注 TODO。
EOF
原则 5：建立”还债日”
每周固定时间偿还技术债：
## 周五下午：技术债时间
可选任务：
- [ ] 重构上周写的"将就代码"
- [ ] 补充缺失的测试
- [ ] 优化性能瓶颈
- [ ] 更新文档
原则：
- 不开发新功能
- 不修复非关键 bug
- 专注提升代码健康度
决策框架：什么时候该完美，什么时候该将就
高业务价值
│
重构优化 ←────────┼────────→ 追求完美
(现有系统) │ (核心功能)
│
低修改成本 ──────────────┼────────────── 高修改成本
│
快速实现 ←────────┼────────→ 战略债务
(实验功能) │ (关键基础设施)
│
低业务价值
决策树：
- 这是核心功能吗？
- 是 → 追求完美
- 否 → 继续下一步
- 修改成本高吗？
- 是 → 战略债务，谨慎将就
- 否 → 快速实现，有问题再改
- 业务价值明确吗？
- 是 → 重构优化
- 否 → 实验功能，快速验证
常见陷阱与规避
陷阱 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 处理重构和优化，你专注方向和价值
最后的话
Worse is Better 不是给懒惰的借口， 不是对质量妥协的辩护， 不是技术债务的免责条款。
它是对复杂现实的诚实承认：
我们无法预见所有未来， 我们无法一次设计完美， 我们只能在迭代中逼近目标。
AI 给了我们前所未有的迭代能力。 别把它浪费在追求完美上。
💡 最后的 Key Insight
在 AI 时代，Worse is Better 的终极形态是： “第一版够好就行，因为我们知道，如果有需要，AI 可以在 5 分钟内让它变得更好。”
这不是降低标准，这是重新定义了什么是”好”。
系列关联阅读：
- #58 AI-Native Code Review：从人工审查到 Agent 陪审团
- #60 TDD vs AI-First：测试驱动开发在 AI 时代的进化
- #62 后代码时代：当自然语言成为编程语言
AI-Native软件工程系列 #63
Published on 2026-03-15