AI 出的面试题，候选人一做就骂娘——不是题目太难，是品控规则没装

AI 出的面试题，候选人一做就骂娘——不是题目太难，是品控规则没装

我让 AI 给高级工程师岗位出 5 道面试题，它 10 秒钟吐了一份清单：

1. 什么是 Spring 的 IOC 和 AOP？
2. Redis 有哪些数据类型？
3. 简述 MySQL 索引原理。
4. 什么是微服务？
5. 说说你做过最复杂的项目。

看起来很全，覆盖框架、中间件、数据库、架构、项目经验。但这份题拿去面试 P6/P7，效果会灾难到什么程度？

前四道是"背题库"型问题，候选人提前准备一周就能对答如流，区分不出真实水平。第五道是"开放式"问题，但缺少追问抓手，面试官听完 20 分钟项目描述，还是不知道对方到底解决了什么复杂问题。

这就是 AI 出面试题的通病：它知道"面试题长什么样"，但不知道"好题目怎么区分候选人"。

面试题设计的核心：不是考知识，是考证据

很多人把面试题理解成"知识点检查清单"。这种理解下，题目越全越好，覆盖越广越好。但好的技术面试只有一个目标：在 45-60 分钟内，拿到候选人"能解决问题"的证据。

知识点可以被背诵，解题过程不能。所以一道好面试题应该满足：

• 有真实业务场景，不是抽象概念复述
• 有递进式追问空间，能区分"做过"和"看过"
• 有多个可行解，能观察候选人的取舍和权衡
• 有明确评分锚点，不同面试官打分离散度不能太大

AI 生成的题目通常只满足第一条的皮毛——套一个场景壳，但追问空间和评分锚点都是空的。

AI 出题的三大缺陷

缺陷一：题目太"平"

"Redis 有哪些数据类型？" 这种问题只有一个标准答案。候选人答对 6 个类型，你也不知道他有没有在生产环境处理过缓存穿透。

改成这样：

你们系统用 Redis 缓存商品详情，QPS 10 万。某天大促，某个不存在商品的请求量突然占到 30%，Redis 压力暴涨，数据库也开始告警。你怎么排查和解决？

这个问题一样考 Redis，但多了几个层次： - 先判断是缓存穿透、击穿还是雪崩 - 再给出具体方案（布隆过滤器、空值缓存、热点 key 打散） - 最后评估每种方案对一致性和内存的影响

从"知不知道"变成"怎么权衡"。

缺陷二：缺少追问链

好的面试题不是孤立的，是一串追问。AI 出题时只给母题，不给追问。

以微服务为例：

• 初级追问：服务间调用超时了怎么办？
• 中级追问：熔断后怎么恢复？半开状态怎么设计？
• 高级追问：熔断策略是根据错误率还是响应时间？不同业务场景怎么选阈值？

没有追问链，面试变成问答游戏。面试官问完一题换一题，候选人背完一个知识点换下一个。

缺陷三：评分标准模糊

"说说你做过最复杂的项目"是最危险的面试题。因为什么叫"复杂"，每个面试官理解不同。有人觉得并发量大叫复杂，有人觉得业务规则多叫复杂，有人觉得跨团队协作叫复杂。

结果同样是"做了订单系统"，A 面试官给 5 分，B 面试官给 3 分。评分离散度大，面试效度就低。

好题目必须有评分锚点。比如：

请描述一个你处理过的线上故障，要求包含：现象、定位过程、根因、修复方案、事后改进。我们会根据根因分析的深度、改进措施的系统性、以及是否能量化影响来评分。

sharp-interview 的品控方法论

sharp-interview 是 sharp-skills 里专门做面试题品控的模块。它的核心思路是：把"能区分候选人的面试题"编码成可执行规则，让 AI 不再出"背题库"型题目。

MUST 规则（题目不过关的硬性标准）：

• 必须基于真实业务场景，不能是概念定义题
• 必须包含至少一个明确的决策点或权衡点
• 必须附带 2-3 个递进追问
• 必须有可量化的评分锚点（至少 3 个评分维度）

SHOULD 规则（提升题目质量）：

• 应该覆盖"设计 + 排查 + 优化"三类能力，而不是只考实现
• 应该允许候选人选择技术栈，不强制指定框架
• 应该让不同经验的候选人都能答出部分内容，但深度有区分

MAY 规则（加分项）：

• 可以设置一个"常见错误答案"陷阱，考察候选人是否盲目自信
• 可以引入数据（QPS、RT、数据量）让方案有讨论基础

实测：同一 prompt 加不加规则的区别

Prompt：给 Java 后端高级工程师出 3 道面试题。

版本 A（无规则）：

1. Spring Boot 自动装配原理是什么？
2. 分布式事务有哪些解决方案？
3. 如何设计一个高并发系统？

版本 B（sharp-interview 规则后）：

1. 你们用 Spring Boot 做了一个订单服务，启动时发现某个自定义 starter 没生效。请描述你会从哪几个层面排查，并说明 @ConditionalOnMissingBean 和 @ConditionalOnClass 在什么场景下会失效。
2. 电商下单链路要同时扣库存、创订单、发优惠券。如果要求"下单成功则必须发券，库存不足则整体失败"，你会怎么设计？请对比 2PC、TCC、Saga、本地消息表在这个场景下的适用性。
3. 一个日活 1000 万的 App，首页 feed 接口 P99 响应时间从 200ms 涨到 800ms。请给出你的排查思路和优化方案，并说明哪些指标是你优先关注的。

版本 A 的题目，候选人可以靠背题应付。版本 B 的题目，候选人必须展示真实的排查思路、方案对比和指标意识。差距不在 prompt 长度，而在题目结构本身。

怎么落地到你的招聘流程

第一步，把岗位能力模型拆成 4-6 个维度。比如 Java 后端 P6：

• Java 基础与 JVM
• 中间件使用与原理
• 系统设计
• 线上问题排查
• 工程化意识

第二步，每个维度准备 2 道母题 + 追问链。母题负责打开话题，追问负责深挖。

第三步，给每道题写评分锚点。锚点不是"答对给分"，而是"答到什么深度给几分"。比如系统设计题：

• 1 分：只列了技术选型，没有说明为什么
• 3 分：说明了选型理由，但没有考虑数据量和并发
• 5 分：考虑了容量估算、故障场景、扩展路径

第四步，把规则文件交给 AI，让它按统一标准批量生成题目，人工只负责终审和微调。

这套流程能把面试官的个人偏好压到最低，把面试信度提上来。

反模式清单

最后列几个常见错误：

1. 考冷门 API。 问 ConcurrentHashMap 的 computeIfAbsent 实现细节，除了准备过面试的人，现场很少有人能答清楚。这不叫考察能力，叫考察背诵。
2. 一题定生死。 候选人某道题没答好，不代表整体不行。好面试要有多道题、多维度交叉验证。
3. 问题太大太空。 "如何设计一个电商系统？" 这种问题 30 分钟讲不完，候选人东拉西扯，面试官也抓不住重点。
4. 只有问题没有答案。 面试官自己都没想清楚"正确答案是什么"，评分全凭感觉。
5. 忽视软技能信号。 候选人说"我没做过但我会学"，和"我没做过但我的思路是……"，是两种完全不同的信号。

面试题不是考卷。考卷测的是"知道多少"，面试题测的是"能做什么"。AI 出题的问题，从来都不是信息不足，而是标准不对。

我在做一个用卡皮巴拉讲设计模式的微信小程序「爪爪代码冒险记」，23 个设计模式用漫画 + 答题的方式讲，目前正在开发中。如果你觉得这类内容有意思，搜一下「爪爪代码冒险记」，或者等我后面的文章。