اگر هر بار که از دستیار کدنویسی سؤال میپرسید، احساس میکنید مدل کند شده یا پاسخهایش بیش از حد طولانی است، احتمالاً با «مالیات پنهانِ زمینه» مواجه شدهاید. تصور کنید یک عامل هوشمند را مجبور کنید برای هر تغییر کوچک در یک خط کد، ابتدا تمام قوانین ۱۰۰ صفحهای شرکت شما را بخواند؛ نتیجه دقیقاً همان تأخیری است که در حال حاضر تجربه میکنید.
به نقل از راهنمای فنی منتشر شده در dev.to در ۱۶ ژوئیه ۲۰۲۶، راهکار این مشکل جایگزینی رویکرد «همه چیز در یک فایل» با یک سیستم مشابه «کارتهای فهرست کتابخانه» است. در این سیستم، عاملها فقط اطلاعاتی را فراخوانی میکنند که برای آن تسک خاص لازم است.
بسیاری از توسعهدهندگان کار با قوانین ساده در Cursor را شروع میکنند، اما این پوشهها بهمرور به تودهای از دستورالعملات متضاد تبدیل میشوند. برای مثال، یک فایل AGENTS.md حجیم ایجاد میشود که هر بار در آغاز هر چت، تمام استانداردهای نامگذاری، سیاستهای گیت و فلسفه مستندسازی را پردازش میکند؛ حتی اگر شما فقط یک سؤال ساده درباره یک تابع داشته باشید. این مسئله میتواند منجر به بروز مشکلاتی شود که ما در ۷ قانون حیاتی برای جلوگیری از تولید بدهی فنی در Cursor به آنها پرداختیم تا از انباشت کدهای ناکارآمد جلوگیری شود.
همانطور که در تحلیلهای پیشین ما دربارهی بهینهسازی پنجرههای متنی اشاره کردیم، حجم زیاد دادههای ورودی لزوماً به معنای دقت بیشتر نیست. وقتی عامل هوشمند هر بار یک بسته عظیم از یادداشتهای معماری را میخواند، سه اتفاق میافتد: هزینه مالی افزایش مییابد چون توکنهای بیشتری مصرف میشود، تأخیر (Latency) — همان فاصله زمانی بین ارسال سؤال و دریافت جواب — بالا میرود و مدل دچار «پرش موضوعی» شده و پاسخهایی خارج از محدوده درخواست شما میدهد.
منطق زمینهی مینیمال
واقعیت این است که زمینه کمتر، اغلب نتایج بهتری دارد. وقتی دستورالعملهای پایه محدود باشند، عامل تضاد کمتری بین دستورات میبیند. به جای بارگذاری تصادفی، سیستم به سمت «فراخوانی هدفمند» میرود؛ یعنی اگر مدل به استانداردهای SQL نیاز دارد، فقط همانها را میخواند.
این تغییر برای تیمهایی حیاتی است که پوشه .cursor آنها بهصورت ارگانیک رشد کرده و اکنون دستورالعملهای مشابه در سه جای مختلف تکرار شده است. هدف این است که پاسخهای اولیهی مدل پاکتر شوند بدون اینکه دانش عمیق پروژه از دست برود. در این راستا، اتوماسیونهای Cursor مدیریت تکراری مخزن کد را به عوامل ابری سپردند تا بار عملیاتی توسعهدهندگان در سازمانهای بزرگ کاهش یابد.
معماری مسیریابی لایهای
این ساختار بهینه بر پایه ۵ لایه طراحی شده تا عامل با حداقل دادههای مفید شروع کند:
لایه ۱: AGENTS.md (نقطه ورود)
این فایل فقط باید به دو سؤال پاسخ دهد: چه چیزهایی هرگز نباید نقض شوند و برای هر تسک به کجا مراجعه کنم؟
- یک پاراگراف دربارهی ثوابت معماری.
- محدودیتهای سخت و لینک به قوانین رفتاری.
- جدولی برای مسیریابی تسکها (مثلاً: تنظیمات محلی $\rightarrow$
README).
لایه ۲: .cursor/README.md (نمایهی محلی)
این فایل نقشه راه داراییهای Cursor است و باید بهجای متنهای طولانی، شامل جداول باشد:
- کدام قوانین وجود دارند و چه زمانی اعمال میشوند.
- لیست مهارتها و کاربرد هر کدام.
- صریحاً به مدل بگویید چه زمانی نباید فایلهای سنگین را باز کند تا توکنها ذخیره شوند.
لایه ۳: قوانین محدود به دامنه (Glob-Scoped Rules)
بهجای «همیشهروشن» بودن تمام قوانین، آنها را به پسوندهای فایل گره بزنید. قانون رفتاری کلی باید بسیار کوتاه باشد و جزئیات به فایلهای تخصصی منتقل شوند:
- قوانین SQL و مدلها: فقط برای
**/*.sql - قوانین متادیتای YAML: فقط برای
**/*.yml
با این روش، ویرایش یک فایل Markdown باعث فعال شدن قوانین SQL نمیشود.
لایه ۴: مهارتها (دستورالعملهای اجرایی)
مهارتها (Skills) — شبیه به دفترچههای راهنمای گامبهگام برای کارهای تکراری — اگر بهعنوان سیاست کلی تعریف شوند، گران تمام میشوند. ساختار بهینه شامل اینهاست:
- توصیفی که دقیقاً میگوید چه زمانی از این مهارت استفاده شود.
- ورودیهای مورد نیاز و گامهای مرتبشده.
- لینک به مستندات مرجع بهجای کپی کردن متن آنها.
لایه ۵: فایلهای مرجع (فهرستها و قراردادها)
مطالبی که بیش از حد طولانی هستند باید در .cursor/reference/ قرار گیرند:
- کاتالوگ کامل مهارتها و زیرعاملها.
- قراردادهای شمای دادهها.
- هر فایل مرجع باید در ابتدای خود ذکر کند که دقیقاً چه زمانی باید بارگذاری شود.
حذف مالیات تکرار
تکرار دادهها عامل اصلی اتلاف توکن است. سریعترین راه برای بازبینی، یک «گذر تکرارزدایی» است تا ایدههای مشابه در AGENTS.md و READMEها شناسایی شوند. برای مثال، اگر سیاست گیت در سه جای مختلف نوشته شده، باید یک «خانه اصلی» برای آن تعریف کرد و در بقیه جاها فقط لینک داد. این کار باعث میشود هنگام تغییر یک دستور، لازم نباشد تمام فایلها را برای یافتن نسخههای قدیمی جستوجو کنید.
بهداشت نمایهسازی و کارایی
بهینه کردن توکنها به آنچه Cursor از مخزن (Repository) نمایهسازی میکند نیز بستگی دارد. برای جلوگیری از «انحراف عامل» در جستوجوهای معنایی (Semantic Search) — یعنی وقتی مدل فایلی را پیدا میکند که ظاهرش شبیه جواب است اما کاربردی ندارد — توصیه میشود از این دو ابزار استفاده کنید:
.gitignore: برای خروجیهای تولید شده و وابستگیها..cursorignore: برای حذف اثرات Build و فایلهای Minified.
مسیر مهاجرت به ساختار جدید
برای انتقال به این سیستم نیاز به بازنویسی کامل نیست، بلکه این ۷ گام را دنبال کنید:
۱. سنسور: هر چه هر بار بارگذاری میشود را لیست کنید و بپرسید «آیا برای یک سؤال کلی واقعاً به این نیاز داشتم؟»
۲. بازنویسی AGENTS.md: آن را به یک مسیریاب تبدیل کنید.
۳. ادغام رفتارها: تمام حفاظهای متداخل را در یک قانون رفتاری نازک جمع کنید.
۴. استخراج قوانین دامنهای: برای SQL، TypeScript و غیره قوانین جداگانه با Glob بسازید.
۵. انتقال فهرستها: کاتالوگها را به .cursor/reference/ ببرید.
۶. حذف تکرارها: یک نسخه برنده انتخاب کنید و بقیه را پاک کنید.
۷. تست: سه پرامپت (کلی، تخصصی-فایلی و نگهداری) را اجرا کنید تا مسیرهای فراخوانی بررسی شوند.
نتایج و اثرات
بعد از این بازسازی، تفاوتها در هر نوبت کوچک اما در مجموع چشمگیر است. پاسخهای اول مدل بدون مقدمههای طولانی و تکرار سیاستها میرسند. هزینهی توکن در ویرایشهای روتین کاهش مییابد چون «پایگاه» مدل کوچکتر شده است. این تغییر، فرض بنیادی تعامل با عامل را عوض میکند: بهجای اینکه سعی کنیم مدل «هر چیزی را همزمان بداند»، روی «بارگذاری هدفمند» تمرکز میکنیم.
گام بعدی شما
- پوشه
.cursorخود را باز کنید و تعداد فایلهایی کهalwaysApply: trueدارند را بشمارید؛ اگر بیش از ۳ فایل است، آنها را به لایهی ۳ (Glob-scoped) منتقل کنید. - یک فایل
.cursorignoreبسازید و تمام پوشههایdistوbuildرا به آن اضافه کنید تا دقت جستوجوی معنایی مدل بالا برود. - فایل
AGENTS.mdرا به یک جدول مسیریابی تبدیل کنید تا مدل یاد بگیرد ابتدا نقشه را بخواند و بعد سراغ جزئیات برود.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تأثیر حافظههای HBM بر سرعت استنتاج مدلهای بزرگ مراجعه کنید.
گفتگو