Day 66 / 共 68 天 · 阶段 12 实战求职

简历 & 项目包装:把作品写成有分量的经历

昨天(Day 65)把三件作品"陈列"到了 GitHub。今天做临门一脚:把它们提炼进简历。核心是用 STAR(问题→方案→指标) 把每个项目写成"解决了什么、怎么解决、结果如何"的一条条经历,用数字说话,别再堆一串技术名词。写好简历,后天(Day 67-68)就进面试冲刺,68 天收官在望。

📍 你在阶段 12(实战求职 D62-68)的位置
D62 作品集①RAG D63 作品集②工具 D64 作品集③多智能体 D65 开源包装 D66 简历 D67-68 面试冲刺
💡 用一个类比兜住今天(今天全程沿用「上法庭举证」的世界观) 投简历 = 上法庭为"我能胜任"这个主张举证招聘方 = 陪审团,只信证据、不信形容词;你的每条经历 = 一份呈堂证供,必须有具体事实和数字,不能只喊"我很厉害";STAR = 一份标准的证词格式(什么情境→你干了啥→什么结果);量化数字 = 铁证(答对率 86% 比"效果不错"有力一万倍);堆技术名词 = 空口白话,陪审团直接无视;GitHub 链接 = 可当场查验的物证。今天的功课:把你 65 天攒下的真本事,翻译成陪审团一看就信的证据。
L01

简历不是"技能罗列",是"证据清单"

🤔 痛点新手简历最常见的写法:"掌握 Python、熟悉 RAG、了解 LangChain、会用向量数据库……"一长串名词。招聘方看了毫无感觉——因为谁都能写"熟悉",这不构成任何证据
💡 本质招聘方筛简历时在问一个问题:"这人真能干活吗?"。你要提供的是证据,不是形容词。"熟悉 RAG"是形容词;"做了一个 RAG 助手,20 题答对率 86%,代码见 GitHub"是证据。好简历 = 一份让人相信你能胜任的证据清单。
📝 举个例子:形容词 vs 证据 ✗ 形容词式:"熟悉大模型应用开发,了解 Agent、RAG、Function Calling。"(空)
✓ 证据式:"独立开发文档问答助手(RAG),攒 20 题评测集将答对率从 68% 优化到 86%,已容器化部署,代码开源。"(有事实、有数字、可查验)
同样是"我会 RAG",一个让人无感,一个让人想约你聊聊。
👶 我没工作经验,拿什么当证据?你的三件作品集就是证据!转行者不靠"前公司经历",靠能拿出来跑、能讲清楚、有数字的项目。这正是我们前四天(Day 62-65)拼命做作品、攒评测数字、发 GitHub 的原因——全是为了今天有"呈堂证供"可举。没有经验不可怕,没有证据才可怕。
L02

STAR 公式:一条经历的标准写法

🤔 痛点知道要写"证据",可具体一条经历怎么组织?东一句技术、西一句结果,读者拼不出完整故事,也感受不到你的贡献。
💡 本质STAR 这个久经考验的公式,把一条经历讲成完整证词。转行简历里可以精简成三段式:问题(为什么做)→ 方案(你怎么做,含关键取舍)→ 指标(结果,带数字)。每条经历都套这个模子,读者一眼看懂"情境-行动-结果"。
STAR:一条经历的四要素 S/T 情境·任务要解决什么问题? A 行动你做了什么关键取舍 R 结果带数字的成效 📎 物证GitHub 链接随时可查 简历版三段式:问题 → 方案(取舍) → 指标(数字) 重点写 A 和 R —— 你的判断力和成果,才是招聘方想看的
图注:每条经历都是一份微型证词。别只写"做了啥",要写"面对什么问题、怎么判断、结果如何"。
📝 举个例子:把作品③套进 STAR (问题)单个大模型写报告易编造、难维护。(方案)设计"研究员/写手/审校"三 Agent 协作流水线,独立审校做防幻觉质检,加返工闸与 trace 日志。(指标)15 个主题审校通过率 80%,抽查无编造出处,可倒查定位薄弱环节。
→ 浓缩成一句简历:"设计三智能体协作报告系统(研究/写作/审校),引入独立防幻觉审校与可观测 trace,审校通过率 80% 且抽查无编造。"
L03

量化:数字从哪来(不用编)

🤔 痛点"要用数字",可新手一慌就开始编("提升效率 300%"),或者觉得"我一个练手项目哪来的数字"。编的一问就穿,没有的又心虚。
💡 本质数字不用编,前面几天早就产出了。你做评测(Day 62-64)得到的答对率、通过率;做性能测的延迟、成本;做优化的"从 X 到 Y"——全是现成的真实数字。这正是"评测最重要"(Day 49)在求职上的第二层回报:评测既让你改得准,又给了你简历上的铁证。
数字类型来自哪一天简历里怎么用
准确率 / 通过率Day62-64 的 golden set 评测"答对率 86%""审校通过率 80%"
优化前后对比评测驱动改进的记录"通过调切块+top-k,从 68% 提升到 86%"
延迟 / 成本Day13/51/56 的性能与成本测量"单次回答 < 3s""语义缓存降本约 X%"
规模你的数据/工具/用例数量"覆盖 20 个 PDF、3 类工具、30 条评测"

👶 小白:我的项目是练手的,数字不好看(比如才 80%),写出来会不会被嫌弃?

👨‍🏫 老师:真实的 80% 远胜编造的 99%。招聘方看重的不是绝对值,而是"你有测量意识、有优化过程"。写"初版 68%→定位问题→优化到 86%"这种带过程的数字,比一个孤零零的漂亮数字更打动人——它证明你会用数据驱动改进。数字诚实、过程清晰,就是好证据。切忌编造:面试一深挖,编的立刻露馅,可信度全崩。

L04

别堆名词:技能栈只是"配料表"

🤔 痛点新手爱把简历塞满 "LangChain / LlamaIndex / FAISS / Docker / K8s / Prompt Engineering / RAG / MCP…" 一大排名词,以为越多越唬人。实际上招聘方要么觉得"堆砌注水",要么当场挑一个深问,把你问穿。
💡 本质名词只是"用了什么配料",不等于"你做出了什么菜"。技能关键词可以有(方便机器筛选/ATS),但要集中放在一个"技术栈"小板块,而不是散落在经历里充数。经历部分只讲"问题-方案-结果",名词自然会作为方案的一部分出现,且每个都有项目背书,经得起深挖。
📝 举个例子:名词的正确用法 ✗ 堆砌:"技能:精通 RAG、Function Calling、多智能体、评测、可观测、Docker、K8s、Prompt 工程、向量数据库……"(每个都"精通"?一问就穿)
✓ 分层:技术栈板块列关键词(Python/LlamaIndex/FastAPI/Docker),经历板块用它们讲故事:"用 LlamaIndex 构建检索、FastAPI 暴露接口、Docker 容器化部署,答对率 86%。"——名词都挂在真实成果上,可信。
👶 那"精通/熟悉/了解"这些词还能用吗?慎用,尤其"精通"。转行者写"精通"极其危险——面试官一定挑你写"精通"的深问,答不上来全盘崩。稳妥写法:用项目说话,让程度不言自明。真要标,顶多"熟悉(有项目)/了解(学过)",诚实分层。记住:让作品证明你的水平,比用形容词自夸靠谱得多。
L05

把三件作品写成三条黄金经历

🤔 痛点三件作品各有侧重,怎么写才能既不重复、又让招聘方看出"这人能力成体系"?乱写会显得像三个孤立练手,写好了就是一条完整能力链的展示。
💡 本质三件作品刻意覆盖了不同能力面(Day 64 说过),简历里就让每条各扛一个关键词:作品①扛"RAG+评测",作品②扛"工具+安全",作品③扛"多智能体+可观测"。三条并列,招聘方一眼看出你的能力是成体系的一条链,而非零散。
### 项目经历(都套用:问题 → 方案 → 指标 + GitHub 链接)

**① 文档知识库问答助手(RAG)**  ·  github.com/you/rag-assistant
- 问题:新员工查制度需翻阅 20+ 份 PDF,效率低。
- 方案:构建 读→切→嵌→存→检索→生成 全流程,强制答案标注出处防幻觉。
- 指标:自建 20 题评测集,答对率经优化 68%→**86%**,单次回答 < 3s,已容器化部署。

**② 多工具智能助手(Function Calling)**  ·  github.com/you/tool-agent
- 问题:Agent 只能答不能办事,且工具调用易失控。
- 方案:设计 3 个工具的 schema 与主循环,工具返回结构化错误、危险操作加审批闸。
- 指标:30 条用例工具选对率 **88%**,危险动作 100% 先确认,无因工具异常崩溃。

**③ 多智能体报告系统(研究/写作/审校)**  ·  github.com/you/report-crew
- 问题:单模型写报告易编造、难维护、难排查。
- 方案:三 Agent 协作流水线 + 独立防幻觉审校 + 返工闸 + trace 可观测。
- 指标:15 主题审校通过率 **80%**,抽查无编造出处,可经 trace 倒查薄弱环节。
📝 举个例子:再加一句"能力链"总述 在项目经历上方加一句概述:"围绕 Agent 开发核心链路完成三个开源项目,覆盖检索增强(带评测)、工具调用(带安全护栏)、多智能体协作(带可观测)。"——先给招聘方一张"能力全景图",再让三条经历逐一坐实。这一句,把"三个练手"升维成"一套体系"。
L06

整份简历的结构(转行版)

🤔 痛点经历会写了,可整份简历各部分怎么排、什么该突出、什么该弱化?转行者的排法和科班应届生不一样——你的强项是作品,不是学历或对口经验。
💡 本质转行简历的排序原则:把最能证明"你能干这行"的东西放最前面——也就是项目作品。学历/过往行业经历该留但往后放、简写。让招聘方 15 秒内看到你的作品和数字。
板块放什么转行者要点
① 顶部信息姓名 / 求职意向 / GitHub / 博客链接GitHub 链接务必放最显眼处
② 一句话概述"从 X 转型 Agent 开发,完成 3 个开源项目……"点明转行 + 亮出作品
③ 项目经历 ⭐三件作品,STAR + 数字 + 链接(L05)最重头,占最大篇幅
④ 技术栈语言/框架/工具关键词,分层标注集中放,别散落充数(L04)
⑤ 学习/开源系统学习经历、开源 PR、技术博客体现持续投入与真实足迹(Day65)
⑥ 教育/过往学历、原行业经历简写;能挖掘可迁移能力更好
👶 原来的行业经历(比如我做过销售/运营)要删掉吗?不删,但换个角度写。挖掘"可迁移能力":做过销售→"擅长理解用户需求、沟通落地";做过运营→"数据驱动决策的意识"。这些软实力配上你的技术作品,反而是差异化优势——纯技术背景的人未必有。诚实呈现转行路径,比假装科班更可信、更有故事。
L07

今日小结 + 动手 10 分钟

🧠 今天你应该能回答

  • 为什么简历是"证据清单"而不是"技能罗列"?形容词 vs 证据的区别?
  • STAR 简历版三段式是哪三段?(问题→方案(取舍)→指标)
  • 简历上的数字从哪来?为什么"带过程的数字"比孤零零的漂亮数字好?
  • 为什么不能堆名词?技术栈关键词的正确放法?"精通"为什么慎用?
  • 转行简历怎么排序?为什么项目经历要放最前、占最大篇幅?

✋ 动手 10 分钟:把作品①写成一条 STAR 经历

套用"问题→方案→指标"三段式,给你的作品① 写一条真实简历经历(数字用你自己评测出来的,没有就先占位、跑完评测再填):

**文档知识库问答助手(RAG)** · github.com/你的名字/rag-assistant
- 问题:______(谁、遇到什么麻烦)
- 方案:______(你怎么做,写出 1 个关键取舍,如"切块 500+50 重叠、强制出处防幻觉")
- 指标:答对率 __%(自测得来)、单次回答 < __ s、已容器化部署

自检三条:①有没有具体数字?②有没有讲出一个取舍(体现判断力)?③有没有GitHub 链接?三个都有,这就是一条能打动招聘方的经历。三件作品都这么写一条,你的简历核心就成型了。

明日预告 · Day 67:简历投出去,面试就来了!接下来两天是面试冲刺。Day 67 过概念题:RAG、Agent、评测、上下文、幻觉这些高频问答逐条突击,把你 66 天学的知识点转成"能张口就答"的面试语言。Day 68 练系统设计题 + 68 天总复盘收官。终点在望,冲刺!
← Day 65 · GitHub / 博客 / 开源 Day 67 · 面试冲刺① 概念题 →