框架思维模型库 · 实操指南

> 版本：v1.0 > 创建日期：2026-04-10 > 维护者：龙龟神将

---

一，实操总览

1.1 场景分类

| 场景类型 | 推荐框架 | 关键思维 | 页内位置 | |----------|----------|----------|----------| | 横向展开 | 逻辑树、金字塔、矩阵 | 系统+结构化+逻辑 | §2.1 | | 纵向深挖 | 五Why、因果链、四层次 | 结构化+逻辑+系统 | §2.2 | | 全面分析 | 十大步骤 | 五大思维全调用 | §2.3 | | 创新突破 | 反事实思维 | 创造性+批判性 | §2.4 | | 中层管理 | 三层能力模型 | 框架思维+结构化 | §2.5 |

---

二，分场景实操

2.1 横向展开实操

#### 场景：分析「客户满意度下降」

``` □ 划定系统边界 - 问题处于哪个系统？（客户价值流） - 系统边界在哪里？（市场→销售→产品→售后→复购） □ 识别要素关联 - 市场获客（流量、转化） - 销售转化（需求匹配、价格谈判） - 产品体验（功能、质量、易用性） - 售后服务（响应速度、解决方案） - 复购推荐（NPS、口碑传播） □ 标注关系 - 促进关系：售后好 → 复购高 - 抑制关系：价格高 → 转化低 ```

``` □ 选择分类维度 - 推荐：按用户旅程（时间轴） - 备选：按要素（人机料法环） □ 绘制逻辑树 客户满意度下降 ┌────┬────┬────┬────┐ ▼ ▼ ▼ ▼ ▼ 市场 销售 产品 售后 复购 ```

``` □ 检查MECE - 五个环节相互独立？✓ - 五个环节完全穷尽？✓ □ 保持同一层次 - 同用「用户旅程」维度 ✓ - 不混入「部门职能」维度 ✓ ```

``` □ 数据分析 - 市场获客：正常 - 销售转化：略低 - 产品体验：下降30% ← 关键节点 - 售后服务：下降50% ← 关键节点 - 复购推荐：下降20% □ 决定：重点深挖「产品体验」和「售后服务」 ```

---

2.2 纵向深挖实操

#### 场景：深挖「产品体验下降」

``` □ 判断原因类型 - 现象：产品体验下降 - 可能类型：技术原因？人为原因？流程原因？ □ 选择框架 - 首选：四层次原因分析法 - 备选：根据原因类型切换框架 ```

``` □ 第一层：问题拆解 「产品体验下降」的具体表现： - App崩溃率上升 - 加载时间延长 - 界面卡顿 □ 第二层：直接原因 「App崩溃率上升」的直接原因： - 某次版本更新后崩溃率从0.1%上升到2.5% □ 第三层：流程/系统原因 「为什么那次更新后崩溃率上升？」 - 测试流程：灰度发布3天，未覆盖所有机型 - 审核流程：紧急版本跳过部分检测 - 监控流程：新崩溃未及时发现 □ 第四层：人的原因 「为什么测试不充分？」 - 知识：测试人员不熟悉新架构 - 习惯：紧急版本走简化流程已成惯例 - 环境：上周五发布，周五下午大家想早下班 ```

``` □ 验证因果 - 时间顺序：版本更新（先）→ 崩溃率上升（后）✓ - 共变关系：版本回滚后崩溃率下降 ✓ - 排除混淆：非系统维护、非竞品攻击 ✓ □ 防止跳跃 - 错误：「因为测试不充分」→ 停止 - 正确：「因为测试不充分」→ 追问「为什么不充分？」 ```

``` □ 识别反馈回路 版本发布 → 崩溃率上升 ↑ │ │ ▼ 回滚 ← 用户流失 → 口碑下降 □ 识别延迟效应 - 三天前发布的版本，今天才发现崩溃？ - 为什么延迟三天？ □ 检查心智层 - 「紧急版本走简化流程」的信念是什么？ - 「周五下午可以早点下班」的潜规则是什么？ ```

``` □ 判断是否可行动 - 是：修改测试流程、增加监控告警 - 否：追究历史责任 □ 判断是否超出范围 - 否：测试流程属于本部门管理范围 □ 判断成本收益 - 成本：增加测试人员和时间 - 收益：避免用户流失和口碑损失 - 结论：收益远大于成本 → 继续行动 ```

---

2.3 问题解决十大步骤实操

#### 场景：解决「团队执行力差」

``` ┌─────────────────────────────────────────────────────────────────┐ │ 十大步骤实操手册 │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ 第一步：定义问题 │ │ ───────────────── │ │ □ 现状（事实）： │ │ - 项目延期率从10%上升到35% │ │ - 任务完成率从85%下降到52% │ │ - 团队成员满意度从4.2下降到3.1 │ │ │ │ □ 期望（应该）： │ │ - 项目延期率控制在15%以内 │ │ - 任务完成率维持在80%以上 │ │ - 团队成员满意度维持在4.0以上 │ │ │ │ □ 差距： │ │ - 延期率差距25% │ │ - 完成率差距28% │ │ - 满意度差距0.9 │ │ │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ 第二步：界定范围 │ │ ───────────────── │ │ □ 是个人问题还是系统问题？ │ │ - 判断：系统问题（多个成员、多个项目同时出现） │ │ │ │ □ 是今天必须解决还是可以缓缓？ │ │ - 判断：影响业务连续性，需要本周内解决 │ │ │ │ □ 影响边界： │ │ - 涉及团队：产品团队（12人）、研发团队（25人） │ │ - 涉及项目：5个重点产品项目 │ │ - 涉及客户：3个战略客户 │ │ │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ 第三步：收集信息 │ │ ───────────────── │ │ □ 发生了什么？（客观事实） │ │ - 访谈记录：沟通不清、优先级不明、反馈慢 │ │ - 数据分析：会议时间增加40%、需求变更频繁 │ │ - 观察记录：团队成员经常加班到晚上10点 │ │ │ │ □ 什么时候开始的？（时间线） │ │ - 8周前：新总监上任 │ │ - 6周前：战略调整，目标变更 │ │ - 4周前：团队扩招30%，新成员占比高 │ │ │ │ □ 涉及谁、影响什么？（相关方和影响面） │ │ - 相关方：总监、产品负责人、研发负责人、HR │ │ - 影响面：交付延期、客户投诉、团队士气 │ │ │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ 第四步：分析根因 │ │ ───────────────── │ │ □ 五Why追问： │ │ Q1：为什么项目延期率高？ │ │ A1：因为任务完成率低 │ │ │ │ Q2：为什么任务完成率低？ │ │ A2：因为经常返工和重新确认 │ │ │ │ Q3：为什么经常返工和重新确认？ │ │ A3：因为需求变更频繁且沟通不清晰 │ │ │ │ Q4：为什么需求变更频繁且沟通不清晰？ │ │ A4：因为新总监上任后战略调整快，产品团队疲于应对 │ │ │ │ Q5：为什么战略调整快，产品团队疲于应对？ │ │ A5：因为缺少信息同步机制和决策评审流程 │ │ │ │ □ 根因定位： │ │ - 直接原因：沟通不清晰、返工多 │ │ - 系统原因：需求变更流程缺失、信息同步机制不健全 │ │ - 人的原因：缺乏决策评审流程的意识和习惯 │ │ │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ 第五步：设定目标 │ │ ───────────────── │ │ □ 解决到什么状态？ │ │ - 8周内：项目延期率从35%降至15% │ │ - 4周内：任务完成率从52%提升至70% │ │ - 2周内：团队成员满意度从3.1提升至3.8 │ │ │ │ □ 什么时候解决？ │ │ - 8周内达成全部目标 │ │ │ │ □ 用什么标准衡量？ │ │ - 项目延期率：项目管理系统的延期统计 │ │ - 任务完成率：JIRA的任务完成统计 │ │ - 满意度：每周匿名问卷调查 │ │ │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ 第六步：生成方案 │ │ ───────────────── │ │ □ 方案A：最优解（理想情况） │ │ - 建立战略评审委员会，所有重大变更需评审 │ │ - 每周一上午召开同步会，所有相关方参加 │ │ - 建立需求变更 SOP，变更超过3次需重新评审 │ │ - 投入：增加2名项目经理、购买协作工具 │ │ │ │ □ 方案B：次优解（资源受限时） │ │ - 简化战略同步会，缩短至30分钟，每周一次 │ │ - 建立需求变更申请表单，变更需填写原因 │ │ - 投入：增加1名项目经理助理 │ │ │ │ □ 方案C：保底解（资源严重受限） │ │ - 每周五下午15分钟快速站会，同步下周重点 │ │ - 建立变更记录表，变更需PMO审批 │ │ - 投入：无额外投入，利用现有资源 │ │ │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ 第七步：评估方案 │ │ ───────────────── │ │ □ 评估维度：效果、成本、风险、可持续性 │ │ │ │ │ 维度 │ 方案A │ 方案B │ 方案C │ │ │ ├────────┼────────────┼────────────┼────────────┤ │ │ │ 效果 │ 高 ★★★★★ │ 中 ★★★☆☆ │ 低 ★★☆☆☆ │ │ │ │ 成本 │ 高(成本大) │ 中(成本中) │ 低(无成本) │ │ │ │ 风险 │ 低(系统解决)│ 中(部分解决)│ 高(临时方案)│ │ │ │ 可持续 │ 高 ★★★★★ │ 中 ★★★☆☆ │ 低 ★★☆☆☆ │ │ │ │ │ □ 推荐：方案A为基础 + 方案B的灵活性 │ │ │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ 第八步：决策拍板 │ │ ───────────────── │ │ □ 决策：采用「改进版方案A」 │ │ □ 理由： │ │ - 效果最好，能从根本上解决问题 │ │ - 成本可接受，回报率明显 │ │ - 风险可控，有逐步推进的过渡方案 │ │ □ 团队分工： │ │ - 项目经理A：负责会议机制建立 │ │ - 产品负责人B：负责需求变更SOP制定 │ │ - HR负责人C：负责团队满意度调查 │ │ │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ 第九步：执行落地 │ │ ───────────────── │ │ □ 责任人清单： │ │ ┌────────────────┬────────────┬──────────────┐ │ │ │ 任务 │ 责任人 │ 截止时间 │ │ │ ├────────────────┼────────────┼──────────────┤ │ │ │ 建立评审机制 │ 项目经理A │ 第1周 │ │ │ │ 制定变更SOP │ 产品负责人B │ 第2周 │ │ │ │ 启动同步会 │ 项目经理A │ 第1周周一 │ │ │ │ 开展满意度调查 │ HR负责人C │ 第2周周五 │ │ │ └────────────────┴────────────┴──────────────┘ │ │ │ │ □ 检查节点： │ │ - 第1周周五：检查同步会执行情况 │ │ - 第2周周五：检查SOP初稿 │ │ - 第4周周五：检查效果数据 │ │ - 第8周周五：检查目标达成情况 │ │ │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ 第十步：复盘沉淀 │ │ ───────────────── │ │ □ 问题是怎么发生的？能否从源头避免？ │ │ - 根因：缺少决策评审流程 │ │ - 源头：战略调整过快时未建立配套机制 │ │ - 改进：重大战略调整时必须同步评估执行能力 │ │ │ │ □ 解决过程中做对了什么？能否固化？ │ │ - 做对：系统性分析而非头痛医头 │ │ - 固化：形成《战略调整执行评估清单》 │ │ │ │ □ 哪里可以更好？下次怎么优化？ │ │ - 不足：初期对团队扩招的消化期预估不足 │ │ - 改进：新成员30%时，预留4周磨合期 │ │ │ └─────────────────────────────────────────────────────────────────┘ ```

---

2.4 创新突破实操

#### 场景：突破「传统电商增长瓶颈」

``` □ 资源不受限假设 - 如果资金不受限？→ 大量补贴获客、全渠道铺开 - 如果团队不受限？→ 平行试错多个方向 - 如果时间不受限？→ 慢慢打磨产品

□ 限制消失假设 - 如果平台流量红利消失？→ 私域运营、用户终身价值 - 如果人口红利消失？→ 东南亚市场、出海

□ 完全相反方法假设 - 如果不是「卖更多」而是「卖更贵」？ - 如果不是「获取新客」而是「激活老客」？ - 如果不是「平台电商」而是「社区电商」？ ```

``` □ 框架组合 - 「用户生命周期」×「价值分层」×「社区运营」 - 新框架：「社区会员制电商」 □ 创新模式 ┌─────────────────────────────────────────┐ │ 社区会员制电商模式 │ │ │ │ 核心：不是流量思维，是社区思维 │ │ 产品：不是标准化商品，是精选定制 │ │ 关系：不是一次性交易，是长期会员 │ │ 增长：不是获新客，是激活老客带新客 │ └─────────────────────────────────────────┘ ```

---

2.5 中层管理三层能力实操

#### 场景：新项目启动会议

``` □ 背景与价值 「为什么做这个项目？」 「解决了什么问题？创造了什么价值？」 □ 目标与边界 「我们最终要达成什么效果？」 「有哪些资源限制或不可妥协的原则？」 □ 关联与影响 「这件事对内对外如何协作与衔接？」 「会有怎样的影响？」 □ 不确定性 「目前哪些是明确的，哪些还在变化中？」 「需要参与者共同探索什么？」 ```

``` □ 启动前：找共同利益 - 不要只说「我需要你帮我」 - 要强调「我们一起为了XX（公司级目标）」 □ 开始时：签订协作契约 - 谁负责拍板（承担后果的人） - 谁负责执行（干活的人） - 谁需要知情（同步进度即可） □ 执行中：降低配合成本 - 替对方清除障碍 - 透明化进度（建立专项群） □ 分歧时：向上借力 - 带着方案升级 - 用公司目标代替部门利益 ```

``` □ 第一句：开门见山 「张总，我需要您30分钟的决策支持。」 □ 第二句：核心诉求 「关于新项目启动，目前有两个方案，需要您拍板。」 □ 第三句：条理阐述 ┌─────────────────────────────────────────┐ │ 方案A：自主研发 │ │ • 优势：技术可控、数据安全 │ │ • 劣势：周期长(6个月)、投入大(500万) │ │ │ │ 方案B：外包合作 │ │ • 优势：周期短(3个月)、投入小(200万) │ │ • 劣势：依赖第三方、数据需脱敏 │ └─────────────────────────────────────────┘ □ 结尾：明确请求 「我的建议是方案B，因为XX，请您决定。」 ```

---

三，工具模板

3.1 框架选择决策表

| 问题类型 | 首选框架 | 备选框架 | 关键检查点 | |----------|----------|----------|------------| | 流程问题 | 流程拆解 | 逻辑树 | 每个节点是否有责任人 | | 系统问题 | 系统循环图 | 因果回路图 | 是否识别反馈回路 | | 战略问题 | SWOT | 波士顿矩阵 | 是否考虑时间维度 | | 原因分析 | 四层次分析法 | 五Why法 | 是否触及心智层 | | 用户行为 | 用户旅程框架 | AARRR模型 | 是否覆盖全生命周期 | | 资源配置 | 矩阵分析 | 优先矩阵 | 是否量化收益/成本 | | 决策评估 | 决策树 | 利弊分析 | 是否考虑概率 |

3.2 框架使用检查清单

``` □ 开始分析前 □ 问题类型判断清楚了吗？ □ 选择框架的依据明确了吗？ □ 是否需要组合多个框架？ □ 分析过程中 □ 维度选择一致了吗？（MECE检查） □ 因果关系验证了吗？ □ 是否有反馈回路被忽略？ □ 延迟效应考虑了吗？ □ 分析完成后 □ 根因是否可行动？ □ 根因是否在影响范围内？ □ 成本收益比可接受吗？ ```

---

四，常见错误与规避

4.1 框架使用错误

| 错误类型 | 表现 | 规避方法 | |----------|------|----------| | 框架滥用 | 什么问题都用同一框架 | 先判断问题类型，再选框架 | | 框架死套 | 不顾情境照搬框架 | 根据情境裁剪框架 | | 框架混用 | 同一层次混入不同维度 | 同一层次用同一维度 | | 框架跳步 | 跳过必要的分析步骤 | 严格执行框架步骤 |

4.2 思维模式错误

| 错误类型 | 表现 | 规避方法 | |----------|------|----------| | 系统盲视 | 只看要素不看关联 | 画系统循环图 | | 逻辑跳跃 | 因果关系未经验证 | 三问验证法 | | 结构混乱 | 分类重叠或遗漏 | MECE检查 | | 批判缺失 | 不质疑假设 | 刻意寻找反例 |

---

五，版本信息

v1.0（2026-04-10）

---