顺便说一句，淘天 27 届暑期实习生还在持续招人，AI工程、算法等方向都有机会，感兴趣可以查看我关联的内推记录。

最近集中看了一批 AI 相关的校招简历，有个感受越来越明显：

不是大家项目差距很大，而是简历呈现方式差距特别大。

你会发现，候选人做的内容往往高度相似：

大模型应用、RAG、知识库问答、Agent、多轮对话、Prompt 优化……

甚至连技术组合都很像：Python、LangChain、向量库、FastAPI、React。

可同样一类项目，有些人写完以后让人觉得“这个同学是真的做过，也想明白了”，有些人则像把一串名词拼在一起，读完只留下几个框架名。

问题通常不在项目，而在你怎么把项目写出来。

1. 最常见的问题：只写“用了什么”，不写“为什么这么做”

很多简历有个典型毛病：项目描述看起来很满，实际读下来完全不知道重点。

比如有人写一个知识库问答项目，会这样写：

• 用 LangChain 搭建 RAG 流程
• 使用向量数据库存储文档
• 用 FastAPI 提供接口
• 前端用 React 实现页面

这类内容的问题是：

你确实写了技术方案，但没有告诉面试官：

• 这个系统到底解决什么业务问题？
• 你在里面真正负责哪一部分？
• 为什么选这个方案？
• 做完后效果到底怎么样？

如果一段项目经历只能让人看出“你会调用框架”，那它的区分度会非常低。因为跟着公开视频或者教程做一遍，几乎每个人都能写出类似描述。

更好的写法，应该把重点放在问题、判断、结果上。

比如同样是做知识库问答，你完全可以换一种叙述方式：

• 场景是什么：面向企业内部文档检索低效的问题
• 你做了什么：设计检索链路、优化切分方式、调整排序策略
• 最终结果：命中率、相关性、延迟、覆盖范围有没有明显变化

真正能打动面试官的，不是“我用了某某框架”，而是“我观察到一个具体问题，然后做了判断，最后把指标拉上来了”。

2. 别把“调模型接口”硬说成“做了 Agent”

这一点在 AI 简历里特别常见。

很多同学只要做了多轮对话，接了知识库，或者给模型加了几个 Prompt，就会把项目名称写成“智能 Agent”“自主决策 Agent”“多工具 Agent 系统”。

但问题是，面试官通常一眼就能看出来你到底做到哪一层。

如果你的所谓 Agent，本质上只是：

• 调一次模型接口
• 带上历史聊天记录
• 检索几段文档拼进上下文

那它其实更接近一个基础的大模型应用，而不是严格意义上的 Agent。

为什么这个问题严重？因为一旦你自己把项目拔高了，面试里就一定会被顺着追问：

• 你的 Agent 有哪些工具？
• 工具调用策略怎么定？
• 推理和执行有没有循环机制？
• 调用失败怎么恢复？
• 如何避免反复试错导致死循环？
• 状态管理怎么做？

如果这些都答不上来，包装得越高，现场越尴尬。

所以最稳妥的策略不是乱贴标签，而是照真实层次写清楚，但把细节写深。

如果你做的是一个普通 LLM 应用，那就老老实实强调这些点：

• 上下文窗口如何管理
• 多轮对话如何防止信息丢失
• Prompt 如何约束回答风格
• 怎样做评测
• 检索策略如何优化

如果你真做了 Agent，再突出 Agent 特有的设计：

• 工具选择机制
• 调用链路
• 异常恢复策略
• 最大步数控制
• 循环检测
• 多工具串联的任务拆解方式

简历最怕的不是“项目不高级”，而是“写得比实际高级很多”。

3. 教程项目不是不能写，关键看你有没有做出自己的东西

很多人会纠结：

“我做的是 BERT 分类、文本生成、基础微调，会不会太普通了？”

其实普通项目本身不是问题。校招生本来就不可能人人都做过工业级复杂系统。真正的问题是，你如果把一个很标准的练手项目，写成一份毫无个人思考的实验报告，那它就很难帮你拿到面试。

例如最典型的写法：

• 基于 BERT 做文本分类
• 在某数据集上达到 xx% 准确率
• 使用 PyTorch 完成训练和推理

这种写法的问题不在于“做得不对”，而在于“太像模板答案”。

因为同一个数据集、同一个模型、同一种微调方式，别人也能做到差不多的结果。

想把基础项目写出亮点，有一个很好用的方法：

不要只讲“模型训出来了”，而要讲你额外做了什么探索。

比如你可以从这些角度切入：

• 推理性能是否做过优化
• 部署成本是否做过权衡
• 某类样本效果为什么差
• 是否分析过误分类案例
• 是否尝试过压缩、量化、蒸馏
• 是否做过不同方案对比

一个“大家都做过”的项目，只要你在其中多走一步，主动做分析、做实验、做取舍，它就开始有辨识度了。

面试官真正想看到的是：

你不只是“会把 demo 跑通”，而是“会围绕一个问题继续往下挖”。

4. 技能栏不是词汇表，写太满反而像在冒险

还有一种简历很典型：技能区写得像技术名词批发市场。

语言从 Python 一路列到 Go、Rust、C++；

框架从 LangChain 一路列到 Spring Boot；

AI 相关再补一串：Transformer、BERT、GPT、LoRA、RLHF、RAG、Agent……

乍看之下很丰富，但大多数面试官的第一反应其实不是“这个人涉猎真广”，而是：

这些东西你到底掌握到什么程度？

因为技能一旦写上去，就默认你愿意为它负责。

如果你写了 Rust，别人就可能问你：

• Rust 拥有权怎么理解？
• 你用 Rust 写过什么项目？
• 借用检查器给你带来过什么具体问题？

如果你写了 RLHF，别人也会问你：

• Reward model 是怎么训练的？
• PPO 在这个过程里扮演什么角色？
• SFT、RM、RL 三个阶段关系是什么？

这时候，很多人就会暴露：其实只是看过一些文章，或者听过概念，谈不上真正掌握。

所以技能栏最好的策略不是“尽量多写”，而是“尽量真实”。

可以按层次来写：

• 主力语言是什么，使用时长多久
• 哪些能力是做过完整项目的
• 哪些只是理解原理、能交流但不算熟练
• 哪些工具是在日常开发中高频使用的

技能不是展示见识面，而是展示可验证能力。

写 5 个能展开讲 10 分钟的，比写 30 个一问就露怯的强太多。

5. 实习经历别写成“我在帮团队打杂”

不少同学写实习时，特别容易陷入一种“工作日报体”：

• 参与某某系统建设
• 协助进行模型优化
• 负责日常开发维护
• 支持技术调研和文档整理

这种写法表面上看很稳，实际上几乎没有有效信息。

因为面试官读完还是不知道：

• 你具体做的是哪块？
• 你是执行现成方案，还是自己做过判断？
• 你到底解决了什么问题？
• 结果有没有可衡量的变化？

像“参与”“协助”“跟进”这种词，用得越多，你的存在感就越弱。

实习经历真正应该突出的是三件事：

第一，你亲手完成了什么动作

不要只说“参与优化”，要说清楚你到底优化了什么。

是改了 Prompt？做了评测集？调了 rerank？改了切分逻辑？补了索引流程？

第二，你做过哪些选择

比如：

• 对比过哪些模型或方案
• 为什么最终选这个
• 成本、效果、延迟之间怎么平衡

第三，结果是什么

这个结果最好尽量落到数字上：

• 准确率
• 命中率
• 延迟
• 吞吐
• 召回率
• 人工评分
• 用户覆盖人数

如果你能把一段实习写成“我发现了什么问题—我尝试了哪些方案—我最终把什么指标做到了多少”，那它的说服力会和“参与某项目开发”完全不是一个级别。

6. “自我评价”大概率是最没必要的一栏

“热爱技术、学习能力强、沟通能力好、抗压能力强、团队协作佳、对 AI 充满热情”——这类话几乎出现在所有人的简历里。

问题是，这些内容对筛选者没有帮助。

因为每个人都能这么写，而且很难验证。

你说自己学习能力强，证据是什么？

你说自己对 AI 感兴趣，体现在哪里？

相比之下，任何一个具体事实都比空泛形容词更有价值。

比如你可以写：

• 维护技术博客，持续输出 RAG / LLM 实践内容
• 给开源项目提过 PR
• 复现过某篇论文或方案并公开代码
• 做过 benchmark 对比并整理成仓库
• 在比赛、开源社区、论坛有可查证产出

说白了，“我是一个怎样的人”不如“我做过什么事”有说服力。

如果没有特别强的信息支撑，自我评价这一栏完全可以删掉，给项目和经历腾位置。

一份更像样的 AI 简历，核心到底是什么？

如果把上面的问题都浓缩一下，其实就一句话：

别把简历写成“我接触过很多技术”，而要写成“我解决过一些具体问题”。

筛简历的时候，真正让人记住的通常不是某个关键词，而是这些东西：

• 你有没有识别出实际问题
• 你有没有比较过不同方案
• 你有没有说明自己的判断依据
• 你有没有拿出结果来证明工作有效
• 你是不是清楚自己做到哪一层，而不是靠包装抬高项目

一个很实用的改简历方法

如果你现在就想动手改，可以把每一条经历都拿出来，按下面几个问题重写一遍：

1. 这是在什么场景下做的？

别上来就写技术名词。

先交代场景和目标，不然别人不知道你为什么做这个。

2. 遇到的核心问题是什么？

比如：

• 检索不准
• 长文档切分后语义丢失
• 对话上下文过长
• 推理延迟太高
• 某类问题错误率异常高

3. 你具体采取了什么办法？

这里写你的动作和判断，不要只写“使用了某框架”。

4. 为什么选这个方案，而不是别的？

这是最能体现思考深度的部分。

哪怕只是做了两三个简单对比，也比没有强。

5. 结果怎么证明？

尽量给数字。

没有绝对精确的数据，也尽量给相对变化、测试集结果、内测反馈、覆盖范围。

最后总结成几条很短的建议

1. 少写框架名，多写决策过程。
2. 少写“参与协助负责”，多写自己具体做了什么。
3. 少吹概念，真实描述项目层次。
4. 少堆技能词，保留自己能经得住追问的内容。
5. 少写性格评价，多写可验证事实。
6. 所有项目尽量往“问题—方法—结果”这个结构靠。

一份好的简历，不是把你会的东西拼命往上堆，而是让面试官快速判断：

这个人做过事，想过事，而且能把事讲明白。