Как я автоматизировала подготовку статей Stavia Models через ИИ-агента в Cursor

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

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

Для Stavia Models мне нужно было научить агента готовить статьи так, как я обычно делаю это сама: с опорой на методологию продукта, проверкой источников, поиском релевантных бенчмарков и примеров, визуальными блоками и нормальной редакционной проверкой.

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

Этот процесс сработал не потому, что агент оказался особенно умным. У Stavia уже была реальная основа, на которую он мог опереться.

Stavia Models — продукт со своей логикой финансового моделирования: ценообразование, привлечение пользователей, удержание, структура затрат и на основе этих вводных — юнит-экономика, финансовые прогнозы и подготовка к привлечению финансирования. Блог тоже был частью продукта: статьи создавались как code-first страницы сайта, а не как отдельные текстовые файлы.

До автоматизации я уже опубликовала около двадцати статей вручную или полуавтоматически. Эти материалы стали ориентиром для будущего процесса. Они показывали, что должна объяснять статья Stavia, насколько практичной она должна быть, как в ней появляется продуктовая логика, какие визуальные блоки работают и как быть для читателей полезнее ответа в ИИ-чате.

Если бы я начала с пустого блога и попросила агента делать SEO-контент, он бы просто производил много поверхностных материалов. Автоматизация получилась полезной только потому, что уже была контент-система, которую имело смысл ставить на поток.

К моменту запуска автоматизации у блога Stavia уже был узнаваемый формат.

Статья должна раскрывать не общую финансовую тему, а решение, которое фаундер принимает в модели. Как установить цены для разных планов подписки, как пробный период влияет на конверсию, почему расходы на AI/API могут съесть маржу, какие бенчмарки нужны для вводных данных и как защитить финансовый прогноз перед инвестором.

Структуру страницы я отработала на самой первой статье, закрепив её компоненты для использования дальше. В начале нужен быстрый ответ, дальше — практичные разделы, внутренние ссылки, визуальные и интерактивные блоки, блок с содержанием и CTA.

Всё это стало эталоном для агента. Ему не нужно было угадывать, как выглядит хорошая статья Stavia. В проекте уже были примеры.

Большая часть редакционной системы выросла из работы над первыми статьями в ChatGPT.

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

Часть правок была про голос: убрать рекламный тон, продвигать продукт только нативно, писать естественно, не перегружать терминами, но и не скатываться в объяснения для младших школьников. Отдельно пришлось бороться с типичными ИИ-паттернами в тексте, которые появляются даже у сильных моделей.

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

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

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

ChatGPT оказался полезен не только для черновиков. Он помог систематизировать повторяющуюся обратную связь: что я обычно принимаю, что отклоняю, когда нужны источники, когда нужны бенчмарки, где нужен пример моделирования, а где достаточно продуктовой логики.

Эта редакционная политика стала основой для документации, с которой дальше работает агент.

Когда я перешла от подготовки статей с помощью ИИ к автоматизации через ИИ-агента, стало понятно, что одного большого промпта недостаточно.

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

Без такой документации агент каждый раз заново изобретал бы процесс, а качество результата могло бы заметно отличаться от запуска к запуску. Когда правила лежат в проекте, агент может открыть их перед задачей и действовать внутри системы.

То, что я пока не готова отдавать полной автоматизации, — это контент-план. Его я по-прежнему готовлю с помощью ИИ в ChatGPT и в несколько итераций довожу до нужного качества.

Потом этот план превращается в очередь статей для агента. Каждая тема в очереди — это не просто название и ключевое слово, а рабочий бриф. В нём есть название, slug, фокус статьи, целевой читатель, ключевые слова, отличие от уже опубликованных материалов, что обязательно включить, чего избегать, нужны ли источники, бенчмарки или пример с цифрами.

Особенно полезными оказались два поля: почему эта статья нужна сейчас и какую ценность она даёт сверх обычного ответа ИИ-чата.

Эти поля хорошо отсекают слабые темы. Если статья не добавляет ничего нового к уже опубликованному контенту и к тому, что пользователь может получить в чате с ИИ, её не стоит отдавать агенту.

Так очередь стала не списком идей, а набором утверждённых задач. Агент берёт следующий готовый бриф и делает по нему страницу.

Перед ежедневной автоматизацией я протестировала процесс вручную в режиме агента Cursor.

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

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

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

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

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

Со второй статьёй я уже была довольна первым результатом агента и опубликовала её без правок. Но даже при хорошем результате я не планировала публиковать без предпросмотра. Финальная проверка по-прежнему остаётся частью процесса.

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

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

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

Раньше процесс шёл несколькими этапами. Сначала мы работали над текстом: логика статьи, структура, примеры, источники, тон и практическая ценность. Затем Cursor превращал утверждённый черновик в страницу сайта, собранную в коде. Потом я снова проверяла уже страницу, потому что текст, который хорошо выглядит в документе, должен работать и в реальном интерфейсе сайта.

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

Технически всё устроено просто: Cursor создаёт статью в отдельной ветке GitHub, а Vercel собирает предпросмотр этой ветки. Вместо прямой публикации на сайт я получаю ссылку на почти готовую страницу.

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

Если всё в порядке, я объединяю ветку с основной, и статья выходит на сайт. Если вижу, что можно усилить фокус, добавить пример, поправить блок или сделать формулировку точнее, отправляю материал на доработку.

Эта граница для меня принципиальна. Агент может подготовить страницу к публикации, но не должен публиковать её сам. Технически запустить полностью автономную фабрику контента не так сложно, но в своих проектах я предпочитаю отвечать за то, что публикую.

После первого теста я перенесла процесс в Cursor Cloud Automation.

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

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

Техническая часть оказалась менее драматичной, чем может звучать. Для облачной автоматизации нужны расписание, репозиторий, блок инструкций и доступ к нужным файлам.

Сложнее решить, что агент должен читать, что он может менять, что не должен решать самостоятельно и где обязан остановиться. Когда эти границы ясны, инструкция для автоматизации может быть относительно короткой, потому что настоящий процесс уже живёт в репозитории.

Когда ежедневная подготовка статей заработала, следующий вопрос был про поддержку уже опубликованного контента.

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

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

Второй процесс — проверка свежести источников. Он чувствительнее: бенчмарки, рыночный контекст, цены API, условия финансирования и утверждения на основе внешних данных. Поэтому здесь агент должен готовить отчёт или PR для проверки, а не молча менять опубликованный контент.

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

Когда процесс заработал, меня больше всего удивили не технические детали.

Этот кейс не про то, что ИИ умеет писать тексты. Это уже не новость.

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

Агент не создал эту экспертизу. Он сделал часть процесса подготовки статей повторяемой.

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

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