极致简化原则（Delete the Part）
一句话定义
先删，再简化，最后才优化——如果你删掉一个零件/流程/需求之后没有被迫至少把其中 10% 加回来，说明你删得不够狠；这条规则是马斯克 5 步生产力法的核心，也是他对"聪明工程师最常见错误"的唯一解药。
核心要义
1) 最常见的聪明工程师错误是——优化一个不该存在的东西
这一条是整套方法的灵魂。
"听起来很蠢，但人们经常忘了彻底删除的选项。如果你不被迫把删除的至少 10% 加回来，说明你没删够。人们通常觉得如果自己没被迫加回来就算成功了——但其实他们失败了，因为他们太保守，留了不该留的东西。所以最常见的聪明工程师的错误就是：优化一个不该存在的东西。"
——2024-08 Lex Fridman 438 - Neuralink Team
"10% 加回规则"是一条反向指标——它告诉你："保守不是安全，保守是一种失败模式。"它逼你越过你以为的安全线去探。
2) 需求本身也要被删
在删零件之前，先删需求——这是 5步生产力框架 的第一步。
"需求在某种程度上总是蠢的。先减少需求的数量。无论给你需求的人多聪明，这些需求都有一定程度的蠢。不从这里开始，你就可能在为错误的问题求得完美答案。"
——2024-08 Lex Fridman 438 - Neuralink Team
他补了一条可操作的规则——"问这个需求是哪来的，回答必须是一个人的名字，不能是'某个部门'或'法规'"。这把"删需求"从一个哲学姿态变成了一个可执行的会议动作。
3) 没删够就去优化，是荒谬
"前两步都没做就来优化，等于优化不该存在的东西。荒谬。"
——2024-08 Lex Fridman 438 - Neuralink Team
顺序不能颠倒——马斯克自己说他"走过无数次倒退——先自动化、再加速、再简化、再删除"，然后吃了 Model 3 过度自动化的大亏（参见 产能地狱）。这条顺序是几十亿美元的学费换回来的。
4) 删除也适用于法律、组织、软件，不只是硬件
"我会建议用直接民主……人民直接对法律投票，法律必须足够短，短到人们能读懂。"
——2021-12 Lex Fridman 252 - SpaceX Mars"通过一条法律需要 60% 赞成票，废除一条法律只需要 40%——让删除法律比通过法律更容易。"
——2021-12 Lex Fridman 252 - SpaceX Mars
他把"删除优先"从 Starship 推到了宪法设计——任何系统都会累积熵，只有让"删"比"加"更便宜，系统才能保持活力。
经典案例
- Starship 砍掉着陆腿：整个着陆腿系统被删掉，改用发射塔"筷子"接回。参见 2021-12 Lex Fridman 252 - SpaceX Mars："这第一次肯定不会成功。这是发疯级别的事情。"
- Optimus 手部 22 自由度：每个零件都被从"需求"层面追问——为什么手指长度不一样？为什么肌肉在前臂而不是手掌？（参见 2024-08 Lex Fridman 438 - Neuralink Team）
- Model S 的门把手/Model 3 的仪表盘：删掉传统汽车的物理按钮、仪表盘分离式屏幕，把 UI 压缩到一块触摸屏上——这是"先删再简化"的经典 UI 应用。
- Raptor 引擎："造最好的零件就是没有零件"——马斯克在多次 Starship 更新里反复强调 Raptor 的简化程度。
- X (Twitter) 裁 80%：从"组织"层面应用删除原则——先砍掉大部分岗位，再看哪些必须加回来。参见 直接报告链。
马斯克原话
"如果你不被迫把删除的至少 10% 加回来，说明你没删够。" ——2024-08 Lex Fridman 438 - Neuralink Team
"最常见的聪明工程师的错误就是：优化一个不该存在的东西。" ——2024-08 Lex Fridman 438 - Neuralink Team
"需求在某种程度上总是蠢的。" ——2024-08 Lex Fridman 438 - Neuralink Team
"让删除法律比通过法律更容易。" ——2021-12 Lex Fridman 252 - SpaceX Mars
你能用上吗？（适用边界）
能用的场景：
- 产品评审：列出所有功能/字段/按钮，挨个问"如果删掉它会怎样？"——不是"它有什么用"，而是"删掉的成本是什么"。默认保留的心理偏差太强了。
- 需求评审：每个需求必须追溯到一个具体的人。PM 不行，"用户"不行——必须是一个名字。
- 组织评审：每个流程、每次例会、每份周报——默认删掉，看谁来把它加回来。
- 代码重构：先删 20% 的代码，看哪些必须加回来。
不能乱用的场景：
- 安全关键系统：删除 ABS 是省了几个零件，但后果不是"10% 加回"。Crew Dragon 的冗余不能按这条来删。
- 你还没理解系统：删除的前提是你真的知道每一部分是干什么的——不懂的情况下删除就是破坏。
- 有多个利益相关方的产品：你删掉的"垃圾功能"可能是另一个团队的 OKR。先确认删除的政治成本。
给普通团队的可操作版本：
1. 每个季度做一次"删除 review"：列出所有流程/会议/报表/字段，强制挑出至少 20% 砍掉。
2. "10% 加回"作为成功指标：如果团队在三个月后完全不需要加回任何东西，说明他们删得还不够。
3. 需求溯源到人名：每个需求卡片必须写"提出者：XXX"——"合规部门"或"用户反馈"都不够。
4. 倒着念口诀：如果你发现自己在想"怎么自动化这个流程"，停下来，倒回去问："这个流程需要存在吗？"