Тон оф войс бренда: часть живого документа, не разовая формулировка
Механизм один и тот же независимо от того, кто в компании пишет тексты и сколько их. Стержневая идея закладывается один раз, а дальше запускается цикл из четырёх шагов, который повторяется на каждом новом правиле документа.
- Старт: одна стержневая идея, не список тезисов. Разовое событие для всего документа, дальше в цикле не повторяется. Ванлайнер голоса бренда, из которого потом вырастают конкретные решения. Стартовой точкой для ToV в Timeweb Cloud была одна фраза из формулировки задачи: «не гиковский, но технически подкованный язык». Ориентир, с которым можно начинать писать.
- Команда пишет реальные тексты: лендинг, рассылку, пост в соцсетях, текст в интерфейсе. На каждом жанре стартовый тезис на что-то не отвечает, и сигнал об этом пробеле приходит из двух независимых источников. Первый: правки человека, редактора, ревьюера, самого автора, который спустя месяц перечитывает свой же текст и видит, что формулировка не сработала. Второй появился в практике за последние пару лет: регулярная работа с ИИ на черновиках. Модель систематически тянет текст к усредненному, статистически частому варианту, и именно там, где она это делает, чаще всего обнаруживается место, которое стоит закрепить как явное правило для всех следующих авторов.
- Решение принимается один раз, на конкретном тексте, независимо от того, заметил его человек или сверка с ИИ. Пример из практики Timeweb Cloud: команда переписывала рассылки и в какой-то момент закрепила разницу явным правилом. Сервисные письма перестали быть роботизированными, маркетинговые стали продающими. Решение приняли на реальных текстах, а не придумали заранее за столом.
- Только после этого решение переносится в документ отдельным пунктом. Правило фиксируется постфактум, как запись уже принятого на практике решения.
- Документ параллельно чистится. Это два разных механизма. Правило, которое ни разу не понадобилось на практике: кандидат на удаление. Правило, которое раньше соблюдали, а потом перестали: кандидат на перепроверку.
Сигнал о перепроверке приходит из тех же двух источников, что на шаге 2. У человека это забытая привычка: автор со временем незаметно возвращается к старым формулировкам, если документ давно не перечитывал. У ИИ похожая история без памяти между сессиями: каждый новый чат начинается заново, без следа вчерашних правок, и та же ошибка модели может вернуться, если документ не подгружен заново или подгружен не полностью.
Практический вывод для обоих источников один: время от времени прогонять уже опубликованные тексты через тот же цикл отдельным заходом, как аудит уже вышедшего. После этого шага цикл продолжается с шага 2: команда пишет уже следующие тексты, и всё запускается заново.
Оба источника сходятся в одном и том же документе постоянно: одно правило может появиться из спора с коллегой на конкретном письме, другое возникает потому, что модель раз за разом тянет формулировку в одну сторону. Разный повод, один и тот же цикл шагов 2–4.
Опция: документ иногда расщепляется на слои
Документ может годами оставаться одним файлом: это нормально, не недоработка. Но когда у конкретного адресата (формата текста или, отдельно, самой модели) накапливается достаточно специфики, которая перестает помещаться в общие правила без потери читаемости, документ иногда расщепляется на отдельные файлы. Тогда единицей фиксации становится целый слой документа.
В работе над Timeweb Cloud общая редполитика бренда в какой-то момент разошлась на отдельный единый гайд для лендингов и велком-писем и отдельный документ с идеями для велкомов: расщепление по формату текста.
А когда ToV регулярно заряжается в контекст нейросети, иногда пишется еще один, отдельный и более явный вариант документа, специально для того, чтобы модель писала правильно, потому что то, что очевидно коллеге по контексту, для модели приходится проговаривать в явном виде. Это тоже расщепление документа, только по другому критерию: по тому, кто его применяет, человек или инструмент. Тот же принцип, просто вторая ось.
Сами эти документы, закрытые корпоративные гугл-доки, на слово в статье не поверишь. Принцип тот же, что и у отдельного правила внутри документа: один базовый живой документ плюс отдельный слой, когда общий файл неудобен для другой цели.
Тон оф войс: примеры формулировок, которые реально работают
Ниже приведена реальная цитата из практики Timeweb Cloud, стартовая точка документа (шаг 1 выше), не придуманная для иллюстрации.
«Не гиковский, но технически подкованный язык».
Два примера ниже показывают типовой вид правила, не цитату из чьей-то реальной редполитики, и рождаются тем же способом, что описан выше.
«Восклицательный знак не чаще одного на письмо».
«Обращаемся к человеку на вы, а не называем его пользователем».
Первое правило снимает соблазн ставить восклицательный знак после каждого факта: тогда теряется, где эмоция настоящая, а где просто привычка. Оба работают по тому же принципу, что и реальное решение в Timeweb Cloud выше: правило формализует то, что раньше каждый раз решалось на глаз.
Как применять документ в ежедневной работе
Документ работает только при одном условии: он остаётся постоянным слоем контекста, не пересказом, который каждый раз формулируют заново. Это касается и нового человека в команде, и инструмента, с которым команда работает.
В Hostman это выглядело так: пригласил в команду сильного англоязычного автора Сергея Короля, вместе выстроили редакцию, которая говорит на языке разработчиков для англоязычного рынка. Формального ToV-документа с таким названием я не заявляю. Но согласование голоса между двумя авторами на новом рынке само по себе требует зафиксированных правил: без них два человека быстро расходятся в тоне, просто потому что у каждого свой слух на язык.
Тот же принцип работает и для нейросети, с которой работает команда: документ загружается как обязательный источник контекста на уровне всего пространства, не разовой вставкой в переписку. В потребительском Claude или ChatGPT это доступно как системная инструкция проекта или custom instructions: документ загружается один раз на уровне пространства, не копируется кусками в диалог каждый раз, когда просишь модель что-то написать или проверить.
Разница в масштабе проверяется жестче, чем разница в инструменте. В одном банке моей практики (узнаваемом по фирменному красному цвету) воронка внештатных авторов дошла почти до 1000 человек, в штат из них отобрали четверых. При таком масштабе устная договоренность о голосе перестает работать физически: с тысячей человек лично не поговоришь. Документ прочитают все сразу, и это работает при любом масштабе.
Я не утверждаю, что там существовал формальный файл под названием тон-оф-войс. Это аргумент в пользу тезиса, не кейс с цитируемыми формулировками из чьей-то реальной редполитики.
Тон оф войс на практике: сверка с документом, не просьба «сделай лучше»
Сначала посмотрим, как это делает человек. Редактор или ревьюер сверяет черновик с документом построчно: этот абзац нарушает пункт про профжаргон, здесь не совпадает тон. Разбор идёт по конкретным пунктам, не по общей фразе «сделай текст лучше». Это буквально то, как в моих текущих проектах устроен агент-редактор: разбор по пунктам конкретного документа плюс отдельный список спорных случаев, которые выносятся на решение человека, не чинятся молча.
Тот же принцип, примененный к ИИ, работает иначе, чем кажется на первый взгляд. У «сделай текст лучше» нет явного критерия: о ней у меня уже есть отдельная статья про ИИ-редактуру, и здесь эта мысль не повторяется как открытие. Задача «укажи построчно, какие пункты вот этого документа нарушены и где именно» устроена совсем иначе. Вторая формулировка передает документ как критерий, задача сводится к сверке, не к вкусовой оценке: модель больше не решает сама, что считать проблемой.
Первая формулировка почти всегда получает вежливое одобрение: модель склонна хвалить черновик, не рвать его на несоответствия. Вывод здесь тот же, что и для человека абзацем выше.
Разница между человеком и ИИ в надежности, не в логике сверки. Редактор-человек стабилен между заходами: если сегодня и через неделю показать ему один и тот же черновик и документ, вердикт не изменится. Один и тот же запрос к одной и той же модели может дать разные ответы в разные разы: это личное наблюдение практика, не результат бенчмарка, и итоговое решение по спорным местам всё равно остается за человеком. Разница ролей, не повод отказаться от ИИ-проверки вовсе. Про дрейф голоса между сессиями (когда память не переносится из чата в чат) я уже разбирал выше, на шаге про чистку документа: та же логика, здесь не повторяю.
Пятишаговый цикл выше можно применить к своему документу прямо сейчас: это рабочий чек-лист, не абстракция. Откройте тот самый файл и пройдитесь по каждому пункту с одним вопросом: он родился из конкретного текста или был вписан заранее, на всякий случай? Пункты второго типа стоит считать кандидатами на удаление.
И симметрично: если один и тот же спор про один и тот же жанр текста, с редактором или с ИИ, возникает второй или третий раз, это не повод спорить заново. Это готовый следующий пункт документа.
