مدفونة في مواد إطلاق Grok 4.5 جملة أهم من معظم نتائج المعايير: النموذج "تم تدريبه جنبًا إلى جنب مع Cursor". ووفقًا لـمنشور Cursor، ساهم المحرر بتريليونات من الرموز المميزة من بيانات تلتقط "تفاعلات المستخدم مع قواعد الأكواد وأدوات البرمجيات".
إذا كنت تستخدم Cursor، فهناك احتمال أن تكون جلسات تطوير مشابهة لجلساتك قد ساعدت في تدريب هذا النموذج. الهدف هنا ليس الذعر، بل تحويل الخبر إلى قائمة تحقق عملية: ما المؤكد؟ ما غير المؤكد؟ وما الذي يجب ضبطه في إعداداتك وأدوات فريقك؟
ما قالته الشركتان
المؤكد من مواد الإطلاق:
- تم تدريب Grok 4.5 "جنبًا إلى جنب مع Cursor" و"بالاشتراك مع SpaceXAI"، وفقًا لـ Cursor.
- بيانات التدريب التقطت "تفاعلات المستخدم مع قواعد الأكواد وأدوات البرمجيات".
- الهدف المعلن هو أن يتعلم النموذج من "البرمجيات الموجودة بالإضافة إلى تفاعلات المطورين والوكلاء".
- تقارير الإطلاق، بما فيها تغطية TechCrunch، تصف البيانات بأنها تشمل آثار تصحيح الأخطاء، فروقات متعددة الملفات، وتصحيحات المستخدمين لمخرجات الوكيل.
السياق المؤسسي مهم أيضًا: وافقت SpaceX على الاستحواذ على Cursor في يونيو 2026 في صفقة بلغت قيمتها 60 مليار دولار، ما وضع المحرر داخل نفس عائلة xAI. بعد أحد عشر يومًا من دخول Grok 4.5 مرحلة تجريبية خاصة في SpaceX وTesla، تم إطلاقه علنًا مع Cursor كواجهة إطلاق.
لماذا تختلف بيانات جلسات Cursor؟
معظم نماذج الأكواد تتعلم من بيانات ثابتة:
- مستودعات GitHub
- وثائق
- أمثلة تعليمية
- أسئلة وأجوبة
- كود نهائي بعد الدمج
هذا يعلّم النموذج شكل الحل النهائي، لكنه لا يعلّمه مسار الوصول إليه.
بيانات جلسات Cursor مختلفة لأنها تسجل العملية نفسها:
- ماذا طلب المطور؟
- ماذا حاول الوكيل فعله؟
- ما التعديل الذي فشل؟
- ماذا غيّر الإنسان بعد ذلك؟
- أي اختبارات تم تشغيلها؟
- كيف بدا الإصلاح النهائي؟
- ما الذي تم التراجع عنه أو تبسيطه؟
هذا النوع من البيانات مفيد جدًا لنماذج البرمجة القائمة على الوكلاء، لأنه يحتوي على أمثلة واقعية لـ"إجابات بدت صحيحة لكنها فشلت عمليًا".
مثال مبسط لما قد تتعلمه النماذج من جلسة كهذه:
- const user = await getUser(id)
- return user.name.toUpperCase()
+ const user = await getUser(id)
+ if (!user?.name) return null
+ return user.name.toUpperCase()
الكود النهائي وحده يعلّم النموذج النتيجة. أما سجل الجلسة فيعلّمه لماذا كان الإصدار الأول هشًا، وما التصحيح الذي اختاره المطور.
لماذا انعكس ذلك على أداء Grok 4.5؟
الملف المنشور للنموذج يشير إلى قوتين واضحتين:
- أداء قوي في مهام الطرفية وسير العمل.
- كفاءة أعلى في عدد الرموز المميزة المستخدمة للوصول إلى الحل.
وفقًا للأرقام المنشورة:
- Terminal Bench 2.1: سجل Grok 4.5 نسبة 83.3%، متقدمًا على Opus 4.8.
- SWE Bench Pro: استخدم في المتوسط 15,954 رمزًا مميزًا للإخراج لكل مهمة، أي أقل بحوالي 4.2 مرة من Opus 4.8 وفق الحد الأقصى المذكور.
هذه النقطة مهمة للمطورين: النموذج الذي يتعلم من جلسات عمل حقيقية يرى أن المطورين غالبًا لا يكافئون الشرح الطويل، بل يكافئون أقصر تعديل عملي يمرر الاختبارات.
للمزيد من الأرقام، راجع تحليلنا للمعايير القياسية.
الأسئلة التي يجب أن تطرحها قبل استخدام Cursor أو Grok 4.5
أثار نقاش Hacker News حول الإطلاق الأسئلة نفسها التي يجب على أي مطور أو فريق طرحها.
هل تم تضمين بياناتي؟
لا يمكن الجزم من الخارج.
عبارة "تريليونات الرموز المميزة" من بيانات التفاعل تعني أن الجمع كان واسع النطاق، لكن لم تنشر الشركتان تفاصيل كافية حول:
- مجموعات المستخدمين المشمولة.
- الفترة الزمنية للبيانات.
- حالات الموافقة.
- أثر إعدادات الخصوصية القديمة.
- هل تم استبعاد خطط أو مؤسسات معينة.
ماذا عن وضع الخصوصية في Cursor؟
Cursor يقدم إعدادًا للخصوصية تنص سياسته المعلنة على أن الكود في تلك الجلسات لا يتم تخزينه أو استخدامه للتدريب.
لكن منشورات الإطلاق لا توضّح علنًا ما إذا كانت مجموعة بيانات Grok 4.5:
- تسبق هذه الحدود.
- احترمتها كما هي.
- أعادت تعريفها بعد الاستحواذ.
- طبقتها بشكل مختلف حسب الخطة.
لذلك لا تعتمد على الذاكرة. افتح سياسة خصوصية Cursor واقرأ النص الحالي، خصوصًا إن كنت تستخدمه داخل شركة أو على مستودعات غير عامة.
هل هذا مخالف للقواعد؟
شروط Cursor سمحت باستخدام بيانات غير وضع الخصوصية لتحسين المنتج. يمكن تفسير تدريب نموذج رئيسي داخل شركة تابعة على أنه نوع من تحسين المنتج، لكن على نطاق مختلف.
إذا كنت ضمن مؤسسة، لا تترك هذا القرار للمطورين فقط. اطلب من الفريق القانوني مقارنة العبارات التالية في العقود:
- "تحسين المنتج"
- "تدريب نموذج"
- "نموذج أساسي تجاري"
- "مشاركة البيانات مع الشركات التابعة"
- "الاحتفاظ ببيانات القياس عن بعد"
هل كودي موجود داخل النموذج؟
الاسترجاع الحرفي لبيانات التدريب نادر في النماذج الحديثة المصممة جيدًا، لكنه ليس مستحيلًا. لا يوجد تدقيق عام منشور لذاكرة Grok 4.5، لذلك تعامل مع السؤال كخطر يجب تقليله، لا كشيء يمكن نفيه بالكامل.
قائمة تحقق للمطورين الأفراد
إذا كنت تستخدم Cursor اليوم، نفّذ هذه الخطوات:
- افتح إعدادات الخصوصية في Cursor.
- تحقق مما إذا كان وضع الخصوصية مفعّلًا.
- إذا كنت تعمل على كود حساس، لا تترك الإعداد الافتراضي دون مراجعة.
- اقرأ سياسة البيانات الحالية، لا النسخة التي تتذكرها.
- لا تلصق الأسرار في المحرر أو المطالبات.
- استخدم ملفات
.envأو مدير أسرار بدلًا من تضمين المفاتيح داخل الكود.
مثال لما لا يجب فعله:
const apiKey = "sk-live-xxxxx"
استخدم بدلًا من ذلك:
const apiKey = process.env.API_KEY
ثم أضف الملف المحلي إلى .gitignore:
.env
قائمة تحقق للفرق
إذا كنت مسؤولًا عن فريق يستخدم أدوات ذكاء اصطناعي للبرمجة، تعامل مع الأمر كحوكمة بيانات لا كإعداد شخصي.
1. راجع إعدادات مساحة العمل
تحقق من:
- إعدادات الخصوصية على مستوى الفريق.
- من يستطيع تغييرها.
- هل الإعدادات موحدة أم يضبطها كل مطور منفردًا.
- هل توجد سجلات تدقيق للتغييرات.
2. افصل بين سطحين مختلفين للبيانات
هناك سطحان يجب عدم خلطهما:
- بيانات قياس المحرر وجلسات Cursor.
- البيانات التي ترسلها إلى واجهات برمجة تطبيقات النموذج وقت الاستدلال.
استخدام نموذج عبر API يخضع لشروط بيانات API. أما قياس المحرر فيخضع لشروط الأداة نفسها. راجع الاثنين بشكل منفصل.
3. امنع تسرب الأسرار
لا يجب إرسال مفاتيح API أو الرموز المميزة أو بيانات الاعتماد إلى أي جلسة ذكاء اصطناعي، سواء كانت داخل محرر أو أداة API أو محادثة.
إذا كنت تختبر نقاط نهاية نموذج، خزّن المفاتيح كمتغيرات بيئة في Apidog بدلًا من لصقها في جلسات المحرر أو المجموعات المشتركة. بهذه الطريقة يشير الفريق إلى المتغير، لا إلى القيمة نفسها.
مثال عملي:
Authorization: Bearer {{XAI_API_KEY}}
بدلًا من:
Authorization: Bearer sk-real-key-here
يمكنك تنزيل Apidog مجانًا لإعداد خزنة مشتركة لمفاتيح نموذج فريقك.
لا تحتاج إلى ترك الأداة، لكن اضبطها بوعي
لا يعني هذا أن عليك التوقف عن استخدام Cursor أو Grok 4.5. لكنه يعني أن استخدام أدوات البرمجة الذكية أصبح يتطلب نفس الانضباط الذي نطبقه على:
- مفاتيح الإنتاج.
- صلاحيات GitHub.
- سجلات CI/CD.
- بيانات العملاء.
- مستودعات الشركات.
القاعدة العملية:
إذا لم تكن مستعدًا لإرسال معلومة إلى مزود خارجي، فلا تضعها في مطالبة أو جلسة محرر أو مثال اختبار مشترك.
السابقة أهم من Grok 4.5 نفسه
Grok 4.5 هو أول نموذج حدودي يتم الإعلان عن تدريبه على جلسات مستخدمي محرر تجاري بهذا الوضوح. لكنه لن يكون الأخير.
كل بائع محرر ذكاء اصطناعي يمتلك الآن حافزًا قويًا لجمع بيانات الجلسات، لأنها تثبت أنها تنتج قدرة عملية لا توفرها المستودعات الثابتة وحدها. وكل استحواذ على شركة أدوات مطور أصبح يحمل سؤالًا إضافيًا: ما قيمة بيانات الاستخدام المتراكمة؟
GitHub وGoogle وAmazon وغيرها تمتلك مجموعات تفاعل مشابهة أو قريبة من هذا النوع. لذلك، قراءة إعدادات الخصوصية لم تعد سلوكًا دفاعيًا زائدًا؛ أصبحت مهارة مهنية.
للمزيد حول النموذج نفسه، راجع:
الأسئلة الشائعة
هل قامت xAI بتدريب Grok 4.5 على بيانات مستخدمي Cursor؟
نعم، وفقًا لوصف الشركتين. ساهمت Cursor بتريليونات من الرموز المميزة من بيانات تفاعل المطورين، بما في ذلك جلسات الوكلاء وتصحيحات المستخدمين.
هل يحمي وضع الخصوصية في Cursor كودي من التدريب؟
هذا هو الغرض المعلن منه. لكن كيفية تطبيقه تحديدًا على مجموعة بيانات Grok 4.5 لم تُشرح علنًا بالتفصيل. تحقق من سياسة Cursor الحالية وشروط خطتك.
هل يمكنني استخدام Grok 4.5 دون المساهمة ببيانات تدريب مستقبلية؟
يعتمد ذلك على إعدادات خصوصية Cursor وشروط بيانات واجهة برمجة تطبيقات xAI. راجع كليهما. الاستخدام عبر API فقط، مثل وحدة تحكم xAI، يخضع لحوكمة مختلفة عن قياس المحرر عن بعد.
لماذا يجعل التدريب على الجلسات النموذج أفضل في البرمجة؟
لأن بيانات الجلسات تعلّم النموذج العملية، لا النتيجة فقط: ما فشل، وما صححه الإنسان، وما الاختبارات التي كشفت المشكلة، وكيف بدا أقصر حل عملي. الكود الثابت يعلّم الحالة النهائية فقط.
Top comments (0)