TraceOnSnow

2026-10-27 秋招XX AI Agent开发工程师面试复盘

Mon, 26 Oct 2026 20:00:00 GMT

2026-10-27 秋招XX AI Agent开发工程师面试复盘

这场面试基本是在聊天。面试官沿着简历里的 Agent 项目一点点往下问，问得很细。我的感觉是，有些追问也不要求我一定做过，而是想看看我会怎么理解、怎么继续往下推。后面还聊到了个人 Agent 项目，我直接做了一次展示。

把这次聊到的几个问题整理一下。

1. 为什么用 Skill，而不是 Function Calling？

这两个东西先要放到不同层次上看。Function Calling 让模型用约定的结构提出工具调用；Skill 把一类任务的操作方法、参考材料和脚本组织起来，告诉 Agent 什么时候用、该怎么做。一个 Skill 完全可以通过 Function Calling 调工具，两者可以配合。

面试官继续追问了渐进式披露：为什么会省 Token，具体怎么省？

按 Agent Skills 规范，开始只加载各技能的名称和描述；确定需要某项技能时，再读完整的 SKILL.md；更详细的参考文件按需读取。省下的是暂时用不到的详细说明，并不是 Skill 本身不占上下文。Agent Skills 规范

因此不能直接说“Skill 一定比 Function Calling 省 Token”。这取决于原来放了多少说明、实际加载了多少材料，以及有没有反复读取。如果技能很多、每次又都加载全文，未必更省；工具定义同样可以按任务筛选，不必一次全部发给模型。

2. Agent 怎么知道自己该调用工具？请求体长什么样？

面试官从“怎么调用”一直问到一次推理里模型究竟收到了什么。

以 Chat Completions 的函数调用格式为例，请求体顶层的 messages 放会话消息，tools 与它并列，定义函数名称、用途和参数结构。模型结合任务和工具说明，返回带 tool_calls 的 assistant 消息。应用检查参数和权限、执行函数，再把这条 assistant 消息和对应的 role: "tool" 结果追加到消息中，通过 tool_call_id 对应调用，继续请求模型。模型也可能继续调用其他工具。OpenAI Function Calling 文档

真正执行操作的是应用程序。模型负责提出调用，应用负责判断能不能执行、在哪里执行，以及怎样处理失败。

Skill 的说明也要通过宿主进入模型上下文，例如先注入技能目录，再通过读取文件的工具取得正文。不能因为用了 Skill，就给 OpenAI 请求体凭空加一个标准的 skills 字段。具体消息格式还要看用的是哪套 API，上面说的是 Chat Completions。

3. MCP 跑在本地还是服务器？STDIO 和 SSE 有什么区别？

这里要把部署位置和传输方式分开。

stdio 通常由客户端启动 MCP Server 子进程，通过标准输入输出交换协议消息。这里的“本地”是相对客户端进程说的；客户端若在服务器上，子进程也可以在服务器上。

HTTP 传输可以连接远程服务，也可以访问同机回环地址。旧的 HTTP+SSE 方案用 SSE 接收服务端消息，并通过另一个端点发送请求；从 2025-03-26 版规范开始，它由 Streamable HTTP 替代。后者使用统一 MCP 端点处理 HTTP 交互，需要流式返回时仍可使用 SSE，所以不能简单把“使用 SSE”和“旧传输”画等号。MCP 传输规范

放回前面的问题里，MCP 负责标准化客户端和服务端的能力交互；Function Calling 负责模型提出结构化调用；Skill 负责组织任务做法。宿主可以把 MCP 工具转换成模型可调用的工具，再由 Skill 指导怎样组合使用。

4. Deep Agents 到底做了什么？为什么用它？

这组追问的重点是具体能力：只说它用了 LangChain、LangGraph，还没解释清楚为什么选它。

Deep Agents 在工具调用循环上提供了文件读写、上下文管理、子任务委派等能力，也支持规划、技能加载和人工介入。比如长工具结果可以转存到文件，后面按需读取；独立子任务可以放进自己的上下文，完成后返回结果；关键工具执行前可以暂停等待确认。底层 LangGraph 则提供持久执行、流式输出和中断等运行能力。Deep Agents 官方介绍

选型时要说清楚自己需要其中哪几项。需要长任务、文件和上下文管理时，这些现成功能能减少外围实现；只有几次确定的工具调用时，也可以先用简单循环。不能把框架的全部能力都算成自己项目已经用上的功能。

5. 怎么理解 Agent Harness？

可以把它理解成让模型持续做事的一整套运行安排。Agent Loop 负责反复请求模型、执行工具、反馈结果，直到完成或停止；Harness 还需要处理上下文、工具接入、权限、文件系统、沙箱，以及运行状态的检查点和恢复。上面的 Deep Agents 就是在这一层提供现成功能。

几项东西解决的问题并不相同：权限决定允许做什么；沙箱限制实际执行环境的影响范围；检查点记录执行状态，支持中断后继续。它们不能只靠一句提示词代替。

Prompt Engineering 关注怎样表达指令，Loop 的设计关注怎样循环、何时退出，Harness 则把这些和实际环境接起来。Skills、Hook 可以参与其中，Cron 可以作为定时触发入口，但定时任务不是每个 Harness 都必须有的核心。

6. 个人 Agent 项目怎么做的？

现场还展示了个人项目。用现在的流程来说明，我希望把平时的笔记、作品记录和文章留在普通 Markdown 里，AI 围绕这些文件协助整理，需要公开时再进入网站。

拿一篇笔记举例，私人主题稿保留在原位置，要发表时准备独立 Post，两份稿以后分别维护。网站仍由 Payload 管理，通过标准 API 对接；程序负责记录对应关系、检查两端变化，写入后回读确认。私人保存和网站公开是两个明确的动作。

这里适合展开的是 AI 与程序怎样分工：AI 帮忙理解材料和组织表达，身份对应、同步检查和写入核对交给程序。具体演示可以沿一篇文章走完整条流程，再挑实际实现过的部分讲。

7. 为什么把主会话和旁路任务分开？

面试里还聊到了只有一个主聊天、同时存在多个旁路任务的设计。按这个描述，可以从协作和上下文隔离来理解。

主会话保留用户目标、约束和最终决策；旁路任务承担相对独立的查询、阅读或处理工作，最后把必要结果交回来。这样主会话不用带着每项任务的全部中间过程，也更容易继续和用户沟通。

代价是任务交接：目标和输入没交代清楚，旁路可能重复劳动或漏掉约束；如果把所有历史都复制过去、再把全部过程塞回来，隔离上下文的收益也就有限。这里讨论的是这种设计的取舍，不能只凭界面形态断定某个产品内部一定怎样实现。

8. Python 和 C++ 有什么区别？

不能只用“解释型”和“编译型”概括。Python 通常是动态类型，C++ 通常是静态类型；常见 CPython 会先编译成字节码再执行，C++ 通常提前编译成机器码，但这不是语言实现唯一可能的方式。

工程上，Python 适合快速组织业务、调用库和编写自动化；C++ 提供更直接的内存布局、资源生命周期和性能控制。性能也要看具体工作落在哪一层：Python 调用的数值库可能把主要计算交给底层原生代码，不能仅凭外层语言判断整个程序的速度。对 Agent 应用来说，还要看瓶颈是在模型和网络请求，还是本地计算。

共斗游戏里的变与不变

Mon, 19 Oct 2026 20:00:00 GMT

共斗游戏里的变与不变

我觉得共斗游戏很有意思的一点，是它既需要一些东西固定下来，又不能一直不变。

怪物有哪些招式，什么情况下会用出来，我手里的武器面对这些招式应该怎么处理，这些都可以慢慢学。刚开始不知道怎么应对，之后靠自己打，或者看攻略，逐渐知道这里应该做什么，再把这些处理练熟。从知道怎么打，到真正能够稳定地打出来，中间还有一个过程。这个过程本身就是乐趣，也让反复打同一个怪物有了意义。

但如果什么都固定，打到后面也容易变成重复。招式见过，处理方式也熟了，下一次还是这样打。共斗游戏需要保留这种越打越熟的感觉，同时又得有一些变化，让人还有继续玩的兴趣。我想到的几个游戏，把变化放在了不同的地方。

《怪物猎人》比较直接。不同怪物有不同的动作，换一个怪物，就有另一套需要学习的东西。武器也有区别，即使面对同样的招式，用不同武器时需要采取的动作也不一样。所以单个怪物可以慢慢打熟，但怪物和武器的差异，又让游戏里有了很多需要重新学习的地方。

《碧蓝幻想 Relink》的战斗流程相对更容易让我觉得重复，不过它有许多不同的可操作角色。换了角色，动作和资源循环都会变。抽象一点看，其中不少玩法还是可以归到蓄力、攒资源再消耗资源、按特定节奏输入这几种模式里，但实际操作起来，不同角色还是提供了明显的区别。知道一个角色怎么打以后，另一个角色也还有值得熟悉的东西。

我觉得这种差异是有用的。虽然可以把角色的玩法概括成几种模式，但操作时面对的毕竟是各自的动作和循环，不能只看概括之后像不像。当然，Relink 还有剧情和其他 JRPG 内容，战斗并不是它全部的支撑。

《艾尔登法环：黑夜君临》又把变化放到了每一局里。地图和部分事件会重复，但当局的资源分布、能走的路线和遇到的情况有变化，还是需要重新规划。即使一开始有了打算，过程中也经常会出现计划之外的情况，不能完全照着原先的路线走到底。

这让我觉得，它在应对重复感这件事上和前两者有些区别。怪物和武器、角色的差异，都给了玩家更多可以学习和练熟的东西；黑夜君临则让玩家已经会处理一些战斗之后，每一局仍然要根据当局的情况作决定。战斗可以越打越熟，但这次先去哪里、怎么拿资源、原来的路线还要不要继续走，到了下一局还是得重新考虑。

工厂游戏的ROI，以及我为什么更喜欢MC整合包

Sun, 18 Oct 2026 20:00:00 GMT

工厂游戏的ROI，以及我为什么更喜欢MC整合包

我玩工厂类游戏，最熟悉的一种感觉就是：永远差一点资源。

下一个生产目标已经摆在那里了，但材料还不够。这个时候就得想，是自己手动补一点，先把眼前的东西做出来；还是等现有产线慢慢攒；或者干脆现在花点时间，把这部分也自动化了。

我觉得工厂游戏里一直有这种ROI判断。为了当前这点资源，值得投入多少时间、多少材料去做自动化？现在搭一套，以后会不会很快就淘汰？要不要先用一个临时方案将就，等到更高级的生产方式解锁了，再一起重构？并不是每次都立刻奔着最终解去，有时候先将就一下才更合适。

这种感觉和写代码还挺像的。发现问题，搭个系统解决，再发现瓶颈，再去优化。但游戏里的反馈直接得多，产量上去了，材料开始往箱子里进，整个系统跑起来，马上就能看到自己的投入有了结果。然后又有下一个目标、下一个缺口，一直有事情可以弄。

这一类游戏我玩过《缺氧》《戴森球计划》，不过体验最多、也最喜欢的，还是MC科技整合包。《水星迫降》、Nomifactory、ATM9、ATM10、GTNH、FTB Infinity，这些我都玩过。

我喜欢整合包的一个原因，是它给的解决方案很多。不同mod各有自己的一套东西，同一种资源、同一个生产目标，往往可以从不同体系里找办法。怎么把手头已经有的机器、资源用起来，怎么把几个mod接到一起，这个过程本身就很有意思。

JEI和AE2对这套体验的帮助也很大。复杂配方多，但查起来方便；仓储和自动化能接起来之后，又可以去设计更复杂的产线。要花心思的事情变成了怎么生产、怎么组合，而不是记住东西到底塞在哪个箱子里。

所以我更喜欢MC整合包，和它的方案空间有很大关系。同样一个目标，我能根据当前的条件换一种做法，也能先搭一个将就的，再慢慢把它改好。这个不断解决问题的过程，就是我玩这类游戏最有兴趣的部分。

2026-10-18 秋招XX服务端研发笔试复盘

Sat, 17 Oct 2026 20:00:00 GMT

2026-10-18 秋招XX服务端研发笔试复盘

题目一：最多换乘一次的公交最小费用

题目大意

给定起点 S、终点 T 和 n 条公交线路。每条线路的费用固定，只能顺着站点顺序乘坐，不能反向。可以直达，也可以在公共站点换乘一次，最多坐两条线路。求从 S 到 T 的最小费用，无法到达输出 -1。

我的思路

最多坐两条线路，就把路径在换乘站拆开。我用了两个哈希表：

ump[0][x]：从 S 出发，坐一条线路到 x 的最低费用；
ump[1][x]：从 x 出发，坐一条线路到 T 的最低费用。

每条线路按站点顺序读入。遇到 S 之后，把后面的站点更新进第一个表；遇到 T 时，回头把这条线路此前经过的站点更新进第二个表。如果此前已经遇到 S，这条线路也能直达，单独更新直达费用。

最后枚举换乘站 x，两边都能走通，就用 ump[0][x] + ump[1][x] 更新答案，再和直达费用比较。

代码

#include <bits/stdc++.h>
using namespace std;

const int maxm = 1e4 + 7;
const int maxn = 1e3 + 7;
const int oo = 1e9 + 7;

int S, T, n;
int c[maxn], m[maxn];
vector<int> id[maxn];
unordered_map<int ,int> ump[2];


int main() {
    scanf("%d%d%d", &S, &T, &n);
    int ans = oo;
    for(int i = 1; i <= n; i++) {
        int hass = 0;
        scanf("%d%d", &c[i], &m[i]);
        for(int j = 1; j <= m[i]; j++) {
            int tmp;
            scanf("%d", &tmp);

            if(hass) {
                if(ump[0].find(tmp) == ump[0].end()) {
                    ump[0][tmp] = c[i];
                }
                else {
                    ump[0][tmp] = min(ump[0][tmp], c[i]);
                }
            }

            if(tmp == S) {
                hass = 1;
            }
            else if(tmp == T) {
                for(int k = 0; k < j - 1; k++) {
                    if(ump[1].find(id[i][k]) == ump[1].end()) {
                        ump[1][id[i][k]] = c[i];
                    }
                    else {
                        ump[1][id[i][k]] = min(ump[1][id[i][k]], c[i]);
                    }
                }
                if(hass) {
                    ans = min(ans, c[i]);
                }
            }

            id[i].emplace_back(tmp);

        }
    }
    // printf("%d\n", ans);
    for(int i = 1; i <= 10000; i++) {
        if(ump[0][i] && ump[1][i]) {
            ans = min(ans, ump[0][i] + ump[1][i]);
        }
    }

    printf("%d\n", (ans == oo) ? -1 : ans);
    return 0;
}
// 64 位输出请用 printf("%lld")

复盘：正反两次扫描

这里可以少绕一点。原来一边读入一边处理，遇到 T 还要回头遍历，几件事挤在一起。

可以先读完整条线路，再正向、反向各扫一次。

正向扫：遇到 S 之后，更新 from[x]，表示从 S 坐一条线路到 x 的最低费用；
反向扫：遇到 T 之后，更新 to[x]，表示从 x 坐一条线路到 T 的最低费用。

最后比较 from[T] 和所有 from[x] + to[x]。直达已经包含在 from[T] 里，不用再另外维护一个答案。两个方向的处理完全对称，也不用在遇到 T 时回头枚举前面的站点。

这一题主要是把处理过程拆清楚。两张费用表的思路没变，不需要为了改写再换一套算法。

题目二：被至少 K 个区间覆盖的整数个数

题目大意

给定数轴上的 n 个闭区间 [l_i, r_i] 和一个整数 k，统计有多少个正整数位置被至少 k 个区间覆盖。

我的思路

我用了离散化加差分。这里要数的是整数点，不能直接拿离散化后的下标差当答案，所以除了区间端点，还把每个端点左右的 x-1、x、x+1 加进了坐标集合，正整数范围之外的点不加。

排好序以后，inc 把原坐标映射到离散化下标，de 再把下标映射回原坐标。每个区间在左端点加一，右端点之后减一，做前缀和得到覆盖数。

扫描时用 be 记当前满足条件的连续段起点。覆盖数低于 k 时，这一段结束，用原坐标算出整数点个数并累加；最后再处理还没结束的那一段。

整体时间复杂度是 O(nlog⁡n)O(n \log n)O(nlogn)，主要花在坐标排序上。

代码

#include <bits/stdc++.h>
#include <unordered_map>
using namespace std;

const int maxn = 1e5 + 7;
int n, k;
int l[maxn], r[maxn];
int a[maxn * 6], s[maxn * 6], b[maxn * 2];

vector<int> nums;
unordered_map<int, int> inc, de;

int main() {
    cin >> n >> k;
    for(int i = 1; i <= n; i++) {
        int x[2];
        cin >> x[0] >> x[1];
        // for(int j = 0; j <= 1; j++) {
        //     if(inc.find(x[j]) == inc.end()) {
        //         inc[x[j]] = 1;
        //         nums.emplace_back(x[j]);
        //     }
        // }
        for(int j = max(1, x[0] - 1); j <= x[0] + 1; j++) {
            if(inc.find(j) == inc.end()) {
                inc[j] = 1;
                nums.emplace_back(j);
            }
        }
        for(int j = max(1, x[1] - 1); j <= x[1] + 1; j++) {
            if(inc.find(j) == inc.end()) {
                inc[j] = 1;
                nums.emplace_back(j);
            }
        }
        l[i] = x[0], r[i] = x[1];
    }
    sort(nums.begin(), nums.end());
    for(int i = 0; i < nums.size(); i++) {
        inc[nums[i]] = i + 1;
        de[i + 1] = nums[i];
    }

    for(int i = 1; i <= n; i++) {
        l[i] = inc[l[i]], r[i] = inc[r[i]];
        a[l[i]]++;
        a[r[i] + 1]--;
    }
    int ans = 0;
    int be = 0, ed;
    for(int i = 1; i <= nums.size(); i++) {
        s[i] = s[i - 1] + a[i];
        if(s[i] >= k) {
            if(be) {

            }
            else {
                be = de[i];
            }
            // ans += (de[i + 1] - de[i]);
        }
        else {
            if(be) {
                ans += de[i - 1] - be + 1;
                be = 0;
            }
        }
        // cout << s[i];
    }
    // cout << endl;
    if(be) {
        int N = nums.size();
        ans += de[N] - be + 1;
    }
    cout << ans << endl;


    return 0;
}
// 64 位输出请用 printf("%lld")

复盘：有序差分事件扫描

这题的辅助数组和下标转换比较多。更简单的写法是：直接用 map 存覆盖数发生变化的位置，不再手写离散化。

整数闭区间 [l, r] 可以看成 [l, r+1)：在 l 处加一，在 r+1 处减一。这样相邻两个事件点之间的覆盖数不变，长度也正好对应这一段的整数点个数。

扫描到坐标 x 时，先用变化前的覆盖数判断 [last, x) 是否应该计入答案，再处理 x 处的变化。如果覆盖数已经达到 k，这一段就贡献 x - last。

时间复杂度仍是 O(nlog⁡n)O(n \log n)O(nlogn)。省下的是实现和调试的麻烦，不是换了更低复杂度的算法。

#include <bits/stdc++.h>
using namespace std;

int main() {
    int n, k;
    cin >> n >> k;

    map<long long, int> diff;

    for (int i = 0; i < n; i++) {
        long long l, r;
        cin >> l >> r;
        diff[l]++;
        diff[r + 1]--;
    }

    long long ans = 0, last = 0;
    int cnt = 0;

    for (auto [x, d] : diff) {
        if (cnt >= k) {
            ans += x - last;
        }
        cnt += d;
        last = x;
    }

    cout << ans << '\n';
}

题目三：RGB 灯带的最少删除次数

题目大意

给两条 RGB 灯带，用只含 R、G、B 的字符串表示。每次可以从任意一条灯带中删除一个灯，剩余灯保持原来的相对顺序。要求最终两条灯带完全相同，而且相邻的灯颜色不同，求最少删除次数。

下面按允许最终保留空串、求最少删除次数来讨论。

我的思路

我直接把状态定义成最少删除次数。f[i][j][k] 表示处理 S 的前 i 个字符和 T 的前 j 个字符，得到相同序列、最后一个保留颜色为 k 时的最少删除次数。

转移按当前两个字符是否相同来分：

颜色相同，可以一起保留，但前一个保留的颜色必须不同；如果当前状态保留的是其他颜色，就把这两个字符一起删掉；
颜色不同，可以删掉其中一个，或者两个都删掉，再从对应的状态转移。

代码里用 x[4][4] 和 xx[4][4] 查另外的颜色。边界状态把其中一条前缀全删掉，代价就是前缀长度；这些边界中的颜色编号是转移占位，不表示空串里真的有这个颜色的灯。

颜色只有三种，时间和空间复杂度都是 O(nm)O(nm)O(nm)。

代码

#include <bits/stdc++.h>
using namespace std;

const int maxn = 2e3 +7;
const int oo = 1e9 + 7;
int n, m;
int a[maxn], b[maxn];
int f[maxn][maxn][4];
int x[4][4];
int xx[4][4];

int tr(char c) {
    if(c == 'R') return 1;
    if(c == 'G') return 2;
    if(c == 'B') return 3;
    return -1;
}

int main() {
    x[1][0] = 2, x[1][1] = 3;
    x[2][0] = 1, x[2][1] = 3;
    x[3][0] = 1, x[3][1] = 2;
    xx[1][2] = 3, xx[2][1] = 3;
    xx[1][3] = 2, xx[3][1] = 2;
    xx[3][2] = 1, xx[2][3] = 1;
    string S, T;
    cin >> S;
    cin >> T;
    n = S.size();
    m = T.size();
    for(int i = 1; i <= n; i++) {
        a[i] = tr(S[i - 1]);
    }
    for(int i = 1; i <= m; i++) {
        b[i] = tr(T[i - 1]);
    }

    for(int i = 1; i <= n; i++) {
        for(int j = 1; j <= m; j++) {
            for(int k = 1; k <= 3; k++) {
                f[i][j][k] = oo;
            }
        }
    }

    for(int i = 1; i <= n; i++) {
        for(int k = 1; k <= 3; k++) {
            f[i][0][k] = i;
        }
    }
    for(int i = 1; i <= m; i++) {
        for(int k = 1; k <= 3; k++) {
            f[0][i][k] = i;
        }
    }
    for(int i = 1; i <= n; i++) {
        for(int j = 1; j <= m; j++) {
            if(a[i] == b[j]) {
                for(int k = 1; k <= 3; k++) {
                    if(k == a[i]) {
                        for(int h = 0; h <= 1; h++) {
                            f[i][j][k] = min(f[i][j][k] , f[i - 1][j - 1][x[k][h]]);
                        }
                    }
                    else {
                        f[i][j][k] = min(f[i][j][k], f[i - 1][j - 1][k] + 2);
                    }
                }
                // f[i][j][a[i]] == 
            }
            else {
                f[i][j][a[i]] = min(f[i][j][a[i]], f[i][j - 1][a[i]] + 1);
                f[i][j][b[j]] = min(f[i][j][b[j]], f[i - 1][j][b[j]] + 1);
                int tmp = xx[a[i]][b[j]];
                f[i][j][tmp] = min(f[i][j][tmp], f[i - 1][j - 1][tmp] + 2);
                
            }
        }
    }
    int ans = oo;

    // for(int i = 0; i <= n; i++) {
    //     for(int j = 0; j <= m; j++) {
    //         cout << " (";
    //         cout << f[i][j][1] << ", " << f[i][j][2] << ", " << f[i][j][3];
    //         cout << ") ";
    //     }
    //     cout << endl;
    // }

    for(int i = 1; i <= 3; i++) {
        ans = min(ans, f[n][m][i]);
        // cout << f[n][m][i] << endl;
    }
    cout << ans << endl;
    return 0;
}
// 64 位输出请用 printf("%lld")

复盘：换成求最多保留多少个灯

也可以反过来想：不枚举删掉哪些灯，而是找最终能保留的最长序列。它必须同时是两条灯带的子序列，而且相邻颜色不同，也就是带这个限制的最长公共子序列。

设 dp[i][j][c] 表示从 S 前 i 个字符和 T 前 j 个字符中，选出的以颜色 c 结尾的最长合法公共子序列长度。转移就分成三种：

不选 S 的当前字符，从 dp[i-1][j][c] 转移；
不选 T 的当前字符，从 dp[i][j-1][c] 转移；
两个字符相同，可以一起选，但前一个颜色必须和当前颜色不同。

如果最长能保留 L 个灯，两条灯带一共就能保留 2L 个，最少删除次数是 n + m - 2L。

时间、空间复杂度仍是 O(nm)O(nm)O(nm)，但不需要 INF 和颜色映射表，转移也少了很多删除分支。

#include <bits/stdc++.h>
using namespace std;

int dp[2005][2005][3];

int color(char c) {
    if (c == 'R') return 0;
    if (c == 'G') return 1;
    return 2;
}

int main() {
    string S, T;
    cin >> S >> T;

    int n = S.size(), m = T.size();

    for (int i = 1; i <= n; i++) {
        for (int j = 1; j <= m; j++) {

            for (int c = 0; c < 3; c++) {
                dp[i][j][c] = max(
                    dp[i - 1][j][c],
                    dp[i][j - 1][c]
                );
            }

            if (S[i - 1] == T[j - 1]) {
                int c = color(S[i - 1]);

                for (int k = 0; k < 3; k++) {
                    if (k != c) {
                        dp[i][j][c] = max(
                            dp[i][j][c],
                            dp[i - 1][j - 1][k] + 1
                        );
                    }
                }
            }
        }
    }

    int L = *max_element(dp[n][m], dp[n][m] + 3);
    cout << n + m - 2 * L << '\n';
}

如果要求至少保留一个灯，需要额外处理不存在合法非空公共子序列的情况。

《终焉的莉莉丝》：19小时全成就之后

Fri, 16 Oct 2026 20:00:00 GMT

《终焉的莉莉丝》：19小时全成就之后

《终焉的莉莉丝》大概玩了五六天，19小时全成就。我对它的评价很高。量足够，地图中规中矩，整个游戏玩下来，大体没有让我觉得不好的地方。

中规中矩、差强人意，往坏点说可以用这两个词。但放在这里，我觉得都是很好的评价。现在连很多有经验的制作组都会在游戏里弄出一些扣分项，能把整个流程做好，不犯什么错，已经很不容易了。当然，莉莉丝也有一个例外，后面说。

它给我的一个很明显的感觉是协调。美术、人物的战斗方式、剧情，甚至游戏模式，都能放在一起。画面好看，整体风格也统一。之前玩《心渊梦境》时也觉得美术很好，不过有时会有一点不统一；莉莉丝在这方面给我的感觉更好。

剧情也和这种气质合得上。碎片化叙事是真的碎片化，不会为了碎片化硬把东西拆开，又不会讲得很谜语。故事比较简单，悲剧基调贯彻得很好，没有强行大团圆，也没有强行洗白。有些刀还是有点公式化，但整个剧情没有爆雷。见过太多剧本有雷点的作品之后，“没有爆雷”对我来说也算一个好评价。

地图设计基本就是中规中矩。唯一让我觉得稍微有一点失控的是禁区，里面有一两条路，通向主线必须开启的机关，但藏的位置让我觉得更像支线道具、全收集道具会藏的地方。主线藏到这个程度，我觉得算一处失误。其他地方都还好。

探索和全收集的平衡我挺喜欢。地图会标出一个房间有没有搜完，至少我知道还要不要在这里继续找。如果能有地形图，而不是每个房间只有一个框，可能会更好。不过现在这种提示程度也挺合适：不用像金刚狼一样给每个宝箱都开提示，不然干嘛还要收集、还要探索？东西藏得也不错，自己仔细一点就能发现，找到的时候会开心，很少让我觉得是在硬藏。

战斗和跳跃手感确实有些奇怪，这大概是它比较薄弱的地方。但我觉得制作组知道这一点，关卡也没有一直逼着我用这些不太舒服的操作。基本没什么跳跳乐，只有一两处可能算跑酷，也主要靠钩索，给的空间比较宽裕。

Boss也是这样。招式明显，就那么几招，死几次基本就记住了。不过招数有限，也不妨碍中间有一些有记忆点、有难度、有挑战的Boss战。我玩得很满意。一个战斗和跳跃手感偏弱的游戏，没有塞进非得靠很好的战斗、跳跃手感才能应付的东西，这一点做得很好。

我是全成就党，莉莉丝的全成就也比较舒服。流程不长，除了100级，其他成就基本不看攻略就能完成。我打完流程还没到100级，最后找了一处刷魂的地方，跑了十次左右，大概二十分钟就刷完了，这个量我可以接受。

如果打算全成就，做全收集时可以顺手把沿途的怪都打了。全收集反正要反复跑图，没必要一直跳怪，加经验的手段也别忘记用。

2026-10-14 秋招XX AI测试开发一面复盘

Tue, 13 Oct 2026 20:00:00 GMT

2026-10-14 秋招XX AI测试开发一面复盘

10月14日晚参加了AI测试开发的一面。自我介绍之后主要聊项目，中间穿插了Linux、MySQL和AI辅助研发流程的问题。下面按问题整理参考回答。

如何跟踪持续增长的日志

场景是程序不断往一个日志文件里写内容，希望在终端里持续看到新增日志。

可以用：

tail -f app.log

tail 默认显示最后10行，-f 会继续跟踪文件末尾的新内容。如果想先看最近100行，再继续跟踪，可以写成：

tail -n 100 -f app.log

如果日志会轮转，比如原文件被改名，程序又创建了一个同名日志文件，更适合用：

tail -F app.log

GNU tail 的 -f 默认跟踪已经打开的文件描述符，原文件改名后仍可能继续跟着旧文件。-F 相当于 --follow=name --retry，会按文件名跟踪，并在文件暂时不存在时继续尝试打开，适合这种日志轮转场景。GNU Coreutils：tail

如何查看当前内存占用

先分清想看整台机器的内存，还是某个进程的内存。

看系统整体内存，可以用：

free -h

-h 会用较容易读的单位展示物理内存、交换空间等信息。判断还能分配多少内存时，可以关注 available，它估算的是不使用交换空间时，可供新应用使用的内存，不能只看 free 一列。procps-ng：free

想看哪些进程占用较多，可以用 top 动态观察，也可以直接按内存占比排序：

top -o %MEM

进程列表里的 RES 是驻留物理内存，%MEM 是它占整机物理内存的比例；VIRT 是虚拟内存大小，不能直接当作实际占用的物理内存。procps-ng：top

如果已经知道进程ID，只想看它当前的内存信息，可以用：

ps -p 1234 -o pid,comm,%mem,rss,vsz

这里的 1234 换成实际进程ID。rss 是驻留物理内存大小，vsz 是虚拟内存大小，单位都是KiB。ps 给的是查询时的快照；需要持续观察变化时，用 top 更方便。procps-ng：ps

MySQL中HAVING和WHERE有什么区别

WHERE 在分组前过滤行，决定哪些记录参与后续分组和统计；HAVING 对分组后的结果做过滤，可以使用 COUNT、SUM 等聚合结果作为条件。MySQL：SELECT

比如，想统计每个部门工资超过10000的员工人数，并且只保留这类员工超过5人的部门，可以写：

SELECT department, COUNT(*) AS employee_count
FROM employees
WHERE salary > 10000
GROUP BY department
HAVING COUNT(*) > 5;

先由 WHERE 筛出工资超过10000的员工，再按部门分组，最后由 HAVING 筛出计数超过5的部门。这里数的是每个部门中工资符合条件的人，不是部门总人数。

像 salary > 10000 这样针对单条记录的条件放在 WHERE；像 COUNT(*) > 5 这样针对当前分组聚合结果的条件放在 HAVING，不能直接拿到同一层查询的 WHERE 里用。

AI Coding、代码审查与研发流程

项目部分还问到了AI辅助开发工具，以及它们在整套研发流程里分别做什么。

AI Coding主要帮助开发者生成、修改和理解代码，也可以辅助调试和编写测试。CR通常指Code Review，也就是代码审查，主要围绕一组代码变更检查问题。两者有交集，但关注点不同：写出修改是一件事，检查这次修改是否合适、会不会引入问题，是另一件事。

代码审查通常围绕PR或MR进行：开发者提交变更，发起合并请求，审查者阅读差异、提出意见，开发者再修改。审查通过并满足项目的其他合并条件后，才进入合并环节。GitHub：Pull request reviews

AI可以辅助找出潜在问题，但审查意见还需要结合代码上下文判断，也需要测试验证。一次审查给出了建议，并不等于问题已经修复。

如果要把代码审查接入工单流程，还需要记录问题对应的代码位置、处理人和状态，在修复后重新检查，确认原问题是否解决。这样才能从“给出一份审查意见”继续走到“跟踪问题的处理结果”。这也是介绍这类项目时需要说明的部分：模型负责什么，流程负责什么，最后怎样确认问题处理完成。

2026-10-11 秋招XX笔试复盘：相同元素的间隔重排

Sat, 10 Oct 2026 20:00:00 GMT

2026-10-11 秋招XX笔试复盘：相同元素的间隔重排

题目：重排数组，让相同元素保持距离

题目大意

重排数组，使相同元素的下标差至少为 kkk，无法构造输出 -1。下面按 k≥1k\ge1k≥1 讨论。

这里的“间隔 kkk”是下标差至少为 kkk，中间至少隔 k−1k-1k−1 个元素，也就是任意连续 kkk 个元素互不相同。比如 n=7,k=3n=7,k=3n=7,k=3，数组 1 1 1 2 2 3 3 可以排成 1 2 3 1 2 3 1。

我当时的想法

我先统计频次，把不同数字按剩余次数排序，每轮取前 kkk 种。用完以后减少频次，再视情况排序。

我还做了两个优化：次数归零的数字退出后续排序；每轮只比较第 kkk 和第 k+1k+1k+1 个元素，只有这里出现逆序时才重新排。在完整取出 kkk 种数的一轮中，前 kkk 个计数同时减一，内部顺序不会变，后面元素的顺序也没变，新的逆序只能出现在两部分的边界。比较第 k+1k+1k+1 项还要先保证剩余种类数大于 kkk。

这能少排一些次，但最坏情况仍要反复全量排序。例如 n=200000n=200000n=200000、k=2k=2k=2，有100000种数、每种出现两次。前近50000轮会触发排序，却没有一种数字被彻底用完。

思路分析

统计每个数字的剩余次数，用大根堆存当前可以使用的数字。每次优先放剩余次数最多的那一种，避免高频数字拖到后面挤不下。

一个数字在位置 iii 用过以后，下一次最早只能放在 i+ki+ki+k。把它的剩余次数和解禁位置放进冷却队列，到位置了再放回堆里。由于每次解禁位置都是当前下标加固定的 kkk，队列本身就是按解禁时间排序的，不需要再用一个堆。

每放一个数，就严格执行“解禁、选数、重新冷却”这三个步骤。如果还没填完，堆却空了，说明剩余数字都不能放在当前位置，返回无法构造。

这个写法把距离条件直接落实到位置，不需要反复对全部不同数字排序，也不用预先猜可行性。每个元素对应一次出堆和至多一次入堆，设不同数字有 mmm 种，时间复杂度 O(nlog⁡(m+1))O(n\log(m+1))O(nlog(m+1))。堆和冷却队列共用 O(m)O(m)O(m) 空间，保存输出另外需要 O(n)O(n)O(n)。

参考代码

构造失败时输出 -1，成功时输出 ans；不要求字典序最小或最大。

#include <bits/stdc++.h>
using namespace std;

// 相同数的下标差至少为 k，k >= 1。
// 成功时返回 true 并写入 ans，失败返回 false。
bool rearrange(const vector<int>& a, int k, vector<int>& ans) {
    ans.clear();
    if (k <= 1) {
        ans = a;
        return true;
    }

    map<int, int> freq;
    for (int x : a) ++freq[x];
    priority_queue<pair<int, int>> available;  // 剩余次数、数值
    for (auto [x, count] : freq)
        available.push({count, x});

    // 解禁位置、剩余次数、数值，解禁位置按入队顺序递增。
    queue<tuple<long long, int, int>> cooling;
    ans.reserve(a.size());
    for (long long pos = 0; pos < (long long)a.size(); ++pos) {
        while (!cooling.empty() && get<0>(cooling.front()) <= pos) {
            auto [ready, count, x] = cooling.front();
            cooling.pop();
            available.push({count, x});
        }
        if (available.empty()) return false;

        auto [count, x] = available.top();
        available.pop();
        ans.push_back(x);
        if (--count > 0)
            cooling.push({pos + k, count, x});
    }
    return true;
}

2026-10-10 秋招XX笔试复盘：因数统计与小偷分配

Fri, 09 Oct 2026 20:00:00 GMT

2026-10-10 秋招XX笔试复盘：因数统计与小偷分配

第一题：因数统计

题目大意

给定 nnn、QQQ 和数组 AAA，其中 n≤2×105n\le2\times10^5n≤2×105，数组元素在 0∼1060\sim10^60∼106。有 QQQ 个询问，每次给一个 KKK，问有多少个正整数 ddd 能整除数组里至少 KKK 个数。

下面按有限候选范围 1≤d≤1061\le d\le10^61≤d≤106、1≤K≤n1\le K\le n1≤K≤n 写参考实现。如果候选正因子没有上界，且数组中至少有 KKK 个0，答案就会是无穷多，因为所有正整数都能整除0。

我当时的想法

我先筛出每个数的全部因数，存成 vector<int> factor[1000001]，再遍历数组，对每个数的因子累加计数，最后按整除数量做后缀和。

思路分析

先统计每个数出现多少次，记为 freq[x]。固定一个候选因子 ddd，它能整除的正数就是 d,2d,3d,…d,2d,3d,\ldotsd,2d,3d,…，所以枚举这些倍数，把出现次数加起来。

与给每个数存整张因数表相比，这样只保存频次数组，不需要一百万个 vector，也没有逐个扩容和保存所有因数的开销。所有倍数循环的总次数是

∑d=1M⌊Md⌋=O(Mlog⁡M)\sum_{d=1}^{M}\left\lfloor\frac{M}{d}\right\rfloor=O(M\log M)d=1∑M⌊dM⌋=O(MlogM)

算出每个 ddd 的整除数量后，再统计“恰好整除 ttt 个数”的因子有几个，对这个数组做后缀和。询问至少 KKK 个，就能直接查表。

如果数组里有 0，每个候选正因子都要额外加上 freq[0]。这也是不能从 factor[0] 里找因数的原因。

总时间复杂度 O(n+Mlog⁡M+Q)O(n+M\log M+Q)O(n+MlogM+Q)，空间复杂度 O(M+n)O(M+n)O(M+n)。

参考代码

候选正因子限定在 [1,M]，代码同时处理数组中的 0。

#include <bits/stdc++.h>
using namespace std;

// 条件：a[i] 在 [0, M]，候选正因子 d 限定在 [1, M]。
// 返回 answer[k]：能整除至少 k 个数组元素的候选 d 的个数。
vector<int> divisorAnswers(const vector<int>& a, int M) {
    int n = a.size();
    vector<int> freq(M + 1, 0);
    for (int x : a) ++freq[x];

    vector<int> answer(n + 2, 0);
    for (int d = 1; d <= M; ++d) {
        int count = freq[0];  // 任意正整数都整除 0。
        for (int x = d; x <= M; x += d)
            count += freq[x];
        ++answer[count];
    }
    for (int k = n - 1; k >= 0; --k)
        answer[k] += answer[k + 1];
    return answer;
}

// auto answer = divisorAnswers(a, 1000000);
// 对 1 <= K <= a.size() 的询问，直接读取 answer[K]。

第二题：小偷分配

题目大意

最大 1000×10001000\times10001000×1000 的方格，每格有小偷，警察从 (1,1)(1,1)(1,1) 出发。警察和小偷都只能向右或向下，到最后一行强制停止。所有小偷先走完，警察再走，最终抓走停留格子里的全部小偷，问警察最多能抓多少。

每个小偷可以独立选择路径。下面按小偷整体协作、尽量减少警察最终抓捕人数的 min-max 模型分析；若改成每个人分别最大化自己的生存概率，还需要约定警察在并列最优时怎样选列。

我当时的想法

我先把网格压成两行：前 n−1n-1n−1 行按列相加，最后一行单独留下。再从右往左处理，尽量把可达位置中人数较少的列填平，而不是只看一个总平均。

思路分析

只看每一列，不必保留上方小偷具体在哪一行。记前 n−1n-1n−1 行的人数和为 UjU_jUj，最后一行的人数为 BjB_jBj，总和为 Sj=Uj+BjS_j=U_j+B_jSj=Uj+Bj。

BjB_jBj 已经在最后一行，不能移动。上方每个小偷都可以停在不小于自己初始列号的任意列。所以问题变成：把第 jjj 列的 UjU_jUj 个人分配到右侧各列，使最终最高的一列尽可能低。

假设能把每列都压到不超过 TTT，必须满足两类限制：

底座不能移动，所以每个 Bj≤TB_j\le TBj≤T。
第 jjj 列到最后一列的人不能跑到左边，所以这个后缀的总人数不能超过后缀的总容量，即 ∑t=jn−1St≤(n−j)T\sum_{t=j}^{n-1}S_t\le(n-j)T∑t=jn−1St≤(n−j)T。

这些限制也足够。先把底座放好，每列还剩 T−BjT-B_jT−Bj 个位置，再从右往左安排可移动的人。处理第 jjj 列时，右边已经安排的人只消耗右边容量；后缀限制保证第 jjj 列剩下的人仍有地方放。

因此答案是

max⁡(max⁡jBj, max⁡j⌈∑t=jn−1Stn−j⌉)\max\left(\max_j B_j,\ \max_j\left\lceil\frac{\sum_{t=j}^{n-1}S_t}{n-j}\right\rceil\right)max(jmaxBj, jmax⌈n−j∑t=jn−1St⌉)

底座这一项不能省。例如 U=[0,0,0]U=[0,0,0]U=[0,0,0]、B=[100,0,0]B=[100,0,0]B=[100,0,0]，总人数虽然能除以 3，但第一列那 100 个人根本不能动。只看整体平均同样不够：U=[0,20]U=[0,20]U=[0,20]、B=[0,0]B=[0,0]B=[0,0] 时，右边的 20 个人无法向左分，答案仍是 20。

读入网格要 O(n2)O(n^2)O(n2)，之后计算答案只要 O(n)O(n)O(n)，除网格外的空间为 O(n)O(n)O(n)。人数合计用 long long。

参考代码

下面按后缀容量公式实现。

#include <bits/stdc++.h>
using namespace std;

// n*n 网格，人数非负；按小偷整体协作的 min-max 模型计算。
long long minCaught(const vector<vector<long long>>& grid) {
    int n = grid.size();
    vector<long long> total(n, 0);
    long long answer = 0;
    for (int i = 0; i < n; ++i) {
        for (int j = 0; j < n; ++j)
            total[j] += grid[i][j];
    }
    for (int j = 0; j < n; ++j)
        answer = max(answer, grid[n - 1][j]);

    long long suffix = 0;
    for (int j = n - 1; j >= 0; --j) {
        suffix += total[j];
        long long columns = n - j;
        long long ceiling = suffix / columns + (suffix % columns != 0);
        answer = max(answer, ceiling);
    }
    return answer;
}

《雪山飞狐》的结尾，还是像没写完

Fri, 02 Oct 2026 20:00:00 GMT

《雪山飞狐》的结尾，还是像没写完

读完《雪山飞狐》，我最直接的感受就是差了一点。故事已经走到这里了，再往后写一点，前面的事情就可以收住，偏偏停了下来。我知道这是一个开放式结尾，但读到最后，还是觉得像没写完。

按前文的发展，苗人凤和胡斐之间的误会已经基本可以解开，两家的恩怨也应该有个了结。胡斐和苗若兰的关系又写得很明确。在我看来，接下来合理的方向几乎只有一种：恩怨了结，胡斐娶苗若兰。读到这里，我已经很难再往别的方向想了。

所以这个结尾留给我的感觉有点别扭。前面已经把事情解释到这个程度，人物之间的关系也走到了这里，最后却没有把它写完。我能想象后面会发生什么，但那个方向太明确了，留给我想象的余地反而没有那么多。

我觉得好的开放式结尾，应该有几个都说得通的走向。顺着人物和前面的故事想下去，走向这一边合理，走向另一边也合理，读者才会在这些可能之间犹豫。《雪山飞狐》在我这里没有形成这种感觉。我顺着前文去想，还是会回到两家化解恩怨、胡斐和苗若兰在一起的结局上。

作者当然可以选择留白。但留下来的这一段到底有没有意思，还是要看读者读到这里是什么感受。就我自己而言，理解它是开放式结尾之后，那种“就差一点，怎么停在这里了”的感觉也没有消失。

2026-09-27 秋招XX笔试复盘：矩阵连通块与DFS状态

Sat, 26 Sep 2026 20:00:00 GMT

2026-09-27 秋招XX笔试复盘：矩阵连通块与DFS状态

题目：两个01矩阵中的完全匹配区域

题目大意

给定两张最大为 100×100100\times100100×100 的 01 矩阵，求 exact-match area 的个数。区域按上下左右四连通，要求两张图里的整块完全一致：位置都是 1，且不存在只在某一张图里向外延伸的部分。

我当时的想法

我从两张图都为 1 的位置开始搜。如果相邻位置出现一边是 1、一边是 0，这一块就不算完全匹配。

思路分析

把两张图中“至少有一张是 1”的格子放到同一张图里，按上下左右遍历连通块。

对一个这样的连通块，只要有一个位置两张图不同，它就不能算完全匹配。如果每个位置都相同，那么整块都是双 1，在两张图里也都没有额外伸出去的部分，答案加一。

这样，搜索只做两件事：访问完整个连通块，再记录这一块有没有不一致的位置。vis 表示这个格子已经处理过，设为真以后就不恢复。这里不需要当前路径状态。

即使已经发现不匹配，也要把整块走完。递归写法不能直接用 ok = ok && dfs(...)，因为 ok 为假时会短路，后面的格子就没有被标记。可以先调用 DFS，再合并返回值。下面直接用栈遍历，避免长连通块带来的递归深度问题。

每个格子最多入栈一次，时间、空间复杂度都是 O(nm)O(nm)O(nm)。

参考代码

下面用栈遍历，两张矩阵的行列数相同。

#include <bits/stdc++.h>
using namespace std;

int countMatches(const vector<string>& a, const vector<string>& b) {
    int n = a.size();
    if (n == 0) return 0;
    int m = a[0].size();
    vector<vector<bool>> vis(n, vector<bool>(m, false));
    const int dx[4] = {1, -1, 0, 0};
    const int dy[4] = {0, 0, 1, -1};
    int ans = 0;

    for (int i = 0; i < n; ++i) {
        for (int j = 0; j < m; ++j) {
            if (vis[i][j] || (a[i][j] == '0' && b[i][j] == '0'))
                continue;

            bool ok = true;
            vector<pair<int, int>> st = {{i, j}};
            vis[i][j] = true;
            while (!st.empty()) {
                auto [x, y] = st.back();
                st.pop_back();
                if (a[x][y] != b[x][y]) ok = false;

                for (int d = 0; d < 4; ++d) {
                    int nx = x + dx[d], ny = y + dy[d];
                    if (nx < 0 || nx >= n || ny < 0 || ny >= m)
                        continue;
                    if (vis[nx][ny]) continue;
                    if (a[nx][ny] == '0' && b[nx][ny] == '0')
                        continue;
                    vis[nx][ny] = true;
                    st.push_back({nx, ny});
                }
            }
            if (ok) ++ans;
        }
    }
    return ans;
}

2026-09-24 秋招XX笔试复盘：连通图计数与去重

Wed, 23 Sep 2026 20:00:00 GMT

2026-09-24 秋招XX笔试复盘：连通图计数与去重

题目：哪些下标对能构成连通简单图

题目大意

给出 T 组数据。每组有长度分别为 N、M 的数组 A、B。从两边各选一个下标 i,j，把 A[i]、B[j] 中一个当作节点数，另一个当作边数。只要有一种分配能构成无自环、无重边、连通的无向图，这个下标对就计一次。

统计的是下标对，所以相同数值出现在不同位置，也要分别计数。

两组样例：A=[1,2,3]、B=[1,2,3]，答案为 5；A=[4,5]、B=[2,3]，答案为 1。以下按“两个数可交换点数与边数角色，任一方向合法就计一次”理解。

思路分析

如果点数为 V≥1，边数为 E，连通简单无向图存在的条件是

V−1≤E≤V(V−1)2.V-1\le E\le\frac{V(V-1)}2.V−1≤E≤2V(V−1).

下界是一棵树，上界是完全图。在树上逐条补边，就能得到中间任意边数。

我当时就是先找这个区间，再排序二分。让 A[i] 作点数，在 B 中查合法边数；然后反过来，让 B[j] 作点数，在 A 中查。每个方向都好算，关键是两边都合法时只能计一次。

设 x=A[i]、y=B[j]，双向合法至少要求 y≥x-1 且 x≥y-1，因此 |x-y|≤1。再代入完全图的上界：

x=y：只有 x≥3 时双向合法。
相差 1：令较小值为 t，要满足 t+1≤t(t-1)/2，对正整数等价于 t≥4。

所以交集恰好是相等且至少为 3 的数对，以及相差 1、较小值至少为 4 的数对。

例如 (4,5)：4 个点 5 条边可以，5 个点 4 条边也可以。两遍扫描会把同一个下标对算两次，不能只减掉相等值。第一组样例的交集恰好只有 (3,3)，没有覆盖这个边界。

最后按容斥计算：A 作点数的数量＋B 作点数的数量－双向都合法的数量。对每个 A[i] 分别查询 B 中的相等值和相邻值频次，就能把交集减干净。

排序加二分的时间复杂度为 O(N log N+M log M+N log M+M log N)，保存数组需要 O(N+M) 空间。答案可能达到 NM，使用 long long。完全图上界的乘法用 __int128，避免先溢出再比较。

参考代码

两遍都完整统计，再统一扣掉交集。图至少有一个节点，答案及中间计数用 long long 保存。

#include <bits/stdc++.h>
using namespace std;
using ll = long long;

ll count_pairs(vector<ll> a, vector<ll> b) {
    sort(a.begin(), a.end());
    sort(b.begin(), b.end());

    auto count_range = [](const vector<ll>& v, ll l, ll r) -> ll {
        if (l > r) return 0;
        return upper_bound(v.begin(), v.end(), r)
             - lower_bound(v.begin(), v.end(), l);
    };
    auto count_direction = [&](const vector<ll>& nodes,
                               const vector<ll>& edges) -> ll {
        ll ans = 0;
        for (ll x : nodes) {
            if (x < 1) continue;
            __int128 bound = (__int128)x * (x - 1) / 2;
            ll r = bound > LLONG_MAX ? LLONG_MAX : (ll)bound;
            ans += count_range(edges, x - 1, r);
        }
        return ans;
    };

    ll ans = count_direction(a, b) + count_direction(b, a);
    for (ll x : a) {
        if (x >= 3) ans -= count_range(b, x, x);
        if (x >= 4 && x < LLONG_MAX)
            ans -= count_range(b, x + 1, x + 1);
        if (x >= 5) ans -= count_range(b, x - 1, x - 1);
    }
    return ans;
}

离散化与双指针

如果重复值很多，可以先离散化成 value → count，每个值只处理一次。用频次前缀和查询 [x-1,x(x-1)/2] 的个数，再乘当前值的出现次数。

交集也按频次扣：相等值 x≥3 减 cntA[x]×cntB[x]；相邻值 x,x+1 且 x≥4，减 cntA[x]×cntB[x+1] 和 cntA[x+1]×cntB[x]。

排序后，合法区间的左右边界还都随点数单调增加，也可以用双指针把每个方向的统计降到 O(N+M)。整体仍要先排序。几种写法的核心都一样：先把两个方向和交集分别定义清楚，再选查询工具。

How to Fish：流程很短，但它确实做到了好玩

Thu, 17 Sep 2026 20:00:00 GMT

How to Fish：流程很短，但它确实做到了好玩

最近聊到多人联机游戏，我会想到How to Fish。它流程很短，定位也很明确，就是让几个朋友一起搞笑。我觉得它做到了。

把鱼钓上来还不算完，你还得亲手把它杀掉，用刀也好，用枪也好，还可以做花式。这个点子本身就让人眼前一亮。钓鱼和上钩之后的处理，组合起来确实有自己的玩法，不只是换个场地让大家站在一起聊天。

它也做了一些不同的关卡，有各种搞耍的鱼，队友被鱼打死这件事看起来就很好笑。几关玩下来，至少每一关都有可玩的东西，也给大家创造了一些爆笑名场面的机会。

我觉得这对这种游戏很重要。关系好的朋友聚在语音里，玩什么都有可能开心，但游戏本身还是得提供点东西。How to Fish确实有一些设计，能让大家在一起玩的时候发生好笑的事。这一点我认可。

我自己也想做游戏，所以看它还有另一层兴趣：这么小的一个点子，怎么就能撑起一款好玩的游戏？哪些东西可以省，哪些地方又必须花心思？它的流程、体量和玩法组合，都很值得研究。

但我也不觉得研究完就能照着做一个，然后复制它的火爆。这里面肯定有偶然性，不能因为它成功了，就把同样的体量、同样的搞笑定位当成成功公式。

所以我之前说它很值得学习，又不值得学习，大概就是这个意思。它怎么用一个简单的点子做出好玩的过程，我想学；至于这样做出来就一定能火，那肯定不是。

《大步走》里让我觉得神的两个谜题

Thu, 10 Sep 2026 20:00:00 GMT

《大步走》里让我觉得神的两个谜题

通关《大步走》之后，我对它的评价非常高。地图很大，游戏里没有任何野怪，麦克风能传到的距离又非常近。这些东西可能会被人诟病，但制作组敢这样做，我挺喜欢它表现出来的追求和气质。整体有点像多人版的《The Witness》。

最让我觉得神的有两个谜题。

一个是运板子。我们到比较后期才发现这个谜题，发现之后，才知道要从世界各地把板子运过来。之前已经走过那么多地方，这时候又得回去，重新想这些地方要怎么联系起来，交通工具怎么用会更高效。

另一个是高尔夫。游戏里有两个高尔夫球谜题，一个简单版，一个加强版。玩加强版的时候，我们一开始找不到球的初始位置，后来才反应过来：球还是简单版的那个球，初始位置根本没变，只是这次要把它运到很远的地方。

那时已经到游戏末期，我们对整张地图都有了解了，于是就得规划怎么利用交通工具，把球运到新的目的地。这个过程我觉得特别好。两个谜题都会让我重新返回地图，再想一遍这些交通工具该怎样把不同地方沟通起来。

可惜这样的谜题不算多，按我的感觉，大概只占整个流程的三分之一到四分之一。其他一些谜题也能达到优秀合作解谜游戏的水平，但也有一些会平庸一点。

我有时会想，如果它放弃这些追求，做成一个关卡制的解谜游戏，或者干脆把东西放近一点，受众会不会更多？不过真这样做，可能又失去《大步走》的真谛了。

有些内容，放在别的地方，以同样形式让我玩，我肯定不会玩。但放在这里，跟这个游戏的气质合得上，恰好就显得很好玩。

2026-09-10 秋招XX AI应用开发一面复盘

Wed, 09 Sep 2026 20:00:00 GMT

2026-09-10 秋招XX AI应用开发一面复盘

这场面试从项目聊起，接着问了 Agent 框架、Redis 和 MySQL，最后是一道链表重排。按问题把思路和参考回答记一下。

项目里最大的困难是什么

自我介绍之后，面试官让我介绍项目，并追问项目里遇到的最大困难。

我讲的是工单状态变化之后触发审核这一环。最初想用状态判断和固定流程把逻辑写出来，后来发现，有些步骤需要结合工单上下文判断，分支也比较多，于是考虑把其中一部分决策交给 Agent，根据当前状态、上下文和已有工具决定下一步做什么。

这个例子要说清楚哪一部分需要模型。固定规则可以继续写成普通代码，比如审核权限、必填项、允许流转的状态；Agent 在允许的范围内判断下一步、选择工具，需要人工确认时再停下来。不能因为用了 Agent，就把明确的业务约束也都交给模型临场决定。

Hook 是什么

Hook 可以理解为框架在特定执行位置留下的扩展点。流程运行到这里，就调用预先注册的逻辑。例如，模型请求前补充上下文，请求后记录结果，工具调用前检查参数。

放到 Agent 里，主流程仍然是调用模型、执行工具、把结果交回模型。Hook 用来在这些步骤前后插入处理。以当前 LangChain 为例，middleware 就通过这类钩子实现日志、提示词调整、重试等功能。具体能改哪些状态、能否中断执行，要看框架给出的接口。官方说明

LangChain、LangGraph、Deep Agents 怎么分工

按目前的文档，可以从三层来理解：

LangChain 提供模型、工具等常用接口，以及现成的 Agent 构建方式，减少接不同模型和工具时的重复代码。
LangGraph 更关注执行流程。用状态、节点和边组织任务，适合把固定步骤和模型决策放在同一个流程里；需要时再配置持久化、暂停和恢复等能力。它也可以独立使用，不要求整个项目都通过 LangChain 搭建。LangGraph 官方说明
Deep Agents 在这些基础上提供更完整的 Agent 执行配套，包括任务规划、文件工具、子 Agent 和上下文管理。当前 SDK 建立在 LangChain 组件之上，使用 LangGraph 运行时。Deep Agents 官方说明

再追问 Deep Agents，可以从一个具体问题讲：任务长了以后，所有材料和工具结果都塞进同一段对话，会越来越难管理。文件工具可以承接较大的中间内容，子 Agent 可以处理相对独立的子任务，只把必要结果带回主流程。规划则用来记录任务拆成了哪些步骤、现在做到哪里。

这些能力是否需要，要回到项目本身。如果只是一次模型调用或很短的工具循环，就不必为了框架名字把三层都堆上去；确实需要拆任务、管理较长上下文时，再解释 Deep Agents 帮忙省掉了哪部分工作。

Redis、MySQL 怎样回答到具体场景

可以先说两者在业务里的位置。MySQL 适合保存工单、用户、审核记录等需要可靠落库的数据，通过事务保证一组修改的一致性。Redis 常用来做缓存、计数、限流或短期状态存储，但缓存里的内容可能过期，也可能与数据库短暂不一致。

拿工单状态举例：主记录保存在 MySQL，读取频繁时才考虑加 Redis 缓存。更新数据库后，可以删除相应缓存，让后续读取重新加载；并发下仍要考虑旧值回填和失效失败。审核能否执行不能只看一个可能过期的缓存值，关键状态检查应当落到可靠的数据和更新条件上。

链表重排

以常见的首尾交错形式为例：

L0 → L1 → L2 → … → Ln
变为
L0 → Ln → L1 → Ln-1 → …

1 → 2 → 3 → 4 → 5
变为
1 → 5 → 2 → 4 → 3

思路分三步：找中点，把链表断成两段；反转后半段；再把两段交替接起来。这样每次都能从两段的头部取节点，不需要反复找原链表的尾节点。

快慢指针找中点，后半段长度不超过前半段。合并时先保存两个节点原来的后继，再修改指针，避免把剩下的链表弄丢。时间复杂度 O(n)O(n)O(n)，额外空间 O(1)O(1)O(1)。

def reorder_list(head):
    if head is None or head.next is None:
        return

    slow = fast = head
    while fast.next and fast.next.next:
        slow = slow.next
        fast = fast.next.next

    cur = slow.next
    slow.next = None
    prev = None
    while cur:
        nxt = cur.next
        cur.next = prev
        prev, cur = cur, nxt

    first, second = head, prev
    while second:
        next_first, next_second = first.next, second.next
        first.next = second
        second.next = next_first
        first, second = next_first, next_second

2026-09-06 秋招XX笔试复盘

Sat, 05 Sep 2026 20:00:00 GMT

2026-09-06 秋招XX笔试复盘

题目一：传送门最短路

题目大意

给定一张无向图，允许自环和重边。普通边 (u,v,w) 双向通行，代价为 w；传送门 (u,v) 也双向通行，代价为 0。

从 st 到 ed，最多使用 k 次传送门，k≤10，并且不能连续使用两次传送门。用过一次后，要先走一条普通边才能再用。起点可以直接使用传送门，也可以全程不用。求最小总代价。

思路分析

只记录“到了哪个点”不够。即使在同一个点，已经用了几次传送门、上一步是不是传送门，都会影响下一步能怎么走。

把状态写成 (u,c,last)：u 是当前点，c 是已用次数，last 表示上一步是否使用传送门。转移只有两类：

走普通边：(u,c,last) → (v,c,0)，增加边权 w。
使用传送门：只有 last=0 且 c<k 时可以走，转到 (v,c+1,1)，代价不变。

起点是 (st,0,0)，所以一开始就能用传送门。到终点后，不论 last 是什么都能结束，不必再补一条普通边。

我当时想的 2k+1 层图和这个状态等价。偶数层 2c 表示用了 c 次、可以再用；奇数层 2c+1 表示刚用了第 c+1 次。普通边既要能在偶数层内移动，也要能从奇数层走到下一偶数层；传送门只从偶数层走到下一奇数层。每条无向边对应的两个方向都要处理。

普通边权非负时，在这些状态上跑 Dijkstra。设普通边数为 m、传送门数为 p，状态数为 O(n(k+1))，转移数为 O((m+p)(k+1))。用堆的时间复杂度为 O((n+m+p)(k+1) log(n(k+1)))；不显式复制所有层，额外空间为 O(n(k+1)+m+p)。

参考代码

普通边权非负，距离使用 long long，不可达时返回 -1。

#include <bits/stdc++.h>
using namespace std;
using ll = long long;

// 点编号 1..n；normal 和 portal 都已按无向边存好。
// 普通边权非负，有限最短距离须小于 LLONG_MAX；不可达返回 -1。
ll shortest_path(int n, int k, int st, int ed,
                 const vector<vector<pair<int, ll>>>& normal,
                 const vector<vector<int>>& portal) {
    const ll INF = LLONG_MAX;
    vector<vector<vector<ll>>> dist(
        k + 1, vector<vector<ll>>(2, vector<ll>(n + 1, INF)));
    // (距离, 节点, 已用传送门次数, 上一步是否为传送门)
    using State = tuple<ll, int, int, int>;
    priority_queue<State, vector<State>, greater<State>> pq;
    dist[0][0][st] = 0;
    pq.emplace(0, st, 0, 0);

    while (!pq.empty()) {
        auto [d, u, used, last] = pq.top();
        pq.pop();
        if (d != dist[used][last][u]) continue;
        if (u == ed) return d;

        auto relax = [&](int v, int next_used, int next_last, ll w) {
            if (w > INF - d) return;
            ll nd = d + w;
            if (nd < dist[next_used][next_last][v]) {
                dist[next_used][next_last][v] = nd;
                pq.emplace(nd, v, next_used, next_last);
            }
        };
        for (auto [v, w] : normal[u]) relax(v, used, 0, w);
        if (!last && used < k)
            for (int v : portal[u]) relax(v, used + 1, 1, 0);
    }
    return -1;
}

第四题：Alice／Bob赛马

题目大意

Alice 和 Bob 各有 n 匹马。给出一个 n×n 矩阵，a[i][j]=1 表示 Alice 的第 i 匹马能赢 Bob 的第 j 匹马，-1 表示会输。

每轮 Bob 先出一匹马，Alice 再选一匹应战，两匹马随后移出，直到全部用完。双方都按最优策略行动：Bob 想让 Alice 的分数尽可能低，Alice 想让自己的分数尽可能高。

先求 Alice 能保证的胜场数；若赢 +1、输 -1，再换算为总分。

思路分析

我当时把它理解成给马分配对手，类比“球放到能放的洞里，最多能放多少个”。沿着这个想法，把所有 a[i][j]=1 连成二分图边：左边是 Alice 的马，右边是 Bob 的马。设最大匹配大小为 M。

先看上界。每匹马只能用一次，所以 Alice 最后赢下的那些对局本身就是一个匹配，胜场数不可能超过 M。

再看下界。Bob 可以根据前面几轮动态选马，不能假设他提前公布完整顺序。不过 Alice 仍然能保证 M 场：看当前剩余图的一个最大匹配。

Bob 出的马在匹配里，就用它匹配到的 Alice 马应战。这轮赢 1 场，删除两匹马后，剩余匹配至少还有 M-1 条。
Bob 出的马不在匹配里，Alice 也选一匹不在匹配里的马。两边剩余马数相同，所以这样的 Alice 马一定存在。删除这两个未匹配点，原来的 M 条匹配都还在。

每轮都能保持“已赢场数＋剩余最大匹配大小”至少为最初的 M。因此不论 Bob 怎么出，Alice 都能保证 M 场，和上界合起来就是答案。

只统计胜场时输出 M。若赢 +1、输 -1，总分为 M-(n-M)=2M-n。

下面用增广路求二分图最大匹配，稠密矩阵下时间复杂度 O(n³)，额外空间 O(n)。规模较大时可以换 Hopcroft–Karp，复杂度为 O(E√n)。

参考代码

函数返回最大胜场数，计分换算按题目实际定义处理。

#include <bits/stdc++.h>
using namespace std;

int maximum_wins(const vector<vector<int>>& a) {
    int n = a.size();
    vector<int> match(n, -1), seen(n);
    function<bool(int)> augment = [&](int i) {
        for (int j = 0; j < n; ++j) {
            if (a[i][j] != 1 || seen[j]) continue;
            seen[j] = 1;
            if (match[j] == -1 || augment(match[j])) {
                match[j] = i;
                return true;
            }
        }
        return false;
    };
    int wins = 0;
    for (int i = 0; i < n; ++i) {
        fill(seen.begin(), seen.end(), 0);
        if (augment(i)) ++wins;
    }
    return wins;
}

2026-08-30 秋招XX AI全栈开发一面复盘

Sat, 29 Aug 2026 20:00:00 GMT

2026-08-30 秋招XX AI全栈开发一面复盘

XX AI 全栈工程师（上海）的一面，形式是牛客 AI 面试。8月30日面完后记下了这些，结果没有留下记录。

整体流程是自我介绍、八股、Agent、项目追问，少了一个手撕环节。我当时觉得它挺公式化，但转念一想，真人面试官的追问就不公式了吗？

题目与我的作答

1. 前端与 Redis 八股

八股选了 TypeScript 方向，记得四道：

JavaScript 在浏览器里的事件是怎么执行的？
TypeScript 泛型有什么作用？
缓存穿透、缓存击穿、缓存雪崩有什么区别？
Redis 的两种持久化机制有什么区别？当时记成一个 A 开头、一个 R 开头。

这部分留下了题目，没有留下我逐题回答的原话。下面把它们按复习时能讲清楚的程度补上。

2. Function Calling → 私有 API → Agent 设计模式

后面这组是递进追问，不是几个互不相关的八股。

先问 Function Calling。我当时说，本地内置了 Python 解释器，把 Tools 写好、规约好，模型自己调用工具去跑。但我又提到，本地环境不能覆盖所有场景，还会涉及一些 API。

于是它继续问：私有 API、网络服务这种工具，具体怎么实现？我回答了 MCP。

再往后问 Agent 有哪些设计模式。我当时只知道 ReAct，不清楚还有哪些更通用的模式。这两块是我自己觉得答得不好的地方。

3. 最自豪的 AI 项目，以及和 AI 迭代中发现的问题

Agent 部分结束后，开始问项目：

讲一个自己最自豪、最想讲的 AI / Vibe Coding 项目，解决了什么问题，怎么做的。
有没有一开始没发现，后来和 AI 反复迭代才发现的问题？最后怎么定位、怎么解决？
再围绕这个问题继续追问一些细节。

我记住了这条追问线，但没有留下具体讲的是哪个项目、举了哪个问题，后面几次追问也记不清了。这一段先保留到这里。

复盘与重做

以下是事后整理的知识解释和重答思路，不是把它们补写成我当时已经答出来的内容。

1. 浏览器事件执行：同步代码、微任务、任务

可以先从一段最短的代码说起：

console.log(1);

setTimeout(() => console.log(2), 0);

Promise.resolve().then(() => console.log(3));

console.log(4);

输出是 1、4、3、2。

1 和 4 是同步代码，先执行。Promise.then 的回调进入微任务队列，setTimeout 的回调是后续任务。当前这段代码执行完、调用栈清空后，先清空微任务，再有机会处理下一个任务，所以 3 在 2 前面。计时器写0也不表示回调会立刻打断当前代码。

讲事件循环时，把这条顺序说清楚，再按追问补浏览器提供的计时器、网络等异步能力，以及渲染时机，就比较容易展开。这里讲的是同一个页面 JavaScript 执行环境里的顺序，不是说整个浏览器只有一个线程。

2. TypeScript 泛型：保留输入和输出的类型关系

泛型可以把类型当成参数。同一份函数能处理不同类型，同时保留类型检查。

function identity<T>(x: T): T {
  return x;
}

const a = identity(123);      // number
const b = identity("hello");  // string

如果写成 any，函数确实也能接收这些值，但返回值和输入之间的类型关系就丢了。这里的 T 表示：传进来是什么类型，返回的仍然是那个类型。

需要限制参数能力时，就加约束：

function printLength<T extends { length: number }>(x: T) {
  console.log(x.length);
}

这时 T 可以变化，但必须有 length。接口也一样，例如 ApiResponse<T> 可以复用响应结构，让 data 分别是 User、Product，不用每次重写一遍。Python 的 TypeVar、list[int] 也是类型参数化的例子，只是 Python 的类型提示本身不会把运行时变成静态类型语言。

3. 缓存三件套：先分清故障发生在哪里

情况	发生了什么	常见处理
穿透	查的数据根本不存在，缓存和数据库都没有，请求反复打到数据库	参数校验、缓存空值、布隆过滤器
击穿	某个热点 Key 失效，大量请求同时回源	合并回源请求、互斥更新、提前刷新或逻辑过期
雪崩	大量 Key 同时失效，或者缓存服务整体不可用	TTL 加随机值，配合限流、降级、多级缓存和高可用

先用“不存在、一个热点、大面积失效”把三种情况分开，再针对场景展开。TTL 加随机值能缓解同时过期，解决不了 Redis 整体宕机，不能把所有方案混在一起背。

4. RDB 和 AOF：快照与写操作日志

RDB 保存某个时间点的数据快照，文件通常比较紧凑，适合备份和恢复。代价是宕机时可能丢掉最近一次快照之后的修改。

AOF 记录写操作，通过重放恢复数据。具体能丢多少数据取决于刷盘策略：always 尽量及时刷盘；everysec 每秒刷盘，通常可能丢最近约一秒的写入；no 交给操作系统决定。它也会做重写，不能理解成日志永远只增不减。

两种可以结合使用，重点是根据可接受的数据丢失窗口、性能和恢复需求选择，不能简单说一种在所有场景都更好。

5. Function Calling：把模型和执行程序分开

我当时说“模型自己调用 Python 解释器去跑”，容易把两层混在一起。

模型看到工具说明和参数格式后，生成的是“调用哪个工具、传什么参数”的结构化请求。真正执行函数、操作解释器、访问网络或数据库的是外面的程序。执行完，再把结果交回模型，让它继续判断。

用户问题
  → 模型返回工具名、参数
  → 程序检查参数与权限，执行工具
  → 工具结果放回上下文
  → 模型继续回答，或再调用工具

所以“内置 Python 解释器”可以是工具的一种实现，但不是 Function Calling 本身的定义。先讲清楚这两层，后面的远程工具问题也就容易接了。

6. 私有 API：先解释调用怎么发生，再说 MCP

模型不需要自己持有私有服务的密钥，也不直接替我完成网络请求。可以在后端封装一个工具函数，由它带着服务需要的身份和权限，通过 HTTP、SDK 或 RPC 调用接口，把结果整理好再返回。

我当时直接回答 MCP，跳到了工具接入方式这一层。MCP 可以用来标准化工具发现和调用，但不用 MCP，也能把一个私有 API 包装成工具。

把这条路径说完整会更清楚：

模型提出工具调用
  → 后端工具函数
  → 带认证访问私有服务
  → 得到业务结果
  → 返回模型

如果工具通过 MCP 接入，宿主里的 Client 先向 Server 查询可用工具及参数说明，再把这些能力提供给模型；执行时由 Client 把调用交给 Server。常见的方法名是 tools/list 和 tools/call。

MCP Server 可以在本机，也可以在远端。本机常见 STDIO，远端可以使用 HTTP；它不等于“远程 API”，也不是所有工具调用的必经步骤。除 Tools 外，它还可以提供 Resources 和 Prompts。

7. Agent 设计模式：从 ReAct 往外展开

我当时只知道 ReAct。复习时可以按任务怎么组织来记几种思路：

ReAct：推理、行动、观察结果，再继续推理，边做边决定下一步。
Plan-and-Execute：先列计划，再逐步执行，必要时调整计划。
Reflection：先得到一版结果，再检查、修正。
Router / Supervisor：按任务类型分发，或由一个协调者安排其他 Agent。

这不是一个互斥、穷尽的分类表。实际系统往往会混合使用，再配合重试、超时、最大步数、检查点、人工确认等控制。

8. 项目追问：需要补一个具体故事

这一部分还缺当时的具体回答，不能拿现在的项目经历直接回填。后续回忆时，只需要把一件事说清楚：

做的是哪个项目 → 最初漏掉了什么问题 → 怎么发现 → 和 AI 怎么迭代 → 最后怎么确认解决了。

如果某次追问已经记不起来，就留在这里，不把通用答题建议写成当时的对话。

顺带整理几个容易混的概念

这些来自后续复习，不另外算成面试官问过的题：

Multi-Agent 是多个 Agent 分工协作；职责、工具和上下文可以不同，但会增加通信、成本和调试难度。
Trace 记录一次任务里的模型调用、工具调用、耗时和错误，是排查执行过程的线索，不是一种 Agent 架构。
Swarm 在不同系统里的具体含义不同，常用来描述多个 Agent 之间动态协作或交接，不能把某个框架的做法当成唯一标准。
Memory 可以存放在外部；只有被取出并放进当前请求的部分，才是模型这一次真正看到的上下文。
RAG 主要解决取什么资料来辅助生成；Agent 主要讨论怎样决定和执行后续行动，两者可以结合。
Redis 的过期删除处理到期的 Key，内存淘汰处理内存不足时留谁；LRU 看最近使用，LFU 看频率。主从复制复制数据，Sentinel负责监控与故障切换，Cluster通过16384个槽分片并提供相应故障转移能力。

当时想写的帖子叫“秋招第一面和第一挂”，但“第一挂”说的是另一家公司的结果，不能因此把这场也记成挂了。

幻兽帕鲁

Fri, 28 Aug 2026 20:00:00 GMT

幻兽帕鲁

第一次开档

幻兽帕鲁刚出来的时候，我就和朋友一起玩了。当时它进了XGP，正好我们几个人的订阅都快到期，就先进去体验了一下。我记得当时XGP版本可以好友联机，但没法自己开服务器。稍微玩了玩，再看了些评论，我们就决定换到能自己开服的版本。

那时我们正好也在折腾MC服务器，试了几个整合包。有一个刚开坑，但大家都不是特别感兴趣，服务器还老是爆内存。这个是我的锅，当时想省钱，最开始好像只开了8G，后来加到16G。现在回头看，可能也不只是内存的问题：我用的是轻量云，CPU主频之类的条件未必适合跑游戏服。当时还觉得自己技术可以，不想去买现成的游戏服务器，非要自己在云服务器上弄，结果也没怎么弄好。总之，这台服务器后来就拿来host帕鲁了。

然后我们立刻就沉迷进去了。

我本身不是宝可梦玩家，小队里倒是有，身边也确实认识一两个宝可梦孝子。不过熟悉宝可梦的人，对帕鲁的感觉可能和我还不太一样。对我来说，在一个大的开放世界里，用球去抓各种不同的宠物，这件事本身就特别好玩。MC的宝可梦mod那么火，其实早就证明过这一点了。只是它毕竟是个mod，画面、传播和商业化都有不少限制。帕鲁把这个东西做出来了，我觉得活该它赚钱。

再加上当时大家对任天堂、对GF多少都有些怨气，尤其看过宝可梦新作的音画表现之后，帕鲁这个样子就更让人愿意去试试了。不过这些都是场外，游戏本身在当时确实很好玩。

我们小队前十到二十个小时基本都很沉迷。后来有些人玩到十到二十级左右，觉得后面就是换个地方刷材料，宠物好像也有点换皮，资源还紧，又不想继续追求毕业，就慢慢淡坑了。我倒是还玩得津津有味，每天研究配种、怎么生万物、怎么继承词条，想着弄一只满速云海鹿，再把每个基地的选址和配置都优化一下。各种视频看个不停，反正忙得不亦乐乎。

印象里那是我在威斯康星麦迪逊的第三个学期，正好一月份开学。开学第一周，我几乎没怎么去上课，也没怎么管课程，全沉迷在里面了。

但我们第一个档最后也没有真正毕业。基础内容差不多都体验过了，算是准毕业，我还想继续弄真正毕业的帕鲁和装备配置，但还没弄完，小伙伴们就逐渐不在线了。我自己也没了这个动力，就放下了。

后来又开了一档

这次回坑，是看到喜欢的UP主评价很高，说它已经加了海量的新内容，每一步都有事情干，一直能给你正反馈。我一下就很想玩。因为那个阶段，我也不想碰一款太复杂的游戏，就想找个能不停给正反馈、每分钟都是赚的东西。

于是就想着，能不能再撺掇当时的小伙伴们一起开个档。大家都挺忙，我本来以为要等到国庆才有空，结果还是想办法提前到了八月份，好像正好是几个读硕士的小伙伴有个假期。

这次我没再重蹈覆辙，老老实实开了腾讯云的专属游戏服务器，一键配置就跑起来了。后面整体体验也很顺畅。刚进档那阵，我们又是每天几乎住在游戏里面，每时每刻都有事情干。

这些方便化的设计是好文明

这次回来，我很明显地感觉到它做了很多方便化的设计。箱子就是其中一个，这点其实可以单独拿出来聊。

我印象里，前些年的生存建造游戏，包括MC，箱子大多就是最原始的箱子。东西往里面放，想分门别类，就在旁边立个牌子，或者给箱子打个标签，然后靠自己记、自己整理。

后来不知道从什么时候开始，自动整理、自动归类慢慢变成了这类游戏的标配。我自己比较熟悉的代表是MC的AE。它未必是最早的，但这一套仓储管理确实很好用。之后就有点像科技包的技术下放，连冒险包也会带上方便整理背包、管理仓库的mod。

再往其他游戏里看，我记得木筏、英灵神殿早期好像也没那么方便，泰拉瑞亚的箱子后来也有了类似的整理功能。具体是谁先做的、每款游戏什么时候加的，我没有认真考据过，但这几年玩下来，确实感觉很多生存游戏都会在某次更新里把这一套补上。帕鲁刚出的时候，我记得也没有现在这么方便。

我不得不说，这是好文明。大家都玩过这么多同类游戏了，怎么让玩家少整理一点箱子、少做一点重复劳动，慢慢也该有个标准了。帕鲁愿意把这些东西加进来，我能感觉到它确实在想着怎么给玩家减负。

而且变化不只在箱子。现在很多帕鲁都有一些功能性的技能，抓到之后，我至少会想一想它有没有用。前期会带能提高捕捉概率的、能帮忙开宝箱而不用常备钥匙的，还有方便砍树、采集的。后面又会关心哪些适合放牧、能产什么资源。随着进度变化，我需要的帕鲁也会跟着变，不是抓来一堆完全换皮的东西。

这就让它的循环很足。出去乱逛，看见有用的资源就采几下，遇到野生帕鲁就打一打、想办法捉回来，看到BOSS就去试试，看到遗迹、看到塔也去摸一下，怎么样都是有提升的。

回到家，又升级了，又解锁新科技了，可以重新规划资源和基地。基地布置好了再出去探索，等回来又有新的东西能解锁，家里的帕鲁也产粮了，蛋也孵出来了。每次回来都有东西等着我，每次出门也都有事情可以做。

捣蛋猫这几只，确实设计得好

还有一点我想说的是帕鲁的人设，捣蛋猫这几只，我觉得是真的花了心思，也设计得很成功。这应该是它能出圈的一个重要因素。

现在大家说自己是打工人，都可以直接说自己是帕鲁，这肯定离不开那些梗图。但那些图也确实可爱，确实好用。它的角色能被大家拿来表达自己的处境，这一点做得很好。

后期还是会重复，战斗也不是强项

不过玩到后期，重复还是不可避免的。它的战斗本身也没有太多交互，打击反馈、打击感都不算强。帕鲁培养到位之后，无论是自己打枪、用刀，还是放帕鲁技能，我们大部分时候都处于一路秒的状态。

当然，也有人能把它玩出魂游的感觉。困难模式，再加一些自限，应该也能玩出不少花样。但我们是多人一起玩普通难度，基本没怎么卡过关，也没往那个方向研究。

对我来说，就是养自己喜欢的帕鲁，再找一只有战斗力的。那些看起来就很厉害的，通常也确实挺能打，算是找个版本答案。喜欢的能养起来，战斗的也够用，基本上就能通关了。

每分钟都有事情干

反正我觉得这次1.0更新确实特别有诚意。一直跟着更新玩的玩家，可能没有那么明显的感觉，但我只玩过最早那阵的抢先体验版，中间的更新都没经历过。这次一下子回来，发现已经多了这么多东西。

而且它整体上很完整。最终地图、最终BOSS，甚至后面还能继续追求的终局内容，都做出来了。我觉得这个游戏里面该有的东西，基本都有了。

说回我一开始为什么想回来玩，就是想找一个每分钟都有事情干、每分钟都是赚的游戏。帕鲁确实做到了。出去探索有收获，回家也有新的东西可以弄，探索和基地两边一直能接上，让人一直有事干，一直爽下去。

我觉得这和现在增量游戏为什么这么火，有相近的地方。就算帕鲁到了后期，循环稍微有一点崩坏，我还是觉得它好玩，也是这个原因。

Gamble With Your Friends：玩一次就够了

Mon, 24 Aug 2026 20:00:00 GMT

Gamble With Your Friends：玩一次就够了

最近在社媒上看到这个游戏比较火，就和小队里的朋友一起玩了。玩下来有些失望。

它用了一套现在独立游戏里挺常见的低多边形画风，把赌场里的各种东西搬了进来。大概有二十台机器，但其中十五台给我的感觉都是同一个东西：投钱，按按钮，等结果。这类东西我体验一次，就不会再想体验了。

而且很快就能找到赚钱的办法。最直接的就是一种转盘，无脑押橙色就行。按我们当时看到的情况，橙色大概有七分之一的概率，押中却能拿到十倍收益，所以长期期望是正的。

另外两个有说法的机器，都能卡点bug。一个是骰子，它本身正常玩，长期期望就是赚的，还能通过一个不难学的技巧，让它固定投出某个点数。另一个是弹珠机，可以把棍子卡进去，让弹珠只往倍率高的地方滚。

真正值得说的机器，大概也就是这三个。剩下稍微有策略的，是百家乐、二十一点和德州扑克。但它也只是把这几个现成的游戏模拟了出来。庄家怎么行动、自己该怎么打，都是大家已经研究过很多遍的东西，它没有在上面做出什么特别的设计。其他机器玩起来就更没区别了，企鹅跳冰面、火箭、猜数字，各种皮换一换，本质上还是投钱、按按钮、等结果。

它确实也有道具搭配，但真正有用的就那么几个。比如那个举起来就不会亏钱的神像，我和另一个朋友一起玩转盘，他负责转，我负责拿神像，看到快要亏钱的时候就举起来保他一下。这个过程至少需要我们关注同一个结果，也稍微有一点配合的意思。

还有两本书，一本增加收益，一本减少亏损。都给同一个人吃，再让他同时开四台老虎机、四个转盘，钱就开始左脚踩右脚飞升了。外加一把手枪，实在没钱还能朝队友开枪换钱兜底。道具上值得说的，大概也就这些。

剩下有意思的部分，基本都是和朋友有关的东西。可以看每个人的收益曲线，看看谁赚了钱、谁把钱败光了；钱多了就去更高一级的地方继续赌，没钱了还能卖掉身体的一部分。和现实里关系比较好的朋友玩，这些东西确实可能搞出点场面。

但我们实际玩的时候，除了拿神像配合转盘，大部分时间还是拿到钱之后各玩各的。莫名其妙有个人把钱亏完了，又莫名其妙有个人赚了一大笔。直到最后看收益曲线，才知道这把是谁C了。中间并没有多少大家聚在一个地方、一起做一件事的过程。

真有这么多人一起挂在语音里，玩什么不行呢？这个题材也就是给大家找个理由，周末聚一聚，嘻嘻哈哈一下。作为一个游戏，我觉得它是失败的。

我都不想拿它跟最近玩的Big Walk比，因为我觉得拿它跟Big Walk比，是侮辱了Big Walk。真要找一个参照，我可能会拿How to Fish来比。

同样都是流程很短、定位搞笑的多人联机游戏，How to Fish至少有自己的玩法。把鱼钓上来还不算完，你得亲手把它杀掉，用刀也好，用枪也好，还可以做花式。它做了几种不同的关卡，有各种搞耍的鱼，队友被鱼打死这件事本身看起来也挺好笑。这些设计能让人眼前一亮，也确实给大家创造了爆笑名场面的机会。我觉得它做到了自己想做的东西，所以我认为它是个好游戏。

Gamble With Your Friends也不是完全没有这种机会。比如某个人赌出神之一手，其他人围着看，肯定也会很有意思。遗憾的是，我们这次并没有多少这样的时刻。真正有配合、有设计的地方就那么一两处，其他大部分机器都是现成玩法搬过来，剩下的就是换着皮抛硬币。玩一次就够了，我没有再体验一次的兴趣。

心渊梦境：量大管饱，也做得很成熟

Sun, 23 Aug 2026 20:00:00 GMT

心渊梦境：量大管饱，也做得很成熟

这是一篇补评。心渊梦境是我大概2024年通关的游戏，当时玩的银河城还不算特别多。

我记得最早是看狗蛋的评测了解到它的。也是在那篇评测，或者后来看的什么地方，我知道了它背后的故事：一个年轻的制作人，得到公司的信任，和自己的团队慢慢磨合，把作品做出来，最后也获得了一定的成功，有了一批喜欢它的玩家。具体是在哪里看到的，我已经记不太清了，但这个故事让我很向往，也让我对上海烛龙多了不少好感。

这也是我现在看一些游戏公司时会在意的东西。比如看到鹰角的《泡姆泡姆》，以及开拓芯支持的《浣熊推币机》《鸡械绿洲》，我会觉得他们确实愿意给这些单机作品、给年轻团队一些机会。再比如看到米哈游的《星布谷地》，虽然是另一个方向，也会让我觉得他们愿意尝试一些不同的东西。这些作品会影响我对一家公司的印象。站在求职的视角，我也会因为这些作品，觉得这样的公司和别的厂不太一样。

不过这些是场外的，还是回到游戏本身。

心渊梦境给我的感觉就是量大管饱。地图很多，不同武器也做出了一定的差异，内容很充足，而且基本功很扎实。剧情、战斗、地图设计，在我当时的体验里都能做到中上。

我不知道用“成熟”来形容这样一款游戏是不是很准确，但它确实给了我这种感觉。有些独立游戏会让你明显感觉到，制作人在某些地方缺少经验，做出了比较低级的失误。心渊梦境没有给我这种感觉。第一次做这个类型，就能把各个部分都做到一个比较稳的水平，我觉得已经很不容易了。

当然，几年之后再回头想，我甚至说不出哪一场BOSS战、哪一个场景给我留下了特别深的印象。但当时玩下来，我确实很满足，还做了全成就。

少数还有印象的，是它的跳跳乐。全成就需要做一些跳跳乐，我记得稍微有点难度，但又做得有些无趣。它好像还做了一个小规模的逆城设定，算是致敬经典。整体上，有致敬，也有自己的东西，各方面都能做到中上。

美术是我觉得比较可惜的一点。不是说它不好，相反，它的基本功很扎实，场景能做得很有质感，也确实好看。我想说的“审美差一点”，也不是审美差，而是有点普通。

就是你看着会觉得，这个场景很美，画得很好，但在风格上还缺少一点让我觉得很有特点、很有高级感的东西。对我来说，它能称得上好看，但是称不上美学，离那个感觉还差一点。这是我觉得比较可惜的地方。

《Poly Bridge》序章：不学没意思，学又很难

Sun, 23 Aug 2026 20:00:00 GMT

《Poly Bridge》序章：不学没意思，学又很难

玩完《Poly Bridge 1》的序章，我有点卡在一个很尴尬的地方：对一个不懂造桥的人来说，它的机制不太透明。

我只知道三角形好像更稳。然后呢？三角形搭在上面好，还是搭在下面好？具体怎么摆？我没有一个清楚的判断。如果只凭感觉去造，造出来能过了，我也觉得没什么意思；真想搞懂，就得花时间深入学习，而且很难。学进去之后或许会有乐趣，但前面的投入也很明显。不学没意思，学又很难。

我大致把里面的桥分成两类。一类是静态造桥，难点就是理解这个结构到底为什么行。另一类涉及一定的先后顺序，对我来说更像解谜，这一类的乐趣也有限。当然，我现在只玩了序章，感受也就到这里。

它的教程不算特别完善。我会希望它举一个三角形搭在下面墙上的例子，告诉我为什么这样搭、能提供多大支撑，让我有东西可以算。但要说这是设计失误，我又觉得未必。我更倾向于把它看成题材本身带来的限制：既然选择贴近现实的造桥题材，就得面对造桥本来就是一门复杂学问这件事。

这让我想到《卡卡颂》。玩《卡卡颂》也可能要反复试算，判断哪种结构更合理，但那些规则是游戏自己设计出来的。规则怎么设计，本来就应该考虑玩的人能不能感到乐趣、能不能感到成长。

《Poly Bridge》要模拟现实里的规则，麻烦也就在这里。现实中一件专业的事情，本身就不见得有那么有趣。至少对我来说，凭感觉把桥搭过去没什么意思，想理解怎么搭桥，又得先去学一门复杂的学问。我现在就卡在这两头。