Eksploatacja Cursora na produkcji

Poziom 3 Przegląd Zaktualizowano 2026-10-12

Eksploatacja Cursora na produkcji obejmuje pięć zadań, które zaczynają się po wdrożeniu kodu: kontrolę wydatków na tokeny, strojenie edytora na dużym repozytorium, przyspieszanie aplikacji, budowę obserwowalności i audyt bezpieczeństwa. Zmiana jest skończona dopiero wtedy, gdy stoją za nią pomiary, a nie wtedy, gdy agent zgłasza koniec pracy.

Ta strona jest dla programistów i liderów technicznych, których zespół już dostarcza kod z Cursorem. Raport zużycia rośnie szybciej niż w planie, Agent potrzebuje 10 sekund, żeby ruszyć w monorepo, a klient zgłasza wolną stronę, której nie widać na żadnym dashboardzie. Znajdź swój objaw poniżej.

Który poradnik z sekcji Eksploatacja rozwiązuje twój problem?

Nie pomyl dwóch poradników o wydajności: jeden przyspiesza samego Cursora, drugi używa Cursora, żeby przyspieszyć twoją aplikację.

Objaw	Otwórz ten poradnik
Indeksowanie się nie kończy, podpowiedzi się opóźniają, edytor zwalnia w monorepo	Strojenie Cursora pod duże repozytoria
Limit zużycia kończy się za wcześnie, długie czaty tracą wątek, reguły ładują się przy każdym zapytaniu	Zarządzanie tokenami w Cursorze
Logi nie mają identyfikatora żądania, nic nie śledzi ruchu między usługami, alerty to szum	Konfiguracja logowania i monitoringu w Cursorze
Strony lub endpointy są wolne, baza danych jest przeciążona, bundle jest za duży	Optymalizacja wydajności aplikacji z Cursorem
Premiera lub przegląd zgodności wymaga oceny bezpieczeństwa	Audyt bezpieczeństwa w Cursorze

W jakiej kolejności przez nie przejść?

Najpierw dostrój edytor. Ta kolejność chroni przed naprawianiem czegoś, czego jeszcze nie umiesz zmierzyć. Wolny indeks i przeładowany kontekst spowalniają każdą kolejną sesję i podnoszą jej koszt.
Ustal punkt odniesienia dla tokenów. Zapisz zużycie z jednego zwykłego tygodnia, zanim zmienisz reguły lub modele, żeby później udowodnić oszczędność.
Zinstrumentuj aplikację. Najpierw logi, metryki i ślady, żeby stroić ścieżkę, której produkcja naprawdę używa.
Poprawiaj wydajność na liczbach. Profiluj, zmień jedną rzecz i zmierz ponownie, jak pokazuje poradnik o wydajności aplikacji.
Zrób audyt bezpieczeństwa, zanim zwiększysz użycie agentów. Więcej kodu pisanego przez agenty to większa powierzchnia ataku. Przeprowadź audyt bezpieczeństwa i zostaw jego kontrole w CI.

Zacznij od audytu repozytorium w trybie tylko do odczytu

Uruchom ten prompt w nowym czacie Agenta albo w Plan Mode, który planuje, zanim napisze kod. Prompt wskazuje najważniejszy poradnik dla tego repozytorium i podaje plik przy każdym twierdzeniu.

Do not edit any file. Audit this repository for production-operation gaps and report a table with the columns: Area, Finding, Evidence (file:line or "not found"), Risk (high/medium/low), Guide.

Check these areas:
1. Logging: is output structured (JSON)? Is a request or correlation ID attached to every log line?
2. Metrics and tracing: is there a metrics endpoint, and is OpenTelemetry or another tracer configured?
3. Alerting: are alert rules stored in the repo, and does any test or runbook show that they fire?
4. Performance: are there benchmarks or performance budgets in CI? List the three slowest-looking database access patterns (queries inside loops, missing pagination).
5. Security: is a dependency audit (npm audit, pip-audit, cargo audit) run in CI? Are there hardcoded secrets or .env files committed?
6. Cursor setup: does .cursorignore exclude build output, generated code and vendored dependencies? How many rules apply to every request?

Write "not found" rather than guessing. End with the three highest-risk findings in the order I should fix them.

Jak udowodnić, że zmiana eksploatacyjna działa, bez czytania każdej linijki?

Kod operacyjny pisany przez agenta psuje się po cichu: alert, który nigdy się nie uruchamia, wygląda tak samo poprawnie jak działający. Dlatego każde zadanie ma jeden dowód, który decyduje o scaleniu, i konkretną osobę, która go przyjmuje.

Zadanie	Dowód, który to potwierdza	Kto zatwierdza
Zarządzanie tokenami	Zużycie z porównywalnego tygodnia przed i po, bez wzrostu liczby cofniętych zmian agenta	Lider techniczny
Strojenie edytora	Czas do końca indeksowania i czas do pierwszej odpowiedzi Agenta, zmierzone dwa razy tak samo	Programista
Wydajność aplikacji	Benchmark lub p95 opóźnienia przed i po z tego samego środowiska oraz budżet w CI	Zespół odpowiedzialny za usługę
Monitoring	Wstrzyknięcie awarii na stagingu, które uruchamia alert i pokazuje jeden trace ID we wszystkich usługach	Osoba na dyżurze (on-call)
Bezpieczeństwo	Test lub reguła skanera dla każdej naprawionej podatności, teraz zielone w CI	Osoba odpowiedzialna za bezpieczeństwo

Dwie funkcje Cursora dodają drugiego, automatycznego recenzenta. Bugbot przegląda pull requesty pod kątem błędów, problemów z bezpieczeństwem i jakością kodu, a Security Agents skanują kod w poszukiwaniu błędów bezpieczeństwa, ryzykownych wzorców i podatności (obie funkcje opisane w dokumentacji Cursora, sprawdzone 2026-08-28). Security Agents to Security Reviewer, który sprawdza pull requesty, oraz Vulnerability Scanner, który działa według harmonogramu (dokumentacja Cursora, sprawdzone 2026-10-12). Konfigurację obu opisuje przegląd kodu w Cursorze, a ich miejsce w procesie pokazuje wymieniony wyżej audyt bezpieczeństwa. Traktuj ich uwagi jako dane wejściowe, a nie jako zatwierdzenie.

Before I merge the change on this branch, produce the evidence for it. Do not change application code.

1. Run the existing test suite and the linter, and paste the exact commands and their final output lines.
2. State the single metric this change is meant to move (p95 latency, bundle size, alert firing, token use per task, or a closed vulnerability) and show its value before and after, with the command that produced each number.
3. For a bug or security fix: write a test that fails on the main branch and passes on this branch. Show both runs.
4. Write the one-step rollback (revert commit, feature flag, or config value) and how I confirm the rollback worked.

If you cannot measure the metric, say so and stop. Do not estimate it.

Co się psuje przy eksploatacji Cursora?

Awaria	Jak z niej wyjść
Wygenerowane reguły alertów nigdy się nie uruchamiają albo dzwonią całą noc	Odrzucaj każdy alert bez testu wstrzyknięcia awarii. Usuwaj alerty, na które nikt nie zareagował przez 30 dni.
„Teraz jest szybciej”, ale bez liczb	Odeślij zmianę z promptem o dowodach powyżej. Bez pomiaru przed i po nie ma scalenia.
Audyt bezpieczeństwa zgłasza nieistniejące podatności albo pomija prawdziwe	Wymagaj dowodu w formie plik:linia i testu odtwarzającego każdą podatność. Trzymaj prawdziwy skaner w CI jako punkt odniesienia.
Cięcie tokenów pogarsza wyniki	Obserwuj przez dwa tygodnie cofnięte i poprawiane zmiany agenta. Jeśli ich przybywa, przywróć usuniętą regułę lub kontekst.
Agent dotyka konfiguracji produkcyjnej lub sekretów	Nie dawaj agentowi dostępu do produkcyjnych poświadczeń i blokuj ryzykowne polecenia powłoki hookami Cursora, które działają przed krokami agenta lub po nich. Zobacz uprawnienia i sandboxing.

Dokąd dalej po eksploatacji Cursora

Przed tą sekcją: dostarczanie z Cursorem opisuje CI/CD i przegląd kodu, do których podpinasz te kontrole.
Po niej: automatyzacja z Cursorem zamienia te kontrole w Cloud Agents i Automations, w tym wyzwalane z Sentry i PagerDuty.
Wersja tego etapu niezależna od narzędzia: eksploatacja z agentami AI, w tym reagowanie na incydenty.
Obserwowanie samych agentów (koszt, sesje, awarie): obserwowalność agentów.
Ten sam etap w innych narzędziach: eksploatacja Claude Code i eksploatacja Codeksa.