当你手上有一把锤子，你看什么都像钉子。你估计在哪听过这个经典的技术笑话，作为一个程序员，我也经常反思，自己会不会就是那个拿着锤子的傻子。

不过，现实工作里，你还可能遇到另一种情况，当你老板花了重金买了个锤子塞给你，你该怎么办？

聊一聊你或许听说过的锤子故事

微服务的兴起是一个最典型的锤子，这段历史离我们并不远。在微服务兴起的时期，“微服务化”成了所有系统的政治正确，每个服务都得领域设计拆分一下，每个服务都看起来像这个锤子的钉子。服务一拆，延迟，开销，故障排查复杂度集体上升。其实微服务的代价清单一直不短：容器管理，注册中心成本，容灾难度升级，链路追踪复杂的上升，部署项膨胀，网络IO 压力膨胀，分布式事务，权限治理全都得重做。20 人的团队治理 50+ 个部署项，每个人都在为一个被临时砸烂的钉子兜底。

我猜到你大概率会有疑问，现在微服务不是一个主流的解决方案吗？微服务看起来明明是一个成熟，稳定，广泛落地的优秀方案，为什么会是一个典型的“锤子”？

我以前也会有这样的疑惑，一个先进的，新兴的，由全世界最聪明的一群工程师，在长期的业务实践和试错流血中孵化出的一套解决方案，为什么会变成一个到处乱砸的“锤子”？

你应该也猜到答案了，锤子是把好锤子，钉子也只是个钉子，只是有人非得用这个锤子非得去砸那个螺丝钉。

锤子为什么非得砸那个螺丝钉？

当一把重金锤子被拿出来之后，“这个锤子好用”已经是一个无法更改的事实，它经过了权威背书，经过了多方评估，经过了可行性分析，现在需要将这个好用的工具铺开落地了。

想法是好的，逻辑是闭合的，证据是令人信服的，可用场景是有先验案例的，客观上这是个正向发展的好故事。但主观落地上，一个组织决策的背后是大量的沉没成本和权威背书，在关心在哪些场景做出哪些成果之前，执行度才是需要砸的第一个钉子。

这算是一种很典型的形式主义，虽然最终走向形式主义的现实原因可能更为复杂，但是这条链路传导到一线工程师手上时，你接收到的信息是大概是：“上头要求使用 XX 工具，这季度使用率需要达到 XX”这种不明所以但不得不做的事情。

因为只需要考虑执行度，而你又只是一个一线开发，出于仅告知最少必要信息原则，你几乎不知道高层背后要讲一个什么故事。而经常向上汇报的你应该知道一个核心原则——如果决策不能执行，你最好能给一个在他们要讲的故事里能逻辑闭合的原因。但由于你不知道他们的故事在讲什么，你给的理由有极高的风险在挑战他们权威认定的“事实”。所以你知道客观原因，知道具体情况，但不知道如何汇报，还不如硬着头皮把这个指标做完，这样你好歹可以写一份简单的“工作如期完成”的汇报材料。

我觉得大多数事情都是从执行开始变坏的，但很少有组织会在最后将失败原因归根到执行方向的失败上，因为执行度作为一个的钉子非常合适，逻辑也很说的过去，只是花了大成本闹了个差强人意的结果，埋下了一堆地雷而已，这些小隐患都算不上是一个错误，甚至可以包装成一个漂亮的管理结果。

所以为什么非得砸那个钉子？因为当你身处于于哪个场景里，你会发现：“给个可汇报的符合故事逻辑的理由不砸那个螺丝钉”和“想办法把锤子砸下去如期完成工作”这两个选项，一个不可接受，一个不那么好，我们也没得选。

为什么执行度是第一个钉子？

客观上来说，除开要背严格业务指标和商业目标的高层，很大一部分中层领导的管理权，就是整个故事里第一把重金打造的锤子。

试想一下，如果你是公司化重金请来的公司微服务化落地团队，你拆的服务少了，会不会让你看起来性价比太低，会不会在暗示上层决策失误，会不会变成一个你能力不行的证据？虽然我们都知道微服务的拆分有很多可量化，有说服力的指标。但在行业野蛮生长的初期，怎么量化一个决策的收益，远比我们想象的要复杂的多。

复杂对于汇报来说是不可接受的，很多时候甚至代表一种危险信号，你在那哼哧哼哧地构建工程评测系统，量化操作收益，做降本增效的可执行评测方案的时候，别人汇报上一句“拆分服务数量到达部门领先水准”，暗戳戳地似乎在影射你执行力差，效益低，是整个故事里不合理的杂音。

抛开收益指标，我们还能立刻量化的是什么呢？当然是这是个锤子的使用率和落地率了。落地是一个非常常见的借口，你可以在各种场景里见到他的变种，比如你会经常听到的一个要求：先不考虑成本，先干出点实际成果来。

被拆服务质量，拆分后的微服务数量，拆分后的微服务大小，微服务拆分比例，这些指标不仅无关痛痒，更不一定能反应是否真的降本增效，解决痛点，但因为好汇报，好量化，很容易就被放在了最显眼的位置上。哪怕这些指标不合理，不好用，你去内卷这个指标，绩效，产出，价值，全都岌岌可危，事已至此，没有钉子，也需要找点钉子了。

同时，落地优先的策略也往往暗示，审计工作的优先级会推后，且会被已有的事实影响，全公司上下都已经花了大量沉没成本去落地这些事，做了大量的指标并汇报，讲了一个完整且合理的故事，真需要质量审计和复盘的那一天，结果也很难有那么理智和客观了。

下个故事见

微服务经历过的故事，往后只会更多。目前看来，互联网行业仍是一个流量和故事驱动的行业。在这个行业当中，大多数纸老虎最常用的手段就是用同一套叙事手法去讲不同的故事，哪怕故事和现实有割裂和分叉，只要逻辑是闭合的，你也只需要对你的权利和资本来源负责。

所以那些拥抱的热情投身于不同技术叙事和营销中的技术人员们，有不小的比例，是没有花时间去关心自己是否处在一个故事泡沫当中。技术从来没有好坏，但你为什么出现在这里却有着不同的原因。去留同因，我们大多都是因为某个故事需要的一个角色而出现在这里，也是因为需要有个人去抡那把锤子站在这里，那到这个故事讲不下去的时候，就是这个角色退场的时候。

组织经常会考量一个人的稳定性指标，也是在考量你是不是会应和同一个故事的人，稳定性只是忠诚度的一种包装，在大多故事里，故事比人不稳定地多。现在，领导讲完了一个精彩绝伦的故事，有花重金给这个故事打了一把锤子，交到你手上，你的角色任务是什么便不言而喻，但我希望你在故事结尾时，还能认得出哪些是钉子，哪些是被你砸坏的螺丝钉，而不是也被裹挟失去了一个工程师该有的理智和客观。

当然，今天的话题聊的不是什么陈年旧事，有些故事正发生在我们身边，致所有一腔热血扎入 AI 旋涡的同僚们，我们下一个故事再见。