How to Win a Hackathon: Notes From the Judging Table
TL;DR · AI 摘要
赢得黑客马拉松的关键在于清晰表达问题和充分准备，而非仅依赖技术实力。
核心要点
- 优秀的项目演示能让评委理解项目，而技术复杂但演示混乱的项目可能输掉比赛。
- 在开始编码前，应明确问题并研究比赛规则和评委关注点。
- 使用熟悉的工具和团队成员，能提高项目完成效率和质量。
结构提纲
按章节快速跳转。
思维导图
用一张图看清主题之间的关系。
查看大纲文本（无障碍 / 无 JS 友好）
- 如何赢得黑客马拉松
- 清晰表达问题
- 让评委产生共鸣
- 赛前准备
- 研究规则和评委关注点
- 避免盲目开始编码
- 使用熟悉工具和团队
- 提高项目完成效率
金句 / Highlights
值得收藏与分享的关键句。
A strong project with a confusing demo loses to a simpler project that the judges understand.
Say what the problem is that you’re solving. You need to get your audience of judges sharing your frustration with the problem that you see in the world.
Use tools that you’re already familiar with and work with people that you’re already familiar with.
如何赢得黑客马拉松：评委席上的笔记 - JetBrains 博客
JetBrains AI
通过 JetBrains 产品中的 AI 功能，为您的工具注入强大动力
关注
- 关注：
- RSS RSS
查看更多
AI
最佳实践
社区
教程
如何赢得黑客马拉松：评委席上的笔记
Katherine Druckman
在 JetBrains x Codex 黑客马拉松中，我花了两天时间观看团队构建并展示他们的项目。决定大多数获胜者的关键因素不仅仅是过去24小时的工作。而是他们在展示项目时所花的几分钟。一个强大但演示令人困惑的项目，会输给一个更简单且评委能理解的项目。
因此，我向几位评委询问了哪些因素能让黑客马拉松的展示脱颖而出，而不是被下一次展示所遗忘。他们的回答几乎完全一致。以下是他们告诉我的内容，再加上我自己在评判这些比赛时学到的一些东西。
从问题开始
每位评委都以某种方式表达了这一点，这说明人们经常搞错这一点。
Jono Bacon，开发者参与公司 Stateshift 的首席执行官，这样说道：“说出你正在解决的问题。你需要让评委们感受到你所看到的世界上这一问题带来的困扰。” 如果观看的人没有感受到这个问题，那么你为应对它所构建的一切都不会产生共鸣。
Scarf 的创始人兼首席执行官 Avi Press 表达了同样的观点，并补充了人们常常忽略的部分：“始终非常清楚你正在解决什么问题，以及你的提交如何解决该问题。听起来显而易见，但人们经常忽略这一点。” 他们经常这样做，是因为他们对技术感到兴奋，并假设问题显而易见。但事实并非如此。
来自 OpenAI 的 Bonnie Xu 将其描述为在编写任何代码之前做出的选择：“我的建议是不要从‘我能使用什么最酷的新工具？’开始，而是从‘我现在能构建一些以前可能无法构建的东西吗？’开始。” 她说，最好的项目来源于某个具体的事物——一个你个人觉得令人烦恼或效率低下的工作流程。从烦恼出发，而不是工具。
在编写一行代码之前做好准备
JetBrains 的开发者倡导者 Jan-Niklas Wortmann 指出，工作在黑客马拉松之前就已经开始了：“在开始之前先阅读规则。在真正理解问题领域、黑客马拉松的目标以及评委可能关注的内容之前，不要开始编写任何内容。” 仔细阅读提示或问题陈述。弄清楚谁是评委以及他们关心什么。如果你能在构建之前与他们交流，那就这样做。
来自 Nebius 的 Colin Lowenberg 提出了一个更实际的版本：不要从零开始。“总有一个比空白的 GitHub 更好的起点。” 如果你对需要的东西没有经验，可以向导师或赞助商请求一个可以开始的仓库。
并给自己在时间限制下最好的机会。Jan-Niklas 再次强调：“使用你已经熟悉的工具，并与你已经熟悉的人一起工作。” 认识新的人是黑客马拉松有趣且值得参加的原因之一，而且许多强大的团队在当天才组建在一起。关键是尽量减少你同时面对的未知因素。在周末同时面对一个新的框架、一个新队友和一个新问题领域，这会有很多需要吸收的内容，所以尽可能利用你已经知道的东西。
这里就是很多团队容易出错的地方。他们试图构建五个功能，结果却一个也没有干净利落地发布。
最好的项目是专注于做好一件事，而不是对五件事只做一半。要警惕范围蔓延和功能病。试图做太多事情看起来像是在表现自己的雄心，但你实际上是在保证你的演示中没有任何东西能端到端地运行。
Colin 将范围直接与演示联系起来：“你的演示应该是重点。它应该展示你的应用在一个流程中能做什么。如果太长了，就减少功能。”如果演示时间太长，这不是节奏的问题，而是范围的问题，解决方法就是删减。
Bonnie 明确指出优势：一个清晰的“哦，现在这变得可能了”的时刻，比展示每一个功能的游览要强得多。展示过去令人沮丧的地方，展示新版本，并让对比变得明显。
把演示当作整个提案
你可能只有几分钟的时间，而演示是人们记住的内容。要这样对待它。
Jono 的规则是：你必须能在大约 90 秒内展示出某些东西在运行。把你描述的问题快速展示出解决方案。
Avi 对演示本身提出了具体的要求：“把评委放在用户的位置上，带他们走过整个过程。”即使你所拥有的东西还不够完善或完全运行，也要展示出使用它时的实际样子。并且要坦率地对待它。“对什么有效、什么无效、如何运作、如何扩展要非常直接。”评委能察觉到你在绕着一个尚未存在的功能说话。对这一点诚实的表现会读作自信。
Colin 给出了一张清单，以防在评委面前停滞不前：“尽可能地模拟一切，并确保所有表单都已填写，与用户的来回流程顺畅。”预先填写数据。模拟缓慢的 API 调用。删除演示中可能停滞的每一个地方。
不要在底层过度设计。正如 Jan-Niklas 所说，发布一个良好的演示比拥有最可靠、质量最高的代码更重要。黑客马拉松奖励的是能运行的演示，而不是没人看到的干净架构。
像你已经赢了那样排练
Colin 的建议是从终点开始：“我希望你想象自己赢得黑客马拉松，并从那里倒推。”想象出一个能赢得比赛的演示，然后朝着它精确地构建。让演示变得流畅和准备就绪。你可能只有几分钟的时间，所以每一秒都应有其存在的理由。
在你展示之前，至少大声排练一次，并确保计时。提案是产品的一部分，那些练习过它的团队看起来确实练习过。
放松并享受乐趣
热情比人们预期的要做得更多。
评委们会感受到你的热情，所以试着记住最初让你兴奋地构建这个项目的理由。这才是我们真正想看到的部分。一个团队显然享受着自己的项目，比一个团队机械地背诵脚本更有说服力。
Jan-Niklas 对整个周末也说了同样的话：时间紧迫和压力是体验的一部分，让自己经历这些本身就是一种学习。享受这个过程。玩得开心。构建。
成功大多取决于三件事：以问题为出发点，展示一个功能在运行，以及让关心这件事变得显而易见。
hackathon
- 分享
上一篇
代理 AI 治理：设计问责与控制