第16章 AI 依赖的风险：账号、模型、平台变量
第 15 章给了你 30 天跑通第一个信号的方法。当第一个信号出现，你会立刻撞上一种结构性的脆弱——你的整个生意，跑在三家以上你不可控的供应商上：模型供应商、云平台、账号体系。这不是「要不要用 AI」的问题（用了，红利才在）；这是「用了之后怎么不被单点故障清零」的问题。本章是第五篇「守」的开篇，专门拆解这种依赖性风险的本质。第 17 章接着给脆弱性测试与对冲的具体方法。
16.1 结论先行：你的生意建在别人的 API 上
一句话主张：超级个体的最大结构性风险，是把命脉交给了自己不可控的三层——模型供应商、云平台、账号体系。
这不是反对用 AI。WLM 三环里 L 环（杠杆）当前最强形态就是 AI 编排——你不用，窗口期红利就白白流走。但每接入一家供应商，你就在自己生意地基上多垫了一块不归你管的砖：它什么时候涨价、什么时候断供、什么时候封你账号，全在你能控的边界之外。
依赖性风险 = Σ( 单点节点 × 失效概率 × 击穿半径 )
单点节点：模型 API、云平台、API Key、分发渠道、支付账号、域名……
失效概率：封号 / 涨价 / 断供 / 降智 / 政策变化 / 区域限制……
击穿半径：从「能用」到「不能赚」的损失程度（按 W / L / M 三环分别计）多数人会本能地把「失效概率」往低估——「OpenAI 不会封我」「Stripe 不会无故冻我」。这种本能的根源是过去十年的消费互联网经验。但你现在的身份变了——从消费者变成了商业用户，触发风控、违反 ToS、关联封禁的概率比消费场景高一个数量级。更要命的是，失效概率本身不重要，击穿半径才重要：一个 $0.01 概率的事件，如果击穿的是你 100% 的月收入，期望损失就是月收入的 1%——这远高于你愿意支付的保险费。
依赖性风险的 WLM 击穿点很清晰：
- 击穿 W 环（窗口）：品类监管落地、平台政策变化，让你踩中的时机红利直接归零。
- 击穿 L 环（杠杆）：API 涨价、模型断供、token 计费规则改变，AI 编排杠杆瞬间失效，单位经济模型反转。
- 击穿 M 环（护城河）：账号被封、内容下架、客户关系清零，积累数月的复利资产一夜归零。
理解这一点后，本章其余都在回答一个问题：这种依赖性风险长什么样、怎么系统识别、怎么与工程层的「安全红线」区分开。
16.2 依赖性风险是什么：定位、能力与边界
与「工程红线」的差异
这是本书最容易被混淆的一组概念。先把层次划清楚：
| 维度 | 战略层依赖性风险（本书第 16 章） | 工程层风险红线（《一人公司产品工程》第 28 章） |
|---|---|---|
| 层次 | 生意架构层 | 代码/执行层 |
| 关心 | 关键路径依赖哪些外部节点？失效后损失多少？ | 密钥/凭据/数据/操作有没有被泄露或破坏？ |
| 失败后果 | 收入断流、生意归零、客户清零 | 安全事故、数据泄露、合规罚款 |
| 典型问题 | OpenAI 涨价 3 倍，我的成本结构崩不崩？ | 我的 API Key 是不是硬编码进了前端？ |
| 持有者 | 你（老板/创始人） | 你或工程负责人 |
| 应对工具 | 依赖地图 + 多供应商冗余 + 降级路径 | 密钥管理 + 权限审计 + 破坏性操作守门 |
一句话区分：工程红线问的是「我的代码会不会被攻破」，战略依赖风险问的是「我的生意会不会被供应商卡死」。 两者都需要，但不要拿工程层的密钥管理去解决战略层的单点依赖——那是错位。前者详见《一人公司产品工程》第 28 章「风险红线」，本书只讲后者。
能做什么 / 不能做什么（边界）
依赖性风险这一视角，能做三件事：
- 识别：列出你生意依赖的所有外部节点，标出哪些是单点（SPOF, Single Point of Failure）。
- 量化击穿半径：估算每个单点失效后，按周/月损失多少收入、多少客户、多少资产。
- 设计对冲：为高击穿半径节点准备降级路径——多供应商、冗余账号、或一份应急剧本。
它不能做三件事：
- 不能消除依赖本身。只要你用 AI，就一定有依赖；零依赖等于零杠杆。目标是「可控」而非「消除」。
- 不能预测失效时点。能做的是降低失效发生时的损失，而不是预测它何时发生。
- 不能替代工程层安全规范。账号冗余不能弥补 SQL 注入，密钥管理也不能弥补供应商断供。
16.3 三层依赖拆解 + 依赖地图
把依赖拆成三层：模型层（智能来源）/ 平台层（交付与分发）/ 账号层（认证与资金）。三层各有典型失败场景，影响半径不同。
┌──────────────────────────────────────────────────┐
│ 你的生意（顶层） │
│ 产品 / 内容 / 服务 / 客户关系 / 现金流 │
└──────────────────────┬───────────────────────────┘
│
┌────────────────┼────────────────┐
▼ ▼ ▼
模型层 平台层 账号层
(智能来源) (交付 + 分发) (认证 + 资金)
│ │ │
┌───┴────┐ ┌────┴────┐ ┌────┴────┐
│OpenAI │ │ Vercel │ │ API Key │
│Claude │ │Cloud- │ │(各家) │
│Google │ │ flare │ │ │
│DeepSeek│ │ GitHub │ │ 平台账号 │
│开源模型 │ │ Stripe │ │(内容/代码)│
│ │ │X/小红书 │ │ │
│ │ │ 邮件服务│ │ 支付账号 │
│ │ │ │ │ 域名 │
└────────┘ └─────────┘ └─────────┘
失败场景: 失败场景: 失败场景:
模型换代 云厂商故障 API Key 吊销
降智/限流 仓库封禁 平台账号封禁
涨价 渠道限流 支付账号冻结
断供/区域限制 政策变化 域名被停
价值观漂移 支付风控 关联封禁16.3.1 模型层：智能来源的脆弱性
模型层是最显眼的依赖，但脆弱点比想象的多。
场景一：模型换代导致能力迁移。 厂商每次发新版（GPT-4 → GPT-5、Claude 3.5 → Claude 4），都伴随能力特性变化。新一代不一定在所有维度都更强——某种特定 prompt 工程、某种风格输出，在新版本上可能反而退化。你针对旧版本深度优化过的 prompt、思维链、系统提示词，可能直接失效。这是结构性能力迁移：不是「新旧版本哪个强」，是「你的产品绑定的是某一版本的特定行为，而这个行为会被迭代清零」。
场景二：静默降级或限流。 厂商有权在不公告的情况下调整模型行为——推理深度、上下文窗口、并发上限、拒绝率。这种现象在 2023-2026 年的 AI 行业里被反复观察到（行业普遍反馈，无独立第三方审计）：同一版本 API，不同时期调用，输出质量会有明显差异。
场景三：价格剧变。 API 涨价、免费额度取消、token 计费规则改变（如开始对缓存命中收费、对推理 token 单独计价）。每一次计费规则变化，都会重写你的单位经济模型。
场景四：断供与区域限制。 出口管制、芯片禁令、IP 屏蔽、本地化合规要求，都可能导致某家模型某天对你的区域不可用。客户主要在中国大陆而产品深度依赖某家受出口管制厂商，这条依赖就是定时炸弹。
场景五：价值观对齐漂移。 厂商持续调整模型的安全策略和价值观对齐。这意味着同一 prompt 在不同时期可能输出截然不同的内容——产品行为变得不可预测。一个上周还能正常跑的流水线，这周可能突然批量拒绝。
影响：模型层失效直接击穿 L 环（杠杆）。如果产品功能绑定某个特定模型能力（如长上下文、某种推理模式），影响半径会扩散到 M 环（产品失效 → 客户流失 → 复利归零）。
16.3.2 平台层：交付与分发的脆弱性
平台层比模型层更隐蔽——你以为自己在「用工具」，实际上你在「租渠道」。
场景一：云平台故障。 AWS / Cloudflare / Vercel / Azure 都出过重大故障。几小时的故障对一个日活工具型产品，意味着客户当天工作流被打断、信任被消耗。只有一家云、一个区域、一条 CDN，这种风险完全没对冲。
场景二：代码托管与基础设施封禁。 GitHub / GitLab 有权根据 ToS、地区制裁、申诉失败封禁账号。代码、CI/CD 配置、私有仓库、Issue 与文档——一个账号没了，整套工程资产可能瞬间失去访问权。
场景三：分发渠道封禁或限流。 这是大多数超级个体真正的命门。X、小红书、B 站、公众号、YouTube——你在哪里获客，就在哪里有把柄。一次误判、一条举报、一次平台政策调整，账号可能被限流、降权、封禁。分发渠道的封禁不是「小概率事件」，它是任何内容创作者职业生涯中迟早会遇到的事件。 关键不是会不会发生，是发生时你还剩什么。
场景四：支付平台风控。 Stripe、Paddle、跨境收款服务的风控规则在不公告的情况下持续收紧。一次异常的订单增长、一笔来自高风险国家的退款、一次客户投诉，都可能触发账户冻结。冻结期间，已收款也可能被冻结 90-180 天。
场景五：政策与监管变化。 GDPR、数据出境合规、内容审查、AI 生成内容标识要求、特定品类（如医疗/金融/法律 AI 工具）的准入门槛——这些变化可能在很短时间内让你的产品在某市场不可售卖。
影响：平台层失效直接击穿 W 环（窗口/时机红利）和 L 环（交付能力）。最致命的是分发渠道失效——它会同时击穿 M 环（获客资产清零）。
16.3.3 账号层：认证与资金的脆弱性
账号层是三层里最容易被低估的——因为它看起来太基础。但账号层的失效，往往是一刀切、无救济的。
场景一：API Key 被吊销。 违反使用条款（批量注册薅额度、内容违规、关联账号被封）、平台反作弊触发、误判——任何一种都会让 Key 在几分钟内失效。只有一把 Key、没有备份，整个产品立刻停摆。
场景二：平台账号封禁。 单个平台账号被封，意味着该账号上的所有内容、关注者、客户私信、历史数据全部失去访问权。获客、客服、品牌展示集中在一个账号上，这一击就是清零级别。
场景三：关联封禁（最阴险的一种）。 多数平台的反作弊系统会基于邮箱、手机号、IP、设备指纹、支付方式做关联识别。一个账号被封，关联的其他账号可能被一并封禁。你以为「我有三个备用账号」很安全，结果三个账号同时没了——因为它们共享了同一个收款 PayPal。
场景四：支付账号限制。 Stripe 风控冻结、银行跨境收款被切断、信用卡被发卡行拒付。产品还在跑、客户还在付费，但钱到不了你账上。
场景五：域名被停。 域名注册商有权根据投诉（商标侵权、滥用投诉、政策违规）停掉你的域名。落地页、API 入口、邮件服务全部基于这个域名——一旦被停，整个对外服务立刻不可达。
影响：账号层失效是最直接的单点清零——它不分模型、不分平台，一刀切断你的认证或资金通道。关联封禁尤其危险，因为它会让你自以为有的「冗余」瞬间失效。
16.4 三个心法
心法一：识别你的单点（SPOF）
铁律：你不知道的单点，迟早会击穿你。每月一次盘点「如果这个节点明天没了，我损失什么」。
单点的本质是「失效半径 > 你的承受能力」的节点。判断单点，不看「失效概率」（无法预测），看「失效后你能不能活下来」（可以估算）。
- 落地动作：本周画一张依赖地图（见 16.5），标出所有 ★ 单点节点。
- 落地动作：每个 ★ 单点，写一句话回答「如果它明天没了，我下一周收入是多少、客户流失多少、恢复需要多久」。答不上来 = 你还没真正理解这个依赖。
心法二：分清「可控 vs 不可控」
铁律：你的精力要投在「不可控但有对冲空间」的地方，而不是「可控但低回报」的地方。
有些事你能控（自己的代码质量、数据备份、客户服务），有些事你完全不能控（厂商涨价、平台封号、地缘政治）。把精力花在「不能控但有对冲空间」的环节——多供应商、多账号、多渠道。
- 落地动作：列出所有「不可控」节点，按击穿半径排序，前 3 个必须有对冲方案。
- 落地动作：每接入一家新供应商，立刻问「如果它失效，我的 Plan B 是谁」——答不上来就先不接入。
心法三：每条关键依赖都要有降级路径
铁律：依赖可以集中（性能/成本最优），但必须有显式降级路径（韧性最优）。
集中不是错——早期为追求速度和成本，集中依赖一家供应商是合理的。但集中必须伴随「显式降级路径」：哪怕只是一个文档化的「如果 X 失效，我 24 小时内切到 Y」的剧本。没降级路径的集中，叫赌博；有降级路径的集中，叫经过权衡的策略。
- 落地动作：为每个 ★ 单点节点准备一份「应急剧本」——切换到哪家备选、切换需要多久、切换后损失什么。
- 落地动作：每季度演练一次降级（哪怕只是 dry run，确认备选账号/模型/渠道是活的）。
16.5 实战：画出你的依赖地图
以一个真实场景为例（脱敏自一线实践）：一个人做的 AI 写作助手，月收入约 $8K，主要客户在中文区与海外各半。
产品：AI 写作助手 月收入：$8K（订阅制）
依赖节点 击穿半径（按周）
─────────────────────────────────────────────────────────────
模型层
├── OpenAI API（主力，~70% 调用）★ 单点 高（停摆 → 月损 $5K+）
├── Anthropic API（备选，~30%） 低（已有冗余）
└── DeepSeek（备选备选，未接入） —（待接入）
平台层
├── Vercel（部署）★ 单点 高（产品不可达）
├── Cloudflare（DNS/CDN）★ 单点 高（产品不可达）
├── GitHub（代码 + CI）★ 单点 中（可本地恢复）
├── X / Twitter（海外获客 ~40%）★ 单点 中（获客断流）
├── 小红书（中文获客 ~50%）★ 单点 高（中文获客断流）
└── 邮件服务（Customer IO）★ 单点 中（客户触达断）
账号层
├── OpenAI API Key（1 把）★ 单点 高（同模型层）
├── Stripe（海外收款 ~60%）★ 单点 极高（资金断流）
├── 国内收款（~40%）★ 单点 极高（资金断流）
├── X 账号 / 小红书账号（各 1 个）★ 单点 高（同平台层）
└── 域名（注册商 A，1 个）★ 单点 极高（对外全断）数一下：11 个 ★ 单点。其中 4 个击穿半径是「极高」（产品对外全断 / 资金断流）。这意味着——这个看起来健康的 $8K/月生意，实际有 4 个「明天就可能让它归零」的节点，而当事人一个都没意识到。
验证：
- [ ] 你能在一张纸上画出自己生意的依赖地图（模型/平台/账号三层）。
- [ ] 你标出了所有 ★ 单点节点。
- [ ] 你为每个 ★ 单点估算了击穿半径（按周/月损失多少）。
- [ ] 你能脱口说出自己生意的「极高击穿半径」节点有几个。
失败边界（依赖地图排查）：
| 症状 | 根因 | 处理 |
|---|---|---|
| 没画过依赖地图 | 没意识到这是战略问题 | 本周必画，先粗后细，宁可错画不漏画 |
| 画完发现 5+ 单点 | 早期为省事集中部署 | 按"击穿半径从高到低"逐个去单点 |
| 知道有单点但没降级 | 拖延或成本敏感 | 至少写一份应急剧本（成本几乎为零） |
| 备份账号和主账号关联 | 没去关联 | 关键账号必须独立邮箱/手机/支付方式 |
工程层「密钥管理 / 凭据安全 / 破坏性操作守门」的完整清单，详见《一人公司产品工程》第 28 章「风险红线」。本书只讲战略层的依赖结构，不抄工程层规范。
16.6 战略依赖风险 vs 工程风险：分工与选型
这组区分必须在每个决策点都过一遍，否则你会在错误的层次投入精力。
| 维度 | 战略依赖风险（本书） | 工程风险（solo 第 28 章） |
|---|---|---|
| 关心 | 生意是否还能继续运转 | 代码/数据是否被攻破或误操作 |
| 例子 | OpenAI 涨价 3 倍，成本结构崩不崩？ | 我的 API Key 是否硬编码进前端？ |
| 决策者 | 你（老板） | 你或工程负责人 |
| 应对 | 多模型/多平台/多账号冗余 + 应急剧本 | 密钥管理 + 权限审计 + 破坏性操作守门 |
| 频率 | 季度复盘 + 重大事件触发 | 每次提交/每次发布持续执行 |
决策树：
- 「我的生意依赖哪个外部节点？没了它我损失多少？」→ 战略依赖风险（本书第 16 章 + 第 17 章对冲）
- 「我的代码、密钥、操作会不会被攻破或误操作？」→ 工程风险（solo 第 28 章）
- 「我有没有混淆两个层次，用工程层规范去掩盖战略层单点？」→ 重新分层（最常见的错误）
一个具体例子：你的 API Key 用了密钥管理服务（工程层做得很好），但你只有这一把 Key（战略层是单点）。Key 管得再安全，厂商一旦吊销，你照样停摆。工程层规范解决不了战略层单点。
16.7 失败边界：三种最常见的死法
死法一：把鸡蛋放在一个模型篮子里
症状：产品完全依赖 GPT-4 / Claude 4 / DeepSeek 的某个版本，深度优化针对该模型的 prompt。
根因：早期为追求最佳效果，自然地深度绑定单一模型。prompt 调得越精，绑定越深，越不愿意换。
对抗：双模型策略（主力 + 备选）、prompt 抽象层（屏蔽模型差异）、每季度评估一次备选模型是否仍可用。关键不是「现在用哪家」，是「换家需要多少成本」——把这个成本控制在 1-2 周工作量以内。
死法二：把获客赌在一个平台
症状：90% 客户来自 X / 小红书 / 公众号 / 某单一渠道。渠道红利期效果太好，懒得搭第二个。
根因：单平台红利期回报率最高，人很难抗拒「同样精力，这个渠道效果最好」的诱惑。但红利期结束、平台限流、账号被封，三种情况任一发生，立刻归零。
对抗：渠道配额约束——任何单一渠道不超过总获客的 50%。强制搭建自有阵地（邮件列表、独立站、私域社群），哪怕短期 ROI 更低。自有阵地是 M 环的承重柱，不是获客渠道之一。
死法三：账号体系没有冗余（或假冗余）
症状：一个 API Key、一个支付账号、一个域名商。或者「准备了备份账号」但备份和主账号共享邮箱/手机/IP/支付方式。
根因：账号管理麻烦，开多个要花钱、要维护。更阴险的是「假冗余」——你以为有备份，实际一旦关联封禁，主备一起没。
对抗：关键账号至少双备份，且强制去关联——不同邮箱（最好不同域名）、不同手机号、不同支付方式、不同登录 IP（如可能）。域名分散在多个注册商。支付账号至少两条独立路径。
红线边界：不可让渡的决策
- 关键依赖必须显式列出：不允许「我不知道自己依赖谁」这种状态存在。每季度更新一次依赖地图。
- 高击穿半径节点必须有降级路径：哪怕只是一份文档化的应急剧本。没有降级路径的高击穿节点 = 赌博。
- 关键账号必须去关联：邮箱、手机、IP、支付方式任一关联 = 假冗余。
- 获客渠道不得超过 50% 集中在单一平台：这条是硬约束，不是建议。
- 支付通道必须至少两条独立路径：资金断流是清零级事件。
这五条红线，是「即便你觉得风险很小也必须遵守」的战略纪律。把它们让出去，等于把生意的存亡权交给了你不可控的第三方。这与第 05 章 5.7 节的「认知红线」一脉相承——认知红线守住判断权，依赖红线守住存续权。
16.8 小结 / 核心心法
你的生意是建在别人地基上的楼。地基的每一块砖都不归你管，但你必须知道哪块砖松了会塌哪一层——以及它塌了之后，你还能不能站着。
- AI 依赖是结构性风险，不是「要不要用」的问题——不用 AI 你连杠杆都没有，用了就必须正面应对依赖。
- 依赖分三层：模型层 / 平台层 / 账号层——每层都有典型失败场景，影响半径不同。
- 每个超级个体必须有一张自己的依赖地图——没画过依赖地图的人，是在蒙眼开车。
- 单点不一定要消除，但必须显式标注 + 备降级路径——集中可以，没降级的集中是赌博。
- 战略层风险不靠工程层规范解决——密钥管理解决不了供应商断供，分层要清楚（呼应 WLM：依赖风险可同时击穿 W/L/M 三环）。
本章锚定了 WLM 的守势视角：W（窗口）会被平台政策变化击穿、L（杠杆）会被模型涨价/断供击穿、M（护城河）会被账号封禁/客户清零击穿。识别依赖结构，是所有对冲动作的前提。下一章给出具体的脆弱性测试方法与对冲组合——怎么从「知道有单点」走到「单点失效也能活下来」。
执行清单（依赖风险季度自检）：
- [ ] 我画出了自己生意的依赖地图（模型/平台/账号三层全列）。
- [ ] 我标注了所有 ★ 单点节点，并估算了每个的击穿半径。
- [ ] 我能为每个高击穿半径节点脱口说出降级路径。
- [ ] 我的关键账号（API Key / 支付 / 域名 / 平台账号）已经去关联。
- [ ] 我没有任何单一获客渠道占比超过 50%。
- [ ] 我至少有两条独立的支付通道。
- [ ] 我每季度演练过一次降级（哪怕只是 dry run）。
- [ ] 我没把战略层依赖风险与工程层安全红线混淆（参见 solo 第 28 章）。
上一章：第15章 第一个 30 天：从合上书到收到第一个信号
下一章：第17章 脆弱性测试与对冲