聊一聊最近看简历一些很减分的问题

淘天 27 届暑期实习生正在招聘 各方向都有海量 HC 欢迎看我置顶帖子投递

校招季翻了很多份 AI 方向的简历，发现一个规律：大家做的项目其实差不多——RAG、Agent、LLM 应用，技术栈也大同小异。但有的简历让人想立刻约面试，有的看完只记住了一串技术关键词。

差距不在项目本身，在写法。

同样是做了一个 RAG 系统，有人写"使用 LangChain 搭建了 RAG 系统"，有人写"对比了三种 chunking 策略后选用了基于段落结构的自适应切分，检索命中率从 62% 提升到 81%"。前者告诉我你用了什么，后者告诉我你思考了什么。面试官筛简历时真正在找的是后者。

场景一：项目描述只罗列技术栈，不讲做了什么、解决了什么

原始写法

AI 对话助手项目技术栈：Python, LangChain, OpenAI API, Pinecone, FastAPI, React

• 使用 LangChain 搭建了 RAG 系统
• 使用 Pinecone 向量数据库存储文档
• 使用 FastAPI 开发后端接口
• 使用 React 开发前端页面

问题分析

看完不知道这个项目做了什么业务、解决了什么问题、你的贡献是什么。纯技术栈罗列和把 package.json 打印出来没区别。面试官看不到任何思考过程，只看到"会用框架"。这种写法在简历筛选阶段几乎没有区分度——任何人跟着教程做一遍都能写出一样的内容。

优化版本

面向企业知识库的智能问答系统

• 针对企业内部文档检索低效的问题，设计并实现了基于 RAG 架构的问答系统，支持对 2000+ 篇技术文档的自然语言查询
• 设计了分层检索策略：先用关键词做粗筛缩小范围，再用向量相似度精排，相比纯向量检索将答案命中率从 62% 提升到 81%
• 解决了长文档切分时语义断裂的问题，实现了基于段落结构的自适应 chunking，平均检索相关性评分提升 23%
• 独立完成后端 API 设计与前端交互界面，支撑 30 人内测使用

优化原则：每一条突出问题 → 方案 → 量化结果三段式。技术栈不需要单独列，自然融在做法描述中就行。

场景二：把调 API 包装成"开发 Agent"

原始写法

智能客服 Agent

• 开发了基于 GPT-4 的智能客服 Agent
• 实现了多轮对话功能
• 接入了知识库实现精准回答

问题分析

面试官一看就知道这大概率是"调了 OpenAI 的 API + 把聊天记录拼进 prompt"。"多轮对话"就是把历史消息拼上去，"接入知识库"就是做了个最基础的 RAG。把这些包装成"Agent"会在面试中被追问得很尴尬——"你的 Agent 有哪些工具？循环怎么设计的？怎么处理工具调用失败？"一问就穿帮。

优化版本

方案 A：如果确实只是基础 LLM 应用，诚实地写清楚你做了什么

基于 LLM 的客服问答系统

• 设计了多轮对话管理机制，通过滑动窗口 + 关键信息摘要控制上下文长度，在 8K token 窗口限制下支持 20 轮以上连贯对话
• 针对客服场景优化了 prompt 工程：通过 few-shot 示例约束回答风格，通过指令注入防御策略防止用户诱导模型输出无关内容
• 对比了三种 chunking 策略在客服知识库上的检索效果，最终选用基于 FAQ 问答对的结构化索引方案，检索准确率达到 87%

方案 B：如果真的有 Agent 要素，突出 Agent 特有的设计决策

具备工具调用能力的智能客服 Agent

• 设计了 ReAct 循环架构，Agent 能根据用户问题动态选择工具：查订单系统、查物流 API、查知识库，支持在单次对话中串联多个工具完成复杂查询
• 实现了工具调用失败的自动恢复机制：将错误信息回传给 LLM 由模型自行决定重试或换工具，而非硬编码恢复逻辑
• 设计了循环检测和最大步数兜底机制，防止 Agent 在异常场景下无限循环，平均任务完成步数 3.2 步

核心原则：你是什么水平就写什么水平，但要把你做到的那个层次写得足够深。一个做得很扎实的 LLM 应用，比一个包装成 Agent 但经不起追问的项目强 10 倍。

场景三：用课程项目 / 教程项目充数，无差异化

原始写法

基于 Transformer 的文本分类

• 使用 BERT 预训练模型对新闻文本进行分类
• 在 THUCNews 数据集上达到 95% 准确率
• 使用 PyTorch 实现模型训练和推理

问题分析

这是一个标准的课程作业 / 入门教程项目。问题不在于做了这个项目——每个人都需要从基础开始。问题在于写法没有展示出你独立思考的部分。95% 准确率在这个数据集上不算什么（随便微调就能到），面试官想看的是你在这个过程中遇到了什么具体问题、怎么解决的。

优化版本

基于 BERT 的新闻文本分类及推理优化

• 在标准微调达到 95% 准确率的基础上，重点探索了推理阶段的性能优化
• 对比了 ONNX Runtime 导出、动态量化（INT8）、知识蒸馏三种加速方案，最终采用 ONNX + INT8 量化方案，将单条推理延迟从 45ms 降至 12ms，精度损失控制在 0.3% 以内
• 分析了模型在短文本（<50 字）上准确率显著下降的问题，通过拼接标题和摘要作为组合输入，短文本准确率从 78% 提升至 91%

优化原则：基础项目不丢人，但你需要展示"在教程之外你还做了什么"。做了额外实验、发现了一个有趣的问题并解决了、或者对某个环节做了深入对比——这些才是区分度。

场景四："熟悉 XXX 框架"堆砌式技能列表

原始写法

技术技能语言：Python, JavaScript, TypeScript, Java, C++, Go, Rust框架：LangChain, LlamaIndex, React, Next.js, FastAPI, Django, Spring Boot工具：Docker, K8s, Git, Linux, MySQL, Redis, MongoDB, Pinecone, ElasticsearchAI：Transformer, BERT, GPT, Stable Diffusion, LoRA, RLHF, RAG, Agent

问题分析

列了 30+ 个技术词，面试官的第一反应不是"这人真厉害"，而是"这些到底会到什么程度"。写了 Rust 和 Go 但简历上没有任何相关项目，面试时被问"你用 Rust 做过什么"就傻了。写了 RLHF 和 LoRA 但其实只看过几篇博客——这些在面试中一追问就会暴露。

优化版本

技术技能

• 主力语言：Python（2 年日常使用），TypeScript（1 年项目经验）
• LLM 应用开发：熟悉 Prompt 工程和 RAG 架构设计，有完整的 RAG 系统从 0 到 1 开发经验；了解 Agent 工作原理（ReAct 循环、工具调用机制），阅读过 LangChain 核心源码
• 基础设施：熟练使用 Git、Docker、Linux 环境；有 FastAPI 后端开发和 React 前端开发经验

优化原则：只写你能在面试中撑住 15 分钟追问的技术。"熟悉"和"了解"要区分清楚——"熟悉"意味着你能在白板上从零写出来，"了解"意味着你知道原理但不一定能写。少即是多——简历上写 5 个真会的，比写 30 个会被戳穿的强得多。

场景五：实习/项目经历写成了工作日志

原始写法

XX 公司 AI 团队实习

• 负责 LLM 应用的日常开发和维护
• 参与了 prompt 优化工作，提升了模型输出质量
• 协助团队完成了 RAG 系统的开发
• 参与了技术调研和文档编写

问题分析

"负责""参与""协助"——看完不知道你具体做了什么。"提升了模型输出质量"——提升了多少？怎么提升的？什么指标？"参与了 RAG 系统的开发"——你负责哪个模块？做了什么设计决策？这种写法把实习经历写成了工作周报，没有任何信息增量。

优化版本

XX 公司 AI 团队 | LLM 应用开发实习

• 独立负责客服场景的 prompt 优化迭代，通过构建 200 条标注评测集 + LLM-as-Judge 自动评估流程，将系统化的 prompt 调优替代了之前的"凭感觉改"模式，回答相关性评分从 3.2 提升至 4.1（5 分制）
• 承担 RAG 系统检索层的重排模块开发：调研并对比了 Cohere Reranker、bge-reranker、Cross-Encoder 三种方案，最终选用 bge-reranker 部署，检索 Top-5 命中率从 71% 提升至 84%，推理延迟增加 < 50ms 在可接受范围内
• 发现并修复了一个文档索引的 bug：部分 PDF 的表格内容在切分时丢失，导致财务类问题检索准确率异常低。设计了表格专用的解析和索引策略，该类问题准确率从 43% 恢复至 79%

优化原则：实习经历的每一条都要回答三个问题——你具体做了什么（不是"参与"而是具体动作）、你做了什么判断和选择（对比了什么方案、为什么选这个）、结果如何量化（数字，不是"提升了"）。

场景六：自我评价写成了性格描述

原始写法

自我评价本人热爱技术，学习能力强，善于沟通，具有良好的团队协作精神，抗压能力强，对 AI 领域有浓厚兴趣。

问题分析

这段话放到任何人简历上都成立，信息量为零。面试官直接跳过。

优化版本

直接删掉，或者替换为有信息量的内容：

开源与社区

• 维护个人技术博客，发表过 3 篇 RAG 实践相关文章，单篇最高阅读 5000+
• 为 LangChain 提交过 2 个 PR（修复文档切分的 edge case），已合并
• 复现并对比了 5 种主流 RAG 方案在中文场景下的效果，整理为开源项目，获 200+ Star

优化原则：用事实代替形容词。"学习能力强"不如"两周内独立完成了 XX 项目"。"对 AI 有兴趣"不如"阅读并复现了 3 篇 RAG 相关论文"。没有可量化的事实支撑的自我评价，不如不写。

通用简历优化清单