ИИ сотрудники Claude Code
Вопрос «как создать эффективных сотрудников» из ИИ агентов Claude Code решается не одной удачной командой. Если написать Claude Code «сделай мне приложение», толку будет мало. Чтобы он вёл себя как настоящий сотрудник, ему нужно то же самое, что получает новый человек в компании: рабочее место, память о продукте и клиентах, понятную постановку задачи, возможность сначала показать план, способ проверить результат, стандарты качества, регулярные обязанности, границы полномочий и инструменты под типовые операции.
Цикл в итоге получается такой: фактура клиентов, приоритет, план, маленькая задача, выполнение, проверка, решение человека, новая фактура.
Эффективный ИИ агент тут не про модель саму по себе. Это про то, как вокруг неё выстроен процесс.
1. Рабочее место и «мозг» проекта
Первый шаг к тому, чтобы вырастить из Claude Code эффективного сотрудника, а не разового исполнителя команд, — дать ему рабочее место. Claude должен работать внутри конкретного репозитория, где лежит продукт, документы, обратная связь и правила игры.
Структура примерно такая:
project/
├── app/ — сам продукт
├── context/ — бизнес-контекст и рабочие сводки
├── customers/ — интервью, звонки, обращения, возражения
├── spec/ — требования к продукту
├── demos/ — сценарии демонстраций, скриншоты, Loom
├── routines/ — задания, которые запускаются регулярно
├── CLAUDE.md — как ИИ должен работать
├── roadmap.md — что сейчас важно
└── review.md — по каким критериям проверять результат
CLAUDE.md
Здесь прописана инструкция для ИИ агента: чем занимается бизнес, кто клиент, какую проблему решает продукт, что считается хорошей работой, как обращаться с файлами, когда сначала показывать план, насколько крупными могут быть изменения, какие проверки запускать после работы и в каком виде сдавать результат.
Примерные правила:
- Делай небольшие изменения, которые легко проверить.
- Перед изменением поведения продукта сначала покажи план.
- Не переписывай соседние части проекта без необходимости.
- Соблюдай существующий стиль.
- После работы запускай подходящие проверки.
- В финале перечисляй изменённые файлы, проведённые тесты и то, что должен проверить человек.
roadmap.md
Тут фиксируется текущий приоритет.
Текущая цель:
Показать, как сервис возвращает потерянные заявки медицинской клинике.
На этой неделе:
— лендинг
— форма заявки
— демонстрационный сценарий
— отправка демо десяти потенциальным клиентам
Пока не делаем:
— оплату
— полноценную CRM
— кабинет администратора
— сложные роли и права доступа
Раздел «пока не делаем» здесь важен не меньше остального. Без него агент легко начинает строить космолёт вместо первой версии продукта.
review.md
Проверочный лист проекта: соответствует ли изменение текущей цели, можно ли быстро понять, что изменилось, работает ли основной сценарий, что происходит при ошибках, нет ли проблем на мобильном, не затронуты ли авторизация, платежи и реальные данные, не добавлена ли лишняя сложность, понятен ли продукт новому посетителю за первые пять секунд, использует ли текст реальные слова клиентов.
Промт для первого запуска
Помоги организовать этот репозиторий как рабочее место ИИ агента.
Создай или обнови:
CLAUDE.md, roadmap.md, review.md,
а также папки context, customers, spec, demos и routines.
Контекст бизнеса:
Продукт: […]
Клиент: […]
Проблема: […]
Обещанный результат: […]
Ближайшая цель: […]
Сохрани первую версию простой.
Перед созданием файлов задай только те вопросы,
ответы на которые действительно изменят структуру или правила работы.
2. Сначала бриф и план
Для любой значимой задачи лучше начинать с режима планирования. ИИ сначала читает контекст, изучает существующий продукт, понимает ограничения, предлагает способ решения, перечисляет затрагиваемые файлы, называет риски, описывает проверку и только потом ждёт подтверждения.
Здесь работает старое правило: сначала дважды отмерить, потом менять файлы.
Сначала изучи CLAUDE.md, roadmap.md, review.md
и текущую реализацию продукта.
Нужно: […]
До редактирования покажи:
1. какие файлы придётся изменить
2. минимальный способ решить задачу
3. как изменится пользовательский сценарий
4. возможные риски
5. как проверить результат
6. что намеренно не войдёт в первую версию
Пока ничего не меняй.
План не обязан быть идеальным. Его ценность в том, что человеку есть на что отреагировать: упростить форму, запретить менять базу, сохранить только демонстрационный сценарий, подключить реальное хранение заявок, убрать лишнюю функциональность.
3. Задача у который конкретный итог
Claude работает намного лучше, когда точно знает, как выглядит «готово». Без этого он вынужден додумывать за вас.
Возьмите формулировки вроде «улучши приложение», «сделай более вирусно», «добавь ИИ», «построй весь продукт», «сделай, чтобы выглядело дороже» — по ним невозможно понять, что именно нужно сделать. Агент начинает угадывать, и тогда роли меняются: вместо того чтобы управлять работой, человек потом разгребает результат.
С хорошим заданием всё иначе. В нём есть конкретная проблема, чёткий участок продукта, который можно трогать, ожидаемое поведение, критерии приёмки, ограничения и понятный способ проверки. Например, так:
Добавь на лендинг форму листа ожидания.
Поля:
— имя
— компания
После отправки покажи понятное подтверждение.
Сохрани текущий визуальный стиль.
Не меняй авторизацию, платежи и остальную навигацию.
Готово, когда:
— форма работает
— ошибки заполнения понятны
— сценарий проверен на компьютере и мобильном
— в консоли нет новых ошибок
Держите в голове простую формулу: одна сессия — одна задача — один результат, который легко посмотреть и проверить.
4. Дайте агенту «глаза»
После того как функция готова, Claude должен сам открыть продукт и пройти пользовательский сценарий. Того, что код собирается, недостаточно. Страница может технически работать и при этом быть непонятной, выглядеть ненадёжно, плохо работать на мобильном, не объяснять, что произойдёт после отправки формы, или показывать кнопку, которую никто не заметит.
Глазами клиента важно проверить: что человек понял за первые пять секунд, понятна ли польза, вызывает ли страница доверие, видно ли следующее действие, используются ли слова, которыми говорит сам клиент.
Глазами оператора продукта: запускается ли приложение, работают ли кнопки и формы, что происходит при пустой отправке, появляется ли успешное состояние, записались ли данные, есть ли ошибки в консоли или сетевых запросах, не сломался ли соседний сценарий.
В примере из ролика Claude заметил, что форма просит email, но не объясняет, что пользователь получит и будут ли ему слать спам. Агент добавил короткое пояснение рядом с кнопкой.
Запусти приложение и проверь изменённый сценарий.
Пройди его как новый клиент:
— что понятно за первые пять секунд
— что вызывает сомнение
— заметно ли основное действие
— работают ли ошибки и успешное состояние
Затем проверь реализацию:
— консоль
— сетевые ошибки
— запись данных
— компьютерную и мобильную версии
Найди одну проблему с самым сильным влиянием
и сделай один сфокусированный проход по её исправлению.
Как только ИИ начинает быстро производить изменения, всё упирается в человека: он должен решить, действительно ли сделано то, что нужно. И тут работает не одна проверка, а сразу две.
Сначала человек смотрит на сами изменения — открывает визуальное сравнение файлов и задаёт себе несколько вопросов. Соответствует ли результат заданию? Совпадает ли он с тем планом, который согласовали заранее? Почему поменялись именно эти файлы, и нет ли среди них чего-то неожиданного? Не задело ли это платежи, базу, маршрутизацию или авторизацию? Именно неожиданные изменения чаще всего и несут риск, поэтому на них стоит смотреть в первую очередь.
Дальше подключается сам Claude — он проверяет свою работу по review.md:
Используй review.md как стандарт качества.
Проверь текущие изменения на:
— ошибки
— сломанные пользовательские сценарии
— непонятное поведение
— риски безопасности
— лишнюю сложность
— выход за границы задачи
— противоречие roadmap.md
Раздели результат на:
1. обязательно исправить
2. желательно исправить
3. можно выпускать
Не исправляй автоматически проблемы высокого риска.
Сначала покажи их мне.
Если изменения серьёзные — затрагивают авторизацию, платежи, персональные данные, миграции, архитектуру или выпуск в продакшен — одной такой проверки мало. Здесь нужен отдельный, более глубокий разбор. И в любом случае самопроверка ИИ не заменяет человеческую приёмку — последнее слово всегда за вами.
6. Расписание и повторяющиеся обязанности
Следующий шаг — дать агенту задачи, которые он выполняет регулярно. Начинать лучше с безопасной аналитической работы, а не с ночного изменения продакшена.
Утренняя сводка. Каждое утро агент читает свежие обращения клиентов, заметки с интервью, открытые задачи и текущий план. На выходе формирует главную боль клиента, один риск для продукта, одну рекомендуемую задачу и один вопрос, который хорошо бы сегодня задать клиентам. При этом код не меняется, пул-реквест не создаётся, отчёт не раздувается, результат сохраняется в конкретный файл.
Еженедельный операционный обзор. По пятницам агент группирует похожие проблемы, ищет дубли, находит повторяющиеся жалобы, рекомендует одно изменение с максимальной отдачей и сохраняет сводку в context/weekly-ops.md.
Проверка каждого пул-реквеста. При открытии пул-реквеста агент сверяет его с review.md и пишет только о том, что может привести к ошибке, поломке сценария, риску безопасности или непонятному поведению.
Так получается «ночная смена», которая не бесконтрольно пишет продукт, а поддерживает порядок в фактуре, задачах и рисках.
Стоит помнить: локальные задачи Claude Desktop работают только при запущенном приложении и бодрствующем компьютере. Облачные routines продолжают работать при выключенном ноутбуке, но запускаются без диалога подтверждения, поэтому им нужны минимальные доступы. И зелёный статус запуска ещё не значит, что задача выполнена правильно — итоговый отчёт и результат всё равно нужно читать самому.
7. Параллельные сотрудники и изоляция работы
Несколько сессий могут одновременно решать разные задачи: одна исправляет ошибку, вторая улучшает первый экран лендинга, третья собирает сценарий демонстрации из клиентских интервью.
Для каждой сессии нужны своя задача, общий контекст проекта, свой набор файлов, ожидаемый формат сдачи и отдельная ветка или worktree — отдельная рабочая копия репозитория, благодаря которой изменения разных агентов не смешиваются.
Хорошая сдача задачи от агента включает причину проблемы, список изменённых файлов, проведённые проверки, что смотреть в сравнении файлов, что осталось неясным и что должен решить человек.
Цель параллельной работы — получить несколько небольших проверяемых пакетов, а не гору изменений к вечеру.
8. Три уровня разрешений
Можно выполнять самостоятельно: читать файлы, изучать код, собирать контекст, предлагать план, запускать локальные тесты, редактировать небольшую изолированную ветку, обновлять документацию, готовить черновик пул-реквеста.
Сначала спросить: установить новую зависимость, изменить структуру базы, затронуть авторизацию, изменить платёжную логику, удалить файлы, провести крупный рефакторинг, изменить внешнюю интеграцию.
Оставить человеку: выпуск в продакшен, решения о деньгах, действия с реальными клиентскими данными, критические настройки безопасности, необратимые операции, отправку сообщений или публикаций от имени компании.
Автономность расширяется постепенно: сначала нормальная память проекта, потом маленькие задачи и проверка, дальше расписание, и уже после этого более широкие права. Автор ролика прямо называет «YOLO-режим» плохой управленческой стратегией.
9. Skills, connectors и hooks
Это три разных слоя.
Skills — повторяемые способы работы. Если один и тот же промпт приходится писать снова и снова, его лучше превратить в навык. Из ролика: разбор лендинга глазами владельца клиники, извлечение слов клиентов из интервью, поиск повторяющихся возражений, создание демонстрационного сценария, проверка понятности первого экрана. Навык описывает не только действие, но и стандарт результата.
Connectors дают агенту доступ к рабочим системам: GitHub, Google Drive, Slack, Linear, календарю и другим корпоративным сервисам. Главный риск в том, что коннектор может давать не только чтение, но и запись. Для фоновой задачи нужны только те сервисы и права, которые ей реально требуются.
Hooks — автоматические предохранители: после редактирования запускать форматирование, перед сдачей задачи запускать тесты, перед созданием пул-реквеста проверять сборку, запрещать завершение работы при проваленных проверках.
Проще говоря: skill объясняет, как выполнять типовую работу, connector даёт нужные данные и действия, hook автоматически проверяет процесс.
План внедрения на семь дней
День 1. Подготовить CLAUDE.md, roadmap.md, review.md и папки context, customers, spec, demos, routines. Записать клиента, проблему, ближайшую цель и определение готовности.
День 2. Взять одну небольшую задачу и попросить агента изучить репозиторий, вернуть план, список файлов, риски, способ проверки и границы первой версии.
День 3. Собрать одно видимое улучшение — форму, страницу цены, демонстрационный сценарий или исправление одной ошибки. Достаточно маленькое для проверки и достаточно настоящее для демонстрации клиенту.
День 4. Запустить визуальную проверку: попросить Claude открыть продукт, пройти сценарий, проверить мобильную версию и исправить одну самую важную проблему.
День 5. Провести ревью: человек смотрит сравнение файлов, затем Claude проверяет изменения по review.md.
День 6. Показать демонстрацию десяти потенциальным клиентам и положить их ответы в customers/, сохраняя исходные формулировки.
День 7. Создать первую routine — начать с безопасной утренней сводки, где агент читает обратную связь и рекомендует следующую небольшую задачу.
После этого цикл начинает подпитывать сам себя.
Важно
Контекст должен быть сохранен отдельно, не в памяти чата — иначе он рано или поздно потеряется. Сначала стоит объяснить ИИ бизнес-контекст, и только потом ставить техническое задание. И важно фиксировать не только приоритеты, но и то, что пока строить не нужно.
С самой работой тоже связана пара правил. Перед значимыми изменениями лучше сначала попросить план, не трогая файлы. У каждой задачи должна быть одна проверяемая финишная черта, а изменения имеет смысл держать достаточно маленькими, чтобы человек успевал их проверить. И проверять нужно живой продукт, а не только код и сборку: смотреть на него глазами клиента и оператора одновременно, использовать в текстах реальные слова клиентов.
Отдельно стоит сказать про проверку результата. Обязательные исправления, желательные улучшения и то, с чем вполне можно жить, лучше не смешивать в одну кучу. Автоматизацию разумно начинать с чтения и аналитики, а не сразу давать права на запись. Фоновой задаче не стоит давать больше доступа, чем ей реально нужно, параллельную работу лучше разводить по отдельным worktrees, а от каждого агента требовать понятную сдачу работы.
И главное: деньги, продакшен, безопасность и клиентские данные всегда остаются за человеком. Повторяющиеся промпты стоит превращать в skills, а проверки — автоматизировать через hooks. Ну и roadmap.md, review.md и клиентскую фактуру нужно обновлять регулярно — иначе «мозг проекта» начинает уверенно работать по устаревшим правилам.
