Мы строим AI-продукт для людей, которые не знают слово «промпт». И это самое сложное
У нашего клиента нет DevOps-инженера. У нашего клиента нет CTO. У нашего клиента иногда нет человека, который знает, как обновить WordPress.
Наш клиент — главред региональной редакции. Ей 42. Она ведёт пять рубрик, управляет тремя журналистами, выкладывает тексты на сайт, в Telegram и Дзен. Её рабочий инструмент — Google Docs и принтер, который вечно жуёт бумагу.
И вот для этого человека мы строим AI-систему с мультиагентным пайплайном, векторной базой, фактчекером с веб-поиском и декомпозицией стиля на аспекты.
Звучит как издевательство. Но это единственный способ сделать продукт, а не демо.
Искушение №1: дать пользователю всё настроить
Когда ты разработчик AI-продукта, первый инстинкт — дать максимум контроля. Пусть пользователь:
- Подключит свои источники новостей
- Настроит парсеры
- Выберет модель
- Напишет промпт для стилизации
- Настроит фильтры по темам
- Задаст расписание публикаций
- Подключит Telegram-бота
No-code платформа! Гибкость! Пользователь сам решает!
Знаете, что произойдёт? Пользователь откроет этот дашборд, посмотрит на 15 полей настройки, скажет «у меня на это нет времени» и закроет вкладку. Навсегда.
Мы это знаем, потому что мы провели 15 интервью с главредами региональных СМИ. Вот что они говорят:
— «Я не хочу разбираться в настройках. Я хочу текст, который можно опубликовать.»
— «У меня 10 минут между летучкой и дедлайном. Если за 10 минут не пойму — до свидания.»
— «Нам предлагали CRM, конструктор сайтов, систему аналитики. Всё стоит. Потому что настраивать некому.»
Искушение №2: начать с парсинга
Логичная мысль: раз мы делаем рерайт новостей — давайте сразу подключим все источники. ТАСС, РИА, региональные сайты, Telegram-каналы, RSS, пресс-релизы на почту, VK-группы администраций.
Серёжа на совещании сказал кратко: «Охренеем».
И он прав. У каждого издания — свой набор источников. Городской портал в Самаре читает одно, областная газета в Новосибирске — другое. Московские каналы, местные пресс-службы, свои информаторы.
Универсальный парсер всех источников — это отдельный продукт. Со своей командой. Со своими проблемами. С кучей edge cases, которые будут ломаться каждый день.
А мы — команда из четырёх человек, и нам нужно запуститься.
Два экрана. Всё.
Вот к чему мы пришли.
Экран 1: Загрузи статьи своего издания. Нажми «Обучить стиль».
Экран 2: Входящие новости → рерайты. Читай, правь, публикуй.
Всё. Два экрана. Никаких дашбордов. Никаких настроек парсеров. Никаких «выберите модель и temperature».
Под капотом — пять агентов, векторная база, фактчекер с доступом в интернет, стилевые профили с декомпозицией на аспекты. Пользователь этого не видит. Пользователю это не нужно. Пользователю нужен текст, который можно опубликовать.
Правило 80/20, которое мы применяем буквально
Невозможно закрыть все потребности всех клиентов. Можно закрыть 80% потребностей 80% клиентов — и сделать это без усилий с их стороны.
Вот как это выглядит на практике:
Источники новостей. 80% региональных СМИ берут новости из одних и тех же федеральных агентств (ТАСС, РИА, Интерфакс) + 3–5 локальных источников. Для беты мы спрашиваем у клиента его список и настраиваем парсинг вручную. Клиент просто видит готовые рерайты.
Загрузка обучающих статей. Копипаст через UI. Да, руками. Да, это 20 минут работы один раз. Если у клиента есть разработчик — даём API-токен. Если клиент хочет автоматический парсинг своего сайта — это отдельная услуга, не часть продукта.
Мультиплатформенность. У издания разные стили для сайта, Telegram и Дзен. В MVP — создай три аккаунта, обучи три стиля. Костыль? Да. Работает? Да. Потом сделаем именованные профили в одном аккаунте.
Каждый раз, когда хочется «сделать правильно» — мы спрашиваем: это для 80% или для 20%? Если для 20% — в бэклог. Если для 80% — делаем сейчас, пусть криво.
Прозрачность вместо магии
Есть соблазн сделать «магию»: кнопка → текст. Без объяснений, что происходит внутри.
Мы пошли другим путём. Пользователь может открыть пошаговый разбор: что нашёл Fact Extractor, что проверил Fact Checker (и какие факты отклонил), какие бэки подтянул Background Finder, что написал Draft Writer, что исправил Critic.
Почему? Потому что наш клиент — журналист. Ему не нужна магия. Ему нужно понимать, можно ли доверять результату. «AI написал» — это чёрный ящик, которому редактор не доверяет. «Агент проверил 14 фактов, 2 не подтвердились, вот ссылки» — это инструмент, с которым можно работать.
Прозрачность — не фича. Это условие, без которого профессионал не будет пользоваться продуктом.
Как выглядит бета
Наш план на бету — максимально ручной. Осознанно.
- Берём 3–5 редакций
- Звоним каждой: «Какие у вас источники? Откуда берёте новости?»
- Находим общие (ТАСС, РИА и ещё пару)
- Настраиваем парсеры в n8n вручную — для каждого клиента
- Клиент загружает 50 своих статей, жмёт «обучить стиль»
- Новости автоматически сыплются в систему, рерайтятся
- Клиент читает, правит, даёт обратную связь
- Мы корректируем
«Это не масштабируется!» — скажет продакт из крупной компании.
Правильно. И не должно. На этапе беты мы не масштабируем. Мы выясняем, работает ли продукт вообще. Три клиента, которые реально пользуются — ценнее трёхсот, которые зарегистрировались и ушли.
Урок, который мы учим каждый день
Сложность — внутри. Простота — снаружи.
Пять агентов, векторная база, стилевые профили с аспектами, фактчекер с веб-поиском, циклы доработки с критиком — это всё работает за кулисами.
Пользователь видит два экрана и один вопрос: «Этот текст можно опубликовать?»
Если ответ «да» — продукт работает. Если «нет» — неважно, сколько агентов у вас в пайплайне.
Самое сложное в AI-продукте — не архитектура. Не выбор модели. Не промпт-инжиниринг.
Самое сложное — удержаться от того, чтобы показать пользователю, какой вы умный.
Статья написана с помощью AI-системы «Рерайт-Завод». Публикуется также на Habr.