上周五下午，我做了一件有点荒唐的事。
让Claude扮演面试官，对我------一个写了12年Java的人------做了一次完整的技术面试。
面试结果出来之前，我以为这会是一场走过场的自我验证。
然后我看到了那份"反馈报告"。
我关掉了窗口，去倒了杯水，回来，盯着屏幕坐了很久。
一、为什么想做这件事
起因是上个月帮公司面了几个候选人。
三个人，背景都不差，五到七年经验，简历上写着各种熟悉的技术栈。
但面完之后，我发现一件事：有些问题，我问得出来，但如果换我来回答，我也未必答得好。
比如我问一个候选人：Redis的跳表为什么比平衡树更适合做有序集合？
他卡住了。
我心里默默给他扣了分。
但事后想了想，如果有人这么问我，我能不能把跳表和AVL树的工程权衡说得清楚？
我不确定。
于是我有了一个有点自虐的念头：让AI来面我一次，看看自己到底在哪些地方是真懂，在哪些地方只是"觉得自己懂"。
二、怎么设计这次面试
我给Claude写了一个Prompt：
你是一个资深技术面试官，正在面试一个声称有12年Java后端开发经验的候选人。
面试要求：
1. 按照真实大厂面试的节奏和风格
2. 从基础原理开始，逐步深入
3. 候选人回答之后，追问细节，不要轻易放过
4. 如果候选人的回答有漏洞，直接指出
5. 面试结束后，给出客观的评估报告
面试范围：
- JVM原理与调优
- 并发编程
- 分布式系统设计
- MySQL与Redis
开始面试，第一个问题。我全程用文字回答，就像真实面试一样，不查资料，不停顿太久。
面试持续了将近一个小时。
下面是我觉得最值得记录的几个片段。
三、那些让我沉默的问题
问题1：你能说说CMS和G1的核心区别吗？
我的回答：
CMS是并发标记清除，主要解决停顿时间问题，老年代用标记-清除算法，会产生内存碎片。G1把堆划分成Region，可以预测停顿时间，整体更适合大堆场景。
AI追问：
CMS的并发标记阶段，为什么还需要一次重新标记（remark）？在这个阶段，它是怎么处理并发标记期间用户线程修改的对象引用的？
我停了大概20秒。
我知道remark这个阶段存在，也知道它是STW的。但为什么需要它，并发标记期间的引用修改具体是怎么追踪的------我说不清楚。
我给了一个模糊的回答，提到了"增量更新"，但说得很不自信。
AI的反馈是：
你提到了增量更新，方向是对的。CMS使用的是增量更新（Incremental Update）算法，在并发标记阶段，如果一个白色对象（未标记）被赋值给黑色对象的字段，写屏障会把这个引用记录下来，remark阶段再重新扫描一遍。这就是为什么remark必须STW------要保证重新扫描期间引用不再变化。你对G1的描述是准确的，但CMS的细节部分不够扎实。
我在面试记录里写下了一个字：惭愧。
这个问题我面过别人，但自己答不好。
问题2：说说synchronized和ReentrantLock的底层实现差异
这个我答得比较流畅，讲了对象头的Mark Word、锁升级过程、ReentrantLock基于AQS的实现。
AI听完，追问：
AQS的等待队列，线程是怎么被唤醒的？假设有5个线程在等锁，锁释放之后，是随机唤醒还是按顺序唤醒？公平模式和非公平模式在这里的差异是什么，底层是怎么实现的？
这个我答出来了，但有一个细节被抓到了------我说非公平锁是"随机的"。
AI纠正了我：
非公平锁不是随机的。线程释放锁之后，新来的线程会先尝试CAS抢锁，抢不到才进队列。已经在队列里等待的线程还是按顺序来的，只是新线程有机会插队。说"随机"是不准确的。
一个字的差距，但确实是错的。
问题3：一个接口平均响应时间从50ms突然变成了500ms，你怎么排查？
这个是开放题，我答得比较有把握，讲了监控、慢查询、GC日志、线程池状态、外部依赖等排查路径。
AI给的评价是：
排查思路是完整的，但你跳过了一个步骤：在看监控数据之前，第一件事应该是确认这个变慢是持续的还是偶发的、是所有用户都慢还是特定用户、是某一台机器还是所有实例。这个分类会直接影响你的排查方向，跳过它容易走弯路。
我承认这个批评是对的。
我在实际工作中其实会做这个分类，但在"表达"排查思路的时候，我习惯性地跳过了"显而易见"的部分------而这恰恰是面试里最容易被扣分的地方。
问题4：让我沉默最久的那一个
快结束的时候，AI问了一个问题：
你们现在的系统，如果让你从零开始重新设计，你会改掉什么？
我以为这是个送分题，结果说到一半，AI追问：
你刚才说要把单体拆成微服务，拆之后服务间调用的一致性问题怎么处理？你们现在用的是强一致性还是最终一致性？具体是通过什么机制保证的？
我说了最终一致性，讲了消息队列。
AI继续追：
消息丢失了怎么办？消息重复消费了怎么办？消费失败了怎么处理？你们的业务场景里，有没有哪些操作是不能接受最终一致的，那些操作你们是怎么处理的？
我答到第三个追问的时候，开始感到一种熟悉的感觉------
我知道答案的大方向，但细节是模糊的。
我平时和团队讨论架构，"最终一致性"这四个字说得很顺。但消息丢失的具体补偿机制，消费失败的重试策略，哪些业务边界是不能用最终一致的------这些我都有处理过，但从来没有系统地整理成清晰的表达。
我能做，但我说不清楚。
四、AI给的那份"评估报告"
面试结束，我让AI给出反馈。
它给了一份很直白的评估：
整体评价： 候选人有扎实的工程经验，能准确识别问题并给出可落地的方案，实战能力明显。 优势：
- 系统设计和架构判断力强，能考虑trade-off
- 排查问题的思路完整，有实际生产经验的痕迹
- 对业务背景的理解深度高于平均水平
明显的短板：
- 基础原理的掌握停留在"知道结论"，遇到追问细节时明显力不从心
- CMS垃圾回收的写屏障机制、AQS非公平锁的精确语义，都有表述错误
- 在表达复杂方案时，习惯跳过前置判断直接给结论，完整性不足
一个值得注意的现象： 候选人在"做"的层面是胜任的，但在"说"的层面有明显缺口。这在实际工作中可能没有问题，但在面试、方案评审、跨团队沟通的场合，会低估自己的真实能力。
最后一段话，我看了三遍。
五、我沉默的原因
不是因为AI说我不行。
是因为它说的我都知道是真的。
12年写代码，我解决过很多问题，主导过一些不小的系统，带过几个团队。
但有一类东西，我从来没有认真整理过：那些"我会做但说不清楚"的东西。
CMS的写屏障，我没有在项目里遇到过需要深究它的场景，所以停在了"知道有这个东西"的层面。
最终一致性的边界条件，我处理过，但从来没有逼自己把它说清楚。
非公平锁的"非随机"，我说错了，但在实际工作里，这个错误不影响任何结果。
这些漏洞，在日常工作里是隐形的。
因为工作不需要你说清楚，只需要你做对。
但AI用了一个小时，把这些漏洞一个一个地照出来了。
六、这次面试让我想明白的事
1. "会做"和"说清楚"是两种能力
我认识很多工程能力很强的人，在面试里发挥失常，不是因为他们不懂，而是因为他们从来没有练习过"把懂的东西说清楚"。
这两种能力需要分开训练。
AI模拟面试，正好是练后者的一个低成本方式------不用真的去面试，不用担心说错了丢脸。
2. 追问才是面试的真正考场
我以前以为面试考的是知识广度。
这次做完之后，我觉得更重要的是深度------能不能在被追问两到三层之后，还保持准确。
AI的追问是不留情面的。它不会因为你说得流利就放过你，它会一直追到你说不下去为止。
这种追问，比我平时的自我复习有效十倍。
3. 有些知识，你以为你懂，其实只是熟悉
"熟悉"和"懂"之间的差距，我在CMS那道题上感受得最清楚。
我熟悉CMS，用过，调过，排查过相关的GC问题。
但"熟悉"意味着我知道在什么场景下用它，知道遇到问题去哪里查。
"懂"意味着我能从原理上解释它为什么这么设计，权衡是什么，限制在哪里。
AI面试，会逼你从"熟悉"的舒适区走出来，暴露出你真正"懂"的边界在哪里。
七、我接下来打算做什么
发现了漏洞，就去补。
这次面试暴露出来的几个薄弱点，我列了一个清单：
待补强的知识点：
- CMS/G1垃圾回收的三色标记细节（写屏障机制）
- AQS的完整实现（公平/非公平的精确语义）
- 分布式一致性的边界条件（哪些场景不适合最终一致）
- 系统性整理自己做过的复杂方案，练习"说清楚"但更重要的是，我打算把"AI模拟面试"变成一个固定的习惯，每个季度做一次。
不是为了真的去找工作。
是因为这是目前我找到的，最能把"自己以为懂"和"真的懂"之间的差距暴露出来的方法。
写在最后
如果你也想试试，我把我用的Prompt放在这里：
你是一个资深技术面试官，正在面试一个声称有X年[技术栈]开发经验的候选人。
要求：
1. 从基础原理开始，逐步深入
2. 每个问题回答之后，至少追问一次细节
3. 发现回答有漏洞，直接指出并纠正
4. 面试结束后，给出包含优势和短板的评估报告
面试范围：[你想考察的技术点]
开始面试。有一个小建议：全程不要查资料，不要停顿太久，像真实面试一样作答。
这样暴露出来的漏洞，才是真实的漏洞。
做完这次面试，我想到了一句话：
AI让准备面试变容易了，但让通过面试变难了。
因为每个人都可以用AI来训练自己，面试官能问的问题越来越细，能接受的模糊答案越来越少。
以前"大概知道"就能过的问题，现在需要"真的懂"。
这不是坏事。
只是以前可以藏着的那些漏洞，现在没地方藏了。
你有没有试过让AI来面试你？发现了什么？欢迎评论区聊聊。
后端AI实验室 不讲概念，只谈实战 代码开源，每周更新