ИИ в аналитике и требованиях: кейс GoRunWithAI

Серия «Разработка с ИИ: полный цикл», часть 1. Платформа GoRunWithAI.

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

Кейс: из «хочу свой сайт» — в требования

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

Шаг 1. ИИ-агент — сырой черновик. Я передал агенту (Kimi) контекст: кто я, что умею, что за проект, и задачу — «собери контент-стратегию и поиск product-market fit». Агент вернул документ на десятки страниц: сегменты аудитории (ИТ-руководители, техлиды, бизнес, джуны), контент-вилку с частотами, гипотезы PMF с критериями проверки, пул RSS-источников по приоритетам.

Шаг 2. Человек — ревью и решения. Агент предложил, но решения принимал я. Что ушло в работу: фокус на сегменты «руководители + техлиды», позиционирование «не канал про ИИ, а работающая фабрика с открытой кухней», частота «одна статья в неделю». Что я отверг: часть гипотез, которые нельзя было проверить на моём масштабе.

Шаг 3. Формализация. Из стратегии родились BRD (бизнес-требования) и Spec — со стеком, границами и критериями приёмки. А из пула источников — файл OPML и таблица приоритетов A/B/C с интервалами опроса: 15 минут, 1 час, сутки.

Итог этапа: от идеи до работающего бэклога — пара вечеров. Дальше каждая строка требований превратилась в код или настройку.

Где ИИ реально помог в аналитике

1. Обработка сырья

Пул источников — классическая задача «переработки»: список RSS-лент с оценкой полезности. ИИ собрал таблицу: название, URL, приоритет, почему этот источник. Человек потом проверил каждый URL — треть отсеялась сразу (мёртвые ленты, дубли).

Приём: просите не «резюме», а структуру. «Собери таблицу источников с колонками X, Y, Z» даёт рабочий артефакт; «посоветуй источники» — простыню текста.

2. Критика требований

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

3. Прототипы и форматы до разработки

Вместо «потом сделаем красиво» — сразу зафиксировали форматы: новость в канале (заголовок, пересказ, ссылка, хештеги), статья на сайте (frontmatter, серия, CTA-вопрос), дайджест недели. Эти форматы стали критериями приёмки для конвейера.

Чего ИИ в аналитике не умел — на моём примере

Спрашивать «зачем». Агент уверенно генерировал разделы стратегии, которые мне были не нужны на старте (монетизация через подписку — при нулевой аудитории). Отсекал я.
Знать мою предметную область. Агент не знал моих ограничений: один человек, вечера после работы, бюджет ~1200 ₽/мес. Контекст пришлось давать явно — и после этого рекомендации резко стали адекватнее.
Отвечать за полноту. Ни один ИИ не спросил «а как ты будешь доставлять посты в Telegram, если Telegram заблокирован для твоего сервера?» Этот вопрос жизнь задала позже — на этапе прода (читайте статью 6).

Артефакт этапа: контекстный пакет задачи

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

Цель и бизнес-контекст: зачем приложение, кто читатели.
Требования с критериями приёмки: конвейер, публикации, дашборд.
Явные ограничения: стек (FastAPI + React + PostgreSQL), бюджет, один разработчик.
Нефункциональные требования: интервалы опроса, лимиты, порог аппрува 0.7.
Открытые вопросы и допущения: MAX-постинг — позже, HTTPS — позже.
Словарь домена: «анонс», «дайджест», «кросспостинг», «аппрув».

Этот пакет стал системным контекстом для агента на этапе разработки. Вложенный час здесь сэкономил дни переделок.

Метрики этапа

Доля требований с критериями приёмки — в проекте: 100% для функций конвейера; без них агент «додумывает».
Число открытых вопросов, закрытых до разработки — у нас все ключевые (форматы, приоритеты, расписание) закрылись на этапе аналитики.
Время от идеи до бэклога — пара вечеров вместо недель. Это и есть измеримый эффект ИИ на этапе.

Практический минимум для старта

Заведите шаблон «идея → требования» и храните его в репозитории.
Введите обязательный шаг «ИИ-критика»: противоречия, краевые случаи, размытые формулировки.
Пишите критерии приёмки в Given/When/Then — они же станут тестами (статья 5).
Соберите словарь домена в Markdown и подключайте его к каждому ИИ-запросу.

💬 Обсудим? Как в вашей команде выглядит «контекстный пакет задачи» — и бывает ли он вообще? Что даётся тяжелее всего: критерии приёмки, словарь домена или открытые вопросы? Делитесь в комментариях или в [Telegram-канале GoRunWithAI]. Все приёмы из этой статьи применены в конвейере GoRunWithAI — живые цифры и сбои на открытом дашборде платформы.

Следующая статья: «Часть 2. Проектирование и архитектура: как устроен GoRunWithAI».