Тон оф войс бренда: часть живого документа, не разовая формулировка

Механизм один и тот же независимо от того, кто в компании пишет тексты и сколько их. Стержневая идея закладывается один раз, а дальше запускается цикл из четырёх шагов, который повторяется на каждом новом правиле документа.

  1. Старт: одна стержневая идея, не список тезисов. Разовое событие для всего документа, дальше в цикле не повторяется. Ванлайнер голоса бренда, из которого потом вырастают конкретные решения. Стартовой точкой для ToV в Timeweb Cloud была одна фраза из формулировки задачи: «не гиковский, но технически подкованный язык». Ориентир, с которым можно начинать писать.
  2. Команда пишет реальные тексты: лендинг, рассылку, пост в соцсетях, текст в интерфейсе. На каждом жанре стартовый тезис на что-то не отвечает, и сигнал об этом пробеле приходит из двух независимых источников. Первый: правки человека, редактора, ревьюера, самого автора, который спустя месяц перечитывает свой же текст и видит, что формулировка не сработала. Второй появился в практике за последние пару лет: регулярная работа с ИИ на черновиках. Модель систематически тянет текст к усредненному, статистически частому варианту, и именно там, где она это делает, чаще всего обнаруживается место, которое стоит закрепить как явное правило для всех следующих авторов.
  3. Решение принимается один раз, на конкретном тексте, независимо от того, заметил его человек или сверка с ИИ. Пример из практики Timeweb Cloud: команда переписывала рассылки и в какой-то момент закрепила разницу явным правилом. Сервисные письма перестали быть роботизированными, маркетинговые стали продающими. Решение приняли на реальных текстах, а не придумали заранее за столом.
  4. Только после этого решение переносится в документ отдельным пунктом. Правило фиксируется постфактум, как запись уже принятого на практике решения.
  5. Документ параллельно чистится. Это два разных механизма. Правило, которое ни разу не понадобилось на практике: кандидат на удаление. Правило, которое раньше соблюдали, а потом перестали: кандидат на перепроверку.

Сигнал о перепроверке приходит из тех же двух источников, что на шаге 2. У человека это забытая привычка: автор со временем незаметно возвращается к старым формулировкам, если документ давно не перечитывал. У ИИ похожая история без памяти между сессиями: каждый новый чат начинается заново, без следа вчерашних правок, и та же ошибка модели может вернуться, если документ не подгружен заново или подгружен не полностью.

Практический вывод для обоих источников один: время от времени прогонять уже опубликованные тексты через тот же цикл отдельным заходом, как аудит уже вышедшего. После этого шага цикл продолжается с шага 2: команда пишет уже следующие тексты, и всё запускается заново.

Оба источника сходятся в одном и том же документе постоянно: одно правило может появиться из спора с коллегой на конкретном письме, другое возникает потому, что модель раз за разом тянет формулировку в одну сторону. Разный повод, один и тот же цикл шагов 2–4.

Правки человека и работа с ИИ запускают один и тот же цикл документа, просто с разным триггером на старте.

Опция: документ иногда расщепляется на слои

Документ может годами оставаться одним файлом: это нормально, не недоработка. Но когда у конкретного адресата (формата текста или, отдельно, самой модели) накапливается достаточно специфики, которая перестает помещаться в общие правила без потери читаемости, документ иногда расщепляется на отдельные файлы. Тогда единицей фиксации становится целый слой документа.

В работе над Timeweb Cloud общая редполитика бренда в какой-то момент разошлась на отдельный единый гайд для лендингов и велком-писем и отдельный документ с идеями для велкомов: расщепление по формату текста.

А когда ToV регулярно заряжается в контекст нейросети, иногда пишется еще один, отдельный и более явный вариант документа, специально для того, чтобы модель писала правильно, потому что то, что очевидно коллеге по контексту, для модели приходится проговаривать в явном виде. Это тоже расщепление документа, только по другому критерию: по тому, кто его применяет, человек или инструмент. Тот же принцип, просто вторая ось.

Сами эти документы, закрытые корпоративные гугл-доки, на слово в статье не поверишь. Принцип тот же, что и у отдельного правила внутри документа: один базовый живой документ плюс отдельный слой, когда общий файл неудобен для другой цели.

Тон оф войс: примеры формулировок, которые реально работают

Ниже приведена реальная цитата из практики Timeweb Cloud, стартовая точка документа (шаг 1 выше), не придуманная для иллюстрации.

Timeweb Cloud

«Не гиковский, но технически подкованный язык».

Два примера ниже показывают типовой вид правила, не цитату из чьей-то реальной редполитики, и рождаются тем же способом, что описан выше.

Пример

«Восклицательный знак не чаще одного на письмо».

Пример

«Обращаемся к человеку на вы, а не называем его пользователем».

Первое правило снимает соблазн ставить восклицательный знак после каждого факта: тогда теряется, где эмоция настоящая, а где просто привычка. Оба работают по тому же принципу, что и реальное решение в Timeweb Cloud выше: правило формализует то, что раньше каждый раз решалось на глаз.

Как применять документ в ежедневной работе

Документ работает только при одном условии: он остаётся постоянным слоем контекста, не пересказом, который каждый раз формулируют заново. Это касается и нового человека в команде, и инструмента, с которым команда работает.

В Hostman это выглядело так: пригласил в команду сильного англоязычного автора Сергея Короля, вместе выстроили редакцию, которая говорит на языке разработчиков для англоязычного рынка. Формального ToV-документа с таким названием я не заявляю. Но согласование голоса между двумя авторами на новом рынке само по себе требует зафиксированных правил: без них два человека быстро расходятся в тоне, просто потому что у каждого свой слух на язык.

Тот же принцип работает и для нейросети, с которой работает команда: документ загружается как обязательный источник контекста на уровне всего пространства, не разовой вставкой в переписку. В потребительском Claude или ChatGPT это доступно как системная инструкция проекта или custom instructions: документ загружается один раз на уровне пространства, не копируется кусками в диалог каждый раз, когда просишь модель что-то написать или проверить.

Разница в масштабе проверяется жестче, чем разница в инструменте. В одном банке моей практики (узнаваемом по фирменному красному цвету) воронка внештатных авторов дошла почти до 1000 человек, в штат из них отобрали четверых. При таком масштабе устная договоренность о голосе перестает работать физически: с тысячей человек лично не поговоришь. Документ прочитают все сразу, и это работает при любом масштабе.

Я не утверждаю, что там существовал формальный файл под названием тон-оф-войс. Это аргумент в пользу тезиса, не кейс с цитируемыми формулировками из чьей-то реальной редполитики.

Тон оф войс на практике: сверка с документом, не просьба «сделай лучше»

Сначала посмотрим, как это делает человек. Редактор или ревьюер сверяет черновик с документом построчно: этот абзац нарушает пункт про профжаргон, здесь не совпадает тон. Разбор идёт по конкретным пунктам, не по общей фразе «сделай текст лучше». Это буквально то, как в моих текущих проектах устроен агент-редактор: разбор по пунктам конкретного документа плюс отдельный список спорных случаев, которые выносятся на решение человека, не чинятся молча.

Тот же принцип, примененный к ИИ, работает иначе, чем кажется на первый взгляд. У «сделай текст лучше» нет явного критерия: о ней у меня уже есть отдельная статья про ИИ-редактуру, и здесь эта мысль не повторяется как открытие. Задача «укажи построчно, какие пункты вот этого документа нарушены и где именно» устроена совсем иначе. Вторая формулировка передает документ как критерий, задача сводится к сверке, не к вкусовой оценке: модель больше не решает сама, что считать проблемой.

Первая формулировка почти всегда получает вежливое одобрение: модель склонна хвалить черновик, не рвать его на несоответствия. Вывод здесь тот же, что и для человека абзацем выше.

Без документа с явными правилами промпт бессилен что при редактуре, что при проверке. Документ здесь обязательное условие в обоих случаях, а не промпт его заменяет.

Разница между человеком и ИИ в надежности, не в логике сверки. Редактор-человек стабилен между заходами: если сегодня и через неделю показать ему один и тот же черновик и документ, вердикт не изменится. Один и тот же запрос к одной и той же модели может дать разные ответы в разные разы: это личное наблюдение практика, не результат бенчмарка, и итоговое решение по спорным местам всё равно остается за человеком. Разница ролей, не повод отказаться от ИИ-проверки вовсе. Про дрейф голоса между сессиями (когда память не переносится из чата в чат) я уже разбирал выше, на шаге про чистку документа: та же логика, здесь не повторяю.

* * *

Пятишаговый цикл выше можно применить к своему документу прямо сейчас: это рабочий чек-лист, не абстракция. Откройте тот самый файл и пройдитесь по каждому пункту с одним вопросом: он родился из конкретного текста или был вписан заранее, на всякий случай? Пункты второго типа стоит считать кандидатами на удаление.

И симметрично: если один и тот же спор про один и тот же жанр текста, с редактором или с ИИ, возникает второй или третий раз, это не повод спорить заново. Это готовый следующий пункт документа.