Głos na tekst w GitHub: jak to naprawdę działa

GitHub nie ma pisania głosem. Robotę odwala Twój skrót klawiszowy.

Odpowiedzmy na pytanie, które ludzie naprawdę wpisują w Google. Nie, GitHub nie ma wbudowanej zamiany głosu na tekst. Nie ma natywnego dyktowania w edytorze zgłoszeń, w formularzu pull requesta, w panelu recenzji, w Discussions ani na wiki. To standardowe webowe pola tekstowe. Żeby do nich dyktować, głos musi pochodzić skądinąd: z Twojego systemu operacyjnego, z przeglądarki albo z zewnętrznej aplikacji.

GitHub nigdy nie blokuje dyktowania. Po prostu sam żadnego nie udostępnia. Masz więc z grubsza trzy opcje. Twój system operacyjny ma wbudowane dyktowanie — Pisanie głosowe w Windowsie pod Win+H albo Dyktowanie w macOS. Rozszerzenie przeglądarki takie jak Voice In potrafi pisać w karcie Chrome lub Edge. Albo globalna aplikacja desktopowa jak Whisper dyktuje do dowolnego pola w dowolnej aplikacji, przeglądarki czy nie.

Te trzy opcje różnią się zasięgiem. Dyktowanie w systemie jest darmowe, działa na jednej platformie naraz, a jakość bywa różna. Rozszerzenie przeglądarki żyje tylko w karcie — nie pójdzie za Tobą do IDE ani do GitHub CLI, a do tego działa w chmurze. Aplikacja desktopowa jak Whisper nie jest przywiązana do karty; ponieważ działa na poziomie systemu, dyktuje do GitHuba w Chrome, Firefoksie, Safari czy Edge, a także do treści commita w GitHub Desktop.

Co naprawdę możesz dyktować (i jedna rzecz, której nie możesz)

Oto granica, której nie pozwolę Ci przekroczyć przez przypadek. Whisper dyktuje to, co piszesz wokół kodu. Nie napisze samego kodu.

Obejmuje to, szczerze mówiąc, większość pisania w dniu programisty. Zgłoszenia błędów. Opisy pull requestów. Notatki z code review. Odpowiedzi w Discussions. Dokumentację README i markdown. Tekst, który wyjaśnia zmianę, a nie samą zmianę. Kiedy mówisz akapit tłumaczący, dlaczego dana migracja jest ryzykowna, Whisper poradzi sobie bez problemu. Kiedy spróbujesz podyktować tę migrację, czeka Cię kiepskie popołudnie.

Powód jest prosty. Mówiony kod nie przetrwa tej podróży. Nazwy funkcji, JSON, snake_case kontra camelCase, flaga kubectl, ścieżka API — wszystko to wychodzi jako angielszczyzna na najlepsze możliwe wyczucie i wymaga ręcznej poprawki. Model głosowy słyszy „user podkreślnik I D” i pisze „user ID” — i już to poprawiasz. Podyktuj więc zdanie „ten PR naprawia sprawdzanie nulla w middleware uwierzytelniania”, a potem wpisz właściwy identyfikator. Większość treści zgłoszeń i pull requestów to i tak w 80% wyjaśnienie, a w 20% fragment kodu. Podyktuj te 80, wpisz te 20.

Naciśnij skrót, mów, dostań tekst w aktywnym polu

Mechanika jest taka sama, jakiej użyłbyś w każdej innej aplikacji — i o to właśnie chodzi. Kliknij w pole GitHuba, które chcesz wypełnić. Przytrzymaj skrót. Mów. Puść. Transkrypcja pojawia się przy kursorze.

Domyślny skrót to Ctrl+Space na Windowsie i Command+Option na macOS. Oba działają jako „naciśnij i mów”: przytrzymujesz, mówiąc, puszczasz, by zakończyć. Możesz je zmienić w ustawieniach, jeśli kolidują z czymś innym — a jeśli kiedykolwiek walczyłeś z konfliktem skrótów, wiesz, dlaczego to ustawienie zasłużyło sobie na miejsce (więcej o tym poniżej).

Jeden szczery szczegół o zakresie. Whisper wkleja do jednego pola, które masz aktywne, po kolei. Nie wypełni całego formularza zgłoszenia GitHuba na jednym oddechu. Przepływ przy nowym zgłoszeniu wygląda więc tak: klikasz w tytuł, dyktujesz go, klikasz w treść, dyktujesz ją. Dwa pola, dwa naciśnięcia. To mniej magia, a bardziej szybki maszynista, który nigdy nie dotyka klawiatury. To właściwy model myślenia.

Cała aplikacja, na żywo

To jest faktyczna aplikacja, działająca tu i teraz — nie zrzut ekranu. Pogrzeb sobie. Ustawienia, dobór skrótu, wybór modeli to wszystko prawdziwa rzecz.

Kilka rzeczy warto wiedzieć, klikając. Nie ma osobnej zakładki dla GitHuba ani „trybu GitHub”, bo nie musi być. Dla Whispera opis pull requesta na GitHubie to pole tekstowe jak każde inne. Ta sama konfiguracja, która dyktuje do edytora zgłoszeń, dyktuje do Twojej poczty i do Twojego IDE. Konfigurujesz to raz. Zasięg to właśnie ta funkcja.

Gdzie się to opłaca: zgłoszenia, opisy PR-ów, recenzje, dyskusje

Zysk to ta nudna, powtarzalna pisanina — rzeczy, które odkładasz, bo ich wpisywanie to mordęga.

Zgłoszenia. Dobre zgłoszenie błędu to głównie narracja: co zrobiłeś, czego się spodziewałeś, co się stało zamiast tego. To naturalne środowisko dyktowania. Opowiedz kroki do odtworzenia tak, jakbyś tłumaczył je koledze przy biurku, a potem ręcznie wklej stack trace.

Opisy pull requestów. Opis PR-a, którego wszyscy unikają pisać, bo diff „mówi sam za siebie” (nie mówi). Podyktuj „dlaczego” — kontekst, którego potrzebuje recenzent — i niech diff opowie „co”.

Code review. W komentarzach z recenzji liczy się ton i to tu ludzie najczęściej za mało wyjaśniają. Wypowiedziana notatka z recenzji wychodzi zwykle bardziej po ludzku i pełniej niż taka wpisana między spotkaniami. Napiszesz „to działa, ale wywali się, gdy lista będzie pusta” zamiast samego „przypadek brzegowy?”.

Dyskusje i dokumentacja. Dłuższy tekst, czyli dokładnie to, w czym głos jest dobry, i dokładnie to, czego nikt nie chce wpisywać. Wstęp do README, odpowiedź w Discussions, przewodnik po migracji — podyktuj szkic, a markdown dopracuj później. Ta sama logika dotyczy dyktowania do zgłoszeń w Jira i innych systemów; GitHub to po prostu kolejne pole na stosie.

Wyczyść dyktowanie automatycznie

Surowe dyktowanie ma wypełniacze. „Yyy”, „no wiesz”, zdanie zaczęte dwa razy. Whisper ma opcjonalny przebieg czyszczenia przez AI, który poprawia wyrazy-wypełniacze, interpunkcję i wielkość liter, tak by zgłoszenie lub PR czytało się, jakbyś pisał je starannie.

Są dwa warianty. W darmowej warstwie lokalnej czyszczenie działa na Twoim komputerze przez Ollama. W wersji Pro podajesz własny klucz OpenAI, a czyszczenie działa w chmurze — dostępne są też odpowiedzi z sieci. Tak czy inaczej jest opcjonalne — wyłącz je, a dostaniesz surową transkrypcję. Zostawiam je włączone przy opisach PR-ów, a wyłączone przy szybkich komentarzach, bo szybki komentarz nie wymaga redakcji, a opis PR-a tak.

Jednej rzeczy czyszczenie nie zrobi — nie uratuje mówionego kodu. Dopracowuje angielszczyznę. Nie wie, że miałeś na myśli getUserById, kiedy powiedziałeś „get user by I D”. Dyktuj dalej tekst; identyfikatory wpisuj dalej ręcznie.

Offline i prywatnie: w trybie lokalnym nic nie opuszcza Twojego komputera

Jeśli dyktujesz zgłoszenia i PR-y dotyczące kodu, który nie jest publiczny, to dokąd trafia dźwięk, ma znaczenie. W trybie lokalnym Whispera transkrypcja odbywa się w całości na Twoim komputerze. Nic z tego, co mówisz, nie jest wysyłane do usługi w chmurze. Podczas transkrypcji w ogóle nie potrzebujesz internetu — łączysz się z siecią tylko raz, przy jednorazowym pobraniu modelu, które waży od około 140 MB do 3 GB, zależnie od wybranego modelu.

To jedyne miejsce, gdzie podzielę się prawdziwą opinią. Dyktowanie wyłącznie w chmurze to katastrofa prywatności czekająca, aż ktoś ją przepisze. Widziałem kiedyś, jak pewien zespół wewnętrzny zafundował sobie pięciocyfrowy rachunek za chmurę w jednym kwartale, bo domowej roboty prototyp dyktowania wysyłał każdą wypowiedź do API — a najgorsze nie był rachunek, tylko to, że wszystkie mówione notatki o niewydanym jeszcze produkcie wylądowały w logach dostawcy. Arkusz z pensjami Twojego szefa, luka bezpieczeństwa, którą zgłaszasz prywatnie, autorska architektura, którą opisujesz w PR-ze — nic z tego nie powinno opuszczać Twojego laptopa tylko dlatego, że chciałeś wpisać akapit głosem. Twój komputer i tak ma mikrofon i procesor. Do jednego akapitu nie potrzebuje serwera w obiegu. Jeśli Twoje narzędzie działa wyłącznie w chmurze, to ja zacząłbym naprawiać właśnie od tego.

Do czego się nie nadaje (do pisania kodu)

Może trafiłeś tu, szukając sposobu na pisanie kodu głosem, albo pamiętasz „Hey, GitHub!” i zastanawiasz się, gdzie się podziało. Dwie szczere odpowiedzi.

„Hey, GitHub!” i GitHub Copilot Voice były technicznym podglądem od GitHub Next. GitHub zakończył ten podgląd w 2024 roku. Nigdy nie stał się produktem; wnioski przelały się do rozszerzenia VS Code Speech. Jeśli więc jakiś wpis na blogu każe Ci dziś włączyć „Hey GitHub”, jest nieaktualny o jakieś dwa lata.

Tor „głos do kodu” nadal istnieje — po prostu żyje w Twoim edytorze i terminalu, a nie na github.com. Rozszerzenie VS Code Speech (czasem nazywane „Hey Code”) pozwala mówić do edytora i do Copilot Chat w sprawie kodu i poleceń. A GitHub Copilot CLI niedawno dodał lokalne wprowadzanie głosem, które steruje agentem Copilota w terminalu. Oba służą do sterowania kodem i agentem AI. Żadne z nich nie dyktuje tekstu do zgłoszenia na GitHubie w przeglądarce. To inny tor — i to ten, który należy do Whispera: pisanie wokół kodu.

Kiedy odpuścić Whispera w swoim przepływie pracy na GitHubie

Wolę, żebyś użył właściwego narzędzia niż tego, które robię. Oto więc, kiedy odpuścić Whispera.

Jeśli tak naprawdę chcesz sterować Copilotem albo edytorem głosem — „napraw tę funkcję”, „uruchom testy”, „wyjaśnij ten blok” — to tor kodu/agenta, a nie tekstu. Użyj zamiast tego rozszerzenia VS Code Speech albo wprowadzania głosem w GitHub Copilot CLI. Rozmawiają z maszyną; Whisper pisze słowa, które czyta człowiek.

Jeśli dyktujesz tylko sporadyczny jednolinijkowy komentarz, Twój system robi to już za darmo. Naciśnij Win+H na Windowsie albo włącz Dyktowanie na macOS i możesz wrzucić szybkie zdanie do pola na GitHubie, bez instalowania czegokolwiek. Whisper zaczyna zarabiać na siebie, kiedy piszesz prawdziwe akapity w wielu aplikacjach, chcesz, by działał offline, albo chcesz jednego skrótu wszędzie zamiast funkcji systemu, która obejmuje tylko niektóre pola. Poniżej tej poprzeczki wbudowana opcja jest w porządku — i nie będę udawał, że jest inaczej.

Lokalnie za darmo, z Pro do chmury

Lokalny pipeline — transkrypcja, czyszczenie AI na urządzeniu, skrót klawiszowy, wszystko, czego potrzebujesz, by dyktować do GitHuba — jest darmowy dla zalogowanych użytkowników i przy rejestracji nie trzeba podawać karty. Instalujesz, logujesz się i zaczynasz dyktować.

Whisper Pro dokłada warstwę chmurową: transkrypcję w chmurze OpenAI, czyszczenie AI w chmurze z Twoim własnym kluczem i odpowiedzi z sieci — z krótkim okresem próbnym dla tej warstwy. Do dyktowania zgłoszeń i PR-ów darmowa warstwa lokalna obejmuje całą robotę. Liczby dla Pro znajdziesz na stronie cennika; nie będę Ci ich rzucał w środku akapitu.

Jeszcze jedno o tym skrócie klawiszowym

Słowo o tym, dlaczego skrót da się dostosować, bo to spina całość. Pierwsza wersja Whispera na niektórych maszynach z Windowsem wyzwalała zatrzymanie nagrywania sześć razy na jedno naciśnięcie klawisza — fantomowe zdarzenia puszczenia klawisza z frameworka wejścia, taka rzecz, która działa na świeżej instalacji, a wywala się na prawdziwej. Trzeba było odbicia (debounce) 300 ms i więcej czasu, niż się przyznam, żeby to działało niezawodnie. Dowiedziałem się o obsłudze wejścia w Windowsie więcej, niż kiedykolwiek chciałem. Lekcja została: to skrót ma się uginać pod Twoją maszynę, a nie odwrotnie. Klikasz w pole, przytrzymujesz klawisz, mówisz. Kod nadal wpisujesz sam — i myślę, że to jest uczciwa wersja tej umowy.