答题参考

本页管 2026-10-27 现场面试里不写代码的那几分钟：开场的自我介绍、面试官顺口问的项目、为什么来 Everpure、最后的反问。之后如果还有招聘经理（hiring manager，HM）轮或架构师轮，也从这里准备。写代码的准备在 面试概览，已经过去的测评材料在 测评留档。职位描述（job description，JD）来自 LinkedIn 上的招聘帖，2026-10-24 用户贴来，本页按它重写。经历只取自 简历（文字版）、简历项目的 STAR 素材、自我介绍、求职策略 和 被问到为什么离开微软怎么答，没有出处的一律不写。

先看这几条

• 职位是 Senior Software Engineer – Engineering Acceleration, Hyperscale Line of Business，在 Santa Clara 办公室上班。团队给 Hyperscale 产品线的工程师做共用的开发工具，JD 点名的是 triage（分拣）、rebase / payload、release（发布）这三类重复又费工的工作流（各是什么见下一节），工作里 90% 是亲手写代码。
• 10/27 是两位工程师各面一小时，招聘方说重点是并发和算法，所以这一场用得上本页的，大概只有开场一两分钟和结尾几分钟【推断】。最该练熟的是自我介绍的结尾和反问的前两条。
• 现场写代码用 Python 没有问题：招聘方 10/21 的准备邮件说，挑一门你用得最熟的语言就行（C、C++、Python、Java、Go 都可以），面试官平时用别的语言也没关系。JD 要求精通 Python 和 C++，指的是入职后的工作，和这一场的考法无关。JD 还专门写了要熟练使用 AI 写代码的工具，被问到怎么用 AI 的概率不小，准备见 工作中怎么用 AI 工具。
• 和这个职位最对得上的，是三段经历里都有的「工程质量」那条线：微软两个服务的 CI/CD（提交代码后自动构建、测试、发布的流水线）和分批发布、F5 的 Python 测试自动化、Google 实习的测试基础设施。讲的时候主线仍是后端，不要说成你的主要工作就是做工具。
• 面试前最该补的是发布流程的细节（ring 是分批发布时的每一批，「你的经历怎么对上」第 1 段有解释。要补的是 ring 怎么分、阈值多少、有没有真的自动回滚过）和你用过的监控工具，见「可能被问到的」第 1 条和第 4 条。

这个职位是什么

团队

Hyperscale 是 Everpure 的一条产品线（line of business）。JD 的原话是这条线做 EB 级（exabyte，100 万 TB）的基础设施，强调速度、可靠和运维上的严谨，没写客户是谁。从名字、以及 JD 开头把超大规模云厂商（hyperscaler，自己建造和运营超大规模数据中心的云服务商）列为公司的战略重点来看，大概是给这类客户做存储【推断】。Engineering Acceleration 是这条线里专门让工程师更快的团队：做大家共用的工具，并且把工具「产品化」（productize），也就是把一个能用的原型做成有文档、有人维护、出了问题有人管、别的团队敢天天依赖的东西。

JD 点名的三类工作流

JD 说要给「高 toil」的工作流做工具。toil 是谷歌的《Site Reliability Engineering》（SRE，网站可靠性工程）一书里的说法，指手工、重复、本可以自动化、做完也不留下长期价值的工作。点名的三类：

• triage（分拣）：JD 没说分拣什么。开发工作流里通常指构建失败、测试失败、bug 报告进来以后，判断是谁的问题、有多严重、该谁处理，没有工具时是人一条条看日志【推断】。
• rebase / payload：rebase 是把一条分支上的改动重新接到另一条分支最新的代码上（git rebase）。payload 在这里大概指要合进某个分支、或要随版本发出去的一批改动【推断，JD 没解释，反问里可以问】。在多条产品分支并行开发的存储公司，把修复从一条分支搬到另一条是很费人工的事【推断】。
• release（发布）：把版本切出来、跑完验证、发出去的整套流程。

时间怎么分

约 50% 做开发者体验和工具：做上面这些工具，用 AI 工具快速做原型、跟着需求变化改，用工程指标找出工作流里卡在哪、证明改进有效。约 40% 是设计和可靠性：

• 让快速迭代的工具仍然可维护、正确、可依赖。
• 给工具和服务设计清楚的接口（REST、gRPC、命令行 CLI）。
• 和技术负责人、经理一起定开发工具的路线图。
• 带新人、做深入的代码评审，建立事故处理、变更管理、构建可观测性（build observability，能看清每次构建花在哪、为什么失败）这些运维规范。

要求

• 6 年以上生产环境的软件工程经验，而且方向是开发者效率（developer productivity）、工具或平台工程。JD 写的是对应 MTS4/Senior 级别，也就是高级工程师那一级。
• 在 Linux 生产环境里精通（mastery）Python 和 C++，会 Go 或 Java 加分。
• 做过内部工具或面向开发者的软件，包括用 Docker 做可复现的环境。
• 熟练用 AI 写代码的工具。
• 亲手设计过 gRPC、REST、CLI 接口。
• 用过工程指标和监控工具，JD 举的例子是 Prometheus（开源的时序指标监控系统）、fb303（Meta 开源的服务状态和计数器接口）、scribe（Meta 开源的日志汇集服务）、t-digest（只用很少内存就能从数据流里估出 p99 这类分位数的数据结构）。fb303 和 scribe 出自 Meta，团队里可能有从 Meta 过来的人【推断】。
• 计算机或电子工程本科。

除此之外，底薪 18 万到 27 万美元，可能另有奖金和股票。在 Santa Clara 办公室上班，除了休假、出差和批准的请假都要到办公室。

你的经历怎么对上

先看对照表，再按贴合程度逐条讲。

1. 微软：两个服务的 CI/CD 和分批发布（最贴合）

简历写的是：你给 SmartArt（PowerPoint 里的图示功能）服务和缩略图服务写了 Azure DevOps 的 CI/CD 流水线（pipeline），发布走按 ring 分批的安全部署，每一步用错误率和延迟做健康检查，不达标就自动回滚。

几个词先讲清楚。CI/CD 是持续集成（每次提交都自动构建、跑测试）加持续交付或部署（构建好的版本自动推到各个环境）。Azure DevOps 是微软的代码托管和流水线平台。ring 是把要发布到的环境和用户分成一圈一圈，先发给最小、出了问题影响也最小的那一圈，确认没事再往外扩。这套做法在微软叫安全部署（Safe Deployment Practices，SDP）。健康检查（health check）是每一圈发完后看两个指标：请求失败的比例（错误率）和响应时间（延迟），不达标就自动回滚（automated rollback）。回滚在你们那里具体是退回上一个版本还是停止往下推，素材里待确认。

对得上的理由是 JD 原文：发布是点名要做工具的三类工作流之一，变更管理是要建立的运维规范之一。流水线是你自己写的。面试官顺着会问什么，见「可能被问到的」第 1 条。

2. Google 实习：Google Play 的 UI 测试基础设施

实习的职位名就是 Tools and Infrastructure Intern（工具和基础设施方向的实习生）。你做了三件事：

• 给 Android UI 测试加上自动的截图差异检查。
• 写了一个对比 Android view 结构的工具，找出不稳定的 view。
• 基于 Espresso（Android 官方的 UI 测试框架）做了 view modifier，截图前把不稳定的 view 藏起来，截完自动还原。

背景要讲得出来。截图差异检查是测试跑到某个画面时截一张图，和事先存好的基准图比，不一样就报失败。view 是 Android 界面上的一个控件。有些 view 每次显示的样子都可能不同（比如显示当前时间的控件，这是举例），截图一比就报差异，代码其实没坏，这叫误报（false positive）。按 STAR 素材，目标是让截图差异检查可靠到能放进 CI 里跑。

对得上的理由：同一份代码有时通过、有时失败的测试叫不稳定测试（flaky test）。误报一多，工程师就习惯性地重跑或无视失败，真问题也跟着被放过。triage 是 JD 点名的第一类工作流，按通常的理解，要分拣的就是这类失败【推断】。你做的事就是从源头减少要分拣的噪音。

3. F5：用 Python 做 API 集成测试自动化，用 Selenium 做 UI 自动化测试

你用 Python 做了 API 集成测试的自动化。集成测试（integration test）是把后端真正跑起来、通过调用 API 检查结果，测几个部分合在一起对不对。你还用 Selenium（驱动真实浏览器去点页面的测试框架）搭了 UI 自动化测试。那个产品负责下发安全策略，改代码时把原来好好的功能弄坏（回归，regression）的代价很高，所以要让回归测试自动跑。

对得上的理由：这是你在工作中写 Python 的经历，对得上 JD 的 Python 要求。测试自动化服务的是写代码的工程师，和「做开发者用的软件」沾得上边。但素材里写的是测试自动化，没说它做成了别的团队也用的工具，不要讲成「给工程团队做工具」。STAR 素材的备注里也写了讲法：平台要给使用方提供质量信号，也就是让写代码的人很快知道自己的改动有没有弄坏东西。

4. 微软：别人依赖的后端服务，和 C++

缩略图生成服务用 C# 和 C++ 写，对外提供 REST 和 gRPC 接口，供多个功能调用。用 Docker 打包，部署在 AKS（Azure 托管的 Kubernetes）上做横向扩展（负载上来时多开几份同样的服务实例分担）。SmartArt 的 Web 功能你用 C# 和 C++ 优化过，简历写的是显著降低了服务延迟。

对得上的理由：JD 要设计 REST 和 gRPC 接口、要用 Docker、要 C++，这三样都在这段里。另外内部工具也是别人依赖的服务，只是用户换成了公司里的工程师，工具一慢、一挂，所有人都得等。容器跑的是 Linux 还是 Windows，素材里没写，JD 强调 Linux 生产环境，面试前要确认。

5. 微软：给两个服务从零搭全套 Azure 基础设施

你给 SmartArt 服务和缩略图服务搭了完整的 Azure 基础设施，从内部测试环境，到全球生产环境，再到美国政府云。内部测试环境在 Office 叫 EDOG（Early Dogfood），对外讲时说「内部测试环境」（求职策略 第四节的写法原则）。政府云（government cloud）是和普通 Azure 隔离的独立环境，合规更严、访问受限，服务地址（endpoint）和配置也和普通环境不同。

对得上的理由：JD 要工具「可依赖」。在访问限制和配置各不相同的多套环境里把同一个服务搭起来、跑稳，说明你处理过真实的生产部署。注意 JD 的可复现环境（reproducible environments）是和 Docker 写在一起的，对应第 4 段的 Docker 打包。这一段的资源是不是用模板（ARM、Bicep，Azure 按模板文件创建资源的格式）建的，素材里待补，确认之前不要说成「环境可复现」。

对不上的，怎么诚实地说

• 年限是后端方向的。 JD 要的 6 年指开发者效率、工具或平台工程方向。照实说你的主线是产品后端服务，「工程质量」那条线（流水线、测试自动化、测试基础设施）是三段经历里各自的一部分，再讲为什么想专门做这件事。
• Python 写的生产工具不多。 你的 Python 主要是 F5 的测试自动化和学校项目，生产服务用的是 C++、C# 和 Java。被问到就照实说，再讲现场写代码用的是 Python。不要说「Python 是我的主力语言」。
• Linux。 简历没写服务跑在什么系统上，确认之前不要说「在 Linux 上做生产运维」。
• 监控工具。 素材里没有用过 Prometheus、fb303、scribe、t-digest 的记录。没用过就照实说，再讲你知道它们各解决什么问题（解释在「这个职位是什么」一节）。用过的监控和告警工具待补。
• 带新人、代码评审、定路线图。 素材里都没有，面试前回想有没有带过实习生或新同事、评审别人代码时最常指出什么、有没有参与定过团队的技术方向。没有就不说。
• 构建可观测性。 JD 把它列在要建立的运维规范里，没写要做构建系统本身。你写过流水线，但素材里没有分析构建慢在哪、为什么失败的经历。被问到就照实说，再说怎么下手：先给每次构建记下每一步的耗时和失败原因（这就是构建可观测性），找出时间花在哪一步，再对症处理，输入没变的步骤复用上次的产物（缓存），互不依赖的步骤同时跑（并行），把大模块拆小、改一处只重建受影响的部分（拆分）【推断：通用思路，不是你的经历】。
• 量化结果大多没有。 STAR 素材里微软四条都标着「需补充」，Google 和 F5 也是。面试官听到「显著降低」一定会追问数字，没有真实的数字就说当时没量或记不清，不要现编。

Most of my production code was C++, C# and Java. My Python was mainly test automation at F5. For the interview I'm comfortable coding in Python.

为什么是 Everpure

先说事实。主力产品是全闪存存储 FlashArray（块存储）和 FlashBlade（文件和对象存储），跑自家的 Purity 操作系统。2026-02 从 Pure Storage 改名 Everpure。JD 里公司自己的说法是 FY2026 营收 37 亿美元，出现了第一个营收过 10 亿美元的季度，FY27 增长还在加速。公司情况见 公司情况。

回答要把公司和团队连起来：Hyperscale 这条线做 EB 级的基础设施，JD 强调速度和可靠，所以发布要又快又稳。每个工程师花在 triage、rebase / payload、发版上的手工时间，乘上整条产品线的人数，就是这个团队能省下来的东西。这正好接上你在微软亲手做过的流水线和分批发布。

The Hyperscale line builds and ships exabyte-scale infrastructure, so every release has to be both fast and safe. What I like about this role is taking the toil out of that: triage, rebase and payload, releases. I also like turning quick prototypes into tools people can rely on. At Microsoft I built the CI/CD pipelines for my own two services and rolled out releases ring by ring, gated on error-rate and latency checks with automatic rollback. I'd like to do that kind of work for a whole engineering organization.

自我介绍怎么调

在 自我介绍 的英文 45 秒通用版上改两处。

第一处，通用部分最后一句（services other people depend on 那句）说完以后，用下面这段代替原来接在后面的公司结尾，把「工程质量」那条线串起来。这是和这个职位最贴的一点，放在最后讲，面试官印象最深。这是讲法上的选择：三段经历里确实都有这些事，但你的主要工作是后端服务，被追问时照实说。

One thread runs through all three jobs: the tooling around the code. At Microsoft I built the CI/CD pipelines for both of my services and shipped releases ring by ring, with health-check gates and automatic rollback. At F5 I automated our API integration tests in Python and built UI regression tests with Selenium. And my internship at Google was on test infrastructure for Google Play: adding screenshot diff checks to Android UI tests, and hiding the unstable views that made them noisy. Taking the toil out of how engineers ship is what I want to focus on next, which is why this role caught my eye.

第二处是时长。intro 页建议 1 分钟以内说完，加了这段会超。把通用版里 F5 那句缩成下面这句，测试自动化已经在新加的这段里讲了。

Before that, at F5, I built Java backends that pushed security policies to large fleets of devices.

可能被问到的

工程师在开场或写完代码后可能顺口问。如果之后还有 HM 轮或架构师轮，会问得更细（面试概览 记了别人流程里的例子）。

1. 讲讲你做的 CI/CD 和发布流程

先讲你确定的部分：两个服务的流水线是你写的。发布一圈一圈往外推，每一圈看错误率和延迟，不达标自动回滚，达标才往下推。流水线里具体有哪些步骤（构建、跑哪些测试、要不要人工批准）素材里没写，要想好。求职策略 第四节还列了几个会顺着问的：不同环境的配置怎么管、政府云里不能直接登录时出了问题靠什么定位、搭一个新环境要多久。

下面几点素材里还没有答案，要你面试前回想、填上真实情况（STAR 素材「面试前要想清楚的」一节）：

• ring 是怎么划分的。素材里只举了个例子（内部测试环境 → 内部用户 → 第一个生产地区 → 全部地区 → 政府云），实际是不是这样待确认。
• 错误率和延迟的阈值大概多少，和什么比：和上一个版本比，还是和固定的服务等级目标（service level objective，SLO，比如「99.9% 的请求要成功」）比。
• 每一圈发完等多久才往下推，这段观察时间叫 bake time。
• 自动回滚具体做什么：退回上一个版本、停止往下推，还是关掉功能开关（feature flag，不改代码就能开关某个功能的配置）。是平台自带的，还是你在流水线里配的。
• 有没有真的触发过回滚，当时是什么问题。有的话，这是最好的面试故事。

一个靠理解就能答的追问：「健康检查都过了，bug 还是漏到生产环境了，怎么办？」先说健康检查的局限：错误率和延迟只能发现「请求失败」和「变慢」。代码返回了错误的结果、但请求本身成功，这两个指标看不出来。所以发布前要靠测试拦住逻辑错误，发布后给关键功能加专门的指标。真漏下去了，先停止往下一圈推，已发出的圈手动回滚。修好后从最小的一圈重新发。最后补一个当初能拦住它的测试或指标。这是通用的道理，除非你们当时确实这么做，否则不要说成是你们的做法。

Health checks only catch failures and slowdowns. A logic bug that returns a wrong answer with a successful status code still passes, so you need tests before the rollout and feature-level metrics after it.

2. 你平时怎么用 AI 写代码

JD 三处写到 AI：

• 职位介绍里说用 AI 辅助开发、跟着需求变化快速迭代。
• 工作内容里说用 AI 工具快速做原型。
• 要求里说熟练使用 AI 写代码的工具。

这道题的讲法、追问和要你填的真实例子都在 工作中怎么用 AI 工具。没有真实例子就别讲，那一页的待填项是这一场之前最该补的。

3. 你会怎么衡量开发者的效率

JD 要用工程指标找出工作流里卡在哪、证明改进有效，所以这是这个团队的本行问题。按工作流的阶段讲，每个阶段量「等了多久」和「白做了多少」：

• 构建：一次构建要多久，看中位数（p50）也看最慢的那 5%（p95）。只看平均数会被少数特别慢的构建掩盖，而工程师抱怨的恰恰是那几次特别慢的。t-digest 这类数据结构就是用来在数据量很大时省内存地估这些分位数的。
• 测试：不稳定测试的比例，重跑才通过的次数。
• 分拣：一个失败从出现到有人认领、到修好，各隔多久。
• 发布：从代码合入到发到生产要多久，发布后回滚的比例。

讲完要补一句局限：指标会被「优化指标本身」带偏，比如为了缩短构建时间关掉一部分测试，所以每个指标都要配一个反方向的指标看着（构建时间配漏到发布阶段的 bug 数）【推断：通用做法，不是你的经历】。能接上你经历的，是发布时的健康检查：你已经在用错误率和延迟判断一次发布是不是变差了。

I'd measure each stage by how long people wait and how much work gets thrown away: build time at p50 and p95, flaky-test rate, time from a failure to an owner, and lead time from merge to production. And I'd pair every metric with a counter-metric so we don't speed up builds by quietly skipping tests.

4. 你用过什么监控和告警

JD 点名了 Prometheus 这类工具。素材里只有发布健康检查用的错误率和延迟，日常的监控、告警、看板用的是什么工具（Azure Monitor、Application Insights，还是别的）待补，填上之前不要具体说工具名。

5. Google 实习那段具体做了什么

按 STAR 的顺序讲：

• 情境是 Android UI 测试里有不稳定的 view，截图比对容易误报。
• 任务是让截图差异检查可靠到能进 CI。
• 做法是先用对比 view 结构的工具找出哪些 view 不稳定，再用基于 Espresso 的 view modifier 在截图前藏起来、截完还原。
• 结果素材里没有数字，误报率降了多少、被多少测试采用都要补。

可能的追问是「为什么把 view 藏起来，而不是比对时跳过那一块区域」。素材里没有当时的考虑，想不起来就照实说，再讲两种做法的代价：跳过区域要知道那块的坐标，布局一变坐标就跟着变。藏 view 是按控件本身找，布局怎么变都找得到，代价是要改界面状态，还原失败会影响后面的步骤。所以按控件处理更省维护，前提是还原可靠【推断】。

At Google I worked on test infrastructure for Google Play. Screenshot diff checks were noisy because some views were unstable, so I built a tool that compared the view hierarchy to find those views, and an Espresso-based modifier that hid them before each screenshot and restored them afterwards. The goal was to make the checks reliable enough to run in CI.

6. 讲一个技术取舍

用各个云的 endpoint 写在代码里的例子（求职策略 第四节）。好处是政府云这类地址几乎不变，写在代码里能经过代码评审和测试，没人能靠改一个配置文件弄坏生产环境。代价是加一个新环境就得改代码、重新发布。现在会改成按环境注入配置（由流水线注入，或放进配置服务），启动时就校验，填错当场失败。具体是哪种写法待你确认，两种讲法不同：代码里一张按云名查的表、运行时按环境选，是合理做法，用那一节第一版英文讲法。各处直接写 URL 才是真写死，用第二版（以 Honestly 开头），先承认再讲怎么改。

7. 讲一个你处理过的并发问题

这家技术面最常考并发，面试官顺口问你经历里的并发很自然。素材里没有具体的并发 bug 故事，不要编。能讲的是缩略图服务：多个功能同时调用它，所以要横向扩展。但要分清：横向扩展是多开几份实例分担请求，解决的是吞吐。面试官问的并发是同一个实例里几个请求同时用到同一份数据会不会出错。所以要回想单个实例里有没有多个请求共用的东西（比如内存里的缓存、共用的连接池，这是举例），用什么保护，遇到过什么竞态（race condition，几个线程执行的先后不同、结果就不同的问题）。想不起具体的，就讲设计上怎么避免：请求之间不共享可变状态，非共享不可的部分用锁或线程安全的容器保护。

8. 讲一次跨组合作

用缩略图服务或 Agent Mode 解析服务。缩略图服务是多个功能组共用的被调用方，接口和迁移要和每个调用方协调。Agent Mode 是 PowerPoint 里由 AI agent 读懂幻灯片再去操作的功能。解析服务把幻灯片转成 agent 能读的结构化 JSON，是 Agent Mode 的上游依赖，下游团队要等它交付。素材见 简历项目的 STAR 素材，有几个调用方、接口怎么迁移这些细节还没有，先补再讲。不要用离职那件事：被问到为什么离开微软怎么答 写明，那件事的教训本身就是跨组协调的缺口，对平台岗尤其敏感。

9. 为什么离开微软

照 被问到为什么离开微软怎么答 的三层口径，默认只说第一层。答完马上转到接下来想做什么（求职策略 第二节最后一段说的顺序），这里正好接「想专门做让工程师发得更快更稳的工具」。

反问

工程师轮结尾通常只剩几分钟，问前两条就够了。后面几条留给 HM 或招聘方。

1. JD 点名的 triage、rebase / payload、release 这三类工作流，现在哪一个最费人？这里的 payload 具体指什么？答案告诉你团队眼下的重点，也能顺势接上你的发布和测试经历。

   The posting mentions triage, rebase and payload, and release workflows. Which of those costs the team the most today? And what does payload mean in your context?

2. 你们现在用什么指标衡量这些工作流，一个工具什么时候算「从原型变成正式支持的工具」？对方怎么答，能看出团队做到了哪一步。

   How do you measure those workflows today, and when does a prototype graduate into a supported tool that teams depend on?

3. 工具用 Python 写的多还是 C++ 写的多？工具要直接处理产品的 C++ 代码吗？

4. 工具的用户是 Hyperscale 这条线的工程师，还是也服务 FlashArray、FlashBlade 这些产品线？

5. 这一场之后的流程是什么，会不会还有 HM 轮和系统设计轮？

6. 改名、收购 1touch（做数据发现和分类的公司）之后，工程团队的方向和组织有什么变化？

概念题补充

面试概览 记了一篇总监轮问过 C++ 多线程概念，下面这些可以在写代码的准备之外过一遍。它们是按「技术面常考并发」挑的练习，和这家面经里的原题无关。

• 写一个生产者消费者模型：手写生产者消费者。生产者线程往有界缓冲区（容量有上限的队列）里放，消费者从里面取。满了放的一方等，空了取的一方等。用互斥量（mutex）加条件变量（condition variable）实现，Python 写法见 Python 并发语法。
• 两线程交替打印：两个线程交替打印。
• 死锁的条件与处理：死锁（两个线程各拿着一把锁、又在等对方手里那把）的四个必要条件，和怎么避免。
• 线程同步方式有哪些：线程同步的几种方式，除了互斥量和条件变量，还有信号量（semaphore，最多允许 N 个线程同时进入）、读写锁（读可以并行、写要独占）、屏障（barrier，一组线程都到齐才一起往下走）。
• 自旋锁和互斥锁的区别与使用场景：自旋锁（拿不到锁时原地反复尝试，而不是睡下）和互斥锁的区别。
• 伪共享（false sharing）：伪共享（false sharing），两个线程改的是不同变量，但它们落在同一条缓存行（cache line，CPU 缓存和内存之间搬数据的最小单位，常见是 64 字节）上，互相让对方的缓存失效，程序变慢。
• C++ inline 与 volatile：C++ 的 volatile 为什么不是同步工具，要用 std::atomic 或锁。

其他

• 你不需要任何签证担保（sponsorship）。申请表问「now or in the future require sponsorship」时答 No。
• 2026-10-16 的第一版是职位还不知道时，拿 Fullstack Software Engineer, AI Infra 代替写的。现在 JD 已知、和 AI 平台无关，那部分删了。如果面试中话题转到 RAG（检索增强生成），能接上的是 Agent Mode 解析服务那段，见 简历项目的 STAR 素材。