وقتی هر ابزار Ai فقط بخشی از پروژه شما رو می‌شناسه؛ راهنمای ساخت Context مشترک بین ChatGPT، Claude، Codex و Cursor

هر بار که از ChatGPT به Claude یا از Claude Code به Codex می‌ری، فقط ابزار رو عوض نمی‌کنین؛ بخش زیادی از شناختی رو که طی هفته‌ها درباره شما و پروژه‌تون ساخته شده هم پشت سر می‌ذارین.

یک ابزار می‌دونه محصول تو چه مرحله‌ای هست، ابزار دیگه لحن برند رو می‌شناسه و سومی از تصمیم معماری هفته گذشته خبر نداره. نتیجه اینه که پیش از شروع هر کار واقعی، دوباره باید توضیح بدید چه کسی هستین، چه چیزی می‌سازین، قبلاً چه تصمیم‌هایی گرفتین و چه مسیرهایی رو امتحان کردین و کنار گذاشتین.

مسئله اصلی کمبود حافظه در مدل‌های هوش مصنوعی نیست؛ مسئله اینه که Context ما بین ابزارهای مختلف تکه‌تکه شده.

برای حل این مسئله دو مسیر اصلی وجود داره: می‌تونیم Contextپروژه رو به‌صورت دستی و فایل‌محور مدیریت کنیم یا از سرویس‌هایی استفاده کنیم که یک لایه مستقل برای حافظه و Context بین ابزارهای AI می‌سازن. انتخاب درست به پیچیدگی پروژه، تعداد ابزارهای مورد استفاده، حساسیت داده‌ها و زمانی بستگی داره که برای نگهداری این Context صرف می‌کنیم.

قبل از انتخاب راه‌حل، تفاوت Memory و Context را بدونم

Memory معمولاً شامل اطلاعاتیه که یک ابزار از تعامل با شما به خاطر می‌سپاره؛ مثل ترجیحات، شیوه نوشتن، نقش شغلی یا بعضی اطلاعات مربوط به پروژه.

اما Context مجموعه گسترده‌تری از اطلاعات موردنیاز برای انجام درست یک کار هست:

هدف و محدوده پروژه

معماری محصول

تصمیم‌های قبلی و دلایل اون‌ها

وضعیت فعلی کار

محدودیت‌ها و خط قرمزها

فایل‌ها و مستندات مرتبط

ترجیحات کاری

افراد، مسئولیت‌ها و ذی‌نفعان

اقدام‌های انجام‌شده و کارهای بعدی

برای مثال، اینکه «من روی یک Design System کار می‌کنم» یک Memory عمومی هست؛ اما اینکه «در معماری توکن‌ها از سه لایه Primitive، Semantic و Component استفاده می‌کنیم و تصمیم گرفتیم Layer سوم فقط برای کامپوننت‌های پیچیده ایجاد بشه» بخشی از Context پروژه هست.

Memory داخلی ChatGPT یا Claude می‌تونه تجربه رو شخصی‌تر کنه، اما معمولاً داخل همون محصول باقی می‌مونه. چیزی که ChatGPT درباره پروژه می‌دونه، الزاماً در Claude Code یا Cursor در دسترس نیست. به همین دلیل برای کار حرفه‌ای روی پروژه‌های بلندمدت، تنها داشتن Memory کافی نیست؛ به یک منبع مشترک برای Context نیاز داریم.

روش اول: ساخت Context مشترک به‌صورت دستی

در روش دستی، یک منبع قابل‌کنترل و مستقل برای اطلاعات پروژه می‌سازیم. ساده‌ترین فرمت برای این کار Markdown هست؛ چون هم انسان می‌تونه آن را بخونه، هم ابزارهای AI و هم Git می‌تونه تغییراتش را ثبت کنه.

برای یک پروژه محصول یا Design System می‌تونیم چنین ساختاری ایجاد کنیم:

project-context/

├── PROJECT.md

├── CURRENT-STATE.md

├── DECISIONS.md

├── WORKING-RULES.md

├── ARCHITECTURE.md

├── GLOSSARY.md

├── CONTENT-GUIDE.md

└── COMPONENT-SPECS/

├── button.md

├── switch.md

├── dropdown.md

└── avatar.md

هر فایل چه نقشی داره؟

این فایل‌ها بهتره در Repository اصلی قرار بگیرن تا Claude Code، Codex و Cursor که روی همون پروژه کار می‌کنن، به یک منبع مشترک دسترسی داشته باشه.

اتصال Context دستی به ابزارهای مختلف

لازم نیست تمام اطلاعات رو در فایل دستور هر ابزار تکرار کنیم. کافیه فایل اصلی هر Agent رو به Context مشترک ارجاع بدیم.

نمونه دستور:

Before starting any task, read:

- project-context/PROJECT.md

- project-context/CURRENT-STATE.md

- project-context/DECISIONS.md

- project-context/WORKING-RULES.md

For component-related tasks, read the relevant specification in:

- project-context/COMPONENT-SPECS/

After completing a task:

1. Update CURRENT-STATE.md.

2. Record new architectural decisions in DECISIONS.md.

3. Do not overwrite unrelated user changes.

این ساختار باعث می‌شه Claude Code و Codex مجبور نباشن در هر سشن تمام Repository یا تمام گفتگوهای قبلی رو از ابتدا بررسی کنن.

چطور نگهداری دستی رو نیمه‌خودکار کنیم؟

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

Before finishing this task, update CURRENT-STATE.md with:

- What was completed

- Files that changed

- Decisions that were made

- Remaining risks or blockers

- Recommended next step

If an architectural decision was made, add it to DECISIONS.md

without rewriting or deleting previous decisions.

در این حالت خود Agent بعد از هر تسک، Context پروژه رو به‌روز می‌کنه؛ اما همچنان بهتره کاربر تغییرات رو بررسی کنه، چون Agent ممکنه اهمیت بعضی تصمیم‌ها رو درست تشخیص نده یا یک جمع‌بندی ناقص ایجاد کنه.

مزایای روش دستی

تقریباً رایگانه.

اطلاعات تو Repository خود پروژه باقی می‌مونه.

تغییرات از طریق Git قابل پیگیری هست.

ساختار Context دقیقاً مطابق نیاز پروژه طراحی می‌شه.

وابستگی به یک سرویس خارجی ایجاد نمی‌شه.

برای پروژه‌های فنی و ابزارهای Coding Agent بسیار مناسبه.

محدودیت‌های روش دستی

فایل‌ها ممکنه به‌مرور قدیمی بشن.

انتقال Context به ChatGPT یا ابزارهای تحت وب همیشه خودکار نیست.

اطلاعات Gmail، Calendar، Slack، Notion و Drive خودکار وارد نمی‌شوند.

تصمیم‌های موجود در گفتگوهای پراکنده باید استخراج و ثبت بشن.

اگر چند پروژه و چند Agent داشته باشیم، نگهداری Context پیچیده‌تر می‌شه.

یک فایل Context بسیار بزرگ می‌تونه مصرف توکن رو افزایش بده.

روش دستی زمانی بهترین عملکرد رو داره که اطلاعات اصلی پروژه در فایل‌ها و Git نگهداری بشه و بیشتر ابزارهای AI نیز مستقیماً روی همون Repository کار کنن.

روش دوم: استفاده از ابزارهای Shared Memory و Context Layer

ابزارهایی مثل Unabyss، MemoryPlugin، Supermemory و OpenMemory تلاش می‌کنن یک حافظه مستقل از مدل ایجاد کنن. به‌جای اینکه Context داخل ChatGPT یا Claude محبوس بمونه، در یک فضای مرکزی ذخیره می‌شن و ابزارهای مختلف از طریق MCP یا افزونه مرورگر به آن دسترسی پیدا می‌کنن.

MCP یا Model Context Protocol استانداردی است که اجازه می‌ده ابزارهای AI به منابع و سرویس‌های بیرونی متصل شوند. در این مدل، Agent به‌جای دریافت تمام اطلاعات در ابتدای Prompt، هنگام نیاز بخش مرتبط Context را جست‌وجو و بازیابی می‌کنه.

فرایند معمول چنین ابزارهایی به این شکل است:

منابع اطلاعاتی مثل GitHub، Notion، Drive، Gmail یا گفتگوهای قبلی متصل می شن.

اطلاعات استخراج و ساختاریافته می‌شن.

Context تو یک Vault، Memory Graph یا Knowledge Base نگهداری می شن.

ChatGPT، Claude، Cursor یا Codex به سرویس متصل می‌شن.

هر Agent فقط اطلاعات مرتبط با درخواست را بازیابی می‌کنن.

در برخی ابزارها، تصمیم‌های جدید هم دوباره در حافظه ذخیره می‌شن.

مقایسه ابزارهای موجود

مقایسه قیمت‌ها

قیمت‌های زیر براساس اطلاعات رسمی منتشرشده در ۱۵ اوت ۲۰۲۶ هستند و ممکن است بعداً تغییر کنن.

یک نکته مهم اینه که هزینه این سرویس‌ها معمولاً جدا از اشتراک ChatGPT، Claude، Cursor یا هزینه API هست. برای مثال، خرید Unabyss Pro جایگزین Claude Pro یا ChatGPT Plus نمی‌شود؛ فقط یک لایه Context بین اون‌ها اضافه می‌کنه.

مقایسه روش دستی و استفاده از ابزار

آیا هزینه ابزارهایی مانند Unabyss منطقی هست؟

پاسخ این سؤال به قیمت خود ابزار محدود نمی‌شه. باید هزینه پنهان روش فعلی رو هم محاسبه کرد:

زمان توضیح مجدد پروژه

مصرف توکن برای ارسال اطلاعات تکراری

زمان پیدا کردن فایل‌ها و گفتگوهای قبلی

دوباره‌کاری ناشی از فراموش‌شدن تصمیم‌ها

پاسخ‌های متناقض میان Agentها

تکرار مسیرهایی که قبلاً بررسی و رد شده

انتقال دستی خروجی یک AI به AI دیگر

اگر هر هفته بیشتر از یک ساعت صرف انتقال Context میان ChatGPT، Claude، Codex و Cursor می‌کنیم، پرداخت حدود ۱۵ دلار در ماه می‌تواند منطقی باشه؛ به‌خصوص اگر سرویس واقعاً بتواند این زمان را کاهش بده.

اما اگر فقط یک پروژه اصلی داریم، همه فایل‌ها در یک Repository نگهداری می‌شن و Claude Code و Codex روی همون پوشه کار می‌کنن، ساختار Markdown و Git احتمالاً بخش بزرگی از نیاز رو بدون هزینه پوشش می‌ده.

چه زمانی روش دستی انتخاب بهتری است؟

روش دستی مناسب‌تر است اگر:

روی یک یا دو پروژه اصلی کار می‌کنید.

Context اصلی داخل Repository و مستندات پروژه قرار دارد.

Claude Code، Codex یا Cursor مستقیماً به فایل‌ها دسترسی دارند.

اطلاعات پروژه حساسه.

می‌خواهید تاریخچه تصمیم‌ها از طریق Git قابل پیگیری باشه.

مشکلی با به‌روزرسانی دوره‌ای فایل‌های Context ندارین.

نمی‌خواید اشتراک جدیدی به هزینه ابزارهای AI اضافه کنید.

در این وضعیت، یک Context Architecture خوب بسیار مهم‌تر از خرید ابزار است.

چه زمانی یک ابزار Context ارزش پرداخت دارد؟

استفاده از سرویس‌هایی مانند Unabyss، MemoryPlugin یا Supermemory زمانی منطقی‌تر است که:

دائماً میان ChatGPT، Claude، Codex و Cursor جابه‌جا می‌شید.

چند پروژه هم‌زمان دارید.

بخشی از اطلاعات در GitHub، بخشی در Notion و بخشی در Gmail یا Drive هست.

لازمه Context به‌صورت مستمر به‌روز شود.

گفتگوهای قبلی بخش مهمی از دانش پروژه را تشکیل میده.

زمان نگهداری دستی از هزینه اشتراک بیشتر شده.

می‌خواید هر AI فقط بخش مرتبط اطلاعات را هنگام نیاز بازیابی کند.

در واقع، هزینه این ابزارها برای «ذخیره‌سازی اطلاعات» نیست؛ برای کاهش اصطکاک، همگام‌سازی و بازیابی هوشمند Context پرداخت می‌شه.

کدام ابزار برای کدام نیاز مناسب‌تر هست؟

مدل ترکیبی؛ انتخابی که برای بسیاری از تیم‌ها منطقی‌تر است

روش دستی و ابزارهای Context الزاماً رقیب هم نیستن. می‌توان از یک مدل ترکیبی استفاده کرد:

تصمیم‌های رسمی و معماری در Markdown و Git ذخیره بشه.

وضعیت لحظه‌ای، گفتگوها و اطلاعات پراکنده توسط یک ابزار Context بازیابی بشه.

Repository همچنان Source of Truth باقی بمونه.

سرویس Context نقش لایه جست‌وجو و انتقال اطلاعات را داشته باشه.

تصمیم‌های مهمی که در AI گرفته می‌شه، دوباره به مستندات رسمی پروژه برگردند.

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

یک مسیر عملی برای شروع

به‌جای خرید فوری یک ابزار یا ادامه‌دادن توضیح‌های تکراری، می‌تونین این مسیر را اجرا کرد:

مرحله اول: ساخت Source of Truth

چهار فایل اصلی ایجاد کنین:

PROJECT.md

CURRENT-STATE.md

DECISIONS.md

WORKING-RULES.md

مرحله دوم: اتصال Agentهای فنی

در CLAUDE.md، AGENTS.md و قوانین Cursor مشخص کنین که پیش از شروع کار، فایل‌های Context مرتبط را بخونن.

مرحله سوم: ثبت خودکار وضعیت

از Agent بخواهید پس از هر تسک، وضعیت پروژه و تصمیم‌های جدید را ثبت کند.

مرحله چهارم: ارزیابی برای دو تا سه هفته

اندازه بگیرین:

چند بار مجبور شدید Context را دوباره توضیح بدید؟

چند دقیقه برای انتقال اطلاعات میان ابزارها صرف شد؟

چند پاسخ به علت Context ناقص اشتباه بود؟

فایل‌های Context چند بار قدیمی شدن؟

چه اطلاعاتی بیرون از Repository باقی موند؟

مرحله پنجم: آزمایش ابزار

اگر مشکل همچنان جدی بود، اول Trial یا پلن رایگان یکی از ابزارها را امتحان کنین:

Supermemory Free برای آزمودن MCP

MemoryPlugin برای انتقال حافظه و تاریخچه گفتگوها

Unabyss برای اتصال منابع متعدد کاری

OpenMemory برای راه‌حل Local و خصوصی

مرحله ششم: حفظ امکان خروج

حتی در صورت استفاده از ابزار، تصمیم‌ها و مستندات اصلی را در فرمت‌های قابل‌خروجی مثل Markdown نگه دارین.

جمع‌بندی

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

ساخت Context مشترک به‌صورت دستی برای پروژه‌های فنی، متمرکز و Repositoryمحور کاملاً کافی و حتی از نظر کنترل و امنیت بهتره. اما وقتی اطلاعات میان گفتگوها، ابزارها و سرویس‌های مختلف پراکنده شده باشه، نگهداری دستی به یک کار مستقل تبدیل می‌شه. در آن نقطه، ابزارهایی مثل Unabyss، MemoryPlugin یا Supermemory می‌توانند هزینه رو با کاهش زمان انتقال و بازیابی Context جبران کنن.

بنابراین پرسش درست این نیست که «روش دستی بهتره یا ابزار؟» پرسش دقیق‌تر اینه:

Context شما چقدر پراکنده است و برای هماهنگ نگه‌داشتن آن میان انسان‌ها، پروژه‌ها و Agentهای مختلف، اکنون چه هزینه‌ای پرداخت می‌کنین؟

برای بسیاری از کاربران حرفه‌ای، بهترین پاسخ یک مدل ترکیبی هست: مستندات و تصمیم‌های رسمی در Git و Markdown، در کنار یک لایه حافظه مشترک برای بازیابی و انتقال Context بین ابزارهای AI.

منابع

Unabyss — وب‌سایت و پلن‌های قیمت‌گذاری

Unabyss — نحوه عملکرد

Unabyss — فهرست Integrationها

Unabyss — تفاوت AI Memory و Context

Unabyss — امنیت و نحوه مدیریت داده‌ها

Unabyss — اتصال Context به Claude و Cursor از طریق MCP

MemoryPlugin — حافظه مشترک میان ابزارهای AI

MemoryPlugin — پلتفرم‌های پشتیبانی‌شده

MemoryPlugin — مقایسه با حافظه داخلی AIها و قیمت‌ها

Supermemory — وب‌سایت رسمی

Supermemory — اتصال MCP

Supermemory — قیمت‌گذاری

OpenMemory MCP — معرفی راه‌حل Local و Self-hosted

Mem0 — زیرساخت Memory برای Agentها

Mem0 — Repository متن‌باز