Communitygithub.com

hackathon-ideas

查找、筛选和排名符合特定黑客松规则、赛道、评判标准、所需技术及截止日期的项目创意,确保其解决真实且具体的根本问题。在需要为黑客松选择构建内容,或比较、压力测试候选创意时使用。

hackathon-ideas 是什么?

该技能旨在帮助开发者团队为黑客松生成并筛选出高质量的项目创意。它遵循一个严格的七步流程:首先从官方规则页面提取所有关键约束(赛道、评判标准、技术栈、截止时间等),并询问团队自身情况;然后,为避免平庸,它会先列出大多数团队都会想到的“显而易见的创意”并将其排除;核心步骤是通过深入分析论坛、GitHub Issues、应用商店评论等渠道,找出真实用户正在经历的实际问题及其根本原因,并辅以引用证据;之后,团队基于这些问题构思至少20个创意,并依据是否解决了根本原因、是否有证据、是否是AI或技术的“薄包装”、是否与现有产品或过往获奖者雷同、以及是否能在截止日期前完成等严格标准进行剔除;最后,对幸存创意依据黑客松的评判标准(并结合“深度”、“可构建性”和“演示强度”三个自有维度)进行打分和排名,输出包含演示脚本、风险假设及“砍掉”优先级在内的详细短名单。最终产物是清晰的Markdown文件,供团队决策并衔接后续的合规检查与演示制作技能。

兼容平台~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/vipink1203/vk-skills/tree/HEAD/skills/hackathon-ideas

在你喜欢的 AI 中提问

打开一个已预加载此 Agent Skill 的新对话。

文档

黑客松创意

我们构建的创意旨在解决一个真实问题的根本原因,为特定人物服务,并有证据表明该问题确实存在,同时基于一个洞察:一个非显而易见的真相,使得此解决方案在常规方法失效时依然有效。

欢迎小而简单的创意;平庸则不受欢迎。

一个创意只有在以下条件下才算合格:它在黑客松结束后仍有意义,并且评委无法仅从赛道名称就猜到它。

黑客松的胜负取决于其评判标准、在截止日期内完成,并通过一个演示时刻:在视频或现场演示的几秒钟内,评委看到作品运行并理解其价值。

关于黑客松的每一条事实都应来自其官方页面,并附上链接引用。

步骤

  1. 阅读简报。 从黑客松的官方页面、规则和常见问题解答(如果没有链接,请向用户索取)中,记录以下内容并附上来源链接:赛道和奖项、评判标准及其权重、必需的或赞助商提供技术、可能导致项目不合规的资格和规则(团队规模、已有代码、地区、许可协议)、提交要求(视频长度、代码仓库、现场演示、书面报告),以及截止日期和剩余时间。 然后,用不超过3个问题询问用户简报无法提供的信息:团队规模和技能、可用时间,以及他们有任何第一手了解的专业领域或倾向的赛道。 当上述每个字段都有了带引用的值或被标记为“未公布”时,该步骤即完成。 当没有公布评判标准时,使用黑客松评分标准中常见的四个同等标准(创意原创性、技术实现、潜在影响力、设计与演示),并在输出中标记为我们的替代方案。
  2. 编写显而易见列表。 在进行任何研究之前,写出大多数团队针对这些赛道和技术会提交的10个创意:任何人第一时间能想到的那些。 这些创意,以及任何是它们轻度变体的创意,都将在第5步中被剔除。
  3. 寻找真实问题。 这是最深入的一步;请投入最多的精力。 前往那些人们用自己的语言描述问题的地方,这些地点应在赛道和团队第一手知识所指的领域内:论坛、子论坛、GitHub Issues、支持和社区讨论帖、应用商店评论、专业群体、公开投诉以及监管报告。 特别关注变通方法:电子表格、脚本、手动重复输入、打印资料、群聊、付费助手做机器的工作;每一个变通方法都标志着一个人们已经在用时间付出代价的问题。 针对每个问题,不断追问“为什么”,直到触及结构性原因,而不是症状。 当笔记中至少包含10个不同的问题,每个问题都包含特定的人物和情境、至少一个带链接的引用或数据点、他们当前使用的变通方法以及根本原因时,该步骤即完成。
  4. 研究领域。 阅读该黑客松或系列赛事的过往获奖作品(例如,在Devpost上的项目画廊)、赞助商最近的发布内容及对必需技术的公开期望,以及已公开的本届提交作品。 当笔记中列出了至少五个过往或当前的项目以及赞助商的公开优先级,且均附有链接时,该步骤即完成。
  5. 生成,然后严格筛选。 写出至少20个创意,每个创意都基于第3步中的一个问题构建。 每个创意需包含:人物和情境、证据链接、它消除的根本原因、洞察、功能描述、演示时刻,以及必需的(赞助商)技术做出了哪些不可或缺的贡献。 然后,用一句话说明理由,剔除以下每一种创意:
    • 出现在显而易见列表或其轻度变体中的;
    • 无法指定特定人物和情境,或没有证据链接的;
    • 只处理了症状而根本原因依然存在的;
    • 是一个薄包装,即必需的技术或AI可以被一个表单、一个搜索框或一个模板替代而功能损失很小的;
    • 其洞察是任何人第一时间就能说出来的;
    • 与现有产品、过往获奖作品或当前提交作品高度相似的(搜索其最近邻并记录);
    • 违反规则,或者无法在剩余时间内,凭借团队技能完成一个可工作的演示时刻的。 当每个创意都被注明了被剔除或保留的理由,并且至少保留了5个创意时,该步骤即完成;当幸存者少于5个时,返回第3步寻找更多问题,而不是放宽筛选标准。
  6. 为幸存者打分。 对每个保留的创意,根据黑客松的每一个评判标准,按1到5分进行评分,并给出黑客松的权重以及每个评分的一行理由,同时加入我们自己的三个维度:深度(证据的强度以及消除根本原因的彻底性)、在剩余时间内的可构建性,以及演示强度。 按加权评判分数加上深度分数进行排名,在分数相同时,以可构建性高低打破平局。
  7. 编写短名单。 针对排名前三的创意,撰写:
    • 一句话推介:一句评委愿意重复的话。
    • 问题:人物、情境、带链接的证据引用、当前的变通方法以及根本原因。
    • 洞察:非显而易见的真相,以及为何现有工具忽略了它。
    • 最相似项目:找到的最接近的现有产品或项目,以及具体的不同点。
    • 目标:它竞争哪些赛道和奖项。
    • 分数:来自第6步的评分表。
    • 演示脚本:视频前30秒发生什么,展示人物的问题以及随后问题的消除。
    • 削减线:演示中哪些功能是必须工作的,哪些是锦上添花的,以便团队在时间紧迫时知道该放弃什么。
    • 最大风险假设:最可能失败的技术或产品赌注,以及一个不超过一小时的快速验证方案,用于在投入前测试该假设。

输出

每次运行后,为每个黑客松在 docs/hackathons/<event-slug>.md 路径下写入一个文件,并在后续运行时就地更新:包含带链接的简报、显而易见列表、带证据的问题笔记、领域研究、所有生成的创意及其剔除理由、评分表以及短名单。

在会话中,展示短名单和截止日期,然后请用户选择一个创意。

当团队承诺采用某个创意时,在外部人员(评委之外)使用该创意之前,它会经过 app-compliance 技能进行合规检查,并由 showcase 技能为其制作演示视频和提交用的README文件。

Individual skills in this repo

This repo contains 1 individual skill — each has its own dedicated page.

相关技能