Computer Use w pracy: zrób i pokaż wynik

Otwórz stronę i pokaż przejście między widokami. Zmień godzinę wydarzenia w kalendarzu. Ustaw, w czym mają otwierać się pliki Markdown. Takie zadania rzeczywiście zlecałem AI w swoich rozmowach.

Łączy je prosta potrzeba: chcę, żeby agent wykonał pracę w programie, którego używam, a potem pokazał mi rezultat. Computer Use daje mu możliwość działania przez interfejs — otwierania widoków, wybierania przycisków, wpisywania danych i sprawdzania, co się zmieniło.

Najciekawsze w moim użyciu tej funkcji jest połączenie działania z rozmową. Agent coś pokazuje, ja widzę problem, doprecyzowuję oczekiwanie i możemy przejść do poprawki. Dobrze widać to zarówno przy budowaniu strony, jak i przy zwykłym porządkowaniu komputera.

Co nazywam tu Computer Use

Chodzi o obsługę aplikacji przez jej interfejs. Agent odczytuje dostępny stan, wykonuje działanie i ponownie sprawdza ekran lub informacje zwrócone przez narzędzie. W moich zapisach występują zarówno operacje w przeglądarce, jak i w aplikacjach Maca.

Technicznie nie musi to być wyłącznie klikanie we współrzędne obrazu. Część operacji w przeglądarce odbywała się przez Playwright — narzędzie pozwalające między innymi odnajdywać przyciski i pola oraz obsługiwać stronę. Obok tego agent korzystał ze zrzutów ekranu i opisów elementów interfejsu. Takie różne sposoby sterowania mieszczą się w szerszym podejściu opisanym w dokumentacji Computer Use OpenAI.

To rozróżnienie przydaje się przy opisywaniu wyników. W zadaniu dotyczącym strony agent może zmieniać kod w plikach, a przez Computer Use oglądać i sprawdzać działającą wersję. Nie przypisuję całego procesu jednemu narzędziu.

Strona: pokaż mi, jak to działa

Przy pracy nad Adrian Lab prosiłem o otwieranie lokalnej wersji obok rozmowy, pokazywanie podstron i sprawdzanie przejść. Zależało mi na tym, żebym mógł zobaczyć działanie i odnieść się do konkretnego miejsca.

W rozmowie z 1 października opisałem też swój sposób prowadzenia Live Demo. Proszę agenta o pokazanie przejścia, rozmawiam głosowo i zatrzymuję go, kiedy mam uwagę. Mogę poprosić o zapisanie jej na później albo o drobną poprawkę od razu. Po pokazie zostaje lista uwag do uporządkowanego opracowania. Większe zmiany chcę zobaczyć ponownie.

To opis mojego sposobu pracy. W tej samej rozmowie są również konkretne działania narzędzia: otwieranie rozdziałów strony, przechodzenie linkiem do opisu demo, powrót do poprzedniej ścieżki i kontrola widoku przy różnej szerokości okna.

Pojawił się wtedy bardzo zwyczajny problem: jasny pas nad stopką. Zgłosiłem też, że zmieniła się treść kafelka dotyczącego podcastu i newslettera. Agent odtworzył widok, sprawdził układ i poprosił o doprecyzowanie, który pas mam na myśli. Wskazałem ten nad stopką.

Dalej praca połączyła kilka rzeczy: poprawkę kodu, ponowne obejrzenie strony i sprawdzenie zachowania kafelka. W odczycie po kliknięciu pojawił się właściwy widok z wyborem podcastu lub newslettera. Kontrola węższego okna wykazała również ucięty napis, więc poprawka objęła także ten konkretny przypadek. Na końcu obejrzałem wynik i zaakceptowałem go.

Właśnie do tego używam takiego pokazu: żeby rozmawiać o czymś, co da się zobaczyć. „Tu jest pusty pas” albo „ten kafelek otwiera niewłaściwą treść” daje znacznie konkretniejszy punkt wyjścia do pracy niż ogólne „popraw stronę”.

Nie wynika z tego, że pojedyncze demo potwierdza poprawność całego produktu. Pokazuje, czy sprawdzony fragment zachowuje się zgodnie z oczekiwaniem. Pozostałe testy nadal mają własną rolę.

Prompt do wykorzystania — propozycja na podstawie tego sposobu pracy:

Otwórz lokalną wersję projektu i pokaż mi działanie [konkretna ścieżka].
Przejdź przez nią po kolei, tak jak zrobiłby to użytkownik.
Po ważnym kroku pokaż wynik i daj mi możliwość zgłoszenia uwagi.

Gdy powiem „stop”, zatrzymaj pokaz.
Zapisz uwagę wraz z miejscem i oczekiwanym zachowaniem.
Drobne poprawki możesz wykonać w uzgodnionym zakresie.

Po pokazie uporządkuj uwagi, wprowadź poprawki i sprawdź je.
Pokaż ponownie zmienione fragmenty.
Ten etap dotyczy lokalnego demo; publikację uzgodnimy osobno.

Edytor geometrii: przejdź przez proces na rzucie

Mam też bardziej widowiskowy przykład. Podczas rozmowy głosowej 10 września poprosiłem agenta, żeby pobrał przykładowy rzut kondygnacji i pokazał mi na interfejsie przejście przez proces jego opracowania.

W zapisie tej próby widać rzeczywiste działania: otwarcie wyboru pliku, wgranie rzutu, klikanie kolejnych punktów obrysu i wykonywanie podziałów wnętrza. Edytor pokazał utworzone pomieszczenie oraz informację o zmianach oczekujących na zapis. Później zwrócił potwierdzenie zapisania zmian pomieszczenia w szkicu.

To mocniejszy dowód niż sama odpowiedź agenta, że potrafi rysować. Powstał efekt w interfejsie. Trzeba jednak zachować dokładność opisu: potwierdzenie zapisu szkicu nie sprawdza skali, wymiarów ani zgodności z rzutem. Nie jest też dowodem ukończenia całego procesu lub finalnego importu.

Ten przypadek traktuję jako przykład sprawdzania narzędzia przez jego użycie. Przy kolejnej takiej próbie warto osobno ocenić dwie rzeczy: czy agent potrafi obsłużyć edytor i czy narysowana geometria jest poprawna. Dopiero drugi etap pozwoliłby wyciągać wnioski o jakości opracowania technicznego.

Kalendarz: zmień ten jeden termin

Computer Use zlecałem też pracę dużo mniej widowiskową. We wrześniu przekazałem rozpisane terminy meczów do dodania do prywatnego kalendarza. Kilka dni później zmieniła się godzina pierwszego spotkania. Poprosiłem o poprawienie tego wpisu, z pozostawieniem pozostałych terminów bez zmian.

Agent otworzył Google Calendar, wyszukał istniejące wydarzenia i przeszedł do właściwego wpisu. Wynik wyszukiwania pokazywał sześć wydarzeń. To istotne: przy aktualizacji trzeba najpierw rozpoznać to, co już istnieje, żeby nie dodać kolejnego egzemplarza tego samego terminu.

Przy zapisie wystąpił błąd. Narzędzie zgłosiło, że wskazany element interfejsu jest już nieaktualny lub nie istnieje. Pierwsza próba kliknięcia przycisku nie wystarczyła.

Po ponownym odczycie interfejsu agent powtórzył zapis. Kalendarz wyświetlił komunikat o przeniesieniu wydarzenia na nową godzinę. Taki komunikat jest dowodem z aplikacji; sam zamiar kliknięcia nim nie jest. Przy ważnym terminie warto dodatkowo otworzyć zapisany wpis i sprawdzić jego szczegóły.

Ten przypadek pokazuje również ograniczenie pracy przez interfejs. Stan strony może zmienić się między odczytem a działaniem. Agent musi umieć rozpoznać nieudaną próbę i ustalić, co jest teraz widoczne. Bez tego łatwo pomylić wykonane polecenie z osiągniętym wynikiem.

Praktyczny prompt do podobnej korekty:

W moim kalendarzu [wskaż właściwy kalendarz] znajdź wydarzenie
[nazwa i data] i zmień godzinę z [stara] na [nowa].
Zachowaj dotychczasowy czas trwania i pozostałe dane.
Nie twórz nowego wydarzenia.

Jeśli pasuje więcej niż jeden wpis, pokaż różnicę przed edycją.
Po zapisie otwórz wydarzenie ponownie i sprawdź datę, godzinę,
strefę czasową oraz kalendarz. Podaj, co faktycznie się zmieniło.

To nowy szablon do wykorzystania, a nie dosłowny zapis mojego historycznego polecenia. Dodaje wyraźny warunek kontroli po zapisie.

Mac: ustawienie jest dopiero początkiem

Inny przykład dotyczył plików .md, czyli plików tekstowych w formacie Markdown. Zapytałem, czy można ustawić wygodny program do ich domyślnego otwierania.

Agent przeszedł przez Finder i opcję „Otwórz w aplikacji”. Najpierw ustawił TextEdit i sprawdził otwarcie przykładowego pliku. Po zobaczeniu efektu stwierdziłem, że wolę Obsidian albo możliwość otwierania w Codexie. Ostatecznie zaakceptowałem Obsidian.

Nastąpiła kolejna zmiana ustawienia i kolejna próba. Samo uruchomienie Obsidiana nie oznaczało jeszcze, że mam przed sobą właściwy dokument. Trzeba było również otworzyć odpowiedni folder jako vault, czyli zbiór plików obsługiwany przez Obsidian. Końcowy odczyt okna wskazywał konkretny plik README otwarty w tej aplikacji.

To mały przykład, ale dobrze oddaje sens pracy z agentem. Mogę zobaczyć pierwsze rozwiązanie, zmienić zdanie i sprawdzić drugie. Kryterium zakończenia jest praktyczne: potrafię otworzyć i przeczytać plik tak, jak chciałem.

Ten test potwierdził działanie dla sprawdzonego pliku i folderu. Nie jest obietnicą, że każdy dokument Markdown, w każdej lokalizacji, zawsze otworzy się identycznie.

Co łączy te zadania

W tych historiach powtarza się ten sam porządek: określam potrzebę, agent działa w interfejsie, a potem sprawdzamy rezultat. Czasem po drodze doprecyzowuję, o co mi chodzi. Czasem trzeba naprawić nieudaną próbę.

Dlatego proponuję opisywać zadanie trzema zdaniami: co ma się zmienić, gdzie wolno działać i po czym poznamy, że zadziałało. To pomaga zarówno agentowi, jak i mnie podczas odbioru.

Nie zmierzyłem na podstawie tych rozmów, ile czasu zaoszczędził mi Computer Use. Nie wyciągam też statystyki skuteczności z kilku wybranych przypadków. Widzę natomiast konkretne użycie: agent wykonał działania w aplikacjach, a ja mogłem odnieść się do ich efektu.

Dostęp do programu wymaga jasnego zakresu

W praktyce trzeba wskazać właściwe konto, dokument lub środowisko. W kalendarzu znaczenie miało to, że chodzi o mój prywatny kalendarz. Przy stronie — o pokaz lokalnej wersji i osobną decyzję o publikacji. Przy plikach — o wybór domyślnej aplikacji dla danego typu dokumentu.

Warto też odróżnić to, co agent widzi, od tego, na co ma zgodę. Tekst na stronie czy w dokumencie nie powinien sam rozszerzać zlecenia. Oficjalna dokumentacja Computer Use zaleca ograniczenie dostępu do potrzebnego zakresu, kontrolę działań o istotnych skutkach oraz sprawdzanie rzeczywistego wyniku. Sam prompt nie zastępuje uprawnień i zabezpieczeń narzędzia.

Dla mnie praktyczna granica jest taka: oglądanie lokalnego widoku, zmiana konkretnego wpisu i publikowanie treści to różne działania. Agent powinien wiedzieć, które z nich zostało zlecone. Jeżeli napotka blokadę dostępu albo nie może potwierdzić wyniku, potrzebuję jasnej informacji o tym miejscu.

Najwięcej sensu widzę w Computer Use wtedy, gdy mogę połączyć polecenie z obejrzeniem efektu: zrób ten krok, pokaż wynik, a ja powiem, czy o to chodziło. Tak pracowałem nad stroną, tak poprawiałem kalendarz i tak dopasowywałem sposób otwierania plików na Macu.