大模型项目经历最常见的3种烂写法，附修改对比

昨天在知识星球 (opens new window)里，一个录友发了简历给我看，项目经历是这样写的：

基于大模型的智能问答系统

• 使用LangChain框架
• 调用GPT-4 API
• 实现了RAG检索
• 使用Milvus向量数据库

我问她："你用的什么Embedding模型？检索不准怎么调的？延迟多少？"

她答不上来。

这不是项目经历，这是功能清单。

然后我又翻了星球里最近的大模型简历，项目经历的写法几乎逃不出这三种。今天逐个拆开，告诉你问题出在哪，怎么改。

---

第一种：功能列表型

这是最常见的。项目经历写成了功能清单，每一行都是"用了什么""做了什么"，但看不出你解决了什么问题。

反面：

基于RAG的企业知识库问答系统

• 使用LangChain搭建RAG流程
• 调用OpenAI GPT-4 API
• 使用Milvus存储向量
• 实现文档解析和智能问答

面试官看完的想法：然后呢？你搭了个LangChain的pipeline，用的默认配置？检索效果怎么样？幻觉处理了吗？

正面：

基于RAG架构的企业知识库问答系统，面向10万+用户的知识检索场景

个人工作：

• 设计向量+BM25混合检索策略，准确率从72%提升至91%
• 封装动态Prompt模板，幻觉率降低40%
• 接口P99延迟从2.1s优化至0.4s

项目难点：

• 长文档检索召回率不足，通过Chunk分段+上下文窗口扩展解决
• 大模型输出不可控，引入RAG约束+输出自校验机制

看出区别了吗？左边是"我做了什么"，右边是"我解决了什么问题、怎么解决的、效果如何"。

大模型简历的核心不是"我用了什么"，而是"我解决了什么问题"。

---

第二种：技术名词堆砌型

这种比功能列表更迷惑，看起来很厉害，但仔细一看全是术语，没有一件事是你自己的。

反面：

基于Transformer架构的智能Agent系统

• 采用ReAct循环实现推理与行动的交替
• 使用Function Calling实现工具调用
• 基于RAG检索增强生成技术
• 采用Prompt Engineering优化模型输出

每个词都是对的，但面试官看完不知道你做了什么决策、解决了什么问题。

"采用ReAct循环"——你是怎么处理多步推理出错的？ "使用Function Calling"——工具调用不稳定怎么办？ "采用Prompt Engineering"——优化了什么？幻觉降了多少？

正面：

基于Agent架构的智能工单处理系统，面向企业IT运维场景

个人工作：

• 设计Function Calling工具编排方案，支持6类运维工具联动，工具调用成功率从78%提升至96%
• 实现ReAct循环的错误恢复机制，多步推理中断后可自动重试并回退
• 设计结构化Prompt约束输出格式，解析失败率从35%降至5%

项目难点：

• 多步推理中工具调用结果不可控，引入结果校验+重试机制
• 长对话上下文丢失导致Agent行为漂移，通过滑动窗口+关键信息摘要解决

区别很明显：右边把技术名词变成了你的技术决策和解决结果。

技术名词不是亮点，技术决策才是。

---

第三种：流水账型

这种写法最像"工作日志"——按时间顺序记录自己做了什么，但没有重点，没有难点，没有结果。

反面：

智能对话系统项目

• 首先搭建了FastAPI后端服务
• 然后接入了向量数据库存储文档
• 接着实现了文档解析和切片功能
• 之后写了检索接口调用Embedding模型
• 最后调用大模型API生成回答
• 部署到了服务器上

面试官看完：这跟跑个教程有什么区别？

正面：

基于RAG架构的智能对话系统，面向企业内部知识问答场景

个人工作：

• 设计文档解析与切片策略，针对PDF/Word/Markdown三种格式分别优化，解析准确率从68%提升至94%
• 实现混合检索（向量+BM25），Rerank后Top5召回率从71%提升至89%
• 部署vLLM推理服务，并发处理能力从8 QPS提升至45 QPS，推理成本降低60%

项目难点：

• PDF表格和图片解析丢失，引入OCR+表格识别模块单独处理
• 单路向量检索对专业术语召回差，增加BM25精确匹配补充

流水账的问题是没有重点。你做的每件事看起来都一样重要，面试官抓不住你的核心贡献。

项目经历不是日记，是给面试官看的广告。 你得告诉他：我最厉害的是这个。

---

三种烂写法的共同问题

看出来了吗？这三种写法，本质上犯了同一个错：

只写了"做了什么"，没写"解决了什么问题、怎么解决的、效果如何"。

大模型方向太新了，面试官看简历不是看你有没有用过某个框架——LangChain谁不会装？他看的是：

1. 你能不能选对技术方案？为什么用RAG不用微调？为什么用Milvus不用Pinecone？
2. 你能不能解决真实问题？检索不准怎么办？幻觉怎么降？延迟怎么优化？
3. 你有没有工程化能力？不是跑了个Demo就行，能上线吗？能扛并发吗？能控制成本吗？

这正好对应了上一篇讲的四要素写法——项目描述、个人工作、项目难点、个人收获。

下一篇，我会把四要素写法在大模型项目经历上的应用拆开讲透：每个要素具体怎么写，常见的坑是什么，附完整模板。

---

这是「大模型应用开发简历系列」的第4篇，工作日每天更新一篇。

如果你想让我帮忙看简历，或者想系统学习简历写法，欢迎加入知识星球 (opens new window)，我在那里每天帮录友改简历。