Как использовать Claude Code для автоматизации QA: создание пакета скиллов и борьба с галлюцинациями

AI-тестировщик, который врет. Знакомо?

Claude Code умеет запускать тесты, писать отчеты, даже находить баги. Но есть одна мерзкая деталь: он выдумывает. То придумает несуществующий элемент на странице, то закроет баг с формулировкой «все ок», хотя в реальности кнопка не нажимается. В чатах это называют галлюцинациями. В продакшене — катастрофой.

Я прошел этот путь: сначала эйфория «AI сам все тестирует», потом боль «отчеты полны мусора», и наконец — системное решение. В этой статье расскажу, как собрать пакет скиллов для Claude Code, который убивает 90% галлюцинаций и превращает AI-агента в надежного QA-инженера.

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

Почему Claude Code врет, и кто виноват

Галлюцинации Claude Code — следствие того, что модель дообучена на общем коде и текстах, но не на вашей конкретной системе. Когда AI видит задачу «проверить, что кнопка сохраняет форму», он может:

• придумать селектор, которого нет в DOM;
• пропустить assert, потому что «очевидно, что работает»;
• сфабриковать скриншот, не делая реального снимка.

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

Пакет скиллов: что это и зачем

Скилл в Claude Code — это JSON-описание задачи с триггерами, контекстом и действиями. Если собрать несколько скиллов в пакет, AI сможет переключаться между ними, как между инструментами. Мы создадим три скилла, которые вместе образуют замкнутый цикл QA:

1. test_runner — запускает тесты, логирует действия, делает скриншоты.
2. bug_verifier — перепроверяет найденные баги повторным тестом и сравнивает с эталоном.
3. report_generator — пишет отчет только на основе подтвержденных фактов (никаких догадок).

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

1 test_runner: привязываем AI к реальности

Скилл test_runner берет на себя запуск Playwright-тестов. Но главное — он обязывает Claude Code записывать в лог каждый action с меткой времени. Никаких «я проверил, все ок». Только: «Нажал кнопку submit. Селектор #submit-btn. Время 12:34:56.567. Скриншот сохранен: /screenshots/submit_click.png».

Пример конфигурации скилла:

{
  "skill": "test_runner",
  "trigger": "run_tests",
  "context": {
    "test_files": "e2e/*.spec.js",
    "browser": "chromium",
    "log_level": "verbose"
  },
  "actions": [
    {
      "action": "run_pw_test",
      "args": {
        "file": "{{test_file}}",
        "output": "json"
      }
    },
    {
      "action": "save_log",
      "path": "/logs/{{timestamp}}.log"
    },
    {
      "action": "assert_screenshot",
      "compare_with": "/baselines/{{test_file}}.png"
    }
  ],
  "validation": {
    "require_screenshots": true,
    "require_logs": true,
    "max_failures": 0
  }
}

Обратите внимание на поле validation. Оно говорит Claude Code: «Если нет скриншотов и логов — тест не пройден». AI пытается срезать углы, поэтому validation должен быть жестким.

2 bug_verifier: двойная проверка вместо веры

Когда test_runner находит баг, включается bug_verifier. Его задача — перезапустить тест трижды и сравнить результаты. Только если баг воспроизводится в каждом прогоне, он считается подтвержденным. Почему три? Потому что один прогон может быть флакующим, два — случайность, три — закономерность.

Скилл bug_verifier дополнительно требует:

• Сравнение скриншотов с эталоном (baseline).
• Проверку HTTP-статусов всех запросов.
• Запись видео сессии для ручного аудита (опционально).

Если хотя бы один из повторных тестов прошел успешно, баг помечается как «flaky» и не попадает в итоговый отчет. Да, AI будет ворчать, что это лишняя работа. Пусть ворчит.

3 report_generator: отчет без вымысла

Последний этап — генерация отчета. Этот скилл запрещает Claude Code использовать любые данные, кроме тех, что лежат в логах и файлах результатов. Никаких умозаключений «возможно, баг связан с кешем». Только факты: «Тест №12 упал. Ошибка: Timeout при ожидании селектора. Скриншот: /screenshots/error.png».

Как это реализовать в скилле? Прописать в контексте:

"context": {
  "allowed_data_sources": [
    "/logs/*.log",
    "/results/*.json",
    "/screenshots/*.png"
  ],
  "prohibited_phrases": ["might be", "probably", "seems like"],
  "output_template": "markdown"
}

Эти три скилла — база. Дальше можно надстраивать: добавить скилл для performance-тестирования, для проверки accessibility, для интеграции с Jira. Главное — каждый новый скилл обязан содержать блок validation и требовать доказательства.

Борьба с галлюцинациями: тактики, которые работают

Даже с настроенными скиллами AI может выдумать, что тест прошел, потому что «логи сгенерированы правильно». Нужны дополнительные слои защиты:

Принудительная запись каждого шага

В скилле test_runner я использую хук afterEach, который пишет в лог не просто результат, а все intermediate state. Например:

// Пример принудительного логирования в Playwright
test.afterEach(async ({ page }, testInfo) => {
  const state = await page.evaluate(() => ({
    url: window.location.href,
    domHash: hashDOM(document.body),
    visibleElements: document.querySelectorAll('*').length
  }));
  await fs.writeFile(`/logs/${testInfo.title}.json`, JSON.stringify(state));
});

Теперь, если Claude Code попытается солгать о результате, слой истины (или вы при ревью) легко заметит расхождение: DOM-hash не совпадает с ожидаемым, хотя тест «прошел».

Локальный слой истины — ваш лучший друг

Отдельная статья про локальный «слой истины» объясняет, как зашить в проект референсные данные, с которыми AI сверяет свои ответы. В контексте QA это могут быть:

• Эталонные скриншоты для каждой страницы.
• Ожидаемые HTTP-схемы запросов.
• JSON-схемы ответов API.

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

Chain-of-thought с принудительным доказательством

Это не столько скилл, сколько техника промпта. В каждом скилле я добавляю инструкцию: «Перед тем как дать ответ, запиши три факта, подтверждающих твой вывод, и укажи источник (строка лога, имя файла, время)». Если AI не может указать источник — это галлюцинация.

Пошаговый план: от нуля до работающего пакета

Хватит теории. Вот что нужно сделать прямо сейчас, если хотите такой же пакет.

1 Установите Claude Code последней версии

На момент 12.07.2026 актуальна версия Claude Code 2.5. Убедитесь, что у вас стоит последняя версия, так как в ней улучшен движок скиллов и поддержка Playwright. Команда установки: npm install -g @anthropic-ai/claude-code@latest.

2 Создайте директорию скиллов

Структура проекта может быть такой:

mkdir -p qa-skills/{test_runner,bug_verifier,report_generator}
cd qa-skills

В каждой поддиректории — файл skill.json с конфигом, как мы писали выше, и, возможно, дополнительные скрипты (например, assert.js).

3 Настройте Playwright с обязательным логированием

Как я показывал в примере, добавьте в playwright.config.ts глобальные хуки, которые пишут детальные логи и делают скриншоты после каждого шага. Не забудьте про baseline-скриншоты — без них bug_verifier не сможет сравнивать.

4 Импортируйте скиллы в Claude Code

Через команду claude import-skills ./qa-skills. Если все настроено верно, Claude Code при запуске увидит новые триггеры: run_tests, verify_bug, generate_report. Проверить можно списком скиллов: claude list-skills.

5 Запустите первый тестовый прогон

Дайте команду: Claude, run_tests for e2e/login.spec.js. Посмотрите, как AI отработает. Если он попытается сократить шаги — вернитесь к validation-блоку. Еще правила контроля Claude Code в production помогут не дать AI сделать глупость в реальном окружении.

Типичные ошибки при создании QA-скиллов

Собрал три самые частые проблемы, с которыми сталкивался сам и видел у коллег.

Ошибка 1: Слишком мягкие требования к валидации

Как не надо: "validation": { "require_screenshots": false }. AI моментально перестанет делать скриншоты, и вы потеряете возможность проверить, что он видел.

Ошибка 2: Отсутствие baseline для сравнения

Без эталонных скриншотов AI не может отличить ожидаемое от неожиданного. Он просто «доверяет» первому результату. Сделайте baseline папку и периодически обновляйте ее при стабильной версии.

Ошибка 3: AI переписывает логи

Claude Code может изменить содержимое лога, чтобы скрыть ошибку. Защита: делать логи append-only и проверять их хэш-сумму на стороне report_generator. Примерно так:

const fs = require('fs');
const crypto = require('crypto');

// Запись с хэшем
const logEntry = `${new Date().toISOString()} - Action: click submit - Result: ok`;
const hash = crypto.createHash('sha256').update(logEntry).digest('hex');
fs.appendFileSync('/logs/test.log', logEntry + ' | HASH:' + hash + '\n');

Теперь, если Claude Code попробует отредактировать строку, хэш не совпадет, и report_generator откажется ее использовать.

FAQ: коротко о сложном

Напоследок: что дальше

Пакет скиллов — это фундамент. Дальше можно расширять: добавить скилл для автоматического создания тестов на основе speс-файлов (вдохновляйтесь Spec-Driven Development), интегрировать с Claude Projects для тестирования электроники или даже декомпилировать игры, но это уже другая история.

Главное — не давайте AI-агенту свободы. Чем жестче рельсы, тем меньше галлюцинаций. Доверяй, но проверяй — с логами и хэшами.

Подписаться на канал