← Все кейсы

Project Polygon

Информационный портал в нише селлеров маркетплейсов с собственным AI-контент-движком, автогенерируемым Дзен-каналом и регуляторной обвязкой по 152-ФЗ. Построен полный production-цикл — от ниша-research и регистрации в РКН до фактчек-пайплайна и cron-orchestration. Через ~12 месяцев работы и месяц публичной индексации эксперимент закрыт с измеренными результатами; всё технологическое и методологическое наследие перенесено в следующие проекты.

TL;DR

• Построил полный пайплайн: контент-портал на 100+ страниц, AI-генератор Дзен-выпусков с фактчеком и двухслойной критикой, auto-review pipeline для гарантии ежедневного выпуска, scheduler для планирования задач, cover-renderer для генерации обложек, reverse-pull notifier для уведомлений из-под санкционных блокировок, Watch Tower для мониторинга ниш.
• Проверил гипотезу «AI-контент в нише без личной экспертизы пробивает SEO-конкуренцию с доменными авторитетами 10+ лет» — гипотеза опровергнута.
• Зафиксировал правило «без доменного валидатора в нишу не входим» как обязательный фильтр для будущих продуктовых решений.
• Унаследовал 7 production-сервисов, регуляторную методологию, stage/prod-пайплайн и 8-уровневую методику оркестрации контента — всё это уже переиспользуется в продолжающих проектах.

Гипотеза эксперимента

Информационная ниша для селлеров российских маркетплейсов (Wildberries, Ozon, Я.Маркет, Avito) выглядела как кандидат на «вечнозелёный» long-tail-трафик: тысячи операционных вопросов («комиссии WB 2026», «штрафы Ozon за просрочку», «карточка YM по 47 параметрам»), большая аудитория, постоянный приток новичков. Гипотеза, которую я хотел проверить:

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

Критерий успеха был мягкий: ~100k показов / 1% CTR / 100₽ дохода с тысячи — 100k₽/мес базовый рубеж окупаемости. Срок «получить первые сигналы» — 2–3 месяца после первой массовой индексации.

Product Engineering — что было построено

Архитектура верхнего уровня

Не один сайт, а распределённая система из 8 кооперирующих сервисов, разнесённых между лабовой dev-средой и production-VPS на Selectel:

Антигаллюцинаторный фактчек как core-компетенция

Критическая проблема LLM-контента в новостной нише — выдуманные точные числа, искажённые имена собственные и непереведённые англоязычные фрагменты. Реализованная схема контроля:

1. Writer (GigaChat-Max) пишет черновик по отобранным источникам из дайджеста новостей.
2. Selector до этого уже отфильтровал тонкий новостной поток (audit-маркер thin-mp-news) — если нет 2-3 операционных тем, генератор отказывается выпускать, и материал идёт в fallback-режим.
3. Critic (YandexGPT + Yandex Search) разбирает черновик на отдельные claims и верифицирует каждый отдельным запросом к Поиску. Все claims с недостаточным evidence помечаются для блокировки.
4. Auto-reprompt при срабатывании критика — writer переписывает проблемный фрагмент. После 2-х неуспешных попыток — human-review.
5. Audit-JSON по каждому выпуску: черновик → claims → verdict → evidence-ссылки. Это даёт reproducible-trace и эмпирическую базу для тюнинга промптов.

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

Двухрежимный auto-review (review + write-fallback)

Отдельный слой страховки от халтуры основного генератора. Sonnet-headless, запускается cron'ом на лабе через 15 минут после server-генератора:

• Режим review — если основной генератор отработал, Sonnet вычитывает выпуск как выпускающий редактор, пишет краткую рецензию и кладёт улучшенный рерайт в incoming/ как черновик «ждёт approve».
• Режим write-fallback — если основной генератор отказался (audit-флаг SKIP), но источники собраны, Sonnet сам собирает резервный выпуск из тех же источников и кладёт его в incoming/ с маркером «резервная сборка». Так в очередь каждый день кладётся хотя бы черновик.

Контракт вывода стандартизирован: @@@SEVERITY@@@, @@@PING@@@, @@@REVIEW@@@, @@@REWRITE@@@ — обёртка парсит секции и раскладывает по правильным путям. Идемпотентность через проверку существующих файлов; --force для перезапуска.

Регуляторная обвязка по 152-ФЗ

Подан полный пакет в РКН (Роскомнадзор) как оператор персональных данных: форма №179, привязка к домену, обоснование категорий обрабатываемых данных (cookies и Метрика), правовые основания. Шаблон формы и distilled знания о ловушках процесса вошли в knowledge base, переиспользуемый для следующих info-сайтов с Метрикой.

Stage/prod-пайплайн

Тот же GitOps-шаблон, что я применяю для всех HEADMAN-проектов:

• Разработка на лабе → push в ветку stage → GitVerse webhook → headman-stage-deployer → автодеплой на <project>.stage.headman.pro за 8–25 сек.
• PR stage→master → Portainer prod-stack webhook → redeploy на prod-домене.
• Канонические правила: контейнеры в общей docker-сети, nginx-proxy-manager резолвит по именам контейнеров (не по именам стеков), env живёт в Portainer stack config (а не в CLI-recreate, иначе теряются переменные).

Управленческие и продуктовые решения

Стек выбран под РФ-ограничения с дня 1

OpenAI и Cloudflare заблокированы РКН; Telegram API заблокирован с RU-хостеров; западные SaaS — риск отключения. Все принятые технологические решения учитывают эти ограничения:

• GigaChat-Max + YandexGPT + Yandex Search вместо OpenAI/Anthropic на server-side. Anthropic вызывается только из лабовой инфраструктуры (auto-review), не из production VPS.
• Yandex Object Storage вместо Cloudflare R2 или S3 — российский хостинг для prerender-статики.
• Reverse-pull notifier вместо прямых вызовов api.telegram.org с сервера. Лаба-вендор тянет очередь и форвардит в TG.

Это не косметика, а структурное проектное решение: если завтра Selectel блокирует ещё что-то, архитектура устойчива, потому что критические зависимости либо российские, либо вынесены за периметр.

SPA + build-time prerender как cost decision

Изначально рассматривался SSR (Next.js на Node-контейнере) — но это требует компьюта 24/7. Для контентного сайта с медленным обновлением выбран Vite-SPA + build-time prerender по sitemap → раскладка plain-HTML на Yandex Object Storage. Стоимость хостинга — десятки рублей в месяц, Lighthouse 95+ без оптимизации, мгновенный rollback через переключение бакета.

Двухслойная критика вместо single-pass writer

Решение разделить writer и critic на разные модели (GigaChat пишет, YandexGPT проверяет) принято после первой итерации, где single-pass генератор давал стабильно ~15% выпусков с искажениями. Отдельный critic с независимым source of truth (Yandex Search) ловит то, что писатель не видит — например, выдуманные точные числа или искажённые имена собственных. Цена — удвоение latency и стоимости, но качество выпусков перешло порог «можно публиковать без редактора».

Auto-review как страховка, а не как доминирующий слой

Когда возник вопрос «зачем нам GigaChat, если Claude headless пишет лучше», — осознанно оставлен гибрид: GigaChat первым (быстрее, дешевле, российский стек), auto-review вторым (вычитка + fallback при skip'е). Полное замещение Claude'ом удорожило бы операцию на порядок и привязало бы нас к Anthropic — ровно то, чего нельзя на RU-инфраструктуре.

Дзен-канал как отдельная воронка, не как часть SEO-стратегии

Изначально предполагалось, что Дзен-канал и сайт работают синергично: канал гонит читателя на сайт, сайт удерживает. На практике Дзен-аудитория почти не переходит — алгоритм Дзена удерживает внутри платформы. После осознания этого канал стал самостоятельной единицей в тестовой фазе (1 канал, 2–3 месяца тестирования), не подпорка для сайта.

Измеримые результаты

Что построено и зафиксировано

• Сайт-портал на 100+ страниц prerender-статики.
• 93 термина глоссария, 22+ экспертных гайда, 5 хабов по площадкам.
• Семантическое ядро на 163 фразы (3 раунда Wordstat + кластерный анализ).
• Content Engine с ежедневным morning / evening / weekly расписанием.
• Подана и принята регистрация в РКН как оператора ПДн.
• 7 production-сервисов в Portainer-стеках, документированных как переиспользуемые.

Что показала индексация (29.04 — 28.05.2026)

• Я.Вебмастер: 27 страниц в индексе по 7 разделам; 0 кликов из поиска за месяц; единичные показы (29 за месяц) по 5 фразам, все из зоны «Яндекс.Маркет селлер», ничего по WB и Ozon.
• Я.Метрика: 25 визитов / 24 уникальных посетителя за месяц; 88% — на главную и /privacy/; отказы 84%; глубина просмотра 1.32.
• История обхода: активная индексация 4–10 мая (пик 75 страниц/день), затем резкий спад из-за технической ошибки в routing — обнаружен бесконечный цикл редиректов 301 вида /-i-reklama/-i-reklama/... на 12 уровней вложенности. Я.Робот подавился и снизил crawl-бюджет.

Себестоимость и операционные метрики

• Себестоимость одного выпуска: < 25 ₽ (GigaChat + YandexGPT + Search + render).
• Latency полного цикла генерации: ~2–3 минуты от триггера до готового черновика.
• Стоимость хостинга prerender-статики: десятки рублей/мес на Yandex Object Storage.
• Auto-review fallback: ~2:44 на полный write-режим, ~30 сек на review-режим.

Что узнал — выводы эксперимента

1. AI-контент в нише с экспертной конкуренцией не пробивается без валидатора

Главный вывод и главный артефакт. Конкуренты в нише — WB-Гид (внутренний контент Wildberries), Sellmonitor (продукт для селлеров, написанный селлерами), vc.ru / Sells (реальные кейсы с цифрами), банковские блоги для предпринимателей (T-Bank, Точка). У всех — domain authority 10+ лет и живая аудитория с собственным опытом. Свежий AI-агрегатор без живой экспертной валидации в такой выдаче не нужен ни поисковому роботу, ни читателю. 84% отказов при единичных посетителях — прямое подтверждение: даже случайный читатель моментально считывает отсутствие «голоса из шкуры».

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

2. Дистрибуция важнее генерации

Контент-движок работает технически безупречно — 27 страниц проиндексировано, Дзен-выпуски выходят ежедневно, фактчек блокирует выдуманные числа. Но без дистрибуции (линкбилдинга, упоминаний в тематических TG-каналах селлеров, партнёрств с агентствами) контент не находит аудиторию. На бюджет инфраструктуры был потрачен один человеко-месяц, на дистрибуцию — почти ноль. Соотношение усилий не соответствовало природе ниши.

3. Технические грабли в routing бьют сильнее, чем кажется

Бесконечный цикл редиректов был результатом одной относительной ссылки в шаблоне, которая накапливала суффикс при каждом обходе. Технически тривиальный баг, но он съел crawl-бюджет домена за критическую неделю первого обхода — и Я.Робот после этого снизил частоту визитов до минимума. Урок: канонизация URL и контроль routing — это SEO-критическая инфраструктура, не косметика. В следующие порталы я заношу проверку «нет цепочек 301-редиректов длиннее одного шага» как часть pre-launch чеклиста.

4. Российский AI-стек работает

GigaChat-Max и YandexGPT с обвязкой Yandex Search дают качество, достаточное для production-публикаций при правильной двухслойной критике. Это снимает опасение «без OpenAI/Claude в RU нельзя делать AI-продукты». Можно — при условии хорошей продуктовой обвязки.

5. Регуляторная сторона — посильна и должна делаться в начале

Подача в РКН по 152-ФЗ оказалась простой при предварительной подготовке knowledge base. Главный урок — делать это до запуска, а не после: пост-фактум приходится отвечать на запросы регулятора и параллельно тушить продуктовые пожары.

Унаследованные активы

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

Что бы сделал иначе

1. Применил правило валидатора до запуска, а не вывел его из провала. Перед стартом — критический вопрос: «есть ли у меня личный опыт в нише или доступ к человеку, который видит халтуру AI?». Если ответ нет — не входить.
2. Сразу заложил бюджет на дистрибуцию, не только на генерацию. Один месяц генерации без месяца на дистрибуцию = слитый месяц.
3. Канонизацию URL как часть pre-launch чеклиста. Проверка отсутствия циклических 301/302 в routing — обязательная перед открытием сайта роботу.
4. Меньшее количество страниц с более глубоким контентом, а не наоборот. 100 поверхностных гайдов проиграли бы и проиграли. Лучше 10 глубоких + личный опыт.

Зачем этот кейс в портфолио

Не «успешный продукт», а демонстрация полного набора компетенций product engineering на одном проекте:

• Архитектура распределённой системы из 8 кооперирующих сервисов под жёсткие регуляторные и инфраструктурные ограничения.
• AI-инжиниринг: двухслойная критика, антигаллюцинаторный фактчек, auto-reprompt, audit-trace, двухрежимный fallback.
• Cost-conscious decision making: SPA+prerender вместо SSR, российский AI-стек вместо санкционно-зависимого, лабовая обвязка вместо cloud-вендоров.
• GitOps-pipeline: автодеплой stage/prod, идемпотентные миграции, stage-gate на post-launch-проекты.
• Регуляторная компетенция: 152-ФЗ, подача в РКН, методология для будущих info-сайтов.
• Honest post-mortem: способность зафиксировать провальный результат, выделить эмпирически подтверждённое правило и сделать его обязательным фильтром для будущих решений.
• Asset extraction: умение извлечь из провального продукта ценную переиспользуемую инфраструктуру для следующих проектов — TarkovCore и других порталов универсальной платформы.

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

← Все кейсы