第 16 章 · 从单一工资到多收入
第二条收入和第一条有多大关系？
- 关联资本
- Financial CapitalHuman CapitalDistribution Capital
- 要交出的成果
- Income Architecture：收入来源、相关性与各自的失效条件。
- 用到的口径
incomeDependency
第 15 章问的是一条路的上限：继续留在现在这条路上，收入的顶在哪里。它走完的结果是收入来源的个数一个都没变。
这一章接着问下一个问题，而且只问这一个：你已经有或者打算有的那几条收入，彼此之间是什么关系。
这个问题有一个很常见的错误答案：「我有三条收入，所以我比只有一条的人安全。」它错的地方不在于算错了条数，而在于条数不是口径。第 1 章已经给过一次判据：工资和年终奖看起来是两笔钱，但它们来自同一个雇主，在收入集中度口径里算一个来源。这一章要把那一句话推到底——推到三笔、四笔、五笔收入上，推到「看起来是外部客户，其实是原雇主换了合同主体付的钱」这种更隐蔽的形状上。
这一章不做的事：不评估你的能力值多少钱（第 13 章），不处理同一条收入的上限结构（第 15 章），不处理来询从哪里来（第 17 章），不设计新收入的验证实验（第 18 章）。这一章只处理几条收入之间的相关性、各自的稳定性、各自的失效条件，以及一条新收入在扣完全部成本之后真正剩下多少。
机制
先把「几条收入」这件事改写成一个可以计算的东西。
两笔收入会不会在同一件事发生时一起变少或一起归零。
它不看这两笔钱从哪个账户进来、由谁签的合同、是不是不同的行业名称，只看一件事：列出每一笔收入的全部失效条件，看它们有没有共用的那几条。 共用的条件越多，相关性越高；共用的条件里只要有一条足以让两笔同时归零，这两笔在抗冲击的意义上就是一笔。
四种最常见的高相关来源：同一个雇主（包括它的子公司、外包主体、关联方）、同一个大客户、同一个平台的派单或排序、同一个行业的景气度。最后一种最容易被漏掉，因为它的两笔收入可能真的来自两家公司、两份合同、两个账户——但这两家公司的预算在同一个周期里一起收紧。
相关性不是一个要靠统计算出来的系数。在个人财务这个尺度上，它是一张失效条件清单的交集，用纸笔就能列完。
会同时失效的收入归在一起，叫一个经济依赖组。它是收入集中度口径里真正的计算单位。
口径 10.5 的定义是「最大的经济相关收入来源 ÷ 总收入」，incomeDependency 的实现把这句话落成了三步：分组键取每笔收入的 dependencyGroup，同一个键的金额先合并再算占比，金额统一用税后月额并换算到记账币种。所以五条收入记在同一个 dependencyGroup 下面，这个函数只会给你一行。
分组的判据只有一句话，和第 10 章那条完全一样：会不会同时出问题。 不是「是不是同一个人付钱」，也不是「是不是同一种收入形态」。一笔钱走了另一个合同主体、开了另一张发票、甚至换了一个行业名称，只要决定它存不存在的还是同一个主体或同一件事，它就填同一个组名。
反过来也成立：一个最初从某个平台认识的客户，后来签了直接合同、你有他的联系方式、平台规则变化不影响这笔钱——它就不进那个平台的组。分组会随事实变化，所以它要定期重填，不是填一次就定了。
一笔收入在下一个月会不会以同样的金额再出现一次。它和金额无关，是收入的另一个维度。
三档，在计划里的作用完全不同：
- 合同收入：有书面约定、有期限、有违约后果。它可以被放心地减在缺口里。
- 波动收入：会重复出现，但金额不定。它只能用观测到的区间下端进计划，不能用月均。
- 一次性收入：不会再出现的那一笔（一次结算、一次转让、一次性补偿）。它既不能进「每月收入」，也不能在已经进了安全资金之后再算一遍收入。
最常见的错误是把三档加成一个月均数，然后用这个月均数去做需要稳定性的判断。月均数只能回答「去年一共收了多少」，不能回答「下个月能不能覆盖必要支出」。
为了让一个愿意付钱的人出现，必须重新花掉的钱和时间。口径是一个除法：一段时间里全部获客投入 ÷ 这段时间里新成交的人数。
它有两个性质，决定了它必须进账：
- 它是每月重新发生的，不是一次性的。 停掉获客，新成交的人数会下降，不是停在原地。所以它要记成持续成本，而不是启动成本。
- 它的大头常常不出现在任何账单上。 现金投入会有发票，你自己花在获客上的小时不会有——而后者按第 9 章那个口径折价之后，经常比现金那一项大几倍。
一条没有获客渠道的「第二条收入」不是一条收入，是一个想法。渠道本身怎么算、怎么分组、断掉值多少钱，是第 17 章的事；这一章只负责把它的成本记进去。
四类收入：这一笔是在卖什么
PRD 对 Phase III 有一条硬要求：严格区分劳动收入、软件杠杆收入、产品收入、资本收入。这个区分要落到一个具体的判断上，而不是一个标签。
| 类型 | 这一笔在卖什么 | 你停手一个月 | 它的失效条件通常长什么样 |
|---|---|---|---|
| 劳动收入 | 你的时间 | 归零 | 付钱的那一方不要了，或者你没法工作了 |
| 软件杠杆收入 | 被工具放大的你的时间 | 归零，工具费继续 | 同上，再加「工具或接口变了，放大倍数掉回去」 |
| 产品收入 | 一件做好的东西的多份副本 | 衰减，获客与维护成本继续 | 没人知道它存在（渠道断）、它不能用了（维护停）、环境要求变了 |
| 资本收入 | 你拥有的生产性资产 | 基本不变 | 资产本身出问题、承租方违约、分配政策变化 |
判断一笔收入属于哪一类，问三句话就够：
- 这一笔钱是不是必须有你在场才会产生？ 是 → 前两类。
- 多卖一份要不要你多花交付时间？ 要 → 劳动或软件杠杆；接近不要 → 产品。
- 它来自你的交付，还是来自你拥有的东西？ 来自拥有的东西 → 资本收入。
两条边界要划清，因为它们是最常被跨过去的：
- 软件杠杆收入仍然是劳动收入。 工具把每份的小时数压低了，所以同样的时间能做更多单，但上限还是你的小时数。它改的是斜率，不是类型。这是第 14 章那份实验在算的东西。
- 一个 SaaS 或者一个知识产品不会自动形成被动收入。 它仍然需要持续获客、维护、服务与合规投入。「可扩展」说的是多卖一份不用多花交付时间，它没有说钱会自己进来。这件事在第 18 章有一笔算到负数的账。
类型和相关性是两个独立的维度，这一点要特别注意。四类收入里的任何两类都可能落在同一个经济依赖组里：你给雇主打工拿工资（劳动），同时持有这家公司的股票拿分红（资本）——类型完全不同，依赖组是同一个。ConcentrationLab 的默认输入里就埋着这件事。
稳定性怎么作用在 Runway 上
这是「稳定性不等于金额」最具体的落点。第 5 章的口径是：
Runway = 可动用的安全资金 ÷ 月必要现金流出
这个式子里没有收入项，所以三档稳定性不是直接改 Runway，而是分别改它周围的三件事：
| 稳定性 | 它能不能进安全资金（分子） | 它能不能改月必要现金流出（分母） | 它能不能减在「失去主收入之后的缺口」里 |
|---|---|---|---|
| 合同收入 | 不能（它是流量，不是余额） | 不能 | 可以，按合同金额与剩余期限 |
| 波动收入 | 不能 | 不能 | 只能按观测区间的下端减 |
| 一次性收入 | 可以，但进了分子就不能再当每月收入算一遍 | 不能 | 不能 |
最后一列是这一章要加进去的那一列。Runway 本身假设收入归零；而现实里失去最大依赖组之后，通常还剩一点残余收入。把残余收入减在分母上，得到的是一个推论，不是 Runway 口径本身——所以它要单独写、单独标明用的是哪一档稳定性。而这个推论的结果，完全取决于你把哪几笔算成了「还在的」。下一节有一个人把这件事算错了 8.9 个月。
| 维度 | 要识别的风险 | 证据从哪来 | 后果 |
|---|---|---|---|
| Cash Flow | 收入不足以覆盖必要支出 | 月必要流出 > 税后现金收入 | 需要借钱维持日常，债务余额上升 |
| Debt | 高成本债务或近期偿债压力 | 加权平均利率、最低还款占收入比、到期日 | 利息吞噬现金流；逾期后果不可逆 |
| Liquidity | 安全资金不足 | Runway 月数、被排除的资产清单 | 一次意外支出就要刷卡或低价变卖 |
| Income | 单一经济来源 | 最大依赖组占总收入的比例 | 一个雇主或客户流失即归零 |
| Assets | 单一资产或企业集中 | 最大分组占总资产的比例 | 单一资产的风险等于整个系统的风险 |
| Currency | 收支及目标货币错配 | 收入、支出、资产各自的币种占比 | 汇率反向波动时实际购买力下降 |
| Jurisdiction | 账户和资产集中于单一环境 | 按 jurisdiction 分组的资产占比 | 规则、税务或准入变化时无法调整 |
| Business | 企业经营与个人财务高度绑定 | 个人资产中企业权益占比、是否个人担保 | 企业出问题时个人安全边界同时消失 |
| Platform | 过度依赖单一平台或客户 | 渠道与客户集中度 | 平台规则一变，渠道资产缩水 |
| Health / Life | 健康事件和家庭责任带来的财务风险 | 保障覆盖、必要支出中的医疗与抚养部分 | 同时降低收入能力并抬高必要支出 |
这张表没有总分列。十个维度的后果严重程度不一样，有的可逆、有的不可逆，加权相加会把这个区别抹掉。
这一章的产出落在 Fragility Map 的 Income 这一行：「收入过度集中」，它要的证据就是收入集中度。第 17 章填的是 Platform 那一行的来询那一半，这一章填 Income 这一行——两件事的分组键必须是同一套 dependencyGroup，否则两张表对不上。
这一章同时动三种资本：Financial（收入与安全资金的口径）、Human（能提供第二条收入的能力）、Distribution（让第二条收入有人买的渠道）。三种缺任何一种，第二条收入都不会出现：没有能力就没有东西可卖，没有渠道就没有人来买，没有现金缓冲就撑不过它的爬坡期。
先把一条做稳，也是这一章的正当结论
这一章不主张人人都该有多条收入。它主张的是另一件事：你应该知道自己现在这几笔收入的相关性有多高、各自在什么条件下归零。
知道之后，有两个合法的下一步，而且它们地位相同：
- 降低依赖——开一条失效条件和现有收入不重叠的新收入。
- 把现有这一条做稳——把它从波动收入推向合同收入、把它的失效条件逐条减少、把 Runway 补到你自己推出来的目标月数。
第二条在很多情况下是更划算的那一个，理由是它不需要爬坡期、不需要新的获客渠道、不占用你本来就不够的小时。PRD 对 Phase III 的训练重点写得很清楚：能不能提高经济产出能力，并减少不必要的单点依赖。 「不必要」这三个字是有分量的——第二条收入如果和第一条共用全部失效条件，它增加的是工作量，不是抗冲击能力。
所以这一章的成果不是「我开了几条收入」，是一张能看出相关性和失效条件的表。表上写着「我现在只有一条，它的失效条件是这三个，我这个季度先减掉第二个」，这是一份完整的产出。
这一章不承诺被动收入，也不点名任何产品或平台
第二条收入不会自己长出来。它要么占用你的小时，要么占用你的现金，通常两样都占。把持续获客、维护、服务与合规的成本记成零，是这一章要拦住的那个错误——「算一遍」第三步有一个具体的减法，扣完之后剩下 1,060，而毛收入是 5,400。
另外，这一章出现的每一个金额、每一个比例、每一个小时价值都是为了让加减法走得通而设的示例，不是对任何地区、任何行业当前价格的陈述。你要做的是用同一个结构填进你自己的数。涉及具体平台、工具、服务、费率与资格条件的内容按年变化，属于带适用地区与核对日期的 Toolkit Pack，不写进正文。
税务与法务的归属问题（第二份收入怎么申报、合同主体怎么认定）在不同地区差别很大，这一章不给结论，只给一条核对动作：把每一笔收入的合同主体、付款主体和申报方式写在表上，然后拿这张表去和当地的专业人士核对。
现实案例
四段账。前两段是同一个人：她以为自己有三条收入，其中两条是一条；第三段讲稳定性怎么把一个月均数变成一个错误结论；第四段讲一条真实存在的第二条收入，在扣完获客成本之后剩多少。
她的月税后收入，四个条目：
| 条目 | 税后月额 | 她填的 dependencyGroup | 类型 | 稳定性 |
|---|---|---|---|---|
| 工资 | 25,000 | 雇主 A | 劳动收入 | 合同收入 |
| 项目奖金 | 3,000 | 雇主 A | 劳动收入 | 波动收入 |
| 外包／顾问费 | 6,000 | 客户 B | 劳动收入 | 合同收入（一年一签） |
| 出租房净租金 | 3,000 | 出租房 | 资本收入 | 合同收入 |
| 基金分红 | 800 | 证券账户 | 资本收入 | 波动收入 |
| 合计 | 37,800 |
按她这张表跑 incomeDependency：总计 37,800，最大依赖组是雇主 A（25,000 + 3,000 = 28,000），占 74.07%；客户 B 占 15.87%，出租房 7.94%，证券账户 2.12%。四个组。
她的结论是：「我有三个雇主之外的来源，最大那个占七成四，不算特别集中。」
但「客户 B」是什么。 她那笔外包是两年前一次组织调整的结果：原来她在雇主 A 内部做的一块事被划了出去，由 A 的一家关联主体和她签服务合同。付款主体换了，发票换了，合同换了。决定这笔钱存不存在的人没换——还是 A 那条产品线的负责人，预算还是从 A 的同一个盘子里批。
把这一条的 dependencyGroup 从「客户 B」改成「雇主 A」，金额一分不动：
- 雇主 A：25,000 + 3,000 + 6,000 = 34,000 ÷ 37,800 = 89.95%
- 出租房 7.94%，证券账户 2.12%，三个组
74.07% → 89.95%。她的收入表没有任何一个数字变化，变的只是一个分组键。
她的财务面（口径同 Phase I）：月必要支出 14,600，最低还款 1,400，月必要现金流出 16,000；可动用的安全资金 112,000。Runway = 112,000 ÷ 16,000 = 7.0 个月。按第 5 章那张表推出来的目标月数是 9（起点 3 + 单一雇主 2 + 收入与行业景气度高度相关 1 + 有租客与房屋维修的不确定性 1 + 重新接上收入 2），目标 144,000，缺口 32,000。
雇主 A 调整，她所在的产品线整条裁掉。工资停、奖金停，关联主体那份服务合同在同一周被通知不续约——批预算的是同一个人，产品线不在了，这块事也不在了。
她在第 24 个月做过一次「如果失业」的推算，用的是她自己那张表（外包算独立来源）：
- 失业后剩下的月收入 = 6,000 + 3,000 + 800 = 9,800
- 月必要现金流出 16,000，净缺口 = 16,000 − 9,800 = 6,200
- 能撑的月数 = 112,000 ÷ 6,200 = 18.06 个月
第 25 个月的实际情况：
- 剩下的月收入 = 3,000 + 800 = 3,800（只有那两笔来自她自己拥有的资产）
- 净缺口 = 16,000 − 3,800 = 12,200
- 能撑的月数 = 112,000 ÷ 12,200 = 9.18 个月
18.06 → 9.18，差 8.88 个月。 安全资金一分没少，必要支出一分没涨，差的全部来自一个分组键。
这里还有一个口径细节值得单独说：7.0 个月那个数（Runway）和上面这两个数不是同一件事。Runway 的分子分母都不含收入，它回答的是「收入归零我能撑几个月」；上面两个数是在它之外加了残余收入做的推论，所以它们的可靠程度完全取决于「残余收入」那一栏填得对不对。她那一栏填错了一笔，推论就错了快一倍。
剩下那 3,800 还有一件事要说清：它正好等于她的所有权收入占比 10.05%（口径 10.6，只认已经到账的现金）。这不是巧合——在她这张表上，唯一和雇主 A 没有共用失效条件的两笔收入，恰好就是来自她自己拥有的那两样东西。类型和相关性是两个维度，但在这个具体的人身上，这两个维度的答案重合了。
他的收入按年看是 288,000，月均 24,000。拆成三档稳定性之后是这样：
| 稳定性 | 月额 | 来自什么 | 过去 12 个月的实际区间 |
|---|---|---|---|
| 合同收入 | 9,000 | 一份签了 12 个月的固定服务合同，剩余 7 个月 | 9,000，没有波动 |
| 波动收入 | 9,000（月均） | 按项目接的活 | 2,000–18,000 |
| 一次性收入 | 6,000（月均） | 一次设备转让 + 一笔旧项目的结算尾款，全年合计 72,000 | 全年只发生过两次 |
| 合计 | 24,000 |
他的月必要现金流出 13,500，可动用的安全资金 81,000——而那 81,000 里的大部分，就是上面那 72,000 一次性收入攒下来的。
用月均算，结论是「每月结余 10,500」： 24,000 − 13,500 = 10,500，看起来很宽裕。
按三档分别算，结论完全不同：
- 合同收入覆盖率 = 9,000 ÷ 13,500 = 66.67%。只靠这一档，每月差 4,500。
- 波动收入最低的那个月是 2,000：当月总收入 9,000 + 2,000 = 11,000，差 2,500。过去 12 个月里有 3 个月出现过这种情况。
- Runway = 81,000 ÷ 13,500 = 6.0 个月。
- 只靠合同收入能撑多久 = 81,000 ÷ 4,500 = 18 个月（这是推论，不是 Runway）。
- 合同 + 波动最低档能撑多久 = 81,000 ÷ 2,500 = 32.4 个月。
那 6,000 的一次性收入是整张表里最危险的一行。 它的 72,000 已经在安全资金 81,000 里了。如果他再把它当成「每月都有的 6,000」写进收入，这笔钱就被算了两遍：一次作为余额在分子里，一次作为流量在「每月结余」里。而第二次是假的——明年没有一次设备可以再转让一遍。
他真正的收入集中度也要重算。那份合同来自一个客户，占 9,000；波动收入过去 12 个月来自 4 个客户，但其中 2 个和合同那家是同一个集团的不同部门，合并后月均 5,200。
- 按客户条目看：最大一个 9,000 ÷ 24,000 = 37.5%
- 按
dependencyGroup看：那个集团 = 9,000 + 5,200 = 14,200 ÷ 24,000 = 59.17%
37.5% 和 59.17%，同一年的同一批收入。 而决定他哪个月过不去的，是 59.17% 那个数。
她的主业：三个直接客户，税后月 18,000（客户甲 6,000、客户乙 5,000、客户丙 7,000）。她的小时价值按第 9 章的口径算：她实际还能再卖出去的那一小时值 220 元。
第 13 个月她上线了一个可自助购买的模板产品，这是一条真正的产品收入。第 18 个月它稳定在毛收入 5,400／月。
她自己的算法是 5,400 − 520（工具订阅与结算手续费）= 4,880。把全部成本列出来之后：
| 项 | 月额 | 这一项是什么 |
|---|---|---|
| 毛收入 | 5,400 | — |
| 工具订阅与结算手续费 | −520 | 账单上有 |
| 获客成本 | −1,400 | 为维持这个销量每月必须重新投入的推广与素材外包 |
| 她自己的时间 | −2,420 | 11 小时（答疑、改版、对账）× 220 |
| 净增量 | 1,060 |
- 她的算法：4,880
- 真实净增量：5,400 − 520 − 1,400 − 11 × 220 = 1,060
- 两个数差 4,880 − 1,060 = 3,820，相当于毛收入的 70.74%
- 从毛收入看，被成本吃掉的部分 = (5,400 − 1,060) ÷ 5,400 = 80.37%
但更重要的那件事在相关性上。 这个产品的全部询单来自同一个内容平台的推荐流。而客户丙（月 7,000）也是两年前从那个平台找来的，至今没有签直接合同、她手上只有那个平台内部的会话窗口——按第 17 章那条判据，这是借来的触达。所以这两笔要填同一个 dependencyGroup。
把毛收入记进去，按两种分组各跑一次 incomeDependency：
| 分组方式 | 总计 | 最大组 | 占比 |
|---|---|---|---|
| 按客户与条目（她原来的表） | 23,400 | 客户丙 7,000 | 29.91% |
按 dependencyGroup（平台丙组 = 客户丙 + 产品） | 23,400 | 平台丙 12,400 | 52.99% |
29.91% → 52.99%，金额一分不动。
再把产品那一行从毛收入 5,400 换成净增量 1,060（这是另一个口径，不能和上面混用）：
- 总计 19,060，平台丙组 = 7,000 + 1,060 = 8,060 ÷ 19,060 = 42.29%
三个数一起读才有意义：这条第二条收入让她的总收入多了 1,060（+5.89%），同时让她最大的依赖组从 29.91% 升到 52.99%。 它增加了收入，提高了集中度。
她的结论不是「这个产品不该做」。1,060 是正的，而且产品收入的斜率和劳动收入不一样——多卖一份不用她多花交付时间。她的结论是两条具体的动作：把客户丙从平台会话窗口转成直接联系（这件事不花钱），以及把那 1,400 的获客成本按来源拆开，看有没有一条不依赖那个平台的。两条做完之前，这条收入在抗冲击的意义上不算第二条。
算一遍
这一章在课程数据里登记的口径是 incomeDependency。要算的三样东西：第一样用下面那个实验室真算，第二样和第三样是加减法，用纸笔和一个普通计算器就能复算。口径的完整定义在口径索引。
第一步：同一笔钱，换一个分组键换一个结论
incomeDependency默认输入是秦那张表：工资 25,000、项目奖金 3,000、外包／顾问费 6,000、出租房净租金 3,000、基金分红 800，合计 37,800／月。默认分组下最大依赖组是雇主 A（工资 + 奖金），占 74.07%，一共四个经济依赖组。
下面那个开关是这整个组件的重点：它只改一个分组键，不改任何一笔金额。 三个实验按顺序做一遍。
实验一：勾上那个开关（分组变，金额不变）。 勾上「那笔外包其实是原雇主换了个合同主体付的」。收入条目还是五条，总额还是 37,800，一分没动。
- 最大依赖组：雇主 A 从 28,000 变成 34,000
- 占比：74.07% → 89.95%
- 组数：4 → 3
15.88 个百分点的跳变，全部来自一个分组键。这就是秦第 25 个月那 8.88 个月差额的来源。先把开关勾回去再做下面两个实验。
实验二：把第二条收入翻倍（6,000 → 12,000），然后勾开关。 把外包那根滑块从 6,000 拖到 12,000，总额变成 43,800。
- 开关关着：雇主 A 28,000 ÷ 43,800 = 63.93%（客户 B 升到 27.40%）
- 开关勾上：雇主 A 40,000 ÷ 43,800 = 91.32%
同一笔努力，两个相反的方向。 分组正确时，第二条收入翻倍把集中度从 74.07% 降到 63.93%；分组错误时（它其实是同一个雇主），同样的翻倍把集中度从 89.95% 推到 91.32%——越努力越集中。所以「要不要加大第二条收入」这个问题，必须先把分组键填对才能回答。
实验三：把工资和奖金都拖到 0（模拟最大依赖组归零）。 工资 0、奖金 0，其余不动，总额变成 9,800。
- 最大依赖组变成客户 B：6,000 ÷ 9,800 = 61.22%，出租房 30.61%，证券账户 8.16%
这一步要看的不是 61.22% 本身，是它说明的那件事：失去最大依赖组之后，下一个依赖组立刻变成新的单点。 而如果那笔外包和雇主 A 本来就是一组（把开关勾上再看），剩下的 6,000 也跟着归零，剩下的就只有 3,800。
还有一件更隐蔽的事在资产那三张表里。 默认输入下，最大的收入依赖组是「雇主 A」，而最大的资产集中组之一也是「雇主 A 的股票与期权」（200,000）——同一个主体同时是你最大的收入来源和一笔主要资产。类型上一个是劳动收入、一个是资本收入，相关性上它们是一组。组件里那三个占比不会提醒你它们相关，所以这件事只能靠你自己在表上标出来。
收入依赖：按经济依赖组，不按条目数
| 分组 | 金额 | 占比 |
|---|---|---|
| 雇主 A | 28,000 元 | 74.1% |
| 客户 B | 6,000 元 | 15.9% |
| 出租房 | 3,000 元 | 7.9% |
| 证券账户 | 800 元 | 2.1% |
资产集中度：按 concentrationGroup
| 分组 | 金额 | 占比 |
|---|---|---|
| 本地房产 | 1,800,000 元 | 77.9% |
| 宽基指数 | 250,000 元 | 10.8% |
| 雇主 A | 200,000 元 | 8.7% |
| 现金与存款 | 60,000 元 | 2.6% |
地区集中度：按司法环境
| 分组 | 金额 | 占比 |
|---|---|---|
| 中国内地 | 2,010,000 元 | 87.0% |
| 美国 | 300,000 元 | 13.0% |
勾上那个开关再看第一张表：收入条目还是五条，金额一分没动，分组从四组变成三组，最大依赖组的占比直接往上跳。 「我有三份收入」这句话里，有几份是真的独立，取决于分组，不取决于条目数。 默认这组输入里还有一件更隐蔽的事——最大的资产集中组和最大的收入依赖组是同一个主体「雇主 A」。 公司出问题的那一天，这两张表会同时变色，而上面这三个占比不会提醒你它们相关。
第二步：两条收入的「同时失效」判断表
这是这一章的核心手算，而且它不需要任何计算器——它需要的是把条件一条一条写下来。
做法三步：（1）给每一条收入列出全部失效条件；（2）标出共用的那几条；（3）把共用条件覆盖的金额加起来。
用秦那张表（五个条目，开关勾上后的真实分组）：
| 失效条件 | 工资 25,000 | 奖金 3,000 | 外包 6,000 | 租金 3,000 | 分红 800 | 共用？ |
|---|---|---|---|---|---|---|
| 雇主 A 裁掉她所在的产品线 | ✓ | ✓ | ✓ | 共用 | ||
| 雇主 A 预算冻结或延迟付款 | ✓ | ✓ | ✓ | 共用 | ||
| 她本人长期无法工作 | ✓ | ✓ | ✓ | 共用 | ||
| 项目考核没达标 | ✓ | 独有 | ||||
| 关联主体注销或换采购流程 | ✓ | 独有 | ||||
| 租客退租、空置或房屋大修 | ✓ | 独有 | ||||
| 所在片区租金下行 | ✓ | 独有 | ||||
| 基金减少或暂停分配 | ✓ | 独有 |
读这张表只看三个数：
- 共用条件 3 条，每一条都同时命中工资、奖金、外包。
- 这 3 条覆盖的金额 = 25,000 + 3,000 + 6,000 = 34,000，占 37,800 的 89.95%——和
incomeDependency给出的最大依赖组占比完全一样。两个方法必须对得上，对不上说明分组键填错了。 - 没有任何一条共用条件跨过第四列和第五列。 租金和分红与前三笔的失效条件交集是空的，所以它们是真正独立的——这正是第 25 个月剩下 3,800 的原因。
三条使用规则：
- 「同一个人付钱」不是分组依据，「同时失效」才是。 外包那一笔的付款主体和工资不同，但三条共用条件一条不差。
- 只要有一条共用条件足以让两笔同时归零，这两笔就合并。 不需要全部条件都重合。
- 自己的健康是最容易漏掉的那一行。 它会同时命中所有劳动收入与软件杠杆收入——不管它们来自几个雇主、几个行业。这一行也是第 6 章那一章存在的理由。
把这张表做成一个可以复算的数： 共用条件覆盖金额 ÷ 总收入。秦的是 34,000 ÷ 37,800 = 89.95%。这个数就是她的收入集中度，而且它是从条件推出来的，不是从账户数或客户数推出来的。
第三步：一条新收入的净增量
第二步算的是相关性，这一步算金额——一条新收入在扣完全部成本之后真正剩下多少。
式子四项：
净增量 = 毛收入 − 获客成本 − 持续成本 − 自己的时间 × 小时价值
用唐的数（毛收入 5,400、获客 1,400、持续 520、11 小时、小时价值 220）：
| 算法 | 结果 | 它漏了什么 |
|---|---|---|
| 只看毛收入 | 5,400 | 漏了全部三项成本 |
| 毛收入 − 账单上的成本（她原来的算法） | 4,880 | 漏了获客成本与她自己的时间 |
| 毛收入 − 账单 − 获客 | 3,480 | 漏了她自己的时间 |
| 全部扣完（净增量） | 1,060 | — |
四个数摊开来看：
- 「只看毛收入」比真实净增量高 5,400 − 1,060 = 4,340，是净增量的 4.09 倍。
- 她原来那个算法高 4,880 − 1,060 = 3,820，相当于毛收入的 70.74%。
- 被成本吃掉的比例 = 4,340 ÷ 5,400 = 80.37%。
最大的那一项是她自己的时间：2,420，占三项成本总额 4,340 的 55.76%。 而它是唯一不出现在任何账单上的一项。这不是巧合，而是这一类收入的常见形状——所以这一项不能用「反正我有空」来当成零。小时价值的口径是你实际还能再卖出去的那一小时的价格，不是「月收入 ÷ 160」。
再算两个边界，这一步才算完整：
（1）获客成本降到 0 会怎样。 1,400 不花了，净增量变成 1,060 + 1,400 = 2,460？不会——获客停掉，销量会往下走，不是停在原地。正确的问法是：毛收入要掉到多少，这条收入的净增量就变成 0？ 固定成本 520 + 时间 2,420 = 2,940，所以毛收入掉到 2,940 + 当时的获客成本以下就不划算了。如果获客完全停掉、毛收入掉到 2,000，净增量 = 2,000 − 520 − 2,420 = −940——负的，而且她每月还在花 11 小时。
（2）同样的 11 小时直接卖掉值多少。 11 × 220 = 2,420／月，是净增量 1,060 的 2.28 倍。
第二个数不是「所以不该做产品」的结论。两者的区别在斜率，不在当下的金额：那 11 小时的支持时间不会随销量线性增长（答疑有重复、改版是一次性的），而直接卖小时是严格线性的。所以这个比较要写成一个条件：如果毛收入翻倍到 10,800、支持时间只涨到 15 小时、获客成本涨到 2,200，净增量 = 10,800 − 520 − 2,200 − 15 × 220 = 4,780，就超过了同样小时数直接卖掉的 15 × 220 = 3,300。
这个条件就是这条收入值不值得继续投的判据，而它必须在投之前写下来。 怎么用最小成本验证它、时间盒多长、什么条件下停，是第 18 章的事。
这三步算出来的数不要加成一个总分
集中度（89.95%）、共用条件数（3）、净增量（1,060）这三样不可比，也没有公认的加权方式。它们各自管一件不同的事：集中度管「最大那一下有多大」，共用条件管「那一下什么时候来」，净增量管「新开的这条到底补上了多少」。
Fragility Map 那张表也没有总分列，理由是同一个。一个总分会把「后果不可逆」和「后果可修复」压成同一个数字，而这正是第 1 章说过不能做的事。
你的行动
成果是一页纸，三块：一张收入表、一张失效条件表、三行结论。一个文本文件就够。
第一块：收入表
每一行六列，一列都不能空。有一列填不出来，说明那一笔你还没真正看清。
收入 税后月额 类型（四类之一） dependencyGroup 稳定性 失效条件 获客成本／月 劳动／软件杠杆／产品／资本 按「会不会同时断」填 合同／波动／一次性 列全，标出共用的 现金 + 小时 × 小时价值
六条填表规则：
- 「类型」只有四个值：劳动收入、软件杠杆收入、产品收入、资本收入。判据是机制那一节的三句话。用工具提效的劳动收入填软件杠杆，不填产品。
dependencyGroup按「会不会同时断」填，不按付钱的人填。 换了合同主体、换了发票、换了行业名称都不构成一个新组；决定这笔钱存不存在的还是同一个主体或同一件事，就填同一个组名。- 「稳定性」只有三个值：合同收入、波动收入、一次性收入。波动收入要在后面括号里写上你观测到的区间，没有区间的波动收入等于没填。
- 一次性收入单独一行，并写明它现在在哪。 如果它已经进了安全资金，就在这一行注明「已计入安全资金，不再算每月收入」。
- 「失效条件」至少写三条，而且必须包含「我本人长期无法工作」这一条（它会命中你全部的劳动收入与软件杠杆收入）。
- 「获客成本」是现金加小时折价。 没有获客动作的收入（比如工资）填「—」；有获客动作但你没记过的，填「未记录」——这是一个信息缺口，不要填 0。
填好的示例（秦，第 25 个月之后重做的那一版）：
收入 税后月额 类型 dependencyGroup 稳定性 失效条件 获客成本／月 工资 25,000（已归零） 劳动收入 雇主 A 合同收入 A 裁产品线（共用）／A 预算冻结（共用）／我本人无法工作（共用） — 项目奖金 3,000（已归零） 劳动收入 雇主 A 波动收入（12 个月区间 0–6,000） 上面三条（全部共用）／项目考核没达标 — 外包／顾问费 6,000（已归零） 劳动收入 雇主 A（付款主体是关联方，批预算的是同一个人） 合同收入（一年一签） 上面三条（全部共用）／关联主体注销 未记录（这笔从来不用我自己找人） 出租房净租金 3,000 资本收入 出租房 合同收入（租约剩 8 个月） 租客退租或空置／房屋大修／片区租金下行 中介佣金，换租客时一次性约 3,000，折月 250 基金分红 800 资本收入 证券账户 波动收入（12 个月区间 300–1,500） 基金减少或暂停分配 — 跑一遍
incomeDependency（按真实分组）： 总计 37,800，最大依赖组雇主 A 34,000，占 89.95%，三个组。 我原来那张表的答案是 74.07%，差 15.88 个百分点，差额全部来自外包那一行的分组键。
第二块：失效条件表
把第一块里的失效条件横过来排，一行一个条件，一列一笔收入，命中打 ✓。格式照抄「算一遍」第二步那张表。
填完算两个数：
共用条件数 = 同时命中两笔以上收入的条件有几条。秦的是 3。 共用条件覆盖金额 ÷ 总收入 = 34,000 ÷ 37,800 = 89.95%。
这个数必须和
incomeDependency给出的最大依赖组占比一致。不一致，就是分组键和失效条件两边有一边填错了，回去改到一致为止。
第三块：三行结论
第一行——我最大的经济依赖组是什么、占多少、它的共用失效条件有哪几条。 示例：雇主 A，占 89.95%，三条共用条件（裁产品线／预算冻结／我本人无法工作）。按客户条目看是 74.07%，那个数不是这个问题的答案。
第二行——如果这个组归零，我剩下什么、能撑几个月。 示例：剩 3,800／月（只有出租房与分红，它们和雇主 A 没有共用失效条件）。月必要现金流出 16,000，净缺口 12,200，112,000 ÷ 12,200 = 9.18 个月。我原来按错的分组算出来是 18.06 个月，差 8.88 个月。Runway 本身（不算残余收入）是 7.0 个月，目标月数 9，缺口 32,000。
第三行——这个季度的一个动作，并说明它是「降依赖」还是「做稳现有的」。 两类动作地位相同，选哪一类要写出理由。示例（降依赖）：我手上唯一一条和雇主 A 不共用失效条件的能力是那套交付方法，这个季度先找一个和原行业无关的客户试一次，上限是现金 2,000 和 24 小时。示例（做稳现有的）：先不开新收入——我的 Runway 还差 32,000 才到目标月数，这个季度把缺口补到一半，同时把出租房的租约从一年一签改成两年。
如果你现在只有一条收入，这份产出照样写得完：第一块一行，第二块把那一条的失效条件列全，第三行写「先把它做稳」以及具体要减掉哪一个失效条件。这是一份完整的 Income Architecture，不是一份没做完的。
重做这份表的触发条件
写在同一页底部：
- 任何一笔收入的付款主体、合同主体或合同期限变了；
- 新增或失去一笔收入；
- 最大
dependencyGroup的占比变动超过 10 个百分点； - 发现某两笔收入其实共用一条失效条件（分组键要合并）；
- 换雇主、换行业，或者从在职变成独立、从独立变成在职；
- 每季度至少一次，无论以上有没有发生。
这一章不处理的四件事
不评估你的能力在市场上值多少钱（第 13 章）；不讨论怎么用工具把单位时间产出提上去（第 14 章）；不处理同一条收入的上限结构（第 15 章）；不处理来询从哪里来、渠道断掉值多少钱（第 17 章）；不设计新收入的最小验证实验（第 18 章）。
顺序是故意的：先知道现有这几笔收入的相关性和失效条件，再决定要不要开新的、开哪一条、怎么验证。反过来做，最常见的结果是开了一条和原来共用全部失效条件的第二条收入，然后在同一个月里失去两条。
检查标准
- 我的收入表每一行都填满了六列（金额、类型、dependencyGroup、稳定性、失效条件、获客成本），没有任何一列用「大概」或「不少」填过去。
- 我检查过那些看起来独立的收入是不是同一个依赖组：逐笔核对了付款主体、合同主体，以及「决定这笔钱存不存在的是谁」，并且能说出按条目算和按依赖组算的两个占比各是多少、差了几个百分点。
- 我的失效条件表列全了每一笔的触发条件（包含「我本人长期无法工作」这一条），标出了共用的那几条，并且「共用条件覆盖金额 ÷ 总收入」和 incomeDependency 给出的最大依赖组占比对得上。
- 我把每一笔收入标了四类之一（劳动／软件杠杆／产品／资本），而且能说出判断依据；我没有把需要持续获客、维护与服务的产品收入当成不用做事的收入。
- 我按三档稳定性分开记了收入，波动收入写了观测区间、一次性收入注明了它现在在安全资金里还是在收入里，而且我算过「只靠合同收入能撑几个月」这个推论与 Runway 本身的区别。
- 我算过每一条新收入的净增量（毛收入 − 获客成本 − 持续成本 − 我自己的时间 × 小时价值），并且和「只看毛收入」对比过；这个季度的动作我写明了是「降依赖」还是「把现有这一条做稳」，以及为什么选它。
容易搞错的地方
以为收入条数就是收入来源数。
实际口径的计算单位是 dependencyGroup，同一个键的金额先合并再算占比。秦有五个条目、她以为有四个来源，真实分组是三个，其中一个占 89.95%。后果：「我有三条收入」这句话带来的安心会推迟建立真正的备份，而推迟的那段时间正好是备份还来得及建的时候。
以为换了合同主体就换了依赖组。 实际判据是「会不会同时失效」。秦那笔外包付款主体不同、发票不同、合同不同，但批预算的是同一个人，三条共用失效条件一条不差，所以它和工资是一组。后果：她第 24 个月算出能撑 18.06 个月，第 25 个月实际是 9.18 个月，差 8.88 个月——安全资金一分没少，差的全部来自一个分组键。
以为第二条收入做大就一定降低集中度。 实际方向取决于分组。同样把外包从 6,000 拖到 12,000：分组正确时集中度从 74.07% 降到 63.93%，分组错误时（它其实是同一个雇主）从 89.95% 升到 91.32%。后果：越努力越集中，而且努力的方向看起来完全合理，所以没人会去复查那个分组键。
以为稳定性就是金额大小。 实际它是另一个维度。冯月均 24,000，但只有 9,000 是合同收入，覆盖率 66.67%；波动收入最低的那个月只有 2,000，当月差 2,500，过去 12 个月出现过 3 次。后果：用月均数做需要稳定性的判断，于是在波动收入最低的那几个月里被迫动用安全资金，而计划里从来没有这几个月。
把一次性收入算两遍。 实际它进了安全资金（分子）之后就不能再当每月收入算一次。冯那 72,000 已经在 81,000 里，如果再当成「每月 6,000」，这笔钱就在余额和流量里各出现一次。后果：一个看起来每月结余 10,500 的人，实际只靠合同收入每月差 4,500——而明年没有一次设备可以再转让一遍。
只看第二条收入的毛收入。 实际要扣三项：获客成本、持续成本、自己的时间 × 小时价值。唐的毛收入 5,400，净增量 1,060，被吃掉 80.37%；三项成本里最大的是她自己的 11 小时（2,420，占 55.76%），而它不出现在任何账单上。后果：按 4,880 这个数判断「这条路成立」，于是继续投，而真正的判据是「毛收入涨到多少、支持时间涨到多少，它才超过同样小时数直接卖掉」。
以为可扩展就是不用做事。 实际一个 SaaS 或知识产品不会自动形成被动收入——它仍然需要持续获客、维护、服务与合规投入，而且获客成本是每月重新发生的，停掉它销量会往下走。唐把获客停掉、毛收入掉到 2,000 之后，净增量是 −940，而她每月还在花 11 小时。后果：把持续成本记成零，于是在最忙的那个月同时发现产品在掉、主业也没时间做。
以为新开的收入一定改善脆弱性。 实际它可能同时改善一项、恶化另一项。唐的产品让总收入多了 1,060（+5.89%），同时让最大依赖组从 29.91% 升到 52.99%——因为它的全部询单和客户丙来自同一个平台。后果：Fragility Map 的 Income 那一行好看了一点，Platform 那一行变差了很多，而只看收入条数的人两件事都不会发现。
以为「人人都该有多条收入」。 实际这一章的结论是两个地位相同的下一步：降低依赖，或者把现有这一条做稳。后者不需要爬坡期、不需要新渠道、不占用你本来就不够的小时，在很多情况下更划算。后果：在 Runway 还差 32,000 才到目标月数的时候去开第二条收入，用一条还没验证的新路去消耗那笔本来用于撑过失业的钱——这正是第 1 章那条下行螺旋的起点。
本章自测
不要回头翻，先自己答一遍。
- 判断两笔收入是不是同一个经济依赖组，要看的那一句话是什么？为什么「换了合同主体、换了发票」不构成一个新组？
- 秦的五个条目，总额 37,800。为什么按她原来那张表算是 74.07%，按真实分组算是 89.95%？这 15.88 个百分点来自哪里？
- 她第 24 个月算出「能撑 18.06 个月」，第 25 个月实际是 9.18 个月。这两个数的分子分母分别是什么？它们和 Runway 口径（7.0 个月）的区别在哪？
- 四类收入的判据是哪三句话？为什么软件杠杆收入仍然属于劳动收入那一边？
- 三档稳定性在 Runway 的分子、分母和「失去主收入之后的缺口」上各起什么作用？一次性收入为什么不能同时进分子和每月收入？
- 冯月均 24,000，为什么说只有 9,000 能进计划？他的收入集中度按客户条目算是 37.5%、按依赖组算是 59.17%，决定他哪个月过不去的是哪一个？
- 一条新收入的净增量式子有哪四项？唐的毛收入 5,400 扣完之后是多少，三项成本里最大的那一项是哪一项、占多少？
- 把外包从 6,000 拖到 12,000，为什么在两种分组下集中度的变化方向相反？两个数分别是多少？
- 你自己那张失效条件表上，共用条件有几条、覆盖金额占总收入多少？这个数和
incomeDependency给出的最大依赖组占比对得上吗？ - 你这个季度的动作是「降依赖」还是「把现有这一条做稳」？为什么是它而不是另一个？
第 1、2 题答不上来，回到「算一遍」第一步，自己把那个开关勾一次，看 74.07% → 89.95% 这一跳。第 5、6 题答不上来，回到机制里那张稳定性对照表。第 9、10 题答不上来，说明「你的行动」还没做完——那一页纸加一张填满的失效条件表，才是这一章的成果。
Phase III 目录里这一组章节的分工很清楚：第 15 章问「这条路上限在哪」，这一章问「几条路之间是什么关系」，第 17 章问「来询从哪里来」，第 18 章问「怎么用最小成本验证一条新的」。四份产出合起来才是 90-Day Income Expansion Plan，而这一章负责的那一份是：让你知道自己手上那几笔收入，在最坏的那一个月里到底会剩下几笔。
这一章对应的 Knowledge Object：
- 核心问题
- 第二条收入和第一条有多大关系？
- 学习目标
- 能按「会不会同时失效」给每一笔收入填 dependencyGroup，算出自己真实的收入集中度，并算出一条新收入扣完全部成本之后真正剩下多少。
- 基础解释
- 条数不是口径。收入集中度的计算单位是经济依赖组：同一个 dependencyGroup 的金额先合并再算占比。分组看的是失效条件清单的交集，不看钱从哪个账户进来、谁签的合同、开的是哪张发票。
- 进阶解释
- 四类收入（劳动／软件杠杆／产品／资本）与相关性是两个独立维度，同一个主体可以同时是你最大的收入来源和一笔主要资产。稳定性是第三个维度：合同收入可以减在缺口里，波动收入只能用观测区间的下端，一次性收入进了安全资金就不能再当每月收入算一遍。分组键填错时，加大第二条收入会把集中度推高而不是降低；而「把现有这一条做稳」和「降低依赖」是地位相同的两个下一步。
- 例子
- 秦五个条目合计 37,800：按她原来那张表最大依赖组是 74.07%，把那笔「客户 B」的外包改回雇主 A 之后是 89.95%，金额一分没动——第 24 个月她因此算出能撑 18.06 个月，第 25 个月实际是 9.18 个月。把外包从 6,000 拖到 12,000，分组正确时集中度降到 63.93%，分组错误时升到 91.32%。唐的产品毛收入 5,400，扣完获客 1,400、账单 520 与 11 小时 × 220 之后，净增量只剩 1,060。
- 计算或实验
incomeDependency- 现实行动
- 做出 Income Architecture：一张六列收入表、一张失效条件表，加三行结论（最大依赖组与它的共用失效条件、它归零后剩什么、这个季度是降依赖还是把现有这一条做稳）。
- 检查标准
- 能说出按条目算和按依赖组算的两个占比各是多少、差额来自哪一个分组键
- 自己那张失效条件表的「共用条件覆盖金额 ÷ 总收入」和 incomeDependency 给出的最大依赖组占比对得上
- 能算出一条新收入的净增量（毛收入 − 获客成本 − 持续成本 − 自己的时间 × 小时价值），并说出三项成本里最大的是哪一项
- 关联概念
- WF-FRAGILITY-003、WF-RUNWAY-002、WF-DIST-017
- 来源
- prd-v1.md 第 07 节 Phase III（严格区分劳动收入、软件杠杆收入、产品收入、资本收入）；prd-v1.md 第 10.5、10.6 节；prd-v1.md 第 12 节 Income 维度
- 最近核对
- 2026-10-17
带走的结论
两条收入依赖同一个雇主或同一个行业时，它们不是两条收入。
自评（三项是分开的，不要一起勾）
进度只存在这台设备的浏览器里，不会上传。清理浏览器数据、换设备或使用隐私窗口都会丢失，请用下面的导出保留一份。