企业官网建设流程全解析

最近有一个关于谷歌 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 的使用边界应该随着考察目标而变化。比如：

从这张表可以看出来，DeepMind 的“避开自家 AI”并不是铁板一块，它大概率是针对某个特定环节的设计，而不是全流程禁止。但它的信号意义在于：AI 时代，招聘评估必须分场景设计，不能再简单出一道算法题就判断候选人的全部能力。

3. 技术面试为什么需要“屏蔽 AI”：从认知科学和测量学角度分析

如果只停留在“面试不让用 AI”的表面，就很难理解这件事的深层价值。技术面试中“屏蔽 AI”背后的逻辑，和考试中“闭卷 vs 开卷”的争论很像，但它比开闭卷问题更复杂。

3.1 面试题考察的是“问题解决的结构”，而不是“答案”

一道好的技术面试题，答案本身并不重要，重要的是候选人展示出来的思考路径。比如候选人拿到一道“设计一个短链接服务”的系统设计题，他需要做的是：

• 明确需求：读多写多？单机还是分布式？需不需要统计点击？
• 分析约束：数据量级、延迟要求、可用性要求。
• 生成方案：哈希算法、发号器、缓存策略、数据库选型。
• 推演权衡：为什么用 Redis 而不是 MySQL？为什么用发号器而不是随机字符串？

如果候选人直接让 AI 生成一个完整的系统设计，他确实能得到一份结构合理的答案。但面试官想要观察的“权衡过程”和“取舍逻辑”就全部消失了。面试官看到的只是最终产物，而技术面试的核心价值恰恰在于观察过程。这就是为什么在考察核心能力时，需要屏蔽 AI——它并不只是防止作弊，更是保护面试官获取有效信息的能力。

3.2 “依赖 AI”和“使用 AI”的区别

这里要做一个重要区分。业内人士讨论的“使用 AI 编程”，通常包含两种截然不同的方式：

1. 完全依赖式：直接把需求交给 AI，让 AI 生成完整代码，人只做搬运。
2. 协作增强式：人主导设计和拆解，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 生成代码跑不通时的排错路径。

这个阶段评分可以参考下面的维度：

从材料看，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 触碰核心风险区域。权限认证和支付交易这类代码，一旦出现逻辑漏洞，损失远大于效率提升。在关键路径上，人必须保持对代码的完全控制权。

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/checkout@v4 - name: Check high-risk module changes run: | HIGH_RISK_PATHS="src/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_DIRS="payment/ 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 生成代码的能力越强，工程质量管控就越重要。团队如果只看到效率提升，没有同步升级质量管控手段，那效率提升的代价往往就是线上事故。

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 时的独立解决问题能力。无论未来面试形式怎么变，这两点都是不变的底层能力。