المهام الأربع الأكثر استخدامًا: استكشاف الكود، وإصلاح الأخطاء، وإعادة الهيكلة، وكتابة الاختبارات
📚 التنقل في السلسلة: المقال السابق 15 كيفية طرح الأسئلة وتقديم التوجيهات علمك "كيفية التعبير" — عبر تقسيم المتطلبات المبهمة إلى توجيهات دقيقة. يغير هذا المقال المنظور: 80% من المهام اليومية تنقسم إلى تلك الفئات الأربع، وسنقدم لك نموذج توجيه جاهزًا للتطبيق لكل منها، يمكنك تعبئته واستخدامه مباشرة.
أصدقائي، دعونا نتحدث اليوم عن أكثر الأمور واقعية وعملية.
تذكر معي، ما الذي تفعله يوميًا عند تعاملك مع الكود؟ ببساطة، تدور معظم أعمالك حول أربعة أشياء: استلام مشروع غير مفهوم، أو إصلاح خطأ غريب ومفاجئ، أو إعادة هيكلة كود رديء لتنظيفه، أو إضافة اختبارات مفقودة لدالة معينة. بالطبع هناك متطلبات أخرى، ولكن هذه الفئات الأربع تمثل الجزء الأكبر من وقتنا اليومي.
تحدث المقال السابق عن "مهارات الصياغة" العامة، وسيركز هذا المقال على السيناريوهات المحددة — فهذه الفئات الأربع لكل منها خطوات نموذجية ثابتة للتطبيق. وبمرور الوقت مع استخدام Claude Code، ستجد نفسك تعتمد على أربعة نماذج أساسية يمكنك الاحتفاظ بها في مفكرتك واستدعاؤها لتعبئتها مباشرة عند الحاجة.
دعنا نوضح الأمر كالتالي: المهارات العامة هي القوة الأساسية الباطنة، وهذه النماذج الأربعة هي الحركات القتالية المحددة. بعد أن تدربت على القوة الباطنة، سنقدم لك الحركات المحددة اليوم.
بعد قراءة هذا المقال، ستحصل على:
- نموذج توجيه جاهز للنسخ لكل فئة من المهام الأربع الأكثر استخدامًا (الاستكشاف / إصلاح الأخطاء / إعادة الهيكلة / كتابة الاختبارات)
- الأسباب والمنطق خلف كيفية صياغة كل فئة، وليس مجرد حفظ للنماذج
- بطاقة مرجعية سريعة للمهام الأربع، يمكنك حفظها للرجوع إليها عند الحاجة
- تطبيق عملي كامل مع المخرجات المتوقعة لتتبع عملية إصلاح خطأ حقيقي خطوة بخطوة
01 افهم أولاً: أربع مهام، أربع أدوات
قبل البدء بالعمل، حدد بوضوح "طبيعة وسلوك" كل مهمة من الفئات الأربع. فمتطلبات كل منها من Claude تختلف تمامًا، واستخدام النمط الخاطئ يقلل الفعالية بكثير.
تشبيه: أربع أدوات مختلفة في صندوق العدة، لكل منها استخدام محدد. يُستخدم مفك البراغي للمسامير، ومفتاح الربط للصواميل، واستخدام مفتاح الربط للمسامير سيكون مزعجًا وغير فعال بالطبع. الاستكشاف، وإصلاح الأخطاء، وإعادة الهيكلة، وكتابة الاختبارات هي أربع أدوات مختلفة — والمسألة ليست "هل تجيد استخدام Claude أم لا"، بل "أي أداة يجب إخراجها لهذه المهمة المحددة".
يكمن الفارق الجوهري بينها في بعد واحد: هل تتطلب هذه المهمة تعديل الكود الخاص بك؟
| المهمة | هل تعدل الكود؟ | ما يفعله Claude بشكل أساسي | أكثر ما يجب عليك مراقبته |
|---|---|---|---|
| استكشاف الكود | لا (للقراءة فقط) | قراءة الملفات والشرح لك | مدى صحة شرحه وتفسيره |
| إصلاح الأخطاء | نعم | تحديد السبب الجذري والتعديل | هل حدد السبب الصحيح، وهل أضاف اختبارات تراجع |
| إعادة الهيكلة | نعم (دون تغيير السلوك) | إعادة الكتابة المكافئة للكود | هل تغير سلوك الكود بعد التعديل |
| كتابة الاختبارات | إضافة ملفات جديدة | توليد الاختبارات وتغطية الحالات الحدية | هل غطى جميع الحالات الحدية (edge cases) |
هل لاحظت الفارق؟ الاستكشاف خالي من المخاطر تمامًا (فهو للقراءة فقط)، لذا يمكنك السؤال بحرية ودون قلق؛ أما إصلاح الأخطاء وإعادة الهيكلة فهما عمليتان تتطلبان تعديل الكود، لذا يجب عليه توضيح الخطة أولاً قبل البدء؛ وتعد كتابة الاختبارات مرحلة وسطية، حيث تضيف ملفات جديدة دون المساس بكودك الأصلي، ولكن عليك التحقق من عدم تراخيه واكتفائه باختبار "الحالات العادية فقط".
تذكر هذا المنطق، وسنشرح في الأقسام الأربعة القادمة كيفية استخدام كل أداة بالتفصيل.
💡 خلاصة في جملة واحدة: صنف المهام الأربع بناءً على "هل تعدل الكود أم لا" أولاً — الاستكشاف خالي من المخاطر فاسأل عنه بحرية، والمهام التي تعدل الكود اطلب منه توضيح الخطة أولاً قبل التعديل.
02 استكشاف الكود غير المألوف:开启 ثلاثة مستويات للأسئلة من العام إلى الخاص
نبدأ بالسيناريو الأكثر تكرارًا: استلام مشروع غير مألوف تمامًا، والمهمة الأولى هي فهمه.
كيف كنا نفعل هذا سابقًا؟ نفتح المجلد ونقف مذهولين أمام عشرات الأدلة، ونبدأ بفتحها واحدًا تلو الآخر لنقضي ساعتين دون الوصول لفكرة واضحة. الآن لا حاجة لذلك — يتعامل Claude Code مع الدليل الحالي كبيئة عمل، ويمكنه قراءة المشروع بالكامل بنفسه، وكل ما عليك هو السؤال.
تشبيه: الانضمام لشركة جديدة. لن تبدأ في أول يوم بالدخول في تفاصيل كود مصدر وحدة معينة، بل ستسأل الموظفين القدامى على ثلاثة مستويات. المستوى الأول "ما الذي تفعله شركتنا عمومًا، وكيف يبدو الهيكل العام للمشروع؟"؛ المستوى الثاني "أين يقع الكود المسؤول عن الدفع؟"؛ المستوى الثالث "كيف ينتقل الكود من مرحلة تقديم الطلب إلى خصم المبلغ؟". من العام إلى الخاص، ومن السطح إلى المسار الممتد، هذا هو التدرج القياسي للاستكشاف.
وفقًا لعرض الوثائق الرسمية، تقابل هذه المستويات الثلاثة ثلاثة أنواع من الأسئلة:
给我一个这个代码库的整体概览，说说它的主要架构模式负责用户认证的代码在哪些文件里？这几个文件是怎么协同工作的？追踪一下登录流程，从前端一直到数据库是怎么走的من العادات الآمنة تشغيل أول مستويين في وضع Plan Mode (وضع التخطيط) — أي بالضغط على Shift+Tab مرتين قبل البدء (الضغطة الأولى تدخل acceptEdits، والثانية تدخل plan). لماذا؟ لأننا في مرحلة الاستكشاف نريد منه القراءة والشرح فقط، ولا نريده أن يتسرع في إجراء أي تعديل على الملفات. في وضع Plan Mode لن يمس كود المصدر الخاص بك، ومهما سألت فلن يغير سطرًا واحدًا.
على سبيل المثال، عند استلام مشروع قديم بلغة Go يتكون من 30 ألف سطر، يمكنك البدء في اليوم الأول كالتالي: اطلب أولاً "نظرة عامة شاملة" لتفهم الخدمات المتوفرة، ثم اطلب تحديد "أين يقع الكود المسؤول عن X"، وفي النهاية اختر مسارًا أساسيًا واطلب "تتبع كيفية معالجة هذا الطلب". سيمكنك فهم المشروع خلال نصف يوم، وهو عمل كان يستغرق سابقًا يومين أو ثلاثة على الأقل.
إليك نموذج الاستكشاف مباشرة، يمكنك استبدال الكلمات بين الأقواس بالمعلومات الخاصة بك:
我刚接手这个项目，帮我快速上手。分三步：
1. 给我整体架构概览，说清主要模块和它们的职责
2. 负责 [你关心的功能，如「订单支付」] 的代码在哪些文件里
3. 追踪 [某条核心流程，如「一笔订单的创建到支付」] 的完整执行路径
用新手能懂的方式讲，先别改任何代码。💡 خلاصة في جملة واحدة: يتبع الاستكشاف تدرجًا ثابتًا — من الهيكل العام إلى الملفات المحددة ثم مسار التنفيذ، من العام إلى الخاص عبر المستويات الثلاثة، ويُفضل تشغيل أول مستويين في وضع Plan Mode كخيار أكثر أمانًا.
03 修 bug：贴报错 → 找根因 → 改 → 加回归测试
يعد إصلاح الأخطاء مهمة متكررة أخرى، وهي الأكثر عرضة للإخفاق والتراجع.
لماذا يسهل الإخفاق هنا؟ لأن الخطأ الأكثر شيوعًا للمبتدئين هو: لصق تفاصيل الخطأ وطلب "أصلح هذا من أجلي" مباشرة، ليقوم Claude بتقديم تعديل "يجعل الخطأ يختفي فحسب". انتبه، "اختفاء الخطأ" لا يعني "حل المشكلة" — ففي كثير من الأحيان يؤدي ذلك فقط إلى إخفاء الأعراض الظاهرية بينما تظل المشكلة الأساسية قائمة لتنفجر لاحقًا بشكل آخر.
تشبيه: زيارة الطبيب عند الشعور بالألم. لن تدخل العيادة وتقول "أعطني مسكنًا للألم فحسب"، بل ستوضح "أين الألم، ومتى بدأ، وما هي الحركة التي تزيده"، لتتيح للطبيب تشخيص المرض أولاً ثم وصف العلاج. إصلاح الأخطاء مماثل تمامًا — اطلب منه تحديد السبب الجذري أولاً، وتجنب التسرع في "تسكين الألم".
تؤكد التوجيهات الرسمية على قاعدة ذهبية تستحق الحفظ:
修复它并验证构建成功。解决根本原因，不要抑制错误。
لذلك، تتكون الخطوات الصحيحة لإصلاح الأخطاء من أربع خطوات أساسية:
- لصق الخطأ + خطوات إعادة الإنتاج: تفاصيل الخطأ وسجل التتبع بالكامل، بالإضافة إلى "ما قمت به لتفعيله"
- اطلب منه تحديد السبب الجذري أولاً: لا تدعه يغير الكود فورًا، بل اطلب توضيح "لماذا حدث الخطأ"
- إجراء الإصلاح: بعد التأكد من السبب الجذري، اسمح له بإجراء التعديل
- إضافة اختبارات التراجع (Regression Tests): أضف اختبارًا يعيد إنتاج هذا الخطأ، لضمان عدم تكراره مستقبلاً
الخطوة الرابعة هي الأكثر عرضة للتجاهل من المبتدئين، ولكنها الأكثر قيمة على الإطلاق. تطرح الوثائق الرسمية فكرة ممتازة: اطلب من Claude "كتابة اختبار فاشل يعيد إنتاج المشكلة أولاً، ثم إصلاحها" — بهذه الطريقة، سيتحول الاختبار للون الأخضر تلقائيًا بعد الإصلاح، مما يمثل قفلاً يمنع تكرار الخطأ مستقبلاً؛ فإذا قام أي شخص بتعديل هذا الجزء بالخطأ لاحقًا، سينطلق التنبيه فورًا بفشل الاختبار.
لقد واجه الكثيرون هذه المشكلة سابقًا. على سبيل المثال، عند إصلاح خطأ في تحليل التاريخ، قام Claude بالتعديل سريعًا، وتم رفع الكود بعد التأكد من اختفاء الخطأ. ولكن بعد أسبوعين قام زميل آخر بإعادة هيكلة هذا الكود وتعديله للشكل السابق، ليعود الخطأ نفسه للظهور مباشرة — والسبب هو عدم وجود اختبار يوضح أن هذا السطر لا يجب مسه. لذلك يجب دائمًا تضمين الخطوة الرابعة عند إصلاح أي خطأ.
إليك نموذج إصلاح الأخطاء مباشرة:
我遇到一个 bug。
报错信息：[完整粘贴报错和堆栈]
复现步骤：[我做了什么才触发，是偶发还是必现]
请你：
1. 先定位根本原因，解释为什么会出错，先别改代码
2. 给我修复方案，解决根因，不要只是把报错盖住
3. 改完补一个能复现这个 bug 的回归测试，跑一遍确认通过💡 خلاصة في جملة واحدة: اتبع الخطوات الأربع لإصلاح الأخطاء — لصق الخطأ وخطوات إعادة الإنتاج، وتحديد السبب الجذري أولاً، ثم التعديل، وفي النهاية إضافة اختبار تراجع؛ وبدون اختبار التراجع، سيعود الخطأ نفسه للظهور عاجلاً أم آجلاً.
04 重构：先讲现状 → 定目标 → 小步改 → 改前改后都测
تعد إعادة الهيكلة الأكثر خطورة لأنها تتضمن تعديل كود يعمل بالفعل دون مشاكل ظاهرية.
عند إصلاح الأخطاء، هناك معيار واضح للنجاح — اختفاء الخطأ ومرور الاختبار بنجاح. أما إعادة الهيكلة فليس لها معيار مماثل، حيث يكمن الهدف في جعل الكود "أكثر نظافة وترتيبًا مع الحفاظ على السلوك دون أي تغيير". وإذا تغير السلوك، فإنك تقوم بإدخال أخطاء جديدة تحت مسمى إعادة الهيكلة، وهذا هو النوع الأكثر إزعاجًا من الأخطاء لأنه لا أحد يفكر عادة في اختبار كود تم الاكتفاء بـ "ترتيبه وتجميله".
تشبيه: تجديد وتزيين منزل مأهول بالسكان دون إخراجهم منه. يجب أن تضمن استمرار عمل المياه والكهرباء ومعيشتهم بشكل طبيعي، وتقتصر مهمتك على طلاء الجدران وترتيب التوصيلات. إعادة الهيكلة تشبه "التجديد بوجود السكان" — حيث يجب ألا تتأثر الوظائف (حياة السكان) طوال العملية.
لذلك، تتمثل الطريقة الآمنة لإعادة الهيكلة في أربع خطوات، وجوهرها هو "قفل السلوك تمامًا باستخدام الاختبارات":
- اطلب منه شرح الوضع الحالي أولاً: افهم بدقة ما يفعله الكود حاليًا، بما في ذلك الحالات الحدية المخفية
- تحديد هدف إعادة الهيكلة بوضوح: هل تريد "تقسيم الدوال"، أم "استخدام أساليب كتابة حديثة"، أم "إزالة التكرار"؟ كن محددًا
- التعديل التدريجي: توصي التوجيهات الرسمية بوضوح بـ "إجراء إعادة الهيكلة بشكل تدريجي وبزيادات صغيرة قابلة للاختبار"، وتجنب السماح له بإعادة كتابة الكود بالكامل دفعة واحدة
- تأكيد نجاح الفحص قبل وبعد التعديل: قم بتشغيل الاختبارات قبل التعديل لحفظ مرجع أساسي، وأعد تشغيلها بعد التعديل، ويجب أن تتطابق نتيجتا التشغيل بالكامل
الخطوة الرابعة هي جوهر وأساس إعادة الهيكلة. وإذا كان الكود يفتقر إلى الاختبارات حاليًا، فإن الخطوة الأولى ليست التعديل بل كتابة اختبارات أولاً — استخدم الاختبارات لالتقاط "لقطة سريعة" للسلوك الحالي، وقارن نتيجة التعديل بها؛ فعدم تغير السلوك هو المعيار الوحيد للنجاح. يتطابق هذا تمامًا مع التوجيهات الرسمية: توفير وسيلة لـ Claude للتحقق من عمله بنفسه، وإلا سيصبح معيار "أنه يبدو صحيحًا" هو الخيار الوحيد، وإعادة الهيكلة التي تبدو صحيحة ظاهريًا هي الأكثر احتواءً على الأخطاء المخفية.
هناك قاعدة ذهبية يجب الالتزام بها: لا تسمح لـ Claude بإعادة هيكلة كود يفتقر لتغطية الاختبارات مباشرة. تخيل سيناريو التسرع، حيث تطلب منه إعادة هيكلة دالة مساعدة تفتقر للاختبارات، فيقوم بـ "تحسين" وحذف فرع حدي يظهر له ككود مهمل، بينما يتعامل هذا الفرع في الواقع مع مدخلات نادرة الحدوث. ولن تكتشف هذا الخطأ إلا بعد انهيار النظام على الخادم الحقيقي. الالتزام دائمًا بكتابة الاختبارات أولاً ثم إعادة الهيكلة قد يبدو أبطأ، ولكنه يمنع الإخفاق تمامًا.
إليك نموذج إعادة الهيكلة مباشرة:
我想重构 [文件 / 函数名]。
重构目标：[具体说，如「拆成更小的函数」「换成现代写法」「消除重复」]
要求：
1. 先解释这段代码现在的行为，包括容易忽略的边界情况
2. 如果它还没有测试，先补上覆盖现有行为的测试
3. 小步重构，保持对外行为完全不变
4. 重构前后都跑一遍测试，确认结果一致💡 一句话总结：重构的命根子是「行为不能变」——先讲现状、再定目标、小步改，用改前改后都过的测试把行为锁死；没测试就先补测试再动手。
05 写测试：重点是逼它覆盖边界情况
الفئة الأخيرة: إضافة اختبارات للكود.
مهمة كتابة الاختبارات ينجزها Claude بسلاسة كبيرة — فهو يفحص ملفات الاختبار الحالية، ويتبع نفس أطر العمل وأساليب التأكيد (assertion) المستخدمة، ليطابق الأسلوب تلقائيًا دون تدخل منك. ولكن هناك فخ هام: إذا لم تحدد شروطًا خاصة، فإنه سيكتفي افتراضيًا باختبار "الحالات العادية فقط".
ماذا نعني باختبار الحالات العادية فقط؟ على سبيل المثال، لدالة قسمة، سيكتب اختبارًا لـ "6 تقسيم 2 يساوي 3" — النتيجة صحيحة بالطبع، ولكن ماذا عن القسمة على 0؟ وتمرير أعداد سالبة؟ وتمرير قيمة فارغة (null)؟ هذه "الحالات الحدية (edge cases)" هي الأماكن التي تظهر فيها الأخطاء فعليًا، وهي الأكثر حاجة لتغطية الاختبارات.
تشبيه: توظيف فاحص جودة للمنتج، لا يمكنك الاكتفاء بجعله يجرب "الاستخدام الطبيعي". فالفحص ذو القيمة الحقيقية هو تجربة المدخلات "غير المتوقعة" — المدخلات الفارغة، الطويلة جدًا، السالبة، أو الرموز الغريبة. فالمشاكل تظهر دائمًا عند الحدود وليس في المسار الطبيعي. وجوهر كتابة الاختبارات هو إجبار Claude على اختبار هذه الحدود.
لذلك، يكمن مفتاح نموذج كتابة الاختبارات في عبارة واحدة: طلب تغطية الحالات الحدية صراحة. وتعرض التوجيهات الرسمية مثالاً جيدًا يحدد بوضوح "الدالة المستهدفة، والسيناريو المطلوب، واستخدام mock من عدمه":
为 foo.py 编写测试，涵盖用户已注销的边界情况。避免 mock。
المقارنة بين الطريقتين توضح الفارق بنظرة واحدة:
| ❌ سؤال مبهم | ✅ سؤال دقيق |
|---|---|
| "اكتب اختبارات لهذه الدالة" | "اكتب اختبارات لدالة divide مع التركيز على تغطية الحالات الحدية مثل القسمة على صفر، الأعداد السالبة، والمدخلات غير الرقمية" |
| يكتفي باختبار المسار الطبيعي، وتظهر نسبة التغطية مرتفعة وهميًا | يختبر الأماكن التي يحتمل انهيار النظام عندها فعليًا |
هناك نصيحة إضافية: استخدم الرمز @ للإشارة للملف المستهدف مباشرة (مثل @src/utils/math.py)، ليقوم بقراءة الملف بالكامل أولاً قبل البدء، وهذا أدق بكثير من الوصف النصي "دالة divide في ملف math". لقد شرحنا استخدام @ سابقًا، وهو مفيد جدًا هنا.
إليك نموذج كتابة الاختبارات مباشرة:
给 @[文件路径] 里的 [函数名] 写测试。
要求：
1. 沿用项目现有的测试框架和断言风格
2. 重点覆盖边界情况：[列出你能想到的，如「空输入、零、负数、超大值、类型不对」]
3. 也帮我想想还有哪些我没列到的边界情况，一并测上
4. 写完跑一遍，有失败的修到通过النقطة الثالثة هي حركة إضافية متميزة — الطلب منه تحديد الثغرات ونقاط السهو لمساعدتك. تشير الوثائق الرسمية أيضًا إلى أن Claude يمكنه تحليل مسارات الكود واكتشاف الحدود التي قد تكون سهوت عنها. يُنصح دائمًا بتضمين هذه العبارة عند كتابة الاختبارات، حيث تنجح كثيرًا في الكشف عن مدخلات غير متوقعة لم تكن لتفكر فيها بمفردك، وهي أكثر شمولاً من المحاولة الفردية.
💡 خلاصة في جملة واحدة: لا تكتفِ بطلب "كتابة اختبارات" فقط — بل أجبره صراحة على تغطية الحالات الحدية (القيم الفارغة، الصفر، الأعداد السالبة، أخطاء الأنواع)، واطلب منه الكشف عن أي حدود أخرى قد تكون سهوت عنها، فالمسار الطبيعي هو الأقل أهمية في الفحص.
06 عملي: تتبع عملية إصلاح خطأ حقيقي خطوة بخطوة
القراءة دون تطبيق غير كافية، دعنا نطبق الخطوات عمليًا. سنستخدم سيناريو "إصلاح الأخطاء" للتطبيق — فهو يضم الخطوات الأربع كاملة، وبمجرد فهمه، ستتمكن من تطبيق الأنماط الثلاثة الأخرى بسهولة. لقد قمنا بإعداد خطأ حقيقي لتجربة إصلاحه.
الخطوة الأولى: إنشاء مشروع تجريبي يحتوي على خطأ (Mac / Linux)
mkdir bug-demo
cd bug-demo
echo 'def average(numbers):
return sum(numbers) / len(numbers)' > calc.pyلمستخدمي Windows: mkdir و cd كما هي، ثم أنشئ ملف calc.py باستخدام المفكرة والصق السطرين بلغة Python فيه.
تقوم دالة average بحساب المتوسط، وتبدو صحيحة ظاهريًا — ولكن عند تمرير قائمة فارغة، ستنهار بسبب القسمة على صفر. هذا هو الخطأ الذي نريد إصلاحه.
النتيجة المتوقعة: يحتوي مجلد bug-demo على ملف calc.py وبه دالة average المكونة من سطرين.
الخطوة الثانية: تشغيل Claude Code
claudeالنتيجة المتوقعة: تظهر شاشة الترحيب وبها مربع الإدخال في الأسفل.
الخطوة الثالثة: تطبيق نموذج إصلاح الأخطاء ولصق الخطأ لإصلاحه
اكتب في مربع الإدخال (هذا هو الشكل النهائي للنموذج بعد تعبئته بناءً على القسم 03):
我遇到一个 bug。
报错信息：调用 average([]) 时报 ZeroDivisionError: division by zero
复现步骤：给 calc.py 里的 average 函数传一个空列表就必现
请你：
1. 先定位根本原因，解释为什么会出错，先别改代码
2. 给我修复方案，解决根因，不要只是把报错盖住
3. 改完补一个能复现这个 bug 的回归测试，跑一遍确认通过النتيجة المتوقعة: سيخبرك Claude أولاً بالسبب الجذري — أن قيمة len(numbers) تكون 0 عند القائمة الفارغة، مما يسبب انهيار القسمة على صفر；ثم يقدم تعديلاً (diff) (مثل إرجاع القيمة 0 عند القائمة الفارغة أو طرح استثناء أكثر وضوحًا) ويتوقف بانتظار موافقتك؛ وبعد الموافقة، سينشئ ملف اختبار جديدًا (مثل test_calc.py) يحتوي على حالة اختبار مخصصة للقائمة الفارغة.
الخطوة الرابعة: الموافقة على التعديلات ومراقبة تشغيل الاختبارات
بعد مراجعة وفهم الـ diff اختر "الموافقة / Yes". سيقوم Claude بتشغيل الاختبارات التي كتبها للتو.
النتيجة المتوقعة: ستظهر نتائج الاختبار في الطرفية بالشكل التالي:
test_calc.py::test_average_empty_list PASSED
test_calc.py::test_average_normal PASSEDظهور الاختبارات باللون الأخضر = تم إصلاح الخطأ بنجاح وقفله تمامًا — فإذا قام أي شخص بإعادة الكود للشكل السابق مستقبلاً، سيفشل الاختبار وينطلق التنبيه فورًا.
الخطوة الخامسة: الخروج والتحقق من تعديل الملف بالفعل
اخرج من Claude (اكتب exit أو اضغط على Ctrl+D) والتحقق من الطرفية:
cat calc.py(لـ Windows PowerShell استخدم type calc.py)
النتيجة المتوقعة: تم إضافة منطق التعامل مع القائمة الفارغة في دالة average بداخل ملف calc.py، وظهر ملف اختبار جديد في الدليل. تطابق الملفات مع الـ diff الذي وافقت عليه يعني نجاح تشغيل دورة إصلاح الأخطاء بالكامل، تهانينا!
⚠️ تنبيه: إذا لم يقم Claude بكتابة اختبار في الخطوة الثالثة تلقائيًا، فمن المحتمل أنك حذفت البند الثالث من النموذج. لا تحذف هذه العبارة أبدًا — فاختبارات التراجع تمثل الحد الفاصل بين المبتدئ والمحترف.
07 ملخص
شرح هذا المقال المهام التي تشغل 80% من وقتك اليومي وقسمها إلى أربع فئات، مقدماً خطوات ثابتة للتطبيق ونموذجًا جاهزًا لكل منها:
| المهمة | جوهر نموذج التوجيه | أهم النقاط الواجب مراقبتها |
|---|---|---|
| استكشاف الكود | "الهيكل العام ← أين يقع الكود المسؤول عن X ← تتبع مسار معين" | تدرج الأسئلة من العام إلى الخاص، وتفعيل Plan Mode في أول مستويين |
| إصلاح الأخطاء | "لصق الخطأ وإعادة الإنتاج ← تحديد السبب الجذري ← التعديل ← إضافة اختبار تراجع" | حل المشكلة من جذورها وتجنب إخفاء الأعراض، ولا تتجاهل اختبارات التراجع |
| إعادة الهيكلة | "فهم الوضع الحالي ← تحديد الهدف ← التعديل التدريجي ← الفحص قبل وبعد التعديل" | الحفاظ على السلوك دون تغيير، والبدء بكتابة الاختبارات أولاً إذا كانت مفقودة |
| كتابة الاختبارات | "اكتب اختبارات تركز على تغطية القيم الفارغة/الصفر/الأعداد السالبة/أخطاء الأنواع" | إجباره صراحة على تغطية الحالات الحدية، واطلب منه الكشف عن الثغرات |
من المفترض الآن أن تكون قادرًا على: البدء مباشرة عند مواجهة أي مهمة من المهام الأربع دون حيرة — حيث تستدعي النموذج المقابل وتقوم بتعبئته، وتعرف بدقة ما الذي يجب أن يفعله Claude في كل خطوة وما الذي يجب عليك مراقبته. تمثل هذه النماذج الأربعة الهيكل الأساسي لمعظم أعمالك القادمة؛ وبمرور الوقت ستكتشف أن المهام الأكثر تعقيدًا هي مجرد مزيج وترابط بين هذه الفئات الأربع.
هذه النماذج الأربعة صالحة للاستخدام اليومي المستمر — فمهما بدت المهمة معقدة، ستعود في النهاية لتطبيق أحد هذه الأنماط الأربعة.
المقال التالي 17 "الصور والوسائط المتعددة" — اقتصرت التوجيهات السابقة على النصوص المكتوبة، ولكن هناك أشياء يصعب التعبير عنها بالكلمات: مثل لقطة شاشة لخطأ معين، أو تصميم واجهة، أو مخطط لهيكل قاعدة البيانات. سيعلمك المقال القادم كيفية تزويد Claude بالصور مباشرة ليعمل استنادًا إليها. تخيل مدى السهولة إذا تمكنت من إرسال لقطة شاشة لخطأ مزعج له مباشرة ليتعامل معها!