أنور پآي
كتابة: Ahmed mohammed
قد ينتهي مساعدك الذكي من تعديل الملفات ويقول إن المهمة اكتملت، بينما لم تُشغّل الاختبارات أو بقيت مشكلة في الكود. Procoder يضيف فحوصًا وقواعد إغلاق للعمل: يفحص التغييرات ويعرض ما يمنع قبولها، ويطلب أدلة قبل اعتبار المهمة منتهية. الفيديو أعلاه يقدم الفكرة باختصار، وهذا المقال يشرح بداية استخدامها وحدودها. [1][2]
هذه مراجعة لوثائق المشروع عند إصدار محدد، وليست تجربة تشغيل نفّذناها. الأمثلة المنقولة أدناه من المصادر الرسمية، ولا ننسب نتائجها إلى اختبار محلي.
لمن هذا؟
لمن يكتب الكود بمساعدة وكيل مثل Claude Code أو Cursor أو Codex أو OpenCode، ويريد أن يفصل بين «الوكيل توقف عن العمل» و«التغيير اجتاز الفحوص المطلوبة».
Procoder أداة لتنظيم عمل الوكيل ومراجعة التغييرات، وليست نموذجًا جديدًا لتوليد الكود. تحتاج معرفة أساسية بالمشروع وGit، الأداة التي تحفظ تاريخ تغييراتك. سنستخدم مسار Claude Code لأنه موثّق في دليل البداية؛ بقية الوكلاء تحتاج إعدادًا بحسب المضيف. [1][3]
إذا كنت تبدأ بتعلّم البرمجة ولم تشغّل مشروعًا أو اختبارًا بعد، افهم أولًا كيف تتحقق من النتيجة. تقرير أخضر لا يشرح وحده لماذا الكود صحيح.
ماذا ستحتاج؟
مشروعًا محفوظًا في Git، ويفضل نسخة تجريبية أو فرعًا منفصلًا قبل إدخال قواعد جديدة.
Claude Code لمسار التثبيت هنا، أو وكيلًا آخر مع دليل التوافق الخاص به.
صلاحية تثبيت الإضافة والأدوات التي يحتاجها مشروعك.
أدوات الفحص المناسبة للغة، مثل المنسّق وLinter، أداة اكتشاف مشكلات الكود، وأدوات مسح الأسرار عند طلبها.
اتصالًا بالتنزيلات اللازمة للإعداد الأولي؛ لا تفترض أن عبارة «ملف تنفيذي واحد» تعني أن جميع أدوات الفحص مضمنة داخله.
المشروع مكتوب بلغة Go، ويقدم ملفًا تنفيذيًا مستقلًا. تشغيل نسخة جاهزة لا يتطلب بيئة Go، لكن فحوصه تستدعي أدوات خارجية مثل gitleaks وsemgrep حسب المهمة. التثبيت اليدوي يوجّه إلى تنزيل ثنائي المنصة والتحقق من بصمته؛ الإضافة تتولى مسار تجهيز الثنائي. [3][4][5]
ترخيص Procoder هو Apache 2.0. تكاليف وكيلك أو مزود النموذج مستقلة عنه. راجع الأوامر قبل اعتمادها، ولا تضع مفاتيح أو بيانات عملاء في المستودع التجريبي أو تقارير تشاركها.
دقة مهمة: أدوات مثل format تطبع النتيجة المقترحة ليكتبها الوكيل بعد المراجعة. لا تعمم ذلك إلى أن كل أمر في الأداة لا يغير أي حالة: وثائق الإعداد تذكر تغييرات محددة لـ init، ويوجد أمر تنظيف خاص بذاكرة الإضافة. راجع سلوك الأمر الذي ستستخدمه. [5][6]
النتيجة النهائية (صورة)
النتيجة التي تستهدفها هي تقرير يوضح سبب رفض التغيير، ثم تقرير جديد بعد معالجة الأسباب وإعادة الفحص. تستطيع رؤية ملف غير منسّق، أو علامة تعارض دمج بقيت في النص، بدل الاكتفاء بعبارة «اكتمل».
مصدر الصورة: النص من مثال docs/getting-started.md الرسمي. أُعيد تنضيده لتسهيل قراءته، دون تغيير القيم أو النتائج. الصورة لا توثّق تشغيل الأداة على جهازنا. [3]
في المثال، تشير BLOCKING إلى مشكلة تمنع اجتياز البوابة. بعد حل تعارض الدمج وتطبيق التنسيق ثم إعادة الفحص، يعرض الدليل نتيجة نظيفة. هذه نتيجة المثال المحدد، وليست ضمانًا لاكتشاف كل عيب في البرنامج.
ومن أهم الحالات التي يذكرها المشروع unchecked أو NOT checked: الفحص لم يحدث أو لم يستطع إصدار حكم. غياب أداة كشف الأسرار، مثلًا، لا يُعامل على أنه «لم نجد أسرارًا». [4]
خطوات 1-2-3
1. ثبّت الإضافة على مشروع تجريبي
داخل Claude Code، اتبع أوامر دليل البداية:
/plugin marketplace add azrtydxb/procoder
/plugin install procoder
/reload-plugins
ثم افتح مستودع المشروع التجريبي وشغّل:
/procoder:init
يفحص الإعداد ما يحتاجه المشروع ويعرض فجوات الأدوات. راجع خطة التثبيت قبل تنفيذها، ثم تحقق من اكتمال تجهيز الأدوات. الإضافة تدعم Hooks، إجراءات مرتبطة بأحداث مثل كتابة ملف أو محاولة حفظ تغيير في Git؛ لكن تفاصيل الربط تختلف بين الوكلاء. [3][6]
للمضيفين الآخرين، اتبع التثبيت اليدوي ودليل التوافق. مجرد وجود الملف التنفيذي لا يضمن اعتراض كل عملية Commit. دليل التثبيت اليدوي يطلب ربط بوابة Git ومراجعة المخرجات الناتجة عن إعدادها. [5]
2. نفّذ تغييرًا صغيرًا واقرأ تقرير البوابة
اطلب من الوكيل تغييرًا محددًا يمكن مراجعته، مثل تحسين رسالة خطأ وإضافة اختبار لها. قبل العمل، اكتب ما ستعتبره نجاحًا: الرسالة الجديدة تظهر في الحالة المطلوبة، والاختبار ينجح دون كسر الحالات السابقة.
بعد كتابة التغيير، شغّل داخل Claude Code:
/procoder:check
راجع أسماء الملفات والنتائج. إذا وجدت مشكلة تنسيق، اطلب النتيجة المقترحة وراجعها قبل تطبيقها. وإذا تعذّر تشغيل أحد الفحوص، فجهّز أداته أو عالج سبب التعطل ثم أعد الفحص. لا تصف تقريرًا ناقصًا بأنه اجتياز.
انتبه أيضًا إلى نطاق البوابة. المستودع الذي يتبنى Procoder عبر .procoder/ أو عقد AGENTS.md الذي يذكره يحصل على الفحوص الأوسع. المستودع غير المتبنّي يستخدم نطاق universal الذي يفحص مجموعة أضيق من المشكلات العامة، وبعض فحوص المحتوى فيه تنظر إلى الأسطر المعدلة فقط. التقرير الهادئ قد يعني نطاقًا أضيق، لا فحصًا شاملًا. [1][7]
3. شغّل الاختبارات وأغلق المهمة على دليل
شغّل مجموعة اختبارات المشروع من الأمر الموثّق:
/procoder:test
يعرض Procoder نتائج تشغيل أدوات الاختبار الفعلية للمشروع، ويميّز بين النجاح والفشل وعدم التشغيل. إذا أردت أن يكون فشل الاختبارات سببًا لمنع إغلاق المهمة أو قبول التغيير، راجع قسم [test] في .procoder/config.toml واضبط السياسة المناسبة. المثال الرسمي لسياسة المنع هو:
[test]
policy = "block"
عدّل القسم الموجود بدل إضافة قسم مكرر. لا تتعامل مع سياسة التقرير الافتراضية وسياسة المنع على أنهما الشيء نفسه. [7]
احتفظ بدليل يذكر ما شغّلته وما أثبته. أدوات متابعة المهام في Procoder تطلب معايير قبول وأدلة وبوابة سليمة قبل الإغلاق. نجاح اختبار واحد لا يثبت أن كل ما طلبته تحقق؛ اربط الدليل بمعيار القبول نفسه. [8]
مشاكل شائعة
البوابة تفشل لأن أداة غير موجودة: اقرأ تقرير الاحتياجات أو استخدم /procoder:doctor. أداة مفقودة قد تعني أن الفحص لم يحدث، لا أن الكود معيب في النقطة التي كان سيفحصها. جهّز الأداة ثم أعد الفحص. [4][9]
التقرير نظيف لكن مشكلة قديمة بقيت في المشروع: procoder check يجيب أساسًا عن التغيير، لا عن كل الشجرة. توجد مراجعة أوسع عبر audit، لكن تشغيلها أول مرة على مشروع قديم غير منسّق قد ينتج تقريرًا ضخمًا. ابدأ بنطاق تستطيع إصلاحه ومراجعته. [4]
المساعد الآخر لا يمنع Commit رغم التثبيت: افصل بين دعم قراءة التعليمات ودعم Hooks. بعض الوكلاء يحصلون على ملفات قواعد، وبعضهم يضيف إجراءات في نقاط محددة من دورة العمل. راجع الربط الفعلي مع Git والمضيف؛ لا تعتمد على قائمة الأسماء وحدها. [5][6]
الاختبارات فاشلة ومع ذلك ترى تقارير غير مانعة: راجع سياسة [test] ونطاق البوابة. إعدادات التقرير والمنع مختلفة، والفحوص التي تعذّر تشغيلها لها حكم مستقل في الوثائق. [7]
يقال إن الأداة «تتعلم»، فتتوقع تحسن النموذج نفسه: حلقة الدروس تسجّل ما أفلت، ثم تطلب تعديلًا ملموسًا، مثل قاعدة Linter أو اختبار يمنع الرجوع. هذا تحديث لعملية العمل وقواعدها، وليس تدريبًا لأوزان النموذج، ولا ضمانًا أن فئة الخطأ لن تظهر مجددًا. [8]
تريد إثبات أنها تقلل الأخطاء بنسبة محددة: صفحة الحدود تصرّح بأن العائد من البوابة مقابل كلفتها لم يُقَس بقياس تجريبي مكتمل. لا نستنتج توفير وقت أو انخفاض عيوب من قائمة الميزات. [4]
مصطلحات
الوكيل البرمجي: مساعد يستخدم النموذج وأدوات المشروع لقراءة الملفات وتعديلها وتشغيل أوامر.
Commit: تسجيل مجموعة تغييرات في تاريخ Git.
بوابة الجودة، Gate: فحوص تنتج حكمًا بالاجتياز أو الرفض ضمن نطاق وسياسة محددين.
Hook: إجراء مرتبط بحدث، مثل تعديل ملف أو محاولة Commit.
Formatter: أداة توحّد شكل الكود والمسافات وفق إعدادات المشروع.
Linter: أداة ترصد أنماطًا أو مشكلات في الكود، دون أن تثبت صحة البرنامج بالكامل.
معايير القبول: نتائج محددة تستطيع التحقق منها قبل إعلان انتهاء المهمة.
حلقة الدروس: تسجيل عيب أفلت، ثم إضافة قاعدة أو اختبار يعالج سبب إفلاته.
ماذا بعد؟
اختر تغييرًا صغيرًا، واكتب معيارين قابلين للفحص قبل أن تطلب من الوكيل تنفيذه. راجع تقرير البوابة، وشغّل الاختبار، ثم اسأل إن كان الدليل يثبت المعيارين فعلًا.
إذا أردت فهم جانب تقليل التعقيد في عمل الوكلاء، اقرأ الذكاء الاصطناعي يعقّد مشروعك؟ جرّب Ponytail. يذكر Procoder تأثره بمبادئ من Ponytail وأدوات أخرى، لكن ذلك لا يثبت تطابقًا كاملًا بين كل وظائفها. [1]
المصادر وحقوق الصور
[2] الفيديو المرفق.
[9] مرجع الأوامر.
الغلاف مشتق من البانر الرسمي مع الحفاظ على نسبته داخل غلاف 1200×630. صورة النتيجة تنضيد لمخرجات المثال الرسمي، وليست لقطة شاشة لاختبار محلي. المصادر تحت Apache 2.0، وأُرفقت نسخة الترخيص مع حزمة المراجعة. حقوق العلامة محفوظة لأصحابها.
لا تعليقات بعد. شارك سؤالك أو تجربتك مع هذا المحتوى.