第17届服创赛·初赛·项目复盘与经验分享

“四十二天，从零到提交”

我们是四个人，参加第十七届大学生服务外包创新创业大赛，选的是A组A05赛题——AI面试助手软件，没有指导老师。

• 3月7日，我被拉入团队，开始着手确定选题。
• 3月10日，确定题目。
• 3月12日，创建仓库。
• 3月14日，确定技术方向。
• 3月15日，正式开始开发。
• 4月10日，大家的网站部分开发完成，但我负责的核心面试官和数字人还没搞定。
• 4月19日，基础面试官和数字人开发完毕，但没有真实的后台对接。同时开始写文档、做视频、做PPT。
• 4月22日，材料收集完毕，提交。

今天简单聊聊天。这次服务外包大赛，咱们做“AI面试官面谈”这个项目，我是负责人，主要来讲讲我的思考与感悟，把我自己从头到尾犯的错、走歪的路，都来跟大家汇报一下。是我自己反思，也是我自己的总结。写出来与大家分享分享。

有些话可能比较直，但都是我用这次比赛实实在在的教训换来的，希望咱们下次能更好。

第一部分：“我搞了伪民主。”

咱们的需求，还记得吗？积分商城、互助平台这些，是我提的，也号召大家一起头脑风暴了。但后来被老师点醒，才发现我们把核心的“AI面试官”功能给边缘化了。

现在回头看，这不光是需求跑偏的问题，更深层的问题在于我作为负责人，搞了“伪民主”。我总想着跟大家商量，问大家想做什么、觉得好不好。但实际情况是，大家积极性没那么高，也不太会主动提想法，最后其实还是我的一言堂，只是我自己不认，非要走个“商量”的形式。这很没效率。

“我太在意大家怎么看我，不敢当坏人。”

我们是在打比赛，要的是结果，不是过家家。 当坏人，去果断拍板，比当一个好老人，去博一个“好说话”的名声，对项目重要得多。我当时太在意大家怎么看我，不敢太强硬，这是我角色扮演上最大的失败。

如果再来一次，我会这么做：直接拍板定题目、定方向，然后告诉大家“兄弟们，就干这个，理由是一二三四，你负责这块，你负责那块”。然后，在动手写任何一行代码之前，先让大家把原型图设计好，把功能流程图定下来。哪个页面有什么按钮，点下去会跳转到哪里，产生什么结果，这些必须一开始就全部敲死。所有人之后都必须严格按照原型图来做，不能自己随意发挥。 这样能保证我们做出来的东西是统一的、可控的，而不是最后拼出一个风格混乱的东西。

其实说实话，这次做出来的界面，我是不满意的。 为什么？因为太“AI”了。图标是AI的风格，布局也是AI生成的，一眼就能看出来不是人用心设计的，缺乏我们自己的独特性。但当时我没有坚持去改，一方面是怕打击大家的积极性，另一方面是返工工作量太大，项目时间又不允许。这是一个教训：下次必须在开工前搞定设计，而且设计不能完全丢给AI。

“我把最难的活揽自己身上，是双输。”

那些跑偏的拓展功能，最后都是分给队员们去做的。而我呢？我把最核心、最难、工作量最大的“AI面试官”部分，全攥在自己手里了。 这导致两个烂结果：

• 第一，你们做的内容和项目核心是割裂的，参与感和成就感肯定很差。
• 第二，我自己被压得半死，根本没精力去管你们之间的衔接和项目的全貌。

这是个双输的分工。

第二部分：“我们把命交给了AI。”

技术这块，是这次最疼的教训。

咱们从CSS换到Vue，其实不管哪样，代码基本都不是我们自己写的，全是AI生成的。 这很可怕，这意味着我们的上限就是AI的上限，我们完全失去了对项目的掌控力。 想精细调整、想做成自己心里想要的样子，根本做不到。提示词写不好，AI就出不来好东西，最后调试优化还得再丢回给AI。对核心技术，团队至少得有一个人能看懂、能上手改，不然就只能做AI的“奴隶”。

“Git用得一塌糊涂，因为分支跟人走不跟功能走。”

我们当时的做法是，每个人用自己名字开一个分支，然后各写各的，写了两周，最后一次性合并。结果合并的时候大量冲突报错，浪费了好多时间去处理这些本不该有的麻烦。

这不是正确的用法。 正确的做法应该是：每天开发都先更新仓库，然后开发新功能的时候，从develop分支新建一个功能分支，做完就申请pull request，由我来审核合并。分支不应该跟开发者挂钩，应该跟功能挂钩。 一个功能一个分支，做完了就合，合完了就删，再开新分支做下一个功能。这样频繁开分支、频繁合并，每一次的冲突都会非常小，就不会出现最后那种大规模冲突的灾难了。这个规范是我在实习时从公司学到的，是行业里真正在用的做法，我们自己做项目也应该这样干。

“我骨架没搭，先去绣花。”

我负责的数字人部分，犯了一个致命的顺序错误：我一上来就死磕技术难度最高的数字人方案，花大量时间在找开源代码、折腾环境配置上，而这些时间绝大多数都被浪费了。

我应该一开始就把除数字人以外的所有面试核心流程全部搭建好，最后再作为插件一样把数字人接进来。核心功能是骨架，数字人是皮。我骨架没搭，先去绣花，导致最后核心的AI功能是最后两周周末才赶出来的。这是极其愚蠢的技术路线规划。

所以，虽然咱们确实什么都是现学，都得靠AI，但技术验证这一步绝对不能省。 下次我会作为负责人，把重要工具和API在开工前自己先花半天跑通一个最小demo，确认此路可通，再让大家开干。

另外，调用大模型API这种活，最好去官方平台找它自己的AI助手。 比如我调用豆包的API，去火山方舟平台问它自己的助手，给出的代码成功率就高很多。专业的事，找专业的工具，别在一棵树上吊死。

第三部分：“我们应该是先砌好每个房间，再对门，而不是贴着墙造下一个房间。”

这次开发，还有一个让我反思很深的地方，就是我们的开发模式有问题。

我们基本上是边搭架子边往上堆东西。打个比方就是：我们做了一个房间，然后贴着这个房间的墙在外面搭下一个房间，结果墙越贴越歪，最后改一个地方牵动全身。

下次必须反过来：先用砖头把每个房间都结结实实地砌好。 每个人负责的模块，先做成一个独立的、能跑通的demo，这间房本身先盖瓷实了。然后我们再把这些独立的房间组装到一起，这时候肯定还是会有冲突，但冲突只发生在门和门的对接处。 我们只需要解决“你的门框和我的门框怎么对齐”，而不是“你的墙歪了导致我的天花板塌了”。接口的修改是局部的、可控的，不会动到每个房间内部的承重墙。

这样做的好处是：每个人的模块在独立阶段就已经把逻辑跑通了，最后集成时定位问题的范围会小很多，能省掉大量后期返工的时间。

“原型图没定就开工，界面AI味重到我自己都不满意。”

没有原型图，没有统一的设计规范，大家各做各的，最后拼出来的东西风格不统一，全是AI的味道。下次，设计先行，原型图不定，谁也别动工。

“负责人应该是辅助，是开团先锋，是兜底，而不是打输出和切后排。”

在“砌砖房”的模式里，我的角色不应该是自己去砌每一块砖，而是当辅助——给队友创造好的开发条件；当开团先锋——在关键的技术节点上冲在前面探路、验证方案可行性；当兜底——任何一个环节出了队友搞不定的问题，我来接住、来收场。

负责人不是把所有重要输出都自己打了，而是让队友安心打出自己的输出，我只在他们打不了的时候补上致命一击。 这才是负责人该干的事。

第四部分：“我把自己当成了主力输出，忘了自己是控场。”

这次我还想坦白一个心理问题：我太喜欢把最重要的活揽到自己身上了。

我把核心功能全包了，结果中途又找到了实习，时间一下子变得非常少。这下更糟，我忙得要死，你们也推进得困难，因为最核心的东西在我这儿卡着。这让项目的整体配合变得很畸形。

这也让我意识到，要学会权力下放，不是嘴上说说。 我真得把一些核心的、有挑战的活，硬塞给你们。我之前总怕给你们难的东西你们搞不定，或者做得不合我意，结果就是累死自己，你们也练不到东西，项目整体还因为我的个人时间问题被严重拖累。 既然是大家合作，每个人都要付出心思在里面，那肯定是让你们的心思更多一点，这样才能减轻我的负担，也能让大家更有参与感。

第五部分：“这些坑，我们下次不能再踩了。”

1. 别自己骗自己。 我们明知道那些拓展功能鸡肋，但为了比赛显得功能多还是加上了。下次，功能宁缺毋滥，就把一两个核心功能做到极致。少而精，永远是硬通货。

2. 别在钱上抠自己。 为了省点小钱纠结，结果耽误的是整个项目不可逆的时间。这是在做项目，不是买零食，该投入的成本要果断。

3. 前期把控是命。 负责人脑子里必须有最终成品的清晰样貌。原型图和功能流程图就是施工图纸，图纸没画好，谁也别动工。 框架内的细节可以交给你们发挥，这是“独裁”和“放权”的平衡。

4. 心态是最后的防线。 过程中我无数次觉得要崩，但我一直跟你们说“没事，小问题，肯定能解决”。作为负责人，内心可以慌，但对外传递出去的，必须是“稳住”。

5. 别把所有项目都硬套AI。 AI应该是解决问题的工具，不是为了加而加的噱头。用不用、怎么用，得看实际需求，别为了跟风硬上。

6. 开发模式决定项目质量。 下次，先用砖头把每个房间砌好，再对门组装，而不是贴着墙造下一个房间。每个人独立跑通demo再集成，接口的冲突是局部的，不能让它变成全局的灾难。

收尾：“感谢大家，我们下次一定拿奖。”

最后，说点心里话。

好在项目最终我肝了三个大夜，熬到凌晨三四点，最终交了一份看得过去的作品。说真的，不知道这次会是什么样的结果，能不能拿奖我也不确定。但对于我们这样一支临时组队、开发周期只有一个月、没有任何真实项目经验的团队来说，这已经是非常好的结果了。

我敢说一句话：不知道这次会不会拿奖，但如果有下一次的比赛，我们是一定会拿奖的。 因为这次踩过的每一个坑，都会变成下次我们脚下的路。

感谢大家在后期也花了大量的心思帮我解决文档编写的问题。虽然大家都没有文档编写的经验，但其中一些内容对我真的有启发作用。我也自认为最终的文档还有大量可改进的地方，但确实因为时间和身体的原因，我不能再继续改下去了。这也是一点遗憾。

这次项目，如果让你们感到不顺畅、没参与感、或者白费了力，主要责任在我，是我这个负责人不成熟。但希望我们经历的这些失败，能变成下一次我们合作的基石。

谢谢大家。