1. 一家把充电做透的公司办黑客松，背后在想什么
1.1 先看懂 Anker 的“硬件+软件”版图
9 月 7 日，Anker 首届黑客松挑战赛报名启动。消息出来当天，我身边不少做开发的朋友第一反应都是：一家靠充电器、充电宝、储能电源出圈的消费电子公司，好端端办什么黑客松？这问题问得其实挺到位——办黑客松这件事，恰恰透露出 Anker 想做的事不只是一次市场活动。
把 Anker 的产品版图摊开看，你会发现它早就不是“卖充电配件的”那么简单了。充电和储能是一条线，Soundcore 音频是一条线，eufy 智能家居和安防是一条线，Nebula 投影、AnkerWork 办公设备、AnkerMake 3D 打印又是新的几条线。这些产品线的共同点是：硬件本身已经做得比较成熟，但真正的差异化越来越依赖软件、算法和场景整合。比如说，一个储能电源如果能根据用户用电习惯自动优化充放电策略，一个安防摄像头如果能更聪明地识别异常行为，这些都不是单纯堆硬件能解决的，而是需要开发者、算法工程师、产品经理坐在一起，把问题定义清楚，再在短时间内做出可用的原型。
这就是黑客松对于这类公司的真正价值：它是一次高效率的“外部研发采样”。公司想知道，当一批有想法的开发者脱离日常业务流程、在极限时间内自由组合时，会碰撞出什么新场景、新交互、新玩法。对参赛者来说，这也是一次难得的“甲方直连”机会——你面对的评委可能就是要为这些想法买单的人，而不是只看演示的一般观众。
1.2 从 9 月 7 日报名启动，能倒推出哪些信息
从时间节点上看，9 月 7 日启动报名，节奏上非常符合行业惯例。秋季黑客松通常会把报名期放在月初，留出两到三周让参赛者组队、提交初步想法，然后才进入筛选、公布入选名单、正式开赛的流程。如果你现在看到这个消息，最该做的不是等到截止前才匆匆填表，而是先把 9 月 7 日当作一个“起跑线”：从现在开始，你有充足的时间想清楚做什么、和谁组队、需要提前验证哪些技术点。
另外，这类硬件背景公司办的黑客松，评审逻辑往往和纯软件黑客松不太一样。纯软件黑客松可能更看重产品完成度、代码质量和用户体验；而像 Anker 这种有硬件基因的公司，评委大概率会更在意三件事：第一，你的方案能不能和真实硬件场景结合，而不是悬在空中；第二，你这个 idea 放到 Anker 现有的产品线里，有没有落地的可能性；第三，你在现场能不能把一个“可用状态”的东西演示出来，而不仅仅是讲一个宏大的故事。
2. 报名表上的 300 字：第一步就得筛掉大半项目
2.1 评审读报名资料时的四个潜台词
很多第一次参加黑客松的人会有个误区，觉得报名就是在官网填个名字、把团队写上去就完事。实际上，主办方在筛选阶段面对的报名数量往往远超预期，第一轮筛选最重的就是你在报名表上写的那段项目简介。他们不会花十分钟逐字读你的方案，更多时候是快速扫过，然后回答四个问题。
第一个潜台词是：这到底是不是一个真问题？评委见过的“伪需求”太多了。什么叫伪需求？就是你自己想象出来的、现实中很少有人真的为此困扰的问题。比如做一个“智能药盒提醒老人吃药”，听起来很有社会价值，但如果你没有接触过真实老人、没有了解过他们吃药的真实场景，很容易做出一个“看起来很贴心但实际很难用”的方案。相比之下，如果你说“我在给家里老人配药时发现，七个药瓶的标签容易混淆，经常出现早上吃错晚上的药”，这就具体得多，可信度也高得多。
第二个潜台词是：你们团队能把这个东西做出来吗？报名阶段评审会看一个信号——你提到的手段和你们团队的技术栈是不是匹配。假设你想做一个基于机器视觉的跌倒检测，但你团队四个人全是硬件工程师，没有一个写过深度模型推理代码，评委心里就会打鼓。不是说不能学，而是黑客松时间太短，现场从零学 AI 的风险太高。
第三个潜台词是：这个项目在 36 小时里做到什么程度才算“成功”？评审真正希望看到的，不是一份商业计划书，而是一个可触摸的 Demo。你在报名阶段最好就明确写出“我们将实现什么、现场会演示什么”，把边界画清楚。比如“实现摄像头实时识别手势并控制台灯开关”就比“打造全屋智能控制体验”好太多。
第四个潜台词是：它和 Anker 的产品/技术方向有没有关联？这一点很多参赛者会忽略。主办方办黑客松是带着业务眼光来的，你的项目如果和他们的硬件生态完全没有交集，哪怕创意再惊艳，在硬件背景评审眼里价值也会打折。这不是说你必须用他们的某个具体产品，而是至少要让项目处于“智能硬件、能源管理、音视频交互、家庭场景”这几条主线的射程范围内。
2.2 一个能过的项目简介，背后是这套写作逻辑
结合我过去参赛和帮人改报名材料的经验，300 字左右的项目简介，最稳的结构是“问题-场景-方案-演示目标”四段式，每段不要超过 80 字。
第一段写问题，要用一句话描述一个让人“哦，这确实烦”的场景，尽量写细节，不要写宏观。第二段写方案，用“我们打算做一个……，通过……实现……”这种句式，让评委一眼看懂你的技术路线。第三段写差异化，一句话说明为什么这事只有你们能做成，或者是已有的方案里缺了什么你们补上了。第四段写演示目标，明确告诉评委现场你们会演示什么、能演示到什么程度。
这里有一个特别容易踩的坑：不要在报名阶段就承诺太多功能。写“我们会在 36 小时内实现语音控制、App 联动、智能调度三种能力”，等于在给自己挖坑。到现场你会发现，任何一个看似简单的功能，在硬件联调时都可能吃掉你两个小时。宁可把演示目标写小一点，写“实现单一场景下的可靠 Demo”，也不要让评委带着“看大戏”的预期进场。
提示：如果你现在已经有组队意向但还没确定项目方向，可以先不填具体题目，围绕“你最熟悉的一个痛点场景+Anker 产品线”想想交集。评委对一个“来自真实使用场景”的项目，包容度会高很多。
3. 入选之后到开赛之前，建议按这个节奏推进
3.1 第一周：把整项目压缩成“最小演示闭环”
假设报名顺利、拿到了入场资格，从确认入选到开赛，通常有一到两周的窗口期。这一两周用得好的团队，和直接裸奔进场的团队，现场表现完全是两个层级。
第一周我只做一件事：把项目压缩成一个“最小演示闭环”。什么叫最小演示闭环？就是沿着用户使用路径，找到最核心的 1 个交互节点，然后把这个节点做通。比如你想做一个储能设备与手机 App 联动的智能节电方案，最核心的演示节点不是“App 上展示各种统计报表”，而是“手机发送一个指令，设备真实地调整了输出功率”。后者是所有功能里最硬核、最容易出问题、最需要提前验证的部分，你必须最先把它打通。
这一周还要做一次“风险排序”。把项目涉及的技术拆成三档：A 档是已经掌握的、现场基本不会出问题的；B 档是做过但不算熟练、有一定失败概率的；C 档是没做过、风险极高的。然后按照“C 档优先验证、B 档做备份方案、A 档留到最后”的原则分配时间。绝大部分项目翻车，都是因为 C 档技术占比太高，而团队又天真地以为现场 36 小时可以边学边做。
3.2 第二周：环境、备份、以及一套“失败预案”
第二周的核心是“预演”和“防呆”。无论你的项目是纯软件还是软硬结合，都要把所有环境依赖提前装好、锁版本、写清楚部署步骤。很多现场事故不是代码写错，而是环境不一致：在家里跑得好好的模型，到了比赛现场依赖冲突、网络受限、GPU 驱动不对，直接白费半天。
如果你是做硬件相关项目，备份就更加重要了。常用传感器、单片机、连接线、转接头，至少要准备两套。不要觉得这是小题大做——黑客松现场掉链子最狠的往往不是逻辑 Bug，而是“传感器昨天还好好的，今天读不到数据了”这种玄学问题。我见过一个团队因为一根 HDMI 线接触不良，在最终评审前 20 分钟才发现画面完全黑屏，最后只能拿着手机照片给评委讲，效果自然大打折扣。
第二周内还应该做一次小范围的模拟答辩。找一个不参与项目的人，给他 3 分钟，让他听完你的 Demo 脚本，然后问他三个问题：你想解决什么问题？你的方案和现有方案有什么不同？为什么现在要做？这三个问题他答得越顺，说明你们的叙事越清晰；如果他支支吾吾，说明你们还没把项目“一句话讲明白”。别小看这步，到了现场面对评委，能一句话讲清楚项目的团队，起评分就比讲不清楚的高一截。
4. 现场 36 小时的真实节奏：时间、精力与演示风险
4.1 按“冲刺-整合-打磨”三段切分，别一上来就写代码
到了比赛日，现场的气氛会非常容易让人上头。尤其是第一次参赛的人，往往比赛宣布开始就冲回座位，打开编辑器开始写代码，写到深夜发现核心功能还没有跑通，第二天早上才开始手忙脚乱地整合，最后连演示环境都没摆好。我把这种状态叫作“无效忙碌”。更稳妥的做法是把 36 小时切成三个明确的阶段。
第一阶段是“需求锁定+架构敲定”，大致占开赛后的前 4 个小时。这段时间不急着写代码，而是把项目范围再砍一遍：今天下午必须跑通什么、明天上午必须整合什么、演示前 3 小时只用来打磨什么，逐条写下来贴在桌面上。团队内部要对“什么叫完成”达成一致，否则每个人都会按自己的理解往里面加东西。注意，这个阶段最容易出现的危险是“中途换方向”。除非原本方案被证伪到完全走不通，否则不要轻易换题。黑客松现场没有哪个方向是完美的，坚持做下去，把已有的推到可演示状态，永远比重新开始一个半生不熟的项目更有胜算。
第二阶段是“核心功能密集开发”，大约从开赛 4 小时到第二天中午。这个阶段的关键词是“频繁集成”，不要每个人在自己分支里埋头写 12 个小时最后才合并。至少每隔两小时做一次集成，哪怕还只是把各部分拼起来跑一遍 main 函数也行。集成越频繁，冲突越少，最后的“地狱联调”就越短。对硬件相关项目来说，这个阶段还要特别小心“串口通信断连”这类问题，早点把通信链路稳定下来，后面的功能都是在这条链路上堆起来的。
第三阶段是“演示打磨”，从第二天中午到评审开始。这个阶段不要再加新功能了，功能再炫如果演示流程没跑顺，等于零。花时间把演示脚本走三遍：第一遍完整走功能，第二遍掐表看时长，第三遍模拟“现场翻车”的情况，比如网络断了、设备没电了、蓝牙连不上，手里有没有 Plan B。这三遍走完，你上台的底气会完全不一样。
4.2 现场最容易翻车的五个瞬间及应对套路
36 小时里，翻车不可怕，可怕的是翻车后没有预案。根据我参加过的多场硬件黑客松经验，现场出现频率最高的五个事故，基本可以提前预防。
第一是“演示时设备断电”。这个发生率比你想象得高得多。应对方式是提前准备一个多口 USB 充电器、一根长线缆、一个电量充足的移动电源，把它作为演示专用电源，不要和开发调试用电混在一起。第二是“现场网络不稳定”。如果你的项目依赖云服务或在线模型推理，务必准备一个本地离线版本的降级方案，哪怕效果差一点，能跑通就比白屏强。第三是“会议室投影/屏幕兼容问题”。提前到现场测试转接头，自带一根 HDMI 线和至少一个 USB-C 转 HDMI 的转接头，两样东西加起来几十块钱，但能避免你对着一个无法识别的外接屏手足无措。
第四是“团队内部意见分歧导致进度停滞”。这个属于人的问题，比技术问题更棘手。我的建议是：遇到分歧时，先定一个“决策截止时间”，比如最多吵 30 分钟，确定一个方向就走，做完了发现问题再回头调。黑客松没有时间留给完美主义。第五是“演示前发现显示器上全是调试输出、界面丑到没法看”。这个属于审美细节，技术含量不高但很影响观感。提前留出 30 分钟设置好演示界面，把控制台日志关掉，开一个干净清爽的演示窗口。
注意：现场如果出现你不理解的技术故障，优先采用“重启大法”和“换线大法”来测试。很多莫名其妙的硬件问题都是接触不良或缓存异常，简单重启往往能解决一半以上的故障。
5. 评委打分时不会明说的优先级：从“做完”到“拿奖”
5.1 硬件背景评委最怕看到的三类项目
参与过这类赛事的评审工作之后，你就会知道评委在看 Demo 时真正紧张的是什么。硬件背景公司的评委，最怕看到的第一类项目是“纯 PPT 项目”——打开屏幕全是架构图和路线图，问到关键实现就说“我们未来会做”。这类项目哪怕立意再宏大，评委也会在打分时给出很低的评价，因为黑客松的本质是“做出来”，不是“想清楚”。
第二类是“伪硬件项目”。有些团队为了迎合主办方，在 PPT 里画了和硬件结合的蓝图，但现场 Demo 只是在一个网页或模拟器上演示，连一个真实传感器的数据都没读到。评委对这种项目会格外敏感，因为硬件能力本身就是这类赛事的门槛，你没有用真实的硬件交互来验证方案，等于主动放弃了主场优势。
第三类是“功能过多、深度不足”的项目。这类团队往往贪多求全，做了五六个功能但每个功能都只有浅层实现。评委一个个点过去，每个功能都能用但都经不起追问——一问调度逻辑就含糊，一问异常处理就说没考虑。这会让评委产生一个明显的判断：你们团队缺乏聚焦能力。与其五个功能每个 60 分，不如一个功能做到 95 分，至少这能向评委证明你们的执行力。
5.2 真正拉开差距的，是“演示叙事”和“后续落地设想”
那高分项目到底赢在哪里？除了功能完成度，我看下来最关键的差距通常在两件事上。
第一件事是“演示叙事”。同样一个功能，会讲和不会讲，打分能差出一个档位。不会讲的团队会按功能列表一个个演示：“这是设备管理，这是数据图表，这是设置页面。”会讲的团队会先构建一个场景：“早上 8 点，你出门前看了一眼手机，发现昨晚储能设备在电价低谷期自动充满了电……”然后在这个场景里，让评委看到他每一步操作背后的用户价值。前者是“演示产品”，后者是“讲述故事”，而评委最终买的是后者。你的 Demo 脚本要尽量按故事线来写，而不是按功能清单来写。
第二件事是“后续落地设想”。评审环节往往留有一些提问时间，很多团队在这个环节支支吾吾，只会回答“这个想法后续还有很多可以完善的地方”这种空话。真正高分团队会提前想好：如果要把它变成产品，第一步做什么，第二步做什么；最大的技术瓶颈在哪里，需要什么样的资源才能跨过去；有没有在 36 小时里识别出某个“短期内就能改进的 quick win”。这些问题想没想过、答得够不够具体，评委一听就知道。它反映的不是你的演示能力，而是你作为一个做产品的人的系统思考能力。
6. 最后一份拿来就能用的“黑客松物资+准备清单”
6.1 可以提前一天核对完的硬件物资清单
到最后，分享一份我自己每次参加黑客松都会提前一天核对的具体清单，尤其适合软硬结合的项目。这份清单不是让你全部背过去，而是逐项问自己“这个我需不需要”。
先说硬件类。你需要自带的不只是电脑，至少应该带一台备用开发板（常用型号最好备两块）、足够的传感器模块、一个多口充电器、100W 级别的移动电源、三根数据线（USB-A 到 C、C 到 C、Micro-B 各一根）、一个 USB 集线器、一根 HDMI 线、一个 USB-C 转 HDMI 转接头、一套螺丝刀工具套装、几根杜邦线和面包板。不要觉得自己是纯软件项目就不用带硬件——现场很多硬件团队会因为缺一个传感器找你借东西，你带来的“额外装备”往往是你社交破冰和找外援的最好筹码。
再说软件类。工作电脑上需要提前装好所有依赖环境，锁好依赖版本，准备好离线安装包。如果你是做模型推理相关项目，记得把模型文件下载到本地，不要依赖比赛现场的网速去下几个 GB 的权重。另外，提前把项目的 README 写好，包含一键启动命令、环境变量说明、常见问题排查，这些不只对评委有用，对 36 小时后的你自己同样有用——人一旦熬到凌晨，记忆力和判断力都会断崖式下跌。
6.2 组队和心态上的三条经验
最后三条经验，算是我这几年黑客松踩坑踩出来的心得，分享给准备参赛的朋友。
第一条关于组队：不要全是技术同质化的人。如果你和技术背景完全一样的人组队，写代码时效率可能很高，但到了定义问题和讲故事的阶段，整个团队就会集体沉默。理想配置是两到三个技术成员加一个能承担产品和叙事角色的成员。注意，这个“产品角色”不一定要有产品经理头衔，只要有人愿意主动去理清需求边界、编排演示节奏、盯住时间节点，就够了。技术再强，如果没人拿表盯进度，一样会在整合阶段翻车。
第二条关于精力分配：不要迷信“熬夜才能赢”。前半夜把核心功能跑通，后半夜轮换休息，第二天白天用清醒的头脑做整合和打磨，这个效率远高于所有人红着眼熬到天亮。很多翻车现场其实就是“凌晨 5 点脑子不清醒的人改坏了原本能用的代码”。适度熬夜可以理解，但全员熬通宵在这个时代已经不是值得炫耀的事情了。
第三条关于心态：把目标定成“做出一个能打动人心的 Demo”，而不是“拿第一名”。黑客松最迷人的一点，是短时间内的极限输出会让你发现自己的边界和可能性。哪怕最后没有拿奖，一个亲手做出来的、能跑能演示的完整原型，也比你在工位上写三个月的模块更有成就感。把注意力放在“做出东西”本身，结果往往是水到渠成的。
从 9 月 7 日报名启动到正式开赛，这段准备期本身就是一场小型的“预演”。愿你在这个秋天，和各路思路清晰、动手能力强的开发者一起，把想法真正变成摸得着的原型。
