当前位置：首页 > news >正文

04-10-06 寻找假设 - 学习笔记

news 2026/4/27 18:24:51

04-10-06 寻找假设 - 学习笔记

章节信息

核心主题:假设的类型、识别隐藏假设、质疑假设、系统设计中的假设
学习目标:学会识别论证中的隐藏假设,评估假设的合理性
关键要点:价值观假设vs描述性假设、识别假设的方法、架构假设、技术选型假设

核心概念

1. 什么是假设?

定义

假设(Assumption):论证中未明确表达但必须成立才能使推理有效的信念或前提。

为什么重要:

假设是论证的"隐形地基"
地基不牢,整个论证都会崩塌
很多看似合理的论证,其实建立在有问题的假设之上
识别假设是批判性思维的核心能力

技术场景中的常见问题:

架构师:"我们应该用微服务架构" 隐藏假设: - 假设1:团队有微服务开发经验 - 假设2:业务复杂度需要微服务 - 假设3:运维能力能支撑微服务 - 假设4:性能开销可以接受 如果这些假设不成立,微服务就是错误选择

假设与理由的区别

理由(Reason):明确说出来的支撑论点 假设(Assumption):没有说出来但必须成立的前提 例: 结论:"我们应该用Kotlin开发" 理由:"Kotlin比Java更安全,代码更简洁" 隐藏假设: - 团队能学会Kotlin - Kotlin的生态足够成熟 - 迁移成本可以接受 - 公司允许使用Kotlin 理由是"说出来的",假设是"没说但必须成立的"

2. 两种主要假设类型

类型1:价值观假设(Value Assumption)

定义:关于"什么更重要"的隐含信念 特征: - 涉及优先级判断 - 反映个人或组织的价值倾向 - 不同人可能有不同的价值观假设 - 没有绝对的对错 例: 结论:"应该先优化性能,再开发新功能" 价值观假设:技术质量 > 功能交付 结论:"应该先上线,再迭代优化" 价值观假设:市场速度 > 技术完美 两个结论都有道理,差异在于价值观假设不同

技术决策中常见的价值观假设:

价值观对立 常见场景 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 稳定性 vs 创新性 技术选型、框架升级 性能 vs 开发效率 语言选择、架构设计 用户体验 vs 开发成本 功能完善度、交互细节 短期交付 vs 长期维护 技术债务、重构计划 统一性 vs 灵活性 技术栈统一、团队自治 安全性 vs 便利性 权限控制、数据保护

类型2:描述性假设(Descriptive Assumption)

定义:关于"世界是怎样的"的隐含信念 特征: - 涉及事实判断 - 可以验证真假 - 是从理由到结论之间的"逻辑桥梁" - 如果不成立,论证就无效 例: 结论:"用Room数据库可以提升App性能" 理由:"Room有编译期检查和优化" 描述性假设: - 假设当前性能瓶颈在数据库层 - 假设Room的性能优于当前方案 - 假设迁移成本不会抵消性能收益 如果瓶颈不在数据库,换Room就解决不了问题

两种假设的对比:

┌──────────────────────────────────────────┐ │ 价值观假设 vs 描述性假设 │ ├──────────────────────────────────────────┤ │ 维度 │ 价值观假设 │ 描述性假设 │ ├──────────────────────────────────────────┤ │ 内容 │ 什么更重要 │ 世界是怎样的 │ │ 性质 │ 主观判断 │ 客观事实 │ │ 验证 │ 难以验证对错 │ 可以验证真假 │ │ 例子 │ 安全>便利 │ 用户有WiFi │ │ 处理 │ 明确并对齐 │ 识别并验证 │ │ 影响 │ 决定方向 │ 决定可行性 │ └──────────────────────────────────────────┘

3. 识别隐藏假设的方法

方法1:检查论证缺口(Gap Analysis)

从理由到结论之间,缺了什么?

【方法】 1. 明确结论是什么 2. 明确理由是什么 3. 问:"从理由到结论,中间缺了什么条件?" 4. 缺少的条件就是隐藏假设 【示例】 结论:"我们应该从Java迁移到Kotlin" 理由:"Kotlin更安全,空安全特性能减少NPE" 从理由到结论的逻辑缺口: ├─ 缺口1:NPE真的是我们的主要问题吗? │ → 假设:NPE是当前bug的主要来源 │ ├─ 缺口2:团队能顺利学会Kotlin吗? │ → 假设:团队学习Kotlin的成本可接受 │ ├─ 缺口3:迁移过程不会引入新问题吗? │ → 假设:Java和Kotlin混合开发不会带来复杂性 │ └─ 缺口4:Kotlin的生态满足我们的需求吗? → 假设:所有依赖库都兼容Kotlin 每个缺口就是一个隐藏假设!

方法2:翻转测试(Flip Test)

把结论翻转,看看假设是否浮现

【方法】 1. 把结论反过来 2. 问:"如果反过来,需要什么条件?" 3. 原结论的假设就是反面条件的否定 【示例】 原结论:"我们应该用MVVM架构" 翻转:"我们不应该用MVVM架构" 翻转后成立的条件: ├─ 团队不熟悉MVVM → 原假设:团队熟悉MVVM ├─ 项目太简单不需要 → 原假设:项目复杂度需要MVVM ├─ 维护成本太高 → 原假设:MVVM的维护成本可接受 └─ 有更好的替代方案 → 原假设:MVVM是最适合的架构 通过翻转,隐藏假设清晰浮现!

方法3:角色代入法

站在不同角色的角度看问题

【方法】 1. 列出所有利益相关方 2. 分别站在每个角色的角度思考 3. 不同角色会质疑不同的假设 【示例:选择新的日志框架】 结论:"应该把日志框架从Log4j换成Timber" 开发者视角: "Timber确实更好用,但迁移100个文件的成本谁来承担?" → 暴露假设:迁移成本可以接受 测试视角: "换了之后,日志格式变了,现有的日志分析脚本都要改" → 暴露假设:不会影响现有工具链 运维视角: "线上日志收集系统能兼容吗?" → 暴露假设:与线上系统兼容 产品视角: "换框架对用户有什么好处?值得花时间吗?" → 暴露假设:这件事值得投入资源

方法4:前提条件清单法

系统地列出论证成立需要的所有前提

【方法】 1. 写下结论 2. 列出"这个结论成立,需要满足什么条件?" 3. 逐一检查每个条件是否真的成立 【示例:采用Flutter跨平台开发】 结论:"用Flutter替代原生开发可以降低成本" 前提条件清单: □ Flutter的性能满足业务需求 □ Flutter能实现所有需要的原生功能 □ 团队能快速掌握Dart语言 □ Flutter的第三方库生态足够丰富 □ 跨平台UI一致性满足设计要求 □ Flutter的热更新能力满足运营需求 □ 长期维护成本确实低于两端原生 □ 招聘Flutter开发者不会比原生更难 □ 现有原生代码的迁移成本可控 每个未勾选的条件都是一个风险!

4. 常见隐藏假设模式

模式1:因果关系假设

把相关性当成因果性 **错误做法** - "竞品用了Flutter,所以竞品开发效率高" 隐藏假设:Flutter是竞品效率高的原因 实际可能:竞品效率高可能因为团队能力强、流程好 **错误做法** - "引入代码审查后,bug减少了" 隐藏假设:代码审查导致了bug减少 实际可能:同期也增加了测试、优化了流程 判断方法: 1. 有没有其他可能的原因? 2. 两件事只是碰巧同时发生? 3. 因果方向对吗?(A导致B,还是B导致A?)

模式2:以偏概全假设

用个别案例代表整体 **错误做法** - "Google用微服务,所以微服务是最佳实践" 隐藏假设:Google的经验适用于所有公司 实际情况:Google的团队规模、基础设施、业务复杂度 和大部分公司完全不同 **错误做法** - "上个项目用MVI成功了,这个项目也应该用" 隐藏假设:两个项目的条件相同 实际情况:团队成员、业务类型、时间约束都可能不同 判断方法: 1. 样本够不够大? 2. 条件够不够相似? 3. 有没有反例?

模式3:现状延续假设

假设未来和现在一样 **错误做法** - "现在用户量只有1万,不需要考虑高并发" 隐藏假设:用户量不会快速增长 实际可能:如果产品成功,用户量可能暴增 **错误做法** - "现在的服务器够用,不需要扩容方案" 隐藏假设:负载不会变化 实际可能:促销活动、节日高峰等都会导致流量激增 判断方法: 1. 什么条件下现状会改变? 2. 改变的概率有多大? 3. 如果改变了,后果是什么?

模式4:能力假设

假设团队有某种能力 **错误做法** - "我们可以自己开发推送服务" 隐藏假设:团队有开发高可用推送服务的能力 实际情况:推送服务涉及长连接、消息可靠性等 复杂问题,团队可能没有经验 **错误做法** - "2周可以完成这个功能" 隐藏假设: - 需求不会变更 - 不会遇到技术难题 - 开发人员不会请假 - 测试一次通过 判断方法: 1. 团队真的有这方面经验吗? 2. 之前做过类似的事吗? 3. 最乐观/最悲观的估算差多少?

模式5:用户行为假设

假设用户会按预期使用 **错误做法** - "用户会仔细阅读引导页" 隐藏假设:用户有耐心阅读 实际情况:大部分用户直接跳过引导 **错误做法** - "用户会按正常流程操作" 隐藏假设:用户不会做异常操作 实际情况:用户会快速连续点击、旋转屏幕、 断网操作、后台切换等 **错误做法** - "用户会及时更新App" 隐藏假设:用户会主动更新 实际情况:大量用户停留在旧版本 判断方法: 1. 用户真的会这样做吗? 2. 有数据支撑吗? 3. 最坏的情况是什么?

Android/IoT开发实战案例

案例1:架构选型中的隐藏假设

场景:IoT智能家居App选择通信架构

背景

项目:智能家居控制App 设备:摄像头、门锁、传感器等 通信:需要实时控制和状态同步 团队:6人,有Android经验,无IoT经验 时间:4个月MVP

忽略隐藏假设的决策

【讨论记录】 架构师: "用MQTT协议做设备通信,这是IoT行业标准" 理由: 1. MQTT是IoT行业标准 2. 轻量级,适合设备端 3. 支持发布/订阅模式 团队: "好,按MQTT做" ...直接开始开发 【3个月后出现的问题】 问题1:MQTT不支持P2P直连 ├─ 隐藏假设:所有场景都走云端 ├─ 实际需求:用户要求局域网内也能控制 └─ 影响:需要额外开发局域网发现和P2P通信 问题2:MQTT的QoS不满足安全需求 ├─ 隐藏假设:MQTT的可靠性足够 ├─ 实际需求:门锁等安全设备需要确认送达 └─ 影响:需要在应用层额外实现确认机制 问题3:设备固件升级需要大文件传输 ├─ 隐藏假设:MQTT只需要传小消息 ├─ 实际需求:OTA升级需要传输几十MB固件 └─ 影响:MQTT不适合大文件传输,需要另选方案 问题4:团队没有MQTT运维经验 ├─ 隐藏假设:团队能搞定MQTT broker的部署和运维 ├─ 实际情况:Broker频繁掉线,消息堆积 └─ 影响:线上事故频发 【根本原因】 没有识别和验证隐藏假设,直接基于"行业标准"做决策

识别并验证假设的决策

【改进的讨论】 架构师: "MQTT是IoT行业标准,我建议用MQTT" Tech Lead: "先别急,我们列一下这个方案的假设" 【第一步:识别隐藏假设】 价值观假设: ├─ "行业标准" > "团队熟悉度" ├─ "技术先进性" > "实现简单性" └─ "长期扩展性" > "短期交付速度" 描述性假设: ├─ 假设1:所有通信场景都走云端 ├─ 假设2:MQTT的QoS满足所有设备的可靠性需求 ├─ 假设3:不需要大文件传输 ├─ 假设4:团队能快速掌握MQTT ├─ 假设5:MQTT broker的运维难度可控 ├─ 假设6:MQTT延迟满足实时控制需求 └─ 假设7:第三方MQTT SDK稳定可靠 【第二步:逐一验证假设】 假设1:所有通信走云端 验证:[未通过] 产品要求局域网内也能控制 结论:需要同时支持云端和局域网通信 假设2:QoS满足可靠性需求 验证:⚠️ 门锁/报警器需要100%送达确认 结论:安全设备需要额外的应用层确认 假设3:不需要大文件传输 验证:[未通过] OTA固件升级需要传输大文件 结论:需要额外的文件传输通道 假设4:团队能快速掌握 验证:⚠️ 团队无MQTT经验,学习需要2-3周 结论:需要预留学习时间 假设5:运维难度可控 验证:[未通过] 团队无Broker运维经验 结论:考虑使用云服务商的托管MQTT 假设6:延迟满足实时控制 验证:[通过] MQTT延迟通常在100ms以内 结论:延迟可接受 假设7:第三方SDK稳定 验证:⚠️ 需要实际测试验证 结论:需要POC验证 【第三步:基于验证结果调整方案】 调整后的架构方案: ┌────────────────────────────────────┐ │ 通信架构 │ ├────────────────────────────────────┤ │ │ │ 云端通信:托管MQTT服务 │ │ ├─ 使用云服务商托管(解决运维问题) │ │ ├─ 应用层确认机制(解决可靠性) │ │ └─ 适用:远程控制、状态同步 │ │ │ │ 局域网通信:mDNS + CoAP │ │ ├─ 设备发现:mDNS │ │ ├─ 控制协议:CoAP(轻量级REST) │ │ └─ 适用:局域网内快速控制 │ │ │ │ 文件传输:HTTP/HTTPS │ │ ├─ OTA固件升级 │ │ ├─ 断点续传 │ │ └─ 适用:大文件传输 │ │ │ └────────────────────────────────────┘ 验证计划: ├─ Week 1:MQTT POC + 团队学习 ├─ Week 2:局域网通信POC ├─ Week 3:集成测试 └─ Week 4:性能和稳定性验证 风险缓解: ├─ 运维风险:用托管服务 ├─ 学习风险:预留学习时间 ├─ 可靠性风险:应用层确认机制 └─ 大文件风险:独立的HTTP通道

关键点分析:

【成功因素】 1. 系统性识别了6个隐藏假设 2. 逐一验证,发现3个假设不成立 3. 基于验证结果调整方案 4. 预留了POC验证时间 5. 针对每个风险有缓解措施 【教训】 "行业标准"不等于"最佳选择" 必须检查"行业标准"背后的假设 是否适用于自己的具体场景

案例2:性能优化中的假设陷阱

场景:App启动速度优化

背景

现状: - 冷启动时间:4.2秒 - 目标:降到2秒以内 - 用户投诉:应用市场大量1星评价提到启动慢 技术Leader的方案: "主要原因是Application初始化太重, 需要把所有SDK改成懒加载"

基于未验证假设的优化

【方案】 技术Leader: "Application.onCreate里初始化了15个SDK, 占了3秒。改成懒加载就能解决。" 隐藏假设(未识别): ├─ 假设1:启动慢的主要原因是SDK初始化 ├─ 假设2:所有SDK都可以懒加载 ├─ 假设3:懒加载不会导致使用时卡顿 ├─ 假设4:没有其他瓶颈 └─ 假设5:优化后能达到2秒目标 【2周后的结果】 优化后启动时间:3.5秒(只快了0.7秒!) 原因分析: ├─ 假设1部分成立:SDK初始化占1.5秒,不是3秒 ├─ 假设2不成立:3个SDK必须提前初始化(推送、埋点、安全) ├─ 假设3不成立:首页用到的SDK懒加载后,首页打开卡了1秒 ├─ 假设4不成立:还有其他瓶颈 │ ├─ 首屏布局复杂,inflate耗时0.8秒 │ ├─ 首屏数据请求串行,耗时1.2秒 │ └─ SharedPreferences读取阻塞主线程0.5秒 └─ 假设5不成立:单靠SDK懒加载远远不够 浪费了2周!

先验证假设再优化

【改进的方法】 Tech Lead: "先别急着改代码,我们先验证假设" 【第一步:识别假设】 方案假设: 1. SDK初始化是主要瓶颈 2. 所有SDK可以懒加载 3. 懒加载没有副作用 4. 没有其他瓶颈 5. 优化后能达到2秒 【第二步:用数据验证假设】 使用Systrace + 自定义打点,分析启动过程: 启动耗时分解: ┌────────────────────────────────────┐ │ 阶段 │ 耗时 │ 占比 │ ├────────────────────────────────────┤ │ Application创建 │ 0.3s │ 7% │ │ SDK初始化 │ 1.5s │ 36% │ │ Activity创建 │ 0.2s │ 5% │ │ 布局inflate │ 0.8s │ 19% │ │ 首屏数据请求 │ 1.2s │ 29% │ │ SP读取(主线程) │ 0.2s │ 5% │ │ 总计 │ 4.2s │ 100% │ └────────────────────────────────────┘ 假设验证结果: ├─ 假设1:部分成立,SDK初始化占36%,是瓶颈之一但非唯一 ├─ 假设2:需要逐一评估 ├─ 假设4:不成立,布局(19%)和网络(29%)也是大头 └─ 假设5:只优化SDK最多省1.5秒,达不到目标 【第三步:基于数据制定全面优化方案】 综合优化方案: 阶段1:SDK初始化优化(预期-1.0s) ├─ 可懒加载的SDK:延迟初始化 ├─ 不可懒加载的SDK:异步线程初始化 └─ 合并初始化:减少线程切换 阶段2:布局优化(预期-0.5s) ├─ ViewStub替代复杂布局 ├─ 异步inflate └─ 减少布局层级 阶段3:数据请求优化(预期-0.8s) ├─ 串行改并行 ├─ 增加缓存,先展示缓存数据 └─ 预加载机制 阶段4:其他优化(预期-0.2s) ├─ SP改为MMKV ├─ 减少主线程IO └─ 线程池优化 预期总效果: ├─ 优化前:4.2秒 ├─ 优化后:4.2 - 2.5 = 1.7秒 └─ 达成目标:[通过] < 2秒 【关键差异】 **错误做法** - 不验证假设:只优化了一个点,效果不达标 **正确做法** - 先验证假设:全面分析,多点优化,效果达标

案例3:IoT设备通信的假设验证

场景:智能摄像头P2P实时视频传输方案

背景

需求: - 用户手机远程查看摄像头实时画面 - 延迟要求:< 500ms - 画质要求:720P以上 方案讨论: 开发A:"直接走云端转发,简单可靠" 开发B:"用P2P直连,延迟更低"

识别和验证假设

【云端转发方案的隐藏假设】 假设1:云端带宽成本可以接受 ├─ 验证:计算成本 │ └─ 1万台设备,每天平均观看30分钟 │ 720P码率约2Mbps │ 带宽成本 = 10000 × 2Mbps × 30min = 巨额成本 ├─ 结论:[未通过] 成本不可接受,设备规模越大越贵 └─ 影响:纯云端方案不可行 假设2:云端延迟满足500ms要求 ├─ 验证:实测链路 │ └─ 设备→云端→手机,经过编码/转发/解码 │ 典型延迟:800ms-1500ms ├─ 结论:[未通过] 延迟超标 └─ 影响:实时性不满足要求 假设3:云端可用性足够高 ├─ 验证:SLA评估 │ └─ 单点故障风险:云端宕机则所有设备不可用 ├─ 结论:⚠️ 需要多机房容灾 └─ 影响:增加架构复杂度和成本 【P2P直连方案的隐藏假设】 假设1:P2P能成功打洞 ├─ 验证:NAT类型分析 │ └─ 对称型NAT(约30%用户)无法直接打洞 ├─ 结论:⚠️ 部分用户需要TURN中继 └─ 影响:仍需要云端作为后备 假设2:P2P连接稳定 ├─ 验证:网络环境测试 │ └─ 弱网环境下P2P容易断连 ├─ 结论:⚠️ 需要自动重连和降级策略 └─ 影响:需要额外的稳定性机制 假设3:设备端有足够算力做P2P ├─ 验证:设备硬件评估 │ └─ 低端设备CPU和内存有限 ├─ 结论:[通过] 主流芯片可以支持 └─ 影响:低端设备可能需要降低画质 【基于假设验证的最终方案】 混合方案: ┌─────────────────────────────────────┐ │ 优先P2P直连,云端作为后备 │ ├─────────────────────────────────────┤ │ │ │ 1. 尝试P2P直连(延迟低,成本低) │ │ ├─ 成功率约70% │ │ └─ 延迟:100-300ms │ │ │ │ 2. P2P失败时,TURN中继(保证可用) │ │ ├─ 覆盖剩余30%用户 │ │ └─ 延迟:300-500ms │ │ │ │ 3. 弱网降级策略 │ │ ├─ 720P → 480P → 360P │ │ ├─ 自动码率调整 │ │ └─ 保证可用性优先 │ │ │ └─────────────────────────────────────┘ 成本对比: ├─ 纯云端:每月XX万元(随设备增长线性增长) ├─ 混合方案:每月XX千元(只有30%流量走云端) └─ 节省:约70%带宽成本

实用工具与检查清单

工具1:假设识别检查清单

┌────────────────────────────────────────┐ │ 假设识别检查清单 │ ├────────────────────────────────────────┤ │ │ │ □ 结论是什么? │ │ □ 理由是什么? │ │ □ 从理由到结论,缺了什么条件? │ │ □ 翻转结论,需要什么条件才成立? │ │ □ 不同角色会怎么质疑? │ │ │ │ 价值观假设检查: │ │ □ 论证者认为什么更重要? │ │ □ 这个优先级在当前场景合理吗? │ │ □ 不同角色的优先级一样吗? │ │ │ │ 描述性假设检查: │ │ □ 有哪些关于事实的隐含前提? │ │ □ 这些前提能用数据验证吗? │ │ □ 如果前提不成立,结论还对吗? │ │ │ └────────────────────────────────────────┘

工具2:技术方案假设分析模板

技术方案假设分析模板 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 【方案名称】 _____________________________________________ 【结论】 "我们应该采用__________方案" 【理由】 1. 2. 3. 【价值观假设】 假设:__________ > __________ 在当前项目中是否合理? □是 □否 理由: 【描述性假设清单】 假设1:_______________________________________ ├─ 类型: □因果 □能力 □用户行为 □现状延续 ├─ 验证方法:_______________________________ ├─ 验证结果: □成立 □不成立 □不确定 ├─ 如果不成立的影响:_______________________ └─ 应对措施:_______________________________ 假设2:_______________________________________ ├─ 类型: □因果 □能力 □用户行为 □现状延续 ├─ 验证方法:_______________________________ ├─ 验证结果: □成立 □不成立 □不确定 ├─ 如果不成立的影响:_______________________ └─ 应对措施:_______________________________ 假设3:_______________________________________ ├─ 类型: □因果 □能力 □用户行为 □现状延续 ├─ 验证方法:_______________________________ ├─ 验证结果: □成立 □不成立 □不确定 ├─ 如果不成立的影响:_______________________ └─ 应对措施:_______________________________ 【关键假设】(不成立就推翻整个方案的假设) 1. 2. 【验证计划】 假设1验证:方法_____ 时间_____ 负责人_____ 假设2验证:方法_____ 时间_____ 负责人_____ 【方案调整】(基于假设验证结果) 原方案 → 调整后方案

工具3:技术决策假设速查表

技术决策常见假设速查表 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 【架构选型】 □ 团队有相关经验 □ 业务复杂度匹配 □ 性能需求满足 □ 运维能力匹配 □ 生态系统成熟 □ 招聘市场充足 【性能优化】 □ 瓶颈定位准确 □ 优化方案有效 □ 不会引入新问题 □ 优化效果可量化 □ 投入产出比合理 【技术选型】 □ 满足当前需求 □ 支持未来扩展 □ 社区活跃度足够 □ 长期维护有保障 □ 与现有技术栈兼容 □ 学习成本可接受 【工期估算】 □ 需求不会变更 □ 技术方案可行 □ 人员不会变动 □ 没有外部依赖阻塞 □ 包含测试和联调时间 □ 预留了缓冲时间 【用户需求】 □ 用户真的需要这个功能 □ 用户会按预期使用 □ 用户的设备能支持 □ 用户的网络环境满足 □ 用户愿意为此付费/升级

工具4:假设验证优先级矩阵

假设验证优先级矩阵 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 根据"影响程度"和"不确定性"两个维度排优先级: 不确定性高 不确定性低 ┌──────────────────┬──────────────────┐ 影响大 │ ★★★★★ │ ★★★ │ │ 最优先验证 │ 记录并监控 │ │ 例:性能瓶颈定位 │ 例:SDK兼容性 │ ├──────────────────┼──────────────────┤ 影响小 │ ★★ │ ★ │ │ 有空再验证 │ 可以接受 │ │ 例:日志格式选择 │ 例:代码风格偏好 │ └──────────────────┴──────────────────┘ 优先验证:影响大 + 不确定性高的假设 其次验证:影响大 + 不确定性低的假设 可延后:影响小的假设