项目经历怎么写进简历：每项贡献对应证据
项目经历的说服力来自可解释的因果关系：约束是什么，方案如何改变请求处理过程，又付出了什么代价。先讲机制与取舍，再用代码、设计记录或实验输出说明结论成立的条件。例如，索引可能减少扫描，却增加写入维护成本；只有执行计划变化，还不能推出接口整体提速。
据此按“业务问题—个人改动—验证结果—适用条件”写两至三条贡献。只有本地实现，就写个人实践；只有阅读理解，就放在学习记录中。
1. 先核对职责
逐项列出自己独立实现、协作参与和仅了解的模块。协作内容说明自己的接口或交付物；公开项目介绍可用来理解场景，不能据此填写任职、上线规模或业务收益。先读站内 没有真实做过怎么描述，再检查主语是否准确。
给准备写进简历的贡献建立如下表格，不必为了填满表格增加组件。
| 准备表达的内容 | 至少准备什么证据 | 没有证据时如何处理 |
|---|---|---|
| 负责工单状态流转 | 状态图、个人提交、正常与非法状态输入输出 | 只描述实际实现的状态和接口 |
| 完成知识库权限过滤 | 测试身份、检索结果、上下文与响应检查记录 | 补做验证，暂不宣称权限隔离完整 |
| 优化 SQL 查询 | SQL、索引、数据分布、执行计划、测量条件 | 陈述完成索引实验，去掉收益数字 |
| 改进 RAG 回答质量 | 固定题集、文档快照、前后配置、逐题结果 | 说明评估与失败分类，不预填正确率 |
2. 把实现过程改写成贡献
每条先写具体对象与动作，再给出验证。下面只是待填写的结构，方括号应替换成自己的事实，未完成的部分删去。
在[工作项目/个人实践]中，为[具体使用者与问题]，
我实现[接口或模块]，采用[关键方案及原因]；
通过[样本、命令或测试]核对[实际结果]，
当前范围是[环境、数据和未覆盖场景]。写知识库时，说明处理哪类文档、如何保存版本、检索是否受权限约束、无证据如何响应。写工单时，说明状态如何变更、重复请求如何处理、失败如何恢复。组件名称附在实现说明里即可。
原站 企业知识库项目问答 可帮助整理追问，使用时只保留自己做过的环节，替换其中的角色与结果。
3. 核实数字与技术含义
性能数据至少说明硬件、版本、数据量、并发方式、预热和采样次数；对比实验保持其他条件一致，保留失败请求。没有稳定测量时，可用“覆盖哪些异常分支”描述验收结果。
MySQL 8.4 的 EXPLAIN ANALYZE 实际执行语句，并以 TREE 格式报告迭代器的耗时、返回行数和循环次数。多次循环时，耗时是每次循环的平均值；父节点耗时包含子节点，不能把各层耗时直接相加当作总耗时。它有助于定位查询开销，但接口还包含连接等待、网络和应用处理，执行计划截图不能单独证明接口整体提速。核对时在本地测试库使用只读查询，并记录实际数据库版本。MySQL 官方手册
RAG 要区分答案是否符合参考答案、是否有召回证据支持，以及检索是否相关。不要把某个向量分数写成准确率。每个比例说明题集、分母和判断规则。LangChain 官方评估教程
同一条回答可能在不同维度上得到相反评价。下面按官方教程的比较对象拆开判断；失败原因是排查方向，不是已运行的实验结论。
| 维度 | 比较对象 | 失败时先检查什么 |
|---|---|---|
| 正确性 | 回答与参考答案 | 是否漏掉关键条件；参考答案是否与文档版本一致 |
| 证据支持度（groundedness） | 回答与召回文档 | 结论是否超出上下文；是否引用了不支持结论的段落 |
| 回答相关性 | 回答与用户问题 | 是否答非所问，即使引用内容本身正确 |
| 检索相关性 | 召回文档与用户问题 | 分块、查询表达或过滤是否使相关内容未进入上下文 |
例如，模型忠实复述过期文档时，证据支持度可能合格，正确性仍可能失败；因此不能用“有引用”代替“答案正确”。若使用模型裁判，还应记录裁判模型、提示词和人工复核方式，使前后结果可比较。
4. 做一次证据驱动的追问
每条贡献准备三个回答：为什么选择这个方案，哪个失败样本暴露了问题，换一种约束会如何调整。用一分钟交代背景和职责，再用三分钟沿请求链讲实现；录音后检查是否混淆团队成果与个人贡献。
证据索引可记录条目编号、提交、运行命令和结果位置。工作资料只保留可授权展示的脱敏内容；不能公开源码时，用流程、接口契约和可说明的验证方法支撑表达。
适用边界
本方法用于整理已有经历，不能替代项目实施，也不保证求职结果。本地题集和模拟数据只说明对应实验；没有上线与运营证据时，不使用生产规模、收入或效率提升等结论。
参考资料
MySQL EXPLAIN 手册 用于核对查询证据；LangChain RAG 评估教程 用于核对质量指标含义。