البدء مع نموذج Composer

Composer هو نموذج Cursor الخاص للبرمجة الوكيلية من الطراز المتقدّم، مُدرّب داخليًا ومحسّن لأمر واحد: إنجاز عمل برمجي حقيقي بسرعة. يخطّط، ويعدّل ملفات متعددة، ويشغّل أوامر الطرفية، ويتنقّل عبر الأدوات بزمن استجابة منخفض بشكل غير معتاد، كل ذلك بجزء بسيط من تكلفة النماذج المتقدّمة الكبيرة. يشرح هذا الدليل ما هو Composer، وكيفية اختياره، وأين يتألق، وأين ينبغي أن تتوجّه إلى نماذج من فئة Claude أو GPT، وكيفية تحقيق أقصى استفادة منه في العمل اليومي.

ما هو نموذج Composer؟

Composer عائلة من النماذج المخصّصة التي بناها فريق Cursor بدلًا من ترخيصها من طرف ثالث. وهو مُدرّب تحديدًا للبرمجة الوكيلية: قراءة قاعدة الكود، ووضع خطة، واستدعاء الأدوات، وتطبيق التعديلات عبر الملفات، والتحقّق من النتائج. وبخلاف نماذج الدردشة العامة التي كُيّفت للبرمجة، تم تحسين Composer منذ البداية لحلقة الوكيل.

أهداف التصميم وراء خط النماذج هي:

• زمن استجابة منخفض: تبدأ الردود بسرعة وتُنفَّذ استدعاءات الأدوات دون فجوات طويلة، فتبدو حلقة التعديل والاختبار فورية.
• كفاءة وكيلية: النموذج مضبوط على تسلسل استدعاءات الأدوات بمعقولية بدلًا من مطالبتك بإدارة كل خطوة بدقة.
• كفاءة السعر: Composer أرخص بشكل ملحوظ لكل طلب من النماذج المتقدّمة الأعلى، وهذا مهم لجلسات الوكلاء الطويلة.
• تفكير عملي: قوي بما يكفي لتخطيط تغييرات متعددة الخطوات مع بقائه أسرع بكثير من نماذج التفكير الممتد.

في المحرّر يتصرّف مثل أي نموذج آخر: تختاره من منتقي النماذج فيشغّل Chat، ووضع Agent، والتعديلات المضمّنة، والوكلاء في الخلفية. ويُلمس الفرق في معدّل الإنجاز. فالمهام التي تستغرق من نموذج متقدّم دقيقة من التفكير تكتمل في ثوانٍ مع Composer، بجودة تصمد جيدًا لغالبية أعمال البرمجة اليومية.

Composer ليس ميزة Composer لعام 2024

لا تخلط بين نموذج Composer وميزة تحرير عدة ملفات القديمة «Composer» التي أطلقتها Cursor في 2024. تلك الأداة المبكّرة كانت سير عمل في الواجهة لتطبيق التغييرات عبر ملفات كثيرة، ودُمجت لاحقًا في ما يُعرف الآن بوضع Agent. أما Composer الذي نتحدث عنه في هذا الدليل فهو النموذج نفسه، المختار من نفس المنتقي الذي يُختار منه Claude وGPT. إذا قرأت دروسًا أقدم تتعامل مع Composer كلوحة منفصلة أو اختصار لوحة مفاتيح، فهي تصف الميزة المتقاعدة، لا هذا النموذج.

كيف يختلف Composer عن النماذج الخارجية

نماذج Claude وGPT وGemini نماذج متقدّمة عامة يوجّهها Cursor عبر الشبكة. أما Composer فشيء من نوع مختلف: نموذج بناه Cursor تحديدًا لحلقة الوكيل. يظهر ذلك الاختلاف في السلوك حتى إن لم تكن التفاصيل الداخلية الدقيقة معلنة.

نسب النموذج الأساسي مقابل النماذج المتقدّمة الموجّهة

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

• النماذج الخارجية تجلب اتساعًا هائلًا وتفكيرًا عميقًا، بتكلفة زمن استجابة وسعر لكل طلب.
• Composer يجلب السرعة والتكلفة المنخفضة، مضبوطًا على الشكل المحدّد لمهام البرمجة لا على معايير التفكير العامة.
• الإطار مهم في الحالتين. أدوات Cursor (قراءة الملفات، التعديلات، الطرفية، البحث) تقف أمام كليهما، فالموازنة حقًا حول سلوك النموذج داخل ذلك الإطار.

مقايضة السرعة مقابل العمق

فكّر فيها كقرص بين العمق ومعدّل الإنجاز لا كخيارين ثنائيين «جيد» و«سيئ»:

• النماذج المنحازة للعمق تقضي وقتًا أطول في التخطيط والتفكير داخليًا، وهذا يُجدي في المشكلات الغامضة والمتشعّبة.
• النماذج المنحازة لمعدّل الإنجاز مثل Composer تتصرف أسرع، وتخمّن أقل مما توحي سرعتها، وتتقارب بسرعة على المهام محدّدة النطاق.
• معظم العمل الحقيقي مزيج. اجعل الافتراضي الطرف المنحاز لمعدّل الإنجاز، وارتقِ عندما يتبيّن أن مهمة تحتاج عمقًا.

أرقام زمن استجابة توضيحية

لجعل المقايضة ملموسة، إليك أرقامًا تقريبية توضيحية. اعتبرها تقديرات تقريبية لا قياسات معيارية، لأن زمن الاستجابة يعتمد بشدة على حجم المهمة وطول السياق والحمولة.

السيناريو	Composer (تقريبًا)	نموذج متقدّم (تقريبًا)
أول رمز ذي معنى	أقل بكثير من ثانية	ثانية أو أكثر
تعديل قصير في ملف واحد	بضع ثوانٍ	من عشر إلى ثلاثين ثانية
مهمة متعددة الملفات وكثيفة الأدوات	عشرات الثواني	من دقيقة إلى عدة دقائق

الأرقام إرشادية لا تعاقدية

توجد الأرقام أعلاه فقط لتوصيل شكل الفرق: Composer أسرع باستمرار، وتتسع الفجوة في الحلقات كثيفة الأدوات. لا تنقلها كأرقام صلبة؛ قِس على عبء عملك إن كانت الدقة تهمّك.

اختيار Composer من منتقي النماذج

Composer متاح في أي مكان يمكنك فيه اختيار نموذج: Chat، ووضع Agent، وسير العمل المضمّن على طراز Composer داخل Agent. للتبديل إليه:

1. افتح Chat أو وضع Agent باختصار اللوحة المعتاد.
2. انقر على منتقي النماذج بجانب مربع الإدخال.
3. ابحث عن Composer في قائمة النماذج. نماذج Cursor الداخلية مجمّعة بشكل منفصل عن النماذج الخارجية.
4. اختر إدخال Composer وأرسل مطالبتك كالمعتاد.

يمكنك أيضًا جعل Composer نموذجك الافتراضي في Settings > Models، بحيث تبدأ كل محادثة جديدة به. كثير من المطوّرين يُبقون Composer كافتراضي ويبدّلون يدويًا إلى نموذج أثقل فقط عندما تحتاج مهمة فعلًا إلى تفكير أعمق.

يظهر Composer أيضًا في قائمة النماذج للوكلاء في الخلفية، ما يجعله خيارًا طبيعيًا للمهام البعيدة حيث لا تراقب زمن الاستجابة مباشرةً لكنك تهتم بالتكلفة ووقت الجدار الكلي.

أين يمكن استخدام Composer

السطح	كيف تستخدم Composer	نموذج التكلفة المعتاد
Chat	اختره من منتقي النماذج	لكل طلب، مُقاس مقابل خطتك
وضع Agent	نفس المنتقي، يُستخدم للمهام متعددة الخطوات	لكل طلب
Cmd-K / التعديل المضمّن	متاح للتعديلات السريعة في موضع واحد	لكل طلب
الوكلاء في الخلفية	اختر Composer عند بدء المهمة	لكل طلب، الجلسات الأطول تكلف أكثر
إكمال Tab	ليس خيارًا من المنتقي؛ يستخدم Tab نموذجه الخاص	يُقاس بشكل مختلف عن طلبات النماذج

التكلفة لكل طلب مقابل لكل رمز

يُقاس استخدام خطة Cursor عمومًا لكل طلب لا بحسب الرمز فقط، ولهذا يمتدّ نموذج أرخص لكل طلب مثل Composer بخطة أطول بكثير مما يوحي سعر رمزه الخام وحده. تأثيران عمليان:

• الجلسات الطويلة التي تسلسل استدعاءات أدوات كثيرة هي حيث تكون ميزة Composer أكبر، لأن كل خطوة إضافية رخيصة نسبيًا.
• إذا اعتدت التفكير في تكلفة الرمز بمعايير API الخام، تذكّر أن Cursor يعرض استخدامك كاستهلاك للخطة، فالرقم الذي تراقبه هو عدّاد الخطة لا رقم بالدولار.

نقاط القوة والمقايضات

لا نموذج واحد يفوز بكل شيء. إليك كيف يقارن Composer بالنماذج المتقدّمة التي عادةً ما تتنقّل بينها.

القدرة	Composer	نماذج فئة Claude	نماذج فئة GPT
زمن استجابة الرد	سريع جدًا	متوسط إلى بطيء	متوسط
التكلفة لكل طلب	منخفضة	عالية	عالية إلى متوسطة
تعديلات متعددة الملفات	قوية، مبنية لهذا الغرض	ممتازة	جيدة جدًا
طلاقة أوامر الطرفية	قوية	ممتازة	جيدة جدًا
التفكير المعماري العميق	جيد	ممتاز	ممتاز
عمليات إعادة هيكلة طويلة غامضة	جيد مع تعليمات واضحة	الأفضل	جيدة جدًا
حلقات التكرار السريعة	الأفضل	متوسط	متوسط

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

الاختيار بين Composer والنماذج الأكبر

قاعدة عملية هي جعل Composer افتراضيًا والارتقاء عندما تُظهر المهمة علامات الحاجة إلى تفكير أعمق. اختر Composer عندما:

• تكون المهمة محدّدة جيدًا: تعرف الملفات، والنمط المتّبع، وتعريف الإنجاز.
• تكرّر بسرعة وتتوقّع عدة جولات صغيرة من التعديلات.
• تنفّذ صيانة روتينية: تحديثات الاعتماديات، وإعادة التسمية، وإعادة هيكلة مدفوعة بالتنسيق.
• تُجمّع مهامًا صغيرة مستقلة كثيرة، حيث تتراكم التكلفة سريعًا.

توجّه إلى نموذج من فئة Claude أو GPT عندما:

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

ارتقِ في منتصف المهمة بدلًا من إعادة البدء

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

نصائح المطالبات للنماذج الصغيرة السريعة

النماذج السريعة تكافئ الدقة. يستجيب Composer بشكل أفضل بوضوح عندما تزيل مطالباتك التخمين، لأن كل تخمين لا يضطر إلى القيام به هو زمن استجابة ورموز موفّرة.

اتبع هذه العادات:

• سمِّ الملفات والمجلدات مقدّمًا. النماذج السريعة تخطّط أقل اتساعًا، فتوجيهها فورًا إلى منطقة السطح الصحيحة يُبقيها على المسار.
• اذكر تعريف الإنجاز. قل ما الاختبارات التي يجب أن تنجح، وما الأمر الذي يجب أن يُشغَّل، أو ما السلوك الذي يجب أن يتغيّر.
• هدف واحد لكل مطالبة. قسّم الطلبات متعددة الأهداف إلى مطالبات متتابعة؛ فحلقة الوكيل تتعامل مع سلاسل الأهداف الصغيرة أفضل بكثير من هدف واحد متشعّب.
• اربط بالأنماط الموجودة. أشِر إلى ملف ينفّذ بالفعل النمط الذي تريده واطلب من النموذج اتباعه.
• حدّد نطاق التأثير. قل صراحةً ما لا يجب لمسه، مثل «لا تعدّل واجهة UserService العامة».

المطالبة جيدة التشكيل لـ Composer تبدو هكذا:

In src/services/, add retry logic to the StripeClient class.
Follow the existing retry pattern in src/services/GithubClient.ts
(exponential backoff, max 3 attempts, logs via the shared logger).

Requirements:
- Only src/services/StripeClient.ts and its test file may change.
- Add unit tests mirroring GithubClient.test.ts.
- `npm test -- stripe` must pass when you are done.

Do not modify the public constructor signature.

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

تحسين المطالبات لنموذج سريع

تغطّي العادات أعلاه الأساسيات؛ يتعمّق هذا القسم أكثر في تشكيل عمل النموذج السريع ليَنجح من المحاولة الأولى.

افعل ولا تفعل

افعل	لا تفعل
سمِّ الملفات والمجلدات بالتحديد	اطلب من النموذج أن «يجد أين يوجد X» في المستودع كله
اذكر تعريف الإنجاز	اترك معايير النجاح ضمنية
أعطِ هدفًا واحدًا لكل مطالبة	اجمع عدة أهداف غير مترابطة في مطالبة واحدة
أشِر إلى نمط موجود لنسخه	صِف نمطًا جديدًا تمامًا بالسرد وحده
اسرد ما لا يجب أن يتغيّر	افترض أن النموذج سيستنتج نطاق التأثير
اطلب خطوة تحقّق	تجاهل الاختبارات وثِق بالفرق بالنظر

مطالبة جيدة مقابل مطالبة سيئة

المطالبة المنتشرة تميل إلى إنتاج تعديل منتشر:

Clean up the auth code and make it better.

المطالبة محدّدة النطاق تمنح النموذج السريع كل ما يحتاجه للوصول من محاولة واحدة:

In src/auth/session.ts, extract the token-refresh logic into a
private method refreshToken() and call it from getSession().

Constraints:
- Only src/auth/session.ts and src/auth/session.test.ts may change.
- Keep the public exports of the module identical.
- Mirror the structure of src/auth/oauth.ts, which already does this.
- `npm test -- auth` must pass.

Report the test output when done.

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

تقطيع المهام إلى خطوات صغيرة

قسّم الأهداف الأكبر إلى تسلسل قصير ودع حلقة الوكيل تحمل كل خطوة:

1. خطّط: اطلب خطة مكتوبة وأكّدها قبل أي تعديلات.
2. نفّذ: ملف واحد أو وحدة واحدة لكل مطالبة.
3. تحقّق: شغّل الاختبارات أو الأمر ذا الصلة بعد كل خطوة.
4. تابع: انتقل إلى الخطوة التالية فقط بعد أن تصبح السابقة خضراء.

أعطِ مراجع ملفات صريحة

فضّل المسارات والرموز على الأوصاف. «حدّث src/billing/Invoice.ts» أفضل من «حدّث كود الفاتورة». وحين تستطيع، الصق اسم الدالة الدقيق أو مقتطفًا قصيرًا للاتباع، لأن النموذج عندئذٍ يقضي وقتًا أقل في البحث ووقتًا أكثر في التعديل.

اطلب التحقّق

تستفيد النماذج السريعة أكثر عندما تجعل التحقّق صريحًا. اختم المطالبات بسطر مثل «شغّل npm test -- <scope> والصق المخرجات»، أو «أبلغ عن الأوامر الدقيقة التي شغّلتها». هذا يحوّل سرعة الوكيل إلى تقدّم موثوق لا حركة غير متحقَّق منها.

ترميز أعراف الفريق في القواعد

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

---
description: Service layer conventions for fast model edits
globs:
  - "src/services/**/*.ts"
alwaysApply: false
---

- Follow the client class pattern in src/services/GithubClient.ts.
- All network calls use the shared http client; never import axios directly.
- Every public method needs a unit test in the matching .test.ts file.
- Prefer early returns; keep methods under 40 lines.
- After edits, run `npm test -- <affected-scope>` and report results.

ومع قواعد كهذه في مكانها، يمكنك إطلاق مطالبات قصيرة على Composer وتثق بأن المعايير المتكرّرة مفروضة دون إعادة ذكرها في كل مرة.

استخدام Composer في الوكلاء في الخلفية

يعمل الوكلاء في الخلفية على تشغيل وكيل Cursor عن بُعد على مستودعك بينما تفعل شيئًا آخر، ويُبلّغون عائدين بفرق أو طلب سحب. غالبًا ما يكون Composer أفضل افتراضي هناك لسببين:

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

من مهام الخلفية الجيدة لـ Composer كتابة الاختبارات الناقصة لوحدة، وتطبيق إعادة هيكلة آلية عبر حزمة، وتوليد هيكل توثيق، وإصلاح مشكلات مباشرة مسحوبة من متعقّب. أما المهام التي تتطلب أحكامًا عبر النظام كله، ابدأ الوكيل الخلفي بنموذج من فئة Claude أو GPT، أو ابدأ بمرحلة تخطيط في محرّرك في المقدمة وسلّم Composer خطة دقيقة.

اكتب مطالبات الخلفية كتكلة

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

Composer في الوكلاء في الخلفية

الوكلاء في الخلفية حيث تتراكم مزايا تكلفة وسرعة Composer، لأنك لا تجلس تراقب كل خطوة. التفويض الجيد يتطلّب بعض الانضباط.

تفويض المهام الطويلة

مطالبة التفويض الجيدة مكتفية ذاتيًا وبشكل تكلة:

Goal: add unit tests for every public method in src/services/Billing.ts.

Context: follow the testing style in src/services/Billing.test.ts if it
exists; otherwise mirror src/services/GithubClient.test.ts.

Scope: only create or edit test files under src/services/. Do not change
production code. If a method looks untestable as written, note it in the
final summary instead of refactoring.

Verify: `npm test -- services/Billing` must pass. Report the output.

اختيار النطاق

• أبقِ مهمة الخلفية في حزمة واحدة أو وحدة واحدة أو شأن واحد. المهام العريضة تنزلق.
• فضّل التغييرات الآلية لعمليات الخلفية: إعادة التسمية، وتغطية الاختبارات، وهياكل التوثيق، وسكربتات الترحيل.
• تجنّب المهام المتعلّقة بالذوق أو الحكم المعماري؛ ابدأ تلك في جلسة مقدّمة حيث يمكنك التوجيه.

مراجعة الفرق

يعيد الوكلاء في الخلفية فرقًا أو طلب سحب، فراجعه كعمل عضو فريق:

1. تحقّق من الملفات الملموسة مقابل النطاق الذي حدّدته. أي شيء خارج النطاق إشارة إلى النظر عن قرب.
2. اقرأ ملخّص الوكيل لِما يدّعي فعله، ثم تحقّق من ادّعاء واحد على الأقل في الكود.
3. شغّل الاختبارات محليًا أو أكّد المخرجات المُبلّغ عنها قبل الدمج.
4. إذا كان الفرق صحيحًا في معظمه لكن فيه بعض الحواف الخشنة، أصلحه في المحرّر بدلًا من إعادة تشغيل الوكيل كله؛ فإعادة التشغيل قد تغيّر أسطرًا غير ذات صلة.

الفروق الخلفية غير المراجَعة عبء

لأن Composer يتحرّك سريعًا، قد ينتج فرقًا كبيرًا بسرعة. سرعة الإنتاج ليست سرعة الصحة. عامل كل نتيجة خلفية كمقترح حتى تتحقّق من الاختبارات والنطاق، وخصّص وقتًا للمراجعة لا للتشغيل فقط.

خصائص التكلفة والاستخدام

Composer من أكثر الطرق كفاءةً في السعر لاستهلاك خطة Cursor. تأثيرات عملية:

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

إذا راقبت الاستخدام في لوحة التحكم، سترى الفرق بوضوح بعد أسبوع من جعل Composer افتراضيًا: نفس حجم المهام المكتملة يقع على حصة أقل ملحوظًا من كوتتك. استراتيجية شائعة هي إنفاق كوتة النماذج المتقدّمة فقط حيث تشتري جودة تفكير حقيقية وترك Composer يمتصّ الحجم الروتيني.

ما يُحسب نحو حدودك

تُحسب طلبات Chat وAgent، وتعديلات Cmd-K، وتشغيلات الوكلاء في الخلفية كلها نحو خطتك، مُقاسة لكل طلب. أما إكمالات Tab فتُعالَج عمومًا بشكل منفصل، وقراءة الملفات أو تشغيل الأوامر لا تُفوتر بحد ذاتها؛ فالتكلفة مدفوعة بالدورات النموذجية التي تستدعيها.

التكلفة والسرعة والجودة النسبية

الجدول أدناه مقارنة تقريبية لمساعدتك على الاختيار، لا معيار قياس. قد تتغيّر الترتيبات بين إصدارات النماذج وحسب مزيج مهامك.

النموذج	السرعة النسبية (تقريبًا)	التكلفة النسبية (تقريبًا)	عمق التفكير النسبي (تقريبًا)
Composer	الأسرع	الأدنى	جيد
Claude Sonnet	متوسط	أعلى	قوي
Claude Opus	الأبطأ	الأعلى	الأقوى
نماذج عائلة GPT	متوسط	عالٍ إلى متوسط	قوي
نماذج Gemini	متوسط إلى سريع	متوسط	قوي

اقرأ الجدول كأنه «يفوز Composer في السرعة والتكلفة؛ وتفوز النماذج المتقدّمة في تفكير الذروة». تستقرّ معظم الفرق على جعل Composer افتراضيًا والارتقاء عمدًا، لا العكس.

الجمع بين Composer ونماذج أخرى

سير العمل الأقوى ليس «اختر نموذجًا واحدًا للأبد»؛ بل توجيه كل مرحلة من المهمة إلى النموذج الذي يناسبها.

1. خطّط بنموذج تفكير. ابدأ بنموذج من فئة Claude أو GPT واطلب خطة فقط: ما الملفات التي تُلمس، وبأي ترتيب، وكيف يتم التحقّق. لا تعدّل بعد.
2. نفّذ بـ Composer. بمجرد كتابة الخطة وموافقتك عليها، بدّل النموذج إلى Composer للتعديلات الفعلية. نموذج سريع بخطة واضحة يتفوّق على نموذج سريع يكتشف الخطة أثناء المضيّ.
3. راجع بنموذج ثانٍ. بعد أن تُطبَّق التعديلات، بدّل إلى نموذج مختلف واطلب منه مراجعة الفرق للصحة والحالات الحدّية والمتطلبات المفقودة. نموذج جديد يقرأ النتيجة يلتقط أشياء برّرها النموذج المنفّذ.

Phase 1 (Claude/GPT, plan only):
"Read src/payments/ and propose a step-by-step plan to add idempotency
keys to the charge endpoint. List files, order, and verification. Do not edit."

Phase 2 (Composer, execute):
"Implement step 1 from the plan. Only src/payments/charge.ts may change.
Run `npm test -- payments` and report output."

Phase 3 (second model, review):
"Review this diff for correctness and edge cases. Flag anything that
breaks idempotency under retries."

تُبقي حلقة الخطّط-نفّذ-راجع الاستدعاءات المكلفة العميقة التفكير صغيرة ومركّزة، بينما يمتصّ Composer حجم التعديل الفعلي.

نفس السياق، نموذج مختلف

تبديل النماذج في منتصف المهمة يُبقي الدردشة والملفات المفتوحة والخطة سليمة، فالتسليم بين المراحل لا يكلّف شيئًا. لا تحتاج إلى إعادة شرح المهمة؛ غيّر المنتقي فحسب وتابع.

الطريق إلى الأمام: Composer 3

خط Composer قيد التطوير النشط، وخارطة الطريق المجتمعية مليئة بالفعل بطلبات لإصدار تالٍ، يُشار إليه غالبًا باسم Composer 3. تشمل الموضوعات المتكرّرة في تلك المناقشة تخطيطًا أقوى للأفق الطويل، وأداءً أفضل على المستودعات الكبيرة جدًا، وموثوقية أعلى في المهام متعددة الخطوات الغامضة، مع الإبقاء على زمن الاستجابة المنخفض والتكلفة المنخفضة المميّزين.

لا تحتاج إلى انتظار أي من ذلك لتستفيد اليوم. نماذج Composer الحالية محرّكات يومية بجودة إنتاجية، ولأن اختيار النموذج قائمة منسدلة لا التزامًا، يمكنك تبنّيها الآن والتبديل فور وصول جيل أحدث إلى المنتقي.

مشكلات وقيود شائعة

Composer سريع، وللسرعة أنماط فشل ينبغي أن تتعرف عليها مبكرًا.

إجراء تعديلات واسعة كبيرة

قد يحاول Composer تغييرًا على مستوى المستودع كله دفعة واحدة ويترك فرقًا متشعّبًا صعب المراجعة.

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

فقدان التعليمات في المهام الطويلة

على مدى جلسة طويلة، قد تتلاشى القيود السابقة مع نموّ السياق.

• السبب: دورات كثيرة بأهداف متغيّرة في دردشة واحدة.
• الإصلاح: أعد ذكر القيود الحرجة عند تغيير الاتجاه، أو ابدأ دردشة جديدة بملخّص مختصر للهدف والقواعد. ملفات القواعد في .cursor/rules تساعد أيضًا في تثبيت الأعراف عبر الجلسة.

واجهات برمجية مُتوهَّمة

تشير النماذج السريعة أحيانًا إلى دوال أو حزم غير موجودة.

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

الحاجة إلى إعادة هيكلة قاعدة الكود كاملة

بعض عمليات إعادة الهيكلة تمتد فعلًا عبر النظام كله وتتجاوز ما يتعامل معه نموذج سريع جيدًا من محاولة واحدة.

• السبب: التغيير له اعتماديات متقاطعة وحدود غامضة.
• الإصلاح: خطّط له بنموذج تفكير أولًا، ثم نفّذه كسلسلة خطوات Composer محدّدة النطاق، مع التحقّق بعد كل خطوة. فكّر في وكيل خلفي واحد لكل حزمة بدلًا من تشغيل عملاق واحد.

المهلات أو التعطّلات

أحيانًا تتعطّل تشغيلة وكيل أو تنتهي مهلتها، خاصةً في المهام الكبيرة جدًا.

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

من العرض إلى السبب إلى الإصلاح

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

الأسئلة الشائعة

هل Composer هو نفسه ميزة Composer لعام 2024؟

لا. «Composer» لعام 2024 كان سير عمل لتحرير عدة ملفات في واجهة Cursor، ثم دُمج في وضع Agent. أما Composer في هذا الدليل فهو نموذج، يُختار من نفس المنتقي الذي يُختار منه Claude وGPT.

على أي نموذج يعمل Composer؟

Composer خط نماذج Cursor الداخلي، درّبه فريق Cursor بدلًا من توجيهه إلى طرف ثالث. وسرعته وصورة تكلفته تأتيان من ذلك التركيز لا من نموذج أساسي عام الغرض.

متى ينبغي أن أختار Composer بدلًا من Claude أو GPT؟

اجعل Composer افتراضيًا للعمل محدّد جيدًا والسريع والتكراري. وارتقِ عندما تكون مهمة غامضة أو تمتد عبر وحدات مترابطة كثيرة أو تحتاج تفكيرًا عميقًا على مستوى المعمارية.

هل هو جيد بما يكفي لعمل إنتاجي حقيقي؟

نعم، لغالبية كبيرة من المهام اليومية: تنفيذ مكوّنات محدّدة، وإصلاح الاختبارات، وإعادات الهيكلة الآلية، والصيانة الروتينية. وللتفكير عالي المخاطر، اقرنه بنموذج متقدّم باستخدام سير العمل خطّط-نفّذ-راجع.

هل يكلّف مبلغًا إضافيًا؟

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

هل يمكنني تبديل النماذج في منتصف المهمة؟

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

لماذا تتعطّل تعديلاتي أو تلاحق ذيلها؟

عادةً لأن المهمة كانت عريضة أكثر من اللازم لمرور واحد. ضيّق النطاق، وأعطِ ملفات صريحة، وتحقّق بعد كل خطوة بدلًا من توقّع أن تفعل مطالبة واحدة كل شيء.

هل سيكون هناك Composer 3؟

تشير المناقشة المجتمعية إلى جيل تالٍ بتخطيط أقوى للأفق الطويل وأداء على المستودعات الكبيرة. لا تحتاج إلى الانتظار؛ فاختيار النموذج قائمة منسدلة، فيمكنك تبنّي إصدار أحدث يوم يظهر.

مرجع سريع

السؤال	الإجابة
ما هو Composer؟	نموذج Cursor الداخلي المحسّن للسرعة للبرمجة الوكيلية
أين أختاره؟	منتقي النماذج في Chat ووضع Agent، أو Settings > Models
متى لا ينبغي أن أستخدمه؟	مهام التفكير العميق والغامضة والثقيلة معمارياً
هل هو ميزة Composer القديمة؟	لا، أداة 2024 متعددة الملفات دُمجت في وضع Agent
هل يعمل في الوكلاء في الخلفية؟	نعم، وهو افتراضي فعّال من حيث التكلفة هناك
ما التالي؟	مناقشة مجتمعية لجيل Composer 3

يكافئ Composer سير عمل بسيطًا: اجعله افتراضيًا، واكتب مطالبات دقيقة، ورمّز أعرافك في قواعد، وارتقِ إلى النماذج المتقدّمة فقط عندما تحتاج مهمة فعلًا إلى تفكير أعمق. تلك العادة تمنحك مزايا السرعة والتكلفة من خط نماذج Cursor الخاص دون التخلي عن الجودة حيث تهمّ.