评委在Hackathon打分时到底在看什么？

很多人参加黑客松容易陷入一个误区：觉得技术堆叠越多、架构越复杂分数就越高。但从评委视角来看，决定胜负的往往根本不是技术细节，而是你对“约束条件”的掌控力。

一个最残酷的现实是：评委在短时间内要看几十个项目，Demo之间会产生严重的视觉疲劳。在这种压力下，评委不是在用某种理想标准衡量你，而是在做相对排序。

分享几个在实际评审中极易拉开分差的细节，对准备参加实战比赛的人很有参考价值：

• Demo能否跑通： 这是一个极低但权重极高的门槛。一个能现场跑通的简单功能，分值远高于一个只能用PPT展示的宏大愿景。因为跑通意味着消除了“不确定性”，而评委最讨厌的就是在时间紧迫时去猜测你的产品是否真的能工作。
• 首句定义产品： 很多团队喜欢先讲市场规模或个人故事，结果前40秒过去了，评委还不知道这玩意儿到底是干嘛的。最高效的开场是：这是一个给 [具体人群] 解决 [具体问题] 的工具。先给锚点，再讲故事。
• 范围与时间的匹配度： 36小时做出一个精巧的小工具，比做出一个漏洞百出的“平台”得分高。能砍掉冗余功能、只死磕一个核心路径的团队，在评委眼中才具备真正的判断力。

在问答环节，如果被问到以下三个问题，建议这样回答：

1. 目标用户是谁？ 拒绝模糊词（如“所有运动员”），要具体到“粉丝4万但没有经纪人的区域格斗选手”。具体意味着你做过调研，而不是在盲猜。
2. 这周末具体写了什么？ 坦诚地说明哪些是调用现有API，哪些是自己写的核心逻辑。模糊不清会被认为在掩盖工作量。
3. 规模扩大后哪里会先崩溃？ 敢于承认具体的技术弱点反而能增加可信度，说“完全没问题”通常会被认为缺乏深度思考。

总结起来，黑客松考的不是你的技术上限，而是在极端时间约束下的交付能力和决策质量。