كيف تكتب موجز بناء رئيسيًا لوكيل برمجي؟

ابدأ بالمهمة القابلة للتحقق

اكتب ما الذي يجب أن يتغير ولمن، ثم اربطه بمتطلب حالي. بدل «ابنِ لي منصة كاملة»، قل: «أضف إنشاء موعد لمستخدم مصرح له، وارفض التعارض، واختبر حالتي النجاح والتكرار». أرفق بنية المشروع الحالية والملفات ذات الصلة فقط، لا أسرارًا أو نسخة كاملة غير ضرورية من المستودع.

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

• الهدف والنطاق والمستخدم المعني.
• السياق المعماري ومصدر الحقيقة.
• ما لا يجوز تغييره أو كشفه.

أضف حدودًا واختبارات

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

مثال قصير: «استخدم العقود الموجودة؛ لا تغيّر D1 أو أسرار الإنتاج؛ أضف اختبارًا يمنع مالكًا من قراءة مشروع آخر؛ توقّف قبل النشر». هذا أوضح من قائمة تقنيات وأوامر بلا سبب.

• اجعل حدود Git والنشر والهجرات صريحة.
• اطلب اختبار مسار الفشل لا العرض الناجح فقط.
• اربط التقرير النهائي بأدلة قابلة للتكرار.

ما الذي لا يفعله الموجز؟

لا يضمن صحة الكود، ولا يحل محل مراجعة الخبير أو تفويض المالك. قد يحتاج التنفيذ إلى سؤال جديد عندما تصطدم المهمة بحد أمني أو قرار منتج لم يُحسم. ArchQore يكوّن موجز تنفيذ من أساس معتمد؛ بوابات الاستعداد والتصريح المنفصلة تمنع تحويل مجرد الموجز إلى تنفيذ تلقائي.

• تجنب نسخ كلمات المرور أو الرموز داخل المحادثة.
• لا تطلب تجاوز الاختبارات من أجل سرعة ظاهرية.
• راجع الفروق قبل الدمج والنشر.