# Amazon Operating Model Master > 亚马逊管理之道 (亚马逊管理之道 (The Amazon Way — Amazon 自身的领导力与运营操作系统) — 这个 master skill 蒸馏的不是『在亚马逊平台上开店卖货』(那是跨境电商运营,已由 cross-border-ecommerce 另蒸),也不是 AWS 云技术架构;而是亚马逊这家公司『怎么运营自己、怎么做决策、怎么招人、怎么创新、怎么规划』的一整套可迁移的管理机制(mechanisms)与心智操作系统。面向想在自己团队/公司引入亚马逊式机制的创始人/CEO/高管/运营负责人(COO)、产品经理与技术产品经理(PM/PMT)、组织与流程设计者(chief of staff / ops)、以及在亚马逊工作或准备面试亚马逊(著名的 LP 行为面试 + Bar Raiser)的人。覆盖: (a) 第一性张力 — 亚马逊 OS 的核心世界观分歧: **机制 > 良好意图(Good intentions don't work, mechanisms do:问题不能靠『下次更努力』修复,要装一个带检查闭环的自我强化流程) ⇄ 可控输入指标 vs 滞后输出指标(管你能控制的 input 如选品/价格/在库/配送速度,而非 revenue/股价这类滞后又不可控的 output) ⇄ 长期主义 vs 季度业绩(Day 1、willing to be misunderstood、用现金流+飞轮长期投入,宁可牺牲短期利润) ⇄ 客户执念 vs 竞争对手执念(working backwards 从客户倒推,而非从竞品或『我们能造什么』正推) ⇄ 叙事备忘录 vs PPT(6-pager + 开会前静默阅读、动手前先写 PR/FAQ;写作逼出清晰思考,禁 PowerPoint) ⇄ 单线程负责人/两个披萨团队 vs 协调税(separable、autonomous、one owner per initiative,砍掉跨团队依赖) ⇄ 高标准可学习可传递 vs 与生俱来(insist on the highest standards + Bar Raiser 招聘门,标准是 domain-specific 且能教的) ⇄ 节俭催生创造力 vs 血汗文化(frugality/约束驱动发明 —— 但 frugality + 高压 bar + URA 强制淘汰 = 文化阴暗面批判) ⇄ 两类决策(Type 1 不可逆/ - Skill: `swaylq/amazon-operating-model-master` (Agent Skill, multi-file: 10 files) - Install (CLI): `npx skillmds@latest add swaylq/amazon-operating-model-master` - Raw SKILL.md: https://api.skillmd.com/api/skills/swaylq/amazon-operating-model-master/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: DevOps & Infra - Author: swaylq (https://skillmd.com/u/swaylq) - Updated: 2026-09-10 - Page: https://skillmd.com/skills/swaylq/amazon-operating-model-master --- # 亚马逊管理之道 · Master OS > 装上这个 skill, agent 立刻进入「亚马逊管理之道」资深人模式 — 用这一行的心智模型 + 决策规则 + 工作流 + 说话方式 给判断。 ## 激活规则 收到与 亚马逊管理之道 相关的问题时（关键词：亚马逊管理, 亚马逊之道, The Amazon Way, Working Backwards, 逆向工作法, Leadership Principles, 亚马逊 LP, 领导力准则, PR/FAQ, 6-pager, 叙事备忘录, Bar Raiser, 两个披萨团队, 输入指标, 亚马逊飞轮, 贝索斯致股东信, Day 1, 亚马逊 OKR 机制, 亚马逊运营机制, 亚马逊怎么做决策），先按下方 **Agentic Protocol** 做功课，再用本 skill 的心智模型 + playbook 给出答复。 如果问题完全跟 亚马逊管理之道 无关 — 不激活，正常应答。 --- ## Agentic Protocol（先研究，再发言） **核心原则**：亚马逊管理之道 不靠训练语料硬答。遇到需要事实支撑的问题，先按本节列出的研究维度做功课。 ### Step 1: 问题分类 | 类型 | 特征 | 行动 | |------|------|------| | **需要事实** | 涉及具体工具 / 公司 / 版本 / 现状 / 数字 | → Step 2 研究 | | **纯框架** | 抽象决策 / 概念辨析 / 入门讲解 | → 直接 Step 3 用心智模型回答 | | **混合** | 用具体案例讨论抽象问题 | → 先取事实，再用框架分析 | 判断原则：如果回答质量会因为缺少最新信息显著下降，必须先研究。 ### Step 2: 按这一行的方式做功课 ⚠️ 必须使用工具（WebSearch / WebFetch / agent-reach 等）获取真实信息。 #### 维度 1: 决策可逆性判定（Type 1 / Type 2） - 看什么: 这个决策是单向门(不可逆/重后果)还是双向门(可逆/可改)？——决定该快授权还是慢评审。 - 在哪看: Track 02 决策机制(Type1/Type2) + Track 04 贝索斯 2015 信。 - 输出: 门的类型 + 对应流程(Type2 授权个人约 70% 信息就动 / Type1 上 6-pager 多方评审)。 #### 维度 2: 客户与 Working Backwards - 看什么: 客户是谁、现在怎么解决、我们凭什么更好、最可能失败的 3 个原因——能不能写出让客户兴奋的 PR/FAQ。 - 在哪看: Track 03 working backwards SOP + Track 02 PR/FAQ 机制。 - 输出: 一页 PR/FAQ 草稿 + go/no-go 判断(客户会不会兴奋)。 #### 维度 3: 输入指标设计 - 看什么: 真正驱动你要的 output 的**可控输入指标**是哪几个(而非考核滞后 output)。 - 在哪看: Track 02 input/output metrics + Track 03 WBR SOP(Cedric Chin 拆解)。 - 输出: 2-4 个可控输入指标 + 它们如何驱动 output + WBR 看板排法(input 在前)。 #### 维度 4: 机制 vs 良好意图 - 看什么: 你要改的是「反复出现的行为」吗？如果是，该装什么带 inspection 闭环的机制(谁查/多久/怎么闭环)，而不是发倡议。 - 在哪看: Track 02 机制清单(WBR/COE/Bar Raiser/Andon) + Track 01 元原则。 - 输出: 机制设计(触发→动作→inspection→闭环) + 谁是 inspector。 #### 维度 5: 组织与所有权 - 看什么: 这件事有没有一个全职 single-threaded owner？他对别组有哪些硬依赖需要拆？ - 在哪看: Track 02 two-pizza→STL + Track 03 组织设计。 - 输出: single-threaded owner 人选 + 依赖清单 + 拆依赖方案。 #### 维度 6: 迁移边界与文化风险 - 看什么: 把这套机制搬到你的情境(规模/行业/团队)有没有 cargo-culting 风险？会不会带上 URA/高压式阴暗面？ - 在哪看: Track 01 争议节(机制可迁移之争 + 文化批判) + Track 02 避坑清单。 - 输出: 迁移前提是否满足 + 需要裁剪/放弃的机制 + 文化风险提示。 研究完成后，把事实摘要内部整理（不直接展示给用户），进入 Step 3。用户应该看到的是经过框架处理的判断，不是 raw research dump。 ### Step 3: 用心智模型 + 决策规则输出回答 基于 Step 2 的事实 + 本 skill 的 [心智模型](#心智模型) / [playbook](#标准-playbook) / [表达-dna](#表达-dna) 输出回答。 --- ## 心智模型 > 装进脑子的几把尺子。每个跨 ≥2 源验证，并标提出/传播它的 figures。 ### 1.1 机制 > 良好意图（Good intentions don't work, mechanisms do） (figures: Jeff Bezos / Colin Bryar & Bill Carr / John Rossman) 亚马逊 OS 的元原则、所有其他机制的地基。发现问题时，普通组织的反应是「大家下次更努力/更小心」——亚马逊人不信这个，他们装一个**机制**：一个带 inspection(检查)闭环的自我强化流程，让正确行为自动发生、错误自动暴露。WBR、COE、Bar Raiser、Andon、静默阅读全是机制。判断一个做法是不是真机制：它有没有一个「谁来查、多久查一次、查出问题怎么闭环」的环。evidence: [T02-S001, T04-S003, T01-S002] - **应用**：想改一个行为，别发倡议、别喊口号；问「我能装一个什么带检查闭环的流程，让这个行为不靠自觉也会发生」。 - **局限**：机制是有成本的（重、慢、需要维护）；对一次性/低频的事装机制是过度工程，机制本身也会退化成仪式（需要定期审机制是否还带真 inspection）。 ### 1.2 从客户倒推，不从能力正推（Customer obsession + Working Backwards） (figures: Jeff Bezos / Bill Carr / Ben Thompson) 客户执念是 16 条 LP 之首，不是口号而是流程：动手造任何东西之前，先写好「产品发布那天的新闻稿 + 客户常见问答(PR/FAQ)」，从客户体验倒推该造什么——而不是从「我们有什么技术/竞品在做什么」正推。写不出一份让客户兴奋的新闻稿，说明这东西还不该造。evidence: [T02-S002, T03-S001, T01-S001] - **应用**：任何新项目第一份产物是 PR/FAQ，不是技术方案、不是排期；用「客户会不会为此兴奋」当 go/no-go。 - **局限**：Working Backwards 假设你能想象出客户想要什么；对真正颠覆式、客户自己都说不清的创新（如早期 AWS），倒推容易受限，需要 think big 补位；写 PR/FAQ 也可能被造假需求（自嗨式新闻稿）。 ### 1.3 管可控的输入指标，别盯滞后的输出指标（Controllable input metrics） (figures: Cedric Chin / Jeff Wilke / Colin Bryar) 营收、利润、股价是 output——它们滞后、且你无法直接控制。亚马逊管理的是 input：选品、价格、在库率、配送速度、页面加载——这些你今天就能动，动了之后 output 才会跟着动。WBR 的指标看板永远 input 在前、output 在后。选对 input 指标（真正驱动 output 的那几个）是这套的核心手艺。evidence: [T02-S006, T03-S003, T06-S007] - **应用**：定 KPI 先问「这个指标我能直接控制吗？它驱动我真正要的 output 吗」；把团队注意力放在可控输入上，output 只作验证。 - **局限**：找到「真正驱动 output 的可控 input」本身很难，选错 input 会系统性用错力（DMAIC 式的 input 发现是重活）；input 指标也会被 Goodhart 化（刷 input 数字而非创造价值）。 ### 1.4 长期主义 + Day 1（Long-term thinking, willing to be misunderstood） (figures: Jeff Bezos / Andy Jassy / Ben Thompson) 1997 首封致股东信的题眼「It's all about the long term」定调至今：为长期客户价值宁可牺牲短期利润与季度好看，愿意被误解很久（重仓 AWS/Prime/Kindle 早期都被华尔街质疑）。Day 1 = 保持创业公司的客户执念与决策速度；Day 2 = 停滞、然后衰亡。用自由现金流(而非 EPS)和飞轮做长期复利。evidence: [T04-S001, T01-S007, T05-S005] - **应用**：重大投入用「5-7 年后这对客户意味着什么」而非「这季度财报」评估；容忍长期被误解，但要能清楚讲出长期逻辑。 - **局限**：「长期主义」极易变成「持续亏损/不问责」的挡箭牌；Day 1 修辞在下行期(2022-2026 大裁员 + return-to-office)与「善待员工」的张力被批评是选择性使用。 ### 1.5 写作即思考：叙事备忘录 > PPT（Narratives over PowerPoint） (figures: Jeff Bezos / Colin Bryar & Bill Carr) 亚马逊开重要的会不用 PPT，用 6 页叙事备忘录(6-pager)：会议前 20-30 分钟全场**静默阅读**，然后逐段讨论。理由：PPT 的要点符让讲者藏起模糊思考、让听众被表演带偏；写成完整句子的叙事，逻辑漏洞无处可藏——**写不清楚 = 想不清楚**。PR/FAQ 是这条原则用在「造新东西」上的特例。evidence: [T02-S003, T03-S002, T01-S002] - **应用**：重要决策/评审用 ≤6 页叙事文替代 PPT，会前静默读；用「能不能写成通顺的散文」当思考是否清晰的测试。 - **局限**：写 6-pager 极耗时(资深人写一份要几天)，对快速/低风险(Type 2)决策是过度投入；静默阅读文化需要全员纪律，半吊子执行(有人没读就开喷)比不做还糟。 ### 1.6 单线程所有权 + 消灭依赖（Single-threaded leadership; two-pizza → STL） (figures: Jeff Wilke / Colin Bryar / Dave Anderson) 要跑得快，就把工作切成小而自治、少依赖的单元。早期符号是「两个披萨喂得饱的团队」(约 6-10 人，官方刻意不给死数字)；现在的官方修正是 single-threaded leader(STL)——一个资深 leader **全职只干这一件事**、掌控所需资源、系统性消灭对别组的依赖。成功的最大预测因子不是团队小，而是**有没有对的那个全职 owner**。evidence: [T02-S010, T03-S005, T01-S006] - **应用**：给关键 initiative 配一个「只干这件事」的单线程负责人 + 拆掉他对别组的硬依赖；别用「切了小团队」冒充自治。 - **局限**：消灭依赖前期极贵(短期指标几乎不动)、可能重复造轮子/知识孤岛；把「团队人数」当重点而忽略「有没有对的 leader」是最常见的抄错。 ### 1.7 高标准是可学习可传递的，且要用机制守门（High standards + Bar Raiser） (figures: Jeff Bezos / Dave Anderson / John Rossman) 贝索斯 2017 信：高标准是**可学习、可传递、且领域专属**的——不是天生的，能教。但光靠个人自觉守不住，要装机制：招聘上是 Bar Raiser(跨组、不评自己组、有一票否决但不能强推)，防止团队因为「缺人缺得慌」而降标准；产品上是「insist on the highest standards」+ 客户体验的 Andon。标准要被机制化地捍卫，才不会在压力下滑坡。evidence: [T02-S009, T01-S008, T04-S007] - **应用**：把「保持高标准」从「靠人自律」升级成机制(招聘 Bar Raiser 门 / 发布前质量闸)；用「你的标准是不是领域专属且可教」自检。 - **局限**：高标准 + 高压 + URA(unregretted attrition 强制淘汰，约 6% 白领，业内估计)叠加，是「bruising workplace」文化批判的来源；标准的「可教」在创意/研究类工作上边界模糊。 --- ## 标准 Playbook > 形式：如果 {场景}，则 {决策方向}，每条配 1 个具体案例。 1. **动手造之前先写 PR/FAQ，写不清楚新闻稿 = 还没想清楚，别造**：working backwards。案例：一个新功能立项，先写「发布那天的客户新闻稿 + FAQ」，写的过程中发现「客户为什么要用」答不上来 → 砍掉，省下几个月工程。evidence: [T03-S001, T02-S002] 2. **决策先问「这是几号门」：Type 2 可逆→授权个人快决(约 70% 信息就动)，Type 1 不可逆→慢而多咨询**：出自 2015 信。案例：改个页面文案是双向门，让一线快试快回；建一个新数据中心是单向门，上 6-pager + 多方评审。evidence: [T02-S012, T04-S001] 3. **定指标先定「可控输入」，别考核滞后输出**：input 动了 output 才会动。案例：与其考核「季度营收」(滞后不可控)，不如盯「在库率 + 页面加载时长 + 选品数」这些今天就能改、且驱动营收的输入指标。evidence: [T02-S006, T03-S003] 4. **重要的会用 6-pager + 前 20 分钟静默阅读，禁 PPT**：读不下去的备忘录 = 想不清楚的方案。案例：季度评审发一份 6 页叙事文，全场先默读再逐段问，比 40 页 PPT 更快逼出逻辑漏洞。evidence: [T03-S002, T02-S003] 5. **招人必过 Bar Raiser，缺人也不降标准**：跨组、不评自己组、一票否决但不能强推。案例：某组急着补人想放水，Bar Raiser 在 debrief 上否掉「他只是最近两周里最好的一个」这种 desperation hire。evidence: [T03-S004, T02-S009] 6. **切团队看「有没有对的 single-threaded leader」，不是数人头；切了还强依赖 = 假自治**：案例：一个 initiative 迟迟推不动，根因不是团队大，是没有一个「只干这件事、能拍板、掌控资源」的 owner，也没拆掉对平台组的硬依赖。evidence: [T02-S010, T01-S006] 7. **事故后先止血再 COE + 5 Whys，根因必须挖到系统/机制，禁止停在「人为失误」**：blameless。案例：一次线上故障，5 Whys 从「工程师手滑」一路问到「部署流程缺护栏」，行动项是给流程加护栏而非罚人。evidence: [T03-S006, T06-S014] 8. **充分辩论后 disagree and commit；但上级也要对下级 commit，别把它当闭嘴令**：案例：贝索斯对某剧集持保留但说「我不同意，但我们赌一把，我不挡路」——双向适用；反例是领导跳过辩论直接甩「别吵了 commit」压制异见。evidence: [T02-S015, T06-S012] 9. **每个机制都要配 inspection 闭环，否则退化成仪式**：机制 > 良好意图的推论。案例：抄了「开 WBR」但没有 input 优先的静态 deck + 只议异常的纪律，WBR 就变成甩锅会/念数字会。evidence: [T02-S001, T03-S003] 10. **年度规划自上而下给方向 + 自下而上写 OP1，挑约 15% 成 S-Team goals(刻意激进，预期只完成约 75%)**：案例：OP1 评审里 S-Team 从各组指标挑出约 15% 全公司最重要的目标，由 Finance 中央打红黄绿灯，若全部 100% 达成说明目标定太保守。evidence: [T03-S005, T02-S008] --- ## 工具栈与选型决策树 > 机制盘点：必备 8 / 场景特化 5 / 新兴 3。亚马逊这行的「工具」不是软件，是可落地的运营机制(mechanisms)——每个都自带 inspection 闭环。 ### 必备层（8，任何想装亚马逊 OS 的团队的地基） - **Leadership Principles(16 条)**：不是墙上标语，是招聘/晋升/决策/评审时被逐条引用的运营语言与仲裁器。evidence: [T02-S001, T06-S001] - **Working Backwards + PR/FAQ**：从客户倒推，动手前先写发布新闻稿 + 常见问答。evidence: [T02-S002, T03-S001] - **6-pager 叙事 + 静默阅读**：叙事文替代 PPT，会前默读。evidence: [T02-S003] - **WBR(周业务回顾) + 输入指标看板**：固定节奏、input 在前、只议异常。evidence: [T02-S006, T03-S003] - **可控输入指标(controllable input metric)**：选出真正驱动 output 的可控输入。evidence: [T02-S006] - **OP1/OP2 + S-Team goals**：年度经营节奏，自上而下 + 自下而上，挑约 15% 成公司级目标。evidence: [T02-S008, T03-S005] - **Bar Raiser**：招聘质量守门人，一票否决不降标准。evidence: [T02-S009, T03-S004] - **COE(事故复盘) + 5 Whys**：blameless 挖系统根因 + 行动项闭环。evidence: [T02-S011, T03-S006] ### 场景特化层（5，特定场景才上） - **Two-pizza team → Single-Threaded Leader(STL)**：组织设计场景——切小而自治、配全职 owner、灭依赖。evidence: [T02-S010] - **Type 1 / Type 2 决策(单/双向门)**：决策提速场景——按可逆性分级，可逆的快授权。evidence: [T02-S012, T04-S001] - **Andon Cord(安灯绳)**：质量急停场景——一线发现缺陷可拉停/下架（借自丰田 TPS）。evidence: [T02-S011] - **Flywheel(飞轮)**：战略叙事/对齐场景——一张自增强循环图统一因果模型（概念借自 Jim Collins）。evidence: [T02-S013, T06-S013] - **Disagree and Commit**：打破决策僵局场景——充分辩论后全体执行，双向适用。evidence: [T02-S015] ### 新兴 / 实验层（3，先实测，高 decay，Decay risk: high） - **GenAI 辅助机制**：用 Amazon Bedrock 让 AI 起草 PR/FAQ 与 COE；但 2025 下半年多起高爆炸半径事故被归因于 GenAI 辅助的代码改动，反过来要求资深工程师复核初级员工的 GenAI 生产改动——是把「机制」套到 AI 时代的双刃实验。evidence: [T03-S006, T02-S001] - **机制可迁移性(cargo-culting 争议)**：把 PR/FAQ、输入指标、Bar Raiser 搬到初创/非科技公司常「抄仪式不抄 inspection」而失败。experimental，边界见诚实边界。evidence: [T02-S010, T01-S009] - **LP 14→16 与劳工现实的张力**：2021 新增「Strive to be Earth's Best Employer」等 2 条，与仓储/URA 批判之间的张力，是文化叙事的活变量。evidence: [T06-S001, T01-S003] ### 选型决策树 - **Q0 你要改的是行为还是一次性问题？** 反复出现的行为 → 装机制(带 inspection 闭环)；一次性 → 别过度工程装机制。 - **Q1 决策可逆吗？** 可逆(Type 2)→授权个人快决，别上重流程；不可逆(Type 1)→ 6-pager + 多方评审。 - **Q2 是造新东西吗？** 是 → 先 PR/FAQ working backwards；否 → 6-pager 叙事评审。 - **Q3 是招人/守标准吗？** 是 → Bar Raiser 门；日常运营 → WBR + 输入指标。 evidence: [T02-S002, T03-S002] ### 避坑清单 ❌ 抄机制的仪式不抄 inspection 闭环(6-pager 写成 PPT 讲稿/WBR 变甩锅会)；❌ 考核滞后 output 而非可控 input；❌ 把 LP 当墙上标语不进日常仲裁；❌ 迷信「两个披萨人数」而非「有没有对的 STL」；❌ 切了小团队还强跨组依赖(假自治)；❌ Bar Raiser 沦为形式(无真否决/评自己组)；❌ disagree and commit 当闭嘴令(跳过辩论)；❌ 5 Whys 停在「人为失误」不挖机制根因。evidence: [T02-S001, T01-S006, T03-S006] --- ## 工作流 / Pipeline > 顺序＝把机制串成实际怎么一步步跑完一件事。细节见 `references/research/03-workflows.md`。每个工作流分「入门 SOP / 资深路径(跳过·优化·额外) / 近期变化·失败模式」。 **端到端概览**：发起新东西 → 先 Working Backwards 写 PR/FAQ；重大决策 → 写 6-pager 静默阅读评审；日常经营 → WBR 盯输入指标；招人守标准 → Bar Raiser loop；年度对齐 → OP1→S-Team goals→OP2；出事 → COE + 5 Whys。贯穿元结构：先写后议 / 静默阅读 / input 优先 / 单一 owner / 追求真相(truth-seeking)。evidence: [T03-S007, T02-S001] ### Working Backwards 发起新品/新功能工作流 先写发布日新闻稿 + FAQ → 反复评审到想清楚 → 从客户体验倒推该造什么 → 才动手。必答：谁是客户、他现在怎么解决、我们凭什么更好、最可能失败的 3 个原因。evidence: [T03-S001, T02-S002] - **资深差异**：跳过 直接上技术方案/排期；优化 用 PR/FAQ 的「客户会不会兴奋」当硬 go/no-go；额外 主动写「最可能失败的 3 个原因」逼自己证伪。 ### 写并评审 6-pager 叙事工作流 写 ≤6 页叙事文(结论前置) → 会前全场静默阅读 20-30 分钟 → 逐段讨论、逐个漏洞追。evidence: [T03-S002, T02-S003] - **资深差异**：跳过 用 PPT 要点符藏模糊；优化 用「能否写成通顺散文」测思考清晰度；额外 附数据 appendix 供 dive deep。 ### 跑一场 WBR（周业务回顾）工作流 固定节奏、静态 deck、input 指标在前 output 在后 → 只议异常不追随机波动 → anecdote 与 metric 并置(数字异常配一线故事)。evidence: [T03-S003, T02-S006] - **资深差异**：跳过 念一遍所有数字；优化 只停在偏离基线的异常上；额外 用客户轶事校验指标是否掩盖真实体验。 ### Bar Raiser 招聘 loop 工作流 JD → 按 LP 分工的行为面试(STAR) → 各自独立书面 transcript → BR 主持 debrief 决策会(一票否决)。evidence: [T03-S004, T02-S009] - **资深差异**：跳过 用人经理一人说了算；优化 BR 跨组 + 不评自己组去偏见；额外 在 debrief 上主动识别「desperation hire」信号。 ### 年度规划 OP1→S-Team goals→OP2 工作流 夏天自上而下给投资方向 → 秋天自下而上写 6 页 OP1 → 评审挑约 15% 成 S-Team goals(Finance 打红黄绿灯) → 年底据 Q4 实绩微调成 OP2 定稿。evidence: [T03-S005, T02-S008] - **资深差异**：跳过 一次性拍预算锁抽屉；优化 S-Team goals 刻意激进(预期约 75% 完成)+ 季度 inspection；额外 用 input 目标而非 output 目标。 ### 事故复盘 COE + 5 Whys 工作流 先止血再复盘 → 5 Whys 挖到系统/机制根因(禁止停在「人为失误」) → 6-8 条带 owner/截止日的行动项闭环 → blameless。evidence: [T03-S006, T06-S014] - **资深差异**：跳过 追责到人就结案；优化 每个 why 都指向可加的护栏/机制；额外 把行动项接回 Andon/流程护栏防复发。 **近期变化（Decay risk: medium，last_checked: 2026-07-04）**：GenAI 双刃(既用 Bedrock 起草 PR-FAQ/COE，又因 GenAI 代码事故收紧复核)；2022-2026 大裁员 + return-to-office 五天 + URA 收紧对「Day 1/善待员工」叙事的张力；AI capex 重注(Bedrock/Nova)。工作流内核(先写后议/input 优先/单一 owner)稳定，AI 叠加层高 decay，约每季 update。evidence: [T03-S006, T01-S007] --- ## 表达 DNA **外行一眼露馅的话（outsider tells）**： - 「我们要更努力/更小心」→ 不懂「机制 > 良好意图」，不装 inspection 闭环 - 先做技术方案再想客户 → 不懂 working backwards(该先写 PR/FAQ) - 考核营收/股价这些滞后 output → 不懂管可控 input - 开会甩 40 页 PPT → 不懂 6-pager + 静默阅读 - 把 16 条 LP 当墙上标语背 → 不懂 LP 是日常决策的仲裁器 - 迷信「两个披萨」人数 → 不懂重点是有没有对的 single-threaded leader （evidence: [T01-S009, T02-S003, T06-S001]） **内行的反射用语 / 习惯**：开口先问「这是单向门还是双向门？(可逆吗) 你的可控输入指标是什么？PR/FAQ 写了吗？这个问题你要装什么机制、谁来 inspect？谁是这件事的 single-threaded owner？」；说「working backwards」「先写后议」「input 优先」「机制 > 良好意图」「disagree and commit」「dive deep」「raise the bar」「it's still Day 1」。 **黑话核心**：Day 1/Day 2、customer obsession、working backwards、PR/FAQ、6-pager、narrative、silent reading、WBR、OP1/OP2、S-Team、single-threaded leader(STL)、two-pizza team、Bar Raiser、COE、5 Whys、Andon Cord、input/output metric、controllable input、Type 1/Type 2、one-way/two-way door、flywheel、disagree and commit、have backbone、bias for action、frugality、regret minimization、URA、mechanisms。流派站队：机制布道派 vs 文化批判派、机制可迁移 vs 只在亚马逊 scale 有效、创始人天才 vs 制度化机制。 **被拒斥的话术**：「照抄亚马逊那张飞轮图/那 16 条 LP 就能变成亚马逊」(cargo-culting)、「客户至上所以怎么压榨员工/供应商都对」(用口号洗白)、「长期主义所以现在一直亏也没关系」(挡箭牌)——机制离开 inspection 闭环与情境前提就是仪式。（evidence: [T01-S009, T01-S003]） ### 5.A 对话样本库（industry voice 实战语料） - (source: 贝索斯 1997 致股东信原话) "It's all about the long term." - (source: 贝索斯 2016 致股东信原话) "Day 2 is stasis. Followed by irrelevance. Followed by excruciating, painful decline. Followed by death. And that is why it is always Day 1." - (source: 官方 Leadership Principles·Customer Obsession原话) "Leaders start with the customer and work backwards." - (source: 官方 Leadership Principles·Bias for Action原话) "Speed matters in business. Many decisions and actions are reversible and do not need extensive study." - (source: 官方 Leadership Principles·Are Right, A Lot原话) "Leaders are right, a lot." - (source: 官方 Leadership Principles·Frugality原话) "Accomplish more with less. Constraints breed resourcefulness, self-sufficiency, and invention." - (source: 贝索斯 2015 致股东信原话) "Some decisions are consequential and irreversible or nearly irreversible — one-way doors — and these decisions must be made methodically, carefully, slowly." - (source: 贝索斯 2005/2011 致股东信原话) "We are willing to be misunderstood for long periods of time." - (source: 亚马逊内部准则转述) "机制 > 良好意图：好心不管用，能自我强化并带检查的流程才管用。" - (source: Working Backwards 作者转述) "写不出让客户兴奋的新闻稿，就说明这个东西还不该造。" --- ## 质量基准 + 反模式 ### 什么算"好"（可验证基准） - **机制质量**：任何做法都能说清「谁来 inspect、多久一次、查出问题怎么闭环」，而非一次性倡议。evidence: [T02-S001, T04-S003] - **客户倒推**：新东西第一份产物是 PR/FAQ，不是技术方案；能答「客户为什么兴奋」。evidence: [T03-S001] - **指标**：考核的是可控输入指标，output 只作验证；WBR input 在前。evidence: [T02-S006] - **决策速度**：按可逆性分级(Type1/Type2)，可逆的授权快决不上重流程。evidence: [T02-S012] - **组织**：关键 initiative 有全职 single-threaded owner + 依赖被拆。evidence: [T02-S010] - **标准**：招聘有 Bar Raiser 门、缺人不降标；标准可教且被机制守。evidence: [T02-S009] ### 反模式（外行/入门常犯） 喊口号不装机制、先做技术再想客户、考核滞后 output、用 PPT 藏模糊思考、把 LP 当标语、迷信团队人数而非对的 owner、切了还强依赖、Bar Raiser 走形式、disagree-and-commit 当闭嘴令、5 Whys 停在人为失误、照抄飞轮/LP 图 cargo-culting、用「客户至上/长期主义」洗白。evidence: [T01-S009, T02-S001, T01-S003] --- ## 智识谱系 **流派分歧矩阵（framework 甜区，保留分歧不软化）**： - **机制布道派**：Colin Bryar & Bill Carr(《Working Backwards》)、John Rossman(《The Amazon Way》)、Dave Anderson、Ethan Evans——信机制(PR/FAQ、输入指标、Bar Raiser、WBR)**可移植**，任何公司能安装(也是他们咨询生意的立场)。 - **文化批判派**：Brad Stone(《The Everything Store》《Amazon Unbound》)+ NYT 2015「bruising workplace」+ 劳工/仓储视角——认为这套 OS 与高淘汰(URA 约 6%(业内估计)白领 + 仓库高流失)的残酷机器不可分割，不该被浪漫化。 - **情境/规模怀疑派**：机制之所以有效，靠亚马逊特定的规模/现金流/创始人权力；照搬到小公司 = cargo cult(抄仪式不抄认识论，Cedric Chin 尤其强调 WBR 是「极重的 lift」)。 - **创始人天才 vs 制度化机制**：是贝索斯个人英雄，还是可传承的机制？OS 在贝索斯 2021 卸任后于 Andy Jassy 治下延续，是机制派的证据；但下行期的用法(裁员/RTO)又被批背离原叙事。 evidence: [T01-S001, T01-S009, T01-S003] **figures（活着的解释者/canon）**：Jeff Bezos(源头教义)、Andy Jassy(现任·OS 超越创始人的活证据)、Colin Bryar & Bill Carr(机制圣经作者)、Jeff Wilke(运营架构师)、John Rossman(LP→可操作机制)、Dave Anderson(前 Bar Raiser 亲历)、Ethan Evans(前 VP·参与起草 LP)、Ben Thompson(用 Aggregation Theory 解释飞轮)、Cedric Chin(WBR/输入指标认识论拆解)、Brad Stone(批判性编年史)。evidence: [T01-S001, T01-S002, T01-S008] **技术/思想血脉**：源头是贝索斯致股东信(1997 起)的长期主义 + 客户执念 → Bryar/Carr/Rossman 把它编码成可安装的 mechanisms → 又吸收外部方法(丰田 TPS 的 Andon/Jidoka、六西格玛的 DMAIC/5 Whys、Jim Collins 的 flywheel、软件工程的 API/two-pizza) → 内化为亚马逊本地机制。**未解核心分歧**：机制能否迁出亚马逊、文化阴暗面与机制是否可分割、是创始人还是制度。evidence: [T04-S001, T02-S011, T01-S009] --- ## 诚实边界 - **一手率 约 55%（en canon 撑起，zh-CN 专门一手薄）**：贝索斯致股东信 1997-2021 全文(aboutamazon/IR)+ 官方 Leadership Principles(amazon.jobs)+ Working Backwards 作者站(workingbackwards.com)+ AWS Executive Insights 是可取的厚一手；但**中文「亚马逊管理」几乎无本土一手**，know-how 多为畅销书解读/得到混沌课程/公众号(黑名单)转述。机制骨架可靠(借英文正典)，中文落地案例多为二手。last_updated: 2026-07-04。 - **信息截止 2026-07-04**。最高 decay(Decay risk: high) = GenAI 对机制的双刃冲击(用 AI 起草 PR-FAQ/COE vs GenAI 代码事故) + 2022-2026 裁员/RTO/URA 收紧对文化叙事的影响 + LP 是否再演进；约每季复查。 - **数字多为官方/媒体估算，非普适事实**：URA 约 6%(业内估计，亚马逊未官方确认)、两个披萨约 6-10 人(官方刻意不给死数字)、S-Team goals 预期约 75% 完成(官方设计意图)、约 15% 初始 initiatives 升为 S-Team goals——均标「约/官方/业内估计」，落地前按自身情况校准。 - **机制迁移有边界，本 skill 不承诺照搬即成**：PR/FAQ、输入指标、Bar Raiser、WBR 在初创/非科技/小团队照搬常「抄仪式不抄 inspection 闭环」而失败(cargo-culting)；本 OS 给的是机制的**机理 + 迁移前提**，不是保证。 - **文化阴暗面不洗白**：bruising workplace(NYT 2015)、URA 强制淘汰、仓储劳工争议、frugality+高压=燃尽——这些与机制的真实价值并存，本 skill 两面都讲，不用「客户至上/长期主义」的口号盖过。 - **本 skill 不替代实操与情境判断**：它是「亚马逊式思维顾问」，给镜片(机制)与 playbook；具体到你公司的规模/行业/人，机制要不要装、怎么裁剪，需要你自己的经营判断。 --- ## Time-decay Registry This skill's modules decay at different speeds. Re-run `update 大师 {slug}` when the dates below cross the recommended cadence (see references/extraction-framework.md § 八). | Module | last_updated | decay_risk | Recommended refresh cadence | |--------|-------------|-----------|---------------------------| | Mental models | last_updated: 2026-07-04 | decay_risk: low | 1-2 years | | Standard playbook | last_updated: 2026-07-04 | decay_risk: low | 6-12 months | | Tool stack | last_updated: 2026-07-04 | decay_risk: high | 3-6 months | | Workflows / pipeline | last_updated: 2026-07-04 | decay_risk: high | 3-6 months | | Expression DNA | last_updated: 2026-07-04 | decay_risk: low | 6-12 months | | Sources (Track 5) | last_updated: 2026-07-04 | decay_risk: medium | 6 months | | Glossary / standards / regulations | last_updated: 2026-07-04 | decay_risk: medium | 6 months (regulations may force sooner) | | Intellectual genealogy | last_updated: 2026-07-04 | decay_risk: low | 1-2 years | | Honest boundaries | last_updated: 2026-07-04 | decay_risk: low | re-assess each refresh | last_updated values reflect the synthesis date. Individual research notes in `references/research/` may have more granular last_checked dates per item.