黑客松像是一种极限运动。
比如滑雪。
我想到的是海明威的《阿尔卑斯山牧歌》。故事开头，两个滑雪者结束了一个月的高山生活，从西尔夫雷塔的雪地回到山谷。他们曾经迷恋那里的雪和阳光，后来却发现自己已经在山上待得太久。阳光无处可逃，春雪只有清晨和傍晚可以滑，原本令人兴奋的纯粹逐渐变成疲倦。
黑客松也会创造一座这样的高山。
在几十个小时里，一群人暂时离开日常生活，进入一个由电脑、白板、代码仓库和截止时间组成的封闭世界。睡眠、饮食和昼夜的边界渐渐消失，外部世界被压缩成偶尔看一眼的消息通知。所有注意力都集中在同一个问题上：怎样让一个原本只存在于讨论中的产品，在截止时间前真正运行起来。
这种体验之所以像极限运动，首先是因为资源极其有限。
时间有限，精力有限，团队人数有限，算力和 token 也有限。每做一个功能，就意味着放弃另一个功能；每花一小时修复边缘问题，就少一小时打磨核心流程。平时可以留到下周讨论的问题，在黑客松里必须立刻作出决定。
前期的头脑风暴、需求裁剪、技术选型、环境搭建和 roadmap 制定，很像登山。
登山时看起来还没有真正开始运动。人走得很慢，要检查装备、观察天气、确认路线、分配体力。但真正站上坡顶以后，很多决定已经很难重新来过。产品目标没有想清楚，技术架构没有搭好，团队分工没有明确，这些问题都会在下坡时被速度迅速放大。
真正开始开发，则像从坡顶向下俯冲。
尤其在 AI 主导的开发环境里，速度会快得惊人。模型可以在几分钟内生成一个页面、一组接口，甚至一套看起来结构完整的应用。人只要稍稍向前倾，重力就会接管身体，代码开始成片出现，产品也开始以一种近乎失控的速度生长。
但速度并不会自动产生方向。
滑雪者需要不断转弯，通过调整重心控制路线和速度。AI 开发也需要持续校准。每一次生成之后，都要重新确认当前实现是否仍然服务于最初的用户需求，代码结构是否还能维护，新增功能是否破坏了核心流程。
规划不清时，生成得越快，偏离得也越远。
一个临时模块可能迅速侵入整个代码库，一个未经验证的技术方案可能成为后续功能的基础，一个看起来很酷的新功能也可能把团队带离真正需要完成的任务。等到问题暴露出来，人已经进入岔路，甚至忘记最初准备去哪里。
滑雪中的失控往往发生得很突然。前一秒还觉得自己掌握了一切，下一秒就可能因为一块软雪、一次错误转向或过度加速摔倒。
黑客松里的产品也一样。
第一版已经能够运行，团队以为最困难的阶段过去了。结果增加一个功能，原本正常的接口开始报错；合并一个分支，另一位成员的页面随之失效；为了修复一个 bug，又制造出三个新的 bug。无数个 PR、分支、依赖和临时方案交叠在一起，代码库逐渐变成一片布满雪痕、断崖和岔路的山坡。
不过，《阿尔卑斯山牧歌》带来的提醒比“控制速度”更深一层。
故事中的人物在山上待了太久。曾经象征自由的阳光和积雪，后来变成了让人无法逃脱的环境。高山生活形成了一套与山谷不同的时间和规则。人在其中停留得越久，越容易把极端状态当成正常状态。
黑客松也可能如此。
一开始，熬夜只是为了完成任务。后来，熬夜本身开始被当作投入的证明。最初，快速生成代码只是提高效率的方法。后来，代码增长的速度开始被误认为产品进展。最初，演示是为了让评委理解产品。后来，整个产品开始围绕演示效果生长。
团队逐渐形成一套只在比赛环境中成立的价值标准：
功能越多，产品越完整；界面越炫，体验越成熟；模型调用越复杂，技术含量越高；能够在台上跑通，产品就已经成立。
这些判断在山上可能有效，回到山谷以后却未必如此。
真实用户不会因为团队熬了几个晚上就原谅糟糕的体验，也不会因为系统接入了多个模型就产生使用需求。评委面前流畅运行的 demo，可能依靠大量硬编码、手工数据和被隐藏的异常路径。比赛中令人兴奋的技术挑战，放进现实场景后可能只是一个很少有人需要的功能。
因此，黑客松最危险的地方也许不是开发失败，而是团队在高度投入中失去对现实的感觉。
所有人都在努力解决问题，于是很少有人停下来追问，这个问题是否值得解决。所有人都在不断向代码库添加内容，于是删除功能反而需要更大的勇气。速度、疲惫和共同奋斗产生了一种强烈的意义感，让人很容易相信，投入越多，方向就越正确。
海明威笔下的高山非常美。问题出在人什么时候应该下山。
好的黑客松团队既要知道如何加速，也要知道什么时候停止增加功能；既要能在陡坡上快速转向，也要能在发现路线错误时重新爬坡；既要享受封闭环境中的高度专注，也要不断记得山谷里的真实世界。
因为产品开发最终没有停留在雪山上的资格。
比赛结束以后，灯光熄灭，评委离场，团队重新面对普通的时间尺度。此时，真正的问题才开始出现：用户是否需要它，架构是否可以维护，临时拼接的系统是否能够继续迭代，一起熬夜的人是否还愿意承担那些缓慢、重复、缺乏戏剧性的工作。
黑客松提供的是一次高速下山的机会。
但一个产品能不能活下来，取决于团队回到山谷以后，还能不能继续走路。