状态杠杆：你不是不努力，你是没做在点子上

一般老百姓对“努力”有过高的评价。特别是当今内卷时代，很多公司默认要想提高效率就得让全体员工更努力、花费更多的时间。也许努力真的是个必要条件，但如果你整天只想着努力，你可就差远了。

殊不知努力更像一个标量，只有强弱；行动则至少同时有方向、时机和先后次序。

这一讲的思维工具叫「状态杠杆（state leverage）」，是我发明的一个名词，学术界并没有统一的说法，但是我们有很多现成的研究结果支持。

状态杠杆，简单说，就是这一步做完之后，世界会不会变得对下一步更友好。

我们先看两个生活中的小感悟。

第一个来自家务活儿。你从超市买了好几条排骨，打算先放冰箱里冻起来，过几天再吃。对此你有两个办法：一个是先切好，分成几份装袋再冻，做的时候打开一个袋子扔锅里就行；另一个是先冻起来，等要吃现切。第二个做法允许你暂时偷懒，可是会带给你很多麻烦 —— 你切之前得先把排骨解冻，为此你必须规划好做饭的时间，更不用说刚解冻的排骨切起来更费力。

买回来就切，把劳动前置，不但劳动量更少，而且是把局面推进到一个低摩擦的状态。

第二个感悟来自《西游记》。唐僧师徒到了祭赛国，发现有冤情，唐僧为了还愿，就去寺院里扫一座宝塔。他跟孙悟空两人从下层往上扫，扫到上面听见有妖怪说话，于是破案。这种扫法当然是剧情需要，但是你看到这儿一定会产生一个疑问：扫塔难道不应该是从上往下扫吗？

从上往下扫，上层的灰扫下来，下层顺手就一起带走了；可是像唐僧那样从下往上扫，你下面刚扫干净，上面一动手，灰又掉下来……你扫一晚上塔不还是脏的吗？

其实两种扫法花的力气差不多，毕竟人的疲劳感主要是来自挥动扫帚、调整姿势、来回移动这些固定成本，而不是清理灰尘的那一点有效功。但是扫塔这个活儿不满足交换律：先做 A 再做 B，和先做 B 再做 A，结果非常不同。

从下往上扫，你创造出来的临时干净状态会被后面的动作推翻；只有从上往下扫，你创造的才是不可逆进展。

切排骨和扫塔的道理都是：做事的顺序，和做事的努力程度，至少是同等重要的。

状态杠杆，就是那些能改变系统状态的行动，它们会重塑后续行动的成本、返工概率和选择空间。

你要优化的不只是这个动作，更是这个动作之后留下来的状态。

咱们说三种杠杆。

✵

第一种是「前置杠杆（Preventive Leverage）」，意思是在事情的上游做的那些动作，相当于一个项目的设计阶段。越早做的决定，对全局的锁定效应就越强。

美国国家航空航天局（NASA）有个著名的观察 [1]。一个项目在设计阶段所花的钱只占全部预算的 15%，但这个阶段锁定（commit）了大约 75% 的生命周期成本。测试、制造、集成、运行和维护怎么做，基本都 被早期设计决定了。

设计阶段如果你发现一个小错误，随手改了就改了，很容易。但是如果等到后面实施阶段才发现问题，重新设计和重新验证的代价就会非常大。比如盖大楼，前期图纸上只是轻轻一笔，后期工地上却是锤子、钢筋、预算、工期、吵架、甩锅、法律程序……后果不堪设想。

据美国国家标准与技术研究院（NIST）2002 年的一份报告说 [2]，超过一半的软件缺陷不是在上游被发现，而是拖到更下游的开发和使用环节才暴露出来……可是缺陷发现得越晚，修复成本提高得越厉害。如果能 改进测试基础设施，更早发现问题，报告估算早在那个年代，每年可以避免的损失就超过 220 亿美元。

所以设计看似便宜，其实是全项目最贵的地方。

这就是为什么丹麦经济学家傅以斌（Bent Flyvbjerg）在《怎样做成大事》一书 [3] 中说，越是大项目，越应该在设计阶段加倍小心，宁可时间花长一点也没关系……他总结的经验叫做「慢慢谋定，快速行动」。

预防远胜于补救，前期多喝两天咖啡，后期少加无数个班，这就是前置杠杆。可是如果你没在真实世界参与过大项目，你可能无法想象，人们就是会在前期做一些很随意的选择，让项目匆匆上马，把一些明明是从从容容的小事变成了灾后重建。

✵

第二种状态杠杆叫「顺序杠杆（Sequencing Leverage）」，意思是项目的不同任务之间存在信息依赖，必须按照严格的顺序进行。

比如你家装修房子。你不能先刷墙再走水电，因为水电一改，墙还得重新砸开；你也不能地板都铺好了，才想起来还没装中央空调。正确的顺序一定是先定方案，再走水电，再做泥木，再刷墙，最后铺地板、装家具。这跟唐僧扫塔是一个道理。

很多人把项目理解成待办清单，先干这个再干那个。可是复杂项目不只是一条线，而是一个依赖网络，其中有多个并行交叉的依赖关系，那怎么办呢？你需要一个叫做「设计结构矩阵（Design Structure Matrix, DSM）」的工具 [4]。

设计结构矩阵把任务之间谁依赖谁、谁影响谁，画成一个方阵。它不但能看出哪些任务可以单向推进、哪些任务互相咬住、哪里有循环，还能告诉你怎样重排顺序才能让信息尽可能单向流动，让进展尽可能单调累积，避免“你等我、我等你”的局面。

一个很典型的案例是用 DSM 梳理福特汽车引擎盖系统的开发流程 [5]。你可能觉得引擎盖就是车前面那块铁皮，没什么了不起 —— 但它牵动的可是一串彼此咬合的决定。

造型团队想把线条压低一点，就会影响内部间隙；间隙一变，铰链的位置和开合轨迹就得跟着改；铰链一改，锁扣的位置、装配方式、碰撞安全，甚至工厂里机器人怎么抓取怎么安装，可能都得重来。

最麻烦的不是事情多，而是事情互相牵连。造型团队先改了外形，只是前端多画了几笔，后面的人就发现原来的结构装不上了。于是结构团队返工。结构一返工，制造团队又得重新评估工艺。工艺一变，安全测试的假设条件又不成立了……项目就在这种来回拉扯中消耗。

DSM 能找出哪些任务之间耦合最强，哪些地方最容易形成返工回路。这样你就能重新安排顺序：哪些问题必须尽早一起协调，哪些事情可以等前面的条件稳定了再做，哪些环节不能贸然往前推进。

你要让所有人同时开工，那就是在互相制造废品。

这个关键认知是工作与工作是不平等的。不是所有团队都该被一视同仁地平推管理。有些接口就是天生高耦合，你不给它更高的协调优先级，项目就一定返工。

✵

第三种状态杠杆是「约束杠杆」，出自以色列物理学家高德拉特（Eliyahu M. Goldratt）提出的「约束理论（Theory of Constraints, TOC）」[6]。

约束理论的核心逻辑非常简单：任何系统的产出，都受制于它最窄的地方 —— 也就是「瓶颈」，也就是卡脖子的地方。你先别着急优化全流程，你先把瓶颈解决。

比如你们公司的前端营销每天能带来 100 个潜在客户，中端销售每天能转化 50 个，而后端交付团队每天只能服务 10 个，那你的瓶颈就是交付。如果你不能提高交付，反而去搞什么“全员狼性培训”，把营销翻 倍到 200 个，销售翻倍到 100 个，有用吗？你不仅没有增加一分钱的真实产出，反而因为堆积了大量无法兑现的订单而造成内部混乱和客户投诉。

瓶颈理论比木桶理论可有用多了，毕竟谁家也不会用只有一个短板的木桶 —— 但是任何一个系统，流水线也好、团队研发也好、审批流程也好，还是你个人的生活也好，其整体的总吞吐量（throughput）都只由一个环节决定，那就是最慢的那个环节 —— 瓶颈。在非瓶颈环节上搞得再热闹也是虚假繁荣。

有一项对上百个已发表 TOC 成功案例的综述发现 [7]，一旦企业真抓住了瓶颈，改善往往不是这里省一点、那里快一点，而是一整片指标一起好转。平均来说，从接单到交付的总耗时（lead time）缩短 69%，企业内部流程跑一圈时间（cycle time）缩短 66%，准时交付率提升 60%，库存下降 50%，吞吐量增加 68%，财务表现提升 82%。

这可是极大的改进！瓶颈就如同高速公路上最窄的一段车道，你把别的路段修得再宽，车还是堵在那里；可一旦把那一段拓开，车流一下子就顺了，积压也跟着缓解。

高德拉特给的解法分五步 ——

1. 先识别瓶颈：到底哪个环节卡住了全局；

2. 充分利用瓶颈：确保瓶颈本身别浪费时间，别停工，别被无关事务打断；

3. 让其他环节服从瓶颈节拍，整个系统要围着瓶颈来配速；

4. 提升瓶颈，在必要的时候增加设备、人手和流程支持，把那个最窄的地方拓宽；

5. 回到第一步，寻找新的瓶颈。

逻辑很简单，但是这里有一个巨大的情感问题：如果你不在瓶颈上，你其实没必要干得那么忙 —— 可是老板们却是看谁闲就催谁。很多老板最受不了员工闲着，哪知道瓶颈没解决，其他努力不但无效，而且还增加麻烦。

✵

我之所以把这些称为「状态杠杆」，是因为它们背后有一个更底层的数学灵魂，那就是理查德·贝尔曼（Richard Bellman）在 1954 年提出的「动态规划（Dynamic Programming）」理论 [8]。

绝大多数人干活，都是在自己的局部运行一个「贪心算法」：我负责的这个事儿，我怎么干最省力，怎么让我当前的收益最大。比如买回排骨直接扔进冰箱就是贪心算法 —— 在当下这一秒，这是最轻松的解法，至于说过两天不好切，那是未来的我操心的事儿。

贪心算法使得一系列局部的最优解拼接出了一个全局的糟糕结果。贝尔曼的动态规划拯救了这个局面。

贝尔曼提出一个方程（Bellman Equation），通俗来说 ——

你的总收益 = 你眼前的即时回报 + 你即将进入的下一个状态的潜在价值（Value of the next state）。

在动态规划的视角下，动作的目的不只是在当下，更是在于完成一次「状态转移（State Transition）」。这就好像职业选手打台球一样，不仅要打进当前的球，还要通过精确控制力度和旋转，让白球在碰撞后停在最完美的位置，方便击打下一颗球……

前置杠杆，就是宁可牺牲当前的即时回报，也要把系统推入一个“未来不用返工”的高价值状态。顺序杠杆，就是用设计结构矩阵为你规划出一条正确的状态转移路径。约束杠杆，则是说在一个复杂系统里，真正决定“下一个状态价值”的变量只有一个，那就是瓶颈。

简单说，你这一步怎么走，不能只看这一步本身值不值，而要看它会把你带到一个什么状态：后面的路是更宽了，还是更窄了，成本是更低了，还是更高了。

贝尔曼有个「最优性原理（Principle of Optimality）」，翻译成大白话就是：不管你过去多烂，也不管你起点在哪，你当下的这个决策，必须能让你在新状态下，面对未来时拥有最好的出路。

✵

咱们看几个日常的应用场景。

前置杠杆，厨房里有句法语叫 “Mise en place”，意思是“一切就位”：大厨在开火炒菜之前，会花大量时间把所有要用的食材切好，酱汁调好，肉类腌好，所有小碗按顺序摆在手边。一旦点火，行云流水，绝不能半途关火去满世界找盐。

你的工作环境最好先处于低摩擦状态。比如你要写个什么东西，也应该先备料 —— 做好调研，把所有的数据、文献、核心大纲全部整理在手边 —— 一旦开始写，就进入纯粹的输出状态，而不是边写边找资料、想结构，甚至还时不时回复个消息。

顺序杠杆除了用于装修房子，更重要的心法是遏制自己先干那些“看起来像进展”的事儿的冲动：你这个报告的核心主题都没想好，就在那儿研究 PPT 皮肤，光修标题字体就花了 15 分钟，一看就不是真干活的人 。

瓶颈杠杆告诉我们不要“到处努力”，而要“只在命门上用力”。能量产的、谁来都差不多的活儿，都不是你最该亲自下场的地方。真正值钱的是那个决定全局节奏的卡点。

你以为自己今天效率低下是因为意志力薄弱、不够自律，其实你的瓶颈是物理的：你昨晚睡眠不足。公司天天搞狼性动员，项目推进还是慢，那就根本不是执行力的问题，而是因为只有老板一个人有拍板权，他的决策带宽锁死了总吞吐量。你写不出东西抱怨自己文笔不够好、打字不够快，其实瓶颈是你脑子里没有值得被写下来的洞见……

✵

刀还是那把刀，扫帚还是那把扫帚，力气还是那些力气。可就是因为你用力的地方不同、顺序不同、卡点不同，事情就发生了质变。

做在点子上，和没做在点子上：

一个叫积累，一个叫耗费；

一个越做越顺，一个越做越堵；

一个是在生利息，一个是在交罚息。

你是在完成任务，还是在制造一个更好的未来状态？

注释

[1] Hirshorn, Steven R., et al. 2016. NASA Systems Engineering Handbook (NASA/SP-2016-6105 Rev2). Washington, DC: NASA.

[2] Tassey, Gregory. 2002. The Economic Impacts of Inadequate Infrastructure for Software Testing. NIST Planning Report 02-3. Gaithersburg, MD: National Institute of Standards and Technology.

[3] Flyvbjerg, Bent, and Dan Gardner. How Big Things Get Done: The Surprising Factors That Determine the Fate of Every Project, from Home Renovations to Space Exploration and Everything In Between. New York: Currency, 2023；《精英日课》第五季，怎样做成大事1：慢慢谋定，快速行动

[4] Eppinger, Steven D., and Tyson R. Browning. 2012. Design Structure Matrix Methods and Applications. Cambridge, MA: MIT Press.

[5] Zambito, Antonino Paolo. 2000. Using the Design Structure Matrix to Streamline Automotive Hood System Development. Master’s thesis, Massachusetts Institute of Technology.

[6] Goldratt, Eliyahu M., and Jeff Cox. 1984. The Goal: A Process of Ongoing Improvement. Croton-on-Hudson, NY: North River Press.

[7] Mabin, Victoria J., and Steven J. Balderstone. 2003. “The Performance of the Theory of Constraints Methodology: Analysis and Discussion of Successful TOC Applications.” International Journal of Operations & Production Management 23 (6): 568–595. doi:10.1108/01443570310476636.

[8] Bellman, Richard. 1954. “The Theory of Dynamic Programming.” Bulletin of the American Mathematical Society 60 (6): 503–515.