虾皮研发工程师一面：全程简历 + AI 研发观

《面试题目》

1. 自我介绍，要求重点介绍项目。
2. 你的项目是什么业务背景？客户是谁？上下游是哪些服务？
3. 介绍第一段实习（主要问简历上写的，尤其在意具体可量化的效果。比如写了 SQL 调优，就追问：具体有哪些情况？如何发现慢 SQL？最终优化了多少条？取得了什么效果？）
4. AI 开发有什么可以分享的吗？
5. 在 AI 开发流程中有没有沉淀出自己的一些东西？比如公司历史代码不一定是好代码，可能有一些潜在的约束或者大家都知道的常识，但 AI 不知道，这种情况你怎么做？
6. 简历上的项目（继续追问细节）。

反问环节面试官的回答：① 团队里研发用 AI 分三档——「自动驾驶级」的同学自己搭了 AI 自动化工作流，把开发流程大部分交给 AI，人只在验收测试报告等关键环节投入；普通的是用提示词开发，用自然语言指导 AI，因此对沟通表达能力要求高；还有被动使用 AI 的。但公司不关注你具体怎么做，只看最终结果。② 审查 AI 生成的大项目方案要按软件工程思想来，拆分拆细，不一定手敲代码，但要按软件工程的流程走。

《参考解析》

项目要讲到「可量化」才经得起追问

原帖的复盘点得很准：面试官非常在意具体、可量化的效果。同样一句「我做过 SQL 调优」，两种答法差别巨大——

• 弱答法：负责数据库优化，提升了查询性能。
• 强答法：订单列表接口在数据量到 800 万行后 P99 从 2.3s 涨到 6s；通过慢查询日志定位到 WHERE user_id = ? ORDER BY create_time DESC LIMIT 20 做了全表扫描，加了 (user_id, create_time) 联合索引并消除回表，P99 降到 120ms。

准备项目时，先把简历上每一个「优化」「重构」「提升」都换成数字（优化前/优化后/口径/怎么测的），再准备一条追问链：怎么发现 → 怎么判断根因 → 试过哪些方案 → 为什么选这个 → 副作用是什么。第 4、5 问尤其会往下钻：优化了多少条 说明对方会追问范围（涉及多少条 SQL、覆盖哪些业务），怎么发现慢 SQL 说明对方会追问手段（慢查询日志、APM、监控大盘）。

业务背景和上下游也要能画出来：谁调用这个服务、它调用谁、数据从哪来到哪去、峰值 QPS 多少、失败会影响什么。面试官问「客户是谁、上下游有哪些服务」就是在确认你是不是只写了自己那一小块代码。

SQL 调优的知识点要能顺着追问展开

常见追问点和对应答法：

• 怎么发现慢 SQL：MySQL 慢查询日志（slow_query_log、long_query_time）+ pt-query-digest 聚合；云上数据库的慢日志面板；APM/链路追踪定位到具体接口再反查 SQL；performance_schema、SHOW PROCESSLIST 看正在跑的慢语句。
• 怎么分析：EXPLAIN 看 type（ALL 全表扫、index、range、ref、const）、key（实际用的索引）、rows（预估扫描行数）、Extra（Using filesort、Using temporary 是重点）；进一步用 EXPLAIN ANALYZE 看真实耗时。
• 常见优化手段：加联合索引并遵守最左前缀；用覆盖索引消除回表；把 SELECT * 收敛到必要列；避免索引列上做函数/运算/隐式类型转换（字符串列传数字会导致索引失效）；深分页 LIMIT 100000, 20 改成基于游标（WHERE id > last_id LIMIT 20）或延迟关联；OR 改写为 UNION ALL；大事务拆小；减少 JOIN 的表数量并保证关联列类型与字符集一致。
• 要说明副作用：索引会增加写入成本和存储、可能让优化器选错索引；加索引前要看区分度（cardinality），低区分度列（性别、状态）单列索引意义不大。
• 最后回到量化：优化了多少条 SQL、接口耗时降幅、慢查询数量变化、数据库 CPU 负载变化，这些数字最好来自监控而不是自测。

「AI 开发有什么沉淀」这题怎么答

面试官的原话是：公司历史代码里有潜在约束和「大家都知道的常识」，AI 不知道，你怎么处理？这题考的是你有没有把隐性知识显性化。有效做法：

• 把约定写进仓库：在仓库根目录放 AGENTS.md / CLAUDE.md / 规则文件，写清分层规范、命名约定、哪些目录不能动、常用命令、提交规范；AI 每次都会读到，比口头传授可靠。
• 给 AI 检索能力：让它先搜再写（grep 现有实现、找同类模块做参照），而不是凭空造一个新写法；把「同类功能在哪个文件」写进提示。
• 用工具约束代替说教：lint 规则、类型检查、架构依赖检查（禁止跨层引用）、CI 卡点，把「约定」变成「跑不过就合不了」。
• 沉淀成模板与代码片段：新接口、新页面、新任务的标准骨架，让 AI 在你的框架里填空。
• 维护一份踩坑清单：每次 AI 犯的错（比如用了废弃的 API、写错了事务边界）都补进规则文件，形成正反馈。

这套说法的价值在于：它把「我提示词写得好」升级成「我让整个团队和 AI 协作得更稳」，后者才是公司想要的沉淀。

「怎么审查 AI 生成的大项目方案」

面试官给的答案是「按软件工程思想，拆分拆细」。可以顺着展开成一套可操作流程：

1. 先定约束再让 AI 出方案：目标、边界（不能改哪些模块）、性能与兼容要求、验收标准，先说清楚，否则方案会跑偏。
2. 方案评审先于代码：让 AI 输出模块划分、接口定义、数据流向、依赖关系、风险点，人先审这一层——架构错了代码写得再漂亮也是返工。
3. 拆到可验证的粒度：每个子模块有明确的输入输出和可执行的验证方式（单测、契约测试、接口用例），逐个验收而不是最后一起验。
4. 小步提交、持续集成：一次只改一个关注点，diff 小才审得动；CI 必须全绿。
5. 关键路径人工把关：并发、事务、权限、支付、数据迁移这类地方逐行读，且要写能复现的测试。
6. 留出返工的预算：AI 生成大项目第一版基本不可能直接用，把「重构和收敛」当成流程的一部分而不是意外。

面试官透露的信号

反问的答案里有两条信息量很大，值得记下来：一是团队不看你用不用 AI、用得多深，只看结果——所以面试时讲 AI 要落到交付质量和速度上，别把「我用了很多 AI」当卖点；二是他们对校招生的期待是「一半一半」：既要有自己手搓的能力，也要会驾驭 AI，因为成长曲线陡、过度依赖 AI 会导致出 bug 时排查不了。准备这类岗位时，一个「我用 AI 提效但同时能独立定位线上问题」的具体故事，比任何工具清单都管用。