简介基于LLM大语言模型的智能面试系统演示工程定位为课程设计与毕业设计参考项目适合计算机相关专业学生用于学习AI应用开发或作为毕设基础框架。项目采用Python编写使用Streamlit搭建可视化交互界面通过OpenAI接口实现智能问答面试流程核心模块包括客户端封装、工具函数、页面配置等代码经测试运行稳定。压缩包共14个文件大小仅346KB主要由Python源码、配置文件、Docker部署文件、CSV数据样例、说明文档和界面截图构成配套requirements.txt可直接安装依赖并针对Mac M1环境提供专属安装命令。当前已有153人学习下载该工程为毕业答辩评审平均96分的高分作品实用价值与稳定性获得验证。下载可获得完整可运行的源码工程及项目使用说明按照README配置OPENAI_API_KEY环境变量即可启动适合答辩演示、课设验收以及在此基础上二次开发扩展。1. LLM智能面试系统一套Prompt驱动的多轮对话工程拿到“基于LLM的智能面试系统 python源代码项目使用说明.zip”这个包时多数人第一反应是把它当成一个能直接跑出完整网页的产品。拆开看会发现它真正值钱的部分并不在界面而在“面试官Agent”怎么被Prompt组织起来谁决定提问顺序、怎么把候选人回答拼回上下文、用什么结构让大模型稳定打分。这套东西说到底是多轮对话工程LLM只是被调用的推理核心。适合谁读拿到这个zip准备复现、改造或换模型接入的人。下面我从源码结构开始拆再走通启动、核心逻辑、参数调整和最后能落地的校验手段。2. 智能面试系统的源码结构目录、模型接入层与数据流向2.1 从zip到工程先用目录树把项目读薄解压后先看整体布局常见做法是先按“入口、业务逻辑、LLM接入、工具配置”四类归档。典型结构长这样llm_interview_system/ ├── main.py # Web服务入口FastAPI/Flask ├── requirements.txt # 依赖清单 ├── .env.example # 环境变量模板 ├── app/ │ ├── agents/ │ │ ├── interviewer.py # 面试官Agent提问与评估 │ │ └── prompts.py # 所有Prompt模板 │ ├── api/ │ │ └── routes.py # 面试会话路由 │ ├── core/ │ │ ├── llm_client.py # LLM统一调用封装 │ │ └── session.py # 会话状态管理 │ ├── models/ │ │ └── schemas.py # 请求/响应数据结构 │ └── utils/ │ └── logger.py # 日志与调试辅助 └── docs/ └── 使用说明.md先扣住两个文件看llm_client.py决定了模型好不好换interviewer.py决定了面试像不像真人。界面路由反而是最后才需要关心的。使用说明文档里一般会写清Python版本、依赖安装和启动命令但目录结构往往讲得很少所以第一步先对照这份树形图确认手上的包是否完整——缺了prompts.py这类文件后面所有行为都会变怪。2.2 模型接入层为什么这层代码决定了你换不换得动理想的项目会把模型调用收敛成一个客户端类业务代码不直接拼OpenAI请求体而是调用chat()这样的方法。这样后续换模型厂商、换本地部署只动一个文件。2.2.1 一个最小化的LLM客户端封装# app/core/llm_client.py import os from openai import OpenAI class LLMClient: 统一模型访问入口支持OpenAI兼容接口 def __init__(self, model: str, base_url: str None): self.model model self.client OpenAI( api_keyos.getenv(LLM_API_KEY), base_urlbase_url or os.getenv(LLM_BASE_URL), ) def chat(self, messages: list, temperature: float 0.3) - str: resp self.client.chat.completions.create( modelself.model, messagesmessages, temperaturetemperature, ) return resp.choices[0].message.content注意base_url参数它让同一套代码既走云端API也能指向本地模型网关这是更换模型时成本最低的做法。LLM_API_KEY和LLM_BASE_URL从.env读不进代码仓库。面试场景对响应速度敏感单轮调用建议设置超时避免候选人等太久。2.3 顺着一次面试请求追数据流一条典型的面试请求路径是前端提交“开始面试”到/api/interview/start路由层创建新的会话ID并初始化状态Agent拿到岗位要求后生成第一道题候选人回答提交到/api/interview/answerAgent把历史消息拼好调用LLMClient.chat()模型返回的文本被解析成两道内容——对当前回答的简短回应、下一道追问最后连同会话ID一起返回给前端。数据流中最重要的中转点是session.py它负责把所有对话历史按顺序拼进messages列表。一旦这个模块设计得不好Agent就会“失忆”。3. 本地跑通智能面试系统Python环境、依赖安装与最小启动3.1 环境准备Python版本与虚拟环境这类项目对Python版本通常在3.9到3.11之间更稳。Python 3.12对部分依赖的C扩展兼容还不够好尤其是pydantic、tokenizers这类编译型包。先用命令确认当前版本python3 --version若版本不符合建议用pyenv管理多版本而不是直接改系统默认。然后为项目单独创建虚拟环境3.1.1 虚拟环境的创建与激活cd llm_interview_system python3 -m venv .venv source .venv/bin/activate # Windows下用 .venv\Scripts\activate激活后命令行前缀会变成(.venv)后续所有pip操作都发生在隔离环境里避免污染全局Python。这个步骤看着基础但大多数“装完依赖跑不起来”的问题都出在没隔离环境导致的版本冲突上。3.2 依赖解析requirements.txt里真正要紧的包使用说明里通常要求执行pip install -r requirements.txt。但建议先打开这份文件过一眼按职责分成三类Web框架、SDK、工具库。以下是一个常见组合的拆解包名用途安装后建议验证fastapiWeb路由与接口层pip show fastapiuvicornASGI服务器负责启动启动时指定--reloadopenai官方SDK走OpenAI兼容接口打印client.base_urlpydantic参数校验和数据结构定义配合FastAPI自动校验请求python-dotenv从.env加载环境变量确认配置已加载安装依赖时若遇到编译报错优先看是不是pydantic-core的wheel没匹配当前Python版本解决办法是升级pip到最新版再试pip install --upgrade pip pip install -r requirements.txt3.3 配置与启动从.env到uvicorn项目里一般会有.env.example复制一份为.env后填入模型服务地址和密钥cp .env.example .env # 编辑 .env重点确认 # LLM_API_KEYsk-xxx # LLM_BASE_URLhttps://api.openai.com/v1 # LLM_MODELgpt-4o-mini # SYSTEM_PROMPT_TEMPLATEprompts/interviewer.md启动命令按入口文件决定。如果是main.py常见的是uvicorn main:app --host 0.0.0.0 --port 8000 --reload--reload用于开发阶段改代码自动重启0.0.0.0允许局域网访问方便在手机上测试前端联动。启动成功后访问http://localhost:8000/docs能看到FastAPI自动生成的接口文档这是验证服务是否正常的第一个信号。3.4 启动失败的常见信号与排查顺序启动阶段最常见的三类问题端口被占用、环境变量没加载、依赖缺失。按这个顺序排查——先看端口冲突报错address already in use换端口或用lsof -i:8000查占用进程再看.env有没有被load_dotenv()正确读取可以在入口文件临时加一行print(os.getenv(LLM_MODEL))验证最后确认报错信息里的模块名与requirements.txt的包名一致大小写和连字符都可能导致异常。若启动成功但调用模型时超时则优先检查LLM_BASE_URL是否能正常联通用curl直接测一次接口。4. 智能面试系统的核心逻辑面试Agent的状态机与提问策略4.1 面试对话为什么需要状态机普通聊天机器人不关心话题边界但面试系统必须知道“现在面到哪个环节”。把面试状态建模成有限的几态能避免候选人答非所问时Agent也跟着跑偏。状态设计上我的做法是INIT - ASKING - EVALUATING - NEXT_QUESTION - FINISHED其中EVALUATING是一个隐藏状态大模型返回的文本先进入评估器判“这题答得怎么样”再决定是追问细节还是换下一题。把评估从提问中拆出来Prompt会更短、更聚焦模型输出也更稳定。4.2 从session到messages多轮上下文怎么组装面试Agent的核心能力是“记得你两轮前说过什么”。实现上依靠把整个对话历史塞进messages# app/agents/interviewer.py def build_messages(self, session, user_answer: str) - list: messages [ {role: system, content: session.system_prompt}, ] for turn in session.history: messages.append({role: user, content: turn[question]}) messages.append({role: assistant, content: turn[answer]}) messages.append({role: user, content: user_answer}) return messages这段代码的关键是顺序system指令在前历史轮次按时间排列当前回答放最后。assistant轮扮演的是面试官它上一条“追问”被当作历史回复这样模型才能理解自己的提问风格并保持连贯。注意history里只存文本不存内部状态结构避免上下文被无关内容污染。4.3 提问策略从宽到严的难度曲线好的面试官不会一上来就考细节。源码里通常通过两段Prompt实现一段固定system定义人设一段动态拼接候选人背景和岗位要求。常见的设计是每三个问题为一组依次递进开放性引入请先介绍一下你在XX项目中的角色。技术深挖你提到使用了XX方案相比YY方案它的取舍是什么场景应变如果在线服务流量突增10倍你会怎么定位瓶颈4.3.1 动态难度在Prompt里的两种落法落法一把“当前题号”直接拼进Prompt让模型自行判断难度阶梯落法二在代码里维护题目队列每次从不同难度池中取题。第一种改动小但控制弱第二种可控性强但需要题库。我个人倾向折中前两轮自由提问第三轮起让模型基于候选人前面的回答做“针对性追问”追问质量往往比题目本身更能体现面试系统的水平。def build_question_prompt(self, session, candidate_info: dict) - str: prompt session.system_prompt prompt f\n候选人背景{candidate_info[background]} prompt f\n当前已问 {session.question_count} 题。 if session.question_count 2: prompt \n现在请根据候选人的上一回答提出一个深入的追问。 return prompt这段体现了question_count这个状态值的作用——它不只用于计数更是Prompt决策的输入。建议在session里额外记录“上一题内容”和“回答摘要”追问时才不会跑题。5. 智能面试系统的Prompt工程结构化提问、评估与模型参数5.1 面试官Prompt模板怎么参数化面试系统与普通聊天机器人最大的差异在于人设固定、目标明确、输出需要结构化。因此Prompt模板建议拆成“系统人设 动态变量 输出格式”三块。系统人设部分要明确约束模型的行为边界例如“你是一名资深后端工程师面试官只围绕岗位要求提问不闲聊”。动态变量通过format()或jinja2注入# app/agents/prompts.py INTERVIEWER_SYSTEM_PROMPT 你是{position}岗位的面试官要求 - 拥有{experience}年以上相关经验 - 语言简洁一次只问一个问题 - 当候选人回答模糊时进行追问并要求举例 - 每轮根据{level}调整提问深度 - 不得评价候选人性格只评估技术表现 .strip() def render_system_prompt(position: str, experience: int, level: str): return INTERVIEWER_SYSTEM_PROMPT.format( positionposition, experienceexperience, levellevel )这里把position、experience、level抽成参数目的是让同一套Agent能服务不同岗位的面试。改造时只动数据不动代码。注意一个常见坑模板里不要用{}包裹其他内容否则format()会报KeyError。5.2 评估模块把打分做成模型能输出的JSON面试系统不能只提问不评价。评估Prompt的目标是让模型输出结构化结果。我的常用设计是要求模型返回JSON并给出明确字段约束EVALUATION_PROMPT 你是面试评分系统。请根据本轮对话对候选人回答进行评分。 维度技术深度(0-10)、逻辑清晰度(0-10)、表达简洁度(0-10)、匹配度(0-10)。 只输出如下JSON结构不要输出其他内容 {scores: {depth: 0, logic: 0, concision: 0, match: 0}, comment: 简短评价, suggested_next: 追问内容或进入下一题} 解析时要注意大模型偶尔会输出Markdown代码块包裹的JSON所以解析逻辑要做两次兜底import json, re def parse_evaluation(raw: str) - dict: text raw.strip() text re.sub(r^json|^|$, , text).strip() try: return json.loads(text) except json.JSONDecodeError: start, end text.find({), text.rfind(}) return json.loads(text[start: end1])这段代码先剥掉代码块标记再尝试全量解析失败时截取首尾花括号之间的内容重试能覆盖绝大多数模型输出偏差。评估结果建议以数值形式落库不保存原始大段评语后续做统计分析更方便。5.3 模型参数设定面试场景里温度和长度怎么给同一个模型在不同参数下表现差异很大。面试场景追求稳定、客观、低随机参数设定上参考以下策略参数取值范围说明temperature0.2~0.4越低回答越稳定0.7以上容易发散top_p0.5~0.7与temperature配合降低采样多样性max_tokens600~1000单题回答上限防止长篇空谈presence_penalty0~0.3轻微鼓励新词汇避免车轱辘话frequency_penalty0~0.3抑制重复句式注意max_tokens不是“思考上限”而是输出截断阈值。评估轮次里如果输出JSON包含长comment设600以下可能被截断导致解析失败建议评估调用单独放宽到1000。提问轮次与评估轮次建议使用两套参数做法是在LLMClient.chat()里显式传入而不是全局写死。5.4 换模型网关从OpenAI兼容接口到本地部署如果不想依赖云端服务常见做法是切换到本地推理网关。很多开源推理服务提供兼容接口代码上只需要改环境变量LLM_BASE_URLhttp://localhost:11434/v1 LLM_API_KEYollama LLM_MODELqwen2.5:7b原理是兼容层把标准请求翻译给本地模型业务代码完全无感。切换后要重点验证三件事响应延迟是否在可接受范围长对话下上下文是否被正确截断JSON输出是否稳定——小参数量模型更容易输出多余内容评估解析兜底逻辑这时就派上用场了。6. 从demo到可用的记录与校验技巧6.1 面试记录落盘与断点恢复面试系统跑通后第一件该补的事是给会话加持久化。用SQLite成本最低建一张interview_sessions表存会话ID、状态、开始时间和消息历史JSON序列化。断点恢复的思路是session_id对外暴露候选人中途刷新页面后前端携带session_id请求/api/interview/resume后端读出消息历史重新初始化Agent。这比把上下文存在内存里可靠得多。实现时给Interviewer加一个load_session(session_id)方法内部把数据库里的历史消息填回session.history即可。6.2 RAG增强的边界什么时候该给面试官加知识库给面试系统配一个岗位相关的知识库是“能够问得更专业”的关键手段。但RAG不是万能的——当候选人的项目经历非常细节的时候检索到的岗位知识反而会干扰追问。我的使用建议是只把“公司技术栈、面试红线、内部架构约定”三类内容向量化提问时让Agent先判断候选人的回答是否涉及这三类再决定是否注入检索结果。这样既不会每轮都做昂贵的向量检索也避免无关知识污染判断。6.3 校验模型是否遵守约束的一条指令最后给一个判断Prompt是否被模型遵守的简单方法在system提示词末尾加一句“你在每轮回复开头用[STATE]标注当前状态若未通过校验返回[INVALID]”。然后在代码中检查输出是否以状态标记开头。若经常出现[INVALID]说明Prompt约束力不足或模型能力不够。用这个开关你可以快速对比不同模型、不同温度下的行为差异——这比反复人工阅读对话日志高效得多。本文还有配套的精品资源点击获取 
长河君 · 2026/9/11 12:07:05 · 阅读 1.2k 基于LLM的智能面试系统：多轮对话与Prompt工程实战解析
简介基于LLM大语言模型的智能面试系统演示工程定位为课程设计与毕业设计参考项目适合计算机相关专业学生用于学习AI应用开发或作为毕设基础框架。项目采用Python编写使用Streamlit搭建可视化交互界面通过OpenAI接口实现智能问答面试流程核心模块包括客户端封装、工具函数、页面配置等代码经测试运行稳定。压缩包共14个文件大小仅346KB主要由Python源码、配置文件、Docker部署文件、CSV数据样例、说明文档和界面截图构成配套requirements.txt可直接安装依赖并针对Mac M1环境提供专属安装命令。当前已有153人学习下载该工程为毕业答辩评审平均96分的高分作品实用价值与稳定性获得验证。下载可获得完整可运行的源码工程及项目使用说明按照README配置OPENAI_API_KEY环境变量即可启动适合答辩演示、课设验收以及在此基础上二次开发扩展。1. LLM智能面试系统一套Prompt驱动的多轮对话工程拿到“基于LLM的智能面试系统 python源代码项目使用说明.zip”这个包时多数人第一反应是把它当成一个能直接跑出完整网页的产品。拆开看会发现它真正值钱的部分并不在界面而在“面试官Agent”怎么被Prompt组织起来谁决定提问顺序、怎么把候选人回答拼回上下文、用什么结构让大模型稳定打分。这套东西说到底是多轮对话工程LLM只是被调用的推理核心。适合谁读拿到这个zip准备复现、改造或换模型接入的人。下面我从源码结构开始拆再走通启动、核心逻辑、参数调整和最后能落地的校验手段。2. 智能面试系统的源码结构目录、模型接入层与数据流向2.1 从zip到工程先用目录树把项目读薄解压后先看整体布局常见做法是先按“入口、业务逻辑、LLM接入、工具配置”四类归档。典型结构长这样llm_interview_system/ ├── main.py # Web服务入口FastAPI/Flask ├── requirements.txt # 依赖清单 ├── .env.example # 环境变量模板 ├── app/ │ ├── agents/ │ │ ├── interviewer.py # 面试官Agent提问与评估 │ │ └── prompts.py # 所有Prompt模板 │ ├── api/ │ │ └── routes.py # 面试会话路由 │ ├── core/ │ │ ├── llm_client.py # LLM统一调用封装 │ │ └── session.py # 会话状态管理 │ ├── models/ │ │ └── schemas.py # 请求/响应数据结构 │ └── utils/ │ └── logger.py # 日志与调试辅助 └── docs/ └── 使用说明.md先扣住两个文件看llm_client.py决定了模型好不好换interviewer.py决定了面试像不像真人。界面路由反而是最后才需要关心的。使用说明文档里一般会写清Python版本、依赖安装和启动命令但目录结构往往讲得很少所以第一步先对照这份树形图确认手上的包是否完整——缺了prompts.py这类文件后面所有行为都会变怪。2.2 模型接入层为什么这层代码决定了你换不换得动理想的项目会把模型调用收敛成一个客户端类业务代码不直接拼OpenAI请求体而是调用chat()这样的方法。这样后续换模型厂商、换本地部署只动一个文件。2.2.1 一个最小化的LLM客户端封装# app/core/llm_client.py import os from openai import OpenAI class LLMClient: 统一模型访问入口支持OpenAI兼容接口 def __init__(self, model: str, base_url: str None): self.model model self.client OpenAI( api_keyos.getenv(LLM_API_KEY), base_urlbase_url or os.getenv(LLM_BASE_URL), ) def chat(self, messages: list, temperature: float 0.3) - str: resp self.client.chat.completions.create( modelself.model, messagesmessages, temperaturetemperature, ) return resp.choices[0].message.content注意base_url参数它让同一套代码既走云端API也能指向本地模型网关这是更换模型时成本最低的做法。LLM_API_KEY和LLM_BASE_URL从.env读不进代码仓库。面试场景对响应速度敏感单轮调用建议设置超时避免候选人等太久。2.3 顺着一次面试请求追数据流一条典型的面试请求路径是前端提交“开始面试”到/api/interview/start路由层创建新的会话ID并初始化状态Agent拿到岗位要求后生成第一道题候选人回答提交到/api/interview/answerAgent把历史消息拼好调用LLMClient.chat()模型返回的文本被解析成两道内容——对当前回答的简短回应、下一道追问最后连同会话ID一起返回给前端。数据流中最重要的中转点是session.py它负责把所有对话历史按顺序拼进messages列表。一旦这个模块设计得不好Agent就会“失忆”。3. 本地跑通智能面试系统Python环境、依赖安装与最小启动3.1 环境准备Python版本与虚拟环境这类项目对Python版本通常在3.9到3.11之间更稳。Python 3.12对部分依赖的C扩展兼容还不够好尤其是pydantic、tokenizers这类编译型包。先用命令确认当前版本python3 --version若版本不符合建议用pyenv管理多版本而不是直接改系统默认。然后为项目单独创建虚拟环境3.1.1 虚拟环境的创建与激活cd llm_interview_system python3 -m venv .venv source .venv/bin/activate # Windows下用 .venv\Scripts\activate激活后命令行前缀会变成(.venv)后续所有pip操作都发生在隔离环境里避免污染全局Python。这个步骤看着基础但大多数“装完依赖跑不起来”的问题都出在没隔离环境导致的版本冲突上。3.2 依赖解析requirements.txt里真正要紧的包使用说明里通常要求执行pip install -r requirements.txt。但建议先打开这份文件过一眼按职责分成三类Web框架、SDK、工具库。以下是一个常见组合的拆解包名用途安装后建议验证fastapiWeb路由与接口层pip show fastapiuvicornASGI服务器负责启动启动时指定--reloadopenai官方SDK走OpenAI兼容接口打印client.base_urlpydantic参数校验和数据结构定义配合FastAPI自动校验请求python-dotenv从.env加载环境变量确认配置已加载安装依赖时若遇到编译报错优先看是不是pydantic-core的wheel没匹配当前Python版本解决办法是升级pip到最新版再试pip install --upgrade pip pip install -r requirements.txt3.3 配置与启动从.env到uvicorn项目里一般会有.env.example复制一份为.env后填入模型服务地址和密钥cp .env.example .env # 编辑 .env重点确认 # LLM_API_KEYsk-xxx # LLM_BASE_URLhttps://api.openai.com/v1 # LLM_MODELgpt-4o-mini # SYSTEM_PROMPT_TEMPLATEprompts/interviewer.md启动命令按入口文件决定。如果是main.py常见的是uvicorn main:app --host 0.0.0.0 --port 8000 --reload--reload用于开发阶段改代码自动重启0.0.0.0允许局域网访问方便在手机上测试前端联动。启动成功后访问http://localhost:8000/docs能看到FastAPI自动生成的接口文档这是验证服务是否正常的第一个信号。3.4 启动失败的常见信号与排查顺序启动阶段最常见的三类问题端口被占用、环境变量没加载、依赖缺失。按这个顺序排查——先看端口冲突报错address already in use换端口或用lsof -i:8000查占用进程再看.env有没有被load_dotenv()正确读取可以在入口文件临时加一行print(os.getenv(LLM_MODEL))验证最后确认报错信息里的模块名与requirements.txt的包名一致大小写和连字符都可能导致异常。若启动成功但调用模型时超时则优先检查LLM_BASE_URL是否能正常联通用curl直接测一次接口。4. 智能面试系统的核心逻辑面试Agent的状态机与提问策略4.1 面试对话为什么需要状态机普通聊天机器人不关心话题边界但面试系统必须知道“现在面到哪个环节”。把面试状态建模成有限的几态能避免候选人答非所问时Agent也跟着跑偏。状态设计上我的做法是INIT - ASKING - EVALUATING - NEXT_QUESTION - FINISHED其中EVALUATING是一个隐藏状态大模型返回的文本先进入评估器判“这题答得怎么样”再决定是追问细节还是换下一题。把评估从提问中拆出来Prompt会更短、更聚焦模型输出也更稳定。4.2 从session到messages多轮上下文怎么组装面试Agent的核心能力是“记得你两轮前说过什么”。实现上依靠把整个对话历史塞进messages# app/agents/interviewer.py def build_messages(self, session, user_answer: str) - list: messages [ {role: system, content: session.system_prompt}, ] for turn in session.history: messages.append({role: user, content: turn[question]}) messages.append({role: assistant, content: turn[answer]}) messages.append({role: user, content: user_answer}) return messages这段代码的关键是顺序system指令在前历史轮次按时间排列当前回答放最后。assistant轮扮演的是面试官它上一条“追问”被当作历史回复这样模型才能理解自己的提问风格并保持连贯。注意history里只存文本不存内部状态结构避免上下文被无关内容污染。4.3 提问策略从宽到严的难度曲线好的面试官不会一上来就考细节。源码里通常通过两段Prompt实现一段固定system定义人设一段动态拼接候选人背景和岗位要求。常见的设计是每三个问题为一组依次递进开放性引入请先介绍一下你在XX项目中的角色。技术深挖你提到使用了XX方案相比YY方案它的取舍是什么场景应变如果在线服务流量突增10倍你会怎么定位瓶颈4.3.1 动态难度在Prompt里的两种落法落法一把“当前题号”直接拼进Prompt让模型自行判断难度阶梯落法二在代码里维护题目队列每次从不同难度池中取题。第一种改动小但控制弱第二种可控性强但需要题库。我个人倾向折中前两轮自由提问第三轮起让模型基于候选人前面的回答做“针对性追问”追问质量往往比题目本身更能体现面试系统的水平。def build_question_prompt(self, session, candidate_info: dict) - str: prompt session.system_prompt prompt f\n候选人背景{candidate_info[background]} prompt f\n当前已问 {session.question_count} 题。 if session.question_count 2: prompt \n现在请根据候选人的上一回答提出一个深入的追问。 return prompt这段体现了question_count这个状态值的作用——它不只用于计数更是Prompt决策的输入。建议在session里额外记录“上一题内容”和“回答摘要”追问时才不会跑题。5. 智能面试系统的Prompt工程结构化提问、评估与模型参数5.1 面试官Prompt模板怎么参数化面试系统与普通聊天机器人最大的差异在于人设固定、目标明确、输出需要结构化。因此Prompt模板建议拆成“系统人设 动态变量 输出格式”三块。系统人设部分要明确约束模型的行为边界例如“你是一名资深后端工程师面试官只围绕岗位要求提问不闲聊”。动态变量通过format()或jinja2注入# app/agents/prompts.py INTERVIEWER_SYSTEM_PROMPT 你是{position}岗位的面试官要求 - 拥有{experience}年以上相关经验 - 语言简洁一次只问一个问题 - 当候选人回答模糊时进行追问并要求举例 - 每轮根据{level}调整提问深度 - 不得评价候选人性格只评估技术表现 .strip() def render_system_prompt(position: str, experience: int, level: str): return INTERVIEWER_SYSTEM_PROMPT.format( positionposition, experienceexperience, levellevel )这里把position、experience、level抽成参数目的是让同一套Agent能服务不同岗位的面试。改造时只动数据不动代码。注意一个常见坑模板里不要用{}包裹其他内容否则format()会报KeyError。5.2 评估模块把打分做成模型能输出的JSON面试系统不能只提问不评价。评估Prompt的目标是让模型输出结构化结果。我的常用设计是要求模型返回JSON并给出明确字段约束EVALUATION_PROMPT 你是面试评分系统。请根据本轮对话对候选人回答进行评分。 维度技术深度(0-10)、逻辑清晰度(0-10)、表达简洁度(0-10)、匹配度(0-10)。 只输出如下JSON结构不要输出其他内容 {scores: {depth: 0, logic: 0, concision: 0, match: 0}, comment: 简短评价, suggested_next: 追问内容或进入下一题} 解析时要注意大模型偶尔会输出Markdown代码块包裹的JSON所以解析逻辑要做两次兜底import json, re def parse_evaluation(raw: str) - dict: text raw.strip() text re.sub(r^json|^|$, , text).strip() try: return json.loads(text) except json.JSONDecodeError: start, end text.find({), text.rfind(}) return json.loads(text[start: end1])这段代码先剥掉代码块标记再尝试全量解析失败时截取首尾花括号之间的内容重试能覆盖绝大多数模型输出偏差。评估结果建议以数值形式落库不保存原始大段评语后续做统计分析更方便。5.3 模型参数设定面试场景里温度和长度怎么给同一个模型在不同参数下表现差异很大。面试场景追求稳定、客观、低随机参数设定上参考以下策略参数取值范围说明temperature0.2~0.4越低回答越稳定0.7以上容易发散top_p0.5~0.7与temperature配合降低采样多样性max_tokens600~1000单题回答上限防止长篇空谈presence_penalty0~0.3轻微鼓励新词汇避免车轱辘话frequency_penalty0~0.3抑制重复句式注意max_tokens不是“思考上限”而是输出截断阈值。评估轮次里如果输出JSON包含长comment设600以下可能被截断导致解析失败建议评估调用单独放宽到1000。提问轮次与评估轮次建议使用两套参数做法是在LLMClient.chat()里显式传入而不是全局写死。5.4 换模型网关从OpenAI兼容接口到本地部署如果不想依赖云端服务常见做法是切换到本地推理网关。很多开源推理服务提供兼容接口代码上只需要改环境变量LLM_BASE_URLhttp://localhost:11434/v1 LLM_API_KEYollama LLM_MODELqwen2.5:7b原理是兼容层把标准请求翻译给本地模型业务代码完全无感。切换后要重点验证三件事响应延迟是否在可接受范围长对话下上下文是否被正确截断JSON输出是否稳定——小参数量模型更容易输出多余内容评估解析兜底逻辑这时就派上用场了。6. 从demo到可用的记录与校验技巧6.1 面试记录落盘与断点恢复面试系统跑通后第一件该补的事是给会话加持久化。用SQLite成本最低建一张interview_sessions表存会话ID、状态、开始时间和消息历史JSON序列化。断点恢复的思路是session_id对外暴露候选人中途刷新页面后前端携带session_id请求/api/interview/resume后端读出消息历史重新初始化Agent。这比把上下文存在内存里可靠得多。实现时给Interviewer加一个load_session(session_id)方法内部把数据库里的历史消息填回session.history即可。6.2 RAG增强的边界什么时候该给面试官加知识库给面试系统配一个岗位相关的知识库是“能够问得更专业”的关键手段。但RAG不是万能的——当候选人的项目经历非常细节的时候检索到的岗位知识反而会干扰追问。我的使用建议是只把“公司技术栈、面试红线、内部架构约定”三类内容向量化提问时让Agent先判断候选人的回答是否涉及这三类再决定是否注入检索结果。这样既不会每轮都做昂贵的向量检索也避免无关知识污染判断。6.3 校验模型是否遵守约束的一条指令最后给一个判断Prompt是否被模型遵守的简单方法在system提示词末尾加一句“你在每轮回复开头用[STATE]标注当前状态若未通过校验返回[INVALID]”。然后在代码中检查输出是否以状态标记开头。若经常出现[INVALID]说明Prompt约束力不足或模型能力不够。用这个开关你可以快速对比不同模型、不同温度下的行为差异——这比反复人工阅读对话日志高效得多。本文还有配套的精品资源点击获取