第一章：从加法到递归
你有两个资产。
一个是邮件模板。你每周用三次。每次用，它替你省了十分钟。每周三十分钟。
另一个是常见问题文档。你每周被问同样的问题五次。每次你发链接而不是从头写答案，替你省了五分钟。每周二十五分钟。
两个资产。每周五十五分钟。接近一小时。
这是加法。一个资产省一些时间，另一个资产省一些时间。加在一起，总节省是它们各自节省的总和。没有更多。没有更少。
加法不是坏的。每周多出一小时是真实的。一年五十多小时。一周的工作时间。这是有价值的。比没有资产好得多。
但加法有一个上限。你的时间有限。你能建的资产数量有限。即使你有二十个资产，每个省一点，总节省会趋近于一个极限——你不可能省出超过你拥有的时间。加法的极限是百分之百。你能省出的最多是你现有的全部时间。但你不能省出超过你有的。
递归没有这个上限。因为递归不是节省时间。递归是创造时间。
当一个资产的输出成为另一个资产的输入，时间被放大了。不是从你的日程里挤出更多。是从资产之间的相互作用中产生新的资源。
---
加法的局限
让我们更仔细地看加法。
假设你每周工作四十小时。你建了一个资产，每周省一小时。现在你工作三十九小时。你建了第二个资产，每周再省一小时。现在你工作三十八小时。
继续建。十个资产后，你每周工作三十小时。二十个资产后，二十小时。理论上，如果你有四十个资产，每个省一小时，你不需要工作。
但这是理论。实际上，资产不是完全独立的。你花在建资产上的时间本身也是成本。建一个资产需要时间——可能两小时，可能五小时。在你“回本”之前，你没有净节省。而且资产需要维护。维护也花时间。
更重要的是，你的工作不是无限可被资产化的。有些任务不能被资产化——它们需要判断、创造力、人际互动。那些任务会留下。你不能用资产把它们全部消除。
所以加法的极限是真实的。你可以变得更高效。你可以省出一些时间。但你不会通过加法达到“不需要工作”。
这不是问题。除非你误以为加法是唯一的路径。如果你只做加法，你会碰到一个天花板。然后你会觉得“我已经做了所有能做的”。你可能是对的。
但递归提供了加法之外的另一条路。
---
递归的定义
递归，在这个语境下，是指一个资产的输出成为另一个资产的输入。
邮件模板替你了时间。你用那段时间建了常见问题文档。常见问题文档替你了时间。你用那段时间改进了邮件模板。改进后的邮件模板替你了更多时间。
这不是两个独立的资产。它们是连接的。一个产生资源，另一个消耗那个资源。消耗后又产生新的资源，反馈给第一个。
这是一个循环。每个循环，系统的总产出增加。不是因为你投入了更多。是因为资产在相互建造。
递归和加法的区别可以在一个简单的图上看到。
加法：资产A → 节省时间 → 你消费（或闲置）。资产B → 节省时间 → 你消费。资产A和B之间没有箭头。
递归：资产A → 节省时间 → 投资于资产B → 资产B节省更多时间 → 投资回资产A → 资产A被改进 → 节省更多时间。箭头形成循环。
在加法中，你从资产中取出的资源被消费了。在递归中，它们被重新投资了。这是唯一的区别。但它产生的结果完全不同。
---
一个具体的递归例子
假设你有一个邮件模板。你每周发十封类似的邮件。模板每封替你省两分钟。每周二十分钟。
你用这二十分钟建了一个简单的检查清单，用于你每周做的报告。报告每周花两小时。检查清单帮你省了十分钟。现在你每周总节省三十分钟。
你用这额外的十分钟——加上原来的二十分钟中的一部分——改进了邮件模板。你加了一个条件分支，处理了一个边缘情况。现在模板每封替你省三分钟，而不是两分钟。每周三十分钟，从原来的二十分钟增加了十分钟。
现在每周总节省四十分钟。来自检查清单的十分钟，来自邮件模板的三十分钟。
你用这四十分钟中的一部分，把检查清单扩展成了一页指南。指南开始被同事使用。他们用它省了时间。其中一个同事在你的指南基础上建了一个自动化脚本。那个脚本你也用。它每周替你省十五分钟。
现在你有：邮件模板（每周三十分钟），检查清单（每周十分钟），指南（被动，不直接省你时间，但替你建立了信誉），自动化脚本（每周十五分钟）。总节省每周五十五分钟。
注意：你没有“更努力”。你只是把从资产中得到的资源重新投资了。每一轮投资，你都在建造新的资产或改进旧的资产。每一轮，总节省增长。
这个增长不是线性的。它不是“每周加十分钟”那么简单。因为每次改进或新建资产，都可能产生新的机会。你可能发现指南可以被更多人使用。你可能发现自动化脚本可以被应用到其他任务。你可能发现邮件模板可以和其他资产连接。
递归的增长是指数型的——在初期不明显，但随着循环次数增加，增长速度会越来越快。当然，指数增长不可能永远持续。总会有瓶颈。但递归比加法能走得更远。
---
为什么大多数人做加法
因为加法更容易。
加法不需要你改变工作方式。你建一个资产，用它，省时间。然后你建另一个资产，用它，省更多时间。你不需要考虑资产之间的关系。你不需要设计循环。你不需要跟踪盈余去了哪里。
加法是直观的。更多资产 = 更多节省。这是线性的思维。递归是非线性的。它需要你思考系统，而不仅是组件。它需要你放弃一些控制——因为当资产开始相互作用，你不能完全预测结果。它需要你信任过程——因为早期循环的回报很小，你要等几轮才能看到明显的增长。
大多数人不做递归，不是因为他们不能。是因为他们不知道递归是可能的。他们以为资产只能独立存在。他们以为节省下来的时间只能被消费。他们从未看到那个循环。
一旦你看到循环，你就不能无视它。问题不再是“我能不能建更多资产”。而是“我能不能让我的资产相互建造”。
---
递归的前提
递归有几个前提。
第一，你需要至少一个资产。没有资产，没有输出，没有可投资的资源。第一个资产必须来自你的“主时间”——不是来自盈余，因为你还没有盈余。这是最困难的一步。这就是为什么第一块石头如此重要。
第二，你的资产需要产生盈余。资产省的时间必须多于你花在维护它上的时间。如果一个资产每周省三十分钟，但维护它每周花二十分钟，净盈余只有十分钟。这不是不能投资，但效率低。低维护资产是递归更好的燃料。
第三，你需要保护盈余。这是最容易被忽视的一点。你省下来的时间不会自己留在那里等你。系统——你的工作、你的责任、你的习惯——会吸收任何空闲。如果你不主动保护盈余，它就会消失。你需要决定：这每周的三十分钟，不是“多出来的时间可以多做些事”。它是“投资于下一个资产的时间”。不能被其他事占用。
第四，你需要有可投资的路径。你知道下一个资产建什么吗？你知道怎么改进现有资产吗？如果你不知道，盈余会被闲置。你需要一个“投资清单”——可能的资产项目，按优先级排序。这样当盈余出现时，你知道把它投向哪里。
大多数人缺乏的是第三和第四。他们没有保护盈余的习惯。盈余被吸收了。或者他们有盈余，但不知道做什么。所以他们把时间花在了不重要的事上——不是因为他们懒，是因为他们没有计划。
---
从加法到递归的转变
转变不是一次事件。是很多次小的选择。
每次你建了一个资产，问自己：它的盈余去了哪里？是被活动吸收了，还是被投资了？
每次你有一段时间空闲，问自己：这是消费时间还是投资时间？
每次你改进一个资产，问自己：这个改进会帮助其他资产吗？
这些问题很小。但它们累积。每次你选择投资而不是消费，你就在从加法转向递归。
这不是一个“要么加法要么递归”的二元选择。你可以在某些领域做加法，在其他领域做递归。你可以从加法开始，慢慢转向递归。你不需要完美。你只需要方向。
大多数人从未开始，因为他们觉得“递归太复杂”。他们等待一个完美的系统设计。他们等待“有时间”去规划。但递归不是被设计的。递归是被建造的。一个资产接一个资产。一个连接接一个连接。你不知道递归会走向哪里。你只知道方向。
---
你现在的位置
你可能还没有资产。你还在建第一个。没关系。这一章不是现在用的。它是给你建了第一个之后用的。
你可能已经有几个资产。它们是独立的。你还没有让它们相互作用。你在做加法。这很好。加法比没有好。但你知道加法有上限。你在思考如何转向递归。
你可能已经在一个小循环里了。一个资产的输出被用来改进另一个。你在看到增长。不是线性的，但真实的。
无论你在哪里，方向是一样的：从独立到连接，从消费盈余到投资盈余，从加法到递归。
这不是关于“做更多”。是关于“做不同”。是关于让资产为你工作——不仅替你省时间，还互相建造。
第一圈最慢。但每一圈都会加速。不是因为你更努力。是因为资产在替你努力。