Диктовка, которая выживает в терминале

Разработчики, которые пробуют инструменты диктовки, часто сталкиваются со сбоем очень определённой формы. В демонстрации инструмент работает прекрасно. Он работает в «Заметках», в Slack, в браузере. Затем вы переводите фокус на терминал, диктуете фразу — и либо ничего не появляется, либо появляется не то, что вы сказали, либо появляется половина, а вторая половина загадочным образом оказывается у вас в буфере обмена. Иногда всё работает локально и умирает в тот момент, когда вы заходите по SSH на сервер.

Закономерность настолько устойчива, что я не считаю это багом какого-то одного продукта. Это следствие того, как вся категория вставляет текст, — и ломается оно ровно в тех местах, где живёт разработчик.

Сейчас это важнее, чем два года назад. Если вы управляете Claude Code голосом — тот рабочий процесс, который я описал в статье управление Claude Code голосом, — то терминал не одно приложение из многих. Он и есть приложение. Именно там оказываются ваши промпты, там агенты ждут корректировок, там вся история с параллельными дорожками либо работает, либо нет. Инструмент диктовки, ненадёжный в терминалах, для вайб-кодера ненадёжен в своей единственной задаче.

Почему вставка ломается именно там, где живут разработчики

Вот механика уровня категории. Большинство инструментов диктовки вставляют текст одинаково: кладут расшифрованную фразу в системный буфер обмена, а затем синтезируют нажатие Cmd+V в приложении в фокусе. Это разумное поведение по умолчанию — вставка мгновенна, работает почти в любом поле ввода GUI и почти не требует инженерной работы под каждое приложение.

Проблема во всём, на что это допущение молча опирается.

Оно опирается на то, что приложение в фокусе трактует 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 получила её как нажатия клавиш, за которыми успевает, а не как ком, который надо истолковать.

Режим вставки никуда не делся и остаётся вариантом по умолчанию, потому что для больших блоков текста в обычных GUI-приложениях он действительно быстрее — сообщение в 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.