مثال افتراضي مفصّل · WEB-085

قائمة طلبات توضح الخطوة التالية

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

القواعد المتفق عليها في المثال

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

الرسائل الواردة وما يظهر في القائمة

سجل المتابعة والقائمة النهائية

SYN-101: أُسندت المهمة TASK-101 لعمر للتحقق من إمكانية التسليم في الموعد المطلوب. SYN-102: بانتظار أن تؤكد لينا رقم الطلب والتاريخ المحدد. SYN-103: بانتظار أن يتحقق سامي من طلب التغيير البنكي عبر المسار المنفصل. وفق السياسة الافتراضية، يراجع المسؤولان الطلبين المنتظرين في 4 أكتوبر 2026، ويتولى بديل مخوّل المهمة إذا غاب المسؤول. تظل الطلبات الثلاثة ظاهرة: طلب له مهمة داخلية وطلبان بانتظار المراجعة. لا إرسال ولا صرف ولا تغيير في طلب أو سجل بنكي.

مخطط سير العمل

فحوص قبل استخدام هذا التصميم

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

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

مراجع الطريقة

تدعم إرشادات أواسب تحديد الأدوات والصلاحيات وفحصها بصورة مستقلة والموافقة على الإجراءات المهمة. وتدعم إرشادات نيست وضوح مسؤوليات الإشراف البشري. هذه المراجع لا تثبت شهادة أو امتثالًا قانونيًا أو نتائج مقاسة.

أواسب: مخاطر الصلاحيات الواسعة · نيست: الإشراف والمسؤوليات