AI时代技术面试：DeepMind限制AI背后的能力评估新逻辑

最近有一个关于谷歌 DeepMind 招聘流程的讨论很有意思据说在部分技术岗位的招聘环节中候选人被要求“尽量避开自家 AI 工具”来完成测评。这个新闻初看像是一种“自我拆台”毕竟 DeepMind 本身就是做 AI 的它旗下的模型产品也一直在强调辅助编程能力。但如果我们把这件事放到技术人才评估、开发流程和 AI 辅助编程的大背景下看它真正触碰的是一个所有技术团队都会越来越头疼的问题当 AI 能帮你完成大量代码工作之后面试官还能靠什么来判断候选人的真实水平这篇文章不打算停留在“大厂招聘八卦”层面。我想从技术视角拆解这件事为什么技术面试必须重新设计AI 辅助开发在哪些环节该用、哪些环节该限制候选人该怎么准备以及技术负责人该怎么把“AI 使用边界”落到团队的日常工程规范里。无论你是准备面试的开发者还是需要设计面试流程的技术管理者这篇文章都会给出一些可执行的建议。先亮明我的核心判断DeepMind 要求候选人“避开自家 AI”并不是反对 AI 编程也不是要回到“手写一切”的原始时代。它要解决的是技术面试中的“信号失真”问题。如果候选人提交的代码可以轻易由 AI 生成面试官就无法分清哪些能力属于候选人、哪些能力属于模型。这不是拒绝 AI而是在重新定义“能力”的评估方式。1. 这件事为什么值得技术人关注技术圈对 AI 辅助开发的讨论过去两年的焦点一直是“AI 能不能写代码”“AI 写代码准不准”。但 DeepMind 这个招聘细节把讨论推到了下一个阶段AI 已经默认存在于开发流程中团队和组织开始要考虑“如何在有 AI 的环境里评估人”。很多开发者听到“面试不让用 AI”的第一反应是抵触觉得这是反潮流。但换个角度想就清楚了如果一家公司招的是“能熟练使用 AI 的工程师”那它完全可以考察候选人的 Prompt 能力、工具链使用、代码审查能力而不是出一些“不用 AI 也能答”的算法题。既然 DeepMind 选择在某个环节刻意屏蔽 AI说明这个环节要考察的能力恰恰是 AI 无法替代的部分。这部分能力是什么是问题拆解能力是调试和排错能力是理解系统运行机制的能力是在信息不完整时做出判断的能力。很多 AI 编程工具能生成一段看起来对的代码但真正的工程师价值在于知道这段代码为什么会错知道系统在什么场景下会崩溃知道怎么设计边界条件。而这些能力恰恰需要在“没有标准答案生成器”的环境里才能被真实观察。无论你是面试者还是面试官这件事都值得你重新想一想你参与的技术面试到底在考察什么如果候选人打开一个 AI 工具就能完成大部分题目那你的面试题还有没有区分度2. 事件背景与技术解读先说明一点关于“谷歌 DeepMind 招聘避开自家 AI”的具体细节不同渠道的表述不完全一致有说是技术测评环节禁用 AI 辅助有说是某些岗位明确要求候选人独立完成编码测试。材料没有给出统一的官方口径所以我不会对细节做过多断言。但有一个背景是明确的DeepMind 本身就是一家以 AI 研究为核心的机构它旗下的模型产品具备很强的代码生成能力而它自己在招聘 AI 相关岗位时反而要求候选人在测评中暂时放下 AI 工具。这种反差本身值得从技术层面解读。这里真正的技术关键词是“评估有效性”。技术面试本质上是一场信号采集面试官通过候选人的回答、代码、设计思路来判断其能力水平。当 AI 工具变成“辅助外脑”时面试官采集到的信号就变成了“候选人 AI”的混合信号。混合信号的问题在于如果候选人本身能力不足但 AI 补足了一部分面试官很难准确评估候选人的基线能力反过来如果候选人能力很强但过度依赖 AI面试官也可能误判。经济学里有一个概念叫“信号甄别”用在技术招聘里非常贴切——当每个人都能轻松获得高分答案时分数就不再携带信息量了。这不是说“所有面试环节都不能用 AI”。更合理的解读是不同的招聘环节应该考察不同的能力AI 的使用边界应该随着考察目标而变化。比如面试环节考察目标是否建议使用 AI 辅助数据结构和算法测评逻辑思维、基础编码能力、边界处理建议禁用系统设计架构思维、需求权衡、全局观可以用 AI 辅助查漏但核心设计需独立完成项目实战或小型开发任务工程能力、工具链运用、代码规范允许使用 AI更接近真实工作代码评审环节发现问题的敏锐度、对细节的把握禁止AI 容易“剧透”答案行为面试沟通表达、协作思维、决策逻辑与 AI 无关从这张表可以看出来DeepMind 的“避开自家 AI”并不是铁板一块它大概率是针对某个特定环节的设计而不是全流程禁止。但它的信号意义在于AI 时代招聘评估必须分场景设计不能再简单出一道算法题就判断候选人的全部能力。3. 技术面试为什么需要“屏蔽 AI”从认知科学和测量学角度分析如果只停留在“面试不让用 AI”的表面就很难理解这件事的深层价值。技术面试中“屏蔽 AI”背后的逻辑和考试中“闭卷 vs 开卷”的争论很像但它比开闭卷问题更复杂。3.1 面试题考察的是“问题解决的结构”而不是“答案”一道好的技术面试题答案本身并不重要重要的是候选人展示出来的思考路径。比如候选人拿到一道“设计一个短链接服务”的系统设计题他需要做的是明确需求读多写多单机还是分布式需不需要统计点击分析约束数据量级、延迟要求、可用性要求。生成方案哈希算法、发号器、缓存策略、数据库选型。推演权衡为什么用 Redis 而不是 MySQL为什么用发号器而不是随机字符串如果候选人直接让 AI 生成一个完整的系统设计他确实能得到一份结构合理的答案。但面试官想要观察的“权衡过程”和“取舍逻辑”就全部消失了。面试官看到的只是最终产物而技术面试的核心价值恰恰在于观察过程。这就是为什么在考察核心能力时需要屏蔽 AI——它并不只是防止作弊更是保护面试官获取有效信息的能力。3.2 “依赖 AI”和“使用 AI”的区别这里要做一个重要区分。业内人士讨论的“使用 AI 编程”通常包含两种截然不同的方式完全依赖式直接把需求交给 AI让 AI 生成完整代码人只做搬运。协作增强式人主导设计和拆解AI 用来补全样板代码、查资料、写测试、做代码审查。这两种方式对应的能力模型完全不同。前者要求最多的是“把需求描述清楚”的能力后者要求的是完整的工程判断力。面试中“避开自家 AI”真正要剔除的其实是完全依赖式的作答因为它无法体现候选人的工程判断力。协作不是问题盲从才是问题。这比“能不能用 AI”更接近本质。3.3 能力退化风险与“组块化”现象认知科学里有一个现象叫“组块化”当一个人长期依赖外部工具完成某项任务时他对该任务底层机制的敏感度会下降。比如长期用 ORM 的开发者可能对 SQL 执行计划不敏感长期用 Docker 的开发者可能对 Linux 进程模型不熟悉。AI 编程工具的潜在风险也是类似的如果开发者长期只负责“检查 AI 生成的代码能否跑通”而不去理解代码背后的原理他的独立排错能力会慢慢退化。这不是反对使用 AI而是提醒我们AI 补足的是“知识检索”和“代码生成”的短板但“定位问题”“理解交互”“权衡取舍”这些能力仍然需要人自己积累。在面试中屏蔽 AI某种程度上也是对候选人“真实能力是否还在线”的一次校验。这对候选人本人其实是一种保护——至少它提供了反馈你脱离了 AI 之后还能不能写出合格的代码。4. AI 时代如何设计技术面试流程大厂的具体招聘流程我们没法完全复制但它的思路可以迁移到任何技术团队。如果你正在负责团队招聘下一轮技术面试可以尝试分成两个阶段设计。4.1 阶段一基础能力测评屏蔽 AI这个阶段的目的是考察候选人的基线能力。设计原则题目不需要偏怪难但需要足够“基础且需要思考”。要求候选人现场共享屏幕在纯文本编辑器中完成不开启 AI 插件。重点观察候选人从拿到题目到写出代码的过程包括思考时间、是否先理清思路再动手、如何做边界检查。题目要有多个备选答案避免候选人背题。这个阶段不适合使用过难的题它应该是“筛选器”而不是“放大器”。主要筛选的是那些没有独立编码能力的简历型候选人。这里的关键词是“公平”如果你要判断候选人的独立能力就必须给所有人创造同样的独立环境。4.2 阶段二工程协作测评开放 AI第二阶段的思路相反既然真实工作中大家都会用 AI那就可以把 AI 变成考察工具。这个阶段可以设计成一个“用 AI 完成一个小型功能开发”的任务重点观察候选人如何拆解任务。候选人如何写 Prompt 来引导 AI。候选人对 AI 生成代码的审查能力能不能发现 bug能不能指出优化点候选人在 AI 生成代码跑不通时的排错路径。这个阶段评分可以参考下面的维度评分维度权重观察要点任务拆解能力25%是否能将大任务拆成可执行的小步骤Prompt 设计能力20%是否能清晰描述需求和约束代码审查能力30%是否能发现 AI 生成代码中的错误排错与调试能力25%AI 代码出错时能否独立定位问题从材料看DeepMind 的“避开自家 AI”更像是阶段一的设计思路。但它没有否定阶段二的存在价值。对技术管理者来说最需要记住的是不是“用不用 AI”的问题而是“在哪个环节用 AI 能帮助你评估哪种能力”的问题。4.3 面试题设计的新标准AI 时代一道好的技术面试题需要同时满足三个条件不依赖“标准答案”如果 AI 能稳定给出高分答案这道题就废了。开放性和约束性并存题目要开放但要有明确的非功能约束比如“要求响应延迟低于 200ms”“要求支持 10 万并发”。能引出“为什么”面试官要能在候选人的方案里追问为什么观察候选人的应变能力和深度。如果发现现有题库里 80% 的题都可以让 AI 直接解出来那面试官就要意识到不是候选人水平有问题而是题目的甄别能力已经被时代淘汰了。这不只是招聘的问题也是整个技术团队能力评估体系需要升级的信号。5. 候选人视角AI 时代怎么准备技术面试如果说面试官需要重新设计流程那候选人同样需要调整准备策略。过去准备面试就是刷题、背八股、看源码但 AI 时代这套路径有些失效了。更稳妥的准备方式是围绕下面几个方向展开。5.1 确保“脱离 AI 后的基本生存能力”这是最直接的一条建议。既然有些面试环节会屏蔽 AI那候选人就必须保证自己的独立编码能力不过度退化。准备方法是每周至少抽出一段时间关闭所有 AI 插件在纯文本编辑器中做几道算法题或写一个小工具。这个过程不是“倒退”而是“保持基线”。具体操作可以是这样的# 准备一个本地练习目录不接入任何 AI 插件 mkdir -p ~/interview-practice cd ~/interview-practice # 创建一个纯后端练习项目不依赖 AI 补全 npm init -y touch index.js # 练习时关闭编辑器的 AI 插件 code --disable-extension GitHub.copilot --disable-extension Continue.continue index.js上面的命令演示了如何用 VS Code 的--disable-extension参数临时禁用 AI 插件为自己创造一个“无 AI 练习环境”。平时可以依赖 AI 提高效率但练习时一定要留出无 AI 时间让大脑保持对代码的主动控制。5.2 把“AI 协作能力”变成可展示的资产既然“会用 AI”也是招聘考察点那就别藏着。建议准备一份“AI 协作案例集”内容包括你平时用什么 AI 工具用在什么环节。你是如何设计 Prompt 的需求拆解怎么做。你遇到过 AI 生成错误代码的情况吗怎么发现和修正的有没有因为 AI 帮助而明显提升效率的案例这套案例集的作用是让面试官知道你既有独立能力又能高效使用现代工具。在“开放 AI”的面试环节把这些讲清楚效果会比单纯说“我熟练使用 AI”好得多。5.3 准备“无 AI 调试”能力AI 时代最容易退化的能力是调试。因为 AI 生成的代码通常是“看起来对”的一旦运行出错很多开发者会直接把错误信息丢回给 AI让它自己修。这在真实工作中没有问题但面试中如果遇到“屏蔽 AI”的场景调试能力就变成了硬实力。调试能力的准备没有捷径只有多练。建议的做法是找一些开源项目的 issue把代码拉下来在不使用 AI 的情况下复现 bug、定位根因、提交修复。这个过程训练的是搜索代码、打断点、看日志、验证假设的完整链路。很多资深工程师的不可替代性其实就体现在排错速度上。6. 从招聘到日常工程团队该不该限制 AI 使用招聘只是入口团队日常开发中的 AI 使用管理其实更复杂。很多团队现在面临的一个尴尬处境是管理者既希望用 AI 提升人效又担心 AI 生成代码带来质量问题和安全隐患。一味禁止不现实完全放任也不负责任。更合理的是建立一套“分级使用规范”。6.1 根据代码风险等级划分 AI 使用方式不是所有代码都适合直接使用 AI 生成。建议按风险等级做区分风险等级代码类型AI 使用建议低风险示例代码、测试代码、脚本工具、文档可以大量使用 AI中风险业务逻辑代码、常规 CRUD可以使用 AI但必须有代码评审高风险权限认证、支付交易、数据迁移、加密解密限制 AI 生成必须人工编写并双重评审这个分级的意义在于既没有一刀切地禁用 AI也没有让 AI 触碰核心风险区域。权限认证和支付交易这类代码一旦出现逻辑漏洞损失远大于效率提升。在关键路径上人必须保持对代码的完全控制权。6.2 固化到 CI/CD 流程中分级使用规范不能只停留在口头建议把关键约束固化到工具链里。比如团队可以约定高风险模块的代码提交必须有特定标识并触发额外的评审流程。下面是一个简化的 CI 检查脚本演示如何拦截“高风险模块中直接提交 AI 生成代码”的情况# 文件路径.github/workflows/ai-code-check.yml name: AI Code Check on: pull_request: types: [opened, synchronize] jobs: check-high-risk-code: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - name: Check high-risk module changes run: | HIGH_RISK_PATHSsrc/main/java/com/example/payment/|src/main/java/com/example/auth/ CHANGED_FILES$(git diff --name-only origin/main...HEAD | grep -E $HIGH_RISK_PATHS) if [ -n $CHANGED_FILES ]; then echo High-risk files changed, requires manual review. else echo No high-risk changes. fi这个脚本不是要阻止高风险代码变更而是确保这些变更被人工关注。它把风险控制的“开关”从依赖个人自觉变成了一个工程流程。对于已经广泛使用 AI 编程的团队这类规则比“不要用 AI 写支付代码”这种口头要求可靠得多。6.3 在代码评审中加入“AI 痕迹检查”日常代码评审中建议增加一个维度“这段代码你是否真正理解”如果开发者自己都解释不清 AI 生成的代码为什么这么写那这段代码就不应该合入。具体操作上可以在评审问题清单里加入下面几条这段代码为什么需要全局变量类之间的关系清楚吗异常处理路径是否完整AI 生成的代码往往会漏掉边界异常。是否有隐藏的循环依赖或 O(n²) 复杂度问题这段代码所用的 API 是否真的存在是否过时AI 生成的代码有两个高频问题一是幻觉 API二是忽略上下文。这两个问题在自动化测试里往往看不出来只有在代码评审的人类视角下才能有效拦截。AI 提高了代码产出速度代码评审提高了代码质量下限这两者的配合才是正循环。7. 完整示例如何在团队落地“AI 使用规范”说了这么多给出一套可以直接拿来改的配置和规范文档帮助团队从“口头讨论 AI 用不用”变成“可执行、可检查”的工程规范。7.1 编写团队 AI 使用规范CONTRIBUTING.md 片段团队仓库里建议增加一个AI_USAGE.md文件内容可以参考下面这个模板# AI 辅助开发使用规范 ## 允许使用的场景 - 编写单元测试和集成测试 - 生成重复性 CRUD 代码 - 编写开发脚本和自动化工具 - 辅助编写文档和代码注释 - 代码重构建议 ## 限制使用的场景 - 涉及用户权限判断的逻辑必须人工编写 - 涉及资金、支付、优惠券计算的逻辑必须人工编写并附带测试 - 涉及数据迁移和删除操作的脚本必须人工编写并通过评审 ## 强制要求 1. 所有 AI 生成的代码提交前必须经过人工代码评审。 2. 提交信息中如果代码由 AI 辅助生成请在 PR 描述中注明。 3. 发现 AI 生成代码存在错误时应先定位根因再决定修复方式。 4. 禁止将包含敏感信息的代码片段粘贴给外部 AI 工具。 ## 评审清单 - [ ] 代码作者能够解释每一段核心逻辑 - [ ] 异常处理路径完整 - [ ] 没有未使用的导入和死代码 - [ ] 性能边界符合要求 - [ ] 权限与安全逻辑已由人工审查这份文档的价值在于把模糊的“尽量少用 AI”变成了可以对照检查的清单。实际使用时团队可以根据自己的技术栈和风险偏好做增删。核心是边界要明确检查要可执行。7.2 用 Git Hooks 拦截高风险提交如果团队希望进一步自动化可以在 Git 层面增加一个pre-commit钩子用来提示开发者当前提交涉及高风险模块。脚本示例如下#!/bin/sh # 文件路径.git/hooks/pre-commit HIGH_RISK_DIRSpayment/ auth/ admin/ migrate/ for dir in $HIGH_RISK_DIRS; do if git diff --cached --name-only | grep -q $dir; then echo 警告本次提交涉及高风险目录 $dir请确认代码已经过人工审查。 echo 如果确认无误可以输入 yes 继续提交 read -r CONFIRM if [ $CONFIRM ! yes ]; then echo 提交已取消。 exit 1 fi fi done exit 0这个钩子的作用是增加一道心理闸门让开发者每次提交高风险代码时都意识到这段代码不是“写完就行”要有额外审查。它不能替代真正的评审但能减少“不经意的高风险变更”。7.3 一键生成代码审查记录AI 辅助开发还有一个实操痛点代码评审时要回溯“这段代码是不是 AI 生成的”“AI 版本和最终版本差在哪里”。建议团队在 PR 描述中使用固定模板## 变更说明 - 功能描述xxx - 是否使用 AI 辅助是 / 否 - 使用方式 - AI 生成初稿人工修改 - 人工编写核心逻辑AI 辅助补全 - AI 用于代码重构和测试生成 - 人工审查重点 - 权限逻辑是否经过人工检查 - 异常处理是否完整 - 关键算法是否经过性能验证这段描述让评审者可以快速定位审查重点。如果 AI 生成的代码涉及高权限模块评审者会天然提高警惕。代码评审的效率不是靠信任提升的而是靠信息透明度提升的。8. 常见误区与风险排查围绕“AI 用于招聘和开发”网上有很多讨论但有不少属于误区。我把常见的问题整理成表格方便对照。问题现象可能原因排查方式解决方案候选人背题题目答案和 AI 生成内容高度相似题目缺乏开放性和场景化查看候选人思考过程追问“为什么”升级题库增加系统设计和场景题候选人在共享屏幕上偷用 AI 工具监考流程不严格面试官观察浏览器插件列表和编辑行为明确告知“该环节禁用 AI”使用本地编辑器团队使用 AI 后线上故障变多AI 生成了不可预期的边界逻辑复盘故障代码是否经过人工评审强制高风险模块的人工评审开发者解释不清自己提交的代码过度依赖 AI未真正理解逻辑代码评审时要求作者逐行解释评审不通过要求作者重写关键逻辑AI 生成代码引用了不存在的 API模型幻觉检查编译日志和运行时错误强调代码评审增加编译和单元测试环节团队完全禁止 AI导致开发者抱怨工具落后管理方式过于僵硬召开技术分享会收集开发者反馈用分级规范代替一刀切使用 AI 时粘贴了公司内部敏感代码安全意识不足检查工具日志和泄漏风险禁止向外部 AI 工具粘贴敏感代码使用私有化部署方案这里特别想强调一条不要因为 AI 写代码很快就跳过代码评审和测试。AI 生成代码的能力越强工程质量管控就越重要。团队如果只看到效率提升没有同步升级质量管控手段那效率提升的代价往往就是线上事故。9. 给不同人群的实践建议不同身份的人可以从这件事里获得不同的行动项。9.1 应届生和初级开发者最需要重视的是“脱离 AI 后的基本功”。真正能让你在面试中脱颖而出的不是“我用过多少 AI 工具”而是你对基础知识的掌控程度。建议把“无 AI 编码练习”纳入每周计划保持自己对代码的敏感度。同时把 AI 作为学习工具使用让 AI 解释代码、生成测试用例、做代码 review这些都是高效的学习反馈。关键是要区分“用 AI 学习”和“用 AI 替代思考”。9.2 社招候选人社招面试更多看项目经验和系统设计能力这对 AI 时代的面试适应力要求更高。建议把精力放在“能讲清楚一个完整项目”上项目的技术选型、架构变动、线上问题、性能优化这些深度经历是 AI 无法替代的。面试前也建议做一个模拟演练如果面试官不让你用 AI你能不能在一个小时内完成一道系统设计题并讲出权衡过程。9.3 技术负责人和面试官重点任务是重新设计评估体系。不要停留在“面试时不让用 AI”这种口号上而是要明确哪些环节屏蔽 AI考察独立能力。哪些环节开放 AI考察协作能力。评分标准是否足够客观能否区分“人强”和“AI 强”。具体可以指定一位同事专门负责整理现有题库把所有能被 AI 轻易解决的题目标记出来逐步替换为场景化、开放式的题目。这项工作越早做团队的招聘质量就越有保障。9.4 给团队管理者的额外提醒AI 对团队的影响不只在招聘和代码质量还涉及到团队的学习氛围。如果一个开发者长期依赖 AI不主动理解底层原理他的成长曲线会逐渐放缓。管理者可以在团队内部设立“无 AI 日”或者“手写核心逻辑挑战”鼓励大家保持基本功。这不是为了限制工具而是为了保持团队的整体技术水位。10. 总结回过头看“谷歌 DeepMind 招聘避开自家 AI”确实是一个有反差的新闻。但从技术视角拆下来它讨论的不是“AI 要不要用”而是“在 AI 无处不在的时代我们如何识别和培养真正属于人的技术能力”。技术面试的本质是评估人的能力而不是评估“人 AI”的组合能力。如果未来大多数编码工作都可以由 AI 承接那么工程师的价值会进一步向问题定义、系统设计、风险判断和排错能力集中。这些能力无法通过“让 AI 写一段代码”来获取只能通过长期、主动的工程实践来沉淀。对开发者来说最好的准备不是拒绝 AI也不是完全依赖 AI而是保持两条腿走路一边熟练使用 AI 提升效率一边持续训练自己在没有 AI 时的独立解决问题能力。无论未来面试形式怎么变这两点都是不变的底层能力。