Nie pisz idealnego promptu: pokaż Loomowi, co trzeba zmienić

Problem widać od razu. W prototypie przycisk znajduje się pod formularzem, w aplikacji obok niego, a na telefonie komunikat błędu wypycha oba elementy poza ekran. Wyjaśnienie tego agentowi programistycznemu AI wystarczająco precyzyjnie może zająć więcej czasu niż pokazanie problemu drugiej osobie.

22 października 2026 r. Atlassian przedstawił zestaw nowości w Loom, w tym Record for agent: tryb nagrywania, który przekształca komentowaną prezentację ekranu w instrukcje dla agenta AI. Loom, narzędzie do asynchronicznego wideo służące do pokazywania współpracownikom przebiegu pracy, przenosi ten zwyczaj na oprogramowanie wykonujące kolejne zadanie. Dokumentacja pomocy określa funkcję jako otwartą betę dla planów Business + AI i Enterprise, z limitem pięciu minut nagrania. Ogłoszenie; aktualne wymagania.

Interesujące nie jest samo to, że agent może otrzymać film. Znany sposób nagrywania tworzy teraz opis zadania, który można sprawdzić, poprawić i przekazać agentowi. Jakość przekazania pracy staje się dzięki temu praktycznym zagadnieniem, zamiast konkursem na najdłuższy prompt.

Oficjalne logo Loom identyfikujące omawiany produkt. To znak marki, a nie zrzut ekranu Record for agent. Logo: Loom / Atlassian; zasady korzystania ze znaków towarowych.

Nagranie może przekazać to, czego brakuje w opisie

Przydatne zgłoszenie błędu wymaga czegoś więcej niż zdania „formularz nie działa”. Potrzebuje stanu początkowego, działania wywołującego problem, oczekiwanego wyniku i faktycznie zaobserwowanego rezultatu. Gdy te szczegóły są rozrzucone po zrzutach ekranu, skopiowanych adresach i wiadomościach na czacie, ktoś musi najpierw odtworzyć ich związek.

Udokumentowany proces Loom łączy instrukcje głosowe z klatkami kluczowymi ekranu, zdarzeniami interakcji i odwiedzonymi odnośnikami. Rozszerzenie Chrome może też zbierać komunikaty konsoli oraz metadane żądań i odpowiedzi sieciowych. Wersja komputerowa udostępnia narzędzia zaznaczania i rysowania wskazujące istotny fragment ekranu. Są to dane wejściowe do tworzonego opisu, nie dowód skuteczności proponowanej poprawki. Szczegóły przechwytywania.

Naszym zdaniem zmienia to najbardziej użyteczną jednostkę komunikacji. Zrzut pokazuje stan, zdanie opisuje intencję, a krótka prezentacja może wyjaśnić, jak jeden stan ma przejść w drugi. Wygenerowany opis stanowi pomost między takim wyjaśnieniem a zadaniem do wykonania.

Warto potraktować nagranie jak paczkę kontekstu. Powinna zawierać wszystko, co niezbędne do żądanej zmiany, i niewiele ponad to. Limit pięciu minut może sprzyjać tej dyscyplinie: pokaż jeden problem, wyjaśnij jego konsekwencję i wskaż wyraźny punkt zakończenia.

Autorskie wyjaśnienie przekazania zadania. Sprawdzenie opisu to osobny etap poprzedzający wykonanie pracy przez agenta.

Uwagi do projektu są łatwiejsze, gdy widać oczekiwane zachowanie

Wyobraźmy sobie zespół poprawiający ekran składania zamówienia. W przykładowym nagraniu projektant mógłby otworzyć zatwierdzony układ, pokazać obecną aplikację i wskazać trzy różnice: opcja dostawy znika w wąskim widoku, suma aktualizuje się zbyt późno, a potwierdzenie akcentuje niewłaściwą informację. Wartość wynika z relacji między ekranami, nie tylko z ich wyglądu.

Osoba sprawdzająca wygenerowany prompt powinna zamienić każdą obserwację w konkretne zachowanie. „Przesuń to” staje się niejednoznaczne, kiedy agent nie patrzy już na tę samą chwilę. „Utrzymaj widoczność sumy po zmianie opcji dostawy w wąskim widoku” wskazuje wynik możliwy do zweryfikowania.

Jest to szczególnie przydatne przy zmianie obejmującej plik projektu i działającą stronę. Przykład w pomocy Loom opisuje przechodzenie między Figmą a witryną podczas wyjaśniania zmiany interfejsu. Funkcja pomaga utrwalić widoczny punkt odniesienia, lecz ustalenie, który wzorzec jest wiążący, nadal należy do zespołu. Dopracowany prototyp może pomijać stany ładowania, błędów i uprawnień. Obsługiwany proces.

Dodaj więc jedno zdanie określające, co musi pozostać prawdziwe. W przykładzie zamówienia może to być zgodność sumy z wybraną dostawą lub pozostawienie fokusu klawiatury na zmienianym polu. Takich warunków często brakuje w makietach, choć są ważniejsze od położenia obramowania.

Ten sam sposób sprawdza się przy tekstach produktu. Pokaż zdanie w rzeczywistym otoczeniu, wyjaśnij, kto je czyta i jaką decyzję ma mu ułatwić. Nagranie wdrożenia nowego użytkownika może ujawnić niezrozumiałe przejście, którego nie pokaże sam fragment tekstu.

Zgłoszenie błędu potrzebuje odtwarzalnego początku i obserwowalnego końca

Drugim użytecznym scenariuszem jest powracający problem obsługi klienta. Załóżmy, że klient potrafi przesłać dokument na komputerze, ale na małym ekranie widzi pusty wskaźnik postępu. Krótkie nagranie może pokazać typ pliku, wybraną czynność, przejście i moment utraty informacji zwrotnej.

Wygenerowane zadanie nadal potrzebuje definicji ukończenia. „Napraw przesyłanie” nie mówi agentowi, czy chodzi o odrzucony plik, brak odpowiedzi sieciowej, czy interfejs, który nie pokazał sukcesu. Lepszy opis oddziela zaobserwowany objaw od podejrzewanej przyczyny.

Początkowe zlecenie ograniczylibyśmy do odtworzenia braku informacji, znalezienia odpowiedzialnej warstwy i zaproponowania zmiany z kontrolą regresji. Jeśli agent odkryje później błąd serwera, ten fakt może uzasadnić rozszerzenie dochodzenia. Uwaga dotycząca układu nie powinna jednak po cichu zmieniać się w przebudowę całego systemu przesyłania.

To praktyczna korzyść dla osób, które nie czują się pewnie w logach. Mogą pokazać zepsutą sekwencję bez wcześniejszej diagnozy. Inżynier lub agent bada problem z użyciem kontekstu, a pierwotna obserwacja pozostaje dostępna do porównania po naprawie.

Nagranie nie zastępuje przez to przypadku testowego. Każde z nich ma inną rolę. Nagranie zachowuje to, na co ktoś trafił; test opisuje zachowanie, które oprogramowanie ma stale spełniać. Dobry proces przekształca pierwsze w odpowiednią postać drugiego.

Skopiowanie promptu i utworzenie zadania w Jira to różne wejścia

Otwarta beta Loom działa w rozszerzeniu Chrome lub aplikacji komputerowej w wersji 2.0 bądź nowszej. Dokumentacja odróżnia też podstawowy proces promptu od tworzenia elementów pracy w Jira, które wymaga konta zarządzanego przez Atlassian i aktywnej subskrypcji Jira. To istotne dla małego zespołu próbującego przekazania pracy bez reorganizacji zarządzania projektem. Dostępność i konfiguracja.

Najprostszy eksperyment to jedno mało ryzykowne zadanie w dobrze znanym projekcie:

1. Otwórz odpowiedni projekt, publiczną stronę testową lub środowisko programistyczne i przygotuj zrozumiały stan początkowy.
2. W obsługiwanym rejestratorze Loom wybierz Record for agent i opisz jedną zmianę, pokazując powiązane interakcje.
3. Zakończ przed limitem pięciu minut i przeczytaj cały wygenerowany plan działania.
4. Doprecyzuj niejasne odwołania, usuń zbędny materiał i dodaj konkretne kryterium akceptacji.
5. Skopiuj prompt jako Markdown do wybranego agenta albo użyj przekazania lub procesu Jira obsługiwanego przez twoje konto.
6. Sprawdź wynik agenta względem pierwotnego scenariusza przed zaakceptowaniem zmiany.

Ta kolejność pozwala zrozumieć pierwszy eksperyment. Daje też prostą ocenę przydatności: porównaj czas potrzebny na jasne zlecenie oraz liczbę pytań doprecyzowujących.

Samo szybkie zakończenie pracy przez agenta nie wystarcza. Jeśli współpracownik nie potrafi wyjaśnić, co się zmieniło i dlaczego odpowiada to pierwotnej obserwacji, przekazanie wymaga poprawy. Najważniejszy zysk to mniej odtwarzania kontekstu, a nie mniej kontroli.

Bogatszy kontekst wymaga bardziej świadomego udostępniania

Dodatkowy kontekst techniczny jest cenny, bo sam ekran nie zawsze wyjaśnia zdarzenie. Nieudane żądanie, niespodziewane przekierowanie lub błąd konsoli mogą wskazywać inną przyczynę niż widoczny objaw. Te same szczegóły mogą zawierać informacje, których nie chcesz wysyłać do kolejnego narzędzia.

Przed nagrywaniem wybierz odpowiednią stronę testową i utrzymuj widoczny zakres zadania. Potem sprawdź wygenerowany opis pod kątem adresów charakterystycznych dla konta, identyfikatorów klientów i zbędnych logów. Dokumentowana lista przechwytywanych danych uzasadnia konkretną kontrolę, zamiast traktowania nagrania jak zwykłego załącznika graficznego.

Chodzi o zachowanie informacji potrzebnych do rozwiązania problemu. Identyfikator żądania może pomóc współpracownikowi znaleźć uprawniony ślad na serwerze. Lista niezwiązanych adresów albo prywatne powiadomienie przypadkiem widoczne podczas nagrania niewiele wnosi do zadania dotyczącego interfejsu.

To redakcyjne pytania kontrolne, a nie dodatkowe uprawnienia produktu ani obietnica obecności każdego szczegółu w każdym zadaniu. Pomagają ustalić, co powinno znaleźć się w faktycznie wysyłanym zleceniu.

Przydatna kontrola ustala, co agent może zmienić, jakie informacje otrzymuje i jak będzie oceniany wynik.

Pierwszą użyteczną miarą jest ilość zachowanego wyjaśnienia

Funkcja może oszczędzić pracę przynajmniej na trzy sposoby. Projektant komunikuje różnicę wizualną bez rozbudowanego opisu. Specjalista wsparcia zachowuje świeżo zaobserwowaną sekwencję. Programista przekazuje zadanie z wyraźniejszym wzorcem i dokładniejszym oczekiwaniem.

Każde zastosowanie ma inny sposób porażki. Uwagi projektowe mogą pominąć zachowanie poza idealnym przebiegiem. Prezentacja wsparcia może zależeć od stanu konta nieodtwarzalnego dla innych. Nagranie programisty może zawierać tyle szczegółów, że właściwe żądanie stanie się niewidoczne.

Do wstępnej oceny wybierz kilka znanych zadań, pozostawiając tego samego agenta i repozytorium. Zapisuj zakres poprawek opisu, częstość pytań i zgodność końcowej zmiany z podanym warunkiem. To mówi więcej o jakości komunikacji niż pojedyncza demonstracja poruszającego się kursora.

Warto też oddzielić jakość wyniku od trudności zadania. Prosta zmiana tekstu może udać się z niemal dowolnym opisem. Więcej pokaże mała zmiana wymagająca kontekstu: stan ładowania, układ wąskiego ekranu lub przejście między narzędziami. Zadanie nadal powinno być odwracalne i łatwe do oceny przez właściciela.

Loom ma dobre warunki, by utrwalić ten zwyczaj, bo ludzie już wyjaśniają sobie pracę nagraniami. Szansa polega na przeniesieniu tej klarowności do procesu agentowego. Ryzykiem jest założenie, że bogatsze wejście usuwa potrzebę określenia celu agenta.

Lepszy opis nadal rozumie inna osoba

Record for agent opiera się na sensownym założeniu: pokazanie może być sprawniejszym początkiem niż opisywanie każdego piksela. Najlepszym wynikiem byłoby zadanie łatwiejsze do zrozumienia i dla agenta, i dla kolegi, z widocznym związkiem między pierwotną obserwacją a zaakceptowaną zmianą.

Przed kolejnym nagraniem zapytaj: czy ktoś, kto nie oglądał jego powstawania, nadal wyjaśni, jak wygląda sukces? Jeśli tak, opis jest użyteczny. Jeśli nie, następna poprawka należy najpierw do instrukcji, a dopiero później do kodu.

Źródła

• Atlassian: Showing what you mean in the age of AI, 22 października 2026 r.
• Loom: Record for AI agents, dokumentacja dostępności, przechwytywania i procesu, sprawdzona 26 października 2026 r.

Zachowaj źródło razem ze sprawdzonymi notatkami

Dla własnych nagrań, do których wykorzystania masz zgodę, Telli.sh oferuje osobne miejsce na materiał źródłowy i sprawdzone notatki. Zacznij od notatki dźwiękowej.