كيفية طرح الأسئلة وتقديم التوجيهات: وجه حديثك إلى صميم قلب Claude
📚 التنقل في السلسلة: المقال السابق 14 واجهة التفاعل والاختصارات علمك كيفية وضع أصابعك في المكان الصحيح — حيث اعتدت على المؤشر، ومفتاح Enter، ومفتاح Esc، وأوامر الشرطة المائلة. يأخذك هذا المقال إلى مستوى آخر: الآن بعد أن عرفت يداك أين تضغط، يجب أن يعرف لسانك كيف يتكلم. فنفس الطلب يمكن أن يختلف إنجاز Claude له تمامًا بناءً على مدى جودة صياغتك للتوجيه.
لنكن صريحين تمامًا: عند بدء استخدام Claude Code لأول مرة، تعامل معه الكثيرون كأنهم يتعاملون مع محرك بحث.
تخيل هذا السيناريو: يظهر خطأ في إحدى دوال المشروع، فتقوم مباشرة بإلقاء عبارة «أصلح هذا الخطأ (bug)»، دون تحديد الملف أو حتى تفاصيل الخطأ، ثم تضغط Enter وتنتظر النتيجة. لينتهي به المطاف بـ "تخمين" خطأ يعتقد هو أنه المطلوب، ويقوم بتعديل ثلاثة ملفات، وليس من بينها الملف الذي كنت تريد إصلاحه فعليًا. وتجد نفسك محدقًا في شاشة مليئة بـ diff ومصعوقًا، وتتمتم في نفسك قائلاً «هذا الذكاء الاصطناعي لا يعمل بشكل جيد».
ولكن عند التفكير مليًا ستدرك — الخلل ليس فيه. المشكلة لا تكمن في Claude على الإطلاق، بل في صياغة تلك الجملة الرديئة: فحجم المعلومات فيها يقارب الصفر، مما يضطره للاعتماد بالكامل على التخمين وسد الفجوات. وإذا خمن بشكل خاطئ، فمن نلوم؟
دعنا نقولها بصراحة: سقف قدرات Claude Code محكوم إلى حد كبير بطريقتك في طرح الأسئلة. فنفس النموذج ونفس المشروع يمكن لمن يجيد تقديم المتطلبات أن ينجزه في ثلاث جمل، بينما يتخبط من لا يجيد الصياغة لخمس جولات ويعود خالي الوفاض وممتلئًا بالإحباط. سنشرح لك اليوم بالتفصيل قواعد الصياغة العامة لـ "كيفية توضيح الطلب في جملة واحدة" — وليس الهدف تعليمك قوالب تحفظها، بل دفعك لفهم "ما الذي يحتاج Claude لمعرفته بدقة لتجنب الخروج عن المسار".
بعد قراءة هذا المقال، ستحصل على:
- جدول مقارنة بين "الأسئلة الرديئة مقابل الأسئلة الجيدة"، لتعديل طريقتك وتقليل إعادة العمل فورًا
- أربع قواعد أساسية لتقديم المتطلبات: التحديد، وتوفير السياق، وتحديد معايير القبول، وإعداد خطة للمهام المعقدة أولاً
- الطريقة الصحيحة لاستخدام الرمز
@للإشارة للملفات وتحديد النطاق بدقة - تطبيق عملي للمقارنة بين "طريقتين للتعبير عن نفس الطلب" لتشاهد الفارق بنفسك
01 أين يكمن الخلل في الأسئلة الرديئة
دعنا نحلل هذا الإخفاق بالتفصيل. عبارة "أصلح هذا الخطأ" تفتقر تمامًا للمعلومات من وجهة نظر Claude:
- أي خطأ؟ يجب عليه أن يخمن الخطأ الذي تقصده.
- أي ملف؟ يجب عليه البحث في المشروع بأكمله.
- ما هو السلوك الصحيح المتوقع؟ هو لا يعرفه على الإطلاق، وسيضطر لتخمينه بناءً على "ما يجب أن يكون عليه الأمر عادة".
تشبيه: تدريب موظف جديد. إذا قلت لمتدرب انضم حديثًا للعمل "رتب هذا الشيء"، فستكون معجزة لو قام به بشكل صحيح. ولكن إذا قلت له "غير لون زر تسجيل الدخول في أعلى يمين الصفحة الرئيسية من الرمادي إلى الأزرق المعتمد للعلامة التجارية #1A73E8"، فسيقوم بذلك بشكل صحيح وهو مغمض العينين. كلما كانت التعليمات محددة، تجنب الموظف الجديد الخطأ؛ وكلما ألقيت عبارات مبهمة، اضطر للتخمين وزاد احتمال وقوعه في الخطأ. ينطبق هذا على Claude تمامًا.
إليك جدول مقارنة مبسط ومترجم بناءً على الوثائق الرسمية:
| السيناريو | ❌ سؤال رديء | ✅ سؤال جيد |
|---|---|---|
| إصلاح الأخطاء | "أصلح خطأ تسجيل الدخول" | "أبلغ المستخدمون عن فشل تسجيل الدخول بعد انتهاء الجلسة. افحص مسار المصادقة في src/auth/ مع التركيز على تجديد token. اكتب اختبارًا فاشلاً لإعادة إنتاج المشكلة أولاً، ثم قم بإصلاحها" |
| كتابة الاختبارات | "أضف اختبارات لـ foo.py" | "اكتب اختبارات لـ foo.py تغطي الحالات الحدية للمستخدمين الذين سجلوا خروجهم بالفعل، وتجنب استخدام mock" |
| الاستفسار عن الكود | "لماذا تم تصميم API ExecutionFactory السيئ بهذا الشكل؟" | "راجع تاريخ git لـ ExecutionFactory ولخص كيف تطور الـ API الخاص به خطوة بخطوة ليصل للشكل الحالي" |
| إضافة ميزة | "أضف مكون تقويم" | "تحقق أولاً من كيفية تنفيذ المكونات الحالية في الصفحة الرئيسية، ويعد HotDogWidget.php مثالاً جيدًا. اتبع هذا النمط لتنفيذ مكون تقويم يتيح للمستخدمين اختيار الشهر والتنقل بين السنوات للأمام والخلف. وتجنب إدخال أي مكتبات جديدة غير موجودة بالفعل في المشروع" |
هل لاحظت الفارق؟ الأسئلة الجيدة تشترك في أمر واحد: تقديم المعلومات التي كان سيضطر Claude لتخمينها مسبقًا.
💡 خلاصة في جملة واحدة: تكمن رداءة الأسئلة في "اعتماد سد فجوات المعلومات بالكامل على تخمين Claude"، بينما يتمثل السؤال الجيد في توضيح ما كان سيخمنه مسبقًا.
يعرض هذا الرسم التوضيحي للمقارنة طريقتين للتعبير عن نفس الطلب: على اليسار سؤال مبهم، يضطر Claude معه للتخمين وطرح الكثير من الأسئلة الاستيضاحية؛ وعلى اليمين تم توفير النطاق والسياق (@ملف) ومعايير القبول معًا، ليصيب الهدف مباشرة ويقوم بتشغيل الاختبارات وتمريرها بنجاح. الفارق ليس في Claude، بل في طريقتك في التعبير.
02 القاعدة الأولى: التحديد أفضل من الإبهام
هذه هي القاعدة الأهم بين القواعد الأربع على الإطلاق.
هناك عبارة تستحق الحفظ في الوثائق الرسمية، ونصها هو:
كلما كانت توجيهاتك أكثر دقة، قل عدد التصحيحات التي ستحتاج إليها.
وبعبارة أبسط: توفير جملة إضافية في البداية يوفر عليك ثلاث جولات من إعادة العمل لاحقًا. قد تظن أن "توفير الوقت" يكمن في كتابة كلمات أقل، ولكن هذه الكلمات القليلة التي وفرتها ستتحول لاحقًا إلى جولات طويلة ومضاعفة من النقاش والتعديل.
إلى أي مدى يجب أن تكون محددًا؟ قم بتضمين ثلاثة أبعاد في توجيهك:
أولاً، تحديد النطاق — أي ملف، وأي دالة، وأي سيناريو. لا تدعه يبحث كإبرة في كومة قش بالمشروع بأكمله.
ثantiًا، توضيح القيود — "لا تستخدم مكتبات جديدة"، "حافظ على التوافق الخلفي"، "لا تقم بتعديل ملفات الاختبار". إذا لم تذكر هذا، سيعمل وفقًا لتفضيلاته الخاصة، وقد لا ترضيك النتيجة لاحقًا.
ثالثًا، الإشارة إلى مرجع — "اتبع نمط HotDogWidget.php". هذه الطريقة هي الأكثر راحة من خلال تجربتنا العملية: بدلاً من وصف النمط الذي تريده بالكلمات، قدم له مباشرة مثالاً جاهزًا يرضيك، ليقوم باتباعه ومحاكاته بدقة كبيرة.
هناك استثناء يخالف البديهة تجدر الإشارة إليه: الأسئلة المبهمة ليست خطأً في جميع الأحوال. فعندما تكون في "مرحلة الاستكشاف" ولم تحدد الاتجاه بنفسك بعد، فإن عبارة مفتوحة مثل "ما الذي تعتقد أنه يمكن تحسينه في هذا الملف؟" قد تكشف لك عن نقاط لم تكن تفكر في السؤال عنها أساسًا. تصف الوثائق الرسمية هذا بقولها: "عندما تستكشف وتكون قادرًا على تصحيح المسار، قد تكون التوجيهات المبهمة مفيدة جدًا". القاعدة هنا هي: كن محددًا للغاية عندما تبحث عن نتائج دقيقة، واترك مساحة للمرونة عندما تبحث عن إلهام وأفكار.
من السهل الوقوع في هذا الفخ عند تطوير أدوات صغيرة — في البداية قد ترغب فقط في رؤية كيف يفهم Claude كودًا غير منظم، فتسأل بشكل عام، وتعطيك اقتراحات التحسين بعض الأفكار المفيدة؛ ولكن بمجرد أن يصبح لديك هدف محدد، فإن استخدام الأسئلة العامة يصبح إهدارًا للوقت والجلسات، حيث سيضطر في كل مرة لإعادة تخمين ما تريده بدقة.
💡 خلاصة في جملة واحدة: كن محددًا لأقصى حد عند البحث عن نتيجة مؤكدة (النطاق + القيود + المراجع)，واترك مساحة للمرونة فقط عندما تبحث عن إلهام وأفكار.
03 القاعدة الثانية: توفير السياق وتجنب جعله يخمن
بالإضافة للتحديد، تتمثل الخطوة الثانية في تقديم المواد المطلوبة مباشرة له بدلاً من الاكتفاء بوصف مكان وجودها.
هناك حركتان هما الأكثر استخدامًا، وحفظهما يكفي لمعظم الحالات:
أولاً، استخدام الرمز @ للإشارة للملفات. كتابة @ في مربع الإدخال تظهر قائمة الإكمال التلقائي لمسارات الملفات، وعند اختيار الملف يتم تضمين محتوى الملف بالكامل مباشرة في المحادثة — مما يغني Claude عن البحث عن الملف ثم قراءته، مما يختصر خطوة ويمنع أخطاء البحث.
بالإشارة إلى تعريفات الأنواع في @src/types/user.ts، قم بإضافة تعليقات الأنواع (types) لـ UserServiceهذا أفضل بكثير من القول المبهم "هناك ملف لأنواع المستخدم في المشروع، ابحث عنه". تؤكد الوثائق الرسمية أن الإشارة بـ @ تقوم بـ "قراءة المحتوى الكامل للملف قبل توليد الاستجابة".
تشبيه: منفذ USB. تشبه الإشارة بـ @ إدخال "ذاكرة USB تحتوي على الملفات" مباشرة في منصة عمل Claude — حيث تتوفر له البيانات فورًا؛ بينما يعني الاكتفاء بالقول الشفهي "البيانات موجودة في الخزانة الثانية بغرفة الملفات بالطابق الثالث" اضطراره للذهاب والبحث، وإذا ذهب للمكان الخطأ فسيتعطل العمل.
ثانياً، لصق تفاصيل الخطأ بالكامل مباشرة. هذه الخطوة تستحق أن تصبح جزءًا من ذاكرتك العضلية — عند مواجهة traceback، لا تكتفي بوصف "أنه يظهر خطأ مؤشر فارغ"، بل انسخ سجل التتبع بالكامل والصقه مباشرة:
运行时报了这个错，帮我定位原因：
TypeError: Cannot read properties of null (reading 'userId')
at getUserProfile (src/services/user.ts:42:18)
at async ProfileController.getProfile (src/controllers/profile.ts:15:20)لماذا نلصق التتبع بالكامل؟ لأن السجل يحتوي على أسماء الملفات وأرقام الأسطر وسلسلة الاستدعاءات بالكامل، مما يتيح لـ Claude تحديد المشكلة بدقة بالانتقال مثلاً لـ user.ts:42. أما اختصارك للخطأ فيعني حذف هذه الإحداثيات الهامة، واضطراره للتخمين مجددًا.
إليك جدول تصنيف كيفية توفير المواد:
| المادة التي تريد تقديمها | ❌ وصف شفهي | ✅ تقديم مباشر |
|---|---|---|
| محتوى ملف معين | "هناك ملف في المشروع يتعامل مع المصادقة" | @src/auth/session.ts |
| تفاصيل خطأ معين | "يظهر خطأ يشير لـ undefined" | انسخ سجل traceback بالكامل والصقه كما هو |
| مشكلة في واجهة المستخدم (UI) | "موقع الزر غير صحيح" | الصق لقطة الشاشة مباشرة (حيث يدعم Claude قراءة الصور) |
| مواصفات واجهة برمجة التطبيقات (API) | "اتبع مواصفات الـ API الخاصة بنا" | @docs/api-spec.md |
باختصار: ما يمكن لصقه، لا تصفه بالكلمات أبدًا. فقراءة Claude للمواد الأصلية تكون دائمًا أكثر دقة من قراءته لوصفك الثانوي لها.
💡 خلاصة في جملة واحدة: استخدم
@للإشارة للملفات، والصق تفاصيل الأخطاء ولقطات الشاشة مباشرة أمامه، وتجنب جعله يبحث استنادًا إلى وصفك.
04 固定معايير نجاح「قابلة للتحقق」
هذه القاعدة هي الأكثر عرضة للتجاهل، لكنها ذات تأثير بالغ: يجب أن يعرف Claude "ما الذي يمثل نجاح المهمة"، ويُفضل أن يكون قادرًا على التحقق من ذلك بنفسه.
لماذا تعد هذه النقطة بالغة الأهمية؟ توضح الوثائق الرسمية المنطق الكامن خلفها:
عندما يبدو أن العمل قد اكتمل، سيتوقف Claude. وفي غياب أي عمليات تحقق يمكنه تشغيلها، يصبح "المظهر المكتمل" هو الإشارة الوحيدة المتاحة، وتصبح أنت حلقة التحقق؛ حيث ينتظر كل خطأ أن تلاحظه بنفسك.
وبعبارة أبسط: إذا لم تحدد معايير، فسيتوقف Claude عن العمل بمجرد "شعوره بأن العمل قد اكتمل تقريبًا"، مما يجعلك أنت الشخص المسؤول عن مراجعة وتدقيق العمل، وعليك اكتشاف كل ثغرة بنفسك. ولكن بمجرد تزويده بعملية تحقق ترجع نتيجة "نجاح / فشل"، ستغلق هذه الحلقة تلقائيًا: حيث ينهي العمل ← يشغل التحقق ← يرى النتيجة ← وإذا فشل التحقق يستمر في التعديل، دون أي حاجة لمتابعتك المستمرة.
المقارنة بين الحالتين:
| المهمة | ❌ غياب معيار القبول | ✅ توفير معيار قابل للتحقق |
|---|---|---|
| كتابة دالة | "قم بتنفيذ دالة للتحقق من البريد الإلكتروني" | "اكتب دالة باسم validateEmail. الحالات التجريبية: user@example.com ترجع true، و invalid ترجع false، و user@.com ترجع false. قم بتشغيل الاختبار بعد الانتهاء" |
| تعديل واجهة المستخدم (UI) | "اجعل لوحة التحكم هذه تبدو أفضل" | "[ألصق التصميم] نفذ هذا التصميم، ثم خذ لقطة شاشة للنتيجة وقارنها بالتصميم الأصلي، وحدد الاختلافات وقم بإصلاحها" |
| إصلاح البناء (Build) | "عملية البناء فشلت" | "يظهر هذا الخطأ أثناء البناء: [الصق الخطأ]. قم بإصلاحه وتأكد من نجاح عملية البناء. قم بحل المشكلة من جذورها وتجنب مجرد إخفاء الخطأ" |
انتبه للعبارة الأخيرة "قم بحل المشكلة من جذورها وتجنب مجرد إخفاء الخطأ" — هذه نصيحة كتبناها بعد التعلم من الأخطاء السابقة. إذا لم تضفها، فقد يسهل عليه الأمر أحيانًا بلف الكود بعبارة try/except أو إضافة @ts-ignore لإزالة الخطأ الظاهري، وبذلك يختفي الخطأ ولكن تظل المشكلة الأساسية قائمة.
طريقة متقدمة: استخدام الأداة /goal لجعل معايير القبول شرطًا لإنهاء العمل. (يتطلب إصدار Claude Code v2.1.139 أو أحدث). تحديد معيار القبول في السؤال العادي يعني "تشغيل الفحص لهذه الجولة فقط"；بينما استخدام /goal يثبت هذا المعيار كهدف للجلسة بأكملها — فبعد كل جولة، سيقوم نموذج صغير (مثل Haiku افتراضيًا) بمراجعة العمل وفق شروطك، وإذا لم تتحقق الشروط سيبدأ جولة جديدة تلقائيًا دون إرجاع التحكم إليك، ويستمر في ذلك حتى تتحقق الشروط بالكامل.
/goal نجاح جميع الاختبارات في test/auth وخلو خطوة lint من الأخطاءهناك تفصيل هام عند استخدام /goal لتجنب المشاكل: يقوم النموذج الصغير المسؤول عن التقييم بقراءة ما يقوم Claude "بعرضه" في المحادثة فقط، ولا يمكنه تشغيل الأوامر أو قراءة الملفات بنفسه. لذلك يجب أن تكون شروطك قابلة للإثبات من خلال مخرجات Claude نفسه — فشرط "نجاح جميع الاختبارات في test/auth" يتحقق لأن Claude سيقوم بالفعل بتشغيل الاختبارات وطباعة النتائج في المحادثة، مما يتيح لنموذج التقييم قراءتها. أما كتابة شروط مثل "أن تكون جودة الكود عالية" والتي لا يمكن التحقق منها عبر المخرجات النصية المباشرة، فلن يتمكن النموذج من تقييمها.
💡 خلاصة في جملة واحدة: زوده بعملية تحقق ترجع نتيجة نجاح / فشل (اختبارات، مقارنة لقطات شاشة، رموز الخروج لعملية البناء) لتغلق حلقة التحقق تلقائيًا؛ وإذا أردت ألا يتوقف حتى تتحقق الشروط تمامًا، استخدم
/goal.
05 القاعدة الرابعة: في المهام المعقدة، اطلب منه وضع خطة أولاً قبل البدء بالعمل
القاعدة الأخيرة مخصصة لـ "المهام الكبيرة": عند مواجهة مهام تتضمن تغييرات كبيرة، أو تؤثر على ملفات متعددة، أو إذا كنت غير متأكد من المسار بنفسك، لا تدعه يبدأ في الكتابة مباشرة — بل اطلب منه إعداد خطة أولاً لتراجعها قبل السماح له بالبدء.
لقد أشرنا إلى هذا في المقال 06 (الحزم والأسعار)، ودعنا نوضح السبب هنا بالتفصيل. تشير الوثائق الرسمية بوضوح إلى:
قد يؤدي جعل Claude يقفز مباشرة إلى البرمجة إلى كتابة كود يحل المشكلة الخطأ.
وبعبارة أخرى، الاستكشاف أولاً، ثم التخطيط، ثم البرمجة — افصل مرحلة "التفكير والفهم" عن مرحلة "التنفيذ والعمل"، لتجنب اندفاعه في اتجاه خاطئ وإجراء تعديلات كثيرة قبل أن تكتشف ذلك.
تشبيه: إعداد المخططات أولاً قبل هدم الجدران عند التجديد. لن يقوم أي عامل بناء محترف بمسك المطرقة وهدم جدار حامل دون مناقشة. بل سيتأكد معك أولاً "أين سيتم هدم الجدران، وتمديد الأسلاك، وتغيير مسار الأنابيب"، ولن يبدأ العمل إلا بعد موافقتك. الخطة هي المخطط الذي يقدمه لك Claude قبل البدء بالعمل — وتعديل المخطط عند اكتشاف خطأ فيه يكون أقل كلفة بكثير من إعادة البناء بعد هدم الجدران فعليًا.
كيف نجعله يقدم خطة أولاً؟ هناك طريقتان:
الطريقة الأولى: التوضيح صراحة في النص بألا يقوم بالتعديل فورًا. فقط أضف قيدًا بسيطًا في المحادثة العادية:
أريد إضافة مفتاح للوضع الداكن في صفحة الإعدادات. أخبرني أولاً بالملفات التي يجب تعديلها وما هي فكرة التعديل،
ولا تقم بتعديل أي كود في هذه الخطوة.الطريقة الثانية: الانتقال إلى Plan Mode (وضع التخطيط). هذا وضع مخصص لـ "التخطيط للقراءة فقط" في Claude Code — حيث يقرأ الملفات ويقترح الحلول، ولكنه لن يقوم بكتابة أي حرف على القرص قبل موافقتك. طريقة الدخول: اضغط على Shift + Tab في الجلسة للتنقل بين الأوضاع دائريًا (default → acceptEdits → plan). وإذا كنت تريد تشغيل توجيه محدد فقط في وضع التخطيط دون تغيير وضع الجلسة بأكملها، أضف البادئة /plan قبل تلك الرسالة.
ومع ذلك، تقدم الوثائق الرسمية نصيحة عملية بعدم المبالغة في استخدام وضع التخطيط لكل شيء:
بالنسبة للمهام ذات النطاق الواضح والإصلاحات البسيطة (مثل إصلاح الأخطاء الإملائية، أو إضافة أسطر تسجيل الأحداث، أو إعادة تسمية المتغيرات)، اطلب من Claude التنفيذ مباشرة. ويكون التخطيط مفيدًا للغاية عندما تكون غير متأكد من الطريقة، أو عندما تتضمن التغييرات ملفات متعددة، أو عندما لا تكون ملمًا بالكود الذي يتم تعديله. إذا كنت تستطيع وصف التعديلات (diff) في جملة واحدة، فتجاوز التخطيط.
النصيحة الأكثر عملية هي النصف الأخير من الجملة السابقة: "هل يمكنك وصف التعديلات الناتجة في جملة واحدة؟" إذا كانت الإجابة بنعم، ابدأ مباشرة؛ وإذا تعثرت، فهذا يعني أن المهمة معقدة وتطلب إعداد خطة أولاً. تشغيل وضع التخطيط لإصلاح خطأ إملائي بسيط هو مجرد تعقيد لا داعي له.
💡 خلاصة في جملة واحدة: إذا كنت غير متأكد / التعديل يؤثر على ملفات متعددة / الكود غير مألوف لديك ← اطلب منه إعداد خطة أولاً (عبر إضافة عبارة "لا تقم بالتعديل الآن" أو الضغط على
Shift+Tabللانتقال لوضع Plan Mode)؛ أما المهام البسيطة التي يمكن وصف تعديلاتها بجملة واحدة فابدأ بتنفيذها مباشرة.
06 عملي: طريقتان لطرح نفس الطلب وتوضيح الفارق
رؤية التطبيق العملي أفضل من مجرد قراءة النظريات، دعنا نجرِ تجربة صغيرة لتشاهد الفارق بنفسك. سنحتاج فقط لملف تجريبي بسيط من ثلاثة أسطر، دون الحاجة لأي مشروع حقيقي.
الخطوة الأولى: إنشاء ملف تجريبي يحتوي على ثغرة (Mac / Linux)
mkdir prompt-demo
cd prompt-demo
echo 'def average(nums):
return sum(nums) / len(nums)' > stats.pyلمستخدمي Windows: mkdir prompt-demo و cd prompt-demo كما هي، ثم أنشئ ملف stats.py باستخدام المفكرة والصق السطرين فيه.
تحتوي هذه الدالة على ثغرة: عند تمرير قائمة فارغة []، ستكون قيمة len(nums) هي 0، مما يؤدي لخطأ "القسمة على صفر" والانهيار. سنستخدم هذا الملف كحقل للتجربة.
الخطوة الثانية: تشغيل Claude في دليل المشروع
claudeالنتيجة المتوقعة: تظهر شاشة الترحيب وبها مربع الإدخال في الأسفل.
الخطوة الثالثة: تجربة "سؤال رديء" أولاً لملاحظة كيف يقوم بالتخمين
@stats.py 帮我改改这个函数النتيجة المتوقعة: سيقوم Claude على الأرجح بـ "تخمين" ما تريده — ربما يضيف تعليقات الأنواع (types) أو يضيف نصوص التوثيق (docstrings)، ولكنه لن يعرف أن ما يهمك فعليًا هو تجنب انهيار القائمة الفارغة، وسيعتمد الاتجاه بالكامل على الحظ. هذا هو ثمن الأسئلة المبهمة: أنه يتخذ القرارات نيابة عنك.
الخطوة الرابعة: التبديل إلى "سؤال جيد" — بتوفير التحديد والسياق ومعايير القبول معًا
@stats.py 里的 average 函数有个 bug：传入空列表时会因为除以零而崩溃。
期望行为是空列表返回 0。
帮我修复，并补一个测试：average([]) 应该返回 0、average([2, 4]) 应该返回 3。
写完把测试跑一遍，确认通过。النتيجة المتوقعة: ستكون سلسلة خطوات Claude واضحة تمامًا هذه المرة — تحديد حالة القائمة الفارغة ← إضافة شرط العودة بالقيمة 0 ← كتابة حالتي الاختبار اللتين حددتهما ← تشغيل الاختبارات فعليًا ← وعرض نتائج النجاح لك. لن يضطر لتخمين ما تريده بعد الآن لأنك قمت بتحديد "مكان الإصلاح، والنتيجة المتوقعة، ومعيار النجاح" بدقة بالغة.
الخطوة الخامسة: الخروج والتحقق من حفظ التعديلات
cat stats.py(لـ Windows PowerShell استخدم type stats.py)
النتيجة المتوقعة: سيظهر في ملف stats.py شرط للتعامل مع القائمة الفارغة (مثل if not nums: return 0). تطابق النتيجة مع ما طلبته في الخطوة الرابعة يعني أنك بدأت تتقن مهارة "الصياغة الواضحة".
المقارنة بين الخطوتين:
| الخطوة الثالثة ❌ سؤال رديء | الخطوة الرابعة ✅ سؤال جيد | |
|---|---|---|
| مكان التعديل | لم يتم تحديده، واضطر للبحث في الملف بالكامل | الإشارة المحددة لدالة average |
| النتيجة المطلوبة | لم يتم تحديدها، وتُركت لتقديره | إرجاع القيمة 0 عند القائمة الفارغة بشكل محدد |
| معيار النجاح | لا توجد معايير، وتوقف بمجرد "شعوره" بالاكتمال | حالتا اختبار + تشغيل الفحص للتحقق |
| تجربتك كمستخدم | تحدق في التعديلات مستغربًا "ليس هذا ما أردته" | سيعمل بدقة وفقًا للسيناريو الذي حددته، ويمرر بنجاح من المرة الأولى |
💡 خلاصة في جملة واحدة: لنفس الملف ونفس الثغرة، يؤدي السؤال الرديء إلى جعل Claude يتخذ القرارات نيابة عنك، بينما يحدد السؤال الجيد "مكان الإصلاح، والنتيجة المتوقعة، ومعيار النجاح" بدقة — وتشغيل هذه التجربة عمليًا يعرض لك الفارق بشكل أكثر وضوحًا من قراءة القواعد نظريًا.
07 ملخص
شرح هذا المقال أمرًا واحدًا فقط: كيف تصوغ توجيهك في جملة واحدة ليفهمك Claude بدقة.
إليك جدولاً يلخص القواعد الأربع الأساسية لتستعين به:
| القاعدة | باختصار | كيفية التطبيق |
|---|---|---|
| التحديد أفضل من الإبهام | حدد النطاق والقيود والمراجع بوضوح | "قم بتعديل average دون استخدام مكتبات جديدة، واتبع نمط xxx" |
| توفير السياق | ما يمكن لصقه، لا تصفه شفهيًا | الإشارة بـ @file، لصق الأخطاء بالكامل، ولصق لقطات الشاشة |
| توفير معايير القبول | دعه يتحقق بنفسه من "نجاح المهمة" | حدد حالات الاختبار واطلب تشغيل الفحص؛ أو استخدم /goal في المهام الصعبة |
| إعداد خطة أولاً | راجع المخططات أولاً قبل هدم الجدران | أضف عبارة "لا تقم بالتعديل الآن" أو اضغط على Shift+Tab للانتقال لوضع Plan Mode |
من المفترض الآن أن تكون قادرًا على: تحويل طلب مبهم مثل "ساعدني في التعديل" إلى متطلبات واضحة يستطيع Claude التعامل معها بدقة — عبر تحديد النطاق، وتوفير السياق، وتقديم معايير نجاح قابلة للتحقق، وإإعداد خطة مسبقة للمهام المعقدة. تعد قواعد الصياغة هذه هي الأساس لكل تفاعلاتك القادمة مع Claude Code — فمهما كانت الميزات متقدمة، فإن إدخال توجيهات رديئة سينتج عنه دائمًا عمل غير مرضٍ.
فكر في هذا السؤال المطروح عليك: إذا كانت "الصياغة الواضحة" بهذه الأهمية، فهل ستحتاج لتكرار بعض القواعد (مثل "لا تستخدم مكتبات جديدة في هذا المشروع أبدًا" أو "يجب وضع جميع الاختبارات في مجلد
tests/"）في كل مرة تطرح فيها سؤالاً؟ ألا توجد طريقة تجعل Claude "يتذكرها" لتتجنب تكرارها يوميًا؟
المقال التالي 16 "سير العمل الشائع" — بعد أن تعلمنا القواعد العامة لـ "كيفية توضيح الطلب في جملة واحدة"، سنقوم بتطبيقها في المقال القادم على أربع من أكثر المهام تكرارًا: استكشاف كود غير مألوف، وإصلاح الأخطاء، وإعادة الهيكلة (Refactoring)، وكتابة الاختبارات، وسنقدم لك خطوات نموذجية جاهزة للتطبيق لكل منها. الآن بعد فهم القواعد، حان وقت تعلم الحركات الفعالة.