用 ChatGPT 准备面试，最消耗人的不是它答得不好，是每次都要把自己重新讲一遍。开一个新窗口，粘简历，解释项目背景，然后得到一段放在任何人身上都成立的建议。重复十几次之后，人会开始怀疑问题出在自己身上。
后来我想清楚了：它的上下文里没有我。它有的是整个互联网，缺的是我那几年具体做过什么、在哪一步卡住、最后怎么绕过去的。
通用模型的记忆里没有我
我最初以为这是提示词的问题，于是把简历写得更长，把项目描述补得更细。效果有一点，但很快遇到另一个麻烦：我越堆越多，它抓到的重点越偏。一段两页纸的项目描述里，它偏偏记住了最不重要的那句。
真正有用的解释是 RAG，但我不想把它讲成技术方案，它本质上只是把闭卷考试改成开卷。我提问的时候，系统先去我的笔记里翻出几篇相关的内容，连问题一起交给模型，模型再基于这些材料回答。
这三步拆开看都很普通。检索，把材料塞进去，生成。它的价值不在于模型更强，而在于回答有了出处。我不需要它替我编，我需要它提醒我：这件事我三年前做过，细节写在那篇复盘里。
用久了之后，我发现最实际的收益不是生成答案，而是解决忘记自己做过什么。面试里卡住的时刻，通常不是不会说，而是想不起某个具体场景。而这个问题，笔记能治，模型只是帮我更快找到那篇笔记。
所以这套东西的重心其实不在 AI。如果笔记本身是空的，或者全是“负责了某某模块的开发”这种没有信息量的句子，再好的检索也翻不出东西。我花在补笔记上的时间，远多于折腾工具。
选 Obsidian 也不是因为它功能多，恰恰是因为它足够笨。文件就是本地的 Markdown，没有数据库，没有专有格式，十年后随便一个编辑器都能打开。这个特性在我这里权重很高：面试准备是一次性的，但笔记我想留很久。代价是没有协作、没有网页端、手机上编辑体验一般，这些我都认了。
拆碎之后才检索得到
一开始我把整份简历做成一个 Markdown 文件丢进去，答案质量很差。原因说出来很简单：检索是按片段命中的，一个巨大的文档命中之后，塞给模型的是一大块混杂的上下文，里面有三个项目、两个技术栈、一堆不相干的职责描述。它只能挑着说，挑错很正常。
改成一篇笔记只放一个项目之后，情况明显好转。主控页只做索引，项目页写背景、我的职责、技术难点、量化结果，技能点和行为面试的故事各自单独成篇，再用双向链接串起来。问一个关于缓存的问题，命中范围就收窄到那两篇，不会被五年前的另一个项目干扰。
规模也有影响。一篇笔记控制在几百字到一千字之间，一个概念讲透，不贪多。太长了片段切得乱，太短了上下文不足。这个粒度是我试出来的，没有理论依据，只是用着顺手。
标题也很关键。语义检索不像关键词搜索那样精确，文件名叫“笔记 12”和叫“支付网关重构复盘”，命中率差得很远。我把所有文件名都改成了能直接读出内容的短语，这件事花了两个晚上，但它带来的提升比我换插件明显。
这个做法有代价，而且不小。拆笔记要花时间，写的时候还得逼自己把当时的数据翻出来，很多时候翻不到，只能写个大概。笔记也会过期，技术栈变了、指标重算了，旧的那篇如果不同步，反而会成为面试时的错误来源——而且它看起来很有出处，比胡说更危险。
我接受这个成本，是因为它顺带解决了一件别的事：面试前把项目笔记过一遍，本身就是最好的复习。即使没有 AI，这些文件也有用。这一点对我来说很重要，我不想为了一个工具去维护一堆只有工具能读的数据。
所以我给自己加了一条规矩：每半年清一次。过期的、被推翻的、写着写着发现不成立的，直接删掉，不留着“以后可能有用”。库越干净，检索越准，这个收益比多存几篇大得多。删东西这件事一开始挺难受，习惯之后反而轻松。
我实际拿它练什么
工具装好之后，我并没有拿它做“生成面试答案”这件事。直接生成的东西我不会背，背出来的语气一听就是背的。
我主要用它做四件事。
第一是把流水账改成有结构的叙述。我写项目笔记时是技术视角，全是“我们做了 A，然后做了 B”，缺少背景和结果。让它按情境、任务、行动、结果的顺序重排一遍，能暴露出我漏掉的部分——通常是背景交代不清，听的人不知道这件事为什么难。
第二是找漏洞，这一步比改写有用得多。我会直接问它：这段叙述里哪些结论没有证据。它经常指出“写了优化了性能，但没写优化前后的对比”，或者“提到负责协调，但没说协调了几方、卡在哪里”。这些问题我自己看不出来，因为我知道全部背景，会下意识地补全。
第三是模拟追问。给它设定一个不好说话的角色，让它基于我的笔记连续深挖。有价值的地方不是它问得多刁钻，而是它问的方向常常和我准备的方向不一样——我准备的是技术选型，它问的是为什么不是另一个方案，以及当时如果失败了怎么办。
第四是一致性检查。我把同一个项目的两份笔记分别喂进去，问它有没有互相矛盾的地方。真找出过几次，一次是时间线对不上，一次是同一件事在两篇里的角色描述不同。这种矛盾在面试里被追问出来，杀伤力比不会答更大。
这四件事都有同一个前提：材料是真实的。它不负责编故事，只负责把已有的东西重新组织、找出破绽。我试过让它“帮我编一个体现领导力的例子”，结果是那种一听就假的模板，我自己都不信。
频率上我也试过每天练，坚持不下来。更实际的做法是集中在面试前一到一个半月，每周两三次，每次挑一个项目，从头讲一遍，让它挑刺，然后把修补的内容写回笔记。这个过程很慢，但改完的那版笔记会一直留着，下次面试还能用。
还有一件事我后来才意识到：它最好用的地方是帮我发现自己在说空话。“我负责了整体架构设计”“推动了跨团队协作”，这类句子在笔记里看不出问题，被它连续追问三层之后就知道自己其实说不清。这个问题在真实面试里同样致命，只是对方不一定会追问到第三层，他会在心里记一笔。
本地还是云端
中间我走过一段弯路。看了几篇教程，用脚本自己搭了一套流程，切分、嵌入、检索、拼装，每一步都能调。搭完那天很有成就感，之后两周我一次都没打开过它。
维护一套自己的 pipeline，时间成本远高于它省下的那点 API 费用。后来我换成现成的插件，语义检索用一个，侧边栏对话用另一个。填一个 API Key，建一次索引，就能用。这类工具的功能差异没有宣传里那么大，选一个顺手的就行。
模型我选的是云端。理由很直白：这个场景要的是理解和组织，本地小模型在长一点的对话里经常抓不住重点，而我准备面试的时间有限，不想把时间花在调环境和等生成上。
有人会说这是把简历传给了第三方。确实是。我自己的处理办法是分两档：写进库里的项目描述尽量脱敏，公司名、客户名、具体金额都不写，只留技术路径和结果量级。真正敏感的内容不进这套系统。
薪资预期、和前公司的纠纷、我自己承认的短板，这些单独放在本地。用一个 8B 左右的模型，配合同样的插件，把服务地址指到本地端口，数据就不出机器。
体验是有落差的。生成慢，上下文窗口小，喂两篇长文档就开始丢前面的内容。它更像一个记性不太好但足够听话的助手。用在基于笔记做摘要、按固定格式整理这类任务上够用，用它来模拟一场高压面试，经常会问出很像但不对的问题。
硬件也是门槛。老款笔记本上跑 8B 会明显卡，风扇一直转，这种状态下人是没法专注准备的。我现在的做法是分工：涉及隐私的留在本地，通用的技术概念复习和话术打磨走云端。这个分工不算优雅，边界也要自己记着，但它是我目前能接受的平衡。
我也不打算把这套流程推荐给所有人。它成立的前提是我本来就习惯写复盘，缺的只是检索；如果一个人平时不写东西，搭完之后面对的仍然是一个空库，还会多一层“我是不是没用对”的挫败。工具能放大的只有已有的东西。
成本这边其实不高。一次建索引加上几百轮对话，费用大概是一顿饭的量级，比我在这上面花的时间便宜得多。真正贵的不是 API，是我为了省这点钱去折腾本地环境所消耗的周末。
还有一件小事要接受：索引是要维护的。改了笔记之后不重建，检索结果就会落后，慢慢开始答非所问，而我不会立刻发现，只会觉得“它最近变笨了”。我给自己的规矩是每次大改完就重建一次，代价是等待，收益是它不会在关键时刻拿旧版本糊弄我。
工具解决的是检索问题，不是理解问题。笔记里没写清楚的事，换个模型也问不出来。
我到现在也没有把这套东西整理成一个漂亮的知识图谱。图谱看起来很好看，但我实际用到的只是“这个项目关联了哪几个技术点”这一层，再复杂的结构我自己都懒得看。
真正让我在面试里说得清楚的，还是那几篇写得不怎么好看的复盘。AI 的作用是让我在需要的时候找到它们，而不是替我想出它们。
评论