{ "version": "https:\/\/jsonfeed.org\/version\/1", "title": "Виталий Филатов", "_rss_description": "Меня зовут Виталий Филатов. Я коммерческий писатель, помогаю бизнесу рассказывать о себе и продукте. Пишу и редактирую статьи, инструкции, текст сайтов и интерфейсов. Люблю работать в команде с дизайнерами и разработчиками.", "_rss_language": "ru", "_itunes_email": "", "_itunes_categories_xml": "", "_itunes_image": "", "_itunes_explicit": "", "home_page_url": "https:\/\/vitalyfilatov.ru\/", "feed_url": "https:\/\/vitalyfilatov.ru\/rss\/", "icon": "https:\/\/vitalyfilatov.ru\/user\/userpic@2x.jpg?1613163987", "author": { "name": "Виталий Филатов", "url": "https:\/\/vitalyfilatov.ru\/", "avatar": "https:\/\/vitalyfilatov.ru\/user\/userpic@2x.jpg?1613163987" }, "items": [ { "id": "104", "url": "https:\/\/vitalyfilatov.ru\/all\/status-model\/", "title": "Упрощаем набор статусов статьи", "content_html": "

Ещё один частный случай с высокими абстракциями. На этот раз на примере статусов статьи в админке Помощи ВТБ Бизнеса из прошлой статьи<\/a>.<\/p>\n

TLDR. Сперва модель статусов отражала серверную логику, отчего жизненный цикл статьи выглядел сложно. Мы вынесли один из статусов в параметр, и стало попроще, но не всем понравилось.<\/p>\n

Контекст и задача<\/h2>\n

На тот момент из-за особенностей архитектуры продукта статьи Помощи считались частью кода и обновлялись с общим релизом. Просто так править статьи было нельзя. Все изменения собирались в админке, ждали ближайшего релиза и синхронизировались с версией Помощи на проде.<\/p>\n

Из-за привязки к общему релизу статусы в админке отражали не только текущее состояние, но и будущие изменения. Кроме того, у опубликованных статей можно было управлять видимостью, что создавало дополнительные статусы.<\/p>\n

\n\"\"\n
Статусная модель статьи в админке. Если не сохранять изменения, статья возвращается в предыдущее состояние. Статью нельзя стразу опубликовать скрытой, но почему — уже не помню<\/div>\n<\/div>\n

Мне доверили придумать краткие и ясные названия статусам, чтобы пользователь меньше путался. Но я сам запутался и решил, что для начала хорошо бы упростить саму модель.<\/p>\n

Немного теории<\/h2>\n

Статусная модель описывает жизненный цикл сущностей, с которыми работает пользователь: заказы, посылки, статьи. Модель объясняет, в каких состояниях объекты могут находиться и по каким правилам переходят из одного в другое.<\/p>\n

Редакторам статусная модель интересна тем, что в ней пересекаются миры разработчиков и пользователей.<\/p>\n

Для разработчика<\/b> статусная модель — это модель жизненного цикла объекта данных, она показывает логику работы программы. За прямоугольниками на схеме разработчик видит программный код, схемы баз данных и текст запросов к ним.<\/p>\n

Для пользователя<\/b> статусная модель — важная часть ментальной модели продукта. На её основе пользователь собирает у себя в голове понимание того, как работает интерфейс. Очевидно, чем логичнее для пользователя набор состояний сущности, тем проще: не нужно запоминать значения статусов и сложные схемы переходов.<\/p>\n

\n

Хорошую статусную модель пользователь понимает интуитивно<\/p>\n<\/blockquote>\n

Чаще всего глазами пользователя на статусную модель никто не смотрит, поэтому вместе с ней в интерфейс просачивается логика программного кода. А когда пользователи начинают путаться, редактору поручают лечить проблемы в сценариях формулировками статусов и тултипами.<\/p>\n

Решение<\/h2>\n

Я предложил сделать видимость статьи одним из параметров, как её название или ключевые слова. В этом случае мы бы переключали видимость флажком в настройках и катили изменённую статью на прод. Такой подход не сильно менял структуру баз данных, но здорово упрощал схему состояний и переходов:<\/p>\n

\n\"\"\n
Если видимость сделать параметром, отдельные статусы для включения и выключения не понадобятся<\/div>\n<\/div>\n

По этой же логике можно было бы вынести в параметры и удаление, но его решили оставить отдельным статусом для удобства. Кнопка «Удалить» перемещала статью в статус «Удаляем» и заменялась на «Отменить удаление».<\/p>\n

В интерфейсе я предложил вынести статьи к релизу в отдельную вкладку и показывать там не статусы, а описание изменений.<\/p>\n

\n\"\"\n
Фрагмент условного интерфейса админки со списком публикуемых статей<\/div>\n<\/div>\n

Аналитику такое решение показалось непривычным и избыточным, мнения разделились. К счастью, пока мы спорили, публикацию статей удалось отвязать от релизного цикла, и набор статусов упростился сам собой.<\/p>\n", "date_published": "2026-05-06T17:06:57+05:00", "date_modified": "2026-05-08T17:56:02+05:00", "image": "https:\/\/vitalyfilatov.ru\/pictures\/092-complex-model@2x.png", "_date_published_rfc2822": "Wed, 06 May 2026 17:06:57 +0500", "_rss_guid_is_permalink": "false", "_rss_guid": "104", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [ "https:\/\/vitalyfilatov.ru\/pictures\/092-complex-model@2x.png", "https:\/\/vitalyfilatov.ru\/pictures\/092-simple-model@2x.png", "https:\/\/vitalyfilatov.ru\/pictures\/092-articles-lists@2x.png" ] } }, { "id": "103", "url": "https:\/\/vitalyfilatov.ru\/all\/vtb-help\/", "title": "Редакционные процессы Помощи ВТБ Бизнеса", "content_html": "

История о том, как рерайт статей превратился в реорганизацию процессов производства.<\/p>\n

Ситуация и задача<\/h2>\n

В 2020 году ВТБ открыл интернет-банк для малого и среднего бизнеса — ВТБ Бизнес. Он служил витриной для уже существовавших банковских продуктов, которые вели автономные команды — СУБО. Такая архитектура не предусматривала единой языковой службы, да и мода на большие редакции до банка ещё не добралась. В команде платформы уже был редактор, но он занимался в основном задачами маркетинга, а статьи для справочного раздела каждое команда-СУБО писала сама.<\/p>\n

Статьи публиковались в сервисе «Помощь»<\/a>, который вела специальная команда внутренних сервисов. Руководителя этой команды беспокоило неравномерное качество этих статей, и он решил нанять второго редактора, переписывать за бизнес-аналитиками и наводить красоту. Так в команде Помощи появился я.<\/p>\n

На момент моего появления работа была организована так:<\/p>\n

    \n
  1. Каждое СУБО отвечало за свои статьи и никого к себе не пускало. Аналитики и юристы не умели писать пользовательские инструкции, поэтому ограничивались односложными ответами на частые вопросы, а стиль и глубина изложения сильно отличались.<\/li>\n
  2. Исходники статей хранились в эксель-таблицах у каждого СУБО. Авторы сами делали иллюстрации из скриншотов на тестовом сервере и заливали в общее облако.<\/li>\n
  3. Когда нужно было что-то изменить или добавить, бизнес-аналитик СУБО правил свою таблицу, выделял изменения цветом и присылал новый файл по почте команде Помощи.<\/li>\n
  4. Там текст из файла вставляли в базу данных и выкатывали на прод с общим релизом.<\/li>\n<\/ol>\n

    Процесс получался хаотичным: версии статей не отслеживали, файлы таблиц дублировались, актуальные правки терялись, картинки разных СУБО перетирали друг друга из-за совпадающих имён. Оперативно выложить что-то было невозможно из-за релизной политики, поэтому иногда статьи успевали обновиться несколько раз до релиза и окончательно всех запутать.<\/p>\n

    Чтобы упорядочить процесс, команда Помощи написала специальную админку с визуальным редактором, где авторы смогли бы работать со статьями без посредников. Но качество от этого не росло, а править и согласовывать текст в админке было так же муторно, как и в эксель-таблицах. Так что я составил план, заручился поддержкой команды и переделал сам подход к производству.<\/p>\n

    Работа с материалами<\/h2>\n

    Первым делом я убедил команду, что писать статьи и следить за структурой разделов нужно нам самим, а СУБО оставить только сбор фактуры, обновление макетов и согласование. Уже опубликованные статьи мы решили постепенно переписать по мере изменений в продуктах.<\/p>\n

    СУБО не обрадовались потере контроля, но после нескольких согласованных статей они обычно убеждались, что редактор бережно передаёт смысл, начинали доверять и охотнее рассказывать о бизнес-логике и нюансах.<\/p>\n

    Мы перенесли все статьи в гугл-доки<\/b>, а ссылки на них и служебную информацию собрали в сводной гугл-таблице. Таблица решала две задачи: хранила статьи со статусами и служила функциональным прототипом для следующих версий админки Помощи.<\/p>\n

    \n\"\"\n
    Сводная таблица — сердце системы контента. Там мы хранили все статьи, включая снятые с публикации, отменённые и удалённые. Вся таблица в гигантском PNG<\/a>, 2 Мб<\/div>\n<\/div>\n

    В первой версии админки не было инструментов согласования, поэтому их заменяли гугл-доки. Мы гибко настраивали доступы, вели архив версий, принимали и согласовывали правки. Особый шик давала совместная работа: на сложных согласованиях я приглашал всех следить за моим курсором в документе и правил текст прямо во время звонка, без расшаривания экрана.<\/p>\n

    Гугл-доки помогали и в вёрстке. Я подогнал шаблон статьи максимально близко к дизайну прода и при редактировании сразу видел примерную форму абзацев и переносы строк.<\/p>\n

    \n\"\"\n
    Аналитики и юристы могли комментировать исходники в любое время, я оперативно разбирал правки и публиковал обновления с ближайшим релизом<\/div>\n<\/div>\n

    Далее мы убрали автогенерацию слагов<\/b> — уникальных частей в URL-адресах статей. Первоначально слаг создавался транслитерацией заголовка, но адреса получались длинными и нечитаемыми. Я предложил составлять слаги силами редактора, чтобы адреса получались понятнее, умещались в СМС и не разрывали сообщения чат-бота.<\/p>\n

    \n

    Срок действия дополнительных опций к пакетам услуг
    \n↓
    \ndb.vtb.ru\/faq\/answers\/srok-dejstviya-dopolnitelnyh-opcij-k-paketam-uslug<\/b>
    \n↓
    \ndb.vtb.ru\/faq\/answers\/srok-dop-optsii<\/b><\/p>\n<\/blockquote>\n

    Уникальностью слагов отслеживали по сводной таблице и проверке на дубли в админке.<\/p>\n

    Поскольку слаги менялись крайне редко, я включил их в имена файлов иллюстраций. Такие имена не повторялись, и по ним можно было фильтровать файлы в хранилище. Папки в облаке также назывались слагом статьи.<\/p>\n

    \n\"\"\n
    Имена файлов упрощали рутину. Например, пожав пачку картинок в тинифаере, я сразу знал, куда сохранять архив с результатом<\/div>\n<\/div>\n

    Перешли со скриншотов интерфейса на макеты в Фигме<\/b>. Пришлось искать подход к дизайнерам СУБО и убеждать их обновлять макеты к релизам, но оно того стоило. Иллюстрации стали чище и консистентнее, а их исходники были всегда доступны. Но главное — мы смогли показывать все нужные состояния интерфейса, а не только те, что получалось поймать на тестовом сервере.<\/p>\n

    Сначала я готовил иллюстрации сам, чтобы изучить нюансы и сформулировать правила. Позже собрал всё в гайд для дизайнеров, и они начали мне помогать.<\/p>\n

    Гайд по изображениям для статей Помощи<\/a> получился наглядным: все картинки в нём собраны по требованиям гайда, чтобы читатель сразу видел образец.<\/p>\n

    Создали наглядный прототип в Обсидиане<\/b>, где отслеживали структуру каталогов, связи между статьями, выпавшие иллюстрации и ссылки на файлы. Чтобы не делать это руками после каждого крупного обновления, я собрал требования, а аналитик Евгений написал скрипт на Питоне.<\/p>\n

    \n\"\"\n
    Граф опубликованных статей в Обсидиане. Красные точки — страницы категорий, оранжевые — статьи с перекрёстными ссылками, а зелёные — с файлами для скачивания<\/div>\n<\/div>\n

    Публикация статей<\/h2>\n

    Админка Помощи задумывалась не для редакторов, поэтому за основу команда взяла визуальный редактор на контейнерах — как в Ноушене. Но он не умел работать в режиме исходного кода — HTML или маркдауна.<\/p>\n

    Необходимость настраивать оформление вручную ломала мой отработанный процесс: на других проектах я целиком копировал гугл-док и прогонял текст через Драйзер<\/a> — самописный скрипт на регулярках. Скрипт вырезал инлайн-стили и служебные блоки, оставляя чистый HTML. Так я мог заряжать в админку по статье в минуту.<\/p>\n

    Менять редактор было поздно, но разработчики нашли остроумное решение: добавили переключатель, который скрывал все контейнеры и показывал поле для HTML-кода.<\/p>\n

    \n
    \n\"\"\n\"\"\n<\/div>\n
    Редактирование статьи в обычном и экспертном режимах. В ранних версиях админки статья называлась вопросом, так уж вышло<\/div>\n<\/div>\n

    Мы выбрали HTML, а не в маркдаун, чтобы как можно меньше переписывать админку. Я всё равно получал готовый код из гугл-дока и сразу типографил текст своими скриптами.<\/p>\n

    Ещё я поучаствовал в разработке админки: тестировал механики, писал текст интерфейса, подменял дизайнера, надоедал всем нормами типографики и спорил с бизнес-аналитиком из-за статусной модели<\/a> :3<\/p>\n

    Работа с СУБО<\/h2>\n

    Сначала в Помощи публиковались 10 команд, но позже их стало уже 35. Они постоянно что-то меняли, уследить за всем было невозможно. Поэтому мы договорились, что за актуальностью своих статей СУБО следят сами, а команда Помощи отвечает за подготовку и публикацию.<\/p>\n

    Процесс добавления новой статьи выглядел так:<\/p>\n

      \n
    1. В СУБО назначали ответственного за процесс и обновляли макеты.<\/li>\n
    2. Ответственный заполнял бриф на новую статью<\/a>, в котором указывал тему, полезное действие, примерный план, ссылки на макеты и документацию.<\/li>\n
    3. Я принимал заявку, изучал материалы и предметную область, задавал вопросы аналитикам и дизайнерам, просил показать продукт в работе.<\/li>\n
    4. Собрав всю фактуру, я писал черновик и готовил иллюстрации по макетам.<\/li>\n
    5. Ответственный вычитывал и комментировал черновик, я дописывал нужное, и всё повторялось, пока статья не была готова.<\/li>\n
    6. Согласованную статью я добавлял в админку, помечал готовой к публикации и закрывал задачу.<\/li>\n<\/ol>\n

      Чтобы изменить уже опубликованную статью, ответственный просто правил копию исходника и передавал мне. А чтобы не тонуть в бюрократии, мелкие правки мы вносили без задачи в Джире, просто по переписке в мессенджере.<\/p>\n

      Задачи шли потоком, мы постоянно что-то правили, обновляли, поддерживали порядок и готовили пачки новых статей к релизам. Отслеживать всё в Джире не получалось, поэтому я завёл редакционный дашборд в Трелло.<\/p>\n

      \n\"\"\n
      Объём задачи в карточке мог быть любым, от мелкой правки до десятка статей<\/div>\n<\/div>\n

      Карточка с задачами типичного релиза выглядела так:<\/p>\n

      \n\"\"\n
      Обновляем 77 статей: добавляем новые, объединяем старые, правим опечатки, заменяем иллюстрации со старым интерфейсом<\/div>\n<\/div>\n

      Итоги<\/h2>\n

      Настроив процессы, мы занялись обычной текучкой: писали новые статьи, обновляли старые, изучали обратную связь от пользователей и операторов горячей линии, следили за обращениями в поддержку и метриками сервиса.<\/p>\n

      Наша команда занималась и другими внутренними сервисами, поэтому мы смогли включить статьи Помощи в глобальный поиск, базу знаний поддержки, чат-бота и контекстную справку в интерфейсе. Нашему руководителю Александру удалось совершить дипломатическое чудо и отвязать публикацию статей от общего релизного цикла, и мы стали обновлять статьи по мере изменений в продуктах, без очередей и предрелизной спешки.<\/p>\n

      Но статей становилось всё больше, а задач на UX-редактуру не прибавлялось, так что я решил заняться Умным домом в МТС. А чтобы проект было легче передать, собрал материалы, записал скринкасты с основными процессами и составил вакансию редактора Помощи<\/a>.<\/p>\n

      К сожалению, вскоре в компании изменилась политика информационной безопасности, внешние облачные сервисы запретили и отбить гугл-доки не удалось. Исходники статей переехали в корпоративную вики, и процессы вновь пришлось менять.<\/p>\n

      Благодарности<\/h2>\n

      Спасибо команде Помощи за понимание, поддержку и вовлечённость. Вы с готовностью вникали во все мои идеи, хоть иногда я не особо выбирал выражения. С вами я получил бесценный опыт — как быть частью команды и находить продуктивное решение.<\/p>\n

      «Хороших выходных. И ведите себя плохо!» ©<\/p>\n", "date_published": "2026-03-23T11:51:11+05:00", "date_modified": "2026-05-06T17:22:18+05:00", "image": "https:\/\/vitalyfilatov.ru\/pictures\/091-pivot-table@2x.png", "_date_published_rfc2822": "Mon, 23 Mar 2026 11:51:11 +0500", "_rss_guid_is_permalink": "false", "_rss_guid": "103", "_e2_data": { "is_favourite": false, "links_required": [ "system\/library\/jquery\/jquery.js", "system\/library\/fotorama\/fotorama.css", "system\/library\/fotorama\/fotorama.js" ], "og_images": [ "https:\/\/vitalyfilatov.ru\/pictures\/091-pivot-table@2x.png", "https:\/\/vitalyfilatov.ru\/pictures\/091-comments@2x.png", "https:\/\/vitalyfilatov.ru\/pictures\/091-tinypng@2x.png", "https:\/\/vitalyfilatov.ru\/pictures\/091-obsidian@2x.png", "https:\/\/vitalyfilatov.ru\/pictures\/091-editor-nodes@2x.png", "https:\/\/vitalyfilatov.ru\/pictures\/091-editor-html@2x.png", "https:\/\/vitalyfilatov.ru\/pictures\/091-trello-dashboard@2x.png", "https:\/\/vitalyfilatov.ru\/pictures\/091-trello-release@2x.png" ] } }, { "id": "101", "url": "https:\/\/vitalyfilatov.ru\/all\/regex-notes\/", "title": "Делаем сноски на HTML регулярками", "content_html": "

      Регулярные выражения — мощный инструмент поиска и замены фрагментов текста. Редактору полезно ими владеть, чтобы при случае не менять что-то руками, а один раз написать умный шаблон. Синтаксис регулярных выражений подробно описан в интернете, поэтому мы сразу перейдём к примеру.<\/p>\n

      В статье про нейронные сети<\/a> у меня набралось десять примечаний, которые я решил оформить ссылками, как в Википедии: знак сноски в верхнем регистре со ссылкой на примечание и примечание в конце статьи со ссылкой на сноску.<\/p>\n

      \n

      Было бы лучше, если бы примечание вплывало при наведении на знак сноски, как в Обсидиане, но Эгея не поддерживает сноски вообще. Чтобы не лезть в код движка, я делаю их на чистом HTML, без JS и прочих хитростей<\/p>\n<\/blockquote>\n

      Текст статьи жил в Обсидиане, поэтому ссылки и сноски оформлены в маркдауне:<\/p>\n

      Текст со сноской[^1]\r\n...\r\n[^1]: Текст примечания на отдельной строке<\/code><\/pre>
      Эти штуки в скобочках предстояло превратить в HTML:<\/p>\n
      Текст со сноской <sup><a href="all\/ai-talks\/#t1" name="n1">[1]<\/a><\/sup>\r\n...\r\n<a name="t1"><\/a>\r\n1. Текст примечания <a href="all\/ai-talks\/#n1">↩︎<\/a><\/code><\/pre>
      Клик на знак сноски прокручивает страницу до тега <А> с именем «t1», а клик по стрелке — на тег <А> с именем «n1». Из-за особенностей движка в адрес ссылки «href=» приходится добавлять часть адреса страницы. Ссылка-якорь с именем примечания стоит на отдельной строке, чтобы окно браузера прокручивалось ровно до начала абзаца.<\/p>\n
      Чтобы пройтись по всему тексту и поменять маркдаун на HTML, нужно найти повторяющиеся фрагменты и написать на их основе шаблоны поиска и замены. Фрагменты у нас такие:<\/p>\n
      [^n] — знак сноски в сплошном тексте\r\n[^n]: Какой-то текст — примечание на отдельной строке<\/code><\/pre>
      Начнём со строки поиска знака сноски.<\/p>\n
      n — порядковый номер примечания, всего их десять. Значит, нам нужна регулярка, которая будет искать какое-то число от 1 до 10 в квадратных скобках c ^ в любом месте текста. Получится так:<\/p>\n
      \\[\\^(\\d{1,2})\\](?!:)<\/code><\/pre>
      Квадратные скобки и ^ — служебные символы, поэтому добавляем перед ними обратный слеш. А перед d — чтобы искать не саму букву, а символ любой цифры. В фигурных скобках указываем, что ищем 1 или 2 цифры. Круглые скобки сохраняют фрагмент строки в переменную — скобочную группу. В конце идёт указание, что строка не должна заканчиваться двоеточием. Это не совсем корректно, ведь знак сноски может стоять где угодно. Но для примера нужна регулярка попроще, так что просто убедимся, что в тексте такого нет.<\/p>\n
      Теперь напишем строку замены:<\/p>\n
      &thinsp;<sup><a href="all\/ai-talks\/#t$1" name="n$1">[$1]<\/a><\/sup><\/code><\/pre>
      Перед знаком ставим &thinsp; — HTML-код тонкого пробела, чтобы знак сноски не слеплялся со словом слева. $1 — переменная, в которой будет число из знака сноски, от 1 до 10. Единица после $ означает порядковый номер скобочной группы. В этой регулярке она одна, но для обработки примечаний нам потребуются уже две.<\/p>\n
      Теперь скопируем текст статьи из Обсидиана в Sublime text, откроем режим поиска и замены (Ctrl + H), включим регулярные выражения (Alt + R) и выполним первый набор регулярок.<\/p>\n
      \n
      \n\"\"\n\"\"\n<\/div>\n
      Найденные регуляркой фрагменты выделены рамкой<\/div>\n<\/div>\n
      Теперь сами примечания. Найдём их в тексте:<\/p>\n
      \\[\\^(\\d{1,2})\\]: (.+?)\\n<\/code><\/pre>
      Первую часть вы уже видели, но теперь мы не исключаем двоеточие. Потом идёт любой текст. Точка означает «любой символ, кроме переноса строки», а «+?» говорит брать символы до первого символа правее. В нашем случае это конец строки \\n.<\/p>\n
      Напишем строку замены:<\/p>\n
      <a name="t$1"><\/a>\\n$1. $2&nbsp;<a href="all\/ai-talks\/#n$1">↩︎<\/a>\\n\\n<\/code><\/pre>
      Как видите, порядковый номер сноски $1 удачно стал частью ссылок и порядковым номером примечания, а текст примечания из скобочной группы $2 вставится между номером с точкой и ссылкой на знак сноски. &nbsp; — знак неразрывного пробела, чтобы стрелка не повисала на следующей строке.<\/p>\n
      Вставим строки в редактор и выполним замену:<\/p>\n
      \n
      \n\"\"\n\"\"\n<\/div>\n
      Все сноски превратились в HTML<\/div>\n<\/div>\n
      Результат можно посмотреть в коде статьи.<\/p>\n
      Где и как учиться регуляркам<\/h2>\n
      Регулярки в JavaScript<\/a> — приятный сайт на русском<\/p>\n
      Regular-Expressions.info<\/a> — сайт про регулярки на английском<\/p>\n
      RegExr<\/a> — гибкий отладчик регулярок. Можно устанавливать разные параметры поиска (флаги), смотреть, что попадает в скобочные группы, и тестировать строку замены<\/p>\n",
            "date_published": "2025-07-18T23:14:09+05:00",
            "date_modified": "2025-07-10T00:23:50+05:00",
            "image": "https:\/\/vitalyfilatov.ru\/pictures\/090-note-before@2x.png",
            "_date_published_rfc2822": "Fri, 18 Jul 2025 23:14:09 +0500",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "101",
            "_e2_data": {
                "is_favourite": false,
                "links_required": [
                    "system\/library\/highlight\/highlight.js",
                    "system\/library\/highlight\/highlight.css",
                    "system\/library\/jquery\/jquery.js",
                    "system\/library\/fotorama\/fotorama.css",
                    "system\/library\/fotorama\/fotorama.js"
                ],
                "og_images": [
                    "https:\/\/vitalyfilatov.ru\/pictures\/090-note-before@2x.png",
                    "https:\/\/vitalyfilatov.ru\/pictures\/090-note-after@2x.png",
                    "https:\/\/vitalyfilatov.ru\/pictures\/090-text-before@2x.png",
                    "https:\/\/vitalyfilatov.ru\/pictures\/090-text-after@2x.png"
                ]
            }
        },
        {
            "id": "100",
            "url": "https:\/\/vitalyfilatov.ru\/all\/ai-talks\/",
            "title": "Как нейросети могут изменить работу UX-редактора",
            "content_html": "
      Фантазирую, как нейросети повлияют на умственный труд, работу с текстом и культуру мышления в целом.<\/p>\n
      В 2024 году мы с Никитой Чернояровым записали подкаст про нейросети<\/a>. Получилось тяжеловато и путанно, поэтому я решил всё немного додумать и выразить более связно. Ожидаемо вышла простыня, зато у вашей умной читалки будет работа. Источники и пояснения смотрите в примечаниях с пижонскими сносками.<\/p>\n
      Начнём с самого важного и объёмного, а там, глядишь, и до Сократа доберёмся.<\/p>\n
      Средний уровень мастерства снизится<\/h2>\n
      Если кратко, то, как и любая новая непонятная технология, нейронные сети стали «новым АйТи внутри АйТи». Бизнес подхватил волну хайпа и набирает «промпт-инженеров» после курсов с ВК, а полезные знания ещё сильнее размоет рерайтами. Неопытных людей в индустрии станет больше, отчего в среднем уровень навыка просядет.<\/p>\n
      Теперь подробнее. Мысль о падении навыков довольно избитая и спорная, поэтому я зайду издалека.<\/p>\n
      \n
      Далее идёт вольный пересказ интернета, поэтому можно смело читать только цитаты<\/p>\n<\/blockquote>\n
      Очевидно, что современные общедоступные нейросети на основе языковых моделей не умеют думать по-настоящему. Они не понимают смысла понятий, которыми оперируют, а знают только о силе связей между ними и угадывают следующее слово в тексте. Из-за этого у нейросетей предсказуемо плохо с суждениями о реальном мире, да и с логикой вообще [1]<\/a><\/sup>.<\/p>\n
      Нейросети хороши в другом: они быстро ищут закономерности в огромных данных, чего-нибудь генерируют по аналогии или обрабатывают по заданным правилам. Нейросети научились понимать запросы на естественном языке и прилично отвечать, но всё ещё остаются автоматами — программами, которые решают описанную задачу описанным методом. Нейросети не могут творчески выходить за границы условий задачи, как человек [2]<\/a><\/sup>.<\/p>\n
      \n
      Нейросети решают задачи только тем способом, которому их обучили, и не умеют учиться новым способам сами<\/p>\n<\/blockquote>\n
      Например, нейросеть может написать научно-популярную статью по вашим тезисам. Но сделает это она исключительно на основе своей базы связей. Эта база может быть невероятно огромна, но без функции критического анализа нейросеть не сможет найти релевантные научные исследования и сделать верные выводы. Вместо этого она соберёт ворох подходящих к тезисам цитат из популярных источников и слепит студенческий реферат.<\/p>\n
      Другой случай — описание конкретных объектов реального мира, которые нейросеть не может воспринимать напрямую и опираться на чувственный опыт. Например, описание товаров на маркетплейсах или каких-нибудь элитных квартир глазами покупателя. Без специального обучения нейросеть не догадается рассчитать время до метро по карте или превратить недостаток расположения дома в преимущество<\/a>.<\/p>\n
      Этот длинный пассаж подводит нас к выводу:<\/p>\n
      \n
      Нейросетям стоит поручать рутину — трудную или нудную работу, для которой они хорошо обучены<\/p>\n<\/blockquote>\n
      Рутина хорошо нам знакома и не учит ничему новому. Если перекладывать на нейросеть творческие задачи, мы будем ограничены её возможностями и не всегда сможем проверить и улучшить результат. Но всё это не делает нейросети плохими или опасными. Проблема, как всегда, не в технологии, а в её применении.<\/p>\n
      Бизнес подаёт чат-ботов как невероятный прорыв и немного преувеличивает их эффективность<\/i> ради роста капитализации [3]<\/a><\/sup>. В простых задачах ChatGPT действительно обеспечивает прирост качества и скорости в моменте [4]<\/a><\/sup>, но в перспективе снижает количество людей, которые захотят учиться сами. Инструмент даёт быстрое решение и вознаграждение, а мозг экономит глюкозу и не мотивирует глубоко вникать.<\/p>\n
      \n
      С умственным протезом условные джуны быстро получат приемлемый результат, но могут пропустить этап простых задач и не сформировать нужные навыки мышления [5]<\/a><\/sup><\/p>\n<\/blockquote>\n
      Например, начинающие писатели часто попадают в писательский блок<\/a>. Если не осознать, что он чаще всего возникает от нехватки понимания, можно просто привыкнуть по любому поводу генерировать черновик нейросетью, потому что некогда, а результат ждут вчера<\/i>.<\/p>\n
      Но если джун и захочет вникать, ему будет не до этого. Требования к джунам постоянно растут и усложняются, сегодня ни у кого нет времени раскачиваться на простых задачах — бизнесу нужен конвейер. Поэтому джуны вынуждены пользоваться любыми помогайками, чтобы не проиграть вайбкодерам.<\/p>\n
      Важно упомянуть и промпты:<\/p>\n
      \n
      Практика составления хитрых промптов не углубляет понимание предметной области, а развивает навык составления промптов<\/p>\n<\/blockquote>\n
      Похожим образом регулярное прохождение тестов на IQ повышает именно навык, а не сам IQ [6]<\/a><\/sup>.<\/p>\n
      Другой аспект — упрощение знаний, которое следует из особенностей производства массового контента. Смотрите выше про научно-популярную статью. Не буду нагнетать, просто попробуйте найти в статьях по UX точное определение этого самого UX [7]<\/a><\/sup>.<\/p>\n
      \n
      Знания утонут в поверхностных пересказах без источников и проверки фактов, учиться станет сложнее. Особенно если генерить учебные планы нейросетью [8]<\/a><\/sup><\/p>\n<\/blockquote>\n
      Но не всё так плохо. Те, кому будет интересно, прочтут нужные книги, вникнут в суть ремесла и получат преимущество. Покупайте мой курс<\/del> Главное, чтобы нашлись работодатели, которым нужна экспертиза, а не тысяча итераций дизайна в неделю.<\/p>\n
      Специалисты останутся востребованы<\/h2>\n
      Бизнес может заменить специалиста чат-ботом, но чат-бот специалиста не заменит. Например, вот из чего складывается моя рутина UX-редактора:<\/p>\n
        \n
      1. Взять задачу, изучить постановку на языке аналитиков. Попросить их добавить ссылки на макеты и документацию;<\/li>\n
      2. Выяснить, что документации нет, а все макеты у дизайнера, который в отпуске;<\/li>\n
      3. Найти коллегу дизайнера, который был на проекте раньше, и через него выйти на нужный файл с макетами;<\/li>\n
      4. По косвенным признакам вычислить нужные макеты среди кучи версий без статусов и дат актуальности. Попутно получить от продакта результаты UX-исследований, которые нужны в задаче;<\/li>\n
      5. По макетам и инструкции в Справочном центре собрать модель процесса, увидеть в нём корнер-кейсы, уточнить их у продакта на звонке и передоговориться о сроках. Заодно убедить продакта вынести часть объяснений в инструкцию;<\/li>\n
      6. Посмотреть результаты исследований, понять, что они получены по другим макетам, и перенести часть выводов на сценарий из задачи;<\/li>\n
      7. Переложить продуктовый смысл на ситуацию пользователя и написать текст<\/i>. Сразу в макетах, учитывая уже написанное, редполитику и словарь продукта, который сами редакторы и ведут;<\/li>\n
      8. Собрать свою версию экрана из компонентов дизайн-системы и объяснить продакту, что для неё не нужно переписывать API. Заодно рассказать, почему типографика важна и её нужно делать хорошо;<\/li>\n
      9. Пройти кросс-ревью у коллеги и выяснить, что у некоторых терминов из текста обнаружились новые значения. Поправить текст;<\/i><\/li>\n
      10. Дополнить словарь, пока не забыл. Оповестить всех, кто с ним работает по редакционному регламенту. Дописать кусочек регламента;<\/li>\n
      11. Убедить юристов в том, что мы меняем их формулировки не из прихоти художника, а с чёткими целями и по методу с научной основой;<\/li>\n
      12. Получить комментарии от продакта, придумать новое решение и переписать текст<\/i> в макетах ещё раз.<\/li>\n<\/ol>\n
        Конечно, всё это можно делегировать нейросети, но всё равно потребуется кто-то, кто её обучит и проследит, чтобы она не бредила в незнакомых ситуациях. А кто сможет это сделать, если сам не разбирается?<\/p>\n
        Пользуясь случаем, просьба ко всем аналитикам, продактам и дизайнерам:<\/p>\n
        \n
        Дорогой друг! Не пиши текст в макетах нейросеткой, это только добавит всем работы: редактор ничего не поймёт и всё равно задаст тысячу вопросов, а потом всё переделает. Пиши своими словами, что должен понять и сделать пользователь на каждом шаге сценария<\/p>\n<\/blockquote>\n
        Обратите внимание, в списке выше собственно работы с текстом<\/i> набралось три эпизода. Очевидно, один только ChatGPT мою рутину не упростит [9]<\/a><\/sup>. Нужен обучаемый ИИ-ассистент, понимающий контекст и умеющий интегрироваться с рабочими сервисами: вики, сервисом локализации, Джирой и Фигмой.<\/p>\n
        В идеале такой ассистент помогал бы мне следить за логикой изложения и единообразием терминов, вовремя обновлять словари, собирать текст по макетам в коллекции формулировок и вовремя подсвечивать отклонения от редполитики и ToV. Это сэкономило бы много времени и внимания, чтобы я, наконец, занялся какой-нибудь стратегией и исследованиями.<\/p>\n
        Умные инструменты сделают работу интереснее<\/h2>\n
        Античный философ Сократ был противником популяризации письменности. Он считал, что без запоминания всех нужных знаний и обучения в диалоге греческая молодёжь утратит самостоятельность суждений. Но Сократ оказался прав не во всём — письменность освободила значительные когнитивные ресурсы и помогла мыслить глубже [10]<\/a><\/sup>.<\/p>\n
        Доступные и гибкие ассистенты могут помочь нам с очередным скачком в мышлении за счёт его более эффективной организации. Сначала вы просто читаете всё подряд, потом собираете библиотеку и делаете заметки, после заводите хитрую картотеку, как у Никласа Лумана<\/a>, а в итоге загружаете всё в ИИ-помощника и настраиваете его под свои задачи.<\/p>\n
        Благодаря машинному анализу накопленных знаний вдумчивый человек сможет вновь стать философом — неторопливо и глубоко размышлять на стыке дисциплин и задавать креативные вопросы, выводящие мышление за рамки привычных моделей.<\/p>\n
        Конечно, при условии, что пока появятся такие инструменты, мы не разучимся сосредотачиваться дольше 30 секунд, а на Земле не закончится электричество. Но его пока хватает, а вы дочитали до конца.<\/p>\n
        Примечания<\/h2>\n
        Прошу прощения за архаичную вёрстку примечаний, но движок блога не предусматривает сноски, а дописывать его я не потяну. Поэтому переход по сноске перекидывает вас из ленты в статью.<\/p>\n
        <\/a><\/p>\n
          \n
        1. Тут я слукавил для драматизма. Нейросети строят логические выводы, но не на суждениях, а на предсказательных способностях. Последние итерации показывают приличные результаты, и в индустрии нет единого мнения по этому вопросу. Смотрите отчёт Apple от 2025 года The Illusion of Thinking<\/a>. А в 2023 выходила статья Санджива Ароры и Анирудха Гояла про успешный тест на генерацию осмысленного текста<\/a>. ↩︎<\/a><\/li>\n<\/ol>\n
          <\/a><\/p>\n
            \n
          1. Психологи считают, что творчество — это когнитивная деятельность, приводящая к новому или необычному видению проблемы или ситуации. Постоянное использование одного инструмента вырабатывает функциональную устойчивость, которая ограничивает креативность. Роберт Солсо, Когнитивная психология. 8-е изд., стр. 540 и 543.<\/i> ↩︎<\/a><\/li>\n<\/ol>\n
            <\/a><\/p>\n
              \n
            1. Например, Сэм Альтман в эссе о мягкой сингулярности<\/a> говорит, что искусственный сверхразум появится совсем скоро, нужно только подождать. Как Метавселенную экстремиста Цукерберга и Марсианский экспресс Илона Маска (он условно рукопожатный). ↩︎<\/a><\/li>\n<\/ol>\n
              <\/a><\/p>\n
                \n
              1. Статья в MIT Economics<\/a> от 2023 года. Результаты исследования 444 человек показывают, что ChatGPT существенно повышает среднюю производительность работников с низкими способностями. ↩︎<\/a><\/li>\n<\/ol>\n
                <\/a><\/p>\n
                  \n
                1. В ходе практики эксперты учатся распознавать специфические паттерны и организуют знания с точки зрения общих принципов, а не поверхностных характеристик. Солсо, стр. 347 и 567.<\/i> ↩︎<\/a><\/li>\n<\/ol>\n
                  <\/a><\/p>\n
                    \n
                  1. У меня нет прямых подтверждений именно этого факта, но есть косвенные. Во-первых, некоторые учёные не наблюдают эффект переноса<\/a>. Во-вторых, исследования карт мозга показывают, что уроки музыки не обеспечивают ребёнка более качественным мозгом. Часы практики создают мозг, более подготовленный для игры на фортепиано. Ребекка Шварцлоуз, Ландшафты мозга, стр. 172.<\/i> В-третьих, исследования профи по тетрису показывают, что они хорошо крутят в уме только фигуры из тетриса. Солсо, стр. 387—388.<\/i> ↩︎<\/a><\/li>\n<\/ol>\n
                    <\/a><\/p>\n
                      \n
                    1. В лучшем случае вы встретите упоминание определения по ISO 9241-210<\/a>, но мало кто упоминает коллекцию определений EXPRESSO<\/a>. Впрочем, мне встречалось мнение, что точные определения не так уж и нужны в работе. ↩︎<\/a><\/li>\n<\/ol>\n
                      <\/a><\/p>\n
                        \n
                      1. Вполне вероятно, что нейросеть проигнорирует редко упоминаемые важные источники, например, сайт NN\/g<\/a> или Советы Бюро Горбунова<\/a>. ↩︎<\/a><\/li>\n<\/ol>\n
                        <\/a><\/p>\n
                          \n
                        1. Но это я. Владимир Лалош как-то рассказывал, что ChatGPT ему хорошо помогает<\/a>. ↩︎<\/a><\/li>\n<\/ol>\n
                          <\/a><\/p>\n
                            \n
                          1. Если Платон только записывал за Сократом, то Аристотель уже не мыслил себя без чтения. Марианна Вульф, Бесконечная история чтения, стр. 98—100 и 104—116.<\/i> ↩︎<\/a><\/li>\n<\/ol>\n
                            Благодарности<\/h2>\n
                            Никита Чернояров позвал меня на подкаст, задавал направление беседе и помог собрать всё в кучу.<\/p>\n
                            Юлия Ушакова помогла свежим взглядом и острым умом.<\/p>\n
                            К. Д. проверил самые важные тезисы на прочность, помог избавиться от лишнего и рассказал о нелёгкой доле современных джунов.<\/p>\n",
            "date_published": "2025-07-07T23:01:03+05:00",
            "date_modified": "2026-06-15T14:13:01+05:00",
            "_date_published_rfc2822": "Mon, 07 Jul 2025 23:01:03 +0500",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "100",
            "_e2_data": {
                "is_favourite": true,
                "links_required": [],
                "og_images": []
            }
        },
        {
            "id": "98",
            "url": "https:\/\/vitalyfilatov.ru\/all\/ideal-id\/",
            "title": "Кейс с совпадающими номерами",
            "content_html": "
                            История про совпадения в номерах стикеров и понимание коммуникационной задачи. И почему нельзя просто так взять и сделать правильно<\/i>.<\/p>\n
                            Рабочие макеты под NDA, поэтому в этот раз только текстом.<\/p>\n
                            Ситуация<\/h2>\n
                            Пользователю нужно подготовить поставку в пункт выдачи: пройтись по своему складу, собрать товары по списку, наклеить на них стикеры с уникальными номерами, упаковать и отвезти.<\/p>\n
                            Чтобы человеку было удобно, разработчики придумали интерактивный чек-лист с нужными товарами и номерами стикеров. Абстрактно список выглядит так:<\/p>\n
                            \n
                            1245642 9258<\/b>
                            \n9008731 9685<\/b>
                            \n5748202 4973<\/b>
                            \n4505331 9685<\/b>
                            \n2356911 6736<\/b><\/p>\n<\/blockquote>\n
                            Там ещё есть чекбоксы, фотки и названия товаров, но про макеты я уже говорил, просто представьте, что они там есть. Четыре последних цифры выделены — пользователям удобно по ним ориентироваться.<\/p>\n
                            Фишка в том, что эти «хвосты» в большинстве случаев уникальны, но иногда совпадают у разных номеров, как в примере выше. И это проблема: пользователь может спутать, наклеить не тот стикер, и товар не примут.<\/p>\n
                            Чтобы обратить внимание пользователя на совпадающие хвосты, команда решает подсветить их цветной плашкой и написать про это в справке к разделу. Наша задача — составить текст, не влезая в уже готовый дизайн.<\/p>\n
                            Формальное решение<\/h2>\n
                            Сперва напишем, что просят, а потом будем рассуждать про дизайн, визуальную коммуникацию и основы когнитивной психологии.<\/p>\n
                            \n
                            Похожие стикеры подсвечиваются<\/b>
                            \nКогда у разных стикеров совпадают последние 4 цифры, мы выделяем их цветом. Если встретили такой, обратите внимание на его полный номер<\/p>\n<\/blockquote>\n
                            Теперь можно сформулировать коммуникационную задачу<\/i> и начать думать. Задача коммуникации простая:<\/p>\n
                            \n
                            Обратить внимание пользователя на разные номера с одинаковыми «хвостами» и помочь не спутать стикеры<\/p>\n<\/blockquote>\n
                            Очевидно, что в контексте задачи выделять «хвосты» цветом — плохое решение: мы привлекаем внимание к какому-то искусственному признаку, а не к важному. Как чиновники, когда подсвечивают знак пешеходного перехода вместо самого пешехода (смотри бессмертную заметку Лебедева<\/a>).<\/p>\n
                            Мало того. Мы привлекаем внимание к общей части различающихся сущностей, что помогает мало. Перефразируя один из гештальт-принципов, можно сказать, что похожие сущности воспринимаются, как связанные по смыслу<\/i>. А нам нужно сделать акцент на их различии. Для этого можно выделить различающиеся части проблемных номеров:<\/p>\n
                            \n
                            1245642 9258<\/b>
                            \n9008731<\/b> 9685
                            \n5748202 4973<\/b>
                            \n4505331<\/b> 9685
                            \n2356911 6736<\/b><\/p>\n<\/blockquote>\n
                            Выглядит так себе, но задачу решает.<\/p>\n
                            Можно оставить выделение цветом, но дополнительно его усилить каким-нибудь сигналом. Например, значком:<\/p>\n
                            \n
                            9008731 9685<\/b><\/mark> ⚠
                            \n5748202 4973<\/b>
                            \n4505331 9685<\/b><\/mark> ⚠<\/p>\n<\/blockquote>\n
                            Спорно, конечно, но хорошее визуальное решение найдёт дизайнер, нам важнее показать общий принцип.<\/p>\n
                            Системное решение<\/h2>\n
                            Всё по ТРИЗ: масштабно и безответственно. Изменить алгоритм генерации номера, чтобы исключить возможность путаницы. Например, генерировать номер так, чтобы в одной поставке не было одинаковых «хвостов».<\/p>\n
                            А ещё лучше — генерировать номер на основе системного ID пользователя и даты сбора поставки с исключением номеров, совпадающих в последних 4 цифрах. Если вдруг не хватит разрядности, можно увеличить длину номера или перейти на шестнадцатеричную систему счисления, где вариантов будет примерно в шесть раз больше.<\/p>\n
                            \n
                            0000—9999 — 10 000 вариантов, 10 в 4 степени
                            \n0000—FFFF — 65 536 вариантов, 16 в 4 степени<\/p>\n<\/blockquote>\n
                            Но решение с уникальной генерацией реализуемо только в принципе. Номерами, чек-листом и печатью стикеров заведуют разные команды. У каждой — свои приоритеты, ресурсы и горящие задачи. Никто просто не сможет протащить через владельца и скоординировать такое крупное изменение. В компаниях обычно просто нет продактов, которые таким занимаются. А у имеющихся зона ответственности и интересов ограничена задачами их команды.<\/p>\n
                            Стоит добавить, что про «правильную» генерацию наверняка уже кто-то думал, но столкнулся с таким ворохом трудностей и зависимостей в реализации, который с лихвой перекрыл ожидаемую выгоду. Но мы не узнаем наверняка: на большинстве проектов не ведут поисковую<\/del> документацию.<\/p>\n
                            UPD. Статье нужен какой-нибудь афористичный вывод, так что вот он: продукт нужно проектировать до того, как он начнёт приносить прибыль. Потом уже будет не до этого.<\/p>\n",
            "date_published": "2025-06-19T22:06:29+05:00",
            "date_modified": "2025-06-19T22:46:06+05:00",
            "_date_published_rfc2822": "Thu, 19 Jun 2025 22:06:29 +0500",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "98",
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": []
            }
        },
        {
            "id": "97",
            "url": "https:\/\/vitalyfilatov.ru\/all\/quasi-skill\/",
            "title": "Как придумать оригинальный софт-скилл",
            "content_html": "
                            Придумывание ещё не изжёванных универсальных навыков для блогов бизнес-коучей — актуальная проблема современного интернета. В этой заметке мы разберём доступный способ решения этой задачи минимальными средствами.<\/p>\n
                            Способ похож на описанный ранее в советах начинающим фантастам<\/a>, но построен на более академичном подходе и новейших открытиях когнитивной психологии.<\/p>\n
                            Сначала составим интуитивно понятный термин, смысл которого будет угадываться без точного определения. Для этого мы построим термин на сочетании известного и смутного.<\/p>\n
                            \n
                            Такой подход позволит читателю ощутить удовольствие от узнавания и активизирует его центры любопытства.<\/p>\n<\/blockquote>\n
                            База термина будет существительным, означающим что-то хорошо известное. Например, мышление — понятие из психологии, с которым читатель наверняка сталкивается постоянно.<\/p>\n
                            Для второй части возьмём понятие более размытое, суть которого читатель должен улавливать смутно. Подойдёт любое относительное прилагательное, которое описывает признак предмета через его отношение к другому предмету и отвечает на вопрос «какое?»<\/p>\n
                            В нашем случае мышление может быть:<\/p>\n