10.14 顺丰 AI 全栈二面：插件开发、ES 译文检索与 Agent 记忆

《面试题目》

1. 你对 AI 全栈这个岗位的理解是什么？
2. 是实习了三个月吗？
3. 你觉得这一段实习带给你的个人提升有哪些？
4. 你在做插件的时候，是怎么去了解它的开发机制的？
5. 插件是用 TypeScript 写的、你之前没学过，是 AI 写的，那你通过什么方式去验证它写得对不对？
6. 机翻为什么不直接用 GPT 返回结果，还要做 ES 相似译文召回、术语库匹配？为什么不在框架内部直接完成？
7. 已经翻译好的历史译文，为什么不直接全部当作提示词传入，而是用 ES 检索？
8. 校对页面这个前端界面也是你做的吗？具体有哪些功能？校对完成之后翻译好的数据是怎么回写到插件这边的？
9. 实习里的知识库建设项目，架构是你搭建的还是只参与了一部分？
10. 知识库增量更新原来按文件修改时间判断，你改成基于 Git PR 记录，当时是怎么考虑的？
11. 这个偏向学习的 Spring-AI Agent 项目，你主要想从中获得什么能力、学到哪些关键经验？
12. Agent 项目里面 MCP/Tool 调用，工具数量多的时候，你是怎么控制大模型选择哪个工具的？有没有做控制？
13. 项目里面对话记忆 Chat Memory 是怎么使用的？
14. 如何判断哪些对话内容需要作为用户记忆存储？短期会话记忆和长期记忆怎么区分处理？
15. 当时存储对话记忆为什么选择 MongoDB？
16. MongoDB 和 Redis 都可以存对话记忆，两者分别有什么优缺点？长对话场景下各自的问题是什么？
17. Redis 你在之前项目里用在哪些方面？
18. 你的简历写掌握深度学习框架、科研是做这一块的，那你为什么要来面工程类开发岗位？
19. 为什么不选择 Agent 开发？Agent 开发和这种「后端 + AI 应用开发」相比，你觉得自己更擅长哪一块？
20. 反问：公司现在对全栈岗位的需求是什么？希望全栈人员具备什么样的能力？
21. 反问：主要业务是什么？

《参考解析》

插件开发机制与 AI 写出的代码怎么验证

陌生宿主插件的开发机制，可靠路径是四条一起走：先读官方文档里的生命周期与扩展点清单，再找一个官方示例跑起来打断点，顺着调用栈看宿主什么时候回调你的代码，最后用最小 demo 把每个钩子单独验一遍。真正卡人的不是 API 名字，而是宿主的约束：哪些线程上执行、超时限制、状态存哪里、升级后兼容性。被追问「AI 写的 TypeScript 你没学过，怎么验证」时，要分层回答：类型检查和 lint 只能拦住第一层错误，重点在行为层——按接口契约写最小调用用例，在真实宿主里跑通主路径，再补异常分支（字段缺失、超时、并发触发），最后人工读一遍关键代码确认它没有调用不存在的 API。AI 写插件代码最常见的坑就是幻觉 API 和错误的作用域假设，编译能过但运行时静默失败，所以「跑得通 + 边界对」比「看得懂」更值得强调。

翻译链路：为什么用 ES 召回而不是把历史译文全塞进提示词

这一题最值得展开。第一是成本与窗口：历史译文动辄上万条，全量塞进去会直接顶到上下文上限，单次调用成本也随之失控。第二是注意力稀释：提示词里无关句对越多，模型越容易抄错相邻的句子，翻译一致性反而下降。第三是术语一致性：专有名词必须靠术语库做硬匹配，这是机翻质量的下限，靠模型自由发挥不稳。所以工程上是「检索做上下文压缩、术语库做硬约束、模型做生成」三层分工：先用待译句在 ES 里做相似句对召回，命中阈值以上的历史译文作为少样本示例给模型，术语命中则强制替换。ES 在这里的价值是近邻检索快、能拿相似度分数做阈值、可以做增量索引；代价是要维护双语语料索引与质量分层（人工确认过的译文才进示例池）。追问常落在「检索不到怎么办」，答案要给出回退：无命中就退化到术语库 + 通用提示词，并在结果里标注低置信度供校对页面优先看。

知识库增量更新：从文件修改时间改成 Git PR 记录

按文件修改时间判断，问题出在 mtime 根本不代表内容变更：克隆、checkout、CI 拉取、批量构建都会刷新时间戳，内容没变也会重跑；文件被删除、重命名感知不到；也无法回答「这次变更是谁提的、为什么改」。改成基于 Git PR 记录后，变更集是权威来源：只处理 diff 涉及的文档，删除和重命名能被识别，每个切片可以绑定提交哈希，出问题能回溯到具体版本，还能顺带拿到提交人作为增量更新的通知对象。代价要一起说：首次全量仍要走一次冷启动扫描，非 Git 来源的文档（网盘、接口同步）需要另开一条变更通道，以及历史提交里可能有未走 PR 的直接提交，需要兜底规则。把「为什么旧方案看起来能用」讲清楚，比只讲新方案更像做过这件事。

Agent 的工具选择与 Chat Memory

工具数量一多模型就开始选错，控制手段有层次：最外层是工具本身的质量——名称可读、描述写清「什么时候该用、什么时候不要用」、参数带示例；再往上是候选裁剪，按当前场景只挂相关工具子集，或用规则与轻量分类先缩一圈；还可以在系统提示里给工具选择策略（先查再写、优先用专用工具）。记忆这块，面试官想区分的是「你是有意识分层还是把所有历史都塞进去」。判定一条内容该不该长期存储，看三点：是否跨会话仍然成立、是否是稳定的偏好而非一次性需求、用户是否显式要求记住；短期会话记忆只服务当前窗口，用滑动窗口加摘要控制长度，长期记忆则要能写入、去重、并在需要时检索回来。存储选型要讲取舍而不是背参数：MongoDB 的文档模型适合变长对话、聚合查询方便、持久化可靠，但单文档会随对话增长，要考虑分集合或按会话分片；Redis 读写在内存里、适合最近窗口和 TTL 过期，但长对话会持续占内存、成本高且复杂查询弱。常见落地是组合：Redis 存最近若干轮会话，MongoDB 存全量记录与长期记忆。

岗位理解与职业动机

「为什么从深度学习科研转到工程岗」不能用「想赚钱」或「科研没意思」收尾。可用的逻辑是：科研训练给你的读论文、做实验、归因能力是可迁移的，而工程岗要求把能力交付成稳定系统，两者的差别在于约束——延迟、成本、可维护性、上线后的排障。AI 全栈的吸引力在于链路完整：前端插件、后端服务、检索与模型调用都在自己手里，能闭环验证效果。被问「为什么不选 Agent 开发」时不要贬低那个方向，讲匹配即可：Agent 开发更偏能力探索与效果调优，后端加 AI 应用更偏工程约束下的稳定性与成本控制，你更擅长后者，并举一个项目里为稳定性做出取舍的实例。最后，「AI 全栈这个岗位你怎么理解」要答具体职责边界，而不是形容词堆砌。