AI代码审查员面试题库（含必背题目）

AI代码审查员面试题库第1页共1页AI代码审查员面试题库解决「面AI代码审查员问不出真本事、评分全靠感觉」：43题覆盖基础认知·实操应用·项目追问·风险避坑·开放思辨，每题附参考答案与追问链，含评分表与红旗信号使用说明一、题库定位本题库面向AI代码审查员（人机协同改造岗）的面试评估，覆盖基础认知、实操应用、项目经验、风险避坑、开放思辨五类，共43题。适用对象：有2年以上开发或测试经验、准备转入代码审查岗的候选人；也适用于评估在职审查员的水平分层。不适用：纯安全岗（渗透、红队）的深度技术面试，那类岗位需另加攻防实操环节。题库的使用前提是候选人必须现场读代码。只答题不读代码的面试，无法区分"真会看"与"会背概念"。二、题目结构与建议用时部分题量建议用时评估权重使用方式一、基础认知1125分钟20%抽5～6题，看概念是否落地二、实操应用940分钟35%必做3题，其中1题需现场读代码三、项目经验730分钟25%选2题，追问到细节四、风险与避坑915分钟12%抽3题，看判断边界五、开放思辨710分钟8%抽2题，看思维深度合计43120分钟100%分两轮完成，避免疲劳单轮面试控制在60分钟内，超过90分钟候选人答题质量明显下降，尤其在后半段的风险题上。两轮安排建议：轮次题量时长重点面试官第一轮基础5题加实操2题60分钟会不会看代码、能不能判误报同级或高一级审查工程师第二轮实操1题加项目2题加风险3题60分钟判断边界、责任意识、真实经历审查组长加安全负责人三、评分锚点（1～5分）分值定义行为特征5优秀答案有具体数字与真实细节，能主动指出自己方案的局限，能说出"什么情况下这个判断会错"4良好答案完整、有案例支撑，逻辑清晰，偶有细节模糊但能自洽3合格知道正确方向，能说出主要步骤，但缺少量化与边界意识2偏弱只能复述概念，举不出自己的例子，追问两层即空1不合格答案与岗位实际脱节，或存在明显的事实错误判定原则：能说出"我判错过什么"的候选人，通常比说"我从没判错"的候选人更可信。四、面试官注意事项●每道题至少追问一层。第一层答案可以准备，第二层通常暴露真实水平。●候选人回答"我们团队用的是某工具"时，追问"这个工具在这类问题上误报多吗、你怎么处理"，能立刻分辨使用者与理解者。●现场读代码环节必须准备一段含3处缺陷、且其中1处AI扫不出来的代码，观察候选人是否只找扫描器能报的问题。●不要在候选人回答后立刻纠正。先记录，等其说完再追问，否则会打断思路、丢失真实判断过程。●对"我从没漏过"这类回答保持警惕，追问"那你们团队的逃逸率是多少、怎么统计的"。一、基础认知题（11题）Q1.你怎么理解AI代码审查员这个岗位？AI做什么，人做什么，交接点在哪？参考答案要点：1.AI做全量扫描：语法风格、已知漏洞模式、重复代码、复杂度、依赖漏洞、密钥、覆盖率提示。特点是覆盖全、速度快、不理解业务。2.人做三件事：过滤误报、判断业务语义与并发时序、对放行负责。这三件AI目前做不了。3.交接点是"候选问题清单"变成"处置结论"的那一刻，责任同时从工具转移到签字人。4.能说出边界：业务逻辑正确性、架构合理性、性能根因、并发时序、隐蔽越权、跨模块状态一致性、团队历史约定，都不在AI能力范围内。追问：如果AI的误报率降到5%，这个岗位还需要吗？Q2.业界静态扫描的误报率常在30%～60%，为什么这么高？参考答案要点：1.模式匹配类规则只看"危险函数被调用"，不看参数是否可控，天然产生大量误报。2.数据流分析受限于跨文件、跨服务、动态语言与反射调用，分析不完整时倾向于"报出来更安全"。3.框架层已有防护（ORM参数化、模板自动转义），规则未必感知框架语义。4.生成代码、测试代码、示例代码被纳入扫描范围，进一步推高噪音。5.后果：误报过多会让开发者形成"全部忽略"的习惯，真正的漏洞被一起忽略。追问：你会用什么指标衡量误报治理的效果？Q3.缺陷逃逸率怎么算？为什么用它做主考核指标？参考答案要点：1.口径：上线后30天内发现的、经回溯确认"审查阶段可见"的缺陷数，除以审查通过的千行代码数（或每百个MR的逃逸数）。2.关键在"审查阶段可见"这个限定，不可见的（如运行时环境、第三方服务故障）不计入，否则会冤枉审查员。3.用它做主指标的原因：审查的价值在于拦住会出事的问题，而不是看了多少行。4.配套指标：误报过滤率、覆盖率、平均审查时长、返工率，防止为了压低逃逸率而滥报。追问：如果团队把线上问题都归因为"需求变更"，逃逸率会怎样？你怎么防？Q4.静态扫描的数据流分析，为什么跨文件、跨服务时会漏？参考答案要点：1.单文件分析只能看到局部变量，跨文件的参数传递需要构建调用图，构建不全就断链。2.动态语言（如Python、JavaScript）的类型与调用目标在运行时才确定，静态分析只能保守推断。3.反射、依赖注入、消息队列、RPC调用会让数据流在分析视角里"消失"。4.跨服务场景下，入口参数在网关被清洗、在服务内又被拼接，工具通常只看到一半。5.所以人工必须补的是"跨边界的那一段"：网关到服务、服务到服务、服务到数据库。追问：你会怎么设计一次针对跨服务数据流的专项排查？Q5.SQL注入有哪几种容易被漏掉的形态？参数化为什么能防住？参考答案要点：1.常见形态：拼接WHERE条件、LIKE模糊查询拼接、ORDERBY与表名拼接（无法用占位符）、IN子句拼接、批量插入拼接。2.ORDERBY与表名这类"结构位"不能用参数占位，必须用白名单映射，这是最易漏的一类。3.参数化的原理是把SQL结构与数据分离，数据库先编译结构再绑定值，值永远不会被当作语法解析。4.但参数化防不住"拼接发生在参数化之前"，也防不住存储过程内部的动态SQL。5.审查动作：找到拼接点，确认拼接的是值还是结构，结构位是否有白名单。追问：如果代码用了ORM，你还会查注入吗？查什么？Q6.水平越权和垂直越权怎么区分？各举一个代码层面的例子。参考答案要点：1.水平越权：同一角色内，A用户访问B用户的资源。典型代码：接口用路径里的orderId直接查库，不校验该订单的userId是否等于当前登录用户。2.垂直越权：低权限角色调用高权限功能。典型代码：管理接口只在前端隐藏入口，后端未校验角色。3.还有一种常被忽略的：租户隔离缺失，查询条件里没有强制带tenantId，靠前端传。4.审查动作是两问：登录了吗（认证）、这条数据是你的吗（授权）。有鉴权注解只回答第一问。5.批量接口要逐个校验归属，只校验第一个ID是高频漏点。追问：网关做了统一鉴权，后端还需要做资源归属校验吗？Q7.发现代码里硬编码了生产密钥，删掉这个文件就够了吗？参考答案要点：1.不够。密钥已进入Git提交历史，任何人clone都能翻出来，删除当前文件不影响历史。2.正确处置：立即轮换密钥（视为已泄露）、清理历史（改写提交或使用过滤工具）、排查是否已被使用。3.还要查同类问题：同一仓库其他位置、CI配置、测试数据、文档、镜像层里是否还有。4.修复方式：改走配置中心或密钥管理服务，本地开发用占位符加环境变量。5.审查动作：密钥类问题一律阻断，不接受"下个版本再改"。追问：如果这个密钥是测试环境的，你会怎么处理？Q8.GPL、AGPL、LGPL、Apache2.0的主要区别是什么？各自的风险点在哪？参考答案要点：1.MIT与BSD：宽松，保留版权声明即可，风险最低。2.Apache2.0：宽松，但有专利授权条款与NOTICE文件要求，需保留声明。3.LGPL：动态链接可闭源，修改库本身需开源，静态链接有争议，需谨慎。4.GPL：衍生作品需以GPL开源，闭源产品引入即污染。5.AGPL：网络服务使用也触发开源义务，SaaS场景同样受限，闭源产品与服务一律阻断。6.还有一类是"无许可证声明"，默认保留所有权利，不能直接用。追问：间接依赖是AGPL，直接依赖是MIT，你怎么处理？Q9.单测覆盖率80%，能说明代码质量好吗？参考答案要点：1.不能。覆盖率只说明"被执行过"，不说明"断言有效"。2.常见的水分：只调用不断言、断言恒真、mock掉全部依赖、覆盖的是getter与配置类。3.真正要看的是关键路径的覆盖：金额计算、状态流转、权限判断、异常分支是否被覆盖。4.审查动作：看未覆盖的行在哪，如果集中在异常处理与边界分支，风险高于数字显示的水平。5.覆盖率下降要问原因，覆盖率上升也要问"新增的测试有没有断言"。追问：如果一个MR把覆盖率从82%降到79%，你会阻断吗？Q10.怎么识别N+1查询？影响怎么估算？参考答案要点：1.识别：循环体（for、map、stream）内部出现查库、调远程接口、读缓存穿透到库。2.也包括ORM的懒加载：取列表时不查，序列化时逐条触发查询，隐蔽性更强。3.估算：列表条数乘单次查询耗时。200条乘5毫秒等于多1秒，加上网络往返通常更高。4.更严重的是连接池：200次查询并发时可能占满连接池，拖垮同实例的其他接口。5.修复方向：批量查询（IN或join）、预加载、缓存，而不是简单加索引。追问：如果列表最多只有20条，你还会要求改吗？Q11.幂等、并发控制、事务边界，三者是什么关系？参考答案要点：1.事务边界解决"要么全成功要么全失败"，解决不了"同一操作被执行两次"。2.幂等解决"重复请求产生同一结果"，通常靠唯一键、状态机前置判断、去重表。3.并发控制解决"两个请求同时修改同一资源"，靠乐观锁、悲观锁、条件更新。4.三者缺一不可：有事务无幂等会重复扣款，有幂等无并发控制会超卖，有锁无事务会状态不一致。5.审查动作：涉及资金与库存的改动，三个都要问到，问不出就阻断。追问：用唯一索引实现幂等，要注意什么？二、实操应用题（9题）Q12.给你180条扫描告警，2小时内出结论，你怎么做？参考答案要点：1.先聚类不去逐条看：按规则聚类，同类超过10条归为批量问题；再按文件聚类，剔除生成代码与测试代码。2.先砍高危：把Blocker级（注入、越权、密钥、反序列化）挑出来优先验证，每条限时60秒。3.再砍明显误报：上游已校验、框架已防护、代码不可达三类，快速标记并写成因。4.剩余逐条定性，按文件分组看，减少上下文切换。5.时间分配建议：聚类10分钟、高危40分钟、误报30分钟、剩余30分钟、写结论10分钟。6.明确说明：2小时内不可能逐条深挖，必须说明本次审查的覆盖边界，未覆盖部分在记录单上标注。追问：如果2小时后还剩40条没看，你怎么写结论？Q13.一个MR改了800行、涉及12个文件，40分钟内怎么审？参考答案要点：1.先看文件清单与变更分布，判断哪2～3个文件是核心逻辑，哪几个是配置、测试、格式化。2.要求作者提供变更说明或当面讲5分钟，比自己从零推断快得多。3.核心文件逐行看，配置与测试看关键项，纯格式化文件跳过。4.优先看"新增的入口"（接口、消费者、定时任务）与"修改的共享逻辑"（工具类、公共方法）。5.800行在40分钟内只能做到"结构性审查"，必须在结论里写明"未逐行审查的部分"，并建议拆分MR。6.长期方案：推动团队把MR控制在400行以内，超过的强制拆分。追问：作者拒绝拆分，说"逻辑就是连在一起的"，你怎么处理？Q14.作者说"这个接口外网访问不到，不用修"，你怎么回应？参考答案要点：1.不接受口头说明，要求给出证据：网关路由配置、网络策略、调用方清单。2.区分"当前不可达"与"设计上不应可达"：前者可能因配置变更而暴露，后者才安全。3.查历史：这个服务有没有曾经对外暴露过，有没有内网横向移动的风险。4.折中方案：若确实内网，可降级为Major，要求补服务间鉴权或网关白名单，并设复查时间。5.结论写进记录单：判定依据是"提供了哪些证据"，而不是"作者说"。追问：如果作者拿不出配置，只说"一直都是这样"，你怎么办？Q15.业务明天必须上线，你在代码里发现硬编码的生产密钥，怎么处理？参考答案要点：1.先定性：密钥是否可用于生产、权限范围多大、是否已在历史提交中。可用且高危，一律阻断。2.给出可执行的替代路径，而不是只说"不行"：改成环境变量或配置中心，通常1～2小时可完成，不必然影响上线。3.若确实来不及，走例外放行：业务负责人与技术负责人双签、临时补偿（如限制该密钥权限、加访问告警）、24小时内轮换、指定复核人。4.明确告知风险：密钥泄露的后果是数据被拖走，不是"上线晚一天"。5.全程留痕，审批单关联到MR。追问：如果业务负责人不肯签字，但要求必须上线，你怎么办？Q16.工具报了一处SQL注入，你怎么判断它是真缺陷还是误报？参考答案要点：1.找入口：这个参数从哪来，是请求参数、消息体、还是内部常量。2.走链路：从入口到拼接点，中间有没有类型转换、白名单、参数化。3.看拼接内容：拼的是值还是结构（表名、排序字段），结构位无法参数化，需要白名单。4.看可达性：这段代码有没有可能被执行，是否有前置条件永远不成立。5.看框架：如果用的是ORM的原始SQL接口，参数化是否真的生效。6.结论必须写出"利用条件"，写不出就标"需确认"而不是"误报"。追问：如果这个参数来自另一个内部服务的返回值，你怎么判断？Q17.看到一段"在循环里查数据库"的代码，你怎么估算它的影响？参考答案要点：1.先问数据量：这个列表最大返回多少条，是20条还是2万条。2.再问单次耗时：单条查询在本库的执行时间，是否走索引，是否跨库或跨服务。3.相乘得总量：200条乘5毫秒等于1秒，加上网络往返与序列化通常翻倍。4.看并发：这个接口的QPS是多少，乘上去是否超过数据库连接池上限。5.看是否有缓存或批量替代方案，评估改造成本。6.结论要带数字："在200条时多1秒，在2000条时会超时"，比"存在N+1问题"有用得多。追问：如果这个接口一天只调用10次，你还会要求改吗？Q18.新增了一个第三方依赖，你怎么审？参考答案要点：1.许可证：是否在企业白名单内，有无传染性条款，是否有NOTICE要求。2.漏洞：当前版本有无已知高危漏洞，修复版本是否可用。3.维护状态：近12个月有无提交，issue是否有响应，作者是否活跃。4.来源：是否来自官方仓库或企业私有源，包名是否与知名库高度相似（抢注风险）。5.传递依赖：展开依赖树，看间接依赖是否引入问题包。6.必要性：这个功能能否用现有依赖或标准库实现，引入一个新依赖的长期维护成本是否值得。7.锁文件：是否提交了lockfile，版本与哈希是否锁定。追问：如果这个包只有3个star、最近一次提交是4年前，但功能正好合适，你怎么建议？Q19.审AI生成的代码，和审人写的代码，关注点有什么不同？参考答案要点：1.AI代码通常"形式完美"：命名规范、注释齐全、结构工整，容易通过形式审查，反而要更警惕。2.重点查四类：调用了不存在的API或参数（幻觉）、复制了过时或有漏洞的实现、引入了不可信依赖、许可证来源不明。3.查语义：AI容易写出"看起来对但边界错"的逻辑，比如分页少一页、金额四舍五入方向错、异常分支返回默认值。4.查一致性：AI生成的代码可能与本项目的既有约定不符（日志格式、错误码、事务写法）。5.查重复：AI倾向于复制粘贴已有实现再改一半，容易产生重复逻辑与不一致。6.流程上：AI生成占比超过30%的MR要升级风险等级，并加查依赖与许可证。追问：如果AI生成的代码测试全过，你还会额外查什么？Q20.线上出现重复扣款，你怎么回溯审查环节？参考答案要点：1.先定位：查日志与调用链，确认重复是同一请求重试、消息重投、还是用户连点。2.看当时diff：审查阶段有没有相关行，是否属于"可见但没看到"。3.分三种归因：没查（流程问题）、看不懂（能力问题）、判成误报（标准问题），三者改进方向不同。4.查工具：当时扫描报了吗，报了为什么被忽略，没报则补规则。5.查同类：全库检索相同模式（无幂等键的扣款入口），发起专项排查。6.沉淀：至少落一项——规则、检查项、培训案例、流程卡点，指定责任人与完成时间。追问：如果回溯发现是测试没覆盖，责任怎么算？三、项目经验题（7题）Q21.讲一次你拦下的最严重的问题，从发现到闭环完整说一遍。追问链：1.第一层：这个问题具体是什么？在哪个文件、哪一行、什么条件下会被利用？2.第二层：你是怎么发现的？工具报的，还是自己看出来的？如果是工具报的，你怎么确认不是误报？3.第三层：作者第一反应是什么？你怎么说服他的？有没有争议？4.第四层：最后怎么修的？修完你怎么验证？有没有查同类代码？5.第五层：这件事之后，团队流程有什么改变？评分要点：能说清利用条件（4分以上）；能说出作者的反应与说服过程（4分）；能说出后续的流程改进（5分）。红旗：只说"发现了一个高危漏洞"却说不出利用条件；把团队功劳说成个人功劳；说不出修复后的验证方式。Q22.讲一次你判错的误报，后来出了什么问题。追问链：1.第一层：当时你依据什么判定它是误报？2.第二层：后来这个问题以什么形式暴露的？线上事故、测试发现，还是同事提醒？3.第三层：你的判定错在哪一步？是数据流没走完，还是轻信了某个前提？4.第四层：同类代码你排查了吗？排查出多少处？5.第五层：你现在的判定标准跟当时有什么不同？评分要点：能坦率承认（3分）；能准确定位错在哪一步（4分）；能说出标准的具体变化（5分）。红旗：说"我从来没判错过"；把责任推给工具或作者；说不出后来做了什么改变。Q23.讲一次你和开发作者的争议，最后怎么解决的。追问链：1.第一层：争议的核心是什么？是事实分歧（是不是漏洞）还是标准分歧（要不要阻断）？2.第二层：你提供了什么证据？对方提供了什么证据？3.第三层：有没有升级到第三方仲裁？谁仲裁的，依据是什么？4.第四层：结果是谁对？如果你错了，你怎么处理的？5.第五层：这件事有没有变成团队的判定标准？评分要点：能区分事实分歧与标准分歧（4分）；能说出证据而非情绪（4分）；能把个案沉淀为标准（5分）。红旗：把争议描述成"对方不讲理"；靠职级压人；没有仲裁机制也能"解决"。Q24.讲一次你推动的门禁规则改进，效果怎么衡量。追问链：1.第一层：改之前是什么规则？为什么需要改？2.第二层：改动涉及哪些人？你怎么说服他们？3.第三层：上线后误报率、拦截率、交付时长各有什么变化？4.第四层：有没有出现"为了过门禁而写假代码"的情况？怎么发现的？5.第五层：如果重来一次，你会怎么做得不一样？评分要点：有前后对比数字（4分）；能说出阻力和化解方式（4分）；能反思副作用（5分）。红旗：只说"推动了规则上线"，没有任何数字；不提副作用；把跨团队配合说成个人成果。Q25.讲一次你做的逃逸回溯，最后沉淀出了什么。追问链：1.第一层：这个缺陷在审查阶段能看到吗？当时的diff里有没有相关行？2.第二层：工具报了吗？报了为什么没处理，没报为什么没报？3.第三层：同类代码排查出多少处？怎么排查的？4.第四层：最后落了哪几项改进？规则、检查项、培训还是流程？5.第五层：三个月后，同类问题还有发生吗？评分要点：五问齐全（4分）；有可验证的改进项与责任人（4分）；有后续效果跟踪（5分）。红旗：把回溯做成追责会；改进项只有"加强意识"；没有责任人也没有时间。Q26.讲一次你处理开源许可证冲突的经历。追问链：1.第一层：是什么许可证？在哪个依赖上，直接还是间接？2.第二层：你怎么发现的？工具报的，还是自己展开依赖树看到的？3.第三层：你怎么判断它构成冲突？依据是什么，有没有咨询法务？4.第四层：最后怎么解决的？替换、隔离、还是取得授权？5.第五层：替换的成本有多大？有没有影响工期？评分要点：能区分直接与间接依赖（4分）；知道自己的判断边界、会转法务（4分）；能说清替换成本（5分）。红旗：凭印象判断许可证；自己下法律结论；不知道AGPL对SaaS的影响。Q27.讲一次发版高峰期的排班或优先级处理。追问链：1.第一层：那段时间每天多少个MR？峰值是多少？2.第二层：你怎么决定先审哪个？依据是什么？3.第三层：有没有出现过审不过来、被迫降低标准的情况？4.第四层：你怎么保证在疲劳状态下不漏高危项？5.第五层：事后有没有调整流程，避免下次再出现？评分要点：有具体数字（4分）；有明确的优先级规则（4分）；能承认极限并设计兜底（5分）。红旗：宣称"再忙也没漏过"；靠加班硬扛没有机制；把降低标准说成灵活处理。四、风险与避坑题（9题）Q28.你阻断了某个MR，作者找了他的领导特批，要求你放行。你怎么处理？参考答案要点：1.不直接对抗，也不直接放行，先把事实摆清：问题是什么、利用条件、可能后果，用书面形式发给双方。2.走正式例外流程：双签、补偿措施、整改期限、复核安排，四件齐全才放行。3.明确责任归属：审批单上写清"由谁批准例外"，审查员的签字只代表"已如实报告风险"。4.事后跟踪整改，到期未改的升级到质量负责人。5.如果企业没有例外流程，这本身就是问题，应在月度会上提出建立流程。追问：如果领导说"出了事我负责"，但没有书面记录，你怎么办？Q29.团队嫌扫描工具误报太多，要求关掉，你怎么应对？参考答案要点：1.先认同问题：误报确实影响效率，关掉是合理诉求的一部分。2.用数据说话：统计误报的类型分布，找出占比最高的2～3条规则，针对性调整而非整体关闭。3.分层处理：高危规则保持开启，低危规则降级为提示不阻断，历史遗留问题进基线。4.给出替代方案：设"每周误报TOP5"机制，持续优化，让团队看到噪音在下降。5.底线：密钥扫描与高危注入类规则不能关，这两类的漏报代价远大于误报成本。追问：如果调整后误报还是很多，你会怎么向团队交代？Q30.你发现直属上级的代码有严重安全问题，怎么办？参考答案要点：1.先确认事实：走完数据流，确认利用条件，避免误判导致尴尬。2.私下沟通优先：一对一说明问题与证据，给对方留出改正空间。3.走正常流程：在MR上留意见，按级别阻断，不因为对方是上级就降级。4.如果被要求放行，要求走例外流程并留痕，把责任归属写清楚。5.涉及重大风险且被强行压下的，按企业合规渠道上报，这是职业底线。追问：如果私下沟通后对方说"我知道，这是临时方案"，你怎么判断真假？Q31.上线后出了事故，有人要求你补一份"当时审过"的记录，你怎么处理？参考答案要点：1.拒绝补签。补记录属于伪造，事故认定时会被视为重大过错，对个人与企业都不利。2.如实说明：当时的审查范围、结论、有无留痕，有就提供，没有就承认没有。3.配合回溯：把精力放在"为什么没发现、怎么防止再发生"，而不是修补记录。4.如果企业制度要求必须留痕而当时没做，这是流程缺陷，应在复盘中提出。5.明确边界：审查员对"按范围审查"负责，不对"替别人掩盖"负责。追问：如果是你的上级要求补，且说"只是走个形式"，你怎么拒绝？Q32.有人提议把公司代码贴到公网AI工具里辅助审查，你怎么看？参考答案要点：1.默认不允许。代码是核心资产，上传即视为泄露，且可能被用于训练。2.例外需要三个前提：企业已批准该工具、已签署数据处理协议、代码已脱敏或属于低敏感级别。3.即便批准，也要限制范围：不得上传密钥、个人信息、核心算法、未公开的业务规则。4.替代方案：内网部署的模型、企业版API（承诺不训练）、本地规则引擎。5.这类事一旦发生，按泄露事件处理，不是"个人习惯"问题。追问：如果工具厂商承诺"不用于训练"，是否可以放宽？Q33.外包团队交付的代码质量很差，但合同工期只剩一周，你怎么处理？参考答案要点：1.先分级：把问题分成"必须修"（安全、资金、数据错误）与"可带着上线"（可维护性、风格）。2.必须修的部分，明确列出清单与验收标准，要求限期整改，不接受"下期优化"。3.可带着上线的部分，写入技术债清单，约定后续迭代偿还，并明确责任方。4.同步商务侧：质量问题应反馈到验收环节，必要时按合同条款处理，而不是由审查员独自扛。5.长期方案：把审查标准前置到外包合同里，明确交付质量门槛与验收口径。追问：如果外包方说"合同里没写这些标准"，你怎么回应？Q34.你判了阻断，架构师说"这个设计就是这样，可以放"，你怎么处理？参考答案要点：1.先分清是"设计取舍"还是"实现缺陷"。设计取舍可以放，实现缺陷不能放。2.要求架构师给出书面说明：这个风险是被接受的，接受的理由是什么，有无补偿措施。3.如果是设计层面的已知风险，把它记入架构决策记录，审查员按"已知风险"处理，不再重复阻断。4.如果架构师的说法与实际代码不符（如声称有网关防护但配置里没有），坚持要证据。5.最终以书面记录为准，口头同意不算。追问：如果架构师坚持不写书面说明，你怎么办？Q35.事故复盘会上，有人把责任定到你"审查没拦住"，你怎么应对？参考答案要点：1.不急着辩解，先摆事实：当时的diff里有没有相关行、工具报没报、你做了什么处置。2.区分三种情况：可见未发现（有责任）、不可见（无责任）、可见但被判为误报（部分责任，需看判定依据是否合理）。3.用记录单说话，而不是记忆。这也是为什么每次审查都要留痕。4.承认该承认的部分，提出改进项；不该承担的，明确说明边界。5.推动建立客观归因机制，避免每次事故都变成互相指责。追问：如果记录单当时没写全，你还有别的证据吗？Q36.长期看大量告警，判断力会下降，你怎么保持状态？参考答案要点：1.固定审查窗口，不随时被打断；每50分钟休息10分钟，单日深度审查不超过5小时。2.批量处理同类问题，减少上下文切换；先高危后长尾。3.建立个人判定清单与误判笔记，把"凭感觉"变成"按条目"。4.定期轮换审查模块，避免对某类代码产生麻木。5.用数据自检：每周抽10条自己判过的误报重看一遍，看是否仍成立。追问：如果团队只有你一个审查员，没法轮换，怎么办？五、开放思辨题（7题）Q37.AI审查工具越来越强，这个岗位五年后还存在吗？评分要点：●高分答案：承认工具会替代大量模式化工作，同时指出"放行责任"无法由工具承担——不是技术问题，是责任主体问题。●能具体说出哪些环节会被替代（规则匹配、去重、初筛），哪些不会（业务语义、并发推演、责任签字）。●能预测岗位形态变化：从"逐条看告警"变成"设计判定标准、治理误报、处理例外"。●低分答案：要么说"AI永远替代不了人"（空话），要么说"迟早被替代"（没有分析）。Q38.门禁应该多严？太严会拖慢交付，太松会放走问题。评分要点：●高分答案：按风险分级设不同严格度，而不是一刀切。R0严到"零容忍"，R3只看扫描结论。●能给出量化思路：例外放行率控制在10%以内，超过说明门禁与业务节奏不匹配。●能指出"严"的成本：开发者会想办法绕过（拆分MR、改配置、找特批），这比放松更危险。●低分答案：只强调"安全第一"或只强调"效率优先"，没有权衡。Q39.代码风格问题该不该在审查里提？评分要点：●高分答案：风格应该交给工具自动化（格式化、lint），审查只处理工具管不了的语义问题。●能说出理由：人提风格问题会引发情绪对抗，且标准主观，收益极低。●能给出边界：涉及可读性且会导致误用的命名问题，可以提，但要定为Minor。●低分答案：认为"风格也是质量"，逐条提；或认为"完全不看风格"。Q40.专职审查员和资深开发兼任，哪个更好？评分要点：●高分答案：看规模与风险。MR量大、有资金与合规要求时，专职更稳；小团队兼任更现实。●能说出兼任的弊端：审查被排期挤压、尺度随人变化、无人对逃逸率负责。●能说出专职的弊端：脱离业务久了会看不懂上下文，容易变成"规则执行机器"。●能给出混合方案：专职做标准与高危，兼任做业务模块的初审。