تطوير تطبيقات الويب 3 داخل مجلد مشروعك الخاص

ما يمكن أن يفعله الوكيل لتطبيق dApp الخاص بك

• الملفاتتعمل أدوات read_file، write_file، edit_file، grep، glob و list_dir في مجلد العمل الخاص بالدردشة، مما يسمح بقراءة ملفات المكونات (components)، الأنماط (styles) وملف ABI JSON وتغييرها.
• Shellيشغّل أمر البناء الخاص بك وأمر الاختبار على Windows، أو WSL، أو خادم SSH تملكه، ويعرض رمز الخروج الفعلي (exit code) لكل أمر.
• الويبتقرأ أدوات web_search و http_get صفحات التوثيق العامة، بحيث يمكن التحقق من سؤال حول مكتبة أو واجهة من خلال الصفحة التي تصفها.
• لقطات الشاشة والصورتقرأ أداة ocr النص من لقطة شاشة محفوظة، مثل نموذج تصميم، وتقوم أداة gen_image بحفظ ملفات الصور، مثل الصور المؤقتة.
• التنسيقتبدأ أداة task وكلاء فرعيين لأجزاء منفصلة من العمل بالتوازي، ترسل أداة run_on_model خطوة صعبة واحدة إلى نموذج أكبر، وتعيد أداة skill استخدام خطة عمل.
• أوضاع الموافقةيعمل وضع Auto-run على الفور، يوقف وضع Ask first الإجراءات التي تغير شيئاً ما ويظهر الاختلاف (diff)، ويكتب وضع Plan only الخطة دون تنفيذ أي شيء.
• المواعيد (Cron)يشغل موجه (prompt) حسب الجدول الزمني، مثلاً أمر الاختبار الخاص بك مرة واحدة يومياً، وتبقى الخطط سارية بعد إعادة تشغيل التطبيق، بحيث يمكن استكمال المهمة الطويلة لاحقاً.
• النماذجاستخدم مزود ذكاء اصطناعي سحابياً عبر نقطة نهاية API قياسية، أو نموذجاً على جهازك الشخصي، أو النموذج المدمج، واضغط على "اختبار" للتحقق من نقطة النهاية.

أربع خطوات توضيحية لمشروع dApp

رسم خريطة لمشروع وراثي

تطلب من الوكيل رسم خريطة لمجلد dApp بدأه شخص آخر. تظهر أداة list_dir الهيكل، وتجد أداة glob ملفات المكونات وملف ABI، وتعد أداة grep قائمة بكل الأماكن التي تستدعي دالة في العقد الذكي. كل نتيجة هي بطاقة في الدردشة. لا يتغير شيء. تظهر الخريطة أماكن معالجة حالات المعاملات وأين تفتقر إليها، وغالباً ما يكون ما يمنع اعتماد تطبيقات dApp هو واجهة أمامية تفشل دون شرح السبب: عدم وجود محفظة، أو الشبكة غير الصحيحة، أو رفض التوقيع. يناسب وضع Plan only هذه المهمة، لأنه يكتب الخطة دون تنفيذ أي شيء، ويمكن للخطة أن تحدد الملفات التي تحتاج إلى انتباه أولاً. اطلب ملفاً مكتوباً قصيراً، ثم راجعه مقابل المجلد قبل أن تبدأ أي تعديل، وقم بتصحيح الوكيل إذا كان قد قرأ ملفاً بشكل خاطئ.

ربط ملف ABI بمكون

تطلب مكوناً يعرض رصيد حساب اختبار. تفتح أداة read_file ملف ABI JSON، مما يعرف الوكيل بأن balanceOf يتطلب عنواناً ويعيد قيمة uint256، وتضيف أداة edit_file الاستدعاء إلى مكونك. في وضع Ask first، ينتظر التغيير كاختلاف (diff). تقرأ الأسطر المضافة والمزالة، تقبلها أو ترفضها، وتطلب مراجعة إذا بدا الاسم أو النوع غير صحيح. ثم يشغّل Shell أمر البناء الخاص بك ويعرض رمز الخروج الفعلي في البطاقة، ويمكنك توسيع البطاقة لقراءة المخرج الكامل. يظهر البناء الأخضر أن الكود يُترجم بنجاح؛ لكنه لا يظهر أن الدالة الصحيحة تم استدعاؤها، لذا تحقق من الاستدعاء مقابل ملف ABI نفسه واحتفظ بملف ABI محدثاً مع العقد.

اختبار كل حالة معاملة

تفشل الواجهات في الفجوات بين الحالات: غير مرسلة، في انتظار المحفظة، معلقة، مؤكدة وفاشلة. لمنع بناء تطبيقات dApp شبحية التي تبدو مكتملة وتنكسر عند أول رفض للتوقيع، اطلب من الوكيل كتابة اختبار واجهة أمامية لكل حالة. تنشئ أداة write_file ملف الاختبار، تعدّل أداة edit_file المكون في حالة وجود حالة مفقودة، ويشغّل Shell أمر الاختبار الخاص بك. تعرض البطاقة رمز الخروج، وعند توسيعها، المخرج الكامل. شغّل الاختبارات ضد سلسلة محلية باستخدام حسابات مؤقتة، اقرأ كل فشل وقرر ما إذا كان الاختبار أو المكون هو الخطأ. لا تقبل تغييراً فقط لأن الاختبارات أصبحت خضراء: اقرأ الاختلاف (diff)، وتحقق من أن الاختبار يؤكد حقاً الحالة التي سُميت باسمها.

تخطيط ميزة، ثم تنفيذها

يمكن لمطور يريد تطوير مهاراته بعد عام واحد في مجال الويب 3 أن يطلب من الوكيل خطة تضيف حالات التحميل، وتصحيحات إمكانية الوصول (accessibility) واختبارات إلى تطبيق dApp موجود. في وضع Plan only، يكتب الوكيل الخطوات ولا يشغّل أي أمر ولا يغير أي ملف. تقرأ الخطة، تحذف ما لا تريده، وتنتقل إلى وضع Ask first لتنفيذها. من ذلك الحين، يتوقف الوكيل قبل كل إجراء يغير شيئاً، وتقرأ كل اختلاف (diff) قبل قبوله. تبقى الخطط سارية بعد إعادة التشغيل، لذا يمكنك التوقف في أي خطوة والاستئناف في اليوم التالي. أنهِ الأمر بتشغيل أمر الاختبار الخاص بك وقراءة مخرجاته بنفسك، واكتب في ملف README الأوامر التي استخدمتها.