### 第17届服创赛·初赛·项目复盘与经验分享 <div style="text-align: right;">——“面包师”团队内部经验分享会</div> ## **“四十二天，从零到提交”** 我们是四个人，参加第十七届大学生服务外包创新创业大赛，选的是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再集成，**接口的冲突是局部的，不能让它变成全局的灾难。** **收尾：“感谢大家，我们下次一定拿奖。”** 最后，说点心里话。 好在项目最终我肝了三个大夜，熬到凌晨三四点，最终交了一份看得过去的作品。说真的，不知道这次会是什么样的结果，能不能拿奖我也不确定。但**对于我们这样一支临时组队、开发周期只有一个月、没有任何真实项目经验的团队来说，这已经是非常好的结果了。** **我敢说一句话：不知道这次会不会拿奖，但如果有下一次的比赛，我们是一定会拿奖的。** 因为这次踩过的每一个坑，都会变成下次我们脚下的路。 感谢大家在后期也花了大量的心思帮我解决文档编写的问题。虽然大家都没有文档编写的经验，但其中一些内容对我真的有启发作用。我也自认为最终的文档还有大量可改进的地方，但确实因为时间和身体的原因，我不能再继续改下去了。这也是一点遗憾。 这次项目，如果让你们感到不顺畅、没参与感、或者白费了力，主要责任在我，是我这个负责人不成熟。**但希望我们经历的这些失败，能变成下一次我们合作的基石。** 谢谢大家。 <div style="text-align: right;">“面包师”团队负责人 洪智鹏</div> <div style="text-align: right;">2026/04/26</div>