Недавно я рассказал на Хабре, как сделал собственного цифрового аватара и создал серию коротких роликов для озвучки своих текстовых заметок.
И почти сразу после публикации мне предложили адаптировать разработку под контент-завод. Для тех, кто не в курсе: это когда контент производится вообще без участия человека.
Технически до такого режима оставалось не так много: генерировать текст, синтезировать голос, автоматически подбирать слайды и передавать всё моему сборщику. На входе — тема, на выходе — готовый ролик.
У меня даже в коде были предусмотрены переменные для замены содержимого слайдов. Но в какой-то момент я сам ударил себя по рукам и перестал разрабатывать эту часть системы.
Потому что смысл моего проекта — автоматизировать всё скучное, чтобы у автора оставались силы на творчество.
А контент-завод делает ровно наоборот.
Человеку он оставляет KPI, воронку и план публикаций, а машине отдаёт мысль, голос, текст и шутки. И, по-моему, это какой-то бред: освобождать человека от необходимости присутствовать в собственном высказывании.
Это буквально «мёртвый интернет» в действии.
Автоматизировать можно почти всё, но не причину, по которой контент вообще должен существовать.
В нормальной фантастике о будущем машины забирали у человека рутину, чтобы ему оставалось творчество. А мы почему-то упорно строим будущее, в котором человек заполняет таблицу с лайками, пока машина творит за него.
И кажется, Булычёв и Стругацкие завещали нам немного другое.
Мы на Хабре запустили исследование о том, как технический контент влияет на решения инженеров. Наша цель — сравнить взгляд тех, кто создает контент, и тех, кто его читает: какие материалы вызывают доверие, влияют ли они на выбор вендора или работодателя и где ожидания авторов расходятся с реальностью.
Параллельно проводим такой же опрос среди инженеров, а по итогам подготовим большое исследование, где сравним взгляд обеих сторон.
Если вы работаете с контентом для продвижения технологий, продуктов или HR-бренда среди инженерной аудитории, приглашаем пройти анонимный опрос.
Опрос займет 10-15 минуты, но очень поможет исследованию.
Андрей Карпатый из пузыря OpenAI чуть больше года назад сказал: «Я полностью принял вайбкодинг, где забываю, что код вообще существует. Я просто вижу то, что хочу, говорю ИИ, и оно появляется». Сейчас вайбкодинг уже обозвали «методом программирования». Видимо, ждём гуманитарные диссертации на тему «Эволюция программирования: неструктурированное, процедурное и модульное, объектно-ориентированное и вайбкодинг».
Опыт подсказывает, что если жизнь в одном месте стремительно упрощается, то в другом — катастрофически усложняется. Поэтому разберём высказывание товарища Карпатого, поищем, где зарыты мины.
Забываю, что код существует Чтобы толком что-то навайбкодить, сначала хорошо бы писать код самому. Иначе забывать нечего, и человек просто не поймёт, что можно забыть, а что — лучше не надо. Это как езда на велосипеде: сначала следишь за каждым движением, чтобы получить навык и только потом забыть.
Если взялся вайбкодить, будь готов забыть то, что знал. Программисты с безлимитными токенами сами признаются, что забывают, как писать код руками. Помните, в школе после летних каникул забывали, как пишутся буквы? Вот-вот.
Вижу то, что хочу Если я вижу айфон, но не представляю, как он устроен изнутри, то что я вижу? Кирпич из стекла и металла. Если вайбкодер не понимает, как его хотелка устроена изнутри, то с ненулевой вероятностью получит такой же кирпич.
Говорю ИИ Грамотно написанный промпт для ИИ может оказаться длиннее готового кода. Можно с первого раза получить достаточно качественный код, но для этого нужно потратить на инструкцию не меньше времени, чем ушло бы на код вручную. А потом долго договариваться с ИИ, чтобы исправить ошибки. Потому что галлюцинации никуда не делись: ИИ игнорируют инструкции, тянут не те библиотеки, подключают не те сервисы и вообще всячески косячат.
И оно появляется Вот именно, что оно: смотрите на иллюстрацию, а для тех, кто не владеет парсалтангом, расскажу, что навайбкожено.
ИИ попросили подключить в проект антивирусную проверку. Он запустил контейнер с антивирусом, и если не присматриваться, то антивирус работает. Но там, где файл нужно отправить на проверку, в переводе на человеческий, написано:
загляни в файл;
если файл не пустой, напиши, что он проверен;
если пустой, напиши, что он заражён вирусом.
Антивирус живёт сам по себе, а файл, который надо проверить на вирусы, проверен на наполнение. Чтобы найти эту «мелочь», нужно знать, как всё работает, и потратить кучу времени.
Так что, если вайбкодите, не разбираясь в программировании, то хакеры уже идут к вам.
Писатель, аналитик и немного администратор: сколько стоит такая роль?
Продолжаю разбирать вакансии, связанные с управлением знаниями и технической документацией. Сегодня смотрим позицию писателя базы знаний в Яндекс 360. Вакансия описана достаточно подробно, но границы роли и предлагаемая зарплата вызывают вопросы.
Дисклеймер. Я больше 15 лет внедряю менеджмент знаний в российских компаниях. Запустил эти разборы, чтобы работодатели могли увидеть спорные места в вакансиях, а специалисты – точнее оценить задачи и подготовиться к собеседованию. Анализирую только опубликованные тексты, а не реальные процессы внутри компаний.
Начну с плюсов
Понятно описаны задачи. Кандидату предстоит писать и обновлять инструкции, следить за изменениями в продуктах, работать с метриками и развивать базу знаний. Уже по тексту можно составить общее представление о работе и сопоставить её со своим опытом и интересами.
Требования логично связаны с обязанностями. Компания ищет не просто автора текстов, а специалиста, который умеет разбираться в процессах, структурировать информацию, общаться с внутренними заказчиками и работать с данными.
Основные условия указаны. Сотрудника оформляют на полную занятость. Указаны зарплатная вилка, квартальная премия, компенсация амортизации личного оборудования, оплачиваемое обучение. Также заявлена возможность развиваться и переходить на другие позиции.
Удалённый формат. График известен заранее – с 10:00 до 19:00 мск. Для многих кандидатов возможность работать без привязки к офису по-прежнему остаётся важным преимуществом.
Дальше начинаются вопросы
Первый – срочные запросы. В вакансии не объясняется, как часто они возникают и укладываются ли в обычный график. Лучше заранее уточнить, нужно ли оставаться на связи после 19:00 или в выходные.
Второй – зарплата. В вакансии указана вилка от 55 до 85 тысяч рублей в месяц до вычета налогов. На мой взгляд, она выглядит скромно для заявленного набора обязанностей: кроме подготовки текстов, сотруднику предстоит заниматься аналитикой, взаимодействовать с внутренними заказчиками, развивать структуру базы и работать с инструментами поддержки.
Третий – границы роли. В одной позиции объединены разные функции. При этом непонятно, какие задачи будут основными и за какие результаты сотрудник отвечает лично.
Четвёртый – мало информации о команде. Не указаны размер команды, распределение обязанностей, рабочие инструменты и траектория профессионального развития.
Мой вывод
Вакансия может подойти специалисту из поддержки, обучения, аналитики или контента, который хочет перейти в управление знаниями и поработать с крупным IT-продуктом.
Здесь есть официальное оформление, удалённый формат, чёткий график и возможность получить опыт работы с текстами, метриками и структурой базы. Перечень задач понятен, но их приоритеты и границы ответственности не обозначены.
Для специалиста из смежной области это может быть хороший, хотя и довольно интенсивный старт. Кандидату с опытом в управлении знаниями стоит внимательно сопоставить зарплатную вилку с фактическим объёмом задач.
Перед откликом стоит уточнить:
как распределяется время между текстами, аналитикой и развитием базы;
сколько человек работает в команде и как разделены обязанности;
какие платформы и инструменты используются;
что входит в настройку и автоматизацию инструментов поддержки;
как часто возникают срочные задачи и требуют ли они работы вне графика;
от чего зависит сумма внутри вилки и как рассчитывается премия;
каких результатов ждут от сотрудника в первые три месяца.
Я веду свой телеграм-канал про управление знаниями, делюсь в нём граблями из проектов для лидеров рынка: Банк СПб, Билайн, Делимобиль, Купер, МЭС и других. А ещё рассказываю про ИИ-находки для дома и не только. Подпишитесь, чтобы не пропустить следующие посты.
Недавно меня приглашали рассказать про 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/
А как прошла последняя встреча в офлайне, я совсем скоро расскажу в статье. Немного терпения, господа!
Это легендарные участники творческой встречи корп авторов офлайн, прошедшей 24 июня
Хабр и коммуникационное агентство FRC проводят двойное исследование о том, как технический контент влияет на решения инженеров. «Мы хотим сравнить взгляд тех, кто создаёт этот контент, и тех, кто его читает», — пояснили организаторы опроса.
«Разбираемся, как инженеры в промышленности выбирают работодателей и поставщиков, каким источникам и техническому контенту доверяют, а каким — нет. И сравниваем это с тем, как компании выстраивают коммуникацию с инженерами — какие задачи решает контент, как он формирует доверие к экспертизе и продуктам, и что в итоге работает», — уточнили в Хабре и 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 Креативный нетворкинг. Вместе генерим идеи для будущих статей.
Кажется, маркетологам, PR-специалистам и контент-командам в последнее время приходится решать одну и ту же задачу: как бренду быть в поле зрения клиентов, когда привычные каналы коммуникации теряют эффективность?
24 июня в 17:30 этот вопрос обсудят эксперты Pressfeed и Хабра на бесплатном вебинаре «Продвижение по новым правилам».
Вместе разберемся:
Как оставаться в инфополе в условиях сокращения бюджетов;
Почему количество публикаций уже не гарантирует результат и на что стоит делать ставку вместо этого;
Как перестроить работу со СМИ, если акцент сместился к аналитике и глубокой экспертности;
Как работать с экспертной коммуникацией как с инструментом продвижения бренда;
И почему эксперты-скептики — ваши лучшие амбассадоры.
Своим опытом поделятся Татьяна Кузнецова, руководительница Академии Pressfeed с более чем 25-летним опытом работы в PR, маркетинге и коммуникациях, и Ирина Лосева, ведущий редактор-эксперт Хабра.
Как я превращал свалку заметок в библиотеку для ИИ-агентов
База растёт сама из работы над контентом. Под каждый материал агент сначала делает исследование: идёт в веб, собирает данные, цифры, источники. Конспект сразу сохраняется в research/ под конкретную статью — это страховка от потери данных, если сессия оборвётся. Важный момент: исследование сохраняется автоматически, ещё до того, как автор начал писать.
Дальше срабатывает правило: перед новым ресёрчем агент обязан проверить, что уже собрано. Если по теме что-то есть, он это дополняет, а не пересобирает с нуля. А самое ценное и многоразовое из разовых исследований переезжает в постоянную базу. Так разовый сбор под одну статью со временем превращается в библиотеку, которой пользуются все агенты.
Звучит красиво, но было три проблемы:
— агент порой не знал, что в базе уже есть инфа, и искал заново; — мог взять устаревшую цифру, потому что никто не помечал, когда факт «протух»; — в документации написано «агент смотрит в базу», а в коде этого нет.
Слои: от свалки к полкам
Факты хранятся по-разному, в зависимости от роли. Большие документы разбил на атомарные карточки:
— fact-card — один проверяемый факт = одна карточка. С источником, уровнем доверия и сроком годности. — case-card — один публичный кейс клиента, и что про него говорить нельзя. — objections — карточка возражения («облако дороже») с готовым безопасным ответом. — personas — карточки аудиторий: боли, KPI, запретные углы.
Зачем дробить? Большой текст легко выдаёт лишнее — непубличную деталь или старую цифру. Атомарная карточка хранит ровно один факт. Просрочилась — система сама её отложит.
Интеграции: появился библиотекарь
Полки — это полдела. Дальше нужен тот, кто приносит нужное:
— Картотека плюс ретривер в коде: даёшь тему — получаешь короткий список релевантных карточек, просроченные помечены. — Компактная коробка вместо всей базы. Агенту едет не дамп на пол-базы, свежие факты, публичные кейсы, и список того, чего в базе нет. — У каждого типа задач своя карта. Не «загляни в базу», а «для пресс-релиза бери позиционирование и публичные кейсы, а конфиденциальные числа только после проверки». — Починил пайплайн. Шаги, которые раньше были красивым описанием, заработали: повторный фактчек сомнительных цифр реально запускается, а 19 ресёрчеров наконец получили веб-поиск, которым «просили» пользоваться.
Предохранитель на финале
Последний шаг любого пайплайна — редактор. Берёт только разрешённые к публикации карточки, а просроченные не пускает в текст. И всё закреплено тестами: рассинхрон «база — агент» теперь роняет сборку.
Что в итоге
Конечно, это не очень обязательный элемент фабрики контента. В воркфлоу записано, что надо найти, передать, написать, проверить. Всё в чистом контексте и галлюцинаций в финале не остаётся. Но каждый запрос это токены и время. И деньги. А запросы повторяются, в конце концов мы крутимся вокруг одних и тех же цифр исследований, бенчмарков, фактов. Поэтому постепенно наполнять базу знаний и оперативно обращаться к ней кажется не такой уж плохой идеей. Стоит потратить на реализацию несколько вечеров.
Два года назад из идеи поддержать начинающих авторов, случайно возникшей во время разговора с моим руководителем, родился целый проект - живые творческие встречи с авторами Хабра в нашем офисе, которые мы назвали "Авторский огонёк". Сейчас планируется уже четвертая встреча. Наша цель остается прежней - вдохновить и замотивировать начинающих авторов, снять их боли и страхи, поделиться полезной информацией, которая поможет им в написании статей и передать из рук в руки классные рабочие инструменты по поиску тем, придумыванию заголовков и новых форматов. Если интересно, как прошла наша встреча в ноябре прошлого года - читайте тут.
Самое ценное, что на таких встречах всегда присутствуют опытные авторы, готовые делиться своими историями, лайфхаками, секретами и советами, а также легенды и просто сотрудники Хабра, которым можно задать любые вопросы.
В июне мы снова планируем провести творческую встречу корпоративных авторов Хабра! Это уже стало доброй традицией, которая объединяет вокруг себя все больше горящих творческих душ. На встрече как всегда обсудим самые важные и актуальные темы: страхи, боли, проблемы, поиски себя и своей ниши, работу с комментариями и многое другое.
! И пока мы только формируем программу, ваши вопросы идеи и предложения будут как нельзя кстати)
Какие темы и вопросы хочется обсудить, какие творческие активности были бы интересны и полезны в формате этой встречи? Поделитесь, пожалуйста, своим мнением в этой анонимной форме https://forms.gle/vQbXZe1d9qcSjxwG6 Также вы можете оставлять идеи в комментах или писать в личку, я всегда открыта для общения!
Кстати, подробнее об этом проекте я хочу рассказать в отдельной стате, которую обещаю скоро опубликовать) Ссылка на регистрацию участников тоже скоро будет, следите за новостями! Если вы - корпоративный автор, тоже пишете на Хабр или только планируете выходить сюда со своими публикациями - будем рады вас видеть! А если вы - опытный автор - приходите вдохновлять новичков своим примером, поделитесь своими историями и лайфаками!
В американском стиле используются двойные типографские кавычки “ ”, в британском одинарные ‘ ’, а в технической документации прямые " ". В американском стиле знаки препинания ставятся внутри кавычек, в британском исходя из смысла. Но часто даже в американских блогах и технических книгах знаки ставят по смыслу, а не внутри.
Апостроф есть прямой ' и типографский ’. Для статей и постов рекомендуется использовать типографский апостроф. Хотя если посмотреть популярные новостные издания или блоги крупных технологических компаний, можно заметить, что у них даже в одной статье могут быть смешаны типографские и прямые апострофы и кавычки. Некоторые ИИ агенты не умеют использовать типографские символы и заменяют их на прямые.
Всегда удобнее ставить прямые кавычки, чем зажимать 3 клавиши для типографских. Тем более в прямых одинаковый символ для открытия и закрытия кавычек, а в типографских разные. На ноутбуке можно настроить умную автозамену на типографский вариант, но большинство программ игнорируют эту настройку. Если вы пишете на разных языках или под разный стиль, то умная замена не поможет. Можно настроить скрипт для автозамены перед публикацией статей, но если в статье содержатся примеры кода, то в них нельзя делать замену. Можно перед публикацией вручную заменять на типографские, но при ответе на комментарии снова будут прямые. Есть шрифты, которые красиво отображают прямой апостроф, но шрифт контролируешь только на своем сайте. Некоторые сайты при наборе текста автоматически заменяют на типографские знаки, но если делать вставку текста, то в нем оставляют прямые.
YouTube начал требовать отключить средства обхода блокировок для просмотра видео. Ограничение касается каналов с жёсткими региональными правами на контент: в первую очередь спортивных — «Формула 1», некоторые футбольные лиги, отдельные музыкальные лейблы. Это каналы, где рекламодатели платят за показы в конкретных странах, а правообладатели продают лицензии по регионам. YouTube обязан контролировать, из какой страны смотрит зритель, — иначе нарушаются условия лицензий.
Для обычных видео — летсплеев, обзоров, подкастов, авторского контента — ничего не изменилось. Средства обхода блокировок работают как прежде. Явление касается единичных каналов с крупными медиапартнёрами и существует уже не первый год — просто периодически всплывает у новых пользователей и вызывает волну тревоги.
Маркетологи и пиарщики, привет! А вас не бесит, когда запускаешь кампанию в новом канале, где аудиторию понимаешь только примерно — и в итоге тратишь время, бюджет и нервы напрасно? В партнёрской программе Хабра всё иначе: вы сначала узнаёте, кто нас читает, какие форматы есть и для каких задач они подходят, а уже потом предлагаете Хабр клиентам.
К своему 20-летию Хабр обновил партнёрскую программу для коммуникационных, рекламных и других агентств, которые помогают клиентам решать имиджевые, продуктовые и HR-задачи.
Если коротко: это программа для тех, кто хочет лучше понимать аудиторию Хабра, быть в курсе всех рекламных форматов, увереннее предлагать их клиентам и получать за это агентское вознаграждение.
Сейчас идёт набор в партнёрку, а уже 9 июня начнётся обучение. За несколько дней команда Хабра расскажет, как устроена аудитория площадки, какие рекламные решения работают под разные задачи и как подбирать форматы под запрос бренда.
В программе:
— разбор 10+ рекламных форматов Хабра; — кейсы компаний из разных сегментов: «Норникель», «Самолёт», LaVivion, VIVO, «СМ-Клиника», «Гемотест», «Островок» и других; — обучение по работе с брифом, аудиторией и подбором форматов; — сертификат эксперта по Хабру для агентства и участников обучения.
После обучения агентство получает статус партнёра. А вместе с ним — возможность получать агентское вознаграждение от 10% до 30%, бесплатные блоги на Хабре, рост партнёрского уровня и доступ к совместным ивентам, обмену лидами и мероприятиям Хабра.
Подать заявку можно до 3 июня. Следующий набор — не раньше октября.
Одна из самых недооценённых вещей в базе знаний — нормальные названия статей.
Не 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. Сохраняет форматирование. Переводит файлы на огромное количество языков и знает русский. После перевода также еще раз проходит по тексту для литературной шлифовки и комфортного чтения.
