تخطَّ إلى المحتوى
cd /blog

الخريطة أولًا، المراجعة ثانيًا

[Ecosystem] [Workflow] [Code Review]

> أسّس وكيل البرمجة الخاص بك على خريطة المستودع قبل أن يكتب. ثم دع Greptile يراجع طلب السحب بعد ذلك. زوج متكامل، وليس بديلًا.

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

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

هذا المقال دليل سير عمل مزدوج. Maguyva هي الخريطة التي يستعلمها الوكيل أولًا. Greptile هو وكيل المراجعة الذي يعلّق على طلب السحب بعد ذلك. هذا الزوج متكامل بحكم التصميم: لا تراجع Maguyva طلبات السحب، ولا يحل Greptile محل طبقة السياق التي يستخدمها الوكيل لكتابته.

لماذا هذا التقسيم مفيد

وكيل البرمجة الذي يبدأ بتحيز التدريب بالإضافة إلى بعض الملفات المُلصَقة سيخترع مسارًا معقولًا ويحرّره. هذا فشل من نوع ‘الملف الخاطئ’، وهو مشكلة استرجاع. Maguyva هي طبقة سياق قاعدة كود MCP عن بُعد: يجتمع الاسترجاع الدلالي والبنيوي (AST) والرسم البياني/التبعيات والنصي في نتيجة واحدة مُصنَّفة، بالإضافة إلى البحث عن الرموز واسترجاع الملفات. الإجابات المدعّمة بالأدلة تعود كـ path/file.ext:line، حتى تتمكن من رفض الخطأ قبل أن توجد الرقعة. المُدَّعى بسيط عمدًا: تغييرات أقل هلوسة. لا يزال بإمكان النموذج التخمين. فقط الخطوة الأولى لم تعد تخمينًا.

Greptile هو وكيل مراجعة كود مدعوم بالذكاء الاصطناعي. بكلماتهم، يراجع تلقائيًا كل طلب سحب بفهم كامل لقاعدة الكود، ويضع نفسه مقابل أدوات تدقيق الشيفرة التقليدية التي تفحص الملفات بشكل منفصل بدلًا من النظام بأكمله. يتكون الإعداد من تثبيت تطبيق GitHub أو GitLab واختيار مستودع. لا يوجد فهرس محلي عليك تشغيله. الاستضافة عبر Greptile Cloud (يذكرون امتثال SOC 2 Type II، مع تقرير متاح عند الطلب)، مع خيار استضافة ذاتية معروض للمؤسسات.

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

هذه مراجعة، وليست صياغة. قوة Greptile هي سياق الرسم البياني الكامل للمستودع مقابل تغيير استقر بالفعل في طلب سحب، متبوعًا بحلقة مغلقة ترسل النتائج إلى Claude Code أو Codex أو Conductor أو Cursor أو Devin. قوة Maguyva هي الخريطة المُصنَّفة التي يستعلمها الوكيل قبل كتابة التغيير. استخدم كليهما. لا تطلب من أحدهما القيام بعمل الآخر.

لا يوجد تكامل منتج من طرف أول بين Maguyva وGreptile مذكور. لست بحاجة إليه أيضًا. تتحدث Maguyva إلى الوكلاء عبر MCP. يتحدث Greptile إلى GitHub أو GitLab عبر تطبيقه الخاص. يلتقيان عند طلب السحب. لا سكريبت لاصق، ولا cron يغذّي أداة إلى أخرى. لا يحتاج هذا الزوج إلى bash لأن كل منتج يجلس بالفعل على السطح الذي يخصه.

ما ليس هذا

هذا ليس تشهيرًا بـ Greptile. هذه ليست صفحة ‘استبدل مراجعك’. أُطلق Greptile على Hacker News في 5 مارس 2024 كشركة Y Combinator W24، وكان ذلك الموضوع طريقة تعرّف بها كثيرون على هذا المنتج لأول مرة. إذا كانت تلك هي الطريقة التي اكتشفتهم بها، استمر باستخدامهم. هذه الصفحة هي النصف الثاني المفقود من تلك الحلقة: تأسيس الوكيل أولًا حتى يكون طلب السحب الذي يراه Greptile مستهدفًا بالفعل للملفات الصحيحة.

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

تغطية اللغات هي نفس النوع من الصدق. يؤطر Greptile الدعم على أنه يغطي جميع لغات البرمجة بدلًا من قائمة مُدرَجة؛ الرقم الدقيق غير مذكور. تنشر Maguyva دعمًا لأكثر من 279 لغة وتقنية قائمة على النص، مع تفصيل تقني (AST مدعوم بواسطة محلل نحوي مقابل نص فقط) على الموقع عندما يكون السؤال تقنيًا. هذان منتجان مختلفان يدّعيان أشياء مختلفة. لا تخلط بينهما.

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

سير العمل

ثلاث مراحل مُسمّاة. نفّذها بهذا الترتيب. لا تتخطَّ أيًا منها في أول مرة تجرّب فيها هذا الزوج.

1. سياق Maguyva

فهرس مستودعًا واحدًا تعرفه بالفعل. اربط عميل MCP الذي تكتب فيه بالفعل — Claude Code أو Cursor أو Codex CLI أو VS Code أو Windsurf أو أي عميل آخر متوافق مع MCP. لدى Maguyva أدلة إعداد لـ 24 عميل MCP موثّق ويمكنها التحدث إلى عملاء آخرين يدعمون تكوين MCP القياسي.

اطرح سؤالًا واحدًا يمكنك تقييمه قبل أن يكتب أي أحد سطرًا واحدًا. ‘أين تُعالَج مهلة انتهاء الجلسة، ومن يستدعيها؟’ خطوة أولى أفضل من ‘أصلح المصادقة’. طالب بالاقتباسات. افتح نتيجة file.ext:line. تتبّع الرمز. تحقق من التبعيات التي أنت على وشك لمسها.

تكشف Maguyva عن 11 أداة MCP موجهة للعملاء عبر البحث والرموز وتحليل التبعيات واسترجاع الملفات وسياق المستودع وسير عمل الأدوات المساعدة الحتمية. تجتمع أربعة أنماط استرجاع في نتيجة واحدة مُصنَّفة؛ find_symbol أداة منفصلة عندما تعرف الاسم بالفعل. تصف الوثائق أقصر مسار: ابدأ مجانًا، فهرس مستودعًا تعرفه بالفعل، اربط العميل، ثم اطرح سؤالًا واحدًا يمكنك التحقق منه.

اللقطات مختومة بالوقت، حتى يتمكن الوكيل من معرفة أي نسخة من الشجرة يقرأ. القيد الصادق هو العمل المحلي غير المتزامن. إذا كان التغيير موجودًا فقط في شجرة العمل ولم يُدفَع بعد، فإن الخريطة المستضافة لا تحتوي عليه بعد. لا تزال ملفات التعليمات (CLAUDE.md، AGENTS.md) لها مكان هنا، للأعراف وما ينبغي عدم لمسه. إنها ليست خريطة حية. استخدمها للسلوك. استخدم Maguyva للحقائق.

لا تدع الوكيل يفتح طلب سحب قبل أن يصمد الاقتباس أمام التماس مع المستودع. تلك البوابة هي الغرض الكامل من هذه المرحلة.

2. طلب سحب الوكيل

نفس الوكيل يكتب الآن التغيير في العميل الذي تدفع مقابله بالفعل. Maguyva ليست محررًا ولا مراجعًا. لا يزال الوكيل ينتج التغيير. لا تزال تفتح طلب سحب على GitHub أو GitLab كما كنت تفعل بالفعل.

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

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

3. مراجعة Greptile

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

اقرأ التعليقات كما تقرأ زميل فريق منتبه: افتح الموقع المقتبس، قرر ما إذا كانت النتيجة صحيحة، ثم تصرّف. حيثما يقدّم Greptile ‘Fix with your Agent’، يرسل المشكلة — مسار الملف، رقم السطر، الكود المقترح — إلى Claude Code أو Codex أو Conductor أو Cursor أو Devin. يرسل ‘Fix All’ جميع المشكلات في تلك المراجعة دفعة واحدة. يوفرون أيضًا Greptile MCP وإضافة Claude Code لذلك التسليم. Maguyva غير موجودة في تلك القائمة المستهدفة المُسمّاة؛ هذا الغياب ليس مشكلة. أنجزت Maguyva عملها بالفعل في المرحلة 1. وكيل البرمجة الذي كتب طلب السحب هو الطرف الذي ينبغي أن يحصل على حمولة الإصلاح.

توقّع ضجيجًا في الأسابيع 2-3 الأولى بينما يتكيّف نظام تعلّم Greptile مع التعليقات التي يتركها فريقك فعليًا. هذا هو الجدول الزمني الذي يذكرونه، وليس عيبًا في الزوج. تبقى المراجعة البشرية في تلك الحلقة. Greptile خطوة أولى تلقائية، وليس زر دمج.

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

كيف تحافظ على صدق هذا التكامل

  • Maguyva دائمًا أولًا. مراجعة طلب سحب بملف خاطئ لا تزال مراجعة ملف خاطئ.
  • Greptile دائمًا بعد ذلك. مسودة مُقتبَسة جيدًا لا تزال تحتاج إلى قراءة تغيير على مستوى النظام بأكمله.
  • لا تطلب من Maguyva نشر تعليقات طلبات السحب. إنها لا تفعل ذلك.
  • لا تطلب من Greptile أن يكون طبقة الاسترجاع الأولى للوكيل بينما لا يزال يختار المسار. هذا ليس عملًا مصممًا لتطبيق GitHub أو GitLab الخاص بهما.
  • لا تخترع خط أنابيب bash ‘يزامن’ الاثنين. طلب السحب هو تلك الواجهة.
  • تحقق من كلا الجانبين بشكل منفصل. فهرس مستودعًا تعرفه بالفعل. اطرح سؤالًا واحدًا يمكنك التحقق منه. ثم افتح طلب سحب صغير واقرأ ما يعلّق عليه Greptile فعليًا.

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

// map first. review second. in that order.

قراءات ذات صلة

المزيد من سجل بناء Maguyva