极简博客
简历
联系方式
第17届服创赛·初赛·项目复盘与经验分享
发布时间:2026-04-26
### 第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>
← 返回博客列表