يرغب Cursor الآن في استضافة الكود الخاص بك، وليس فقط كتابته. في 17 أغسطس 2026، بدأت الشركة في طرح Origin، خدمة استضافة Git الخاصة بها، في مرحلة بيتا المبكرة لجميع الخطط المدفوعة. تم إطلاق المستودعات، طلبات السحب، تصفح الكود، والمزامنة ثنائية الاتجاه مع GitHub في اليوم الأول، وكل ذلك يعيش في علامة تبويب جديدة "قاعدة الكود" (Codebase) داخل المحرر.
الفكرة واضحة: تم تصميم منصات Git للأشخاص الذين يدفعون التغييرات (commits) بضع مرات يوميًا، ويراهن Cursor على أن العقد القادم للتحكم في الإصدار سيتشكل بواسطة الوكلاء (agents) الذين يفتحون الفروع، ويحدثون طلبات السحب (PRs)، ويدمجون العمل على مدار الساعة. Origin هي أول منصة استضافة مصممة حول هذا الافتراض منذ البداية.
إذا كان فريقك يبني واجهات برمجة تطبيقات (APIs)، فإن هذا يمسك عاجلاً مما تتخيل: مواصفات OpenAPI الخاصة بك، واختبارات العقود القائمة على التكامل المستمر (CI)، وسير عمل المراجعة الخاص بك كلها موجودة أينما تشير نقطة Git البعيدة الخاصة بك. إليك ما يفعله Origin اليوم، وما الذي ينقصه، وكيفية الحفاظ على سير عمل واجهة برمجة التطبيقات (بما في ذلك أتمتة اختبار Apidog) سليماً إذا جربته.
ما هو Origin
Origin هو منصة Git سحابية تديرها Cursor. تشمل النسخة التجريبية الأولية:
- مستودعات مستضافة تقوم بإنشائها من علامة تبويب Codebase، أو من الويب على
cursor.com/codebase، أو من وكيل Cursor أثناء مهمة. تتبع المستودعات البعيدة النمطhttps://cursor.com/codebase/{owner}/{repo}، وتعمل أوامرgit cloneوpushوpullالقياسية عليها. - طلبات السحب (Pull requests) مع الأجزاء التي تتوقعها: جدول زمني، التزامات (commits)، فحوصات، فروقات، تعليقات، ودمج، قابلة للمراجعة داخل المحرر أو في المتصفح.
- تصفح الكود والبحث على الويب، مع إعدادات على مستوى المستودع وعلى مستوى قاعدة الكود.
- واجهة سطر أوامر مخصصة (CLI) لسير عمل الطرفية، منفصلة عن المحرر.
- تكامل الوكيل (Agent)، وهي النقطة الأساسية: يمكن للوكلاء قراءة قاعدة الكود، والإجابة على الأسئلة المتعلقة بها، وإجراء التغييرات، وتحديث طلبات السحب، ودفع الفروع من نفس الواجهة التي تراجع فيها عملهم. وفقًا لسجل التغييرات، ستتوفر المزيد من "الميزات الأصلية للوكيل" قريبًا.
التوفر: خطط Pro و Teams و Enterprise فقط. لا يمكن لمستخدمي الخطط المجانية إنشاء مستودعات Origin، ويمكن للمؤسسات الكبرى الانسحاب تمامًا. تفاصيل مثل حصص التخزين، واجهة برمجة التطبيقات العامة (API)، وخطافات الويب (webhooks) لم يتم توثيقها بعد، وهو ما يستحق التذكر قبل نقل أي شيء مهم. راجع وثائق Origin من Cursor للحالة الحالية.
يُنهي Origin شهرًا حافلاً للشركة؛ تغطية صحفية، بما في ذلك تقرير SiliconANGLE، تشير أيضًا إلى أن الإطلاق جاء بعد أيام من إكمال SpaceX استحواذها على Cursor. للاطلاع على جانب المحرر من المنتج، يغطي دليل Cursor الشامل الخاص بنا الأساسيات.
مزامنة GitHub هي الجزء الذكي
لا يمكن لأحد ترحيل شركة من GitHub في عطلة نهاية الأسبوع، و Cursor تدرك ذلك. لذا تعتمد نسخة Origin التجريبية على مزامنة ثنائية الاتجاه بدلاً من الترحيل:
- اعكس مستودع GitHub في Origin، وستتحدث المستودعات المتزامنة في الوقت الفعلي.
- تتم مزامنة تعليقات وتفاعلات طلبات السحب (PRs) في كلا الاتجاهين في غضون ثوانٍ: تعليق يُترك في Cursor يُنشر على GitHub، ورد GitHub يظهر في Cursor.
- يبقى GitHub هو مصدر الحقيقة لأي مستودع بدأ هناك. تستمر الدفعات (Pushes) في التدفق إلى GitHub؛ Origin هو مرآة حية مع قصة وكيل (agent) أفضل، وليس بديلًا بعيدًا.
- تُعكس أذونات الوصول إعدادات القراءة/الكتابة الخاصة بك في GitHub، لذا لا توسع المزامنة بهدوء من يمكنه الوصول إلى مستودع.
هذا هو نفس نمط التبني منخفض الالتزام الذي نجح مع Cursor مقابل VS Code: لا تطلب من أحد المغادرة، اجلس جنبًا إلى جنب مع الموجود، ودع سير العمل الجديد يفوز بالراحة. يمكنك تجربة واجهة مستخدم مراجعة طلبات السحب (PR) في Origin يوم الاثنين دون إخبار فريق المنصة الخاص بك، لأنه لا يتغير شيء في إعداد GitHub الخاص بك.
السياق الاستراتيجي الضمني أصعب تجاهله. كان GitHub هو المنزل الافتراضي للكود لمدة خمسة عشر عامًا، وتمر قصة الذكاء الاصطناعي الخاصة به عبر Copilot، الذي يتنافس مباشرة مع Cursor؛ قارنا الاثنين في Cursor vs GitHub Copilot. قيام Cursor ببناء منصة خاصة بها هو تصريح بأنها لم تعد ترغب في أن تكون خريطة طريق وكيلها (agent roadmap) مقيدة بمنصة منافس.
ما الذي ينقص (وهو كثير، في الوقت الحالي)
النسخة التجريبية هي منصة، وليست منصة DevOps كاملة. حتى تاريخ الإطلاق، يحتوي Origin على:
- لا يوجد CI/CD أصلي. بدلاً من ذلك، يتصل Depot و Buildkite عبر علامة تبويب التطبيقات في المستودع ويمكنهما تشغيل ملفات سير عمل GitHub Actions الموجودة لديك مقابل مستودعات Origin. إنه جسر عملي، لكنه اعتماد على طرف ثالث حيث يمتلك GitHub منتجًا مدمجًا.
- لا توجد مشاكل، لا مناقشات، لا ويكي. مراجعة الكود هي العنصر التعاوني الوحيد.
- لا استضافة ذاتية، لا واجهة برمجة تطبيقات عامة موثقة، لا خطافات ويب، لا حدود تخزين معلنة.
- شريك إطلاق بارز واحد: اربط Vercel من علامة تبويب التطبيقات، ويحصل كل طلب سحب (PR) على نشر معاينة ينتقل إلى الإنتاج عند الدمج، وهو نفس سير العمل الذي يديره Vercel لمستودعات GitHub. (كان Vercel يطلق المنتجات بسرعة مؤخرًا؛ وهي نفس البوابة التي تشغل حاليًا خصم GPT-5.6 Sol.)
لا تهم أي من هذه الثغرات كثيرًا طالما بقي GitHub هو مصدر الحقيقة خلف المزامنة. لكنها تهم بشكل كبير في اليوم الذي يفكر فيه الفريق في جعل Origin هو الأساسي. تعامل مع النسخة التجريبية كطبقة للمراجعة والوكلاء، وليس كبنية تحتية.
ماذا يعني هذا لفرق واجهات برمجة التطبيقات (API) على وجه التحديد
ربما يمس سير عمل واجهة برمجة التطبيقات (API) الخاص بك المنصة في ثلاثة أماكن: تعيش المواصفات في المستودع، وتُجرى اختبارات العقود في CI على كل طلب سحب (PR)، ويوافق المراجعون على التغييرات لكليهما. إليك كيفية ارتباط كل منها بـ Origin اليوم.
المواصفات ومراجعة التصميم. إذا اتبعت سير عمل يعتمد على التصميم أولاً، فإن ملف OpenAPI الخاص بك هو العنصر الأكثر مراجعة في المستودع. تتعامل فروقات طلبات السحب (PR diffs) في Origin مع YAML مثل أي نص آخر، وتعني مزامنة التعليقات ثنائية الاتجاه أن مراجع واجهة برمجة التطبيقات المقيم في GitHub ومشغل الوكيل المقيم في Cursor يرى نفس سلسلة المحادثات. لا يوجد شيء يتعطل، ولا شيء يتحسن بعد؛ يصل الجزء المثير للاهتمام عندما يبدأ الوكلاء في اقتراح تغييرات على المواصفات كطلبات سحب (PRs)، وهو بالضبط الحلقة التي بُني Origin من أجلها. يغطي دليلنا حول تشغيل Apidog CLI داخل Cursor بالفعل السماح لوكيل المحرر بالتحقق من صحة المواصفات قبل الالتزام بها.
اختبار عقود التكامل المستمر (CI). يعمل Apidog CLI كخطوة في أي نظام تكامل مستمر (CI)، وإجابة Origin على CI هي "أحضر سير عمل GitHub Actions الخاص بك عبر Depot أو Buildkite". في الممارسة العملية، هذا يعني أن خطوة سير العمل الحالية مثل apidog run --scenario smoke-tests يجب أن تنتقل دون تعديل، لأن تنسيق ملف سير العمل هو نفسه. تحذير صريح: لم نتحقق من طبقة توافق Depot's Actions مع كل إجراء موجود، ولم يفعل أي شخص آخر هذا الأسبوع. قم بتشغيل خط أنابيبك مقابل مستودع تجريبي معكوس قبل الوثوق به بفرع إصدار.
التغييرات التي يقودها الوكيل تحتاج إلى بوابات مقاومة للوكيل. الفرضية الأساسية لـ Origin هي وصول المزيد من الكود من الوكلاء، بشكل أسرع. هذا يرفع من قيمة الفحوصات الآلية والحتمية على كل طلب سحب (PR)، لأن المراجعين البشريين يصبحون عنق الزجاجة. مجموعة اختبارات عقود تفشل البناء عندما ينحرف مخطط الاستجابة هي بالضبط نوع البوابة التي تتناسب مع إنتاجية الوكيل، وهي إعداد يستغرق خمس دقائق في Apidog: حدد تأكيدات ضد مواصفاتك مرة واحدة، وقم بتشغيلها من واجهة سطر الأوامر (CLI) في أي CI ينفذ طلبات سحب Origin الخاصة بك. قم بتنزيل Apidog إذا كنت تريد هذه البوابة قبل أن يحصل وكلاؤك على صلاحية الدفع، واطلع على دليلنا حول اختبار ضمان الجودة مع Cursor للحصول على حلقة الاختبار الأوسع.
هل يجب أن تجربه؟
اختصار قرار:
- المطورون الفرديون والفرق الصغيرة على خطط Cursor المدفوعة: نعم، مخاطر منخفضة. اعكس مستودعًا، استخدم عرض طلبات السحب (PR)، احتفظ بـ GitHub كمصدر للحقيقة. لن تخسر شيئًا إذا لم ينجح Origin.
- الفرق ذات الاستثمار الكبير في GitHub Actions: جربه على مشروع جانبي أولاً. تنتقل سير عملك نظريًا عبر Depot أو Buildkite، لكن "الانتقال النظري" ليس خطة ترحيل.
- أي شخص يذكر GitHub في قصته الامتثالية: انتظر. لا استضافة ذاتية، لا واجهة برمجة تطبيقات موثقة، وعلامة بيتا مبكرة تجعل Origin غير قابل للتطبيق للكود المنظم اليوم.
- الفرق التي تستخدم وكلاء Cursor بالفعل بكثرة: هذا هو الفئة المستهدفة لـ Origin. إذا كنت تستخدم ميزات وكيل Cursor يوميًا، فإن وجود وكلاء يفتحون ويحدثون طلبات السحب (PRs) على منصة تعاملهم كمستخدمين من الدرجة الأولى يعد مكسبًا حقيقيًا لسير العمل في الوقت الحالي.
أصبحت المنصة واجهة للوكلاء
القصة الحقيقية ليست أن GitHub لديه منافس جديد. بل هي أن Cursor تعتقد أن المستودع نفسه على وشك أن يصبح واجهة للوكلاء بشكل أساسي، حيث يقوم البشر بالمراجعة بدلاً من تأليف معظم التغييرات. سواء فاز Origin أم لا، سيتم سحب كل منصة في هذا الاتجاه، وستشعر فرق واجهات برمجة التطبيقات (API) بذلك أولاً، لأن المواصفات واختبارات العقود هي بوابات المراجعة الأكثر قابلية للأتمتة في البرمجيات.
التحضير هو نفسه في كلتا الحالتين: اجعل فحوصات واجهة برمجة التطبيقات الخاصة بك قابلة للبرمجة ومستقلة عن المنصة. يحتفظ Apidog بمواصفاتك، نماذجك (mocks)، وسيناريوهات الاختبار في مكان واحد ويشغلها من واجهة سطر أوامر (CLI) لا تهتم ما إذا كان طلب السحب (PR) جاء من إنسان على GitHub أو وكيل على Origin. جربه مجانًا، وستتحرك بوابات المراجعة معك بغض النظر عمن يفوز في حرب المنصات.
الأسئلة الشائعة
هل Cursor Origin مجاني؟ لا. تتطلب استضافة كود Origin خطة Cursor مدفوعة (Pro، Teams، أو Enterprise). لا يمكن لمستخدمي الخطط المجانية إنشاء مستودعات Origin، ويمكن للمؤسسات الكبرى الانسحاب من Origin بالكامل.
هل يجب علي مغادرة GitHub لاستخدامه؟ لا. يفترض تصميم الإطلاق أنك لن تفعل ذلك: اعكس مستودع GitHub في Origin، ويبقى GitHub هو مصدر الحقيقة، مع مزامنة الدفعات (pushes)، وتعليقات طلبات السحب (PR comments)، والتفاعلات في كلا الاتجاهين في الوقت الفعلي تقريبًا.
هل يمتلك Origin ميزة CI/CD؟ ليس بشكل أصلي. يتصل Depot و Buildkite عبر علامة تبويب التطبيقات ويشغلان ملفات سير عمل GitHub Actions الموجودة لديك. تم دمج Vercel أيضًا لنشر معاينات طلبات السحب (PR).
هل يمكن للوكلاء استخدام Origin مباشرة؟ نعم، هذه هي الميزة الأساسية: يمكن لوكلاء Cursor إنشاء مستودعات، والإجابة على الأسئلة المتعلقة بقاعدة الكود، وتحديث طلبات السحب، ودفع الفروع. تقول Cursor إن المزيد من الميزات الأصلية للوكيل قادمة؛ يغطي دليل وضع وكيل Cursor الخاص بنا ما يمكن للوكلاء فعله بالفعل في المحرر.
كيف أقوم بتشغيل اختبارات واجهة برمجة التطبيقات (API) على طلبات سحب Origin؟ بنفس الطريقة التي تفعلها على GitHub: قم بتشغيل Apidog CLI كخطوة CI. في Origin، هذا يعني ربط Depot أو Buildkite بالمستودع وإعادة استخدام سير عمل Actions الحالي لديك، مع بقاء أوامر apidog run الخاصة بك دون تغيير.