ملاحظة الكاتب: يوجّه هذا المقال إلى المطورين الذين يستخدمون Agent بالفعل في عملهم، ويوضح السياق والمواد المرجعية ومعايير القبول القابلة للتحقق التي ينبغي إعدادها قبل تسليم المهمة، وما الذي لا يزال يحتاج إلى مراجعة بشرية.
بعد استخدام Agent، زاد حجم الإنتاج بالفعل، لكن الإرهاق البشري ازداد أيضًا. في 3 نوفمبر 2026، نشر أحد المطورين على V2EX وصفًا لهذه الحالة: يبقى الإنسان حاضرًا في دورة العمل، فيفحص النتائج ويصحح مسار المهمة ومشكلات التصميم باستمرار، ما يجعل التفويض الكامل صعبًا. وأشار المنشور إلى تجربة معروفة: يساعد توفير سياق ومواد مرجعية أكثر اكتمالًا Agent على فهم المهمة وتحسين جودة التسليم. لكنه لم يوضح ما المقصود تحديدًا بـ«أكثر اكتمالًا».
هذا ليس مقالًا آخر يقدم نصائح عامة عن «كتابة موجه جيد». نركز هنا على التحضير قبل تسليم المهمة: تقسيم المتطلبات المبهمة إلى أهداف وقيود ومواد مرجعية ومعايير إنجاز قابلة للتحقق، بحيث يستطيع Agent مراجعة عمله بنفسه ولا تحتاج أنت إلى التدخل إلا عند نقاط محددة. وتجدر الإشارة إلى أنه لا توجد حاليًا بيانات مقارنة منشورة تتيح قياس أثر طرق التحضير المختلفة؛ أما الأمثلة الواردة فهي تلخيص لحالات شائعة، وعليك اختبار فعاليتها في مهامك الخاصة.
الفائدة الأساسية: بعد قراءة المقال، ستحصل على هيكل قابل لإعادة الاستخدام لوصف مهام Agent وصياغة معايير قبولها، وستتمكن من تحديد ما يمكن تركه لـ Agent ليراجعه بنفسه وما يجب أن يحسمه الإنسان.
أهم النقاط حول سياق مهمة الوكيل ومعايير قبولها
قبل البدء بكتابة وصف المهمة، من المهم فهم الصورة العامة: غالبًا ما ينحرف الوكيل (Agent) عن المطلوب لأن فهمه لـ«ما الذي يجب فعله»، و«إلى أي مستوى يجب إنجازه»، و«ما الذي لا يجوز المساس به» يختلف عن فهمك. يوضح الجدول التالي العناصر الخمسة التي ينبغي أن يتضمنها وصف المهمة الجيد.
| العنصر | الوصف | المشكلة التي يحلها |
|---|---|---|
| الهدف | وضّح في جملة واحدة ما المطلوب تسليمه ولمن | يمنع الوكيل من توسيع المتطلبات أو الانحراف عن المسار من تلقاء نفسه |
| السياق والخلفية | حالة المشروع الحالية، والوحدات ذات الصلة، والمحاولات السابقة | يمنع تكرار العمل أو إلغاء تصميم قائم |
| القيود | الملفات التي لا يجوز تعديلها، والتقنيات المطلوبة، ومتطلبات الأداء أو التوافق | يمنع تقديم حل يعمل تقنيًا لكنه غير مناسب للاستخدام |
| المراجع | أمثلة من الشفرة الحالية، ووثائق الواجهات، ونماذج للأسلوب | تساعد على مواءمة أسلوب المخرجات وبنيتها مع المشروع القائم |
| معايير القبول | شروط للإنجاز يمكن التحقق منها بندًا بندًا، ويفضل أن يكون التحقق آليًا | تتيح للوكيل مراجعة عمله بنفسه، وتقلل حاجتك إلى مراجعة كل سطر |
علامات شائعة لانحراف الوكيل عن المهمة
لم يذكر المنشور الأصلي سيناريوهات محددة للانحراف، لذا جمعنا هنا بعض الحالات الشائعة لدى وكلاء البرمجة وتنفيذ المهام. قد تبدو مختلفة، لكن السبب الجذري غالبًا هو غياب أحد عناصر وصف المهمة.
| علامة الانحراف | السبب الشائع | إجراء وقائي |
|---|---|---|
| إصلاح خطأ مع إعادة هيكلة نصف الوحدة في أثناء ذلك | حدود الهدف غير واضحة، ونطاق التعديل غير محدد | حدّد في القيود الملفات أو الدوال المسموح بتعديلها فقط |
| إضافة تبعية جديدة غير موجودة في المشروع | عدم معرفة التقنيات المستخدمة حاليًا | اذكر التبعيات الحالية في السياق، مع قاعدة تمنع إضافة تبعيات جديدة |
| اختلاف أسلوب الشفرة عن بقية المشروع | غياب أمثلة مرجعية | أرفق مثالًا أو مثالين لتنفيذ مشابه ضمن المراجع |
| إعلان اكتمال المهمة دون تغطية السيناريوهات المهمة | غموض شروط الإنجاز | صغ معايير القبول في صورة عناصر قابلة للتحقق |
| تقديم حل ممكن تقنيًا لكنه لا يحقق هدف المنتج | عدم توضيح قرارات التصميم مسبقًا | اتخذ قرار التصميم بنفسك أولًا، ثم كلّف الوكيل بتنفيذه |
الحالة الأخيرة تستحق الانتباه خصوصًا. فالمشكلة ليست في أن السياق «غير كافٍ»، بل في أن المفاضلات التصميمية نفسها تحتاج إلى قرار بشري. سنناقش هذه النقطة لاحقًا على حدة.
كيفية إعداد وصف مهمة للوكيل: هيكل من خمسة أقسام
عند جمع العناصر الخمسة السابقة في مستند واحد، تحصل على وصف للمهمة يستطيع الوكيل فهمه والرجوع إليه للتحقق من عمله. يُنصح باستخدام Markdown وحفظ المستند في مستودع المشروع، وتسميته مثلًا TASK.md. ويمكن أيضًا وضع القيود العامة في ملف تعليمات على مستوى المشروع، مثل AGENTS.md، وتخصيص مستند منفصل لكل مهمة يتضمن أهدافها المحددة.
القسم الأول: صياغة هدف مهمة الوكيل
يجب أن توضّح جملة واحدة ما المطلوب تسليمه، ولمن، وفي أي سياق سيُستخدم. فعبارة مثل «تحسين وحدة تسجيل الدخول» قد يفهمها الوكيل على أنها تحسين للأداء، أو إعادة هيكلة للشفرة، أو تغيير للواجهة. والأفضل أن تقول: «اجعل واجهة تسجيل الدخول تُرجع رمز خطأ موحدًا عند إدخال كلمة مرور خاطئة، لتعرض الواجهة الأمامية رسالة بناءً عليه، دون تغيير مسار تسجيل الدخول الناجح».
إذا كانت المهمة كبيرة، فمن الأفضل إضافة جملة تحت الهدف توضّح «ما لن تتناوله هذه المهمة». غالبًا ما تمنع الاستثناءات الواضحة الوكيل من توسيع نطاق المتطلبات بصورة أفضل من الوصف الإيجابي وحده.
القسم الثاني: تقديم سياق المهمة للوكيل
المهم في السياق ليس كثرته، بل مدى صلته بالمهمة. إعطاء الوكيل المستودع بأكمله لا يعني أنك زودته بسياق كافٍ؛ فهو لا يزال بحاجة إلى معرفة الأجزاء المرتبطة بالمهمة. يُنصح بترتيب المعلومات كما يلي:
- الوحدات ذات الصلة: اذكر الملفات أو المجلدات المرتبطة مباشرة بالمهمة، مثل منطق تسجيل الدخول في
src/auth/وملفات الاختبار المقابلة. - القرارات السابقة: وضّح سبب اعتماد التصميم الحالي، مثل: «تُعرّف جميع رموز الأخطاء في وحدة
errors، ولا تُكتب مباشرة داخل شفرة منطق الأعمال». - الحلول التي جُرّبت سابقًا: إذا جُرّب نهج ثم تم التخلي عنه، اذكر السبب حتى لا يكرره الوكيل.
- شرح المصطلحات: وضّح مصطلحات العمل الخاصة بالمشروع التي لا يستطيع الوكيل استنتاج معناها من الشفرة بصورة موثوقة.
القسم الثالث: قائمة قيود الوكيل
تساعد القيود على تجنّب مخرجات «تعمل، لكنها غير صالحة للاستخدام». ويمكن سرد القيود الشائعة في قائمة ليراجعها الوكيل قبل التنفيذ وبعده:
- نطاق التعديلات المسموح بها، والملفات الممنوع تعديلها صراحةً، مثل نصوص ترحيل قاعدة البيانات وتعريفات الواجهات العامة.
- قيود التقنيات المستخدمة، مثل «عدم إضافة اعتماديات خارجية جديدة» أو «استخدام مكتبة التسجيل الموجودة في المشروع فقط».
- متطلبات التوافق والأداء، مثل «الإبقاء على توقيعات الواجهات الحالية دون تغيير».
- طريقة التعامل مع الحالات غير الواضحة، مثل «إذا تبيّن أن تعديل واجهة عامة ضروري، فتوقّف واشرح السبب، ولا تعدّلها من تلقاء نفسك».
النقطة الأخيرة مهمة جدًا. تحديد شرط واضح يوجب على الوكيل التوقف وطلب رأي شخص آخر يوفر جهدًا كبيرًا مقارنة باكتشاف أنه تصرّف من تلقاء نفسه بعد انتهاء العمل.
القسم الرابع: اختيار المواد المرجعية للوكيل
تساعد المواد المرجعية الوكيل على اتباع الأساليب المعتمدة بدلًا من البدء من الصفر. وغالبًا ما تكون الأمثلة الأكثر فاعلية هي التطبيقات المشابهة داخل المشروع نفسه، مثل: «عند إضافة واجهة جديدة، اتبع الأسلوب المستخدم في src/user/، بما في ذلك التحقق من المعاملات ومعالجة الأخطاء». أما المستندات الخارجية، فاكتفِ بتقديم الأقسام المتعلقة بالمهمة مع تحديد الإصدار، حتى لا يكتب الوكيل الشفرة وفق واجهات إصدار قديم.
كيف تكتب معايير قبول قابلة للتحقق للوكيل؟
معايير القبول هي أكثر أجزاء وصف المهمة عرضة للصياغة المبهمة، وهي أيضًا من أكثرها استحقاقًا للوقت. والاختبار بسيط: إذا لم يستطع الوكيل التحقق بنفسه من استيفاء معيار القبول، فهو مجرد أمنية لا معيار.
| صياغة مبهمة | صياغة قابلة للتحقق | طريقة التحقق |
|---|---|---|
| يجب أن تكون جودة الشفرة جيدة | اجتياز فحص lint المعتمد في المشروع دون إضافة تحذيرات جديدة | يشغّل الوكيل أمر الفحص ويبلّغ بالنتيجة |
| يجب أن تعمل الميزة بشكل صحيح | إضافة اختبارات وحدات تغطي ثلاث حالات: كلمة مرور خاطئة، وحساب غير موجود، وتسجيل دخول ناجح، مع اجتيازها جميعًا | تشغيل الاختبارات وإرفاق ملخص بالنتائج |
| يجب عدم التأثير في الميزات الأخرى | اجتياز مجموعة الاختبارات الحالية بالكامل، دون تعديل الملفات المحظور تعديلها في القيود | تشغيل جميع الاختبارات وسرد الملفات المعدّلة |
| يجب أن تكون الوثائق مكتملة | إضافة شرح لرموز الأخطاء في وثائق الواجهة، بتنسيق يطابق الإدخالات الحالية | المقارنة مع المثال المرجعي بندًا بندًا |
| يجب ألا يتراجع الأداء | عدم إضافة استعلامات قاعدة بيانات جديدة في المسار الحرج | توضيح التغير في عدد الاستعلامات في الملخص |
بعد كتابة المعايير، اطلب من الوكيل في نهاية وصف المهمة أن يبلّغ عن حالة الإنجاز «بمراجعة معايير القبول بندًا بندًا»: يوضح لكل معيار ما إذا كان مستوفًى، وما الدليل على ذلك، وسبب عدم استيفائه إن وجد. بهذه الطريقة، يكفيك الاطلاع على جدول المقارنة عند مراجعة النتيجة، بدلًا من قراءة جميع التعديلات من البداية.
دليل سريع لسياق الوكيل ومعايير القبول
فيما يلي خطوات عملية تلخّص ما سبق ويمكن تطبيقها مباشرة. لا تحتاج العملية إلى أدوات إضافية؛ يكفي مستند Markdown للبدء.
إعداد وصف مهمة الوكيل في 5 خطوات
- اكتب معايير القبول أولًا، ثم الهدف: تساعدك هذه الطريقة على تحديد شكل النتيجة المكتملة، وتجنّب صياغة هدف واسع أكثر من اللازم.
- أضف سياق المهمة: اذكر الوحدات والقرارات السابقة والمحاولات الفاشلة ذات الصلة فقط، مع الإيجاز.
- حدّد القيود وشروط التوقف: وضّح ما يجب عدم المساس به، والحالات التي تستدعي التوقف وطلب التوضيح.
- اختر مثالًا أو مثالين مرجعيين: أعطِ الأولوية للتطبيقات المشابهة داخل المشروع، وأشر إلى الأقسام ذات الصلة فقط من الوثائق الخارجية.
- اطلب تقريرًا منظّمًا: بعد الانتهاء، يجب تقديم تقرير يتناول كل معيار قبول على حدة، مع قائمة بالملفات المعدّلة والمشكلات التي لم تُحل.
مثال على وصف مهمة لوكيل (إصلاح رسالة خطأ تسجيل الدخول)
فيما يلي قالب لوصف مهمة في سيناريو افتراضي، معروض في قائمة يمكنك استبدال محتواها بما يناسبك:
- الهدف: تُرجع واجهة تسجيل الدخول رمز الخطأ نفسه عند إدخال كلمة مرور خاطئة أو عدم وجود الحساب، وتعرض الواجهة الأمامية رسالة بناءً عليه. لا يشمل هذا التعديل مسار تسجيل الدخول الناجح أو تنسيق الصفحة.
- الخلفية: تُعرّف رموز الأخطاء في وحدة
errors؛ وجرت سابقًا محاولة للتعامل معها في الواجهة الأمامية بناءً على نص الخطأ، لكن تم التخلي عنها بسبب تعدد اللغات. - القيود: يُسمح فقط بتعديل
src/auth/والاختبارات المقابلة؛ لا تُضف أي اعتماديات؛ إذا لزم تعديل تعريف واجهة عامة، فتوقف أولًا ووضّح السبب. - المراجع: طريقة معالجة الأخطاء في واجهة التسجيل ضمن
src/user/. - معايير القبول: إضافة اختبارات وحدات لثلاثة سيناريوهات واجتيازها جميعًا؛ اجتياز جميع الاختبارات الحالية؛ عدم ظهور تحذيرات جديدة من أداة lint؛ إضافة شرح لرمزَي خطأ في توثيق الواجهة.
- صيغة التقرير: مراجعة كل معيار من معايير القبول، وسرد الملفات المعدّلة، وتوضيح المشكلات المتبقية.
🚀 نصيحة للبدء: يمكنك تكليف نماذج مختلفة بتنفيذ وصف المهمة نفسه، ثم مقارنة مدى التزام كل نموذج بالقيود وشروط التوقف. وعبر منصة تجميع مثل APIYI على apiyi.com، يمكنك التبديل بين نماذج مزوّدين مختلفين باستخدام واجهة واحدة ومفتاح API واحد، دون الحاجة إلى تسجيل حسابات متعددة وإعدادها. وهذا يسهّل المقارنة على مهامك الفعلية.
المراجعة المتبادلة لخطط الوكلاء باستخدام نماذج من مزودين مختلفين
أشار كاتب المنشور الأصلي إلى مصدر قلق آخر: قد تشترك نماذج المزود الواحد في نقاط ضعف متشابهة. لذلك يرغب في أن يراجع وكلاء من مزودين مختلفين أعمال بعضهم، لكنه لا يستطيع حاليًا تبادل المعلومات بينهم إلا عبر مستندات Markdown أو النسخ واللصق، مما يجعل التنسيق مكلفًا. ويمكن الجمع بين هذه الفكرة وطريقة العمل في هذا المقال: وصف المهمة ومعايير القبول هما أفضل مرجع مشترك للمراجعة المتبادلة. لا يحتاج المراجع إلى فهم جميع نواياك؛ يكفي أن يفحص كل بند في ضوء المعايير نفسها.
تتمثل طريقة أبسط في إسناد أدوار مختلفة إلى النماذج، مع تزويدها جميعًا بوصف المهمة نفسه:
| الدور | المدخلات | المسؤولية | طريقة الوصول |
|---|---|---|---|
| المنفّذ | وصف المهمة | تنفيذ الحل والتحقق منه وفق معايير القبول | وكيل البرمجة الذي تستخدمه عادةً |
| المراجع A | وصف المهمة + ملخص التغييرات | مراجعة معايير القبول بندًا بندًا والإشارة إلى السيناريوهات غير المغطاة | نموذج من مزود آخر، يمكن استدعاؤه عبر الواجهة الموحدة من APIYI |
| المراجع B | وصف المهمة + ملخص التغييرات | التحقق تحديدًا من عدم مخالفة القيود وشروط التوقف | نموذج من مزود ثالث، يكفي تغيير اسم النموذج في الواجهة نفسها لاستدعائه |
| الإنسان | ملخص ملاحظات المراجعة | معالجة نقاط الاختلاف بين المراجعين ومسائل التصميم فقط | لا توجد |
إذا كنت مستعدًا لكتابة برنامج نصي صغير يربط خطوات «نتيجة التنفيذ ← إرسالها إلى نماذج المراجعة ← تجميع الملاحظات»، فيمكنك الاستغناء عن معظم عمليات النسخ واللصق اليدوية. توفر APIYI واجهة موحدة متوافقة مع حزم تطوير البرمجيات الشائعة، بحيث يكفي تغيير اسم النموذج في البرنامج النصي لاستدعاء نموذج من مزود آخر. وهذا يخفف صعوبة التكامل، وهي من أكثر العقبات إزعاجًا عند إدخال وكلاء من مزودين مختلفين. لكن انتبه: ما تؤتمته هنا هو نقل المعلومات، أما القرار النهائي فينبغي أن يبقى للإنسان.
ما المشكلات التي يحلها سياق الوكيل، وما الذي يتطلب مراجعة بشرية؟
يمكن للسياق المُعدّ جيدًا أن يقلّل الحاجة إلى تصحيح المسار، لكنه لا يلغي التدخل البشري تمامًا. طرح المنشور الأصلي «انحراف المهمة عن مسارها» و«مشكلات التصميم» معًا، لكن طبيعة المشكلتين مختلفة: فالأولى تنتج غالبًا عن نقص المعلومات، أما الثانية فتتطلب عادةً المفاضلة بين خيارات.
| نوع المشكلة | هل يمكن حلها بالسياق؟ | السبب | دور الإنسان |
|---|---|---|---|
| تجاوز نطاق التعديل | نعم، في الغالب | يستطيع الوكيل التحقق من عمله عند توضيح القيود | فحص قائمة التعديلات على سبيل العينة |
| عدم اتساق الأسلوب والتنسيق | نعم، في الغالب | تكفي الأمثلة المرجعية لتوضيح النمط المطلوب | الفحص من حين لآخر |
| عدم اكتمال تغطية الاختبارات | نعم، في معظم الحالات | يكفي تحديد السيناريوهات في معايير القبول | مراجعة اكتمال قائمة السيناريوهات |
| المفاضلات المعمارية والتصميمية | يصعب ذلك | تتطلب حكمًا على المفاضلة بين عدة حلول معقولة | اتخاذ القرار مسبقًا وإدراجه في وصف المهمة |
| قصد المنتج وتجربة المستخدم | يصعب ذلك | يعتمدان على أهداف العمل وفهم المستخدمين | تحديدهما مسبقًا والتحقق من النتائج بعد التنفيذ |
| مدى صحة معايير القبول نفسها | لا | لا يستطيع الوكيل سوى المقارنة بالمعايير، ولا يمكنه التشكيك في افتراضاتها | يجب أن يتحمل الإنسان المسؤولية |
يصعب تفويض مشكلات التصميم بالكامل إلى الوكيل لأنها لا تملك عادةً إجابة صحيحة واحدة. مثلًا، هل توضع رموز الأخطاء في الوحدة المشتركة أم في وحدة منطق الأعمال؟ كلا الخيارين قابل للتنفيذ، لكن الاختيار يعتمد على اتجاه توسع الفريق مستقبلًا وعاداته في الصيانة. وغالبًا ما تستند هذه المعلومات إلى حكم الأشخاص، ويصعب تدوينها بالكامل.
لذلك تتمثل الاستراتيجية الأكثر عملية في تقديم التدخل البشري إلى مرحلة مبكرة: اتخذ قرارات التصميم قبل بدء المهمة وأدرجها في القيود، حتى لا تحتاج إلى مراقبة الوكيل طوال التنفيذ. وبعد انتهائه، يكفي أن تراجع قائمة التحقق من القبول ونقاط الاختلاف بين المراجعين. هكذا يتحول دور الإنسان في دورة العمل من «المتابعة طوال الوقت» إلى «تحديد الاتجاه في البداية والتحقق من النتائج في النهاية».
الأسئلة الشائعة FAQ
Q1: ما معايير قبول عمل الوكيل (Agent)؟
معايير القبول هي شروط يجب استيفاؤها عند إتمام المهمة، ويمكن التحقق منها بندًا بندًا، مثل «اجتياز جميع الاختبارات المحددة» أو «عدم تعديل الملفات المحظور تعديلها». تساعد هذه المعايير الوكيل على مراجعة عمله، وتتيح للإنسان تقييم النتيجة سريعًا دون قراءة المخرجات كاملةً سطرًا بسطر.
Q2: هل الأفضل دائمًا تقديم أكبر قدر ممكن من السياق؟
لا. فالمعلومات غير المرتبطة بالمهمة قد تشتت الانتباه، بل قد تدفع الوكيل إلى تعديل أجزاء لا ينبغي له المساس بها. اختر السياق وفقًا للمهمة: الوحدات ذات الصلة، والقرارات المتخذة سابقًا، والمحاولات التي فشلت، والمصطلحات الضرورية. إذا لم تكن متأكدًا من فائدة معلومة ما، يمكنك استخدام APIYI apiyi.com لاستدعاء نماذج مختلفة واختبار نسخة مختصرة وأخرى كاملة من وصف المهمة، لمعرفة أيهما أقل انحرافًا عن المطلوب.
Q3: هل يجب كتابة وصف مفصل بهذا الشكل لكل مهمة صغيرة؟
لا. يمكن وضع القيود العامة وخلفية المشروع في ملف تعليمات على مستوى المشروع لإعادة استخدامها باستمرار، ثم إضافة الهدف والمواد المرجعية ومعايير القبول لكل مهمة فقط. أما التعديلات الصغيرة التي تستغرق بضع دقائق، فعادةً ما تكفيها جملة تحدد الهدف ومعياران أو ثلاثة للقبول.
Q4: ما أنواع الوكلاء والمهام التي تناسبها هذه الطريقة؟
تناسب هذه الطريقة أساسًا وكلاء البرمجة ووكلاء المهام ذات المخرجات المحددة، مثل إصلاح الأخطاء، وتنفيذ واجهات البرمجة، وإنشاء المستندات، وتنظيم البيانات. أما المهام الاستكشافية التي لم يتحدد هدفها بعد، فيصعب وضع معايير قبول واضحة لها مسبقًا؛ لذا من الأفضل أن يناقش الإنسان والوكيل الاتجاه أولًا قبل التنفيذ.
Q5: كيف أستخدم نماذج من مزودين مختلفين للمراجعة المتبادلة دون النسخ واللصق مرارًا؟
يمكنك كتابة برنامج نصي صغير يرسل نتيجة التنفيذ ووصف المهمة معًا إلى نماذج المراجعة، ثم يجمع ملاحظاتها. وباستخدام الواجهة الموحدة من APIYI apiyi.com، يكفي تغيير اسم النموذج في البرنامج لاستدعاء نماذج مزودين مختلفين، دون الحاجة إلى دمج حزمة SDK وإعداد حساب لكل مزود على حدة. وهذا مناسب لإنشاء نموذج أولي سريع لسير عمل يجمع بين «التنفيذ + المراجعة من عدة جهات».
Q6: ما حدود هذه الطريقة؟
أولًا، لا يمكنها أن تحل محل الحكم البشري في التصميم؛ فلا يزال الإنسان مسؤولًا عن المفاضلات المعمارية وتحديد أهداف المنتج. ثانيًا، إذا كُتبت معايير القبول بصورة خاطئة، فسيلتزم الوكيل بتلك المعايير الخاطئة. بالإضافة إلى ذلك، لا تتوفر حاليًا بيانات عامة تقيس الفروق في النتائج بين طرق الإعداد المختلفة. لذلك، يُنصح بإجراء مقارنة محدودة على مهامك الخاصة وتسجيل عدد مرات تصحيح المسار للاستفادة منها كمرجع.
سياق الوكيل ومعايير القبول: أهم النقاط
- غالبًا ما ينحرف الوكيل عن المسار بسبب نقص المعلومات: غياب الهدف أو القيود أو المواد المرجعية قد يؤدي إلى إعادة العمل.
- العناصر الخمسة لوصف المهمة: الهدف، والسياق، والقيود، والمواد المرجعية، ومعايير القبول؛ لا غنى عن أي منها.
- يجب أن تكون معايير القبول قابلة للتحقق: المعايير التي لا يستطيع الوكيل التحقق منها بنفسه ليست سوى أمنيات.
- حدد شروط التوقف: توضيح متى يجب على الوكيل التوقف وطرح الأسئلة يوفر جهد التصحيح لاحقًا.
- احسم قرارات التصميم مبكرًا: يحدد الإنسان خيارات البنية والمفاضلات المتعلقة بالمنتج أولًا، ثم يدوّنها ضمن القيود.
- استخدم المعايير نفسها للمراجعة المتقاطعة: يمكنك استدعاء نماذج من عدة مزودين عبر واجهة APIYI الموحدة لمقارنة المراجعات.
الخلاصة
يرجع جانب كبير من إرهاق الإنسان أثناء متابعة عمل الوكيل إلى عدم اكتمال المعلومات عند تسليم المهمة، مما يضطره إلى المراقبة المستمرة وتصحيح المسار. ولتجهيز المهمة مسبقًا، ركز على ثلاث نقاط:
- اكتب وصف المهمة في خمسة أقسام: الهدف، والسياق، والقيود، والمواد المرجعية، ومعايير القبول. هكذا يعرف الوكيل ما المطلوب، والمستوى المتوقع، وما لا يجوز المساس به.
- صغ معايير القبول في بنود قابلة للتحقق: اطلب من الوكيل مراجعتها بندًا بندًا وإعداد تقرير بالمطابقة، لتكتفي أنت بمراجعة الجدول والمسائل العالقة.
- ميّز بين المسائل التي يمكن معالجتها بتوفير السياق وتلك التي تتطلب مراجعة بشرية: احسم مفاضلات التصميم مسبقًا، واترك مسؤولية معايير القبول نفسها للإنسان.
ابدأ بمهمتك الفعلية التالية: اكتب معايير القبول أولًا، ثم استكمل بقية الأقسام، وسجّل عدد المرات التي احتجت فيها إلى التدخل أثناء العمل لتستفيد منها في التحسين. وإذا كنت تجرّب أيضًا المراجعة المتقاطعة باستخدام نماذج من عدة مزودين، فيمكنك استخدام واجهة APIYI الموحدة عبر apiyi.com للوصول إلى نماذج مختلفة، واختبارها على مهام فعلية لمعرفة أي مجموعة تقلل حاجتك إلى التدخل أكثر من غيرها.
📚 المراجع
- نقاش على V2EX – كيف نقلّل التدخل البشري لتمكين الوكيل من العمل باستقلالية وتحسين جودة التسليم: مصدر فكرة هذا المقال
- الرابط:
v2ex.com/t/1254207 - الوصف: يتناول إرهاق الإنسان عند المشاركة في دورة عمل الوكيل، ودور السياق، وفكرة المراجعة المتبادلة بين وكلاء من مزودين مختلفين
الكاتب: الفريق التقني في APIYI
التواصل التقني: نرحب بتواصلكم معنا عبر الصفحة الرئيسية لموقع APIYI على apiyi.com، لتبادل الخبرات العملية حول تعليمات مهام الوكلاء والتعاون بين النماذج المتعددة
