亚马逊案例分析多元化的业务模式

写亚马逊案例分析时，很多人只把零售、云、广告几条线并列罗列，写完发现没有「协同」两个字，分数上不去。这篇按商科作业的评分习惯，先给一条能套用的拆解顺序：从业务线清单到彼此输送什么资源，再到哪条线在补贴哪条线，最后落到案例正文该怎么组织。也说明什么情况下「协同」这个视角不成立，避免硬凑。

写亚马逊案例分析时，很多人第一反应是把零售、云、广告几条线并列罗列一遍，每条线配上几句介绍，交上去自己都觉得像公司简介。问题出在题目里那个词：多元化。多元化不是「有很多条业务」，而是这些业务之间有没有真实的资源流动。商科作业的评分点通常落在协同机制上，你只要把「谁给谁输送了什么」讲清楚，分数就不会低。

这篇按商科作业的写作习惯给一条能直接套用的拆解顺序：先把业务线清单画明白，再找协同的具体接口，然后判断谁在补贴谁，最后落到正文结构。每一节都附上「什么情况下这套讲法不成立」，避免你为了凑协同而硬写，反而被扣分。

先画清单：亚马逊到底有几条被算进来的业务线

动手写之前先定口径。不同材料对业务线的切法不一样，有的按部门、有的按收入类型，你混着用就会出现同一块业务算两遍的情况。更省事的切法是按「面向谁收费」来分：面向消费者收费、面向商家收费、面向开发者与企业收费。这样切出来的每条线，收入来源一眼就能看清。

• 每条线只记三件事：收入从哪来、成本压在哪、需要什么前置资源，其他细节先放一边；
• 业务线划分口径要在正文里明说，比如「本文按收费对象划分」，别让读者猜；
• 如果作业只要求分析零售板块，就别硬把云和广告塞进来，那是跑题不是加分；
• 清单画完先自查一遍：有没有哪条线的收入来源你其实说不清楚，说不清的那条先别写。

协同怎么讲才不空：找资源输送的具体接口

「几条业务互相促进」这句话本身是零信息。要让它变成分析，必须落到具体接口上，也就是哪一块资源被两条以上的业务线同时用了。可用的接口通常有三类：用户账号与流量入口、履约与物流网络、数据与算力基础设施。找接口的办法是拿清单里的每条线去对照这三类资源，看它用不用、跟谁共用。

流量接口

同一个账号体系下，一条线积累的用户可以被另一条线用来降低获客成本

履约接口

仓储与配送网络同时服务自营和第三方，摊薄单位固定成本

数据与算力接口

底层基础设施先满足内部业务，再对外提供服务，规模越大单位成本越低

每个接口都要追问一句「谁给谁省了什么」：是省了获客成本、省了履约成本，还是省了基础设施的重复投入。写不出这一句，说明这个接口还没分析到位。另外要提醒一句，如果案例限定在某个地区或某个阶段，有些业务线之间可能根本还没打通，这时候硬写协同就是不成立的，老老实实写「该阶段以独立运营为主」反而更稳。

再补一层：协同的边界条件

协同不是越大越好。接口越多，内部协调成本越高，遇到监管或竞争压力时，一条线的问题可能顺着接口传导到其他线。写案例时可以补一句风险：共用资源在带来效率的同时，也把几条线的命运绑在了一起，这一点在讨论业务组合稳定性时很有用。具体规模数字和监管口径，到 /official-api 和 /models 一类资料库核对当时的记录，别凭印象写。

谁在养谁：看补贴方向和现金流结构

判断交叉补贴，不用去猜内部账，看两个东西就够了：各条线的毛利水平和投入节奏。毛利高、投入节奏稳的线，通常在给高投入、抢份额的线输血。这里要区分两种情况——短期补贴是为了抢市场份额，长期结构性交叉补贴则是业务模式本身的特征，两者的案例结论完全不一样，写的时候要点明你判断的是哪一种。

• 比对各条线的毛利水平，找出明显偏高和明显偏低的两端；
• 看投入节奏：哪条线在持续加大基础设施或市场投入；
• 把观察拉到两到三年的方向上看，单一年份容易误判；
• 结论里写清这是阶段性补贴还是结构性安排，并给出你的判断依据。

数据方面，作业要求用哪个来源就用哪个来源，需要横向对照时到 /price-watch 看当时的记录，不要自己编数字。只看一年就下结论是常见失误，因为投入节奏的转向往往要隔一两年才看得出来。

案例正文怎么排：一套能直接落笔的结构

1. 业务线现状用一页以内的篇幅交代清单和划分口径，只写收入和成本结构，不写公司历史
2. 协同接口挑两到三个最有把握的接口展开，每个接口写清谁给谁省了什么
3. 交叉补贴与风险说明补贴方向、判断依据，以及共用资源带来的传导风险
4. 结论与边界单独一段写这个模式在什么条件下会失效，并回扣你的划分口径

写的时候每个论点后面挂一个可验证的事实点，不要只堆形容词。术语拿不准就去 /ai-dict 查，行业应用类的概念可以在 /ai-dict/category/application 对照，避免把「平台经济」「规模效应」这类词用串。

容易扣分的几个写法

• 把公司介绍整段搬进来，占了大半篇幅却没有分析动作；
• 只按时间线讲发展历史，不讲业务之间的结构性关系；
• 结论写绝对化判断，比如「该模式必然成功」，完全没写前提条件；
• 引用数据不标来源，或者来源和数字对不上；
• 每条业务线平均用力，协同接口只有一句话带过，重点错位。

避免这些坑的办法不是写得更长，而是写得更窄：砍掉和协同无关的介绍，把篇幅让给接口分析和边界条件。作业篇幅有限时，宁可只讲两条线之间的输送关系讲透，也不要五条线各写一段。

多元化分析的落点不是「有几条线」，而是「哪条线在用另一条线攒下的东西」。