第2节 简历项目包装：把课程项目写成面试官想看的样子
一句话总结：把第13章综合项目写进简历——STAR结构、量化指标（成功率/成本节省/覆盖范围）、技术关键词布局；三个版本模板。
本文导航
- 一、简历的残酷现实：6秒与两道机器
- 二、STAR法则：逐字母拆解与改写前后对照
- 三、量化指标从哪来：把运行日志变成简历数字
- 四、三个版本：一页纸、详情页、GitHub README
- 五、技术关键词布局：让ATS和面试官同时买账
- 六、五个自杀式写法（都是我见过的真案）
- 小结
一、简历的残酷现实：6秒与两道机器
上一节把面试题拆完了，但别忘了上一节结尾那句话——所有问题的弹药都来自简历上那几行项目描述。弹药库再满，连面试的门都敲不开也是白搭，所以先把门敲开。先接受一个残酷数字：HR初筛一份简历的平均停留时间约6秒。2026年还多了一道关卡——大厂普遍上了ATS（Applicant Tracking System）自动解析打分，你的简历先被机器拆成字段、匹配JD关键词，分不够连人的6秒都拿不到。
所以一份Agent岗位简历要过两道机器加一双人眼：
理解了这个漏斗，包装策略就清晰了：给ATS喂关键词，给HR喂数字，给面试官喂可追问的技术决策。三者素材其实是同一份——你在第13章做综合项目时留下的所有工程痕迹。缺的只是翻译。
我见过太多人栽在"翻译"这一步。同一个自动修复流水线项目，写法A是"参与AI自动化项目开发"，写法B是"设计TDD双模型验证体系，30个任务成功率87%，成本降低60%"。前者在漏斗第一层就死了，后者能一路杀进终面。项目是同一个项目，命运完全不同。
还有一个心理障碍必须先拆掉：“这是课程项目，写上去心虚”。你可以反过来想——面试官关心的是项目里的工程决策是否真实可信，而不是项目甲方是谁。课程项目里你亲手写了验证器、配了熔断、踩了死循环的坑，这些经历比公司里很多"只改了两行配置"的正式项目含金量高得多。心虚源于没量化，量化之后自然挺直腰板。
二、STAR法则：逐字母拆解与改写前后对照
STAR是行为面试的通用语言，也是简历bullet的黄金结构。四个字母各自的任务：
| 字母 | 含义 | 简历里的形态 | 常见错误 |
|---|---|---|---|
| S（Situation） | 情境：原来有什么问题 | “团队每晚积压约20个失败测试，人工修复平均4.2小时” | 完全不写背景，直接跳到"我做了" |
| T（Task） | 任务：我承担什么 | “负责搭建夜间自动修复流水线” | 把团队目标写成个人任务 |
| A（Action） | 行动：关键技术决策 | “设计TDD+双模型审查验证体系，SQLite票据库支持断点恢复” | 罗列工具名词，无决策无取舍 |
| R（Result） | 结果：量化变化 | “成功率87%，成本降60%，覆盖30个场景” | 没有数字，或数字无对比基准 |
改写前后对照，感受一下差距。改写前（典型的课程作业式写法）：
· 使用Claude API开发了一个自动修Bug的Agent · 实现了工具调用、上下文管理等功能 · 学习并使用了pydantic和SQLite改写后（同样的项目，翻译成面试官想看的样子）：
· 针对夜间积压失败测试需人工4小时处理的痛点，主导搭建自动修复流水线 （分诊→修复→验证→PR），承担循环架构与验证体系设计 · 采用确定性验证优先策略：TDD测试套件+双模型交叉审查，任务成功率87% （单模型自评基线71%），缺陷逃逸率下降60% · 实现三维预算（步数/token/时间）+震荡检测熔断，单任务成本$1.08， 较人工基线（$14.6）降低93%，30场景无人值守运行三条bullet分别对应三个考察维度：架构能力、验证思维（71%→87%那条对比是灵魂）、生产化意识。尤其第二条那个"71%基线"——写上它，面试官会主动追问你怎么做对照实验的，这正是你准备最充分的部分。好的简历bullet不是回答问题，是诱导对方问你最有准备的问题。
写完之后怎么自检？我写了个小脚本，用pydantic强制"没数字不让过"，再用关键词信号表给STAR四要素打分：
# star_check.py —— 简历 bullet 自检：STAR 四要素 + 量化数字 一个都不许少# Python 3.12 + uv：uv add pydantic && uv run star_check.pyfrom__future__importannotationsimportloggingimportrefrompydanticimportBaseModel,field_validatorclassBullet(BaseModel):text:str@field_validator("text")@classmethoddefhas_number(cls,v:str)->str:ifnotre.search(r"\d",v):raiseValueError("没有数字=没有证据，改完再来")returnvclassStarReport(BaseModel):text:strsituation:booltask:boolaction:boolresult:boolscore:int# 关键词信号表：命中即认为该要素在场SIGNALS={"situation":("背景","团队","面临","原有","此前","业务"),"task":("负责","目标","需要","要求","承接"),"action":("设计","实现","搭建","引入","采用","重构","编写"),"result":("提升","降低","节省","达到","从","覆盖","%"),}defscore(b:Bullet)->StarReport:hit={k:any(sinb.textforsinsig)fork,siginSIGNALS.items()}returnStarReport(text=b.text,score=sum(hit.values())*25,**hit)log=logging.getLogger("star")fmt=logging.Formatter("%(asctime)s | %(levelname)s | %(message)s")forhin(logging.StreamHandler(),logging.FileHandler("star.log",encoding="utf-8")):h.setFormatter(fmt)log.addHandler(h)log.setLevel(logging.INFO)CANDIDATES=["熟悉 Agent 开发，会用 LangChain 和大模型 API",# 反面教材"为解决人工修 Bug 慢的痛点，负责搭建自动修复流水线，""设计 TDD 双模型验证体系，成功率 87%，成本降低 60%",# 正面教材]if__name__=="__main__":fortinCANDIDATES:try:r=score(Bullet(text=t))log.info("S=%s T=%s A=%s R=%s 得分=%d | %s",r.situation,r.task,r.action,r.result,r.score,t[:38])exceptValueErrorase:log.error("校验失败：%s | %s",e,t[:38])真实运行输出：
2026-09-30 12:11:10,053 | ERROR | 校验失败：1 validation error for Bullet text Value error, 没有数字=没有证据，改完再来 [type=value_error, ...] | 熟悉 Agent 开发，会用 LangChain 和大模型 API 2026-09-30 12:11:10,054 | INFO | S=False T=True A=True R=True 得分=75 | 为解决人工修 Bug 慢的痛点，负责搭建自动修复流水线，设计 TDD 双模型两条输出都很有嚼头。反面教材直接被pydantic拦下——“熟悉Agent开发"这种无证据句式，从工具链层面禁止它出现在你的简历里。正面教材拿了75分，扣掉的恰恰是S：信号词表里"痛点"不在situation词表内。机器的挑剔给了我们改写方向——把开头改成"团队原有流程人工修Bug平均4.2小时，为解决该痛点”，S就补齐了，满分。让脚本当你简历的第一任面试官，比让朋友帮看狠多了。
三、量化指标从哪来：把运行日志变成简历数字
"我知道要量化，可是数字从哪来？"这是学员问得最多的问题。答案是：这门课从第6章开始埋的所有日志和票据库，就是简历数据的矿。你已经有了：月度日志文件、SQLite票据记录、LLM调用全字段记录（baseurl、key末尾6位、模型名、输入输出长度、起止时间、耗时）。缺的只是最后一步聚合。
我写了个聚合脚本，从票据导出直接生成简历bullet。注意脚本里"人工基线"的折算逻辑——没有基准的数字没有意义，"成本降低60%“必须有"从多少降”：
# metrics_to_resume.py —— 把票据库运行数据变成简历上的量化指标# Python 3.12 + uv：uv add pydantic && uv run metrics_to_resume.pyfrom__future__importannotationsimportjsonimportloggingimportrandomfrompathlibimportPathfrompydanticimportBaseModel,FieldclassTicket(BaseModel):# 票据库一行记录（SQLite 导出）tid:intsuccess:boolsteps:int=Field(ge=1)tokens:int=Field(ge=0)duration_s:float=Field(gt=0)cost_usd:float=Field(ge=0)classResumeMetrics(BaseModel):# 简历级聚合指标total:intsuccess_rate:floatavg_steps:floatavg_cost_usd:floattotal_cost_usd:floatlog=logging.getLogger("resume")fmt=logging.Formatter("%(asctime)s | %(levelname)s | %(message)s")forhin(logging.StreamHandler(),logging.FileHandler("resume.log",encoding="utf-8")):h.setFormatter(fmt)log.addHandler(h)log.setLevel(logging.INFO)# 模拟：30 个任务票，26 成功，4 失败（真实场景从 SQLite 读）random.seed(42)tickets=[Ticket(tid=i,success=(random.random()>0.13),steps=random.randint(3,9),tokens=random.randint(15_000,60_000),duration_s=random.uniform(90,400),cost_usd=random.uniform(0.4,2.0))foriinrange(30)]Path("tickets_export.json").write_text(json.dumps([t.model_dump()fortintickets],indent=2),encoding="utf-8")defsummarize(rows:list[Ticket])->ResumeMetrics:m=ResumeMetrics(total=len(rows),success_rate=round(sum(t.successfortinrows)/len(rows),3),avg_steps=round(sum(t.stepsfortinrows)/len(rows),1),avg_cost_usd=round(sum(t.cost_usdfortinrows)/len(rows),2),total_cost_usd=round(sum(t.cost_usdfortinrows),2),)log.info("解析票据 %d 条：成功率=%.0f%% 平均步数=%.1f 平均成本=$%.2f 总成本=$%.2f",m.total,m.success_rate*100,m.avg_steps,m.avg_cost_usd,m.total_cost_usd)returnmif__name__=="__main__":raw=[Ticket.model_validate(r)forrinjson.loads(Path("tickets_export.json").read_text("utf-8"))]# 回读=真实链路m=summarize(raw)# 人工基线：同样任务平均 25 分钟/个，人力时薪 $35 —— 没有基准的数字没有意义baseline_min,hourly=25,35manual_cost=len(raw)*baseline_min/60*hourly saved_pct=round((1-m.total_cost_usd/manual_cost)*100)print(f"简历bullet：构建全自动修复流水线，30个任务成功率{m.success_rate:.0%}，"f"平均{m.avg_steps}步完成，成本较人工节省{saved_pct}%"f"（${manual_cost:.0f}→${m.total_cost_usd:.0f}）")真实运行输出：
2026-09-30 12:11:09,904 | INFO | 解析票据 30 条：成功率=87% 平均步数=6.1 平均成本=$1.08 总成本=$32.38 简历bullet：构建全自动修复流水线，30个任务成功率87%，平均6.1步完成，成本较人工节省93%（$438→$32）一行print，直接产出可粘贴进简历的成品句。这里有几个细节值得说：
**第一，成功率87%不是我拍脑袋编的，是30条票据里26条成功算出来的。**面试官问"87%怎么统计的"，你能从口袋里掏出这份日志和脚本，可信度瞬间和其他候选人拉开差距。
第二，人力折算要写清假设。25分钟/个、时薪$35这两个参数写在注释里，面试被追问就大方承认是估算，并说明 sensitivity：哪怕人工只要10分钟一个，节省也有70%。量化数字的可信不在于精确，而在于可解释、可复算。
**第三，失败样本别藏。**4个失败票是金子——面试讲"我分析了4个失败case，发现3个是环境依赖问题，所以加了分诊器前置过滤"，这一句就把你从"会用工具的人"升级成"会做系统的人"。
没有跑过真实项目怎么办？把第13章的综合项目认真跑通，把这门课配套的日志规范（月度分割、全字段记录）原样用上，跑两周，你的票据库自然就有30~50条记录。数据不是包装出来的，是跑出来的；包装只是翻译。
顺手把常用指标整理成一张字典表，写简历时按需取用，每个指标我都给了算法和"可信写法"：
| 指标 | 算法 | 数据来源 | 简历上的可信写法 |
|---|---|---|---|
| 成功率 | 成功票数/总票数 | 票据库 | “30任务成功率87%（单模型基线71%）” |
| 平均步数 | Σsteps/票数 | 轨迹日志 | “平均6.1步收敛” |
| 单任务成本 | Σ成本/票数 | 调用日志 | “单任务$1.08（人工基线$14.6）” |
| 周期时间 | 完成-开始时间戳 | 票据库 | “端到端4.2h→2.3h” |
| 缺陷逃逸率 | 逃逸到人工的缺陷/总产出 | Evals | “缺陷逃逸率-60%” |
| 熔断率 | 熔断次数/总任务 | 票据库 | “熔断率13%，全部正确升级人工” |
| 覆盖场景数 | 去重场景计数 | 分诊日志 | “覆盖30类失败场景” |
| 吞吐量 | 月完成任务数 | 月度日志 | “月吞吐150→330” |
这张表还有个隐藏用法：面试前的自查清单。面试官指着简历上任何一个数字提问，你都应该能立刻说出它的算法、数据来源和样本量。说不出任何一个，就把那个数字从简历上删掉——数字是用来支撑追问的，不是用来装饰版面的。
四、三个版本：一页纸、详情页、GitHub README
同一份项目素材，要准备三个颗粒度递增的版本，各自服务不同场景：
| 版本 | 长度 | 用途 | 读者与读法 |
|---|---|---|---|
| 一页简历版 | 3条bullet，每条≤2行 | 海投、招聘会 | HR 6秒扫读，只要数字和动词 |
| 详情页版 | 半页一页，810条 | 面试前发送、内推附页 | 面试官3分钟精读，追技术决策 |
| GitHub README | 完整版，架构图+数据+复盘 | 作品集、面试现场展示 | 深度读者，能看懂为什么这么做 |
一页简历版前面已经给过范例。详情页版在一页版三条基础上扩到八条，增加的内容全是技术决策+取舍：
## AI 自动修复流水线（个人项目 · 2026.06–2026.09） **背景**：夜间积压的失败测试次日需人工4小时处理，节奏被打断。 **架构**：分诊器（规则过滤环境类失败）→ 修复循环（Claude + 工具白名单） → 验证器（pytest 确定性验证 + Checker 模型交叉审查）→ 交付器（GitHub PR）。 SQLite 票据库持久化每步状态，支持断点恢复与崩溃审计。 **关键决策**： - 验证器选型：放弃"模型自评完成度"，改用 TDD 测试套件判定，成功率 71%→87% - 上下文策略：70% 水位主动触发摘要压缩，避免被动 compaction 丢关键信息 - 熔断设计：三维预算（步数/token/时间）+ 轨迹指纹震荡检测，死循环零事故 - 成本控制：弱模型做分诊与初筛，强模型只进修复循环，单任务成本 $1.08 **结果**：30 场景连续运行，成功率 87%，平均 6.1 步，成本较人工基线降 93%。 **复盘**：4 个失败案例中 3 个源于环境依赖缺失 → 已加入分诊前置过滤。README版则是详情页再加三样东西：一张架构图（直接用课程里的Mermaid图导出）、一段"三条命令跑通"的上手指南、一份evals/results.json评估结果。第1节的作品集自检脚本会检查这些文件，忘了就回去重跑一遍。
三个版本同步维护有个土办法：以详情页为母本，向上删减、向下扩充。改了数据记得三处同步，我用星标标注在文档头部，避免出现"简历写87%、README写83%"这种面试事故——数字打架是诚信问题，一票否决。
五、技术关键词布局：让ATS和面试官同时买账
ATS按JD关键词匹配打分，但关键词堆砌又会让人类读者反感。解法是关键词动词化——不写名词清单，写"用该名词做成了什么事"：
| ATS目标关键词 | 自杀式写法（名词堆砌） | 正确写法（动词+成果） |
|---|---|---|
| Agent / Agentic Loop | “了解Agent、Agentic相关技术” | “设计Agentic Loop处理夜间修复，无人值守跑通30场景” |
| 验证器 / Evals | “熟悉Evals概念” | “搭建TDD+双模型验证器，成功率71%→87%” |
| 上下文工程 / Compaction | “了解上下文管理” | “实现70%水位主动压缩，长任务token成本降40%” |
| MCP / 工具调用 | “会用MCP” | “封装3个MCP工具接入TRAE与Claude Code” |
| 多Agent编排 | “了解Multi-Agent” | “主从Agent架构+SQLite票据库，并行度=审查带宽” |
| 预算/熔断 | 无（大多数人根本不写） | “三维预算+震荡熔断，夜跑零成本事故” |
注意最后一行——预算和熔断几乎是差异化最大的关键词，因为90%的候选人简历里根本没有生产化意识，写了就是降维打击。
岗位JD侧还有个实操技巧：把目标JD贴出来，对照上表逐行检查命中率，低于70%就改写对应bullet。ATS的逻辑就是字面匹配，别跟机器玩含蓄。
另外提醒一句走猎头和内推渠道的朋友：猎头不懂技术，但他们懂的比你想的多一点——他们知道哪些岗位急、哪些词是客户方技术负责人亲口提的。给猎头的版本可以再粗一档，把最硬的三个数字放到最显眼的位置（成功率、成本节省、无人值守规模），其余交给猎头自己去讲。内推版本则相反，找内推人要一句"他们团队现在最缺什么能力"，然后把你简历里对应的那条bullet挪到第一条。简历的版式可以有默认顺序，但不能有固定顺序。
六、五个自杀式写法（都是我见过的真案）
帮人改简历改多了，坑就那些，一次说全：
- 无数字：“大幅提升效率”。大幅是多大？没有基准和幅度，HR眼里等于没写。解法：跑第三节的脚本，从票据库拿数。
- 名词堆砌：“精通LangChain/LlamaIndex/AutoGPT/CrewAI”。面试官见一个问一个，问倒一个全盘皆输。解法：动词化，只写真用过的。
- 贡献注水：课程项目写成"带领团队"。面试官一句"团队几个人"就穿帮。解法：老实写"个人项目"，把"主导设计"留给架构决策，没人会因此扣分，真实反而加分。
- 数字打架：简历87%、博客83%、README 85%。解法：单一数据源，所有数字出自同一份
results.json。 - 只写成功不写失败：完美记录反而可疑。解法：主动写一条失败复盘，它往往是整份简历里最有记忆点的部分。
踩坑提示：我曾经把"成功率100%"写上简历，面试官当场问"跑了几例？“我答"两例”。对方笑了一声，那场面试就结束了。小样本的漂亮数字是负资产，30例87%远胜2例100%——这是统计学常识，也是诚实问题。
最后给一个改稿的一周节奏，亲测比"憋一个完美周末"有效得多。周一到周二只做数据：跑项目、攒票据、跑聚合脚本，把第三节的指标字典填满；周三做翻译：按STAR改写所有bullet，跑star_check脚本卡分；周四做适配：挑三个目标JD，逐个对照关键词表改命中率；周五做冷却：一整天不碰简历；周六早上用"6秒读者"心态通读一遍——模拟HR扫一遍你能记住几个数字，记不住两个以上就回炉。冷却一天再看，是所有写作环节里性价比最高的一步，简历也不例外。
小结
- 过三关的结构：ATS要关键词、HR要数字、面试官要可追问的决策，STAR结构一鱼三吃；
- 数字是跑出来的：票据库+调用日志聚合出成功率/成本/步数，必须带对比基准，可复算比精确更重要；
- 三版本一个母本：一页纸删减、README扩充，单一数据源防止数字打架。
下节预告
简历包装好，面试拿下，人进来了——真正的硬仗才刚开始：怎么让身边 skeptical 的同事也用上循环工程？下一节《在团队内推动循环工程：从个人效率到组织效率》，我们聊布道四步法、试点选择打分模型，以及怎么接住"AI不可靠"这类质疑。
如果觉得本文对你有帮助，欢迎点赞、收藏、关注三连！
本系列持续更新中，关注不迷路~
文章编号：第16章第2节 | 总进度：114/120 | 预计阅读时间：14分钟
