Диктування, яке витримує термінал

Розробники, які пробують інструменти диктування, часто натрапляють на збій дуже специфічної форми. Інструмент чудово працює в демонстрації. Він працює в Notes, у Slack, у браузері. А тоді ви фокусуєте термінал, диктуєте речення — і або нічого не з’являється, або з’являється щось не те, що ви сказали, або з’являється половина, а друга половина тепер загадковим чином опинилася у вашому буфері обміну. Іноді все працює локально й помирає тієї миті, коли ви заходите на машину через SSH.

Ця закономірність достатньо стала, щоб я не вважав її вадою якогось одного продукту. Це наслідок того, як уся категорія вставляє текст, — і він дає збій рівно в тих місцях, де живе розробник.

Зараз це важить більше, ніж два роки тому. Якщо ви керуєте Claude Code голосом — робочий процес, який я описав у керуванні Claude Code голосом, — то термінал не є одним застосунком з-поміж багатьох. Він і є тим самим застосунком. Саме туди потрапляють ваші промпти, саме там агенти чекають на скерування, саме там уся ця історія з паралельними доріжками або працює, або ні. Інструмент диктування, ненадійний у терміналах, для vibe-кодера ненадійний у своїй єдиній роботі.

Чому вставлення ламається саме там, де живуть розробники

Ось механіка на рівні категорії. Більшість інструментів диктування вставляють текст однаково: кладуть транскрибоване речення в системний буфер обміну, а тоді синтезують натискання Cmd+V у застосунку з фокусом. Це розумний типовий вибір — вставлення миттєве, воно працює майже в будь-якому графічному текстовому полі й майже не потребує інженерної роботи під кожен застосунок.

Проблема — в усьому тому, від чого це припущення тихо залежить.

Воно залежить від того, чи трактує застосунок із фокусом Cmd+V як «вставити». Термінали часто ні: багато з них використовують Cmd+V для чогось іншого або ні для чого, tmux і vim мають власні уявлення про те, що означає вставлення, а віддалена SSH-сесія може витлумачити сплеск вставленого тексту так, як локальна машина передбачити не може. Bracketed paste, режим копіювання, режим вставки проти звичайного режиму: світ терміналів повний станів, у яких синтетичне вставлення потрапляє не туди або нікуди.

Воно залежить від того, чи буфер обміну доступний і не захищений. Менеджери буфера обміну його переписують. Менеджери паролів навмисно його очищають або захищають — функція безпеки, що мовчки перетворює «встав моє диктування» на «встав нічого». І навіть коли все спрацювало, інструмент щойно перезаписав те, що ви скопіювали. SHA коміту, який ви несли між вікнами, зник — його замінило ваше ж речення. Для того, хто жонглює кількома доріжками, це не подряпина: буфер обміну виконував роботу.

І воно залежить — ось це людей дивує — від вашої розкладки клавіатури. Коли інструмент відкочується до симуляції натискань клавіш, наївний спосіб — надсилати коди клавіш: фізичні позиції. Коди клавіш перетворюються на символи через вашу розкладку. На QWERTY код для «V» дає V. На Dvorak та сама фізична позиція — це інша літера. Тож інструмент, що симулює скан-коди на розкладці Dvorak, AZERTY чи Colemak, видає текст, який має вигляд шифру простої заміни. Користувачі повідомляють про абракадабру й припускають, що зламалося розпізнавання мовлення. Ні — мовлення розпізналося ідеально, його переплутало вставлення.

У цьому немає ані злого умислу, ані чиїхось лінощів. Вставлення через буфер обміну — правильний типовий вибір для 90% випадків. Просто розробники проводять день в інших 10%.

Що насправді означає «надрукуй це натомість»

У Keebye є налаштування insert_mode з двома значеннями: paste — типове — і type.

Режим набору не вставляє. На macOS він використовує CGEventKeyboardSetUnicodeString — API, що прикріплює сам текст у Unicode до синтетичної події клавіші. Символ несеться в самій події, а не шукається через вашу розкладку клавіатури. Це робить його незалежним від розкладки за конструкцією: Dvorak, AZERTY, Colemak — на чому б ви не друкували, надходить саме той текст, який було транскрибовано, бо перетворення скан-коду на символ, яке можна зіпсувати, тут ніколи не було.

Друга властивість режиму набору — та, що цікавить користувачів терміналів: він ніколи не чіпає буфер обміну. Нуль операцій із буфером обміну на цьому шляху коду. Вміст вашого буфера обміну залишається вашим — SHA виживає, менеджеру паролів немає від чого захищатися, менеджеру буфера обміну немає чого записувати.

А оскільки термінали й віддалені сесії можуть захлинатися текстом, що надходить швидше, ніж друкує людина, режим набору свідомо тримає темп: текст іде частинами по 16 символів із проміжком у 4 мілісекунди між частинами. Достатньо швидко, щоб речення надійшло значно менш ніж за секунду; достатньо розмірено, щоб панель tmux через SSH отримала його як натискання клавіш, за якими встигає, а не як згусток, який треба тлумачити.

Режим вставлення нікуди не подівся й лишається типовим, бо він справді швидший для великих блоків тексту у звичайних графічних застосунках — повідомлення у Slack на три абзаци надходить одним вставленням, а не потоком частин. Утім, урок про розкладки засвоїв і режим вставлення: синтетичне Cmd+V використовує фізичний код клавіші V, тож саме вставлення не ламається на розкладках, відмінних від QWERTY, так, як це буває з підходами через пошук символів.

Практичне налаштування для роботи з агентами просте: перемкніть insert_mode на type, сфокусуйте термінал із запущеним Claude Code, утримайте клавішу, скажіть скерування, відпустіть. Промпт надійде так, як надійшли б натискання клавіш, бо, з погляду термінала, це вони і є. Покроковий варіант цього налаштування, включно з особливостями SSH і tmux, є в голосовому диктуванні для терміналу macOS.

Чесні обмеження

Режим набору повільніший за вставлення на довгих текстах — це арифметика, а не дефект. Натискання клавіш частинами з проміжками для темпу тривають довше, ніж одна подія вставлення, і якщо ви диктуєте кілька абзаців у документ, режим вставлення відчуватиметься жвавішим. Саме тому вставлення лишається типовим, а режим набору вмикаєте ви самі в налаштуваннях: правильний режим залежить від того, куди прямує ваш текст.

Деякі застосунки обмежують частоту синтетичного введення або фільтрують його, зазвичай з міркувань безпеки, і жодна стратегія вставлення від цього повністю не втече — застосунок, який відмовляється приймати синтетичні події, відмовляє їх кожному інструменту диктування.

І щоб прямо сказати, про що ця стаття і про що вона ні: скарга «вставлення ламається в терміналах» — це закономірність по всій категорії диктування, а не вада, притаманна якомусь конкретному конкурентові. Інші інструменти мають власні відповіді й власні сильні сторони — ми написали чесні порівняння Keebye vs Superwhisper і Keebye vs Wispr Flow, включно з тим, де кожен із них може пасувати вам краще.

Вставлення — це неефектна половина диктування

Уся увага дістається розпізнаванню мовлення: назви моделей, заяви про точність, кількість мов. Але в інструмента диктування дві роботи: правильно вас почути — а тоді доставити текст туди, де стоїть курсор, не втративши й не спотворивши його. Друга робота звучить тривіально, і саме на ній категорія тихо підводить розробників, бо друга робота легка в TextEdit і важка в панелі tmux на віддаленій машині під розкладкою Dvorak.

Якщо ваші промпти потрапляють у термінали — а якщо ви керуєте агентами для коду, то потрапляють, — вставлення не є виноскою. Це різниця між інструментом, який ви демонструєте, і інструментом, яким ви користуєтеся. До речі, споріднені режими збою мають той самий присмак: з’їдене перше слово диктування через холодний старт мікрофона — це ще одна скарга рівня категорії з механічним поясненням, і про неї ми написали в чому застосунки диктування з’їдають ваше перше слово.

Keebye перебуває в ранньому доступі для macOS. Якщо ваше диктування бодай раз зникало десь між вашим ротом і терміналом, почніть безкоштовний пробний період нижче, увімкніть режим набору й повторіть той самий промпт. Скопійований SHA залишиться в буфері обміну, поки слова надходитимуть як надрукований Unicode.