Лучшие практики работы с ИИ-инструментами

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

Совет #1: Детальное описание задачи

Часто нам очень лень детально описывать задачу даже своим коллегам, что уж там говорить про ИИ. К сожалению, такие промпты вряд ли приведут нас к желаемому результату:

  • “Создай LLM-алерт-менеджер, который будет умным способом группировать алерты из Графаны в инциденты”
  • “Добавь в проект фичу по автоматическому анализу сообщений пользователей и изменению уровня критичности инцидента по результатам анализа”

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

Пайплайн создания задачи

  1. Описываем задачу или проект по шаблону

В шаблон можно включать:

  • Цель (чего хотим достичь с точки зрения UX)
  • Definitions-of-Done (можно в формате примеров инпут - желаемый аутпут или списка тестов)
  • Ограничения скоупа (что НЕ НАДО делать - часто очень важно)
  • Желаемый стек и подходы
  • Релевантные материалы (всякие PDF, схемы, картинки)
  1. Просим LLM сделать ревью

В отдельном свежем чате в IDE, в браузере в ChatGPT или в специальном режиме Architect задаем уточняющие вопросы. Обязательно уточняем, что пока НЕ ПИШЕМ код.

  1. Пакуем итоговый план

Итоговый план пакуем в Markdown, делаем финальные правки и подаём как контекст в новый чат.

  1. Дополнительно для больших фич

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

Примечание: Есть специальные инструменты, заточенные именно под этап планирования - например, Traycer, а также фреймворки типа BMAD или OpenSpec. Но мы бы рекомендовали пробовать их, только если вы уже достаточно уверены в своих силах.

Совет #2: Настройка инструментов

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

Файл с правилами

Общий или проектный файл с правилами (.cursorrules, AGENTS.md, CLAUDE.md), который будет привязываться к каждому новому чату. Это не панацея, модели всё равно будут тупить и не слушаться, особенно при распухании чата, но польза точно есть.

Туда можно включить:

  • Общие гайдлайны по написанию кода - стиль, желаемая длина файлов
  • Инструкции по запуску разных команд - как запускать энвы, где брать секреты для обращения к разным API
  • Что нельзя делать, с упором на то, что особенно бесит лично вас:
    • “не добавляй комментарии к коду, если они не добавляют ценности к его пониманию”
    • “не создавай новые файлы без явного разрешения”
    • “не переходи от стадии планирования и вопросов к написанию кода без явного разрешения”
    • “не изменяй сами тесты, чтоб они проходили, без явного разрешения”
    • “НИ В КОЕМ СЛУЧАЕ не хардкодь никакие эдж-кейсы в коде”

Не рекомендуем сильно раздувать эти файлы, подробнее про это в разделе AI-friendly документация.

Memories / Memory Bank

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

Например, в Claude Code есть целый раздел документации, посвящённый тому, как работает ручная и автоматическая память.

MCP

Не утихают споры о полезности MCP - многие считают, что они только забивают контекст и ничем не отличаются от API. Зерно правды в этом есть, но практически замечено, что польза есть - проще настроить разные MCP с нужными доступами, а затем в чате упоминать, когда вызов того или иного инструмента оправдан.

Примеры полезных в нашей работе MCP:

  • Postgres - read-only для чтения данных из БД со статистикой
  • Kubernetes - для чтения логов задеплоенных приложений
  • Grafana - для чтения списка алертов
  • Context7 - предоставляет актуальные спецификации библиотек
  • Puppeteer - для открытия и чтения содержимого сайтов, может даже делать скриншоты

Важно! Если возможно, обязательно сразу отключите в них лишние инструменты - для безопасности (чтоб LLM не дропнула вам весь кластер в Кубике) и для экономии места в контекстном окне.

Подробнее об этом в разделе MCP и CLI.

Изучение документации

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

Совет #3: Выбор правильной модели

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

Но если вашей подписки хватает на условный Opus-4.6, мы бы порекомендовали использовать как основную модель и модель для субагентов именно его.

Планирование архитектуры

Часто считается наиболее сложным этапом, где лучше не экономить:

  • GPT-5.4 xHigh Reasoning
  • Claude Opus 4.6

Оркестрация

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

Написание кода и тестов

Многие переключаются на более дешёвые модели:

  • GLM-4.5
  • Kimi K2
  • Qwen 3.5
  • Grok Code Fast

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

Совет #4: Адаптация командных практик

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

Ревью и контроль качества

  • Делай ревью написанного ИИ-кода, спрашивай, что делает этот код, если непонятно
  • При работе с ИИ тупых вопросов не бывает - они так и норовят тебя обмануть
  • В конце работы над фичёй попроси модель посмотреть на текущий git diff и прибрать лишний код, убрать бесполезные комментарии и отметить потенциальные проблемы

Эффективная работа

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

Структура проекта

  • Важно поддерживать хорошую структуру репозитория и умеренную длину файлов - так агенту будет намного проще собирать нужный точечный контекст
  • Важно уделить внимание тестам - как минимум нужно несколько хороших end-to-end тестов, которые будут проверять всю функциональность

Для production-проектов

Если это не пет-проект, который не надо будет особо поддерживать, то обязательно:

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

Совет #5: Управление контекстом чата

Наверное, раз сейчас есть модели с контекстом в 1 миллион токенов, то лучше писать всё, что касается одного проекта или фичи, в один чат - чтоб не терялся контекст, так? Нет, не так.

Проблема распухания контекста

Агенты начинают жесточайше деградировать при распухании контекста. Если началась “компрессия контекста” (когда моделька саммеризирует содержание чата), то чаще лучше и проще начать новый чат и подать на вход необходимый контекст.

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

Как не терять контекст

Чтоб не терять контекст обязательно:

  1. Подаём на вход наш дизайн-док и общий ридми по репозиторию
  2. Полезная штука - вместо авто-компакта попросить модель саммеризировать текущее состояние работы над задачей, отревьюить, добавить недостающие элементы, а затем подать это саммери на вход в новый чат

Общая метафора

Работа с ИИ-агентами похожа на управление командой талантливых, но странных разработчиков:

  • Нужно правильно поставить задачу и дать весь нужный контекст
  • Обязательно следим за прогрессом и вмешиваемся при пробуксовке или явно ошибочном направлении
  • Сами всегда оцениваем план и принимаем окончательное решение, ведь ответственность за результат лежит на нас
  • Чёткие инструкции, контроль промежуточных результатов, код-ревью, тесты - маст-хэв
  • Запрещаем использовать стек или архитектурные решения, которые сами не понимаем

Следующая: Командные процессы

Предыдущая: Сессии и режимы работы