Cursor zamieni arkusz sprzedaży w działającą aplikację. Kto zajmie się linkiem?

W poniedziałek rano szef sprzedaży chce zobaczyć na jednej stronie, którymi klientami trzeba się zająć. Liczby są w arkuszu, reguły przydzielania klientów na drugiej karcie, a każdy ma trochę inną kopię pliku. Programista może zbudować użyteczny panel w jedno popołudnie. Pierwsze kłopotliwe pytanie pojawia się wtedy, gdy szef sprzedaży prosi o link.

Anysphere, twórca środowiska programistycznego Cursor, udostępnił Live Apps 5 listopada 2026 roku. Możesz poprosić działającego w chmurze agenta Cursor o aplikację internetową. Cursor może przygotować hosting, uwierzytelnianie i, jeśli aplikacja tego wymaga, bazę Postgres. Po kontroli bezpieczeństwa i świadomej decyzji o publikacji aplikacja otrzymuje działający adres URL. Funkcja jest dostępna w płatnych planach z włączonymi agentami w chmurze. Kod może pochodzić z nowego lub istniejącego repozytorium w Cursor Origin albo GitHubie. Ogłoszenie Cursor

To sprawia, że wewnętrzna aplikacja staje się praktyczną opcją w procesach obsługiwanych wcześniej za pomocą kopii arkusza i cotygodniowych wiadomości. Łatwiej też przejść od prototypu do narzędzia, na którym zacznie polegać ktoś z zespołu. Na przykładzie panelu sprzedaży i portalu dla nowych pracowników można zobaczyć, kiedy prototyp jest gotowy na ten krok i jak sprawdzić, kto ma dostęp do danych, kto może je zmienić i kto może wyłączyć aplikację.

Kliknięcie przycisku wdrożenia rozpoczyna pracę nad utrzymaniem aplikacji

Cursor wymaga, aby wprost poprosić o aplikację i użyć agenta działającego w chmurze. Lokalna sesja programistyczna nadal może pomóc w pracy z kodem, a proces Apps opisany przez Cursor odbywa się za pośrednictwem agenta w chmurze. Przy pracy od zera można utworzyć repozytorium w Cursor Origin. Jeśli aplikacja zespołu jest już w obsługiwanym repozytorium, można użyć istniejącego kodu. Cursor przygotowuje zasoby, a osoba publikująca wybiera adres URL i decyduje, kiedy go udostępnić. Konfiguracja i wdrażanie Apps

Droga od kodu źródłowego do działającego adresu URL. Odbiorców i źródło danych pokazano oddzielnie. Ilustracja Telli.sh.

Cursor opisuje dwa rodzaje kontroli przed publikacją. Reguły deterministyczne wykrywają znane przypadki, takie jak poufna wartość zapisana w pliku. Kontrola bezpieczeństwa wspomagana przez AI szuka poważnych problemów w kodzie źródłowym. Według Cursor administratorzy zespołu mogą dodawać własne reguły, przeglądać aplikacje i sekrety zespołu oraz wycofywać publikacje. Mogą też zezwolić na niektóre publikacje zablokowane przez kontrolę AI. Cursor utrzymuje blokady w przypadku złośliwego kodu, sekretów wpisanych na stałe do kodu lub ujawnionych danych uwierzytelniających. Właściciel aplikacji nadal decyduje, jakich danych uwierzytelniających aplikacja potrzebuje. Ogłoszenie Cursor · Bezpieczeństwo i administracja Apps

Wyobraź sobie aplikację, której strona główna pokazuje sumy sprzedaży, a punkt dostępu do szczegółów zwraca dane wszystkich klientów. Po zalogowaniu kierownika sprzedaży zakres widoczny na stronie może wyglądać prawidłowo. Ktoś z zespołu może jednak odgadnąć adres szczegółów lub wysłać do serwera zapytanie o region niewidoczny w tabeli. Kontrola wdrożenia może wykryć błędy implementacji. Reguły dostępu do regionów wynikają z zasad zespołu i trzeba je sprawdzić podczas testu wdrożenia z użyciem właściwych ról.

Po uruchomieniu adresu URL skutki tych decyzji stają się odczuwalne. Gdy współpracownicy zapiszą adres w zakładkach, awaria raportu może opóźnić poranną rozmowę. Jeśli aplikacja stanie się jedynym miejscem zapisu decyzji lub zatwierdzeń, jej baza danych stanie się częścią procesu biznesowego. Nawet mała aplikacja potrzebuje osoby, która potrafi wyjaśnić, co się stało, gdy liczby się nie zgadzają.

Zacznij od panelu z dostępem tylko do odczytu

Załóżmy, że zespół operacji sprzedażowych chce przeglądać szanse sprzedażowe z dwóch regionów. Pierwsza wersja panelu może wyświetlać liczbę szans na każdym etapie, datę ostatniego odświeżenia i link do szczegółów w CRM. Najpierw warto użyć fikcyjnych danych klientów. Gdy widok działa prawidłowo, aplikacja może otrzymać dostęp do raportu lub widoku bazy ograniczonego do pól potrzebnych w panelu. CRM nadal obsługuje przydziały i notatki. Dzięki temu pierwsza wersja nie zmienia zapisów biznesowych, a zespół ma niezależny punkt odniesienia do uzgadniania sum.

Dokumentacja Cursor Apps wskazuje, że sekrety służące do połączenia z hurtownią danych lub innym zewnętrznym zasobem można wprowadzić w ustawieniach aplikacji albo w panelu Apps. Według Cursor agent nie widzi tych wartości. Używa ich jednak opublikowana aplikacja podczas wykonywania zapytań. Umieść połączenie w kodzie po stronie serwera i ogranicz dozwolony zakres zapytań. Sprawdź gotową stronę i odpowiedzi sieciowe pod kątem pól, które powinny zostać na serwerze. Sekret z dostępem do odczytu pomaga pod warunkiem, że konto rzeczywiście ma wyłącznie dostęp do odczytu właściwego zbioru danych. Sekrety w Cursor Apps

Uruchom panel z perspektywy trzech osób. Docelowy użytkownik powinien zobaczyć prawidłową sumę i czas aktualizacji. Osoba przypisana do innego regionu powinna widzieć wyłącznie wiersze dopuszczone przez reguły aplikacji, nawet po zmianie linku lub zapytania. Osoba spoza grona odbiorców powinna otrzymać odmowę przed przesłaniem jakichkolwiek danych z panelu. Drugi przypadek jest szczególnie ważny, bo twórca testujący samodzielnie może łatwo go przeoczyć.

Do porównania wyników użyj ustalonego wyciągu z systemu referencyjnego. Zapisz zakres dat, strefę czasową, reguły uwzględniania rekordów i oczekiwaną sumę dla każdego regionu. Jeśli na wykresie pozornie brakuje poniedziałkowych szans sprzedażowych, przyczyną może być inna interpretacja okresu raportowania. W pierwszym zestawie testów uwzględnij pusty wynik, przekroczenie czasu odpowiedzi systemu źródłowego i nieaktualne dane. Wyświetlenie czasu ostatniej udanej aktualizacji i czytelnego błędu pozwala odróżnić awarię od faktycznego spadku liczby szans sprzedażowych.

W portalu dla nowych pracowników każde pole musi uzasadniać swój zapis

Portal zawierający tylko odsyłacze do istniejących zasad może się obyć bez nowej bazy. Interaktywna lista zadań wymaga zapisu stanu. Cursor może utworzyć bazę Postgres, gdy aplikacja jej potrzebuje, więc drugą wersję łatwo zbudować. Najpierw zapisz, które wartości naprawdę muszą zostać zachowane. Identyfikator zadania, czas jego ukończenia i stały identyfikator zalogowanego użytkownika mogą wystarczyć. Kopia notatek kierownika, numer dokumentu tożsamości lub adres domowy pracownika zwiększają ryzyko bez poprawy działania listy. Zasoby Cursor Apps

Oddziel dane pomagające pracownikom przejść przez proces od danych potrzebnych koordynatorowi do zarządzania nim. Pracownik może oznaczyć przypisaną mu lekturę jako ukończoną. Koordynator może potrzebować zestawienia zaległych kroków w całej grupie. Zastosuj odrębną regułę dostępu do widoku koordynatora i oddzielnie sprawdź jego zapytanie. Wspólny ekran logowania nadaje obu widokom spójny wygląd, choć ich wymagania dotyczące dostępu są różne.

Trzy odrębne kontrole dostępu w jednej aplikacji wewnętrznej. Ilustracja Telli.sh.

Przed zapisaniem prawdziwych informacji wdrożeniowych można przeprowadzić mały pilotaż z fikcyjnym pracownikiem i testowym koordynatorem. Ustal jednoznaczny warunek, którego niespełnienie zatrzyma wydanie. Pracownik nie może nadpisać stanu zadania innej osoby, nawet po zmianie identyfikatora w żądaniu przeglądarki. Sprawdź też, czy ponowne oznaczenie tego samego zadania daje ten sam wynik bez zdublowania wpisu. Pilotaż pozwala zweryfikować działanie bez angażowania współpracowników w ujawnianie prawdziwych danych.

Przy takiej aplikacji przydaje się lista czynności związanych z przekazaniem obowiązków. Zapisz, jak nowy koordynator dostaje dostęp, gdzie edytuje się poradnik, kto może odebrać dostęp osobie odchodzącej i co się dzieje z istniejącymi wpisami o ukończeniu zadań. Ustal, jak odtworzyć potrzebne dane, gdy zmiana się nie powiedzie. Cursor może utworzyć bazę, a zespół określa, jak w przypadku tej listy ma wyglądać odzyskiwanie i przechowywanie danych.

Zaproszenie i klucz integracji pełnią różne funkcje

Aktualna dokumentacja Cursor Apps opisuje trzy tryby udostępniania. Aplikacja dostępna po zaproszeniu jest otwarta dla właściciela i wskazanych zalogowanych osób lub grup. Udostępnienie zespołowe pozwala korzystać z niej całemu zalogowanemu zespołowi Cursor. Aplikację publiczną może otworzyć każdy, kto ma adres URL. W planach Teams i Enterprise udostępnianie publiczne jest domyślnie wyłączone, chyba że włączy je administrator. Ogłoszenie o wydaniu podkreśla dostępność udostępniania publicznego w planach indywidualnych. Sam fakt, że link działa, niewiele mówi o tym, kto naprawdę ma dostęp. Rzeczywisty zakres sprawdzisz w panelu Apps. Udostępnianie Cursor Apps

Ta sama dokumentacja opisuje klucze API do automatycznych żądań. Klucz przekazuje się w nagłówku HTTP, a żądanie jest identyfikowane jako automatyczne i nie jest przypisane do konkretnej osoby. To przydatne, gdy aplikację ma wywoływać skrypt. Zmienia też sposób badania nieoczekiwanego żądania. Jeśli aplikacja obsługuje sesje użytkowników i klucz API, sprawdź, czy automatyzacja ma dostęp tylko do potrzebnych operacji. Zapisz, gdzie klucz jest używany i kto będzie go wymieniać. Jeśli wszystkie ważne działania zaczynają się od otwarcia linku przez członka zespołu, w pierwszym pilotażu wystarczą sesje użytkowników. Klucze API Cursor Apps

Gdy aplikacja odczytuje dane z hurtowni, trzeba sprawdzić trzy warstwy dostępu. Cursor określa odbiorców linku. Aplikacja decyduje, z których operacji i wierszy mogą korzystać. System źródłowy decyduje, co może odczytać konto używane przez aplikację. Błąd w jednej warstwie mogą ograniczyć pozostałe. Jeżeli panel potrzebuje wyłącznie zbiorczych liczb, przyznanie mu dostępu do każdego rekordu CRM podnosi koszt nawet małego błędu w aplikacji.

Testy mogą być proste. Otwórz działający link w nowych sesjach przeglądarki jako osoba zaproszona, jako zalogowana osoba z zespołu bez uprawnień i bez logowania. W uprawnionej sesji poproś o jeden widoczny rekord oraz o jeden rekord z innego regionu. Jeśli skrypt używa klucza, sprawdź, czy żądanie bez nagłówka kończy się odmową i czy unieważniony klucz jest odrzucany. Każda z tych prób ujawnia inny rodzaj pomyłki.

Mały zakres pierwszej wersji ułatwia sprawdzenie

1. Wybierz jedno zadanie i konkretną grupę odbiorców. W przypadku panelu poproś o tygodniowe sumy szans według etapu na fikcyjnych danych, widoczny czas odświeżenia i odsyłacz do CRM. W przypadku portalu poproś o krótką listę zadań dla fikcyjnych kont pracowniczych.
2. Uruchom agenta w chmurze i poproś go wprost o zbudowanie aplikacji. Użyj repozytorium dostępnego dla przyszłego właściciela. Pierwsza zmiana powinna być na tyle mała, aby osoba odpowiedzialna potrafiła wyjaśnić działanie ścieżek, modelu danych i obsługi błędów.
3. Ustal, które dane można zachować i które żądania mogą je zmieniać. Dodaj w ustawieniach aplikacji sekret o wąskim zakresie uprawnień dopiero wtedy, gdy działa proces z fikcyjnymi danymi. Poproś agenta o wskazanie, gdzie jest używany sekret i gdzie sprawdzane są uprawnienia odbiorców.
4. Uruchom kontrolę publikacji i przeczytaj jej wyniki. Wybierz adres URL, opublikuj aplikację świadomie i udostępnij ją najmniejszej odpowiedniej grupie. Na wdrożonym adresie sprawdź prawidłowo obsłużone i odrzucone żądania, zanim ktokolwiek zacznie polegać na aplikacji.
5. Zapisz, kto odpowiada za aplikację, z którą usługą źródłową się łączy i kto może ją wyłączyć. Powtórz najważniejsze testy po zmianie widoczności, integracji lub danych uwierzytelniających. Zachowaj alternatywny link lub proces na wypadek tymczasowej niedostępności aplikacji.

Pierwsze wydanie może mieć mniejszy zakres niż kod, jaki agent potrafi wygenerować. Panel pokazujący każdego ranka jedną wiarygodną liczbę może być bardziej przydatny niż narzędzie z sześcioma widokami i kwestionowanymi wyliczeniami. Dobrze utrzymana lista zadań może ograniczyć liczbę powtarzających się wiadomości, nawet jeśli widok koordynatora powstanie później. Przy małym pierwszym wydaniu łatwiej też zauważyć, jakie zmiany, prośby o dostęp i pytania faktycznie trafiają do osoby odpowiedzialnej.

Warto ocenić wynik w zwykłym tygodniu pracy. Zobacz, jak często ktoś otwiera aplikację bez przypomnienia, czy może znaleźć źródło kwestionowanej liczby i jak długo właścicielowi zajmuje naprawa problemu. Działająca aplikacja, która oszczędza kilka minut dziennie, może być warta utrzymania. Jeśli zespół nadal potwierdza wyniki w arkuszu, ustal, którego wyniku aplikacji jeszcze nie uważa za wiarygodny.

Zmiany w Cursor ułatwiają rozpoczęcie takiej próby. W ogłoszeniu z 5 listopada tworzenie aplikacji, baza danych, uwierzytelnianie, hosting i link do udostępniania są częścią jednego procesu. Wcześniej podobny eksperyment mógł utknąć na etapie szukania opiekuna hostingu lub organizowania logowania. Gdy te elementy są dostępne, najwięcej uwagi wymaga precyzyjne określenie odbiorców, danych i warunków wydania. Na końcu liczy się link, z którego jedna osoba potrafi korzystać, a druga wie, jak go utrzymać. Ogłoszenie Cursor

Źródła

• Wydanie Cursor Live Apps, 5 listopada 2026
• Dokumentacja Cursor Apps dotycząca konfiguracji, udostępniania i administracji

---

Aby zachować rozmowy i decyzje związane z wewnętrznym narzędziem w archiwum z możliwością wyszukiwania, załóż konto Telli.sh.