Как проверить, что Codex и Claude Code соблюдают правила проекта?

Как проверить, что Codex и Claude Code соблюдают правила проекта?

Выберите небольшую правку сайта и заранее запишите, по каким признакам вы примете результат. Затем поручите её Codex или Claude Code и сопоставьте изменения с правилами из AGENTS.md и CLAUDE.md. Сам факт, что агент прочитал файл, ещё не подтверждает соблюдение инструкций. Проверка должна охватывать конкретные действия: какие файлы он изменил, какие проверки выполнил и о каких ограничениях сообщил. Ниже разберём, как провести такой тест без глубоких знаний программирования и что передать разработчику, если результат расходится с заданием.

Какие правила из AGENTS.md и CLAUDE.md можно проверить?

Начните с файла, в котором команда хранит инструкции для ИИ-агента. AGENTS.md описывает правила работы с проектом для инструментов, которые поддерживают этот формат. Claude Code использует CLAUDE.md. Размещение файлов и вложенные инструкции влияют на то, какой контекст получит агент, поэтому перед тестом нужно выяснить, какие правила относятся к выбранной папке (источник: docs.qcode.cc).

Для владельца бизнеса эти файлы похожи на памятку подрядчику: где разрешено менять сайт, что нужно сохранить и как предъявить результат. Но фразу «сделай качественно» проверить нельзя. Замените её условием, которое видно в результате работы.

  • Вместо «сохраняй стиль» напишите: «Для новой кнопки используй компонент кнопки, который уже есть в проекте».
  • Вместо «не трогай лишнее» укажите: «В этой задаче меняй только текст страницы доставки».
  • Вместо «проверь сайт» задайте: «Выполни команду проверки проекта и укажи её результат в отчёте».
  • Вместо «будь осторожен» уточните: «Не устанавливай зависимости без согласования».

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

Отдельно определите признаки успеха для бизнеса. Например, после правки страницы доставки сумма остаётся в BYN, кнопка заказа ведёт туда же, а текст помещается на экране телефона. Это условия учебной задачи, а не универсальные требования к любому сайту.

Как подготовить тест без риска для рабочего сайта?

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

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

  1. Выберите одну страницу и одно изменение, например замену текста заголовка.
  2. Запишите разрешённую область: какой файл или раздел можно менять.
  3. Укажите обязательную проверку, которую разработчик подтвердил для этого проекта.
  4. Задайте формат отчёта: список изменённых файлов, результат проверки и нерешённые вопросы.

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

Один и тот же тест можно повторить после смены инструмента. При переносе проекта из Claude Code в Codex или Gemini CLI сохраните исходное состояние и текст задания: так будет проще увидеть, какие правила новый агент учёл, а какие пропустил.

Что попросить у агента до начала работы и после неё?

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

Текст задания можно сформулировать так: «Найди инструкции проекта, которые относятся к выбранной странице. Назови файлы и кратко перечисли применимые ограничения. Если инструкции противоречат друг другу, опиши конфликт до правки. Затем измени только заголовок и выполни проверку, которую задают правила проекта. Не публикуй изменения».

После работы запросите отчёт с проверяемыми деталями. Слова «всё готово» не объясняют, что произошло. Для приёмки нужны следующие сведения:

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

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

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

Как понять, почему агент нарушил инструкции?

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

Вложенные AGENTS.md позволяют задавать отдельные правила для частей проекта. Такой подход используют и в репозитории OpenCode, где инструкции находятся в корне и отдельных пакетах (источник: PurpleSchool). Поэтому проверки только корневого файла недостаточно: попросите показать инструкции для папки, в которой агент менял код. Порядок их применения уточняйте для конкретного инструмента.

Если Codex и Claude Code получают разные версии общих правил, сначала устраните расхождение. В качестве способа поддерживать единый текст источники описывают символическую ссылку между AGENTS.md и CLAUDE.md (источники: PurpleSchool, FOMENKO). Это ссылка файловой системы на другой файл. Перед такой настройкой разработчику нужно проверить, что она работает в вашей среде и оба инструмента получают нужное содержимое.

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

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

Типичные ошибки при проверке правил ИИ-агента

  • Принимать пересказ AGENTS.md за доказательство. Исправление: сопоставьте каждое важное правило с изменениями или журналом проверки.
  • Проверять сразу большую переделку. Исправление: выделите одну правку, чтобы причину отклонения можно было проследить.
  • Хранить разные общие требования в AGENTS.md и CLAUDE.md. Исправление: согласуйте единый текст и способ его обновления.
  • Считать запрет в инструкции технической защитой. Исправление: отдельно настройте права доступа и ограничения среды.
  • Принимать отчёт без просмотра сайта. Исправление: откройте изменённую страницу и проверьте условия задания вручную.

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

Когда агент изменил только разрешённые файлы, показал результат нужной проверки и сохранил условия задания, у вас есть основание принять эту конкретную правку. Это ещё не гарантия для следующих задач, поэтому сохраните задание как повторяемый тест после изменения правил или смены инструмента.

Следующий шаг на две минуты: откройте AGENTS.md или CLAUDE.md и замените одну расплывчатую фразу на условие, которое сможете проверить при приёмке ближайшей правки.