نمونه‌کار AI بسازید؛ سه پروژهٔ روشن از ده مخزن مبهم بهتر است

برای نشان‌دادن مهارت AI در GitHub، در انتخاب فرضی میان سه پروژهٔ روشن و ده مخزن مبهم، توصیهٔ GitHub به سنجاق‌کردن سه تا پنج پروژهٔ مرتبط و متنوع را مبنا بگذارید. هر پروژه باید به‌روشنی نشان دهد چه مسئله‌ای را حل کرده‌اید، چه سهمی داشته‌اید و نتیجه را چگونه می‌توان اجرا و آزمود.

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

کدام پروژه‌ها را سنجاق کنید؟

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

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

• ارتباط با شغل: بتوانید بگویید کدام بخش از پیاده‌سازی به نیاز موقعیت موردنظر پاسخ می‌دهد.
• سهم قابل‌تشخیص: تصمیم‌ها و تغییرهای خود را از کار همکاران و خروجی ابزار AI جدا کنید.
• نتیجهٔ قابل‌بررسی: بازدیدکننده بتواند با یک ورودی نمونه، دمو یا دستور آزمون، ادعای README را به رفتار پروژه وصل کند.

برای انتخاب میان دو مخزن، جملهٔ «این پروژه مهارت من در ... را با ... نشان می‌دهد» را برای هرکدام کامل کنید. جای خالی دوم باید به شاهدی مشخص در همان مخزن برسد؛ نام یک مدل یا فهرست کتابخانه‌ها به‌تنهایی چنین شاهدی نیست. این پرسش کمک می‌کند ترتیب پروژه‌ها نیز تابع شغل هدف باشد، نه زمان ساخت یا پیچیدگی ظاهری آن‌ها.

در README چه چیزی بنویسید؟

README را با مسئله آغاز کنید: چه کسی از پروژه استفاده می‌کند، چه ورودی‌ای می‌دهد و چه خروجی‌ای می‌گیرد؟ سپس داده و تصمیم فنی را توضیح دهید. اگر داده پاک‌سازی شده، بخشی کنار گذاشته شده یا استفاده از آن محدودیت دارد، همان‌جا ذکر کنید؛ وگرنه خواننده نمی‌داند نتیجه بر چه پایه‌ای به دست آمده است.

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

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

• مسئله | Problem: «این ابزار به [کاربر] کمک می‌کند [کار مشخص] را با ورودی [نوع ورودی] انجام دهد و [نوع خروجی] بگیرد.»
• داده | Data: «داده از [منشأ واقعی] آمده، با [مرحلهٔ آماده‌سازی] پردازش شده و استفاده یا انتشار آن [شرط واقعی] دارد.»
• تصمیم فنی | Technical decision: «[روش انتخاب‌شده] را برای [نیاز مشخص] به کار بردم؛ دلیل انتخاب [معیار قابل‌توضیح] بود.»
• نقش AI و سهم من | AI role and my contribution: «مدل [وظیفه] را انجام می‌دهد؛ من [طراحی، پیاده‌سازی یا ارزیابی مشخص] را انجام دادم.»
• اجرا و دمو | Run and demo: پیش‌نیازها، دستور اجرا، یک ورودی نمونه و خروجی موردانتظار را بیاورید.
• آزمون | Tests: دستور آزمون، آنچه می‌سنجد و نتیجهٔ ثبت‌شده را بنویسید. ارزیابی کیفیت مدل را جدا از آزمون عملکرد کد توضیح دهید.
• محدودیت | Limitations: موارد شکست، وابستگی به سرویس بیرونی و هزینه یا نیاز سخت‌افزاریِ مؤثر بر اجرا را مشخص کنید.

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

اجرا و آزمون را قابل‌تکرار کنید

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

دمو الزاماً وب‌سایت عمومی نیست. اجرای محلی با ورودی کوتاه و خروجی قابل‌مشاهده نیز می‌تواند نشان دهد برنامه چه می‌کند. اگر پاسخ مدل در هر اجرا تغییر می‌کند، خروجی ثابت و تضمین‌شده وعده ندهید؛ توضیح دهید کدام ویژگی باید برقرار بماند، مانند حضور ارجاع به سند یا رعایت قالب پاسخ، و آن را چگونه می‌سنجید.

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

پروفایل و رزومه را به همین شواهد وصل کنید

در معرفی کوتاه پروفایل، حوزهٔ کاری و نقش مطلوب خود را بنویسید. پروژه‌ها را طوری مرتب کنید که نزدیک‌ترین نمونه به موقعیت شغلی زودتر دیده شود؛ توضیح کوتاه مخزن نیز باید همان مسئله‌ای را بیان کند که README باز می‌کند. در رزومه، کنار ادعای مهارت AI به پروژهٔ مرتبط پیوند دهید تا بررسی‌کننده برای یافتن شاهد آن میان مخزن‌های نامرتبط جست‌وجو نکند.

در آزمایش استخدامی دربارهٔ مهارت AI، ۱٬۷۲۵ استخدام‌کننده از بریتانیا، آمریکا و آلمان رزومه‌های فرضی را برای سه شغل ارزیابی کردند؛ درج مهارت AI احتمال دعوت به مصاحبه را حدود ۸ تا ۱۵ واحد درصد افزایش داد. این آزمایش اثر نمونه‌کار GitHub یا نتیجهٔ استخدام در بازار فارسی‌زبان را اندازه نگرفت. ارزش عملی مخزنِ روشن آن است که ادعای مهارت را به کاری قابل‌دیدن پیوند می‌دهد: خواننده می‌تواند روش، سهم شخصی و حدود نتیجه را در خود پروژه بررسی کند.

بیشتر بخوانید:

• تأیید انسانی برای عامل‌ها بسازید؛ توقف را فقط پیش از کار پرخطر بگذارید
• RAG یا پنجرهٔ زمینهٔ بلند؛ اسناد بیشتر همیشه پاسخ بهتر نمی‌سازند
• GPT-6 Sol و Luna آمدند؛ اختلاف قیمت ۲۰ برابری برای دو نوع کار