Diktēšana, kas izdzīvo terminālī

Izstrādātāji, kas izmēģina diktēšanas rīkus, bieži uzskrien kļūmei ar ļoti konkrētu formu. Demonstrācijā rīks strādā skaisti. Tas strādā lietotnē Notes, Slack, pārlūkā. Tad tu fokusē termināli, nodiktē teikumu, un vai nu neparādās nekas, vai parādās kaut kas, ko tu neteici, vai parādās puse, bet otra puse noslēpumaini nonākusi tavā starpliktuvē. Reizēm tas strādā lokāli un nomirst brīdī, kad caur SSH pieslēdzies serverim.

Šī aina atkārtojas pietiekami konsekventi, lai es nedomātu, ka tā ir kļūda kādā vienā produktā. Tās ir sekas tam, kā šī kategorija ievieto tekstu — un tas izgāžas tieši tajās vietās, kur izstrādātājs dzīvo.

Šodien tas ir svarīgāk nekā pirms diviem gadiem. Ja vadi Claude Code ar balsi — darbplūsma, ko aprakstīju rakstā Claude Code vadīšana ar balsi —, tad terminālis nav viena lietotne starp daudzām. Tā ir tā lietotne. Tur nonāk tavi prompti, tur aģenti gaida pārvirzīšanu, tur viss paralēlo joslu stāsts vai nu strādā, vai ne. Diktēšanas rīks, kas termināļos ir nestabils, vibecoder acīs ir nestabils savā vienīgajā darbā.

Kāpēc ielīmēšana salūzt tieši tur, kur izstrādātāji dzīvo?

Lūk, kategorijas līmeņa mehānika. Vairums diktēšanas rīku tekstu ievieto vienādi: tie noliek tavu transkribēto teikumu sistēmas starpliktuvē un tad fokusētajā lietotnē sintezē Cmd+V taustiņsitienu. Tas ir saprātīgs noklusējums — ielīmēšana ir acumirklīga, tā strādā gandrīz jebkurā grafiskā teksta laukā, un tai gandrīz nevajadzēja atsevišķu izstrādi katrai lietotnei.

Problēma ir viss tas, uz ko šis pieņēmums klusi paļaujas.

Tas paļaujas, ka fokusētā lietotne Cmd+V uztver kā „ielīmēt”. Termināļi bieži to nedara — daudzi Cmd+V izmanto kaut kam citam vai vispār nekam, tmux un vim ir savas domas par to, ko nozīmē ielīmēšana, un attālināta SSH sesija var interpretēt ielīmēta teksta uzplūdu veidos, ko lokālā mašīna nespēj paredzēt. Bracketed paste, kopēšanas režīms, ievietošanas režīms pret parasto režīmu: termināļu pasaule ir pilna ar stāvokļiem, kuros sintētiska ielīmēšana nonāk nepareizi vai nenonāk nekur.

Tas paļaujas, ka starpliktuve ir pieejama un neaizsargāta. Starpliktuves pārvaldnieki to pārraksta. Paroļu pārvaldnieki to apzināti notīra vai aizsargā — drošības funkcija, kas „ielīmē manu diktējumu” klusi pārvērš par „ielīmē neko”. Un pat tad, kad viss strādā, rīks tikko pārrakstīja to, ko biji nokopējis. Komita SHA, ko nesi starp logiem, ir pazudis, aizstāts ar tavu paša teikumu. Kādam, kas žonglē ar vairākām joslām, tas nav sīkums; starpliktuve pildīja savu darbu.

Un tas paļaujas — šis ir tas, kas cilvēkus pārsteidz — uz tavu tastatūras izkārtojumu. Kad rīks atkāpjas pie taustiņsitienu simulēšanas, naivais veids ir sūtīt taustiņu kodus: fizisko taustiņu pozīcijas. Taustiņu kodi tiek sasaistīti ar rakstzīmēm caur tavu izkārtojumu. QWERTY izkārtojumā kods „V” dod V. Dvorak izkārtojumā tā pati fiziskā pozīcija ir cits burts. Tāpēc rīks, kas simulē skenēšanas kodus Dvorak, AZERTY vai Colemak izkārtojumā, rada tekstu, kas izskatās izlaists caur aizvietošanas šifru. Lietotāji ziņo par nesakarībām un pieņem, ka izgāzās runas atpazīšana. Tā neizgāzās — runa bija nevainojama, ievietošana to sajauca.

Nekas no tā nav ļaunprātība vai slinkums. Ielīmēšana caur starpliktuvi ir pareizais noklusējums 90% gadījumu. Vienkārši izstrādātāji savu dienu pavada atlikušajos 10%.

Ko patiesībā nozīmē „uzraksti to tā vietā”

Keebye ir iestatījums insert_mode ar divām vērtībām: paste, kas ir noklusējums, un type.

Rakstīšanas režīms neielīmē. macOS vidē tas izmanto CGEventKeyboardSetUnicodeString — API, kas sintētiskam taustiņa notikumam pievieno īsto Unicode tekstu. Rakstzīme tiek nesta pašā notikumā, nevis meklēta caur tavu tastatūras izkārtojumu. Tas to pēc konstrukcijas padara neatkarīgu no izkārtojuma: Dvorak, AZERTY, Colemak — lai ar ko tu rakstītu, pienākušais teksts ir transkribētais teksts, jo nekad nebija skenēšanas koda pārvēršanas rakstzīmē, kas varētu aiziet greizi.

Otra rakstīšanas režīma īpašība ir tā, kas rūp termināļa lietotājiem: tas nekad neaiztiek starpliktuvi. Nulle starpliktuves darbību šajā koda ceļā. Tavas starpliktuves saturs paliek tavs — SHA izdzīvo, paroļu pārvaldniekam nav pret ko sargāties, starpliktuves pārvaldniekam nav ko reģistrēt.

Un, tā kā termināļi un attālinātas sesijas var aizrīties ar tekstu, kas pienāk ātrāk, nekā jebkurš cilvēks raksta, rakstīšanas režīms apzināti sevi ierobežo: teksts ieiet pa 16 rakstzīmju gabaliem ar 4 milisekunžu pauzi starp gabaliem. Pietiekami ātri, lai teikums nonāktu krietni ātrāk par sekundi; pietiekami mēreni, lai tmux panelis caur SSH to saņemtu kā taustiņsitienus, kuriem paspēj līdzi, nevis kā bloku, kas jāinterpretē.

Ielīmēšanas režīms joprojām ir un joprojām ir noklusējums, jo lieliem teksta blokiem parastās grafiskās lietotnēs tas patiešām ir ātrāks — trīs rindkopu Slack ziņa pienāk kā viena ielīmēšana, nevis gabalu plūsma. Tomēr arī ielīmēšanas režīms izkārtojuma mācību apguva: sintētiskais Cmd+V izmanto fizisko V taustiņa kodu, tāpēc pati ielīmēšana ne-QWERTY izkārtojumos nesalūzt tā, kā tas notiek ar rakstzīmju meklēšanas pieejām.

Praktiskais uzstādījums aģentu darbam ir vienkāršs: pārslēdz insert_mode uz type, fokusē termināli, kurā darbojas Claude Code, turi taustiņu, pasaki pārvirzīšanu, atlaid. Prompts pienāk tā, kā pienāktu taustiņsitieni, jo, cik terminālis spēj spriest, tie tādi arī ir. Soli pa solim izklāstīta šī uzstādījuma versija, ieskaitot SSH un tmux niansēs, ir sadaļā balss diktēšana macOS terminālim.

Godīgie ierobežojumi

Rakstīšanas režīms garam tekstam ir lēnāks par ielīmēšanu — tā ir aritmētika, nevis defekts. Gabalos sadalīti taustiņsitieni ar tempa pauzēm aizņem vairāk laika nekā viens ielīmēšanas notikums, un, ja diktē vairākas rindkopas dokumentā, ielīmēšanas režīms šķitīs žiglāks. Tieši tāpēc ielīmēšana paliek noklusējums, bet rakstīšanas režīms ir kaut kas, ko iestatījumos ieslēdz pats; pareizais režīms atkarīgs no tā, uz kurieni dodas tavs teksts.

Dažas lietotnes sintētisko ievadi ierobežo vai filtrē, parasti drošības apsvērumu dēļ, un neviena ievietošanas stratēģija no tā pilnībā neizvairās — lietotne, kas atsakās no sintētiskiem notikumiem, atsakās no tiem no jebkura diktēšanas rīka.

Un lai būtu skaidrs, ko šis raksts apgalvo un ko ne: sūdzība par to, ka ielīmēšana termināļos izgāžas, ir aina, kas vijas cauri visai diktēšanas kategorijai, nevis kāda konkurenta unikāls defekts. Citiem rīkiem ir savas atbildes un savas stiprās puses — mēs uzrakstījām godīgus salīdzinājumus Keebye vs Superwhisper un Keebye vs Wispr Flow, tostarp par to, kur katrs no tiem tev varētu derēt labāk.

Ievietošana ir diktēšanas neglamūrā puse

Visu uzmanību saņem runas atpazīšana — modeļu nosaukumi, precizitātes apgalvojumi, valodu skaits. Bet diktēšanas rīkam ir divi darbi: pareizi tevi sadzirdēt un tad nogādāt tekstu tur, kur ir tavs kursors, to nepazaudējot un nesakropļojot. Otrais darbs izklausās triviāls un ir tieši tas, kurā kategorija klusi pieviļ izstrādātājus, jo otrais darbs ir viegls lietotnē TextEdit un grūts tmux panelī attālinātā serverī ar Dvorak izkārtojumu.

Ja tavi prompti nonāk termināļos — un, ja vadi kodēšanas aģentus, tie tur nonāk —, ievietošana nav zemsvītras piezīme. Tā ir atšķirība starp rīku, ko demonstrē, un rīku, ko lieto. Starp citu, radniecīgām kļūmēm ir tāda pati garša: diktējuma pirmā vārda apēšana mikrofona aukstā starta dēļ ir vēl viena visai kategorijai kopīga sūdzība ar mehānisku skaidrojumu, un to mēs aprakstījām rakstā kāpēc diktēšanas lietotnes apēd tavu pirmo vārdu.

Keebye ir agrīnajā piekļuvē macOS videi. Ja tavs diktējums kādreiz ir pazudis kaut kur starp muti un termināli, sāc bezmaksas izmēģinājumu zemāk, ieslēdz rakstīšanas režīmu un atkārto to pašu promptu. Tavs nokopētais SHA paliek starpliktuvē, kamēr vārdi pienāk kā uzrakstīts Unicode.