Wybierz model AI napędzający sesje debugowania
StatusRivet potrzebuje modelu do przetwarzania, a Ty decydujesz, gdzie się znajduje: u dostawcy AI w chmurze przez standardowy endpoint API, na Twoim PC lub jako wbudowany. Ta strona wyjaśnia trzy opcje i sposób testowania połączenia.
Trzy miejsca uruchomienia modelu
Dostawca AI w chmurze
Dostawca AI w chmurze sprawdza się przy dużych bazach kodu i długich logach. Wpisujesz standardowy endpoint API i swój klucz. Klucz pozostaje lokalny. Każda prośba trafia do wybranego dostawcy, włącznie z tekstem pliku lub logu odczytywanego przez agenta w tym kroku, więc przeczytaj politykę prywatności dostawcy przed wysłaniem kodu źródłowego, który nie jest publiczny. Ogranicz pracę do oprogramowania, które napisałeś lub masz prawo debugować. Dostawca może naliczać opłaty za użycie zgodnie z własnymi warunkami, a StatusRivet jest niezależny od każdego dostawcy. Wybierz go, gdy Twoje logi i pliki źródłowe wymagają dużego okna kontekstowego.
Model na Twoim PC
Model działający na Twoim PC sprawdza się przy kodzie, którego nie możesz wysłać nigdzie indziej. Twój PC wykonuje pracę. Wskaż StatusRivet na lokalny endpoint, a prośby trafią do Twojej maszyny, więc nic nie opuszcza Twojego komputera. Kompromisem jest sprzęt: prędkość i okno kontekstowe zależą od tego, co Twój PC jest w stanie uruchomić, a długi log może się nie zmieścić. Użyj przycisku Test, aby sprawdzić okno kontekstowe przed długą sesją. Aktualizacja lub zmiana modelu to Twój obowiązek. Sprawdza się na maszynach laboratoryjnych i nieopublikowanych sterownikach, o ile akceptujesz te ograniczenia.
Model wbudowany
Wbudowany model jest gotowy do użycia bez Twojego własnego endpointa, więc jest najkrótszą drogą od instalacji do pierwszej rozmowy. Nie jest potrzebny żaden endpoint. Użyj go, aby wypróbować tryby zatwierdzania, odczytać krótki log i zobaczyć, jak wygląda karta diff przed konfiguracją czegokolwiek innego. Gdy zadanie wymaga więcej, podłącz dostawcę AI w chmurze lub model na PC i uruchom tę samą rozmowę ponownie, aby porównać odpowiedzi. Przeglądaj każdy diff w ten sam sposób, niezależnie od tego, który model go wygenerował.
Przetestuj połączenie przed długą sesją
Naciśnij przycisk Test obok endpointa, aby sprawdzić połączenie. Wynik pokazuje czas odpowiedzi i okno kontekstowe tego modelu. Czas odpowiedzi mówi Ci, czy endpoint odpowiada w tempie, z którym możesz pracować. Okno kontekstowe mówi, ile logu lub pliku źródłowego mieści się w jednym żądaniu, co ma znaczenie, gdy długim wywołaniem stosu jest część prośby. Uruchom test ponownie po zmianie endpointa lub modelu. Nieudany test wskazuje na problem z połączeniem, a nie z Twoim kodem. Napraw to najpierw.
Wybierz rozmiar modelu do zadania
Używaj większego modelu do trudnego wnioskowania, np. śledzenia błędu przez kilka modułów lub przeglądania większej zmiany, a mniejszego do drobnych edycji, takich jak dodanie sprawdzenia null. Narzędzie run_on_model pozwala agentowi wysłać jeden trudny krok do większego modelu, podczas gdy reszta sesji pozostaje na mniejszym. To utrzymuje rutynowe kroki na mniejszym modelu, podczas gdy trudny krok otrzymuje więcej zasobów. Wybieraj według zadania, a nie z przyzwyczajenia, i użyj przycisku Test, aby porównać okna kontekstowe przed wrzuceniem długiego logu awarii. Najpierw dopasuj log.
Jakość modeli różni się między dostawcami i wersjami, więc traktuj każdą odpowiedź jako szkic. Szkice wymagają przeglądu. Przeczytaj diff, zbuduj ponownie za pomocą polecenia build i uruchom polecenie test przed zaakceptowaniem zmiany. Ask first zatrzymuje przed akcjami zmieniającymi coś, co daje Ci miejsce na zatrzymanie się i przeczytanie. Plan only zapisuje plan i nic nie uruchamia, co pomaga, gdy chcesz zobaczyć kroki przed przełączeniem na Auto-run lub Ask first. Agent pracuje na podstawie wyjścia tekstowego, więc wynik jest tylko tak dobry, jak logi, które mu podasz.
