Bot API Kalshi powinien zdobywać swój zakres działania przez wykazane zachowanie. Udane połączenie lub jedno przyjęte zlecenie nie pokazuje, jak program obsługuje częściowe wykonania, powtórzone wiadomości, zmienione ograniczenia rynku lub awarię po transmisji. Te przypadki określają wiarygodność jego zapisu konta, gdy zwykłe założenia zawodzą.
Kryteria akceptacji przekładają szerokie określenia, takie jak niezawodny lub bezpieczny, na obserwowalne wyniki. Określają początkowy stan konta, wprowadzone zdarzenie, działanie dozwolone botowi i oczekiwane później zapisy. Test, który nie potrafi określić oczekiwanego wyniku ekonomicznego, prawdopodobnie niewiele ustali o zachowaniu bota.
Ten poradnik przedstawia hipotetyczne ćwiczenia akceptacji w zatwierdzonym procesie rozwoju. Limity liczbowe i ceny są wymyślone. Testy demonstracyjne, symulowane odpowiedzi i odtwarzane zapisy mogą oceniać zachowanie oprogramowania bez dowodzenia produkcyjnej płynności lub rentowności strategii. Wszelkie rzeczywiste uprawnienia handlowe pozostają oddzielną decyzją ograniczoną instrukcjami właściciela konta.
Najpierw zapisz kryteria akceptacji bota API Kalshi
Kryteria akceptacji bota Kalshi powinny opisywać wyniki przed szczegółami wdrożenia. Na przykład dwukrotne odtworzenie tego samego wykonania musi zmienić pozycję raz. Wygasła propozycja nie może stać się nowym zleceniem. Utracona odpowiedź musi tworzyć stan nierozstrzygnięty, zamiast automatycznie zwalniać rezerwację.
Określ dowody wymagane do zaliczenia. Komunikat konsoli o zignorowaniu duplikatu nie wystarcza, jeżeli ewidencja nadal policzyła ilość podwójnie. Zbadaj wynikową pozycję, opłaty, stan zlecenia i dziennik. Wynik akceptacji powinien być zrozumiały dla osoby, która nie napisała odpowiedniego kodu.
Starszy poradnik bota handlowego API Kalshi w Pythonie opisuje niezawodne projektowanie poza klientem konkretnego języka. Użyj tutaj tej perspektywy: ważne jest zachowanie na granicy konta. Wybór języka programowania nie usuwa potrzeby weryfikowania znaczenia ekonomicznego.
Ustal znany początkowy stan konta
Każde ćwiczenie potrzebuje stanu początkowego możliwego do niezależnego sprawdzenia. Określ pozycje, aktywne zlecenia, dostępną zdolność i nierozstrzygnięte zamiary. Bez znanego punktu odniesienia późniejszą niezgodność można przypisać niewyjaśnionemu wcześniejszemu warunkowi zamiast badanemu zachowaniu.
Dla hipotetycznego zestawu zacznij od dziesięciu kontraktów Yes, aktywnego zlecenia pięciu kontraktów i limitu trzydziestu kontraktów na zdarzenie. Bot powinien obliczyć piętnaście kontraktów istniejącej lub możliwej ekspozycji według tych prostych zasad. Nowe żądanie dwudziestu przekroczyłoby limit, gdyby wszystkie ilości stały się pozycjami.
Zachowuj te dane testowe oddzielnie od informacji rzeczywistego konta. Test nigdy nie powinien bez powiadomienia pożyczać produkcyjnych danych uwierzytelniających ani wnioskować o nieszkodliwości znajomego identyfikatora rynku. Wyraźnie określaj środowisko i używaj właściwych mu kontroli. Celem jest testowanie ograniczonego zachowania, a nie odkrywanie stanu konta przez przypadkowe wykonanie.
Testuj dokładne kwoty dziesiętne
Bieżąca dokumentacja Kalshi używa stałoprzecinkowych cen i ilości. Akceptacja powinna obejmować wartości, z którymi parser całkowitych centów lub całych kontraktów poradziłby sobie błędnie, z zachowaniem hipotetycznych ograniczeń rynku ćwiczenia.
Użyj wymyślonej poprawnej ceny 0,3375 USD i ilości 8,40 kontraktów. Ich wartość zakupu wynosi 2,835 USD przed opłatami. Oczekiwana ewidencja powinna zachowywać dokładny iloczyn na etapie, na którym ma znaczenie, a następnie oddzielnie stosować udokumentowane końcowe reguły zaokrąglania. Obcięcie ilości do ośmiu jest niepowodzeniem.
Testuj też nieprawidłowe formaty, brakujące jednostki i wartości poza dozwolonym zakresem. Bot powinien odrzucać lub odseparowywać niejednoznaczną kwotę zamiast zgadywać. Parser akceptujący niepoprawne wartości, ponieważ potrafi wyciągnąć jakieś cyfry, tworzy niebezpieczną różnicę między treścią danych wejściowych a dozwolonym działaniem konta.
Testuj siatkę cen niezależnie od precyzji
Wartość dziesiętna może być poprawna składniowo, lecz poza dozwoloną siatką rynku. Bot powinien odczytywać bieżące ograniczenia cen i weryfikować względem nich proponowany limit. Ciąg z czterema miejscami dziesiętnymi nie jest automatycznie poprawną ceną o czterech miejscach dla każdego rynku.
W hipotetycznym przedziale z krokami 0,005 USD zamierzona maksymalna cena kupna 0,3375 USD leży między 0,335 USD a 0,340 USD. Jeżeli zasady zaokrąglają do dopuszczalnej ceny kupna, nie może ona przekroczyć zatwierdzonego maksimum. Zaokrąglenie w górę do 0,340 USD naruszałoby tę konkretną instrukcję.
Przetestuj zmianę siatki między utworzeniem propozycji a wysłaniem. Oczekiwanym zachowaniem powinna być świeża weryfikacja, zatwierdzona korekta lub odrzucenie do przeglądu. Bot nie powinien wielokrotnie wysyłać niepoprawnej ceny, zakładając, że każde odrzucenie jest przejściowym problemem sieciowym.
Testuj kierunek ekonomiczny na przypadkach w prostym języku
Adapter zleceń powinien prawidłowo przekładać zamierzoną przez użytkownika ekspozycję wyniku na pola kierunku bieżącego punktu końcowego. Dokumentacja kierunku zleceń Kalshi jest odniesieniem do interpretacji bieżących pól odpowiedzi. Znaczenie żądań należy także sprawdzać względem dokładnie używanego punktu końcowego.
Zapisuj przypadki ludzkim językiem przed badaniem serializowanych danych: zwiększyć ekspozycję Yes przy maksymalnej cenie, zmniejszyć istniejącą pozycję przy minimalnej cenie lub wyrazić obsługiwaną decyzję strony No przez bieżący interfejs. Odkoduj każde żądanie z powrotem na prosty język i porównaj z pierwotnym zamiarem.
Uwzględniaj przypadki cen komplementarnych, ponieważ mogą ukrywać błędy. Liczbowo wiarygodna wartość po niewłaściwej stronie może tworzyć poprawną, lecz niezamierzoną ekspozycję. Zaliczenie walidatora schematu dowodzi tylko dopuszczalnego kształtu żądania; akceptacja musi też dowieść przenoszenia przez ten kształt zamierzonej instrukcji ekonomicznej.
Testuj granicę uprawnień
Daj botowi uprawnienia do obserwowania szerokiej listy rynków, ale handlu tylko na małym zatwierdzonym podzbiorze. Następnie przedstaw atrakcyjną propozycję spoza niego. Oczekiwanym wynikiem jest zapisane odrzucenie bez podpisanego lub wysłanego zlecenia.
Powtórz ćwiczenie z nieobsługiwanym typem zlecenia, nadmierną ilością i wygasłą autoryzacją. Każde powinno zostać zatrzymane na odpowiedniej bramce. Wyjaśnienie generowane przez model nie powinno móc unieważnić zasad pilnym językiem lub twierdzeniem o wyjątkowo wysokiej pewności.
Poradnik automatyzacji Polymarket porównuje procesy ręczne, nadzorowane i delegowane. Przydatna ogólna lekcja mówi, że uprawnienie musi być wyraźne na każdym etapie. Dla tego bota Kalshi zapis akceptacji powinien dokładnie pokazywać odmówione działanie i nadal dozwoloną pracę obserwacyjną lub uzgadniającą.
Testuj równoczesne propozycje względem jednego limitu
Dwie propozycje mogą przechodzić pojedynczo, a razem przekraczać wspólny limit. Akceptacja powinna wprowadzać je wystarczająco blisko w czasie, by ujawnić wyścig między sprawdzeniem zdolności a zapisaniem rezerwacji. Oczekiwanym zachowaniem jest skoordynowana autoryzacja, a nie dwie niezależne zgody oparte na tym samym nieaktualnym obrazie.
Wróć do hipotetycznego limitu trzydziestu kontraktów z piętnastoma już posiadanymi lub zaangażowanymi. Dwie propozycje żądają po dziesięć. Tylko jedno zwiększenie o dziesięć mieści się, jeżeli zasady oceniają ilość przy najgorszym możliwym wykonaniu; drugie podniosłoby potencjalną ekspozycję do trzydziestu pięciu. Bot musi odrzucić, zmienić wielkość według zatwierdzonych zasad lub odroczyć drugą propozycję.
Zbadaj wspólną ewidencję po obu decyzjach. Powinna zawierać jedną spójną sumę rezerwacji i powód odroczenia lub odrzucenia propozycji. Test nie powinien być zaliczony tylko dlatego, że późniejsze odrzucenie platformy przypadkiem zapobiegło nadwyżce. Własna granica autoryzacji aplikacji musi działać.
Testuj idempotentne przetwarzanie wykonań
Idempotentne przetwarzanie wykonań oznacza, że otrzymanie tego samego ekonomicznego wykonania więcej niż raz ma taki sam skutek dla konta jak otrzymanie raz. Strumienie, ponowne połączenia i późniejsze zapytania konta mogą dostarczać nakładające się dowody. Bot musi rozpoznawać to samo wykonanie według stałego identyfikatora i udokumentowanego znaczenia rewizji.
Zacznij od dziesięciu kontraktów i wprowadź wykonanie czterech. Wynikowa pozycja wynosi czternaście. Odtwórz to samo wykonanie drugą ścieżką; wynik powinien pozostać czternaście z powiązaną opłatą zapisaną raz. Drugie odrębne wykonanie czterech kontraktów powinno następnie dać osiemnaście.
Ten test odróżnia powieloną transmisję od powtórzonego prawidłowego handlu. Usuwanie duplikatów tylko według ilości i ceny błędnie odrzucałoby oddzielne wykonania o przypadkiem identycznych warunkach. Zapis potrzebuje identyfikatorów i pochodzenia wystarczająco mocnych do zachowania rzeczywistych wykonań przy pomijaniu powtarzających się obserwacji tego samego.
Testuj częściowe wykonania i stan reszty
Częściowe wykonanie powinno aktualizować zasoby o wykonaną ilość i zachowywać poprawny stan niewykonanej części. Wybrane zachowanie czasu obowiązywania ma znaczenie. Oczekująca reszta i anulowana natychmiastowa reszta są różnymi zobowiązaniami konta nawet przy identycznej wykonanej ilości.
W hipotetycznym zleceniu dwunastu kontraktów pięć wykonuje się po 0,40 USD, kosztując 2 USD przed opłatami. Siedem pozostaje niewykonanych. Jedno ćwiczenie pozostawia te siedem aktywnymi; inne kończy je według wybranego udokumentowanego zachowania zlecenia natychmiastowego. Oczekiwane panele rezerwacji i zleceń powinny odpowiednio się różnić.
Bot nigdy nie powinien wnioskować, że każde częściowe wykonanie tworzy aktywną resztę. Powinien też unikać traktowania anulowanej reszty jako anulowania wykonanych pięciu. Sprawdzaj razem pozycję, koszt zakupu, opłaty i końcowy stan zlecenia, aby test weryfikował pełny wynik ekonomiczny.
Polecaj i zarabiaj USDC
Polecaj i zarabiaj USDCNasz program partnerski wypłaca prowizje w czasie rzeczywistym.
Testuj utraconą odpowiedź wysłania
Zasymuluj transmisję zlecenia, po której odpowiedź zostaje utracona. W jednym przypadku platforma je przyjęła, w innym odrzuciła. Bot początkowo ma ten sam lokalny objaw, więc pierwsza reakcja powinna zachowywać niepewność i badać pierwotny zamiar.
Oczekiwane zachowanie obejmuje zachowanie właściwej rezerwacji, unikanie świeżego niepowiązanego zlecenia i sprawdzanie obsługiwanych zapisów zleceń oraz wykonań. Test powinien weryfikować, że sama pusta lista otwartych zleceń nie zamyka sprawy, jeżeli zlecenie mogło wykonać się w całości.
Identyfikator zlecenia klienta może pomagać łączyć zapisy, ale bot musi zweryfikować bieżące zasady obsługi duplikatów platformy, zamiast zakładać nieograniczone wykonanie dokładnie raz. Lokalne przetwarzanie idempotentne, identyfikacja żądania i gwarancje zdalnego przyjęcia są powiązanymi narzędziami o różnych zakresach. Kryteria akceptacji powinny określać rzeczywiście badaną gwarancję.
Testuj awarię po przyjęciu
Szczególnie przydatne ćwiczenie odzyskiwania po restarcie zatrzymuje proces po przyjęciu zlecenia przez platformę, lecz przed zapisaniem lokalnego sukcesu. Po restarcie bot powinien wczytać trwały zamiar i uzgodnić zdalny stan przed decyzją, czy cokolwiek wymaga wysłania.
Jeżeli po prostu odtworzy każdy zamiar bez lokalnej flagi ukończenia, może tworzyć podwójną ekspozycję. Oczekiwanym wynikiem odzyskiwania jest jedno ekonomiczne zlecenie połączone z pierwotnym zamiarem, z każdą aktywną ilością lub wykonaniem odzwierciedlonym w ewidencji konta. Jeżeli na podstawie dostępnych dowodów nie można ustalić tej relacji, wynik powinien pozostać wyraźnie nierozstrzygnięty.
Starszy poradnik bota automatycznego handlu Kalshi wyjaśnia stany operacyjne. Restart powinien być przejściem przez obserwację i uzgodnienie, a nie automatycznym skokiem do nieograniczonego handlu. Akceptacja powinna badać to przejście, zamiast tylko potwierdzać udane uruchomienie procesu.
Testuj anulowanie podczas wykonania
Wprowadź wykonanie podczas trwającego anulowania. Bot powinien uzgodnić wykonaną ilość i rzeczywiście usuniętą część. Żądanie anulowania wyraża zamiar; nie zapobiega wstecz wykonaniu, które już nastąpiło.
Dla wymyślonej aktywnej reszty dziewięciu kontraktów załóż wykonanie trzech przed anulowaniem pozostałych sześciu. Pozycja konta zwiększa się o trzy, a zobowiązanie związane z sześcioma się kończy. Propozycja zastąpienia powinna używać tego wynikowego stanu, zamiast zakładać anulowanie wszystkich dziewięciu.
Sprawdzaj wyjaśnienie dla operatora obok liczb. Interfejs powinien pokazywać, dlaczego końcowa pozycja różni się od ilości widocznej na początku anulowania. Ogólna etykieta anulowania może ukrywać dodatkowe wykonanie i zachęcać do zbyt dużego zastąpienia, nawet jeżeli podstawowa ewidencja akurat zawiera poprawną ilość.
Testuj zmieniony stan rynku
Propozycja może być poprawna przy utworzeniu i niepoprawna przy wysłaniu. Wprowadź pauzę, zamknięcie lub zmienione ograniczenie rynku między etapami. Oczekiwane zachowanie powinno wynikać z bieżących reguł platformy i zasad aplikacji, bez próby obchodzenia stanu wielokrotnymi żądaniami.
Dokumentacja cyklu rynku Kalshi opisuje bieżące etapy handlu i rozliczenia. Zestaw akceptacji powinien używać tego znaczenia, zamiast zakładać, że jedna ogólna flaga otwarte lub zamknięte obejmuje każdy obowiązek.
Badania mogą trwać przy wyłączonym tworzeniu zleceń, a uzgadnianie może pozostać konieczne po zakończeniu handlu. Testuj te możliwości oddzielnie. Bot zatrzymujący wszelką obserwację konta po zamknięciu rynku może przeoczyć właśnie zapisy potrzebne do ustalenia końcowych pozycji, opłat i rozliczenia. Ograniczenia operacyjne powinny zawężać działania bez usuwania obowiązku rozliczenia wcześniejszych.
Testuj luki strumienia i nakładające się odczyty odzyskiwania
Odłącz prywatny strumień podczas wykonań, a następnie połącz ponownie i pobierz historię konta. Odzyskiwanie może napotkać wykonania już widziane przed luką i nowe. Oczekiwana ewidencja powinna uwzględniać każde zdarzenie ekonomiczne raz i wskazywać odzyskany przedział.
Przydatne ćwiczenie zwraca zapisy w niewygodnej kolejności. Późna aktualizacja nie powinna nadpisywać nowszego stanu tylko dlatego, że lokalnie dotarła później. Zachowuj identyfikatory zdarzeń, odpowiednie znaczniki czasu i udokumentowane informacje wersji przy ustalaniu relacji zapisów.
Jeżeli nie można ustalić pełnego pokrycia, bot powinien zachować wyjątek i ograniczyć nową ekspozycję według zasad. Precyzyjnie wyglądająca pozycja z niepełnego strumienia nie oznacza udanego odzyskiwania. Test przechodzi, gdy wynik jest zweryfikowany lub uczciwie nierozstrzygnięty z jasnym następnym krokiem.
Testuj limity wywołań bez zmiany zamiaru
Odczyt lub zapis objęty limitem wywołań nie powinien powodować zmiany znaczenia ekonomicznego żądania przez bota. Wydłużenie odstępów może zmieniać czas, ale nie może bez powiadomienia zwiększać ilości, poszerzać limitu ani generować nowego niezależnego zamiaru. Opóźnione propozycje mogą wygasać podczas czekania.
Przećwicz zwykłe ograniczanie danych rynkowych i prywatne żądanie uzgodnienia potrzebne do rozstrzygnięcia niepewności. Bot powinien nadawać priorytety według zasad operacyjnych i zachowywać wystarczającą zdolność do niezbędnej obserwacji konta tam, gdzie pozwala interfejs. Nie powinien zużywać każdego dostępnego żądania na mało wartościowe odświeżenia ofert.
Zapisuj rzeczywiste opóźnienie w historii badań i wykonania. Strategia nie może przypisywać sobie pierwotnej oferty, jeżeli limit wywołań odroczył decyzję. Wynik akceptacji powinien pokazywać ponowną weryfikację lub odrzucenie nieaktualnych propozycji oraz zachowanie powiązania nierozstrzygniętych wysłań z pierwotnymi rezerwacjami.
Testuj awarię danych uwierzytelniających jako kontrolowany stan
Wygasłe, unieważnione lub źle skonfigurowane dane uwierzytelniające powinny tworzyć jasny stan utraty możliwości. Bot powinien unikać ujawniania sekretów w komunikatach błędów i nie powinien przechodzić na niezamierzone konto lub środowisko tylko po to, by żądanie się powiodło.
Odróżniaj obserwację publiczną od prywatnego dostępu. Ekran danych rynkowych może nadal działać przy awarii odczytów konta i działań zleceń. Interfejs powinien wyjaśniać różnicę, aby operator nie wnioskował, że ruchomy ekran cen dowodzi prawidłowego połączenia handlowego.
Poradnik platformy handlowej Kalshi omawia dostęp do konta i użyteczność operacyjną. Akceptacja powinna obejmować to, co czytelnik widzi podczas awarii danych uwierzytelniających: dotknięte uprawnienia, ostatni zweryfikowany czas konta i nierozstrzygnięte zobowiązania. Ogólna etykieta braku połączenia nie wystarcza, jeżeli ukrywa obowiązki nadal możliwe do wykonania.
Testuj powierzchnię przeglądu dla człowieka
Bot może zachowywać poprawne zapisy wewnętrzne i nadal mylić operatora słabą prezentacją. Testuj, czy ekran odróżnia stany proponowane, zatwierdzone, wysłane, aktywne, wykonane i uzgodnione. Pokazuj częściowe ilości i nierozstrzygnięte pozycje bez wymagania interpretacji surowych logów przez czytelnika.
Poproś recenzenta o wyjaśnienie wymyślonego incydentu z samego wyświetlanego zapisu. Powinien wskazać kontrakt, możliwą ekspozycję, ostatnie zweryfikowane dowody i następne działanie. Jeżeli nie potrafi, zestaw akceptacji znalazł problem użyteczności mogący pod presją stać się problemem operacyjnym.
Porównanie z platformą handlową Polymarket pomaga oddzielić ogólne obowiązki interfejsu od mechaniki platformy. Jasne informacje o przechowywaniu aktywów, zleceniach i rozliczeniu mają znaczenie w obu kontekstach, ale etykiety muszą opisywać rzeczywisty model konta. Wspólny projekt wizualny nie powinien nadawać odmiennym stanom pozoru ekonomicznej identyczności.
Zachowuj wersjonowane dowody akceptacji
Zapisuj scenariusz, wersję klienta, konfigurację i zaobserwowany wynik dla każdego uruchomienia akceptacji. Późniejszą zmianę kodu lub schematu można wtedy porównać ze znanym punktem odniesienia. Bez wersjonowanych dowodów twierdzenie o zaliczeniu testów przez bota może odnosić się do nieużywanej już konfiguracji.
Skupiaj kontrole regresji na istotnych granicach: kwotach, kierunku, uprawnieniach, przetwarzaniu duplikatów i odzyskiwaniu. Setki powtórzeń udanego zwykłego testu połączenia niewiele dodają, jeżeli migracja zmieniła pole określające kupno lub sprzedaż zamierzonego wyniku przez zlecenie.
Starszy poradnik API handlu rynków predykcyjnych wyjaśnia połączenie i weryfikację jako odrębne obowiązki. Dowody akceptacji powinny podobnie odróżniać dostępność interfejsu od prawidłowego zachowania pełnego procesu konta. Oba są użytecznymi faktami, ale tylko jeden dotyczy trudnych przypadków operacyjnych.
Przyznaj botowi API Kalshi tylko zaliczony zakres
Akceptacja jest podstawą ograniczonej decyzji operacyjnej. Bot zaliczający testy uzgodnienia tylko do odczytu nie wykazał automatycznie odzyskiwania rzeczywistych zleceń. Bot testowany na jednym typie zlecenia niekoniecznie wykazał obsługę każdego innego czasu obowiązywania lub konfiguracji konta.
Dokumentuj zatwierdzony zakres, znane ograniczenia i warunki wymagające nowego przeglądu. Rozszerzenie powinno wynikać z nowych dowodów: dodatkowego pokrycia scenariuszy, bieżącej weryfikacji schematu i jasnych zasad konta. Zachowuj możliwość pozostania w trybie obserwacji lub nadzoru, gdy przypadek odzyskiwania nadal jest nierozstrzygnięty.
Najbardziej użyteczny wynik akceptacji to precyzyjne stwierdzenie wykazanego zachowania. Pokazuje zachowywanie jednostek, poszanowanie uprawnień, jednokrotne przetwarzanie wykonań i odtwarzanie stanu konta po określonych awariach. Te dowody informują lepiej niż szeroka etykieta niezawodności i dają operatorowi konkretną podstawę decyzji o następnej pracy dozwolonej programowi.