ذاكرة ثانية في Claude Code: كيف تبني بنيتها خلال ساعة
Markdownكيف تبني ذاكرة ثانية لـ Claude Code: هيكل للذاكرة، وبنية مجلدات من خمسة أجزاء، واستخدام Git كي يتذكر الوكيل كل شيء عن مشروعك بين الجلسات.
قراءة المقال كاملًا
النقطة الأساسية
ذاكرة Claude Code الثانية ليست ملفًا واحدًا؛ إنها بنية من خمسة مجلدات بالإضافة إلى Git. يحدد CLAUDE.md القواعد ومسارات التوجيه، ويخزن business/ المعرفة المتعلقة بالمشروع، ويخزن ai-clone/ معلومات عنك بصفتك صاحب القرار، ويضم plans/ الخطط التقنية، ويحتوي retrospectives/ على الدروس المستفادة من الجلسات السابقة. يبدأ الوكيل بملف CLAUDE.md ويتبع الروابط إلى المجلد المناسب للطلب المحدد. تتناول هذه المقالة تسلسل الذاكرة في وثائق Claude Code الرسمية، وبنية الأجزاء الخمسة، وطريقة إنشائها خطوة بخطوة خلال ساعة.
الوثائق المرجعية لـ Ailoot: ailoot.ai/docs/.
لماذا يحتاج Claude Code إلى ذاكرة ثانية، وما الضروري فيها؟
النقطة الأساسية
يغطي ملف CLAUDE.md واحد القواعد الأساسية، لكنه لا يستطيع استيعاب ذاكرة العمل. بعد شهر، تكون قد نسيت سبب رفعك للسعر. وبعد ثلاثة أشهر، تكون قد نسيت سبب رفضك الدفع بالتقسيط. تعيش المعرفة في أربعة أماكن في الوقت نفسه: في ذهنك، ومحادثات Telegram، ومستندات Google، وأذهان الموظفين. تجمعها الذاكرة الثانية كلها في مجلد واحد من ملفات Markdown إلى جانب المشروع، ويمكن لـ Claude الوصول إليه من تلقاء نفسه.
تفتح Claude Code يوم الثلاثاء. تشرح له: هذا هو المشروع، وهذه جمهوره، ولا تفعل كذا. تعملان معًا. يوم الخميس، تبدأ محادثة جديدة، وعليك أن تشرح كل شيء من جديد.
إذا كان لديك ملف CLAUDE.md، فقد حللت الجولة الأولى من الإحباط. تعيش القواعد الأساسية ووصف المشروع في ملف واحد، ويُحمّل في كل جلسة. شرحت طريقة عمل هذا الملف في دليلي عن CLAUDE.md - يمكنك قراءته أولًا لترسيخ الأساس.
لكن CLAUDE.md هو دليل تعليمات لموظف جديد: كيف يرتدي ملابسه، وما النبرة التي يستخدمها مع العملاء، وما الأوامر التي يستخدمها للنشر. وهذا لا يكفي لاتخاذ قرارات جيدة بشأن المشروع. فالقرارات تتطلب معرفة: ما المنتج، ومن جمهوره، وكيف تعمل اقتصادياته، وما الذي جربته وما الذي لم ينجح.
في تجربة الكاتب الموصوفة هنا، كانت هذه المعرفة تعيش في أربعة أماكن: ذهنه، ومحادثات Telegram، ومستندات Google، وأذهان الموظفين. بعد شهر من اتخاذ قرار، لم يعد أحد يتذكر سبب اتخاذه. وكان الموظف الجديد يقضي ساعة في سؤال الفريق حتى يفهم العمل. ولم يكن Claude جزءًا من هذا السياق أصلًا.
قبل إنشاء الذاكرة الثانية، كانت كل جلسة، بحسب التجربة التي يصفها الكاتب، تعني إعادة شرح هوية العميل، وبنية العرض، ومزود خدمة الدفع. أما مع business/، فأفتح محادثة وأقول: «حدّث العرض وفق خطة الأسعار الجديدة» - فينتقل Claude من تلقاء نفسه إلى business/company/legal.md، ويقرأ المتطلبات، ثم يذهب إلى business/products/pricing.md، ويرى خطة الأسعار الجديدة، ويقترح تعديلًا في خطوة واحدة. انتهى التمهيد؛ يُحمّل السياق تلقائيًا.
ملاحظة
هذه ليست مشكلة في ذاكرة Claude، بل مشكلة في البنية. نافذة سياق الوكيل هي ذاكرته العاملة. ولا يحمّل إلا ما تشير إليه صراحةً. كل ما عدا ذلك يظل خارج النافذة ويُحمّل عند الحاجة. تخزن الذاكرة الثانية هذا «كل ما عدا ذلك» بطريقة منظمة كي يستطيع Claude العثور على طريقه.
تسمي Anthropic هذه المشكلة «تدهور السياق» في مدونتها الهندسية:
كلما زاد عدد الرموز في نافذة السياق، تراجعت قدرة النموذج على استرجاع المعلومات من ذلك السياق بدقة.
بعبارة أخرى، كلما حشوت النافذة بمزيد من المعلومات، تراجعت قدرة الوكيل على التعامل مع التفاصيل. والحل هو الاحتفاظ ببنية من الملفات الخارجية يستطيع Claude زيارتها تلقائيًا استجابةً لطلب محدد. هذه هي الذاكرة الثانية.
ما الذاكرة الثانية، وكيف ينطبق مفهومها على Claude؟
النقطة الأساسية
الفكرة بسيطة: العقل مخصص لتوليد الأفكار، لا لتخزينها. أما في Claude Code، فتتحول الذاكرة الثانية من منهجية للإنتاجية إلى بنية للوكيل: مجلد خارجي من الملاحظات يستطيع الوكيل الوصول إليه مباشرة عبر نظام الملفات.
عادةً ما تتعلق الذاكرة الثانية بالإنتاجية عمومًا: ينشئ الناس خزنة Obsidian ويضيفون مقتطفات من الكتب، وملاحظات المكالمات، وأفكار المشاريع.
عندما طبّق الكاتب الفكرة على العمل مع Claude Code، لم تعد تتعلق بالإنتاجية، بل أصبحت بنية للوكيل.
في المنهج التقليدي، تكون الذاكرة الثانية ملكًا لك وتصل إليها يدويًا. أما عند العمل مع Claude Code، فتصبح الذاكرة الثانية ثنائية الاتجاه: تصل إليها أنت والوكيل. وهذا يغير متطلبات تنسيقها.
بما أن الوكيل يصل إليها تلقائيًا، ينبغي أن تكون الملفات بتنسيق يفهمه من دون تكامل منفصل. Markdown مثالي لذلك: نص، وتسلسل هرمي للعناوين، وروابط بين الملفات. أما Notion وGoogle Docs فلا يناسبان. يمكنك ربطهما عبر MCP، لكن ذلك يضيف طبقة أخرى، ورمزًا آخر لكل طلب، ونقطة فشل أخرى.
وبما أن الملفات موجودة في نظام الملفات إلى جانب المشروع، فهي تقع تلقائيًا ضمن نطاق وصول Claude Code. لا يلزم إعداد شيء. ابدأ الوكيل في مجلد المشروع وسيتمكن من رؤية جميع الملفات داخله. هذا مجاني ويعمل مباشرةً دون إعداد.
نصيحة
يمكنك الاحتفاظ بذاكرتك الثانية في Obsidian - أفتحها فيه أنا أيضًا كي يسهل عليّ عرض شبكة الروابط. لكن الملفات نفسها موجودة في مجلد عادي إلى جانب الشيفرة. Obsidian مجرد غلاف لطيف لملفات Markdown. يستطيع Claude رؤيتها من دون Obsidian. ويمكنك استخدام أي محرر؛ المهم أن تكون الملفات على القرص لا في خدمة سحابية لها تنسيقها الخاص.
ما تسلسل الذاكرة المتاح في Claude Code افتراضيًا؟
النقطة الأساسية
يستطيع Claude Code قراءة أربعة مستويات من ملفات CLAUDE.md افتراضيًا (المؤسسة، والمستخدم، والمشروع، والمحلي)، ومنذ الإصدار 2.1.59 يحتفظ بذاكرة تلقائية خاصة به في ~/.claude/projects/<project>/memory/. يكفي ذلك للذاكرة الأساسية، لكنه لا يكفي لسياق العمل؛ لذا ضعه في مجلد منفصل إلى جانب المشروع.
قبل إضافة أي شيء من عندك، لننظر إلى ما يستطيع Claude تذكره من دون مساعدتك. تصف Anthropic آليتين في وثائقها الرسمية: CLAUDE.md (قواعد تكتبها أنت) والذاكرة التلقائية (دروس يكتبها Claude بنفسه). وتُحمّل الآليتان في بداية كل جلسة.
يبحث Claude عن CLAUDE.md في أربعة مواضع في الوقت نفسه:
| المستوى | الموقع | الغرض |
|---|---|---|
| المؤسسة | /Library/Application Support/ClaudeCode/CLAUDE.md (macOS)، /etc/claude-code/CLAUDE.md (Linux)، C:\Program Files\ClaudeCode\CLAUDE.md (Windows) | قواعد ينشرها المسؤول على الفريق بأكمله عبر MDM. لا يحتاج الأفراد إلى هذا الملف. |
| المستخدم | ~/.claude/CLAUDE.md | قواعد شخصية تنطبق على جميع المشاريع. «أجب باللغة التي أفضلها»، «لا تستخدم شرطة طويلة». |
| المشروع | ./CLAUDE.md في جذر المشروع | قواعد خاصة بمشروع محدد: مجموعة التقنيات، وبنية المجلدات، وقواعد العمل. يُضاف إلى Git. |
| المحلي | ./CLAUDE.local.md | ملاحظاتك الشخصية لهذا المشروع، ولا تُضاف إلى Git. أضفه إلى .gitignore. |
تُحمّل الملفات الأربعة كلها في السياق. وكلما كان المستوى أكثر تحديدًا، ارتفعت أولويته. يُقرأ الملف المحلي أخيرًا، لذا تتغلب قواعده على سائر القواعد.
يمكن أن يوجد ملف CLAUDE.md أيضًا في أي مجلد داخل المشروع. عندما يقرأ Claude ملفًا من مجلد فرعي، يحمّل ملف CLAUDE.md الموجود في ذلك المجلد عند الحاجة. وهذا مفيد في المستودع الأحادي: توضع قواعد الواجهة الأمامية في frontend/CLAUDE.md، وقواعد الواجهة الخلفية في backend/CLAUDE.md، ولا تُحمّل إلا عندما يعمل الوكيل على الجزء المعني.
ظهرت الذاكرة التلقائية في Claude Code 2.1.59. وهي ملفات يكتبها Claude عنك:
~/.claude/projects/<project-name>/memory/
├── MEMORY.md # فهرس، يُحمّل في كل جلسة (200 سطر أو 25KB)
├── debugging.md # ملاحظات تفصيلية (تُحمّل عند الحاجة)
├── api-conventions.md
└── ...
وتصفها Anthropic في الوثائق الرسمية كما يلي:
لا يحفظ Claude شيئًا في كل جلسة. بل يقرر ما يستحق التذكر بناءً على احتمال فائدة المعلومة في محادثة مستقبلية.
تُفعّل الذاكرة التلقائية بواسطة الخيار autoMemoryEnabled في ~/.claude/settings.json. ويقرر Claude ما يكتبه هناك. يمكنك قراءة MEMORY.md وتعديله يدويًا - فهو ملف Markdown عادي.
تحذير
الذاكرة التلقائية مفيدة، لكنها لا تحل محل الذاكرة الثانية. يكتب Claude فيها خلاصات عملية عن الأدوات وأنماط الشيفرة، مثل «يتعطل هذا البرنامج النصي من دون الخيار X» أو «اسم جدول قاعدة البيانات هذا». لكنه لا يكتب فيها استراتيجية العمل. إذا أردت أن يتذكر الوكيل جمهورك وسبب اختيارك سعرًا معينًا، فعليك وضع ذلك بنفسك في مجلد سياق منفصل.
CLAUDE.md أم الذاكرة الثانية - أين ترسم الحد الفاصل؟
النقطة الأساسية
CLAUDE.md دليل تعليمات لموظف جديد: كيف يتصرف، وما الأوامر التي يستخدمها، وما الذي ينبغي ألا يفعله. أما الذاكرة الثانية فهي موسوعة الشركة: ما الذي تفعله، ولمن، وكيف تعمل اقتصادياته، وما الذي جربته. ملف واحد لقواعد السلوك، وبنية من المعرفة الخارجية. CLAUDE.md هو الفهرس؛ والذاكرة الثانية هي الأرشيف. من دون الفهرس، لا يعرف الوكيل أن الأرشيف موجود. ومن دون الأرشيف، لا يعرف سوى القواعد، لا سياق العمل.
إليك التشبيه الذي أستخدمه في محاضراتي: تخيل أنك وظفت موظفًا جديدًا. ماذا تعطيه في يومه الأول؟
دليل تعليمات: كيف يرتدي ملابسه، ومتى يصل، وما النبرة التي يستخدمها مع العملاء، ومن خلال أي نظام ينشر. إنه مستند قصير. ولا يشرح ما الذي تفعله أو لماذا؛ بل يوضح ببساطة كيف يتصرف.
وبشكل منفصل، تمنحه إمكانية الوصول إلى موسوعة الشركة. تشرح الموسوعة ماهية المنتج، ولمن هو موجه، ومن الجمهور، وما السعر وسببه، ومن المنافسون، وما الأخطاء التي ارتكبتها. إنها أرشيف واسع. لا يقرأه أحد كاملًا؛ بل تذهب إليه عند وجود سؤال محدد.
CLAUDE.md = دليل التعليمات. الذاكرة الثانية = الموسوعة. تحتاج إلى الاثنين.
التمييز بسيط. ضع في CLAUDE.md كل ما هو ملائم لكل مهمة:
- دور الوكيل في هذا المشروع (مساعد، أو قائد، أو معاون)
- اللغة التي يجب أن يجيب بها
- مجموعة الأدوات
- أوامر النشر
- المحظورات (لا تستخدم شرطة طويلة، ولا تشغّل
git push --force) - مسارات التوجيه: أين يذهب لسياق العمل وأين يذهب للمبادئ
وضع في الذاكرة الثانية كل ما هو مطلوب عند الحاجة:
- المنتج والجمهور والاقتصاديات والأهداف
- المنافسون والسوق
- القرارات السابقة وأسبابها
- أمثلة العملاء والتقييمات
- المبادئ والمنهجية
وتوضح Anthropic التمييز نفسه في وثائقها:
يُحمّل CLAUDE.md في كل جلسة، لذا أدرج فيه ما ينطبق على نطاق واسع فقط. أما المعرفة بالمجال أو مسارات العمل التي لا تلزم إلا أحيانًا، فاستخدم لها المهارات. يحمّلها Claude عند الحاجة من دون تضخيم كل محادثة.
المهارات إحدى طرق تخزين المعرفة المرتبطة بحالات محددة. ومجلد business/ إلى جانب المشروع طريقة أخرى. أستخدم كليهما، وسأشرحهما بمزيد من التفصيل أدناه.
ممَّ تتكون ذاكرة المشروع - خمسة أجزاء وآلة زمنية
النقطة الأساسية
ذاكرة المشروع هي خمسة مجلدات تعلوها إدارة Git. يحدد CLAUDE.md القواعد ومسارات التوجيه. ويخزن ai-clone/ إسقاطك الرقمي: مبادئك ونبرتك وملاحظاتك بعد الأخطاء. ويخزن business/ المعرفة المتعلقة بالمشروع. ويضم plans/ الخطط التقنية حسب المرحلة. ويحتوي retrospectives/ على مراجعات الجلسات. يحول Git كل ذلك إلى آلة زمنية: بعد عام، يمكنك فتح أي ملف ورؤية محتواه وقت اتخاذ القرار.
بنية نموذجية من التجربة التي يصفها الكاتب:
| المجلد | المحتويات | الغرض |
|---|---|---|
CLAUDE.md | قواعد المشروع، ومجموعة التقنيات، وبنية الملفات، وتوجيه المجلدات، ولغة التواصل | هذا دليل تعليمات الوكيل. يُحمّل في كل جلسة. أقل من 200 سطر، ويفضل أن يكون بين 80 و120. |
ai-clone/ | من أنا، ومبادئي، ونبرتي، وأسلوب اتخاذ قراراتي، وملاحظاتي بعد الأخطاء | إسقاط رقمي لي بصفتي صاحب قرار. يعرف ما سأرفضه فورًا، والأسلوب الذي أقترح به الأشياء، والقواعد التي تعلمتها من الأخطاء. |
business/ | المنتج، والجمهور، والأهداف، والاقتصاديات، والتسويق، والقرارات السابقة، والأمثلة | ملفات Markdown مترابطة بروابط Wiki. يرتبط كل ملف بالآخر عبر روابط [[...]]. يذهب الوكيل إليها عند سؤال محدد. |
plans/ | خطة واحدة لكل ميزة. ملف YYYY-MM-DD-feature.md بمراحل ومربعات اختيار | يوجد Plan Mode في محادثة واحدة ويُفقد بعد /clear. أما مجلد plans/ فيعيش داخل المستودع، ويمكن لأي وكيل متابعة الخطة في أي وقت. |
retrospectives/ | مراجعات بعد كل جلسة: ما أُنجز، وما ينبغي تذكره، وما يمكن تحسينه | تعلّم النظام ذاتيًا. تتحول الأخطاء إلى قواعد في ai-clone/feedback/. |
+ git | سجل إصدارات كل الملفات | آلة زمنية. افتح أي ملف وشغّل git log لمعرفة متى تغير ولماذا. |
النقطة المنهجية الأساسية هي الفصل بين ai-clone/ وbusiness/.
يجيب business/ عن سؤال «ماذا نفعل؟»: المنتج والجمهور والأسعار والمنافسون. فهو يتعلق بالمشروع. إذا سلمت المشروع إلى شريك غدًا، سينتقل هذا المجلد معه.
ويجيب ai-clone/ عن سؤال «كيف أتخذ القرارات؟»: مبادئي ونبرتي وحرفيتي وكلمات التوقف الخاصة بي. فهو يتعلق بي. إذا بدأت مشروعًا جديدًا غدًا، سينتقل هذا المجلد معي.
ينشأ عنهما معًا ما أسميه شركة الشخص الواحد. شخص واحد، وسياق منظم، وذكاء اصطناعي يقرأ ذلك السياق.
هل تريد ألا تكتفي بإعداد مجلد ثانٍ، بل أن تبني أيضًا نظامًا يجعل Claude متسقًا؟ هذا لا يكفي وحده. من دون ai-clone/، يجيب الوكيل كما لو كان يتحدث نيابة عن الجميع، لا عنك. ومن دون هندسة السياق، يتجول في المجلد كله ويهدر الرموز. من المفيد ربط العناصر الثلاثة: الذاكرة الثانية + النسخة المستنسخة بالذكاء الاصطناعي + هندسة السياق. هذه هي الركائز الثلاث التي يؤدي غيابها إلى هلوسة الذكاء الاصطناعي.
ما الذي ينبغي أن يوضع في business/، وما الذي ينبغي استبعاده؟
النقطة الأساسية
ضع في business/ حقائق المشروع التي تتغير مرة أسبوعيًا أو أقل: تحديد المكانة، والجمهور، والمنتجات والأسعار، والأهداف الفصلية، والقرارات الرئيسية. واترك خارجه مراسلات المحادثات، والمواد الخام غير المعالجة، والمعلومات المكررة في الشيفرة، ولقطات الشاشة، والأرقام المتغيرة. استبدل الأرقام بعلامة LIVE ورابط إلى استعلام SQL - أشرح ذلك في قسم منفصل أدناه.
البنية العليا لمجلد business/ في المشروع الذي يصفه الكاتب:
business/
├── INDEX.md ← خريطة المجلد، ابدأ بقراءته
├── company/ ← الرسالة، والكيان القانوني، والقيم، والسياسات القانونية
├── products/ ← المنتجات، والبرامج، والأسعار
├── audience/ ← ملف العميل، والشرائح، والاعتراضات
├── goals/ ← الأهداف السنوية والفصلية والشهرية، والمقاييس
├── economics/ ← اقتصاديات الوحدة، والدخل، والنفقات، والتوقعات
├── marketing/ ← القنوات، ومسار التحويل، والمواد، والمنافسون
├── execution/ ← التخطيط الأسبوعي، وقائمة الأعمال المتراكمة
└── assets/ ← نظام التصميم، والتقييمات، وبنك النصوص
هذا مثال من المشروع الذي يصفه الكاتب، وليس قاعدة ملزمة. أنشئ المجلدات عند الحاجة. بدأت بثلاثة (products/ وaudience/ وgoals/)، ثم أضفت البقية بعد 2-3 أشهر، عندما لم يعد واضحًا أين أضع الأشياء الجديدة.
الملف الرئيسي في المجلد هو INDEX.md. إنه خريطة تضم جدولًا من نوع «السؤال ← الملف» يستخدمه Claude لمعرفة الوجهة. ومن دونه، يهدر الوكيل الرموز بقراءة كل الملفات بالتتابع.
مقتطف نموذجي من INDEX.md:
### أين تجد الأشياء
| ما تحتاج إليه | أين تبحث |
|---|---|
| من عميلنا وما نقاط معاناته | `business/audience/avatar.md` |
| المنتجات والخطط والأسعار | `business/products/` |
| الأهداف والمقاييس | `business/goals/` |
| الاقتصاديات (الدخل والنفقات واقتصاديات الوحدة) | `business/economics/` |
| قنوات الترويج والمواد | `business/marketing/` |
بعد ذلك، يكفي سطر واحد في CLAUDE.md: «لأسئلة العمل، اقرأ business/INDEX.md واتبع الخريطة». لا يحمّل الوكيل المجلد كله إلى السياق؛ بل يحمّل الخريطة، ويختار الملف المناسب، ويقرأ ذلك الملف وحده.
قائمة بما ينبغي عدم وضعه في business/:
- مراسلات المحادثات الخام من دون معالجة. إذا كانت فيها فكرة مفيدة، استخلصها وسجلها. وإذا لم تكن كذلك، فاتركها.
- المعلومات المكررة في الشيفرة. لا حاجة إلى «تُجرى المدفوعات عبر CloudPayments»؛ يستطيع الوكيل رؤية ذلك في الشيفرة.
- لقطات الشاشة والصور. فهي تزيد حجم المجلد ولا يحللها نموذج نصي دون خطوة إضافية.
- الأرقام المتغيرة. «لدينا اليوم 423 دفعة لهذا المنتج» ستصبح قديمة بعد أسبوع. استخدم علامة LIVE ورابطًا إلى استعلام قاعدة البيانات.
- المعلومات الحساسة أو المشكوك فيها. إذا نُشر المستودع غدًا على YouTube أمام 100 ألف شخص، فأبقِ فيه ما تقبل بعرضه فقط. يقرأ المجلد الموظفون والوكلاء وأحيانًا المتعاقدون الخارجيون.
تحذير
إذا كان المستودع عامًا، فمجلد business/ عام أيضًا. أتعامل مع الذاكرة الثانية كما لو أن المستودع قد يصبح عامًا غدًا، حتى لو كان خاصًا الآن. لا أسماء عملاء من دون موافقتهم، ولا أرقام إيرادات شهرية، ولا كلمات مرور. هذه العادة توفر كثيرًا من القلق.
لماذا نخصص مجلدًا مستقلًا باسم ai-clone، ولماذا ينبغي عدم خلطه بـ business؟
النقطة الأساسية
يخزن ai-clone/ إسقاطك الرقمي: المبادئ والنبرة وكلمات التوقف والملاحظات بعد الأخطاء. يتحول كل خطأ من الوكيل إلى قاعدة في ai-clone/feedback/ وفق الصيغة «القاعدة ← السبب ← طريقة التطبيق». ينتقل المجلد معك من مشروع إلى آخر. أما business/ فيبقى مع المشروع. أبقهما منفصلين: سيكون business/ جديدًا في المشروع الجديد، لكن مبادئك وأسلوبك سيبقيان كما هما.
الفكرة بسيطة: يعرف العمل ما الذي نفعله، وتعرف النسخة المستنسخة كيف أتخذ قراراتي.
بنية ai-clone/ في المشروع الذي يصفه الكاتب:
ai-clone/
├── INDEX.md ← خريطة المجلد
├── role.md ← من أنا، وخلفيتي، وما يهمني
├── identity/ ← القيم، والرؤية، والرسالة
├── thinking/ ← النماذج الذهنية من المحاضرات
├── voice/ ← النبرة، والمفردات، والأسلوب
├── principles/ ← المعتقدات المتعلقة بالمنتج والشيفرة والعمل
├── feedback/ ← القواعد المستفادة من الأخطاء ← المجلد الرئيسي
├── style/ ← كلمات التوقف، وتنسيق Telegram
└── reference/ ← الأدوات والبيئة
أكثر المجلدات فائدة هو feedback/. يحتوي على قواعد محددة تعلمتها من أخطاء الوكيل. ضع كل قاعدة في ملف مستقل بالتنسيق التالي:
---
name: short-name
description: سطر واحد - ما الذي في الملف ومتى ينبغي تطبيقه
type: feedback
---
قاعدة قصيرة في جملة واحدة.
**السبب:** لماذا توجد هذه القاعدة؟ السياق، أو الحادثة، أو الملاحظة.
**طريقة التطبيق:** محفزات محددة توضح متى تنطبق القاعدة.
من دون «السبب»، تصبح القاعدة ميتة؛ فلن يطبقها الوكيل على موقف مشابه. ومن دون «طريقة التطبيق»، لن يتضح متى ينبغي استخدام القاعدة.
مثال من مجلدي: قاعدة «شرطة قصيرة، لا شرطة طويلة». نشأت لأن الشرطة الطويلة — علامة بصرية بارزة للنصوص التي يولدها الذكاء الاصطناعي. وتنطبق على أي نص موجه إلى الجمهور. يوجد الملف في ai-clone/feedback/no-em-dashes.md.
أفعل ذلك بطريقة مختلفة قليلًا: أكتب القواعد في ai-clone/feedback/، لا في CLAUDE.md. فـ CLAUDE.md ملف خاص بالمشروع، لكن قواعد النبرة والأسلوب شخصية، وتنتقل معي إلى المشروع التالي. أما CLAUDE.md فيبقى مع المشروع.
ملاحظة
مقياس نضج هذا النهج هو عدد المرات التي تقول فيها للوكيل أسبوعيًا «لا، ليس هكذا» بشأن الأمر نفسه. في النظام الناضج، تكون الإجابة صفرًا. يتحول كل خطأ إلى قاعدة في feedback/، ولا يكرره الوكيل في المرة التالية.
ما المقاييس الحية، ولماذا لا ينبغي تثبيت الأرقام في الملفات؟
النقطة الأساسية
تصبح الأرقام في ملفات الذاكرة الثانية قديمة خلال أيام. فـ«1,000 عميل» اليوم تصبح 1,050 غدًا و2,000 بعد شهر. إذا ثبتّها في الملف، فسيقدم لك الوكيل بعد شهر اقتراحات مبنية على بيانات الأمس. الحل هو وضع علامة LIVE في الملف، وإنشاء مستند منفصل باسم live-metrics.md يحتوي على استعلامات SQL جاهزة للتشغيل. عندما يرى الوكيل LIVE، ينتقل إلى قاعدة البيانات، ويستخرج الرقم الحالي، ويبني تفكيره على بيانات محدثة.
من أهم المزالق عند البدء بإنشاء ذاكرة ثانية ملؤها بأرقام قديمة. تكتب «لدينا 320 عميلًا»، وبعد أسبوعين يصبح العدد 410. وتكتب «الإيراد الشهري 4.7 مليون»، ثم يصبح الرقم بعد شهر بلا سياق: هل هو هدف أم نتيجة فعلية أم توقع؟
في مثال الكاتب، تجري العملية كما يلي. في الملف business/products/practicum.md، توضع علامة بدل الرقم:
## الدفعات
> **LIVE** - شغّل الاستعلامات في `live-metrics.md`، قسم «المبيعات»
> للاطلاع على المدفوعات الحالية حسب الدفعة.
| الدفعة | التواريخ | الذين دفعوا |
|-------|------|------------|
| 1 | 10-12 مارس 2026 | LIVE |
| 2 | 24-26 مارس 2026 | LIVE |
ويحتوي ملف منفصل باسم live-metrics.md على استعلامات SQL جاهزة للتشغيل، وأوصاف لما تعرضه:
## المبيعات (المدفوعات حسب الدفعة)
```sql
SELECT c.name, COUNT(p.id) AS paid, SUM(p.amount) AS revenue
FROM purchases p
JOIN cohorts c ON c.id = p.cohort_id
WHERE p.status = 'paid'
GROUP BY c.name
ORDER BY c.starts_at DESC;
```
عندما أسأل الوكيل «كم دفعة لدينا للدفعة الثانية؟»، فإنه:
- يقرأ
business/products/practicum.md - يرى علامة LIVE بجانب الرقم
- يفتح
live-metrics.md - يعثر على قسم «المبيعات»
- يشغّل الاستعلام على قاعدة بيانات الإنتاج
- يجيب باستخدام بيانات حديثة
هذا يحل مشكلتين في آن واحد: لا تصبح الأرقام قديمة، وتُتخذ القرارات وفق الصورة الراهنة لا صورة العام الماضي.
تحذير
في النهج الذي يصفه الكاتب، لا يُسمح بالوصول إلى قاعدة بيانات الإنتاج إلا للوكلاء الموثوقين. ولا يحصلون على الوصول إلا عبر غلاف يسجل الاستعلامات ولا يكشف كلمات المرور. وضع أمر psql مباشر مع كلمة مرور بنص صريح في live-metrics.md فكرة سيئة. أنشئ غلافًا يأخذ كلمة المرور من متغير بيئة ولا يكشفها في المخرجات. هذه طبقة تقنية منفصلة، لكن LIVE من دونها يصبح ثغرة أمنية.
كيف يتنقل الذكاء الاصطناعي في الذاكرة الثانية عند تنفيذ طلب واحد؟
النقطة الأساسية
مسار الطلب ثابت دائمًا: يقرأ Claude ملف CLAUDE.md، ويرى الخرائط (business/INDEX.md وai-clone/INDEX.md)، وينتقل إلى INDEX المعني، ويتبع مساره إلى ملف محدد، ثم يستخرج رقمًا عبر LIVE إذا لزم الأمر. يتطلب ذلك 5-6 عمليات قراءة بدلًا من حشو المجلد كله في السياق. وتظل النافذة متاحة للاستدلال، ولا تُهدر الرموز على ملفات غير ذات صلة.
طلب محدد، مثل: «اكتب مسودة بريد إلكتروني للمشاركين عن الدفعة الجديدة».
- يبدأ Claude بنافذة فارغة. ويحمّل CLAUDE.md (القواعد، ومجموعة التقنيات، ومسارات التوجيه).
- يرى في مسارات التوجيه في CLAUDE.md: «
ai-clone/INDEX.md- اقرأه دائمًا في بداية الجلسة». فيفتح الملف ويعرف من أنا، وما نبرتي، وما كلمات التوقف التي أستخدمها. - يرى في مسارات التوجيه: «قوالب البريد الإلكتروني -
src/lib/email/layout.ts». فيفتح الملف ويفهم التنسيق. - يرى: «سياق المنتج -
business/products/practicum.md». فيفتح الملف ويقرأ عن المنتج. - يرى علامة LIVE في الملف وإحالة إلى
live-metrics.md. فيفتح الملف ويعثر على SQL الجاهز للتشغيل. إذا احتاج إلى رقم حالي، يشغّل الاستعلام. وإذا لم يحتج إليه، يضع علامة «استخرج هذا الرقم عند الإرسال». - يرى قواعد النبرة في
ai-clone/style/telegram-format.md، وحظر الشرطة الطويلة فيai-clone/feedback/no-em-dashes.md، ومعدلات تحويل مسار التحويل فيbusiness/marketing/funnel.md.
ثم يكتب البريد الإلكتروني بنبرتي، مستخدمًا أرقامًا حديثة وخاليًا من الشرطات الطويلة وعلامات الذكاء الاصطناعي.
تسمي Anthropic هذا النهج «السياق عند الحاجة» في مدونتها الهندسية:
تحتفظ الوكلاء المبنية وفق نهج «في الوقت المناسب» بمعرّفات خفيفة (مثل مسارات الملفات، والاستعلامات المحفوظة، والروابط، وما إلى ذلك)، وتستخدم هذه الروابط لجلب البيانات ديناميكيًا إلى السياق وقت التشغيل عبر الأدوات.
بعبارة أخرى، يحمل Claude مؤشرات إلى البيانات، لا البيانات نفسها. وهذا أوفر كثيرًا في الرموز وأكثر دقة، لأن المعلومات ذات الصلة وحدها تدخل السياق. وتبقى النافذة صافية للاستدلال.
خمسة أنماط مضادة للذاكرة الثانية - ما الذي ينبغي تجنبه؟
النقطة الأساسية
الأخطاء الرئيسية التي يرتكبها المبتدئون في الذاكرة الثانية: 1) تضخم CLAUDE.md إلى أكثر من 500 سطر بدلًا من إبقائه موجزًا للتوجيه؛ 2) إنشاء مجلد تخزين شامل يتحول إلى مكب؛ 3) تكرار معلومات يعرفها Claude أصلًا من اللغة أو الشيفرة؛ 4) تثبيت أرقام تصبح قديمة من دون LIVE؛ 5) ترك السياق غير متاح للوكيل أو عدم توجيهه إليه، سواء كان في المستودع نفسه أو مخزن خاص مستقل.
النمط المضاد 1. تضخم CLAUDE.md. 500 سطر من التعليمات «بدلًا من وضع كل شيء في مكان واحد». تتحدث Anthropic بوضوح:
اجعله موجزًا. اسأل عن كل سطر: «إذا حذفته، هل سيبدأ Claude بارتكاب أخطاء؟» إن لم يكن الأمر كذلك، فاحذفه. تؤدي ملفات CLAUDE.md المتضخمة إلى تجاهل Claude تعليماتك الفعلية!
الطول المستهدف هو 80-120 سطرًا. ضع كل ما عدا ذلك في ملفات منفصلة ووجّه إليه.
النمط المضاد 2. مجلد شامل لكل شيء. تضع كل شيء في الذاكرة الثانية: مراسلات خام، ولقطات شاشة عديمة الفائدة، وتقارير لن يقرأها أحد. بعد شهر، يتضخم المجلد، ويهدر الوكيل الرموز في قراءة الحشو، ولا تعود تعرف أين تجد الأشياء. القاعدة: ينبغي أن يجيب كل ملف في الذاكرة الثانية عن سؤال محدد. إذا لم يفتحه أحد خلال ستة أشهر، فاحذفه أو انقله إلى الأرشيف.
النمط المضاد 3. التكرار. «تمر المدفوعات عبر CloudPayments في src/lib/payment/cloudpayments.ts، ومزود الخدمة مضبوط في .env». يستطيع الوكيل رؤية كل ذلك في الشيفرة. لا تكرره في business/. فالمعلومات المكررة تصبح قديمة: تتغير الشيفرة ولا يُحدّث business/، فيعمل الوكيل استنادًا إلى معلومات متقادمة.
النمط المضاد 4. الأرقام المثبتة. «لدينا 1,247 عميلًا ومعدل تحويل 6.3%» - تخيل أن هذه أرقام من شركة تقنية مالية مجردة. ستصبح كل هذه الأرقام قديمة خلال أسبوع. استخدم علامة LIVE وlive-metrics.md. يوجد القسم الذي يتناول ذلك أعلاه.
النمط المضاد 5. سياق دون مسار وصول متاح. إذا كانت الذاكرة الثانية في موضع آخر ولا يملك الوكيل إذنًا أو مرجعًا إليها، فلا يكفي البدء في مجلد الشيفرة. للملاحظات المشتركة غير الحساسة، يعد إبقاء business/ وai-clone/ داخل المستودع ترتيبًا ملائمًا. وللسياق الخاص، أبقه في موضع مستقل خاضع للتحكم واضبط الوصول المسموح والتوجيه صراحة. سهولة المجلدات لا تتجاوز السرية.
نصيحة
ينظم فرع مستقل (context أو business-context) العمل لكنه ليس حد وصول؛ فملفاته ما زالت كائنات Git في المستودع نفسه وقد تُنشر مع الفروع أو السجل. للسياق التجاري الخاص، استخدم مستودعًا خاصًا مستقلًا أو مخزنًا خارجيًا بضوابط وصول وتوجيه مسموح للوكيل صريحين. قد تشير الوحدة الفرعية إلى مستودع خاص مستقل، لكن خصوصيتها تأتي من أذونات ذلك المستودع وليس من الوحدة نفسها. خيار آخر مجلد محلي متجاهل عمدًا بنسخة احتياطية خاصة؛ ولا يزيل التجاهل ملفات متتبعة أو تاريخًا منشورًا سابقًا. أبق مع الشيفرة السياق القابل للمشاركة فقط.
كيف تبني ذاكرة ثانية خلال ساعة - وصفة خطوة بخطوة
النقطة الأساسية
يمكنك إعداد ذاكرة ثانية بسيطة خلال ساعة: أنشئ المجلدين business/ وai-clone/ في الجذر، وأنشئ ملف خريطة INDEX.md في كل منهما، وأضف وصفًا موجزًا للمنتج تحت business/products/، ووصفًا للعميل تحت audience/، ووصفًا لك في ai-clone/role.md. أضف مسارات التوجيه إلى هذه المجلدات في CLAUDE.md. ثم وسّعها أثناء العمل: بعد كل خطأ للوكيل، أضف قاعدة إلى ai-clone/feedback/؛ وبعد كل قرار، أضف ملاحظة إلى business/.
أنشئ مجلدين في الجذر
في جذر المشروع، إلى جانب
src/:mkdir -p business/{products,audience,goals,economics,marketing} mkdir -p ai-clone/{identity,voice,principles,feedback,style}أنشئ INDEX.md ليكون خريطة للمجلد
يحتوي
business/INDEX.mdعلى جدول من نوع «السؤال ← الملف». ابدأ بخمسة صفوف على الأقل، وأضف المزيد مع تقدمك. افعل الشيء نفسه فيai-clone/INDEX.md.أضف أوصافًا موجزة للمنتج والعميل
business/products/main.md- ما المنتج، ولمن، وكم تكلفته، وما الذي يميزه. من 30 إلى 50 سطرًا.business/audience/avatar.md- من العميل، وما نقاط معاناته، وما الذي يشتريه. من 30 إلى 50 سطرًا. لا تصف عميلًا مثاليًا؛ صف عميلًا حقيقيًا. إذا لم تكن تعرف شيئًا، فاكتب «بحاجة إلى توضيح» وتابع.صِف نفسك في ai-clone/role.md
من أنت، وماذا تفعل، وما الذي يهمك. من 20 إلى 30 سطرًا. هذا يكفي للبدء. أضف النبرة والمبادئ وكلمات التوقف عندما تلاحظ أن الوكيل يكتب بأسلوب لا يشبه أسلوبك.
أضف مسارات التوجيه إلى CLAUDE.md
افتح
CLAUDE.mdوأضف قسمًا:## خريطة المشروع - سياق العمل ← `business/INDEX.md` - سياق عني ← `ai-clone/INDEX.md` - الخطط التقنية ← `plans/YYYY-MM-DD-*.md` - مراجعات الجلسات السابقة ← `retrospectives/` اقرأ دائمًا `ai-clone/INDEX.md` و`business/INDEX.md` في بداية الجلسة.ابدأ Claude Code وتحقق
افتح الوكيل. اسأله: «أخبرني عن منتجي وجمهوري». إذا أجاب استنادًا إلى سياق المجلد، فالنظام يعمل. وإذا اختلق معلومات، فتحقق من وجود المجلدات إلى جانب المشروع، ومن صحة أسماء الملفات، ومن دقة مسارات التوجيه في
CLAUDE.md.
بعد ذلك، تنمو الذاكرة الثانية وفق مبدأين.
أولًا: كلما ارتكب الوكيل خطأ، أضف قاعدة. بعد 3-4 أسابيع، سيحتوي ai-clone/feedback/ على 15-20 ملف قاعدة، وسيتوقف الوكيل عن ارتكاب معظم الأخطاء الشائعة.
ثانيًا: كلما اتخذت قرارًا في العمل، سجله في business/. إذا رفعت السعر، فأضف ملاحظة إلى business/products/pricing.md تتضمن التاريخ والسبب. وإذا غيرت تحديد المكانة، فأضف ملاحظة إلى business/company/about.md. بعد ستة أشهر، سيكون لديك أرشيف يتذكر «لماذا».
نص الطلب: نص جاهز للاستخدام لتحديث الذاكرة الثانية مساءً
لقد أنجزنا معًا قدرًا كبيرًا من العمل هذا الأسبوع.
حلل جميع تغييرات الشيفرة لهذا الأسبوع وكل الالتزامات التي أجريناها.
ما المعلومات القيّمة من ذلك التي ينبغي أن تكون في business/؟ اكتبها في الملفات المناسبة،
وأضف روابط Wiki إلى الملفات المجاورة كيلا يضيع السياق.
إذا كانت هناك قرارات في الشيفرة لم أشرحها، فاسألني عن السبب،
وسجل السبب في الملف المناسب مع ذكر التاريخ.
لا تكرر ما يتضح بالفعل من الشيفرة. أدرج فقط ما لن يعرفه الوكيل
في الجلسة التالية من دون business/.
ما الخطوة التالية - المهارات والوكلاء الفرعيون وهندسة السياق
النقطة الأساسية
الذاكرة الثانية مع CLAUDE.md هي الأساس. أضف فوقها المهارات (معرفة إجرائية تُحمّل عند الحاجة بناءً على وصف المهمة)، والوكلاء الفرعيين (مثيلات Claude معزولة ذات نوافذ سياق خاصة بها للمهام الثقيلة)، وهندسة السياق (إدارة ما يدخل النافذة). هذه هي الطوابق الثلاثة العليا. ولا تعمل من دون الأساس؛ إذ لن يجد الوكيل شيئًا يقرأه.
بعد إنشاء الذاكرة الثانية، هناك ثلاث أدوات أخرى تصفها Anthropic بوصفها ثلاثة مستويات مختلفة لتحسين السياق.
المهارات هي معرفة إجرائية. إذا كان لديك سير عمل تكرره (كتابة دليل تعليمي، أو إعداد منشور Telegram، أو تدقيق موقع)، فيمكنك ترميزه في ملف SKILL.md مع وصف للمهمة. في بداية الجلسة، يتصفح Claude أسماء المهارات وأوصافها، ولا يحمّل إلا ما يناسب المهمة الحالية. وهذا يوفر الرموز ويحافظ على التركيز.
الوكلاء الفرعيون مثيلات معزولة من Claude لها نوافذ سياق خاصة بها. شغّل وكيلًا فرعيًا على مهمة تتطلب جهدًا (قراءة 30 ملفًا وإعداد ملخص)، وسيعمل في نافذته الخاصة ويعيد النتيجة وحدها. وتظل نافذتك الرئيسية واضحة. تكتب Anthropic:
يمكن للوكلاء الفرعيين المتخصصين حل المهام المركزة ضمن نوافذ سياق نظيفة. [...] يستطيع كل وكيل فرعي الاستكشاف على نطاق واسع، وإنفاق عشرات الآلاف من الرموز أو أكثر، لكنه يعيد ملخصًا مضغوطًا ومصفّى فقط عن عمله (غالبًا ما بين 1,000 و2,000 رمز).
هندسة السياق هي إدارة ما يدخل النافذة أصلًا. وقد وصف فريق Anthropic ذلك بأنه مهارة أساسية للعمل مع الوكلاء في 2025، أي مستوى يعلو هندسة المطالبات. هندسة المطالبات تختار الصياغة؛ أما هندسة السياق فتختار الملفات ومسارات التوجيه والمهارات والوكلاء الفرعيين.
الذاكرة الثانية هي أول لبنة في هندسة السياق. من دونها، لا تجد المهارات شيئًا لتقرأه، ولا مكان يذهب إليه الوكلاء الفرعيون، وتمتلئ نافذة الوكيل بمعلومات عشوائية. أما بوجودها، فتبدأ الأدوات الثلاث بالعمل.
الخطوة التالية. أنشئ مجلدين إلى جانب المشروع: business/ وai-clone/. أضف إلى كل منهما ملف INDEX.md من 5 أسطر يعمل خريطة. وأضف أربعة أسطر توجيه إلى CLAUDE.md. خلال ساعة، سيكون لديك إطار عمل للذاكرة الثانية. ثم وسّعه باتباع قاعدة «بعد كل خطأ من الوكيل، أضف سطرًا إلى ai-clone/feedback/». أشرح قالب CLAUDE.md الكامل الذي ستستخدمه للتوجيه إلى الذاكرة الثانية في دليل كيفية إعداد CLAUDE.md بشكل صحيح.
المصادر
- وثائق ذاكرة Claude Code - تسلسل الذاكرة الرسمي في Claude Code من Anthropic
- أفضل الممارسات في Claude Code - إرشادات Anthropic الرسمية للعمل مع CLAUDE.md
- هندسة السياق الفعالة لوكلاء الذكاء الاصطناعي - من Anthropic Engineering، شرح تدهور السياق وميزانية الانتباه والسياق عند الحاجة
- شرح المهارات - مدونة Anthropic: التمييز بين المهارات والذاكرة والوكلاء الفرعيين وMCP
تابع استكشاف Ailoot عبر ailoot.ai.
المزيد من التفاصيل
أسئلة شائعة
هل يبقي وضع سياق العمل على فرع Git آخر خاصًا؟
لا. الفرع جزء من المستودع نفسه، وقد تُشارك ملفاته مع كائنات المستودع وسجله. استخدم مخزنًا خاصًا مستقل التحكم، أو مجلدًا محليًا متجاهلًا عمدًا بنسخة احتياطية؛ فالتجاهل لا يمحو السجل المتتبع القائم.
كيف يجد الوكيل سياقًا خاصًا خارج مستودع الشيفرة؟
أعطه مرجعًا صريحًا وأذونات الوصول اللازمة للمهمة فقط. احتفظ بفهرس قصير يوجه إلى الوثيقة المناسبة، وتحقق من قدرته على قراءة الملف المسموح؛ فالموضع الخاص بلا توجيه لا يضيف السياق تلقائيًا.