Иногда кажется, что 90% работы с ИИ занимает логистика контекста: переключение между чатами, ручной сбор информации в сервисах и новые консультации с моделью. Сначала задаём вопрос ИИ, затем идём за цифрами в Wordstat, Директ и Метрику, копируем результаты обратно в чат, уточняем выводы — и повторяем этот цикл для следующей задачи.
Мы собрали именно этот рабочий процесс в одном чате Cursor. Агент получает данные из Wordstat, Яндекс Директа, Яндекс Метрики и сервиса Яндекс Аудитории, а обсуждение, анализ и подготовка следующих действий остаются в общей истории. Сейчас мы также тестируем два способа согласования подготовленных изменений: письменное подтверждение в чате и кнопку в веб‑панели.
Запись в кабинет остаётся отдельным шагом: apply запускается только после проверки человеком.
Краткое содержание
Короткий глоссарий
Термин | Что означает в этой статье |
|---|---|
MCP | Протокол, через который агент вызывает инструменты проекта и получает данные из API. |
JTBD | Jobs To Be Done: задачи, ради которых сегмент аудитории выбирает продукт. |
Патч | Машиночитаемый список предложенных изменений; у нас это |
Dry‑run | Пробный прогон: показывает будущие изменения, но ничего не записывает в API. |
Approval | Зафиксированное согласование патча, привязанное к его SHA256-хэшу. |
Apply | Выполнение уже согласованного патча и запись изменений в кабинет. |
Write gate | Проверка перед apply: есть ли dry‑run, approval и совпадает ли хэш патча. |
Как раньше работали с Директом?
Начинали с обычного чата.
«Проанализируй аудиторию для продукта X.»
Модель выдавала сегменты без привязки к Wordstat и кабинету.
Дальше — в Wordstat за частотностями и минус‑идеями.
В Директ — смотреть расход, ключи, объявления.
В Метрику — сверить, что считается конверсией.
В Яндекс Аудитории — загрузить CRM, собрать look‑alike, проверить охват.
Отдельно — тексты объявлений и картинки.
Отдельно — письмо коллеге: «можно вот так минусануть?»
Чтобы принять одно решение, маркетолог вручную переносил цифры между окнами и каждый раз заново объяснял контекст.
А что если Директ и связанные сервисы — в одном чате?
Теперь агент в Cursor ходит в API из одного проекта:
Сервис | Зачем |
|---|---|
Wordstat | спрос, частотности, идеи для ключей и минус‑слов |
Яндекс Директ | кампании, группы, ключи, ставки, объявления, расход |
Яндекс Метрика | цели, конверсии, сегменты для ретаргетинга |
Яндекс Аудитории | CRM‑базы, look‑alike, сегменты из Метрики |
MCP‑серверы свои, на Python. Токены в .env, в промпт уходят отчёты и ID, а не OAuth. Из чата Директ доступен только на чтение: allow‑list пропускает только вызовы (service, get) и отклоняет пишущие операции. Skill задаёт, как агент работает с API; запись в кабинет — отдельным apply‑процессом.
Что мы делаем на практике?
Три типовых сценария.
Еженедельная оптимизация — основной цикл
Это то, что крутится каждую неделю:
/analyze-campaign → отчёт → /propose-edits → патч → dry-run → согласование → apply
Маркетолог: период + ID кампаний.
Агент забирает отчёт из Директа и Метрики: расход, CPA, запросы, площадки.
Пишет
waste_report.md— что съедает бюджет и почему.Формирует
campaign_patch.json: минус‑слова, ставки, правки объявлений.Dry‑run показывает план — ноль записей в API.
Человек проверяет патч и подтверждает его в чате или кнопкой в веб‑панели.
Apply отправляет изменения и пишет журнал.
Фрагмент отчёта:
Группа «Общие» — CPA 192 ₽, в 1,7 раза выше среднего 4 481 ₽ на ключ «с1 программа стоимость» — широкий трафик без «лицензия» Минус-кандидаты: битрикс, community, охрана труда ...
За несколько месяцев по одному аккаунту: 35 пакетов правок подготовлено, 26 согласовано, 10+ применено.
Запуск или доработка кампании
Когда нужен новый продукт или новая семантика, сценарий идёт в четыре этапа:
Анализ и JTBD — разобрать продукт, сегменты, задачи, триггеры и барьеры (
/jtbd).Wordstat — проверить спрос, собрать частотности и кластеры запросов.
Черновик объявлений — подготовить группы, заголовки и тексты (
/build-campaign-draft).Согласование и загрузка в Директ — показать патч и dry‑run, получить approval, затем выполнить apply.
Пример: запуск рк для продукта Codex для 1С.
Аудитории и ретаргетинг
Цепочка из трёх сервисов:
Метрика — сегмент по целям и поведению («был на странице лицензий 90 дней», «бросил корзину»).
Яндекс Аудитории — CRM‑выгрузка, look‑alike, сегмент из пикселя; здесь смотрим охват.
Директ — привязка к группе через
AudienceTargets: РСЯ на прогретую базу, ретаргет на тех, кто не дошёл до оплаты.
Агент описывает цепочку, готовит патч или скрипт, показывает dry‑run. Человек проверяет охват — потом apply.
Кто решает, что уйдёт в Директ?
В прод изменения уходят только после человеческого согласования. Единственный окончательный интерфейс мы пока не выбрали: тестируем чат и веб‑панель, чтобы понять, где меньше ошибок и лишних действий.
анализ → campaign_patch.json → dry-run → ревью → approval.json → apply → журнал
Патч — внутренняя схема, не формат API Директа:
{ "patch_id": "licenses_minus_2026_05_26", "campaign_id": 701000001, "negative_keywords_add": [ { "keyword": "битрикс", "match_type": "BROAD" } ], "bid_adjustments": [ { "ad_group_id": 5767000001, "bid_modifier_percent": -25, "reason": "CPA группы выше среднего" } ] }
Dry‑run по умолчанию:
DRY-RUN apply_patch + negatives: 3 ~ bid modifiers: 1 writes: 0 status: OK (no production changes)
Оба варианта создают approval.json, но по‑разному встраиваются в работу:
Способ | Как работает | Что проверяем на практике |
|---|---|---|
В чате | Человек пишет «согласовано» или «одобряю»; сохраняется | Удобно ли принимать решение рядом с отчётом и патчем; достаточно ли явно отделено согласование от обсуждения |
В веб‑панели | Человек нажимает «Согласовать»; сохраняется | Меньше ли случайных подтверждений; оправдан ли переход в отдельный интерфейс |
Фразы «применяй», «вноси» или apply в чате одновременно фиксируют согласие и отдельное поручение перейти к apply. В интерфейсе согласование и запуск apply остаются разными действиями.
В обоих случаях approval привязан к SHA256-хэшу патча. Если патч изменился после согласования, хэш перестаёт совпадать и apply блокируется.
Write‑токен лежит в том же .env, что и агент: это процессная защита, а не отдельная граница полномочий. Оба способа согласования пока остаются частью эксперимента; общими для них уже стали dry‑run, хэш патча и журнал операций.
Что ещё можно из чата?
Еженедельные сводки — расход, CPA, корзины, площадки. Вместо общей оценки — таблица из API:
Расход: 87 129 ₽ при плане ~100 000 ₽ Корзина Метрики: 18, из них 13 — неделя 22–28 июня CPC РСЯ: с 208 ₽ до 81 ₽ к концу месяца Топ площадки: ya.ru, mail.yandex.ru, dzen.ru
Правки объявлений — тексты, sitelinks, картинки для РСЯ: агент готовит, человек согласует, apply пишет в кабинет.
Можно без согласования | Нельзя без согласования |
|---|---|
Читать Директ, Метрику, Wordstat | Менять ставки и минус‑слова |
Писать отчёты и патчи | Поднимать бюджет и менять стратегию |
Запускать dry‑run | Удалять кампании и группы |
Смотреть аудитории | Загружать базы и писать в Аудитории |
Что изменилось по факту?
Задача | Было | Стало |
|---|---|---|
Еженедельный аудит | ручной отчёт в кабинете |
|
Поиск мусорных запросов | «на глаз» |
|
Семантика новой РК | Wordstat отдельно | Wordstat MCP + черновик в чате |
Аудитории | три кабинета вручную | Метрика → Аудитории → Директ из одного проекта |
Согласование правок | «вот скрин, можно?» | патч, dry‑run, approval в чате или панели |
Чего система не обещает?
Если ждёте | Получите на самом деле |
|---|---|
Замену маркетолога на спорных минусах и офферах | Рекомендации и патч; решение за человеком |
Доказательство, что approve нажал именно этот человек | Файл с хэшем и процесс; без криптографической подписи |
Автооткат при частичном сбое API | Журнал с тем, что успело примениться; разбор руками |
Гарантированное снижение CPA | Быстрее собранные факты и контролируемая запись |
В Директ уходит только то, что человек согласовал после dry‑run.
