Cursor AI: كيف تنقل Cursor Projects فرق البرمجة إلى طابور المراجعة

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

هذا شرح تشغيلي موجّه إلى قادة الفرق الهندسية والمؤسسين التقنيين وأصحاب الوكالات. والسؤال المفيد هنا ليس عدد الوكلاء الذين يستطيع Cursor تشغيلهم، بل قدرة الفريق على استيعاب العمل العائد منهم من دون فقدان السيطرة على التكلفة أو الجودة.

كيف تعمل Cursor Projects داخل Cursor AI؟

يمثل Cursor Project حاوية مستمرة لحزمة من العمل، مثل ميزة أو عملية ترحيل أو تطبيق كامل. ويضم وكيلًا منسقًا يؤدي دور المدير في هذا الإعداد؛ فهو يخطط للعمل ويفوض التنفيذ، لكنه لا يكتب الكود بنفسه.

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

أما العنصر الثاني فهو السياق المشترك. يحتفظ كل Project بملفات تتزامن بين الأجهزة السحابية والمحلية التي يستخدمها وكلاؤه. ويمكن أن تجمع هذه الملفات الأبحاث والمخرجات والمعرفة بقاعدة الكود وتعليمات الاختبار والملاحظات التي تحدد أسلوب العمل المطلوب من الفريق.

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

والعنصر الثالث هو الاشتراكات. يمكن توجيه Project لمراقبة قناة Slack، أو العمل وفق جدول زمني، أو متابعة طلبات السحب. وعند وصول إشارة مطابقة، يبدأ عمل مفوض جديد من دون أن يكتب أحد موجّهًا جديدًا.

فكرة الوكلاء المتكررين نفسها ليست جديدة على Cursor؛ إذ أتاح إصدار 19 أغسطس لوكلاء Cloud Agents مراقبة طلبات السحب وسلاسل Slack والجداول الزمنية. الجديد في Projects هو وضع ذلك العمل المتكرر تحت إدارة منسق واحد، وبسياق مشترك يستمر عبر تدفق أطول من المهام.

هذه هي قيمة الإصدار الحقيقية. لا يقدم Cursor محادثة برمجية أخرى فحسب، بل يمنح العمل المفوض مساحة دائمة.

لماذا ينقل وكلاء البرمجة بالذكاء الاصطناعي نقطة الاختناق إلى المراجعة؟

قد يقلل السياق المشترك وقت الإعداد المتكرر. لكن Cursor لم ينشر رقمًا لمقدار التسريع، كما أن هذا الإصدار التجريبي أحدث من أن يبرر تقديرًا كهذا؛ لذلك لا تضع ساعات موفّرة في الميزانية بعد.

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

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

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

من يستفيد منه، وما الذي يتغير عمليًا؟

قائد فريق هندسي في SaaS يدير عملية ترحيل

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

العائد هنا هو الاستمرارية عبر عدة فروع. وينبغي للقائد قياس التغييرات المقبولة ووقت المراجعة، لا نشاط الوكلاء.

مدير تقني في وكالة يدير أعمال العملاء

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

العائد هو تقليل الشرح المتكرر. أما الحد الصارم فهو الفصل بين العملاء: يجب ألا يتحول سياق أحد الحسابات وبيانات اعتماده إلى مخزون مشترك مع حساب آخر.

مدير هندسة دعم يراقب بلاغات الأعطال

اربط قناة عامة واحدة في Slack مخصصة لبلاغات الأعطال، واستخدم قاعدة تأهيل ضيقة. يمكن للبلاغ المرفق بخطوات قابلة لإعادة الإنتاج أن يدخل Project، فيما تبقى الأسئلة والبلاغات المكررة والحوادث الخاصة بحساب بعينه لدى شخص مسؤول.

العائد هو فرع مجهز وأدلة جاهزة للمراجعة، وليس دمجًا تلقائيًا. تحصر وثائق Automations الحالية في Cursor مشغلات Slack في القنوات العامة، كما أن إعلان Projects لا ينشر مصفوفة منفصلة للقنوات المدعومة.

فريق منصة يتولى صيانة متكررة

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

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

كيف تشغّل تجربة محدودة لأتمتة البرمجة بالذكاء الاصطناعي؟

لم ينشر Cursor واجهة API لـProjects ولا دليل إعداد تفصيليًا لها. لذلك تعتمد التجربة الواقعية على واجهة الإصدار التجريبي الظاهرة حاليًا، وعلى ضوابط Cloud Agents ذات الصلة والموثقة اليوم.

1. 1

   تحقق من الإتاحة والفوترة

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

2. 2

   اختر عملًا واحدًا قابلًا للتكرار

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

3. 3

   اكتب سياق التشغيل المشترك

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

4. 4

   أضف مسار استقبال واحدًا

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

5. 5

   عيّن مسؤولًا عن طابور المراجعة

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

6. 6

   قس العمل الذي يجتاز المراجعة

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

احسب تكلفة التجربة مع وقت المراجعة

يسهل تحديد تكلفة الخطة الأساسية. تبلغ كلفة Teams Standard $40 لكل مستخدم شهريًا، أي إن أربعة مقاعد جديدة تكلف $160 لدورة فوترة واحدة. أما Teams Premium فتبلغ كلفتها $120 لكل مستخدم شهريًا، وتتضمن خمسة أضعاف استخدام Standard، لكن شراء Premium قبل أن تنتج التجربة بيانات الاستخدام الخاصة بها يتجاوز الجزء المفيد من الاختبار.

بند التكلفة المتغيرة أصعب. تُحاسب Cloud Agents وفق أسعار API للنموذج المختار. وتضيف خطتا Teams وEnterprise رسم Cursor Token Rate قدره $0.25 لكل مليون توكن مؤهل من توكنات الإدخال والإخراج والتخزين المؤقت التابعة لجهات خارجية. ويكون الاستخدام عند الطلب مفعّلًا افتراضيًا في Teams، مع إمكانية تحديد مسؤولي الفريق سقفًا شهريًا للإنفاق على مستوى الفريق.

في ما يلي نموذج محدود، مع توصيف كل رقم متعلق بحجم العمل بوضوح على أنه افتراض:

• افتراض النطاق: مستودع واحد، ومشغّل واحد، وبحد أقصى 20 عنصر عمل تصل إلى المراجعة.
• افتراض الاستخدام: يستهلك كل عنصر عمل مكتمل، بما في ذلك نشاط المنسق ووكلاء التنفيذ، 100,000 توكن إدخال غير مخزن مؤقتًا، و400,000 توكن قراءة من الذاكرة المؤقتة، و20,000 توكن إخراج على Claude Sonnet 5، من دون توكنات كتابة إلى الذاكرة المؤقتة.
• افتراض المراجعة: يخصص مراجع خبير 20 دقيقة لكل عنصر عائد، بتكلفة شاملة قدرها $100 في الساعة.

وفق أسعار Claude Sonnet 5 الحالية لدى Cursor، تبلغ تكلفة عنصر العمل المفترض $0.20 للإدخال، و$0.08 للقراءة من الذاكرة المؤقتة، و$0.20 للإخراج. ويضيف رسم التوكن في Teams مبلغ $0.13 على إجمالي 520,000 توكن مؤهل. بذلك تصبح تكلفة الاستخدام المفترضة $0.61 لكل عنصر، أو $12.20 مقابل 20 عنصرًا.

المراجعة هي البند الأكبر. يتطلب عشرون عنصرًا، بواقع 20 دقيقة لكل منها، حجز 400 دقيقة، أي 6 ساعات و40 دقيقة. ومع التكلفة المفترضة البالغة $100 في الساعة، يصل وقت المراجع إلى $666.67.

أضف $160 لأربعة مقاعد Standard جديدة، ومع احتساب الاستخدام المفترض سواء أصبح تكلفة زائدة أم لا، يكون إجمالي التخطيط الأولي للشهر $838.87. وهذا ليس توقعًا للفاتورة؛ فالمقاعد الحالية تلغي شراء $160، وقد يغطي الاستخدام المشمول مبلغ $12.20، كما قد تستهلك أعمال Projects الحقيقية توكنات أكثر لأن المنسق يستطيع التفويض إلى عدة وكلاء.

لا يفترض هذا النموذج أن تكلفة المراجعة ستكون دائمًا $666.67؛ والمقصود أن وقت المراجعة يحتاج إلى بند مستقل في الميزانية. عدّل عدد المهام والدقائق والتكلفة الشاملة بما يلائم فريقك قبل وصف التجربة بأنها زهيدة.

ولمن يريد تقييم المنتج والاشتراك على نطاق أوسع، تغطي مراجعة Cursor الرئيسية المحرر وCloud Agents والأسعار وبوابات المراجعة الحالية.

الصورة بلا تجميل

أولًا، هذا طرح تجريبي وليس معيار تشغيل مستقرًا. يذكر الإعلان شريط التنقل الأيسر، لكنه لا يقدم مصفوفة إتاحة خاصة بـProjects، ولا تفصيلًا للاستخدام، ولا تحكمًا في التوازي، ولا التزامًا بالخدمة. فقد تصل الميزة قبل الوثائق اللازمة للشراء المؤسسي.

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

ثالثًا، يعيد المنسق العمل لتراجعه أنت؛ فهذا جزء من عقد المنتج. ولا يلغي المراجعة البشرية أو الاختبارات القابلة للتنفيذ أو فحوص الأمان أو مسؤولية الدمج.

رابعًا، تظل البيئة هي العامل الذي يحدد قدرة الوكيل على إثبات عمله. تحتاج Cloud Agents إلى المستودعات والتبعيات والأسرار وأوامر التشغيل والوصول إلى الشبكة التي تتطلبها المهمة. وإذا فشلت عملية Build للبيئة، تظل آخر عملية Build ناجحة فعالة، لكن البيئة غير المكتملة قد تنتج كودًا مقنعًا من دون دليل صالح.

وأخيرًا، يعمل كل Project على جهاز سحابي، مع استخدام وكلاء محليين عندما يلزم اختبار مرتبط بجهاز بعينه. ينبغي للفرق ذات متطلبات الشبكات الخاصة إدراج هذه الحدود في مراجعتها. تستطيع Cursor Self-Hosted Machines نقل تنفيذ الأدوات إلى أجهزة يديرها العميل، لكن حلقة وكيل Cursor ومعالجة النموذج تظلان في سحابة Cursor.

ما الخطوة المناسبة الآن؟

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

انتظر إذا لم تظهر Projects، أو تعذر على المستودع تشغيل فحوصه في بيئة Cloud Agent، أو لم يتولَّ أحد مسؤولية المراجعة. وانتظر كذلك إذا كانت المشتريات تتطلب وثيقة خاصة بإتاحة Projects أو فوترة لم ينشرها Cursor.

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

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

احصل على التحليل التالي لسير عمل الذكاء الاصطناعي الموجّه للمشغّلين عبر النشرة البريدية.