استفاده از آیرا کد کنار Cursor؛ راهنمای گردش کار مشترک

می‌توانی Cursor را برای دیدن و ویرایش کد باز نگه داری و نشست آیرا کد را در ترمینال همان پروژه اجرا کنی. کار مشترک وقتی قابل پیگیری می‌ماند که هر تغییر مسئول مشخصی داشته باشد و نتیجهٔ آن در ویرایشگر و تست دیده شود.

اگر هنوز در مرحلهٔ انتخاب ابزار هستی، ابتدا مقایسهٔ آیرا کد و Cursor را بخوان. این راهنما برای وقتی است که می‌خواهی آن‌ها را در یک پروژه کنار هم به کار بگیری.

۱. هر دو ابزار را به یک پوشهٔ پروژه وصل کن

پروژه را در Cursor باز کن. در ترمینال همان پنجره، مسیر فعلی و تغییرات موجود را ببین:

pwd
git status --short
aira --version

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

برای نصب و بررسی افزونهٔ اتصال ویرایشگر، طبق راهنمای رسمی آیرا کد از این فرمان‌ها استفاده کن:

aira extensions install ide
aira extensions status

راهنما، نصب دستی فایل افزونه و بررسی وضعیت اتصال را هم توضیح می‌دهد. نصب افزونه به‌تنهایی به معنی فعال‌بودن نشست نیست؛ آیرا کد باید روی همان ماشین و در مسیر پروژه اجرا شود.

۲. برای هر تغییر یک مسئول انتخاب کن

مثلاً برای یک خطای فرم، این تقسیم کار روشن است:

عامل داخلی Cursor را هم‌زمان برای ویرایش همان فایل فعال نکن. اگر می‌خواهی مسئولیت را عوض کنی، کار اول را تمام کن، اختلاف کد را بخوان و وضعیت فعلی را به ابزار دوم بده.

۳. درخواست را به رفتار قابل مشاهده وصل کن

نشست را از ترمینال پروژه شروع کن:

aira

سپس یک درخواست محدود بده:

در فرم ثبت سفارش، تا وقتی درخواست قبلی تمام نشده ارسال دوباره ممکن نباشد. پس از خطا امکان تلاش دوباره باقی بماند. قبل از تغییر، فایل‌های مسئول و علت را توضیح بده. ظاهر فرم و قرارداد API را تغییر نده.

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

۴. راهنمای پروژه را هماهنگ نگه دار

قواعد Cursor می‌توانند قراردادهای پروژه را نگه دارند. آیرا کد هم حافظه و راهنمای پروژه را در مسیر خودش می‌خواند. این دو را یک حافظهٔ مشترک و خودکار فرض نکن.

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

۵. پایان کار را ثبت کن

git diff --stat
git diff --check
git diff

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

اگر اتصال کار نکرد

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

برای تکمیل این جریان، راهنمای تست‌نویسی و دیباگ را دنبال کن. اگر به دنبال گزینهٔ دیگری برای کار داخل ویرایشگر هستی، مقایسه با GitHub Copilot مسیرهای فعلی آن را توضیح می‌دهد.