Иногда кажется, что 90% работы с ИИ занимает логистика контекста: переключение между чатами, ручной сбор информации в сервисах и новые консультации с моделью. Сначала задаём вопрос ИИ, затем идём за цифрами в Wordstat, Директ и Метрику, копируем результаты обратно в чат, уточняем выводы — и повторяем этот цикл для следующей задачи.

Мы собрали именно этот рабочий процесс в одном чате Cursor. Агент получает данные из Wordstat, Яндекс Директа, Яндекс Метрики и сервиса Яндекс Аудитории, а обсуждение, анализ и подготовка следующих действий остаются в общей истории. Сейчас мы также тестируем два способа согласования подготовленных изменений: письменное подтверждение в чате и кнопку в веб‑панели.

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

Краткое содержание

• Как раньше выглядела работа с Директом?

• Как сервисы оказались в одном чате?

• Какие сценарии используем на практике?

  • Еженедельная оптимизация

  • Запуск кампании

  • Аудитории и ретаргетинг

• Как устроены согласование и apply?

Короткий глоссарий

Как раньше работали с Директом?

Начинали с обычного чата.

«Проанализируй аудиторию для продукта X.»
Модель выдавала сегменты без привязки к Wordstat и кабинету.

Дальше — в Wordstat за частотностями и минус‑идеями.
В Директ — смотреть расход, ключи, объявления.
В Метрику — сверить, что считается конверсией.
В Яндекс Аудитории — загрузить CRM, собрать look‑alike, проверить охват.
Отдельно — тексты объявлений и картинки.
Отдельно — письмо коллеге: «можно вот так минусануть?»

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

А что если Директ и связанные сервисы — в одном чате?

Теперь агент в Cursor ходит в API из одного проекта:

MCP‑серверы свои, на Python. Токены в .env, в промпт уходят отчёты и ID, а не OAuth. Из чата Директ доступен только на чтение: allow‑list пропускает только вызовы (service, get) и отклоняет пишущие операции. Skill задаёт, как агент работает с API; запись в кабинет — отдельным apply‑процессом.

Что мы делаем на практике?

Три типовых сценария.

Еженедельная оптимизация — основной цикл

Это то, что крутится каждую неделю:

/analyze-campaign → отчёт → /propose-edits → патч → dry-run → согласование → apply

1. Маркетолог: период + ID кампаний.

2. Агент забирает отчёт из Директа и Метрики: расход, CPA, запросы, площадки.

3. Пишет waste_report.md — что съедает бюджет и почему.

4. Формирует campaign_patch.json: минус‑слова, ставки, правки объявлений.

5. Dry‑run показывает план — ноль записей в API.

6. Человек проверяет патч и подтверждает его в чате или кнопкой в веб‑панели.

7. Apply отправляет изменения и пишет журнал.

Фрагмент отчёта:

Группа «Общие» — CPA 192 ₽, в 1,7 раза выше среднего
4 481 ₽ на ключ «с1 программа стоимость» — широкий трафик без «лицензия»
Минус-кандидаты: битрикс, community, охрана труда
...

За несколько месяцев по одному аккаунту: 35 пакетов правок подготовлено, 26 согласовано, 10+ применено.

Запуск или доработка кампании

Когда нужен новый продукт или новая семантика, сценарий идёт в четыре этапа:

1. Анализ и JTBD — разобрать продукт, сегменты, задачи, триггеры и барьеры (/jtbd).

2. Wordstat — проверить спрос, собрать частотности и кластеры запросов.

3. Черновик объявлений — подготовить группы, заголовки и тексты (/build-campaign-draft).

4. Согласование и загрузка в Директ — показать патч и dry‑run, получить approval, затем выполнить apply.

Пример: запуск рк для продукта Codex для 1С.

Аудитории и ретаргетинг

Цепочка из трёх сервисов:

1. Метрика — сегмент по целям и поведению («был на странице лицензий 90 дней», «бросил корзину»).

2. Яндекс Аудитории — CRM‑выгрузка, look‑alike, сегмент из пикселя; здесь смотрим охват.

3. Директ — привязка к группе через 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 пишет в кабинет.

Что изменилось по факту?

Чего система не обещает?

В Директ уходит только то, что человек согласовал после dry‑run.