راهنماها

۲۰ ایده پروژه هکاتون که در یک آخر هفته می‌توانید نمایش دهید

بهترین ایده‌های پروژه‌ی هکاتون یک مشکل مشخص را برای یک فرد مشخص حل می‌کنند و می‌توان آن را در کمتر از سه دقیقه، به‌صورت زنده نشان داد. معمولاً این یعنی یک وب‌اپ با یک مسیر اصلی: یک فرم، کمی منطق یا یک فراخوانی API، و یک نتیجه‌ی واضح روی صفحه. در ادامه بیست ایده را بر اساس موضوعات رایج هکاتون دسته‌بندی کرده‌ایم. برای هر کدام مخاطب، دمویی که در ۲۴ تا ۴۸ ساعت می‌توان ساخت، اینکه بعد از رویداد چطور می‌تواند به کسب‌وکار تبدیل شود، و بخش سختِ واقعی آن را توضیح داده‌ایم. یکی را انتخاب کنید، آن را کوچک کنید، و یک‌چهارم پایانی زمان را صرف دمو کنید.

اگر ایده‌هایی می‌خواهید که بعد از رویداد هم ادامه پیدا کنند، ایده‌های پروژه‌ی جانبی که با هوش مصنوعی می‌سازید و ایده‌های استارتاپ هوش مصنوعی گزینه‌های بهتری هستند. این فهرست برای یک آخر هفته تنظیم شده است.

ایده‌ای انتخاب کنید که با رویداد هم‌خوانی دارد

اگر رویداد درباره‌ی ... استایده‌های قوی از این فهرستچیزی که داوران معمولاً دنبال آن هستند
جامعه و فناوری شهری۱ تا ۴یک مشکل واقعی محلی، کاربران مشخص
آموزش۵ تا ۸دانش‌آموزان یا معلمان واقعاً کمک گرفته باشند
اقلیم و پایداری۹ تا ۱۱یک تغییر قابل اندازه‌گیری، عددهای صادقانه
سلامت و دسترسی‌پذیری۱۲ تا ۱۴دقت در داده‌ها و ایمنی
ابزارهای توسعه‌دهنده۱۵ تا ۱۷صرفه‌جویی واقعی در وقت توسعه‌دهنده
هوش مصنوعی و API۱۸ تا ۲۰استفاده‌ی هوشمندانه از مدل، نه فقط یک جعبه‌ی چت

همیشه قوانین و معیارهای داوری رویداد را اول بخوانید؛ آن‌ها بیشتر از موضوع رویداد تعیین‌کننده‌اند.

جامعه و فناوری شهری

۱. تابلوی اشیای گمشده برای یک دانشگاه یا محل برگزاری

  • مخاطب: دانشجویان، بازدیدکنندگان جشنواره‌ها، اعضای باشگاه ورزشی.
  • دمو: یک شیء پیداشده را با عکس و مکان ثبت کنید، بر اساس دسته جست‌وجو کنید، و یک جریان «این مال من است» داشته باشید که به یابنده اطلاع می‌دهد.
  • بعد از رویداد: محل‌های برگزاری می‌توانند برای یک تابلوی با برند پول بدهند؛ بیشتر آن‌ها این را یک خدمت رایگان می‌بینند.
  • بخش سخت: جلوگیری از ادعاهای جعلی. یک پرسش ساده که فقط مالک می‌تواند پاسخ دهد («رنگ قاب گوشی چیست؟») یک لحظه‌ی خوب در دمو می‌سازد.

۲. تطبیق‌دهنده‌ی شیفت داوطلبان

  • مخاطب: بانک‌های غذا، پناهگاه‌ها و خیریه‌هایی که برنامه‌ی کاری روی کاغذ دارند.
  • دمو: مدیر برنامه شیفت‌ها را با ظرفیت می‌سازد؛ داوطلبان با گوشی ثبت‌نام می‌کنند؛ یک داشبورد جای خالی‌ها را نشان می‌دهد. سازنده‌ی برنامه‌ریزی هسته‌ی کار را پوشش می‌دهد.
  • بخش سخت: جلب توجه یک سازمان واقعی. یک پیشنهاد قیمت یا عکس از برنامه‌ی کاغذی واقعی را به ارائه بیاورید.

۳. نقشه‌ی مکان‌های دسترس‌پذیر برای یک شهر

  • مخاطب: افراد با ویلچر، والدین با کالسکه‌ی کودک، افرادی با نیازهای حسی.
  • دمو: نقشه‌ای از مکان‌ها با دسترسی بدون پله، توالت‌های مناسب و ساعات آرام، و فرمی برای افزودن یا اصلاح یک مکان.
  • بخش سخت: داده‌ای که بتوان به آن اعتماد کرد. نشان دهید هر مورد از کجا آمده و آخرین بار کی بررسی شده است.

۴. تصمیم‌های شورای شهر به زبان ساده

  • مخاطب: ساکنانی که هرگز صورتجلسه‌ها را نمی‌خوانند.
  • دمو: یک دستور جلسه‌ی عمومی را جای‌گذاری یا بارگذاری کنید، یک خلاصه‌ی کوتاه و ساده دریافت کنید که نشان دهد چه چیزی تصمیم‌گیری می‌شود و چه زمانی، و دکمه‌ی «این موضوع را دنبال کن».
  • بخش سخت: دقت. متن اصلی را کنار خلاصه نشان دهید تا مردم بتوانند بررسی کنند.

آموزش

۵. گروه‌یاب مطالعه برای یک درس

  • مخاطب: دانشجویانی که در کلاس‌های بزرگ کسی را نمی‌شناسند.
  • دمو: درس و زمان‌های آزاد خود را انتخاب کنید، گروه‌های مناسب را ببینید و به یکی بپیوندید. سازنده‌ی فهرست پایه‌ی خوبی است.
  • بخش سخت: ایمنی و حریم خصوصی. برای ورود از ایمیل دانشگاهی استفاده کنید و شماره تلفن شخصی را نشان ندهید.

۶. تمرین امتحان‌های گذشته با نمره‌دهی فوری

  • مخاطب: دانش‌آموزانی که برای یک امتحان مرور می‌کنند.
  • دمو: سؤال‌های چندگزینه‌ای بر اساس موضوع، بازخورد فوری، و نمودار موضوعات ضعیف. ساخت یک اپ آزمون را ببینید.
  • بعد از رویداد: یک سطح پولی با سؤال‌های بیشتر می‌تواند جواب دهد، اگر خودتان سؤال بنویسید.
  • بخش سخت: حق نشر. از سؤال‌هایی استفاده کنید که خودتان نوشته‌اید یا هیئت برگزارکننده‌ی امتحان اجازه‌ی استفاده از آن‌ها را داده است.

۷. ابزار بلیط خروج کلاسی

  • مخاطب: معلمانی که می‌خواهند در پایان درس سریع بفهمند «آیا متوجه شدند؟».
  • دمو: معلم یک بررسی دو سؤالی می‌سازد، دانش‌آموزان با یک کد روی گوشی پاسخ می‌دهند و معلم در چند ثانیه خلاصه را می‌بیند.
  • بخش سخت: کار در کلاس واقعی: بدون ورود برای دانش‌آموزان زیر ۱۳ سال، و سریع روی اینترنت ضعیف مدرسه.

۸. تطبیق‌دهنده‌ی سطح خواندن

  • مخاطب: معلمان و والدینی که کودکشان سطح خواندنی پایین‌تر یا بالاتر از سن خود دارد.
  • دمو: یک متن را جای‌گذاری کنید و سطح خواندن را انتخاب کنید؛ یک مدل هوش مصنوعی متن را بازنویسی می‌کند و واژه‌های سخت را با تعریف هایلایت می‌کند.
  • بخش سخت: حفظ معنا. هر دو نسخه را کنار هم نشان دهید و اجازه دهید معلم ویرایش کند.

اقلیم و پایداری

۹. رزرو و دفترچه‌ی کافه‌ی تعمیر

  • مخاطب: رویدادهای تعمیر در جامعه.
  • دمو: افراد برای یک وسیله نوبت رزرو می‌کنند، داوطلبان آنچه را تعمیر شده ثبت می‌کنند، و صفحه‌ای مجموع وسایلی را که از سطل زباله نجات یافته‌اند نشان می‌دهد. سازنده‌ی رویداد مناسب است.
  • بخش سخت: عددهای تأثیر صادقانه. تعداد وسایل تعمیرشده را بشمارید؛ عددهای کربنی را که نمی‌توانید پشتوانه‌اش را نشان دهید، جعل نکنید.

۱۰. داشبورد انرژی دفتر یا مدرسه

  • مخاطب: کارکنان تأسیسات و کمیته‌های محیط‌زیستی.
  • دمو: خوانش کنتور را بارگذاری کنید (یا یک فایل نمونه)، مصرف را بر اساس روز و اتاق ببینید، و جهش‌های غیرعادی را علامت بزنید. از سازنده‌ی داشبورد شروع کنید.
  • بخش سخت: داده‌ی واقعی. اگر نمی‌توانید کنتورهای زنده را بگیرید، همین را بگویید و با یک نمونه‌ی برچسب‌خورده دمو کنید.

۱۱. اشتراک‌گذاری غذای مازاد در یک ساختمان

  • مخاطب: دفاتر، خوابگاه‌ها، یخچال‌های اجتماعی.
  • دمو: غذای باقی‌مانده را با عکس و زمان تحویل ثبت کنید، اعلان دریافت کنید و آن را بردارید. موارد به‌صورت خودکار منقضی می‌شوند.
  • بخش سخت: قوانین ایمنی غذا. فقط غذای بسته‌بندی‌شده یا با برچسب واضح را بپذیرید و یک صفحه‌ی کوتاه از رهنمودها اضافه کنید.

سلامت و دسترسی‌پذیری

در این موضوع احتیاط کنید. دمو نباید تشخیص بدهد یا توصیه‌ی پزشکی بدهد، و نباید از داده‌های واقعی بیماران استفاده کنید.

۱۲. یادآور دارو برای مراقبان

  • مخاطب: کسانی که از پدر، مادر یا فرزندی با چند نوع دارو مراقبت می‌کنند.
  • دمو: داروها را با زمان‌بندی اضافه کنید، یادآور دریافت کنید، دوزهای مصرف‌شده را تیک بزنید، و یک نمای فقط‌خواندنی با خواهر یا برادر خود به اشتراک بگذارید.
  • بخش سخت: قابلیت اطمینان. یادآوری از دست‌رفته اهمیت دارد؛ در ارائه صادق باشید که دمو یک دستگاه پزشکی نیست.

۱۳. صف انتظار اتاق کلینیک

  • مخاطب: کلینیک‌های بدون نوبت، داروخانه‌ها، مراکز مشاوره.
  • دمو: با اسکن یک کد وارد صف شوید، موقعیت خود را ببینید و وقتی نوبت‌تان نزدیک است پیام دریافت کنید.
  • بخش سخت: افرادی که گوشی هوشمند ندارند. نشان دهید کارکنان چطور آن‌ها را به‌صورت دستی اضافه می‌کنند.

۱۴. بررسی‌گر دسترس‌پذیری وب‌سایت برای یک مشکل

  • مخاطب: صاحبان وب‌سایت‌های کوچک.
  • دمو: یک آدرس وارد کنید، یک مورد را خوب بررسی کنید (نبودن متن جایگزین تصاویر، یا کنتراست پایین رنگ‌ها)، و اصلاحات را نشان دهید.
  • بخش سخت: عمق به‌جای گستردگی. یک بررسی درست و کامل بهتر از بیست بررسی سطحی است. چطور وب‌سایت خود را دسترس‌پذیر کنیم اصول را توضیح می‌دهد.

ابزارهای توسعه‌دهنده

۱۵. سرور ساختگی پاسخ API از روی یک نمونه

  • مخاطب: توسعه‌دهندگان فرانت‌اند که منتظر بک‌اند هستند.
  • دمو: یک پاسخ نمونه‌ی JSON را جای‌گذاری کنید و یک آدرس زنده بگیرید که همان را برگرداند، با تأخیر یا خطای اختیاری.
  • بعد از رویداد: ابزارهای زیادی این کار را می‌کنند، پس بیشتر یک پروژه‌ی یادگیری است تا یک کسب‌وکار.
  • بخش سخت: متمایز بودن. یک ویژگی متفاوت انتخاب کنید، مثلاً ساختن داده‌ی ساختگی واقعی‌نما از روی نمونه.

۱۶. خلاصه‌ی درخواست ادغام برای غیرتوسعه‌دهندگان

  • مخاطب: مدیران محصول که می‌خواهند بدانند این هفته چه چیزی تغییر کرده.
  • دمو: یک مخزن عمومی را وصل کنید (یا یک diff را جای‌گذاری کنید)، و یک خلاصه‌ی ساده از تغییرات را بر اساس ویژگی دریافت کنید. گیت‌هاب چیست مبانی را پوشش می‌دهد.
  • بخش سخت: دسترسی‌ها. در دمو از مخازن عمومی استفاده کنید و هرگز توکن دسترسی را در فرانت‌اند جای‌گذاری نکنید.

۱۷. بررسی‌گر متغیرهای محیطی

  • مخاطب: تیم‌هایی که با یک تنظیم گمشده دیپلوی‌شان خراب می‌شود.
  • دمو: یک فایل پیکربندی نمونه را با یک فایل واقعی مقایسه کنید (با مقادیر پنهان) و آنچه کم یا بلااستفاده است را فهرست کنید.
  • بخش سخت: هرگز نشان ندادن مقادیر محرمانه. چطور کلیدهای API را ایمن نگه داریم توضیح می‌دهد چرا.

پروژه‌های هوش مصنوعی و API

این‌ها محبوب هستند، پس سطح انتظار بالاتر است. یک جعبه‌ی چت روی یک مدل کافی نیست؛ یک کار مشخص را بهتر از قبل نشان دهید.

۱۸. تقسیم‌کننده‌ی فیش

  • مخاطب: دوستانی که صورتحساب رستوران را تقسیم می‌کنند.
  • دمو: عکس یک فیش بگیرید، اپ اقلام را می‌خواند، هر نفر آنچه را خورده است لمس می‌کند، و نشان می‌دهد چه کسی چقدر بدهکار است.
  • بخش سخت: خواندن فیش‌های نامرتب. اجازه دهید افراد اشتباهات را سریع اصلاح کنند؛ این بخشی از دمو است.

۱۹. تبدیل یادداشت جلسه به فهرست اقدام

  • مخاطب: انجمن‌های دانشجویی و تیم‌های کوچک.
  • دمو: یادداشت‌ها یا متن جلسه را جای‌گذاری کنید، اقدام‌ها را با مسئول و تاریخ دریافت کنید، و برای هر نفر بفرستید.
  • بخش سخت: مسئولان اشتباه و مهلت‌های ساختگی. برای هر اقدام، جمله‌ی منبع را نشان دهید.

۲۰. پرکننده‌ی فرم با صدا

  • مخاطب: افرادی که فرم‌های طولانی برایشان سخت است: کاربران مسن‌تر، افراد با دیسلکسیا یا کم‌بینایی.
  • دمو: پاسخ‌ها را برای فرم، یک سؤال در هر بار، با صدا بگویید؛ اپ فیلدها را پر می‌کند و برای تأیید دوباره می‌خواند.
  • بخش سخت: گرفتن رضایت درست و هرگز ارسال نکردن بدون بررسی نهایی توسط انسان.

برای هر ایده‌ی هوش مصنوعی به یک کلید API نیاز دارید و درخواست‌ها هزینه دارند؛ چطور از APIهای LLM استفاده کنیم کلیدها، هزینه‌ها و محدودیت‌ها را توضیح می‌دهد.

چطور برنده شویم (یا دست‌کم تمام کنیم)

  1. اول اسکریپت دمو را بنویسید. سه جمله: کاربر کیست، چه کاری انجام می‌دهد، و چه چیزی می‌بیند. فقط آنچه اسکریپت لازم دارد را بسازید.
  2. مسیر اصلی را تا نیمه‌ی زمان کار کنید. برای بخش‌های خسته‌کننده مثل ورود، فرم‌ها و پایگاه داده از قالب‌ها، کیت‌های شروع یا یک ساز اپ با هوش مصنوعی استفاده کنید. ابزاری مثل Mythex می‌تواند یک وب‌اپ کارا با پایگاه داده بسازد و آن را روی یک لینک منتشر کند، که به تیم شما وقت برای بخش هوشمندانه می‌دهد. ابتدا قوانین رویداد را درباره‌ی ابزارها بررسی کنید.
  3. از داده‌ی نمونه‌ی واقع‌گرایانه استفاده کنید. ده ورودی باورپذیر دمو را واقعی جلوه می‌دهد؛ «تست تست ۱۲۳» این کار را نمی‌کند.
  4. یک ویدیوی پشتیبان ضبط کنید. در هکاتون‌ها وای‌فای قطع می‌شود. یک ضبط دو دقیقه‌ای ارائه را نجات می‌دهد.
  5. مشکل یک فرد واقعی را نشان دهید. نقل قولی از کسی که با او صحبت کرده‌اید، یا عکسی از فرآیند کاغذی که جایگزین می‌کنید.
  6. درباره‌ی محدودیت‌ها صادق باشید. داوران «این داده‌ی نمونه است» را بیشتر از ادعایی که می‌توانند آن را ببینند و رد کنند، محترم می‌شمارند.

چطور یک MVP را در یک آخر هفته بسازیم درباره‌ی کوچک کردن دامنه بیشتر توضیح می‌دهد. اگر پروژه بعد از رویداد جدی شد، چطور ایده‌ی اپ را اعتبارسنجی کنیم قدم بعدی است.

پرسش‌ها

یک پروژه خوب هکاتون چه ویژگی‌هایی دارد؟

یک مشکل مشخص برای یک فرد مشخص، دمویی که به‌صورت زنده در دو یا سه دقیقه کار کند، و یک نکته واقعاً هوشمندانه یا خوب اجرا شده. داوران معمولاً تیمی را به یاد می‌آورند که مشکل واقعی یک کاربر را از اول تا آخر حل کرده باشد، نه تیمی که بیشترین امکانات را داشته است.

یک پروژه هکاتون باید چقدر بزرگ باشد؟

کوچک‌تر از آنچه فکر می‌کنید. روی یک مسیر اصلی کاربر برنامه‌ریزی کنید: کسی وارد می‌شود، کار اصلی را انجام می‌دهد و نتیجه را می‌بیند. این مسیر را تا نیمه‌ی زمان کار کنید، سپس بقیه‌ی وقت را صرف بهبود ظاهر، دمو و ضبط پشتیبان کنید.

آیا می‌توان در هکاتون از ابزارهای هوش مصنوعی استفاده کرد؟

معمولاً بله، اما قوانین رویداد را بررسی کنید. برخی هکاتون‌ها می‌خواهند کد در طول رویداد نوشته شود، از شما می‌خواهند ابزارها و کتابخانه‌ها را اعلام کنید، یا مسیرهای خاص با شرایط جداگانه دارند. اگر شک دارید، قبل از شروع از برگزارکنندگان بپرسید.

یک مبتدی در هکاتون چه چیزی باید بسازد؟

یک وب‌اپ ساده با یک فرم، یک پایگاه داده و یک صفحه‌ی نتایج: یک فرم ثبت‌نام، یک تابلوی اشیای گمشده یا یک برنامه‌ریز مطالعه. استفاده از یک ساز اپ با هوش مصنوعی یا یک قالب آماده برای بخش‌های پایه، وقت کافی برای تمرکز روی ایده و دمو باقی می‌گذارد.

Mythex · Pricing · با هوش مصنوعی هر چیزی بسازید · قالب‌های وب‌سایت و اپلیکیشن · مقایسه‌ی Mythex · واژه‌نامه‌ی ساخت اپلیکیشن با هوش مصنوعی · ابزارهای رایگان ساخت اپلیکیشن با هوش مصنوعی · English

English አማርኛ العربية Български বাংলা Bosanski Català Čeština Dansk Deutsch Ελληνικά Español Español (España) Eesti Suomi Français Français (Canada) ગુજરાતી हिन्दी Hrvatski Magyar Հայերեն Bahasa Indonesia Íslenska Italiano 日本語 ქართული Қазақ тілі ಕನ್ನಡ 한국어 Lietuvių Latviešu Македонски മലയാളം Монгол मराठी Bahasa Melayu မြန်မာ Norsk bokmål Nederlands ਪੰਜਾਬੀ Polski Português (Brasil) Português (Portugal) Română Русский Slovenčina Slovenščina Soomaali Shqip Srpski Svenska Kiswahili தமிழ் తెలుగు ไทย Tagalog Türkçe Українська اردو Tiếng Việt 简体中文 繁體中文(香港) 繁體中文(台灣)