在“AI垃圾”泛滥的世界举办软件黑客松：一种新尝试

背景

近年来，举办软件黑客松（Hackathon）、软件狂欢节（Software Jam）或各类代码竞赛变得愈发尴尬且充满挑战。一个典型的痛点是：评委往往被看似光鲜亮丽的 AI B2B SaaS 产品所迷惑，最终让一个仅仅是 ChatGPT 包装层（Wrapper）的项目赢得比赛。这种现象不仅打击了真正开发者的积极性，也反映了当前软件竞赛中“重形式、轻质量”的弊端。

尽管 Anthropic 等公司试图让人相信软件问题已经解决，甚至认为可以“一键生成”优秀的编译器，但事实并非如此。除了 Web 开发领域外，软件工程中仍存在大量未解之谜。与此同时，游戏开发领域依然保持着活力，Game Jam（游戏开发狂欢节）依然有效，这引发了作者的反问：为什么软件狂欢节不能像游戏狂欢节那样成功？

此外，资金问题也是阻碍黑客松发展的另一大难题。传统的筹资模式是向当地公司乞求赞助，但在当前的行业环境下，这条路径已难以为继。作者供职于非营利组织 Hack Club（一个由青少年组成、致力于制作酷炫项目的运动组织），虽然非营利身份在筹资上有一定优势，但 Hack Club 采用基于“工时”的资金分配机制，这引入了新的激励扭曲问题。

核心内容

作者详细阐述了 Hack Club 在运行软件狂欢节时面临的困境，以及他们试图通过借鉴 Game Jam 的模式来解决这些问题的探索过程。

1. 工时资助模式的激励扭曲

Hack Club 采用基于工时的资助方案：每个项目每小时可获得 8.5 美元的预算用于购买奖品或激励参与者。为了准确追踪编码时间，Hack Club 开发了 Hackatime，这是一个基于 Wakatime 的服务器，通过追踪用户物理敲击键盘的时间来确定资助金额。

这种模式看似公平，实则引发了严重的激励扭曲：

• 虚报工时：在早期，工时由参与者自报，导致有人为了多拿钱而谎报时间。
• 低质量产出：即使引入了 Hackatime 进行客观追踪，新的问题出现了。参与者发现，只要坐在电脑前敲击键盘，就能获得报酬。这导致许多人倾向于制作“懒惰的项目”（Lazy Projects），即低质量、无学习价值的代码堆砌，以此“刷”工时换取现金或奖品（如机票、活动门票）。
• 投票机制的局限：虽然引入了投票机制来惩罚低质量项目并奖励高质量项目，但这依然无法完全消除“刷工时”的动力，因为参与者依然可以通过制作大量低劣项目来消耗 Hack Club 的预算。

2. 借鉴 Game Jam 的成功逻辑

作者指出，在 Game Jam 中，很少有人会大规模提交低质量的游戏作品。原因在于：在 Game Jam 中，提交烂作品只会带来羞耻感（在投票中被碾压），且参与者无法从中获得任何实质奖励，反而浪费了时间且未学到东西。

因此，作者提出将 Game Jam 的核心逻辑引入软件狂欢节：让低质量代码无处藏身，让高质量代码获得尊重。

3. 解决方案：软件狂欢节（Software Jam）的新模式

为了解决上述问题，Hack Club 推出了新的软件狂欢节模式，核心策略包括：

• 严格的评委与期望管理：聘请更好的评委，并明确传达期望。例如，在项目创意列表中明确标注“不包含 LLM（大语言模型）”，以此抵制 AI 生成的“垃圾代码”（AI Slop）。
• 强调代码质量：给予参与者足够的时间来编写“漂亮的代码”。作者批评了当前行业普遍存在的“斯德哥尔摩综合征”心态——即接受 AI 生成的混乱代码，并安慰自己“以后会重构”。相反，作者主张从一开始就写出高质量的代码，从而奠定一个真正可持续项目的基础。
• 动态奖金池：为了适配基于工时的资助模型，奖金池需要随参与人数规模扩大。这意味着广告中需要注明奖金的大致范围，并附带免责声明，说明奖金将根据项目预算动态调整。

4. 风险与代价

这种新模式并非完美。由于奖金池取决于参与人数，参与者需要承担一定的“风险行为”：如果参与人数不足，奖金可能会低于预期。作者认为，为了获得更优质的软件狂欢节体验和更有效的 Hack Club 项目，参与者付出这一点点风险代价是值得的。

关键要点

• AI 包装层泛滥：当前软件黑客松中，评委容易被看似先进的 AI B2B SaaS 产品迷惑，导致 ChatGPT Wrapper 等项目获奖，而真正高质量的工程被忽视。
• 工时资助的副作用：Hack Club 基于 Hackatime（追踪键盘敲击时间）的资助模式（$8.5/小时）导致了“刷工时”现象，参与者倾向于制作低质量、无学习价值的“懒惰项目”以换取现金或奖品。
• Game Jam 的启示：游戏开发狂欢节之所以成功，是因为低质量作品无法带来奖励，只会带来声誉损失和时间浪费。软件狂欢节应借鉴此逻辑，消除低质量产出的经济激励。
• 抵制 AI Slop：新的软件狂欢节明确排斥简单的 LLM 生成代码，强调“斯德哥尔摩综合征”式的“以后重构”是不可取的，主张从一开始就编写高质量、可维护的代码。
• 动态奖金机制：为了维持基于工时的资助，奖金池随参与规模动态调整，参与者需接受一定的不确定性风险。
• 项目链接：作者正在运行的软件狂欢节网站为 radish.hackclub.com，联系方式为 [email protected]。

意义与影响

这篇文章不仅是对 Hack Club 内部项目的一次复盘，更是对当前 AI 时代软件开发教育与实践的一次深刻反思。

1. 重新定义“好软件”的标准：在 AI 能够一键生成代码的背景下，文章强调了“ craftsmanship（工匠精神）”和“代码质量”的重要性。它指出，软件并未被 AI 彻底解决，人类开发者在架构设计、代码整洁度和工程思维上的价值依然不可替代。
2. 解决教育激励的悖论：对于像 Hack Club 这样的青少年编程教育组织，如何平衡“鼓励参与”与“保证质量”是一个经典难题。作者提出的方案表明，单纯的经济激励（按工时付费）容易滋生惰性，必须结合社区声誉机制（如 Game Jam 式的投票与评判）和严格的质量门槛。
3. 对 AI 辅助开发的批判性思考：文章明确反对将 AI 作为偷懒的工具（即生成“Slop”），并倡导将 AI 视为辅助而非替代。它提醒开发者，依赖 AI 生成混乱代码并指望后期重构，是一种短视且有害的工程习惯。
4. 探索新型竞赛模式：这种“软件狂欢节”模式为其他技术社区和组织提供了参考，即在 AI 时代，竞赛和黑客松需要从“比拼谁做得快/多”转向“比拼谁做得好/深”，并通过机制设计确保参与者获得真正的技能提升而非仅仅是物质奖励。