برای آموزش شروع کار با Cursor لازم نیست از ساخت یک فروشگاه کامل یا اتصال درگاه پرداخت شروع کنید. یک پروژهٔ کوچک، مثل فهرست کارهای روزانه، فرصت بهتری می‌دهد تا درخواست روشن بنویسید، تغییرات را بخوانید و نتیجه را آزمایش کنید.
در این راهنما یک تمرین پیشنهادی با HTML، CSS و JavaScript داریم. هدف، یادگیری روش همکاری با دستیار است؛ نه وعدهٔ ساخت خودکار یک برنامهٔ بی‌خطا. خروجی واقعی به درخواست شما، نسخهٔ ابزار و بررسی خودتان وابسته است.
Cursor Agent چه کاری انجام می‌دهد؟
طبق راهنمای رسمی Agent، دستیار می‌تواند فایل‌های پروژه را بررسی کند، چند فایل را ویرایش کند و از ابزارهایی مانند ترمینال کمک بگیرد. درخواست را در پنل Agent وارد می‌کنید و تغییرات را در نمای مقایسه می‌بینید.
بنابراین صرفاً با یک پاسخ متنی روبه‌رو نیستید. پیش از شروع، محدودهٔ پروژه را روشن کنید: کدام پوشه در اختیار ابزار است، چه نتیجه‌ای می‌خواهید و چه کارهایی در این تمرین مجاز نیست. برای اولین تجربه، یک پوشهٔ آزمایشی مستقل انتخاب خوبی است.
تمرین ما: فهرست کارهای فارسی، بدون حساب کاربری
نسخهٔ اول این امکانات را داشته باشد:
- افزودن یک کار با متن دلخواه و کلید Enter یا دکمهٔ افزودن؛
- رد کردن ورودی خالی یا متنی که فقط فاصله دارد؛
- علامت زدن کار انجام‌شده و نمایش تعداد کارهای باقی‌مانده؛
- حذف همان ردیفی که کاربر انتخاب کرده است؛
- نمایش مناسب فارسی و صفحهٔ کوچک موبایل.
در این نسخه، داده‌ها فقط تا زمانی که صفحه باز است نگهداری می‌شوند. ذخیره‌سازی دائمی، ورود کاربر، سرویس بیرونی و پرداخت را عمداً به مرحلهٔ بعد موکول کنید تا بتوانید رفتار پایه را مستقل بررسی کنید.
گام اول: محیط تمرین را محدود و قابل بازگشت کنید
پوشه‌ای مانند cursor-todo-demo بسازید و همان پوشه را در Cursor باز کنید. فایل واقعی مشتری، رمز، کلید API یا نسخهٔ اصلی پروژهٔ کاری را وارد این تمرین نکنید. اگر پروژه‌تان از قبل وجود دارد، ابتدا یک نسخهٔ قابل بازگشت از وضعیت فعلی نگه دارید.
برای کار جدی‌تر، مستندات فایل‌های نادیده‌گرفته‌شده در Cursor را بخوانید. فایل .cursorignore دسترسی برخی قابلیت‌ها به مسیرهای مشخص را محدود می‌کند، اما مستندات صریحاً می‌گویند ابزارهای ترمینال و MCP تحت همین محدودیت قرار نمی‌گیرند؛ آن را تضمین کامل حفاظت از رازها ندانید.
در پروژهٔ آموزشی خالی، معمولاً لازم نیست مسئلهٔ مدیریت رازها را با ساختن فایل‌های حساس پیچیده کنید. ساده‌ترین انتخاب این است که اصلاً دادهٔ محرمانه‌ای در پوشه نباشد.
گام دوم: قبل از تولید کد، برنامهٔ کوتاه بخواهید
این متن پیشنهادی را در پنل Agent وارد کنید و مسیر آن را با پوشهٔ خودتان تطبیق بدهید:
در همین پوشه یک فهرست کارهای فارسی برای تمرین بساز.
فقط از HTML، CSS و JavaScript معمولی استفاده کن.
فایل‌ها index.html، styles.css و app.js باشند.
قبل از ویرایش، ساختار و روش آزمایش را کوتاه توضیح بده.
فعلاً هیچ حساب کاربری، سرویس بیرونی، بستهٔ جدید یا ذخیره‌سازی دائمی اضافه نکن.
ورودی خالی پذیرفته نشود؛ متن کار به صورت متن معمولی نمایش داده شود.
افزودن با Enter، انجام‌شده، حذف تکی و شمارندهٔ باقی‌مانده لازم است.
رابط راست‌به‌چپ و قابل استفاده در موبایل باشد.
دستور ترمینال را پیش از اجرا توضیح بده و به فایل‌های بیرون این پوشه دست نزن.
این درخواست، تعریف کار و معیار تحویل را کنار هم دارد. اگر برنامهٔ پیشنهادی شامل چارچوبی پیچیده، پایگاه داده یا نصب چند بسته شد، همان‌جا مسیر را اصلاح کنید؛ این قابلیت‌ها در نسخهٔ اول تمرین ما لازم نیستند.
گام سوم: یک تغییر مشخص را تا پایان دنبال کنید
پس از بررسی برنامه، ساخت نسخهٔ اول را بخواهید. اگر دستیار چند قابلیت اضافه پیشنهاد داد، همه را هم‌زمان وارد پروژه نکنید. ابتدا ببینید افزودن و حذف کار واقعاً درست انجام می‌شود یا نه، سپس سراغ ظاهر و امکانات بعدی بروید.
نام دکمه‌ها و جای گزینه‌های Agent ممکن است میان نسخه‌ها تغییر کند. برای اصل روش، روی سه کار تمرکز کنید: درخواست مشخص، خواندن تغییر فایل‌ها و آزمایش نتیجه. تعداد فایل‌های تولیدشده یا سرعت نوشتن، جای این سه مرحله را نمی‌گیرد.
در مستندات امنیت Agent آمده است که ویرایش فایل می‌تواند مستقیماً ذخیره شود و اجرای خودکار یا بازخوانی خودکار برنامه نیز بر زمان اجرای تغییرات اثر دارد. تنظیمات محافظتی را برای این تمرین بی‌دلیل تغییر ندهید و دستورهای ترمینال را فقط وقتی اجرا کنید که کارکردشان را می‌فهمید.
گام چهارم: تغییرات را فایل‌به‌فایل بخوانید
در نمای Diff، خط‌های اضافه و حذف‌شده را بررسی کنید. از دستیار بپرسید هر فایل چه مسئولیتی دارد و برای یک رفتار مشخص، کدام بخش تغییر کرده است. راهنمای رسمی بازبینی و آزمایش Cursor نیز تأکید می‌کند که ظاهر درست کد یا عبور از چند آزمایش، همهٔ خطاها را آشکار نمی‌کند.
برای این تمرین، این سؤال‌ها کمک می‌کنند:
| فایل | سؤال بازبینی |
|---|---|
index.html |
آیا ورودی و دکمه‌ها برچسب روشن دارند و صفحه فارسی تعریف شده است؟ |
styles.css |
آیا اندازه‌های ثابت باعث بیرون‌زدن محتوا در موبایل می‌شوند؟ |
app.js |
آیا متن خالی رد می‌شود و حذف یک ردیف به بقیه کاری ندارد؟ |
| همهٔ فایل‌ها | آیا وابستگی، ارتباط شبکه یا قابلیت خارج از درخواست اضافه شده است؟ |
اگر Git در پروژه فعال است، این دستورهای خواندنی برای بررسی وضعیت و تفاوت فایل‌های ثبت‌شده مفیدند:
git status --short
git diff --stat
git diff -- index.html styles.css app.js
مطابق مستندات Git diff، نتیجهٔ مقایسه به وضعیت فایل‌ها و گزینهٔ دستور بستگی دارد. محتوای فایل جدیدِ ثبت‌نشده را صرفاً از روی خروجی خالی git diff تأیید نکنید؛ خود فایل را باز کنید و وضعیت آن را در git status ببینید.
گام پنجم: این شش آزمایش را خودتان انجام بدهید
فایل index.html را در مرورگر باز کنید. اگر روش اجرای متفاوتی برای پروژه انتخاب کرده‌اید، همان روش را از قبل مشخص کنید و وابستگی تازه را ناخواسته وارد تمرین نکنید.
- سه کار متفاوت اضافه کنید؛ هر سه باید جدا نمایش داده شوند.
- یک ورودی خالی و یک ورودی شامل فاصله امتحان کنید؛ نباید ردیف تازه بسازند.
- یک کار را انجام‌شده کنید؛ تعداد باقی‌مانده باید با تعریف تمرین سازگار باشد.
- ردیف وسط را حذف کنید؛ دو ردیف دیگر باید باقی بمانند.
- عبارتی مثل
<strong>نمونه</strong>را به‌عنوان نام کار وارد کنید؛ قرار است متن معمولی دیده شود، نه اینکه قالب HTML اجرا شود. - عرض مرورگر را کوچک کنید و افزودن با صفحه‌کلید را امتحان کنید؛ دکمه‌ها و متن باید قابل استفاده بمانند.
در نسخهٔ بدون ذخیره‌سازی این تمرین، خالی شدن فهرست پس از بارگذاری مجدد، مطابق تعریف اولیه است. اگر می‌خواهید داده بماند، آن را به‌عنوان یک نیاز جدید با آزمایش جدا اضافه کنید؛ به دستیار نگویید همه‌چیز را از نو بسازد.
وقتی خطا پیدا کردید، چه درخواستی بنویسید؟
به‌جای «درست کار نمی‌کند»، موقعیت قابل تکرار را توضیح بدهید:
سه کار الف، ب و ج می‌سازم. با حذف ب، گاهی ج هم ناپدید می‌شود.
انتظار دارم فقط ب حذف شود.
مسیر شناسایی ردیف‌ها و رویداد حذف را بررسی کن.
فقط اصلاح مرتبط را انجام بده و روش آزمایش همین خطا را توضیح بده.
بعد از اصلاح، همان مراحل را دوباره تکرار کنید و افزودن، انجام‌شده و حذف را هم یک‌بار مرور کنید. برای برگشت از یک مسیر نامناسب می‌توانید قابلیت Checkpoint را طبق مستندات Agent بررسی کنید؛ برای نسخهٔ اصلی پروژه، پشتیبان یا کنترل نسخهٔ مستقل هم داشته باشید.
انتخاب اشتراک را از یادگیری روش کار جدا کنید
امکانات، مدل‌های قابل انتخاب و سقف استفاده ممکن است تغییر کنند. برای انتخاب، نوع نیاز و مشخصات پلن را بررسی کنید؛ داشتن اشتراک به معنی درست بودن همهٔ خروجی‌ها یا دسترسی نامحدود نیست.
اگر قصد تهیهٔ دسترسی دارید، پلن موجود Cursor در مارکت‌کیو و چک‌لیست پیش از خرید اشتراک نقطهٔ شروع مقایسه‌اند. همچنین تفاوت اکانت، کلید API و اشتراک را بخوانید؛ اعتبار یک API را معادل اشتراک خود ویرایشگر فرض نکنید.
پرسش‌های رایج
آیا برای شروع باید برنامه‌نویس حرفه‌ای باشم؟
برای این تمرین می‌توانید مبتدی باشید، اما باید بتوانید نتیجه را اجرا و رفتار آن را بررسی کنید. از دستیار توضیح بخش‌های کد را بخواهید و پیش از استفادهٔ واقعی، مفاهیم پایه را یاد بگیرید.
آیا Accept کردن همهٔ تغییرات کافی است؟
خیر؛ فایل‌ها و نتیجهٔ اجرا را بررسی کنید. تغییر غیرمرتبط را جدا شناسایی کنید و معیار تحویل را مبنای تصمیم قرار بدهید.
چرا درخواست کوچک بهتر از ساخت یک برنامهٔ کامل است؟
در این تمرین، دامنهٔ کوچک کمک می‌کند بفهمید هر تغییر چه اثری داشته و خطا را با چند مرحلهٔ روشن تکرار کنید. بعد از عبور نسخهٔ پایه از آزمایش‌ها، قابلیت بعدی را اضافه کنید.
منابع و تاریخ بررسی
منابع رسمی در ۶ نوامبر ۲۰۲۶ بررسی شدند: کار با Agent، بازبینی و آزمایش، امنیت Agent، قواعد نادیده گرفتن فایل و Git diff. تصویر شاخص، طراحی مفهومی فرایند کار است و اسکرین‌شات یک نسخهٔ مشخص از برنامه نیست.
