AI时代技术招聘的新课题：DeepMind为何要求候选人避开AI

最近看到了关于谷歌 DeepMind 招聘流程的一个讨论：有消息说，DeepMind 在部分招聘环节中会要求候选人“避开自家 AI”，也就是在完成面试评估或编程测试时，不要使用自家的 AI 工具来辅助作答。这条规则乍一看有点反直觉——一家全球顶尖的 AI 研究机构，为什么会禁止候选人用 AI？尤其在“用 AI 写代码”已经越来越普遍的今天，这个问题对普通开发者、技术管理者、面试官都有很强的参考价值。

这篇文章不打算只做新闻复述，而是从技术招聘、能力评估、AI 工程实践三个角度展开。如果你正在准备算法或系统设计面试，或者你负责团队招聘、需要设计一套不被 AI 干扰的评估流程，这篇文章会提供一套完整思路和可执行的落地方案。

1. 事件背景：谷歌 DeepMind 招聘中的“避开自家 AI”到底在说什么

1.1 事件本身是什么

根据公开讨论和媒体报道，谷歌 DeepMind 在招聘流程中出现了与 AI 工具使用相关的规则调整。比较常见的解读是：在面试评估阶段，候选人被要求不要使用 DeepMind 自家 AI 产品辅助完成笔试或代码评测，因为一旦借助模型直接生成答案，面试官就很难判断候选人真实的技术水平。

说得更直白一点：当 AI 能轻松通过算法题和系统设计题的时候，一场“考代码”的面试，考出来的可能不是候选人的能力，而是候选人的“搜索和提问能力”。

需要说明的是，各家公司的招聘规则会随业务阶段和管理风格变化。我们不能把某个内部流程当成行业标准，但这件事背后的技术逻辑值得讨论：为什么 AI 时代里，顶尖 AI 公司反而会在招聘环节限制 AI？这背后涉及能力评估的“信度”问题，也涉及 AI 对工作模式的深层影响。

1.2 为什么这件事值得关注

我身边很多开发者看到这条新闻的第一反应是：“既然是 AI 公司，不应该更拥抱 AI 吗？为什么反而禁止？”

这其实是一种误解。招聘和日常工作不是同一件事。日常工作中，AI 是效率工具，能帮我们完成重复劳动、提供思路、加快编码速度；招聘中，AI 则是潜在的“作弊工具”，会让面试官无法区分“候选人自己能做出来”和“AI 能做出来”。

这两者的边界，正是 AI 时代里每个团队都绕不开的问题。无论你所在的公司有没有明确规则，未来几年你都会面临类似选择：

• 写代码时允许用 AI 吗？
• 候选人用 AI 做了笔试题，算不算违规？
• 如果候选人用 AI 完成工作，团队如何做代码 review？
• 一个“很会把需求描述给 AI”的人，和一个“自己实现核心逻辑”的人，谁更值得招？

DeepMind 的这条规则只是把这个问题摆到了台面上。它提示我们：AI 工具越强大，人才评估机制就越需要重新设计。

1.3 关键词辨析：AI 辅助与 AI 替代

在展开分析前，先区分两个概念。

AI 辅助是指：候选人借助 AI 进行代码补全、语法检查、思路提示、测试用例生成，但候选人本身理解每一步逻辑，能够解释代码、修改代码、定位问题。AI 在这里扮演“助手”角色。

AI 替代则是指：候选人直接把面试题丢给 AI，AI 生成完整答案，候选人甚至没有完整读过代码，更不用说理解边界条件。AI 在这里扮演“作者”角色。

招聘中限制 AI，通常不是反对 AI 辅助，而是希望把“依赖 AI 完成”和“理解自己写的东西”区分开。如果候选人能在 AI 辅助下完成高质量实现，并且能扛住追问、现场改需求、解释设计取舍，这种能力本身就是优秀的工程能力。问题是，很多面试流程并没有设计“追问”环节，导致 AI 替代很难被识别。

2. 一条招聘规则背后的技术思考

2.1 能力评估的“污染”问题

在机器学习里，训练集和测试集必须严格分离，否则模型评估结果会虚高，这叫数据泄露。招聘面试的逻辑其实一样：面试题是“测试集”，候选人的真实能力是“模型”本身，如果 AI 在答题环节参与过多，就相当于把“外部知识”泄露到了测试过程中。

一旦这种泄露出现，面试官得到的反馈就不是“候选人的能力分布”，而是“候选人的 AI 使用水平分布”。这会产生两个后果：

第一，筛选标准失效。本来想招一个逻辑扎实、能独立攻坚的工程师，结果招进来的人擅长“描述需求和拼装答案”，遇到线上问题未必能独立排查。

第二，评估不公平。会写提示词的候选人，在算法题上的表现可能远超真实水平；而不擅长用 AI 的候选人，即使算法功底很好，也可能因为答题速度慢而被误判。这种不公平会直接影响团队人才结构。

所以，限定“避开自家 AI”，本质上是在保护评估数据的纯净性。

2.2 基准测试的“过拟合”现象

做 AI 的开发者对“过拟合”这个词一定不陌生。模型在训练集上表现很好，一到新数据就崩，这就是过拟合。

招聘里的过拟合也有类似表现：候选人在 LeetCode 风格笔试题上表现很好，因为网上有大量原题和 AI 生成的题解；但进入真实业务后，需求模糊、约束复杂、历史包袱重，候选人反而无从下手。

DeepMind 这类公司招聘的岗位大多面向 AI 研究和高级工程岗，考察的重点不是“你能否做出一道动态规划题”，而是“你能否在不确定条件下推进一个复杂问题”。这种能力很难通过 AI 直接获得，必须靠候选人的思路、表达、推导、权衡来呈现。

因此，招聘规则中“避开自家 AI”的深层逻辑，可以理解为：要看清候选人在没有 AI“参考答案”时的思维能力，避免被“过拟合的面试表现”误导。

2.3 参考系漂移：当评估工具变成评估对象

还有一个容易被忽略的角度：如果候选人在面试时使用 DeepMind 自家模型来答题，这个模型的输出质量会直接影响面试官对候选人的判断。这时候，模型反而变成了“隐藏的面试官”。

这就产生了参考系漂移。原本的评估体系是：

候选人能力 → 面试表现 → 评估结果

引入 AI 后变成了：

候选人能力 + AI 输出质量 + 候选人的提问能力 → 面试表现 → 评估结果

AI 输出质量这一变量，候选人控制不了，面试官也控制不了，但它却能显著影响结果。对一家 AI 公司来说，这个问题更尴尬：候选人可能是在测试自家模型的真实水平，而不是展示自己的水平。

这也是为什么有些团队会在面试中明确要求候选人不使用特定 AI 工具，或者要求候选人如实声明 AI 使用情况。目的不是打压 AI，而是让面试官的评估参考系保持稳定。

2.4 对 AI 产品本身的反向影响

更进一步想，如果一个 AI 公司允许候选人在面试中使用自家 AI，这个 AI 就会在面试场景中被反复调用。短时间内大量用户询问同一批面试题，实际上构成了对模型的“定向探测”。

这会带来几个风险：

• 面试题泄漏进模型上下文，后续候选用同一工具可能拿到相似答案。
• 模型会因为大量相似 Prompt 出现输出偏好，影响正常用户的体验。
• 面试题本身可能成为模型的“隐式训练样本”，进一步模糊 AI 与候选人的贡献边界。

所以，“避开自家 AI”也可能包含一种产品层面的考量：保护面试题的独立性，避免自家模型成为招聘流程中不可控的一环。

3. 用 AI 到底会不会影响面试结果

3.1 面试评估的不只是代码

很多候选人对“面试能不能用 AI”这个问题非常关心，但真正需要理解的，是面试官到底在看什么。

一场技术面试，尤其是高级岗位，评估维度通常包括：

• 技术深度：对核心概念、底层原理、边界条件的理解程度。
• 工程判断：面对模糊需求时，如何拆解任务、选择方案、评估风险。
• 协作能力：能否清晰表达思路，能否倾听建议并调整方案。
• 学习能力：遇到陌生问题时，如何快速建立理解框架。
• 代码质量：变量命名、函数拆分、异常处理、可读性。

这里面只有“代码质量”和“技术深度”比较容易被 AI 辅助掩盖，其他维度很难被 AI 替代。哪怕候选人用 AI 生成了完整代码，面试官只要追问几轮，就能看出候选人是否真正理解这段代码。

所以，我的建议是：在技术面试中，与其纠结“能不能用 AI”，不如把 AI 当成一个压力测试工具。候选人用 AI 可以，但必须能解释所有代码、能改需求、能定位 Bug。如果候选人做不到这些，AI 辅助反而会成为减分项。

3.2 AI 辅助在代码题中的实际表现

从经验看，当前主流大模型在常见算法题、设计题上表现已经很不错。以一道中等难度的动态规划题为例，AI 可以直接给出可运行代码和复杂度分析，甚至附带边界测试。

但 AI 在以下几类场景中仍然容易暴露问题：

• 高度定制化的业务逻辑：题目涉及特定领域规则，网上没有直接答案。
• 对代码进行多轮修改：第一版生成后，面试官追加新需求，候选人如果不懂原代码，改起来会非常吃力。
• 工程化约束：内存限制、并发安全、幂等性要求、可观测性设计，AI 容易答得“正确但不可用”。
• 解释与调试：一个隐藏 Bug 可能藏得很深，候选人需要具备系统排查能力。

因此，在面试中考察候选人是否真正理解代码，最有效的方式不是禁止 AI，而是设计“AI 很难直接作弊”的题：现场逐步增加需求、让候选人讲清楚每一步选择、要求候选人构造测试用例验证自己的方案。

3.3 如何区分“会写代码”和“会实现需求”

我比较欣赏一个观点：区分一个候选人的能力，不是看他是“从零写出代码”，还是“借助 AI 生成代码”，而是看他面对一个需求时，能否完成从“问题定义”到“方案落地”的闭环。

具体来说，会实现需求的工程师通常具备这些特点：

• 能提出关键问题：需求中哪些条件没说明？性能要求是多少？失败场景怎么处理？
• 能快速原型验证：先用最直接的方式跑通流程，再逐步优化。
• 能识别 AI 回答中的错误：模型生成代码有幻觉，候选人能否一眼看出问题。
• 能对方案做取舍：AI 给了一个很复杂的方案，候选人能否判断“不需要这么复杂”。

如果候选人只是把 AI 的答案复制粘贴，这些能力就都无法显现。所以，在面试中设计追问环节、压力环节、改造环节，比单纯限制 AI 更公平。

4. 设计一套“反 AI 辅助”的面试评估方案（实操）

这一节给出一个可落地的面试评估方案。它的目标不是“惩罚使用 AI 的候选人”，而是让面试官获得更真实的评估信号。你可以根据团队规模、岗位级别和技术栈灵活调整。

4.1 评估目标拆解

在设计流程前，先明确你想评估什么能力。这里用三层模型：

这套方案把“AI 影响最大”的代码实现放在工程层，但通过多轮改造和追问，确保候选人必须真正理解代码。

4.2 限定环境与工具链

如果团队希望减少 AI 对笔试环节的干扰，可以在笔试阶段做环境限定：

• 使用在线笔试平台，开启“禁止切屏”或“浏览器监控”。
• 要求关闭浏览器翻译插件和 AI 插件。
• 不允许候选人使用本地大模型客户端。
• 在题目层面设计“无法直接靠搜索引擎获取答案”的定制描述。

示例笔试环境说明（可复制到招聘邮件中）：

【笔试环境要求】 1. 请使用指定在线 IDE 完成题目，不要使用本地编辑器。 2. 考试期间请关闭所有 AI 编程助手、AI 聊天工具和翻译插件。 3. 不要打开无关网页或搜索引擎。 4. 如果出现网络异常，请立即联系面试协调员。 5. 最终提交代码时，请附上思路说明和自测用例。

需要留意的是，这类规则本质上依赖候选人自觉，技术上很难完全杜绝。所以环境限定只作为辅助手段，核心还是面试环节的多轮追问。

4.3 追问型场景设计

追问是区分“AI 辅助”和“真实能力”最有效的手段。下面是我推荐的一种流程。

第一步：给出开放式问题。不要直接问“实现一个 LRU Cache”，而是给一个带有模糊场景的问题。

示例题目描述：

我们需要为内部系统设计一个短链接服务。主要用户是运营人员，预期支持每天 100 万次访问、每月 1 万条新链接生成。不需要做用户体系。 请先梳理需求，再给出核心数据结构设计和接口定义，最后实现一个简化版本。

第二步：第一轮追问。候选人给出方案后，追加以下问题：

• “短链接的字符集怎么确定？预计可用多少年？”
• “如果同一个原始链接被生成两次，应该返回同一个短链接还是两个？”
• “短链接过期怎么办？谁来清理？清理策略是什么？”
• “访问量上来后，单机数据库扛得住吗？你会怎么扩展？”
• “如果有人恶意生成大量短链接，系统会出什么问题？”

这些追问没有标准答案，但能很快判断候选人是真的思考过，还是只搬运了 AI 的通用设计。

第三步：代码改造。让候选人在已有代码基础上完成一个新增需求：

在上一个问题的基础上，请增加一个功能： 短链接点击时，如果检测到用户 IP 来自异常来源，则返回一个风险页而不是直接跳转。 要求说明你的检测规则和实现方案。

这种改造任务，核心考察候选人能否快速阅读已有代码、准确定位改动点、合理处理原有逻辑，AI 可以帮你生成“新增代码”，但很难帮你理解原有设计。

4.4 候选人的自我声明与规范约束

对于远程面试或“允许使用 AI”的流程，建议在开头做一个简单的声明。这既是规则约束，也是保护候选人。

声明示例：

面试过程中允许使用 AI 辅助，但请注意： 1. 你必须完全理解最终提交的代码，并能解释每一处实现。 2. 面试官可能要求你修改代码、补充测试或解释设计，AI 给出答案后，你需要独立完成验证和调试。 3. 如果直接使用 AI 生成完整答案并提交，可能会被认为不符合本次评估的期望。 4. 如不确定是否可以使用某种工具，请先询问面试官。

这段话看起来很客气，实际上把责任交给了候选人。它能过滤掉一部分试图完全依赖 AI 的候选人，同时不会误伤正常使用 AI 提效的开发者。

4.5 一道题的完整多轮追问示例

下面用一道简单题展示完整流程。

题目：

// 给定一个整数数组 nums 和一个目标值 target， // 返回两个数的下标，使得两数之和等于 target。 // 可以假设只有一组答案，且同一个元素不能使用两次。 public int[] twoSum(int[] nums, int target) { Map<Integer, Integer> map = new HashMap<>(); for (int i = 0; i < nums.length; i++) { int complement = target - nums[i]; if (map.containsKey(complement)) { return new int[]{map.get(complement), i}; } map.put(nums[i], i); } return new int[]{}; }

第一轮追问：

• “这个方法时间复杂度是多少？空间复杂度呢？”
• “如果 nums 中有重复元素，这个实现会有问题吗？”
• “如果数组已经排序，你能写出一个 O(1) 空间复杂度的解法吗？”

第二轮改造：

如果允许同一个元素使用多次，并且要求返回所有满足条件的组合，不允许重复组合，你怎么改？

这轮改造已经偏离“原题模型”，候选人如果只是背过答案，很难快速给出正确解法。

第三轮工程化：

这个方法是被一个高并发接口调用的，nums 有 100 万个元素，target 不断变化， 你如何设计这个接口？需要考虑缓存和内存限制。

到这里，一面代码题已经变成了系统设计讨论。AI 可以生成两数之和的解法，但很难代替候选人完成“接口设计 + 缓存策略 + 复杂度权衡”的完整表达。

5. 用 AI 能力反哺招聘：自动化筛选与风险控制

5.1 AI 辅助面试评估的边界

招聘流程并不是要完全排斥 AI。实际操作中，AI 可以在三个环节提升效率：

• 简历初筛：提取候选人的技术栈、项目经验、年限、亮点，减少 HR 重复劳动。
• 题目出题：自动生成不同难度的题目和测试用例。
• 面试记录整理：把面试中的关键问答整理成结构化记录，方便复盘。

但 AI 不应该用于“自动判定候选人是否通过”，尤其是涉及代码能力的判断。原因有两个：第一，AI 当前对推理质量的评估还不够稳定；第二，面试中有很多非语言信号，AI 无法全面覆盖。更稳妥的做法是：AI 负责收集和整理信息，人类面试官负责判断。

5.2 一个 AI 风险评估脚本示例（Python）

下面给出一个 Python 示例，演示如何对候选人提交的文本做简单的“AI 辅助痕迹”风险提示。注意，这个脚本不能作为判定证据，只用于辅助面试官关注高风险候选人。

# 文件路径：code_review/ai_risk_checker.py import re def get_code_blocks(content): """提取代码块内容，用于后续分析""" pattern = re.compile(r"```[\s\S]*?```", re.MULTILINE) return pattern.findall(content) def check_ai_style_indicators(content): """ 简单检查代码中是否存在常见 AI 生成风格标记。 注意：这只是启发式检测，不能作为证据。 """ # 常见 AI 生成的注释风格 indicators = { "过于完整的注释": ["// 使用方法", "# 参数说明", "/* 复杂度分析 */"], "典型套话": ["以下是一个示例", "请注意", "可以看出", "综上所述"], "明显模板代码": ["public static void main", "class Solution"], } detected = [] for name, patterns in indicators.items(): for p in patterns: if p in content: detected.append({"类型": name, "命中内容": p}) return detected def estimate_ai_usage_risk(content: str) -> float: """ 根据几个简单信号估算风险分数。 - 代码注释比例过高 - 存在大量模板化说明 - 代码风格统一但缺少个人特征 返回值 0.0 ~ 1.0 """ if not content: return 0.0 score = 0.0 # 信号1：代码注释占比 comment_lines = len(re.findall(r"^\s*(#|//|/\*|\*)", content, re.MULTILINE)) total_lines = len(content.splitlines()) if total_lines > 0 and comment_lines / total_lines > 0.4: score += 0.3 # 信号2：模板套话 templates = ["以下是一个示例", "请注意", "综上所述", "首先", "然后", "最后"] hits = sum(1 for t in templates if t in content) if hits >= 3: score += 0.3 # 信号3：代码块极规整，缺少行内注释 if "```" in content and "//" not in content.split("```")[0]: score += 0.1 return min(score, 1.0) if __name__ == "__main__": sample_content = """ 以下是一个解决方案： // 参数说明：nums 为输入数组 // 使用方法：调用 twoSum 方法 public int[] twoSum(int[] nums, int target) { // 首先初始化哈希表 Map<Integer, Integer> map = new HashMap<>(); // 然后遍历数组 for (int i = 0; i < nums.length; i++) { int complement = target - nums[i]; // 如果存在则返回结果 if (map.containsKey(complement)) { return new int[]{map.get(complement), i}; } map.put(nums[i], i); } return new int[]{}; } """ risk_score = estimate_ai_usage_risk(sample_content) print(f"AI 使用风险系数：{risk_score:.2f}") for item in check_ai_style_indicators(sample_content): print(item)

这个脚本思路很简单：检测注释比例、模板化表达、代码风格单一度。实际生产环境可以采集更多指标，比如：

• 代码提交时间是否异常集中在最后几分钟。
• 候选人能否在上传代码后立即解释每一段代码。
• 候选人在录音中对代码细节的熟悉程度。

需要严肃提醒：任何 AI 检测工具都不能作为拒绝候选人的唯一依据。误判成本很高，必须在检测结果基础上进行人工面试验证。

5.3 代码查重与 AI 生成检测思路

如果你是全职负责招聘的工程师，可以考虑建设一个初筛系统，流程如下：

候选人提交代码 -> 静态分析：语法检查、复杂度评估 -> 代码查重：与题库历史提交记录对比 -> AI 生成风格检测：注释占比、模板结构、命名一致性 -> 输出风险报告 -> 人工面试验证

这里的关键是“人工面试验证”。代码查重和 AI 检测都只能缩小范围，不能直接定罪。毕竟候选人可能参考过网上题解，也可能用了 AI 补全，这些行为本身未必影响最终工作表现。面试官应当在现场判断候选人是否理解代码，而不是仅凭静态结果下结论。

6. 对开发者的求职启示

6.1 AI 时代的技术能力表达

很多开发者担心“以后面试是不是都要手写代码，不能用 AI 了”。我觉得这个担心有点过度。

真正重要的不是“面试中能不能用 AI”，而是你能否在面试中表达出三件事：

• 我能独立解决未知问题。
• 我能理解现有系统的运行逻辑。
• 我能与团队协作推进复杂工程。

如果你的能力建立在对 AI 输出的依赖上，一旦离开工具，你可能会陷入“无 AI 无法编程”的状态。这不是职业道德问题，而是职业风险问题。AI 可以帮你写代码，但很难帮你建立对系统的整体认知。

因此，日常开发中建议这样使用 AI：

• 先用 AI 生成初版代码，然后自己重写一遍，理解每一行的作用。
• 让 AI 提出方案，但你要对方案做技术选型，并说明理由。
• 让 AI 生成测试用例，同时自己补充边界条件和异常场景。
• 遇到 Bug，先尝试自己定位，再向 AI 求助。

这样既保留了 AI 的效率优势，又不会丧失独立解决问题的能力。

6.2 面试前如何利用 AI 但不依赖 AI

如果你正在准备面试，建议把 AI 当成“陪练”，而不是“抢答器”。

推荐练习流程：

1. 找一道题目，先不用 AI，自己尝试 30 分钟。
2. 30 分钟后如果没思路，让 AI 给出“提示方向”，不要让它直接给完整代码。
3. 在提示基础上，自己写代码并跑通。
4. 再用 AI 生成参考答案，对比你的实现，找出可以优化的点。
5. 最后，把题目讲给一个虚拟听众，用自己的语言解释思路。

这套流程的核心是：AI 负责扩展思路，你负责建立自己的能力闭环。面试时如果遇到类似题，你会发现自己比单纯背题的人更有底气。

6.3 沉淀自己的“提问-验证-复盘”闭环

AI 时代，最值钱的技能之一是“提出好问题的能力”。这个能力不是天然有的，需要刻意训练。

我建议开发者建立一套个人实践闭环：

这套闭环能让你在使用 AI 的同时，不断提升自己的独立判断力。长期来看，它比“背一百道题”更能帮助你在面试和真实工作中脱颖而出。

7. 对团队管理者的招聘建议

7.1 不要只看“题目结果”

如果你负责团队招聘，我强烈建议你重新审视目前的面试评估方式。如果你发现团队里“笔试成绩很好的人，转正后表现平平”，那很可能是评估流程被 AI 或题海战术“污染”了。

调整思路如下：

• 降低“算法原题”的评分权重，提高“现场解决问题”的权重。
• 增加“模糊需求题”，题目不要给得太完整，让候选人主动提问。
• 增加“代码 review 环节”，让候选人 review 一段有问题的代码，而不是从零写代码。
• 增加“结对编程”环节，面试官和候选人一起改一个真实模块。

这些环节对 AI 的依赖度低，更能反映候选人的真实工程认知。

7.2 用行为面试考察工程思维

行为面试是抗 AI 干扰的最有效手段。你可以问候选人以下问题：

• “请讲一个你在生产环境中定位困难 Bug 的完整案例。”
• “你在过去的项目里，做过哪些技术上比较冒险的决定？”
• “如果你发现同事提交的代码存在严重性能问题，你会怎么处理？”
• “描述一次需求不明确但你成功交付的经验。”
• “你有没有用过 AI 编程助手？你如何保证它生成的代码是可靠的？”

这些问题没有标准答案，AI 也帮不了候选人太多，因为候选人必须基于真实经历回答。后续可以追问细节来验证真伪。

7.3 建立评测基线并持续校准

任何评估方案都需要反馈循环。建议记录以下数据：

• 候选人笔试成绩与试用期表现的相关性。
• 候选人面试中被追问时的应变表现与入职后绩效的相关性。
• 团队对 AI 使用规则认同度的季度调研。
• 面试通过率、拒绝原因分布。

通过持续校准，你才能找到真正适合团队的评估指标。不要迷信任何单一工具或流程，招聘本身就是一个构建在“对人和技术的判断”上的系统工程。

常见的做法是：每个季度回顾一次面试题库，把已经被大量 AI 解出、网上流传过久、候选人普遍能答出的题目标记为“风险题”，逐步替换为定制化题目。

8. 常见问题与避坑

还有一个常见误区：团队担心“限制 AI 会让候选人体验变差”。实际上，候选人更反感的是规则不透明。如果你允许使用 AI，请明确说明；如果你不允许，也请提前告知，而不是等答题完成后再判定违规。清晰的规则能减少纠纷，也能让候选人更安心地展示自己。

9. 最佳实践：AI 时代的研发人才评估体系

9.1 能力维度分层

在 AI 时代，研发人才评估建议分层进行：

第一层，硬技能。包括语言基础、算法数据结构、系统设计、数据库、网络。这部分 AI 可以辅助学习，但候选人必须能独立输出和解释。

第二层，工程能力。包括代码质量、性能意识、安全思维、测试习惯、调试能力、Review 能力。这部分很难靠 AI 生成，需要项目经验积累。

第三层，认知能力。包括问题定义、需求拆解、方案权衡、风险意识、跨团队沟通。这部分是 AI 最难替代的，也是高级岗位筛选的关键。

招聘时，不同层级应该使用不同的评估方法。硬技能可以用笔试或现场编程考察；工程能力用代码 Review 和结对编程考察；认知能力用案例复盘和行为面试考察。

9.2 面试流程设计

一个抗 AI 干扰的面试流程可以参考以下结构：

1. 简历筛选（AI 辅助初筛） 2. 笔试（限定环境，题目含定制场景） 3. 技术一面（简答题 + 现场编码 + 追问） 4. 技术二面（代码 Review + 系统设计） 5. 行为面（项目复盘 + 价值观匹配） 6. 定薪定级会议（综合多轮反馈）

关键点是：笔试只作为初步过滤，不要用它一锤定音。真正的评估应该落在面试官与候选人的多轮交流中。

9.3 数据记录与复盘指标

推荐记录以下面试数据：

• 候选人对追问的应答时长和质量。
• 候选人在代码改造任务中的表现。
• 候选人主动询问的需求澄清数量。
• 候选人对自己代码的熟悉程度评分。
• 面试官的主观置信度。

这些数据可以帮助团队分析“哪些环节最容易受到 AI 影响”，从而持续优化面试题。

9.4 工程文化与安全边界

最后还是要强调：招聘中最怕的不是“候选人用 AI”，而是团队没有统一标准。建议在招聘制度中明确以下内容：

• 公司对 AI 工具使用的总体态度，鼓励还是限制，在哪些场景下限制。
• 笔试、面试、试用期三个阶段分别适用什么规则。
• 候选人使用 AI 后是否需要主动声明。
• 发现违规行为后的处理流程。

这样的制度既保护团队利益，也让候选人知道自己被公平对待。

10. 总结与学习路线

10.1 核心结论

回到最初的新闻：谷歌 DeepMind 招聘中要求候选人“避开自家 AI”，表面上看是对 AI 的限制，实质上是对人才评估方法的修正。AI 再强，也不能替代“候选人是否理解自己在做什么”这个核心问题。

这件事给我们的启发有三点：

第一，对开发者来说，AI 是工具，不是能力本身。独立解决问题的能力、系统思维、工程判断力，仍然是你最核心的竞争力。

第二，对招聘者来说，评估方式必须升级。不要只靠一套笔试走天下，要给候选人更多表达真实能力的机会。

第三，对技术管理者来说，AI 使用规则要透明、可执行。与其做一个“反 AI”的姿态，不如设计一个“能看清人真实能力”的评估体系。

10.2 开发者可以继续深入学习什么

如果你希望进一步提升自己在 AI 时代的竞争力，可以从这几个方向发力：

• 系统设计：学习高并发、缓存、消息队列、分布式事务、可观测性设计。
• 代码质量：掌握重构、设计模式、单元测试、代码审查方法。
• AI 工程化：学习大模型应用开发、提示词工程、Agent 框架、模型部署。
• 工程方法论：阅读《人月神话》《代码大全》《重构》等经典，重点理解“为什么”。

实践路径建议：维护一个自己的开源项目，记录完整的项目设计文档和踩坑笔记。这样做既能锻炼工程能力，也能沉淀个人品牌。

10.3 最后几句话

以后面试中遇到“能不能用 AI”这样的问题，不用紧张，更不要急着隐瞒。坦诚说明你的使用习惯，并用实力证明你理解最终结果。真正优秀的团队不会因为“你用了 AI”而拒绝你，他们只会拒绝“被 AI 替代的你”。

技术变化很快，但底层能力不会贬值。把 AI 当作学习伙伴，持续打磨自己的思考能力，你会在技术这条路上走得更稳。