RAG 与 Agent 项目怎么写进简历？问题—动作—指标—证据模板
RAG 或 Agent 项目经历应写成“问题—动作—指标—证据”：先交代受约束的业务或工程问题，再写你亲自完成的关键动作，用有口径的测量结果说明变化，最后给出可核验材料。没有真实指标时可以写验收方式和已观察结果，但不能补造百分比、用户规模或业务收益。
先说结论
一段项目经历通常由一句项目定位和两到四条要点组成。每条要点只承担一个结论：
为解决【问题】，我负责【动作】；在【评估范围与条件】下，【指标或验收结果】；证据为【代码、测试、评估记录、日志或文档】。
这不是要求把四个标签原样塞进简历，而是确保每个亮点都能回答“为什么做、你做了什么、如何判断、怎么证明”。
适合谁，不适合谁
本文适合有个人项目、课程改造项目或真实工作项目，准备投递 AI 应用开发、RAG、Agent 或 AI 平台相关岗位的开发者。
本文不提供可直接冒充经历的成果数据。若项目涉及公司保密信息，应使用经允许的抽象描述、范围或脱敏证据；无法公开不等于可以虚构。
四段法分别写什么
| 部分 | 要回答的问题 | 可写内容 | 不应写 |
|---|---|---|---|
| 问题 | 为什么需要这项工作 | 检索不准、输出不可解析、工具越权风险、延迟不可控 | 空泛的“赋能业务” |
| 动作 | 你具体负责什么 | 设计链路、实现过滤、建立评估集、增加预算与降级 | 只列框架和模型名 |
| 指标 | 如何判断动作有效 | 固定样例结果、错误类别、延迟分位、成本口径、验收通过项 | 无来源的提升百分比 |
| 证据 | 面试官如何核验 | PR、测试、评估报告、日志样例、设计文档、演示步骤 | 无法解释的截图或口头结论 |
“指标”不等于必须写增长数字。对个人项目，Schema 校验是否通过、越权请求是否被拒绝、无证据问题是否返回未知、故障演练是否触发降级，都可以是可重复的验收结果。
先写一句项目定位
项目定位建议包含场景、核心链路和你的职责边界：
面向【用户/场景】的【系统类型】，覆盖【关键链路】；本人负责【明确模块】，项目性质为【个人练习/课程改造/工作项目】。
示意：
个人练习项目：面向授权文档问答的 RAG 服务，覆盖导入、检索、引用回答与离线评估；本人实现后端查询链路和评估脚本。
这句话只演示结构，不代表真实项目。请替换成可核验事实，并删去未完成的模块。
RAG 项目怎么套用
问题
从具体失败现象中选一个：
- 关键词和语义表达不一致导致相关文档漏召回；
- 文档更新后旧切片仍参与检索；
- 不同用户可能检索到无权访问的内容；
- 回答没有引用，无法核验来源；
- 调整 Chunk、Top-K 或重排后无法判断是否回归。
动作
只写自己做过且能解释的动作，例如：
- 拆分索引与查询链路，记录文档、切片和索引版本；
- 在检索前加入服务端权限过滤，不依赖 Prompt 隐藏内容；
- 建立固定问题集，分别评估检索命中和最终回答；
- 为回答保留引用，并在无可靠证据时返回未知；
- 对候选检索方案保存参数、运行条件和错误样例。
指标与证据
优先使用项目真实记录：评估集规模、命中定义、候选版本对比、错误分类、运行环境和日志。若没有可靠数字，可以写：
建立覆盖正常、无答案、权限和文档更新场景的固定评估集；每次检索配置变更运行回归，并保留失败样例与参数记录。
这是一条过程与证据表达，不宣称未经测量的提升。
Agent 项目怎么套用
Agent 项目不要只写“使用某框架实现智能决策”。更有区分度的问题包括：
- 工具参数可能不符合业务 Schema；
- 模型可能选择无权限或高风险工具；
- 多步执行可能循环、超时或重复产生副作用；
- 外部工具部分成功后，系统状态难以恢复；
- 计划、调用、审批和结果之间缺少审计链路。
对应动作可以是工具 allowlist、运行时参数校验、服务端鉴权、幂等键、总超时、最大步数、人工确认、补偿状态和审计记录。指标应围绕这些边界测量，而不是把“能调用工具”当作完成。
示意表达：
针对工具参数错误与重复执行风险，为允许调用的工具定义运行时 Schema、总超时和幂等键；通过故障样例验证非法参数被拒绝、重复请求不产生第二次副作用，并保留测试与审计日志。
仍需根据你真实实现的范围删改，不能直接当作经历使用。
把弱表达改成可追问表达
弱表达：
使用向量数据库、Embedding 和大模型完成企业级 RAG，显著提升准确率。
改写步骤：
- 问题：明确是哪类查询或权限问题；
- 动作：只保留自己设计和实现的部分；
- 指标：补评估集、基线和口径，或删除“显著提升”；
- 证据：指出测试、报告或仓库位置。
不带虚构数字的结构示意：
针对【真实失败类型】，实现【本人完成的检索/权限/评估动作】；在【固定评估范围】对比【真实基线与候选方案】，记录【实际指标与错误分类】；相关证据见【具体材料】。
没有生产数据时怎么写
个人项目可以使用以下层级，按真实情况选择：
- 实现证据：核心链路有代码、测试和可复现步骤；
- 评估证据：固定样例与断言可重复运行；
- 故障证据：超时、无答案、越权、工具失败能被触发和观察；
- 部署证据：说明部署环境和限制，但不声称生产规模；
- 用户证据：只有确有授权记录时才描述使用情况。
“本地压测”“课程项目”“个人部署”都可以诚实写；不要替换成“生产验证”“服务大量用户”或“带来业务增长”。
一页简历如何取舍
- 项目定位一句，避免长篇业务背景；
- 每条亮点只写一个问题和一个主要动作；
- 保留与目标 JD 最相关的两到四条；
- 技术栈放在动作中体现，不单独堆十几个名词；
- 每个指标都准备口径、基线和失败样例；
- 每个“负责、设计、优化”都能解释你的决策边界。
常见误区与失败边界
- 把团队成果全部写成个人成果：应区分个人职责与协作结果。
- 只有动作没有问题：面试官无法判断技术选择是否必要。
- 只有指标没有口径：数字越精确，越需要基线和原始记录。
- 把框架能力当成自己的实现：应说明调用、配置、扩展或自研的边界。
- 用“企业级”“高并发”“高准确率”代替证据：这些词本身不可核验。
- 所有项目使用同一组亮点：RAG 应突出检索与评估，Agent 应突出工具与状态边界。
可执行检查清单
- [ ] 每条经历都能拆成问题、动作、指标、证据
- [ ] 项目性质和个人职责边界真实明确
- [ ] RAG 指标区分检索与最终回答，不混成一个“准确率”
- [ ] Agent 描述包含工具权限、状态或失败处理，而不只写编排框架
- [ ] 所有数字都有样例范围、基线、条件和记录
- [ ] 没有数据时已改写为可验证的验收与证据
- [ ] 没有虚构用户、Offer、薪资、成功率或生产规模
- [ ] 每个亮点都已准备至少一个追问答案
下一步
回到 AI 求职与面试 Hub 可以检查简历内容与目标岗位是否一致。完成四段式表达后，下一步使用 AI 项目深挖追问框架，逐条验证架构、评估、成本、故障与取舍是否经得住追问。