Вы только что закончили длинное структурированное письмо клиенту в Gmail. Нажимаете «Отправить», переключаетесь в Slack — и замираете на секунду. Пальцы готовы продолжать в том же официальном тоне. Не то приложение. Не та атмосфера.
Поэтому вы стираете уже почти набранное "Уважаемые коллеги," и начинаете заново с дружелюбного приветствия. Через три приложения вы снова переписываете — для документа в Notion. Потом ещё раз — для комментария к код-ревью. И каждый раз делаете одну и ту же маленькую умственную работу: подбираете тон, которого ждёт конкретное приложение.
В среднем офисный работник переключается между приложениями около 1200 раз в день, и у каждого приложения свои правила письма. Ваш мозг их знает, но платит налог каждый раз, когда приходится перенастраиваться. Умные правила письма — это решение. Они позволяют инструментам автоматически подстраивать тон под каждое приложение, чтобы вам не приходилось делать это самому.
Почему один тон не подходит всем приложениям
Каждое приложение создано под свой тип общения. В них зашиты конвенции, которые сами подсказывают, какое письмо здесь уместно, — даже если вы этого не замечаете.
Slack создан для скорости. Сообщения короткие, в тредах, их чаще пробегают глазами. Официальное "Уважаемые коллеги," выглядит сухо или даже пассивно-агрессивно. По данным собственного исследования Slack о коммуникации на работе, 70% сотрудников предпочитают неформальное общение с коллегами строго деловому языку.
Email — противоположность. Это место для структурного мышления, документирования и сообщений, которые могут быть пересланы или сохранены на годы. Небрежное "привет" нормально звучит в Slack, но фальшиво — в письме клиенту. Сам формат — тема, приветствие, подпись — приглашает к более взвешенному тону.
Дальше идут документы. Notion, Google Docs, страницы Confluence. Они где-то посередине: структурированнее чата, но менее «показные», чем email. Здесь важны списки и заголовки. Предложения становятся длиннее.
Редакторам кода и терминалам нужен совсем другой стиль. Комментарии и сообщения коммитов должны быть короткими, конкретными и в настоящем времени. "Обрабатывает случай, когда пользователь null" звучит лучше, чем "Привет, команда, я внёс небольшое изменение, чтобы обработать один хитрый кейс".
Посты в X (Twitter) — отдельный мир: ёмкие, разбитые на строки, часто нарочито небрежные, чтобы выглядеть «своими» в ленте. Посты в LinkedIn — тёплые и личные. Проектные инструменты вроде Linear и Jira ждут плоских, ориентированных на решение комментариев без преамбулы.
Вы всё это и так знаете. И постоянно применяете. Цена в том, что вы делаете это вручную — в каждом сообщении.
Скрытая цена ручного переключения тона
Переключение тона кажется бесплатным, потому что каждый отдельный случай — мелочь. Но суммарно это быстро складывается в реальную нагрузку.
Исследование Anatomy of Work Index от Asana показало, что специалисты умственного труда используют около 10 разных приложений в день и переключаются между ними примерно 25 раз. Отдельное исследование Harvard Business Review оценило это число почти в 1200 переключений в день между приложениями и сайтами — примерно одно переключение каждые 24 секунды за восьмичасовой день.
Большая часть этих переключений связана с письмом. Ответ в Slack, черновик письма, комментарий в Linear, правка документа. Каждый раз — быстрая мысленная перенастройка: - Насколько официально это должно звучать? - Какой длины? - Уместны ли тут эмодзи? - Списки или абзацы? - Прощаюсь или просто заканчиваю?
Умножьте эти микро-решения на сотни сообщений в день — и получите ощутимую когнитивную нагрузку. 45% сотрудников говорят, что переключение между слишком большим числом приложений снижает их продуктивность, а 43% считают это умственно изматывающим. И часть этого налога уходит именно на то, чтобы понять, какой стиль письма ждёт следующее приложение.
Что на самом деле такое «умные правила письма»
Умное правило письма — это две вещи, склеенные вместе: триггер (в каком вы приложении) и промпт (как ИИ должен переписать или отполировать текст). Когда вы пишете или диктуете в активное приложение, правило срабатывает и подгоняет результат под нужный стиль.
Вы не говорите инструменту «сделай это неформальным» каждый раз. Вы один раз настраиваете правило для Slack, один раз — для Gmail, один раз — для Notion. Инструмент сам определяет активное приложение и применяет подходящий стиль.
Итог: вы пишете или диктуете одинаково везде, а отполированный результат подстраивается под адресата. Усилие от переключения тона снижается с «каждое сообщение» до «настроил один раз».
Это не то же самое, что универсальный ИИ-«переключатель тона», куда нужно вставить текст, выбрать тон из выпадашки и скопировать результат обратно. Там вся работа всё равно на вас. Умные правила убирают саму выпадашку.
Из чего состоит хорошее правило письма
У хорошего правила для одного приложения примерно пять компонентов. Пропустите любой — и результат начнёт «плыть».
1. Уровень формальности
Неформальный, нейтральный, деловой или технический. Это задаёт «температуру» всего сообщения: словарь, сокращения, ритм фраз.
2. Целевая длина
Коротко и по делу (Slack), среднего объёма и структурно (email) — или то, чего просит конкретное приложение. Правила без указания длины обычно «переразъясняют» по умолчанию.
3. Структура
Маркированные и нумерованные списки, абзацы, заголовки. Правило для Notion должно поощрять структуру. Правило для Slack — наоборот.
4. Политика по эмодзи и пунктуации
В одних приложениях эмодзи к месту, в других — нет. Где-то любят длинные тире, где-то — нет. Когда вы прописываете политику явно, ИИ не выбирает дефолт, который не подходит вашей команде.
5. Поведение с подписью
Письмо требует подписи. Slack — нет. Комментарии в коде — тоже нет. Если не уточнить, концовки будут разнобойными. Половина сообщений в Slack будет случайно заканчиваться "Спасибо,", потому что модели кажется, что так вежливее.
Вместе эти пять настроек превращают расплывчатое «сделай как надо для этого приложения» в правило, которое каждый раз даёт стабильный результат.
Именно это и делает функция Smart Rules в Voicr на macOS. Зажимаете клавишу FN, говорите из любого приложения — и правило для этого приложения само полирует речь. На выходе текст уже в правильном тоне ещё до того, как попадает в буфер обмена. Никаких выпадашек, никаких переключателей тона, никакого «подожди, я перепишу».
Готовые правила, которые можно забрать себе
Ниже — промпты-правила для приложений, в которых вы, скорее всего, пишете чаще всего. Они написаны простым языком, как вы и сами бы написали для любой модели. Закидывайте их в Voicr, в команду Raycast AI, в действие Shortcuts или в любой другой инструмент, который прогоняет ваш текст через LLM.
Правило для Slack
``` Перепиши вход как неформальное, дружелюбное сообщение в Slack. Максимум 2–3 предложения. Используй сокращения. Убирай приветствия и прощания. Не используй маркированные списки, если я буквально не перечисляю что-то. Лёгкие эмодзи допустимы, если они уместны. Пропускай шаблонные фразы вроде "Надеюсь, у тебя всё хорошо". ```
Правило для email (Gmail, Outlook, Apple Mail)
``` Перепиши вход как деловое, но тёплое письмо. Начни с короткого приветствия и упомяни имя получателя, если я его назвал. Используй ясные абзацы по 2–4 предложения. Заверши вежливой подписью ("С уважением," или "Спасибо,"). Без эмодзи. Используй сокращения умеренно, чтобы смягчить тон, оставаясь в деловом регистре. ```
Правило для Notion / документов
``` Перепиши вход как ясный, структурированный текст документа. Используй короткие абзацы и маркированные списки там, где это уместно. Лучше обычные заголовки, чем встроенный жирный шрифт. Убирай «я-формулы» вроде "я думаю" или "я хочу сказать". Должно звучать как готовый раздел, а не сообщение в чате. ```
Правило для Linear / Jira (инженерные тикеты)
``` Перепиши вход как сфокусированный инженерный комментарий к тикету. Прямо и кратко. Настоящее время. Сначала вывод или решение. Маркированные подпункты, если их несколько. Без приветствий и прощаний. ```
Правило для редактора кода (VS Code, Cursor, Xcode)
``` Перепиши вход как короткий комментарий в коде. Настоящее время. Без "я" и "мы". Идеально — одно предложение, максимум два. Не повторяй то, что и так очевидно из кода — объясни «почему» или неочевидную часть. ```
Правило для X (Twitter)
``` Перепиши вход как твит. Ёмко, с переносами строк для читаемости, без корпоративной речи. Нижний регистр допустим. Убирай оговорки вроде "на мой взгляд". Максимум 240 символов. Хештеги — только если я их добавил сам. ```
Это отправные точки. Подкручивайте формулировки, пока результат не зазвучит как *вы*, а не как голос ИИ по умолчанию.
Сопоставляем правила с приложениями, которыми вы реально пользуетесь
Вам не нужно правило для каждого приложения, которое вы открываете. Нужны правила для тех, где вы пишете много.
Пройдитесь по своей последней неделе и заметьте, куда в основном уходил ваш набор текста. У большинства людей это короткий список: 1. Один мессенджер — Slack, Teams, Discord или iMessage 2. Один почтовый клиент — Gmail, Outlook, Apple Mail 3. Одно приложение для документов или заметок — Notion, Google Docs, Apple Notes, Obsidian 4. Один проектный инструмент — Linear, Jira, Asana, Height 5. Один редактор кода или терминал — VS Code, Cursor, Xcode, iTerm 6. Возможно, одна соцсеть — X, LinkedIn, Bluesky
Настройте правила для этих шести (или меньше). Всё остальное может опираться на разумное правило-полировку по умолчанию. За 30 правил никто медали не даёт. Скорее наоборот — придётся помнить, какое где применяется.
Если интересно копнуть глубже в сторону голосового ввода в каждом приложении, посмотрите наши гайды: голосовой ввод в Slack, диктовка писем на Mac и голосовой ввод в Notion.
Типичные ошибки при настройке правил письма
Большинство неудач с правилами укладывается в несколько предсказуемых сценариев.
Слишком расплывчатые правила
"Сделай это профессионально" даёт ИИ слишком много свободы. Уточняйте длину, структуру, поведение с подписью и политику по эмодзи. Чем конкретнее правило, тем стабильнее результат.
Слишком жёсткие правила
Противоположная ловушка. Если в правиле для Slack стоит жёсткий лимит в пять слов, каждое сообщение получится обрубленным и странным. Задавайте ориентиры, а не наручники.
Одинаковые правила под разными именами
Легко скопировать правило для email в «Confluence», «Notion» и «Jira» — и забыть. Но каждому нужен свой нюанс. Если два правила и правда идентичны, объедините их и пусть одно обслуживает оба приложения.
Правила, которые ломают вашу интонацию
У вашего письма есть характер. Правило, которое превращает всё в корпоративный шаблон, заставит вас бросить инструмент за неделю. Задача — переводить ваш голос в нужный регистр для каждого приложения, а не подменять его чьим-то ещё.
Забыть про правило по умолчанию
А что происходит, когда вы пишете в приложении без правила? Большинство инструментов откатывается на общую полировку. Убедитесь, что эта общая полировка вам действительно нравится, потому что срабатывать она будет чаще, чем кажется.
Как применить умные правила письма на практике
Если из всего этого взять одну мысль — вот она: цена переключения тона реальна и быстро накапливается. Каждая микро-правка, каждая маленькая перенастройка складываются в рабочий день. Умные правила письма — это способ перестать платить этот налог.
Начните с малого. Выберите два приложения, где вы пишете больше всего — обычно это Slack и почта — и напишите по одному правилу для каждого. Поживите с ними несколько дней. Подмечайте, что звучит не так, и правьте формулировки. Потом добавьте третье правило для приложения, которое идёт следующим по объёму письма за неделю.
Если не хочется собирать всё это самостоятельно, Voicr делает это нативно на macOS. Зажимаете FN в любом приложении, говорите естественно — и правило для этого приложения полирует ваши слова по пути в буфер обмена. Сообщения в Slack выходят неформальными, письма — деловыми, комментарии в коде — лаконичными. И вам не пришлось думать ни об одном из них. В этом и смысл: текст под нужный контекст, без самостоятельной переписки.