AI简历定制工具

投一个岗位改一次简历，平均 40 分钟。我访谈了 10 多个研究生同学，发现大家都卡在同一个地方：不是不会写简历，而是针对不同 JD 调整措辞和筛选经历太耗时间——很多人干脆一份简历投所有，匹配度很低。

我做了一个工具：输入 JD 和母版简历，1 分钟内自动完成 JD 解析、经历匹配、内容改写、ATS 预评分，直接导出 PDF。10+ 人内测验证可用。

产品形态是一个 Web 应用（Next.js 全栈开发）。用户先录入一份包含所有经历的母版简历，之后每次投递只需粘贴 JD，AI 自动完成四件事：解析 JD 核心要求、从母版中筛选最匹配的经历、针对 JD 改写措辞、按模板格式输出并做 ATS 关键词评分。支持 JD 精准匹配和行业通用两种生成模式，可选多套简历模板，生成后直接导出 PDF。

后端是一个基于 LangGraph 的 5 节点 Agent 工作流：JD 解析 → 经历匹配 → 内容改写 → ATS 评分 → 导出 PDF。每个节点用 Zod Schema 做强类型约束，关键节点失败时自动重试。全链路接入 LangSmith 追踪，用于定位质量问题和驱动 Prompt 迭代。累计生成 100+ 份简历。

---

两个产品决策

1. 一个 Prompt 搞不定复杂任务

最直觉的方案是一个 Prompt 搞定——"请根据这个 JD 和简历，生成优化后的简历"。

实测发现成功率只有 60% 左右。失败的方式五花八门：有时漏掉 JD 的关键要求，有时选了不相关的经历，有时格式直接错乱。更麻烦的是，出错了不知道错在哪一步——输入一团东西，输出一团东西，中间是黑盒。

问题的本质是：简历定制不是一个任务，是四五个任务串在一起——理解 JD 要什么、选哪段经历、怎么改写措辞、怎么排版输出，每一步的逻辑完全不同。塞进一个 Prompt 是在要求模型同时做所有事，任何一步出错都会连锁崩塌。

我把它拆成了 5 个节点的工作流（基于 LangGraph）：JD 解析 → 经历匹配 → 内容改写 → ATS 评分 → 导出 PDF。每个节点有独立的输入输出 Schema，出错时能定位到具体环节，关键节点可以自动重试。

拆完之后成功率从 60% 到 95%+。但更重要的收获不是数字——是获得了迭代的抓手。哪个节点输出质量差，改哪个节点的策略就行，不用每次推倒重来。

2. AI 理解的"相关"和用户理解的不一样

工作流稳定之后，最大的问题变成了经历匹配准确率。

比如 JD 要求"有数据分析经验"，AI 选了一段偏运营的经历——因为那段里提到了"用户数据"这个词。从语义匹配的角度，AI 没错；但从求职者的角度，这段经历根本不是在说数据分析能力。

我接入了 LangSmith 做全链路追踪，逐条看每个节点的输出。分析 Bad Case 后发现：问题出在我只告诉模型"选最相关的经历"，但没有定义什么叫"相关"——模型在用自己的理解，而不是用 JD 的标准。

解决方案是在prompt中，把匹配逻辑从隐式变显式：

1. JD 解析环节增加一步：显式提取"核心技能要求"列表（不是模糊的关键词，而是结构化的能力标签）
2. 经历筛选环节要求模型输出映射表——每段经历匹配了哪些技能要求，匹配依据是什么
3. 基于映射表计算匹配分数，选得分最高的

改完之后匹配准确率明显提升。用户反馈"选的经历比我自己选的还准"——这其实说明一个问题：人在改简历时也经常凭直觉选经历，而不是系统性地对照 JD 要求。工具把这个过程变成了可追溯的逻辑链。

可观测性驱动迭代

AI 产品的迭代和传统产品不一样——改了一个 Prompt，你不知道是真的变好了还是刚好这几个 Case 跑对了。我接入 LangSmith 对每个节点做 Trace 追踪：输入输出、Token 消耗、延迟、输出质量。每轮 Prompt 修改前后都能对比同一批 Case 的表现，10+ 轮迭代都有数据支撑而不是凭感觉。

---

数据

---

收获

• AI 产品的可靠性不能靠 Prompt 堆砌，得靠架构设计。 单次调用像是让一个人同时做五件事，工作流是让五个人各做一件事——后者的失败模式可控得多。
• "选最相关的"不是需求定义，是偷懒。 不把"相关"拆成可执行的判断标准，就是在把产品决策丢给模型碰运气。