T L;DR

我们的大脑拥有两种不同的思考模式，这两种模式并不是大脑中的两个物理区域，而是从模式上进行的区分，作者称之为系统 1 和系统 2：

1. 系统 1 快速、直觉，擅长处理日常琐事，但容易受到偏见影响；
2. 系统 2 缓慢、理性，能够帮助我们做出深思熟虑的决策，但它的运行消耗大量的认知资源。

因为资源有限导致系统 2 的懒惰，因此我们需要合理分配认知资源，减少系统 2 的无效消耗，并通过习惯养成、环境布置和采纳外部建议，帮助自己在关键时刻做出更清晰、更理性的判断。

《思考，快与慢》这本书我看了很多次，但都没有看完，最初看了大概之后了解了系统 1 和系统 2，但一直不明白这有什么用。后来 AI 爆发，出现了基础模型以及推理模型，然后忽然明白，这不就是系统 1 和系统 2 么。于是又拿起这本书重新拜读起来，这次总算读完了。

系统 1 和系统 2 实际上从底层解释了我们如何思考、如何做决策，从早晨穿哪件衣服，到职业生涯中的关键选择，都离不开这两个系统。大多数人认为自己是理性的、善于分析的，然而事实上，我们日常的很多选择都是系统 1 无意识驱动的结果。

有一次晚上跟朋友玩德州，因为已经很晚了，我的系统 2 已经罢工。当时牌面看起来像顺子，我的牌也确实有可能组成顺子，结果最后一张牌开出来都没有成顺子 。但从对方的行为已经可以断定他手里有顺子，于是我就直接弃牌了。对方果然是顺子，然而弃牌后我发现，我虽然是没能成顺子，但我是同花啊。如果当时系统 2 还能正常运行一下，可能就不会错失这一手了。

认为我的牌可以组成顺子这个想法一开始就占据了思维，从忘记了其实还可以组成同花的想法，其实就是由认知偏误导致的。认知偏误又是有系统 1 导致的。系统 1 的判断虽然快速，但它经常会出错，尤其是在环境复杂或自己精力不济的时候。而系统 2，虽然可以纠正错误、做出更理性的判断，但它非常「懒」，更容易在我们精疲力尽时自动下线。

正是这种认知的盲区导致了决策失误，让我们可能在错误的事情上消耗了太多的认知资源，或者因为信息过载而错失了真正重要的机会。更糟糕的是，当环境变得复杂、压力变大时，我们的情绪、记忆和外界环境会进一步干扰理性决策。因此，理解这两套认知系统的运作方式，不仅能够帮助我们清晰地认识到自身思维的局限性，更能掌握具体的方法去优化和改善决策流程。

系统 1 和系统 2

• 系统 1：速度快、能耗低、依赖模式匹配和直觉，适合快速决策，但容易受到偏见影响，无法进行深度推理。
• 系统 2：速度慢、消耗大量注意力，擅长复杂推理和分析，可以处理新情况，但运行成本高。

系统 1 主要处理快速反应和熟练任务，例如： 走路、开车、识别人脸、阅读简单文字、做基本的加减法、躲避障碍物。系统 2 主要处理深度思考和新问题，例如： 逻辑推理、复杂数学计算、权衡利弊、长期规划、学习新知识。现实中，两者并不是独立运行，而是相互协作的。系统1 负责日常自动化操作，而系统2 在需要更高精度决策时介入。

既然系统 1 速度快并且几乎不消耗能量，那么自然把经常做的事情交给系统 1 就是最好的选择。这自然也是需要付出成本的：

1. 训练系统 1 需要的花费大量的精力；
2. 系统 1 虽然速度快，但是无法进行复杂的推理；

训练系统 1：学习

当你对执行一个任务越来越熟练时，需要付出的努力程度就会降低。对大脑的各项研究证明，与行动相关的活动模式会随着熟练程度的加强而变化，一些大脑区域将不再参与其中。

训练系统 1 的过程实际上就是我们所说的学习。人类学习一项新知识的过程，本质上是大脑内神经元之间建立新连接的过程。我们的大脑由数十亿个神经元（Neuron）组成，每个神经元之间的连接部位被称为突触（Synapse）。神经元通过它的轴突（Axon）向其他神经元传递电信号（动作电位）。当我们学习某项技能时，相关的神经元之间会通过突触建立更强、更有效的连接。¹在我们真正的学会之前，我们需要用系统2 主动思考才能完成任务，但经过足够的练习，这些任务逐渐被系统 1 自动化处理，因为神经通路已经被高度优化了。

这并不是一个简单的过程，马尔科姆·格拉德威尔在 2008 年出版的畅销书《异类》中提出了 10,000 小时法则 。格拉德威尔引用 K·安德斯·埃里克森的研究解释说，在任何领域达到世界一流水平的关键在于练习一项特定的任务至少 10,000 小时 。虽然有研究指出 10,000 小时并不严谨，但从新手到大师不可避免的需要大量的训练。

系统 1 的学习过程其实可以类比为一种贝叶斯推断（Bayesian Inference）。在统计学中，贝叶斯推理是一种通过不断更新「先验知识」来调整对世界的认知的方法。而我们的系统 1，就是一个不自觉地在做贝叶斯更新的机器。每一次你做出一次判断、解决一次问题，系统 1 都会根据已有经验（先验概率） 和 新观察到的信息（似然性） 来调整自己的判断机制。这也是为什么我们训练得越多、经验越丰富，直觉就越准确 —— 因为系统 1 的「先验」变得更加贴近现实。

另外，随着年龄的增长，我们的「学习速度」也会下降，我们的学习速度实际上受到「神经可塑性」的影响。神经可塑性（Neuroplasticity）是大脑通过生长和重组来改变神经网络的能力 。这种变化包括形成新的神经元连接、皮质重映射等 。但随着年龄增长，这种神经可塑性会逐渐降低，因此成年人学习新技能时所需要的时间和精力要比儿童时期更多。²好消息是有研究表明，有规律的有氧运动可以改善大脑的神经可塑性。

我们不可能无限制地将所有技能和知识都训练成系统1的自动反应。另外，即便是系统 1 擅长的事情，我们也不能过分依赖于系统 1，因为系统 1 还存在另外一个问题，那就是「认知偏误」。

系统 1 的运行：启发法

我们前面提到，神经突触连接的强化为系统 1 的高效决策提供了「硬件基础」。但现实世界情况复杂多变，仅靠固定的神经模式显然不足以应对。系统 1 还需要另一种更灵活、更快速的「软件」，这就是启发法（Heuristic）。

人们依赖于数量有限的启发式原则，而这些原则能将测量概率以及预测价值的任务简化，使其成为更为简单的判断过程。

心理学家认为，启发法本质上是一种心理捷径（mental shortcut），可以在有限的时间和信息条件下快速做出决策。正如维基百科所定义：

启发法解释了在知识有限（资讯不完整）和时间有限的情况下，得出可能陈述或可行解决方案的艺术。 它描述了一种分析程序，在该程序中，在对系统了解有限的情况下，在推定结论的帮助下做出有关系统的陈述。 由此得出的结论往往偏离最优解。启发法的品质可以透过将其与最佳解决方案进行比较来确定。

换句话说，启发法牺牲了精确度和全面性，换来了决策的速度和认知资源的节省。作者在书中提到了几种常见的启发法：

• 代表性启发（Representativeness Heuristic）
  当我们遇到一个新的事物 B 时，会下意识地将它与自己熟悉的事物 A 进行比较。如果发现两者十分相似，就认为它们有相同的特征，进而直接将对 A 的经验或知识套用到 B 上面。例如，我们看到一位穿白大褂的人会本能地觉得他可能是医生，而实际上可能不是。
• 可得性启发（Availability Heuristic）
  如果某件事或信息更容易从大脑中调取出来，我们就会倾向于认为这件事更常见或者概率更高。比如新闻经常报道飞机失事的消息，因此很多人觉得坐飞机比开车更危险，而实际统计数据则完全相反。
• 锚定启发（Anchoring Heuristic）
  在做决策时，我们倾向于受到最初信息（锚点）的强烈影响。例如，商品标价为 1000 元然后折扣到 500 元，顾客通常觉得非常划算，哪怕这件商品实际价值可能远低于500元。
• 立体启发法（What You See Is All There Is, WYSIATI）
  人们做判断时，只会基于目前看到的信息作出决策，而不会主动去考虑还缺少哪些信息。也就是说，你看到的，就构成了你的全部判断依据。系统 1 不会主动怀疑信息的来源，也不会提醒你“还有什么是我没看到的”。
• 情绪启发（Affect Heuristic）
  我们会用“好感”来快速决定一件事是好是坏，而不是去分析利弊。例如，如果你本能地喜欢某个人，可能会觉得他做事也更靠谱。这种启发可以让我们迅速下判断，但也可能让我们被情绪带节奏。

启发法的存在使得系统 1 能够极大地节省认知资源，快速做出决策。但这种快捷方式必然要付出代价——牺牲精确度，增加了我们在决策过程中产生认知偏误的可能性。

监督系统 1：系统 2

要避免系统 1 的偏见我们需要有意识地调用系统 2 来监督系统 1 的输出，以降低决策错误的风险。系统 2 负责检查系统 1 的直觉判断是否合理。

系统 2 的一大主要功能是监督和控制思想活动以及由系统1引导的各种行为，使得一些想法直接体现在行动上，或者抑制或改变其他想法。

举个实际的例子：在股票市场交易中，有一种投资策略叫做 Buy the dip（逢低买入），也就是说当股票价格下跌时买入优质股票。系统 1 在经过长期训练后，可能一看到股票下跌就产生了直觉性的买入信号，因为在过去这种策略曾经奏效过。然而，系统 1 只基于历史经验进行简单的模式匹配，并不考虑当前市场环境与以往的不同之处，比如市场中存在的系统性风险。

这时，系统 2 应该主动介入：

• 为什么这支股票在下跌？
• 现在是否存在系统性风险，比如宏观经济是否有重大变化？
• 公司基本面或技术面是否已经发生了改变？

只有经过系统 2 的严格分析，确认当前的情况确实符合逢低买入的条件，才可以避免因为系统 1 的偏误而造成损失。然而，系统 2 本身也有明显的局限性，最大的局限就在于：

• 系统 2 的运行成本非常高：系统 2 需要进行大量的信息搜集（财报、经济数据、政策环境等），并逐个进行理性分析。这不仅花费大量的时间，也会消耗极高的注意力（认知资源）。这自然不是系统 2 的问题，而是深入思考时我们需要大量的信息来辅助决策。
• 系统 2 对认知资源的依赖，使它无法持续长时间高效运行，这就决定了我们无法对所有的决策都进行系统 2 的深度分析。

懒惰的系统 2

物理学中的最小作用量原理（Principle of Least Action）说的是光或物体总是沿着使作用量最小的路径前进，除非有额外的力作用在其上。同样，我们的思维也倾向于选择最省能量的路径，即系统 1 的直觉和启发式，而不是调用系统 2 进行深度思考。当认知资源不足时系统 2 甚至会直接认同系统 1 的结论。

系统 1是冲动、凭直觉的；而系统 2 则具备推理能力，它很谨慎，但对一些人而言，这个系统也是懒惰的。

系统 2 之所以「懒惰」，其实并不是缺陷，而是一种适应性的优势。人类早期所面对的环境是稳定的、重复的，很多决策场景都可以靠快速直觉（系统 1）来应对。大脑虽然只占身体 2% 的体重，却消耗了约 20% 的能量，而其中又以系统 2 的思考最为「烧脑」。为了节省能量来保障最基本的生存，系统 2 能不用就不用。

The metaphor of the cognitive miser assumes that the human mind is limited in time, knowledge, attention, and cognitive resources. Usually people do not think rationally or cautiously, but use cognitive shortcuts to make inferences and form judgments.²
认知吝啬者的隐喻假定人类的思维在时间、知识、注意力和认知资源方面是有限的。通常人们不会理性或谨慎地思考，而是使用认知捷径来进行推理和形成判断。

系统 2 的「烧脑」源于它运行过程中需要大量调动认知资源，并频繁占用工作记忆来进行深度思考。认知资源每天的总量是有限的，而工作记忆就像大脑的 CPU Cache —— 速度快，但容量极小。这两个条件的限制，是系统 2 无法被无限使用的根本原因。

认知资源

所谓认知资源（Cognitive Resources）是指人类在执行认知任务时所需的有限心理能量，包括注意力、工作记忆、自控力和思维能力。它决定了我们进行深度思考、抑制冲动和做出复杂决策的能力。

虽然系统 2 很懒惰，但是当然只要你愿意，你依然可以启动系统 2，但是要消耗一部分的认知资源来控制自己的思维。也就是你不仅要付出认知资源去思考问题，还要付出认知资源去控制自己的思维聚焦在需要解决的问题上。这种情况下人们在其他方面的思考就会降低。

在和朋友悠闲地散步时让他心算出“23×78”的结果，而且要立刻就算出来，这时他肯定会停下脚步来算。 对系统2有高需求的活动同样需要自我控制，而发挥自我控制力既有损耗又很枯燥。与认知负担不同，自我损耗至少会令人丧失一部分动力。在一项任务中控制自我后，在另一项任务中就感受不到自己在努力，但只要你真的想做，就一定能做到。

认知资源既像计算机内存（带宽有限），也像电池（能量有限）。在短时间内，它决定了我们能同时专注多少件事；在长时间内，它决定了我们一天能完成多少复杂任务。

刻意掌控意志和进行自我控制很辛苦。如果你必须强迫自己去做某件事，而此时这件事又面临一个新的挑战，你就会很不情愿或是根本无法进行自我控制。这种现象被命名为自我损耗（Ego Depletion）。 认知负担不是自我控制减弱的唯一因素。喝几杯酒，或者一夜没睡也会产生同样的结果。早起的人的自我控制力会在晚上受到影响，而夜猫子的自我控制能力则会在早晨受到影响。

心理学家米哈里·契克森米哈（Mihaly Csikszentmihalyi）提出过一种被称为「心流（Flow）」对状态。在这种状态下人们几乎不需要消耗自控力就可以专注在任务上，将所有的认知资源都应用在深度思考上。然后现实中大多时候我们很难进入心流，工作中经常需要与人沟通，或者被提及，经常需要在不同的工作流之间切换，这种切换便会打断原本的心流状态。

心流巧妙地区分了两种努力形式：对任务的关注和对注意力的严格控制。以每小时150英里的速度骑摩托车和在象棋大赛中角逐都需要付出努力，然而在心流状态下，集中注意力关注吸引人的事并不要求自我控制。因此，我们要将所有资源都用于手头上的任务才好。

工作记忆

工作记忆是一种记忆容量有限的认知系统，被用以暂时保存资讯。工作记忆对于推理以及指导决策和行为有重要影响。³

在 UX 设计中我们也经常提到「神奇的数字 7±2」理论，意思是说大多数人在一次只能保留大约 7 个（±2）信息块（chunks）在工作记忆中。例如，表单字段不超过 7 项；导航项尽量控制在 5–9 个之类。不过这一理论后来被 Nelson Cowan 修正，其实更准确的数字是 4±1 个 chunks。

所谓信息块，可以是一个数字、一个单词，也可以是一个概念组合，例如一个电话号码可以被「打包」成一个信息块。这种容量限制意味着，一旦任务信息过多或过于复杂，工作记忆就会迅速被占满。

系统 2 的运行高度依赖工作记忆。当我们在做需要深度思考的任务时，比如写一篇文章、做数学题、做战略决策，系统 2 必须同时在工作记忆中「暂存」多个信息片段，同时进行比对、运算或推演。然而，当任务过于复杂，或信息超出工作记忆容量时，大脑的运行就会「卡顿」，系统 2 也会更容易出错、犯懒或放弃。

压力对工作记忆的影响

当我们处于压力状态时，大脑会分泌压力激素，比如皮质醇和去甲肾上腺素。这些激素会直接作用于大脑的前额叶皮层 ——也就是系统 2 主要运作的区域。结果就是，我们的大脑在压力下变得更难集中注意力，工作记忆的容量也会下降。有研究表明，人在压力环境下，工作记忆容量会下降 30% 以上。尤其是在面对复杂、结构不清晰或无反馈的任务时，这种影响更加明显。

这也解释了为什么在压力大的时候，我们总是容易出现「脑子一片空白」、「不知道从哪里开始」的感觉。这种情况下，系统 2 很容易崩溃，放弃思考，将决策交还给系统 1，变得冲动、短视，甚至陷入情绪化反应。

影响系统 2 的因素

认知资源和工作记忆从根本上会影响系统 2 的运行，除此之外，还有很多其他因素也会影响系统 2 的结果输出。我们可以从内外因素来看，内部因素主要是：记忆自我、情绪以及由系统 1 产生的认知偏误的影响；而外部因素则主要是信息输入和环境因素。

两个自我

体验自我（Experiencing Self）指的是当下的感受，比如此刻你是否感觉愉快或不适；而记忆自我（Remembering Self） 则是对过去经历的总结评价，比如回忆过去的一次旅行时，你总体上是觉得愉快还是糟糕。由于体验自我依赖「当前感受」，它可能导致我们做出短视决策，而记忆自我由于遵循峰终定律（Peak-End Rule），则可能让我们高估或低估某些经历，从而影响系统 2 在长远规划中的判断。换句话说，即使系统 2 在运行，它的输入信息仍然可能受到体验自我和记忆自我的扭曲。

大脑在做决定时，更倾向于参考记忆自我的评价，而非体验自我的实时感受。因此，当人们回顾过去时，更容易被一次经历中最强烈的片段和结尾时的情绪所影响，而忽略整体经历。

这意味着，我们的决策并非始终基于真实而全面的信息，反而可能依赖记忆中那些经过加工、甚至扭曲的信息片段。

情绪的影响

情绪的状态对系统 2 的表现也有重要的影响。当我们处于强烈的情绪波动（如愤怒、焦虑或兴奋）时，系统 2 很难保持冷静、客观地分析问题。

情绪反应的迅速性往往会激活系统 1，并暂时抑制系统 2 的理性运转。即使你知道理智决策的重要性，过于强烈的情绪也会让你本能地优先考虑短期满足或快速缓解情绪。

偏见的影响

前面我们提到系统 1 的运行主要是依赖于启发法，启发法虽快，但是会产生各种认知偏误。这些偏见也会渗透到系统 2 的决策过程中。尽管我们通常相信自己的理性能够修正直觉上的错误，但事实并非如此简单。尤其是在认知资源或工作记忆不足的时候，系统 2 会拒绝工作，直接认同系统 1 的结果，那么同样也会认同系统 1 的偏见。

作者在书中提到的几个主要的偏见。

• 确认偏误
  确认偏误指的是人们倾向于寻找和记住那些支持自己观点的信息，而忽视甚至排斥与自身观点相冲突的信息。当系统 2 尝试理性分析某个问题时，这种偏误可能导致我们只关注那些“符合期待”的证据，忽略客观全面的信息，最终强化了原有的偏见。
• 锚定效应
  锚定效应指的是人们在做决策时，过度依赖最初接触到的信息（锚点），即使这个信息可能与最终决策毫无关系。系统 2 虽然擅长分析与计算，但也容易受到初始信息的误导。
• 框架效应
  框架效应描述的是同一信息在不同表达方式下，会导致人们做出不同的决策。系统 2 本应保持客观理性，但实际上，它很容易受到信息表述方式的干扰。
• 禀赋效应
  禀赋效应是指人们对于自己已经拥有的东西，会赋予更高的价值，而对未拥有的东西则估值更低。当系统 2 在评估资产、投资或交易时，这种心理倾向会导致决策的不理性。
• 层叠效应
  层叠效应指的是人们倾向于跟随他人的观点或行动，特别是当许多人表现出相同倾向时。这种效应可能导致系统 2 忽视独立的理性分析，而盲目追随多数。
• 启动效应
  启动效应指的是某些前期接触到的信息或刺激，会无意识地影响我们随后的行为或决策。尽管系统 2 可能没有明确察觉，但这些无意识的影响仍会改变其分析和判断的方向。
• 曝光效应
  曝光效应描述的是人们对熟悉的事物倾向于更积极的评价，仅仅是因为经常接触。这种偏好可能导致系统 2 过高估计熟悉选项的价值，忽略其他更优选项。
• 光环效应
  光环效应指的是人们会因为某一突出优点而整体高估一个人的其他特质。例如，因为一个人外貌出众，可能系统 2 会下意识地认为此人在其他方面同样优秀，而忽略了客观事实。
• 规划谬误
  规划谬误指的是人们倾向于过于乐观地估计任务完成所需的时间、资源或成本，而忽略历史经验或客观数据。要避免这种偏误，可以参考以往类似案例的数据，以获得更为准确的预测。

参考 List of cognitive biases，当中列出了更多的认知偏误。

信息输入

系统 2 的思考过程，简单可以理解为，收集信息、整理信息、然后分析并作出最终的决策。第一步所收集信息的质量和数量都会影响我们最终的分析决策。

但除了主动收集信息之外，我们每天都会被动接收大量信息，这使得系统 2 很难有效地分辨哪些是真正重要的，哪些是无用的噪音。更糟糕的是，大脑倾向于被即时满足感所吸引，例如刷手机和查看社交媒体上的信息流，这种即时满足感很容易转变成「信息成瘾」。

Passing a gas station, you see that prices are up, and within one second you’re thinking of your household budget, and other rising costs, then inflation, and politicians, and that person you know who voted for the bad politician instead of the good one, and so on.⁴
路过加油站时，你看到油价上涨，你会立刻想到家庭预算、其他不断上涨的成本、通货膨胀、政客，以及那个投票给坏政客的朋友，等等。

有研究表明接收新的信息也会促进多巴胺的产生⁵而产生信息成瘾性，我们在研究的过程中也可能会产生不断收集信息的冲动，担心自己会错过某些关键信息（FOMO 心态），FOMO 心态与信息成瘾会相互促进，是的有限的资源都被浪费在了收集过程中的对信息的处理。社交网络的成瘾性在于无限滚动设计与精确的算法，可以计算出用户最关心的东西，这东西与好奇心，好奇心会促进多巴胺的产生，于是让用户可以不停的继续刷新新的资讯。

你的思维关注什么，就会驱动你的行为。如果你每天都沉浸在社交媒体的争论中，你的现实世界也会充满焦虑和争吵；如果你每天都沉浸在创造性的思考中，你的生活会朝着更有生产力的方向发展。

系统 2 的认知资源是稀缺的，如果它被无关紧要的信息（如社交媒体上的政治争论）占据，就没有足够的能量处理更重要的决策。过载的信息摄入会让系统 1 过度活跃，我们会更加依赖启发法和情绪化决策，而不是系统 2 的深度思考。

环境影响

前面提到的框架效应反映的就是环境对我们决策的潜在影响。我们房间的布置、办公环境的布局，甚至日常用品的摆放方式，本质上都是默认的选项。这些看似简单的选项，实际上在潜移默化地引导和强化我们的行为。当一件事变得非常容易执行时，我们就更倾向于去做它。

外部环境对于我们的决策方式有着深远的影响。我们的大脑习惯于在熟悉的环境中采用固定的行为模式，这便是所谓的「习惯」。习惯形成的本质是环境提示（Cue）与随后的奖励（Reward）之间的反复联结，逐渐内化为自动化的系统 1 行为。

在外部环境没有明显变化的情况下，改变已固化的习惯非常困难，即使系统 2 理性地认识到了改变的必要性。

例如，如果你想要改变不健康的饮食习惯，仅凭借意志力和系统 2 的刻意决策往往收效甚微。更有效的策略是积极地改变外部环境，比如避免购买和储备零食，或是远离诱发不健康饮食的环境和场所，尽量减少习惯触发因素的存在。

优化决策系统

我们已经了解了影响系统 2 运作的种种因素。现在的问题是，如何在现实的约束下，尽可能提升我们的决策质量。前面我们提到过一些我们无法突破的限制：

• 时间有限： 一天永远只有 24 小时。
• 认知资源有限： 它像精力一样会被消耗，虽能恢复，但总量有限。过度使用会导致“决策疲劳”和判断力下降。
• 系统 1 的容量与学习成本： 培养可靠的直觉（训练系统 1）需要大量时间、经验和高质量的反馈，并非一蹴而就。
• 生理局限： 我们的学习能力和精力水平会随年龄和健康状态发生自然波动。

因此，优化决策并非追求“无限理性”，而是在这些限制条件下，进行聪明的资源管理，让宝贵的系统2发挥最大效用。

认知资源分配

把东西装进行李箱，是对资源管理问题的最好比喻。我们每个人都有一个时间箱，要在里面装上工作、休闲和与家人共度的时光。我们也都有一个金钱箱，要在里面装上住房、服饰和其他所有支出。资源的稀缺和富足，会改变我们装箱的方式。如果没有余闲存在，我们在装箱时就不得不进行权衡。可见，稀缺的本质就是没有余闲。⁶

当认知资源匮乏时（如同贫穷状态下对金钱的锱铢必较），我们的大脑会被眼前的“急事”或琐事占据，不断进行权衡，从而消耗大量带宽，无暇进行长远规划和深度思考。这会导致决策质量下降，甚至陷入恶性循环。

因此，优化决策的首要任务就是像管理稀缺资源一样管理我们的认知资源。

1. 保障与恢复认知资源
2. 在认知高峰期处理关键决策
3. 减少非必要决策数量
4. 保留认知冗余

保证认知资源充裕

• 充足的睡眠是最基础也是最重要的认知资源恢复方式。长期睡眠不足会严重损害系统2的运作能力，导致注意力不集中、冲动控制力下降。
• 规律作息与休息： 保持稳定的作息有助于调节生理节律。白天工作期间，短暂的休息（如番茄工作法的休息间隙）、冥想或正念练习，也能帮助恢复部分认知资源，缓解精神疲劳。
• 健康生活方式： 均衡饮食、适度运动也被证明对大脑健康和认知功能有积极影响。

在认知高峰期处理关键决策

大多数人的认知资源和注意力高峰都集中在早晨。识别并利用好自己的精力高峰期，安排复杂决策、重要规划或创造性任务，能最大程度地发挥系统 2 的优势。相反，应避免在疲劳、饥饿或情绪不稳定时做重要决定。

我给自己定的投资规则是：“晚上不做投资决策”。虽然美股是在晚上开盘，但我会在早上规划好策略，晚上只是严格执行计划。当行情发生意外波动时，也不会在情绪激动时贸然做出新的决定，以免受情绪驱使而做出非理性决策。

减少非必要决策数量

每个决策都有重要性之分，有些决策不算重要，例如工作日的午饭吃什么，有些则很重要，例如女友生日的晚餐吃什么。我们要做的是把认知资源留给真正重要的事情，而将那些不重要、重复性的决策自动化或惯性化。

例如，工作日我会固定自带午餐。这些午餐并不追求美味，仅仅满足基本的能量需求即可。相反，周末或特殊场合的饮食决策则精心挑选，系统 2 资源在这些关键时刻发挥更大作用。许多知名人物（如乔布斯或扎克伯格）选择固定着装，正是通过减少无谓决策数量，释放更多认知资源投入重要事务。

保留冗余

留出一定的认知冗余，能帮助我们更有效地应对意外情况或突发任务。相反，认知资源长期处于超负荷状态不仅降低决策质量，还会导致分析瘫痪。

适当的「留白」还能促使大脑在无意识中整合信息，系统 1 在此过程中可能产生意外的洞察力与创造力。如果大脑始终处于超载状态，这种宝贵的机会就会被扼杀掉。分析瘫痪，也会影响我们在应付突发情况时的反应能力。

优化工作记忆

我们通常会分几个简单的步骤来执行任务，以避免大脑超负荷运行。这样的话，我们可以将中间结果储存在长期记忆中或是记在纸上，而不是简单地堆积在工作记忆中。

优化工作记忆的关键策略之一就是将信息从大脑中释放出来，这被称为「信息外部化」（externalization）。例如，使用白板、便签、脑图工具等来梳理思路；将复杂问题拆解为可管理的小任务；记录中间结果，避免反复回想；

满意原则

在决策优化的过程中，我们常常会陷入一个误区，以为这个世界上存在一个所谓「最优解」。虽然有些简单问题确实有，但大多数的实际问题并没有所谓的最优解。即使在数学上的「最优化问题」也并不总是存在最优解，因为现实的信息不完全且经常模糊、计算资源和决策时间又十分有限。

诺贝尔经济学奖得主 Herbert Simon 提出的满意原则（Satisficing）：

现实中的人类不是「最优化者（Optimizer）」，而是「满意者（Satisficer）」——我们不会寻找最优解，而是找到一个「够好」的解。

正是《思考，快与慢》这本书的核心逻辑之一——大脑不是用来求解数学上的最优问题的，而是用来在有限时间和资源下，找到“足够好”的答案。

习惯养成

减少系统 2 决策负担的有效方法之一，是将重复性、不重要的决策交给系统 1 去自动化处理，这就是我们所说的「习惯养成」。

麻省理工学院的研究人员在每种习惯中发现了一种简单的神经逻辑回路，这种回路包含三部分：暗示、惯常行为和奖赏。⁸

真正驱动习惯回路运转的是对奖赏的渴望。当我们觉得一件事情有价值，但不想消耗系统 2 去执行的时候，就可以训练系统 1（开始的时候需要系统 2 强行介入），让它在未来自动完成这件事，减少自身负担。

过去几年我坚持每周至少健身 3 次。我会在日历上先 block 自己的时间，到点就去。最开始的时候可能会逃课，后来发现只要到了健身房，懒惰的想法就会降低，撸铁的动力就会增加一点。于是后面就是先让自己去健身房，去之前先说好，只做一组就行。我并没有遵守「提示（Cue）→ 惯常行为（Routine）→ 奖赏（Reward）」这样的路径，而是只有前两步「提示 → 行动」，并没有奖赏，完成训练后的那种「自律的成就感」也是一种奖赏吧。

前面我们也提到过框架效应以及环境对决策的影响，习惯养成最有效的方法就让环境来强化自己的行为。去掉那些会干扰自己的事物，让整个生活都围绕你想要的好习惯来设计。也许有人会说「这么活着不会很累吗？」，我觉得恰恰相反。虽然可能看似缺少一些生活中的小乐趣——比如每天吃同样的食物、做同样的运动、穿相同的衣服，但正如我们前面提到的，「稀缺」才是真正重要的。减少了每日的微小「乐趣」之后，之后的每一次大餐才会显得印象深刻，个人也会变得更容易满足。如果每天都充满了「刺激」，那么「刺激」本身就会变得平庸，人会变得更难满足，更难体验到生活中微不足道的乐趣。

习惯本身是中立的，好习惯可以被强化，坏习惯同样也是。习惯可以帮你坚持运动、早睡早起，它同样也会帮你建立起下班就点外卖、早起先刷短视频这样的“坏习惯”。所以，我们真正要做的，是利用系统 2 的清醒时刻，有意识地设计好自己的环境与习惯系统，让自己的未来尽可能少走弯路。

采纳外部建议

A remarkable aspect of your mental life is that you are rarely stumped … The normal state of your mind is that you have intuitive feelings and opinions about almost everything that comes your way. You like or dislike people long before you know much about them; you trust or distrust strangers without knowing why; you feel that an enterprise is bound to succeed without analyzing it.

内部视角是通过关注特定任务和手边的信息来考虑问题，并基于这组狭窄独特的输入（可能包含轶事证据和错误认知）进行预测。这是大多数人进行规划时的常用方法。

人们倾向于内部视角主要有几个原因：天性乐观、乐观主义错觉（认为自己的未来比他人更光明）以及控制错觉（认为自己能控制偶然事件）。此外，自我意识（Ego）也扮演了重要角色，人们倾向于认为自己与众不同且更优秀，因此相信「这次不一样」。有趣的是，人们在评估他人情况时，反而更擅长运用外部视角。

在与内部意见的竞争中，外部意见丝毫没有取胜的机会…偏向内部意见常带有道德的意味。

卡尼曼提出了一个有效的方法——参考类别法（Reference Class Forecasting）。不要只盯着自己独特的计划和能力，而是要查看同类型任务在现实中的平均结果。在做投资决策时，不仅考虑自己对市场的判断，还要参考市场历史上的平均收益与风险。

引入外部数据、他人经验、集体智慧，可以帮助我们矫正自身的认知偏见，尤其是系统 2 的过度自信与过度理性。

理性不等于正确

更进一步，我们还需要保持对系统 2 自身的警觉。很多人以为只要启动系统 2 就等于理性决策，实际上，系统 2 也有自己的缺陷。正如我们之前提到的斯坦诺维奇的观点：理性与智力并不等同。一个人在逻辑推理上能力很强，并不意味着他在现实生活中的决策就没有偏见和错误。系统 2 的过度自信、选择性接收信息、确认偏误，都可能让人陷入“自以为理性”的陷阱。

使用分析框架

上面提到的优化策略主要聚焦在「硬件」层面 —— 认知资源、工作记忆、自控力本身的限制。但在此基础上，我们还需要借助更好的「软件」——也就是分析框架，来提升系统 2 的决策质量。

分析框架指的是一套用来理解问题、拆解问题并制定应对策略的思维工具。比如： 结合跨学科的知识准备和通用的思维框架能显著提高决策能力。这些框架帮助从不同角度审视问题：

• 逆向思维 (Inversion): 从反面或目标倒推来思考问题。
• 二阶思维 (Second-Order Thinking): 考虑决策的后续影响，不断追问「然后呢？」。
• 地图并非疆域 (The Map Is Not the Territory): 认识到模型或地图只是现实的简化，并非现实本身。

更多决策模型和心理模型可以参考 fs 的这篇文章：Mental Models: The Best Way to Make Intelligent Decisions

———

无论是通过习惯养成减轻系统 2 的负担，还是通过外部建议与批判性思维提高系统 2 的决策质量，我们最终的目标都是一样的：让系统 2 的有限资源被用在真正重要的地方。

一个优秀的决策者，并不是永远理性的人，而是一个懂得什么时候自动化，什么时候反思的人。他知道如何借助系统 1 的力量，同时也知道如何校准系统 2 的判断，让两者协同发挥作用。

1. Cognitive Miser
2. What’s Taking Up Your Mental Bandwidth Right Now?
3. How information is like snacks, money, and drugs—to your brain
4. 稀缺
5. 习惯的力量
6. Working memory

过去 5 年，我们团队一直都在使用 Jira 来实践 Scrum。Jira 的难用是众所周知的，但作为产品经理我也理解为什么 Jira 这么难用。2B 尤其是面向大型企业客户的产品，最终形态都是像 Jira 或者 Salesforce 那样。体验极差，但是灵活性非常高，面对大型客户，每家公司都有自己的工作流，这种定制的工作流本来就不够 SaaS，所以为了满足这种需求，产品只能做到非常灵活，一个极端就是直接提供 API，让客户自己随便玩。但是并非所有人都有了编程经验，于是不会编程的用户便想要一些简单的规则引擎，规则引擎本身是一个非常复杂的任务；但规则引擎并不难解决所有问题，总会有一些高级用户会提出来为什么不增加这样或那样的规则，甚至为什么不直接增加一个可以运行代码的节点。灵活性不是一个简单的问题。不过这是另一个话题了。

但对于我们团队来说，我们不需要非常灵活的东西，他会让事情变得复杂，我们只需要简单的看板，可以统计 Velocity，可以无限嵌套子任务的工具。某次网上冲浪期间发现了 Linear，但一开始并没有直接使用，我的第一印象是“这不就是一个速度更快、更简单的 Jira 吗”，并不觉得有什么颠覆性的东西。一年之后我又无意间读到了 Linear Method，然后才开始入坑，也才慢慢理解了 Linear 背后设计意图。Shape Up 也是同理，只是 Basecamp 的理念可能过于先进，我到现在也没有完全吃透。

在使用 Linear 的同时，我们结合 Linear Method 和 Shape Up，对我们的开发流程进行了重塑，尝试解决我们在 Scrum 中遇到的问题。实践了快一年，并非所有的问题都得以解决，但我个人的感受是整体项目的交付速度提升至少有 20%。有必要总结一下我们这一年的经验。

在使用 Jira 和 Scrum 的时候，开发团队每 2 周进行一个 Sprint，每个 Sprint 的最后一天我们会做 Sprint Review 和 Retrospective 以及 Planning。Sprint Review 就是把团队的交付的内容和 Stakeholders 同步，通常我们会测试环境 Demo 即将上线的新功能。Demo 完成后 Stakeholders 会提出一些问题或者建议，随后是 Retro，主要是回顾团队协作的情况。紧跟着就是 Planning，产品经理讲述下个 Sprint 的项目。Planning 之后是 Grooming，开发团队对项目进行拆解，将每个项目拆分成开发任务并评估出故事点，评估完成后 Scrum Master 会根据团队过去的 Velocity 给出最终的交付物。

这里存在几个问题：

1. 故事点估算的交付周期几乎不起作用，很少会按时交付。
2. 所有人都显得很忙碌，工程师总是在写代码，修 bug，对于项目价值以及原因并不理解。
3. Sprint 不停的冲刺，团队很少能够审视过去做过的项目是否真的有价值。
4. Sprint 目标确定后，极少有空间去修复技术债务。
5. Sprint 开始的时候，往往技术方案还不是很确定，Sprint 冲刺的过程中存在着大量的不确定性。
6. 如果项目出现风险，导致无法在 Sprint 结束的时候上线，结果就是延期到下个 Sprint，完全不够敏捷。
7. 设计师应该在 Scrum 中的哪个阶段参与？如何参与？

过去，我们在 Scrum 的框架中打了很多补丁，效果并不理想，反而徒增了许多工作量。当时我们并没有意识到或许换一种工作流可能就可以很好的解决。其实也不用替换掉整个工作流，只需要少许改动就可以解决很多问题，这个改动就是在 Cycle¹ 之间引入了 Cooldown。我们参考 Basecamp 的 Shape Up 方法，并结合自身实践，将 Cycle 的长度设置为 3 周，在 Cycle 与 Cycle 之间增加 1 周的 Cooldown。

Cycle 中要做的事情与 Sprint 并没有太大的变化，主要是关注交付。我们保留了每天早上的站会，花 5–10 分钟来同步项目进展，主要目的是发现风险点。如果开发的过程中发现了新的不确定因素，团队成员会在站会上提出来，如果影响到项目的交付，我们会尝试调整项目的 Scope，或者安排更多的人力。风险确认之后，我们也会发布 Linear 的 Project Updates，内容会同步到 Stakeholders 所在的 Slack Channel，确保所有人都了解项目情况。

持续冲刺最大的问题就是很少去反思之前做过的项目，开发也没有时间去做性能优化，解决技术债，而这些问题在 Cooldown 中都有一定的缓解。在 Cooldown 中，我们主要关注以下事项：

1. 回顾上上个 Cycle 的结果：分析每个项目是否达成了预期的目标。
2. 制定下个 Cycle 的计划：结合之前项目的经验和数据，制定下个 Cycle 的计划。
3. 明确方案和拆分任务：确定下个 Cycle 的计划后，开发团队会进行技术调研，确定技术方案 ，然后根据方案拆分出开发任务。
4. 评估开发任务的故事点：开发会对每一个具体的开发任务给出相应的故事点，根据整个项目的故事点总数，我们可以预估下个 Cycle 的交付物。
5. 优化和修复：优化上个 Cycle 中出现的问题，或者修复 Bug，为下一个 Cycle 的顺利进行做准备。

整个 Cooldown 从周一到周五大概会这样安排大概是这个样子：

周一：开会的一天

周一大部分时间都在「开会」。主要在做的事情实际上就是回顾之前的项目，然后计划下个项目。

1. 回顾会议

回顾会议由产品经理来同步上上个 Cycle 交付的项目的数据。通常我们的项目分成两种：一种是功能交付；另一种是试验一些新的想法。前者通常关心的是用户使用情况；我们团队做的比较多的是后者，后者我们会将每个项目的结果分成 3 种：

1. 符合预期（Validated）：即项目结果达成了我们最初设定的指标，并总结原因。
2. 不符合预期（Invalidated）：即项目结果没有达成最初设定的指标，然后分析原因可能是什么。
3. 没有结论（Inconclusive）：这个比较复杂，虽然指标可能符合预期或者不符合，但因为有其他因素的干扰，导致无法判断是否是因为这个项目导致的结果。

同样，针对 3 种结果，也会有 3 种不同的行动项：

1. Validated：通常下一步行动是进一步优化，或者进行规模化。
2. Invalidated：则会进一步讨论是否需要继续，或者放弃。通常一个项目会对应一个目标，而达成目标的方式通常有很多种，每一个项目通常我们会选择其中一种来做尝试，如果这种方法被证实为无效，我们可以会继续评估是否这个目标还值得去做，如果值得，那么再考虑其他方式。而如果已经没有新的想法了，则暂时放弃。有些放弃的项目也会需求下线之前的项目，清理代码。
3. Inconclusive：与 Invalidated 的类似，不同的是当中有试验初期未被考虑的因素出现，这个因素对试验的结果产生了一定的影响。那么无论结果是符合预期还是不符合，都不能作为确定的事情，我们需要考虑这个新的因素后重新设计试验，然后重新评估项目是否还有机会成功，如果有，那么稍微调整下再继续观察。如果考虑到新的因素之后，原有的项目已经无法奏效，那么就像相当于是 Invalidated 了。

2. Planning 会议

Planning 主要是产品经理向团队介绍接下来一个 Cycle 的目标和方案。我个人很喜欢 Shape Up 中写 Pitch 的方法，不过对于并不是所有产品经理都能够写出合格的 Pitch，因此也暂时没有在团队内部推广。Planning 实际上会过 3 种项目：

1. 产品经理原本安排在下个 Cycle 要做的事情。
2. 回顾议会中，如果有提出新的想法，产品经理也可能会安排到下个 Cycle 中。
3. Linear Triage 中所有的项目：Cycle 的过程中如果有任何新的想法，通常都会先进入 Triage 中，每次 Planning 的时候我们都会一条一条的 Walkthrough，如果决定不做的就会直接 Cancel 掉，决定要做的就会尝试安排到下个 Cycle 中。如果 Cycle 没有空余的时间，则会 Snooze 推迟到下下个 Cycle 再讨论。

3. Retrospective 会议

这个是从 Scrum 中延续下来的会议，这个会议与项目无关，主要关注的是团队协作流程中的问题。通常会议上我们会收集团队成员的反馈，大家回顾项目进行中碰到的阻力，跨团队协作、文档、做事方式等等，把所有认为不合理的地方都记录下来。会议中我们会讨论这些问题，并且商讨出一个可行的解决方案写入下个 Cycle 的行动项目 。会议结束后，每个行动项目都会有一个 Owner 来追踪。实际上，我们现在的项目运作流程就是在这个会议中讨论出来的。

周二到周四：Shaping

这几天相当于 Shape Up 中的 Shaping 过程（虽然并不完全相同），Shaping 主要达成几个目标：

1. 目的是明确交付项目所需的具体内容，也就是 Definition of Done。
2. 明确投入的成本，也就是 Shape Up 中提到的 Appetite。在《RICE 框架》中有提到一种衡量 ROI 的方法，讲道理应该遵守这种规则来设定 Appetite。
3. 分析技术可行性，调研技术方案。
4. 然后拆分技术任务，并评估点数。

对于开发来说，Planning 的项目可以分成两种状态：

1. 我们知道怎么做，整个项目基本确定，需要用到的数据、服务、设计都是比较确定的。
2. 项目看起来具备可行性，但还没有具体的实施方案，其中又可以分成以下几种状态：
   1. 不知道用什么技术来实现；
   2. 知道用什么技术来实现，但对该技术不熟悉；
   3. 技术都比较了解，但是有外部依赖性，可能需要依赖外部团队。

对于 2.a 和 2.b，工程师首先会调研技术方案，技术方案调研完成的标准是用简单的脚本构建了原本的需求，其中的代码质量可能无法到达 Ready for Production 的水平，但是基本的流程跑通了，也大概知道有哪些坑以及要做什么事情。确定这些之后就可以对项目进行拆解。

2.c 产品经理和工程师也会找对应的团队去沟通，如果其他团队可以在 Cycle 内提供支持，那么首先要做的就是协商接口协议和大致的时间，然后各自按照协议进行开发。团队确定协议后也会先拆解项目。

也时候也会出现一种情况，就是到 Cooldown 结束的时候也没确定技术方案。这个时候有两个选择：

1. 暂停该项目，等待下个 Cycle 的时候再决定是否要继续，因为成本比较高。
2. 把技术调研本身作为一个任务放进 Cycle 中，这种情况下该项目通常不会作为交付目标，而是如果有空余时间才会去做。

把技术调研放进 Cycle 的另外一个问题是 Story Point 无法确定。我们之前有出现过整个 Cycle 都是在做调研，尝试过很多方案，最终还是没有找到合适的方案。最大的问题是没有制定一个「止损」，我们现在通常会给一个固定的时间来做技术调研，通常是 1–2 天，如果 2 天之后没有任何进展，可以会先暂停调研，转而投入更确定的项目中。

Shape Up 中有个 Hill 的概念，技术调研就像是在爬一个山坡，爬到山顶意味着技术调研已经结束，方案已经很明确了。Linear 没有向 Basecamp 的 Hill 的概念，所以我们为进入 Cycle 中的调研任务定了一些规则。由于调研任务很难评估时间，所以我们会在调研任务一开始的时候确定一个最大时间，也就是根据项目本身的价值，我们最多还愿意投入多少的时间来做技术调研，通常是 1–3 天。然后我们每天会评估前一天调研的情况，通常在最大时间达到的时候会有几种结果：

1. 方案已经明确：这是最理想的情况，接下来就是做任务拆解，但不一定需要在这个 Cycle 进行开发。
2. 方向已经明确，但具体的技术细节还要在调研：这种时候我们通常会在给出 1 天的时间，一天之后在进入这个评估流程。
3. 方向依然不明确：这种时候我们会暂定调研，转化把人力投入到已经确定的项目中。

周五：评估故事点的艺术

周五也是 Cooldown 的最后一天，在下周一的时候就会直接进入 Cycle 中， 因此周五最主要的事情就是确定下个 Cycle 的交付物（Scope）。 最初我们按照 Scrum 的 方式来评估点数，整个评估过程需要所有参与的工程师 一起，所有人 同时评估一个项目，评估的结果通常会有些出入，有些人的点数多，有些人认为的少，然后讨论为什么会有出入，通常是一些背景知识的差异，或者有些人想到一些 边缘情况，所有信息都聊清楚之后，最终达成一致。这种方法的结果是没有问题的，但是效率非常低下，因为每一个项目大家都要讨论很久，结果就是一个点数评估要好几个小时才能完成。

我们的解决方案是制作了一个评估点数的标准，每种类型的任务都有相对应的点数，例如对于前端来说，最简单的需求莫过于改文案，所以一个改文案的 Issue 就是 1 个 Story point；比改文案稍微复杂的就是改个 CSS 属性，改颜色，调整字号什么的，它比改文案复杂的点在于有时候你的修改可能不生效，CSS 覆盖什么的，所以可能会需要找一下在哪里改。以此类推，我们使用斐波那契数列来制作了一个 Cheatsheet 帮助工程师评估每个 Issue 的点数。整个项目的点数就是把所有 Subtask 的点数加起来。

我见过一些团队会被所有做过的任务都进行归纳，然后给每种类型的任务都给一个固定的点数，每个点数下面 也都会链接到一些典型的任务上。这样做唯一的问题也是效率，回顾过去做过的所有任务并分类归纳并不是一件轻松的事情。对比我们现在的做法是，先定义一些我们经常被碰到任务，作为一个锚点，然后遇到新类型的时候，会临时评估一个点数，到 Cycle Retro 的时候我们会重新调整下点数标准。效果也很不错，从最开始到现在基本已经稳定，中间值有过一次比较大的调整，是因为有一些新的任务比我们定义的 3 个点大，但是比 5 个点小。于是我们把所有的 5 个点之后任务都统一往后挪了一位，对应的 Cycle Velocity 也给这膨胀了。

另外就是评估点数的标准描述上，最开始我们定义的锚点就是“1 点：修改文案”这种比较清晰的，但是对所有任务类型清晰的分类和归纳依然是个体力活，所有基本上在 3 个点往后的，如果实在难以分类，我们就用很模糊的语言来表达，有几个案例可以感受下：

• 5 个点有个类型是“写一个全新的、简单的 UI 组件”，意思是一个 Subtask 需要写一个之前没有的 UI 组件，但是这个组件很简单，简单就是一个很主观的词，但团队内部慢慢的就会达成共识，虽然没有文本说明。大家对简单的共识可能就有几个条件：没有动画、只有简单的交互（点击），甚至没有交互，所以大家一看到就知道这是一个简单的组件。
• 8 个点也有个标准是写复杂的新组件，复杂意味着可能有多个交互方式，内部元素也比较多，但是大概看一眼也都知道应该怎么写。
• 13 个点也有个写组件的，是复杂的带动画的 UI 组件：动画通常调试起来比较复杂，所以只是给一个组件加动画本身就是 5 个点。
• 21 个点同样有一个是创建新的 UI 组件，但是你一眼看上去就知道这玩意非常复杂，起码得 3、5 天才能搞定。

再说一个拆任务的粒度，通常我们希望是越细越好，所有的故事点就是针对最小粒度的任务做的。举个例子，前面提到的 复杂的带动画的 UI 组件，有些组件本身和动画并不耦合，这种时候就应该拆分成两个任务：1 个写复杂组件的任务（8 个点） + 1 个给组件加动画的任务（5 个点）；也有些组件 UI 和动画的耦合比较深，两个必须一起做才行，这个时候才会保留 1 个任务给 13 个点。

评估点数之后就是确定 Cycle 的 Scope，根据过往的 Cycle 数据我们已经大致知道在一整个 Cycle 中团队能够交付 600 个故事点，虽然每个人的数字都会有一些差异。但团队整体基本上就是在这个数字附近波动。在 Linear 中我们把所有要做的项目和任务都放进下个 Cycle 中就可以看到总体的点数了。通常为了预防一些未知的事情，我们会保留 20% 的冗余点数，也就是其中 80% 的点数是必须交付的，项目中有一些 Nice to have 的就会放在冗余里面，也就是能交付最好，如果有意外发生，不交付也行。

固定时间，动态范围

前面提到在 Scrum 中我们会遇到一个问题，如果 Sprint Goal 无法达成时应该怎么做？以前的做法是，那就延期到下个 Sprint 中。而在 Shape Up 中有一个原则我觉得可以非常好的解决这个问题：

Fixed time, variable scope.

在 Scrum 中，我认为的一个 Sprint 的定义是至少一次的发布周期，Cycle 同样也是，每个 Cycle 3 周意味着 3 周内我们要进行至少一次发布。发布不是没做完就直接上线，而是功能是完整的，但可能体验不是很好，甚至在某些边缘场景中会有 bug 存在，并且 bug 是已知的，我们称之为 Release with bugs。最根本的原因就是 Cycle 就一定要交付，而且交付物是可用的，即使有 bug 也不影响主流程。这也符合 Agile 本身所推崇的持续交付。从客户和项目 Stakeholder 的角度来看也更容易接受。Cycle 的交付物对于一个团队来说是一个 Commitment，如果时间到了没有交付，客户和 Stakeholder 会降低对团队的信任；而如果交付了，即便是存在 bug，这个时候大家都会表示理解，毕竟不是不能用。而 Cooldown 的过程中我们就会修补之前提到的问题。

作为买家，我自然也不喜欢这种交付方式，最明显的案例就是游戏行业，我们已经看到过很多刚发布的时候一堆问题， 然后慢慢改进的游戏，Cycberpunk 2077、无人深空这种。我的看法是 2C 产品最核心的就是体验，如果有功能且体验不错的产品就有很多，用户和玩家有很多选择；而在 2B 里面功能显然更重要一些，看看 Salesforce 和 Jira 就知道了，毕竟买的人不一定用，所以他不关心所谓的体验。另一方面 2B 涉及到的 Stakeholder 比较多，可能上下游的团队都已经准备好了，那么 Release with bug 好过什么都不交付。

举个例子，例如我们的项目是做注册登录，目标就是让用户可以注册并且登录到我们系统中。往大了说就是一个账号体系，最终一定会非常复杂，但是 3 周内我们能做什么呢？最基本的邮箱注册和登录一定是要有的。找回密码呢？自然也非常重要，但不一定要体现在产品功能上，意思是你的 UI 上有“找回密码”这个按钮，但是用户按下之后是 Contact support，然后 Support 可以 联系开发团队后台修改什么的，虽然加到了人力成本，但是作为 Edge case 来说，风险可以接受。

其他问题

到这里，我们使用 Linear Method 最关键的部分就已经说完了，其实就是引入了 Cooldown，而 Cycle 当中做的事情和 Sprint 本身没有区别。

关于交付

这个时候可能有几个问题，同样是 4 周，我们现在的方法只有 3 周实在写代码，另外一周更多的时候是在写文档；而在 Sprint 中，代码就是文档，有 4 周的时间都是再写代码，前者交付的产品应该会比后者少才对。

话虽如此，直接写代码的前提是你的知道你要写什么，虽然 Agile 宣扬拥抱变化，但是需求天天改 Agile 祖师爷来了也没用。拥抱变化是指对趋势和方向的变化，即如果之前的路走错了，下一次改就行了，其核心是通过学习，不断的提升认知，不断了解什么是“正确”的方向，然后不断的调整；而不是天天改需求，改需求意味着根本不知道方向是什么，只是在原地打转而已。

延期的问题其实也是 Sprint 过程中经常发生不确定性，这些不确定性导致的延期。基本上这种不确定可以分成两类：

1. 需求的不确定
2. 技术方案的不确定

这两个问题在 Cooldown 的过程中都有一定程度的解决。但在 Cycle 进行了一半产品经理要改需求，这种事情也拦不住，我们还是回到最开始的原则「Fixed time, variable scope」，时间就这么多，要改动也是可以，但是改动后的版本也要能保证按期交付，交付后可以在打 Patch 来进一步优化。

如果说连方向都变了，整个项目都需要推倒重来，我到目前还没有这种经历，但是我们的预案是会立即停止 Cycle，重新进入 Cooldown 阶段，重新评估项目。这种情况发生的时候，相当于 Cycle 的目标已经发生了变化，那么继续原来的 Cycle 就是没有意义的。

关于故事点

Some teams try to attach estimates to their tasks or scopes to report status. The problem with estimates is they have a very different meaning depending on the nature of the work being estimated.

一些团队会估算任务或范围来做报告状态。估算的问题在于，它们的含义因所估算工作的性质而有很大不同。

Shape Up 并不使用故事点，转而使用 Hill 来作为状态，我并未尝试过这种方式，一方面在 Linear 中没有这样的概念，比较难以实施，另外所有人需要转变思路。我们也不确定这样做是否值得，我们唯一对故事点的抱怨是估算花费了太多的时间，而这个问题已被解决。有了故事点，很大程度上可以帮助我们更好的跟踪项目动态。

故事点的意义在于让我们可以知道团队在一个 Cycle 内的工作容量，从而预估交付物，给利益相关方承诺。虽然并不是完美，但就我们使用的情况来看，问题也不大。

以下是我们在不同时间团队的 Cycle Velocity，你可以看到故事点可能会随着 Cycle 的进行而波动，实际上就是中途发现了不确定。但是我们的交付进度（蓝色实线）基本上是贴着 Linear 的预测（蓝色虚线，只是线性的平均线而已）在进行，基本上说明项目没有问题。

如果蓝色实线距离蓝色虚线有比较大的距离，那么意味着项目可能会延期，这个时候项目的 Lead 通常会发布 Project Updates 来报告项目状态为 At Risk，此时我们会有几个预案：

1. At Risk：通常意味着增加人手可以解决，我们可以暂停优先级较低的项目，而让临时增加人手来解决。
2. At Risk：如果实在没有人手，那么再次思考 Scope 能否继续缩小。
3. Off Track：意味着没救了，无论如何 都不可能按时交付了。这个是最差的情况，我们也出现过 2–3 次。只能提前和 Stakeholder 沟通，达成一致。

关于设计

遗憾的是我们依然没有解决设计师应该如何参与的问题。理论上 Shaping 的过程就是设计师和工程师通常参与 Shaping，搞清楚要做什么，然而我很少遇到能和工程师配合很好的设计师。这不一定是设计师的问题，在一些公司，设计师是一种资源，需要的时候得去申请。这种情况下，设计师调过来也只是完成一些任务，他不会尝试去理解你的项目目标、背景、所处的状态，只是来完成任务而已。当然并不是所有人都这样，但毕竟能够深入理解项目并负责人的是少数。我的项目中尽量不使用设计师，多数时候与设计师沟通要消耗不少时间，有这些时间我自己都把 Demo 写好了。这其实是敏捷（Agile）的另外一层问题，在一个公司当中，只有一个团队和项目敏捷是不够的，外部资源总会成为 Blocker，解决的方案就是让整个公司、整个组织都变得敏捷起来。

我的多数项目中，我自己承担了设计师的角色，从设计师和开发的沟通来看，相比较使用 Figma，我更喜欢用 React 来做设计（直接写代码）。原因是很多时候 Figma 做不到我想要的效果，尤其是要做非常灵活的组件的时候，例如按钮的颜色继承父级组件的颜色，这种情况在 Figma 中需要设计师手动标记，而开发常常会忘记去看这些标记。

对我来说 Figma 还不够灵活，我的习惯是，在做设计的时候，第一版基本上是不会做组件的，先把页面画出来。随着页面的增加，会出现很多重复的组件，这个时候我才开始做组件，然后把页面上重复的地方全部替换成组件。随着项目继续推进，有些组件就需要根据一些参数/变量来自动调整，这个时候需要回去改组件，同时再调整所有用到该组件的地方，很多时候要把组件的宽高一个个全部调整一次，基本上就是个体力活。虽然在写代码也是相同的流程，但是代码的行为比 Figma 调整 Responsive 更加可预测，所以改动起来也会更容易。

在与开发的配合中，我尝试过两种方式，我们目前的几乎所有的项目都使用 Radix Theme 和 Tailwind：

第一种做法是，我会在 Shaping 的过程中会有一个草图（通常使用 ExcaliDraw），工程师就可以根据草图来直接开发，有些地方可能需要工程师自己发挥，因为有 Radix 组件，多数时候都不会太差。开发完成后，我会先验收功能，没有问题我会在对 UI 做一些微调，然后就可以上线了。

第二种做法是，我先写 UI 和交互，只设计前端的逻辑，以及一些 Mock 的数据，并没有真正和后端交互。然后工程师会在此基础之上加上后端的数据。这种流程比较复杂的时候，用代码直接开发 Demo 有另外一个好处，每一次开发完成后我自己会先用一次，总是会发现一些不合理的地方，然后重新调整。用 Figma 当然也可以做一些流程，模拟点击来尝试，但和真正在前端 Mock 数据来使用时完全不同的。

对于一些需要复杂流程的我会选择第二种，如果只是一个做内容展示的页面，则使用第一种。

回到正题，以上就是我们过去一年使用 Linear 并且结合 Shape Up 和 Linear Method 调整后的实践经验，其中不可避免地带有我们团队的历史因素，例如团队成员配合默契，使得 Story Point 的标准即使相对宽松也不会影响最终交付。我们没有完全投入到 Shape Up 或者 Linear Method 中，而是结合自身情况进行调整。没有必要为了改变而改变，只有当现有流程出现问题时，我们才会考虑引入新的方法。我们也深知，没有一套方法可以完美适配所有团队。最佳实践，唯有在实践中根据自身情况不断微调、优化才能得到。

1. Cycle 或者 Sprint 对我来说都是一个周期的单位。Linear Method 不适用 Sprint 是认为 Sprint 有冲刺和意思，而 Cycle 的重点是交付价值，而不是冲刺交付具体的工作量。我个人到无所谓。 ↩︎