“Paste a job posting, sit that companys interview 2 minutes later in your IDE”这个标题真正有价值的部分不是“2 分钟”这个速度而是“把面试准备的前半段流程自动化”这件事。它解决的是很多开发者准备跳槽时都会遇到的痛点拿到一份招聘信息不知道从哪里开始准备不知道这个岗位会考什么更不知道自己的项目经历里哪些点会被追问。这个主题围绕三样东西展开招聘信息文本、IDE 里的 AI 插件、一套能拆解岗位并生成面试问题的提示词流程。适合正在准备社招或校招面试、想用 IDE 做快速岗位调研的开发者阅读。下面按实际操作顺序拆解。1. 先搞清楚它到底解决什么问题再决定要不要搭这套工作流1.1 面试准备的时间消耗不在背诵而在信息整理和考点定位很多人准备技术面试时第一步不是刷题而是打开招聘 JD 逐条看再打开搜索引擎查公司技术栈再翻历史面经最后整理成一份考点清单。这个过程非常消耗精力。一份写得好的 JD 通常会包含岗位职责、任职要求、加分项、团队方向等但它不会直接告诉你“面试官会问你什么”。你需要自己做一次翻译把“精通 Java 并发”翻译成“可能考察 synchronized、ReentrantLock、线程池参数、CAS、volatile 原理”把“熟悉分布式系统设计”翻译成“可能追问 CAP、分布式事务、幂等性、限流降级”。这个翻译过程恰恰是 AI 最擅长做的。只要把 JD 粘贴进 IDE再用合适的提示词让模型做一次结构化拆解它就能产出一个覆盖考点、技术栈、项目经验、系统设计方向的准备清单。注意这里不是让模型替你回答问题而是让它帮你把“未知信息”转换成“已知问题”。从这个角度看标题里的“sit that companys interview”不能理解成“替你面试”而应该理解成“按这家公司的岗位要求模拟一场面试流程”。你仍然是主角模型只负责出题和反馈。1.2 为什么优先考虑在 IDE 里完成而不是浏览器标签页你可能会问为什么非要在 IDE 里做这件事在浏览器里打开一个 AI 聊天窗口不也一样吗确实可以但 IDE 场景有一个明显优势你本地的代码就是最重要的上下文。如果只是粘贴 JD浏览器里的 AI 也能生成通用面试题。但这类题目往往太泛谁都能用缺少针对你个人项目的追问。而在 IDE 里你可以把项目目录里的 README、核心模块、简历项目描述一起给到模型让它在生成题目时自动区分“通用八股”和“你简历里最可能被追问的点”。这更接近真实面试的逻辑面试官手里看过你的简历也知道岗位要求他会针对两者交叉的部分提问。另外IDE 工作流可以保存成脚本、提示词模板、输出文件形成可复用的流程。第一次搭好之后之后每次投递新岗位只需要替换 JD 和相关代码路径就能稳定产出结构化面试准备清单。这种复用性比每次都重新复制粘贴到聊天窗口要高效很多。当前不少 AI 增强型 IDE 或插件已经支持把文件拖入对话、选中代码后直接解释、把一段代码加入上下文这些操作对不熟悉命令行的开发者也很友好。真正需要动手的部分其实就是把提示词整理好、把文件目录建好。2. 搭建这套工作流前先确认你的 IDE 和大模型插件组合2.1 基础环境IDE、AI 插件、大模型 API想把这个流程跑通不需要特别强的硬件但环境组合要稳定。当前比较主流的路线是在 VS Code、JetBrains 系 IDE 或一些 AI 增强型 IDE 里接入支持自定义提示词的 AI 插件再通过插件配置大模型 API 或本地模型服务。我推荐按照以下条件来准备项目推荐配置说明IDEVS Code 或 JetBrains 系社区版够用插件生态成熟AI 插件支持自定义提示词和文件上下文的插件不绑定固定品牌重点是能读文件内容模型服务第三方 API 或本地模型本地模型要关注显存、内存和响应速度工作目录面试准备专用目录建议拆分 JD、题目、回答草稿、提示词四个子目录注意这里不绑定某一个固定插件。原因很简单这类插件更新很快而且每个人的网络条件、API 配置、IDE 版本都不同。标题里说的“2 分钟”前提是环境已经配好、模型响应稳定而不是第一次打开 IDE 就能做到。2.2 数据输入的三种形式文本粘贴、文件导入、代码库关联实际操作时招聘信息有三种喂给模型的方式三种方式有时可以混用。第一种是直接粘贴。从招聘网站复制 JD 正文粘贴到 IDE 的 AI 对话输入框或提示词文件中。这种方式最快适合只想快速出一份问题清单的场景。缺点是你得手动清理掉招聘网站上的排版噪音比如按钮文案、公司福利、联系方式等。第二种是文件导入。把 JD 保存成 markdown 或 txt放到 job_descriptions 目录里然后在提示词中引用该文件。这种方式适合批量处理多个岗位。你可以写一个小脚本遍历目录把每个 JD 文件依次交给模型处理输出结果自动命名保存。第三种是代码库关联。把你简历里提到的项目在本地的对应目录打开选中一个核心文件或 README让模型结合文件内容生成项目追问。这属于进阶用法也是 IDE 工作流相对浏览器最大的优势。3. 从粘贴一条 JD 到生成模拟面试问法我是这样拆步骤的3.1 第一步把 JD 放进 IDE 的上下文第一步不是直接问“给我出一套面试题”。先做输入清洗把 JD 里无关的信息删掉只保留岗位职责、任职要求、加分项、技术栈关键词。如果你是从网页复制的注意把多余的链接、换行、特殊符号清理掉。清洗之后把这段文本粘贴到 IDE 的对话输入框并同时说明你的身份。我的做法是先在提示词里写清楚“我是一名 Java 后端开发者正在准备这个岗位的面试。请帮我拆解岗位要求并标记出我可能需要重点准备的技术点。”这样做是为了让模型知道你是有经验的人不需要从零科普可以直接进入考点分析。3.2 第二步做需求拆解先别急于问题目很多人会跳过这一步直接让模型出题。结果就是题目非常空泛比如“请介绍一下 Java 中的多线程”。这种题目确实有用但它和这份 JD 的关系很弱。更稳妥的顺序是先让模型把 JD 转成一个结构化列表包含技术栈要求、业务场景、软性要求、加分项然后基于这个列表再生成题目。拆解输出大概长这样JD 原文片段翻译为考点准备优先级熟悉 Spring Boot 微服务开发Spring Boot 自动装配、AOP、Bean 生命周期、配置中心高有订单系统或支付系统经验分布式事务、幂等、对账、金额精度高掌握 MySQL 和 Redis索引优化、锁、事务隔离级别、缓存一致性中加分项有高并发调优经验线程池、限流、熔断、Full GC 排查低但可能加分这步非常关键。它决定了后续题目是“针对这个公司需求”还是“随便拿一套题来糊弄”。我一般在模型输出表格后会人工检查一遍有没有 JD 里没提的突然冒出来的考点有没有明显不符合自己经验水平的内容。发现问题就及时修正提示词。3.3 第三步生成面试问题清单和考察点需求拆解完成后再让模型生成面试问题。这时提示词要明确问题维度不要只生成“算法题”或“八股文”。建议按四类输出基础技术题对应 JD 里明确写到的技术栈。项目经历题针对简历里写过的项目进行追问考察真实参与度。系统设计题考察架构能力比如“如果让你设计一个短链接系统你会怎么拆”。软技能与团队题沟通、协作、故障处理、质疑场景。比如针对“订单系统经验”这个点基础题可能会是“你如何处理订单表的高并发写入”项目经历题则可能是“你在订单项目里做过哪些优化怎么验证最终效果”系统设计题可能是“如果要做订单超时自动取消有哪些方案”。这种题目才是有梯度的一套题。注意生成后要筛选。模型可能在项目经历题里编造你没做过的功能因为它的训练数据来自大量公开项目。人工筛选这一步不能省特别是项目经历题只能用来参考提问角度不能直接当成“你的真实项目经验”来回答。3.4 第四步关联本地代码生成项目追问求职者最容易吃亏的地方不是基础题答不上来而是写过的项目被面试官追问细节时卡住。要减少这种情况可以把本地项目代码打开选中核心模块或 README让模型基于代码内容生成追问。我常用的做法是在提示词里放进一段话“下面是我的项目 README 和核心代码片段请结合上面的 JD 考点生成 5 个面试官可能追问的问题并指出每个问题对应代码里的哪一部分。”这样生成的问题就不是泛泛而谈而是会指向具体实现。比如模型可能会问“你的 userId 分片策略是怎么设计的如果某个分片数据量过大你打算怎么处理”这类问题在真实面试里非常常见因为你可能写在 README 里说用了分库分表面试官就会顺着往下问。这一步做完你就得到两个成果一份通用考点题一份结合代码的项目追问。这两个成果合起来约等于一次完整的面试预演脚本。3.5 第五步输出回答草稿与知识缺口清单出了题之后不要只停留在“看一遍问题”。更实用的做法是把问题逐条发给模型让它生成一个“回答框架”注意不是标准答案而是包含要点、代码片段思路、可能的追问方向的框架。你在此基础上补充自己的经验细节形成回答草稿。同时让模型标记知识缺口。你可以问“上面这些问题里哪些是新手最容易答不出来哪些需要写代码演示”模型的回答可以作为检查清单帮你把复习优先级排序。这步完成之后整个工作流就有了闭环输入 JD - 拆解考点 - 生成题目 - 结合项目追问 - 输出回答草稿 - 整理待复习点。下次准备新岗位只需要换 JD 和项目路径。4. 提示词模板和参数设计决定生成质量的关键4.1 一套可以复制的提示词模板为了让流程稳定我建议把提示词保存成模板文件不要每次都临时敲。下面是一套可以改着用的模板你根据实际 IDE 插件要求调整格式。请你扮演一位技术面试官岗位方向是 [语言/方向]。 我现在把这份招聘信息粘贴给你请按以下步骤输出 第一步拆解岗位要求 - 技术栈要求 - 业务场景要求 - 面试考点预估 - 加分项和潜在深挖点 第二步生成 10 道面试题 - 3 道基础技术题 - 2 道项目经历题 - 3 道系统设计题 - 2 道软技能题 第三步针对每道题给出一句话考察点 - 面试官想通过这道题了解什么 - 如果候选人继续答下去可能的追问方向 第四步标记风险点 - 哪些考点与 JD 强相关不能跳过 - 哪些坑是候选人容易说错或说不清的 以下内容为我的候选背景和输入文本。 [候选背景2 年 Java 后端经验主要写过订单和后台管理系统] [招聘信息粘贴 JD]这个模板的用意是让输出保持结构一致。你可以根据岗位和自身经验调整题目数量但强烈建议保留“考察点”和“追问方向”这两栏。只有自己知道面试官为什么问这个准备时才知道该往哪个方向使劲。4.2 温度、模型、上下文长度怎么调如果你用的插件支持参数调整这里给几个通用经验。生成面试题时温度可以设置在 0.3 到 0.7 之间。温度太低输出会偏保守题目会显得模板化温度太高模型容易绕出 JD 范围开始编一些不存在的要求。拆解考点时用低一点更稳生成追问时可以稍微调高让它写出更发散的问题。模型选择上功能越新的模型通常效果越好但也要看你的配置成本和响应速度。如果只是准备面试不必追求最大的模型关键在于提示词是否把任务边界说清楚。上下文长度需要注意。JD 本身不长但如果你同时把 README、简历、多个代码文件放进去很快会超过窗口限制。我的建议是分轮进行不要一次性把所有材料都塞进去。先做 JD 拆解再单独关联代码项目。这样既不会爆上下文也方便你检查每一轮的输出。4.3 如何防止模型编造公司内部信息一个大坑是模型在生成面试题时可能会添加它从训练数据里推测出来的“公司小作文”。比如它可能会说“这家公司实际上使用某种架构”“该公司面试一般会问某题”。这类信息很可能带有猜测成分甚至和当前招聘信息完全不符。要防止这种情况必须在提示词里明确约束“只能基于用户提供的招聘信息和项目文件生成内容不要推测公司内部规则、薪资、团队情况、面试流程。”如果信息不在输入材料中请模型如实说明不确定性。另外不要为了追求热门话题而让模型“结合网上流传的公司面经”去生成题目。面经不是 JD它既不实时也不稳定还可能涉及非公开信息。稳妥的做法是只把 JD 和你自己的材料作为事实来源。5. 批量处理多个岗位和扩展用法5.1 把一个表格里的 JD 批量跑完如果你同时投了多家公司建议把 JD 整理成一个 CSV 或 Markdown 表格每行一个岗位包含公司名、岗位名、JD 链接、JD 正文。然后写一个简单的脚本逐个把 JD 交给模型处理输出保存到 question_bank 目录。# 示例伪代码具体接口按你使用的插件或模型服务调整 import csv import os jobs [] with open(jobs.csv, encodingutf-8) as f: reader csv.DictReader(f) for row in reader: jobs.append(row) output_dir question_bank os.makedirs(output_dir, exist_okTrue) for job in jobs: company job[company] jd job[jd] prompt f请根据以下招聘信息生成面试准备清单。\n公司{company}\nJD{jd}\n按第四部分的模板输出。 # 调用模型接口并保存结果 # response chat_model(prompt) # with open(f{output_dir}/{company}.md, w, encodingutf-8) as f: # f.write(response)这里写的只是流程示例实际接口要根据你用的代码填充。批量跑之前先用手工方式验证一条 JD 的输出结构再放开循环。不要一上来就开大并发否则很容易出现部分任务返回空结果、超时或者输出乱序。更稳的批次是一次处理几个然后人工抽查生成质量。批量跑完之后建议在 question_bank 里只保留岗位名称和输出文件不要在文件名或内容里放联系方式、证件信息、薪资历史等敏感内容。否则文件一旦同步到云端代码仓库会带来不必要的隐私风险。5.2 导出为面试复习清单模型生成的内容只是原料不是复习终态。我一般会把每份面试准备清单再整理成三部分考点速览、题目列表、一段自我介绍。考点速览可以是一个表格题目列表则按基础题、项目题、设计题分类自我介绍用 1 分钟和 3 分钟两个版本。整理动作不一定非要在 IDE 里做但可以继续用 IDE 打开生成的 Markdown 文件进行编辑顺手在待复习的点后面打勾。这样文件本身就变成了一张可追踪的复习卡。面试前只需要打开这个文件快速过一遍。5.3 与简历、项目 README 组合成第二层面试题只针对 JD 出题还是缺少“个人化”。更强的做法是把 JD、简历项目描述、项目 README 放在同一个目录下让模型生成一份“交叉题目”。比如 JD 要求“熟悉分布式事务”而你简历里写“开发过一个优惠券系统涉及库存扣减”模型的题目就可能变成“你的优惠券库存扣减如何保证不超发如果引入消息队列异步扣减会带来哪些一致性问题”这种交叉问题在真实面试里出现的概率很高因为在面试官眼里JD 是岗位基线简历是候选人差异点他需要验证的是“这个人的经验能不能覆盖岗位需求”。建议每个岗位都生成 5 到 8 道交叉题不用多但每道题都要写清参考答案要点。6. 容易踩的坑与排查链路6.1 生成内容太泛问题不够“公司定制”如果模型输出的题目和 JD 几乎没有关系比如不管你贴什么 JD它都返回同一套“Java 八股”优先检查两点。第一提示词里是否明确要求先拆解 JD 再生成题目。如果一上来就让它出题模型很容易进入通用题目模式。第二JD 是否被插件的上下文截断了。有些插件对长文本有长度限制看起来粘贴了全文实际发送时只发送了开头部分。你可以在输出里检查它是否有引用 JD 中的具体关键词如果完全没引用基本可以断定上下文传递出了问题。6.2 模型出现事实性错误生成面试准备内容时模型有可能把某个框架的原理讲错或者写出不存在的 API。这类错误很难完全避免所以我不建议把模型生成的内容当成“标准答案”去背诵。更合理的用法是把模型输出当作索引然后自己查阅官方文档或源码验证关键细节。比如模型说“ConcurrentHashMap 在 JDK 8 中放弃了分段锁”这个结论大体正确但你最好亲自去源码里看一眼才能在面试中讲清粒度变化。所有涉及具体版本、具体 API 的结论都要以官方文档为准。排查时如果发现错误集中在某个技术领域比如 Redis、MySQL 参数可以单独再写一个提示词要求模型“只输出结论并把结论按确定、可能、需要查阅分成三档”。这样至少能减少盲目信任。6.3 输出乱码、超时、插件不生效如果是输出乱码先检查文件编码。使用中文内容时建议把工作目录下的文件统一保存为 UTF-8。如果是插件不生效先确认插件的版本和 IDE 版本兼容性再确认提示词是否被插件自动截断或转义。超时则要从上下文长度和网络条件排查把一次发送的文件数量降下来通常能解决大半问题。这里给一个通用排查顺序先看现象是没输出、超时、乱码还是内容质量不对。再看输入JD 文本是否完整文件路径是否指向了正确文件是否夹带了无关内容。再看环境IDE 插件版本、模型服务状态、上下文长度限制。再看参数温度、模型选择、并发数、超时时间。最后判断是不是功能边界问题有些插件本身不支持读取整个目录只接收选中内容这时你需要手动选中代码文件再发送。6.4 隐私和数据安全建议最后说一个容易被忽略的问题。招聘 JD 虽然是公开信息但你粘贴进去的不只是 JD还可能有简历、代码、项目 README。这些内容里可能包含内部系统名称、未公开的业务逻辑、配置文件里的密钥、个人信息。所以在使用任意大模型服务之前一定要检查输入内容。不要把数据库密码、生产环境 IP、用户隐私数据放进提示词。如果你所在公司有代码保密要求更不应该把公司内部项目文件直接粘贴到第三方 AI 工具里。稳妥做法是只把项目里可公开的 README 片段或你自己重新整理过的项目说明放进上下文。用脱敏后的信息描述项目既能帮助生成项目追问又不会泄露敏感内容。如果你需要长期保存这些文件建议把面试准备目录加入 .gitignore避免不小心同步到公共代码仓库。这个动作很小但在求职阶段文件量变多之后能省掉很多不必要的麻烦。整体跑完之后我自己最深的感受是这个流程真正提升的不是“背题能力”而是把一份陌生岗位快速结构化、再对照自身项目找出差距的能力。它适合用在投递前做快速筛选也适合面试前一晚做集中预演。但你仍然需要花时间把生成的高频考点真正弄懂把项目细节亲自验证一遍。工具帮你节省的是查找和整理信息的时间而不是最后那个“站在面试官面前把问题答清楚”的环节。建议先把单条 JD 跑稳再决定要不要批量处理先把提示词模板固定下来再逐步加入代码关联和项目追问。这样这套 IDE 工作流才有可能在真实求职里起作用。 用AI在IDE里把招聘JD变成面试题：一份可复用的准备流程
“Paste a job posting, sit that companys interview 2 minutes later in your IDE”这个标题真正有价值的部分不是“2 分钟”这个速度而是“把面试准备的前半段流程自动化”这件事。它解决的是很多开发者准备跳槽时都会遇到的痛点拿到一份招聘信息不知道从哪里开始准备不知道这个岗位会考什么更不知道自己的项目经历里哪些点会被追问。这个主题围绕三样东西展开招聘信息文本、IDE 里的 AI 插件、一套能拆解岗位并生成面试问题的提示词流程。适合正在准备社招或校招面试、想用 IDE 做快速岗位调研的开发者阅读。下面按实际操作顺序拆解。1. 先搞清楚它到底解决什么问题再决定要不要搭这套工作流1.1 面试准备的时间消耗不在背诵而在信息整理和考点定位很多人准备技术面试时第一步不是刷题而是打开招聘 JD 逐条看再打开搜索引擎查公司技术栈再翻历史面经最后整理成一份考点清单。这个过程非常消耗精力。一份写得好的 JD 通常会包含岗位职责、任职要求、加分项、团队方向等但它不会直接告诉你“面试官会问你什么”。你需要自己做一次翻译把“精通 Java 并发”翻译成“可能考察 synchronized、ReentrantLock、线程池参数、CAS、volatile 原理”把“熟悉分布式系统设计”翻译成“可能追问 CAP、分布式事务、幂等性、限流降级”。这个翻译过程恰恰是 AI 最擅长做的。只要把 JD 粘贴进 IDE再用合适的提示词让模型做一次结构化拆解它就能产出一个覆盖考点、技术栈、项目经验、系统设计方向的准备清单。注意这里不是让模型替你回答问题而是让它帮你把“未知信息”转换成“已知问题”。从这个角度看标题里的“sit that companys interview”不能理解成“替你面试”而应该理解成“按这家公司的岗位要求模拟一场面试流程”。你仍然是主角模型只负责出题和反馈。1.2 为什么优先考虑在 IDE 里完成而不是浏览器标签页你可能会问为什么非要在 IDE 里做这件事在浏览器里打开一个 AI 聊天窗口不也一样吗确实可以但 IDE 场景有一个明显优势你本地的代码就是最重要的上下文。如果只是粘贴 JD浏览器里的 AI 也能生成通用面试题。但这类题目往往太泛谁都能用缺少针对你个人项目的追问。而在 IDE 里你可以把项目目录里的 README、核心模块、简历项目描述一起给到模型让它在生成题目时自动区分“通用八股”和“你简历里最可能被追问的点”。这更接近真实面试的逻辑面试官手里看过你的简历也知道岗位要求他会针对两者交叉的部分提问。另外IDE 工作流可以保存成脚本、提示词模板、输出文件形成可复用的流程。第一次搭好之后之后每次投递新岗位只需要替换 JD 和相关代码路径就能稳定产出结构化面试准备清单。这种复用性比每次都重新复制粘贴到聊天窗口要高效很多。当前不少 AI 增强型 IDE 或插件已经支持把文件拖入对话、选中代码后直接解释、把一段代码加入上下文这些操作对不熟悉命令行的开发者也很友好。真正需要动手的部分其实就是把提示词整理好、把文件目录建好。2. 搭建这套工作流前先确认你的 IDE 和大模型插件组合2.1 基础环境IDE、AI 插件、大模型 API想把这个流程跑通不需要特别强的硬件但环境组合要稳定。当前比较主流的路线是在 VS Code、JetBrains 系 IDE 或一些 AI 增强型 IDE 里接入支持自定义提示词的 AI 插件再通过插件配置大模型 API 或本地模型服务。我推荐按照以下条件来准备项目推荐配置说明IDEVS Code 或 JetBrains 系社区版够用插件生态成熟AI 插件支持自定义提示词和文件上下文的插件不绑定固定品牌重点是能读文件内容模型服务第三方 API 或本地模型本地模型要关注显存、内存和响应速度工作目录面试准备专用目录建议拆分 JD、题目、回答草稿、提示词四个子目录注意这里不绑定某一个固定插件。原因很简单这类插件更新很快而且每个人的网络条件、API 配置、IDE 版本都不同。标题里说的“2 分钟”前提是环境已经配好、模型响应稳定而不是第一次打开 IDE 就能做到。2.2 数据输入的三种形式文本粘贴、文件导入、代码库关联实际操作时招聘信息有三种喂给模型的方式三种方式有时可以混用。第一种是直接粘贴。从招聘网站复制 JD 正文粘贴到 IDE 的 AI 对话输入框或提示词文件中。这种方式最快适合只想快速出一份问题清单的场景。缺点是你得手动清理掉招聘网站上的排版噪音比如按钮文案、公司福利、联系方式等。第二种是文件导入。把 JD 保存成 markdown 或 txt放到 job_descriptions 目录里然后在提示词中引用该文件。这种方式适合批量处理多个岗位。你可以写一个小脚本遍历目录把每个 JD 文件依次交给模型处理输出结果自动命名保存。第三种是代码库关联。把你简历里提到的项目在本地的对应目录打开选中一个核心文件或 README让模型结合文件内容生成项目追问。这属于进阶用法也是 IDE 工作流相对浏览器最大的优势。3. 从粘贴一条 JD 到生成模拟面试问法我是这样拆步骤的3.1 第一步把 JD 放进 IDE 的上下文第一步不是直接问“给我出一套面试题”。先做输入清洗把 JD 里无关的信息删掉只保留岗位职责、任职要求、加分项、技术栈关键词。如果你是从网页复制的注意把多余的链接、换行、特殊符号清理掉。清洗之后把这段文本粘贴到 IDE 的对话输入框并同时说明你的身份。我的做法是先在提示词里写清楚“我是一名 Java 后端开发者正在准备这个岗位的面试。请帮我拆解岗位要求并标记出我可能需要重点准备的技术点。”这样做是为了让模型知道你是有经验的人不需要从零科普可以直接进入考点分析。3.2 第二步做需求拆解先别急于问题目很多人会跳过这一步直接让模型出题。结果就是题目非常空泛比如“请介绍一下 Java 中的多线程”。这种题目确实有用但它和这份 JD 的关系很弱。更稳妥的顺序是先让模型把 JD 转成一个结构化列表包含技术栈要求、业务场景、软性要求、加分项然后基于这个列表再生成题目。拆解输出大概长这样JD 原文片段翻译为考点准备优先级熟悉 Spring Boot 微服务开发Spring Boot 自动装配、AOP、Bean 生命周期、配置中心高有订单系统或支付系统经验分布式事务、幂等、对账、金额精度高掌握 MySQL 和 Redis索引优化、锁、事务隔离级别、缓存一致性中加分项有高并发调优经验线程池、限流、熔断、Full GC 排查低但可能加分这步非常关键。它决定了后续题目是“针对这个公司需求”还是“随便拿一套题来糊弄”。我一般在模型输出表格后会人工检查一遍有没有 JD 里没提的突然冒出来的考点有没有明显不符合自己经验水平的内容。发现问题就及时修正提示词。3.3 第三步生成面试问题清单和考察点需求拆解完成后再让模型生成面试问题。这时提示词要明确问题维度不要只生成“算法题”或“八股文”。建议按四类输出基础技术题对应 JD 里明确写到的技术栈。项目经历题针对简历里写过的项目进行追问考察真实参与度。系统设计题考察架构能力比如“如果让你设计一个短链接系统你会怎么拆”。软技能与团队题沟通、协作、故障处理、质疑场景。比如针对“订单系统经验”这个点基础题可能会是“你如何处理订单表的高并发写入”项目经历题则可能是“你在订单项目里做过哪些优化怎么验证最终效果”系统设计题可能是“如果要做订单超时自动取消有哪些方案”。这种题目才是有梯度的一套题。注意生成后要筛选。模型可能在项目经历题里编造你没做过的功能因为它的训练数据来自大量公开项目。人工筛选这一步不能省特别是项目经历题只能用来参考提问角度不能直接当成“你的真实项目经验”来回答。3.4 第四步关联本地代码生成项目追问求职者最容易吃亏的地方不是基础题答不上来而是写过的项目被面试官追问细节时卡住。要减少这种情况可以把本地项目代码打开选中核心模块或 README让模型基于代码内容生成追问。我常用的做法是在提示词里放进一段话“下面是我的项目 README 和核心代码片段请结合上面的 JD 考点生成 5 个面试官可能追问的问题并指出每个问题对应代码里的哪一部分。”这样生成的问题就不是泛泛而谈而是会指向具体实现。比如模型可能会问“你的 userId 分片策略是怎么设计的如果某个分片数据量过大你打算怎么处理”这类问题在真实面试里非常常见因为你可能写在 README 里说用了分库分表面试官就会顺着往下问。这一步做完你就得到两个成果一份通用考点题一份结合代码的项目追问。这两个成果合起来约等于一次完整的面试预演脚本。3.5 第五步输出回答草稿与知识缺口清单出了题之后不要只停留在“看一遍问题”。更实用的做法是把问题逐条发给模型让它生成一个“回答框架”注意不是标准答案而是包含要点、代码片段思路、可能的追问方向的框架。你在此基础上补充自己的经验细节形成回答草稿。同时让模型标记知识缺口。你可以问“上面这些问题里哪些是新手最容易答不出来哪些需要写代码演示”模型的回答可以作为检查清单帮你把复习优先级排序。这步完成之后整个工作流就有了闭环输入 JD - 拆解考点 - 生成题目 - 结合项目追问 - 输出回答草稿 - 整理待复习点。下次准备新岗位只需要换 JD 和项目路径。4. 提示词模板和参数设计决定生成质量的关键4.1 一套可以复制的提示词模板为了让流程稳定我建议把提示词保存成模板文件不要每次都临时敲。下面是一套可以改着用的模板你根据实际 IDE 插件要求调整格式。请你扮演一位技术面试官岗位方向是 [语言/方向]。 我现在把这份招聘信息粘贴给你请按以下步骤输出 第一步拆解岗位要求 - 技术栈要求 - 业务场景要求 - 面试考点预估 - 加分项和潜在深挖点 第二步生成 10 道面试题 - 3 道基础技术题 - 2 道项目经历题 - 3 道系统设计题 - 2 道软技能题 第三步针对每道题给出一句话考察点 - 面试官想通过这道题了解什么 - 如果候选人继续答下去可能的追问方向 第四步标记风险点 - 哪些考点与 JD 强相关不能跳过 - 哪些坑是候选人容易说错或说不清的 以下内容为我的候选背景和输入文本。 [候选背景2 年 Java 后端经验主要写过订单和后台管理系统] [招聘信息粘贴 JD]这个模板的用意是让输出保持结构一致。你可以根据岗位和自身经验调整题目数量但强烈建议保留“考察点”和“追问方向”这两栏。只有自己知道面试官为什么问这个准备时才知道该往哪个方向使劲。4.2 温度、模型、上下文长度怎么调如果你用的插件支持参数调整这里给几个通用经验。生成面试题时温度可以设置在 0.3 到 0.7 之间。温度太低输出会偏保守题目会显得模板化温度太高模型容易绕出 JD 范围开始编一些不存在的要求。拆解考点时用低一点更稳生成追问时可以稍微调高让它写出更发散的问题。模型选择上功能越新的模型通常效果越好但也要看你的配置成本和响应速度。如果只是准备面试不必追求最大的模型关键在于提示词是否把任务边界说清楚。上下文长度需要注意。JD 本身不长但如果你同时把 README、简历、多个代码文件放进去很快会超过窗口限制。我的建议是分轮进行不要一次性把所有材料都塞进去。先做 JD 拆解再单独关联代码项目。这样既不会爆上下文也方便你检查每一轮的输出。4.3 如何防止模型编造公司内部信息一个大坑是模型在生成面试题时可能会添加它从训练数据里推测出来的“公司小作文”。比如它可能会说“这家公司实际上使用某种架构”“该公司面试一般会问某题”。这类信息很可能带有猜测成分甚至和当前招聘信息完全不符。要防止这种情况必须在提示词里明确约束“只能基于用户提供的招聘信息和项目文件生成内容不要推测公司内部规则、薪资、团队情况、面试流程。”如果信息不在输入材料中请模型如实说明不确定性。另外不要为了追求热门话题而让模型“结合网上流传的公司面经”去生成题目。面经不是 JD它既不实时也不稳定还可能涉及非公开信息。稳妥的做法是只把 JD 和你自己的材料作为事实来源。5. 批量处理多个岗位和扩展用法5.1 把一个表格里的 JD 批量跑完如果你同时投了多家公司建议把 JD 整理成一个 CSV 或 Markdown 表格每行一个岗位包含公司名、岗位名、JD 链接、JD 正文。然后写一个简单的脚本逐个把 JD 交给模型处理输出保存到 question_bank 目录。# 示例伪代码具体接口按你使用的插件或模型服务调整 import csv import os jobs [] with open(jobs.csv, encodingutf-8) as f: reader csv.DictReader(f) for row in reader: jobs.append(row) output_dir question_bank os.makedirs(output_dir, exist_okTrue) for job in jobs: company job[company] jd job[jd] prompt f请根据以下招聘信息生成面试准备清单。\n公司{company}\nJD{jd}\n按第四部分的模板输出。 # 调用模型接口并保存结果 # response chat_model(prompt) # with open(f{output_dir}/{company}.md, w, encodingutf-8) as f: # f.write(response)这里写的只是流程示例实际接口要根据你用的代码填充。批量跑之前先用手工方式验证一条 JD 的输出结构再放开循环。不要一上来就开大并发否则很容易出现部分任务返回空结果、超时或者输出乱序。更稳的批次是一次处理几个然后人工抽查生成质量。批量跑完之后建议在 question_bank 里只保留岗位名称和输出文件不要在文件名或内容里放联系方式、证件信息、薪资历史等敏感内容。否则文件一旦同步到云端代码仓库会带来不必要的隐私风险。5.2 导出为面试复习清单模型生成的内容只是原料不是复习终态。我一般会把每份面试准备清单再整理成三部分考点速览、题目列表、一段自我介绍。考点速览可以是一个表格题目列表则按基础题、项目题、设计题分类自我介绍用 1 分钟和 3 分钟两个版本。整理动作不一定非要在 IDE 里做但可以继续用 IDE 打开生成的 Markdown 文件进行编辑顺手在待复习的点后面打勾。这样文件本身就变成了一张可追踪的复习卡。面试前只需要打开这个文件快速过一遍。5.3 与简历、项目 README 组合成第二层面试题只针对 JD 出题还是缺少“个人化”。更强的做法是把 JD、简历项目描述、项目 README 放在同一个目录下让模型生成一份“交叉题目”。比如 JD 要求“熟悉分布式事务”而你简历里写“开发过一个优惠券系统涉及库存扣减”模型的题目就可能变成“你的优惠券库存扣减如何保证不超发如果引入消息队列异步扣减会带来哪些一致性问题”这种交叉问题在真实面试里出现的概率很高因为在面试官眼里JD 是岗位基线简历是候选人差异点他需要验证的是“这个人的经验能不能覆盖岗位需求”。建议每个岗位都生成 5 到 8 道交叉题不用多但每道题都要写清参考答案要点。6. 容易踩的坑与排查链路6.1 生成内容太泛问题不够“公司定制”如果模型输出的题目和 JD 几乎没有关系比如不管你贴什么 JD它都返回同一套“Java 八股”优先检查两点。第一提示词里是否明确要求先拆解 JD 再生成题目。如果一上来就让它出题模型很容易进入通用题目模式。第二JD 是否被插件的上下文截断了。有些插件对长文本有长度限制看起来粘贴了全文实际发送时只发送了开头部分。你可以在输出里检查它是否有引用 JD 中的具体关键词如果完全没引用基本可以断定上下文传递出了问题。6.2 模型出现事实性错误生成面试准备内容时模型有可能把某个框架的原理讲错或者写出不存在的 API。这类错误很难完全避免所以我不建议把模型生成的内容当成“标准答案”去背诵。更合理的用法是把模型输出当作索引然后自己查阅官方文档或源码验证关键细节。比如模型说“ConcurrentHashMap 在 JDK 8 中放弃了分段锁”这个结论大体正确但你最好亲自去源码里看一眼才能在面试中讲清粒度变化。所有涉及具体版本、具体 API 的结论都要以官方文档为准。排查时如果发现错误集中在某个技术领域比如 Redis、MySQL 参数可以单独再写一个提示词要求模型“只输出结论并把结论按确定、可能、需要查阅分成三档”。这样至少能减少盲目信任。6.3 输出乱码、超时、插件不生效如果是输出乱码先检查文件编码。使用中文内容时建议把工作目录下的文件统一保存为 UTF-8。如果是插件不生效先确认插件的版本和 IDE 版本兼容性再确认提示词是否被插件自动截断或转义。超时则要从上下文长度和网络条件排查把一次发送的文件数量降下来通常能解决大半问题。这里给一个通用排查顺序先看现象是没输出、超时、乱码还是内容质量不对。再看输入JD 文本是否完整文件路径是否指向了正确文件是否夹带了无关内容。再看环境IDE 插件版本、模型服务状态、上下文长度限制。再看参数温度、模型选择、并发数、超时时间。最后判断是不是功能边界问题有些插件本身不支持读取整个目录只接收选中内容这时你需要手动选中代码文件再发送。6.4 隐私和数据安全建议最后说一个容易被忽略的问题。招聘 JD 虽然是公开信息但你粘贴进去的不只是 JD还可能有简历、代码、项目 README。这些内容里可能包含内部系统名称、未公开的业务逻辑、配置文件里的密钥、个人信息。所以在使用任意大模型服务之前一定要检查输入内容。不要把数据库密码、生产环境 IP、用户隐私数据放进提示词。如果你所在公司有代码保密要求更不应该把公司内部项目文件直接粘贴到第三方 AI 工具里。稳妥做法是只把项目里可公开的 README 片段或你自己重新整理过的项目说明放进上下文。用脱敏后的信息描述项目既能帮助生成项目追问又不会泄露敏感内容。如果你需要长期保存这些文件建议把面试准备目录加入 .gitignore避免不小心同步到公共代码仓库。这个动作很小但在求职阶段文件量变多之后能省掉很多不必要的麻烦。整体跑完之后我自己最深的感受是这个流程真正提升的不是“背题能力”而是把一份陌生岗位快速结构化、再对照自身项目找出差距的能力。它适合用在投递前做快速筛选也适合面试前一晚做集中预演。但你仍然需要花时间把生成的高频考点真正弄懂把项目细节亲自验证一遍。工具帮你节省的是查找和整理信息的时间而不是最后那个“站在面试官面前把问题答清楚”的环节。建议先把单条 JD 跑稳再决定要不要批量处理先把提示词模板固定下来再逐步加入代码关联和项目追问。这样这套 IDE 工作流才有可能在真实求职里起作用。