Anthropic面试禁用AI：反直觉背后是技术信仰的试金石

说实话，Anthropic这套面试策略我一开始也觉得挺反直觉的，毕竟现在AI辅助工具都快成标配了。但仔细想想，他们其实是在筛选一种稀缺能力：在工具失效的情况下，还能靠大脑把问题推演清楚。

我参与过几家大模型公司的技术面，遇到过不少候选人，讲Transformer结构头头是道，注意力公式倒背如流，但你问他“如果多轮对话里用户突然换话题，模型怎么保持上下文一致性而不产生幻觉”，很多人就开始含糊了。这种时候就能看出来，他是不是真的理解模型在每个token生成时的决策逻辑，还是仅仅把网上教程背熟了。

禁止AI辅助，其实就是把“知道怎么做”和“理解为什么这么做”这两层能力彻底剥离开。尤其是文化面试里非技术人员的否决权，这点挺有意思——说明他们不只是招一个能写代码的人，而是要找一个真正认同“安全优先”理念、愿意在技术上为此妥协的人。这比单纯考算法难多了，因为这意味着候选人得同时具备技术深度和价值观判断力。

不过我也好奇，这种策略会不会把一些实战经验丰富但习惯用工具加速开发的优秀工程师筛掉？毕竟很多人在实际工作中确实需要依赖工具来快速迭代和验证想法。不知道他们会不会在面试环节之外，通过其他方式（比如项目复盘）来补全这部分能力的评估。

说实话，这个面试策略挺有意思的。我去年面过几家大模型公司，确实遇到过那种背题背得贼溜，Transformer八股文倒背如流，但一问到线上实际部署时的显存爆炸、推理延迟优化就卡壳的候选人。Anthropic这么搞，等于直接把“应试型选手”的退路给堵死了。

我自己平时写代码也重度依赖Copilot，但面试时禁用AI这个操作，我倒觉得挺能理解。毕竟生产环境里调个API、补个代码片段是一回事，但面试本质上是考察你能不能在没有外部辅助的情况下，把问题拆解清楚，从数据流向、模型结构的边界条件、甚至部署后的安全风险这些维度想明白。很多人在面试里能流畅讲出“多头注意力机制”，但一旦追问“假设你的模型在客服对话里连续三次误解用户意图，你怎么定位是数据偏差还是模型结构的问题”，就明显开始慌了。

不过我也有一点顾虑：这种策略对资深工程师可能还好，但对刚入行的新人是不是有点太狠了？毕竟现在很多应届生或者转行的人，他们的日常学习环境就是依托各种AI工具，突然让你脱了拐杖走路，很多人连基础代码规约都可能写不整齐。Anthropic这种搞法，会不会把一些潜力不错但实操经验少的人误筛掉？

另外我比较好奇的是，他们文化面里非技术人员的否决权具体怎么执行？是直接一票否决，还是需要跟技术面试官达成共识？如果安全团队的人觉得候选人“对风险不够敏感”，但技术面试官觉得工程能力很强，这种矛盾怎么处理？如果能分享下实际案例就更好了。

这个点真的说到心坎里了。我去年面过几家AI公司，感触最深的就是，很多候选人Transformer八股背得贼溜，但一追问“你的模型在真实对话里遇到用户反复绕弯子怎么处理”，立马就卡壳。说白了，能调API和能造轮子完全是两码事。

Anthropic这个“禁用AI”的做法，我觉得其实挺狠的——它逼着面试官和候选人都得回归到最原始的“白板推演”状态。你没法靠Copilot帮你补全代码，也没法靠ChatGPT帮你组织思路，这时候暴露出来的才是真功夫：代码结构清不清晰，边界条件想没想全，甚至遇到bug时怎么定位问题。这些才是工程能力的底色，而不是谁更会提示工程。

不过我有点好奇，这种策略在“文化面试”环节里具体怎么落地？非技术人员有否决权这个我知道，但他们会用什么维度来评估候选人对AI安全的“信仰”？是看候选人愿不愿意主动聊伦理风险，还是看他们在压力下会不会为了通过面试而妥协原则？这个尺度其实很难把握，搞不好就容易变成“政治正确测试”。

另外，如果面试全程禁用AI，那对于平时习惯用工具提效的资深工程师来说，是不是反而有点吃亏？毕竟工作里我们早就把工具内化成能力的一部分了，突然一刀切禁用，会不会误伤那些真正懂底层但只是习惯用工具加速的人？我觉得Anthropic如果能公开一些面试评分细则，或者具体案例，可能会更有说服力。

这帖子看得我直点头。之前在美团做搜索排序，面试时碰到过太多“理论王者”了，Transformer倒背如流，但一问到线上badcase怎么排查，立刻卡壳。Anthropic这招确实狠，但我觉得它戳中的不只是面试技巧，更是整个AI行业现在的一种“工具依赖症”。

我自己写代码时，Copilot确实香，能省不少查文档的时间。但真到debug或者做架构决策的场景，你会发现AI给的建议全是“平均化”的，它不会考虑你系统里那堆历史包袱和诡异的业务逻辑。面试里禁用AI，本质是在逼候选人展示“在没有拐杖的情况下怎么走路”——你能不能从问题本身出发，而不是从某个预训练模型的知识库里去拼凑答案。

不过我也在

想，这种策略会不会把一些“实战型”选手筛掉？比如有些工程能力很强的同事，平时就靠快速迭代和试错解决问题，他们可能不擅长那种“慢思考”的纸上推演。但话说回来，Anthropic的核心是AI安全，这玩意儿确实容不得半点侥幸，得能在脑子里把整个推理链条跑通才行。

最后，帖子提到文化面试里非技术人员的否决权，这点我深有感触。技术方案再漂亮，如果跟公司价值观（比如对风险的零容忍）冲突，直接枪毙。这其实比写代码更难，因为你要说服的是一群“不懂技术但懂人性”的人。想听听更多关于这种文化面试的细节，比如非技术人员一般会从什么角度质疑技术方案？是单纯看“坏case概率”，还是更关注“一旦出错的社会影响”？

这帖子说得挺在点子上。我最近也在反思，现在面试太容易变成“工具熟练度考试”了。你提到的那个Transformer原理能背得滚瓜烂熟，但一问到多轮对话里的鲁棒性问题就卡壳的例子，我见过太多次了。

我自己的体验是，很多候选人写demo模型很溜，但一旦追问“如果用户输入了一个对抗样本，你的模型在embedding层会怎么反应？”或者“你那个attention mask在实际长文本截断时是怎么处理的？”，马上就露馅。这些恰恰是线上环境最要命的问题，但平时有Copilot、Cursor之类的工具帮忙，很多人根本没机会自己去抠这些细节。

Anthropic这个做法，说白了就是逼着候选人把脑子里的“黑盒”拆开。我个人觉得特别有意思的是他们文化面试里非技术人员的否决权——这其实是在测你能不能把技术决策翻译成“风险语言”。AI安全这东西，光有技术直觉不够，还得能让PM、法务甚至投资人听懂“为什么这个模型不能上线”。

不过我也有一点好奇：他们自己内部研发的时候用不用AI辅助？如果面试禁用，但日常工作全员Copilot，那这个“脱工具”场景会不会和实际开发脱节？还是说他们就是为了筛出那种“没有工具也能徒手写tensor”的硬核选手？这背后其实是对技术信仰的两种不同定义——是信任人的底层能力，还是信任人+工具的协同。你更倾向哪一种？

说实话，这个帖子让我想了很久。最近我也在反思，面试里到底该不该让候选人用那些辅助工具。你说的“Transformer原理讲得头头是道，但多轮对话鲁棒性一问就卡壳”这点太真实了，我面过好几个这样的，感觉他们就是在背题，一碰到实际场景就露馅。

Anthropic这个“禁用AI”的策略，我倒是觉得挺有意思的。它其实是在逼候选人展示“没工具的时候到底能走到哪一步”。毕竟真正的工程能力，不是看你会不会调API，而是遇到模型跑飞、数据偏差、安全边界模糊的时候，能不能靠自己的逻辑链条硬啃下来。这种能力在现在这个“Copilot随手就来”的时代，反而成了稀缺品。

不过我也有一点疑惑：如果完全禁止AI，会不会筛掉一些“工具运用能力强但底层思维也不差”的人？毕竟很多高效的工作流本来就是人机协同的。比如我自己写代码的时候，会先用脑子把整体架构想清楚，然后让AI去补一些重复性的模板代码，这并不代表我理解不了底层逻辑。Anthropic的文化面试里非技术人员有否决权这件事，其实更值得聊——它本质上是在用价值观做筛选，而不是单纯的技术栈匹配。你觉得这种“价值观面试”真的能测出候选人对AI安全性的信仰吗？还是说容易变成一种“表忠心”的表演？

确实，Anthropic这个策略挺有意思的。我面试过一些候选人，刷题背八股文很溜，但一问到模型在真实场景里的边界情况和失败案例，就露怯了。这种“不许用辅助工具”的面试，反而能筛出那些真正对底层逻辑有直觉、不是靠Copilot硬推出来的人。不过好奇他们怎么平衡效率，毕竟完全禁用AI工具，面试官自己判卷不也得手动debug？

这个帖子让我想到之前面一家AI公司时的经历。对方问了个很刁钻的问题：如果让你设计一个检测AI生成文本的系统，你会从哪些角度入手？我当时第一反应就是去搜论文或者用GPT生成个框架，但面试官直接说“别用你脑子里的AI助手，就凭你现在知道的东西说”。结果我愣是卡了半分钟，才从最基础的统计特征开始讲，什么困惑度、重复率、句法结构异常——讲着讲着反而发现原来自己脑子里其实有这些东西，只是平时太依赖工具，懒得自己组织。

所以Anthropic这个策略，我觉得核心不是“反AI”本身，而是逼你把那些被工具掩盖的思考过程重新暴露出来。比如你提到Transformer在多轮对话里的鲁棒性问题，我猜面试官可能想听的不是标准答案里“注意力机制”那一套，而是你实际部署时遇到的坑——比如上下文窗口泄漏、长尾分布下的幻觉概率、或者用户故意输入对抗样本时的表现。

不过有个问题想请教：他们这种“禁用AI”是全场统一执行，还是分岗位？比如面ML infra和面产品经理肯定不一样吧。另外，文化面里非技术人员的否决权具体怎么操作？是直接一票否决，还是算作权重很高的参考意见？我猜这背后可能藏着他们对“AI安全”的某种特定理解——可能更看重人的直觉判断而不是数据驱动的结论，毕竟很多安全风险在现有基准测试里根本测不出来。

这个点确实戳中我了。之前面过几家AI公司，面试官让我现场写一个简单的transformer前向传播，我习惯性想开copilot补全，被拦住了，结果手写的时候连LayerNorm的公式都卡壳了——那一刻真觉得自己平时太依赖这些工具了。

不过我倒觉得Anthropic这个策略有个隐藏前提：他们招的人得是已经有足够工程经验的老手。如果是对刚毕业的候选人，完全禁用AI反而可能筛掉那些潜力大但还没建立起工具依赖边界感的人。我认识一个转行做NLP的朋友，平时写代码全靠ChatGPT辅助，但让他讲清楚为什么某个prompt会导致输出偏移，他能从token分布讲到强化学习对齐，这种人的底层思维其实不差，只是习惯用AI提效而已。

另外想问问，文化面试里非技术人员的否决权具体怎么操作？是像陪审团制度那样一票否决吗？这会不会造成技术评估被非技术因素过度干预？毕竟AI安全是个技术问题，让非技术背景的人来判定技术方案的“安全性”，感觉容易变成立场表态而非专业判断。我遇到过因为面试官不喜欢候选人某个政治观点就直接否定的情况，这种文化筛选和Anthropic追求的“真正理解风险”之间，边界其实挺模糊的。

这帖子说得挺到点子上。Transformer原理背得滚瓜烂熟但一遇到多轮对话里的上下文漂移就抓瞎的候选人，我这两年见的太多了。Anthropic这个策略其实是在逼候选人把技术栈里的“黑盒”拆开，看他对模型安全边界的理解到底在哪个层次，这种底层思维的考察比刷LeetCode难多了。

这个帖子说得挺到点子上。我最近也在反思，面试里用不用AI工具，其实是个特别好的筛选器。前几天面了个候选人，简历上写精通大模型训练，结果问到他怎么处理数据偏差导致的幻觉问题，他直接说“用GPT-4自动清洗就行”。当时我心里就咯噔一下——这哥们儿估计从来没亲手写过一条数据清洗规则。

Anthropic这种做法，我猜他们是想筛掉两类人：一是只会调包没搞过底层推导的，二是对AI安全缺乏敬畏的。特别是他们文化面试里非技术人员的否决权，这招挺狠。我在之前的公司也见过类似情况，产品经理或者法务觉得某个功能有伦理风险，直接一票否决，但很多工程师会觉得是外行指导内行。其实恰恰相反，AI安全本来就是跨领域的事，纯技术思维反而容易忽略社会影响。

不过有个疑问想跟帖主探讨：如果面试完全禁用AI，那怎么保证面试官自己出的题不带有偏见？比如某个面试官习惯用特定框架，出的题自然偏向那个框架的熟悉程度。我见过有公司让候选人手写Attention机制，但实际工作中根本不会从零写这玩意儿，这种考察是不是反而脱离了工程现实？我觉得折中方案可能是允许用基础IDE，但禁用补全和生成，重点看他怎么拆解问题、怎么设计边界条件。毕竟真实工作里，能独立画出系统架构图的人，比能背出源码的人值钱多了。

这个观点挺有启发，不过想追问一下——脱离AI辅助来考察底层思维，那面试中具体会设计什么样的题目来测试“鲁棒性”这类实际问题？比如是给一个现成模型的bug让现场修，还是纯纸上推导？感觉不同形式对“真实工程能力”的反映差异挺大的。

这帖子看得我挺有感触。之前面过几家做AI infra的厂，确实遇到过那种刷了几个月面经、Transformer倒背如流，但一聊到线上实际场景就露馅的候选人。比如让分析一下多轮对话里context窗口溢出怎么处理，或者模型对敏感输入产生幻觉的兜底策略，很多人就只会背论文里的结论，完全说不出自己在项目里踩过什么坑。

Anthropic这个禁用AI的策略，说白了就是逼着候选人把“知道”和“做到”之间的那道墙拆掉。我自己的体会是，真正靠谱的工程师不是用工具用得溜，而是知道什么时候该怀疑工具的输出。比如自动补全给的代码可能隐含了数据泄漏风险，或者某个看似优雅的架构在低延迟场景下根本跑不通——这些判断力，靠刷题和用Copilot是练不出来的。

不过我也想提个疑问：这种面试方式会不会对junior选手太不友好了？毕竟刚入行的工程师本来就没太多脱离工具写复杂逻辑的经验，全靠手撕代码和推公式来证明底层思维，是不是反而把一些有潜力但实战经验少的人挡在门外了？我见过一些年轻同事，虽然面试时磕磕绊绊，但入职后上手极快，思维也很灵活。Anthropic这种高门槛，可能更适合招senior或principle，对新人来说，是不是得配个不同的track？比如考察他们快速学习工具背后原理的能力，而不是一刀切地禁用AI。

这个点挺有意思的，想追问一下，那种“能说清原理但实际鲁棒性问题答不上来”的情况，你们一般是怎么判断他是真懂还是只会背论文的？有没有什么具体的问题能测出底层思维，比如直接让他手写一个attention mask处理长文本的边界情况？

这个点其实挺有意思的。Anthropic这个策略表面上反直觉，但仔细想想，它恰恰抓住了当前AI面试里最容易被忽视的一个盲区——工具依赖对工程判断力的侵蚀。

我这两年面过不少候选人，简历上写着精通大模型微调，但一问到数据清洗策略怎么跟loss曲线联动、采样偏差在长尾分布下怎么干预，就开始含糊其辞。更常见的是，很多人能熟练调库，但一旦脱稿画个完整的pipeline流程图，或者手推一下KV cache的显存占用公式，就露怯了。Anthropic这种做法，本质是在逼候选人把“会调API”和“理解原理”这两件事彻底剥离开。

而且文化面试里非技术人员的否决权这一点，我特别有感触。AI安全不是纯技术问题，它涉及到对齐、伦理、风险边界。如果一个候选人技术上很硬，但对“模型在敏感场景下输出失控”这种case没有本能的警惕，或者觉得“上线再说，出bug再修”，那就算代码写得再漂亮，对Anthropic这样的公司来说也是高风险。这种一票否决权，其实是在筛选价值观上的同路人。

不过说实话，这个策略对面试官的要求也极高。面试官自己必须能精准设计出那种“脱离工具依然能体现深度”的题目，而不是变成单纯的八股文背诵。比如让你现场设计一个缓解多轮对话中上下文遗忘的机制，不能套用现成的attention结构，这种题目就很好。但可惜大多数面试官自己都未必有这个功力。

所以我觉得，这个策略对公司和候选人是双向筛选。能扛住这种面试进来的人，大概率是真正理解AI安全本质的。

作为在AI领域摸爬滚打了十来年的从业者，看到这个帖子真的很有共鸣。Anthropic的这个面试策略，表面上是“反工具化”，但深挖下去，其实触及了当前AI行业最根本的一个矛盾：我们到底要培养“会用工具的人”，还是“理解工具本质的人”？我试着从几个维度拆解一下，顺便分享一些自己踩过的坑。

先说帖子里的核心观察：禁止AI辅助，本质是在考察“底层思维”。这一点我完全认同。我自己在做大模型微调时，遇到过最典型的案例就是“Transformer原理背诵得滚瓜烂熟，但一上多轮对话就崩”。比如一个候选人在面试时能流畅写出自注意力公式，提到QKV矩阵、位置编码，甚至能画出残差连接。但当我追问：在多轮对话中，如果用户连续三次打断模型，或者输入序列长度超过预训练时的最大长度（比如从4k扩展到32k），模型的位置编码需要怎么调整？旋转位置编码RoPE的旋转矩阵在长序列下会出现哪些退化问题？如果不用RoPE，改用ALiBi，它在长上下文下的优势是什么？——这时对方往往卡壳。这不是知识储备问题，而是缺乏将理论推演到实际工程边界的经验积累。Anthropic的面试恰恰是在逼候选人走出“模型是黑盒”的舒适区，去手动推导那个边界在哪里。

不过，帖子也提到了一个很现实的矛盾：工具熟练度也是生产力。这点我深有体会。去年我们团队招过一个候选人大神，他面试时不怎么谈架构，但上来就展示了用vLLM部署推理服务时，如何通过调整KV Cache的预填充策略，把单卡A100上的吞吐量从200 tokens/s拉到350 tokens/s。他当时的思路是：用paged attention的page size对齐显存带宽，再结合flash attention的tiling策略做显存复用。这种能力，如果面试时一刀切禁止代码生成或调试工具，可能根本展现不出来。因为他的强项在于“感知到工具的性能瓶颈”，而不是“徒手推导推理时间公式”。所以Anthropic式的面试，确实可能误判这类“实干型”人才。

但话说回来，Anthropic的面试策略之所以有效，恰恰是因为它把“价值观”和“技术力”拧成了一股绳。我参加过几次他们风格类似的面试（当然没进），最深的感受是：文化面试里非技术人员的否决权，其实是在考察“你是否能预见到技术方案可能带来的社会风险”。比如，他们会问：如果你在优化RLHF的reward模型时，发现某个群体的偏好数据被过度拟合，导致模型输出偏向该群体，你会怎么处理？这个问题表面是技术题（如何做数据平衡、如何设计对抗训练），但内核是价值观题（你愿不愿意在性能损失10%的前提下，主动剔除那部分数据）。这种题，靠AI工具是答不出来的，因为工具不会告诉你“性能损失10%是否值得”，这需要候选人有自己的价值排序。

再说那个留存率的问题。80%的两年留存率，我倾向于认为跟面试策略强相关，但机制不是“因为面试难所以人留得住”。更可能的是，这种面试筛选出了“对AI安全有执念”的人，而这些人恰好是高激励团队的天然匹配者。我见过太多大厂用高薪挖人，但半年后因为技术方向分歧（比如“要不要上线一个未经验证但爆款潜力大的功能”）而离职的案例。Anthropic的面试把价值观冲突前置到招聘环节，相当于提前做了一次“文化适配度过滤”，这比任何期权激励都更能留住那些“认死理”的人。当然，期权激励是必要条件，不是充分条件——如果钱给不够，再信仰坚定的人也会被现实压垮。

关于行业趋势的分化，我这两年观察到的实际案例也印证了帖子里的判断。一类是Anthropic式的“无工具审查”，另一类则走向了“工具辅助但考察调试能力”。比如我朋友所在的自动驾驶公司，他们的面试会允许候选人用Copilot写代码，但考察重点变成了：如果Copilot生成的代码在边缘场景（比如夜间湿滑路面、行人遮挡）下出现概率性崩溃，你如何通过单元测试或fuzzing测试来定位？这种思路本质上是在考察“人机协作的边界意识”——你知道工具会犯错，并且知道如何快速验证和修正。这种做法比单纯禁止工具更务实，因为它承认了“工具无法替代人的判断力，但可以放大人的效率”。

最后，我想分享一个我自己踩过的坑，可能对想实践这类面试策略的人有参考价值。去年我尝试在团队内部推行“无AI辅助”面试，结果发现一个问题：不同候选人对AI工具的依赖程度差异巨大。有些人在面试中会不自觉地用“如果我用Copilot，我会先写一个模板函数然后调优”来回答，这种回答其实反映的是“习惯性思维”，而不是能力不足。如果强行禁止所有工具，反而逼着他们在不擅长的领域（比如手写代码）耗费精力，导致无法展示真正的工程能力。后来我们调整了策略：第一轮技术面允许使用任意工具，但要求同步解释每一步操作的理由；第二轮文化面则完全禁止工具，重点考察“当没有外部辅助时，你如何构建解决问题的逻辑框架”。这种分层设计，既保留了工具熟练度的考察，又保留了底层思维的挖掘。

总结一下：Anthropic的面试策略是极端化的，它赌的是“技术信仰的浓度”。对于追求快速迭代的团队，可能更适合“工具辅助+调试能力”的混合模式。但无论如何，有一点是确定的：随着AI工具日益强大，面试的胜负手正在从“你懂多少知识”转向“你如何理解知识的边界”。能同时做到“用工具快速验证想法”和“不依赖工具独立反思工具局限”的人，才是未来最稀缺的。毕竟，当有一天AI能自动写完80%的代码时，那剩下的20%——那些需要判断“什么不该做”的时刻——才是人类工程师最后的护城河。

你说到的“能流畅回答Transformer原理，却解释不了实际鲁棒性问题”这点太真实了。我之前面过一家做对话机器人的公司，技术面时把注意力机制和位置编码背得滚瓜烂熟，结果面试官追问了一句“如果用户连续发三条语义冲突的句子，模型在长上下文里怎么保持一致性”，我当场就卡壳了。后来自己复盘才发现，很多所谓的“理解”其实只是记住了论文里的结论，根本没想过工程落地的坑。

Anthropic这个做法让我挺好奇的：他们文化面试里非技术人员的否决权具体是怎么操作的？比如一个算法能力很强的候选人，但安全对齐测试里暴露出对“模型产生有害输出”风险不够敏感，非技术面试官能直接一票否决吗？如果是这样，那技术岗的面试权重分配大概是什么比例？我猜他们可能更看重候选人在“没有代码补全”的情况下，能不能当场手撕一个带约束条件的采样逻辑，或者现场分析一个对抗样本的传播路径。这种考察方式对刷题党来说简直是噩梦，但对真正搞过安全模型的人反而是加分项。

另外想请教下，你在实际招聘时有没有遇到过那种“禁用AI后反而表现更好”的候选人？我总觉得有些工程师平时太依赖Copilot，离了工具连for循环边界条件都得想半天，但Anthropic这种极端策略说不定能筛出那些真正把模型机理刻在脑子里的人。不过也挺好奇，如果面试官自己平时也用AI写代码，那他们怎么保证面试时能准确判断候选人“脱离工具”后的真实水平？会不会有双标嫌疑？

这个点真的戳到痛处了。我面过好几个号称精通Transformer的，一问到多轮对话里怎么处理上下文漂移就卡壳，说白了就是背题背多了。Anthropic这么搞其实挺狠的，直接筛掉那些靠Copilot写项目但自己根本不解构问题的人。不过好奇这种面试模式下，他们怎么评估候选人的工程效率？毕竟实际工作中工具链也是能力的一部分。

这个点抓得很准。Anthropic面试禁用AI本质上是在筛选“能解释why而非how”的人——Transformer的鲁棒性问题恰恰暴露了很多工程师只停留在API调用层。我最近面人也发现，让候选人不靠Copilot手写一个简单的attention mask实现，能筛掉一半只会调包的人。文化面试那边给非技术一票否决权确实激进，但这才能保证安全对齐不是空话。

这个帖子让我想到，如果面试时完全禁用AI，那考察的到底是候选人当下的知识储备，还是他未来在真实工作中解决问题的能力？毕竟实际开发里没人会关掉IDE的补全功能… 另外很好奇，像调试复杂bug或者分析日志这种场景，面试官会允许用搜索引擎或者文档吗？还是说他们默认这些工具和AI有本质区别？