تصور کنید هر بار که ترمینال را باز می‌کنید، باید دوباره به دستیار هوش مصنوعی خود یادآوری کنید که چرا تست‌های Redis در این پروژه باید به‌صورت تک‌رشته‌ای اجرا شوند. در ۲۹ اوت ۲۰۲۶، پروژه متن‌باز Copilot CLI Local Memory برای پایان دادن به این «فراموشی جلسات» که برنامه‌نویسان هنگام استفاده از GitHub Copilot CLI با آن دست‌وپنجه نرم می‌کنند، معرفی شد.
بیشتر دستیارهای کدنویسی با هوش مصنوعی، هر جلسه را مانند یک صفحهٔ سفید می‌بینند. در حالی که برنامه‌نویسان در حین کار، نکات حیاتی پروژه را کشف می‌کنند — مثلاً اینکه چرا یک تست خاص Redis باید به‌صورت متوالی (serially) اجرا شود — این درس‌ها معمولاً با بستن ترمینال از بین می‌روند. این ابزار یک رکورد دائمی و محلی از این یافته‌ها ایجاد می‌کند، بدون آنکه به پایگاه‌داده‌های پیچیده یا مدیریت وضعیت در فضای ابری نیاز داشته باشد. این رویکرد یادآور راهکار اندرو دی‌تایلر برای استفاده از فایل‌های Markdown است که برای حل مشکل فراموشی در عامل‌های هوش مصنوعی پیشنهاد شده بود.
نیاز به زمینه محلی (Local Context)
این پروژه از تمایلی برای صحبت با Copilot CLI مانند یک همکار برنامه‌نویس متولد شد. نویسنده می‌خواست یافته‌های خاص دیباگ را ذخیره کند؛ مواردی مانند اینکه تست‌های یکپارچه‌سازی Redis باید به‌صورت تک‌رشته‌ای اجرا شوند زیرا Workerها از DB 0 مشترک استفاده می‌کنند، یا اینکه تغییر زمان انتظار (timeout) احراز هویت نیازمند به‌روزرسانی هم‌زمان هر دو فایل gateway.yml و worker.yml است.
مثال‌های دیگر شامل تصمیمات مربوط به مهاجرت داده‌ها است؛ مانند استفاده از استراتژی «گسترش-مهاجرت-انقباض» (expand–migrate–contract) به این دلیل که APIها و Workerها به‌طور مستقل مستقر می‌شوند. این‌ها دقیقاً همان جزئیاتی هستند — مانند دلایل تست‌های ناپایدار (flaky-tests) و وابستگی‌های پیکربندی — که مهندسان در حین کار فعال یاد می‌گیرند اما اغلب با پایان یافتن یک جلسه، آن‌ها را گم می‌کنند. در موارد پیچیده‌تر، دسترسی به چنین داده‌های زمینه‌ای می‌تواند حیاتی باشد، مشابه زمانی که استفاده از داده‌های زمان‌اجرا در Claude Code منجر به حل یک نشت حافظه بحرانی در محیط Production شد.
به نقل از مستندات این پروژه در dev.to، این سامانه از طریق سه دستور اصلی عمل می‌کند: /remember برای ذخیره یک قانون، /memories برای فهرست کردن آن‌ها و /forget برای حذف. این افزونه برای ذخیره‌سازی از روشی «ساده و سنتی» (boring) استفاده می‌کند: فایل‌های متنی Markdown.
جزئیات پیاده‌سازی فنی
هر حافظه به‌صورت یک فایل دستورالعمل ماژولار در مسیر ~/.copilot/instructions/local-memory/ ذخیره می‌شود. ساختار این حافظه‌ها به شرح زیر است:
- قالب: Markdown معمولی همراه با YAML frontmatter (مثلاً
applyTo: "**"). یک قانون می‌تواند چنین باشد: «استقرارهای محیط Production باید همیشه با پرچم--dry-runاجرا شوند.» - محدوده‌بندی (Scoping): کاربران می‌توانند با پرچم
--scopeقوانین را به فایل‌های خاص محدود کنند. مثلاً با دستور/remember --scope "src/**/*.ts" Use Zod rather than Joi for validation، قوانین اعتبارسنجی Zod فقط برای فایل‌های تایپ‌اسکریپت اعمال می‌شود. - جست‌وجو: این ابزار به‌جای استفاده از پایگاه‌داده برداری (Vector Database) یا سرویس‌های Embedding — که شبیه به یک کتابدار است که مفاهیم را بر اساس شباهت معنایی دسته‌بندی می‌کند — از رتبه‌بندی کلمات محلی (local term ranking) برای جست‌وجوهای صریح استفاده می‌کند.
محدودیت‌های طراحی و امنیت
توسعه‌دهنده این ابزار را «عامدانه کوچک» طراحی کرده است. بر اساس مستندات، این افزونه هیچ فرآیند پس‌زمینه، تله‌متری، وابستگی زمان‌اجرایی یا سروری ندارد. همچنین افزونه ورودی‌های مشابه را حذف (deduplicate) می‌کند و اگر چندین حافظه با یک متن مطابقت داشته باشند، از حذف بر اساس متن خودداری می‌کند.
برای جلوگیری از نشت امنیتی، این افزونه شامل یک مسدودکننده (blocker) ابتدایی برای فرمت‌های رایج اعتبارنامه‌ها (Credentials) است، هرچند نویسنده هشدار می‌دهد که اسرار (Secrets) هرگز نباید در دستورالعمل‌های عامل ذخیره شوند. اگرچه افزونه هیچ تماس شبکه‌ای برقرار نمی‌کند، اما Copilot ممکن است متن دستورالعمل‌ها را در پرامپت‌های ارسالی به مدل بگنجاند؛ این بدان معناست که ذخیره‌سازی محلی، اسرار را برای پرامپت‌ها امن نمی‌کند.
این رویکرد تمایزی روشن بین استانداردهای تیمی و دانش فردی ایجاد می‌کند. در حالی که قراردادهای پایدار مخزن — مانند نسخه‌ی زبان و استانداردهای فرمت‌بندی — باید در یک فایل copilot-instructions.md باشند که در مخزن ثبت شده است، این حافظه محلی برای «دانش نوظهور» (emergent knowledge) است که در حین انجام یک تسک خاص اتفاق می‌افتد. این تفکیک میان ابزارهای مختلف اهمیت دارد، چرا که تفاوت‌های ساختاری در انتقال عامل‌های هوش مصنوعی می‌تواند منجر به شکست در حفظ زمینه‌های عملیاتی شود.
برای برنامه‌نویس، این امر نقش هوش مصنوعی را از یک دستیار عمومی به یک شریک آگاه از پروژه تغییر می‌دهد. با ارتقای حافظه‌های محلی به مستندات رسمی پس از اثبات پایداری آن‌ها، تیم‌ها می‌توانند یک پایگاه دانش زنده بسازند که به‌طور ارگانیک از جلسات واقعی دیباگ تکامل می‌یابد. این رویکرد با مستندات Memory گیت‌هاب همسو است که زمینه یادگرفته‌شده را شامل تصمیمات معماری، دستورات Build و الگوهای اتصال به پایگاه‌داده می‌داند.
این ابزار به‌ویژه برای برنامه‌نویسانی مفید است که در سازمان‌هایی کار می‌کنند که قابلیت Memory مدیریت‌شده توسط گیت‌هاب را غیرفعال کرده‌اند اما اجازه نصب افزونه‌های سفارشی را می‌دهند. این ابزار راهی برای داشتن یک «برگه تقلب» (cheat sheet) شخصی فراهم می‌کند که هوش مصنوعی می‌تواند در هر جلسه جدید به‌طور خودکار به آن ارجاع دهد.
اگر از تکرار دستورالعمل‌ها خسته شده‌اید، اکنون می‌توانید این وضعیت محلی را پیاده‌سازی کنید. این مخزن نصب‌کننده‌هایی برای ویندوز، macOS و لینوکس و همچنین حذف‌کننده‌هایی (uninstallers) فراهم کرده است که به‌طور پیش‌فرض حافظه‌های ذخیره‌شده را حفظ می‌کنند. شما می‌توانید این پروژه را در آدرس https://github.com/shankarnarayanb/copilot-cli-local-memory بیابید.
گام بعدی شما
- اگر از تکرار دستورالعمل‌ها خسته شده‌اید، مخزن پروژه را از گیت‌هاب کلون کرده و روی سیستم‌عامل خود نصب کنید.
- قوانینی که در طول دیباگ‌های طولانی کشف می‌کنید را بلافاصله با دستور
/rememberثبت کنید. - حافظه‌هایی که پس از مدتی ثابت و مورد نیاز کل تیم شدند را به مستندات رسمی پروژه منتقل کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو