الخاص يغلب العام، دائمًا
الغريزة تدفعك إلى استخدام أداة واحدة متعددة الاستخدامات. تجنب ذلك. فالأدوات المحددة الاستخدام أسهل في الاستخدام الصحيح من قبل النموذج، كما أنها أسهل بكثير بالنسبة لك في تحليلها.
- لا تفعل
- run_query(sql). لقد منحت نموذج اللغة صلاحية الوصول غير المقيد إلى قاعدة البيانات. ولا توجد أي تعليمات تجعل هذه العملية آمنة.
- افعل
- find_invoices_by_vendor(vendor_id, from_date, to_date). قابلة للتعداد، ومحدودة النطاق، وقابلة للفهرسة، وأوضاع الفشل فيها معروفة.
- لا تفعل
- update_record(table, id, fields). نفس المشكلة من منظور مختلف.
- افعل
- set_invoice_gl_code(invoice_id, gl_code). ملاحظة واحدة: قابلة للتدقيق وقابلة للإلغاء.
الاختبار العملي: هل يمكنك تدوين كل الآثار التي يمكن أن تحدثها هذه الأداة، في شكل قائمة محدودة؟ إذا لم تتمكن من ذلك، فهذا يعني أنها عامة للغاية.
التحقق من صحة الطلب على أساس أن المتصل عدواني
ليس لأن النموذج قائم على التنافس، بل لأن مدخلاته قد تكون كذلك. فأي شيء يقرأه النموذج — سواء كان مستندًا أو رسالة بريد إلكتروني من عميل أو صفحة ويب — قد يحتوي على تعليمات، وعند استدعاء الأداة يتحول ذلك إلى إجراء.
- استخدم مخططات صارمة لضمان صحة الشكل قبل أن يراه الكود الخاص بك. قم بتعداد ما يمكن تعداده.
- أعد التحقق من صحة البيانات من جانب الخادم على أي حال. فالمخطط يضمن الشكل، ولا يضمن أن المعرّف ينتمي إلى هذا المستأجر.
- لا تحصل أبدًا على الأذونات من النموذج. فهوية السائل مستمدة من جلستك، ويتم تحديدها من جانب الخادم. وأي أداة تقبل معلمة user_id هي أداة يمكن توجيهها للتصرف بصفتها شخصًا آخر.
- تحديد كل شيء: عدد النتائج، ونطاقات التواريخ، والمبالغ. الاستعلام غير المحدد هو بمثابة عطل ينتظر الإدخال الصحيح.
افترض أن أي نص قرأه النموذج غير موثوق به. والقاعدة السارية هي: يمكن للمحتوى أن يُسترشد به في الإجابة، لكنه لا يمكن أن يبرر أبدًا اتخاذ إجراء ما.
الفصل بين القراءة والكتابة
تستحق عمليات القراءة والكتابة معاملة مختلفة، والدمج بينهما هو ما يجعل ميزة التلخيص تتحول إلى ميزة النشر.
- بيانات اعتماد مختلفة. يُمنح مسار القراءة دورًا لا يسمح بالكتابة، ويتم فرض ذلك من قِبل قاعدة البيانات، وليس عن قصد.
- يتم ترقيم عمليات الكتابة بشكل فردي، وتسجيلها بشكل فردي، ويمكن التراجع عنها بشكل فردي.
- يحمل كل عملية كتابة مفتاحًا للتكرار المستمد من العمل، لذا فإن إعادة محاولة استدعاء الأداة لا تؤدي إلى أي تأثير.
- تخضع الرسائل التي يتجاوز حجمها الحد الأدنى الذي تختاره لعملية موافقة. ويعتمد تحديد هذا الحد الأدنى على المجال؛ أما وجوده بحد ذاته فليس شرطًا.
الأخطاء جزء من الواجهة
يقوم النموذج بقراءة الخطأ الذي حدث ويقرر الإجراء التالي. فالرسالة الجيدة تؤدي إلى استعادة النظام، أما الرسالة السيئة فتؤدي إلى حلقة إعادة المحاولة أو إلى إجابة مختلقة.
- اذكر ما الذي حدث من خطأ وما الذي يمكن أن ينجح بدلاً من ذلك. فعبارة «لا توجد فواتير في تلك الفترة؛ أقرب تاريخ هو 2026-03-01» تسمح للنظام بتصحيح الخطأ بنفسه، بينما عبارة «خطأ 400» لا تسمح بذلك.
- التمييز بين المدخلات الخاطئة وفشل النظام. يجب تصحيح الأولى، أما الثانية فيجب إحالتها إلى شخص.
- Never return a stack trace or an internal identifier. It ends up in an answer.
- اجعل المكالمة الفاشلة تظهر بوضوح في النص، حتى لا تعامل الحلقة سلسلة الخطأ على أنها بيانات.
نحن نتعامل مع رسائل أخطاء الأدوات على أنها «هندسة فورية»، لأن هذا هو جوهرها. يتم قراءتها بواسطة النموذج نفسه، وفي السياق نفسه، وتؤدي إلى تغيير السلوك بنفس القدر.
هل تريد أن ننفّذ هذا معك؟
التدقيق هو هذه المنهجية موجّهة إلى أنظمتك، وفي نهايته خطة بناء مُسعّرة.
تحديد موعد مكالمة