Использование ИИ агентов в работе программиста (Claude, Codex) над одной или несколькими задачами одновмеменно

ИИ-агент — это не просто чат, а младший разработчик с доступом к проекту.

Он может:

прочитать кодовую базу, найти нужные файлы, предложить план решения задачи, написать техническую спецификацию, изменить код, запустить тесты, найти ошибку, сделать рефакторинг, подготовить pull request или объяснить чужой код. Claude Code официально описывается как агентный coding assistant для фич, багов и автоматизации задач в кодовой базе; Codex — как coding agent для написания, ревью и отладки кода через CLI, IDE, web/mobile и CI/CD.

​

Но ответственность остается за программистом:

ИИ предлагает и меняет код → программист проверяет diff, архитектуру, безопасность и тесты.

Основыне понятия при работе с ИИ агентами

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

Coding agent — агент, специально заточенный под разработку.

Prompt — запрос к ИИ.

Context / контекст — информация, которую агент видит (получает) перед выполнением задачи.

Context window / окно контекста — максимальный объем информации, который модель может учитывать одновременно.

Instructions / инструкции — постоянные правила (не относящиеся к конкретной задаче, а вязанные со всем проэтом , например стилистика кода, ограничения и т.д.) для агента. (напрмиер в файле AGENTS.md или CLAUDE.md)

Tool — внешняя возможность, которой агент может пользоваться.

Tool use — процесс, когда агент сам решает вызвать инструмент.

MCP / Model Context Protocol — протокол подключения ИИ к внешним инструментам и данным.

MCP Server — сервер, который предоставляет агенту инструменты или данные.

Skill / навык — готовый пакет инструкций, ресурсов и иногда скриптов для определенной задачи.

Slash command — команда вида: /review и т.п.

Workflow — повторяемая последовательность действий.

Plan mode / режим планирования — режим, где агент сначала думает и составляет план, а не сразу меняет код. Для сложных задач это очень важно: сначала план → потом реализация

Task / задача — конкретная единица работы для агента.

Sub-agent / суб-агент — отдельный агент с узкой ролью.

Multi-agent — режим, где несколько агентов работают над разными частями задачи.

Agent Team / команда агентов — организованная группа агентов с ролями и общей задачей.

Memory / память — сохраненные сведения, которые агент может использовать между задачами или сессиями. например - стиль проекта, команды тестов, архитектурные правила, предпочтения команды, типичные ошибки

Repository context — контекст конкретного репозитория.

Sandbox / песочница — изолированная среда, где агент может выполнять код без риска сломать рабочую систему.

Diff — разница между старым и новым кодом.

Code review — проверка изменений.

Human-in-the-loop — принцип, что человек остается в процессе принятия решений.

Guardrails / ограничители — правила безопасности для агента.

Permissions / разрешения — что агенту можно делать.

Hooks — автоматические действия, которые срабатывают в определенный момент.

CI/CD agent — агент, встроенный в pipeline.

Headless mode — запуск агента без интерактивного чата. Такой режим удобен для автоматизации, CI/CD и скриптов.

RAG / Retrieval-Augmented Generation — подход, когда агент сначала ищет нужную информацию во внешних источниках, а потом отвечает.

Embeddings / эмбеддинги — числовое представление текста или кода, которое помогает искать похожие фрагменты.

Retrieval / извлечение информации — этап поиска нужных данных для агента.

Orchestrator / оркестратор — компонент, который управляет работой агентов и инструментов.

Уровень автономности — насколько самостоятельно агент может действовать.

Hallucination / галлюцинация — когда ИИ уверенно говорит неправду.

Grounding / заземление — привязка ответа агента к реальным данным.

Eval / оценка качества — проверка, насколько хорошо агент выполняет задачу.

Оптимизированная схема работы c AI agents

Общий цикл такой:

Задача
 ↓
Контекст проекта
 ↓
План от ИИ
 ↓
Проверка плана человеком
 ↓
Изменения в коде
 ↓
Запуск тестов / линтера
 ↓
Review diff
 ↓
Исправления
 ↓
Коммит / Pull Request

То есть не надо писать агенту:

Сделай мне оплату.

Лучше писать:

Нужно добавить поддержку оплаты через Checkout.com Flow.

Сначала изучи текущую структуру проекта:
- где создается заказ
- где вызывается платежная форма
- где обрабатывается callback/webhook

Пока не изменяй файлы. Сначала дай план: какие файлы нужно менять и почему.

Первый этап — дать агенту понять проект

Перед тем как просить писать код, можно попросить его исследовать проект (но не обязательно это делать).

Пример промпта:

Изучи проект и кратко опиши:
1. какая архитектура используется
2. где находятся контроллеры, сервисы, модели и тесты
3. как запускать тесты
4. какие правила кодстайла видны по проекту
5. какие файлы, скорее всего, связаны с задачей
Пока ничего не изменяй.

Это важно, потому что агент не должен сразу «ломиться» в код. Сначала он должен понять контекст.

Claude Code в документации прямо позиционируется как инструмент для исследования кодовой базы, исправления багов, рефакторинга, тестирования и повседневных задач разработки.

Второй этап — описать задачу как техническое ТЗ

Плохой вариант:

Исправь баг.

Хороший вариант:

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

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

Ограничения:
- не менять backend API
- не менять структуру формы
- сохранить совместимость с текущими обработчиками onSubmit и onCompleted

Сначала найди возможную причину и предложи 2-3 варианта решения.

Чем лучше формулировка, тем меньше агент будет фантазировать.

Третий этап — сначала план, потом код

Лучший порядок:

• 1. Проанализируй
• 2. Найди файлы
• 3. Предложи план
• 4. Подожди подтверждения
• 5. Только потом меняй код

Пример:

Нужно добавить фильтр по статусу заказа.

Сначала:
- найди контроллер, модель и Blade-шаблон списка заказов
- опиши текущий flow
- предложи план изменений
- не редактируй файлы без плана

После плана можно сказать:

Ок, реализуй вариант 2. После изменений запусти тесты и покажи diff.

Четвертый этап — маленькие задачи вместо одной огромной

Не надо давать агенту сразу:

Перепиши всю админку.

Лучше разбить:

• Задача 1: добавь поле slug в статьи.
• Задача 2: добавь миграцию.
• Задача 3: обнови форму.
• Задача 4: добавь валидацию.
• Задача 5: добавь тесты.

ИИ-агенты лучше работают, когда задача имеет четкие границы.

Где лучше использовать Claude / Codex

Хорошие задачи для ИИ-агента

• - найти место в проекте, где реализована логика
• - объяснить чужой legacy-код
• - написать CRUD
• - добавить тесты
• - найти причину ошибки
• - сделать рефакторинг небольшого модуля
• - обновить документацию
• - написать миграцию
• - проверить diff
• - найти edge cases
• - подготовить pull request

Codex, например, официально описывается как агент, который помогает писать код, понимать незнакомые кодовые базы и ревьюить код на баги, логические ошибки и непокрытые edge cases.

Плохие задачи для полного автопилота

• - сложная бизнес-логика с деньгами
• - платежи
• - безопасность
• - права доступа
• - миграции production-базы
• - криптография
• - персональные данные
• - массовое удаление данных

В этих местах ИИ можно использовать как помощника, но не как финального исполнителя без проверки.

Одновременная работа в нескольких ветках с разными задачами но в одном коде без клонирования с использованием ИИ агентов

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

Тогда возникает желание запускать генерацию кода длянескольких задач в нескольких ветках на одном компьютере и в одном окружении (например докер контейнере).

Просто создавать разные чаты/треды ИИ Агентов в одной ветке гит - недостаточно: они могут работать с одними и теми же файлами и конфликтовать.

Усчатью,для этого есть в гите стандартный способ — запускать каждую задачу в отдельной ветке + отдельном git worktree и в разных алис-папках.

Интересно, что хотя фича worktree в Git существует уже больше 10 лет, массово ее начали использовать сравнительно недавно — особенно с появлением AI-агентов и параллельной разработки, когда удобно держать десятки веток одновременно открытыми в отдельных каталогах.

Проверить свою версию Git:

git --version

Если версия новее 2.17, то весь привычный набор worktree уже доступен

Одновременная работа над разными задачами в Codex

Для Codex AI Agent / Codex CLI, для этого есть следующий способ — запускать каждую задачу в отдельной ветке + отдельном git worktree.

Схема работы

Допустим, есть 3 независимые задачи:

1. Новый API
2. Рефакторинг фронтенда
3. Написание тестов

Создаешь отдельные worktree:

git worktree add ../api-task feature/api
git worktree add ../frontend-task feature/frontend
git worktree add ../tests-task feature/tests

Получишь:

project-main/
api-task/
frontend-task/
tests-task/

Каждая папка привязана к своей ветке.

Далее открываешь 3 терминала:

cd ../api-task
codex

cd ../frontend-task
codex

cd ../tests-task
codex

И даешь каждому агенту свою задачу.

Хорошая декомпозиция параллельных тасок

Плохо:

• Агент 1: переделай авторизацию
• Агент 2: тоже переделай авторизацию

Будут конфликты.

Хорошо:

• Агент 1: backend авторизации
• Агент 2: UI логина
• Агент 3: тесты авторизации

Минимум пересечений по файлам.

После завершения

В каждой ветке:

git add .
git commit -m "done"

Потом:

git checkout main
git merge feature/api
git merge feature/frontend
git merge feature/tests

или через Pull Request'ы.

Практический пример-шаблон для одного человека разбиения на таски и додновременногоих выполнения

Тогда можно держать 3–5 агентов одновременно без серьезных конфликтов. Именно worktree является изоляцией, а не агент-чат/тред внутри Codex

Одновременная работа над разными задачами в Claude Code

У Claude Code есть встроенная нативная поддержка worktree, ручные команды git worktree add больше не обязательны.

Использование флаг --worktree (или -w)

Нужно запустить сессию сразу в изолированном worktree:

Терминал 1 claude -w feature-payments  

Терминал 2 claude -w bugfix-auth

Каждая сессия Claude Code работает в своем worktree — правки в одной сессии никогда не затрагивают файлы другой, поэтому можно одновременно строить фичу в одном терминале и чинить баг во втором.

При этом создается изолированная рабочая директория со своей веткой, исходная сессия остается нетронутой — без stash, без конфликтов.

Запрос worktree прямо в сессии

Не обязательно даже флаг — внутри сессии можно просто сказать «работай в worktree», и модель сама вызовет создание worktree.

Изоляция субагентов (для параллельных подзадач)

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

• Скажи Claude: «use worktrees for your agents»
• Или закрепи навсегда у кастомного субагента, добавив в frontmatter: isolation: worktree

Запуск субагентов без worktree-изоляции на задачах, пишущих файлы — самый частый источник конфликтов. The-Prompt-Shelf

Копирование нужных untracked-файлов

По умолчанию в новый worktree не попадают gitignored-файлы (например .env). Чтобы их прокидывать, создай .worktreeinclude — он использует синтаксис .gitignore; копируются только файлы, которые совпадают с паттерном и при этом gitignored, так что отслеживаемые файлы не дублируются.

Desktop-приложение

Десктоп-приложение создает worktree автоматически для каждой новой сессии — там вообще ничего настраивать не надо.

Практические нюансы

• Сколько параллельно: запускай 2–4 параллельные сессии за раз, при необходимости стартуй их со сдвигом.
• Одну ветку нельзя в два worktree — git это запретит.
• Очистка: если выйти без коммитов, весь worktree вместе с временной веткой удаляется автоматически — основной репозиторий остается чистым. Но если убить сессию посреди задачи и не дать автоочистке сработать, worktree и ветки будут накапливаться — периодически запускай git worktree list и git worktree remove. >
• Фоновые задачи: начиная с v2.1.x фоновые сессии тоже поддерживают worktree-изоляцию, так что долгие задачи больше не блокируют основную ветку.
• Не-git VCS (Mercurial, Perforce, SVN): режим worktree все равно работает через кастомные хуки WorktreeCreate и WorktreeRemove в настройках.

Полная официальная страница: https://code.claude.com/docs/en/worktrees

аналогичные схемы работы над параллельными тасками существуют и для других ИИ агентов таких как Cursor, Gemeni Antigravitacy и т.д.

Grounding / заземление ИИ-Агента

Заземление в запросах к ИИ-агентам — это привязка ответа модели к конкретным фактам, источникам, данным, контексту или ограничениям, чтобы агент не “фантазировал”, а работал в рамках проверенной информации.

По-английски это часто называется grounding.

Простыми словами:

Не просто: “Ответь как знаешь”,
а: “Ответь, используя вот эти данные, вот этот документ, вот эту базу, вот эти правила”.

Пример без заземления

Расскажи, какие тарифы есть у нашей компании.

ИИ может начать придумывать тарифы, если не знает реальные данные.

Пример с заземлением

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

[таблица тарифов...]

Такой запрос “заземляет” ответ на конкретной таблице.

Зачем нужно заземление

Оно помогает:

1. уменьшить галлюцинации — модель меньше придумывает;
2. повысить точность — ответ основан на реальных данных;
3. контролировать поведение агента — агент действует по правилам;
4. сделать ответ проверяемым — можно понять, откуда взялась информация;
5. ограничить область ответа — модель не уходит в лишние рассуждения.

Что может быть заземлением

Заземлять ИИ-агента можно на:

• документах;
• базе данных;
• API;
• пользовательском профиле;
• текущей странице сайта;
• результатах поиска;
• правилах компании;
• коде проекта;
• истории диалога;
• конкретном JSON-объекте;
• системных инструкциях.

Пример для ИИ-агента

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

База знаний:
1. Возврат возможен в течение 14 дней.
2. Деньги возвращаются на тот же способ оплаты.
3. Товары со следами использования не принимаются.

Пример для программного агента

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

Проанализируй этот /services/window.js.  и исправь загрузку файлов на серви в попапе Загрузка

Хорошая формула запроса с заземлением

Задача:
[что нужно сделать]

Контекст:
[данные, документы, код, правила]

Ограничения:
[что нельзя делать / что учитывать]

Формат ответа:
[как именно ответить]

Если информации недостаточно:
[что должен сделать агент]

Таким образом

Заземление — это способ сказать ИИ:

“Отвечай не вообще из головы, а строго на основе этого контекста и этих правил.”

Как использовать CLAUDE.md / AGENTS.md

Для Claude Code часто используют CLAUDE.md. Это файл с памятью проекта: команды, правила, архитектура, стиль, ограничения. Claude Code загружает такие инструкции в начале разговора как контекст.

Пример структуры:

# Project Rules

## Stack
- Laravel 11
- PHP 8.2
- MySQL
- Blade
- jQuery

## Commands
- Run tests: php artisan test
- Run PHPStan: vendor/bin/phpstan analyse
- Clear cache: php artisan optimize:clear

## Rules
- Do not edit vendor/
- Do not change public API without asking
- Use FormRequest for validation
- Use policies for authorization
- Do not put business logic in controllers

## Payment rules
- Never expose secret API keys to frontend
- Do not change webhook signature validation without review

Для Codex аналогично полезно иметь проектные инструкции: что можно менять, какие команды запускать, как проверять результат. OpenAI в документации по Codex также выделяет best practices: планирование, валидацию, MCP, skills и автоматизации.

Типовой порядок работы над багом

• 1. Дать описание бага
• 2. Дать шаги воспроизведения
• 3. Попросить найти связанные файлы
• 4. Попросить объяснить причину
• 5. Попросить предложить варианты исправления
• 6. Выбрать вариант
• 7. Дать агенту внести изменения
• 8. Запустить тесты
• 9. Проверить diff
• 10. Добавить regression test

Пример первого промпта:

Есть баг: после выбора ответа в Telegram inline keyboard пользователь может нажать старую кнопку повторно.

Найди код, который обрабатывает callback_query.
Сначала ничего не меняй.
Опиши:

• 1. где создаются кнопки
• 2. где обрабатывается ответ
• 3. почему возможен повторный ответ
• 4. как лучше заблокировать повторную обработку

Потом (пример второго промта):

Реализуй защиту от повторного ответа через проверку статуса в базе.
Добавь тест, который проверяет, что второй callback не меняет результат.

Типовой порядок работы над новой фичей

• 1. Описать бизнес-цель
• 2. Описать ограничения
• 3. Попросить найти похожую реализацию
• 4. Попросить план
• 5. Реализовать минимальную версию
• 6. Добавить тесты
• 7. Сделать review
• 8. Улучшить код

Пример:

Нужно добавить экспорт invoice в PDF.

Ограничения:

• - Laravel
• - использовать существующий шаблон invoice
• - не менять текущую страницу просмотра invoice
• - PDF должен открываться по маршруту /income-invoices/{id}/pdf

Сначала найди похожие PDF-экспорты в проекте и предложи план.

Типовой порядок рефакторинга

Рефакторинг лучше делать осторожно:

• 1. Сначала попросить описать текущую логику
• 2. Попросить найти тесты
• 3. Если тестов нет — сначала добавить тесты
• 4. Только потом менять код
• 5. После каждого шага запускать тесты

Промпт:

Нужно упростить этот сервис.

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

Очень полезный сценарий: один агент пишет код, другой — проверяет.

Агент 1:
реализует фичу

Агент 2:
делает review diff

Человек:
принимает финальное решение

Промпт для ревью:

Проверь этот diff как senior backend developer.

Ищи:
1. баги
2. проблемы безопасности
3. race conditions
4. неправильную обработку ошибок
5. нарушение архитектуры
6. отсутствие тестов

Не переписывай код сразу. Сначала дай список замечаний по приоритету.

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

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

Как использовать ИИ-агента в Laravel / PHP-проекте

Для такого стека можно дать агенту такие правила:

Правила:

• - Контроллеры должны быть тонкими
• - Бизнес-логику выносить в сервисы
• - Валидацию делать через FormRequest
• - Авторизацию через Policy/Gate
• - Для сложных запросов использовать Query Builder или Eloquent scopes
• - Не менять миграции, которые уже применялись в production
• - Для новой логики добавлять feature tests
• - Не трогать .env

Пример задачи:

Добавь Laravel Policy для редактирования статьи.

Сначала найди:

• - модель Article
• - контроллер редактирования
• - текущую систему авторизации
• - существующие policies

Затем предложи план.

Как использовать агента в JavaScript-проекте

Правила:

• - Не менять публичные data-атрибуты без причины
• - Не ломать существующие обработчики событий
• - Проверять повторную инициализацию компонентов
• - Следить за очисткой setInterval / setTimeout
• - Не создавать глобальные переменные без необходимости

Пример:

Проверь этот JS-код на проблему повторной инициализации.

Особенно проверь:

• - удаляются ли старые обработчики
• - очищаются ли таймеры
• - не монтируется ли компонент дважды в один контейнер
• - нет ли гонки между async init и destroy

Что обязательно проверять после ИИ

После работы агента всегда проверять:

• 1. git diff
• 2. тесты
• 3. миграции
• 4. права доступа
• 5. обработку ошибок
• 6. обратную совместимость
• 7. security-риск
• 8. производительность
• 9. edge cases
• 10. не удалил ли агент важный код

Особенно внимательно:

• - платежи
• - webhooks
• - авторизация
• - SQL-запросы
• - файловые операции
• - внешние API
• - cron/jobs/queues

Хороший шаблон промпта для агента

Задача:
[что нужно сделать]

Контекст:
[что уже известно]

Ограничения:
[что нельзя ломать]

Ожидаемый результат:
[как должно работать]

Порядок работы:
1. сначала изучи проект
2. найди связанные файлы
3. предложи план
4. после подтверждения измени код
5. запусти тесты
6. покажи diff и объясни изменения

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

​

Итоговая схема: кто что делает при разработке проекта с использованием ИИ агентов

Программист:

• - ставит цель
• - задает ограничения
• - проверяет архитектуру
• - принимает решения
• - делает финальный review

ИИ-агент:

• - читает проект
• - ищет файлы
• - предлагает план
• - пишет черновой код
• - добавляет тесты
• - объясняет diff
• - помогает найти ошибки

Безопасный порядок использования

1. Explain
   Сначала попросить объяснить код.

2. Locate
   Найти нужные файлы.

3. Plan
   Составить план.

4. Implement
   Внести маленькое изменение.

5. Test
   Запустить тесты.

6. Review
   Проверить diff.

7. Iterate
   Исправить замечания.

8. Commit
   Коммитить только после проверки человеком.

Главная формула:

ИИ не заменяет программиста.
ИИ ускоряет цикл:
понять → написать → проверить → исправить.

Лучший результат получается не когда вы говорите «сделай все», а когда используете агента как исполнителя под контролем senior-разработчика.

Тесты для самопроверки и самоподготовки

1. Для чего в первую очередь предназначен Claude Code?

• A) Для редактирования фотографий
• B) Для работы разработчика с кодовой базой через терминал *
• C) Для создания музыкальных треков
• D) Только для общения в браузере

Подсказка: Claude Code работает в терминале и имеет доступ к файлам проекта, командам, тестам и Git.

2. Какой командой можно установить Claude Code через npm?

• A) npm install claude-ai
• B) npm install -g @anthropic-ai/claude-code *
• C) npx install claude-desktop
• D) composer require anthropic/claude

Подсказка: Claude Code устанавливается глобально через npm и затем запускается в директории проекта.

3. Какой файл Claude Code читает в начале сессии как инструкцию проекта?

• A) README.md
• B) package.json
• C) CLAUDE.md *
• D) index.js

Подсказка: CLAUDE.md задает правила работы Claude Code внутри конкретного проекта.

4. Что лучше всего записывать в CLAUDE.md?

• A) Ключевые команды сборки, тестов, архитектурные решения и ограничения проекта *
• B) Полную историю компании
• C) Все зависимости из node_modules
• D) Случайные заметки без структуры

Подсказка: хороший CLAUDE.md похож на рабочую записку для ИИ о том, как правильно действовать в проекте.

5. Что не рекомендуется писать в CLAUDE.md?

• A) Bash-команды для тестов
• B) Правила обработки ошибок
• C) Длинные теоретические объяснения *
• D) Неочевидные ограничения проекта

Подсказка: слишком большой CLAUDE.md может занимать много контекста и снижать качество работы модели.

6. Какой пример хорошо объясняет принцип «пишите не только что делать, но и почему»?

• A) Просто написать «делай красиво»
• B) Объяснить, что strict-режим нужен из-за прошлой production-ошибки с неявным any *
• C) Удалить все комментарии из проекта
• D) Записать только название фреймворка

Подсказка: объяснение причины помогает Claude принимать решения в ситуациях, которые не описаны явно.

7. Что означает команда с символом # во время работы Claude Code?

• A) Завершить текущую сессию
• B) Запустить тесты
• C) Добавить новое правило в CLAUDE.md *
• D) Очистить историю проекта

Подсказка: если вы второй раз исправляете одну и ту же ошибку, правило стоит записать в CLAUDE.md.

8. Какой уровень CLAUDE.md является персональным и действует кросс-проектно?

• A) ./CLAUDE.md
• B) ~/.claude/CLAUDE.md *
• C) CLAUDE.local.md
• D) README.md

Подсказка: глобальные персональные настройки Claude Code обычно не коммитятся в репозиторий.

9. Какой файл предназначен для локальных персональных переопределений в текущем проекте?

• A) CLAUDE.local.md *
• B) package-lock.json
• C) CHANGELOG.md
• D) LICENSE.md

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

10. Где рекомендуется хранить модульные правила, когда CLAUDE.md становится слишком большим?

• A) .claude/rules/ *
• B) node_modules/rules/
• C) public/assets/
• D) vendor/claude/

Подсказка: директория .claude/rules/ позволяет разделить правила по темам: стиль кода, тесты, API, безопасность.

11. Для чего используются правила с YAML-заголовком paths?

• A) Чтобы правила применялись только к файлам, подходящим под glob-паттерн *
• B) Чтобы удалить все тестовые файлы
• C) Чтобы изменить название проекта
• D) Чтобы отключить Git

Подсказка: path-based rules помогают применять инструкции только к нужным файлам и экономить контекст.

12. Что такое Commands в Claude Code?

• A) Автоматические навыки, которые Claude запускает сам
• B) Слэш-команды, которые пользователь запускает вручную *
• C) Отдельные модели Claude
• D) Только команды операционной системы Windows

Подсказка: команды из .claude/commands/ можно вызывать вручную как slash commands.

13. Какой файл команды может соответствовать вызову /project:review?

• A) .claude/commands/review.md *
• B) .claude/skills/review.md
• C) .claude/agents/review.json
• D) public/review.html

Подсказка: команда review.md в директории команд проекта может стать slash-командой для ревью.

14. Что позволяет делать синтаксис !`git diff ...` внутри command-файла?

• A) Встроить вывод shell-команды в промпт до обработки Claude *
• B) Удалить Git-репозиторий
• C) Автоматически купить подписку
• D) Запретить Claude читать файлы

Подсказка: command-файл может сначала выполнить shell-команду, а затем передать результат Claude.

15. Для чего используется переменная $ARGUMENTS в Commands?

• A) Для передачи аргументов в слэш-команду *
• B) Для запуска Docker
• C) Для отключения всех правил
• D) Для удаления истории терминала

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

16. Чем Skills отличаются от Commands?

• A) Skills запускаются только вручную
• B) Skills активируются Claude автоматически при подходящем сценарии *
• C) Skills нужны только для CSS
• D) Skills не имеют описания

Подсказка: Skills распознают задачу и включаются без ручного вызова слэш-команды.

17. Какой файл обычно описывает условия срабатывания skill'а?

• A) SKILL.md *
• B) README.txt
• C) index.php
• D) .env

Подсказка: SKILL.md содержит YAML-заголовок, описание и правила применения навыка.

18. Что может содержать папка skill'а?

• A) Только один пустой файл
• B) Скрипты, справочные документы, данные и шаблоны *
• C) Только изображения
• D) Только CSS-файлы

Подсказка: Skill — это не просто текстовая команда, а полноценный набор материалов для выполнения сценария.

19. Какая часть skill'а часто является особенно ценной?

• A) Список случайных ссылок
• B) Раздел с подводными камнями и типичными ошибками *
• C) Пустой YAML-заголовок
• D) Логотип проекта

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

20. Что такое Agents в Claude Code?

• A) Суб-агентные роли с собственным системным промптом, инструментами и настройками модели *
• B) Только визуальные темы интерфейса
• C) Обычные HTML-шаблоны
• D) Команды для установки npm-пакетов

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

21. Зачем агенту указывать поле tools?

• A) Чтобы ограничить доступные возможности агента *
• B) Чтобы изменить цвет терминала
• C) Чтобы отключить все модели
• D) Чтобы удалить Git-историю

Подсказка: для security-аудита агенту можно дать только Read, Grep и Glob без права записи.

22. В чем ключевая польза суб-агентов?

• A) Они засоряют основной контекст большим количеством деталей
• B) Они выполняют исследовательскую (или иную) работу в отдельном небольшом контексте и возвращают сжатый результат *
• C) Они запрещают запуск тестов, заменяя их работу своим функционалом
• D) Они работают только параллеьно без зависимости от оркестратора

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

23. Что такое Tasks в Claude Code?

• A) Система управления задачами с зависимостями и локальным хранением *
• B) Только список сообщений в чате
• C) Замена CSS-файлов
• D) Режим рисования диаграмм

Подсказка: Tasks хранятся локально и могут использоваться несколькими сессиями или суб-агентами.

24. Где хранятся данные Tasks?

• A) ~/.claude/tasks *
• B) /var/www/html/tasks
• C) C:/Windows/System32/tasks
• D) node_modules/tasks

Подсказка: Tasks являются локальным компонентом управления проектной работой Claude Code.

25. Что такое Agent Teams?

• A) Режим, где несколько участников работают совместно и координируются через общий список задач *
• B) Только список CSS-классов
• C) Одна обычная команда терминала
• D) Режим отключения всех агентов

Подсказка: Agent Teams подходят для параллельной работы над API, фронтендом и тестами.

26. Когда Agent Teams подходят лучше всего?

• A) Когда задача строго последовательная и все редактируют один файл
• B) Когда задачу можно декомпозировать на относительно независимые части *
• C) Когда не нужен общий список задач
• D) Когда запрещено параллельное выполнение

Подсказка: Agent Teams полезны, когда разные участники могут работать над разными частями проекта.

27. Когда Agent Teams лучше не использовать?

• A) Когда подзадачи независимы
• B) Когда нужна параллельная разработка
• C) Когда есть жесткая последовательная зависимость или частое редактирование одного файла *
• D) Когда есть общий список задач

Подсказка: для сильно связанных задач иногда лучше одна сессия или обычные суб-агенты.

28. Что позволяет сделать Remote Control в Claude Code?

• A) Управлять терминальной сессией с телефона *
• B) Создавать только презентации
• C) Полностью удалить проект
• D) Отключить все плагины

Подсказка: Remote Control запускается через claude rc и позволяет руководить задачей с мобильного устройства.

29. Что позволяют сделать Claude Code Channels?

• A) Подключить сессию Claude Code к Telegram или Discord *
• B) Только изменить шрифт терминала
• C) Установить PHP-зависимости
• D) Полностью заменить GitHub

Подсказка: Channels дают возможность отправлять команды ИИ через привычный мессенджер.

30. Что нужно поддерживать для работы Channels?

• A) Запущенную терминальную сессию *
• B) Только открытый браузер без терминала
• C) Выключенный компьютер
• D) Пустой репозиторий без файлов

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

31. Что такое Hooks в Claude Code?

• A) Shell-команды, которые автоматически срабатывают в определенных точках жизненного цикла *
• B) Только React-хуки
• C) Стили для Markdown
• D) Голосовые команды

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

32. Для чего лучше всего использовать Hooks?

• A) Для мягких предпочтений по стилю ответа
• B) Для бизнес-правил, которые должны выполняться детерминированно и на 100% *
• C) Для случайного выбора модели
• D) Для генерации картинок

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

33. Какой пример применения Hooks указан в статье?

• A) Автоматический запуск lint для файла, который записывает Claude *
• B) Автоматическое удаление всех тестов
• C) Отключение Git
• D) Создание случайных веток

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

34. Что такое MCP?

• A) Открытый стандарт подключения Claude к внешним сервисам *
• B) Язык программирования для CSS
• C) Формат изображений
• D) Только команда для очистки кэша

Подсказка: MCP можно представить как универсальный разъем для подключения ИИ к данным и инструментам.

35. Какую роль выполняет MCP Server?

• A) Предоставляет данные и возможности для Claude *
• B) Только рисует SVG
• C) Удаляет все токены
• D) Заменяет операционную систему

Подсказка: Claude выступает клиентом, а MCP Server предоставляет внешние возможности.

36. Где обычно располагается проектная конфигурация MCP?

• A) .mcp.json *
• B) .env.localhost
• C) public/index.html
• D) composer.json

Подсказка: проектная .mcp.json может коммититься и использоваться всей командой.

37. Зачем рекомендуется использовать переменные окружения в MCP-конфигурации?

• A) Чтобы не записывать секретные токены прямо в репозиторий *
• B) Чтобы увеличить размер проекта
• C) Чтобы отключить все API
• D) Чтобы заменить Git-коммиты

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

38. Что такое плагины в экосистеме Claude Code?

• A) Устанавливаемые модули, которые могут объединять skills, hooks, subagents и MCP server *
• B) Только картинки для интерфейса
• C) Файлы для удаления проекта
• D) Исключительно браузерные расширения

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

39. Для чего используется Headless Mode в Claude Code?

• A) Для запуска Claude Code в неинтерактивном режиме, например в CI/CD *
• B) Для отключения всех команд
• C) Для запуска только графического интерфейса
• D) Для удаления pull request

Подсказка: параметр -p позволяет встроить Claude Code в автоматизированные процессы без ожидания ручного ввода.

40. Почему код-ревью лучше выполнять отдельным экземпляром Claude?

• A) Потому что отдельный экземпляр меньше склонен оправдывать код, который сам же сгенерировал *
• B) Потому что один экземпляр не умеет читать diff
• C) Потому что Claude не умеет запускать тесты
• D) Потому что ревью невозможно автоматизировать

Подсказка: отдельный экземпляр Claude Code легче замечает ошибки и критичнее оценивает изменения.

41. Что такое токен в контексте LLM-моделей?

• A) Всегда одно целое слово
• B) Часть текста, которую модель использует для обработки и анализа *
• C) Только число в программном коде
• D) Только символ пробела между словами

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

42. Почему JavaScript-код может занимать больше токенов, чем обычный текст?

• A) Потому что в коде много специальных символов, операторов, скобок и точек *
• B) Потому что LLM не умеют читать JavaScript
• C) Потому что каждая строка кода всегда равна ровно 100 токенам
• D) Потому что пробелы в коде всегда считаются за 10 токенов

Подсказка: в коде отдельными токенами часто становятся символы вроде точки, скобок, запятых и операторов.

43. Примерно сколько токенов может занять такой фрагмент JavaScript-кода? ctx.moveTo(x + w * 0.78, y + h * 0.5);

• A) Примерно 2–3 токена
• B) Примерно 20–25 токенов *
• C) Примерно 100–150 токенов
• D) Ровно 1 токен, потому что это одна строка кода

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

44. Почему строка ctx.moveTo(x + w * 0.78, y + h * 0.5); может занимать около 20 токенов, а не 5–6?

• A) Потому что токенизатор может отдельно учитывать части вроде ctx, ., move, To, (, числа и операторы *
• B) Потому что каждый символ JavaScript всегда равен одному токену
• C) Потому что пробелы автоматически умножают количество токенов на 10
• D) Потому что LLM сначала переводит JavaScript в машинный код

Подсказка: токены — это не обязательно слова; в коде они часто соответствуют маленьким фрагментам синтаксиса.

45. От чего в первую очередь зависит максимальная длина ответа LLM в одном запросе?

• A) Только от языка, на котором задан вопрос
• B) От лимитов токенов, контекстного окна и настроек генерации *
• C) Только от скорости интернета пользователя
• D) Только от количества слов в первом предложении

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

46. На основе чего LLM выбирает токен конца ответа?

• A) Только на основе длины последнего слова
• B) На основе вероятности следующего токена в текущем контексте *
• C) Только на основе количества букв в вопросе
• D) На основе случайного таймера внутри браузера

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

47. Что такое токен завершения (EOS token) в генерации LLM?

• A) Специальный сигнал, после которого модель заканчивает ответ *
• B) Первый токен в вопросе пользователя
• C) Обязательная точка в конце каждого предложения
• D) Название самого длинного слова в ответе

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

48. Что произойдет, если задать очень маленький лимит ответа LLM модели, например 10 токенов?

• A) Модель гарантировано сократит полный смысл ответа чтобы уложиться в 10 токенов
• B) Модель проигнорирует лимит и допишет ответ до конца
• C) Модель будет учитывать лимит и возможно, даст не полный ответ *
• D) Модель автоматически увеличит лимит до одного абзаца

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

49. Что произойдет, если задать определенный лимит ответа LLM модели, токакая длина ответа будет?

• A) Модель гарантировано будет генерировать ответ равный заданному количеству токенов
• B) Модель проигнорирует лимит и допишет ответ до конца
• C) Модель будет учитывать лимит и возможно, даст не полный ответ или ответ с меньшим количесвом токенов*
• D) Модель автоматически изменит лимит до нужной длинный ответа чтобы максиамльно развернуто дать ответ

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

50. Почему длинный вопрос может уменьшить возможную длину ответа?

• A) Потому что входной текст и ответ вместе занимают общее контекстное окно модели *
• B) Потому что модель не умеет читать длинные вопросы
• C) Потому что длинный вопрос всегда считается ошибкой
• D) Потому что модель отвечает только на первые 10 слов

Подсказка: общий лимит обычно считается как сумма входа, истории диалога, документов и ответа.

51. Может ли LLM бесконечно писать ответ, если пользователь попросит роман или бескнечную рекурсивнуюгенерацию текста по ипу у попа жила собака...?

• A) Да, модель всегда пишет бесконечно, если ее попросить
• B) Нет, на практике есть лимиты контекста, времени, вычислений и длины вывода *
• C) Да, потому что слова не занимают память
• D) Нет, потому что LLM может отвечать только одним абзацем

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

52. Почему после завершенной фразы вероятность EOS token может увеличиться?

• B) Потому что точка автоматически удаляет все следующие токены, что повышает вероятность появления EOS token
• C) Потому что после каждого предложения ответ обязан закончиться через EOS token
• A) Потому что модель видит признаки законченной мысли в уже сгенерированном тексте *
• D) Потому что EOS token вставляется только пользователем вручную, в момент генерацииответа LLM моделью

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

53. Чем отличается выбор EOS token от остановки по max_tokens?

• A) EOS означает, что модель выбрала завершение, а max_tokens может принудительно оборвать ответ *
• B) EOS всегда появляется только после ошибки, а max_tokens всегда улучшает качество ответа
• C) EOS увеличивает длину ответа, а max_tokens отключает токенизацию
• D) Между ними нет никакой разницы

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

54. Почему инструкция “ответь кратко” может повлиять на появление токена конца?

• A) Потому что такая инструкция меняет контекст, в котором модель оценивает вероятность продолжения *
• B) Потому что она полностью запрещает модели использовать обычные слова
• C) Потому что она удаляет EOS token из словаря модели
• D) Потому что модель перестает учитывать вопрос пользователя

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

55. Почему LLM-модель всегда отвечает на сообщение пользователя (если нет цензуры)?

• A) Потому что она заранее знает единственно правильный ответ на любой вопрос
• B) Потому что модель училась на данных в паре(формате) вопрос- ответ, заголовок-контекн, после текста (токена) всегда есть слудующий *
• C) Потому что она не использует токены и всегда пишет полный текст
• D) Потому что она не может завершить генерацию ответа без явного указания

Подсказка LLM предсказывает следующий токен на основе контекста и обучающих данных.

56. Почему модель не всегда молчит, даже если вопрос неполный или странный?

• A) Потому что после дообучения ее часто настраивают быть полезным ассистентом *
• B) Потому что она физически не может сгенерировать пустой ответ
• C) Потому что она всегда проверяет вопрос в интернете
• D) Потому что она заранее хранит готовые ответы на все возможные вопросы

Подсказка GPT-модели обучают реагировать на запрос пользователя и стараться дать полезный ответ.

57. Какой подход считается стандартным для параллельной работы нескольких Codex/Claude AI Agent над одним проектом?

• A) Запускать всех агентов в одной ветке Git
• B) Для каждой задачи создавать отдельную ветку и отдельный git worktree *
• C) Использовать один терминал для всех агентов
• D) Копировать проект вручную в разные папки без Git

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

58. Для чего используется команда git worktree при работе с несколькими Codex/Claude AI Agent?

• A) Для удаления старых веток
• B) Для объединения изменений из разных веток
• C) Для создания нескольких рабочих директорий, связанных с разными ветками Git *
• D) Для запуска нескольких процессов Node.js

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

59. Какой вариант декомпозиции задач лучше всего подходит для одновременной работы нескольких Codex/Claude AI Agent?

• A) Все агенты одновременно изменяют один и тот же модуль авторизации
• B) Один агент работает над API, второй над интерфейсом, третий над тестами *
• C) Все агенты редактируют один и тот же файл конфигурации
• D) Все агенты работают в одной ветке main

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

См. также

• вайб-кодинг ,
• Другие тесты

Ответы на вопросы для самопроверки пишите в комментариях, мы проверим, или же задавайте свой вопрос по данной теме.