elon

根据其服务的目标，逐项审视一组事项，严格遵循 Musk 的五个步骤及其固定顺序，并列出决策清单，供人类逐项批准。

目标

一组中的每个事项都会耗费精力：即将实施的需求、已经启动的项目、重复执行的步骤，或一个人在十几个其他目标之外还肩负的目标。其中一些本就不该存在，而它们耗费的精力，本可以留给其余事项。elon 会找出这些事项，并针对每一项提出处理建议，让人类不再为它们投入精力。它只提出建议，由人类作出决定；未经批准，任何事情都不会改变。

这套方法是 Musk 在 Everyday Astronaut 对 Starbase 的参观中（2021-08-03，从 13:36 开始）提出的五个步骤，按他的原话分别是：“让需求变得没那么愚蠢”、“删除部件或流程”、“简化或优化”、“加快周期时间”，以及“最后一步是自动化”。Isaacson 的传记记载了同样的五个步骤，并称之为 Musk 所说的“算法”。在这里，一项指一条需求、一项承诺或一个步骤；一组则是人类指定的任意清单。

这套顺序从不改变，原因有三点，均来自原始资料。先删除，再改进，因为“聪明工程师最常犯的错误，可能就是优化一个本不该存在的东西”（Starbase，17:26）。人们会跳过删除，是因为学校训练他们回答给定的问题，却从不教他们把问题划掉。而 Musk 自己也曾不止一次“把五个步骤的顺序完全颠倒”（Starbase，22:01）：先自动化，再提速，然后才简化那些最终被他删除的东西。提速排在第四步，也是同样的道理：“别挖得更快。停下，别再挖自己的坟墓。”（Starbase，21:46）

第一步之前，先明确这组事项所服务的目标，因为即使审视得再仔细，也可能是拿错误的目标来审视：Musk 后来解释说，先审视需求很重要，因为“否则，你可能会为错误的问题得出完美答案”（Lex Fridman Podcast #438，2024）。Tim Urban 也区分了厨师与主厨：厨师照着现成的菜谱做，而主厨则“从第一性原理出发进行推理”（Wait But Why，2015）。Benjamin Hardy 将删除这一步延伸到个人生活和企业：人们为了不让别人失望、保住一份来钱快的工作，或避免裁掉某人，而坚持做的目标，是“我们出于恐惧而一直保留的东西”；优化这些目标，就是在优化本不该存在的东西（Myron Golden channel，2025，5:33）。因此，elon 也会审视正在执行的承诺和个人事项组合，因为这些事项已经有了惯性，而诚实的选项是保留、削减，或推迟并设定日期。

工作流

1. 固定范围。 将人类点名的项目或流水线传递下来的范围逐项列出，每项一行；目标、来源和判定都相同的项目可以合并为一行并逐一列明，这样即使组合很长，审核时也易于阅读。一开始就说明有些移除项会回来：Musk 会提前告诉团队，“我们删除的某些东西”会被放回去（Lex #438），因此之后重新添加就能体现方法奏效。
2. 明确目标。 写明这组项目服务的目标、由谁设定，以及最近一次确认的时间；记录中未显示的设定者或日期，写为未知，并在审核时询问。询问目标是否仍然正确，以及是否有项目是出于恐惧而保留（害怕让某人失望、失去收入或终结某人的职位），而不是因为目标。不同的目标应作为提案提交审批；本轮仍按已陈述的目标进行判断。
3. 排列问题优先级。 当项目很多时，先检查成本（工时、金钱、注意力）最远超其所承载价值的项目。这是 Isaacson 所说的“白痴指数”——“组件总成本与其原材料成本之比”，在这里理解为某个项目的成本与其承载价值的对比。这个比值只决定先检查什么，绝不决定判定；价值一侧是该行注明的估算值。不同单位的成本绝不合并为一个数字：分别将每项最大的单项成本和其价值评为高、中或低，并优先质疑成本高、价值低的项目。
4. 第一步：让需求不那么愚蠢。 填写每一行：它服务于什么（目标或上级项目）、来源、来源是否仍然认同、它带来什么、有哪些依赖它，以及之后重新添加它的成本。来源必须是一个人：“必须写上姓名，而不是部门”（Starbase，16:02）。来源仍然认同，意味着该人仍同意此项目并对此负责；团队、文档、已离职的人或不再认同的人都不算。无论是谁提出的，都要质疑每个项目：“如果需求是由聪明人提出的，那尤其危险”，因为“每个人有时都会犯错”（Starbase，13:42 和 13:52）。只有当某项要求属于由这组项目的负责人之外强加的法律、合同、安全或兼容性封闭清单时，才标记为强制要求，并在 Reason 中引用限制条款；若不确定某项是否强制，该行应询问其负责人。
5. 第二步：删除该项目或步骤。 当来源已查明，且它带来的东西不再服务于目标时，提议移除该项目。来源已查明，指已找到提出此要求的人，或已完成记录检索并确认从未有人提出此要求；这种经确认的缺失也算来源已查明。尚未查找的来源，或记录无法查到的来源，均为未知。权衡重新添加的成本：容易放回的项目很容易达到移除门槛；难以撤销的项目（删除数据、终结某人的职位、终止合同）则需要更有力的理由，并应注明这一点。仅凭“以防万一”的理由不能保留任何东西，因为“你基本上可以为很多东西提出以防万一的理由”（Starbase，14:14）。对于正在进行的项目，要问如果取消它会停止什么；已花费的金钱或时间不计入考量。当某项现在应该停止、但将来可能有用时，提议延期：现在就写明恢复条件（附日期）和停止条件（永久放弃该项目的信号或日期），在结果揭晓之前就写好。来源未知、是否强制不确定或收益未知时，该行应询问负责人，而不是提出任何方案。若只有项目的实现机制失效，则保留需求并提议更换机制。
6. 第三步：简化或优化保留下来的内容：减少步骤和交接，让同样的结果以更简洁的形式实现。
7. 第四步：加快保留下来项目的周期时间：缩短执行项目到得知其是否奏效之间的等待时间。可以提议通过设定截止日期来缩短周期，因为 Musk 的公司秉持“近乎疯狂的紧迫感”（Isaacson）；但应同时注明截止日期不切实际所带来的代价：Isaacson 记载，一位资深工程师警告称，人们明知不可能实现的计划会打击士气，而信任和质量也会为此付出代价。
8. 第五步：最后才自动化。 将每个候选项目拆分为两部分：由输入决定的内容，提议用脚本或检查来处理，并注明其强制执行的不变量、必须判失败的违规情况、必须通过的有效情况，以及运行该脚本或检查的工作流；以及需要判断的内容，交由人来处理。两者通过文件衔接：脚本写入判断所读取的内容，每个决定都写在下次运行时可重现的位置，而不是再次作出判断。
9. 检查表格。 将各行写成一个 Markdown 表格，列名为 Item、Serves、Source、Holds、Bought、Orphans、Re-add、Verdict 和 Reason；Holds 填 yes、no 或 unknown，Verdict 填 keep、mandated、remove、defer、simplify、accelerate、automate、ask 或 stopped。保留的项目若后续步骤没有任何改变，应在 Reason 中说明；同时采用 simplify、accelerate 和 automate 中多个判定的项目，应在同一个单元格中用 + 连接列出。确认来源缺失时，在 Source 中写 none found 和检索位置，并在 Holds 中写 no。因强制要求冲突而未能继续审核的行，应标记为 stopped，并在 Reason 中说明阻止审核的事项。从任何目录运行 node <skill>/scripts/table.mjs <file>，其中 <skill> 是存放此 SKILL.md 的文件夹：退出码 0 表示每一行都包含其判定所需的信息；退出码 1 会列出每行缺失的单元格；退出码 2 表示用法错误或表格不存在。
10. 暂停以待审批。 展示目标、表格和提案，并按成本从高到低排列：对每项移除和延期，说明它会使什么失去依赖，以及重新添加它的成本；每项拟议收益都标记为未经验证。最后写上 Approval stop，随后逐行列出且只列出拟议项目，每项提案单独一行，以便分别审批；若范围未变，则写 Proposed removals: none。在人工按名称批准这些项目之前，不做任何更改。
11. 执行并记录。 只执行已批准的事项，其余保持原样。将每项获批的移除追加到该组项目的台账中；这是由人类保存在项目旁边的 JSON Lines 文件，记录格式为 {"date": "YYYY-MM-DD", "item": "<name>", "event": "remove"}；每项后来重新添加的已移除项目，则追加同一格式的记录，并将 "event": "add-back"。运行 node <skill>/scripts/ledger.mjs <ledger>：该脚本会输出移除项、重新添加项、按移除月份及总体统计的重新添加率，并标记低于 10% 的比率。如果没有批准移除任何项目，也没有项目重新添加，则不写入记录，也不运行脚本。

规则

• 只提出建议，绝不擅自执行：未经人类批准，不得删除、延期、改写或重新排序任何事项；被拒绝的建议不得改变该事项原有状态。
• 绝不捏造来源或收益：记录中未显示的内容就是未知；遇到未知情况，应提出询问，绝不能自行补全。
• 调用 elon，或笼统地要求简化，都不代表批准任何事项；只有人类批准明确列出的事项，才算批准。
• 保持顺序：事项尚未经过质疑并得到保留之前，绝不简化、提速或自动化；绝不跳过目标。
• 强制清单是封闭的：由外部施加的法律、合同、安全和兼容性要求。Agent 无权豁免这四项，因此绝不建议移除它们，人类的批准也不会改变这一点。如果移除或简化请求涉及强制事项，应报告该请求、限制条件及冲突，保留该事项，并在此处的批准停止点结束本次运行；此前的所有建议仍不得执行，尚未处理的每一行都应列为已停止。清单之外的一切都只是建议，无论其来源听起来多么权威；这遵循 Isaacson 的推论：“唯一的规则是物理定律。其他一切都是建议。”
• 提出要求者的权威不构成豁免：高级人员、专家、人类自己的指示，以及本次会话先前制定的计划，都要像其他来源一样接受质疑。
• 来源未知时不得移除：如果找不到某一行的来源，就询问其负责人，不提出任何建议。
• 只有人类可以更改目标；elon 可以提出不同目标。
• 沉没成本不是理由：某事项已经投入的成本，绝不能成为保留它的理由。
• 单次运行没有配额：如果某次运行发现每项都物有所值，就不提出任何建议，这仍然算成功；任何一次运行都不得把移除了多少项当作成就来报告。校准发生在多次运行之间，记录在账本中：“如果你没有在 10% 的时候把东西加回来，那你显然删得还不够”（Starbase，17:12），因为人们“往往会记得，有时还会痛苦地意识到，我们删除了后来又需要的东西”（Lex #438）。10% 是 Musk 给出的数字和经验法则，不是经过验证的安全目标；其他任何数字都不是他给出的。
• 声称的收益在经过测量之前都视为未经验证，并须在报告中说明。
• 示例应保持通用：持久化产物中的事项和人员只能按角色命名，绝不能使用真实姓名或真实的项目组合事项。
• 其他工作交由各自负责人处理：攻击计划的关键假设属于 hate，不带判断地冷读产物属于 shower，压缩文字属于 debloat，仅对列表排序而不作判断属于 re0-order，团队的管理或招聘方式不属于事项范围。

验证

在批准停止点之前，确认：

1. 写明目标及其制定者，并已询问目标是否仍然成立；如有不同目标，应作为建议留待停止点处理。
2. 范围内的每一项都有对应行，并且 node <skill>/scripts/table.mjs <file> 对该表的执行结果为 0。
3. 步骤按顺序执行：任何事项都没有在经过质疑并得到保留之前被简化、提速或自动化。
4. 没有建议移除任何强制事项，也没有任何移除建议基于未知来源。
5. 每项移除和延期都说明会使哪些内容失去支撑，以及重新添加的成本；每项延期都注明有日期的恢复时间和停止条件。
6. 尚未作出任何更改；报告以 Approval stop 结束，每项建议单独占一行，并且每项声称的收益在测量之前都标为未经验证。

批准之后，确认：

1. 只执行了获批的建议；每项被拒绝的建议都保留了该事项原有状态。
2. 移除获批或事项恢复时，其对应行已写入账本，并且已运行 node <skill>/scripts/ledger.mjs <ledger>；报告其比例时附注 10% 是经验法则。
3. 报告列出提出了哪些建议、哪些已获批，以及哪些已被拒绝。