中行总部员工：211硕士毕业刚满一年，在软件中心做研发，转正之后第一个完整年拿了22万左右，六险二金拉满，很满意（附 Agent 面试题）

沉默王二约 4539 字大约 15 分钟

每年这个时候，总有很多同学羡慕银行的工作，那刚好看到这样一则消息，同步给大家感受一下。

211 硕士，毕业刚满一年，在中行软件中心做研发。转正之后第一个完整年，拿了 22 万左右，四五年后能摸到 40 万的收入线。

单看数字，可能有些同学会觉得，22 万也太少了，放在互联网连白菜都算不上。

但拿多少钱和满不满意，真的是两件事。

尤其是对高薪没有特别高的诉求，又希望相对舒适的工作环境，那银行，毫无疑问，就是最佳去处。

据中行2025年年报披露，金融科技投入约 250.01 亿元，这个数字至少能说明软件中心并不是传统银行里的边缘技术部门。中行已经制定了“人工智能+建设规划”和“人工智能+金融落实方案”，搭建了“326”全球人工智能赋能体系。

3类基础平台：算力、技术、数据；
2套机制：敏捷赋能、安全治理；
6种应用范式：覆盖感知识别、分析决策、知识图谱、智能问答、报告生成、智能交互等场景。

AI已经覆盖信贷、营销、运营、风控、客服、办公和科技等领域，比如说一个信贷 Agent，其流程是这样的，获取企业基本资料和授权数据→检索内部信贷制度→调用企业画像、风险信息和财务分析工具→识别财务报表及合同→生成尽职调查报告初稿→标记风险点和资料缺口→交由客户经理或审批人员确认。

中行软件中心也一直在做 AI 和数字化的落地。智能风控、智能客服、RPA 流程自动化、知识库问答，银行在 AI 应用上的投入力度一点都不小。

所以我的观点很明确，想去银行就大胆去冲，对于 27 届的同学来说，接下来两个月就是冲刺的关键期。

如果你是一位愿意相信努力、相信过程、相信一步一个脚印、相信自己能在 AI 时代分一杯羹的人，那接下来的硬核内容，希望你能认真读一读。

（全文比较肝，保证大家能学到很多很多，系好安全带，我们粗粗发～）

派聪明RAG

01、如果用户量突然增长，系统压力变大，瓶颈可能在哪里？

“派聪明是基于 ES 混合检索的 RAG 知识库，从用户提问到拿到回答，经过三个环节：Embedding 向量化、ES 检索、LLM 生成。瓶颈也在这三个地方。”

“第一个是 Embedding API。我用的是阿里 DashScope 的 text-embedding-v4，有 rate limit，每分钟最多 60 个批次，每天上限 2000 个批次。用户量小的时候感觉不到，但如果大量文档上传和检索请求同时进来，Embedding 调用就会排队。”

“第二个是 ES 的 KNN 搜索。派聪明的召回窗口设置是 topK 乘以 30，如果要召回 5 条结果，ES 要扫描 150 个向量做相似度计算。数据量从几千涨到几十万之后，扫描代价会明显上升。”

“第三个是 LLM 推理。ReAct 每轮都要等模型返回结果才能决定下一步，没办法并行。”

02、如果重新设计这个项目，你会怎么优化整体架构？

“第一件事是加查询改写模块。现在派聪明没有显式的查询改写，用户输入什么就拿什么去检索。但用户的原始提问经常不是好的检索 query，太口语化，或者一句话里包含好几个意图。”

“加上查询改写之后，可以做同义扩展、意图分解、上下位泛化，多条改写后的 query 并行检索再合并去重，召回率能提升不少。”

“第二件事是加语义缓存。很多用户问的问题是相似的，比如‘怎么创建项目’和‘项目怎么新建’，语义上差不多。把查询向量和结果做一层缓存，相似度超过阈值直接返回缓存结果，省掉重复的 Embedding 和 LLM 调用。”

“第三件事是混合检索的权重调优。现在 BM25 权重 1.0，KNN 权重 0.2，写死在代码里。不同类型的查询适合不同的权重——精确术语查询 BM25 应该高一些，模糊语义查询 KNN 应该高一些。可以根据查询特征动态调整。”

PaiCLI

文中涉及的PaiCLI Agent 已经开源到GitHub，Go版本也有：https://github.com/itwanger/PaiCLI-Python

03、Agent 效果一般，有 Badcase，怎么确定优化方向？

“确定优化方向之前，先得知道 Badcase 在哪个环节出了问题。”

“PaiCLI 的做法是 trace 重建。每个节点的执行都有快照记录——输入是什么、输出是什么、状态是成功还是失败、耗时多少。整条路径从用户输入到最终产出，每一步都有据可查。”

“拿到 trace 之后，给每个 Badcase 打一个主标签，只打一个：检索未召回、工具调用报错、推理断裂、格式违规、上下文溢出。不要打多个标签，否则分析的时候分不清该往哪个方向优化。”

“标签攒够之后做分布统计，哪个类别的失败率最高一目了然。假如检索未召回占了大头，优化重心就放在检索上，查询改写、调向量模型、优化切块粒度。”

“还有一个前提是回归测试。PaiCLI 维护了一个 Golden Set，123 条确定性测试用例。每改一次提示词或者调一次参数，先跑一遍 Golden Set，确认没有回退再上线。”

04、海量异步任务的平均耗时怎么统计？数据量太大放不进内存

“关键约束是‘放不进内存’，所以存每个任务的原始耗时数据肯定不行。得用聚合的方式，只存统计量，不存原始值。”

“我会用滑动窗口加分桶聚合。把时间轴切成固定宽度的桶，每个桶代表一分钟。每个桶只存两个数字：任务数量 count 和耗时总和 sum。一个任务完成时，根据完成时间找到对应的桶，count 加 1，sum 加上这次的耗时。平均值就是 sum 除以 count。”

“桶的数量是固定的。假如只关心最近一小时的趋势，就维护 60 个桶，每个桶一分钟。新的一分钟到了，最旧的桶清零复用。内存占用恒定，跟任务量没关系。”

“如果还需要看分位数，比如 P50、P95、P99，count 和 sum 就不够了。这时候用 T-Digest 或者 DDSketch 这类近似算法，用很小的内存就能估算出分位数，误差在可接受范围内。”

“变化趋势的展示也简单——每个桶的平均值连成折线图，某个时间段突然升高，去查那个时段的任务日志就行。”

05、用 Vibe Coding 方式设计一个分布式限流系统，你会怎么设计？

“Vibe Coding 的关键在于给 AI 一份清晰的 Spec 文档。分布式限流这种系统，不能上来就让 AI 写代码，先把需求想清楚。”

“Spec 文档里写清楚三件事：限流算法选型、API 接口定义、故障降级策略。”

“算法我会选令牌桶（Token Bucket）。令牌桶允许一定程度的突发流量，桶里有令牌就放行，没有就拒绝，令牌按固定速率补充。相比固定窗口计数器，令牌桶不会在窗口切换的瞬间出现双倍放量的问题。”

“分布式环境下用 Redis 加 Lua 脚本。Lua 脚本在 Redis 里原子执行，检查令牌数、扣减令牌、计算下一个补充时间，三步在一个脚本里完成，不需要分布式锁。”

“Spec 写好之后，交给 Claude Code 或者 PaiCLI 去生成代码。生成的代码先跑单测，再跑压测验证限流精度。”

分布式限流中需要考虑哪些问题？

“第一个是一致性。Redis 用主从架构的话，主节点写入到从节点同步有延迟。极端情况下，主节点刚扣完令牌还没同步，请求打到从节点读到的还是旧数据。对于限流来说，这种短暂的不一致大部分时候可以接受。如果业务要求严格精确，就得用 Redis 单节点或者 RedLock。”

“第二个是性能。每次限流判断都要访问 Redis，网络往返在毫秒级。高 QPS 的场景下可以在本地做预扣，从 Redis 批量拿一批令牌到本地，本地扣减不走网络，扣完了再去 Redis 拿。牺牲一点精确度换性能。”

“第三个是故障降级。Redis 挂了不能把所有请求都拒掉。降级策略是切到本地限流，用进程内的令牌桶兜底。精度会差一些，因为每个节点各自计数，但至少不影响正常业务。”

06、全自动流水线，交付不依靠人，怎么保证可靠性？

“全自动的前提是每一层门禁都足够可靠，不需要人来兜底。”

“代码提交之后，第一层是静态分析和 lint，检查代码风格和潜在问题。第二层是单元测试，覆盖率不达标就打回。第三层是集成测试，跑核心场景的端到端用例。第四层是 LLM-as-Judge 做代码审查，让模型按评分标准检查代码质量和安全隐患。”

“测试全过之后做金丝雀发布——只放一小部分流量到新版本，监控错误率、延迟、业务指标。指标正常就逐步扩大流量，指标异常就自动回滚到上一个版本。”

“还有一点，对不可逆操作（删数据、改表结构、发通知）要设硬性门槛。这类操作即使在全自动流水线里也得有二次确认，可以是延迟执行加取消窗口。”

场景题

07、订单列表带筛选加排序，用分页游标还是真分页？

“先看场景。后台管理系统用 OFFSET 分页，C 端用户列表用 Keyset 分页。”

“OFFSET 分页就是 LIMIT 20 OFFSET 100，优点是简单，支持跳页。运营后台经常需要直接跳到第 50 页查数据，OFFSET 天然支持。缺点是深翻页性能差——OFFSET 10000 意味着数据库先扫描前 10000 条再丢掉，只返回后面 20 条。”

“Keyset 分页是 WHERE id > 上一页最后一条的 id ORDER BY id LIMIT 20，性能恒定，不管翻到第几页都一样快。缺点是不支持跳页，只能一页一页往后翻。”

“C 端的订单列表一般是无限滚动，用户不需要跳页，Keyset 刚好合适。如果排序字段不唯一，比如按创建时间排序，多条订单可能有相同的创建时间——游标就不能只用一个字段，得用复合游标 WHERE (create_time, id) > (?, ?)，保证唯一性。”

“带筛选条件的情况记得建联合索引。筛选字段加排序字段加 id，要有索引覆盖。不然加了筛选之后走全表扫描，分页再怎么优化也没用。”

08、异步支付回执变慢，怎么判断是渠道慢还是我方慢？

“在调用路径上埋三个时间戳就行了。”

“发出支付请求的时候记 T1，收到渠道回调的时候记 T2，我方处理完入库的时候记 T3。”

“T2 减 T1 是渠道的耗时。这个值变大了，说明渠道变慢了，得找渠道对接方确认是系统升级还是出了故障。”

“T3 减 T2 是我方的处理耗时。这个值变大了，问题在我们这边——消息堆积、数据库写入变慢、或者有锁竞争。”

“还有一种情况是 T2 一直没来。回调超时了，不是‘变慢’的问题，是回调丢了。这时候需要主动去渠道查询支付状态做补偿。”

09、token 在网关到订单服务传递，如何防用户串号？

“核心原则就一个。下游服务不要自己解析 token，只信任网关传过来的用户身份。”

“网关做统一的 JWT 验签和解析，从 token 里提取 userId，写到内部请求头里，比如 X-User-Id。下游的订单服务只读这个请求头，不碰原始 token。”

为什么不让下游自己解析？

“因为多个服务各自解析容易出问题。密钥轮换的时候某个服务没更新、token 过期判断不一致、解析逻辑有 bug。集中在网关做一次就够了。”

“防串号还要做权属校验——订单服务在操作订单之前，先查这个订单属不属于当前请求的 userId。就算上游传错了，权属校验也能兜住。”

10、对账明细十万级别，定时任务频繁超时怎么办？

“十万条超时，多半是一次性把数据全加载到内存里了。”

“第一步，分批拉取。不要一条 SQL 把十万条全捞出来。用游标分页，每次拉 1000 条处理完再拉下一批。”

“第二步，对账文件用流式解析。银行对账文件一般是 CSV 或者定长文本，别一口气读进内存。用 BufferedReader 逐行读取，边读边处理。”

“第三步，对比算法优化。如果之前是嵌套循环，拿我方每条记录去对账文件里逐条找匹配——那是 O(n²)。改成归并对比：两边按订单号排序，双指针从头往后走，一趟扫完，O(n log n)。”

“做完这些还超时的话，就把对账任务按商户号或者时间段分片，拆成多个子任务并行跑。”

11、订单既有支付成功又有退款，状态机怎么防回退？

“状态机防回退的核心是白名单。只定义哪些转换是合法的，其余一概拒绝。”

“拿订单来说，合法的转换是：待支付→已支付→已退款。已退款→已支付不在白名单里，代码试图做这个转换直接拒绝。”

“落到数据库层面，用条件更新：UPDATE orders SET status = 'REFUNDED', version = version + 1 WHERE id = ? AND status = 'PAID' AND version = ?。当前状态不是已支付，或者版本号不匹配，影响行数是 0，业务层拿到 0 就知道转换失败了。”

“version 字段解决的是并发问题。两个退款请求同时进来，第一个把 version 从 1 改成 2 成功了，第二个拿着 version = 1 去更新，匹配不上，自动失败。数据库的行锁就够了，不需要分布式锁。”

“每次状态转换记一条流水，从什么状态变成什么状态、谁触发的、什么时间。出了问题回溯流水能看到完整的变更轨迹。”