Как проверить изменения кода от ИИ перед принятием результата
Проверьте объём изменений, diff, индекс Git, результаты тестов и открытые вопросы в Mono Code с шаблоном ревью и командами только для чтения.
Проверяйте код в репозитории, а не только пересказ агента. Убедительное объяснение может сопровождать неполное исправление, ни разу не запущенный тест или посторонние правки. Перед принятием результата разделите требуемое поведение, реальные изменения и доказательства проверки.
Mono Code позволяет открывать файлы проекта, работать с агентами для программирования и видеть изменения Git прямо в редакторе. Здесь речь о проверке небольшого завершённого изменения; как подключиться, описано в руководстве по удалённой работе с кодом. Репозиторий и команды всегда остаются на вашем собственном компьютере — хосте. Mono ещё не вышел; вы можете записаться в список ожидания.
1. Повторно сформулируйте критерий приёмки
Возьмём вымышленный пример: форма задачи принимает заголовок только из пробелов. Требуется отклонять такой ввод, сохранив работу обычных заголовков. Перед просмотром патча запишите условия:
- Нельзя отправить пустой заголовок или заголовок только из пробелов.
- Обычный заголовок по-прежнему отправляется успешно.
- Пользователь видит полезное сообщение о проверке.
- Остальное поведение формы остаётся в согласованных границах.
Держите этот список рядом с diff. Он даёт основу для оценки, независимую от объяснения агента. Если исходный запрос был неоднозначен, уточните поведение до принятия более широкой реализации.
2. Установите состояние репозитория
Подтвердите хост, папку проекта и ветку. Сравните список изменённых файлов с исходным состоянием, записанным до работы агента. Существовавшие правки пользователя не становятся работой агента лишь потому, что находятся в том же файле.
В терминале нужного хоста помогут команды только для чтения:
git status --short
git diff --stat
git diff -- path/to/file
git diff --cached -- path/to/fileЗамените пример пути реальным. Обычный git diff показывает неиндексированные изменения; --cached сравнивает изменения в индексе с коммитом. Неотслеживаемые файлы нужно просмотреть отдельно. Документация Git diff объясняет эти сравнения. Чистое рабочее дерево не показывает, успел ли агент сделать коммит; если это произошло, проверьте соответствующую историю.
3. Прочитайте патч и окружающий код
В редакторе Mono поле слева отмечает добавленные и изменённые строки, а нажатие на отметку открывает diff этого фрагмента. Это удобный способ посмотреть одно изменение, но не доказательство, что вы просмотрели все. Если отметки нет или она устарела, это не значит, что файл не менялся.
В примере с заголовком найдите условие валидации и проследите дальнейшее выполнение. Проверяется ли нормализованное значение? Видна ли ошибка? Прекращается ли отправка? Изучайте окружение, а не отдельное добавленное условие без вызывающего кода.
Проверьте новые файлы, удалённый код, зависимости и постороннее форматирование. Краткое объяснение не оправдывает большой необъяснённый diff. Перейдите на хост или большой экран, если строки обрезаны либо изменение слишком широкое для надёжного чтения.
4. Сопоставьте тесты с поведением
Попросите указать реально выполненную команду, её результат и пропущенные проверки. «Тесты должны пройти» — прогноз, а не зафиксированный результат. Даже успешный набор тестов должен содержать случай, относящийся к исходной ошибке.
| Случай | Ожидаемое наблюдение |
|---|---|
| Пустой заголовок | Отправка прекращается с нужным сообщением |
| Только пробелы | Такое же отклонение без создания объекта |
| Обычный заголовок | Отправка по-прежнему работает |
| Существующее поведение вне изменения | Значимые прежние проверки проходят |
Ручная проверка подходит для видимого сообщения; автоматический регрессионный тест может защитить правило валидации. Выбирайте доказательства поведения, а не тесты, повторяющие реализацию. Если среда не позволяет тестировать, явно зафиксируйте ограничение и решите, где провести недостающую проверку.
5. Исправляйте замечания, сохраняя постороннюю работу
Давайте точную обратную связь: «Заголовок из пробелов отклоняется, но сообщение об ошибке не появляется» или «Объясни изменение файла зависимостей ради этой валидации». Указывайте поведение и файл, а не просто «попробуй ещё».
Не используйте общий сброс или восстановление ради небольшой ненужной правки, если рядом есть другая работа. Попросите точечное исправление и проверьте новый diff. После исправления повторите затронутые проверки: прежний успех не подтверждает последующие изменения.
Разрешение команды и принятие кода — разные решения. Одобрение запуска теста не разрешает коммит, слияние или развёртывание. Оценке самой операции посвящено руководство по разрешениям.
6. Оставьте проверяемую передачу результата
Запишите вывод коротко:
Требуемое поведение: Отклонять пустые заголовки задач.
Проверенные файлы: Перечислить реальные пути.
Доказательства: Команды, результаты и значимые ручные проверки.
Открытые вопросы: Всё ещё не проверенное.
Следующее решение: Принять, запросить исправление или отложить.Решения о коммитах и выпуске принимайте явно. Чтобы сохранить переписку, экспортируйте её в Markdown, но сохраните и настоящие файлы проекта. Переписка фиксирует обсуждение; репозиторий и подтверждённые проверки устанавливают, что изменилось.
