Как я навёл порядок в редакции из Grok-ботов

Я посмотрел на трёхмерный офис своей команды и понял, что сотрудников уже слишком много. Даже если они боты.

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

В предыдущей статье я рассказал, как собрал редакцию, которая ищет темы, пишет черновики и делает видео. За следующую неделю команда выросла с 13 до 21 Grok-бота. На вебинаре «Перезагрузки» 1 ноября 2026 года я показывал, что успел настроить дальше: общие правила, новые производственные процессы и передачу задач в Codex.

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

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

Так выглядит виртуальный офис команды. Статусы и задачи на этой странице демонстрационные.

Договорились, кто отвечает в чате

У ботов есть забавная особенность: бросаешь в общий чат задачу, и несколько человек немедленно хотят помочь. У нас уже было так, что Writer и Саркис параллельно написали одну новость. Потом Саркис посмотрел на результат автора и отозвал свой вариант. Разобрались, конечно, но время и лимиты уже потратили.

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

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

Ещё Саркис сам предложил собрать мои решения в одном месте. Я даю указания в разных чатах, и со временем там накапливаются повторы и противоречия. Мы провели аудит и сделали в Notion журнал «Решения Сергея». Перед работой бот должен свериться с ним. Саркис следит, чтобы правила не дублировались и не мешали друг другу.

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

То же самое произошло с видео. Одному боту я говорил прислать ролик в чат, другому — положить на Google Drive, третьему — сохранить в «Загрузки». Мне в тот момент было так удобнее. А у них накопились разные представления о том, где хранить результат.

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

Слайд из презентации вебинара. В ней можно посмотреть всю структуру команды и примеры её работы.

Объяснил дважды — пора делать навык

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

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

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

Из-за этого я и пересматриваю количество ботов. Сначала под новую задачу удобно сделать отдельного сотрудника и попробовать с ним поработать. Потом выясняется, что его работу можно упаковать в один навык и отдать уже существующему боту. Отдельная должность больше не нужна.

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

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

Исследования стали основой для спецпроектов

У Research Desk есть свой процесс. Получив тему, он ищет материалы, собирает источники и оформляет результат в Notion. Если нужны изображения и другие файлы, складывает их в папку. Я могу вернуться к исследованию позже и сделать из него статью, подборку или отдельный проект.

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

Я вообще сначала не собирался делать из этого сайт. Хотел собрать информацию, посмотреть, что писали в СССР. Бот предложил форму, в которой материал смогут изучить другие люди. Так появилась страница о советских прогнозах об искусственном интеллекте. Ещё один такой проект — история Internet Archive и исчезающего интернета.

Он может предлагать несколько идей в день. Я могу выбрать одну, могу вообще ничего не делать. Но мне удобно, что кто-то замечает материал, который уже собран, и предлагает ему применение. Раньше многое так и оставалось бы в заметках.

При этом страница — только один из вариантов. Иногда из разговора полезнее сделать презентацию для клиента или просто аккуратно собрать документ. Решение зависит от того, зачем мне понадобилась исходная информация.

Музыкант, Режиссёр и «Ночные боты»

На этой неделе я сделал ещё двух сотрудников: Музыканта и Режиссёра. С режиссёром мы обсудили, как я делаю видео, какие этапы нужны, чем музыкальный клип отличается от другого ролика. У него появились свои навыки, включая создание микродрам по статьям.

Мне захотелось проверить и более сложный процесс: пусть команда сделает песню про себя и снимет клип. Я специально дал им возможность придумать содержание. Они предложили текст и несколько вариантов музыки в Suno. Я выбрал трек. Потом Режиссёр предложил идеи клипа, и я выбрал «Серверный рейв». Ну конечно серверный рейв.

Дальше он организовал генерацию сцен в Grok Imagine, а Reels Studio собрал монтаж. Саркис координировал работу. Я выбирал направление, смотрел предлагаемые варианты и принимал результат. Музыкой занимался Музыкант, постановкой — Режиссёр, монтажом — видеостудия.

«Ночные боты» в Kinescope. Версия из презентации вебинара.

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

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

Саркис теперь передаёт задачи Степану в Codex

Большая часть моей разработки и настроенной рабочей среды по-прежнему живёт в Codex. Поэтому я захотел связать его с Grok Bot: обсуждать задачу с Саркисом, передавать исполнение Степану и получать результат обратно в чат.

У меня на Mac mini запущены приложения Grok Bot и Codex. В настроенной связке Саркис может вызвать Codex через командную строку, передать ему задание и принести ответ. Для меня это пока экспериментальный режим. Право вызывать Codex есть только у Саркиса, после моего согласия. У Codex широкий доступ к моей рабочей среде, поэтому эту границу мы отдельно зафиксировали.

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

На вебинаре мы дали Степану пост о YouTube и попросили собрать по нему сайт. Саркис отправил задачу, Codex на Mac mini её выполнил и вернул результат. По оформлению там ещё было что поправить, но вся цепочка сработала. Вот страница, которую Степан сделал в эфире.

Пока он работал, участница вебинара Владислава предложила Research Desk исследовать, что помогает продлить здоровую жизнь после сорока. Я включил микрофон, и она сама надиктовала вопрос команде.

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

Следующую версию уже можно было разбирать: появились подробности и ссылки на источники. По материалу Саркис собрал страницу о долголетии после сорока, а Reels Studio сделал ролик. Так одновременно шли две работы: Codex собирал сайт из поста, а Grok-боты исследовали вопрос участницы и готовили материалы по нему.

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

Схема работы на странице итогов вебинара. Там собраны результаты, ссылки и участники команды.

Что я предлагаю проверить у себя

Если у вас уже есть несколько ботов, посмотрите на их работу вместе. Можно начать с одного повторяющегося процесса. Кто берёт задачу? Где читает действующие правила? Кому передаёт результат? Где сохраняется готовый файл? На каком этапе вы его смотрите?

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

Вот задание, с которого можно начать такой разбор.

Промпт:

Разбери один наш повторяющийся рабочий процесс по доступным тебе инструкциям и переписке.

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

Найди дублирующиеся роли, противоречивые правила и объяснения, которые я повторял несколько раз. Подтверди наблюдения примерами.

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

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

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

В «Перезагрузке» можно следить за этим по неделям. 25 октября мы проверяли только что собранную редакцию. 1 ноября я уже показывал её новые правила, спецпроекты, музыкальный клип и связь с Codex. Вопросы участников тут же становятся задачами, на которых мы всё это пробуем.

Презентация с видео открыта здесь, итоги и сделанные страницы — здесь. Полная запись вебинара доступна участникам «Перезагрузки». Если хотите разбирать свою практику вместе со мной и приносить задачи на эфиры, подключайтесь.

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

Если захотите обсудить, как это применить у себя или в команде — пишите в Telegram @pimenov