14 ديسمبر 2025·5 دقيقة
تحديد نطاق مهمة Claude Code: من طلبات غامضة إلى التزامات
تعلّم كيفية تحديد نطاق مهمة Claude Code لتحويل طلبات الميزات غير الواضحة إلى معايير قبول قابلة للاختبار، خطة واجهة مستخدم/API حد أدنى، وسلسلة من الالتزامات الصغيرة.
تعلّم كيفية تحديد نطاق مهمة Claude Code لتحويل طلبات الميزات غير الواضحة إلى معايير قبول قابلة للاختبار، خطة واجهة مستخدم/API حد أدنى، وسلسلة من الالتزامات الصغيرة.
يبدو الطلب الغامض بلا ضرر: «أضف بحثًا أفضل»، «اجعل تجربة الانضمام أسهل»، «المستخدمون يحتاجون إشعارات». في الفرق الحقيقية يصل غالبًا كرسالة دردشة سطر واحد، لقطة شاشة مع سهام، أو مكالمة عميل نصف متذكرة. الجميع يوافق، لكن كل شخص يتصور شيئًا مختلفًا.
التكلفة تظهر لاحقًا. عندما يكون النطاق غير واضح، يبني الناس على تخميناتهم. العرض الأول يتحول إلى جولة أخرى من التوضيح: «هذا ليس ما قصدته». يُعاد العمل، والتغيير يكبر بهدوء. تعديلات التصميم تؤدي إلى تغييرات في الشيفرة، والتي تتطلب اختبارًا إضافيًا. تبطئ المراجعات لأن التغيير الغامض يصعب التحقق منه. إذا لم يستطع أحد تعريف ما يعنيه «صحيح»، ينتهي المراجعون بمناقشة السلوك بدلًا من فحص الجودة.
يمكنك عادةً اكتشاف المهمة الغامضة مبكرًا:
المهمة محددة النطاق تعطي الفريق خط نهاية: معايير قبول واضحة، خطة واجهة مستخدم وAPI الحد الأدنى، وحدود صريحة لما لا يدخل في النطاق. هذا الفرق بين «تحسين البحث» وتغيير صغير سهل البناء والمراجعة.
عادةً عادة عملية: فرّق بين «تعريف الإنجاز» و«المرغوب فيه». «المنجز» قائمة قصيرة من الفحوص التي يمكنك تشغيلها (مثال: «يعيد البحث نتائج بالعنوان، يعرض ‘لا نتائج’ عندما تكون فارغة، ويبقي الاستعلام في عنوان URL»). «المرغوب فيه» كل شيء يمكن أن ينتظر (مرادفات، تعديل الترتيب، تمييز النص، تحليلات). وضع هذه العلامات مُسبقًا يمنع نمو النطاق بطريق الخطأ.
الطلبات الغامضة تبدأ غالبًا كاقتراحات إصلاح: «أضف زرًا»، «حوّل إلى سير جديد»، «استخدم نموذجًا مختلفًا». قف لترجم الاقتراح إلى نتيجة أولًا.
تنسيق بسيط يساعد: «بصفتي [مستخدم]، أريد [فعل شيء]، لكي [أصل لهدف].» اجعلها واضحة. إذا لم تستطع قولها في نفس النفس، فهي لا تزال غامضة.
بعد ذلك، وصف ما يتغير للمستخدم عند الانتهاء. ركز على السلوك المرئي، لا على تفاصيل التنفيذ. مثال: «بعد إرسال النموذج، أرى تأكيدًا وأستطيع العثور على السجل الجديد في القائمة.» هذا يخلق خط نهاية واضح ويجعل من الصعب تسلل «مجرّد تعديل واحد آخر».
اكتب أيضًا ما يبقى كما هو. غير الأهداف تحمي نطاقك. إذا كان الطلب «تحسين تجربة الانضمام»، قد يكون من غير الأهداف «لا إعادة تصميم لوحة القيادة» أو «لا تغييرات في منطق فئات الأسعار».
أخيرًا، اختر مسارًا رئيسيًا واحدًا لتدعمه أولًا: الشريحة الطرفية الوحيدة التي تثبت أن الميزة تعمل.
مثال: بدلًا من «أضف لقطات في كل مكان»، اكتب: «بصفتي مالك المشروع، أستطيع استعادة أحدث لقطة لتطبيقي، لكي أتمكن من التراجع عن تغيير سيء.» غير الأهداف: «لا استعادة جماعية، لا إعادة تصميم واجهة المستخدم.»
الطلب الغامض نادرًا ما يفتقد الجهد. هو يفتقد القرارات.
ابدأ بالقيود التي تغير النطاق بصمت. المواعيد النهائية مهمة، لكن قواعد الوصول واحتياجات الامتثال كذلك. إذا كنت تبني على منصة بها مستويات وأدوار، قرر مبكرًا من يحصل على الميزة وتحت أي خطة.
ثم اطلب مثالًا واحدًا ملموسًا. لقطة شاشة، سلوك منافس، أو تذكرة سابقة تكشف ما يعنيه «أفضل» فعليًا. إذا لم يكن لدى الطالب مثال، اطلب منه إعادة تسجيل آخر مرة شعر فيها بالألم: ما الشاشة التي كان عليها، ما الذي نقره، ماذا توقع؟
حالات الحافة هي حيث يتضخم النطاق، لذا سمِّ الكبيرة مبكرًا: البيانات الفارغة، أخطاء التحقق، الاتصالات البطيئة أو الفاشلة، وماذا يعني «التراجع» فعليًا.
أخيرًا، قرر كيف ستتحقق من النجاح. بدون نتيجة قابلة للاختبار، تتحول المهمة إلى آراء.
هذه الأسئلة الخمسة تزيل معظم الغموض عادةً:
مثال: «إضافة نطاقات مخصصة للعملاء» تصبح أوضح عندما تقرر أي مستوى تنتمي إليه، من يستطيع إعدادها، هل مكان الاستضافة يؤثر على الامتثال، ما الخطأ المعروض عند DNS غير صالح، وماذا يعني «تم» (النطاق مُثبت، HTTPS مفعل، وخطة استرجاع آمنة).
الطلبات الفوضوية تخلط بين الأهداف، التخمينات، وحالات الحافة نصف المُتذكرَة. المهمة هي تحويل ذلك إلى عبارات يستطيع أي شخص اختبارها دون قراءة أفكارك. نفس المعايير يجب أن توجه التصميم، البرمجة، المراجعة، وضمان الجودة.
نمط بسيط يحافظ على الوضوح. يمكنك استخدام Given/When/Then، أو نقاط قصيرة تعني الشيء نفسه.
اكتب كل معيار كاختبار واحد يمكن لشخص تشغيله:
طبقها الآن. افترض أن الملاحظة تقول: «اجعل اللقطات أسهل. أريد أن أستعيد إذا أحدث التغيير الأخير كسرًا.» حوّلها إلى عبارات قابلة للاختبار:
إذا قدر QA تشغيل هذه الفحوص والمراجعون التحقق منها في واجهة المستخدم والسجلات، فأنت جاهز لتخطيط عمل واجهة المستخدم وAPI وتقسيمه إلى التزامات صغيرة.
خطة واجهة المستخدم الحد الأدنى وعد: أصغر تغيير مرئي يثبت أن الميزة تعمل.
ابدأ بتسمية الشاشات التي ستتغير وما الذي يلاحظه الشخص خلال 10 ثوانٍ. إذا كان الطلب «اجعلها أسهل» أو «نظفها»، ترجم ذلك إلى تغيير ملموس واحد يمكنك الإشارة إليه.
اكتبه كخريطة صغيرة، لا إعادة تصميم. مثال: «صفحة الطلبات: أضف شريط مرشحات أعلى الجدول»، أو «الإعدادات: أضف مفتاح تبديل جديد تحت الإشعارات.» إذا لم تستطع تسمية الشاشة والعنصر الدقيق الذي يتغير، فإن النطاق لا يزال غير واضح.
معظم تغييرات الواجهة تحتاج بعض الحالات المتوقعة. اذكر فقط الحالات التي تنطبق:
نسخ واجهة المستخدم جزء من النطاق. التقط التسميات والرسائل التي يجب الموافقة عليها: نص الزر، تسميات الحقول، نص المساعدة، ورسائل الخطأ. إذا كانت الصياغة لا تزال مفتوحة، ضعها كمحتوى مؤقت واذكر من سيؤكدها.
حافظ على ملاحظة صغيرة «ليس الآن» لأي شيء غير مطلوب لاستخدام الميزة (تحسينات الاستجابة، الفرز المتقدم، الرسوم المتحركة، الأيقونات الجديدة).
المهمة محددة النطاق تحتاج عقدًا صغيرًا وواضحًا بين الواجهة، الخادم، والبيانات. الهدف ليس تصميم النظام بأكمله؛ بل تحديد أصغر مجموعة من الطلبات والحقول تثبت أن الميزة تعمل.
ابدأ بسرد البيانات التي تحتاجها ومصدرها: الحقول الموجودة التي يمكنك قراءتها، الحقول الجديدة التي يجب تخزينها، والقيم التي يمكنك حسابها. إذا لم تستطع تسمية مصدر كل حقل، فليس لديك خطة بعد.
حافظ على سطح API صغيرًا. للعديد من الميزات، طلب قراءة واحد وطلب كتابة واحد يكفيان:
GET /items/{id} يعيد الحالة اللازمة لعرض الشاشةPOST /items/{id}/update يقبل فقط ما يمكن للمستخدم تغييره ويعيد الحالة المحدثةاكتب المدخلات والمخرجات ككائنات بسيطة، لا فقرات. أدرج الحقول المطلوبة مقابل الاختيارية، وماذا يحدث في الأخطاء الشائعة (غير موجود، فشل التحقق).
قم بتمرير سريع لأذونات قبل لمس قاعدة البيانات. قرر من يقرأ ومن يكتب، واذكر القاعدة في جملة واحدة (مثال: «أي مستخدم مسجّل يمكنه القراءة، فقط الإداريون يمكنهم الكتابة»). تجاهل هذا غالبًا يؤدي إلى إعادة عمل.
أخيرًا، قرر ما يجب تخزينه وما يمكن حسابه. قاعدة بسيطة: خزّن الحقائق، واحسب وجهات العرض.
يعمل Claude Code بشكل أفضل عندما تعطيه هدفًا واضحًا وصندوقًا ضيّقًا. ابدأ بلصق الطلب الفوضوي وأي قيود (الموعد النهائي، المستخدمون المتأثرون، قواعد البيانات). ثم اطلب إخراجًا محددًا يتضمن:
بعد أن يرد، اقرأها كمراجع. إذا رأيت عبارات مثل «تحسين الأداء» أو «اجعلها أنظف»، اطلب صياغة قابلة للقياس.
الطلب: «أضف طريقة لإيقاف الاشتراك مؤقتًا.»
نسخة محددة النطاق قد تقول: «يمكن للمستخدم إيقاف الاشتراك لمدة 1 إلى 3 أشهر؛ تاريخ الفاتورة التالي يتحدّث؛ يمكن للمسؤول رؤية حالة الإيقاف»، وما هو خارج النطاق: «لا تغييرات في التسويات المالية».
من هناك، تخطيط الالتزامات يصبح عمليًا: التزام واحد لشكل قاعدة البيانات وAPI، التزام لواجهة المستخدم، التزام للتحقق وحالات الخطأ، التزام للاختبارات الشاملة.
التغييرات الكبيرة تخفي الأخطاء. الالتزامات الصغيرة تجعل المراجعات أسرع، تسهّل التراجع، وتساعدك على ملاحظة خروجك عن معايير القبول.
قاعدة مفيدة: كل التزام يجب أن يفتح سلوكًا جديدًا واحدًا، ويشمل طريقة سريعة لإثباته.
تسلسل شائع يبدو هكذا:
حافظ على تركيز كل التزام. تجنّب «بينما أنا هنا» عمليات إعادة الهيكلة. اجعل التطبيق يعمل من النهاية إلى النهاية، حتى لو كانت الواجهة أساسية. لا تدمج الترحيلات، السلوك، والواجهة في التزام واحد إلا إذا كان لديك سبب قوي.
يقول صاحب مصلحة: «هل يمكننا إضافة تصدير التقارير؟» هذا يخفي الكثير من الخيارات: أي تقرير، أي صيغة، من يمكنه التصدير، وكيفية التسليم.
اطرح فقط الأسئلة التي تغيّر التصميم:
افترض الأجوبة: «تقرير ملخّص المبيعات، CSV فقط، دور المدير، تنزيل مباشر، آخر 90 يومًا كحد أقصى.» الآن تصبح معايير القبول للنسخة الأولى ملموسة: يمكن للمدراء النقر على تصدير في صفحة ملخص المبيعات؛ يتطابق CSV مع أعمدة الجدول المعروض؛ يحترم التصدير المرشحات الحالية؛ يظهر خطأ واضح عند محاولة تصدير أكثر من 90 يومًا؛ يكتمل التنزيل خلال 30 ثانية لما يصل إلى 50k صف.
خطة واجهة المستخدم الحد الأدنى: زر Export بجانب إجراءات الجدول، حالة تحميل أثناء الإنشاء، ورسالة خطأ توضح للمستخدم كيف يصلح المشكلة (مثل «اختر 90 يومًا أو أقل»).
خطة API الحد الأدنى: نقطة نهاية واحدة تقبل المرشحات وتعيد CSV كاستجابة ملف، معاد استخدام نفس استعلام الجدول مع فرض قاعدة 90 يومًا جانب الخادم.
ثم اشحنها في بضعة التزامات محكمة: أولًا نقطة النهاية لمسار سعيدة ثابت، ثم ربط الواجهة، ثم التحقق ورسائل الخطأ للمستخدم، ثم الاختبارات والوثائق.
طلبات مثل «أضف أدوار فريق» غالبًا ما تخفي قواعد حول الدعوات، التحرير، وماذا يحدث للمستخدمين الحاليين. إذا وجدت نفسك تخمّن، اكتب الفرضية وحولها إلى سؤال أو قاعدة صريحة.
تفقد الفرق أيامًا عندما تتضمن المهمة كلاً من «اجعلها تعمل» و«اجعلها جميلة». اجعل المهمة الأولى مركزة على السلوك والبيانات. ضع التنسيق والرسوم المتحركة في مهمة متابعة ما لم تكن مطلوبة لاستخدام الميزة.
حالات الحافة مهمة، لكن ليس كلها تحتاج الحل فورًا. عالج القليل الذي يكسر الثقة (إرسال مزدوج، تعديلات متعارضة) وأجّل الباقي مع ملاحظات واضحة.
إذا لم تكتبها، ستفقدها. أدرج على الأقل مسار تعيس واحد وقاعدة أذونات واحدة في معايير القبول.
تجنب كلمات مثل «سريع» أو «بديهي» ما لم تربطها برقم أو فحص ملموس. استبدلها بشيء يمكن إثباته في المراجعة.
ثبّت المهمة بحيث يتمكن زميل من المراجعة والاختبار دون قراءة الأفكار:
مثال: «إضافة البحث المحفوظ» تصبح «يمكن للمستخدمين حفظ مرشح وإعادة تطبيقه لاحقًا»، مع استثناءات مثل «لا مشاركة» و«لا تغييرات في الفرز».
بمجرد أن تحصل على مهمة محددة النطاق، احمها. قبل البرمجة، قم بمراجعة سريعة مع من طلب التغيير:
ثم خزّن المعايير حيث يحدث العمل: في التذكرة، في وصف طلب السحب، وأينما ينظر فريقك فعلاً.
إذا كنت تبني في Koder.ai (koder.ai)، فالمساعدة تكون في قفل الخطة أولًا ثم توليد الشيفرة منها. وضع التخطيط يناسب هذا سير العمل، واللقطات والاسترجاع تحافظ على التجارب آمنة عندما تحتاج لتجربة نهج ثم التراجع عنه.
عندما تظهر أفكار جديدة أثناء التنفيذ، حافظ على استقرار النطاق: اكتبها في قائمة متابعة، أوقف العمل لإعادة تحديد النطاق إذا غيرت معايير القبول، واجعل الالتزامات مربوطة بمعيار واحد في كل مرة.
ابدأ بكتابة النتيجة في جملة واحدة (ما الذي يمكن للمستخدم فعله عند الانتهاء)، ثم أضف 3–7 معايير قبول يمكن للمختبِر التحقق منها.
إذا لم تستطع وصف السلوك “الصحيح” دون نقاش، فالمهمة لا تزال غامضة.
استخدم الصيغة السريعة التالية:
ثم أضف مثالًا واحدًا ملموسًا للسلوك المتوقع. إذا لم تتمكن من إعطاء مثال، أعد تمثيل آخر مرة ظهر فيها المشكلة واكتب ما نقره المستخدم وما توقع رؤيته.
اكتب أولًا قائمة قصيرة بتعريف الإنجاز (الفحوصات التي يجب أن تجتاز)، ثم قائمة منفصلة بالمميزات المرغوبة.
القاعدة الافتراضية: إذا لم يكن مطلوبًا لإثبات عمل الميزة من النهاية إلى النهاية، فتوضع في قائمة المميزات المرغوبة.
اطرح الأسئلة القليلة التي تغيّر النطاق:
هذه الأسئلة تجبر اتخاذ القرارات المفقودة على الظهور.
عامل حالات الحافة كعناصر نطاق، لا كمفاجآت. للنسخة الأولى، غطِ الحالات التي تكسر الثقة:
كل شيء آخر يمكن تأجيله مع ملاحظة واضحة بأنه خارج النطاق.
استخدم بيانات قابلة للاختبار يمكن لأي شخص تشغيلها دون تخمين:
ضمّن على الأقل حالة فشل واحدة وقاعدة أذونات واحدة. إذا لم تتمكن من اختبار معيار، أعد كتابته حتى يصبح قابلًا للاختبار.
سمِّ الشاشات الدقيقة والتغيير المرئي الواحد لكل شاشة.
كما أدرج حالات واجهة المستخدم المطلوبة:
احرص أيضًا أن تكون النصوص (نص الزر، الأخطاء) ضمن النطاق، حتى لو كانت نصوصًا مؤقتة.
احتفظ بعقد الواجهة صغيرة: عادةً قراءة واحدة وكتابة واحدة تكفي للنسخة الأولى.
عَرِّف:
خزن الحقائق؛ احسب وجهات العرض عندما تستطيع.
اطلب مخرجات محددة ومربوطة بصندوق زمني:
ثم أعد طلب أي عبارات غامضة مثل “تحسين الأداء” إلى صياغة قابلة للقياس.
التسلسل الافتراضي:
قاعدة الإبهام: التزام واحد = سلوك مرئي واحد + طريقة سريعة لإثباته. تجنّب دمج عمليات إعادة هيكلة غير مرتبطة داخل التزامات الميزة.