用 LangGraph 设计可修复的 AI 面试工作流

1. 先区分确定性逻辑与模型推理#

上传 PDF 后，系统先在本地完成文本提取、空白清理与质量校验。只有通过基本检查的纯文本才会进入模型调用。这条边界带来三个好处：

• 文件解析失败可以给出明确错误，而不是让模型面对乱码；
• PDF 页面图像不会无必要地发送给模型；
• 清洗规则可以通过普通代码测试，不依赖模型稳定性。

模型更适合承担简历归纳、面试策略、问题生成和答案评价。数据库则只负责用户、简历、面试集、收藏和练习记录等业务事实。工作流状态不代替持久化，持久化也不侵入每个节点的推理细节。

2. 把中间状态写进类型#

工作流状态包含原始文本、清洗文本、简历摘要、JD 上下文、面试策略、不同难度的问题列表、错误信息和最终结果。每次模型调用都返回结构化对象，再由 Pydantic 校验后进入下游节点。

这样做的意义不只是“防止 JSON 格式错误”。类型把节点间契约写清楚了：生成节点不必知道数据库表结构，修复节点只接收问题列表与缺口信息，最终节点负责把内部状态转换成 API 响应。某个节点替换模型或 Prompt 时，不会让整条链路一起变化。

3. 生成之后必须有修复路径#

一次生成常见的问题包括：题目语义重复、难度分布不符、答案视角不统一、题目脱离简历证据。工作流在初次生成后执行确定性的归一化与去重，再计算每个难度的缺口。缺少的部分进入修复节点补齐，而不是把全部题目推倒重来。

单题重生成也使用独立工作流：先读取原问题、简历摘要、JD 和同组题目，生成候选题，再检查它与现有题目的重复度。如果候选结果不合法，系统保留旧题或返回可解释错误。这比“点一下按钮，再赌一次模型输出”更接近可靠产品。

4. 评价是另一条工作流#

用户练习回答时，输入不是只有“问题 + 用户答案”。评价节点还需要参考答案、简历背景和评分维度。输出包含结构化评分、做得好的部分、缺失信息和一个改进版本。

我没有把评价接在生成流程后面，而是设计成单独的图。原因是两条流程的触发时机、状态、成本和失败恢复完全不同。生成关注题目集合的完整性，评价关注单个回答的证据与表达。拆开后，两者都更容易维护。

5. 流式进度应该对应真实节点#

长工作流如果只显示一个转圈动画，用户不知道系统是卡住还是仍在处理。项目后续为生成过程加入阶段进度：文本提取、简历分析、策略规划、不同难度生成、修复与落库。前端显示的是实际节点推进，而不是伪造的百分比。

这也改善了排障：当请求在“困难题生成”阶段失败，日志和 UI 都能指向同一节点，不必从一个巨大请求里猜测问题发生在哪里。

6. 我的结论#

LangGraph 的价值不是把函数画成图，而是把状态、边界、条件分支和恢复路径变成系统的一等公民。对于包含多个模型步骤、需要校验修复、又必须接入真实业务数据的 AI 应用，显式工作流比线性 Prompt 链更容易解释、测试和持续演进。