Как проверить изменение, которое ИИ-ассистент внёс в вашу игру, прежде чем его оставить?

Сравните изменённые файлы с задачей, прочитайте diff начиная с удалений, сами запустите проверки, сыграйте изменённое место и только потом сделайте коммит.

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

Почему «готово» недостаточно?

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

Часть этого в редакторе вообще не видна. Страница Visual Studio Code о проверке правок, сделанных ИИ говорит, что ожидающие правки уже сохранены на диск, что изменения, сделанные командами терминала или скриптами, в её список правок не попадают и что её контрольные точки не отменяют команды терминала и развёртывания. Так страница читалась 29 октября 2026 года, последнее обновление — 21 октября. Каким бы инструментом вы ни пользовались, надёжный взгляд даёт система контроля версий: каждый файл, который отличается от вашего последнего коммита.

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

На что смотреть сначала?

На список изменённых файлов. Его дают две команды:

git status
git diff --stat

git status называет каждый изменённый файл и каждый новый. git diff --stat добавляет, сколько строк каждый файл получил и потерял. Учтите, что git diff сам по себе не показывает файлы, которые новые и ещё не добавлены в Git; git status показывает, поэтому читайте оба.

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

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

Как читать diff, если вы не программист?

Читайте его как список удалённых строк (красные, с пометкой -) и добавленных (зелёные, с пометкой +) и начинайте с удалённых. Пропавшую строку легче всего пропустить и труднее всего заметить в игре: проверку, которая не давала игроку проходить сквозь стены, сброс счёта, защиту от пустого сохранения.

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

• Изменившиеся числа: скорость, жизни, таймеры, цены. Каждое должно быть в вашей задаче.
• Код, превращённый в комментарии, или целый блок, удалённый и написанный заново в другом месте.
• Новая функция, похожая на старую: одна и та же работа сделана дважды, и со временем две копии разойдутся.
• Текст, который видит игрок: меню, подсказки, сообщения об ошибках. Он всё ещё верен и стоит на своём месте?

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

Какие проверки запускать самому?

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

Зелёный тест доказывает только то, что он проверяет. Если в том же diff изменился файл тестов, прочитайте эту часть: тест, который раньше ждал счёт 0 после перезапуска, а теперь ждёт то, что вернёт код, больше ничего не проверяет.

Что сыграть, прежде чем оставить изменение?

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

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

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

Как оставить изменение или выбросить его?

Чтобы оставить, сделайте коммит с сообщением, которое говорит, что изменилось, словами игрока: «каждая волна на 10% быстрее, вплоть до удвоенной начальной скорости». Одна задача — один коммит. Позже, когда что-то сломается, вы найдёте, какое изменение это сделало, и отмените именно его.

Чтобы выбросить, вернитесь к последнему коммиту. В Git git restore . возвращает файлы, которые Git уже отслеживает, к виду последнего коммита, если изменения не были добавлены через git add; файлы, созданные ассистентом, эта команда не удаляет, поэтому снова посмотрите git status и удалите их вручную. Редакторы со своей отменой или контрольными точками умеют то же самое, в пределах, которые они описывают. Затем напишите задачу получше: скажите, что пошло не так, и добавьте проверку, которая поймала бы это.

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

Может ли проверку сделать другой ИИ?

Он может читать diff вместе с вами: объяснять строки, указывать на удалённые проверки, спрашивать, зачем нужна новая функция. Это помогает, особенно если вы не читаете код. Но он не может решить, делает ли игра по-прежнему то, что вы хотели, потому что это знаете только вы, и не может сыграть в игру за вас. Используйте его как второго читателя, но никогда не как одобрение.

Частые вопросы

Сколько должна занимать проверка? Примерно столько, насколько мало изменение. Если чтение diff занимает больше времени, чем написание задачи, задача, скорее всего, была слишком большой; следующую разделите.

Нужен ли для этого Git? Нужен какой-то способ увидеть, что изменилось, и вернуться назад. Обычно это Git, и он бесплатный; большинство редакторов и ассистентов с ним работают.

Что если изменение верное, но код выглядит неряшливо? Оставьте его, если оно работает и вы его понимаете, а приборку поручите отдельной задачей, с теми же проверками. Не смешивайте приборку с новой функцией.

Проверять ли изменения в графике, звуке и файлах уровней? Да, глядя и играя, а не читая diff. Список изменённых файлов всё равно говорит, на какие смотреть.

Когда в игру могут играть другие? Когда маршрут выше проходит на свежей странице и незнакомый человек может пройти игру без вашей помощи. Тогда её можно отправить на HeapPlay.