Leader背绩效时摊牌要“大礼包”：职场黑话与博弈论算法（Nim游戏）解题详解

背绩效的场合，Leader当着HRBP的面突然来一句：“干这么多年，累了，想歇歇，帮我争取个大礼包。”这话一出来，空气都得静三秒。

这不就是典型的职场黑话现场教学吗？表面像是在感慨人生，实际是在递话：我不想硬扛了，但也不想自己开口裸辞，看看公司愿不愿意按“体面点”的方式送我走。HRBP在场是关键，这种话不是随便感叹，就是说给该听的人听的。

有人说，Leader八成是闻到味儿了，知道自己位置不稳，先把台阶摆出来。你别说，这种老江湖的发言还真挺典，话说得软，意思一点不软。背绩效的人在旁边估计都听懵了，本来以为是复盘，结果听成了离职谈判预告。成年人上班，有时候真不是谁能力不行，是谁先把话说到那个份上。HR听完，估计已经在心里算“包”了。

技术岔题：Nim 游戏算法精讲

聊完职场，咱也别光看热闹。程序员嘛，遇到啥事都习惯性拆解逻辑。这让我想起一道经典的算法/数据结构面试题：Nim 游戏。

一上来就琢磨递归或动态规划，十有八九会把问题想复杂了。面试官真正想看的，往往不是你会不会模拟拿石子的过程，而是你能不能一眼洞察本质：

这个题根本不用搜索状态，直接看石子总数 n 和 4 的关系就够了。

题目规则很简单：有一堆石子，两个人轮流拿，每次只能拿 1 到 3 个，谁拿到最后一颗谁赢。假设双方都足够聪明，问先手会不会赢。

面对这种“轮流操作、双方都执行最优策略”的题，先别急着写代码，从最小样本开始枚举找规律：

• n = 1，先手直接拿完，赢。
• n = 2，先手也赢。
• n = 3，先手还是赢。
• n = 4，这时候情况变了。先手拿1个，后手拿3个；先手拿2，后手拿2；先手拿3，后手拿1。无论如何，先手必输。

到这里就应该警觉了：4 是一个关键的分界点。

再继续验证：

• n = 5，先手拿1个，给对方留下4个（必输局面），所以先手赢。
• n = 6，先手拿2个，给对方留4个，赢。
• n = 7，先手拿3个，给对方留4个，赢。
• n = 8，不管先手怎么拿（1,2,3），都会给对方留下5、6或7，而这些都是对手能赢的局面，所以先手输。

规律已经非常明显了：只要是 4 的倍数，先手必输；不是 4 的倍数，先手必赢。

理解这个规律，不要死记硬背。关键在于，每一轮两人最多能拿走4个石子（你拿1我拿3，你拿2我拿2，你拿3我拿1）。如果你作为先手，能一直把局面控制成“留给对手的石子数是4的倍数”，那么对手永远无法翻盘，最终被迫拿走最后一颗石子的就是他。

所以，这题的 Java 解法，简单到不像一道算法题：

public class Solution {
    public boolean canWinNim(int n) {
        return n % 4 != 0;
    }
}

就这一行判断，足够了。

当然，也有人喜欢用动态规划来解，思路也不复杂：dp[i] 表示面对 i 个石子时，当前行动者是否能赢。状态转移方程为：dp[i] = !dp[i-1] || !dp[i-2] || !dp[i-3]。意思是，如果我能通过拿1、2或3个石子，把对手逼入一个必输的局面（dp[i-1]、dp[i-2]、dp[i-3] 中有一个为 false），那么我当前就能赢。

动态规划的写法如下：

public class Solution {
    public boolean canWinNim(int n) {
        if (n <= 3) {
            return true;
        }

        boolean[] dp = new boolean[n + 1];
        dp[1] = true;
        dp[2] = true;
        dp[3] = true;
        dp[4] = false;

        for (int i = 5; i <= n; i++) {
            dp[i] = !dp[i - 1] || !dp[i - 2] || !dp[i - 3];
        }

        return dp[n];
    }
}

但问题恰恰在于，当你把 DP 表推出来，很快就会发现：

• dp[4] = false
• dp[8] = false
• dp[12] = false
  ...

规律直接摆在脸上。既然如此，还保留整个数组干什么呢？用动态规划来解这道题，纯属多绕了一个大弯。

这道题真正的价值点，不在于代码量，而在于你是否具备 “最优策略 + 规律归纳” 的洞察力。很多文章喜欢把它包装成高深的博弈论，其实落地到代码层面，核心思想就一句话：

先手想赢，就想办法在每一轮操作后，把石子总数控制成 4 的倍数留给对手。

在技术面试求职中，这类题目常常不是考察你会不会写代码，而是考察你懂不懂得“收”。该用数学结论的时候别硬上递归，该一行代码结束战斗的时候别拖成半页。

就像开头的职场故事，表面是感性的疲惫与歇息，底层是理性的博弈与计算。无论是处理人际关系还是解决算法问题，看清规则、抓住关键，往往比盲目努力更重要。如果你对这类融合了场景思考和实战解题的内容感兴趣，欢迎来云栈社区一起交流探讨。