خلاصه اجرایی
نسخه رسمی roadmap.sh، وایبکدینگ را بهعنوان ساخت نرمافزار با کمک مدلهای زبانی و دستورهای زبان طبیعی معرفی میکند و در نقشه رسمی خود، روی چند ستون اصلی تأکید دارد: تعریف و ذهنیت، انتخاب پشته فنی، پرامپتنویسی، زمینهٔ پروژه، تست، اشکالزدایی، امنیت، کنترل نسخه و ابزارها. در راهنمای best practices همان مجموعه نیز چرخهٔ کاری بهشکل روشنتر بازتعریف شده است: زمینهٔ تمیز، برنامهریزی پیش از کدنویسی، بازبینی خروجی، حفاظت از کدبیس و استانداردسازی workflowها. [1]
اما برای آموزش حرفهای، فقط تکرار همان گراف کافی نیست. مستندات رسمی Claude Code، Codex، GitHub Copilot، Gemini CLI و Cursor همگی به زبانهای مختلف همان چند اصل را تکرار میکنند: دستورهای پایدار در فایلهای پروژه، گرفتن plan پیش از تغییر، محدود کردن دامنهٔ درخواست، خواندن diff، اجرای تست بعد از هر تغییر، و استفاده از مهارتهای تکرارشونده، زیرعاملها و MCP برای مقیاسپذیری. بنابراین اینفوگرافیک فارسی بهتر است «فرایندمحور» باشد، نه «ابزارمحور»؛ یعنی اول روش درست را آموزش بدهد و بعد ابزارهای نمونه را در همان چارچوب قرار دهد. [2]
یک نکتهٔ مهم این است که «وایبکدینگ» در معنای اولیهٔ طنزآمیزِ Andrej Karpathy و در تفسیر دقیق Simon Willison، بیشتر به نمونهسازی کمریسک و حتی گاهی «Accept All» بدون خواندن diff اشاره دارد؛ اما این با توسعهٔ مسئولانهٔ AI-assisted یکی نیست. همین تمایز، باید در نسخه فارسی با یک نوار هشدار روشن نمایش داده شود: «نمونهسازی سریع» با «کدنویسی تولیدیِ قابل اتکا» فرق دارد. [3]
بههمین دلیل، پیشنهاد نهایی این گزارش این است که اینفوگرافیک فارسی شما از مسیر رسمی roadmap.sh الهام بگیرد، ولی آن را به یک نقشهٔ خواندنیتر و قابلچاپ تبدیل کند: یک لایهٔ «پایههای حداقلی»، یک ستون میانی «چرخهٔ اجرای درست»، یک ریل کناری برای «اشتباهات پرهزینه»، و یک فوتر برای «تمرینها، زمانها و چکپوینتها». این نسخه هم برای مخاطب مبتدی خواناتر است، هم برای مربی و طراح گرافیک آمادهتر. [4]
چارچوب مفهومی و یافتههای تحقیق
در این گزارش، واژهٔ «وایبکدینگ» را در معنای آموزشیِ گستردهترِ roadmap.sh بهکار میبرم: توسعه با عاملهای کدنویس و مدلهای زبانی، از ایده تا دیباگ و بازبینی. بااینحال، برای پرهیز از سوءبرداشت، تفکیک Simon Willison مفید است: «کمک گرفتن از LLM برای نوشتن کد» الزاماً وایبکدینگِ بیقیدوبند نیست؛ اگر کد را بفهمید، تست کنید و بتوانید توضیحش دهید، عملاً در حال مهندسی نرمافزار هستید، نه صرفاً «رها کردن خود به حسوحال». [5]
خود roadmap.sh بهطور ضمنی همین بلوغ را پیشنهاد میکند. در بخش ذهنیت میگوید AI بیشتر شبیه یک توسعهدهندهٔ junior در کنار شماست: باید با او گفتوگو کنید، زمینه بدهید، خروجی را چک کنید و اصلاحش کنید. همانجا تصریح میشود که هنوز باید مبانی برنامهنویسی را بفهمید، حتی اگر لازم نباشد همهٔ جزئیات نحوی را حفظ باشید. این نکته برای نسخه فارسی بسیار مهم است، چون بسیاری از پوسترهای شتابزده، وایبکدینگ را طوری معرفی میکنند که انگار هر نوع دانش پایه غیرضروری شده است. [6]
چرا باید روی «زمینهٔ تمیز» و «کارهای کوچک» اصرار کرد؟ چون هم راهنمای رسمی roadmap.sh و هم پژوهشهای بنیادیتر یک هشدار مشترک میدهند: زمینهٔ کهنه یا بیشازحد شلوغ باعث افت کیفیت میشود. مقالهٔ best practices در roadmap.sh صریحاً میگوید بیشتر شکستهای کدنویسیِ AI از context کهنه یا overloaded میآیند. از آن طرف، مقالهٔ «Lost in the Middle» نشان میدهد حتی مدلهای long-context هم همیشه اطلاعات طولانی را بهطور مقاوم و یکنواخت بهکار نمیگیرند و وقتی دادهٔ مهم وسط متن قرار بگیرد، عملکرد افت میکند. Anthropic هم در راهنمای long-context خود پیشنهاد میکند دادههای طولانی را بالای prompt، و پرسش را پایین بیاورید و از ساختاردهی روشن استفاده کنید. [7]
همینطور نباید از بنچمارکها این نتیجهٔ غلط را گرفت که «عاملهای کدنویس دیگر مسئلهٔ مهندسی واقعی را حل کردهاند». SWE-bench دقیقاً برای اندازهگیری توان مدلها در حل مسائل واقعیِ مخزنی ساخته شده است، چون edit کردن یک repo واقعی با issue و pull request مسئلهای سخت و چندلایه است. از سوی دیگر، METR در یک RCT روی توسعهدهندگان باتجربهٔ متنباز گزارش کرد که ابزارهای AI اوایل ۲۰۲۵ در مخزنهای آشنا، بهطور متوسط آنها را کندتر کردهاند؛ زیرا زمان prompting، انتظار و مخصوصاً بازبینی و اصلاح خروجی بالا بوده است. بنابراین نقشهٔ یادگیری درست باید از روز اول روی review، test و rollback حساب باز کند، نه فقط روی سرعت تولید. [8]
در لایهٔ امنیت، شواهد نیز همسو هستند. بخش امنیت roadmap.sh روی environment variables و audit پیش از go-live تأکید دارد. GitHub Copilot هم توصیه میکند کارهای حساس و بحرانی، مخصوصاً امنیت، اطلاعات شخصی، احراز هویت و incident response را بهعنوان نخستین دستهٔ وظایف به عامل نسپارید. OWASP Top 10 همچنان کنترل دسترسی، تزریق، پیکربندی ناامن و مدیریت دادهٔ حساس را از ریسکهای اصلی وباپها میداند. افزون بر این، Veracode در گزارش ۲۰۲۵ خود روی ناامن بودن بخش قابلتوجهی از کدهای تولیدشده توسط LLMها هشدار داده است. پس در نسخه فارسی، امنیت نباید یک گوشهٔ کوچک باشد؛ باید یکی از ستونهای اصلی باشد. [9]
طرح اینفوگرافیک فارسی آماده تولید تصویر
منطق چیدمان
بهجای کپیبرداری مستقیم از گراف roadmap.sh، پیشنهاد بهتر برای مخاطب فارسیزبان این است که پوستر را بهشکل یک پوستر عمودیِ خوانا طراحی کنید: یک هدر پرقدرت، سپس یک ستون میانیِ مرحلهبهمرحله، با دو ریل جانبی برای «اشتباهات پرهزینه» و «جعبهابزار»، و در پایان یک فوتر برای «پروژههای تمرینی» و «چکپوینتهای ارزیابی». این رویکرد، ساختار موضوعی roadmap.sh را به ترتیب یادگیری تبدیل میکند و اصول رسمیِ context → plan → review → protect → scale را نیز روشنتر نشان میدهد. [10]
|
بخش |
جایگاه در پوستر |
کارکرد طراحی |
|
هدر |
۱۵٪ بالای بوم |
عنوان، تعریف یکخطی، نوار اصول |
|
ستون میانی |
۵۵٪ میانی |
مسیر یادگیری در ۸ کارت متوالی |
|
ریل راست |
۱۵٪ |
اشتباهات پرهزینه و باورهای غلط |
|
ریل چپ |
۱۵٪ |
ابزارها، فایلهای زمینه و آزمونها |
|
فوتر |
۱۵٪ پایین |
پروژههای تمرینی، زمانها، چکپوینتها |
متنهای دقیق آماده درج
متنهای زیر، نسخهٔ فارسیِ پیشنهادی و ویرایششده برای درج مستقیم در تصویر هستند. این متنها از ساختار roadmap.sh، راهنمای best practices، و مستندات رسمی ابزارها بازنویسی شدهاند تا هم دقیق باشند و هم برای طرح گرافیکی کوتاه و خوانا بمانند. [11]
متن هدر
|
ناحیه |
متن آماده |
|
عنوان اصلی |
نقشه راه یادگیری وایبکدینگ |
|
زیرعنوان |
از ایده تا محصول قابل اتکا با کمک عاملهای کدنویس |
|
تعریف کوتاه |
وایبکدینگ یعنی ساخت نرمافزار با دستورهای زبان طبیعی و همکاری با عاملهای کدنویس؛ اما در کار حرفهای، بازبینی، تست و امنیت حذفشدنی نیستند. |
|
نوار اصول |
زمینهٔ تمیز · اول طرح · دامنهٔ محدود · دیف را بخوان · تست را اجرا کن |
کارتهای مسیر اصلی
|
کارت |
عنوان |
متن کوتاه |
برچسب پایین کارت |
|
کارت نخست |
تعریف و ذهنیت |
هوش مصنوعی همکار سریع است، نه داور نهایی. |
هدایت، نه واگذاری کامل |
|
کارت دوم |
پایههای حداقلی |
وب یا پایتون، ترمینال، ساختار فایل و خطاهای رایج را بفهم. |
بدون این پایه، سرعت پایدار نمیشود |
|
کارت سوم |
کنترل نسخه |
Commitهای کوچک، شاخههای کوتاه، و بازگشت امن با Git. |
هر تغییر باید راه برگشت داشته باشد |
|
کارت چهارم |
زمینهٔ پروژه |
CLAUDE.md / AGENTS.md / GEMINI.md / Rules را کوتاه و دقیق نگه دار. |
ساختار، فرمان اجرا، محدودیتها |
|
کارت پنجم |
اول برنامه، بعد اجرا |
پیش از کدنویسی، plan بگیر و فرضها را فهرست کن. |
فرض پنهان = خطای پنهان |
|
کارت ششم |
پرامپتنویسی دقیق |
هدف، قیدها، فایلهای مجاز، و معیار موفقیت را روشن بنویس. |
نمونهٔ مرجع بده |
|
کارت هفتم |
بازبینی و تست |
هر diff را بخوان؛ سپس typecheck، lint و test را اجرا کن. |
قبول بدون فهم = خطر |
|
کارت هشتم |
امنیت و مقیاسدهی |
رازها، مهاجرتها، دسترسیها، Skillها و MCP را جدی بگیر. |
پروتوتایپ با تولید فرق دارد |
ریل راست
|
بلوک |
متن آماده |
|
عنوان ریل |
اشتباهات پرهزینه |
|
مورد نخست |
هرچه زمینه بیشتر، بهتر ← نه؛ زمینهٔ کهنه کیفیت را پایین میآورد. |
|
مورد دوم |
اول کد بزنیم، بعداً plan میگیریم ← نه؛ plan قبل از اجرا جلوی آشفتگی را میگیرد. |
|
مورد سوم |
همهٔ تغییرات را Accept All کن ← نه؛ diff باید خوانده شود. |
|
مورد چهارم |
تست را آخر کار مینویسیم ← نه؛ تست باید همراه ساخت افزوده شود. |
|
مورد پنجم |
عامل خودش امنیت را میفهمد ← نه؛ ناحیههای حساس باید با محدودیت و بازبینی دستی کنترل شوند. |
ریل چپ
|
بلوک |
متن آماده |
|
عنوان ریل |
جعبهابزار |
|
فایلهای زمینه |
CLAUDE.md · AGENTS.md · GEMINI.md · Copilot Instructions · Cursor Rules |
|
کیفیت کد |
Git · ESLint · Ruff · Vitest · pytest · Playwright |
|
عاملها |
Claude Code · Codex · Cursor · GitHub Copilot · Gemini CLI |
|
مقیاسدهی |
Skillها · زیرعاملها · MCP |
فوتر
|
بلوک |
متن آماده |
|
عنوان فوتر |
پروژههای تمرینی و چکپوینتها |
|
پروژهٔ نخست |
فهرست کارها در خط فرمان |
|
پروژهٔ دوم |
وباپ سادهٔ یادداشت با رابط کاربری و تست |
|
پروژهٔ سوم |
سرویس کارها با API، تست سراسری و بازبینی امنیت |
|
چکپوینت نخست |
میتوانم برای هر feature یک plan شفاف بگیرم. |
|
چکپوینت دوم |
میتوانم فایل زمینهٔ کوتاه و دقیق بنویسم. |
|
چکپوینت سوم |
میتوانم تغییرات خطرناک را در diff تشخیص بدهم. |
|
چکپوینت چهارم |
میتوانم پیش از اصلاح باگ، تست شکستخورده بسازم. |
|
چکپوینت پنجم |
میتوانم برای migration طرح بازگردانی بنویسم. |
رنگ، آیکون و نمونههای مرجع بصری
برای خوانایی حرفهای، یک پالت تیره با کنتراست بالا توصیه میشود: پسزمینه #0B1220، سطح کارت #111827، متن اصلی #F9FAFB، متن فرعی #CBD5E1، آبی برای «زمینه» (#38BDF8)، بنفش برای «پرامپت و plan» (#8B5CF6)، سبز برای «تست و کیفیت» (#10B981)، کهربایی برای «بازبینی» (#F59E0B) و قرمز برای «امنیت و خطاها» (#EF4444). آیکونها نیز بهتر است مینیمال و خطی باشند: حباب گفتوگو، ترمینال، شاخهٔ Git، سند قواعد، قطبنما، ذرهبین، تیک سپر، و اتصال شبکه برای MCP. این بخش توصیهٔ طراحی است، نه بازتاب مستقیم یک منبع خاص.
برای نمونههای بصری مرجع، خود roadmap اصلی، تصویر «Standard instruction types in CLAUDE.md»، تصویر «Plan Mode workflow»، و تصویر «Feature development workflow with Claude Code» در راهنماهای رسمی roadmap.sh بهترین الگوها هستند، چون دقیقاً همان فرایندهای context، plan، review و workflow را که این گزارش بر آنها تکیه دارد، بهصورت تصویری نشان میدهند. [12]
مشخصات فنی خروجی SVG و PNG
مشخصات بوم و شبکه
|
مشخصه |
پیشنهاد اصلی |
|
نسبت تصویر |
عمودی |
|
اندازهٔ اصلی چاپ |
A3 عمودی |
|
اندازهٔ پیشنهادی SVG |
viewBox="0 0 3508 4961" |
|
خروجی PNG چاپی |
3508 × 4961 px با رزولوشن ۳۰۰dpi |
|
خروجی PNG دیجیتال |
2160 × 3840 px برای نمایشگر و شبکههای اجتماعی |
|
حاشیهٔ امن |
۱۶۰px از هر طرف |
|
شبکه |
۱۲ ستون با gutter حدود ۵۶px |
|
فاصلهٔ عمودی بین کارتها |
۴۰ تا ۵۶px |
|
گوشهٔ کارتها |
۲۸px |
|
سایه |
بسیار ملایم؛ در SVG زنده بماند، در PNG تختسازی شود |
تایپوگرافی و قواعد ویرایشی
برای متن فارسی، Vazirmatn انتخاب بسیار خوبی است، چون یک خانوادهٔ فارسی-عربی آزاد و متنباز با وزنهای متعدد است و برای متن رابط و وب مناسب طراحی شده است. برای برچسبهای کدی و نام فایلها، JetBrains Mono مناسب است، چون یک تایپفیس free/open-source ویژهٔ توسعهدهندگان است. [13]
|
نقش تایپوگرافی |
فونت |
وزن |
اندازهٔ پیشنهادی |
|
عنوان اصلی |
Vazirmatn |
ExtraBold |
۱۱۲–۱۳۲px |
|
زیرعنوان |
Vazirmatn |
SemiBold |
۴۸–۵۸px |
|
عنوان کارت |
Vazirmatn |
Bold |
۴۰–۴۸px |
|
متن کارت |
Vazirmatn |
Regular |
۳۰–۳۶px |
|
برچسبهای کدی |
JetBrains Mono |
Medium |
۲۶–۳۰px |
برای جلوگیری از خطاهای فارسی، این چکلیست ویرایشی را حتماً قبل از export نهایی اجرا کنید:
|
مورد کنترل |
صورت درست پیشنهادی |
|
نام اصلی |
وایبکدینگ |
|
Prompting |
پرامپتنویسی |
|
Planning |
برنامهریزی |
|
Debugging |
اشکالزدایی |
|
Version Control |
کنترل نسخه |
|
Context |
زمینهٔ پروژه |
|
Review |
بازبینی |
|
Rollback |
بازگردانی |
|
Unit Test |
تست واحد |
|
End-to-End Test |
تست سراسری |
همچنین بهتر است متن فارسی راستچین باشد، اما نام ابزارها و فایلها مثل CLAUDE.md، AGENTS.md، pytest و Playwright در capsules جداگانه یا در ردیفهای monospace لاتین نمایش داده شوند تا هم خوانا باشند و هم از غلط املایی جلوگیری شود.
اسکلت پیشنهادی SVG
نمونهٔ زیر یک اسکلت حداقلی برای فایل master است؛ نه برای استفادهٔ نهایی، بلکه برای شروع کار طراح یا ابزار گرافیکی:
<svg xmlns="http://www.w3.org/2000/svg" width="3508" height="4961" viewBox="0 0 3508 4961">
<defs>
<style>
.fa { font-family: "Vazirmatn", sans-serif; direction: rtl; unicode-bidi: plaintext; }
.mono { font-family: "JetBrains Mono", monospace; direction: ltr; }
.title { font-size: 124px; font-weight: 800; fill: #F9FAFB; }
.subtitle { font-size: 54px; font-weight: 600; fill: #CBD5E1; }
.card-title { font-size: 46px; font-weight: 700; fill: #F9FAFB; }
.card-body { font-size: 32px; font-weight: 400; fill: #CBD5E1; }
</style>
</defs>
<rect x="0" y="0" width="3508" height="4961" fill="#0B1220"/>
<text class="fa title" x="3348" y="220" text-anchor="end">نقشه راه یادگیری وایبکدینگ</text>
<text class="fa subtitle" x="3348" y="310" text-anchor="end">از ایده تا محصول قابل اتکا با کمک عاملهای کدنویس</text>
<rect x="160" y="420" rx="28" ry="28" width="3188" height="260" fill="#111827"/>
<text class="fa card-title" x="3260" y="510" text-anchor="end">تعریف و ذهنیت</text>
<text class="fa card-body" x="3260" y="580" text-anchor="end">هوش مصنوعی همکار سریع است، نه داور نهایی.</text>
<rect x="160" y="740" rx="28" ry="28" width="3188" height="260" fill="#111827"/>
<text class="fa card-title" x="3260" y="830" text-anchor="end">پایههای حداقلی</text>
<text class="fa card-body" x="3260" y="900" text-anchor="end">وب یا پایتون، ترمینال، ساختار فایل و خطاهای رایج را بفهم.</text>
</svg>
اگر طراح شما با Figma، Illustrator یا Inkscape کار میکند، بهتر است master را بهصورت SVG زنده نگه دارید و فقط خروجیهای نهایی برای شبکههای اجتماعی را PNG کنید. متنها را تا آخرین مرحله outline نکنید تا بازبینی املایی و اصلاح نسخه آسان بماند.
مسیر درست یادگیری و اشتباهات رایج
سوءبرداشتها و اصلاح آنها
|
سوءبرداشت رایج |
اصلاح دقیق |
چرا مهم است |
شواهد |
|
وایبکدینگ یعنی لازم نیست کد را بخوانم |
برای نمونهسازیهای کمریسک شاید بتوانید سریع جلو بروید، اما در کار حرفهای باید بتوانید تغییر را توضیح دهید، diff را بخوانید و خروجی را تست کنید |
نخواندن کد مساوی است با واگذاری قضاوت مهندسی به مدل |
Simon Willison، roadmap.sh و راهنمای review. [14] |
|
هرچه context بیشتر، خروجی بهتر |
context باید تازه، کوتاه و مرتبط باشد |
زمینهٔ شلوغ باعث فراموشی، تناقض و افت کیفیت میشود |
roadmap.sh best practices، Anthropic، Lost in the Middle. [15] |
|
ابزار خوب، خودش plan میگیرد |
plan باید در workflow شما اجباری باشد |
بدون plan، مدل وسط اجرا تصمیمهای معماری میگیرد و کدبیس را شلخته میکند |
roadmap.sh، Claude Code، Copilot cloud agent. [16] |
|
تست را بعد از تمام شدن feature مینویسیم |
از AI بخواهید همزمان با ساخت، تست هم بنویسد |
فاصلهٔ زیاد بین تغییر و تست، پیدا کردن ریشهٔ خطا را سخت میکند |
roadmap.sh testing، Vitest، pytest، Playwright. [17] |
|
کارهای حساس مثل auth و migration را هم میشود یکجا به عامل سپرد |
ناحیههای حساس باید off-limits یا نیازمند plan، rollback و review دستی باشند |
این بخشها بیشترین هزینهٔ خرابی را دارند |
roadmap.sh security/migration، GitHub Copilot، OWASP. [18] |
|
مدل اگر تستها را پاس کرد، یعنی راهحل درست است |
تستِ عبوری شرط لازم است، نه کافی |
خود Anthropic هشدار میدهد مدل ممکن است برای پاسکردن تستها hard-code یا workaround بسازد |
Anthropic prompt engineering. [19] |
|
Skills و MCP فقط امکانات جانبیاند |
در پروژههای واقعی، اینها برای کاهش تکرار، کنترل context و اتصال به ابزارها حیاتی میشوند |
بدون آنها، promptها تکراری و sessionها پرهزینه و آشفته میشوند |
Anthropic، Codex، Gemini CLI، Cursor، MCP. [20] |
برنامه درسی گامبهگام
زمانهای زیر برآورد آموزشی پیشنهادی هستند. این برآورد از گسترهٔ موضوعی roadmap.sh، مدت ۳۰ تا ۴۵ دقیقهای تمرین نخست در tutorial رسمی roadmap.sh، و حجم واقعی setup / context / plan / test / review در مستندات رسمی ابزارها استنتاج شدهاند. برای کسی که از قبل برنامهنویسی بلد است، این زمانها معمولاً بهمراتب کمتر میشود. [21]
|
مرحله |
چه یاد بگیرید |
تمرین و پروژه |
زمان پیشنهادی |
چکپوینت ارزیابی |
منابع مرجع |
|
ذهنیت و نصب |
تعریف وایبکدینگ، تفاوت نمونهسازی با تولید، نصب یک عامل اصلی |
یک repo خالی بسازید و از عامل بخواهید ساختار پروژه را توضیح دهد |
مبتدی: ۲–۴ ساعت / دارای پایه: ۱ ساعت |
میتوانید بگویید عامل شما چه چیزهایی را میبیند و چه چیزهایی را نه |
roadmap، Claude/Codex/Gemini overview. [22] |
|
پایههای حداقلی |
HTML/CSS/JavaScript یا Python، ترمینال، مدیریت بستهها |
یک CLI کوچک یا صفحهٔ ساده بسازید و تکتک فایلها را توضیح دهید |
مبتدی: ۱۰–۱۸ ساعت / دارای پایه: ۲–۴ ساعت |
میتوانید flow داده را در یک برنامهٔ ساده توضیح دهید |
React، Next.js، FastAPI، roadmap mindset. [23] |
|
کنترل نسخه و کیفیت محلی |
Git، branch، commit کوچک، revert، lint و format |
عمداً یک تغییر بد بسازید و با git revert برگردانید؛ سپس lint را اجرا کنید |
مبتدی: ۴–۶ ساعت / دارای پایه: ۲ ساعت |
بدون ترس میتوانید به آخرین وضعیت سالم برگردید |
roadmap version control، Git docs، ESLint، Ruff. [24] |
|
زمینهٔ پروژه |
نوشتن CLAUDE.md یا AGENTS.md یا GEMINI.md یا Rules/Copilot Instructions |
یک فایل زمینهٔ ۳۰ تا ۵۰ خطی بنویسید: run commands، conventions، off-limits |
مبتدی: ۳–۵ ساعت / دارای پایه: ۱–۲ ساعت |
فایل زمینهٔ شما کوتاه، دقیق و بدون تاریخگذشته است |
roadmap context، Claude memory، Codex AGENTS، Gemini CLI، Copilot، Cursor Rules. [25] |
|
برنامهریزی و پرامپتنویسی |
Plan mode، assumptions، scope، example file، success criteria |
برای افزودن یک feature، اول plan بگیرید؛ فرضها و فایلهای درگیر را فهرست کنید |
مبتدی: ۶–۸ ساعت / دارای پایه: ۳–۴ ساعت |
هیچ تغییر بزرگی را بدون plan شروع نمیکنید |
roadmap best practices، Claude plan mode، Anthropic prompting، Copilot prompt tips. [26] |
|
بازبینی، تست و دیباگ |
خواندن diff، typecheck، واحد، integration، E2E، استفاده از log |
یک feature را با test بنویسید، بعد عمداً bug بسازید و «اول testِ خراب» را تمرین کنید |
مبتدی: ۱۰–۱۴ ساعت / دارای پایه: ۶–۸ ساعت |
میتوانید بگویید هر change چه فایلهایی را عوض کرده و چرا |
roadmap review/testing/debugging، Vitest، pytest، Playwright. [27] |
|
امنیت و migrations |
env vars، input validation، access control، migration plan، rollback |
یک feature دارای .env و schema change فرضی طراحی کنید، اما پیش از اجرا plan و rollback بنویسید |
مبتدی: ۸–۱۲ ساعت / دارای پایه: ۴–۶ ساعت |
auth، secrets و schema change را بهعنوان high-risk تشخیص میدهید |
roadmap security، GitHub sensitive-task guidance، OWASP، Veracode. [28] |
|
Skills، زیرعاملها و MCP |
skillهای تکرارشونده، subagents، اتصال ابزارها و منابع بیرونی |
یک Skill برای code review یا write-tests بسازید و یک MCP server مجاز اضافه کنید |
مبتدی: ۸–۱۲ ساعت / دارای پایه: ۴–۶ ساعت |
promptهای تکراری شما به skill تبدیل شدهاند و context شلوغ نشده است |
roadmap scale، Claude skills، Codex skills/subagents، Gemini skills، Cursor skills/MCP، MCP spec. [29] |
جعبهابزار و کتابخانههای پیشنهادی
بهجای اینکه ابزارها را «بهترین» یا «بدترین» بنامیم، برای یادگیری حرفهای بهتر است آنها را بر اساس نقششان در workflow دستهبندی کنیم. خود roadmap.sh هم ابزارها را زیرشاخهٔ یک مهارت بزرگتر میبیند، نه جانشین آن مهارت. [30]
|
نقش |
گزینههای مناسب |
چرا مفید است |
منبع |
|
عامل اصلی ترمینالی |
Claude Code، Codex، Gemini CLI |
برای plan، اجرا، خواندن/ویرایش فایل، تست و automation |
مستندات رسمی هر سه ابزار. [31] |
|
عامل درون IDE |
Cursor، GitHub Copilot |
برای repo-level context، rules، code review و task delegation |
Cursor docs و GitHub Docs. [32] |
|
پروتوتایپ سریع رابط |
v0، Lovable، Bolt.new، Replit |
برای نمونهسازی سریع و low-stakes، نه لزوماً workflow سختگیرانهٔ تولید |
فهرست ابزارهای roadmap.sh. [33] |
|
زمینهٔ پایدار پروژه |
CLAUDE.md، AGENTS.md، GEMINI.md، Copilot Instructions، Cursor Rules |
حذف تکرار، همراستاسازی عامل با conventions پروژه |
Claude، Codex، Gemini، Copilot، Cursor. [34] |
|
تست فرانتاند و فولاستک |
Vitest، Playwright |
unit/component و E2E در اکوسیستم JS/TS |
Vitest، Playwright. [35] |
|
تست بکاند پایتون |
pytest |
ساده، بالغ و استاندارد برای Python |
pytest docs. [36] |
|
lint و format |
ESLint، Ruff |
کشف سریع ایرادهای سبک، کیفیت و بخشی از bugها |
ESLint، Ruff docs. [37] |
|
گسترش قابلیت عامل |
MCP، Skills، Subagents |
اتصال به ابزارها و workflowهای تکرارشونده با context تمیزتر |
MCP spec، Claude/Codex/Gemini/Cursor. [38] |
|
پشتهٔ شروع وب |
React، Next.js، Tailwind |
رایج، مستند و سازگار با نمونههای فراوان AI-assisted |
roadmap tech-stack، React/Next/Tailwind docs، دادههای محبوبیت GitHub و Stack Overflow. [39] |
|
پشتهٔ شروع API |
Python + FastAPI |
سریع، خوانا و مناسب برای تمرین API و testability |
roadmap tech-stack و FastAPI docs. [40] |
اگر مخاطب شما مبتدی مطلق است، بهترین شاخهٔ شروع معمولاً یکی از این دو است: فرانتاند سبک با React/Next.js/Tailwind یا بکاند سبک با Python/FastAPI. دلیل این پیشنهاد فقط محبوبیت نیست؛ roadmap.sh هم صراحتاً روی پشتههای mainstream تأکید میکند، و هم اسناد رسمی و جامعهٔ توسعهدهندگان برای این مسیرها مثال و مستندات بسیار بیشتری دارند. [41]
اسکریپت مدرس و نمودارهای Mermaid
اسکریپت کوتاه مدرس
اسکریپت زیر بر پایهٔ همان چرخهٔ رسمیای نوشته شده که در roadmap.sh و مستندات ابزارها تکرار میشود: زمینه → plan → prompt محدود → review → test → security → scale. [42]
«امروز قرار نیست به هوش مصنوعی نقش جادوگر بدهیم؛ قرار است به او نقش یک همکار سریع اما نیازمند هدایت بدهیم. اول مسئله را شفاف میکنیم، بعد زمینهٔ پروژه را مشخص میکنیم، بعد از عامل میخواهیم طرح بدهد، نه اینکه مستقیم کد بریزد.
وقتی plan را دیدیم، سه چیز را میپرسیم: چه فایلهایی عوض میشوند، چه فرضهایی پشت این طراحی هست، و چه چیزی نباید touched شود. بعد تازه اجازهٔ اجرا میدهیم.
بعد از تولید کد، مهمترین کار ما خواندن diff است. اگر حذف فایل، تغییر API، وابستگی جدید یا دستکاری ناحیهٔ حساس دیدیم، توقف میکنیم. سپس test، typecheck و lint را اجرا میکنیم. اگر چیزی شکست، علت را پیدا میکنیم و دوباره loop را تکرار میکنیم.
در پایان، اگر دیدیم یک prompt را بارها تکرار میکنیم، آن را به Skill تبدیل میکنیم. اگر لازم بود به ابزار یا دادهٔ بیرونی متصل شویم، از MCP استفاده میکنیم. این یعنی وایبکدینگِ حرفهای: سریع، اما کنترلشده.»
جریان یادگیری
نمودار زیر، جمعبندی فرایند پیشنهادی این گزارش از روی roadmap.sh، best practices، و مستندات رسمی Claude/Codex/Copilot/MCP است. [43]
|
|
وابستگی مهارتها
این نمودار وابستگیها را نشان میدهد: هرچه به پایین میروید، بدون لایهٔ قبلی یادگیری سست میشود. این مدل وابستگی از صدای مشترک roadmap.sh، راهنماهای context files، و اسناد Skills/MCP استخراج شده است. [44]
|
|
زمانبندی پیشنهادی
این زمانبندی، یک برنامهٔ نسبی برای مبتدی مطلق است و از مرحلهبندی آموزشی پیشنهادی بالا ساخته شده است. [45]
|
|
ماتریس منابع و سنجش اعتبار
|
اولویت |
منبع |
نوع |
نقش در این گزارش |
درجهٔ اتکا |
|
بسیار بالا |
roadmap.sh Vibe Coding roadmap و best practices. [46] |
منبع مرجع موضوع |
ستون فقرات ساختار اینفوگرافیک و ترتیب اصول |
بسیار بالا |
|
بسیار بالا |
فایلهای محتوایی رسمی roadmap در GitHub: definition، mindset، testing، security، context، version control و… . [47] |
منبع رسمیِ ساختاری |
برای استخراج گرههای دقیق نقشه |
بسیار بالا |
|
بسیار بالا |
مستندات رسمی Claude Code. [48] |
مستندات رسمی ابزار |
context، plan mode، skills |
بسیار بالا |
|
بسیار بالا |
مستندات رسمی OpenAI Codex. [49] |
مستندات رسمی ابزار |
AGENTS.md، skills، subagents، plans |
بسیار بالا |
|
بسیار بالا |
مستندات رسمی GitHub Copilot. [50] |
مستندات رسمی ابزار |
promptها، custom instructions، planning، MCP |
بسیار بالا |
|
بالا |
مستندات رسمی Gemini CLI. [51] |
مستندات رسمی ابزار |
GEMINI.md، skills، agent mode |
بسیار بالا |
|
بالا |
Cursor Docs. [52] |
مستندات رسمی ابزار |
Rules، skills، MCP، subagents |
بالا |
|
بسیار بالا |
MCP official docs and specification. [53] |
استاندارد باز رسمی |
اتصال ابزارها، دادهها و workflowها |
بسیار بالا |
|
بسیار بالا |
Anthropic prompt engineering docs. [54] |
مستندات فنی رسمی |
بهترین practices برای clarity، examples، long context و anti-hardcoding |
بسیار بالا |
|
بسیار بالا |
مقالات و بنچمارکهای اصلی: SWE-bench و Lost in the Middle؛ همچنین مطالعهٔ METR. [55] |
مقاله و benchmark اصلی |
واقعگرایی دربارهٔ محدودیتها و هزینهٔ review |
بسیار بالا |
|
بسیار بالا |
OWASP و Veracode. [56] |
استاندارد/گزارش امنیتی |
لایهٔ امنیت، secrets، access control، code risk |
بسیار بالا |
|
بالا |
Simon Willison و Red Hat Developer. [57] |
بلاگهای معتبر و تخصصی |
تفکیک نمونهسازیِ vibe از توسعهٔ مسئولانه |
بالا |
|
متوسط |
منابع فارسی مکمل: Quera و Faradars. [58] |
منبع آموزشی فارسی |
برای پرامپتنویسی، Git، تست و مبانی؛ نه منبع اولیهٔ مفهوم vibe coding |
متوسط |
جمعبندی نهایی در مورد منابع این است: برای خودِ مفهوم وایبکدینگ و workflow حرفهای آن، منابع اصلی باید انگلیسی و اولیه باشند؛ یعنی roadmap.sh، مستندات رسمی ابزارها، استانداردهای MCP و OWASP، و مقالات/بنچمارکهای اصلی. منابع فارسی موجود، فعلاً بیشتر برای «مبانی», «پرامپتنویسی», «Git», «تست» و آموزش واژگان فارسی مفید هستند و نباید جایگزین منبع اولیهٔ فنی شوند. [59]
[1] [5] [11] [22] developer-roadmap/src/data/roadmaps/vibe-coding/content/what-is-vibe-coding@lzHnwx_3gftRZbstk6INB.md at 278ca7309f89e60ef060fa3699962c36e68d5f21 · nilbuild/developer-roadmap · GitHub
[2] [34] [48] https://docs.anthropic.com/en/docs/claude-code/memory
https://docs.anthropic.com/en/docs/claude-code/memory
[3] https://x.com/karpathy/status/1886192184808149383?lang=en
https://x.com/karpathy/status/1886192184808149383?lang=en
[4] [10] [47] developer-roadmap/src/data/roadmaps/vibe-coding/content at 278ca7309f89e60ef060fa3699962c36e68d5f21 · nilbuild/developer-roadmap · GitHub
[6] [44] developer-roadmap/src/data/roadmaps/vibe-coding/content/the-vibe-coder-mindset@LkLQ8GjBXDuw1XsrE4Cjj.md at 278ca7309f89e60ef060fa3699962c36e68d5f21 · nilbuild/developer-roadmap · GitHub
[7] [15] [16] [26] [29] [42] [43] Vibe Coding Best Practices: How To Get Consistent Results
https://roadmap.sh/vibe-coding/best-practices
[8] [55] https://arxiv.org/abs/2310.06770
https://arxiv.org/abs/2310.06770
[9] [18] [28] developer-roadmap/src/data/roadmaps/vibe-coding/content/security-best-practices@2omItZjkVFW9kMiNXdt-h.md at 278ca7309f89e60ef060fa3699962c36e68d5f21 · nilbuild/developer-roadmap · GitHub
https://roadmap.sh/vibe-coding?utm_source=chatgpt.com
[13] https://rastikerdar.github.io/vazirmatn/fa
https://rastikerdar.github.io/vazirmatn/fa
[14] [57] https://simonwillison.net/2025/Mar/19/vibe-coding/
https://simonwillison.net/2025/Mar/19/vibe-coding/
[17] developer-roadmap/src/data/roadmaps/vibe-coding/content/testing@4bJRhuZzVc32x2Y0gGGrh.md at 278ca7309f89e60ef060fa3699962c36e68d5f21 · nilbuild/developer-roadmap · GitHub
[19] https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/multishot-prompting
https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/multishot-prompting
[20] https://docs.anthropic.com/en/docs/claude-code/skills
https://docs.anthropic.com/en/docs/claude-code/skills
[21] [45] Vibe coding tutorial: Build your first app with Claude Code
https://roadmap.sh/vibe-coding/tutorial
[23] https://react.dev/learn
[24] developer-roadmap/src/data/roadmaps/vibe-coding/content/master-version-control@q5lkCO_uGmkcJopjltg8j.md at 278ca7309f89e60ef060fa3699962c36e68d5f21 · nilbuild/developer-roadmap · GitHub
[25] developer-roadmap/src/data/roadmaps/vibe-coding/content/context@0ZJrFxKo5HyD9OgzG5LWp.md at 278ca7309f89e60ef060fa3699962c36e68d5f21 · nilbuild/developer-roadmap · GitHub
[27] developer-roadmap/src/data/roadmaps/vibe-coding/content/debugging@mHChjJd39ofwPBS-v_sQY.md at 278ca7309f89e60ef060fa3699962c36e68d5f21 · nilbuild/developer-roadmap · GitHub
[30] [33] The 10 Best Vibe Coding Tools in 2026: Our Choices
https://roadmap.sh/vibe-coding/best-tools
[31] https://docs.anthropic.com/en/docs/claude-code/overview
https://docs.anthropic.com/en/docs/claude-code/overview
[32] [52] https://cursor.com/docs/rules
[35] https://vitest.dev/guide/
[36] https://docs.pytest.org/en/stable/getting-started.html
https://docs.pytest.org/en/stable/getting-started.html
[37] https://eslint.org/docs/latest/use/core-concepts/
https://eslint.org/docs/latest/use/core-concepts/
[38] [53] https://modelcontextprotocol.io/docs/getting-started/intro
https://modelcontextprotocol.io/docs/getting-started/intro
[39] [40] [41] developer-roadmap/src/data/roadmaps/vibe-coding/content/tech-stack-and-coding@GC4vVcOcFWE1RByD-sd4G.md at 278ca7309f89e60ef060fa3699962c36e68d5f21 · nilbuild/developer-roadmap · GitHub
[49] https://developers.openai.com/codex/guides/agents-md
https://developers.openai.com/codex/guides/agents-md
[50] https://docs.github.com/en/copilot/get-started/best-practices
https://docs.github.com/en/copilot/get-started/best-practices
[51] https://docs.cloud.google.com/gemini/docs/codeassist/gemini-cli
https://docs.cloud.google.com/gemini/docs/codeassist/gemini-cli
[54] https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/overview
https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/overview
[56] https://owasp.org/www-project-top-ten/
https://owasp.org/www-project-top-ten/
[58] https://quera.org/college/landpage/18153/prompt-writing