阿里云 AI Infra 一面：实习项目深挖与 AI 代码质量

《面试题目》

1. 你对阿里云内部的平台了解多少？
2. 实习期间做的项目：项目背景、整体框架设计、整条链路的执行过程（会被逐层深挖）。
3. AI 诊断工具你具体是怎么做诊断的？
4. 怎么做 code review？
5. 有没有做测试，是怎么做的？
6. 怎么保证 AI 写的代码的准确性？
7. 给一段 150 行左右的代码，解释这个类的功能大概是什么。

《参考解析》

有实习背景的面试，深挖项目的目的是验证「你在这条链路里的位置」。 准备方式不是背项目介绍，而是把链路画出来：请求从哪进来、经过哪些服务与存储、每一步的输入输出与量级（QPS、数据量、延迟）、失败路径怎么处理、结果用什么指标衡量。面试官会顺着其中任何一环往下钻，比如你说「做了诊断」，他就会问诊断的输入是哪几种数据、判据是规则还是模型、准确率怎么算、误报怎么处理。答不上某一环，很容易被推断成那部分不是你做的，所以宁可主动缩小范围，说清「这块是同事负责的，我负责的是另一段」，也不要含糊带过。

AI 诊断工具的设计，核心是把「模型给结论」变成「结论有证据、可复现」。 典型链路是：接入可观测数据（指标、日志、链路追踪），做异常检测找出偏离基线的对象与时间段，然后把相关的日志与变更记录按时间对齐聚到同一个上下文里交给模型，最后输出带有依据（哪条指标、哪条日志、哪个变更单）的假设清单与置信度。工程上要处理的问题包括：数据量太大时怎么采样与聚合、多源数据怎么按实体对齐、模型输出怎么约束成结构化格式、以及误报成本高时怎么加人工确认环节。诊断类应用最忌讳直接输出一个结论而不给证据链，因为运维人员无法验证；好的设计会让每一条结论都能点回到原始数据，这样即使判错也能快速排除。

Code review 的答法要落到「看什么、按什么顺序看、什么情况下必须拦下来」。 AI 生成的代码通常语法正确但缺少对业务约束与边界条件的理解，所以评审重点排序是：需求是否被正确实现（先看逻辑再抠风格）、边界与异常路径（空值、超时、重试、幂等）、并发与状态（共享变量、竞态、连接的获取与释放）、安全与权限（越权访问、注入、敏感信息落日志）、可观测性与回滚成本。流程上把生成范围切小、每个改动都伴随测试、关键模块要求人工逐行看，是比「事后检查」更有效的手段。评审记录里保留「为什么这么改」的理由，比只留一个 approve 有价值。

保证 AI 代码准确性，本质是把模型输出放进一条能自动验证的管线。 可用的手段包括：静态检查与类型检查做第一道门；改动必须带测试，且测试要覆盖这次改动引入的新分支；对难以写单测的逻辑做契约测试或快照测试；用同一批输入跑新旧两套实现做双跑对比；上线走灰度并留回滚开关。同时要明确哪些代码不允许模型独立产出——涉及资金、鉴权、数据订正这类不可逆操作必须有人把关。回答里如果能给出一两个真实踩过的坑（比如模型悄悄改了错误处理、把异常吞掉导致问题被掩盖），说服力会比罗列工具强很多。

测试怎么做，别只答覆盖率。 有意义的答法是按风险分层：核心链路的单测与集成测试必做，外部依赖用容器或 mock 隔离，故障场景做注入测试（下游超时、返回脏数据、部分失败），上线前用影子流量或回放真实流量验证。覆盖率只用来找盲区，不作为目标——100% 覆盖但断言全是「不抛异常」的测试没有价值。如果 AI 生成的代码带测试，还要评审测试本身是否有效：断言是否检查了行为而不是实现细节、有没有只覆盖 happy path。

「解释这段代码在做什么」这类题考的是读代码的结构化能力，不是记忆力。 拿到一段陌生的类，建议按这个顺序走：先看类名、实现的接口与公开方法，判断它扮演的角色；再看字段与构造注入的依赖，推断它的数据来源与外部依赖；然后找主流程方法，沿调用链画一遍数据流，标出状态变更点（写库、发消息、改缓存）与并发控制点（锁、原子变量、队列）；最后指出可疑或有歧义的地方，并说明你会怎么确认（找调用方、看测试、查配置）。表达时先给一句结论（这个类是什么、负责哪一步），再分层展开，并且边说边确认理解方向——150 行的代码里通常藏着一两个设计意图，能主动指出来（比如用状态机控制重试、用双重检查做懒加载）比逐行翻译更像有经验的工程师。