Tal till text i GitHub: så fungerar det egentligen

GitHub har ingen röstinmatning. Din snabbtangent gör jobbet.

Låt mig svara på frågan folk faktiskt skriver in på Google. Nej, GitHub har ingen inbyggd tal till text. Det finns ingen inbyggd diktering i issue-editorn, PR-formuläret, granskningspanelen, Discussions eller wikin. Det är vanliga webbtextrutor. För att diktera i dem måste rösten komma någon annanstans ifrån: ditt operativsystem, din webbläsare eller en tredjepartsapp.

GitHub blockerar aldrig diktering. De erbjuder bara ingen egen. Så du har i stort sett tre val. Ditt operativsystem har inbyggd diktering — Windows Röstinmatning på Win+H, eller macOS Diktering. Ett webbläsartillägg som Voice In kan skriva i en flik i Chrome eller Edge. Eller en systemövergripande skrivbordsapp som Whisper som dikterar i vilket fält som helst i vilken app som helst, webbläsare eller inte.

Skillnaden mellan de tre är räckvidd. Operativsystemets diktering är gratis och fungerar på en plattform i taget, kvaliteten varierar. Ett webbläsartillägg lever bara inuti fliken — det kan inte följa med dig in i din IDE eller GitHub CLI, och det körs i molnet. En skrivbordsapp som Whisper är inte bunden till en flik; eftersom den fungerar på operativsystemsnivå dikterar den i GitHub i Chrome, Firefox, Safari eller Edge, och i ett commit-meddelande i GitHub Desktop också.

Vad du faktiskt kan diktera (och det enda du inte kan)

Här är gränsen jag inte tänker låta dig kliva över av misstag. Whisper dikterar texten kring din kod. Den skriver inte koden själv.

Det täcker ärligt talat större delen av en utvecklares skrivardag. Felrapporter. Beskrivningar av pull requests. Kodgranskningsnotiser. Svar i Discussions. README och markdown-dokument. Texten som förklarar ändringen, inte själva ändringen. När du talar in ett stycke som beskriver varför en migrering är riskabel klarar Whisper det galant. När du försöker diktera själva migreringen får du en jobbig eftermiddag.

Orsaken är enkel. Talad kod överlever inte resan. Funktionsnamn, JSON, snake_case kontra camelCase, en kubectl-flagga, en API-sökväg — det kommer ut som bästa möjliga engelska och kräver manuell rättning. En röstmodell hör "user understreck I D" och skriver "user ID", och nu sitter du och rättar. Så diktera meningen som säger "den här PR:en fixar null-kontrollen i auth-middlewaren", och skriv sedan in den faktiska identifieraren. De flesta issue- och PR-texter består ändå till 80 % av förklaring och 20 % kodavsnitt. Diktera de 80, skriv de 20.

Tryck på en snabbtangent, prata, få text i det fokuserade fältet

Mekaniken är densamma som du skulle använda i vilken annan app som helst, vilket är hela poängen. Klicka i GitHub-fältet du vill fylla i. Håll in snabbtangenten. Prata. Släpp. Transkriptionen dyker upp vid markören.

Standardsnabbtangenten är Ctrl+Space på Windows och Command+Option på macOS. Båda är push-to-talk: håll in medan du pratar, släpp för att stoppa. Du kan ändra dem i inställningarna om de krockar med något — och har du någonsin slagits mot en snabbtangentskonflikt vet du varför den inställningen gjort sig förtjänt av sin plats (mer om det nedan).

En ärlig detalj om omfattningen. Whisper klistrar in i det enda fält du har i fokus, ett i taget. Den fyller inte i ett helt GitHub-issue-formulär på ett andetag. Så flödet för en ny issue är: klicka på titeln, diktera den, klicka på texten, diktera den. Två fält, två tryck. Det känns mindre som magi och mer som en snabb skribent som aldrig rör tangentbordet. Det är rätt mental modell.

Hela appen, live

Det här är den faktiska appen, körd här och nu — inte en skärmbild. Peta runt. Inställningarna, snabbtangentsväljaren, modellvalen är på riktigt.

Ett par saker värda att veta medan du klickar. Det finns ingen GitHub-specifik flik och inget "GitHub-läge", för det behövs inte. För Whisper är en GitHub PR-beskrivning ett textfält som vilket annat som helst. Samma uppsättning som dikterar i issue-editorn dikterar i din e-post och i din IDE. Du ställer in det en gång. Räckvidden är själva funktionen.

Där det lönar sig: issues, PR-beskrivningar, granskningar, discussions

Det lönar sig framför allt för det tråkiga, repetitiva skrivandet — det du skjuter upp för att det är ett tjat att skriva.

Issues. En bra felrapport är mestadels berättande: vad du gjorde, vad du förväntade dig, vad som hände i stället. Det är dikteringens hemmaplan. Prata dig igenom stegen för att återskapa felet på samma sätt som du skulle förklara dem för en kollega vid skrivbordet, och klistra sedan in stack-tracen för hand.

Beskrivningar av pull requests. PR-texten som alla hoppar över att skriva för att diffen "talar för sig själv" (det gör den inte). Diktera varför — kontexten granskaren behöver — och låt diffen tala om vad.

Kodgranskningar. Granskningskommentarer är där tonen spelar roll och där folk förklarar för lite. Att tala in en granskningsnotis blir oftast mer mänskligt och mer fullständigt än att skriva en mellan möten. Du skriver "det här fungerar, men det kraschar när listan är tom" i stället för bara "specialfall?".

Discussions och dokumentation. Längre text, vilket är precis vad röst är bra på och precis vad ingen vill skriva. En README-introduktion, ett Discussions-svar, en migreringsguide — diktera utkastet och putsa markdown efteråt. Samma logik gäller för att diktera i Jira-ärenden och andra system; GitHub är bara ytterligare ett fält på högen.

Putsa dikteringen automatiskt

Rå diktering har utfyllnad. "Eh", "liksom", meningen du började på två gånger. Whisper har en valfri AI-genomgång som rättar utfyllnadsord, interpunktion och versaler så att din issue eller PR läser som om du skrivit den med omsorg.

Det finns två varianter. I den gratis lokala nivån körs putsningen på din egen maskin via Ollama. I Pro tar du med din egen OpenAI-nyckel och putsningen körs i molnet, med webbsvar tillgängliga också. Hur som helst är den valfri — stäng av den och du får den råa transkriptionen. Jag har den på för PR-beskrivningar och av för snabba kommentarer, för en snabb kommentar behöver ingen redigering medan en PR-beskrivning gör det.

En sak putsningen inte gör är att rädda talad kod. Den putsar engelskan. Den vet inte att du menade getUserById när du sa "get user by I D". Fortsätt diktera texten; fortsätt skriva identifierarna.

Offline och privat: inget lämnar din maskin i lokalt läge

Om du dikterar issues och PR:er om kod som inte är offentlig spelar det roll vart ljudet tar vägen. I Whispers lokala läge sker transkriptionen helt på din egen maskin. Inget du säger skickas till en molntjänst. Du behöver ingen internetuppkoppling alls under transkriptionen — det enda tillfället du går online är den engångsnedladdning av modellen, som varierar mellan ungefär 140 MB och 3 GB beroende på vilken modell du väljer.

Det här är det enda stället där jag tänker ge dig en riktig åsikt. Diktering enbart i molnet är en integritetskatastrof som väntar på att bli transkriberad. Jag såg en gång ett internt team dra på sig en femsiffrig molnnota på ett enda kvartal för att en hemmasnickrad dikteringsprototyp skickade varje yttrande till ett API — och det värsta var inte notan, det var att allas talade anteckningar om en osläppt produkt nu låg i en leverantörs loggar. Din chefs lönekalkyl, säkerhetsbristen du anmäler privat, den proprietära arkitekturen du beskriver i en PR — inget av det borde lämna din laptop bara för att du ville skriva ett stycke med rösten. Din maskin har redan en mikrofon och en CPU. För ett stycke behöver den ingen server i loopen. Om ditt verktyg bara körs i molnet är det den biten jag skulle fixa först.

Vad det inte är till för (att skriva kod)

Du kanske kom hit för att hitta ett sätt att skriva kod med rösten, eller så minns du "Hey, GitHub!" och undrar vart det tog vägen. Två ärliga svar.

"Hey, GitHub!" och GitHub Copilot Voice var en teknisk förhandsvisning från GitHub Next. GitHub lade ner förhandsvisningen 2024. Det blev aldrig en produkt; lärdomarna rullade in i tillägget VS Code Speech. Så om ett blogginlägg säger åt dig att aktivera "Hey GitHub" idag är det ett par år föråldrat.

Spåret för röst-till-kod finns fortfarande — det lever bara i din editor och terminal, inte på github.com. Tillägget VS Code Speech (ibland kallat "Hey Code") låter dig prata med editorn och med Copilot Chat för kod och kommandon. Och GitHub Copilot CLI fick nyligen lokal röstinmatning som styr Copilot-agenten i terminalen. Båda är till för att styra kod och en AI-agent. Ingen av dem dikterar text i en GitHub-issue i din webbläsare. Det är ett annat spår, och det är det Whisper äger: skrivandet kring koden.

När du ska hoppa över Whisper för ditt GitHub-flöde

Jag vill hellre att du använder rätt verktyg än det jag bygger. Så här är när du ska hoppa över Whisper.

Om det du faktiskt vill är att styra Copilot eller din editor med rösten — "fixa den här funktionen", "kör testerna", "förklara det här blocket" — så är det kod-/agentspåret, inte text. Använd tillägget VS Code Speech eller röstinmatningen i GitHub Copilot CLI i stället. De pratar med maskinen; Whisper skriver orden en människa läser.

Om du bara nån enstaka gång dikterar en enradskommentar gör ditt operativsystem redan det gratis. Tryck på Win+H på Windows eller slå på Diktering på macOS, så kan du släppa in en snabb mening i ett GitHub-fält utan att installera något. Whisper börjar förtjäna sin plats när du skriver riktiga stycken i många appar, vill att det ska fungera offline, eller vill ha en snabbtangent överallt i stället för en operativsystemsfunktion som bara täcker vissa fält. Under den ribban duger det inbyggda alternativet, och jag tänker inte låtsas annat.

Gratis lokalt, med Pro för molnet

Den lokala pipelinen — transkriptionen, AI-putsningen på enheten, snabbtangenten, allt du behöver för att diktera i GitHub — är gratis för inloggade användare, och inget kort krävs vid registreringen. Du installerar, loggar in och börjar diktera.

Whisper Pro lägger till molnytan: OpenAI molntranskription, AI-putsning i molnet med din egen nyckel, och webbsvar, med en kort provperiod för den nivån. För att diktera issues och PR:er täcker den gratis lokala nivån hela jobbet. Siffrorna för Pro finns på prissidan; jag tänker inte rabbla dem för dig mitt i ett stycke.

En sista sak om den där snabbtangenten

Ett ord om varför snabbtangenten går att anpassa, eftersom det knyter ihop hela alltet. Den första versionen av Whisper avfyrade sin inspelningsstopp sex gånger per tangenttryck på vissa Windows-maskiner — spökreleaser från input-ramverket, den sortens sak som fungerar på en ren installation och går sönder på en riktig. Det krävdes en 300 ms debounce och mer tid än jag vill erkänna för att få det pålitligt. Jag lärde mig mer om Windows input-hantering än jag någonsin velat. Lärdomen satt: snabbtangenten måste böja sig efter din maskin, inte tvärtom. Klicka i fältet, håll in tangenten, prata. Koden skriver du fortfarande själv — och jag tycker det är den ärliga versionen av uppgörelsen.