layered-reasoning

分层推理

---

常见模式

模式 1：30K → 3K → 300 英尺分解（自上而下）

适用场景：从愿景／原则出发，推导出具体行动

结构：

• 30,000 英尺（战略层）：为什么？核心原则、不变量、约束（例如，“客户隐私不容妥协”）
• 3,000 英尺（战术层）：做什么？方法、架构、策略（例如，“零信任安全模型、端到端加密”）
• 300 英尺（执行层）：怎么做？具体行动、流程、代码（例如，“为静态数据实现 AES-256 加密”）

示例：产品战略

• 30K：“成为最值得信赖的平台”（原则）
• 3K：“实现 SOC 2 合规、发布安全报告、提供 24/7 支持”（策略）
• 300 英尺：“实施 MFA、开展季度审计、招聘 5 名支持工程师”（行动）

流程：(1) 定义战略层不变量，(2) 推导满足这些不变量的战术方案，(3) 选定策略，(4) 设计执行策略的操作流程，(5) 验证执行层不会违反战略约束

模式 2：自下而上汇总

适用场景：从观察结果／数据出发，逐步归纳出原则

结构：

• 300 英尺：具体观察、测量结果、事件（例如，“用户 A 点击了 5 次，用户 B 中途退出”）
• 3,000 英尺：模式、趋势、类别（例如，“40% 的用户在结账时退出，加载缓慢与退出相关”）
• 30,000 英尺：原则、理论、根本原因（例如，“性能会影响转化率；每增加 100ms，转化率就会降低 1%”）

示例：工程复盘

• 300 英尺：“服务在下午 3:42 崩溃，内存使用量飙升至 32GB，返回了 500 个错误”
• 3K：“缓存层存在内存泄漏，在负载下由特定的 API 调用模式触发”
• 30K：“我们的缓存策略缺少淘汰策略；所有缓存都需要基于 TTL 的过期机制”

流程：(1) 收集执行层数据，(2) 识别模式并归类，(3) 在战术层提出假设，(4) 用更多数据验证，(5) 提炼战略原则

模式 3：层间转换（跨层沟通）

适用场景：向不同受众（CEO、经理、工程师）解释同一概念

方法：在保留核心含义的同时，调整抽象层级

示例：解释技术债务

• CEO（30K）：“我们早期为了快速构建产品走了捷径。现在，如果不投入 2M 美元进行现代化改造，增长每年会放缓 20%。”
• 经理（3K）：“单体架构阻碍了团队独立提升效率。应在 6 个月内迁移到微服务。”
• 工程师（300 英尺）：“将用户服务从单体中拆分出来。创建 API 层、实施服务网格并迁移流量。”

流程：(1) 确定受众所处的层级，(2) 提炼核心信息，(3) 使用与该层级相关的概念／指标进行转换，(4) 保持各层之间的因果联系

模式 4：约束传递（自上而下）

适用场景：高层约束必须指导低层决策

机制：战略约束逐层向下传递，在每一层缩小可选范围

示例：医疗应用设计

• 30K 约束：“HIPAA 合规不容妥协”（战略层）
• 3K 推导：“所有 PHI 都必须加密，必须保留审计日志，并强制实施访问控制”（战术层）
• 300 英尺实施：“使用 AWS KMS 加密、CloudTrail 审计、IAM 管理访问”（执行层）

护栏：低层不得违反高层约束（例如，执行层决定跳过加密，就违反了战略约束）

模式 5：识别涌现属性（自底向上）

适用情形：较低层级的交互产生了意想不到的上层行为

示例：团队结构

• 300 ft：“每个团队负责一个微服务，独立部署，并通过 Slack 协调”
• 3K 涌现现象：“康威定律：架构会映射沟通结构；跨团队功能开发缓慢”
• 30K 洞见：“组织结构决定系统架构；应按产品线而非服务重新调整团队”

流程：(1) 观察实际运作情况，(2) 识别战术层涌现出的模式，(3) 认识到其战略影响，(4) 视需要调整战略

模式 6：跨层一致性检查

适用情形：验证所有层级是否一致（不存在矛盾）

检查类型：

• 向上一致性：运作是否落实了战术？战术是否实现了战略？
• 向下一致性：能否通过这些战术执行战略？能否在运作层面落实战术？
• 横向一致性：并行的战术选择是否相互矛盾？运作流程是否冲突？

不一致示例：战略称“快速行动”，战术称“广泛审批流程”，运作称“3 周发布周期” → 矛盾

修正方法：使各层级保持一致。可选择 (1) 调整战略（“谨慎行动”），(2) 调整战术（“简化审批”），或 (3) 调整运作（“每日发布”）

---

工作流

应用分层推理时，采用以下结构化方法：

□ Step 1: Identify relevant layers and abstraction levels
□ Step 2: Define strategic layer (principles, invariants, constraints)
□ Step 3: Derive tactical layer (approaches that satisfy strategy)
□ Step 4: Design operational layer (concrete actions implementing tactics)
□ Step 5: Validate consistency across all layers
□ Step 6: Translate between layers for different audiences
□ Step 7: Iterate based on feedback from any layer
□ Step 8: Document reasoning at each layer

步骤 1：识别相关层级和抽象级别（详情） 确定所需层级数（通常为 3–5 层）。将层级映射到各个领域：业务（愿景/战略/执行）、技术（架构/设计/代码）、组织（使命/目标/任务）。

步骤 2：定义战略层（详情） 确立必须成立的高层原则、不变量和约束。这些要求不可妥协，并指导所有较低层级。

步骤 3：推导战术层（详情） 生成满足战略约束的方法/政策/架构。可能存在多种战术方案；应根据权衡取舍进行选择。

步骤 4：设计运作层（详情） 创建具体流程、实现或行动，以落实战术选择。执行就在这一层发生。

步骤 5：验证所有层级之间的一致性（详情） 检查向上一致性（运作是否落实了战术？）、向下一致性（能否执行战略？）和横向一致性（并行选择是否冲突？）。

步骤 6：针对不同受众在层级之间转换表述（详情） 针对每位利益相关者，以恰当的抽象级别进行沟通。CEO 需要战略视角，工程师需要运作细节。

步骤 7：根据任意层级的反馈进行迭代（详情） 如果运作约束导致战术不可行，就调整战术或战略。如果战略发生变化，就向下传递变更。

步骤 8：记录各层级的推理过程（详情） 在每个层级明确说明理由，解释其与上层或下层的关系。这样可以清晰呈现假设，并有助于今后的迭代。

---

防护措施

1. 保持各层级之间的一致性

风险：战略目标与实际运作相矛盾，或实现过程违背原则

防护措施：定期检查向上、向下和横向的一致性。双向传递变更（战略变更 → 更新战术/运作；运作约束 → 更新战术/战略）。

警示信号：“我们的战略是 X，但实际做的是 Y”表明层级不匹配

2. 沟通时不要跳过层级

危险：从 30K 英尺直接跳到 300 英尺，会让受众困惑、丢失上下文。

防护措施：按顺序逐层讲解。向高管说明时，从 30K 英尺讲到 3K 英尺（除非对方提出要求，否则到此为止）。向工程师说明时，先提供 30K 英尺的背景，再深入到 300 英尺。

检验：听众能否回答“这为什么重要？”（关联到上层）和“我们该怎么做？”（关联到下层）。

3. 每个层级都应独立发挥作用

危险：层级只有组合起来才有意义，无法单独理解。

防护措施：即使不看运营细节，战略层也应能指导决策。无需查看代码，也应能理解战术层。无需重新推导战略，运营层也应能直接执行。

原则：不同受众可以独立理解和使用好的层级。

4. 层级限制在 3–5 个

危险：层级过多会增加开销；层级过少则会丢失细微差别。

防护措施：对于大多数领域，3 个层级就足够（战略／战术／运营，或架构／设计／代码）。复杂领域可能需要 4–5 个，但很少需要更多。

经验法则：你能否清晰地说出每个层级的名称？如果不能，说明层级太多了。

5. 上层约束，下层实施

危险：将层级视为彼此独立，而非层级关系。

防护措施：战略层设定约束（“必须符合 HIPAA 合规要求”）。战术层在约束范围内选择方案（“加密 + 审计日志”）。运营层负责实施（“AES-256 + CloudTrail”）。下层不能违反上层要求。

反模式：运营决策（“为追求速度而跳过加密”）违反了战略约束（“符合 HIPAA 合规要求”）。

6. 双向传递变更

危险：战略转变后未更新战术／运营，或发现运营约束后战略却未调整。

防护措施：自上而下：战略变更 → 重新评估战术 → 调整运营。自下而上：运营约束 → 重新评估战术 → 必要时调整战略。

示例：战略转向“隐私优先” → 更新战术（端到端加密）→ 更新运营（实施加密）。或者：运营约束（性能）→ 调整战术（采用不同方案）→ 明确战略（“在性能约束范围内优先保护隐私”）。

7. 明确每个层级的假设

危险：隐含假设一旦不成立，就会导致不一致。

防护措施：记录每个层级的假设。战略层：“假设市场具有竞争性。”战术层：“假设使用云基础设施。”运营层：“假设使用 Python 3.9+。”

益处：假设发生变化时，就能知道需要更新哪些层级。

8. 识别涌现属性

危险：只关注设计出来的属性，而忽略意料之外的后果。

防护措施：定期观察底层，关注中层涌现出的模式，并考虑其战略影响。涌现属性可能会推翻战略假设。

示例：微服务（运营层）→ 协调开销（战术层涌现）→ 功能交付变慢（若目标是提速，则意味着战略失败）。

---

快速参考

不同领域的层级映射

领域	第 1 层（30K 英尺）	第 2 层（3K 英尺）	第 3 层（300 英尺）
业务	愿景、使命	战略、目标	战术、任务
产品	市场定位	功能路线图	用户故事
技术	架构原则	系统设计	代码实现
组织	文化、价值观	政策、流程	日常规程

一致性检查问题

检查类型	问题
向上	这些操作是否落实了策略？策略是否实现了战略？
向下	是否能用现有策略执行这一战略？能否在操作层面落实策略？
横向	并行的战术选择是否相互矛盾？操作流程是否存在冲突？

面向不同受众的翻译提示

受众	层级	关注点	指标
CEO / 董事会	3 万英尺	原因、成果、风险	收入、市场份额、战略风险
VP / 总监	3 千英尺	内容、方法、资源	团队速度、路线图、预算
经理 / 负责人	300 至 3 千英尺	方法、执行、时间线	冲刺速度、里程碑、质量
工程师	300 英尺	实现、细节	代码质量、测试覆盖率、性能

---

资源

资源导航

• 模板：分层推理文档模板、一致性检查模板、跨层沟通模板
• 方法论：层级设计原则、一致性验证技巧、涌现检测、双向传递
• 评分标准：分层推理质量评估标准（10 项）

相关技能

• abstraction-concrete-examples：用于在抽象与具体之间转换（相关，但结构不如分层方法严谨）
• decomposition-reconstruction：用于拆解复杂系统（与分层方法互补）
• communication-storytelling：用于不同层级受众之间的沟通转换
• adr-architecture：用于跨层记录架构决策
• alignment-values-north-star：用于定义战略层（价值观 → 战略）

---

情境示例

示例 1：SaaS 产品战略

3 万英尺（战略）：“成为最易用的小型企业 CRM”（定位）

3 千英尺（战术）：“简洁的 UI、5 分钟完成设置、移动优先、每位用户 20 美元定价、自助式引导”

300 英尺（操作）：“React 应用、使用 OAuth 进行身份验证、使用 Stripe 进行计费，引导流程：注册 → 导入联系人 → 发送首封邮件”

一致性检查：20 美元的定价是否支持“最易用”（是，门槛较低）？5 分钟完成设置是否符合当前实现（在实践中衡量）？移动优先是否与 React 架构一致（是）？

示例 2：技术架构

3 万英尺：“构建高可用系统，停机时间低于 1%，支持流量增长 10 倍”

3 千英尺：“多区域部署、自动扩缩容、熔断器、蓝绿部署”

300 英尺：“AWS 多可用区、采用目标跟踪的 ECS Fargate、Istio 熔断器、CodeDeploy 蓝绿部署”

涌现：观察到：跨区域延迟为 200 ms → 战术调整：区域间数据复制 → 战略澄清：“区域内高可用，区域间最终一致”

示例 3：组织变革

3 万英尺：“打造以客户为中心的文化，让客户反馈驱动决策”

3 千英尺：“每月召开客户咨询委员会会议、每次互动后开展 NPS 调查、在高管仪表板中展示客户支持 KPI”

300 英尺：“每月第一个周一安排 CAB 会议；工单关闭后通过 Delighted 自动收集 NPS；在 Looker 仪表板中按客服代表展示 CS CSAT”

一致性：每月召开 CAB 会议是否支持“以客户为中心”（还是频率太低）？客户支持 KPI 是否会激励正确的行为（检查是否有人为刷指标）？自动化是否削弱了人际互动（可能存在冲突）？