能力对标：简历该突出什么

先记住这一页的一句话：简历不是经历流水账，而是证据链——把JD 清单里的每一个要求，翻译成一条"我能证明给你看"的证据。 大模型岗尤其如此：市场被"会用 API"的简历淹没了，能写清楚技术难点、取舍与量化结果的简历，寥寥无几。

本页的项目示例均为通用模板

文中所有项目写法均为示例模板，用于展示结构与写法，不代表任何真实个人经历，也不建议原样照抄——照抄示例项目在深挖一轮就会露馅。

一、简历的本质：证据链

面试官读一份简历的时间以分钟计，真正在做的事只有一件：寻找你符合 JD 的证据。简历写作的全部方法，可以压缩成一条链：

JD 要求  →  能力项  →  证据
"熟悉 RAG" → RAG 能力 → "搭建企业知识库问答系统，chunk 策略优化后召回率 68%→82%"

• JD 要求：来自目标岗位 JD（见JD 清单）；
• 能力项：你宣称具备的能力；
• 证据：项目/经历中能支撑该能力的具体事实，最好带数字。

三段里证据是唯一的硬通货。没有证据的"精通 XX"，在面试官眼里等于没写，甚至是负分（准备深挖时答不出来）。

一条面试官铁律

简历里出现的每一个技术名词，都视为你可以被追问 10 分钟的对象。 写之前问自己：这个名词我能讲出原理、代价和一个真实例子吗？不能，就删掉或降级为"了解"。

二、大模型岗简历的黄金结构

1. 项目四段式：背景 → 难点 → 方案 → 量化结果

这是大模型岗项目最有效的结构，四个部分各有使命：

部分	写什么	面试官想听到
项目背景	业务场景、要解决什么问题、为什么值得做	你理解问题，而不是只写代码
技术难点	该项目真正难的地方（数据、效果、成本、稳定性）	你识别过真正的困难
方案与取舍	你选了什么方案、为什么、对比过哪些替代	你有判断力，有对比证据
量化结果	模型指标 + 业务指标 + 资源成本	你能证明效果，数字经得起追问

2. 讲透一个项目，胜过罗列五个

大模型岗面试几乎必然有"项目深挖"环节：围绕一个项目连续追问 20–40 分钟。与其写五个浅尝辄止的项目，不如把两三个项目写到能扛住整场深挖。 判断标准：这个项目你能从头到尾讲出——为什么选这个模型/方案、数据怎么来的、遇到什么坑、怎么排查的、量化结果怎么算的。

三、"做过什么" vs "能讲多深"

大模型领域"做过什么"贬值极快（开源教程让每个人都"做过"），"能讲多深"才是壁垒。三类典型：

层级	简历写法	面试表现	评价
用过	"使用 GPT-4 完成 XX 功能"	只能答"调了 API、提示词写了几版"	撞上人人都会，无区分度
做过	"搭建 RAG 问答系统，召回率 75%"	能讲流程、能答细节问题	合格线，但同质化
讲透	"对比 BM25/向量/混合检索，选定混合+重排；识别出 chunk 边界问题导致召回失败，改为按章节切分，召回率 68%→82%，错误率降 31%"	能讲取舍、能讲坑、数字经得起追问	有壁垒，进终面

如何从"做过"到"讲透"：每个项目补上三样东西——对比实验（你选了 A 方案，B 方案为什么不行）、失败经历（哪个方案翻车了，怎么发现的）、量化结果（效果、成本、延迟各一个数）。

四、五类项目怎么写

以下五类是知识点拆解里最常见的项目类型。每类给「面试官会怎么问 + 好写法示例」。

1. 微调类项目

面试官会问：为什么用 LoRA 不用全参微调？秩 r 和 α 怎么定的？训练数据哪来的、多少条？过拟合没有？微调后变笨了怎么发现和解决？怎么证明微调有效？

普通写法：使用 LoRA 微调 Llama-3-8B 提升客服意图识别准确率至 90%。

好写法：

对话意图识别微调（LoRA）
背景：规则+提示方案在长尾意图上准确率仅 71%，用户流失风险高。
难点：训练数据仅 2000 条，易过拟合；基座在中文业务语料上表现弱。
方案：基于 Qwen 基座 LoRA 微调（r=16, α=32），构建指令-回答数据集；
     冻结基座、仅训低秩增量；用 10% 验证集监控损失早停。
结果：长尾意图准确率 71%→86%（提升 15 个点）；通用能力基准前后持平，
     证明无灾难性遗忘；每轮训练成本约 30 元（单卡 A100）。

为什么好：背景→难点→方案（带超参与理由）→量化结果（模型指标 + 遗忘检测 + 成本），每一句都留了深挖的入口。

2. RAG 类项目

面试官会问：为什么用 RAG 不用微调？chunk 怎么切的、多大？用什么检索器，为什么？检索质量怎么评估？答错的时候是检索问题还是生成问题？怎么排查？

普通写法：基于向量数据库实现 RAG 知识库问答，回答准确率 85%。

好写法：

企业知识库问答（RAG）
背景：客服知识库 2 万文档、更新频繁，微调无法跟新，需外挂知识。
难点：文档含大量表格与长段落，朴素切块导致召回碎片化；答案引用易幻觉。
方案：按语义段落切块（500 token，重叠 50）+ 混合检索（BM25+向量）
     加重排序；生成阶段强制引用来源；建立 300 题 golden set。
结果：检索召回率 68%→82%；答案忠实度（引用可验证率）达 93%，
     幻觉率较基线降 41%；平均首 token 延迟 1.2s。

为什么好：体现"为什么 RAG 而非微调"的判断、检索优化细节、以及关键的评测体系（golden set、忠实度）。

3. Agent 类项目

面试官会问：Agent 循环怎么设计的？工具调用怎么保证格式正确？卡死/循环了怎么处理？记忆怎么存？成本怎么控制？提示注入怎么防？

普通写法：基于 LangChain 开发数据分析 Agent，支持调用 SQL 工具。

好写法：

数据分析 Agent（工具调用）
背景：业务人员查询数据需等数仓排期，希望自然语言直达数据。
难点：SQL 生成正确率不稳；多轮对话中上下文与工具结果超长；存在注入风险。
方案：ReAct 循环 + 工具 schema 校验（非法参数自动重试 1 次）；
     关键上下文压缩进摘要；SQL 白名单 + 只读账号权限隔离。
结果：SQL 生成正确率 81%（baseline 62%）；平均每任务工具调用 3.2 次，
     失败自动恢复覆盖 87%；每任务 token 成本约 0.08 元。

为什么好：体现可靠性与成本意识——这正是 2025 年 Agent 岗的考察重心。

4. 评测类项目

面试官会问：评测集怎么来的？为什么选这些基准？LLM-as-a-judge 的偏差怎么处理的？怎么防数据污染？线上怎么验证？

普通写法：负责模型效果评测，使用 MMLU 等基准。

好写法：

大模型业务评测体系
背景：模型频繁迭代，团队靠人工抽检判断效果，无法回归。
难点：业务无标准答案，需兼顾客观指标与主观质量；防止基准污染。
方案：搭建 3 套评估集（公开基准 500 题 + 业务自建 800 题 + 人工标准集），
     引入 LLM-as-a-judge（双模型互评 + 位置打乱消除偏差），接入 CI 回归。
结果：上线后每次迭代 20 分钟内出评测报告，拦截 6 次效果退化；
     人工-模型评判一致性达 89%，显著低于人工两两一致性约 90% 的基线误差。

为什么好：评测项目最稀缺，写清方法（防偏差、防污染）就是最好的差异化。

5. 部署类项目

面试官会问：显存怎么估算的？为什么用这个量化位宽？批处理怎么做的？TTFT/吞吐多少？压测怎么做的？OOM 了怎么办？

普通写法：使用 vLLM 部署模型，QPS 提升 3 倍。

好写法：

推理服务化与优化
背景：业务需要 100 QPS 的在线推理，原服务单实例只能支撑 20 QPS。
难点：长上下文场景 KV cache 显存爆炸；FP16 权重 + 缓存显存超配。
方案：权重 INT8 量化（AWQ，精度损失 <0.5 个点）+ vLLM continuous
     batching + KV cache 上限约束与 PagedAttention 复用；
     压测定位瓶颈从 GPU 计算转为内存带宽。
结果：单实例吞吐 20→110 QPS（约 5.5 倍），P95 延迟 <2s，
     单位 token 成本下降约 60%；精度回退用评测集回归确认。

为什么好：从"部署了"升级为"优化链路 + 量化选型 + 瓶颈定位 + 成本数字"。

五、项目深挖自测：六类必被追问的问题

大模型岗的"项目深挖"不是闲聊，而是用六类问题反复轰炸一个项目，看你能不能接住。每个项目写完后，用下表自测：

追问类型	典型问题	答不好的表现	准备方法
动机类	为什么用 RAG 不用微调？为什么选这个基座？	"大家都这么用"	写下一句话判断 + 一个反例
细节类	chunk 切多大？重叠多少？为什么？	答不出具体数字	写下你的关键超参与理由
数据类	数据从哪来？多少条？怎么清洗的？	"网上找的"	写下数据来源、规模与处理流程
取舍类	试过别的方案吗？为什么放弃？	"没试过别的"	补一次对比实验，哪怕小规模
评估类	怎么证明有效？基线是什么？评测集哪来的？	只说"准确率 90%"	写下基线、口径、评测集构成
成本类	训练/推理跑一次多少钱？延迟多少？	"没算过"	至少估一个数量级（元/天、秒级）

最容易被问哭的三个项目问题（示范答案）：

1. "你这个方案，基线是什么？"——示范："基座模型直接提示词方案，同一个 300 题业务集上准确率 71%；微调后 86%。"
2. "数据里有没有泄漏？评测集会不会和训练数据重叠？"——示范："我用 MinHash 对训练集和评测集做了近似去重，检出并移除了 XX 条重叠样本；评测集按时间切分，晚于训练数据。"
3. "这个项目如果重做，你会改什么？"——示范："前期评测集建晚了，前两版效果全靠主观判断。重做的话第一天就建 golden set，并接进 CI 做回归。"

把六类问题做成"项目体检单"

给简历上最强的两个项目各写一份一页纸的"项目档案"：一句话背景、三个难点、方案取舍表、评测口径、成本数字、一个失败复盘。面试前三天只看这份档案——它就是你的深挖防线。

项目档案模板（可直接套用）：

项目名称：________________
一句话定位：________________
业务背景（3 行）：________________
三个技术难点：①____ ②____ ③____
方案选型与理由（含放弃的方案）：____
数据来源与规模：____
评测口径（评测集构成 / 基线 / 指标）：____
量化结果（模型指标 / 业务指标 / 成本延迟）：____
踩过的坑与复盘：____

六、量化结果怎么写

1. 模型指标 + 业务指标，两个都要

类型	例子	为什么重要
模型指标	准确率、召回率、pass@k、忠实度、幻觉率	证明"技术本身有效"
业务指标	转化率、客诉下降、人力节省、用户留存	证明"对业务有价值"（面试官最认）
资源指标	延迟、吞吐、token 成本、显存	大模型岗特有加分项：证明"跑得动、用得起"

2. 诚实原则：数字必须经得起三连问

"怎么测的？样本多大？基线是多少？" 大模型岗面试官对"提升 15 个点"这种数字天然警惕。写法上的三个守则：

• 写基线：写"71%→86%"比只写"86%"可信十倍；
• 写口径：注明评测集规模与构成（"300 题业务 golden set"）；
• 别编造：宁可少写一个数字，不要写一个追问就崩的数字——面试官当场拆穿造假，整个简历的可信度归零。

3. 项目数字的三种来源与可信度分级

来源	例子	可信度	面试追问
你亲自跑的对比实验	"同评测集，baseline 71% → 微调后 86%"	高，最推荐	评测集怎么来的？样本多少？
团队/线上数据	"上线后客诉下降约 30%"	中，要能讲口径	口径怎么定义？统计周期？
官方/公开基准引用	"该模型 MMLU 公开 90 分"	低（不是你做的）	只能作背景，不能当成果

大模型岗简历里最常犯的"数字事故"是第三类：把模型的公开分数写进自己的成果。 公开基准分属于模型厂商、不属于你——你的成果必须是你自己测的。写"使用该模型（MMLU 公开 90 分）在业务集上达到 XX"是合理的；写"MMLU 90 分"当自己的成绩，深挖一轮就会翻车。

七、技能列表怎么列：分层，别堆名词

大模型岗技能列表建议按四层组织，宁少勿滥：

层级	内容	写法示例
编程语言	Python（精通）、C++（熟悉）、SQL（熟练）	写程度，别只写名字
框架与工具	PyTorch、HF Transformers、vLLM、LangChain	与项目呼应，能讲原理
模型技术	Transformer、LoRA、RAG、RLHF/DPO、量化	与项目呼应，能讲取舍
工程能力	分布式训练、评测体系、服务化、CI/CD	加分项，有证据才写

技能列表三个雷区

① 堆 30 个名词——面试官默认你全会，随便挑一个深挖就崩；② 写"熟悉"但没有任何项目佐证——技能与项目脱节等于没写；③ 写已经过时的工具（如 2025 年还只写"熟悉 LangChain"而完全没有底层理解）——暴露知识陈旧。

八、常见简历错误：10 个反例

1. 只写课程，不写项目：大模型岗是工程岗，没有项目等于没有证据；
2. 堆名词不解释："精通 Transformer、RAG、LoRA、Agent"——每个都经不起追问；
3. 指标经不起追问：写了"准确率 95%"，问"评测集哪来的"答不上来；
4. 把"做过 demo"写成"负责系统"：demo 与线上系统的差距面试 10 分钟就暴露；
5. 只写工具，不写判断："用了 LangChain" vs "对比了 LangChain 与自写管道，因可控性选了后者"；
6. 没有失败与复盘：大模型项目必然有坑，只报喜不报忧会被认为没有深度；
7. 项目与目标 JD 脱节：投 Agent 岗，简历主角却是图像分类；
8. 把团队项目写成个人项目：深挖"具体哪部分是你做的"时含糊其辞；
9. 量化指标只有模型指标，没有业务与成本：大模型岗尤其看成本意识；
10. 一份简历投所有岗位：连岗位名都不改，HR 一眼看穿。

九、按岗位定制简历：侧重点不同

同一份经历，投不同岗位时突出证据的侧面不同。对照下表定制简历的标题与第一条要点（岗位侧重点来自JD 清单的关键词雷达）：

岗位	简历最该突出的证据	常见误区
算法工程师（大模型方向）	完整落地链路（选型→组合→评测→上线）与方案取舍	只写"效果提升"，不写"为什么选这个方案"
NLP 算法工程师	经典 NLP 功底（分词/序列标注）+ LLM 组合应用	只写大模型项目，丢了基础能力证据
大模型训练工程师	分布式配置、损失曲线诊断、数据管道规模	只写"跑过训练"，没有规模与问题诊断
推理优化工程师	量化/KV cache/批处理的具体数字、瓶颈定位过程	只写"部署了 vLLM"，没有前后对比
AI 应用工程师	端到端交付 + 评测体系 + 成本/延迟	只有 demo，没有评测与成本意识
Agent 工程师	可靠性（重试/护栏/防注入）、成本控制	只写框架名，不写稳定性设计
评测工程师	评测集设计、防偏差/防污染方法、回归拦截案例	只写"测过 MMLU"，没有方法论
数据工程师（LLM 方向）	语料规模、去重/过滤方法、质量闭环	只写"清洗过数据"，没有方法与数字

一条经历，按岗位换"证据角度"

同一个微调项目：

• 投算法岗 → 强调"为什么选 LoRA 而非全参、秩与数据配比做过什么实验"；
• 投应用岗 → 强调"评测集怎么设计、上线后成本与延迟"；
• 投训练岗 → 强调"显存怎么省、训练曲线怎么监控"。

简历不是造假，是把同一事实的多个侧面，对准不同岗位的雷达。

投递前建议维护两个版本：投算法/训练类岗位的版本突出模型选型、原理与实验；投应用/工程类岗位的版本突出工程闭环、评测与成本。别用一份简历海投所有岗位——HR 第一眼找的就是"与岗位雷达对齐的关键词"。

十、能力自查表

投递前逐项打勾，任一 ☐ 未勾就要返工：

项目层

• [ ] 简历中最强的 1–2 个项目能各讲 20 分钟以上（含取舍与失败）
• [ ] 每个项目有：背景 → 难点 → 方案 → 量化结果 四段式
• [ ] 至少一个项目有"对比实验"或"方案选型理由"
• [ ] 量化结果有基线与口径，能答"怎么测的、样本多大"
• [ ] 大模型类项目至少覆盖：效果 + 成本/延迟（二者至少其一）

技能层

• [ ] 技能列表每个名词都能讲 10 分钟原理
• [ ] 技能与项目相互印证，无孤立名词
• [ ] 与目标 JD 的关键词雷达（见JD 清单）对齐

语言层

• [ ] 全文无"精通"无证据的空话
• [ ] 无错别字、格式统一、长度一页
• [ ] 有 GitHub/作品集链接且真实可访问

对标层

• [ ] 按知识点拆解自评，写在简历上的能力没有"概念模糊"档
• [ ] 用面试题库自测，项目相关的深挖题能答八成

十一、延伸阅读

站内继续读

• 知识点拆解 —— 简历上每个名词的深挖考点都在这里
• 面试题库 —— 项目深挖题的参考答案要点
• JD 清单 —— 按关键词雷达逐项对齐简历
• 模块导读与岗位版图 —— 确认你的简历在讲哪个岗位的故事

参考资料

• GitHub —— 作品集与项目仓库的承载地，大模型项目建议附 README 与演示
• Hugging Face —— 模型/数据集/space 展示，微调与评测项目的最佳展示平台
• LinkedIn —— 海外求职主阵地，英文 JD 与行业人脉
• BOSS直聘 —— 国内投递主渠道，可直接对比简历与 JD 关键词