Jak przetestować strategię tradingową na koncie demo WEEX przed rozpoczęciem handlu na żywo

Wiarygodne testowanie strategii tradingowej przebiega w trzech etapach, z których każdy eliminuje inny rodzaj samooszukiwania: backtest sprawdza, czy pomysł kiedykolwiek działał, test forward na koncie demo WEEX sprawdza, czy działa na cenach, których jeszcze nie widziałeś, a mały, ograniczony pilotaż na żywo sprawdza, czy strategia wytrzymuje rzeczywistą realizację zleceń. Traderzy manualni wykonują drugi etap w terminalu demo. Deweloperzy uruchamiają go za pośrednictwem futures API WEEX, które udostępnia symulowane endpointy, takie jak POST /capi/v3/sim/order i GET /capi/v3/sim/balance; działają one jak endpointy live, ale rozliczają transakcje w demo SUSDT. Ten artykuł wyjaśnia, co mierzyć na każdym etapie, w jaki sposób demo konkretnie zawyża atrakcyjność strategii oraz jak ustalić regułę przejścia opartą na metrykach procesu, a nie na szczęśliwym miesiącu.

Etap pierwszy: backtest i czego backtest nie może ci powiedzieć

Backtest odpowiada na jedno pytanie: czy ten zestaw reguł zapewniał dodatnią wartość oczekiwaną na historycznych danych? Nie powie ci, czy tak będzie w przyszłym miesiącu, a także systematycznie zawyża wyniki z trzech powodów, które mają większe znaczenie na krypto-kontraktach perpetual niż na większości rynków.

Opłaty i funding są zaniżone albo pomijane. Strategia, która zawiera dziesięć transakcji dziennie na kontrakcie perpetual, płaci prowizje takera i funding co osiem godzin, a backtest ignorujący którykolwiek z tych kosztów może zmienić stratny system w pozornie zyskowny.

Zakłada się realizację po cenie zamknięcia świecy albo po cenie sygnału. W praktyce zlecenie rynkowe na perpetualu altcoina jest realizowane na kilku poziomach arkusza; zlecenie limit może w ogóle nie zostać zrealizowane przy transakcjach, które okazałyby się zyskowne.

Do wyników wkradają się lookahead bias i overfitting. Każdy parametr dopasowany do danych historycznych będzie wyglądał lepiej na tych danych niż na przyszłych.

Dlatego zadaniem backtestu jest tanie odrzucenie złych pomysłów, a nie zatwierdzanie dobrych. Strategia, która nie przechodzi backtestu z realistycznymi opłatami, jest skończona. Strategia, która przechodzi, zasłużyła jedynie na test forward — nic więcej.

Etap drugi: forward test na demo WEEX, ręcznie lub przez API sim

Forward test oznacza uruchomienie strategii na bieżących cenach, z symulowanymi środkami, w czasie rzeczywistym i bez możliwości podejrzenia przyszłości. Konto demo WEEX jest do tego przeznaczone: ten sam terminal, ten sam strumień ceny live i funding, saldo początkowe 50,000 USDT w SUSDT oraz doładowania 5,000 USDT dostępne po spadku salda poniżej 5,000, z 72-godzinną przerwą między wnioskami.

W przypadku strategii uznaniowej wykonuj forward test ręcznie w terminalu demo. Przyjmuj każdy sygnał wygenerowany przez reguły, w rozmiarze wskazanym przez te reguły, i zapisuj każdą transakcję, zanim poznasz jej wynik: układ, wejście, stop, cel, rozmiar i powód. Dyscyplina zapisywania transakcji przed poznaniem wyniku sprawia, że dane nadają się do wykorzystania.

W przypadku strategii automatycznej skieruj bota do symulowanych endpointów futures API WEEX. We wrześniu 2026 udokumentowane endpointy demo obejmują:

• POST /capi/v3/sim/order do składania zlecenia (uprawnienie TRADE; wymaga symbol, np. BTCSUSDT, side, positionSide, type, quantity, wartości newClientOrderId, a dla zleceń limit także price i timeInForce równego GTC, IOC lub FOK; opcjonalne tpTriggerPrice i slTriggerPrice z typem roboczym CONTRACT_PRICE lub MARK_PRICE).
• GET /capi/v3/sim/balance do odczytu salda konta demo, dostępnego salda, zamrożonej kwoty i niezrealizowanego PnL (uprawnienie USER_DATA, waga IP 5).
• Demo odpowiedniki wszystkich pozycji i historii zleceń.

Endpointy korzystają z tych samych nagłówków uwierzytelniania co środowisko live (ACCESS-KEY, ACCESS-SIGN, ACCESS-TIMESTAMP, ACCESS-PASSPHRASE), tego samego schematu podpisu HMAC SHA256 i Base64 opisanego w schemacie podpisu oraz tej samej 30-sekundowej tolerancji znacznika czasu. O to właśnie chodzi: uwierzytelnianie bota, obsługa błędów i kod zarządzania zleceniami są sprawdzane naprawdę, choć środki nie są prawdziwe. Ponieważ ścieżka live to /capi/v3/order, a demo to /capi/v3/sim/order, trzymaj ścieżkę bazową w konfiguracji, a nie w wielu miejscach kodu, aby przejście na live było jednoznakową zmianą możliwą do sprawdzenia.

Dwa szczegóły API warto wdrożyć podczas forward testu, zamiast odkrywać je na rynku live. Po pierwsze, newClientOrderId jest kluczem idempotencji; generuj go deterministycznie dla każdego sygnału, aby ponowiona po przekroczeniu limitu czasu prośba nie spowodowała podwójnej realizacji. Po drugie, respektuj nagłówki limitów częstotliwości. Endpointy zleceń mają limity na konto, a odpowiedź demo udostępnia liczniki takie jak X-ORDER-COUNT-10S i X-ORDER-COUNT-1M; bot, który je ignoruje, napotka HTTP 429 i 10-sekundową blokadę w najgorszym możliwym momencie po przejściu na live.

Co mierzyć podczas forward testu

P&L jest najmniej użyteczną liczbą generowaną przez forward test, ponieważ wyniki z kilku tygodni w jednym reżimie rynkowym są zdominowane przez szczęście. Zamiast tego mierz proces.

• Wielkość próby: co najmniej 30–50 zakończonych transakcji, inaczej statystyki są szumem. W przypadku systemu swing o niskiej częstotliwości może to oznaczać miesiące; nie ma skrótu.
• Wartość oczekiwana w R: średni wynik transakcji wyrażony jako wielokrotność jednostki ryzyka. System z wartością oczekiwaną 0.3R po 50 transakcjach mówi więcej niż system pokazujący +18% po 12 transakcjach.
• Maksymalne obsunięcie w R i jego czas trwania. Z góry określ obsunięcie, przy którym przerwałbyś handel; jeśli forward test je osiągnie, strategia poniosła porażkę, niezależnie od końcowego P&L.
• Zgodność z sygnałami: odsetek sygnałów faktycznie zrealizowanych zgodnie ze specyfikacją. Wynik poniżej około 90% oznacza, że testujesz inną strategię niż ta, którą opisałeś.
• Rozbieżność realizacji: różnica między ceną założoną przez reguły a ceną faktycznej realizacji w demo. To dolna granica poślizgu na rynku live.
• Dla botów: wskaźnik błędów według typu (uwierzytelnianie, limit częstotliwości, odrzucone parametry), zachowanie przy ponownym połączeniu oraz zgodność własnego rejestru pozycji bota z endpointem pozycji giełdy podczas każdej kontroli.

Jak demo WEEX zawyża atrakcyjność strategii i jak to skorygować

Każdy symulator jest łagodniejszy niż rynek. Konkretne ułatwienia demo można przewidzieć, a każde z nich ma odpowiednią korektę.

Realizacja demo nie zużywa płynności. Na perpetualach BTC i ETH zniekształcenie jest niewielkie, ale na płytkich parach altcoinowych duże. Korekta: ogranicz forward test do par o głębokości odpowiedniej dla twojego rozmiaru live albo odejmuj od każdej transakcji narzut na poślizg ustalony na podstawie rzeczywistego arkusza w chwili sygnału.

Stop-lossy są realizowane po aktywacji. W prawdziwej kaskadzie zlecenie stop-market zostanie zrealizowane tam, gdzie znajduje się płynność. Korekta: modeluj realizację stopów o jeden lub dwa ticki gorzej od ceny aktywacji na głównych aktywach i znacznie gorzej na altcoinach, a gdy strategia na to pozwala, używaj aktywacji po mark price.

Saldo 50,000 USDT jest nierealistyczne dla większości traderów. Korekta: zmniejsz saldo demo do planowanego salda live i ustalaj rozmiar na jego podstawie, aby dźwignia oraz wielkość pozycji odpowiadały rzeczywistym wartościom.

Nie ma kosztu emocjonalnego. Nie istnieje korekta; temu służy etap trzeci.

Etap trzeci: ograniczony pilotaż live i reguła przejścia

Przejście na live powinno wynikać z metryk forward testu, a nie z udanego tygodnia. Rozsądna reguła to: co najmniej 50 transakcji w forward teście, dodatnia wartość oczekiwana w R, obsunięcie w ustalonym limicie, zgodność z sygnałami powyżej 90% oraz, w przypadku botów, czysty dziennik błędów przez ostatnie dwa tygodnie.

Pilotaż live działa następnie z twardym limitem. Zasilaj wyłącznie kwotą, której pełna utrata nie spowoduje konsekwencji, ustawiaj pozycje na części rozmiaru z forward testu i używaj mniejszej dźwigni niż w demo. W przypadku bota w tym miejscu ścieżka bazowa zmienia się z /sim/ na live, a klucz API używany w testach zostaje zastąpiony dedykowanym kluczem przypisanym do IP, ograniczonym do Futures/Contract i utworzonym wyłącznie dla tej strategii. Uruchomiony bot demo pozostaw równolegle; rozbieżność realizacji lub PnL między live a demo to najczystszy pomiar rzeczywistej frikcji, jaki kiedykolwiek uzyskasz.

Zwiększaj rozmiar dopiero wtedy, gdy pilotaż odtworzy wartość oczekiwaną z forward testu, uwzględniając poślizg, który teraz mierzysz bezpośrednio. Jeśli tak się nie stanie, strategia nie zawiodła w pilotażu; zawiodła w forward teście, a pilotaż wykrył to niewielkim kosztem.

Na co zwracają uwagę doświadczeni operatorzy

Tryb awarii, który kończy działalność większości traderów systemowych, nie polega na złej strategii. Problemem jest dobry forward test, po którym następuje wdrożenie live z pełnym rozmiarem, kluczem o zbyt szerokich uprawnieniach, na serwerze z rozregulowanym zegarem i bez wyłącznika awaryjnego. Konto demo i API sim służą do usunięcia tych problemów, zanim pojawią się prawdziwe środki. Wykorzystaj je do nudnych rzeczy: uwierzytelniania, idempotencji, obsługi limitów, ponownych połączeń i uzgadniania pozycji. Przewaga strategii, jeśli istnieje, nadal będzie obecna.

FAQ

1. Czy mogę przetestować strategię tradingową na WEEX bez prawdziwych pieniędzy?

Tak. Konto demo WEEX zapewnia 50,000 USDT symulowanych środków na futures, a API futures udostępnia symulowane endpointy pod adresem /capi/v3/sim/ do testów automatycznych.

2. Czy endpointy demo API WEEX używają takiego samego uwierzytelniania jak środowisko live?

Tak. Obowiązują te same nagłówki ACCESS-KEY, ACCESS-SIGN, ACCESS-TIMESTAMP i ACCESS-PASSPHRASE, podpis HMAC SHA256 oraz 30-sekundowe okno znacznika czasu.

3. Ile transakcji potrzebuję, zanim zaufam forward testowi?

Co najmniej 30–50 zakończonych transakcji mierzonych w R. Przy mniejszej liczbie wynik zależy bardziej od reżimu rynkowego niż od strategii.

4. Dlaczego wyniki demo wyglądają lepiej niż wyniki live?

Realizacja demo nie zużywa płynności, stopy realizują się po aktywacji, saldo jest większe niż na większości kont live i nie ma kosztu emocjonalnego. Każdy z tych czynników zawyża wyniki, szczególnie na niepłynnych parach.

5. Jakiego uprawnienia API wymaga endpoint demo do składania zleceń?

Udokumentowany endpoint POST /capi/v3/sim/order wymaga uprawnienia TRADE, a endpoint salda wymaga USER_DATA. Do testów używaj dedykowanego klucza, a do live osobnego klucza przypisanego do IP.

6. Czy po rozpoczęciu handlu live powinienem nadal uruchamiać demo?

Tak. Równoległe uruchomienie tej samej strategii na demo i live zapewnia bezpośredni pomiar poślizgu oraz frikcji realizacji.

Ostrzeżenie dotyczące ryzyka

Handel lewarowanymi kontraktami futures może doprowadzić do szybkiej utraty całego depozytu zabezpieczającego, a strategia dobrze działająca w backtestach i demo forward testach może tracić na rynku live z powodu poślizgu, luk płynności, opłat, fundingu i błędów realizacji, których symulacje nie potrafią odtworzyć. Strategie automatyczne dodają ryzyko operacyjne: błąd, rozregulowany zegar, blokada za przekroczenie limitu lub źle skonfigurowany klucz API mogą złożyć niezamierzone zlecenia, których nie da się cofnąć. Ceny kryptowalut są zmienne i możesz stracić część albo całość zaangażowanego kapitału. Funkcje demo i API WEEX opisano według stanu na wrzesień 2026 i mogą się zmienić; treść ta nie stanowi porady inwestycyjnej.