Asystent React powinien traktować Chrome Summarizer jako lokalną pomoc w czytaniu, Gemini jako osobną usługę do proponowania zmian, a zapis uzależnić od przeglądu człowieka. To rozwiązanie dla programisty, który chce zachować oryginalny brief i kontrolować zmiany w szkicu.
W tym artykule
- Dwa modele, trzy oddzielne działania
- Wymagania urządzenia i przeglądarki
- Obsłuż dostępność, anulowanie i długie teksty
- Powiąż propozycję z aktualnym szkicem
- Zapisuj po kontroli, nie po samym wygenerowaniu
- Co obejmowały próby Trip Workbench
Dwa modele, trzy oddzielne działania
W opisanym przez Raju Dandigama przykładzie Trip Workbench użytkownik najpierw może streścić oryginalny brief lokalnie, następnie osobno poprosić Gemini o propozycję zmian, a na końcu przejrzeć i zastosować wybrany zestaw poprawek. Każde działanie ma inny cel: podsumowanie pomaga czytać, propozycja wskazuje możliwe zmiany, a ich zastosowanie zapisuje zaakceptowaną poprawkę zwykłą ścieżką aktualizacji backendu.
Chrome podaje, że podczas korzystania z jego wbudowanego modelu żadne dane nie są wysyłane do Google ani stron trzecich. Po pobraniu modelu lokalne podsumowywanie nie wymaga połączenia z internetem. To dotyczy wyłącznie użycia wbudowanego modelu. W osobnym działaniu Trip Workbench wysyła oryginalny brief do backendu aplikacji, który kieruje żądanie do Gemini. Lokalne streszczenie nie uruchamia tej prośby.
W takim układzie zachowaj oryginalny brief jako punkt odniesienia. Nie zastępuj go streszczeniem: propozycja Gemini ma być zmianą do sprawdzenia, a nie nową wersją źródła.
Wymagania urządzenia i przeglądarki
Strona Chrome Summarizer wskazuje Chrome 138 stable jako wersję dostępności API. Została zaktualizowana 30 lipca 2025 r. Podaje też wymagania dotyczące systemu i sprzętu:
| Sprawdzenie | Warunek podany przez Chrome | Co sprawdzić w aplikacji |
| System i urządzenie | Windows 10 lub 11, macOS 13 lub nowszy, Linux albo ChromeOS na Chromebooku Plus z Platform 16389.0.0 lub nowszą | Nie wymagaj Summarizera na Androidzie, iOS ani na urządzeniach z ChromeOS innych niż Chromebook Plus. |
| Wolne miejsce | Co najmniej 22 GB na woluminie zawierającym profil Chrome | Sprawdź miejsce potrzebne do pobrania modelu na urządzeniu użytkownika. |
| Procesor lub karta graficzna | GPU z ponad 4 GB VRAM albo procesor z co najmniej 16 GB RAM i 4 rdzeniami | Uwzględnij oba warianty sprzętowe przy określaniu wymagań funkcji. |
To warunki podane na stronie dokumentacji, a nie wynik sprawdzenia konkretnego urządzenia. Chrome informuje również, że początkowe pobranie modelu wymaga połączenia bez limitu transferu; później model może działać offline.
Obsłuż dostępność, anulowanie i długie teksty
Najpierw sprawdź dostępność API za pomocą Summarizer.availability(), przekazując te same opcje, których użyjesz przy tworzeniu sesji. Chrome podaje cztery możliwe stany: available, downloadable, downloading i unavailable. Jeśli uruchomienie wymaga pobrania modelu, tworzenie sesji powinno rozpocząć się po działaniu użytkownika. Szczegóły opisuje dokumentacja Chrome Summarizer API.
Przekaż sygnał anulowania także do tworzenia sesji. Dokumentacja MDN opisuje opcję signal w Summarizer.create(). Przerwanie przed rozstrzygnięciem obietnicy anuluje tworzenie. Przerwanie po utworzeniu sesji zwalnia jej zasoby, a wywołania Summarizera odrzuca błędem AbortError. Dzięki temu aplikacja może obsłużyć anulowanie również wtedy, gdy model jest jeszcze przygotowywany. Zasady opisuje referencja MDN dla Summarizer.create().
Mierz konkretny tekst zamiast zakładać stały limit tokenów. Wartość inputQuota zależy od implementacji, a measureInputUsage() pozwala sprawdzić zużycie dla danego tekstu. Gdy brief przekracza dostępny limit, Chrome opisuje dzielenie go na fragmenty według akapitów lub tematów, streszczanie każdego fragmentu, a następnie streszczanie połączonych podsumowań. Kolejne rundy mogą obniżyć dokładność i wydłużyć działanie, więc oryginał powinien pozostać dostępny. Szczegóły dotyczące limitu zawiera dokumentacja MDN właściwości inputQuota, a podejścia do długich tekstów opisuje przewodnik Chrome.
Powiąż propozycję z aktualnym szkicem
Propozycja może stać się nieaktualna, jeśli użytkownik zmieni szkic w trakcie oczekiwania na odpowiedź. W Trip Workbench koordynator śledzi tożsamość szkicu i sesji, zapisaną rewizję, wersję lokalnych edycji oraz wersję briefu. Sprawdza aktualność po zakończeniu żądania i ponownie przy zastosowaniu poprawek. Warto zachować oba sprawdzenia: wynik może być świeży w chwili nadejścia, a nieaktualny, gdy użytkownik kliknie „zastosuj”.
Opisany adapter prosi Gemini o odpowiedź JSON przez responseMimeType: "application/json", ale nie przekazuje schematu wyjściowego. Aplikacja parsuje więc odpowiedź i sprawdza ją przed użyciem. Sama forma JSON nie gwarantuje, że proponowane wartości pasują do pól szkicu ani do reguł aplikacji.
Zapisuj po kontroli, nie po samym wygenerowaniu
Po odpowiedzi pokaż propozycję jako zestaw zmian do przejrzenia. Dopiero świadome zastosowanie poprawek powinno uruchomić zwykłą ścieżkę mutacji backendu. W przykładzie Trip Workbench zapisanie szkicu jest oddzielone od jego późniejszego wysłania; zastosowanie poprawek samo w sobie nie rezerwuje podróży.
To rozdzielenie ogranicza ryzyko, że opóźniona odpowiedź nadpisze nowszą edycję albo że sugestia modelu zostanie zapisana bez kontroli. Jeśli koordynator stwierdzi, że szkic się zmienił, aplikacja może wstrzymać zastosowanie nieaktualnej propozycji i poprosić o ponowne jej przygotowanie.
Co obejmowały próby Trip Workbench
Raju Dandigam opisał osiem kontrolowanych sprawdzeń cyklu życia z atrapą Summarizera. Dotyczyły między innymi błędów dostępności, anulowania i odrzucania spóźnionych wyników. Zgłosił też trzy problemy w badanym adapterze: odrzucona obietnica dostępności wymykała się obsłudze błędów, anulowane wcześniej żądanie nadal tworzyło sesję, a wywołanie tworzące sesję nie otrzymywało sygnału anulowania.
Dandigam zaznaczył, że rozszerzenie React nie zostało zamontowane ani sprawdzone pod kątem typów, a próby z atrapą nie weryfikowały zachowania natywnego modelu, jakości podsumowań, wydajności ani danych przesyłanych przez sieć.