Как сделать ИИ-агента для маркетинга и контент-плана

Что получится в результате

Соберем ИИ-агента, который помогает маркетологу вести контент-план как управляемый процесс: собирать спрос, кластеризовать темы, выбирать рубрики, готовить брифы, писать черновики, проверять бренд-правила, ставить материалы на согласование и собирать отчет по результатам.

В результате будет рабочий прототип:

1. аудитория и продуктовые направления хранятся в `audience_segments` и `content_pillars`;
2. поисковые запросы, идеи и темы попадают в `topic_backlog`;
3. агент группирует темы в `topic_clusters`;
4. редакторский календарь ведется в `content_calendar`;
5. брифы статей хранятся в `content_briefs`;
6. черновики пишутся в `draft_queue`;
7. проверки качества идут через `content_checks`;
8. согласование проходит через `approval_queue`;
9. approved-материалы попадают в `publication_queue`;
10. фактические публикации и метрики пишутся в `performance_log`;
11. все изменения фиксируются в `audit_log`.

В первой версии агент не публикует сырой AI-текст, не обещает неподтвержденные результаты, не меняет бренд-позиционирование сам и не запускает рекламу без человека.

Что понадобится

Минимальный набор:

1. Google Sheets как база прототипа.
2. n8n для workflow.
3. LLM API для кластеризации, брифов и черновиков.
4. Данные из Yandex Wordstat или ручная выгрузка запросов.
5. Google Search Console или ручная выгрузка страниц и запросов.
6. Google Analytics 4 или Яндекс Метрика для результатов.
7. CMS, Notion, Trello, Jira или Google Docs для редакционного процесса.
8. Бренд-гайд, tone of voice и список запрещенных обещаний.
9. Маркетолог или редактор, который утверждает темы и публикации.

Для первого запуска хватит Google Sheets, n8n, 100-300 запросов, списка текущих статей и одной контентной цели.

Шаг 1. Выберите один контентный процесс

Не начинайте с агента, который “делает весь маркетинг”.

Выберите один сценарий:

1. SEO-статьи для блога;
2. контент-план для Telegram;
3. контент-план для VK или других соцсетей;
4. идеи для email-рассылок;
5. брифы для редактора;
6. обновление старых статей;
7. дайджесты по новостям ниши;
8. превращение вебинаров в статьи и посты.

Для этой инструкции выберем основной сценарий: агент собирает темы, готовит редакционный календарь и пишет брифы для SEO-статей. Публикация идет только после approval.

Проверка: сценарий заканчивается понятным статусом `ready_for_editor`, а не абстрактным “улучшить маркетинг”.

Шаг 2. Зафиксируйте ограничения

Запретите агенту опасные маркетинговые действия.

Нельзя:

1. публиковать материал без approval;
2. обещать гарантированный рост продаж, трафика или дохода;
3. придумывать кейсы, цифры и отзывы;
4. использовать чужие тексты без переработки и проверки;
5. менять позиционирование бренда;
6. запускать рекламу;
7. менять SEO-title на сайте без проверки;
8. удалять страницы;
9. публиковать юридические, медицинские или финансовые утверждения без эксперта;
10. использовать персональные данные клиентов без согласия.

Системное правило:

Ты помощник маркетолога и редактора.
Ты готовишь идеи, кластеры, брифы, черновики и проверки.
Ты не публикуешь материалы и не запускаешь кампании без approval.
Не выдумывай кейсы, цифры, цитаты и результаты.
Если факта нет в данных, помечай его как needs_fact_check.

Проверка: если в prompt попросить “сразу опубликуй статью”, агент создает запись в `approval_queue`, а не publication action.

Шаг 3. Создайте Google Sheet проекта

Создайте таблицу `marketing_content_agent_mvp`.

Добавьте листы:

marketing_settings
audience_segments
content_pillars
brand_rules
keyword_pool
existing_content
topic_backlog
topic_clusters
content_calendar
content_briefs
draft_queue
content_checks
approval_queue
publication_queue
performance_log
report_snapshots
audit_log
error_log

Проверка: в таблице есть все листы, а доступ к редактированию есть только у маркетинга и редактора.

Шаг 4. Заполните marketing_settings

Лист `marketing_settings` хранит пороги и правила.

Колонки:

key
value
description
updated_by
updated_at

Стартовые строки:

min_keyword_demand | 10 | минимальный спрос по запросу
cluster_similarity_threshold | 0.72 | порог объединения тем
max_posts_per_week | 5 | лимит публикаций в неделю
draft_requires_approval | yes | черновик требует проверки
publish_requires_approval | yes | публикация требует проверки
fact_check_required | yes | факты и цифры проверяются
brand_check_required | yes | бренд-правила обязательны
seo_check_required | yes | SEO-проверка обязательна
content_freshness_days | 180 | когда обновлять старую статью

Проверка: workflow читает лимиты из `marketing_settings`, а не из текста prompt.

Шаг 5. Создайте audience_segments

Лист `audience_segments` описывает, для кого создается контент.

Колонки:

segment_id
name
role
pain_points
goals
awareness_level
preferred_formats
forbidden_angles
status

Пример:

seg_smb_owner | Владелец малого бизнеса | decision maker | мало времени, непонятно с чего начать AI | выбрать первый сценарий автоматизации | problem_aware | статья, чеклист, инструкция | сложный технический жаргон | active
seg_marketer | Маркетолог | practitioner | много каналов, нужен план | ускорить контент-производство | solution_aware | шаблон, гайд, кейсы | обещания гарантированного роста | active

Проверка: каждая тема в будущем привязана хотя бы к одному `segment_id`.

Шаг 6. Создайте content_pillars

Лист `content_pillars` хранит основные направления контента.

Колонки:

pillar_id
name
goal
target_segments
allowed_formats
priority
owner
status

Пример:

pillar_ai_agents | ИИ-агенты | привлечь аудиторию, которая ищет практические инструкции | seg_smb_owner, seg_marketer | статья, инструкция, обзор | high | editor | active
pillar_tools | Инструменты AI | закрыть спрос по конкретным сервисам | seg_marketer | обзор, сравнение, инструкция | medium | editor | active
pillar_security | Безопасность AI | объяснить риски и контроль | seg_smb_owner | чеклист, инструкция | high | expert | active

Проверка: темы без `pillar_id` не попадают в календарь.

Шаг 7. Создайте brand_rules

Лист `brand_rules` нужен, чтобы агент не писал вразнобой.

Колонки:

rule_id
rule_type
rule_text
severity
owner
status
updated_at

Типы:

tone
claim
legal
seo
format
style

Примеры:

BR-001 | tone | писать просто, конкретно, без канцелярита | medium | editor | active | 2026-05-23
BR-002 | claim | не обещать гарантированный рост продаж или трафика | high | marketing | active | 2026-05-23
BR-003 | style | не писать длинные вступления без практического смысла | medium | editor | active | 2026-05-23
BR-004 | legal | спорные юридические утверждения отправлять эксперту | high | legal | active | 2026-05-23

Проверка: черновик с фразой “гарантируем рост продаж” получает ошибку в `content_checks`.

Шаг 8. Создайте keyword_pool

Лист `keyword_pool` хранит запросы и сигналы спроса.

Колонки:

keyword_id
query
region
language
demand
source_name
intent
difficulty
current_url
status
collected_at

Возможные `source_name`:

wordstat
search_console
keyword_planner
site_search
manual
competitor

Intent:

informational
commercial
how_to
comparison
tool
navigational
unknown

Проверка: каждый запрос имеет `intent` и не лежит в таблице как просто “идея”.

Шаг 9. Загрузите запросы из Wordstat или CSV

Для прототипа можно начать с ручной CSV-выгрузки.

Колонки CSV:

query
demand
region
source_name
collected_at

Workflow `marketing_keyword_import`:

1. получить CSV;
2. нормализовать запрос;
3. удалить пустые строки;
4. удалить дубли;
5. поставить `intent = unknown`;
6. записать строки в `keyword_pool`;
7. добавить событие в `audit_log`.

Проверка: 100 запросов из CSV превращаются в 100 или меньше уникальных строк без дублей.

Шаг 10. Добавьте текущие страницы сайта

Создайте лист `existing_content`.

Колонки:

content_id
url
title
content_type
pillar_id
primary_keyword
secondary_keywords
published_at
updated_at
status
traffic_30d
clicks_30d
impressions_30d
avg_position
needs_update

Статусы:

published
draft
outdated
needs_update
archived

Проверка: если запрос уже закрыт сильной страницей, агент не создает дубль темы.

Шаг 11. Классифицируйте intent запросов

Создайте workflow `marketing_intent_classifier`.

Prompt:

Определи intent поискового запроса.
Верни только JSON.

Запрос: {{query}}

Варианты:
informational - человек хочет понять тему
how_to - нужна пошаговая инструкция
comparison - сравнение вариантов
tool - ищет конкретный инструмент
commercial - выбирает покупку или услугу
navigational - ищет конкретный сайт или бренд
unknown - непонятно

Ответ:
{
  "intent": "informational|how_to|comparison|tool|commercial|navigational|unknown",
  "confidence": 0,
  "reason": "short"
}

Проверка: запрос `как сделать ии агента` получает `how_to`, а `лучшие ии агенты` получает `comparison`.

Шаг 12. Создайте topic_backlog

Лист `topic_backlog` хранит кандидаты тем.

Колонки:

topic_id
title
pillar_id
segment_id
primary_keyword
secondary_keywords
intent
demand_total
business_value
content_type
priority
status
owner
created_at

Статусы:

new
clustered
brief_needed
brief_ready
draft_needed
draft_ready
ready_for_approval
approved
scheduled
published
rejected

Проверка: тема без `primary_keyword`, `pillar_id` и `segment_id` не идет дальше.

Шаг 13. Сгруппируйте запросы в topic_clusters

Лист `topic_clusters` хранит группы похожих запросов.

Колонки:

cluster_id
cluster_name
pillar_id
main_intent
primary_keyword
keywords_json
demand_total
existing_url
recommended_action
priority
status

Recommended action:

create_new
update_existing
merge_with_existing
ignore
manual_review

Правила:

1. похожие how_to запросы объединять в одну инструкцию;
2. tool-запросы вести в отдельные страницы инструментов;
3. comparison-запросы вести в обзоры и подборки;
4. если есть сильная текущая страница, ставить `update_existing`;
5. если intent смешанный, ставить `manual_review`.

Проверка: `создание ии агента` и `как создать ии агента` попадают в один cluster.

Шаг 14. Настройте prompt для кластеризации

Prompt:

Сгруппируй запросы в темы для контент-плана.
Не создавай отдельную тему для каждого похожего запроса.
Учитывай intent, смысл, уровень воронки и текущие страницы.
Верни JSON без Markdown.

Схема:
{
  "clusters": [
    {
      "cluster_name": "string",
      "main_intent": "how_to|informational|comparison|tool|commercial|mixed",
      "primary_keyword": "string",
      "keywords": ["string"],
      "recommended_action": "create_new|update_existing|merge_with_existing|ignore|manual_review",
      "reason": "string"
    }
  ]
}

Проверка: модель возвращает массив clusters, который можно записать в `topic_clusters`.

Шаг 15. Рассчитайте приоритет темы

В `topic_backlog.priority` не используйте только частотность.

Формула:

priority_score =
demand_score * 0.30 +
business_value * 0.30 +
content_gap * 0.20 +
freshness_need * 0.10 +
production_ease * 0.10

Шкала:

high
medium
low
manual_review

Проверка: тема с низким спросом, но высоким business value может попасть выше массовой, но нерелевантной темы.

Шаг 16. Создайте content_calendar

Лист `content_calendar` хранит редакционный план.

Колонки:

calendar_id
topic_id
planned_date
channel
content_type
title
owner
status
deadline_brief
deadline_draft
deadline_review
published_url
comment

Каналы:

blog
telegram
vk
email
youtube
linkedin
docs

Статусы:

planned
brief_ready
draft_ready
in_review
approved
scheduled
published
postponed
cancelled

Проверка: на одну дату не ставится больше лимита `max_posts_per_week`.

Шаг 17. Создайте content_briefs

Лист `content_briefs` хранит техническое задание для материала.

Колонки:

brief_id
topic_id
calendar_id
working_title
primary_keyword
secondary_keywords
target_segment
search_intent
outline_json
must_cover
examples_needed
internal_links
cta
tone
status
created_at

Статусы:

draft
ready_for_editor
approved
needs_fix

Проверка: бриф содержит структуру, ключевые вопросы, внутренние ссылки и что именно нужно раскрыть.

Шаг 18. Настройте prompt для брифа

Prompt:

Составь редакционный бриф по теме.
Опирайся только на topic_cluster, audience_segments, content_pillars, existing_content и brand_rules.
Не пиши готовую статью.
Не выдумывай факты и кейсы.

Верни JSON:
{
  "working_title": "string",
  "search_intent": "string",
  "target_segment": "string",
  "outline": [
    {
      "h2": "string",
      "purpose": "string",
      "must_cover": ["string"]
    }
  ],
  "must_answer": ["string"],
  "examples_needed": ["string"],
  "internal_links": ["url or slug"],
  "cta": "string",
  "risks": ["string"]
}

Проверка: бриф можно отдать редактору без дополнительного объяснения.

Шаг 19. Создайте draft_queue

Лист `draft_queue` хранит черновики материалов.

Колонки:

draft_id
brief_id
topic_id
channel
format
draft_text
status
model
created_at
updated_at
author
comment

Статусы:

draft
needs_fact_check
needs_brand_check
ready_for_editor
approved
rejected

Проверка: черновик не получает `approved` автоматически.

Шаг 20. Настройте prompt для черновика

Prompt:

Напиши черновик материала по approved-брифу.
Соблюдай brand_rules.
Не добавляй неподтвержденные цифры, кейсы, цитаты и обещания.
Если нужен факт, но его нет в данных, добавь метку [needs_fact_check: что проверить].
Пиши конкретно, без воды.
Не публикуй и не готовь финальный статус.

Дополнительное правило для SEO-статьи:

Первый экран должен быстро отвечать на запрос.
Каждый раздел должен раскрывать отдельный вопрос.
Не повторяй один и тот же тезис разными словами.

Проверка: в черновике нет выдуманных процентов, кейсов и цитат.

Шаг 21. Создайте content_checks

Лист `content_checks` хранит проверки качества.

Колонки:

check_id
draft_id
check_type
status
severity
message
fixed_by
checked_at

Типы:

seo
brand
fact
legal
style
duplicate
readability
cta

Статусы:

passed
warning
failed
needs_human_review

Проверка: материал не идет в approval, если есть `failed` по `fact`, `brand` или `legal`.

Шаг 22. Настройте SEO-проверку

SEO-проверка не должна превращать текст в спам.

Проверяйте:

1. есть ли ответ на search intent;
2. есть ли primary keyword в title или H1;
3. раскрыты ли secondary keywords;
4. нет ли дубля с existing_content;
5. есть ли внутренние ссылки;
6. есть ли понятная структура H2;
7. не переспамлены ли запросы;
8. есть ли FAQ, если тема вопросная;
9. есть ли дата обновления для evergreen-материала;
10. нужен ли экспертный review.

Проверка: SEO-check может поставить `warning`, но не должен ломать стиль ради частотности.

Шаг 23. Настройте brand-проверку

Brand-check сравнивает черновик с `brand_rules`.

Запрещенные сигналы:

гарантируем рост
100% результат
лучший на рынке без доказательств
мгновенно решит все задачи
заменит специалиста полностью
не требует контроля

Если найдено:

1. записать `content_checks.status = failed`;
2. указать правило `rule_id`;
3. предложить безопасную формулировку;
4. поставить draft в `needs_brand_check`.

Проверка: фраза “ИИ-агент полностью заменит маркетолога” не проходит.

Шаг 24. Создайте approval_queue

Лист `approval_queue` хранит согласования.

Колонки:

approval_id
draft_id
topic_id
approval_type
assigned_to
status
decision
decision_comment
created_at
decided_at

Типы:

brief_approval
draft_approval
brand_review
expert_review
publication_approval

Решения:

approved
needs_fix
rejected
postpone

Проверка: публикация возможна только после `publication_approval = approved`.

Шаг 25. Создайте publication_queue

Лист `publication_queue` хранит материалы, готовые к публикации.

Колонки:

publication_id
draft_id
calendar_id
channel
target_url
scheduled_at
status
approved_by
published_at
published_url
error_message

Статусы:

waiting
scheduled
published
failed
cancelled

Для первой версии используйте безопасный режим:

1. агент готовит материал;
2. редактор утверждает;
3. агент создает draft в CMS или Google Docs;
4. человек публикует вручную;
5. в таблицу записывается `published_url`.

Проверка: без `approved_by` строка не получает `scheduled`.

Шаг 26. Подключите CMS или редакционный инструмент

Выберите один путь.

Вариант 1: Google Docs.

1. агент создает документ;
2. вставляет title, brief, draft и checklist;
3. дает ссылку редактору;
4. редактор публикует вручную.

Вариант 2: CMS draft.

1. агент создает черновик через API;
2. ставит статус `draft`;
3. заполняет title, slug, body, meta;
4. не нажимает publish;
5. редактор проверяет в админке.

Вариант 3: Notion или Trello.

1. агент создает карточку;
2. прикладывает brief и draft;
3. ставит checklist;
4. назначает ответственного.

Проверка: в live-публикацию ничего не уходит автоматически.

Шаг 27. Создайте performance_log

Лист `performance_log` хранит результаты публикаций.

Колонки:

metric_id
publication_id
published_url
date
channel
impressions
clicks
ctr
sessions
engagement_rate
conversions
avg_position
comments
shares
leads
note

Проверка: через 7, 30 и 90 дней по статье можно увидеть результат, а не просто дату публикации.

Шаг 28. Настройте отчет report_snapshots

Лист `report_snapshots` хранит регулярные отчеты.

Колонки:

report_id
report_type
period_start
period_end
generated_at
metrics_json
summary
next_actions_json
status

Еженедельный отчет:

{
  "planned_items": 12,
  "briefs_ready": 5,
  "drafts_ready": 4,
  "waiting_approval": 3,
  "published": 2,
  "needs_update": 6,
  "top_topics": ["ИИ-агенты", "RAG", "локальные модели"],
  "blocked_items": ["brief_102", "draft_087"]
}

Проверка: отчет заканчивается списком следующих действий, а не только summary.

Шаг 29. Настройте audit_log

Лист `audit_log` нужен, чтобы понимать, кто и когда изменил план.

Колонки:

event_id
created_at
actor
entity_type
entity_id
action
before_json
after_json
reason
system

Логируйте:

1. импорт запросов;
2. создание кластера;
3. создание темы;
4. изменение приоритета;
5. создание брифа;
6. создание черновика;
7. провал проверки;
8. approval;
9. создание публикационной очереди;
10. запись результата.

Проверка: можно восстановить, почему тема попала в календарь.

Шаг 30. Настройте error_log

Лист `error_log` хранит сбои.

Колонки:

error_id
created_at
entity_type
entity_id
step
severity
error_code
message
raw_payload_url
resolved
resolved_by
resolved_at

Типовые `error_code`:

keyword_import_failed
llm_json_invalid
cluster_failed
missing_pillar
missing_segment
brand_check_failed
fact_check_required
cms_api_failed
analytics_api_failed
duplicate_topic

Проверка: если модель вернула невалидный JSON, тема не пропадает, а получает ошибку `llm_json_invalid`.

Шаг 31. Протестируйте на контрольном наборе

Соберите тестовые данные:

1. 20 похожих запросов по одной теме;
2. 10 запросов с разным intent;
3. 5 тем, уже закрытых текущими статьями;
4. 3 темы без сегмента;
5. 3 темы с юридическими или финансовыми утверждениями;
6. 1 черновик с выдуманной статистикой;
7. 1 черновик с фразой “гарантируем рост”;
8. 1 topic cluster, который должен пойти в manual review.

Ожидаемые результаты:

похожие запросы объединяются
дубли текущих статей идут в update_existing
спорные утверждения идут в expert_review
публикация без approval невозможна

Проверка: после изменения prompt тестовый набор проходит без регрессий.

Шаг 32. Проверьте минимальный результат

Прототип готов, если:

1. запросы попадают в `keyword_pool`;
2. intent классифицируется;
3. темы создаются в `topic_backlog`;
4. похожие запросы объединяются в `topic_clusters`;
5. календарь заполняется в `content_calendar`;
6. бриф создается в `content_briefs`;
7. черновик создается в `draft_queue`;
8. проверки пишутся в `content_checks`;
9. без approval нет публикации;
10. approved-материал попадает в `publication_queue`;
11. результаты пишутся в `performance_log`;
12. все изменения видны в `audit_log`.

Проверка: возьмите 30 запросов, получите 3-5 кластеров, один бриф, один черновик и одну строку в approval.

Что нельзя автоматизировать в первой версии

Не автоматизируйте сразу:

1. публикацию на сайт без редактора;
2. массовую генерацию статей без брифов;
3. запуск рекламы;
4. изменение бренд-позиционирования;
5. обещания результатов без доказательств;
6. публикацию кейсов без подтверждения;
7. юридические, медицинские и финансовые советы;
8. удаление старых страниц;
9. замену редактора полностью;
10. автоматическую перелинковку на сайте без проверки;
11. публикацию чужих цитат без разрешения;
12. использование персональных данных клиентов без согласия.

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

Частые вопросы

Может ли агент сам вести контент-план?

Он может обновлять таблицу, предлагать темы, даты, брифы и статусы. Но редактор должен утверждать приоритеты, черновики и публикации, иначе контент-план быстро превратится в поток слабых материалов.

Можно ли сразу генерировать статьи пачками?

Технически можно, но для сайта это плохой старт. Сначала проверьте кластеризацию, брифы, бренд-правила и качество одного материала. Массовая генерация без контроля дает дубли, воду и фактические ошибки.

Что лучше брать за основу: Wordstat или Search Console?

Для новых тем удобен Wordstat или Keyword Planner. Для улучшения текущих страниц важнее Search Console: она показывает реальные запросы, показы, клики и позиции уже опубликованных материалов.

Как агент должен работать со старыми статьями?

Если тема уже закрыта, агент должен ставить `update_existing`, а не создавать дубль. В брифе на обновление нужно указать, какие разделы устарели, какие запросы не закрыты и какие внутренние ссылки добавить.

Какой минимум нужен для запуска?

Таблицы `keyword_pool`, `existing_content`, `topic_backlog`, `topic_clusters`, `content_calendar`, `content_briefs`, `draft_queue`, `content_checks`, `approval_queue`, n8n workflow, LLM JSON prompts и обязательный `audit_log`.