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

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

Настало время поделиться с миром моим вариантом.

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

Ловите:

Работай по этим правилам, без исключений.

# ОБЩИЕ ПРИНЦИПЫ
- Не придумывай данные, события, источники или чужие мнения без запроса.
- Если чего-то не знаешь — прямо пиши «не знаю».
- Приоритет — точность и логика, а не красивая подача.
- Мнение допускается только при уместности: 1–3 предложения, пометка «моё мнение», строго отделено от фактов.
- Перед ответом оцени запрос и выбери подходящую роль эксперта. Если роль нетривиальна, отвечай от её имени и укажи её явно.
- Если используется web-поиск, приводятся факты/данные (даты, числа, версии, имена, цитаты, статистика) или делается предположение — указывай основание ответа.
- Не скрывай ограничений. Если задача невозможна — так и скажи.
- Задавай уточняющие вопросы только если без них возможны принципиально разные ответы:
    - если без ответа нельзя дать корректный ответ, остановись и задай вопрос;
    - если можно дать базовый безопасный вариант, дай его и задай вопрос в конце.
- Указывай, если информация неточная, устаревшая или неполная.
- Явно помечай предположения и аналогии.
- Если вставляешь web-ссылку, предварительно проверь её доступность.
- Минимизируй использование тире и списков.

# КАКИЕ ОТВЕТЫ Я ЖДУ
- По умолчанию: краткие, прикладные, без «воды» и объяснений очевидного.
- Поэтапные, если запрос сложный.
- С вариантами, если есть фундаментально разные подходы.
- С пояснением, если ответ неоднозначен.

Если у вас есть интересные варианты, чем дополнить — велкам в комменты

Через неделю встречаемся, будем обсуждать использование AI в создании контента. Этика, подходы, нейронки, все дела. Букайте время в календарях:

Четверг, 25.12, в 20:00

Попозже накидаю подробную повестку

Напоминаю, что через сутки встречаемся.

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

Ссылку кину завтра, ближе ко времени.

Шарьте всем причастным

Готовность три часа. Звонок будет в православном Телемосте, если планируете вещать, ставьте приложение — в вебе он порой ведёт себя непредсказуемо. Ссылка будет минут за пять до начала.

Зовите всех, кто работает с контентом: собственным или внутри продукта. Будет интересно, гарантирую

Залетаем через 5 минут. Комменты будут под этим сообщением

Неплохой перевод статьи о важных аспектах общения с ChatGPT 5.2, есть несколько довольно занимательных примеров промптов.

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

Прикладное использование иишек всё пресказуемее

Как заставить ИИ работать с проектной (и не только) документацией.

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

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

Ответ есть уже довольно давно. Ещё в 2020м исследователи одной запрещённой соцсети опубликовали статью про RAG (Retrieval-Augmented Generation). Это такой подход, при котором ИИ не полагается на одну только память, а сперва ищет информацию во внешнем хранилище — и только потом формирует ответ на основе найденного.

Давайте на примере библиотеки и библиотекаря.

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

Библиотекарь — это RAG-логика поверх LLM. Когда ты задаёшь вопрос, библиотекарь не бросается отвечать сразу. Он сперва выявляет суть твоего вопроса, идёт в библиотеку, ищет релевантные книги и даже страницы в них. Он достаёт конкретные абзацы, а не перебирает всю книгу целиком. И только после этого он возвращается и отвечает. Библиотекарь не обязан знать ответ заранее. Он должен уметь искать и пересказывать.

Почему это принципиально важно?

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

Как выглядит запрос в RAG-логике:

Ты спрашиваешь у своего ИИ: «Какие риски могут сработать при изменении формы регистрации юрлиц в нашем продукте?»

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

Если в библиотеке нет нужной книги, твой библиотекарь скажет об этом.

Почему RAG — не просто «поиск + ChatGPT».

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

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

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

Навигация по постам в канале:

2023-12-31 Проверка зрения дизайнеров
2024-01-21 Баги будут
2025-04-29 Последствия неочевидных ошибок
2025-05-03 CJM и иллюзия контроля
2025-05-05 Техдолг и тротил под фундамент проекта
2025-05-15 Культ метрик и чем он чреват
2025-05-25 Менторство
2025-06-09 UX vs CX: кто кого включает
2025-07-18 PO, PM, PjM: кто такие и при чём тут мыло, ракеты и застройщики
2025-08-23 Риски невидимых зависимостей
2025-09-01 ИИ, тире и ёлочки
2025-09-14 Внедрение методологий без саботажа
2025-09-19 Саботаж при внедрении методологий
2025-10-03 Метрики, которые убивают ваш продукт
2025-10-07 PoDPR: приоритизация для взрослых
2025-10-19 Обновление цикла про Информационную Архитектуру
2025-11-18 Гипотезы без риска и измеримости
2025-11-22 Рынок найма мутировал
2025-12-03 Кто не пишет с AI, пусть бросит в меня камень
2025-12-08 Семь лет Дизайну Данных
2026-01-03 RAG в документации на примере библиотекаря
2026-01-25 Почему не нужно боятся увольнения
2026-05-14 Personas и JTBD: два этажа одного здания

Очень честный и хороший выпуск про то, как и зачем писать хорошие тексты (и, конечно, про ограничения использования иишек)

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

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

Не переключайтесь

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

Но поиск новой работы всегда сопряжён с уходом со старой. А ведь уход — это тоже отдельная тема. Грамотное увольнение может содержать вас от трёх месяцев до полугода (а то и больше).

Я был по обе стороны увольнения: много раз сам увольнял и не меньше помогал другим уволиться на максимально выгодных условиях.

Давайте немного расскажу про то, почему вам не стоит бояться увольнения:

1. Вас никогда не уволят по статье. Просто поверьте. Если ваш начальник угрожает этим, смело шлите его. ТК РФ в этом отношении накладывает на работодателя такой пиздец, что ему намного проще пойти на соглашение сторон, чем идти через процессуальный ад.

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

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

Хотел ещё написать про то, как правильно выбирать работодателя и читать трудовые договоры. Или как увольнять так, чтобы все остались довольны. Но и так получается лонгрид. Вот вам вместо этого охеренный подкаст на тему увольнений.

Шарьте. И не переключайтесь

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

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

17-18 апреля буду выступать на конференции Merge в Иннополисе.

Тема сейчас максимально актуальная: «Приоритизация здорового человека: как учесть риски и обратимость». Расскажу, почему классические фреймворки иногда искажают картину и как PoDPR помогает выбирать инициативы, которые можно быстро и безопасно проверить.

Конфа обещает быть жаркой: 7 тематических направлений от разработки до маркетинга, 170+ спикеров, 10 одновременных потоков и нетворкинг.

По промокоду SHERER можно взять билет со скидкой 20%

Подробнее о конфе на сайте: tatarstan2026.mergeconf.ru

Подписчики из Казани и около: пишите, пересечёмся

Друзья, у меня открылась офигительная позиция для сильного дизайнера в мой проект. Ниже — вакансия от нашего дизайн-лида:

Уровень: Middle+

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

Задача: изучать потребности пользователей, проектировать клиентскую логику и интерфейсы. Принцип: сильный UX, простой UI. В первую очередь веб, в меньшей степени мобильные платформы.

Коротко: нужно быть больше ux-инженером, чем ui-дизайнером. Вы умеете быстро погружаться в сложный контекст, разбирать его на винтики, и планомерно превращать в решения. Желательно иметь минимальную техническую грамотность – например, вы понимаете принцип работы браузера, можете объяснить, как работает кнопка “войти через VK ID”.

Скиллсет:
- Фреймворки CJM и JTBD.
- Функциональная, информационная и навигационная модели интерфейса – вы знаете что это, можете собрать, и объяснить что с этим делать дальше.
- Собирать и описывать функциональные сценарии и user flow с учётом слоя системной логики.
- Проектировать интерфейсы (от простых до сложных, и можете объяснить почему интерфейс должен быть именно таким).
- Можете собрать библиотеку компонентов в фигме и собрать с ее помощью простой функциональный UI.
- Исследовать и проектировать с помощью AI.

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

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

Если к кому-то не вернулись с обратной связью, прошу понять и простить напомнить к середине следующей недели

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

Это первая из двух статей, вторая будет про развитие Job Story из User Story, не переключайтесь