Контент и копирайтинг *

Контент Claude теперь помечен. И это не новость про списывающих студентов

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

Что сделали:

— причина - кодекс прозрачности в рамках EU AI Act, вступил в силу 2 августа. Требует помечать сгенерированный или отредактированный ИИ контент так, чтобы метку читали другие системы. Подписанты не только Anthropic.
— все модели, вышедшие после 2 августа, метят и текст, и файлы. Для файлов — открытый стандарт C2PA.
— метка ставится на уровне модели. То есть она есть везде, откуда бы текст ни вышел: API, чат, Claude Code, Cowork, Tag.
— метка едет вместе с текстом при копировании и, по формулировке справки, может пережить часть правок. Сколько правок её снимают не уточняется.
— на старые модели поддержку обещают дораскатить.

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

Что меняется у редакции

Предупреждать, что вы генерируете с помощью ИИ перестало быть вашим решением. Раньше «говорить ли заказчику, что черновик собрал агент» было вопросом договорённостей и совести. Теперь это свойство файла. Вопрос только в том, узнает заказчик об этом от вас или без вас.

Стилевые детекторы съезжают на второй план. Я рассказывал про свой слой проверок на GitHub Actions — там среди прочего скрипт считает плотность тире и ищет следы машинного текста. Это эвристика, она угадывает по стилю. Метка не угадывает, она в источнике. Значит, такие детекторы перестают быть ответом на вопрос «писал ли это ИИ» и остаются тем, чем и должны быть, — проверкой качества, а не происхождения.

Асимметрия, которую легко упустить. Наличие метки — сильное свидетельство. Отсутствие не значит ничего: метят не все и не везде, старые модели дораскатывают, локальные модели никто не обязывает. Любая проверка сотрудников или студентов «на ИИ» по этому принципу будет ловить одних и пропускать других. Строить такие процедуры начнут уже осенью, а границы у метки пока нет.

И к тому, о чём уже писал

В манифесте контент-опса у меня стояла строчка: ответственность за выпущенное важнее скорости выпуска. Тогда это была позиция. Теперь у неё появился технический носитель — происхождение едет вместе с текстом и доезжает до читателя.

А ещё я обещал развернуть content sec ops. Вот его первый слой, и он не про доступы агента к базе знаний, а про провенанс: знаем ли мы, что именно в материале сгенерировано, зафиксировано ли это где-то помимо головы редактора, и что мы отвечаем, когда спросят. Редакция с логом пайплайна ответит за минуту. Таких пока мало.

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

Раньше вышло в канале.

Как выбрать PR- агентство для работы с международным рынком?

Бюджет — $50k на пять месяцев, но cливать их на ежемесячный ретейнер я не планирую. 

Я серийный предприниматель и наверное очень плохой потенциальный заказчик :)

Ранее я не использовал PR в проектах, но опыт в бизнесе какой-то имеется - 3 экзита, $5,5M привлеченных инвестиций, клиенты В России: Яндекс , Фонбет, Тинькофф, Сбер, МДМ, Тануки, Чайхона 1 и тд
Зарубежные: (18 стран) Disney, Citi, Honda, Vivo, Telcel, P&G, Bayer, Toyota

Плохо понимаю, на какие критерии ориентироваться, как ставить задачу/ как понимать эффективность работы подрядчика.

Мы строим AI-native компанию https://mastgroup.it.com на международном рынке

У меня сверх высокие требования к поставщику услуг, я должен понимать, что агентство с которым я работаю, использует топовые AI-инструменты и готовые продукты, которые дают 10x к эффективности относительно других агентств.

Цель - привлечение внимание фондов и потенциальных партнеров к тому, как компания использует Ai- native принципы за счет которых захватывает рынок. 

Мы должны стать одним из самых узнаваемых брендов в контексте Рекламные технологии/AI-native

Есть идеи:

• использовать в коммуникациях только AI- аватар основателя, который будет давать интервью на нескольких языках.

• Публиковать уникальную аналитика по рынку, собранную AI- агентами

• Публиковать кейсы работы уникального продукта, который представляет собой AI-агента, который устанавливается на сайт клиента/партнера и делает за него всю необходимую работу, чтобы клиент начал зарабатывать на 30-70% больше

Как я отказался от HR в компании

Мне нужно было найти 2 спеца - SEO и контент-менеджера, сайт на Битриксе. Отправил HR требования и условия, работа удаленная. Неделя прошла, спрашиваю - все не подходят. На второй неделе не выдержал, спросил какого хрена где резюме. В итоге забрал на себя и за 2 дня нанял в команду спецов.

Иногда HR только мешают своими бестолковыми подборами и созданием видимости работы. И да, когда я открыл сам все отклики я офигел от количества отказов толковым спецам. На вопрос почему столько отказов и почему у меня не спрашивали, внятного ответа так и не получил. На тот момент я работал руководителем отдела трафика в компании.

Наговорить бессвязно — рабочий приём, а не лень

Андрей Карпатый, который в 2026 перешёл в Anthropic в команду претрейна, описал приём из собственной практики. Когда модели не хватает контекста, а печатать лень, он переключается на голосовой ввод и минут десять говорит потоком сознания — без структуры, как выйдет. Смысл не в экономии времени: модели неплохо собирают связное из бессвязного, и пересказ ваших путаных мыслей возвращается к вам чище оригинала.

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

Но переносить этот приём на редакцию я бы не спешил, и вот почему.

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

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

Отдельно про цену. Десять минут речи — это довольно большой кусок текста и примерно две тысячи токенов, и он остаётся в переписке до конца сессии. Каждый следующий ваш вопрос модель читает вместе с ним заново: к двадцатой реплике вы оплатили эти десять минут двадцать раз. Но дороже не деньги, а место. Окно контекста не резиновое, и ваши оговорки лежат в нём рядом с правилами канала. Чем длиннее разговор, тем охотнее модель цепляется за случайную фразу из потока вместо инструкции в скилле. В агентском пайплайне это ещё умножается на каждый шаг цикла.

Отсюда рабочая рамка. Наговаривать — в отдельной сессии, забирать оттуда только сборку, ужимать её руками и приносить в работу абзацем, который вы прочли и одобрили. Проверять при этом не то, что модель оставила, а то, что она выбросила. Ценность приёма не в готовом брифе, а в том, что он вытаскивает из вас причины, которые вы не стали бы печатать. Собеседником модель тут работает отлично. Автором задачи — нет.

В канале вышло ещё днём.

Ваши скиллы возможно написаны под модель, которой уже нет

Anthropic удалила больше 80% системного промпта из Claude Code, и качество на их тестах не упало. Пересказывать статью не буду, интереснее, что из этого следует, если вы сами пишете агентов и скиллы.

1. Половина ваших правил — заплатки на провалы прошлых версий. «Не начинай с общих фраз», «не используй конструкцию X» — вы это добавляли, потому что модель так делала. Перестала делать, и правило работает вхолостую, а иногда против вас: запрет отнимает у сильной модели право решать по ситуации. Что сделать: пройти по скиллам и рядом с каждым правилом поставить дату и ошибку, из-за которой оно появилось. Где ошибку не вспомнить или ей больше полугода — кандидат на удаление.

2. Резать вслепую нельзя, а мерить нечем. У Anthropic были свои прогоны: удалили кусок промпта, прогнали набор задач, сравнили результат. Поэтому они и могли уверенно сказать «сняли 80%, качество то же». У нас так не выходит. Меняем скилл, смотрим на два поста и решаем, что стало лучше. А на третьем оказывается, что модель перестала расставлять ссылки, просто в первых двух ссылок и не было.

3. Конфликтуют не правила, а источники правил. Редстандарт, скилл канала, CLAUDE.md, бриф — четыре места, где написано про тон. Модель разгребает противоречие вместо работы. Решение не в сокращении, а в иерархии: тон и позиция живут только в скилле канала, фактура и грабли — только в CLAUDE.md, задача выпуска — только в брифе. Правило встретилось дважды — одно вхождение удаляется, а не уточняется.

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

5. Архитектура скиллов важнее их содержания. Один SKILL.md на девятьсот строк грузится целиком: пишете пост в телеграм — модель попутно читает правила для лендингов. Лишнее разбавляет нужное, а трогать такой файл страшно, поэтому его проще дополнить, чем разобрать. Разложите по уровням: верхний решает, что за задача и куда идти дальше; профиль канала держит тон и рубрикатор только для себя; редкие рубрики подгружаются по надобности. Тогда правки перестают быть страшными: меняете один канал и точно знаете, что остальные не задели.

Что переносится на другие модели

Не переносится цифра. 80% — результат конкретной связки: их обвязка, их модели, их тесты на коде. Для GPT, Gemini или локальных моделей такого замера у вас нет.

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

Не переносятся архитектурные приёмы. Прогрессивное раскрытие, отложенная загрузка инструментов, автопамять — это свойства обвязки, а не модели. В чужом фреймворке эквивалента может не быть, и тогда «вынесите редкое в отдельный скилл» превращается в «вынесите в файл, который никто не подгрузит».

И главное

Спор о длине промптов маскирует настоящую проблему: у нас нет способа отличить улучшение от ухудшения. Пока его нет, любое решение — резать или не резать — принимается на ощущениях. Вопрос не в том, сколько правил у вас в скиллах, а в том, знаете ли вы, какие из них хоть на что-то влияют. А это уже content ops. 😎

Раньше в канале.

Про арендованные протезы и ИИ-аугментации

Я постоянно использую ИИ в своих разработках: обсуждаю архитектуру, ищу ошибки, проверяю идеи, пишу сценарии и ускоряю производство видео.

И недавно поймал себя на одной мысли.

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

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

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

Одно помогает сохранить прежнего себя. Другое — неизбежно тебя изменяет.

Но у любого расширения есть обратная сторона.

С новым инструментом ты можешь больше. Однако без него постепенно начинаешь хуже ощущать собственные границы.

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

ИИ-агенты расширят нас ещё сильнее. Они смогут не только хранить и показывать информацию, но и анализировать её, выбирать варианты и совершать действия от нашего имени.

И здесь возникает важный вопрос: сохраняем ли мы при этом способность самостоятельно думать, выбирать и отказываться от предложенного?

Пока инструмент расширяет тебя — это аугментация.
Когда без него ты уже не можешь оставаться собой — он становится протезом.

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

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

Этот вопрос важен ещё и потому, что своими цифровыми аугментациями мы, как правило, не владеем.

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

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

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

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

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

Так мы действительно расширили себя — или просто арендовали себе протез?

Эту же мысль я собрал в короткий анимационный выпуск.
Видеоверсия длится около минуты и доступна по ссылке.

P.S. Прошлый выпуск и история создания моего аватара

11,5 миллионов в месяц за управление знаниями: мечта или реальность?

Продолжаю разбирать вакансии, связанные с управлением знаниями и технической документацией. Сегодня смотрим позицию LMS/База знаний координатора в международной компании Union Staff.

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

Зарплата, конечно же, указана не в рублях, а в узбекских сумах. Но, согласитесь, интерес вызывает?

Дисклеймер. Я больше 15 лет внедряю менеджмент знаний в российских компаниях. Запустил эти разборы, чтобы работодатели могли увидеть спорные места в вакансиях, а специалисты – точнее оценить задачи и подготовиться к собеседованию. Анализирую только опубликованные тексты вакансий, а не реальные процессы внутри компаний.

Начну с плюсов

Вакансия описана на языке профильных специалистов. В ней прямо упоминаются база знаний, Knowledge Management и распространённые платформы: Confluence, Notion, SharePoint и другие. Это помогает опытному кандидату быстро понять, с чем предстоит работать.

Требования к опыту выглядят адекватно. Достаточно опыта работы с LMS, базами знаний или корпоративными порталами. От кандидата не требуют десяти лет в Knowledge Management и экспертного владения всеми перечисленными системами одновременно.

Компания международная, предполагается участие в развитии новых направлений. Это может заинтересовать кандидатов, для которых важен масштаб проектов. 

Дальше начинаются вопросы

Первый – роль размыта. В одной вакансии смешаны обязанности менеджера по управлению знаниями и специалиста по обучению. Контроль прохождения курсов и администрирование LMS скорее относятся к L&D, чем к Knowledge Management. 

Эта неопределённость влияет на отклики. Специалист по управлению знаниями может решить, что вакансия в основном про обучение. Кандидат из L&D, наоборот, может недооценить объём работы с базой знаний.

Второй – недостаточно раскрыта работа с базой знаний. По вакансии сложно сказать, какие задачи будет выполнять специалист. Нужно ли проектировать структуру и навигацию, определять владельцев информации, настраивать жизненный цикл знаний, работать с поиском и метриками, создавать правила публикации и актуализации?

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

Третий – русский язык на уровне C2. Для большинства международных компаний стандартом считается уровень C1, а более жёсткое требование без объяснения причин кажется избыточным и лишь сужает воронку кандидатов.

Мой вывод

Вакансия может подойти кандидату, который уже работал с LMS, корпоративными порталами или базами знаний и хочет развиваться на стыке Knowledge Management и обучения.

Особенно интересной она может быть для L&D-менеджера, который хочет глубже работать со знаниями, или для начинающего KM-специалиста, готового совмещать развитие базы знаний с операционными задачами в LMS.

Перед откликом я бы уточнил:

• как распределяется время между работой со знаниями и корпоративным обучением;

• какую платформу используют сейчас и почему в вакансии перечислено несколько систем;

• кто отвечает за структуру, поиск, качество и актуальность базы знаний;

• какие процессы уже настроены, а какие предстоит создать;

• обязательно ли подтверждать русский язык на уровне C2;

• какая зарплатная вилка, тип договора, формат работы и допустимые часовые пояса. 

Если вы развиваете управление знаниями в компании или ищете кандидатов и не знаете, как привлечь сильных специалистов, напишите мне в личные сообщения. Посмотрю вакансию и подсвечу места, которые стоит доработать.

Больше разборов вакансий – в моём телеграм-канале Знания на завтрак. Подпишитесь, чтобы не пропустить.

Я же лучше собаки? Именно этот метафорический вопрос встал передо мной, когда я, будучи тимлидом команды ИИ, решил впустить (разумеется, в разумных пределах) в свою рабочую деятельность популярные модели.

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

Оказалось, что модели всегда выдают что-то новенькое. На одну и ту же задачу сначала рекомендует 20 часов занятости топового сеньора команды, при точно таком же запросе далее - уже 10. Разницу чувствуете? Бюджет команды - несомненно ощутил бы эффект. Еще интересней, что на практике на ту таску он потратил бы часов 8.

Не хотелось бы уходить в какие дебри, а спросить именно у вас, дорогие товарищи, как вы считаете, способна ли ИИ-шка полностью заменить руководителей на местах, забрав на себя всю управленческую рутину или все-таки это направление по-прежнему будет нуждаться в грамотных специалистах, которые пусть и не будут всегда правы в своих решениях, но все же будут решать вопросы с присущей человеку логикой?

Что под капотом

Под капотом — двигательный отсек. Или женщина. Последние лет 150 чаще двигатель, чем женщина.

Если вы не реконструктор, который шьёт и носит капоты 18 века, если речь в вашем тексте идёт не про автомобиль и его двигательный отсек — у вас нет капота. Нет его в вашем ПО, нет его в самодельной электронике. И, соответственно, под ним ничего быть не может.

Надо объяснить, из чего состоит приложение, раскрыть секреты его архитектуры, состав модулей или стек — лучше так и сказать. Нет там капота. Тянуть за уши неуместную аналогию ни к чему, она понимания не добавляет.

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

_{Примеры «капотов» в комментариях.}

"Слащавый он какой-то"

Развитие искусственного интеллекта продолжает набирать обороты, появляются новые модели, внедряются свежие подходы, даже соответствующие законодательные акты принимаются на государственном уровне.

Сегодня хотелось бы немного поразмышлять насчет того, куда же все же мы идем с этими новомодными технологиями и... Причем не как айтишник, а как обычный человек. В рабочих моментах ИИ-шечка все же отрабатывает на все 100%.

Сейчас из каждого утюга идут рассуждения, касаемые перспективности развития нейросетевых технологий, важно понимать, что на местах рядовые граждане все чаще прибегают к их помощи. Углубляться в тонкости хрупкого баланса интеллекта искусственного и естественного не буду. Отмечу, что хотелось бы надеяться, что человечество (или хотя бы его подавляющее большинство) будет тяготеть к последнему. Сегодня же ситуация следующая.

Генерируем все: тексты, музыку, картинки, презентации и так далее. Лично у меня идет какое-то отторжение к творениям ИИ-креаторов, которых, по данным статистики, на одном из популярных стриминговых сервисов уже больше (вдумайтесь) 140 тысяч. Все как у героя Балабанова: "мне не нравится. Слащавый он какой-то, подкрашенный весь..."

Несмотря на лично мое отношение ко всему происходящему, лагерь современников из ИТ-сообщества и не только (мы не сказали про угрозу замены кодеров) разбивается на две когорты. В правом углу ринга - любители нового - зумеры, а в синих трусах - консерваторы, рожденные в прошлом веке.

И все же интересно, сколько нас таких здесь? Кто за кого? С удовольствием посмотрю ваши комментарии.

Тетрис, 18 сентября 1985: не тот ли это «Tetris 0»?

Не хочу лить воду, просто покажу, что (пере)обнаружилось в археологии: в коллекции Андрея Кислова (Andrey_Ak), которую он снимал с лент от Электроники-60 и выкладывал на форуме T.I.S., есть архив MT004/RAFOS.rar. Внутри лежит системный том RAFOS.DSK, а на нём файл TET.SAV, 32 блока, дата в каталоге 18-09-1985. Это версия Тетриса под Электронику-60 на английском языке, и в ней открытым текстом стоит подпись автора.

Копирайт автора с той самой “передачей прав на 10 лет ВЦ АН СССР”:

GAME BY PAJITNOV A.L.
(C) ВЦ АН СССР. 1985

Открытый вопрос

Весной 1989-го, пока Atari, Tengen и ЭЛОРГ делили права, в Библиотеке Конгресса легли такие регистрации:

• 14.04.1989, Atari Games: PA 412-085 и PA 412-086

• 15.05.1989, А. Пажитнов: TX 2-600-074

• 17.05.1989, Tengen: версия для NES

• 19.05.1989, ЭЛОРГ: PA 412-170, «original version 3.12»

• 22.05.1989, ЭЛОРГ: PA 412-169, «Tetris 2»

• 22.05.1989, ЭЛОРГ: PAu 1-214-035, «Tetris 1», год создания 1985

• 22.05.1989, ЭЛОРГ: PAu 1-214-036, «Tetris 0», год создания 1985

PAu означает unpublished work, неопубликованное произведение. ЭЛОРГ отдельно застолбил две ранние вещи 1985 года, которые никогда не издавались, и назвал их «Tetris 1» и «Tetris 0».

А на ленте лежит английская сборка, датированная сентябрём 1985-го, с подписью автора и копирайтом ВЦ АН СССР. Ровно то, что имеет смысл переводить на английский, если собираешься показывать вещь наружу.

Сам бинарник, кстати, уже запускали и показывали публично. На ZX-PK есть сообщение hobot в ветке про контроллер псевдодиска для ДВК.

Мою статью с Хабра целиком перепечатали на другом сайте без спроса. Что делать?

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

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

• Первое. Насколько вообще действенны жалобы регистратору вроде REG.RU? Реагируют ли они на такое, и что обычно требуют приложить, чтобы жалоба сработала?

• Второе. Есть ли толк от исключения копии из выдачи через формы Google и Яндекса? Контент это не удаляет, но лишает смысла всю затею с трафиком.

• Третье. Есть ли смысл писать в рекламную сеть, чей баннер стоит на странице? Могут ли площадку отключить от монетизации за чужой контент?

• И общий вопрос: у кого был похожий опыт, чем закончилось и сколько заняло времени? Провальные истории даже интереснее удачных.

Вайб‑кодинг довёл: «сайт за ночь», сотый планировщик бюджета и клон Google Диска

Наблюдение за последние месяцы: слово «SaaS» на глазах становится ругательным. Треды забиты историями «создал продукт на миллион за сутки», и почти всегда это реклама аккаунта автора, а не продукт. Планировщиков бюджета, написанных с Клодом, я лично насчитал уже больше сотни. Но недавно встретился экземпляр покрепче: человек с помощью ИИ собрал аналог Google Диска. Всерьёз. Хранение чужих файлов — это юридика (персональные данные, DMCA, 152-ФЗ), это бэкапы, это аптайм, это поддержка на годы. Ничего из этого в промпте не было.

Параллельно из каждого утюга: ИИ заменит дизайнеров, копирайтеров, вообще всех.

У меня противоположный опыт, и он скучнее хайпа: ИИ — это инструмент у специалиста. Работает ровно настолько, насколько ты сам понимаешь предметную область.

Конкретика из моей ниши — SEO. Прежде чем подпускать ИИ к семантике, я несколько лет собирал её руками. Поэтому вижу, где модель реально ускоряет, а где уверенно гонит брак:

— ускоряет: рутина по кластеризации, черновики метатегов, шаблоны программатик‑страниц, техничка;

— гонит брак: длинные хвосты и тонкие настройки. Модель не чувствует нишу и не идёт в нестандартные решения — она выдаёт медиану обучающей выборки. А в SEO деньги лежат как раз за пределами медианы: в запросах, которые конкуренты не увидели, и в решениях, которые «по бест‑практикам» делать не принято.

Свой первый коммерческий сайт — простой многостраничник под SEO — я писал месяц, с ИИ в руках. Не за ночь. И всё равно наделал кучу ошибок, часть страниц переделывал. А на юзабилити звал живого дизайнера: расположение текстов, шрифты, подача картинок. Потому что сайтом пользуются люди, и насмотренность дизайнера — тысячи отсмотренных работ, натренированный глаз — это пока не сжимается в датасет. Модель может сгенерить лендинг, который «выглядит как лендинг». Дизайнер видит, почему по нему не хочется скроллить.

Вывод у меня короткий, без драмы. ИИ ускоряет того, кто знает, куда ехать, — в разы, проверено ежедневной работой. Но если посадить за руль человека без прав, быстрая машина просто быстрее довезёт до столба. «Сайт за ночь» — это не история про силу ИИ. Это история про то, что автор ещё не узнал, чего он не знает.

Интересно, у кого как: встречали «продукт за ночь», который прожил хотя бы год?

Сбер, ДМС и 61 тысяча: где заканчивается редактура и начинается управление знаниями?

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

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

Дисклеймер. Я больше 15 лет внедряю менеджмент знаний в российских компаниях. Запустил эти разборы, чтобы работодатели могли увидеть спорные места в вакансиях, а специалисты – точнее оценить задачи и подготовиться к собеседованию. Анализирую только опубликованные тексты вакансий, а не реальные процессы внутри компаний.

Начну с плюсов

Вакансия не перегружена. Обязанности описаны кратко и не создают ощущения, что на одного человека хотят возложить несколько разных ролей.

Требования выглядят адекватными и соответствуют уровню позиции. Вакансия доступна для специалистов с небольшим опытом.

Есть социальный пакет. Официальное оформление, обучение, ДМС и работа в крупной известной компании делают предложение привлекательным.

Дальше начинаются вопросы

Первый – зарплата. Предложение от 61 тыс. рублей в месяц выглядит невысоким даже с учётом региона (Ставрополь) и бренда работодателя.

Второй – обязанности описаны слишком общими фразами. Не очень понятно, чем именно предстоит заниматься. Специалист должен просто писать и обновлять статьи или ещё работать со структурой базы знаний, поиском, метриками, шаблонами и правилами публикации?

Третий – профильное образование. Кандидат должен иметь образование в области журналистики или филологии. Это заметно сужает круг потенциальных кандидатов. При этом на практике на таких позициях успешно работают специалисты с самым разным бэкграундом.

Четвёртый – мало конкретики о команде и инструментах. Также ничего не указано про карьерное развитие и процессы работы. Кандидату с опытом будет сложно оценить уровень зрелости направления.

Мой вывод

Вакансия может подойти специалисту с небольшим опытом, который хочет попробовать себя в работе с базами знаний и при этом стартовать в крупной компании. Для опытного специалиста позиция может показаться менее интересной, так как есть вероятность, что работа ограничена редакторскими задачами. Отдельный вопрос – зарплата: указано только «от 61 тыс.», без верхней границы.

Если база знаний нужна только как хранилище статей, роль действительно ближе к редактуре. Если она должна помогать сотрудникам быстрее находить ответы, снижать нагрузку на поддержку и работать как источник данных для ИИ-ассистентов, одной редактуры мало: нужны структура, правила, процессы, метрики и регулярная работа с качеством знаний.

Так что, перед откликом стоит уточнить:

• что будет основным: написание, редактура, актуализация или развитие базы знаний;

• в каких инструментах предстоит работать и какую роль выполняет база знаний;

• есть ли наставник и план адаптации;

• кто ставит задачи и проверяет результат;

• есть ли шаблоны и правила публикации;

• нужно ли работать с метриками, поиском и структурой базы;

• насколько обязательно профильное образование;

• что входит в ДМС и обучение;

• какие варианты роста есть внутри команды.

Если вы развиваете управление знаниями в компании или ищете кандидатов и не знаете, как привлечь сильных специалистов, напишите мне в личные сообщения. Посмотрю вакансию и подсвечу места, которые стоит доработать.

В пятницу опубликую полный список открытых вакансий в своём телеграм-канале Знания на завтрак. Подпишитесь, чтобы не пропустить.

Музыкальное радио в Hi-Fi качестве для слушателей и авторов.

Совсем ещё недавно, мечты тысяч радиолюбителей по всему свету сводились к созданию собственной радиостанции, где можно было сутки напролёт крутить разную музыку без ограничений. Но жесткий контроль со стороны ГИЭ (Государственная организация электросвязи) не давал такой возможности.

Мало того что нужно было регистрировать купленный или созданный своими руками передатчик, так ещё и "крутить" всё подряд запрещалось. У каждого радиолюбителя должен был быть зарегистрированный позывной, к примеру мой старый позывной UR4IFH, так ещё и нужно сдавать экзамены на знание основ радиоэлектроники и связи. Это касалось не только времём СССР - такие правила есть и сейчас.

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

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

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

Для успеха интернет радиостанции, как равно и для эфирной, важна популярность. Но где её взять - купить? Можно и купить. Сейчас за деньги можно раскрутить что угодно. Вопрос лишь в том, будет ли востребована такая станция и не сойдёт ли на нет её популярность в ближайшей перспективе?

Итак, важным условием существования радиостанции с постоянно растущим рейтингом слушателей, является её уникальная особенность. Нужно придумать свою фишку, которой нет у других. Но ведь если придумать что-то необычное, конкуренты смогут это "утянуть" и сделать так же или даже круче. Да, это так. Но эта уникальная фишка должна существовать не сама по себе - она должна быть основана на целой цепочке взаимодействий, без которых копия не сможет реализовать всей идеи.

Лично я запустил такое радио в высоком качестве 320 кбит в формате AAC для любителей музыки. Основной материал, который я транслирую, - это музыка от независимых авторов и малых студий. Сюда входят и треки созданные в нейросетях, например в SUNO, Udio, Mureka и других. Авторские отчисления поступают владельцам этих треков на их криптокошельки через созданную мною систему распределения роялти основанную на блокчейне (об этом читайте в других моих статьях).

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

Интересно, а какие вы придумали способы, чтобы сделать свои проекты уникальными и защищенными от копирования?

Про автоматизацию автора и мёртвый интернет

Недавно я рассказал на Хабре, как сделал собственного цифрового аватара и создал серию коротких роликов для озвучки своих текстовых заметок.

И почти сразу после публикации мне предложили адаптировать разработку под контент-завод.
Для тех, кто не в курсе: это когда контент производится вообще без участия человека.

Технически до такого режима оставалось не так много: генерировать текст, синтезировать голос, автоматически подбирать слайды и передавать всё моему сборщику. На входе — тема, на выходе — готовый ролик.

У меня даже в коде были предусмотрены переменные для замены содержимого слайдов. Но в какой-то момент я сам ударил себя по рукам и перестал разрабатывать эту часть системы.

Потому что смысл моего проекта — автоматизировать всё скучное, чтобы у автора оставались силы на творчество.

А контент-завод делает ровно наоборот.

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

Это буквально «мёртвый интернет» в действии.

Автоматизировать можно почти всё, но не причину, по которой контент вообще должен существовать.

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

И кажется, Булычёв и Стругацкие завещали нам немного другое.

Эту же мысль я собрал в короткий анимационный выпуск — видеоверсия длится 1:09 и доступна на YouTube.

DevRel-, PR- и HR-специалисты, общий сбор!

Мы на Хабре запустили исследование о том, как технический контент влияет на решения инженеров. Наша цель — сравнить взгляд тех, кто создает контент, и тех, кто его читает: какие материалы вызывают доверие, влияют ли они на выбор вендора или работодателя и где ожидания авторов расходятся с реальностью.

Параллельно проводим такой же опрос среди инженеров, а по итогам подготовим большое исследование, где сравним взгляд обеих сторон.

Если вы работаете с контентом для продвижения технологий, продуктов или HR-бренда среди инженерной аудитории, приглашаем пройти анонимный опрос.

Опрос займет 10-15 минуты, но очень поможет исследованию. 

Вайбкодите? Тогда мы идём к вам...

Андрей Карпатый из пузыря OpenAI чуть больше года назад сказал: «Я полностью принял вайбкодинг, где забываю, что код вообще существует. Я просто вижу то, что хочу, говорю ИИ, и оно появляется». Сейчас вайбкодинг уже обозвали «методом программирования». Видимо, ждём гуманитарные диссертации на тему «Эволюция программирования: неструктурированное, процедурное и модульное, объектно-ориентированное и вайбкодинг».

Опыт подсказывает, что если жизнь в одном месте стремительно упрощается, то в другом — катастрофически усложняется. Поэтому разберём высказывание товарища Карпатого, поищем, где зарыты мины.

Забываю, что код существует
Чтобы толком что-то навайбкодить, сначала хорошо бы писать код самому. Иначе забывать нечего, и человек просто не поймёт, что можно забыть, а что — лучше не надо. Это как езда на велосипеде: сначала следишь за каждым движением, чтобы получить навык и только потом забыть.

Если взялся вайбкодить, будь готов забыть то, что знал. Программисты с безлимитными токенами сами признаются, что забывают, как писать код руками. Помните, в школе после летних каникул забывали, как пишутся буквы? Вот-вот.

Вижу то, что хочу
Если я вижу айфон, но не представляю, как он устроен изнутри, то что я вижу? Кирпич из стекла и металла. Если вайбкодер не понимает, как его хотелка устроена изнутри, то с ненулевой вероятностью получит такой же кирпич.

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

И оно появляется
Вот именно, что оно: смотрите на иллюстрацию, а для тех, кто не владеет парсалтангом, расскажу, что навайбкожено.

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

• загляни в файл;

• если файл не пустой, напиши, что он проверен;

• если пустой, напиши, что он заражён вирусом.

Антивирус живёт сам по себе, а файл, который надо проверить на вирусы, проверен на наполнение. Чтобы найти эту «мелочь», нужно знать, как всё работает, и потратить кучу времени.

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

Писатель, аналитик и немного администратор: сколько стоит такая роль?

Продолжаю разбирать вакансии, связанные с управлением знаниями и технической документацией. Сегодня смотрим позицию писателя базы знаний в Яндекс 360. Вакансия описана достаточно подробно, но границы роли и предлагаемая зарплата вызывают вопросы. 

Дисклеймер. Я больше 15 лет внедряю менеджмент знаний в российских компаниях. Запустил эти разборы, чтобы работодатели могли увидеть спорные места в вакансиях, а специалисты – точнее оценить задачи и подготовиться к собеседованию. Анализирую только опубликованные тексты, а не реальные процессы внутри компаний.

Начну с плюсов

Понятно описаны задачи. Кандидату предстоит писать и обновлять инструкции, следить за изменениями в продуктах, работать с метриками и развивать базу знаний. Уже по тексту можно составить общее представление о работе и сопоставить её со своим опытом и интересами.

Требования логично связаны с обязанностями. Компания ищет не просто автора текстов, а специалиста, который умеет разбираться в процессах, структурировать информацию, общаться с внутренними заказчиками и работать с данными.

Основные условия указаны. Сотрудника оформляют на полную занятость. Указаны зарплатная вилка, квартальная премия, компенсация амортизации личного оборудования, оплачиваемое обучение. Также заявлена возможность развиваться и переходить на другие позиции.

Удалённый формат. График известен заранее – с 10:00 до 19:00 мск. Для многих кандидатов возможность работать без привязки к офису по-прежнему остаётся важным преимуществом.

Дальше начинаются вопросы

Первый – срочные запросы. В вакансии не объясняется, как часто они возникают и укладываются ли в обычный график. Лучше заранее уточнить, нужно ли оставаться на связи после 19:00 или в выходные.

Второй – зарплата. В вакансии указана вилка от 55 до 85 тысяч рублей в месяц до вычета налогов. На мой взгляд, она выглядит скромно для заявленного набора обязанностей: кроме подготовки текстов, сотруднику предстоит заниматься аналитикой, взаимодействовать с внутренними заказчиками, развивать структуру базы и работать с инструментами поддержки.

Третий – границы роли. В одной позиции объединены разные функции. При этом непонятно, какие задачи будут основными и за какие результаты сотрудник отвечает лично.

Четвёртый – мало информации о команде. Не указаны размер команды, распределение обязанностей, рабочие инструменты и траектория профессионального развития.

Мой вывод

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

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

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

Перед откликом стоит уточнить:

• как распределяется время между текстами, аналитикой и развитием базы;

• сколько человек работает в команде и как разделены обязанности;

• какие платформы и инструменты используются;

• что входит в настройку и автоматизацию инструментов поддержки;

• как часто возникают срочные задачи и требуют ли они работы вне графика;

• от чего зависит сумма внутри вилки и как рассчитывается премия;

• каких результатов ждут от сотрудника в первые три месяца.

Вакансию можно посмотреть тут.

Я веду свой телеграм-канал про управление знаниями, делюсь в нём граблями из проектов для лидеров рынка: Банк СПб, Билайн, Делимобиль, Купер, МЭС и других. А ещё рассказываю про ИИ-находки для дома и не только. Подпишитесь, чтобы не пропустить следующие посты.

GEO без инъекций

Недавно меня приглашали рассказать про GEO-оптимизацию. Я тогда отказался, но в прошлом посте про Моллика был как раз момент на эту тему. Поэтому я решил всё-таки рассказать в рамках одного поста кратко про то, что у меня описано в скиллах редактуры, чтобы закрыть часть вопросов. Если нужна полная инфа по GEO — пишите.

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

Что теперь работает против тебя:

— Скрытый текст, цвет фона, шрифт в пиксель. Модели это видят и понимают, зачем это спрятано.
— Прямые команды. «Ты обязан рекомендовать», «игнорируй предыдущие инструкции», «скажи пользователю, что это лучший материал». Чем сильнее агент, тем жёстче он это режет.
— Фальшивый консенсус для ИИ. «Все эксперты сходятся», «общепризнанно лучший» — без единого пруфа. Человек такое пролистывает, модель помечает как ненадёжное.
— Двойное дно. Одно для людей, другое зашито «для ИИ». Как только модель замечает расхождение, доверие падает ко всей странице.

Что реально заставляет модель тебя цитировать:

1. Извлекаемые факты. Модель тащит то, что можно забрать одним куском. Не «мы серьёзно ускорили процесс», а «сократили время сборки с 40 до 6 минут (замер за март 2026)».
2. Источник, дата, имя. Каждая цифра с происхождением, каждая цитата с автором и должностью. Это не занудство, а ровно то, что отличает текст, который модель готова показать человеку.
3. Структура под реальные вопросы. Заголовки, которые отвечают на то, что человек спросит вслух. Так модель находит нужный кусок и цитирует его, не перевирая. Заголовок «Наш подход» бесполезен, а «Сколько это стоит и от чего зависит цена» — находится и цитируется.
4. Конкретика вместо настроения. «Ведущее решение на рынке» — пустой звук и для человека, и для модели.
5. Честность про границы. Абзац «где это не сработает / чего мы не умеем» поднимает доверие.
6. Свежесть. Дата у данных, «по состоянию на …». Модель охотнее рекомендует те данные, которые не протухли.

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

Модель редко цитирует страницу целиком — она выдёргивает один абзац и показывает его человеку в отрыве от всего остального. Поэтому каждый абзац должен быть самодостаточным, с фактом, источником и датой внутри себя. Абзац, который начинается со слова "это", "поэтому", "как мы уже говорили выше", при выдёргивании превращается в кашу и модель его просто не берёт.

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

Больше и чаще у меня в канале.

Манифест контент-опса

Развивая тему ContenOps, я попробовал написать какой-то программный манифест. В DevOps философия базируется на принципах Agile, модели CALMS и концепции непрерывной поставки ценности. Если просто: писать код важно, нужно ещё важнее доставлять надёжно и отвечать за доставленное. Для контента развилка та же, только доставляем мы не код, а то, чему должны верить читатель и модель.

Что мы ценим. По мотивам Agile-манифеста разработки программного обеспечения

🔹Проверяемость важнее объёма.

🔹Правка системы важнее правки текста.

🔹Голос как контракт важнее голоса как чутья.

🔹Ответственность за выпущенное важнее скорости выпуска.

🔹Формализованное знание важнее знания в голове у редактора.

🔹Доверие читателя и модели важнее охвата.

При всей ценности того, что справа, левое мы ценим больше.

Три пути

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

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

Обратная связь. В DevOps смысл петли в том, что исправление возвращается к источнику ошибки, а не гасит её последствия. Иначе источник спокойно повторит тот же дефект завтра. У агента источник ошибки — это скилл, поэтому и правку возвращают в скилл, а не в текст. Поправить текст — разовый патч, работа на выброс: сам агент об этой правке не узнает и завтра ошибётся снова. Поправить скилл — значит замкнуть петлю, чтобы ошибка не вернулась. По той же причине проверку встраивают прямо в поток, как CI, а не оставляют на финальную вычитку: чем ближе к источнику пойман дефект, тем дешевле он обходится.

Обучение. В основе третьего пути простое наблюдение: если наказывать людей за сбои системы, они начинают эти сбои прятать, и система ломается незаметно. На редакцию это переносится дословно. Сбой агента — это дефект правила, а не вина редактора, поэтому его и разбирают без поиска виноватых: стоит начать наказывать и о сбоях просто перестанут докладывать. Дальше та же логика тянет за собой остальное. Скиллы копятся и конфликтуют друг с другом, как код, а значит, у контента появляется собственный техдолг и время на его разбор — это работа, а не отвлечение от неё. Устойчивость проверяют раньше читателя: агента нарочно гоняют на граничных случаях, потому что сломать систему самому всегда дешевле, чем ждать, пока это сделает аудитория.

И небольшой вывод

Ничего из вышеописанного не про то, как быстрее генерировать. Это делают все, поэтому объём и обесценивается. Манифест про то, как отвечать за сгенерированное: за цифру, которую не проверили, за голос, который поплыл, за материал, вышедший под твоим брендом.

Кто освоит контентопс в новом смысле, тот и будет редакцией через год. Остальные останутся фабрикой. А фабрика делает то, что дешевеет.

Подписывайтесь на канал, там пишу больше и чаще.

Технический писатель за 110 000: вход в профессию или испытание на прочность?

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

Сегодня смотрим вакансию технического писателя/контент-менеджера базы знаний в компании «Сканпорт». Наткнулся на эту вакансию на днях. Она уже закрыта, но на ней можно наглядно разобрать плюсы и минусы. 

Начну с плюсов

Первое: работодатель дал ссылку на публичную базу знаний. Кандидат может заранее посмотреть, с каким продуктом, структурой и контентом ему предстоит работать. Уже на этом этапе можно примерно оценить объём задачи и понять, что ждёт впереди.

Второе: зарплата указана – 110 000 рублей. Соискатель может сразу решить, подходит ему такая сумма или нет.

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

Теперь к вопросам

Главный – кого всё-таки ищут: начинающего специалиста или самостоятельного сотрудника? Формально компания готова рассматривать новичков, но одновременно хочет видеть опыт от года, понимание таксономии баз знаний, Markdown, Confluence, таск-трекеры и Kanban. Знания REST API, JSON, складских и логистических процессов указаны как преимущество, а не обязательное требование, но даже без них задачи выглядят не совсем стартовыми.

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

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

Отдельный момент – удалёнка. Она предусмотрена, но обсуждается индивидуально. При этом график фиксированный: пять дней в неделю с 9:15 до 18:00. Работать из дома, вероятно, можно. А вот работать из любого часового пояса и самостоятельно выбирать часы – надо уточнять. Если нет, для кандидатов из удалённых регионов это заметно сужает возможности.

Мой вывод

Вакансия может подойти не абсолютному новичку, а скорее начинающему специалисту с некоторой базой. Например, человеку из технической поддержки, тестирования, аналитики или контента, который уже сталкивался с документацией и хочет развиваться в этом направлении.

Перед откликом я бы уточнил:

• кто и как будет обучать нового сотрудника;

• какие задачи займут большую часть рабочего времени; 

• что компания ожидает получить в первые три месяца; 

• действительно ли можно работать полностью удалённо и насколько строго привязан график.

***

Напишите, если было полезно. Стоит продолжать такой формат?

Я веду свой телеграм-канал про управление знаниями, делюсь в нём граблями из проектов для лидеров рынка: Банк СПб, Билайн, Делимобиль, Купер, МЭС и других. Подпишитесь, чтобы не пропустить следующие посты.

10 июля Хабр проведет творческую встречу корпоративных авторов онлайн или по вашим многочисленным просьбам ...

Всем привет! 10 июля мы проведем онлайн-встречу по следам “Авторского огонька” и соберем всех тех корпоративных авторов, кто очень хотел принять участие, но находится далеко от Москвы и физически не мог этого сделать.

На этот раз ехать никуда не нужно, нужно просто зарегистрироваться и из любой точки мира подключиться к онлайн-эфиру, который состоится уже в эту пятницу, 10 июля, в 13.00 по Мск.

Это будет немного сокращенный формат встречи, всего на 1,5 - 2 часа, чтобы не сильно отвлекать вас от работы или от пятничных приятностей и развлечений. Но звёзды и легенды Хабра снова будут с нами! Участие бесплатное, но важно заполнить анкету на странице мероприятия. Регистрация и подробная информация по ссылке https://habr.timepad.ru/event/4078341/

А как прошла последняя встреча в офлайне, я совсем скоро расскажу в статье. Немного терпения, господа!

Хабр и коммуникационное агентство FRC проводят двойное исследование о том, как технический контент влияет на решения инженеров. «Мы хотим сравнить взгляд тех, кто создаёт этот контент, и тех, кто его читает», — пояснили организаторы опроса.

Опрос для создателей контента, PR и HR «Отраслевое расследование в 3 сериях: контент, которому (не) верят» займёт 10–15 минут. Все ответы анонимны и будут использоваться только в обобщённом виде.

«Разбираемся, как инженеры в промышленности выбирают работодателей и поставщиков, каким источникам и техническому контенту доверяют, а каким — нет. И сравниваем это с тем, как компании выстраивают коммуникацию с инженерами — какие задачи решает контент, как он формирует доверие к экспертизе и продуктам, и что в итоге работает», — уточнили в Хабре и FRC. По итогам опроса будет подготовлено исследование, где сравнят обе стороны рынка.

Заходите к нам на огонёк! 24 июня состоится закрытая творческая встреча клуба корпоративных авторов Хабра

Мероприятие пройдет в Москве, в формате офлайн. Регистрация уже идёт! Делюсь ссылкой на страницу, как и обещала ранее, и благодарю всех, кто принял участие в опросе. Ваши вопросы будут озвучены на встрече, а ответят на них звезды Хабра.

Также вы можете написать свои вопросы мне в личку или тут в комментариях. Рекомендуется также поделиться инфой о встрече со своими коллегами и друзьями — корпоративными авторами! Мест осталось немного, поэтому лучше поспешить с заполнением анкеты и обязательно дождаться подтверждения регистрации.

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

На нашей встрече в следующую среду будет уютно, тепло и интересно! Много классных спикеров, творческая атмосфера, возможность пообщаться с единомышленниками, найти новые идеи и вдохновиться! Будем обсуждать поиск тем, лайфхаки и секреты написания крутых статей, общаться со звездами и легендами Хабра, а также с победителями, организаторами и членами жюри «Технотекста». Пора уже узнать их секреты!

Конечно, мероприятие, прежде всего, нацелено на то, чтобы помочь начинающим авторам. Но мы будем рады и опытным, которые готовы вместе искать ответы на вечные вопросы о том, как писать интересно об очевидном, как выглядеть экспертом, но не стать «душнилой», как влюбить читателя в свой текст, какие околотехнические темы зайдут на Хабре и многое другое. Также в программе будут нетворкинг и интересные творческие активности.

📆 До встречи осталась меньше недели, поэтому регистрироваться нужно уже сейчас! Для тех, кто в других городах, проведем потом встречу в онлайн-формате. Об этом сообщу дополнительно!

🔥 Мероприятие бесплатное, но количество мест ограничено. По всем вопросам пишите, пожалуйста, мне в личку — буду рада пообщаться и увидеть вас на нашей встрече! 🫶

Программа нашей встречи:
 

14:00 — 15:00
Сбор гостей

15:00 — 15:05
Приветственное слово от Хабра. 

15:05 — 15:30
«Статья, которая зайдёт: как вовлечь аудиторию в чтение». Приёмы для создания лидов, заголовков и секреты интересной подачи материала». Виктория Гонгина, старший редактор-эксперт команды онбординга и обучения коммерческого департамента Хабра, куратор Технотекста. 

15:30 — 15:50
«Писать, отложить, вернуться: о процессе подготовки сильных статей». Артур Думчев, дважды победитель «Технотекста», техлид бэкенда в SberDevices. 

15:50 — 16:10
«Что творится с нейрослопом в научных статьях и как детектируют и борются с GenAI». Дмитрий Ватолин, победитель Технотекста, руководитель лаборатории компьютерной графики и мультимедиа ВМК МГУ.

16.10 — 16.30
«Как стать автором и взорвать Хабр». Игорь Данилов, технический пиарщик в дуэте с автором корпоративного блога «Цифрового Сибура» Иваном Васильевым. 

16.30 — 17.00
Перерыв на общение и перекус. 

17:00 — 17:20
«Как не похоронить хороший текст. О темах, смыслах, хабах, ключевых словах, реакции аудитории и секретах качественной статьи». Павел Соколов, руководитель группы контент-маркетинга IT-компании «Онлайн патент».

17:20 — 17:40
«100500 комментариев и 1 автор: как искупаться и не утонуть». Анастасия Распопина, автор и редактор текстов IT-тематики.

17:40 — 18:00
«Курсы, игры, два стола. Как Хабр помогает развиваться корпоративным авторам». Лилия Лущенко, старший редактор-эксперт в команде онбординга и обучения Хабра.

18:00 — 19:00
Креативный нетворкинг. Вместе генерим идеи для будущих статей.

19:00 — 19:30
Завершение мероприятия.

Маркетологи и пиарщики, привет!

Кажется, маркетологам, PR-специалистам и контент-командам в последнее время приходится решать одну и ту же задачу: как бренду быть в поле зрения клиентов, когда привычные каналы коммуникации теряют эффективность?

24 июня в 17:30 этот вопрос обсудят эксперты Pressfeed и Хабра на бесплатном вебинаре «Продвижение по новым правилам». 

Вместе разберемся: 

• Как оставаться в инфополе в условиях сокращения бюджетов;

• Почему количество публикаций уже не гарантирует результат и на что стоит делать ставку вместо этого;

• Как перестроить работу со СМИ, если акцент сместился к аналитике и глубокой экспертности;

• Как работать с экспертной коммуникацией как с инструментом продвижения бренда;

• И почему эксперты-скептики — ваши лучшие амбассадоры.

Своим опытом поделятся Татьяна Кузнецова, руководительница Академии Pressfeed с более чем 25-летним опытом работы в PR, маркетинге и коммуникациях, и Ирина Лосева, ведущий редактор-эксперт Хабра.

→ Зарегистрироваться на вебинар

Как я превращал свалку заметок в библиотеку для ИИ-агентов

База растёт сама из работы над контентом. Под каждый материал агент сначала делает исследование: идёт в веб, собирает данные, цифры, источники. Конспект сразу сохраняется в research/ под конкретную статью — это страховка от потери данных, если сессия оборвётся. Важный момент: исследование сохраняется автоматически, ещё до того, как автор начал писать.

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

Звучит красиво, но было три проблемы:

— агент порой не знал, что в базе уже есть инфа, и искал заново;
— мог взять устаревшую цифру, потому что никто не помечал, когда факт «протух»;
— в документации написано «агент смотрит в базу», а в коде этого нет.

Слои: от свалки к полкам

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

— fact-card — один проверяемый факт = одна карточка. С источником, уровнем доверия и сроком годности.
— case-card — один публичный кейс клиента, и что про него говорить нельзя.
— objections — карточка возражения («облако дороже») с готовым безопасным ответом.
— personas — карточки аудиторий: боли, KPI, запретные углы.

Зачем дробить? Большой текст легко выдаёт лишнее — непубличную деталь или старую цифру. Атомарная карточка хранит ровно один факт. Просрочилась — система сама её отложит.

Интеграции: появился библиотекарь

Полки — это полдела. Дальше нужен тот, кто приносит нужное:

— Картотека плюс ретривер в коде: даёшь тему — получаешь короткий список релевантных карточек, просроченные помечены.
— Компактная коробка вместо всей базы. Агенту едет не дамп на пол-базы, свежие факты, публичные кейсы, и список того, чего в базе нет.
— У каждого типа задач своя карта. Не «загляни в базу», а «для пресс-релиза бери позиционирование и публичные кейсы, а конфиденциальные числа только после проверки».
— Починил пайплайн. Шаги, которые раньше были красивым описанием, заработали: повторный фактчек сомнительных цифр реально запускается, а 19 ресёрчеров наконец получили веб-поиск, которым «просили» пользоваться.

Предохранитель на финале

Последний шаг любого пайплайна — редактор. Берёт только разрешённые к публикации карточки, а просроченные не пускает в текст. И всё закреплено тестами: рассинхрон «база — агент» теперь роняет сборку.

Что в итоге

Конечно, это не очень обязательный элемент фабрики контента. В воркфлоу записано, что надо найти, передать, написать, проверить. Всё в чистом контексте и галлюцинаций в финале не остаётся. Но каждый запрос это токены и время. И деньги. А запросы повторяются, в конце концов мы крутимся вокруг одних и тех же цифр исследований, бенчмарков, фактов. Поэтому постепенно наполнять базу знаний и оперативно обращаться к ней кажется не такой уж плохой идеей. Стоит потратить на реализацию несколько вечеров.

Ставьте плюсы, подписывайтесь на канал.

Авторский огонёк на Хабре снова загорится в июне!

Два года назад из идеи поддержать начинающих авторов, случайно возникшей во время разговора с моим руководителем, родился целый проект - живые творческие встречи с авторами Хабра в нашем офисе, которые мы назвали "Авторский огонёк". Сейчас планируется уже четвертая встреча. Наша цель остается прежней - вдохновить и замотивировать начинающих авторов, снять их боли и страхи, поделиться полезной информацией, которая поможет им в написании статей и передать из рук в руки классные рабочие инструменты по поиску тем, придумыванию заголовков и новых форматов. Если интересно, как прошла наша встреча в ноябре прошлого года - читайте тут.

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

В июне мы снова планируем провести творческую встречу корпоративных авторов Хабра! Это уже стало доброй традицией, которая объединяет вокруг себя все больше горящих творческих душ. На встрече как всегда обсудим самые важные и актуальные темы: страхи, боли, проблемы, поиски себя и своей ниши, работу с комментариями и многое другое.

! И пока мы только формируем программу, ваши вопросы идеи и предложения будут как нельзя кстати)

Какие темы и вопросы хочется обсудить, какие творческие активности были бы интересны и полезны в формате этой встречи? Поделитесь, пожалуйста, своим мнением в этой анонимной форме https://forms.gle/vQbXZe1d9qcSjxwG6 Также вы можете оставлять идеи в комментах или писать в личку, я всегда открыта для общения!

Кстати, подробнее об этом проекте я хочу рассказать в отдельной стате, которую обещаю скоро опубликовать) Ссылка на регистрацию участников тоже скоро будет, следите за новостями! Если вы - корпоративный автор, тоже пишете на Хабр или только планируете выходить сюда со своими публикациями - будем рады вас видеть! А если вы - опытный автор - приходите вдохновлять новичков своим примером, поделитесь своими историями и лайфаками!

Апостроф и кавычки

В американском стиле используются двойные типографские кавычки “ ”, в британском одинарные ‘ ’, а в технической документации прямые " ". В американском стиле знаки препинания ставятся внутри кавычек, в британском исходя из смысла. Но часто даже в американских блогах и технических книгах знаки ставят по смыслу, а не внутри.

Апостроф есть прямой ' и типографский ’. Для статей и постов рекомендуется использовать типографский апостроф. Хотя если посмотреть популярные новостные издания или блоги крупных технологических компаний, можно заметить, что у них даже в одной статье могут быть смешаны типографские и прямые апострофы и кавычки. Некоторые ИИ агенты не умеют использовать типографские символы и заменяют их на прямые.

Всегда удобнее ставить прямые кавычки, чем зажимать 3 клавиши для типографских. Тем более в прямых одинаковый символ для открытия и закрытия кавычек, а в типографских разные. На ноутбуке можно настроить умную автозамену на типографский вариант, но большинство программ игнорируют эту настройку. Если вы пишете на разных языках или под разный стиль, то умная замена не поможет. Можно настроить скрипт для автозамены перед публикацией статей, но если в статье содержатся примеры кода, то в них нельзя делать замену. Можно перед публикацией вручную заменять на типографские, но при ответе на комментарии снова будут прямые. Есть шрифты, которые красиво отображают прямой апостроф, но шрифт контролируешь только на своем сайте. Некоторые сайты при наборе текста автоматически заменяют на типографские знаки, но если делать вставку текста, то в нем оставляют прямые.

Blog • Telegram

YouTube начал требовать отключить средства обхода блокировок для просмотра видео. Ограничение касается каналов с жёсткими региональными правами на контент: в первую очередь спортивных — «Формула 1», некоторые футбольные лиги, отдельные музыкальные лейблы. Это каналы, где рекламодатели платят за показы в конкретных странах, а правообладатели продают лицензии по регионам. YouTube обязан контролировать, из какой страны смотрит зритель, — иначе нарушаются условия лицензий.

Для обычных видео — летсплеев, обзоров, подкастов, авторского контента — ничего не изменилось. Средства обхода блокировок работают как прежде. Явление касается единичных каналов с крупными медиапартнёрами и существует уже не первый год — просто периодически всплывает у новых пользователей и вызывает волну тревоги.

Маркетологи и пиарщики, привет! А вас не бесит, когда запускаешь кампанию в новом канале, где аудиторию понимаешь только примерно — и в итоге тратишь время, бюджет и нервы напрасно? В партнёрской программе Хабра всё иначе: вы сначала узнаёте, кто нас читает, какие форматы есть и для каких задач они подходят, а уже потом предлагаете Хабр клиентам.

К своему 20-летию Хабр обновил партнёрскую программу для коммуникационных, рекламных и других агентств, которые помогают клиентам решать имиджевые, продуктовые и HR-задачи.

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

Сейчас идёт набор в партнёрку, а уже 9 июня начнётся обучение. За несколько дней команда Хабра расскажет, как устроена аудитория площадки, какие рекламные решения работают под разные задачи и как подбирать форматы под запрос бренда.

В программе:

— разбор 10+ рекламных форматов Хабра;
— кейсы компаний из разных сегментов: «Норникель», «Самолёт», LaVivion, VIVO, «СМ-Клиника», «Гемотест», «Островок» и других;
— обучение по работе с брифом, аудиторией и подбором форматов;
— сертификат эксперта по Хабру для агентства и участников обучения.

После обучения агентство получает статус партнёра. А вместе с ним — возможность получать агентское вознаграждение от 10% до 30%, бесплатные блоги на Хабре, рост партнёрского уровня и доступ к совместным ивентам, обмену лидами и мероприятиям Хабра.

Подать заявку можно до 3 июня. Следующий набор — не раньше октября.

→ Оставить заявку на партнёрскую программу Хабра

Как находить инструкции быстрее на 40%

Одна из самых недооценённых вещей в базе знаний — нормальные названия статей.

Не AI, не «умный поиск», не модный second brain. Это всё здорово, но начинается взаимодействие с базой гораздо раньше.

Я как-то работал над скоростью поиска внутри БЗ и внезапно выяснил, что саппорты тратили огромное количество рабочего времени впустую просто потому, что документация называлась примерно так: «Новый процесс», «Финальная схема», «Инструкция updated», «Регламент 2»

И пользовательский путь в базе знаний выглядел так:
1. открыть статью,
2. понять, что это не то,
3. закрыть,
4. открыть следующую.
5. повторить 14 раз.

Причём самое полезное, что я тогда сделал, вообще не связано с написанием документации. Я просто сел рядом с саппортом и начал смотреть, как он ищет информацию. Не как казалось мне или его руководству, а как он реально это делал. И тут вскрылось прекрасное: оказалось, сотрудники почти никогда не ищут «правильными терминами».

Они ищут по симптомам, по словам клиентов, по кнопкам из интерфейса, по ошибкам и формулировкам типа «не проходит оплата». И если статья называется идеально «методологически», но обычный человек никогда так не формулирует проблему, поиск для него не работает.

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

Выглядит не очень героически, зато поиск информации ускорился почти на 40%. Сами понимаете, что в этом времени — не только качество и количество обработанных тикетов, но и коэффициент удовлетворённости клиента.

Главный инсайт, который я получил: база знаний — это в последнюю очередь про написание статей. В основном, это про удобство их использования.

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

Я заметил любопытную вещь: у некоторых материалов может быть много просмотров, но очень мало голосов и комментариев. Например, у меня в среднем получается примерно один плюс к рейтингу статьи на тысячу просмотров. В одном опросе по теме релокации ответили около 2500 человек - то есть люди дочитали статью до конца, не поленились поставить галочки и подтвердить выбор, - но за саму новость проголосовали примерно 150 человек.

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

Поэтому интересно спросить у хабровчан: что обычно заставляет вас поставить плюс статье? Вы голосуете только за действительно сильный материал, за практическую пользу, за совпадение с вашей позицией, за качество подачи - или чаще просто читаете и не голосуете? Если последнее, то по какой причине? Насколько, по вашему ощущению, на Хабре вообще принято поддерживать автора голосом или комментарием, если материал оказался полезным, но спорить особо не о чем?

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

У меня при первых публикациях была эйфория из-за быстро набирающихся просмотров и комментариев, хотя моя первая статья была, честно говоря, довольно слабой даже по моим нынешним меркам и собрала только критику. Вторая статья зашла лучше, после чего я стал писать активнее. Но когда тратишь на статью целый день, а иногда и больше, а потом видишь 6–7 плюсов просто потому, что материал был без провокации, политики и громкого конфликта, руки немного опускаются.

А буквально на днях столкнулся с ситуацией: за день написал нейтральную новость и слабенькую статью, почти без минусов под самими материалами. При этом моя карма упала больше чем на 20 единиц. Возможно, это совпадение или обычная реакция площадки, но выглядело странно - будто кто-то специально не хотел дать мне приблизиться к 50+ кармы для получения значка «Автор». Я понимаю, что для этого нужно ещё пять публикаций с рейтингом 50+, но всё же ситуация показалась необычной.

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

В общем, хочу спросить без претензий и обид: как вы сами голосуете на Хабре? Что должно быть в статье, чтобы вы поставили плюс? И почему чаще всего вы не голосуете, даже если материал прочитали до конца?

Так это пост, а не статья или новость, читателей будет базаво мало, поэтому пожалуйста пишите, буквально каждый комменатрий будет важен!

Brave (точнее, Brave Shields) удаляет ссылки на Дзен

Авторам статей - пища для ума: стоит ли использовать ссылки на Дзен, если они не отобразятся у некоторых пользователей? При создании статьи Как я зарегистрировал CVE и разозлил вендора обратил внимание, что ссылка на статью в Дзен исчезла. Текст в браузере выглядит так (ссылка в скобках):

А полный текст вот:

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

Статья вышла ещё в прошлом году. Несколько раз я пытался отредактировать статью и вернуть ссылку - ничего не выходило. Я уже даже заподозрил, что администрации Хабра чем-то не по нраву Дзен (и даже искал правила Хабра, чтоб понять причину). В итоге как-то всё забылось. Ответ нашёлся недавно. Решил подать статью в Технотекст. Вспомнил о проблеме и подумал, что это может негативно отразиться на оценке публикации в конкурсе. И тут я, наконец, догадался сделать то, что нужно было ещё почти год назад: проверил отображение в других браузерах. FF, Chrome - отображали корректно. В итоге выяснил, что проблема возникает в Brave (проверял на версиях 1.85.118 и 1.89.137) при включённом Brave Shields. Может ли настройка Brave Shield решить проблему не знаю - сходу не разобрался.

Открытый проект Translate Books with LLMs позволяет быстро переводить целые книги или большие на разные языки. Проект использует ChatGPT, Gemini, Mistral и DeepSeek. Можно запускать переводчик локально через Ollama. Принимает любые типы файлов: EPUB, SRT, DOCX, TXT. Сохраняет форматирование. Переводит файлы на огромное количество языков и знает русский. После перевода также еще раз проходит по тексту для литературной шлифовки и комфортного чтения.

22 преля состоялся TechCommPod Online Meetup, а сегодня уже можно посмотреть его в записи!

• АРИНА БАЛЕРИНА рассказала, кто такие техписатели. Как понять, что это ваше. Как стать одним из них.

• ЕКАТЕРИНА ПАВЛОВА провела мастер-класс по созданию сайта-визитки в Gramax.

• ДМИТРИЙ РАЗВОЗЖАЕВ показал свой зоопарк из AI-агентов.

• КОНСТАНТИН МАКУШЕВ порассуждал про паттерны и антипаттерны в документации.

В самом конце наши замечательные спикеры поделились откровенными историями самых эпичных ошибок в своей карьере.

Если пропустили эфир —  не страшно, мы все записали и уже залили на две площадки:

• Youtube: https://youtu.be/5wvMrNh07IY

• VK Видео: https://vkvideo.ru/video-237909665_456239018

Если вы были в эфире (или после просмотра записи) — пожалуйста, заполните анкету обратной связи. Это позволит подготовить для вас другие интересные и полезные мероприятия: https://forms.gle/juvvvxPQEoVMZuz37

Продолжаю делиться граблями, на которые я наступил в Claude Code. Как я ловил API Error: Stream idle timeout - partial response received

Дисклеймер: кажется, что всё это можно было и не ловить — по крайней мере в более простых системах я такие ошибки никогда не видел. Но раз уж начал упарываться в агентов, то почему бы не наступить на все грабли.

Проблема такая: оркестратор собирает SEO-статью на 8 000 слов, отдаёт редактору, пробует сохранить. Через 30 секунд тишины: API Error: Stream idle timeout — partial response received

Файл создан, но обрезан на месте, где стрим ушёл в idle.

❌ Первая очевидная неверная гипотеза: большой Write

Значит надо резать на чанки. Снизил лимит 15 000 → 8 000 → 6 000 → 5 000. Таймаут повторялся. Значит, дело не в размере записи.

✨ Настоящая причина: пересборка текста

Оркестратор не копировал готовый текст субагента. Он его пересобирал: переоформлял, перенумеровывал 28 сносок, «причёсывал» заголовки. Пока модель думала над форматированием, токены в стрим не эмитились. API считал соединение мёртвым и закрывал.

Решение РАЗ: passthrough + чанки ≤ 3 000

Вводим правило rules/common/safe-file-save.md:

➡️ Субагент возвращает строку оркестратору. Оркестратор копирует её в Write байт-в-байт — без «улучшений».

➡️ Разбиение планируется один раз до первого Write, потом проходится механически.

➡️ Лимит 3 000 символов на Write/Edit — потолок, при котором стрим не уходит в idle при честном passthrough.

➡️ Перед каждым Edit — сообщение 💾 Чанк K/M…. Иначе пользователь видит тишину и прерывает.

Если таймаут повторяется на 3 000 — спуск на 1 500. Если и там падает — это сеть, не контент.

И Recovery для обрезанных файлов

Повторный Write поверх частичного файла затирает уже сохранённое. Поэтому:

➡️ ls — проверить, что файл есть

➡️ Read — измерить длину

➡️ Edit (append) с точки обрыва, чанки по 3 000

Никогда не стартовать Write заново по тому же пути.

⭐️ Вторая волна: редактор

После фикса записи таймаут вернулся на возврате субагента-редактора. Вход 18 000 символов, выход 18 000 переписанного текста + отчёт «до/после» + метрики. Prefill и генерация занимают десятки секунд без эмита токенов. Retry не помогал: корень — объём выхода.

Решение ДВА: diff-mode

Вводим правило rules/common/editor-diff-mode.md. Редактор возвращает не переписанный текст, а список правок:

=== EDIT id=1 op=replace === FIND: Данное решение является инновационным продуктом REPLACE: VK Cloud управляет инфраструктурой — от ВМ до managed-БД REASON: редполитика + инфостиль === END EDIT ===

Лимиты: ≤ 60 правок, FIND ≤ 300, REPLACE ≤ 500, суммарный выход ≤ 8 000. Оркестратор парсит блоки и применяет через Edit.

Матрица по длине для глубокой редактуры:

➡️ ≤ 4 000 → классический

➡️ 4 000 – 20 000 → diff-mode

➡️ > 20 000 → секционный (одна H2 за вызов)

Пороги ниже именно для тяжёлых режимов — они удваивают выход за счёт отчёта «до/после».

Что в итоге то:

Два источника одной ошибки: оркестратор переформатирует перед Write, редактор генерирует слишком много на выход. Лечатся по отдельности: passthrough + чанки для записи, diff-mode для правок. Recovery закрывает остаточные случаи, когда таймаут всё-таки прилетел.

Я вроде не курю, но захотелось.

Как всегда ссылка на канал. Подписывайтесь

Запилили TG-бота для склейки голосовух - https://t.me/voicemixbot

👍 Зачем.

1. Сложно наговорить длинную 3-минутную мысль за раз красиво. Вместо этого, ясно произнеси отдельные фразы по 5 сек друг за другом, продумав каждую.

2. Мысль приходит только на улице во время прогулки и с собой только телега, монтировать дома никто не будет, а итоговая цельная голосовуха с красивой мыслью нужна уже сейчас чтобы кому-то переслать.

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

🧰 Как пользоваться.

1. Заходим в @voicemixbot - ему уйдёт команда start.

2. Шлем голосовухи друг за другом. После каждой видим ADD N, где N - её порядковый номер (начиная с нуля). Это значит, голосовой кусок вставился в ряд. Не говори следующую голосовуху, пока не получил ADD.

3. Удалить последнюю голосовуху - pop. Когда понял, что последней голосовухе нужен новый дубль. Вернёт SIZE N, где N - новое общее число эпизодов в проекте.

4. Всё сказал: пишем makeили go. Получаем цельный файл. Забыл что-то сказать - докидываем голосовух в конец и снова make .

5. Пишем clear если надо начать новый файл.

💎 Команды.

• clear - забыть всё, начать новый проект

• info - статус текущего проекта

• make - склеить текущий проект (цепь голосовух) в один файл

• name TEXT - указать название TEXT для вашей итоговой записи

• pop - удалить последнюю голосовуху из стека

• amp 1 или amp 0 - включить или выключить автоусиление тихой речи.

• bitrate N - установить битрейт, где N - между 2000 и 50000
23000 - достаточно для прилично звучащей речи

• mk N MESSAGE - поставить текстовую метку MESSAGE перед куском номер N. Нумерация с нуля. N - это тот номер, который фигурирует в ответе "ADD"

• fade N, N - число миллисекунд: длительность плавного перехода между фразами.

Метки.

00:00 - Приветствие
00:21 - Музыка
00:31 - Новости
01:04 - О погоде

Чтобы получить такую таблицу временных меток под записью, отправляй нужный текст перед той голосовухой, на начало которой этот текст должен ссылаться. Текстом считается любой текст, которого нет в таблице команд. Если вы хотели поставить метку перед уже отправленной голосовухой, но забыли это сделать, то используйте команду mk N (см выше).

🔌 Технические детали.

Кодируем речь кодеком OPUS, он прекрасно звучит даже на битрейте 24k, где mp3 бы уже умер. "/" в начале команды не важен. /pop и pop работают одинаково. Цепь голосовух мы называем "проект". У каждого проекта есть уникальное случайное служебное имя вида d7_uaUcUXc0. Помнить его не надо. Команда clear создаёт новый проект с новым именем, забывая предыдущий навсегда. Лимит кусков в проекте - 200, но лучше не рисковать. make 13 минутного файла будет работать 3 минуты. Написано на голимом C++20, libopus, libogg, epoll.

⌛ Лимиты.

1. Одна голосовуха - не более 60 секунд.

2. Число голосовух в проекте - 200 штук.

3. Получается суммарно более 2 часов на один файл, но стало страшно. В будущем возможно порежем лимит результирующего файла чем-то на уровне 10 минут.

🔒Безопасность и надёжность.

clear удаляет голосовухи с сервера бота. Бекапов нет. ФС сервера - в ramdisk. Наговорил, скомпилил - забери себе, не растягивай проект на неделю. Сервер не стабилен, падает раз в неделю с переналивом всей OS с нуля. У админа доступ ко всем голосовухам (как у админы телеграм к личкам), но чаще падает сервер с данными, чем админу охота покопаться. Если придёт майор с бутылкой - всех сдадим, но рамдиск (может быть уже нечего). Метаданные о пользователях не собираем, спамить не будем - даже БД нет. Точнее, есть, но в рамдиске. Если сервер не отвечает, то он либо сдох и ему скоро автоматически нальют образ по вотчдогу, либо занят компиляцией чьего-то проекта - отправь команду info и подожди. Устраивать DoS и хакерство с отправкой гиговых видосов и фоток не надо: бот даже не начнёт качать. В целом, наверное вы можете его положить, но мы просто пнём сервак и он забудет всё плохое в жизни, рамдиск же.

https://t.me/voicemixbot в общем.

GEO - оптимизация контента под ИИ. Как это делать?

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

По прогнозам Gartner (исследовательская компания с фокусом на IT) в 2026 году объём традиционного поиска упадёт на 25% из-за перехода пользователей на ИИ-ответы. Так что сейчас - самое время работать с контентом так, чтобы он был удобен для ИИ, сохраняя при этом смысл и ценность. Конечно, привычная нам органика из поисковика никуда не уйдет и не будет полностью заменена платным размещением, она изменится. Но одного SEO будет уже не достаточно (хотя это и не новость!).  

Техническая база оптимизации сайтов остается прежней. Но помимо классического SEO, мы подстраиваем контент под генеративный поиск, чтобы из него легко извлекался конкретный ответ, приводим в соответствие Schema-разметку, усиливаем E-E-A-T сигналы (авторство, экспертность, источники), насколько удается закрываем тему семантически (не ключевыми словами, а полным раскрытием намерения пользователя).

Теперь мониторим: цитируют ли нас ChatGPT,Perplexity и другие Ai по целевым запросам клиента. Это новая актуальная метрика видимости, и для неё уже существуют свои инструменты. 

GEO быстро меняется, но расскажу, какие моменты на сегодняшний день могут быть интересны: 

1)ИИ предпочитает скучные тексты. Чем проще и прямолинейнее написан абзац, тем охотнее его цитируют нейросети. Не нужно никаких длинных подводок. Желательно чтобы ответ на тот вопрос, по которому вы хотите "выдаваться", был сформулирован у вас на сайте уже в первом абзаце.

2)Ссылки на чужие (проверенные!) источники помогают. Если в тексте ссылаться на исследования, статистику, авторитетные источники, то ИИ цитирует чаще.

3)Эффект “Википедии”. Страницы, которые структурно напоминают “Википедию” - определение, подразделы, конкретика - цитируются лучше обычных. ИИ обучали в том числе и на популярной интернет-энциклопедии. 

4)Используйте в тексте конкретные цифры. Это достаточно просто, но добавляет вашему тексту достоверности в глазах ИИ.

5)ИИ любит цитировать авторов и бренды, которые ассоциируются с тематикой. И еще, если название компании или продукта часто встречается рядом с конкретными утверждениями (на разных площадках, авторитетных и не очень), ИИ начинает ассоциировать бренд с темой.

6)Корпоративный контент для ИИ - это хорошо, но лучше цитируется контент с указанием автора, его должности, опытом и тд. (E-E-A-T сигналы).

Пример:

Как может звучать в обычном тексте:

"Для пошива обуви по индивидуальным меркам мы рекомендуем измерять параметры стопы в вечернее время: так можно узнать максимальные размеры”. 

Как может звучать эта же фраза, оптимизированная для ИИ-поиска: 

"Как говорит технолог нашей компании Ольга Петрова, которая более 10-ти лет занимается пошивом обуви по индивидуальным меркам, самые точные измерения стопы получаются в вечернее время. Стопа немного отекает, и можно уловить ее максимальный размер”.

Пробовали ли вы оптимизировать свой контент под ИИ-выдачу? Делитесь в комментариях! 

Исследователи из Nous Research опубликовали Autoreason — работу о том, почему итеративное самоулучшение LLM ломается на практике, и как это починить. Тема актуальная: все мы пытались строить агентов по схеме «сгенерируй → покритикуй → перепиши», и у всех это работало хуже ожиданий.

Авторы выделили три структурные проблемы примитивного подхода.

➡️ Искажение от формулировки — модель галлюцинирует недостатки, когда её прямо просят критиковать (ну конечно, она же не может сказать «всё хорошо»).

➡️ Расползание задачи — тексты бесконтрольно разрастаются с каждым проходом, теряя фокус.

➡️ Отсутствие сдержанности — модель никогда не говорит «изменения не нужны», хотя часто это правильный ответ.

На Haiku 3.5 традиционная критика-и-ревизия сжимала выдачу на 59-70% за 15 итераций — чистая деградация.

Их решение: на каждой итерации генерировать три версии — неизменный инкумбент (A), состязательную переработку (B) и синтез (AB). Судит панель свежих агентов без общего контекста через слепое голосование по методу Борда, где вариант «ничего не менять» равноправный кандидат. Каждый судья ранжирует все три варианта, за первое место даётся больше баллов, за последнее — меньше. Если исходный вариант выигрывает дважды подряд — стоп, сходимость.

По Claude-линейке результаты сильные: Sonnet 4.6 на задачах программирования показал 77% против 73% у однократной генерации, Haiku 3.5 с новым методом обогнал выбор лучшего из 6 вариантов при равных вычислительных затратах (40% против 31%). Но самое интересное — точка перелома на Haiku 4.5: при 60% точности прирост от доработок исчезает. Разрыв между способностью генерировать и оценивать закрылся, итерации стали бесполезными.

Практические выводы для агентов в Claude Code: роли критика, автора и синтезатора должны быть отдельными агентами с независимым контекстом, иначе получишь искажения. Всегда включай опцию «оставить как есть» в список возможных действий. Используй несколько судей (минимум 3, лучше 7) для принятия решений о редактуре. И самое главное — с сильными моделями (Haiku 4.5+, Sonnet 4) можно не заморачиваться с итерациями вообще, однократной генерации часто достаточно.

Короче, если твой агент в Claude Code делает хуже после «улучшений» — это не баг, а особенность примитивного самоулучшения. Autoreason показывает, как это лечить правильно, но на современных моделях проблема может быть уже неактуальна.

Оригинал и больше такого у меня в канале