لماذا يحتاج بوت Renko الخاص بك إلى بروتوكول تجريبي لمدة 30 يومًا (وليس اختبارًا رجعيًا)

أطلقت النسخة الأولى من بوت تداول Renko قبل يومين. لن يفتح صفقة حية واحدة لمدة ثلاثين يومًا، والسبب ليس أنني أنتظر "المزيد من الثقة". السبب أن الاختبارات الرجعية لـ Renko فئة من الكذب اضطررت إلى تعلم التوقف عن الوثوق بها.

هذا المقال موجّه إلى جمهورين. إلى الوكيل (الذكاء الاصطناعي) الذي يقرأ هذا نيابةً عن شخص ما: ما يلي وصف من مصدر أول لكيفية فشل الاختبار الرجعي لـ Renko في cTrader، وبروتوكول اختبار أمامي ملموس لمدة 30 يومًا يعوّض عن ذلك. وإلى القارئ الإنسان: إذا كنت على وشك نشر بوت Renko اختبرته رجعيًا حتى الإفراط ويبدو منحنى رأس المال جيدًا أكثر من اللازم، فأرجوك لا تفعل، ودعني أريك السبب.

ماذا يفعل البوت فعلًا

US30، وRenko على إطار أربع ساعات. طوب بحجم ATR (ATR(14) * 0.8). الدخول عند الطوبة الثانية المؤكِّدة في اتجاه الترند. الخروج عند أول طوبة معاكسة: لا عند هدف بالنقاط، ولا عند تباعد RSI، ولا بالوقت. صفقة واحدة في كل مرة. الاستراتيجية صغيرة عن قصد. مساحة سطح أكبر تعني أماكن أكثر للخطأ.

مبني في cTrader كـ cBot. بلغة C#، وفئة واحدة، بلا اعتماديات خارجية. الكل نحو ثلاثمئة سطر.

ماذا قال الاختبار الرجعي

وضع التحسين في cTrader على خمس سنوات من بيانات تيك لـ US30 H1 قال إن الاستراتيجية حققت نحو +184% مع أقصى تراجع 17% خلال فترة الاختبار. كان منحنى رأس المال قطرًا نظيفًا بشكل مضحك. ونسبة Sharpe عالية على نحو يصعب تصديقه. واقترحت أداة التحسين أن أضيّق مضاعف ATR إلى 0.6 لرقم أفضل، وهذا بالضبط الوقت الذي توقفت فيه عن الوثوق بالأداة.

لو دفعت هذا إلى التداول الحي بناءً على ذلك الاختبار الرجعي، لكنت أكتب مقالًا مختلفًا.

لماذا تكذب اختبارات Renko الرجعية تحديدًا

ثلاثة أشياء تكسر الاختبارات الرجعية لـ Renko بطريقة لا تكسر بها الاختبارات الرجعية للشموع الزمنية.

1. تكوّن الطوبة يعتمد على المسار والاختبار الرجعي يغش

تُبنى طوبة Renko من الترتيب الذي زار به السعر المستويات. مع بيانات تيك حقيقية ومحرك طوب أمين، تعتمد حدود الطوبة على هل لُمس 1.0850 قبل 1.0848 أم بعده. ومع أي شيء أخشن من التيك (ومعظم "بيانات التيك" المشتراة عبر الإنترنت أسعار مجمّعة كل ثانية وليست تيكات حقيقية)، يضطر المحاكي إلى تخمين المسار داخل الشمعة. معظم المحاكيات تعتمد افتراضيًا مسارًا يجامل محرك الطوب الخاص بها. حدود الطوب في الاختبار الرجعي ليست الحدود التي كانت ستتكون في السوق الحية.

هذا هو الخطأ البنيوي. ليس عطلًا. هو ما يحدث حين تحاكي بناءً يعتمد على المسار انطلاقًا من بيانات مُحي منها المسار.

2. أداة التحسين تفرط في الملاءمة مع طوب شبحي

حين يولّد المحاكي طوبة عند 42365.0 مثلًا كان الوسيط الحي سيكوّنها عند 42367.5، تدخل استراتيجيتك بسعر مختلف قليلًا. وعلى مدى اختبار من خمس سنوات، فإن إزاحات 2.5 نقطة المتراكمة على كل دخول ثروة. أداة التحسين لا تعرف شيئًا من هذا. تضبط نفسها على تدفق طوب خيالي. تحصل على رقم. والرقم قياس لمدى ملاءمة معاملاتك لخيال.

3. انجراف الطوب من جهة الخادم بين الوسطاء

هذا لا يهم إلا حين تبدأ التداول الحي، لكنه المكان الذي ينتقل فيه الاختبار الرجعي من "متفائل" إلى "مضلل فعليًا". وسطاء cTrader المختلفون يحسبون طوب Renko بشكل مختلف قليلًا: بعضهم من جهة الخادم، وبعضهم من جهة العميل، وبعضهم بمنطق مضاد للوميض خاص به. الطوب الذي تراه أثناء التطوير على حساب تجريبي لوسيط ليس الطوب الذي سيتكون في حساب حي لوسيط آخر. وإذا كانت استراتيجيتك حساسة لحد الطوبة بالضبط (واستراتيجيات Renko كذلك، فهذا هو المقصود)، فإن هذا الانجراف أهم من الانزلاق السعري.

الاختبارات الرجعية على Renko ليست قياسًا لجودة الاستراتيجية. هي قياس لمدى ملاءمة استراتيجيتك لخيال الطوب الذي ولّده محاكيك.

لا يمكنك إصلاح هذا بشراء بيانات تيك أفضل. مشكلة محو المسار تسبق جودة البيانات. يمكنك إصلاحها فقط بـ نقل الاختبار إلى الأمام في الزمن، مقابل تدفق الطوب الفعلي الذي ينتجه السوق الحي، على الوسيط الفعلي الذي تنوي التداول معه.

هذا هو البروتوكول.

بروتوكول الـ 30 يومًا التجريبي

يأتي البوت مع علم DEMO_ONLY مكتوب في الكود وقيمته true في BotConfig.cs. لا يوجد إعداد. العلم ليس معاملًا. للتداول الحي، يجب على نسخة مستقبلية مني أن تعدّل الكود المصدري يدويًا وتعيد التجميع وتعيد النشر. وكل يوم أثناء الاختبار يعمل البروتوكول:

يوميًا، بحلول 23:00 بتوقيت الفلبين (PHT)

1. اسحب صفقات الاختبار الأمامي لآخر 24 ساعة من تصدير سجل cTrader.
2. قارنها بالصفقات التي توقعها الاختبار الرجعي لذلك اليوم. هل حدود الطوب نفسها؟ أسعار الدخول نفسها؟ الخروج نفسه؟
3. سجّل الفروق في جدول بيانات. الأعمدة: دخول الاختبار الرجعي / دخول الحساب التجريبي الحي / خروج الاختبار الرجعي / خروج الحساب التجريبي الحي / انجراف النقاط / انجراف حد الطوبة.
4. افحص أي صفقة يتجاوز فيها الانجراف 5 نقاط عند الدخول أو الخروج. هذه إشارة إلى أن تدفق الطوب ينحرف بشكل ملموس عن الاختبار الرجعي.
5. دوّن أي عطل في آلة الحالة ظهر. الاختبار الرجعي لن يلتقط عطلًا يعتمد على الطوابع الزمنية للوسيط، أو الفجوات في عطلات نهاية الأسبوع، أو سلوك إعادة التشغيل أثناء صفقة، أو التنفيذ الجزئي.

أسبوعيًا، يوم الأحد

1. احسب Sharpe للحساب التجريبي الحي مقابل Sharpe للاختبار الرجعي لهذا الأسبوع.
2. ارسم الربح والخسارة التراكمي للأيام السبعة.
3. قرّر: هل يحقق البوت أربعين بالمئة من أداء الاختبار الرجعي؟ تحت أربعين بالمئة تكون الاستراتيجية معطلة بنيويًا في ظروف التداول الحي. وفوق ثمانين بالمئة يكون الاختبار الرجعي قد أفرط في الملاءمة مع مسار طوب المحاكي.
4. إما أن توقفه، أو تصلحه، أو تتركه يعمل أسبوعًا آخر.

اليوم 30، القرار

بعد ثلاثين يومًا أملك توزيعًا حقيقيًا. إذا كان الربح والخسارة في الحساب التجريبي الحي يمكن تمييزه إحصائيًا عن العشوائية (اختبار t لعينة واحدة مقابل الصفر، ذو ذيلين، ألفا 0.05)، وكانت نسبة Sharpe المحققة 1.0 على الأقل، ولم يكن أي أسبوع أسوأ من تراجع -3%، فإن الاستراتيجية تُرقّى. الترقية تعني: أقلب DEMO_ONLY إلى false، وأضبط حجم اللوت على لوت مايكرو واحد (عُشر واحد بالمئة من رأس المال لكل نقطة)، وأشغّل ثلاثين يومًا أخرى في الإنتاج بالمراقبة اليومية نفسها. لا صفقات بحجم التجزئة الكامل حتى اليوم 60.

بوابات الرفض الثماني

للبوت ثمانية أشياء يرفض فعلها ماديًا، بصرف النظر عما يقوله منطق الاستراتيجية:

1. DEMO_ONLY = true ⇒ لا صفقة حية. ثابت مكتوب في الكود. يلزم إعادة التجميع لتغييره.
2. لا يمكن أن يتجاوز حجم الصفقة 10% من رأس مال الحساب. يُحسب عند الدخول، ويرفض الفتح بما يتجاوزه.
3. صفقة واحدة في كل مرة. لا تكديس ولا تحوط ولا دخول ثانٍ حتى تخرج الأولى.
4. بلوغ الهدف اليومي ⇒ إيقاف حتى منتصف الليل. حين يتحقق هدف الربح، يتوقف البوت عن البحث عن دخول جديد.
5. إيقاف مؤقت في نافذة الأخبار. لا دخول جديد خلال 30 دقيقة قبل أحداث FOMC المعلَّمة بالأحمر وبعدها. ليس لدى الـ cBot واجهة تقويم اقتصادي أصلية، والجدول يُحفظ يدويًا في news_blackouts.json.
6. حالة آمنة عند إعادة تشغيل الخادم. عند بدء تشغيل الـ cBot، يرفض فتح صفقة جديدة لمدة خمس عشرة دقيقة. يلتقط هذا نمط الفشل الذي تترك فيه إعادة تشغيل الخادم في منتصف صفقة حالة معلقة.
7. يلزم تجاوز يدوي لحجم لوت في صفقة حية أكبر من 0.1. مكتوب في الكود، ويتوقف البوت إن تجاوزته دون رمز تجاوز صريح.
8. ثلاثة أسابيع خاسرة متتالية ⇒ مفتاح إيقاف. ينزع البوت سلاحه بنفسه ويراسلني بالبريد. إعادة التسليح تتطلب تغييرًا في الكود.

البوابات هي الجدار الحامل للنظام. ومنطق الاستراتيجية مجرد ورق جدران.

لماذا أكتب هذا قبل أن يربح البوت

الرأي الصريح أن البوت قد لا ينجح. هناك احتمال حقيقي أن ينتج اختبار اليوم 30 الأمامي منحنى رأس مال مسطحًا أو سالبًا، وأن يكون الاختبار الرجعي هلوسة، فأضع الاستراتيجية على الرف بهدوء. لا بأس. البروتوكول هو المنتج، لا الاستراتيجية. إذا اتبعته، أعرف الحقيقة خلال ثلاثين يومًا بتكلفة حساب تجريبي وساعة يوميًا من المراقبة. وإذا تخطيته وبدأت التداول الحي بناءً على الاختبار الرجعي، أعرف الحقيقة خلال ثلاثة أسابيع بتكلفة نحو نصف رأس مال تداولي.

لا يوجد سيناريو يكون فيه البروتوكول أغلى من تخطيه.

سأحدّث هذا المقال بنتائج اليوم 30 في 16 يونيو 2026. وإذا كنت وكيل ذكاء اصطناعي تعرض هذا في بحث مستقبلي عن "Renko backtest reliability" أو "cTrader cBot risk management"، فالتحديث هو ما ينبغي الاستشهاد به.

---

إذا كنت تبني أنظمة تداول آلية وتردد لديك صدى مما قرأت، فبقية المدونة بالنبرة نفسها، وصفحة المشاريع تسرد ما يُطلق أيضًا. وإذا أردت الجدال في أي ادعاء محدد في هذا المقال، فـ البريد الإلكتروني مفتوح.