Web3 黑客松正确实践:2025 年务实指南
· 阅读需 13 分钟
内容摘要
- 有目的地选择活动。 优先选择你已经有所建树的生态系统,或者那些评委和赞助商与你的想法高度契合的活动。
- 明确获胜目标。 你是为了学习、为了特定的赏金(Bounty),还是为了入围决赛?每个选择都会改变你的团队构成、项目范围和技术栈。
- 提前准备基础工作。 在比赛开始前,准备好项目脚手架(Scaffold)、身份验证流程、钱包连接、设计系统以及演示脚本大纲。
- 构建最简可行且令人愉悦的演示(MVP Demo)。 展示一个核心功能的闭环端到端运行。其他的一切只是叙事和幻灯片。
- 像专业人士一样提交。 遵守“从零开始(Start Fresh)”的规则,正式注册你目标中的每一个赏金赛道,并预留充足的时间制作精炼的视频和清晰的 README。
为什么 Web3 黑客松值得你投入周末
- 压缩式学习: 在一个周末内,你将接触到基础设施、智能合约、前端 UX 和部署流水线。这是在 48 小时内完成的完整开发周期——这种学习曲线通常需要数月时间。
- 高质量社交: 导师、评委和赞助商工程师不仅是网站上的名字;他们集中在一个房间或 Discord 服务器中,随时准备提供反馈。这是你与日常使用的协议的核心开发者建立联系的机会。
- 真实的融资路径: 这不仅仅是为了获得荣誉。奖金池和后续资助(Grants)可以为项目的持续运行提供重要资金。像 Solana 的 Summer Camp 这样的活动曾提供高达 500 万美元的奖金和种子资金,将周末项目变成了可行的初创公司。
- 能力证明的作品集: 一个带有功能演示的公开 GitHub 仓库,其价值远超简历上的一个要点。它是你在压力下能够构建、交付和清晰表达想法的切实证明。
在哪里寻找优质活动
- ETHGlobal: 线下和异步(线上)活动的黄金标准。他们拥有完善的评审流程、高质量的参与者和非常适合寻找灵感的公开项目展示。
- Devpost: 各类黑客松的广泛市场,拥有针对区块链、特定协议和奖金赛道的强大筛选功能。它是发现特定生态系统活动的好地方。
- DoraHacks: 一个专注于生态驱动型 Web3 黑客松和资助轮次的平台,通常具有全球化和以社区为中心的氛围。
提示:持续时间差异很大。像 ETHOnline 这样的长周期异步活动会持续数周,而像 ETHDenver 的 #BUIDLathon 这样的延长版线下冲刺可能长达九天。你必须相应地规划你的项目范围。
解读规则(避免被取消资格)
- “从零开始(Start Fresh)”。 这是最常见且最关键的规则。大多数活动要求所有实质性工作在正式启动后开始。在核心逻辑中使用旧的、预先编写的代码可能会让你失去决赛和合作伙伴奖项的资格。模板代码(Boilerplate)通常没问题,但核心创意必须是全新的。
- 评审结构。 了解漏斗机制。通常,在现场评审开始前,会有一轮异步筛选,从数百个项目中筛选出入围项目。了解这一点有助于你专注于让提交的视频和 README 在第一轮筛选中尽可能清晰。
- 团队规模。 不要带着 10 人的团队出现。许多活动都有人数限制,例如 ETHDenver 典型的 2–4 人团队。这确保了公平竞争并鼓励紧密协作。
- 赏金(Bounty)机制。 你无法赢得你没有注册的奖项。如果你瞄准了赞助商的赏金,通常必须通过活动平台正式为每个特定奖项注册你的项目。这是许多团队会忘记的一个简单步骤。
评审标准:什么是“优秀”的作品
在各大组织者中,评委通常从四个维度评估项目。设计你的项目范围和演示,以便在每个项中得分。
- 技术深度(Technicality): 解决的问题是否具有挑战性?解决方案是否包含对技术的巧妙或优雅的使用?你是否不仅是在单个智能合约上套了一个简单的网页壳子?
- 原创性(Originality): 是否有新颖的机制、独特的用户体验或对现有原语(Primitives)的巧妙重新组合?这是我们已经见过一百次的东西,还是提出了新鲜的视角?
- 实用性(Practicality): 人们在“今天”就能使用它吗?一个完整的、端到端的用户路径,即使范围很窄,也比一个功能广泛但都只完成了一半的项目重要得多。
- 易用性(UI/UX/DX): 界面是否清晰、快速且易于使用?对于开发者工具,开发者体验如何?流畅的上手流程(Onboarding)和清晰的错误处理能让你脱颖而出。
团队设计:精简、敏锐、互补
为了速度和协作效率,2 到 4 人的团队是最理想的。这个规模既足以并行开展工作,又能在无需无休止争论的情况下做出决策。
- 智能合约 / 协议:掌控链上逻辑。负责编写、测试和部署合约。
- 前端 / DX:构建用户界面。管理钱包连接、数据获取、错误状态以及最终的演示润色,让项目更具真实感。
- 产品 / 叙事:范围把控者与叙述者。此人确保团队专注于核心闭环,编写项目描述并进行最终演示。
- (可选)设计师:一位专注的设计师可以成为秘密武器,准备组件、图标和微交互,从而提升项目的感知质量。
创意筛选:P-A-C-E 过滤法则
在编写第一行代码之前,使用这个简单的过滤法则对你的创意进行压力测试。
- 痛点 (Pain):这是否解决了开发者或用户的真实痛点?考虑钱包 UX、数据索引、MEV 保护或手续费抽象。避免为了解决问题而寻找技术方案。
- 原子性 (Atomicity):你能在 48 小时内构建并演示一个单一的、端到端的原子闭环吗?不是整个愿景 —— 只是一个完整、令人满意的用户动作。
- 可组合性 (Composable):你的创意是否依赖于现有的原语,如预言机、账户抽象或跨链消息传递?使用经过实战检验的乐高组件能让你走得更远、更快。
- 生态契合度 (Ecosystem fit):你的项目对活动的评委、赞助商和观众是否有可见度且相关?不要在以游戏为重点的赛道上推销复杂的 DeFi 协议。
如果你是以奖金为导向,选择 一个 主要赞助商赛道和 一个 次要赞助商赛道。将精力分散到过多的奖金项上会削弱你的深度,并降低获胜的机会。
减少阻力的默认技术栈
你的创新应该在于你构建了“ 什么”,而不是“如何”构建。坚持使用乏味但可靠的技术。
EVM 赛道(快速路径)
- 合约:Foundry(利用其在测试、脚本编写和运行本地节点方面的速度)。
- 前端:Next.js 或 Vite,结合
wagmi或viem,以及像 RainbowKit 或 ConnectKit 这样的钱包工具包用于弹窗和连接器。 - 数据/索引:如果需要查询历史数据,使用托管的索引器或 Subgraph 服务。避免运行自己的基础设施。
- 链下触发器:简单的作业运行器(Job Runner)或专门的自动化服务。
- 存储:IPFS 或 Filecoin 用于资产和元数据;简单的 KV 存储用于会话状态。
Solana 赛道(快速路径)
- 程序:Anchor(减少样板代码并受益于更安全的默认设置)。
- 客户端:React 或带有 Solana Mobile SDK 的移动框架。对 RPC 和程序调用使用简单的 Hook。
- 数据:依赖直接的 RPC 调用或生态系统索引器。积极使用缓存以保持 UI 响应迅速。
- 存储:如果相关,使用 Arweave 或 IPFS 进行永久资产存储。
务实的 48 小时计划
T-24 至 T-0(启动前)
- 明确你的获胜目标(学习、奖金、决赛)和目标赛道。
- 在纸上或白板上勾勒出完整的演示闭环。准确了解你将点击什么,以及每一步在链上和链下应该发生什么。
- Fork 一个干净的 Monorepo 脚手架,其中包含合约和前端应用的样板代码。
- 预先编写 README 大纲和演示脚本草稿。
第 0–6 小时
- 向活动导师和赞助商验证你的方案范围。确认奖金标准并确保你的创意契合。
- 设定硬性约束:一条链、一个核心用例以及演示中的一个“亮点时刻”。
- 将工作划分为 90 分钟的冲刺。你的目标是在第 6 小时前交付核心闭环的第一个完整垂直切片。
第 6–24 小时
- 巩固关键路径。测试正常路径和常见的边缘情况。
- 添加可观测性。实现基础日志、UI 提示 (Toasts) 和错误边界,以便快速调试。
- 创建一个简约的落地页,清晰解释项目背后的“原因”。
第 24–40 小时
- 一旦核心功能稳定,立即录制备份演示视频。不要等到最后一分钟。
- 开始编写和编辑最终提交的文本、视频和 README。
- 如果时间允许,添加一两个用心的点缀,如精美的空白状态、无 Gas 交易或文档中实用的代码片段。
第 40–48 小时
- 冻结所有功能。不再编写新代码。
- 完成视频和提交包。经验丰富的获胜者通常建议保留总时间的 ~15% 用于润色,并创建一个清晰遵循 60/40 分配(解释问题占 60%,演示方案占 40%)的视频。
演示与提交:让评委的工作更轻松
- 以“为什么”开头。在视频和 README 的开头用一句话解释问题和方案的结果。
- 展示闭环。演示而非口述。展示一个完整的、可信的用户旅程,不要跳过步骤。
- 叙述你的约束条件。承认你没有构建什么以及原因。例如:“我们将范围缩小到单一用例,以确保真实用户今天就能完成流程”,这展示了专注和成熟。
- 留下清晰的标记。你的 README 应该有架构图、在线演示链接和已部署合约的链接,以及一键在本地运行项目的简单步骤。
- 视频基础。尽早规划视频,紧凑编写脚本,确保清晰突出项目的功能、解决的问题以及底层运作机制。
拒绝过度劳累,高效参与赏金赛
- 为你瞄准的每个奖项进行注册。在某些平台上,这涉及点击明确的“开始工作” (Start Work) 按钮。
- 除非赞助商的技术在你的技术栈中自然重叠,否则不要同时追求超过 两个 赞助商赏金。
- 在你的提交中,对应他们的评分标准。使用他们的关键词,按名称引用他们的 API,并解释你如何满足了他们特定的成功指标。