https://bytedepth.cn bytedepth 最近发布的文章 Tue, 25 Aug 2026 11:08:44 +0800 https://bytedepth.cn/posts/adr-template-and-example https://bytedepth.cn/posts/adr-template-and-example > **TL;DR**：本篇提供 ADR（架构决策记录）的空白模板与一个公认写得好的完整示例。模板遵循 Michael Nygard 的原始四要素结构，示例改编自业界广泛参考的微服务缓存决策案例。直接复制模板使用，对照示例检查完整度——**一篇合格的 ADR 不在于篇幅，而在于假设可证伪、后果含负向、放弃了什么被写明**。 --- ## 概念解释 ### ADR 模板的来源 Michael Nygard 在 2011 年的文章《Documenting Architecture Decisions》中提出的格式极其简洁：Context（上下文）、Decision（决策）、Consequences Tue, 25 Aug 2026 11:08:44 +0800 https://bytedepth.cn/posts/decision-tradeoffs-software-engineering https://bytedepth.cn/posts/decision-tradeoffs-software-engineering > **TL;DR**：本篇用一个完整案例串起全专栏方法——为消息队列选型做一次可复盘的技术选型。流程是：判断门类型 → 列选项与维度 → 决策矩阵权衡 → Premortem 识别风险 → 写 ADR 记录假设与退出条件 → 预设回退路径。最终产出是一页“技术选型决策记录”，让选型过程可被审阅、假设可被证伪、回退可被执行。判断选型是否合格，不看上线后是否“没问题”，看证据链是否闭合、退出条件是否预设。 --- ## 概念解释 ### 技术选型作为决策问题 技术选型（如选消息队列、数据库、框架）是软件工程最高频的决策类型。它的难点不在“哪个技术更好”，而在“在当前团队、业务约束、未来不确定性下 Tue, 25 Aug 2026 10:47:27 +0800 https://bytedepth.cn/posts/premortem-precommitment https://bytedepth.cn/posts/premortem-precommitment > **TL;DR**：Premortem（事前验尸）在决策执行前，假设“这个决策一年后失败了”，然后倒推失败原因。它把事后复盘的反思能力前置到还有机会调整的时刻。预承诺是配套机制：基于 Premortem 识别的风险，预先承诺“若出现 X 就做 Y”，避免事发后临时决策。两者配合，把单向门决策的失败成本从“事后救火”前移到“事前预防”。 --- ## 概念解释 ### Premortem 的由来与原理 **Premortem**（事前验尸）由心理学家 Gary Klein 于 2007 年在《Harvard Business Review》提出。它与传统的 postmortem（事后复盘）相 Tue, 25 Aug 2026 10:47:11 +0800 https://bytedepth.cn/posts/reversibility-two-way-door https://bytedepth.cn/posts/reversibility-two-way-door > **TL;DR**：不是所有决策都值得同等慎重。Bezos 的门框架把决策分为双向门（可逆，快做）和单向门（不可逆，慎做），让分析投入匹配风险。关键认知：可逆性是**连续谱而非二元**——很多决策表面可回退却带隐性不可逆成本（数据已迁移、承诺已被依赖）。判断门类型的方法不是问“能不能撤销”，而是问“撤销的代价是否超过重做”。 --- ## 概念解释 ### 双向门与单向门 这两个概念由亚马逊创始人 Jeff Bezos 在 2016 年致股东信《2016 Letter to Shareholders》中明确提出。他用“门”比喻决策的不可逆性： - **双向门**（two-way door） Tue, 25 Aug 2026 10:46:55 +0800 https://bytedepth.cn/posts/decision-matrix-trade-offs https://bytedepth.cn/posts/decision-matrix-trade-offs > **TL;DR**：决策矩阵把“凭直觉选”变成“显式权衡”——列出选项与评估维度，为每个交叉点打分或标注，让“为什么选 A 不选 B”成为可检查的推理。它的价值不在精确分数，而在**暴露权重假设**：当两个方案总分接近时，翻看哪个维度的权重决定了结果，就能发现你真正在权衡什么。矩阵不替你做决定，它让你的取舍可被审阅、可被质疑、可被修正。 --- ## 概念解释 ### 决策矩阵是什么 **决策矩阵**（Decision Matrix，又称 Pugh 矩阵或加权评分矩阵）是一种多准则决策工具：把候选方案作为行、评估维度作为列，为每个交叉点打分，再按维度权重加权求和，得出每个方案的总分。它最早 Tue, 25 Aug 2026 10:46:40 +0800 https://bytedepth.cn/posts/adr-architecture-decision-records https://bytedepth.cn/posts/adr-architecture-decision-records > **TL;DR**：架构决策记录（ADR）是一份轻量文档，记录“做了什么决策、为什么、基于什么假设、放弃了什么”。它不是设计文档，而是决策的留痕——让半年后没人记得“为什么选了 A”时仍能回溯推理。ADR 的关键属性是可演进：新决策可取代旧决策，形成决策树而非孤立文件。一份合格的 ADR 必须包含上下文、决策、后果与假设，且**假设是可证伪的**——若假设不成立，决策应被推翻。 --- ## 概念解释 ### ADR 的由来与定义 **架构决策记录**（Architecture Decision Record，ADR）由 Michael Nygard 在 2011 年的文章《Documen Tue, 25 Aug 2026 10:46:24 +0800 https://bytedepth.cn/posts/decision-tradeoffs-overview https://bytedepth.cn/posts/decision-tradeoffs-overview > **TL;DR**：决策不是“选最好的方案”，而是**在多目标、不确定性和约束下，做出可被审阅、可回退、可演进的承诺**。系统思维建模、因果与证据验证之后，决策与权衡负责把分析转化为选择。关键区分：可逆决策快做、不可逆决策慎做；决策质量不等于结果好坏——**过程可审阅、假设可回溯、退出条件预设，才是一个工程决策的交付物**。 --- ## 概念解释 在进入正文前，先讲清本专栏用到的核心概念——它们常被混用，但各自指向不同的认知任务。 ### 决策与权衡 **决策**是把多个可能行动收敛为一个承诺的认知动作。它由三层组成：选项（有哪些可能）、判断（哪个更优）、承诺（选定并执行）。**权衡** Tue, 25 Aug 2026 10:46:09 +0800 https://bytedepth.cn/posts/causal-evidence-software-engineering https://bytedepth.cn/posts/causal-evidence-software-engineering > **TL;DR**：本篇用一个完整案例串起全专栏方法——引入编程 Agent 后，交付周期是否真的缩短、质量是否守住。流程是：5W2H 与时间线固化事实 → 系统模型定位瓶颈 → 因果图显化混杂与中介 → 列竞争性解释 → 灰度/消融实验检验 → 指标护栏与 PDSA 复盘。最终产出是一页可照着执行的“证据化改进记录”，而非泛泛案例故事。判断改进是否有效，不看文档长度，看证据链是否闭合、护栏是否守住、模型是否被更新。 ## 目录 | 章节 | 说明 | |------|------| | [案例与系统边界](#案例与系统边界) | 引入 Agent 想缩短交付周期 | | [串起全流程]( Mon, 24 Aug 2026 14:31:40 +0800 https://bytedepth.cn/posts/metrics-decision-review-goodhart https://bytedepth.cn/posts/metrics-decision-review-goodhart > **TL;DR**：指标不是被动的仪表，它会改变行为——一旦某指标成为考核或决策依据，团队就会优化这个数字而非真实结果，这就是 Goodhart 定律的工程含义。应对不是“堆更多指标”，而是分清目标、结果指标、领先指标、代理指标与护栏指标，让指标组合**暴露权衡与副作用**而非彼此粉饰。决策复盘则回答：当时相信什么、基于什么证据、预测什么、实际发生什么、该更新哪条规则——把“成功”从结果倒推改为过程校准。 ## 目录 | 章节 | 说明 | |------|------| | [指标为何改变行为](#指标为何改变行为) | 度量即干预 | | [Goodhart 定律的工程含义](#Goo Mon, 24 Aug 2026 14:31:28 +0800 https://bytedepth.cn/posts/experiment-design-ablation https://bytedepth.cn/posts/experiment-design-ablation > **TL;DR**：实验是把“X 是否导致 Y”从观察转为干预检验的最强工具。A/B 测试随机分组、因果强度最高；灰度发布按比例放量、兼顾安全与验证；消融实验回答“移除某组件后结果是否改变”；前后对比最弱，易被时间趋势污染。四种设计支持的因果主张强度不同，不能混用其结论。消融逐项移除并不总能代表组件真实贡献——组件之间存在交互效应时，单独移除与组合移除的结果会矛盾。  ## 目录 | 章节 | 说明 | |---- Mon, 24 Aug 2026 14:31:17 +0800 https://bytedepth.cn/posts/causal-graphs-confounding https://bytedepth.cn/posts/causal-graphs-confounding > **TL;DR**：因果图（DAG）用箭头表达“我们假设谁导致谁”，帮我们判断该控制什么、不该控制什么。直觉认为“控制越多变量越严谨”，但因果图显示三种变量要分开处理：**混杂因素**必须控制，**中介变量**通常不该控制（会切断机制），**碰撞器**一旦控制反而引入虚假关联。判断“AI 辅助编码是否缩短交付周期”时，工作复杂度、团队成熟度是混杂，代码生成速度是中介，把这两类混为一谈就会得到错误结论。  # Mon, 24 Aug 2026 14:31:06 +0800 https://bytedepth.cn/posts/root-cause-evidence-closure https://bytedepth.cn/posts/root-cause-evidence-closure > **TL;DR**：根因分析（RCA）的难点不是“找到原因”，而是判断一个原因主张**证据是否闭合**。[因果分析与根因分析](/posts/211) 给出了从时间线到证据表的六步流程；本篇深化“证据标准与适用边界”——人的失误是调查起点而非结论，5 Whys 和鱼骨图只生成假设，故障树处理 AND/OR 组合，FMEA 是前瞻工具而非事后证明。一条因果路径只有同时具备机制、时序和区分性证据，才应进入“已闭合”集合。 ## 目录 | 章节 | 说明 | |------|------| | [与既有 RCA 笔记的分工](#与既有%20RCA%20笔记的分工) | 流程在 06，证据标准在本 Mon, 24 Aug 2026 14:30:55 +0800 https://bytedepth.cn/posts/causal-evidence-overview https://bytedepth.cn/posts/causal-evidence-overview > **TL;DR**：把“我认为 X 导致 Y”变成可被审阅、验证和更新的决策依据，先分清**相关、因果、机制、反事实与证据强度**五件事，再走一条统一工作流：问题与结果变量 → 因果假设 → 竞争性解释 → 证据与设计 → 干预 → 复查与更新。系统思维提出结构假设，因果与证据负责检验关键关系——**漂亮的关系图或回归结果本身不是因果证明**。  ## 目录 | 章节 | 说明 | |------|------| | [这 Mon, 24 Aug 2026 14:30:44 +0800 https://bytedepth.cn/posts/how-to-choose-methods https://bytedepth.cn/posts/how-to-choose-methods > **TL;DR**：方法选择遵循两步——**先判断面对的是什么情境，再定位当前缺少哪一种认知产出**。没有脱离情境的“最佳方法”：稳定流程适合标准化，复杂情境适合探索性实验。覆盖多阶段的端到端框架（A3、PDSA、OODA 等）不能因为都叫“循环”就互换。本篇承接 [思维方法全景地图](/posts/216) 的七阶段闭环，回答“卡在某一阶段时该用哪个工具”；工具本身的清单见 [认知透镜与思维工具索引](/posts/215)。 ![framework coverage matrix](/images/7cd84534e3ea4317aa255130a27abbbe.svg "width= Mon, 24 Aug 2026 14:30:32 +0800 https://bytedepth.cn/posts/thinking-methods-landscape https://bytedepth.cn/posts/thinking-methods-landscape > **TL;DR**：这张地图只回答一个问题：**当工作卡住时，下一步该用什么**。先定位“观察—定义—建模—验证—决策—行动—学习”中的缺口，再选择能产出当前所需结果的最小方法——方法不是越多越好，能让思考被检查、让行动产生反馈才有价值。本篇是导航中枢；具体有哪些工具见 [认知透镜与思维工具索引](/posts/215)，怎么选见 [如何选择方法](/posts/219)。 > > **使用顺序**：定位卡点 → 选择认知透镜 → 选择最小工具 → 检查产出 → 根据反馈更新。  | 归属与收录原则 | | [认知透镜](#认知透镜) | 12 种改变观察方式的透镜 | | [阶段型 Mon, 24 Aug 2026 14:30:10 +0800 https://bytedepth.cn/posts/systems-thinking-software-engineering https://bytedepth.cn/posts/systems-thinking-software-engineering > **TL;DR**：软件交付不是“开发写完代码”的局部过程，而是从需求承诺到用户验证、并把运行反馈带回团队的社会技术系统。改善它应以价值流为边界，用 DORA 成组指标观察速度与稳定性，以系统模型解释等待和返工，再用 A3 承载问题解决、PDSA 验证干预。  ## 目录 | 章节 | 说明 | |------|------| | [案例与系统边界](#案例与系统边界) | 交付周期从 2 天增至 8 天 | | [先建立 Sun, 23 Aug 2026 23:24:38 +0800 https://bytedepth.cn/posts/systems-modeling-workshop https://bytedepth.cn/posts/systems-modeling-workshop > **TL;DR**：系统建模工作坊的目标不是画出漂亮而完整的图，而是让分散在不同角色中的事实、假设和利益冲突进入同一个可检验模型。一次有效工作坊应产出：共同问题定义、行为曲线、版本化因果模型、证据缺口、竞争性解释和下一轮验证计划。 ## 目录 | 章节 | 说明 | |------|------| | [何时值得开工作坊](#何时值得开工作坊) | 适用条件与禁区 | | [会前准备](#会前准备) | 范围、数据与参与者 | | [九十分钟流程](#九十分钟流程) | 从行为到验证计划 | | [引导规则](#引导规则) | 分离事实、解释和权力 | | [质量检查](#质量检查) | Sun, 23 Aug 2026 23:24:35 +0800 https://bytedepth.cn/posts/leverage-points-intervention https://bytedepth.cn/posts/leverage-points-intervention > **TL;DR**：杠杆点不是“投入最少、收益最大”的万能按钮，而是改变系统行为的不同层次。参数最容易改却常被系统吸收；信息流、规则、目标和范式通常影响更深，也更难推动。可靠策略是组合高低层干预，以可回退实验验证方向，并持续监测延迟、副作用与系统适应。  ## 目录 | 章节 | 说明 | |------|------| | [从浅到深的干预层次](#从浅到深的干预层次) | 参数、结构、反馈、规则与目的 | | [选择杠杆点 Sun, 23 Aug 2026 23:24:33 +0800 https://bytedepth.cn/posts/causal-root-cause-analysis https://bytedepth.cn/posts/causal-root-cause-analysis > **TL;DR**：寻找根因的方法叫**根因分析（Root Cause Analysis，RCA）**，但复杂事故往往没有唯一“根因”。有效流程是：时间线与 5W2H 固化事实 → 变化分析缩小范围 → 因果树表达多重条件 → 证据表检验关系 → 屏障分析发现防线缺口 → 设计并验证纠正措施。5 Whys 和鱼骨图用于生成假设，不能单独证明因果。  ## 目录 | 章节 | 说明 | |------|------| Sun, 23 Aug 2026 23:24:30 +0800