Diktálás, ami túléli a terminált

Azok a fejlesztők, akik kipróbálnak diktálóeszközöket, gyakran nagyon jellegzetes formájú hibába futnak. Az eszköz gyönyörűen működik a demóban. Működik a Jegyzetekben, a Slackben, a böngészőben. Aztán fókuszba hozol egy terminált, bediktálsz egy mondatot, és vagy nem jelenik meg semmi, vagy megjelenik valami, ami nem az, amit mondtál, vagy a fele megjelenik, a másik fele pedig rejtélyes módon a vágólapodon van. Néha helyben működik, és abban a pillanatban hal meg, amikor SSH-val belépsz egy gépre.

A minta elég következetes ahhoz, hogy ne higgyem: egyetlen termék hibája. Annak a következménye, ahogyan a kategória beszúrja a szöveget — és pontosan azokon a helyeken bukik el, ahol egy fejlesztő él.

Ez ma többet számít, mint két éve. Ha hanggal vezeted a Claude Code-ot — az a munkafolyamat, amelyet a Claude Code vezetése hanggal írásban leírtam —, akkor a terminál nem egy app a sok közül. Az az app. Ott landolnak a promptjaid, ott várnak az agentjeid az irányváltásra, ott működik vagy nem működik az egész párhuzamos lane-es dolog. Egy terminálban szeszélyes diktálóeszköz egy vibecodernak épp az egyetlen feladatában szeszélyes.

Miért pont ott törik el a beillesztés, ahol a fejlesztők élnek?

Íme a kategóriaszintű mechanizmus. A legtöbb diktálóeszköz ugyanúgy szúrja be a szöveget: az átírt mondatot a rendszer vágólapjára teszi, majd a fókuszban lévő appnál szintetizál egy Cmd+V leütést. Ésszerű alapértelmezés — a beillesztés azonnali, szinte minden grafikus szövegmezőben működik, és alig igényelt appspecifikus fejlesztést.

A gond mindaz, amitől ez a feltételezés csendben függ.

Függ attól, hogy a fókuszban lévő app a Cmd+V-t „beillesztésként” kezeli-e. A terminálok gyakran nem: sok közülük másra vagy semmire használja a Cmd+V-t, a tmuxnak és a vimnek megvan a saját elképzelése arról, mit jelent a beillesztés, egy távoli SSH-munkamenet pedig olyan módon értelmezhet egy beillesztett szövegcsomót, amelyet a helyi gép nem tud megjósolni. Bracketed paste, copy-mode, insert-mode kontra normal-mode: a terminálvilág tele van olyan állapotokkal, ahol egy szintetikus beillesztés rossz helyre vagy sehová sem érkezik.

Függ attól, hogy a vágólap elérhető és nem védett. A vágólapkezelők átírják. A jelszókezelők szándékosan törlik vagy védik — ez biztonsági funkció, amely a „illeszd be a diktálásomat” kérést csendben „ne illessz be semmit”-té alakítja. És még ha minden működik is, az eszköz épp felülírta azt, amit korábban kimásoltál. Az ablakok között hordozott commit-SHA eltűnt, a helyén a saját mondatod. Aki több lane-t zsonglőrködik, annak ez nem apró karcolás; a vágólapnak dolga volt.

És függ — ez az, ami meglepi az embereket — a billentyűzetkiosztásodtól. Amikor egy eszköz billentyűleütések szimulálására vált vissza, a naiv megoldás az, hogy billentyű_kódokat_ küld: a fizikai billentyűpozíciókat. A billentyűkódok a kiosztáson keresztül képződnek le karakterekre. QWERTY-n a „V” kódja V-t ad. Dvorakon ugyanaz a fizikai pozíció más betű. Így egy olyan eszköz, amely Dvorak-, AZERTY- vagy Colemak-kiosztáson szimulál scancode-okat, olyan szöveget állít elő, mintha behelyettesítéses rejtjelezésen ment volna át. A felhasználók halandzsáról számolnak be, és azt hiszik, a beszédfelismerés bukott el. Nem az — a beszéd tökéletes volt, a beszúrás kavarta össze.

Ebben senki részéről nincs rosszindulat vagy lustaság. A vágólapos beillesztés a helyes alapértelmezés a 90%-os esetre. Csak épp a fejlesztők a maradék 10%-ban töltik a napjukat.

Mit jelent valójában, hogy „inkább gépeld be”

A Keebye-nak van egy insert_mode nevű beállítása két értékkel: paste, ami az alapértelmezés, és type.

A gépelős mód nem illeszt be. macOS-en a CGEventKeyboardSetUnicodeString API-t használja, amely a tényleges Unicode-szöveget csatolja egy szintetikus billentyűeseményhez. A karaktert maga az esemény hordozza, nem a billentyűzetkiosztásod keresi ki. Ettől szerkezetileg kiosztásfüggetlen: Dvorak, AZERTY, Colemak, bármin gépelsz is, az érkező szöveg az, amit átírtunk, mert sosem volt scancode-ból karakterré fordítás, ami elromolhatna.

A gépelős mód második tulajdonsága az, ami a terminálhasználókat érdekli: sosem nyúl a vágólaphoz. Nulla vágólapművelet ezen a kódútvonalon. A vágólapod tartalma a tiéd marad — a SHA túléli, a jelszókezelőnek nincs mitől védekeznie, a vágólapkezelőnek nincs mit naplóznia.

És mivel a terminálok és a távoli munkamenetek megakadhatnak azon a szövegen, amely gyorsabban érkezik, mint ahogy bármelyik ember gépel, a gépelős mód szándékosan ütemezi magát: a szöveg 16 karakteres darabokban megy be, a darabok között 4 milliszekundum szünettel. Elég gyorsan ahhoz, hogy egy mondat jóval egy másodpercen belül landoljon; elég megfontoltan ahhoz, hogy egy SSH-n keresztüli tmux-panel olyan billentyűleütésként kapja, amellyel lépést tud tartani, ne pedig értelmezendő masszaként.

A beillesztős mód továbbra is ott van, és továbbra is az alapértelmezés, mert normál grafikus appokban nagy szövegtömbökhöz valóban gyorsabb — egy három bekezdéses Slack-üzenet egyetlen beillesztésként érkezik, nem darabok folyamaként. A kiosztásból viszont a beillesztős mód is levonta a tanulságot: a szintetikus Cmd+V a fizikai V billentyűkódot használja, így maga a beillesztés nem törik el nem QWERTY-kiosztásokon úgy, ahogy a karakterkikeresésre épülő megközelítések.

Az agentes munka gyakorlati beállítása egyszerű: állítsd az insert_mode-ot type-ra, hozd fókuszba a Claude Code-ot futtató terminált, tartsd nyomva a billentyűt, mondd ki az irányváltást, engedd el. A prompt úgy érkezik meg, ahogy a billentyűleütések érkeznének, mert a terminál szempontjából pontosan azok. Ennek a beállításnak a lépésről lépésre változata, benne az SSH- és tmux-specifikumokkal, a hangdiktálás a macOS-terminálhoz oldalon található.

Az őszinte korlátok

A gépelős mód lassabb a beillesztésnél hosszú szövegnél — ez aritmetika, nem hiba. A szüneteltetve darabolt billentyűleütések tovább tartanak egyetlen beillesztési eseménynél, és ha több bekezdést diktálsz egy dokumentumba, a beillesztős mód fürgébbnek fog tűnni. Pontosan ezért marad a beillesztés az alapértelmezés, és a gépelős mód olyasmi, amit a beállításokban kapcsolsz be; a helyes mód attól függ, hová megy a szöveged.

Egyes alkalmazások korlátozzák vagy szűrik a szintetikus bevitelt, általában biztonsági okból, és ez alól egyetlen beszúrási stratégia sem menekül teljesen — az az app, amely visszautasítja a szintetikus eseményeket, minden diktálóeszköztől visszautasítja őket.

És hogy világos legyen, mit állít és mit nem állít ez az írás: a „a beillesztés eltörik a terminálokban” panasz a diktálási kategória egészére jellemző minta, nem egyetlen versenytárs egyedi hibája. Más eszközöknek megvan a maguk válasza és a maguk erőssége — őszinte összehasonlításokat írtunk a Keebye vs Superwhisper és a Keebye vs Wispr Flow oldalon, benne azzal is, hol illhet hozzád jobban bármelyikük.

A beszúrás a diktálás dicstelen fele

A beszédfelismerés kapja az összes figyelmet — modellnevek, pontossági állítások, nyelvszámok. Csakhogy egy diktálóeszköznek két feladata van: jól hallani téged, majd eljuttatni a szöveget oda, ahol a kurzorod van, anélkül hogy elveszítené vagy összekuszálná. A második feladat triviálisnak hangzik, és itt bukik el csendben a kategória a fejlesztőkkel szemben, mert a második feladat könnyű a TextEditben, és nehéz egy távoli gépen futó tmux-panelben, Dvorak-kiosztás alatt.

Ha a promptjaid terminálokban landolnak — és ha kódolóügynököket vezetsz, ott landolnak —, a beszúrás nem lábjegyzet. Ez a különbség egy demózható és egy használható eszköz között. Egyébként a rokon hibamódoknak ugyanez az íze van: az, hogy a mikrofon hidegindulása felfalja a diktálás első szavát, szintén kategóriaszintű panasz mechanikus magyarázattal, és azt is megírtuk a miért falják fel a diktálóappok az első szavadat írásban.

A Keebye korai hozzáférésben érhető el macOS-re. Ha a diktálásod valaha eltűnt valahol a szád és egy terminál között, indítsd el lent az ingyenes próbaidőszakot, kapcsold be a gépelős módot, és próbáld újra ugyanazt a promptot. A kimásolt SHA-d a vágólapon marad, miközben a szavak begépelt Unicode-ként érkeznek.