技术招聘新常态：识别LLM辅助下的真实理解力

这轮招聘季我陆续面试了不少候选人，发现技术岗位的候选人正在分化成三种状态：狮子型、狐狸型，以及越来越多带有 LLM 辅助痕迹的类型。第一种像狮子，问题抛出去，先给结论，再讲理由，思路硬朗，但偶尔会在边界条件上翻车。第二种像狐狸，擅长绕，遇到复杂问题会先拆解、再试探，最后给一个相对周全的回答，但有时候绕得太多，你抓不住他真正的判断。第三种不太一样，表达结构漂亮，术语准确，角度全面，像一份精心整理过的资料，但一旦被连续追问，很多地方就开始含糊。前两种我一直都在招，第三种是最近一两年才明显多起来的。

这里不讨论“该不该用 LLM 准备面试”这种站队问题。工具已经在这里了，真正值得聊的是：作为候选人，怎么把 LLM 用成思考辅助，而不是用成记忆外包；作为面试官，怎么在狮子、狐狸和 LLM 混合出现的候选池里，判断出谁真的有解决问题的能力。

我先把这段时间最想提醒同行的一句话放在前面：不要因为候选人提到 LLM 就扣分，也不要因为候选人答得完美就放松追问。真正要评估的核心只有一个——他有没有理解。

1. 狮子、狐狸，还有 LLM：技术招聘正在面对的新角色

1.1 两种经典候选人画像

做技术招聘做得久了，你会发现面试官对不同候选人其实有一套默认的观察框架。狮子型候选人的典型特征是先给结论，再给理由。你问他“这个服务怎么做高可用”，他不会先说一堆概念，而是直接告诉你“先把状态外置，再把重启和恢复做成自动化，最后压测验证恢复时间”。这种候选人处理生产事故、做技术攻坚很好用，因为他在高压下依然能快速判断。但狮子型也有短板：细节边界偶尔会被忽略，比如他只说了高可用方案，却没有提到分布式事务、数据一致性这些容易被数据打脸的地方。

狐狸型候选人相反。你问一个问题，他会先反问“这个场景的真实约束是什么，QPS 大概什么量级，容错要求是多少”。然后他会把问题拆成几个子问题，逐个给出思路。这种候选人在做复杂系统设计、跨团队协作时很占优势，因为他天然会考虑约束和权衡。问题在于，狐狸型候选人有时候会把“讨论过程”当成“答案”，聊了二十分钟，你还是不知道他最终会怎么取舍。

这两种类型没有绝对的好坏，更多是岗位匹配问题。如果团队缺一个能快速处理线上故障的运维开发，狮子型更合适；如果要做前期架构设计，狐狸型更好用。

1.2 第三种角色的出现，不是坏事，而是新常态

现在的问题是，LLM 成了第三种角色。它不完全改变候选人的性格底色，而是改变了候选人获取信息和组织表达的方式。一个原本是狐狸的候选人，可能在 LLM 帮助下把拆解过程做得更完整；一个原本是狮子的候选人，可能用 LLM 快速补齐自己不太熟悉的领域边界。

这带来一个很现实的后果：面试官过去熟悉的“问题-回答-追问”链路，不再能有效区分“真正理解”和“工具辅助下的理解”。因为 LLM 生成的内容在结构上非常像资深工程师的答案，术语准确、逻辑通顺、甚至还会主动列出风险点。

我在面试中见过一个候选人，让他解释“如何为一个多租户系统设计权限模型”。他给出的答案从 RBAC、ABAC 到租户隔离、数据权限，几乎把所有点都覆盖了，表述也很有条理。但当我追问“如果两个租户共用一个数据库，你怎样在查询层避免数据泄露”时，他开始含糊。再追问“为什么要用中间表而不是在用户表里加一个租户字段”，他的回答又绕回了“业界推荐这么做”。这说明他拿到的是一份优质答案，但真正落到执行层的时候，他没有办法从第一性原理出发解释权衡。

所以我的判断是：LLM 参与招聘不是洪水猛兽，但面试评估方式需要跟着变。过去面试可以靠一两道有区分度的题来判断候选人，现在必须靠多轮追问、场景验证和项目复盘，才能看到工具后面的真实水平。

2. 面试官真正要评估的，不是工具使用痕迹，而是理解深度

2.1 先分清四个维度：知识、理解、判断、执行

我在设计面试评估表时，会把候选人表现拆成四个维度。

第一层是知识。他知不知道这个概念，能不能说出术语。第二层是理解。他能不能用自己的话解释为什么，能不能讲清楚边界条件。第三层是判断。面对一个不确定场景，他能不能根据约束选择合适的方案。第四层是执行。他提供的方案能不能真的落地，会出现哪些坑，以及他怎么验证。

LLM 最容易补足的是第一层，也就是知识。这一层本来就是面试里最不值钱的。过去靠背诵能拿到优势，现在背诵能力更加不重要，因为任何人都能在几秒内生成一份结构完美的知识性回答。

真正难补的是第二层到第四层。理解需要推导过程，判断需要实践反馈，执行需要踩过坑。这些能力在 LLM 生成的文本里看起来都有，但它们只是“看起来有”，经不起连续追问。

2.2 用追问和边界问题，把“听说过”变成“真正理解”

那么面试官应该怎么问，才能绕开 LLM 的文本优势？

我自己的做法是：候选人的第一段回答，只当作信息量参考，不当作能力证明。真正的评估从第一段回答结束之后开始。

我会做的第一件事，是问“你是怎么得出这个结论的”。如果候选人能说出一个清晰的推导链，而不是“这个方案在业界比较常见，所以选它”，就说明他至少理解这个结论的来源。

第二件事是问边界。比如候选人提到“用消息队列做异步解耦”，我会追问：如果消息积压了怎么办？如果下游消费失败，你的重试策略是什么？重试会不会导致重复订单？这些问题会强制候选人从“概念层面”掉到“实现层面”。

第三件事是问失败场景。让候选人讲一讲“你之前做过的项目里，哪一个方案上线后出了你没想到的问题”。这个问题对那些依赖 LLM 完成项目复盘的人特别有效，因为真实的失败细节、当时的判断失误、复盘后的调整过程，通常很难被工具凭空生成。就算候选人用 LLM 帮忙润色，关键细节一定是他自己的。

2.3 判断候选人是否理解，而不是背答案

这里给一个比较直观的判断标准，方便刚做面试官的人参考。

如果一个候选人在第一轮回答中说出了关键概念，在后两轮追问中依然能保持逻辑一致、并能主动举出反例，那说明他是真的理解。如果候选人只在你问到某个具体细节时才想起补充，而且补充内容与前面的回答之间有明显的跳脱感，那大概率是他在从记忆里调用另一段材料。

还要留意一种情况：候选人说“这个问题我之前让 LLM 帮我梳理过”。这不是扣分项，反而说明他知道用工具。我会继续问“那你觉得它梳理的内容里，有哪些和你实际经验不一致”。如果他能讲出一两条不一致的细节，说明他做的是校验，而不是照单全收。如果他说“我觉得都挺对的”，那就要警惕了。

这里提醒一下：不要因为候选人提了 LLM 就预设他在投机。真正危险的不是用工具，而是放弃对工具输出的审查。

3. 一个真实场景：ComfyUI 和 LLM 该不该部署在同一台机器上

3.1 直接回答：可以分开，但先想清楚业务约束

这一节用一个我在面试和实际项目中都聊过的话题来展开：ComfyUI 和 LLM 必须在同一台电脑上吗？

先给结论：不一定。尤其是在生产环境里，ComfyUI 负责图像生成工作流的编排和节点执行，LLM 负责文本理解、提示词扩写、对话生成等任务，它们的资源需求不一样、算力需求不一样、调用频率也不一样。合理的设计通常是让它们各自部署在能满足自身瓶颈的机器上，通过 API 或内部服务完成调用。

比如 ComfyUI 这类图像工作流，瓶颈往往在 GPU 显存和显存带宽。跑一张图可能要占用十几 GB 显存，如果你的工作流里还接入了大模型来做提示词解析，那 LLM 推理也会占用 GPU。两者如果硬塞到同一台机器上，很容易出现显存不足、任务排队、切换模型频繁加载的问题。

反过来，如果只是在本机做学习和实验，那完全可以把 ComfyUI 和 LLM 放在同一台电脑上。此时需要关注的就不是“能不能”，而是“会不会互相抢占资源”。我建议先看两块：第一，GPU 显存是否足够同时容纳图像模型和语言模型；第二，是不是有比较高的并发调用需求。如果只是偶尔跑一个工作流，那分开部署的收益并不明显。

3.2 面试现场会怎么追问：延迟、显存、离线、数据、依赖

我还原一下这个题目在面试里的追问过程，因为这类问题非常能测试候选人对分布式部署和资源规划的真实理解。

候选人如果直接回答“可以分开部署”，这只是第一层。面试官接下来会追问：那分开之后，ComfyUI 调用 LLM 的网络延迟怎么处理？如果 LLM 服务端的响应时间是两秒，图像工作流能接受吗？需不需要做通信层优化，比如异步回调、任务队列、超时处理？这些追问指向的是候选人对“服务依赖”的理解，而不是对某个工具的记忆。

再追一层：如果两个服务部署在不同机器上，那么用户上传的图片、生成的中间结果、LLM 接收的文本提示词，都会经过网络传输。网络带宽够不够？敏感数据要不要走内网？如果环境是离线内网环境，该用什么方式进行私有化部署？如果选用现有 LLM 框架做服务化，那么框架本身的版本兼容性、依赖 SDK 在离线环境里能不能安装，都需要提前验证。

到这里，候选人如果还能继续讲清楚 ComfyUI 的节点模式和 LLM 服务接口之间怎么对接，说明他真正跑过类似的链路。如果只是说“应该可以，网上都说可以”，那大概率只是看过一篇部署教程。

3.3 候选人能答到什么程度，对应什么能力水平

我把候选人在这个问题上的表现分成三档。

第一档：只能给出“可以分开”的结论。这说明他知道结论，但缺少对资源、延迟、场景的判断，适合初级岗位。

第二档：能讲清楚为什么要分开，能从显存、GPU 占用、响应时间、部署复杂度几个角度展开。这说明他做过一定的架构思考，适合中级岗位。

第三档：在第二档基础上，能说出“如果延迟敏感，应该把 LLM 做成常驻服务而不是每次启动新进程”“如果显存不够，可以让图像模型和语言模型分时共享 GPU，而不是同时加载”“如果离线部署，要提前检查所有依赖包，包括 LLM 框架的推理引擎、加速库和模型文件路径”。这一类候选人通常是从实践里趟过坑的，适合负责系统设计和技术攻坚。

这道题本身不是标准答案题，它的价值在于给面试官一个可以不断往下钻的路径。每一层追问都会逼着候选人把一个“听来的知识点”还原成“自己能执行的方案”。

4. 候选人把 LLM 用在正确环节，才能在面试里加分

4.1 正确的使用方法：准备、复盘、模拟追问

作为候选人，我并不反对在面试准备阶段使用 LLM。前提是，你要把它当成交互式练习伙伴，而不是答案生成器。

我推荐的做法可以分成三步。

第一步是准备素材。先把自己的项目经历、技术栈、做过的关键决策、遇到过的失败和复盘，以条目的形式写下来。这一步不要用 LLM 代写，因为只有你清楚哪些细节是真实的。

第二步是让 LLM 生成追问清单。你可以把描述好的项目输入给模型，让它模拟一个严格的面试官，从边界条件、资源占用、失败场景、后续优化四个方向生成问题。这一步的价值不是获取正确答案，而是帮你发现自己描述里的盲点。

第三步是逐条用自己的话回答。每回答完一条，就把答案贴给 LLM，让它做反馈，指出哪里逻辑跳跃、哪里缺少数据支撑、哪里回答得过于概念化。然后你根据反馈继续修改，直到你能脱离草稿、自然讲出完整过程。

这样用下来，LLM 就像陪练。它帮你看到自己没想清楚的地方，但真正组织语言、梳理因果链、补充实例细节的人仍然是你。

4.2 错误的依赖方式：现场念答案、只记结论不记原理

我也见到过不少错误用法，简单列一下。

第一种，只记结论不记原理。候选人把面试常见问题让 LLM 生成一遍，通读几遍记个大概。这种准备方式在“概念解释题”上可能有点效果，但一旦面试官追问“为什么”，就容易卡住。因为原理层的推导过程没有被真正内化。

第二种，现场把题目丢给 LLM。不管是把手机拿起来问，还是提前准备好一段提示词让模型现场输出，这类依赖在面试里都是高风险行为。先不说合规问题，就算技术实现了，面试官连续追问两三轮之后，你仍然会露馅。因为 LLM 生成的是文本，不是你的决策过程，很多问题它没法替你回答。

第三种，把 LLM 给出的项目复盘直接当成自己的经历。比如候选人用提示词生成一个“电商大促期间系统限流设计”的方案，然后放到面试里说成自己做的项目。只要面试官多问一句“当时的流量峰值是多少、限流阈值由谁决定、有没有出现误杀”，这个项目经历就会迅速塌掉。

4.3 一个可复用的准备流程

给一个比较通用的准备流程，适用于技术岗面试前的一周。

第一天和第二天：梳理项目经历，输出一份真实的问题清单。内容包含项目背景、你的角色、核心决策、遇到的最大问题、当时的判断过程、上线后的数据变化、后续优化空间。这份清单是面试的底稿，不能靠 LLM 完成。

第三天：把底稿里的项目逐个丢给 LLM，让它生成针对性的追问问题。你不需要记住所有问题，只需要挑出那些你回答不完整的，标记为薄弱项。

第四天：针对薄弱项做专项补齐。补齐方式不是再看一遍 LLM 的答案，而是去找文档、看源码、画时序图，或者自己写个小 Demo 验证。比如你薄弱项是分布式锁，那就自己去搭一个 Redis 环境跑一遍，看锁失效表现。

第五天：模拟面试。可以找朋友，也可以让 LLM 扮演面试官，但你回答时要开启语音或打字过程，不能先看答案再复述。模拟的目标不是答对，而是练习“即使不知道确切答案，也能表达出搜索和验证路径”。

第六天和第七天：把薄弱项再过一遍，重点复习那些被追问过两次以上的内容。如果某个知识点你每次都答不顺，那大概率不是表达问题，是理解问题，要回到资料和代码层面去补。

这样准备下来的效果，通常在面试追问环节最明显。因为你的回答不是从答案库调用，而是建立在真实理解和验证基础上的。

5. 招聘流程要跟着工具进化：从背题目到测判断

5.1 把编码题改成代码阅读和调试

很多团队还在用手写算法题筛选候选人。这类题目在 LLM 普及之后，区分度正在下降。候选人完全可以把常见题目提前准备好，或者让 LLM 生成一段标准解法。手写算法测的是“有没有见过这道题”，而不是“能不能解决这个系统的实际问题”。

我更推荐改成代码阅读和调试题。给候选人一段包含 bug 的服务端代码，让他找问题、说原因、改方案。这类题目很难靠 LLM 直接生成答案，因为代码里的上下文、命名、异常处理逻辑都是现场设计的，候选人必须在真实理解后才能排查。

我一般设计代码阅读题时会故意埋三类问题：一类是空指针或并发问题，一类是资源泄漏问题，一类是边界判断问题。候选人如果能按顺序说出来，并且能解释为什么这里会出问题，那他的工程能力基本是可验证的。

5.2 项目经历追问：决策、边界、失败、复盘

项目经历永远是最难被 LLM 替代的面试环节。关键是面试官要问对方向。

我常用的追问顺序是：先问这个项目要解决什么问题，再问为什么选择现在的方案，接着问资源约束和团队协作，然后问上线后的验证方式，最后问如果重做一遍会改哪里。

举一个例子。候选人说他用过消息队列做系统异步化。我不会问“消息队列的优点是什么”，而会问“你当时为什么不用 HTTP 回调而选消息队列”？如果他说因为要削峰填谷，我会继续问：那峰值是多少？队列积压多久可以接受？如果消费失败，数据怎么恢复？这些问题没有标准答案，需要候选人从自己的项目细节里调取记忆，LLM 帮不上忙。

如果候选人讲不出来具体数字，可以用一个常见补救方式：“峰值我没有精确统计，但我们的设计目标是在三倍流量下不丢消息。”这种回答说明他知道用约束来表达设计目标，也是可以接受的。

5.3 评估表要增加“解释有效性”和“不确定性处理”

传统面试评估表里通常有“技术能力”“沟通能力”“项目经验”这些维度。在 LLM 参与成为常态后，我建议增加两个维度。

第一个是“解释有效性”。不只看候选人答没答对，还要看他能否用清晰的语言解释解决方案的推导过程。如果候选人给出了正确结论，但解释路径混乱、前后矛盾，那么 LLM 辅助的可能性很高，需要仔细甄别是否理解不足。

第二个是“不确定性处理”。面试时可以故意问一个候选人不熟悉的方向，观察他的反应。成熟的候选人会说“这块我不太熟，但根据类似经验，我会先确认这几个问题，再做一个小实验验证”。依赖工具的人则容易给出一个看似完整但经不起推敲的答案，或者长时间沉默。

评估表上最好还能记录一个独立字段：面试官是否追问了两轮以上。只要追问轮数足够多，候选人的真实水平就会浮出来。这也是我在管理招聘流程时最看重的机制——不是换更难的题，而是把追问当成标准动作，而不是看候选人状态好不好的即兴发挥。

注意：增加追问轮数后，面试时间会变长，建议把单场面试控制在 60 到 90 分钟，最多覆盖两到三个关键领域。不要为了追问而追问，每轮追问都要服务于判断候选人在某个维度上的深度。

6. 哪些信号容易被误判，以及我推荐的排查顺序

6.1 容易误判的信号

第一个容易误判的信号是“表达完美”。以前我们默认表达流畅等于能力强，现在这个等式不再成立。LLM 生成的高质量文本会让很多候选人看起来很像资深工程师。真正需要警惕的不是流畅，而是所有回答都停留在概念层，没有具体的项目细节、没有数字、没有失败经历、没有“我当时其实做错了后来才改”的痕迹。

第二个容易误判的信号是“提到 LLM 就等于能力差”。这种误判会流失掉真正会利用工具的候选人。比如一个候选人说“我在做项目里用 LLM 自动生成了接口文档，并发现了两个文档与代码不一致的地方”，这其实是加分项。因为他不是被动接受输出，而是主动用工具完成校验。区分标准不是是否依赖工具，而是是否具备审查工具输出并结合上下文验证的能力。

第三个容易误判的信号是“快速回答等于提前背题”。有些候选人确实反应快、经验足，他能在几秒钟内给出答案。如果面试官因为候选人回答太快就怀疑他用了模板，反而会误伤。我在这种情况下会主动问一个“你刚才提到的这个方案，在实际落地时最容易被忽略的点是什么”，如果候选人能说出一个真实的坑，那他的反应快就是真的。

6.2 排查链路

如果你在面试中判断候选人可能过度依赖 LLM，不要直接下结论，按照下面顺序排查。

先看问题本身。确认你问的问题是否足够具体。如果问题本身是“讲一下微服务”，这种宽泛问题本来就容易招来模板化回答。换成“你负责的一个微服务，在线用户数达到多少时开始出现超时？”才能逼出真实经验。

再看回答结构。候选人是否在每种问题下都用同样的三段式结构回答，而且几乎没有口语化表达、没有停顿、没有修正自己说法的过程。真人讲技术问题时，多多少少会出现“不对，准确说是这样”的自我修正，这是正常的思维痕迹。完全没有修正，反而说明内容可能来自背诵。

再检查项目细节。这是最可靠的一层。追问项目中具体的数字、时间、路径、工具命令、失败日志。一个亲历过项目的人，不会把“用 Docker 部署”说成“可能用了容器化技术”，也不会把线上问题描述得完全平滑。细节是防伪标记。

最后看候选人的自我反思能力。问“如果让你重新做这个项目，你会改哪个设计决策”。这个问题的答案往往藏在真实经历里，LLM 很难伪造出有体温的复盘。

6.3 招聘方也应该更新认知

最后聊一点招聘方自己的变化。

很多团队还在用旧 JD 筛选简历，比如要求“精通某项技术”，但没有把 LLM 协作能力、系统设计能力、失败复盘能力写进去。这会让招聘流程和实际工作脱节。现在很多岗位的日常工作里，LLM 已经成为写代码、写文档、分析日志的辅助工具，那么面试时也应该明确考察“候选人能否在工具辅助下把事情做好”。

我建议在 JD 里增加类似的描述：希望候选人在使用 AI 辅助编程工具时，能保持代码质量和审查意识；在系统设计问题中，能结合实际约束做决策；在项目复盘时，能讲出具体失败的根因和改进方案。

同时，内部题库要持续更新。如果一个面试题在网上已经有大量现成答案，或者用 LLM 能轻松生成完整答案，这道题的区分度就会快速下降。可以定期拿题库里的题目交给 LLM 试答，如果答案过于标准，就要设计新的追问分支。

如果让我给这一轮技术招聘的变化做一个收尾，我会这样写：LLM 不是来帮候选人混过面试的，也不是来取代面试官的。它放大的其实是我们原本就有但一直没认真对待的能力——理解、判断和反思。候选人真正的竞争力不再是知道多少，而是在不确定性面前能不能用已有经验做出合理的决策，并愿意通过实验和复盘持续修正自己。面试官要做的，也不是和工具赛跑，而是用更深层的追问，把那些真实做过、真实踩过、真实改进过的人，从大量标准化表达里找出来。

对于准备面试的工程师，我的建议还是那一句：先把单点技术验证做扎实，再用 LLM 扩充边界，最后用自己的话把整个推导过程讲给别人听。这个过程没有捷径，但它带来的能力提升，不会因为面试结束而消失。