بشر يطورون Codex بأقل من 1%！
لم يمضِ أمس أن حصلت للتو على الـ API، وقضيت بعض الوقت في كتابة سكربت يعلّق أوامر
إجمالي أصول الحساب الابتدائية 311.8u
شغلت طوال الليل، فحققّت حجم تداول 8k وربحت 1.31u
تكلفة النقاط في مثل هذه الحالة تكون تقريبًا سالبة
والسبب الرئيسي هو أن سيولة المنصة الآن ممتازة جدًا
كتابة هذا السكربت تتطلب مراعاة أشياء كثيرة:
- ما الذي يمكن تشغيله بالتوازي، وما الذي يجب أن يكون تسلسليًا؟
يمكن قراءة البيانات بالتوازي، لكن يُفضّل أن تكون عملية إرسال الأوامر وإلغاؤها تسلسلية؛ وإلا فقد يحدث بسهولة أن يتم حذف/إلغاء أمر تم إرساله للتو بسبب تشغيل خيط آخر بالخطأ، أو يحدث تعليق مزدوج
- هل نُفصل خيطَي BUY و SELL؟
ـ BUY يحتاج إلى مسح للسوق والدفتر، وهو بطيء نسبيًا؛
ـ SELL يحتاج إلى مراقبة المراكز في الحساب، والاستجابة يجب أن تكون سريعة.
بعد الفصل، لن تقوم عملية SELL بالتباطؤ بسبب فحص BUY الكامل
- كيف نصمم الـ state المحلي؟
لا يمكن الاعتماد فقط على open orders من الـ API، لأن حالة البورصة ليست متطابقة لحظيًا. بعد نجاح create order، قد لا تظهر open orders إلا بعد عدة ثوانٍ. الـ state المحلي يجب أن يتحمل مسؤولية منع التكرار على المدى القصير، ومنع الإرسال المكرر، ومنع الإلغاء/التنظيف الخاطئ
- كيفية التعامل مع eventual consistency؟
لا يمكن اعتبار أن الطلب الذي تم إنشاؤه للتو غير صالح لمجرد أن open orders لا تظهر في البحث بعد ثانية. يجب تحديد نافذة انتظار مثل 30-60 ثانية، لتجنب قيام خيط مزامنة الحساب بإزالة الطلب الجديد بالغلط
- كيف نحصل على سعر الطلب؟
Yes / No و Over / Under بهذه النواتج العكسية من السهل جدًا حسابها بشكل خاطئ. خصوصًا عند SELL، الأفضل استخدام bestAsk الخاص بنتيجة الموقف الحالي، بدلًا من أخذ جانب Yes من دفتر الأوامر بشكل أعمى ثم عمل complement
- كيف نتعامل مع دقة الكمية/الحصص؟
عرض الواجهة 17.86 لا يعني أن هذا هو مقدار ما يمكن بيعه فعليًا 17.86. يجب دائمًا قطع كمية الطلب للأسفل (downward truncation)، ولا يجوز التقريب؛ وإلا فقد يظهر خطأ insufficient shares
- كيف نصنّف استثناءات الـ API؟
hash mismatch، رصيد غير كافٍ، حصص غير كافية، انقطاع اتصال بعيد، تقطيع في الاستجابة، تأخر مزامنة الأوامر—طرق المعالجة تختلف. لا يجوز الاكتفاء بمحاولات retry غير محدودة
- كيف نكتب حدود التحكم في المخاطر؟
لا بيع بسعر السوق، لا تنفيذ يأكل السيولة (no take)، post-only، تقييد نطاق BUY، إلغاء أوامر الشراء قبل بدء الجولة… يجب تحويل هذه الأمور إلى قيود صارمة داخل الكود
ليس المقصود أنه بمجرد وجود AI يمكن بسهولة بناء نظام مستقر طويل الأمد وقابل للتسليم بشكل موثوق. يجب أن ننطلق من منظور الهندسة: إجراء اختبارات الاستقرار ووضع ضوابط المخاطر
الأصدقاء المهتمون تعالوا نتبادل الحديث～
@Predictdotfun
لم يمضِ أمس أن حصلت للتو على الـ API، وقضيت بعض الوقت في كتابة سكربت يعلّق أوامر
إجمالي أصول الحساب الابتدائية 311.8u
شغلت طوال الليل، فحققّت حجم تداول 8k وربحت 1.31u
تكلفة النقاط في مثل هذه الحالة تكون تقريبًا سالبة
والسبب الرئيسي هو أن سيولة المنصة الآن ممتازة جدًا
كتابة هذا السكربت تتطلب مراعاة أشياء كثيرة:
- ما الذي يمكن تشغيله بالتوازي، وما الذي يجب أن يكون تسلسليًا؟
يمكن قراءة البيانات بالتوازي، لكن يُفضّل أن تكون عملية إرسال الأوامر وإلغاؤها تسلسلية؛ وإلا فقد يحدث بسهولة أن يتم حذف/إلغاء أمر تم إرساله للتو بسبب تشغيل خيط آخر بالخطأ، أو يحدث تعليق مزدوج
- هل نُفصل خيطَي BUY و SELL؟
ـ BUY يحتاج إلى مسح للسوق والدفتر، وهو بطيء نسبيًا؛
ـ SELL يحتاج إلى مراقبة المراكز في الحساب، والاستجابة يجب أن تكون سريعة.
بعد الفصل، لن تقوم عملية SELL بالتباطؤ بسبب فحص BUY الكامل
- كيف نصمم الـ state المحلي؟
لا يمكن الاعتماد فقط على open orders من الـ API، لأن حالة البورصة ليست متطابقة لحظيًا. بعد نجاح create order، قد لا تظهر open orders إلا بعد عدة ثوانٍ. الـ state المحلي يجب أن يتحمل مسؤولية منع التكرار على المدى القصير، ومنع الإرسال المكرر، ومنع الإلغاء/التنظيف الخاطئ
- كيفية التعامل مع eventual consistency؟
لا يمكن اعتبار أن الطلب الذي تم إنشاؤه للتو غير صالح لمجرد أن open orders لا تظهر في البحث بعد ثانية. يجب تحديد نافذة انتظار مثل 30-60 ثانية، لتجنب قيام خيط مزامنة الحساب بإزالة الطلب الجديد بالغلط
- كيف نحصل على سعر الطلب؟
Yes / No و Over / Under بهذه النواتج العكسية من السهل جدًا حسابها بشكل خاطئ. خصوصًا عند SELL، الأفضل استخدام bestAsk الخاص بنتيجة الموقف الحالي، بدلًا من أخذ جانب Yes من دفتر الأوامر بشكل أعمى ثم عمل complement
- كيف نتعامل مع دقة الكمية/الحصص؟
عرض الواجهة 17.86 لا يعني أن هذا هو مقدار ما يمكن بيعه فعليًا 17.86. يجب دائمًا قطع كمية الطلب للأسفل (downward truncation)، ولا يجوز التقريب؛ وإلا فقد يظهر خطأ insufficient shares
- كيف نصنّف استثناءات الـ API؟
hash mismatch، رصيد غير كافٍ، حصص غير كافية، انقطاع اتصال بعيد، تقطيع في الاستجابة، تأخر مزامنة الأوامر—طرق المعالجة تختلف. لا يجوز الاكتفاء بمحاولات retry غير محدودة
- كيف نكتب حدود التحكم في المخاطر؟
لا بيع بسعر السوق، لا تنفيذ يأكل السيولة (no take)، post-only، تقييد نطاق BUY، إلغاء أوامر الشراء قبل بدء الجولة… يجب تحويل هذه الأمور إلى قيود صارمة داخل الكود
ليس المقصود أنه بمجرد وجود AI يمكن بسهولة بناء نظام مستقر طويل الأمد وقابل للتسليم بشكل موثوق. يجب أن ننطلق من منظور الهندسة: إجراء اختبارات الاستقرار ووضع ضوابط المخاطر
الأصدقاء المهتمون تعالوا نتبادل الحديث～
@Predictdotfun
