大二暑假放弃回家、留在学校备赛最后却没拿到奖。这事儿其实一直想复盘但拖到现在才动笔。比赛输赢本身倒还好真正让我在意的是明明投入了三个月每天泡实验室最后交出来的东西自己都不愿意再看第二遍。这篇文章不是“我很惨”的碎碎念是一次尽量客观的失败复盘。如果你也是大二今年暑假准备参加竞赛或者已经组好了队伍这篇内容可能会帮你在开赛前避掉几条弯路。1. 这次竞赛的基本情况先说背景。这是一场校级以上、偏向应用开发的竞赛周期大概三个月要求做一个能跑的软件原型最后提交作品和答辩。我们队伍四个人两个写代码一个做文档和 PPT队长负责进度安排和对外沟通。时间线是这样的阶段时间段实际进度选题与组队7月初一周后确定方向技术调研7月中下旬边做边学没有完整预研开发实现8月核心功能在最后两周才跑通文档与演示准备9月初答辩前三天开始写 PPT提交与答辩9月中旬勉强赶上截止时间答辩表现不佳最终结果进入淘汰赛阶段但没有拿到任何名次。准确地说是进入了复赛/答辩环节然后在这个环节被淘汰。2. 备赛阶段看起来在干活实际效率很低现在回头看备赛期的三个月里至少有一半时间属于无效忙碌。2.1 选题阶段纠结太久方向不聚焦我们花了将近一周才确定题目。一开始提了四五个方向有的太大有的太虚最后选了一个“看起来能做”的项目——一个带数据可视化的校园信息查询工具。问题在于这个题目不是我们擅长的方向也谈不上多感兴趣只是觉得难度适中。队伍里没有人认真研究过同类作品是什么水平也没有去查往年获奖作品。选题时唯一的判断标准是“能不能做完”而不是“有没有亮点”。这个决策在后来的开发中反复折磨我们功能做得越多越觉得平庸做得越少又觉得没竞争力。2.2 技术调研走马观花没有沉淀确定方向后我们花了两周做技术调研。但所谓调研其实就是看了一些教程和开源项目收藏了一堆链接没有真正跑通一个完整的 Demo。现在回想最稳妥的做法应该是第一周就搭一个最简单的原型哪怕只有一个页面的数据展示也要把整个开发链路跑通。这样后面所有功能都只是在已验证的架构上加东西而不是每次都被环境配置、依赖冲突卡住。2.3 开发阶段主力一个人在扛其他人参与度不高8月份是开发期但实际进展非常慢。原因主要有三个队伍里有两个人暑假要回家远程协作效率很低经常一天下来只有几条消息。技术栈没有提前统一有人说用 Vue有人说用 React最后迁就了某个人的熟悉技术栈但没有形成书面分工。核心功能集中在一个人手上其他人只是写一些辅助模块进度一旦卡住整个团队就停摆。那段时间GitHub 的提交记录是公开的——基本只有早上和凌晨两个时段的提交而且集中在两三个人身上。这说明工作分配极度不均衡。3. 答辩现场暴露了所有问题如果说开发阶段的问题还能掩盖答辩环节就是完全暴露。3.1 演示准备不足我们的作品在答辩前三天才全部跑通没有多余时间做真实数据的完整演示。答辩现场用的是测试数据数据量很小、场景也不真实。评委想看的是在真实场景下的表现我们只能反复说明“这部分我们做了适配只是今天没带更多数据”。3.2 被追问后答不上来评委问了三个问题我们基本都只回答了一半“你们的数据缓存策略是怎么设计的”“如果并发用户达到一千人这个架构会出什么问题”“同类工具已经很多你们的差异化优势是什么”第一问我们确实做过一些缓存但讲不清楚实现细节第二问完全没考虑过第三问是最伤的——我们根本没想过这个问题。3.3 队长答辩但了解不全面我们选择让队长负责答辩但队长参与开发最少。PPT 里的功能细节队长能讲出大概却经不起追问。遇到技术细节他看向开发同学开发同学在台下又来不及补充。4. 失败原因拆解不是运气问题赛后我反复想了很多天排除了“评委不公”“题目太难”之类的理由。真实原因非常清晰表面原因深层原因开发时间不够前期调研和原型太慢没有尽早跑通链路队友参与度不均组队时只看熟不熟不看技术匹配度和投入意愿答辩答不上来对项目缺乏全局理解只写了代码没总结方案作品缺少亮点选题时没有研究同类竞品没有差异化设计项目像是课程作业没有任何真实用户测试不解决具体问题有一句话我赛后才想明白竞赛不是“做出一个东西”而是“在限定条件下证明你的方案有价值”。我们只是在做一个能演示的功能集合而不是一个能解决问题的作品。5. 复盘如果重新备赛我会做哪些调整把这些复盘落到具体行动上大致有五条。5.1 第一周必须跑通最小 Demo不管选题多粗糙第一周结束时整个开发链路必须完整前端能打开后端能返回数据数据库能存取。哪怕功能再简陋也要保证链路通。这能提前解决大部分环境问题。5.2 书面明确分工和交付时间每个人负责哪个模块、什么时候交什么全部写成文档。每周固定一次同步进度落后要当场说出来而不是拖到下一周。5.3 每周做一次“竞品分析”不是赛前做一次就完而是每周都花一小时看同类产品、往届获奖作品记录它们的功能、交互和不足再对照自己的项目看有没有跟进或避开的必要。5.4 答辩问题从开发第一天就开始积累答辩不是最后三天的事。每完成一个功能模块就写一个“功能说明 实现方式 为什么这样做”的文档。这些内容累积起来就是答辩的素材库。当初我们就是漏了这一步导致答辩前拼命补文档。5.5 找真实用户试用哪怕是找同学、室友、朋友来用也比自己对着测试数据好。真实用户会提出你根本想不到的问题这些问题就是你答辩时能“秀”的地方“我们在测试中发现……所以调整了设计。”这句话的杀伤力远大于“我们做了一个 XX 功能”。6. 对于准备参加竞赛的人几条比较实在的建议6.1 大二参赛别奔着“拿奖”去这个年龄段参加竞赛最重要的收益是用三个月时间经历一个完整项目从需求到实现、从演示到答辩的全流程。这个经验在找实习、做毕设时都会反复用到。拿奖是结果不是目标。把目标定成“做完一个能讲清楚的项目”反而更容易有好结果。6.2 选队友看“投入度”而不是“能力”能力可以学投入度很难改变。一个愿意每周投入十小时的普通开发者比一个只来开会的“大佬”靠谱得多。组队前先问清楚暑假能不能留校、每天能投入多长时间、家里电脑带不带得动。这些比技术栈重要。6.3 遵守进度比赶进度舒服得多“最后一周爆肝”是最常见的项目失败模式。提前做好计划每周完成一小块最后一周只用来打磨和测试体验会完全不同。6.4 学会砍需求项目做到一半肯定会发现时间不够。这时要学会“砍”。砍功能不是放弃是保证核心体验的完整性。一个做完了的简单功能比五个没做完的复杂功能强得多。我们当初就是舍不得砍需求结果所有功能都只做到 80%答辩时每一个都经不起追问。7. 竞赛收尾后的调整从失败里拿到真正有用的东西比赛结束一周后我做了三件事算是把这次失败“消化”了7.1 整理项目代码和文档把 GitHub 仓库重新整理删掉无用代码写清楚 README。这次整理让我发现自己写过的代码其实有大量可以复用的逻辑也存在不少架构问题。后来找实习时这个项目成了面试里能聊得最深入的话题之一。7.2 把失败写成文字复盘不是心里想一遍而是写下来。写完才会发现很多想法是情绪化的不是事实。我在比赛结束十天后写了第一版复盘又过了一个月再次修改最后留下的版本已经非常冷静。7.3 补上缺失的知识答辩中暴露的那些问题表面上看是“没准备”实际上是基础知识不够扎实。赛后我花了三周时间把缓存、并发、数据库索引这几个点重新学了一遍。这些后来在面试和课程设计中都用上了。8. 常见问题与心态调整8.1 没有获奖简历上怎么写可以如实写“参赛并进入复赛/决赛”。重点不是名次而是你在项目里具体做了什么。把项目职责、技术栈、解决的问题写清楚比一个三等奖更有说服力。8.2 要不要复盘多久复盘一次要。但建议比赛结束后先休息三五天等情绪平复了再复盘。复盘时不要只写“我太菜了”而是写“哪个环节出了问题 → 为什么出问题 → 下次怎么做”。复盘的目标是提取方法论不是自我批判。8.3 大二失败了对保研、找工作有影响吗单独一次竞赛失败几乎没有直接影响。影响最大的是你从这段经历里有没有长进。如果能在面试里清晰地讲出“我做过什么、遇到什么问题、怎么解决的”这段经历反而会变成加分项。8.4 还会继续打比赛吗会。但下一次会更看重选题、队友、计划而不是“努力”本身。竞赛最大的成本是时间和精力合理的策略比蛮力重要得多。9. 写在最后这次竞赛没能给我带来一块奖牌但给我留下了比奖牌更持久的东西一次完整的、深度的失败经历。你能从失败里提炼出几条可复用的原则比拿奖更值——尽管当时我并不这么认为。如果你现在正处在大二正在犹豫要不要参加暑假竞赛我的建议是参加。但要提前想清楚选题、队友和计划这三点。不要等到比赛结束才去复盘。下一次竞赛或者下一个项目我会在动手之前就把这些问题想清楚。