1st Place - 2025 FEIT Hackathon Festival
引言
活动链接：https://eng.unimelb.edu.au/students/eng-and-it-calendar/upcoming-events/industry/hackathon-festival-2025
2025年9月29日（星期一）到10月1日（星期三），我和我的四个队友一起参加了2025年FEIT Hackathon Festival，并取得了第一名的成绩， 拿到了总共6000澳刀的奖金。
在这次活动中，题目刚公布，我们一头雾水，但J哥带我们做个排除法，我们先把明显大家都不同意做的主题筛选掉，最后留下了两个问题： 一个是Problem 2，是关于AI如何赋能新时代的技术人员的转行的问题；另一个是Problem 3，我记得好像是如何改进有ADHD症状的学生在课堂上的表现。
然后，LX好像提到了一下，在转行的过程中，我们会有一个技能不匹配的问题，而且技能直接有前后依赖关系，就像是游戏里面的技能树一样， 我们应该可以考虑一下做一个技能树去向用户推荐你需要掌握的技能。
但是问题来啦，我们应该怎么把AI融合进去呢？我们意识到，现代的AI其实区别于传统的匹配问题，他更擅长是做自然语言的分析，所以我们想到，
可以让AI去分析用户的问卷结果（问卷也可以经过AI动态生成后续问题），也可以让AI去分析用户上传的简历，通过他简历上的标注的信息， 比如在学校学习的课程、毕业后的工作内容、以及项目的内容，根据这些信息来自动分析出他掌握了哪些技能，也就是用户的Skill Set。除此之外，我们还需要记录用户的性格，因为有些人喜欢有新意的工作，而有些人喜欢一成不变的工作，我们最好根据用户的喜欢去给他匹配他需要的工作。
可以让AI去分析招聘市场上的JD，因为JD一般以自然语言的形式存在，我们需要用AI把他解析成一个需要的Skill Set。然后问题就转换成了一个简单的匹配问题。除此之外，我们还需要收集网络上对这个岗位的工作内容的评价，这个工作是偏向创造力还是偏向重复劳动？这个工作被AI取代/赋能的可能性如何？
除此之外，我们还希望AI去网络上各个薪资分享平台下载更新每个岗位不同年限的薪资水平（平均数、中位数）、岗位数量，最好还要和用户的意向工作地区匹配。然后我们根据这些信息计算出一个岗位未来的潜力，包括它是否容易改行，以及是否能提供客观的收入。根据这些信息计算出每个岗位的潜在价值。潜在价值高的岗位会给他需要的Skill Set提供更高的Value，也就是说，Value高的Skill Set是更值得优先学习的。而且，Skill之间可能会存在相关关系或者依赖关系，我们也希望我们的AI能够自动分析推导出这样的关系，而不是依赖人工构建数据库。
所以，我们最终的产品其实是一个三段式的前端程序，第一步和第三步分别是平平无奇的问卷以及后续的Skill Set学习路径推荐（呈现出如果我们想要转去这个目标岗位，哪些技能是要学的，其中哪些是已学的，哪些是推荐优先学习的（根据Skill之间的依赖关系还有Value的高低进行推荐）。而我们的产品最酷炫的是第二步，一个动态的Skill推荐图，所以我们的产品被起名叫做SkillGraph AI（这个名字是我找Gemini帮忙起的）.
下面重点介绍一下这个Skill推荐图，一开始，它会显示你已掌握的技能，然后显示若干个它推荐你转型的岗位（在展示的过程中，我们只写了IT相关的岗位），你可以通过点击岗位设定你的转行目标。当转行目标设定完成后，他需要的Skill会被高亮，你可以看清楚自己和目标之间的差距（已学习、未学习用不同的颜色表示），除此之外，你可能会看到有很多未学习的Skill，可能会困惑下一步应该学习什么。这时候，SkillGraph AI会把前置依赖的Skill（其中高Value的优先）优先推荐给用户。用户在学习完一个Skill之后可以点亮这个技能点，他会亮起并点亮下一个推荐的部分，给用户一个很强的正反馈。
我们这个产品的前端技术部分就介绍到这里，至于具体应该怎么用AI去实现，我记得LX让我们用一个叫做LangChain的AI工作流去做，但是对于一个概念比赛（PPT比赛），我没有太过深入细节。
组员贡献
- Presentation阶段
在最终准备Presentation的那一天，我和设计师LZR和产品经理兼队长J哥一起爆肝调整PPT上的细节。不得不说，他们做设计出身的专业人士调出来的效果相当有冲击力，非常吸人眼球！最给力的还是J哥，一个人搞定了演讲稿的撰写还有上台Presentation的环节，顺便把评委问的两个产品问题（比如招聘方能使用这个SkillGraph AI吗）给挡了回去。
- 核心技术部分
然后，上面的SkillGraph的颜色和动态效果，J哥负责清晰描述我们的需求并且决定应该如何做取舍。我和LZR设计了一套Node的高亮效果的颜色，Jeffrey提供了动态图的库以及Node和Edge之间的光环效果，我负责做点击Node相关的代码逻辑以及在最终阶段的样式调整。
- 外围技术部分
LZR帮忙用Tailwindcss设计了一套很好看的问卷页，但可惜我在集成的时候用MaterialUI替换掉了，最终效果不太理想。我负责问卷页、结果页的几乎全部设计和代码集成。LX负责推导我们这个产品的AI和数据相关的逻辑，比如我们的数据应该从哪里采集，我们应该用什么样的技术进行分析，怎么让多个AI Agent之间互相配合。对于Q&A的部分，LX复制阻挡AI和数据相关的提问，而我负责阻挡所有外围技术（比如前端、后端、数据库的技术）的提问。
收获
这是我最想写成文档记录的部分。我从这一次活动中收获了非常多技术以外的能力，以前我是一个只关心技术的Geek，就像Jeffrey一样，我对待这个PPT比赛的态度其实也是一句“我只想写代码”，然后就打退堂鼓脱离战斗了。
但是，通过和团队的配合，我学习到了很多技术以外的能力，比如
规划能力
- 拆分任务
一个大的任务一定是由很多小任务组成的，他们之间有不同的依赖关系。比如你需要先定产品的原型，然后做前期的调研（比如竞品是怎么做的，他们有什么缺点没有满足用户的需求？用户的需求是怎么样的？用户的痛点是什么？），这个阶段是头脑风暴的阶段，我们最好在线下进行，因为头脑风暴的阶段需要大家互相贡献idea，而且有时候需要用白板/草稿纸描述自己的思路，在这种非常发散的阶段容易发生走神/抢麦，非常不适合线上进行。第三步是规划具体技术的实现，我们要定好一个技术栈，并且划分出几个模块/页面，在他们之间规定好接口，方便我们几个技术人员分头去实施。最后是技术集成、修复bug、验收、细节修改的阶段，这个阶段要服从产品经理的指示，我们可以提出我们的建议，但是最后要统一听产品经理的意见。在定好产品之后，最后是Presentation的阶段，我们应该先制定PPT的框架，就是每一页具体应该讲什么样的内容，定好他的标题和表达核心，然后整体过一遍确保我们的逻辑通顺叙事连贯。然后我们应该把PPT和演讲稿的不同章节分配给不同的组员去做，不应该让J哥一个人承担过多职责。同理，Q&A的阶段我们也应该动员大家一起去做，比如一个人去帮忙问AI收集评委可能得问题，另一个人帮忙写我们产品应该怎么回答这些问题，全部写成文档交给大家一起审核。
- 规划工作流
以上是拆分任务的部分，规划工作流的部分，我们需要注意我们做一个事情是要有理有据有逻辑的，我们为什么要做这个事情，一定是我们发现了什么问题然后想要解决这个问题，我们要注意这个叙事的逻辑。除此之外，我们也应该先看看这个问题其他人是怎么做的，他们为什么没有解决这个问题呢？最后，我们应该对比我们新解决了什么问题，得到了什么样的结论。
- 分配任务
关于分配任务的部分，我目前想到的是一开始我们组队要足够多元化，每个人都最好能负责多个方面。这样我们可以考虑让大伙的工作并行完成。如果一个人只适合一个岗位，那么一旦他的工作依赖的前置步骤卡壳了或者他的工作提前做完了，就变成挂机的状态了。
沟通能力
我们组合用了多种沟通方式：
- 线下面对面沟通
线下沟通的成本非常高，特别是对于技术人员来说，他们一般都不喜欢出门，而且万一累了也不能及时休息，对于写代码来说休息不够非常影响产出的质量。但是线下沟通的好处是能确保听众是专注的（不会走神），而且不会产生抢麦的现象，配合眼神、表情和肢体语言，我们能得到线上沟通完全达不到的效率，尤其是lecturer是一个热情洋溢并且逻辑清晰的人时，与他进行实时互动可以得到不一样的沟通体验。另外，在线下使用白板/草稿纸确实比较方便，或许我们需要一个共享白板来实现这个功能。
- 线上Discord沟通
Discord提供非常高清的投屏，并且可以多人免费不限时观看。在Discord上发出的消息在任何端（手机/电脑）都能确保接收到，也可以编辑信息。总的来说作为一个生产力工具是比较合格的，除了传文件不宜过大以外。但是它不提供腾讯会议的批注功能，在遇到紧急情况或者非会议时间召集队友时，也没有微信响应及时。
- 共享文档
在需要快速编辑项目初期的产品文档、技术文档以及最终合力修改PPT和演讲稿时，Google Docs中的文档是非常合适的，而其中的幻灯片功能则非常非常难用，只是我们没有找到更好的替代品。Google Docs的缺点是不适合写格式化的代码。写文档的过程其实是帮助你自己理清思路的过程，让你搞清楚整个事情的前后逻辑关系，我们为什么要做这一步，我们这一步需要做到什么样的效果才算成功，以免在项目执行到一半时大家产生分歧互相甩锅。。除此之外，文档可以让听众在走神时有自行补上缺失部分的机会，避免干扰会议进行。最后，对于ADHD的患者来说，文档可以在间隔几个小时之后提供给你恢复工作状态的机会。同时，这也让每次会议有实际产出，把大家达成一致的部分确定下来，是大家分工合作互相配合的前提。（突然感觉到书记官很有用）
- github代码仓库
这是程序员最需要使用的沟通方式了。但是我发现需要确保队员都知道怎么处理git的merge、rebase时的各种问题，比如版本冲突或者合并冲突。甚至他们不清楚pull不下来和push不上去怎么处理，看上去真的是挺头疼的。除此之外，我们应该确保非技术岗位的组员也能参与实时调整，在线上沟通的时候他们可以通过阅读源代码并指挥AI的方式进行调整。我们要确保在项目之前教他安装node环境，并且学会npm install和npm run dev的方式自行调试。
TODO: 补充我们获奖的图片、我们的产品的示意图、我们的代码仓库