وضع Plan Mode في Claude Code: دليل خطوة بخطوة ومراحله الأربع في 2026

تجد تعليمات إضافية في توثيق Ailoot.

ما وضع Plan Mode، ولماذا لا يكفي وحده؟#

في الوضع العادي، يكتب Claude Code الشيفرة فورًا، وإذا لم تتابع ما يفعله، فقد تحصل فجأة على فرق يشمل ملفات كثيرة. يعكس Plan Mode ترتيب الخطوات: البحث والتخطيط أولًا، ثم الموافقة، ثم التغييرات.

تصف Anthropic وضع Plan Mode في توثيقها الرسمي كما يلي:

يبدو الأمر بسيطًا، لكنه يخفي التحول الأساسي. يغيّر Plan Mode إيقاع العمل: اتفق أولًا، ثم نفّذ. إنه تغيير في الوضع، لا تعديل شكلي. تكمن المشكلة لدى من يبرمجون بأسلوب vibe coding في أن وكلاء الذكاء الاصطناعي يميلون إلى التسرع. إذا طلبت «أضف مصادقة Google» في الوضع العادي، فسيكتب Claude الشيفرة في دقيقة، لكن نصف الملفات ستكون غير صحيحة. في Plan Mode، يتحول الطلب نفسه إلى خطة نصية يمكنك قراءتها في دقيقتين وتصحيحها قبل لمس أي شيفرة.

إليك فخًا لا تتناوله الأدلة الدولية. Plan Mode وحده أداة ضعيفة: فالخطة لا توجد إلا في المحادثة الحالية. أغلق النافذة وستضيع الخطة. لا يمكنك تسليمها إلى وكيل آخر. ولا توجد إصدارات أو محفوظات. إذا كانت المهمة كبيرة، مثل إعادة هيكلة وحدة تضم 30 ملفًا أو الانتقال إلى قاعدة بيانات جديدة، فستبلغ الخطة سريعًا سقف نافذة السياق وتبدأ جودتها في التراجع.

لهذا يعمل Plan Mode جيدًا مع مجلد plans/ في المستودع. تُحفظ الخطة في plans/2026-05-21-google-oauth.md، وتُقسّم إلى مراحل مع مربعات اختيار، ويمكن لأي وكيل لاحق استلامها ومتابعتها. هكذا تعمل هندسة السياق: إدارة السياق قبل الطلب، لا أثناءه.

كيف تفعّل Plan Mode في Claude Code؟#

أسرع طريقة أثناء الجلسة هي استخدام لوحة المفاتيح:

Shift+Tab           # cycles through modes: default → acceptEdits → plan

بعد الضغط مرتين، سيظهر المؤشر ⏸ plan mode on في أسفل الطرفية. تعيدك الضغطة الثالثة إلى الوضع العادي. هذه هي الطريقة الأكثر ملاءمة؛ إذ يمكنك التبديل أثناء العمل عندما تلاحظ أن المهمة تتوسع.

الطريقة الثانية هي إضافة بادئة قبل طلب واحد:

/plan write a plan to migrate the database from MySQL to Postgres

يفيد هذا الخيار عندما تكون في وضع القبول التلقائي ولا تريد تغييره طوال الجلسة. طلب واحد في Plan Mode، ثم يستمر العمل كما كان.

الطريقة الثالثة عند تشغيل الجلسة:

claude --permission-mode plan

استخدم هذا الخيار عندما تعرف مسبقًا أن المهمة تحتاج إلى تخطيط، مثلًا قبل إعادة هيكلة كبيرة أو عملية ترحيل.

الطريقة الرابعة هي تعيين الوضع الافتراضي في .claude/settings.json داخل المشروع:

{
  "permissions": {
    "defaultMode": "plan"
  }
}

متى يكون ذلك مفيدًا؟ عندما يعمل فريق على نظام معقد يمكن لأي تغيير فيه أن يؤثر في الوحدات المجاورة. عندها يحمي وضع Plan Mode الافتراضي الجميع من التغييرات العرضية.

وهناك حيلة خامسة غالبًا ما تُغفل: يفتح Ctrl+G الخطة في محرر نصوص. استخدمه عندما تكون الخطة صحيحة تقريبًا، لكنك تحتاج إلى إعادة صياغة نقطتين أو ثلاث أو إضافة قيد. حرّرها يدويًا واحفظها، وسيواصل Claude العمل وفق نسختك.

ما المراحل الأربع المعتمدة لدى Anthropic في Plan Mode: Explore وPlan وImplement وCommit؟#

تصف أدلة كثيرة ثلاث مراحل (Explore-Plan-Execute) أو مرحلتين فقط (Plan-Implement). هذه اختصارات. في دليل أفضل الممارسات الرسمي، تصف Anthropic أربع مراحل بالضبط. والفرق مهم: فصل Commit في مرحلة مستقلة يجعلك تسجل النتيجة بدلًا من تركها عند «أضفت بضعة تعديلات أخرى هنا، وسأنشئ commit لاحقًا»؛ وهو المصدر الأكثر شيوعًا لضياع العمل.

كلما كانت الخطة أدق، قلّت التكرارات اللازمة للتنفيذ. إذا قضيت 10 دقائق في التخطيط، فسيُنجز التنفيذ بطلب واحد. وإذا رسمت الخطة في دقيقة، فسيستغرق التنفيذ ساعة من الإصلاحات.

إليك شكل المراحل الأربع عند إضافة Google OAuth (مثال من Anthropic Docs):

تختلف الطلبات أيضًا في كل مرحلة. في Explore: «اقرأ /src/auth وافهم كيف نتعامل مع الجلسات وتسجيل الدخول». في Plan: «أريد إضافة Google OAuth. ما الملفات التي يجب تغييرها؟ أنشئ خطة». في Implement: «نفّذ تدفق OAuth من خطتك، واكتب الاختبارات، وشغّل المجموعة، وأصلح الإخفاقات». في Commit: «أنشئ commit برسالة وصفية وافتح طلب سحب».

هناك تفصيل مهم: لا يمنع Plan Mode Claude من تشغيل أوامر البحث. يُسمح باستخدام Read وLS وGlob وGrep وجلب الويب وأوامر shell للاستكشاف. المحظور فقط هو Edit وWrite وأي عمليات تغيّر نظام الملفات. وهذا يعني أن Claude يستطيع قراءة بنية المشروع، وتشغيل git log، والاطلاع على الاختبارات، لكنه لن يتمكن من تغيير أي شيء عن طريق الخطأ.

كيف تقرأ خطة Claude وتقرر ما إذا كنت ستوافق عليها؟#

عندما ينتهي Claude من إنشاء الخطة، يعرض خيارات الخطوة التالية:

• الموافقة والبدء في الوضع التلقائي
• الموافقة وقبول التعديلات
• الموافقة ومراجعة كل تعديل يدويًا
• مواصلة التخطيط مع تقديم ملاحظات
• التحسين باستخدام Ultraplan (مراجعة عبر المتصفح)

معرفة ما إذا كان ينبغي الموافقة على الخطة هي المهارة الأساسية في Plan Mode. من السهل أن تضغط «موافقة» تلقائيًا ثم تضطر إلى التراجع عن commits. يريد الذكاء الاصطناعي المتملق أن يقدم إجابة سريعة، وتريد أنت الوصول إلى الشيفرة أسرع. كلاكما مخطئ.

تستوفي الخطة الجيدة 7 معايير:

1. أسماء ملفات محددة. ليس «سأحدّث المصادقة»، بل «سأغيّر src/auth/login.ts:42-58، وأنشئ src/auth/oauth-callback.ts، وأحدّث src/auth/session.ts:103».
2. تسلسل محدد. تُقسّم الخطة إلى مراحل أو خطوات، بدلًا من «سأنفذ كل هذا بطريقة ما».
3. تسمية التبعيات الخارجية. إذا كانت المهمة تتطلب مكتبة جديدة، تُذكر. وإذا كانت تتطلب متغيرات بيئة، فتُذكر.
4. ذكر المخاطر. تقول الخطة الجيدة: «قد يؤدي الترحيل إلى كسر الجلسات الحالية؛ يجب التحقق من X». أما السيئة فتصمت عن الآثار الجانبية.
5. وجود معايير للنجاح. «تنجح اختبارات test/auth، ويكون فاحص التنسيق نظيفًا، ويبدأ خادم التطوير من دون أخطاء».
6. خلوها من افتراضات «مختلقة من العدم». إذا قال Claude «سأستخدم المكتبة Z»، فتحقق: هل ثبّتها أصلًا في المشروع؟ إذا اختلقها الذكاء الاصطناعي، فلن تجد لها ذكرًا في package.json.
7. أن تكون الخطة قابلة للقراءة على الشاشة. إذا بلغت خطة مهمة بسيطة 200 سطر، فربما تكون المهمة أكبر من أن تُنجز بخطة واحدة. قسّمها إلى أجزاء.

عندما لا تجتاز الخطة التحقق، تتوفر ثلاثة خيارات:

• مواصلة التخطيط مع تقديم ملاحظات—قدّم إلى Claude تعليقًا محددًا عمّا لا يعجبك، وسيعيد كتابة الخطة.
• Ctrl+G—افتح الخطة في محرر، وحررها يدويًا، واحفظها. سيتابع Claude وفق نسختك.
• التحسين باستخدام Ultraplan—تُنقل الخطة إلى وضع المتصفح في Claude Code على الويب، حيث تراجع الأقسام وتعلّق عليها، ثم تنفذها محليًا أو في السحابة.

إذا حدث خطأ في منتصف التنفيذ، فلا تحاول فرضه. عُد إلى Plan Mode وأعد كتابة الخطة. هذا أقل تكلفة بعشر مرات من التراجع عن 40 commits لاحقًا.

Plan Mode مع مجلد plans/: مزيج يناسب السياق الطويل#

Plan Mode وضع في Claude Code. أما مجلد plans/ فهو منهجية مبنية عليه. إذا استخدمت Plan Mode من دون مجلد، فستبلغ الحد بعد ساعة من العمل.

إليك المنطق. نافذة سياق Claude هي ذاكرة الجلسة. يمكنها استيعاب مليون token في Opus 4.7، لكن ذلك يمثل حجم المحادثة كلها. إذا خططت لمهمة معقدة في محادثة واحدة، ثم طلبت التنفيذ، ثم ناقشت خطأً، ثم انتقلت إلى أمر آخر، فستنتفخ النافذة. يبدأ Claude بنسيان القرارات المبكرة، والخلط بين السياقات، وطرح الأسئلة من جديد.

الحل هو القاعدة الذهبية: مهمة واحدة—محادثة واحدة.

إليك طريقة تطبيقها:

1. المحادثة 1—إعداد الخطة. فعّل Plan Mode، واشرح المهمة، وسيُنشئ Claude خطة. احفظها في plans/2026-05-21-feature-name.md. أغلق النافذة.
2. المحادثة 2—تقسيم الخطة إلى مراحل. افتح محادثة جديدة. اطلب: «خذ plans/2026-05-21-feature-name.md وقسّمه إلى مراحل». احفظ الملف المحدّث.
3. المحادثة 3—تنفيذ المرحلة 1. افتح محادثة جديدة. اطلب: «نفّذ المرحلة 1 من plans/2026-05-21-feature-name.md، وضع علامة على البنود عند إكمالها». أغلق النافذة.
4. المحادثة 4—تنفيذ المرحلة 2. كرر الأمر نفسه.

ما الفائدة؟ تظل نافذة سياق كل محادثة جديدة. لا يعرف Claude في المرحلة 3 تفاصيل المرحلة 1، لكنه يعرف الخطة لأن ملف plans/ موجود في المستودع. يمكن لأي وكيل لاحق، سواء أكان وكيلًا فرعيًا أو جلسة جديدة أو تشغيلًا عبر /goal، استلام الخطة ومتابعتها.

مقارنة بين النهجين:

لكل ميزة ملف خطة خاص بها. عندما تحتاج بعد ثلاثة أشهر إلى تذكر سبب اختيار موفر دفع على بديل، يمكنك فتح الخطة المعنية وقراءة سجل القرار: ما الذي نوقش، وما الخيارات التي أُخذت بعين الاعتبار، ولماذا اختير هذا المسار بالذات.

هذه خطط عمل حية؛ أما الوثائق الثابتة فتصبح قديمة خلال بضعة أشهر.

كيف تجعل Claude يعمل أثناء نومك باستخدام Plan Mode و/goal؟#

العائق الرئيسي في جلسات الذكاء الاصطناعي الطويلة ليس النموذج نفسه، بل الشخص الذي يضغط على Enter. كلما وصل Claude إلى نهاية دور، ينتظر ردك. يزيل /goal هذا الانتظار.

الصياغة بسيطة:

/goal all tests in test/auth pass and lint is clean, or stop after 20 turns

يمكن أن يصل طول الشرط إلى 4000 حرف. يوجد هدف واحد لكل جلسة. بعد كل دور، ينظر النموذج المصغر Haiku إلى نص المحادثة ويقرر: «تحقق الشرط—إنهاء» أو «لم يتحقق—الدور التالي». لا يستدعي المُقيِّم أدوات؛ بل يقرأ فقط.

الأسماء البديلة لمسحه: /goal stop و/goal off و/goal reset و/goal none و/goal cancel.

يبدو الجمع مع Plan Mode كما يلي:

1. فعّل Plan Mode (اضغط على Shift+Tab مرتين).
2. اطلب: «أنشئ خطة لترحيل قاعدة البيانات من MySQL إلى Postgres، واحفظها في plans/2026-05-21-postgres-migration.md مع مراحل ومعايير».
3. راجع الخطة وحررها ووافق عليها.
4. اخرج من Plan Mode (اضغط على Shift+Tab مرة أخرى).
5. عيّن هدفًا: «أكمل كل المراحل في plans/2026-05-21-postgres-migration.md، وضع علامة على مربعات الاختيار، وتأكد من نجاح كل الاختبارات، أو توقف بعد 50 دورًا».
6. أغلق حاسوبك المحمول ونم.

في الصباح، تحقق من النتيجة: إما «✓ اكتمل الهدف» أو «◎ توقف بعد 50 دورًا»، مع سجل لما أُنجز.

هناك ثلاث قواعد أساسية لاستخدام /goal، وإلا فستهدر الرموز:

القاعدة 1: حالة نهائية قابلة للقياس. «اجعله يبدو جميلًا» طلب سيئ. أما «يعيد npm test القيمة 0، ويعيد npm run lint القيمة 0، ويُضاف إدخال إلى CHANGELOG.md» فطلب جيد.

القاعدة 2: تحقق صريح. ينبغي أن يشير الشرط إلى شيء يمكن التحقق منه: أمر أو ملف أو نقطة نهاية. ليس «كل شيء يعمل»، بل «يعيد curl localhost:3000/api/users الحالة 200».

القاعدة 3: حد لعدد الأدوار. أضف دائمًا or stop after N turns. توصي Anthropic صراحةً في التوثيق بما يلي:

إذا فعّلت /goal من دون or stop after، فقد تختفي ميزانيتك طوال الليل.

ما دورة الخطوات الأربع التي تحول Plan Mode إلى عملية هندسية؟#

من الأخطاء الشائعة السؤال «كيف أصلحه؟»: يعطي Claude حلًا، فتطبقه، لكن لا ينجح شيء أو تزداد الأمور سوءًا. هذه هي «مجاملة الذكاء الاصطناعي»: لقد دُرّب على الإجابة بسرعة، وأنت تريد الوصول إلى الشيفرة أسرع. وتعالج دورة من 4 خطوات هذه المشكلة.

تمنع دورة الخطوات الأربع هذا السلوك. وتُستخدم بالتتابع ضمن جلسة Plan Mode واحدة:

الخطوة 1. إثبات الحقائق من دون حل.

نص الطلب: «أواجه ما يلي: [وصف العَرَض]. مهمتك الآن هي إثبات الحقائق. يُحظر تقديم أي حلول أو أفكار أو نصائح. المطلوب فقط: ما ألاحظه، وما الخطوات القابلة لإعادة الإنتاج، وما البيانات المتاحة، وما البيانات المفقودة. شرط توقف صارم: لا تقترح حلولًا؛ سجّل التشخيص فقط».

هذا يمنع اندفاع الذكاء الاصطناعي الأول: «إليك الحل». على Claude أن يتوقف عند «ما هو معروف وما هو مجهول».

الخطوة 2. تطوير خيارات بالاستناد إلى سوابق.

نص الطلب: «بعد تثبيت التشخيص، ابحث على الإنترنت عن سوابق لحل مشكلات مشابهة. اعرض 3 نهوج مختلفة على الأقل. ولكل نهج: رابط إلى المصدر الأولي، ووصف موجز، والإيجابيات والسلبيات في حالتنا».

هذا يمنع اندفاع الذكاء الاصطناعي الثاني: «اختلاق حل من عندي». نجعله يخرج إلى العالم ويعود بنهج يمكن التحقق منه.

الخطوة 3. خطة مفصلة مع المخاطر.

نص الطلب: «خذ أفضل خيار من الخطوة 2 وضع خطة مفصلة: الملفات المحددة التي يجب لمسها، وما يجب إضافته، وما يجب حذفه، والاختبارات المطلوب كتابتها، وما قد يتعطل، والمخاطر التي تلوح بعد 2-3 خطوات».

هذه هي مرحلة Plan المألوفة، مع اختلاف واحد: تستند إلى الخيارات المتحقق منها في الخطوة 2، لا إلى تخمينات Claude.

الخطوة 4. مراجعة الخطة ذاتيًا.

نص الطلب: «أجرِ الآن مراجعة ذاتية إلزامية. أعد فحص خطتك بصدق: هل توجد مواضع اختلقت فيها شيئًا من العدم ولم تتحققي منه بمراجعته مقابل الشيفرة أو التوثيق أو سابقة من الخطوة 2؟ إذا وجدت، فحددها ونقّح الخطة».

هذا هو المرشح النهائي. على Claude أن يتحقق من منطقه ويقر بالمواضع التي هلوس فيها. عادةً ما تُنقّح بندين على الأقل من بنود الخطة في هذه الخطوة.

بعد الخطوات الأربع، تصبح الخطة جاهزة للموافقة. تنتقل إلى التنفيذ مطمئنًا إلى فهم المهمة، وموازنة الخيارات، ومراعاة المخاطر.

صُممت هذه المنهجية لتشخيص الأخطاء الصعبة واتخاذ القرارات المعمارية، حيث تكون تكلفة الخطأ مرتفعة. وعند تطبيقها على Plan Mode، تزيل أكبر مشكلة لدى من يبرمجون بأسلوب vibe coding: «أعطاني الذكاء الاصطناعي حلًا، وطبقته، فانهار كل شيء».

ما الطلبات الخمسة الجاهزة للاستخدام في Plan Mode للمهام الشائعة؟#

القالب 1. إعادة هيكلة وحدة.

I'm enabling Plan Mode. Task: refactor the {module-name} module.

Step 1: Study the current structure of the {module-path} module. Describe:
- which files are part of the module
- which external dependencies it has
- which parts are duplicated
- which functions are overcomplicated

Step 2: Find 2-3 examples online of refactoring similar modules.
At least 1 source must be official Anthropic or related framework documentation.

Step 3: Create a refactoring plan in plans/YYYY-MM-DD-refactor-{module}.md:
- which files to rename
- which functions to extract into separate modules
- which tests to keep and which to rewrite
- risks: what could break for users

Step 4: Self-check. Are there any assumptions in the plan that are "pulled out of thin air"?
Rewrite or remove them.

القالب 2. ترحيل قاعدة بيانات.

I'm enabling Plan Mode. Task: migrate the database from {old} to {new}.

Step 1: Study the current database schema using {schema-reading-command}. Describe:
- which tables exist and their size
- which relationships, indexes, and constraints there are
- where migrations are stored
- which data is critical

Step 2: Find precedents for {old → new} migrations in production projects.
At least 3 different approaches: pg_dump, dual-write, blue-green.
For each, list the pros and risks for our data size.

Step 3: Create a migration plan in plans/YYYY-MM-DD-db-migration.md:
- phases (backup, migration, verification, switchover)
- success criteria for each phase
- rollback plan if something goes wrong
- downtime or no downtime

Step 4: Self-check. Are all figures supported by documentation?
Have all steps been mentally checked against the dev environment?

القالب 3. إضافة ميزة جديدة.

I'm enabling Plan Mode. Task: add the {description} feature to the project.

Step 1: Study how similar features currently work in the project.
Specifically, look at:
- {file-1}
- {file-2}
- which architectural patterns are used
- which tests are written for similar features

Step 2: Find how this feature is implemented in open-source projects
with a similar architecture. At least 2 different approaches.

Step 3: Create a plan in plans/YYYY-MM-DD-feature-{name}.md:
- list of new files
- list of changed files with specific lines
- implementation sequence
- which tests to add
- what to add to CLAUDE.md as a rule for future sessions

Step 4: Self-check. Does the plan follow the project's architecture?
Does it assume libraries that haven't been installed yet?

القالب 4. كتابة الاختبارات.

I'm enabling Plan Mode. Task: cover the {name} module with tests.

Step 1: Study the {path} module. Identify:
- public functions and their signatures
- internal functions we will NOT test (implementation details)
- edge cases: empty input, errors, concurrent access

Step 2: Find test examples for a similar class of tasks
in popular open-source projects using the same framework.

Step 3: Create a test plan in plans/YYYY-MM-DD-tests-{module}.md:
- for each public function, a list of tests
- which mocks are needed
- which fixtures
- which verification approach (assertion style)

Step 4: Self-check. Do all tests check behavior rather than implementation?
Does the coverage include edge cases?

القالب 5. تصحيح خطأ معقد.

I'm enabling Plan Mode. Task: understand the cause of the error {symptom-description}.

Step 1: ESTABLISH THE FACTS. Solutions and ideas are prohibited. Only:
- what I observe (exact wording of the error)
- reproducible steps
- what data is available (logs, traces, library versions)
- what data is missing (what needs to be collected additionally)

Step 2: Find precedents for this error.
At least 3 sources: GitHub issues, documentation.
For each, provide a link and a brief summary of the solution.

Step 3: Create a diagnostic plan in plans/YYYY-MM-DD-bug-{name}.md:
- which hypotheses to check (sorted by likelihood)
- which commands/scripts to run to check each one
- the expected result of each check

Step 4: Self-check. Are there any hypotheses in the plan that are "pulled out of thin air"?
Are all hypotheses tied to facts from Step 1?

انسخ كل قالب، واستبدل {parameters} ببياناتك، ثم ألصقه في Claude Code ضمن Plan Mode. ستكون النتيجة خطة عمل في plans/ توافق عليها وتستخدمها للتنفيذ.

Plan Mode مقابل الوضع العادي: أيهما تختار؟#

تقول Anthropic ذلك مباشرة في توثيقها:

عند تطبيق إرشادات Anthropic للعمل مع Claude Code، ميّز بين تعديل بسيط مفهوم منخفض المخاطر وتغيير يحتاج إلى اكتشاف أو تنسيق. لا تعد القدرة على وصف الفرق بعبارة واحدة بديلًا عن تقييم الآثار الجانبية والتحقق.

تجاوز الخطة المستقلة فقط عندما يكون الفرق الفعلي صغيرًا ومفهومًا ومنخفض المخاطر. استخدم التخطيط لاكتشاف النهج أو تنسيق تغييرات خطرة بين المكونات. لا تزيل معرفة أسماء الملفات أو تلخيص الهدف بجملة مخاطر الترحيل أو المصادقة أو سلامة البيانات.

جدول القرار:

قبل اختيار الوضع، اسأل هل تفهم النهج والآثار الجانبية والتحقق. نفّذ مباشرة تغييرًا صغيرًا موضعيًا منخفض المخاطر بفحص واضح. خطط أولًا عند الغموض أو الشيفرة غير المألوفة أو الترحيل أو المصادقة أو التنسيق بين المكونات، حتى لو عرفت أسماء الملفات الـ3-5 المتأثرة.

كيف تجمع Plan Mode وCLAUDE.md والوكلاء الفرعيين لضمان عمل موثوق؟#

ملف CLAUDE.md يقرأه Claude في بداية كل جلسة، بما فيها Plan Mode. إذا نص CLAUDE.md على «لا تضع تواريخ ثابتة في الشيفرة مطلقًا؛ احصل عليها دائمًا من قاعدة البيانات»، فلن تقترح الخطة وضع تواريخ ثابتة. وإذا لم يتضمن هذه القاعدة، فقد تقترح الخطة أي شيء.

يعمل هذا المزيج كما يلي:

الطبقة 1. يحدد CLAUDE.md القواعد.

يحدد الملف حزمة المشروع ومبادئه المعمارية والمحظورات («لا تستخدم واجهات API المتقادمة») والمتطلبات («تمر جميع الرسائل الإلكترونية عبر تخطيط مشترك»). اقرأ الدليل المفصل: كيفية إعداد CLAUDE.md.

الطبقة 2. يطبق Plan Mode القواعد على المهمة.

عندما تفعّل Plan Mode وتطلب «أضف OAuth»، يقرأ Claude ملف CLAUDE.md، ويرى القواعد («خزّن الرموز في Redis، لا في قاعدة البيانات»)، ويأخذها في الحسبان مباشرةً في الخطة. وهكذا تتوافق الخطة مع معمارية المشروع.

الطبقة 3. يقسّم الوكلاء الفرعيون العمل.

إذا قُسّمت الخطة إلى مراحل، فيمكن إسناد كل مرحلة إلى وكيل فرعي مستقل. يعمل كل وكيل فرعي في نافذة سياق خاصة به من دون إثقال النافذة الرئيسية. تظل الخطة في plans/ المصدر المركزي للحقيقة: يقرؤها الوكلاء الفرعيون، وينفذون مرحلتهم، ويحدّثون مربعات الاختيار.

ما الأخطاء السبعة التي تفسد Plan Mode؟#

الخطأ 1. الخطة موجودة في المحادثة فقط.

العَرَض: كتبت خطة وأغلقت النافذة، وتحتاج إلى العودة في اليوم التالي، لكن لا شيء موجود؛ فقد ضاع السياق. الحل: احفظ الخطة دائمًا في plans/YYYY-MM-DD-feature-name.md داخل المستودع. المحادثة مكتب عمل؛ والملف أرشيف.

الخطأ 2. جميع المهام في محادثة واحدة.

العَرَض: تناقش المصادقة، ثم الترحيل، ثم تصميم الواجهة، ثم خطأً في جلسة واحدة. تنتفخ نافذة السياق وينسى Claude الأمور السابقة. الحل: مهمة واحدة—محادثة واحدة. انتهيت من الخطة؟ أغلق النافذة. أتبدأ التنفيذ؟ افتح نافذة جديدة.

الخطأ 3. خطة من 3000 سطر بلا مراحل.

العَرَض: توجد خطة، لكنها بلا مربعات اختيار أو تقسيم. يستحيل معرفة ما أُنجز وما لم يُنجز، ويستحيل تفويض العمل. الحل: قسّم كل خطة إلى 3-7 مراحل. واجعل كل مرحلة قائمة بمربعات اختيار وإجراءات محددة.

الخطأ 4. لا يوجد بحث متعمق قبل الخطة.

العَرَض: يقترح Claude حلًا من عنده لأنك لم تطلب منه البحث عن سوابق. وبعد أسبوع، تكتشف أن المصدر المفتوح يستخدم نهجًا أفضل منذ زمن. الحل: الخطوة 2 من دورة الخطوات الأربع؛ اطلب من Claude العثور على 2-3 سوابق عبر الإنترنت قبل إنشاء الخطة.

الخطأ 5. الذكاء الاصطناعي المتملق يقدم حلًا من دون تشخيص.

العَرَض: تسأل «كيف أصلح الخطأ X؟»، فيعطي Claude حلًا، وتطبقه، لكن لا ينجح شيء أو تسوء الأمور. الحل: ابدأ دائمًا بعبارة «أثبت الحقائق؛ الحلول ممنوعة». لا تنتقل إلى الخيارات إلا بعد التشخيص.

الخطأ 6. تجاوز المراجعة الذاتية.

العَرَض: تبدو الخطة معقولة، لكنها تحتوي على 2-3 افتراضات «مختلقة من العدم» (مكتبة مخترعة أو واجهة API غير موجودة أو إصدار خاطئ). ويتعطل التنفيذ عند تلك النقاط. الحل: الخطوة 4 من دورة الخطوات الأربع؛ اطلب من Claude إعادة فحص خطته بصدق والإشارة إلى الافتراضات.

الخطأ 7. شروط مبهمة في /goal.

العَرَض: تضبط /goal اجعله يبدو جميلًا، وتتركه طوال الليل، ثم تستيقظ لتجد أن $200 من حصتك قد استُهلكت. الحل: لا تستخدم إلا شروطًا قابلة للقياس، مع أمر للتحقق وشرط إلزامي or stop after N turns. لا تقل «اجعله جيدًا» أو «حسّنه».

الخطأ الثامن، وهو الأكثر شيوعًا بين من يبرمجون بأسلوب vibe coding، هو تجاهل فكرة مجلد plans/ نفسها. Plan Mode بلا مجلد plans/ ليس منهجية؛ بل لعبة. إذا استخدمت Plan Mode ولم تنشئ ملفات، فستحصل على 10% من إمكاناته.

ماذا تفعل بعد تجربتك الأولى مع Plan Mode؟#

ثلاث خطوات عملية مرتبة حسب الصعوبة:

الخطوة 1. أعد إعداد CLAUDE.md إن لم يكن لديك واحد بعد.

من دون CLAUDE.md، يعمل Plan Mode «في فراغ»؛ فلا يعرف Claude قواعد المشروع ويقترح خططًا تخرق المعمارية. الدليل الكامل: كيفية إعداد CLAUDE.md. يتكون ملف CLAUDE.md الأدنى من 50-80 سطرًا تصف حزمة المشروع والقواعد والمحظورات. الطول أمر ثانوي؛ المهم هو التحديد.

الخطوة 2. أنشئ مجلد plans/ في المستودع.

أضف مجلد plans/ إلى جذر المشروع. اتفقوا على صيغة تسمية: YYYY-MM-DD-feature-name.md. خصص ملفًا لكل خطة. بعد شهر سيكون لديك 20-30 ملفًا، وبعد ستة أشهر 100+ ملف. وهذا سجل حي لقرارات المشروع.

الخطوة 3. جرّب /goal في مهمة واحدة.

اختر مهمة تنجزها عادةً يدويًا خلال 30-40 دقيقة. فعّل Plan Mode، وأنشئ خطة، واحفظها في plans/. اخرج من Plan Mode. عيّن /goal complete all phases in plans/file.md, all tests pass, or stop after 30 turns. أغلق حاسوبك المحمول لمدة ساعة وافعل شيئًا آخر. عد وتحقق من النتيجة.

هذه الخطوات الثلاث هي الحد الأدنى. يُبنى ذلك تدريجيًا؛ لا تحاول جمع كل شيء في ليلة واحدة. ابدأ بـCLAUDE.md، وأضف plans/ بعد أسبوع، وجرّب /goal طوال الليل بعد شهر.

عندما تكون مستعدًا، تعرّف على Ailoot.