Как написать задачу для ИИ-ассистента, чтобы результат можно было проверить?

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

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

Что делает задачу проверяемой?

Пять частей. Большинству задач нужны все пять, и каждая умещается в одно-два предложения.

Новизны в этом совете нет. Руководство GitHub по запросам для Copilot просит простой и конкретный запрос, разбитый на шаги, с одним-двумя примерами того, что вы ожидаете. В рекомендациях по работе с Claude Code на первом месте стоит проверка, которую ассистент может запустить сам, потому что без неё «выглядит готовым» остаётся единственным сигналом, который у него есть. Обе страницы были такими 25 октября 2026 года. Дальше эти советы применены к небольшой игре.

Насколько маленькой должна быть одна задача?

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

Если задаче нужно описание подлиннее, сначала попросите план, а код оставьте на потом. Страница Claude Code предлагает именно это: пусть ассистент прочитает код и предложит, какие файлы изменятся, вы сами прочитаете план, и только потом он начнёт писать. План, который затрагивает половину проекта, — знак, что задачу стоит разделить.

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

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

Вот одна и та же просьба для небольшого шутера, написанная дважды.

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

Как объяснить ассистенту, как проверить свою работу?

Дайте ему то, что отвечает «да» или «нет».

• Тест, который ассистент может запустить, с прописанными случаями: «перезапуск ставит счёт в 0».
• Команда, результат которой можно прочитать: сборка завершается, страница загружается без ошибок в консоли.
• Шаги, которые вы сыграете сами, записанные до изменения: «старт, потерять все жизни, нажать перезапуск, на счёте 0».

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

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

Что ассистент должен сказать, когда закончит?

Попросите в той же задаче короткий отчёт в таком порядке:

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

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

Что стоит держать в файле проекта, а не писать в каждой задаче?

Всё, что иначе пришлось бы повторять: как запустить игру и тесты, какие папки трогать нельзя, правила кода. Большинство ассистентов читают такой файл в начале сеанса (в Claude Code он называется CLAUDE.md). Делайте его коротким: страница Claude Code предупреждает, что в длинном файле важные правила теряются.

Правило заслуживает места там, если, забыв его, можно сломать игру. В заметках, которые мы ведём для KittenGalaxy, сказано, что при добавлении клавиши, экрана или состояния игры сенсорное управление для них добавляется в том же изменении, иначе игроки на телефоне до них не доберутся. Тогда в задаче остаётся сказать только то, что новое.

Что делать, если результат неправильный?

Вернуться назад и попросить снова, с задачей получше.

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

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

Нужно ли быть программистом, чтобы писать такие задачи? Нет. Части 1, 3 и 5 — о том, что делает игра, простыми словами. Для части 2 спросите ассистента, где должно быть изменение, прежде чем просить его внести.

Длинная задача лучше короткой? Сама по себе нет. Длинную задачу со многими изменениями проверить труднее, чем короткую с одним. Длина помогает, когда добавляет проверку или ограничение.

Нужны ли тесты в маленькой игре? Для правил, которые можно сформулировать точно (счёт, жизни, таймер, сохранения), да. Их дёшево запускать после каждого следующего изменения. Ощущения и удовольствие по-прежнему проверяются игрой.

Что, если ассистент задаёт мне вопросы? Ответьте на них в задаче до того, как он начнёт писать. Вопрос, заданный рано, обходится дешевле неправильного изменения.

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