基于LLM的求职提升应用Role Accel技术咨询

首先得说，Role Accel这个定位真的很实用——AI模拟面试+技术测验+简历分析+职业导师，刚好戳中求职者的核心需求，React+Node.js的技术栈也很稳妥。针对你提出的三个技术问题，我结合自己做LLM工具的经验分享下思路：

1. 多AI功能场景下的提示词模板组织方案 #

我之前做过类似多模块的LLM应用，最实用的方式是按功能模块+场景维度分层管理：

• 目录结构分层：比如在后端代码里建一个prompt-templates文件夹，下面分mock-interviews、concept-arcade、resume-analyzer、ai-mentor四个子文件夹，每个子文件夹里再按具体场景放模板，比如mock-interviews下有initial-hiring-manager-prompt.hbs、follow-up-technical-question-prompt.yaml等。
• 复用通用片段：把所有功能都用到的通用提示词抽出来，比如「你是专业的 tech 领域从业者，回答要贴合行业实际」这种角色定义，放在common子文件夹里，用模板引擎（比如Handlebars、EJS，甚至自己写个简单的字符串替换工具）来拼接。
• 用结构化格式存储：别用纯文本存模板，用JSON或YAML，这样可以给模板加元数据（比如适用的LLM模型、token限制、触发条件），比如：

role: hiring-manager
content: |
  你现在是{{company}}的{{position}}招聘经理，正在进行技术面试。请根据求职者的简历{{resume_summary}}和目标岗位要求{{job_desc}}，提出针对性的技术问题，问题要循序渐进，每次只提一个问题。
metadata:
  model: gpt-4
  max_tokens: 500

• 版本控制：把模板纳入代码仓库，每次调整都留记录，方便回溯。如果后期需要非技术人员调整模板，可以做一个简单的后台配置界面，把模板存在数据库里，但初期用文件管理足够高效。

2. 长AI模拟对话的会话状态管理模式 #

长对话（比如mock面试）的核心是平衡上下文完整性和token成本，同时要能控制对话流程，我常用的模式有这几种：

• 结构化会话存储：不要只存纯文本对话历史，而是用结构化对象存储每一条消息，比如：

{
  sessionId: "xxx",
  userId: "xxx",
  messages: [
    {
      role: "system",
      content: "你是招聘经理...",
      metadata: { stage: "interview-start" }
    },
    {
      role: "user",
      content: "我之前做过React项目...",
      metadata: { skill: "react" }
    },
    // ...更多消息
  ],
  context: {
    targetPosition: "前端工程师",
    resumeSkills: ["React", "Node.js"],
    interviewStage: "technical-question"
  }
}

• 对话摘要压缩：当对话超过一定轮数（比如10轮），调用LLM生成当前对话的摘要，把摘要替换掉早期的冗余对话历史，只保留关键信息（比如求职者提到的核心技能、回答的亮点/不足），这样既能减少token消耗，又能让LLM保持上下文感知。
• 状态机控制流程：把mock面试分成不同阶段（自我介绍→技术提问→行为提问→总结反馈），用状态机来管理每个阶段的触发条件和提示词模板，比如当用户完成自我介绍后，自动切换到技术提问阶段，调用对应的模板生成问题，避免对话跑偏。
• 存储选型：短期会话（比如正在进行的面试）用Redis存储，读写快；长期的会话历史（比如用户的面试记录）存在PostgreSQL这类关系型数据库里，方便后续查询和分析。

3. 拆分功能为独立服务的时机判断 #

拆分服务不是为了跟风微服务，而是为了解决实际问题，当你遇到以下情况时，就可以考虑拆分：

• 资源竞争严重：比如mock面试的LLM调用耗时久、占资源，导致简历分析功能响应变慢，这时候把mock面试单独拆成一个服务，独立扩容资源。
• 团队规模扩大：如果后续有专门的团队负责AI导师模块，或者有不同的开发者维护不同功能，拆分服务可以让每个团队独立迭代，避免代码冲突。
• 技术栈差异需求：比如Concept Arcade可能用轻量开源LLM（比如Llama 2 7B）就能满足，而mock面试需要GPT-4这类大模型，拆分服务可以让每个模块独立选择适合的模型和部署方式。
• 流量差异巨大：如果某一个功能（比如mock面试）的流量占比超过70%，单独拆分可以针对性地扩容这个服务，降低整体成本。
• 合规或隔离需求：比如简历分析涉及用户敏感数据，需要单独做数据加密和权限控制，拆分服务可以更好地隔离风险。

如果当前你的用户量不大、团队只有几个人，建议先保持单体架构，这样开发和维护成本更低，等遇到上面的痛点再拆分也不迟。

最后，如果你还没做的话，可以考虑给每个功能加个prompt调试界面，方便你快速测试不同模板的效果，节省开发时间。

备注：内容来源于stack exchange，提问作者Nathan Johnson