Как проверять код, написанный ИИ: plan → edit → test → commit

Агент изменил несколько файлов и написал, что задача решена. Прежде чем принимать работу, выясните, что именно изменилось и какой проверкой подтверждён результат. Фраза «тесты прошли» без команды и её вывода оставляет этот вопрос открытым.

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

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

Для учебного примера понадобятся Python 3 и отдельная папка вне рабочих проектов. Он не подключается к GitHub, не отправляет данные и не меняет настройки Git глобально. На Windows используйте терминал с установленными Git и Python; имя команды Python может отличаться. Ниже проверен вариант python3 в Linux.

Если вы ещё выбираете рабочую связку, начните с базы статей «Человек 2.0». Здесь мы разбираем приёмку уже подготовленного изменения.

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

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

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

Сначала посмотрите состояние рабочей копии:

git status --short
git diff --stat
git diff
git diff --check

git status --short показывает изменённые и неотслеживаемые файлы. В обычном состоянии две позиции перед именем отражают состояние индекса и рабочей копии. Индекс, или staging area, хранит подготовленный состав следующего коммита.

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

git diff --cached --stat
git diff --cached
git diff --cached --check

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

Новые неотслеживаемые файлы ещё не входят в обычный diff. Откройте их отдельно, прежде чем добавлять в индекс. Сопоставьте каждое изменение с задачей: откуда взялся новый файл, зачем изменена зависимость, не затронуты ли доступы и рабочие данные. Подробности режимов описаны в официальной документации Git.

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

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

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

Учебный пример: проверка проходит, но Git находит пробелы

Создайте отдельную пустую папку. Сохраните в ней calc.py со следующим содержимым:

def total(items):
    return sum(items)

Добавьте рядом файл test_calc.py:

import unittest
from calc import total

class TotalTests(unittest.TestCase):
    def test_empty(self):
        self.assertEqual(total([]), 0)

    def test_values(self):
        self.assertEqual(total([2, 3]), 5)

if __name__ == "__main__":
    unittest.main()

В терминале этой учебной папки выполните:

python3 -m unittest -v

В проверенном примере выполнены два теста, итог OK, код завершения 0. Это подтверждает только два выбранных случая. Например, поведение со строками этот набор не проверяет.

В нашей отдельной проверке после исходного коммита к строке return sum(items) были добавлены пробелы в конце. Тесты остались зелёными, а git diff --check сообщил trailing whitespace и вернул код 2. После добавления этой строки в индекс обычный diff стал пустым; проблему по-прежнему нашёл git diff --cached --check. Код 2 относится к нашему запуску, универсальный критерий ошибки здесь — ненулевой код.

Скриншот показывает вывод из изолированного учебного репозитория, а не из продукта или клиентского проекта. Удаление пробелов и повторный запуск дали код 0 у обеих проверок оформления.

Перед коммитом прочитайте полный diff индекса. Убедитесь, что там нет .env, ключей, дампов, выгрузок клиентов и посторонних правок. Имя файла само по себе не гарантирует безопасность: секрет может оказаться внутри обычного исходника. Проверка diff человеком и принятый в проекте secret scanner дополняют друг друга.

Добавляйте конкретные проверенные файлы. Например, для учебной функции:

git add calc.py test_calc.py
git diff --cached --check
git diff --cached
git commit -m "Add total function tests"
git status --short

Обычный git commit сохраняет подготовленное содержимое индекса. Если автор Git не настроен или проверка проекта запрещает коммит, остановитесь и разберитесь с сообщением. Не отключайте защитные проверки ради завершения примера и не используйте чужое имя автора.

Пустой git status --short после коммита означает отсутствие показываемых изменений; игнорируемые файлы он обычно не перечисляет. Коммит не отправляет код на сервер и сам по себе ничего не развёртывает. Его наличие также не доказывает безопасность изменения. Механика описана в документации git-commit.

Этот запрос подходит как исходная инструкция для небольшой задачи:

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

Для своей задачи добавьте конкретные примеры входов и ожидаемых результатов. Инструкция задаёт порядок, но ответственность за оценку риска остаётся у владельца проекта.

Достаточно ли зелёных тестов, чтобы принять код?

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

Почему git diff пустой, хотя агент изменил файлы?

Возможно, правки уже добавлены в индекс. Проверьте git status --short и git diff --cached. Новые неотслеживаемые файлы также требуют отдельного просмотра. Пустой обычный diff не означает отсутствия всех изменений.

Можно ли откатить любую ошибку коммитом?

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

У вас есть понятная цель, небольшой просмотренный diff, результат подходящей проверки и проверенный состав коммита. Незапущенные тесты и ограничения перечислены явно. Если любое из этих доказательств отсутствует, запросите его до приёмки.

Для следующей задачи выберите один небольшой дефект и заранее опишите наблюдаемый результат. Материалы о работе с агентами собраны в базе знаний «Человек 2.0». Эта ссылка ведёт к материалам для изучения; отдельную услугу проверки кода она не обещает.

• git-status: рабочая копия, индекс и короткий формат.
• git-diff: обычное и подготовленное сравнение, --stat, --check.
• git-commit: сохранение индекса и ограничения операции.
• unittest: запуск тестов стандартной библиотекой Python.
• Writing tests, Playwright: действия и проверка ожидаемого состояния.

Документация и учебные команды проверены 18 сентября 2026 года. Технические сведения следует пересмотреть при изменении версий инструментов.