القواعد الأربع التي تجعل كل الأوامر أدناه تعمل
قبل الأوامر، إليك القواعد المشتركة بينها جميعًا. إضافة هذه القواعد إلى أي أمر برمجي تحسّن النتيجة أكثر من تغيير النموذج.
اذكر إصدارك. تميل بيانات التدريب نحو الإصدار الرئيسي الذي كُتب عنه أكثر، وغالبًا ليس الإصدار الذي تستخدمه أنت. جملة نحن نستخدم [الإطار] [الإصدار]، [اللغة] [الإصدار] تمنع معظم الإجابات المتقادمة.
قيّد حجم التغيير. اطلب إصلاحًا وستحصل غالبًا على إعادة هيكلة كاملة. جملة غيّر أقل قدر ممكن، حافظ على البنية والتسمية الحالية، واذكر كل سطر غيّرته مع سبب من سطر واحد هي الجملة الأكثر فائدة في هذا المستند بأكمله.
اطلب الفرضيات قبل الحلول. النموذج الذي يُسأل عمّا هو خاطئ يعطيك تخمينًا مقدَّمًا كاستنتاج. أما النموذج الذي يُطلب منه ترتيب الأسباب المحتملة مع فحوصات رخيصة، فيعطيك خطة تصحيح فعلية.
اطلب نمط الفشل. سؤال ما الذي يمكن أن يُعطّله هذا، وهل هذا يعالج السبب أم العرض؟ يكشف أخطر فئة من مساعدة الذكاء الاصطناعي، وهي التغيير الذي يُخفي العرض بينما يبقى الخلل قائمًا.
تصحيح الأخطاء
1. فرضيات مرتبة حسب الاحتمال
إليك الخطأ، والكود ذو الصلة، وما استبعدته بالفعل. لا تعطني حلًا بعد. اذكر الأسباب الأربعة الأكثر احتمالًا مرتبة حسب الاحتمالية، ولكل منها أرخص فحص واحد يمكن أن يؤكدها أو يستبعدها. الخطأ: [الصق هنا]. الكود: [الصق هنا]. ما استُبعد بالفعل: [قائمة]. البيئة التقنية: [اللغة، الإطار، الإصدارات].
2. الخطأ المتقطع
هذا يفشل بشكل متقطع، تقريبًا [التكرار]، تحت [الظروف]. عدّد فئات الفشل المتقطع التي يمكن أن تنتج هذا العرض بالتحديد: التوقيت، الترتيب، استنفاد الموارد، اعتمادية خارجية، تسرب حالة بين التشغيلات، الساعة أو المنطقة الزمنية، التخزين المؤقت. لكل فئة، اذكر ما في الكود يدعمها أو يناقضها، وما الذي يجب أن أسجّله بالضبط للتمييز بينها. الكود: [الصق هنا].
3. يعمل محليًا
هذا يعمل محليًا ويفشل في [البيئة]. اذكر كل فئة من فروقات البيئة يمكن أن تسبب هذا العرض بالتحديد: الإعدادات، متغيرات البيئة، الإصدارات، نظام الملفات وحساسية حالة الأحرف، المنطقة الزمنية واللغة، الشبكة ونظام DNS، الصلاحيات، حدود الموارد، وفروقات البناء أو التحزيم. رتّبها حسب الاحتمالية بناءً على العرض، وأعطني أمر التشخيص لكل واحدة.
4. اشرح الإصلاح قبل أن أعتمده
اشرح لماذا يعمل هذا الإصلاح، وما الذي لا يُصلحه، وما الذي يمكن أن يُعطّله. إذا كان السبب الحقيقي في مكان آخر وهذا مجرد ترقيع للعرض، فقل ذلك مباشرة.
مراجعة الكود
5. مراجعة تغيير (diff)
راجع هذا التغيير كمراجع صارم. الفئات مرتبة حسب الأولوية: أخطاء الصحة، مشكلات الأمان، أنماط الفشل غير المعالجة، حالات التسابق (race conditions)، ثم الأسلوب. لكل ملاحظة، اذكر مستوى الخطورة والسطر المحدد وسبب أهميتها في هذا الكود تحديدًا وليس بشكل عام. لا تعلّق على التنسيق. إذا كان التغيير سليمًا، فقل ذلك بدلًا من اختلاق ملاحظات. الأعراف المتبعة: [صِف]. التغيير: [الصق هنا].
6. فحص الأمان
راجع هذا الكود من ناحية الأمان تحديدًا: الحقن (injection)، ثغرات المصادقة والتفويض، إلغاء التسلسل غير الآمن، أسرار داخل الكود أو السجلات، مدخلات غير مُتحقَّق منها تصل إلى عملية حساسة، ومخاطر الاعتماديات. لكل واحدة، اذكر مسار الهجوم بشكل ملموس بدلًا من ذكر اسم الفئة فقط. اذكر بوضوح ما لا يمكنك تقييمه دون رؤية [بيئة النشر، طبقة المصادقة، حساسية البيانات].
7. تدقيق أنماط الفشل
لكل استدعاء خارجي في هذا الكود، اذكر ما يحدث عندما يكون بطيئًا، وعندما يفشل، وعندما يعيد بيانات غير متوقعة، وعندما ينجح جزئيًا فقط. أي من هذه الحالات غير معالج حاليًا، وأيها سيمر بصمت؟
هذا السؤال الأخير يكشف مشكلات إنتاج حقيقية أكثر مما تكشفه مراجعة عامة، لأنه يسأل عن المسارات التي لم يكتب أحد اختبارًا لها.
إعادة الهيكلة والبنية
8. خطة إعادة الهيكلة
اقترح خطة متسلسلة لإعادة هيكلة [الوصف]. القيود: الواجهة العامة لـ [س] لا يمكن أن تتغير، وننشر بشكل مستمر لذا يجب أن تكون كل خطوة قابلة للنشر بشكل مستقل، ويجب أن تنجح الاختبارات بعد كل خطوة. لكل خطوة، اذكر التغيير والمخاطرة وكيفية التحقق منها وكيفية التراجع عنها. رتّب حسب المخاطرة، الأقل أولًا. لا تكتب الكود بعد.
9. جادل عن الجانب الآخر
أنا أختار [النهج أ] على [النهج ب] لـ [السياق والقيود]. اطرح أقوى حجة ممكنة لصالح ب. ما الذي يجب أن يكون صحيحًا بشأن قيودنا حتى يكون ب هو الصحيح، وهل أي من ذلك صحيح هنا فعلًا؟ لا تستنتج أن كليهما صالح.
10. افهم ما ورثته
إليك ملفات المصدر الرئيسية. أنتج: نقاط الدخول، تدفق البيانات من الطلب إلى الاستجابة، الحالة المشتركة وأين يتم تغييرها، الاعتماديات الخارجية وما يحدث عند تعذّر كل منها، والمجالات الثلاثة الأكثر احتمالًا لاحتواء أخطاء بناءً على التعقيد والترابط. اذكر بوضوح ما لا يمكنك تحديده مما زودتك به.
هذه التعليمة الأخيرة مهمة. النماذج ستصف سلوك ملف لم تلصقه، مستنتجةً إياه من اسمه فقط. إجبار قائمة صريحة بالمجهولات يخبرك بما يجب أن تذهب لتقرأه.
الاختبارات
11. الاختبارات التي لم تكن لتكتبها
اكتب حالات اختبار لهذه الدالة، مع التركيز على المدخلات التي على الأرجح لم أفكر فيها: الحدود، القيم الفارغة والعدمية، يونيكود، القيم الكبيرة جدًا، الاستدعاءات المتزامنة، وأي افتراض ضمني في التنفيذ. لكل اختبار، اذكر الافتراض الذي يتحقق منه. الدالة: [الصق هنا].
12. اختبر مجموعة الاختبارات نفسها
إليك دالة واختباراتها الحالية. ما السلوك غير المغطى؟ تحديدًا: مسارات الأخطاء، القيم الحدية، التفاعلات بين المعاملات، وأي شيء يفعله التنفيذ ولا يتحقق منه أي اختبار. لا تعد كتابة الاختبارات الحالية.
الثاني هو الأمر الأعلى قيمة والأقل استخدامًا. نسب التغطية تخبرك بالأسطر التي نُفّذت، لا بالسلوكيات التي تم التحقق منها فعليًا، والفجوة بين الاثنين هي حيث تعيش الانحدارات (regressions).
نمط الرأي الثاني
العادة الأعلى قيمة في هذه الحزمة بأكملها، وهي الوحيدة التي تتطلب أكثر من نموذج واحد.
احصل على إجابة من نموذج واحد. ثم بدّل وسلّمها له:
اقترح مهندس آخر هذا الحل لهذه المشكلة. اكتشف ما الخطأ فيه: الصحة في الحالات الحدية، التزامن، معالجة الأخطاء، الأداء عند [الحجم]، أو نهج أبسط تم تفويته. إذا كان الحل سليمًا فعلًا، فقل ذلك بوضوح بدلًا من اختلاق اعتراضات. المشكلة: [الصق هنا]. الحل المقترح: [الصق هنا].
هناك نتيجتان وكلتاهما مفيدة. إما أن يجد النموذج الثاني ثغرة حقيقية، وهو ما تعرفه الآن قبل الدمج، أو يوافق رغم أنه دُفع للاختلاف، وهو تأكيد ذو معنى. التكرار مع النموذج نفسه لا يعطيك أيًا من الاثنين، لأن النموذج الذي يراجع مخرجاته الخاصة يوافق نفسه في الغالب.
استخدمه في القرارات التي سيكون الخطأ فيها مكلفًا: تغيير في المخطط، إصلاح تزامن، أي شيء يمس المصادقة أو المال. وليس في العمل الروتيني. راجع مقارنة النماذج جنبًا إلى جنب، وتبديل النماذج في منتصف المحادثة، وكتابة وتصحيح الكود باستخدام عدة نماذج لمعرفة سير العمل كاملًا في مكان واحد.
ما يجب الانتباه إليه
واجهات برمجية مُختلَقة. أسماء دوال ومعاملات ومفاتيح إعدادات تبدو واثقة لكنها غير موجودة، خصوصًا للمكتبات التي تغيّرت مؤخرًا. التوقيع سيبدو صحيحًا. تحقق من التوثيق الفعلي قبل البناء على أي شيء غير مألوف.
غياب إشارة الثقة. الإصلاح الصحيح والإصلاح الخاطئ بشكل دقيق يصلان بنفس درجة اليقين. النبرة لا تخبرك بشيء.
زحف نطاق صامت. هذا هو بالضبط سبب وجود القيد الثاني.
مسرحية أمنية. ذكر أسماء فئات الثغرات في كودك خطوة أولى مفيدة. لكنها ليست تدقيقًا أمنيًا، والنموذج لا يعرف نموذج التهديد لديك ولا بيئة النشر ولا حساسية البيانات.
احتفظ بالأوامر التي تستخدمها أسبوعيًا في مكان يمكنك اللصق منه، وضع القيود الثابتة في تعليمات المشروع لتُطبَّق تلقائيًا على كل محادثة في ذلك المشروع.
- اذكر لغتك وإطار العمل والإصدار في كل أمر برمجي
- أضف جملة تقييد حجم التغيير إلى أي أمر ينتج كودًا
- اطلب فرضيات مرتبة وفحوصات رخيصة قبل طلب الإصلاح
- اسأل دائمًا عمّا يمكن أن يُعطّله الإصلاح وهل يعالج العرض فقط
- طبّق نمط الرأي الثاني على أي شيء مكلف إن أخطأت فيه
- اسأل عمّا لا تغطيه مجموعة الاختبارات الحالية، وليس فقط عن اختبارات إضافية
- تحقق من الواجهات البرمجية غير المألوفة مقابل التوثيق الفعلي
- احتفظ بالأوامر التي تستخدمها أسبوعيًا في مكان يمكنك اللصق منه
الأسئلة الشائعة
هل تعمل هذه الأوامر مع Claude فقط؟
لا. كُتبت بأسلوب السياق الطويل والاستدلال الدقيق الذي يتفوق فيه Claude، لكنها تعمل مباشرة مع GPT وGemini أيضًا. بل إن بعضها أفضل عند استخدامه عبر نماذج مختلفة: أمر الرأي الثاني يتطلب نموذجين، وأمر "جادل عن الجانب الآخر" أكثر فائدة عندما لا يكون النموذج المجادل هو من اتخذ القرار الأصلي.
أي نموذج يجب أن أستخدمه لأي أمر؟
كنقطة بداية: Claude للاستدلال الدقيق والبنية غير المألوفة وشرح سبب سلوك شيء ما؛ GPT للتنفيذ السريع في أرض مألوفة وللمخرجات المهيكلة الصارمة؛ نموذج بسياق كبير عندما يتجاوز السؤال حجم الكود الذي يتسع بارتياح في أمر عادي. ثم عدّل ذلك بناءً على أسبوع من مقارناتك الخاصة، لأن الإجابة الصحيحة تعتمد على تقنياتك أكثر من أي مقياس مرجعي.
هل هذا بديل لأداة برمجة وكيلية (agentic)؟
لا، فهما يحلّان مشكلتين مختلفتين. الوكيل يعيش داخل مستودعك ويعدّل الملفات. هذه الأوامر مخصصة لطبقة الاستدلال: فهم خطأ، مراجعة تغيير، تخطيط إعادة هيكلة، مناقشة نهج. يستخدم معظم المطورين الاثنين معًا، واختيار النموذج هنا أكثر أهمية لأنك تقيّم الاستدلال وليس التغيير الناتج.
كيف أوقفه عن إعادة كتابة كود لم أطلبه؟
أضف هذا إلى الأمر: غيّر أقل قدر ممكن، حافظ على البنية والتسمية الحالية، واذكر كل سطر غيّرته مع سبب من سطر واحد. إعادة الهيكلة غير المطلوبة هي السبب الرئيسي الذي يجعل مقترحات الذكاء الاصطناعي غير قابلة للمراجعة، وتقييد حجم التغيير هو الفرق بين تغيير يمكنك تتبعه وآخر عليك إعادة قراءته من الصفر.
هل يمكنني لصق كود خاص بالملكية؟
لا تدرّب Whizi على محادثاتك، وسياسة بيانات كل مزود قابلة للمراجعة قبل أن تفعّل ذلك النموذج، لكن سياسة جهة عملك هي القيد الملزم وهي تختلف كثيرًا. حيث تنطبق القيود، إعادة إنتاج المشكلة كمثال مصغّر يحافظ على البنية ويحذف منطق العمل عادة مسموح وأفضل كأمر، لأنه يزيل التفاصيل التي كانت تنافس على الانتباه.