<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
<title>bytedepth</title>
<link>https://bytedepth.cn</link>
<description>bytedepth 最近发布的文章</description>
<atom:link href="https://bytedepth.cn/feed.xml" rel="self" type="application/rss+xml"/>
<lastBuildDate>Wed, 26 Aug 2026 12:08:26 +0800</lastBuildDate>
<item>
<title>05 软件工程综合实践：做一次能改变规则的复盘</title>
<link>https://bytedepth.cn/posts/retrospective-software-engineering-practice</link>
<guid isPermaLink="true">https://bytedepth.cn/posts/retrospective-software-engineering-practice</guid>
<description>&gt; **TL;DR**：本篇用一个完整案例串起全专栏方法——为一次线上事故做端到端复盘。流程：无责时间线 → 促成条件与系统防线 → PDSA 对照假设 → 判断更新深度 → 产出可审阅的行动项与复查记录。最终产出是一页“复盘决策记录”，让未参与者能复述因果逻辑、判断更新是否到位。判断复盘是否有效，不看文档长度，看行动项是否改变了规则或信息流、复发率是否下降。 --- ## 概念解释 ### 什么是“能改变规则的复盘” 大多数复盘止于“总结经验教训”——它产出一句话“下次注意”，但不改变任何规则、信息流或结构。能改变规则的复盘至少产出一项**可验证的系统层更新**（改信息流、激励或结构），使同</description>
<pubDate>Wed, 26 Aug 2026 12:08:26 +0800</pubDate>
</item>
<item>
<title>04 单环、双环与系统学习：更新哪一层</title>
<link>https://bytedepth.cn/posts/single-double-loop-systems-learning</link>
<guid isPermaLink="true">https://bytedepth.cn/posts/single-double-loop-systems-learning</guid>
<description>&gt; **TL;DR**：Chris Argyris 区分了三种学习深度：单环学习只问“动作对不对”，双环学习追问“规则和目标对不对”，系统学习改变信息流、激励和结构。大多数复盘停在单环——改动作不改规则。有效复盘必须有意识地追问“能不能改更深一层”，因为只调动作不改变系统条件，同类问题会反复出现。 --- ## 概念解释 ### 三种学习深度的定义 Chris Argyris 在《Double Loop Learning in Organizations》（HBR, 1977）中提出： - **单环学习**：行动结果与预期不符 → 调整动作/参数 → 不质疑规则和目标。类比：恒温器检测到温度偏</description>
<pubDate>Wed, 26 Aug 2026 12:08:14 +0800</pubDate>
</item>
<item>
<title>03 AAR 与迭代回顾：简洁高效的行动后学习</title>
<link>https://bytedepth.cn/posts/aar-iteration-retrospective</link>
<guid isPermaLink="true">https://bytedepth.cn/posts/aar-iteration-retrospective</guid>
<description>&gt; **TL;DR**：AAR（After Action Review）是美国陆军发展的行动后学习方法，只用四个问题就能产出可复用的学习。迭代回顾是 AAR 在敏捷中的变体。两者都不追求完整 PDSA 的严谨，而是以极低成本在每次行动后快速提取“预期 vs 实际”的差距。核心纪律：写下来而非只在脑子里过一遍——**不落纸的学习等于没学**。 --- ## 概念解释 ### AAR 的由来与定义 **AAR**（After Action Review）由美国陆军在 1970 年代发展，后被企业管理领域广泛借鉴。它的设计原则是：**任何行动结束后，无论成功失败，都立即进行结构化回顾**。AAR 的</description>
<pubDate>Wed, 26 Aug 2026 12:08:03 +0800</pubDate>
</item>
<item>
<title>02 PDSA 循环：从预测到研究的知识生成</title>
<link>https://bytedepth.cn/posts/pdsa-cycle-knowledge-generation</link>
<guid isPermaLink="true">https://bytedepth.cn/posts/pdsa-cycle-knowledge-generation</guid>
<description>&gt; **TL;DR**：PDSA（Plan-Do-Study-Act）是 W. Edwards Deming 提出的持续改进循环，核心不在 P 和 D，而在 **Study**——Deming 强调“研究”而非“检查成败”。PDSA 的独特价值是：每次行动前先写下预测，行动后对比预测与实际，从差距中提取知识。它不是“做了再看”，而是“预测了再做，研究了再学”。 --- ## 概念解释 ### PDSA 的由来与定义 **PDSA** 由 W. Edwards Deming 在其质量管理理论中提出，是 PDCA（Plan-Do-Check-Act）的演进版。Deming 在晚年将 Check 改</description>
<pubDate>Wed, 26 Aug 2026 12:07:51 +0800</pubDate>
</item>
<item>
<title>01 无责复盘：从时间线到系统防线</title>
<link>https://bytedepth.cn/posts/blameless-postmortem-system-defenses</link>
<guid isPermaLink="true">https://bytedepth.cn/posts/blameless-postmortem-system-defenses</guid>
<description>&gt; **TL;DR**：无责复盘（Blameless Postmortem）是 Google SRE 推广的事后分析方法，核心原则是**归因到系统条件而非个人**。复盘回答“当时什么系统条件让这个行为合理且危险”，而非“谁做错了”。有效流程：时间线（事实与解释分离）→ 促成条件分析 → 系统防线缺口 → 可验证行动项。产出不是“加强培训”，而是改变信息流、工具和默认路径。 --- ## 概念解释 ### 无责复盘的由来与定义 **无责复盘**（Blameless Postmortem）由 Google SRE 团队在《SRE Book》中系统阐述。它的核心主张：**把事故归因于系统条件（流程、</description>
<pubDate>Wed, 26 Aug 2026 12:07:39 +0800</pubDate>
</item>
<item>
<title>00 复盘与学习总览：从行动结果到能力更新</title>
<link>https://bytedepth.cn/posts/retrospective-learning-overview</link>
<guid isPermaLink="true">https://bytedepth.cn/posts/retrospective-learning-overview</guid>
<description>&gt; **TL;DR**：复盘不是“总结经验教训”，而是**把行动结果转化为可被检查、可被更新、可被他人复用的能力**。系统思维建模、因果与证据验证、决策与权衡选择之后，复盘与学习负责回答：结果说了什么、需要更新哪一层（动作/规则/目标/系统）、以及怎么让下次不同。关键区分：复盘产出的不是结论，而是**可审阅的更新记录**——当时相信什么、实际发生什么、该更新哪条规则。 --- ## 概念解释 ### 复盘与学习 **复盘**原指棋局的“复局”——对弈结束后重新摆棋，分析每一步的得失。在工程实践中，复盘是行动结束后系统性地回顾“预期 vs 实际”的差距，并据此更新模型、规则或系统能力。 **学习</description>
<pubDate>Wed, 26 Aug 2026 12:07:27 +0800</pubDate>
</item>
<item>
<title>附录：ADR 模板与示例</title>
<link>https://bytedepth.cn/posts/adr-template-and-example</link>
<guid isPermaLink="true">https://bytedepth.cn/posts/adr-template-and-example</guid>
<description>&gt; **TL;DR**：本篇提供 ADR（架构决策记录）的空白模板与一个公认写得好的完整示例。模板遵循 Michael Nygard 的原始四要素结构，示例改编自业界广泛参考的微服务缓存决策案例。直接复制模板使用，对照示例检查完整度——**一篇合格的 ADR 不在于篇幅，而在于假设可证伪、后果含负向、放弃了什么被写明**。 --- ## 概念解释 ### ADR 模板的来源 Michael Nygard 在 2011 年的文章《Documenting Architecture Decisions》中提出的格式极其简洁：Context（上下文）、Decision（决策）、Consequences</description>
<pubDate>Tue, 25 Aug 2026 11:08:44 +0800</pubDate>
</item>
<item>
<title>决策与权衡综合实践：做一次可复盘的技术选型</title>
<link>https://bytedepth.cn/posts/decision-tradeoffs-software-engineering</link>
<guid isPermaLink="true">https://bytedepth.cn/posts/decision-tradeoffs-software-engineering</guid>
<description>&gt; **TL;DR**：本篇用一个完整案例串起全专栏方法——为消息队列选型做一次可复盘的技术选型。流程是：判断门类型 → 列选项与维度 → 决策矩阵权衡 → Premortem 识别风险 → 写 ADR 记录假设与退出条件 → 预设回退路径。最终产出是一页“技术选型决策记录”，让选型过程可被审阅、假设可被证伪、回退可被执行。判断选型是否合格，不看上线后是否“没问题”，看证据链是否闭合、退出条件是否预设。 --- ## 概念解释 ### 技术选型作为决策问题 技术选型（如选消息队列、数据库、框架）是软件工程最高频的决策类型。它的难点不在“哪个技术更好”，而在“在当前团队、业务约束、未来不确定性下</description>
<pubDate>Tue, 25 Aug 2026 10:47:27 +0800</pubDate>
</item>
<item>
<title>Premortem与预承诺：在行动前发现失败路径</title>
<link>https://bytedepth.cn/posts/premortem-precommitment</link>
<guid isPermaLink="true">https://bytedepth.cn/posts/premortem-precommitment</guid>
<description>&gt; **TL;DR**：Premortem（事前验尸）在决策执行前，假设“这个决策一年后失败了”，然后倒推失败原因。它把事后复盘的反思能力前置到还有机会调整的时刻。预承诺是配套机制：基于 Premortem 识别的风险，预先承诺“若出现 X 就做 Y”，避免事发后临时决策。两者配合，把单向门决策的失败成本从“事后救火”前移到“事前预防”。 --- ## 概念解释 ### Premortem 的由来与原理 **Premortem**（事前验尸）由心理学家 Gary Klein 于 2007 年在《Harvard Business Review》提出。它与传统的 postmortem（事后复盘）相</description>
<pubDate>Tue, 25 Aug 2026 10:47:11 +0800</pubDate>
</item>
<item>
<title>可逆性与双向门：降低决策的不可逆成本</title>
<link>https://bytedepth.cn/posts/reversibility-two-way-door</link>
<guid isPermaLink="true">https://bytedepth.cn/posts/reversibility-two-way-door</guid>
<description>&gt; **TL;DR**：不是所有决策都值得同等慎重。Bezos 的门框架把决策分为双向门（可逆，快做）和单向门（不可逆，慎做），让分析投入匹配风险。关键认知：可逆性是**连续谱而非二元**——很多决策表面可回退却带隐性不可逆成本（数据已迁移、承诺已被依赖）。判断门类型的方法不是问“能不能撤销”，而是问“撤销的代价是否超过重做”。 --- ## 概念解释 ### 双向门与单向门 这两个概念由亚马逊创始人 Jeff Bezos 在 2016 年致股东信《2016 Letter to Shareholders》中明确提出。他用“门”比喻决策的不可逆性： - **双向门**（two-way door）</description>
<pubDate>Tue, 25 Aug 2026 10:46:55 +0800</pubDate>
</item>
<item>
<title>决策矩阵与权衡：在多目标下显式取舍</title>
<link>https://bytedepth.cn/posts/decision-matrix-trade-offs</link>
<guid isPermaLink="true">https://bytedepth.cn/posts/decision-matrix-trade-offs</guid>
<description>&gt; **TL;DR**：决策矩阵把“凭直觉选”变成“显式权衡”——列出选项与评估维度，为每个交叉点打分或标注，让“为什么选 A 不选 B”成为可检查的推理。它的价值不在精确分数，而在**暴露权重假设**：当两个方案总分接近时，翻看哪个维度的权重决定了结果，就能发现你真正在权衡什么。矩阵不替你做决定，它让你的取舍可被审阅、可被质疑、可被修正。 --- ## 概念解释 ### 决策矩阵是什么 **决策矩阵**（Decision Matrix，又称 Pugh 矩阵或加权评分矩阵）是一种多准则决策工具：把候选方案作为行、评估维度作为列，为每个交叉点打分，再按维度权重加权求和，得出每个方案的总分。它最早</description>
<pubDate>Tue, 25 Aug 2026 10:46:40 +0800</pubDate>
</item>
<item>
<title>决策记录ADR：让技术决策可追溯可演进</title>
<link>https://bytedepth.cn/posts/adr-architecture-decision-records</link>
<guid isPermaLink="true">https://bytedepth.cn/posts/adr-architecture-decision-records</guid>
<description>&gt; **TL;DR**：架构决策记录（ADR）是一份轻量文档，记录“做了什么决策、为什么、基于什么假设、放弃了什么”。它不是设计文档，而是决策的留痕——让半年后没人记得“为什么选了 A”时仍能回溯推理。ADR 的关键属性是可演进：新决策可取代旧决策，形成决策树而非孤立文件。一份合格的 ADR 必须包含上下文、决策、后果与假设，且**假设是可证伪的**——若假设不成立，决策应被推翻。 --- ## 概念解释 ### ADR 的由来与定义 **架构决策记录**（Architecture Decision Record，ADR）由 Michael Nygard 在 2011 年的文章《Documen</description>
<pubDate>Tue, 25 Aug 2026 10:46:24 +0800</pubDate>
</item>
<item>
<title>决策与权衡总览：从选项到可审阅的承诺</title>
<link>https://bytedepth.cn/posts/decision-tradeoffs-overview</link>
<guid isPermaLink="true">https://bytedepth.cn/posts/decision-tradeoffs-overview</guid>
<description>&gt; **TL;DR**：决策不是“选最好的方案”，而是**在多目标、不确定性和约束下，做出可被审阅、可回退、可演进的承诺**。系统思维建模、因果与证据验证之后，决策与权衡负责把分析转化为选择。关键区分：可逆决策快做、不可逆决策慎做；决策质量不等于结果好坏——**过程可审阅、假设可回溯、退出条件预设，才是一个工程决策的交付物**。 --- ## 概念解释 在进入正文前，先讲清本专栏用到的核心概念——它们常被混用，但各自指向不同的认知任务。 ### 决策与权衡 **决策**是把多个可能行动收敛为一个承诺的认知动作。它由三层组成：选项（有哪些可能）、判断（哪个更优）、承诺（选定并执行）。**权衡**</description>
<pubDate>Tue, 25 Aug 2026 10:46:09 +0800</pubDate>
</item>
<item>
<title>软件工程综合实践：验证一次改进是否有效</title>
<link>https://bytedepth.cn/posts/causal-evidence-software-engineering</link>
<guid isPermaLink="true">https://bytedepth.cn/posts/causal-evidence-software-engineering</guid>
<description>&gt; **TL;DR**：本篇用一个完整案例串起全专栏方法——引入编程 Agent 后，交付周期是否真的缩短、质量是否守住。流程是：5W2H 与时间线固化事实 → 系统模型定位瓶颈 → 因果图显化混杂与中介 → 列竞争性解释 → 灰度/消融实验检验 → 指标护栏与 PDSA 复盘。最终产出是一页可照着执行的“证据化改进记录”，而非泛泛案例故事。判断改进是否有效，不看文档长度，看证据链是否闭合、护栏是否守住、模型是否被更新。 ## 目录 | 章节 | 说明 | |------|------| | [案例与系统边界](#案例与系统边界) | 引入 Agent 想缩短交付周期 | | [串起全流程](</description>
<pubDate>Mon, 24 Aug 2026 14:31:40 +0800</pubDate>
</item>
<item>
<title>指标与决策复盘：避免 Goodhart 式自欺</title>
<link>https://bytedepth.cn/posts/metrics-decision-review-goodhart</link>
<guid isPermaLink="true">https://bytedepth.cn/posts/metrics-decision-review-goodhart</guid>
<description>&gt; **TL;DR**：指标不是被动的仪表，它会改变行为——一旦某指标成为考核或决策依据，团队就会优化这个数字而非真实结果，这就是 Goodhart 定律的工程含义。应对不是“堆更多指标”，而是分清目标、结果指标、领先指标、代理指标与护栏指标，让指标组合**暴露权衡与副作用**而非彼此粉饰。决策复盘则回答：当时相信什么、基于什么证据、预测什么、实际发生什么、该更新哪条规则——把“成功”从结果倒推改为过程校准。 ## 目录 | 章节 | 说明 | |------|------| | [指标为何改变行为](#指标为何改变行为) | 度量即干预 | | [Goodhart 定律的工程含义](#Goo</description>
<pubDate>Mon, 24 Aug 2026 14:31:28 +0800</pubDate>
</item>
<item>
<title>实验设计：AB 测试、灰度与消融实验</title>
<link>https://bytedepth.cn/posts/experiment-design-ablation</link>
<guid isPermaLink="true">https://bytedepth.cn/posts/experiment-design-ablation</guid>
<description>&gt; **TL;DR**：实验是把“X 是否导致 Y”从观察转为干预检验的最强工具。A/B 测试随机分组、因果强度最高；灰度发布按比例放量、兼顾安全与验证；消融实验回答“移除某组件后结果是否改变”；前后对比最弱，易被时间趋势污染。四种设计支持的因果主张强度不同，不能混用其结论。消融逐项移除并不总能代表组件真实贡献——组件之间存在交互效应时，单独移除与组合移除的结果会矛盾。 ![experiment design comparison](/images/86cf0111b4bf489dacde5144c9a13954.svg &quot;width=650&quot;) ## 目录 | 章节 | 说明 | |----</description>
<pubDate>Mon, 24 Aug 2026 14:31:17 +0800</pubDate>
</item>
<item>
<title>因果图与混杂：为什么控制更多变量也会出错</title>
<link>https://bytedepth.cn/posts/causal-graphs-confounding</link>
<guid isPermaLink="true">https://bytedepth.cn/posts/causal-graphs-confounding</guid>
<description>&gt; **TL;DR**：因果图（DAG）用箭头表达“我们假设谁导致谁”，帮我们判断该控制什么、不该控制什么。直觉认为“控制越多变量越严谨”，但因果图显示三种变量要分开处理：**混杂因素**必须控制，**中介变量**通常不该控制（会切断机制），**碰撞器**一旦控制反而引入虚假关联。判断“AI 辅助编码是否缩短交付周期”时，工作复杂度、团队成熟度是混杂，代码生成速度是中介，把这两类混为一谈就会得到错误结论。 ![dag confounder mediator collider](/images/34b1eb970e4d4bde9e013e1e350ba4f4.svg &quot;width=650&quot;) #</description>
<pubDate>Mon, 24 Aug 2026 14:31:06 +0800</pubDate>
</item>
<item>
<title>根因分析：从时间线到因果证据闭环</title>
<link>https://bytedepth.cn/posts/root-cause-evidence-closure</link>
<guid isPermaLink="true">https://bytedepth.cn/posts/root-cause-evidence-closure</guid>
<description>&gt; **TL;DR**：根因分析（RCA）的难点不是“找到原因”，而是判断一个原因主张**证据是否闭合**。[因果分析与根因分析](/posts/211) 给出了从时间线到证据表的六步流程；本篇深化“证据标准与适用边界”——人的失误是调查起点而非结论，5 Whys 和鱼骨图只生成假设，故障树处理 AND/OR 组合，FMEA 是前瞻工具而非事后证明。一条因果路径只有同时具备机制、时序和区分性证据，才应进入“已闭合”集合。 ## 目录 | 章节 | 说明 | |------|------| | [与既有 RCA 笔记的分工](#与既有%20RCA%20笔记的分工) | 流程在 06，证据标准在本</description>
<pubDate>Mon, 24 Aug 2026 14:30:55 +0800</pubDate>
</item>
<item>
<title>因果与证据总览：从主张到可验证决策</title>
<link>https://bytedepth.cn/posts/causal-evidence-overview</link>
<guid isPermaLink="true">https://bytedepth.cn/posts/causal-evidence-overview</guid>
<description>&gt; **TL;DR**：把“我认为 X 导致 Y”变成可被审阅、验证和更新的决策依据，先分清**相关、因果、机制、反事实与证据强度**五件事，再走一条统一工作流：问题与结果变量 → 因果假设 → 竞争性解释 → 证据与设计 → 干预 → 复查与更新。系统思维提出结构假设，因果与证据负责检验关键关系——**漂亮的关系图或回归结果本身不是因果证明**。 ![causal evidence workflow](/images/2835547e14944ec0a357adae85de3444.svg &quot;width=650&quot;) ## 目录 | 章节 | 说明 | |------|------| | [这</description>
<pubDate>Mon, 24 Aug 2026 14:30:44 +0800</pubDate>
</item>
<item>
<title>如何选择方法：按情境与卡点匹配工具</title>
<link>https://bytedepth.cn/posts/how-to-choose-methods</link>
<guid isPermaLink="true">https://bytedepth.cn/posts/how-to-choose-methods</guid>
<description>&gt; **TL;DR**：方法选择遵循两步——**先判断面对的是什么情境，再定位当前缺少哪一种认知产出**。没有脱离情境的“最佳方法”：稳定流程适合标准化，复杂情境适合探索性实验。覆盖多阶段的端到端框架（A3、PDSA、OODA 等）不能因为都叫“循环”就互换。本篇承接 [思维方法全景地图](/posts/216) 的七阶段闭环，回答“卡在某一阶段时该用哪个工具”；工具本身的清单见 [认知透镜与思维工具索引](/posts/215)。 ![framework coverage matrix](/images/7cd84534e3ea4317aa255130a27abbbe.svg &quot;width=</description>
<pubDate>Mon, 24 Aug 2026 14:30:32 +0800</pubDate>
</item>
</channel>
</rss>