6.3 展示贡献：个人职责与能力证明¶
让别人知道你解决了什么问题、做出了什么决策¶
个人贡献不是“我写了多少行代码”
6.2 完成答辩后，你能够把项目整体讲清楚。但答辩和简历中经常会被追问：“你具体做了什么？” 如果只能回答“我们一起做的”，就无法证明个人能力。
本节将帮助你明确自己在项目中的具体职责，用 Git 提交、设计文档、测试报告等证据支持，形成一份个人贡献说明，可复用于答辩、简历和作品集。
本节学习目标
明确个人在项目中的技术贡献、过程贡献和协作贡献；用证据支持每项贡献；形成 1—2 页个人贡献说明，可复用于答辩、简历和作品集；准备个人技术亮点清单，可写入简历。
🎯 本节完成后，你要交付¶
| 成果 | 要求 |
|---|---|
| 个人贡献说明 | 1—2 页，明确职责、成果、问题和成长 |
| 关键成果证据链接 | Git 提交、设计文档、测试报告、演示视频 |
| 能力自评与教师评价对照表 | 对比自评与教师评价，识别差距 |
| 个人技术亮点清单 | 3—5 项，可写入简历 |
个人贡献必须真实
不要虚构职责、夸大贡献或占用他人成果。Git 提交记录、设计文档和测试报告是可验证的证据，虚构内容无法经受追问。
一、为什么要明确个人贡献¶
1. 答辩和面试中的高频追问¶
| 场景 | 追问 | 期望回答 |
|---|---|---|
| 答辩 | “你在团队中负责什么？” | 明确职责、展示证据、说明协作方式 |
| 简历 | “项目描述中的‘负责 XX’具体指什么？” | 具体模块、关键决策、量化成果 |
| 面试 | “这个功能是你做的还是队友做的？” | 诚实区分，展示自己的真实贡献 |
2. 个人贡献与团队贡献的区别¶
| 团队贡献 | 个人贡献 |
|---|---|
| “我们开发了失物招领平台” | “我负责后端用户认证和失物管理模块，设计并实现 JWT 鉴权和角色权限控制” |
| “我们完成了测试” | “我编写了 15 个测试用例，覆盖登录、核心流程和权限场景，发现并修复 3 个 P0 缺陷” |
| “我们完成了部署” | “我编写 Docker Compose 配置，实现 MySQL、后端、前端、Nginx 一键部署” |
3. 个人贡献的价值¶
- 答辩：让评委知道你的具体职责和贡献；
- 简历：提供可验证的项目经历；
- 面试：准备应对追问的回答；
- 复盘：识别自己的强项和弱项，为后续学习提供方向。
二、个人贡献的四个维度¶
个人贡献不只是写代码，还包括过程贡献、协作贡献和 AI 协作贡献。
1. 技术贡献¶
技术贡献是你具体负责的模块、关键技术决策和解决的问题。
| 维度 | 内容 | 证据 |
|---|---|---|
| 模块负责 | 负责哪些后端模块、前端页面或数据库设计 | Git 提交记录、模块代码 |
| 关键决策 | 技术选型、架构设计、数据库设计 | 设计文档、对比分析表 |
| 问题解决 | 遇到的技术难题、根因分析、解决方案 | 问题排查记录、修复提交 |
| 质量保障 | 编写的测试用例、缺陷修复、回归验证 | 测试报告、缺陷清单 |
| 部署实施 | Docker 配置、部署文档、环境验证 | Dockerfile、docker-compose.yml、部署记录 |
2. 过程贡献¶
过程贡献是你在项目过程中承担的非编码工作。
| 维度 | 内容 | 证据 |
|---|---|---|
| 需求分析 | 参与需求调研、编写需求文档 | 需求分析说明书、调研记录 |
| 设计评审 | 参与架构设计、数据库设计评审 | 设计文档、评审记录 |
| 测试验证 | 编写测试计划、执行测试、记录缺陷 | 测试计划、测试用例、缺陷清单 |
| 部署实施 | 编写部署文档、执行部署验证 | 部署说明、部署验证记录 |
| 文档编写 | 编写 README、API 文档、用户手册 | README、API 文档 |
3. 协作贡献¶
协作贡献是你在团队协作中发挥的作用。
| 维度 | 内容 | 证据 |
|---|---|---|
| 沟通协调 | 组织会议、协调任务、解决冲突 | 会议纪要、任务看板 |
| 代码审查 | 审查队友代码、提出改进建议 | 代码审查记录、PR 评论 |
| 文档编写 | 编写团队文档、整理知识库 | 团队文档、知识库链接 |
| 经验分享 | 分享技术心得、帮助队友解决问题 | 分享记录、聊天记录 |
4. AI 协作贡献¶
本课程项目中，与 AI 协作的方式本身也是能力证明。能讲清"AI 做了什么、你决定了什么、你如何验证"，比声称"全是自己写的"更有说服力。
| 维度 | 内容 | 证据 |
|---|---|---|
| 上下文组织 | 为 AI 提供文档、规则和任务卡，让 AI 基于真实项目工作 | AGENTS.md、任务卡、提示词记录 |
| 人工判断 | 采纳、修改或拒绝 AI 建议的决策过程 | AI 协作记录中的"人工判断" |
| 结果验证 | 对 AI 产出的运行、测试和评审 | 测试报告、缺陷记录、Git 提交 |
不要隐瞒 AI 参与，也不要夸大 AI 作用
答辩和面试中，"这段代码是 AI 写的还是你写的"是必问问题。隐瞒 AI 参与无法经受代码抽查；把成果全归于 AI 又无法证明个人能力。正确的做法是：明确 AI 参与了哪些任务，突出你在其中做出的判断和验证。AI 使用说明的准备方法参见6.2 完成答辩。
三、用证据支持每项贡献¶
1. Git 提交记录：代码贡献的直接证据¶
建议记录：
| 提交范围 | 文件 | 说明 |
|---|---|---|
| 用户认证模块 | AuthController.java、JwtUtil.java |
设计并实现 JWT 鉴权 |
| 失物管理模块 | LostItemController.java、LostItemService.java |
实现失物发布、搜索、详情 |
| 认领审核模块 | ClaimController.java、ClaimService.java |
实现认领申请、管理员审核 |
| 部署配置 | Dockerfile、docker-compose.yml、nginx.conf |
实现 Docker 一键部署 |
| 测试代码 | AuthControllerTest.java、ClaimServiceTest.java |
编写单元测试和接口测试 |
2. 设计文档：架构决策的思考过程¶
| 文档 | 贡献 |
|---|---|
| 《系统设计说明书》 | 参与架构设计、数据库设计、接口设计 |
| 《需求分析说明书》 | 参与需求调研、用户故事编写、业务规则定义 |
| 《测试计划》 | 编写测试范围、测试策略、测试用例 |
| 《部署说明》 | 编写部署步骤、配置说明、环境验证 |
3. 测试报告：质量保障的具体成果¶
| 成果 | 证据 |
|---|---|
| 测试用例 | 15 个测试用例，覆盖正常、异常、权限场景 |
| 缺陷修复 | 发现 3 个 P0 缺陷，全部修复并回归通过 |
| 测试覆盖率 | 核心功能覆盖率 100% |
| 部署验证 | Docker 环境完成核心流程 |
4. 演示视频：沟通表达的能力展示¶
| 成果 | 证据 |
|---|---|
| 演示视频 | 3—5 分钟，清晰展示项目价值 |
| 答辩 PPT | 10—15 页，结构完整 |
| 答辩陈述 | 5—8 分钟，逻辑清晰 |
四、个人贡献说明的结构¶
1. 推荐结构¶
2. 个人贡献说明示例¶
五、能力自评与教师评价对照表¶
1. 能力自评表¶
| 能力维度 | 自评等级 | 证据 |
|---|---|---|
| 后端开发 | 熟练 | 独立完成 3 个模块，代码通过测试 |
| 前端开发 | 基本 | 协助前端开发，解决跨域和接口对接问题 |
| 数据库设计 | 熟练 | 设计 4 张核心表，通过外键关联确保数据一致性 |
| 测试验证 | 熟练 | 编写 15 个测试用例，覆盖正常、异常、权限场景 |
| 部署实施 | 熟练 | 编写 Docker 配置，实现一键部署 |
| 文档编写 | 熟练 | 编写 README、部署说明、测试报告 |
| 团队协作 | 良好 | 参与 3 人团队，负责后端和部署 |
| 问题解决 | 良好 | 解决 3 个 P0 缺陷和部署问题 |
2. 教师评价对照表¶
| 能力维度 | 自评等级 | 教师评价 | 差距分析 | 改进方向 |
|---|---|---|---|---|
| 后端开发 | 熟练 | 良好 | 需加强高并发和性能优化 | 学习 JMeter，阅读性能优化资料 |
| 前端开发 | 基本 | 一般 | 需加强响应式设计和组件化开发 | 学习 Vue 组件库，实践响应式设计 |
| 数据库设计 | 熟练 | 良好 | 需加强索引优化和查询优化 | 学习 MySQL 索引原理，实践查询优化 |
| 测试验证 | 熟练 | 良好 | 需加强自动化测试和性能测试 | 学习 JUnit 5 高级用法，实践 JMeter |
| 部署实施 | 熟练 | 良好 | 需加强 CI/CD 和监控 | 学习 GitHub Actions，实践自动化部署 |
| 文档编写 | 熟练 | 良好 | 需加强技术写作和图表表达 | 学习技术写作规范，实践架构图绘制 |
| 团队协作 | 良好 | 良好 | 需加强项目管理和风险控制 | 学习敏捷开发，实践项目管理工具 |
| 问题解决 | 良好 | 良好 | 需加强根因分析和方案对比 | 学习根因分析方法，实践方案对比 |
六、个人技术亮点清单：可写入简历¶
从个人贡献中提炼 3—5 个技术亮点，可写入简历。
1. 技术亮点示例¶
| 序号 | 技术亮点 | 解决的问题 | 证据 |
|---|---|---|---|
| 1 | 设计并实现 JWT 鉴权和角色权限控制 | 确保用户身份安全和数据隔离 | AuthController.java、JwtUtil.java |
| 2 | 实现统一异常处理和响应规范 | 规范错误响应，便于前端处理 | GlobalExceptionHandler.java、ApiResponse.java |
| 3 | 使用 Docker Compose 实现一键部署 | 降低部署门槛，确保可复现 | Dockerfile、docker-compose.yml |
| 4 | 编写 15 个测试用例，覆盖正常、异常、权限场景 | 确保核心流程正确、缺陷已修复 | 测试报告、缺陷清单 |
| 5 | 解决重复认领、权限绕过、部署连接问题 | 修复 3 个 P0 缺陷，确保系统稳定 | 问题排查记录、修复提交 |
2. 简历描述写法¶
避免：
推荐：
七、多人项目的贡献划分¶
如果是多人项目，需要明确每个人的贡献，避免重复或遗漏。
1. 贡献划分表¶
| 成员 | 技术贡献 | 过程贡献 | 协作贡献 |
|---|---|---|---|
| 成员 A | 后端开发、用户认证、失物管理 | 需求分析、架构设计 | 代码审查、技术分享 |
| 成员 B | 前端开发、页面设计、交互实现 | 需求分析、原型设计 | 沟通协调、文档编写 |
| 成员 C | 部署实施、测试验证、缺陷修复 | 测试计划、部署说明 | 项目管理、进度跟踪 |
2. 贡献划分原则¶
- 职责明确：每个人有明确的主责模块；
- 证据可查：每项贡献有 Git 提交或文档证据；
- 避免重复：同一模块不重复计入多人贡献；
- 承认协作：协助他人的工作可计入协作贡献。
八、提交前自查¶
- 个人贡献说明 1—2 页，结构清晰；
- 明确了技术贡献、过程贡献和协作贡献；
- 每项贡献有 Git 提交、文档或测试报告等证据支持；
- 关键成果有量化指标（如模块数量、测试用例数量、缺陷修复数量）；
- 遇到的问题有根因分析和解决过程；
- 能力自评与教师评价对照表已完成；
- 个人技术亮点清单 3—5 项，可写入简历；
- 多人项目的贡献划分明确，无重复或遗漏；
- 个人贡献说明来自真实项目，无虚构内容。
本节小结¶
展示个人贡献的核心是让别人知道你解决了什么问题、做出了什么决策、承担了什么责任、获得了什么成长：
明确三个维度的贡献 → 用证据支持每项贡献 → 形成个人贡献说明 → 提炼技术亮点 → 对照自评与教师评价。
完成本节后，你将拥有一份可复用于答辩、简历和作品集的个人贡献说明。下一节将帮助你将项目成果转化为简历项目描述、作品集链接和面试表达。