الأخطاء الشائعة وكيفية تجنّبها
تناولنا الأذونات وsandboxing والمراجعة الذاتية قبل الـpush. يختم هذا الدرس الوحدة بخمسة أخطاء تتكرر لدى كل من يعمل مع وكيل برمجي — لا لأن الوكيل 'سيّئ'، بل لأن كل واحد منها يختبئ تحديدًا في المكان الذي يسهل تخطّيه. المواضع الخمسة: تقرير يبدو مقنِعًا، وملف لم يره الوكيل قط، ونص خارجي يُقرأ كأنه تعليم
قبل الإقلاع، يمرّ الطيّار بندًا بندًا على قائمة تحقّق بدلًا من الوثوق بأن المحرّك 'يبدو سليمًا' — كل بند يحصل على فحصه الخاص، لأن تقريرًا عامًا واحدًا قد يُخفي عطلًا صغيرًا وخطيرًا.
- الإفراط في الثقة بمخرجات الوكيل
- قبول تقرير بلغة طبيعية مثل "غيّرته في كل المواضع الأربعة عشر" كحقيقة مؤكَّدة، دون أن تتحقّق بنفسك من أن الوصف يطابق الـdiff الفعلي في كل مكان.
- فجوة السياق
- عندما يفتقر الوكيل إلى ملف أو معلومة ذات صلة من المستودع، فإنه يفترض افتراضًا منطقيًا بناءً على ما رآه بالفعل — وقد يكون ذلك الافتراض خاطئًا دون أن ينتبه أحد.
- حقن التعليمات من محتوى مقروء
- تعليمة مخفية داخل نص خارجي طُلب من الوكيل تلخيصه أو قراءته فقط (تذكرة، صفحة ويب، README) — خطيرة لأن الوكيل قد يعاملها كأنها صادرة من المستخدم.
- سرّ متروك في تاريخ git
- مفتاح أو كلمة مرور دخلا في commit وأصبحا مرئيين لكل من لديه وصول إلى المستودع — حذف السطر في commit لاحق لا يزيله من تاريخ git، ولذلك يجب تدوير (rotate) المفتاح نفسه.
- مراجعة diff موجَّهة حسب المخاطر
- عندما يكون الـdiff أكبر من أن يُقرأ سطرًا سطرًا، تفحص أولًا الملفات الأكثر حساسية (الأمان، auth، rate-limiting) كلًّا على حدة، بدلًا من الوثوق بأنه 'مجرد rename آلي'.
