这学期的创新实训我们组是被问题一路推着走的。选题改了三版技术栈选型争到面红耳赤Git合并冲突差点把整个分支搞废答辩前一周还在硬着头皮砍功能。现在回头看恰恰是这些不顺利让这轮实训比前两轮都值钱。这篇文章不讲漂亮话只把我们从选题到答辩的完整过程、踩过的坑、试错后的调整方案摊开来讲给后面要参加创新实训的同学以及任何正在做团队项目的朋友做个参考。1. 选题的拉锯战从能做出来到值得做1.1 我们最初想做的大而全方案为何被否创新实训三的通知下来以后我们组第一周就交了版交上去。当时大家热情很高方案写得很满一个校园内的活动服务平台要有活动发布、日历提醒、在线报名、扫码签到、积分系统、社交圈子甚至还想接地图组件。技术上也准备全部上最新的前端用新框架后端上微服务数据库恨不得拆成四个库来用。某导师看完方案只问了一句谁会持续用一个月这一下把我们问住了。回头看这个大而全的方案犯了三个典型毛病。第一功能太多意味着每个功能都只能做浅四个人各管一大块最后整合的时候发现每个模块都是半成品。第二整个方案没有一个核心闭环演示的时候只能逐个功能走马观花讲不出一个完整的故事。第三也是最要命的我们从来没有定义过谁是目标用户、用户遇到的真实问题是什么纯属为了做功能而做功能。这其实是创新实训最容易踩的坑。前两轮实训做的大多是单点小项目题目是给定的功能是明确的完成度很好衡量。到了第三轮自由度一下子变大反而不会干活了。我们一开始把功能丰富等同于项目有价值直到被追问才发现功能堆砌和产品价值是两码事。1.2 最终选题的三问法过滤标准被否掉以后我们组开了两次会最后定了一套选题过滤标准。我管它叫三问法后面帮了大忙。第一个问题八周内能不能做出一个可演示的版本这里说的可演示不是代码能跑而是在评委面前走完一条完整操作链路不会断在半路。如果答案是否定的说明范围和周期不匹配。第二个问题能不能用一句话说清价值差异比如一个比传统纸质签到更高效、比第三方工具更贴合校内场景的二维码签到工具这就够了。第三个问题有没有足够的工作量分给四个人太小会有人摸鱼太大则必然延期。按照这三条我们最终把选题定为面向校内各类活动的二维码签到与统计工具。活动组织者创建活动、生成签到二维码参与者扫码完成签到发起者后台查看实时统计和导出记录。范围不大但前后端链路完整能讲出一个有头有尾的使用故事而且每个模块都有明确负责人。这个选题最后被认可不是因为技术多难而是因为它刚刚好——有真实的用户场景有完整的业务流程又能在八周内做扎实。后来我在别的项目里也用这套三问法过滤过想法基本没有失手过。2. 技术栈选型我们为何最终放弃全家桶2.1 选型会议的争论点选题敲定之后技术栈选型又成了第二个战场。当时组里有三种声音有人觉得既然叫创新实训就应该上最新最热的技术简历上好看有人提议前后端都用自己完全没接触过的东西理由是反正有八周边学边做也有人主张怎么稳怎么来优先保证能跑通。我一开始属于第一种觉得项目价值和技术新颖度是挂钩的。但后来某导师说了一段话让我印象很深创新实训考察的是你在约束下做合理决策的能力不是把你懂的技术都堆上去。八周时间、四个人、还要兼顾课程这些约束摆在这里选一个大家都不熟悉的技术栈等于上来就给自己加难度。最后我们用了表里这一套方案层面初始讨论方案最终采用选型理由前端React 新的UI框架Vue 3 Element Plus组内三人已有项目经验排错效率高后端微服务方案 / FastAPI 二选一FastAPI开发速度快自带接口文档适合小团队数据库PostgreSQLMySQL教程资料多部署环境成熟部署Kubernetes / Docker ComposeDocker Compose只需一台服务器不引入额外运维复杂度表格里每个选择都不是拍脑袋定的。前端选 Vue 是因为三个人都写过遇到问题能当天解决而不是花三天查文档。后端选 FastAPI 是因为我们要做的主要是接口逻辑和二维码生成不涉及复杂多服务通信FastAPI 的自动文档还能省掉写接口说明的功夫。数据库选 MySQL 纯粹因为资料多遇到字符集、锁表这类问题一搜就能找到答案。2.2 从试新到求稳的转变逻辑有人可能会问那创新实训的创新体现在哪里我的体悟是真正的学习点根本不在于换个新框架而在于从需求建模到接口设计从多人协作到部署上线的完整链路这些能力换多少框架都不会过时。如果你把框架当作项目差异化的核心那说明项目本身还不够硬。我们组当时最典型的教训是有个组员私下把前端某模块换成了自己刚学的偏门插件结果遇到一个兼容性 bug 整整折腾了两天最后还得回退。我们回退的时候没有争论谁对谁错而是定了一条团队共识任何技术选型新增学习成本不能超过两个人的半天工作量。这条规则后来帮我们避了好几次坑。不要误解我的意思我不是反对学新东西而是强烈建议把学新东西单独放在实训之外的时间做不要拿团队项目的截止日期当学习成本。3. Git分支协作被合并冲突教育的最深刻一课3.1 初期各自为战引发的合并事故第四周的时候我们经历了一次差点重写代码的合并事故。事故本身不复杂三个人同时在 dev 分支上开发有人直接从 dev 改了文件就提交有人从来不 pull 最新代码周五合并时同一个文件被三个人各改了一遍冲突标记满屏都是。那时候我们连git diff都不熟有人就开始手动把对方的代码搬到一边结果搬完以后把别人刚提交的一个完整签到接口逻辑弄丢了最后只能靠git reflog翻历史找回来。复盘的时候发现问题根源不是操作失误而是没有协作规范。四个人对什么时候提交、分支怎么命名、冲突由谁解决完全没有共识。各自为战听起来自由实际上效率极低因为每一次合并都在赌运气。这件事之后我最大的领悟是多人项目的瓶颈往往是版本管理意识的参差而不是代码能力的高低。哪怕只有两个人在一个仓库里工作分支策略也必须提前定清楚否则迟早有人替你交学费。3.2 我们最终落地的协作规范事故之后我们花了一个晚上把 Git 协作流程定死后面六周再没出过严重冲突。具体规则如下长期保留的主干分支是dev发布答辩版本时才切release分支。功能分支一律从最新的dev切出命名带模块名比如feat/event-checkin、fix/auth-timeout。每天开始开发前先git pull origin dev保证自己基于最新代码工作。提交信息统一用feat、fix、docs、refactor前缀粒度要小一个提交只做一件事。合并到dev前必须有人做过 Code Review至少一个组员在合并请求里点过确认。冲突由提交者主动牵头解决而不是让最早发现的人背锅。下面是我们在功能分支上的标准操作模板# 从最新的 dev 切功能分支 git checkout dev git pull origin dev git checkout -b feat/event-checkin # 开发中保持小粒度提交 git add signin/api.py git commit -m feat: 完成签到接口的二维码生成逻辑 # 合并前先 rebase 到最新 dev git fetch origin git rebase origin/dev # 推送并发起合并请求 git push origin feat/event-checkin我们特意选择用rebase而不是直接merge目的是让提交历史保持线性。远程合并时如果出现冲突会发现冲突在公共分支上解决搞不好又会出现覆盖别人代码的问题。而rebase等于先把本地提交挪到最新代码之上冲突在本地处理处理完再推上去合并请求看起来就干净很多。同时我建议每个团队都养成一个习惯合代码之前跑一遍git log --graph --oneline看提交图。如果图上分叉混乱到看不出主线说明协作方式已经出问题了趁早纠偏。4. 里程碑式开发节奏倒排期背后的取舍逻辑4.1 为什么必须从答辩日期倒着排实训刚开始的时候我们组的计划是先把功能做完最后再准备答辩。这个想法听着没毛病实际执行起来会变成灾难因为做完是个没有标准的概念功能改着改着就失控了。我们把答辩日期定下来之后从那天开始倒推把八周拆成了四个里程碑每个里程碑都有明确的可演示产出。迭代目标交付物第 1-2 周数据模型与基础认证数据库脚本、登录注册接口、用户角色权限第 3-4 周签到闭环活动创建、签到码生成、扫码签到、记录落库第 5-6 周数据统计与界面打磨统计页、导出表格、前端界面完善第 7-8 周部署与答辩准备线上部署、演示脚本、QA 修复、PPT倒排期的价值不是让你列一个时间表而是逼你在每个节点做取舍。第 4 周如果签到闭环还没打通后面所有功能都要为它让路而不是反过来继续加新需求。4.2 节奏失控的那两周以及我们怎么爬出来我们组在第二到第四周其实失控得很彻底。每隔一两天就有人提出一个新想法比如加活动分类、加 Excel 导出、加短信通知、加地图选点。到第三周末期每个人手上至少有两三个半截子功能签到核心链路却还没完全走通。当时最慌的是所有人手上都有代码但没有一条用户路径是完整的。解决办法就两个字冻结。第四周周会我们立了一条军令状第四周之后不再加任何新功能只修 Bug 和打磨交互。同时把积分系统和社交圈子直接砍了只保留活动、签到、统计三个模块。砍功能的时候谁都不好受但砍完以后的进度肉眼可见地健康起来。这一段经历让我确信会砍功能比会加功能更能体现项目管理能力。一个项目能顺利交付靠的不是把每个想做的功能都做完而是敢于在时间不够时做减法。我们当时的补救措施很朴素每个模块指定唯一负责人接口变动必须同步到团队文档每天站会先检查今天结束前系统能不能多走通一步。4.3 每日站会如何从形式化变成有效产出站会本来是敏捷开发里的常见仪式但很多人开着开着就变成了汇报大会。我们组一开始的站会是这样的每个人轮流讲我昨天做了什么一人讲五分钟讲完散会会跟没开一样。后来我们改变了发言的结构不再说我做了什么而是回答三个问题昨天完成了什么能演示的东西今天推进什么能让系统变得更完整有没有谁被一个问题卡了超过半天这三个问题的核心其实都是变化量而不是工作量。只要没有可演示的新产出这天的进度就等于零。我们还定了一条硬规则站会不会超过十五分钟站着开不许坐。只要是能当场解决的阻塞当场拉人解决不许留到会后另约时间。从那以后每天上午十点的十五分钟变成了全天信息最密的时段。5. 答辩演练真正拉开差距的往往是提问环节5.1 演示Demo的三条铁律到第七周系统功能基本稳定我们开始专心准备答辩展示。当时总结了三条演示铁律每一条都是用实际翻车换来的。第一条用真实数据不要写死假数据。模拟答辩时我们发现一旦评委追问这个数据从哪来的演示的同学容易支支吾吾说不清。后来我们把演示环境里放一组真实的模拟活动数据创建时间、签到时间、统计图表都是程序真实跑出来的逻辑链条严丝合缝。第二条必须准备故障预案。现场网络不可能永远是好的手机扫码也可能会失败所以除了在线演示我们还提前录好了一段完整操作的备用视频万一系统挂了至少能让评委看到系统流程。第三条用一条用户故事串起整个演示流程而不是逐功能罗列。我们从活动创建者发布活动开始讲参与者扫码签到的体验最后落到统计页面的数据变化完整讲完一个从创建到参与再到沉淀的故事。5.2 评委提问的常见角度与应答准备答辩环节最考验人的其实不是讲 PPT而是回答提问。我们内部演练时整理了四类最高频的问题给每个问题都准备了应答框架。提问方向常见问法应对思路业务边界谁会真正用为什么不用现成工具承认局限说清我们的工具更贴合场景、数据更可控技术选型为什么不用某个更流行的框架拿出选型记录里的对比结论说明当时权衡过的因素个人贡献你在这个项目里具体做了什么对应到模块讲清数据流和接口设计而不只停留在页面性能与安全一百人同时扫码会怎样给出实际的并发处理策略没有覆盖到的就说明限制这里有个应答技巧很值得分享回答问题先说结论再给依据。比如评委问为什么用二维码而不是 NFC不要从通信原理讲起先一句因为二维码对普通参与者的使用门槛最低只要手机能拍照就行然后再补充成本和兼容性的考虑。结论在前论据在后评委听着省力你也不容易绕晕。5.3 我们踩过的一次演示翻车第一次内部模拟答辩我们组的演示翻车了。当时准备了很长时间的扫码签到流程现场突然网络波动二维码页面加载了快半分钟都没出来台下模拟评委的组员已经开始低头看手机。场面的尴尬程度不亚于开卷考试碰上一道完全没复习的题。那次翻车直接催生了我们的第二条铁律演示环境的稳定性优先级永远高于功能丰富度。后来我们调整了策略演示时先打开本地服务核心数据全部预置网络只作为备选依赖同时把录屏放在桌面第一屏。这个方法在后面两次正式演练中都用上了一次都没有再卡壳。6. 实训结束后比代码更值钱的三样东西6.1 从做完到做对的过程意识实训刚结束的那个周末我翻了一遍我们组仓库里的提交记录发现初期的 commit message 写着改了、更新、修了一下这种废话到后期逐渐变成了规范的feat/fix/refactor。这其实是我个人成长的缩影——前两轮实训我只关心代码能不能跑这一轮我开始追问谁会用、为什么这么设计、怎么验证它真的有用。这种做对的意识比多会几个框架重要得多。它让我意识到写代码只是一环需求理解、方案设计、协作沟通、演示表达每环都会影响项目的成败。6.2 把说不清的憋屈写成文档的习惯我们组在实训中期定了一个很轻的记录方式每天每个人往共享文档里写两三行当天完成了什么卡在哪了不需要长篇大论只要能让第二天的人接上思路就行。这个习惯初期我们觉得麻烦后来有一次组员请假两天回来看完文档半小时就接上了进度那一刻才意识到它的价值。还有一个细节是记录决策理由比记录决策本身更重要。比如某天我们决定把二维码有效期设为五分钟文档里不能只写调成了五分钟要写设五分钟是为了防止截图代签但时间太短会影响活动方操作所以折中选择。后期做复盘的时候这些理由帮我们省了无数争论。6.3 协作中磨出来的两条共识实训结束以后我们组散伙饭上聊出一个共识做完比完美重要公开比硬扛重要。项目做到第六周所有人都很疲惫但大家形成了一个默契——只要有人卡住超过半天就会在群里吼一声其他人要么给思路要么直接上手帮看。后来我发现这种有问题当天说的氛围比任何代码规范都更能保证项目存活。最后再分享一个小技巧每周五下午花十分钟做一次删功能练习。拿一张白纸把现有功能一个一个列出来逐个追问如果删掉它核心闭环还能不能走通。如果答案是可以说明这是个可以延后的功能如果删掉会让流程断掉那就是必须守住的核心。这个练习帮我训练出一种直觉让我在后续课程项目和社团工作里都能快速分辨优先级。实训教给我的东西很多但这套关于取舍和协作的方法到现在还在用。
