Чтобы найти ошибку вместе с ИИ, сначала повторите сбой и соберите факты: действие, запрос, ответ и нужную запись в журнале. Затем проверьте одно объяснение и только после этого меняйте код.
«Кнопка не работает, исправь» — знакомое начало долгого разговора с помощником. Он меняет файл за файлом, а форма всё ещё не отправляется. Покажем другой ход на настоящей учебной поломке. Для разбора собранных наблюдений есть и текстовый помощник в Ное: его инструкция ниже.
Коротко
- Сбой нужно повторить в понятных условиях: что ввели, что нажали, чего ожидали и что получили.
- В нашем опыте форма отправляла
name, а сервер ожидал full_name. Поэтому заполненное поле всё равно приводило к отказу. - Причину нашли по запросу, ответу 422 и соответствующей записи журнала. Изменили одно имя поля и повторили отправку.
- После исправления заявка сохранилась. Пустое имя сервер по-прежнему отклонял — полезная соседняя проверка тоже осталась рабочей.
Как описать сбой, чтобы появился первый шаг
Отладка, или debugging, — поиск причины неправильной работы программы и проверка исправления. Начинается она с воспроизведения: повторения действий, при которых ошибка появляется снова.
Для учебного сайта «Мастерская» записали: открыть форму, ввести «Учебная Анна», нажать «Оставить заявку». Ожидание — увидеть подтверждение и найти новую запись. На деле появляется «Не сохранено: Нужно поле full_name».
Это уже гораздо полезнее, чем «ничего не работает». У нас есть конкретное действие, ожидаемый результат и точный текст отказа. Помощник может повторить те же шаги и проверить, встретился ли с той же проблемой.
На своём проекте добавьте адрес страницы, версию приложения, если она известна, и важные условия: выполнен ли вход, что было в полях, появляется ли сбой каждый раз. Реальные имена и контакты замените вымышленными. Если воспроизвести не удалось, так и запишите — причина пока не доказана.
Где посмотреть, что отправила форма
Откройте инструменты разработчика в браузере, вкладку Network («Сеть»), затем повторите отправку. В первом уроке показано, как находить запросы страницы.
Выберите запрос формы. В Payload («Переданные данные») видно, что ушло на сервер. В Response («Ответ») — что он вернул. В нашем учебном запросе ушло вот это:
А сервер сообщил, что ему нужно full_name. Два похожих названия для человека могут означать одно и то же, но программа ждёт конкретное поле. Если его нет, ей нечего читать в этом месте.
Код ответа — 422 Unprocessable Content, «содержимое не может быть обработано». Сервер понял формат запроса, но не смог выполнить его с присланными данными. Общее значение кода описано в справочнике MDN. Само число ещё не раскрывает причину: её уточняет текст ответа и код программы.
JSON — JavaScript Object Notation, текстовый формат записи данных. В примере name — имя поля, «Учебная Анна» — его значение. Имя поля не равно тексту подписи рядом с кнопкой; смотреть нужно на то, что реально передано.
Зачем нужны журналы и номер запроса
Лог, от английского log, — журнал событий программы. Сервер может записывать, какое действие пришло, чем закончилось и почему было отклонено. Это помогает увидеть серверную сторону того же события.
В учебном проекте каждому отправленному запросу присваивается request_id, идентификатор запроса. Он попадает и в ответ браузеру, и в запись журнала. Мы нашли там тот же идентификатор: путь /api/requests, статус 422, причина «Нужно поле full_name».
Идентификатор связывает две записи. Он не объясняет ошибку сам: объяснение мы получили из содержимого запроса и отказа. Если журнал большой, время и идентификатор помогают выбрать нужное событие среди остальных.
Не просите ИИ «изучить все логи» и не копируйте их целиком. Начните с небольшого обезличенного фрагмента вокруг нужного запроса. В журнал не должны попадать пароли, ключи доступа и данные посетителей. Руководство Chrome по сетевой панели показывает, как посмотреть отправленные данные и ответ; это разные части одного обмена.
Как проверить причину до правки
После просмотра фактов возникла гипотеза — объяснение, которое можно проверить: форма отправляет поле с неверным именем. Чтобы её проверить, мы сравнили два места в коде.
Теперь у правки есть основание. Мы меняем имя поля при отправке на full_name, потому что оно требуется сервером в этом учебном приложении. Это не универсальное правило о названиях: у другого проекта договор может быть иным.
Что было бы плохой правкой? Просто убрать проверку имени на сервере, чтобы исчез отказ. Тогда программа перестала бы сообщать об отсутствующих данных, но нужную заявку это не создало бы.
В настоящем проекте сперва выясните контракт API. API — Application Programming Interface, программный интерфейс: договор, по которому части приложения обмениваются запросами и ответами. Где его описание и какая сторона от него отклонилась, нужно проверить до замены поля. Путь формы через сервер и базу разобран во втором уроке серии.
Чем подтвердили исправление
Повторили исходное действие: то же учебное имя, та же кнопка. Теперь форма передала full_name, сервер ответил 201 Created, «создано», и показал идентификатор заявки. Мы отдельно прочитали список и нашли эту запись.
Затем напрямую отправили пустое full_name. Сервер снова ответил 422, дополнительной записи не появилось. Получилось проверить и нужный успешный случай, и сохранность проверки пустого имени.
Именно это подтверждает исправление нашей ошибки. Сообщение ИИ «поправил», изменённый файл или успешная подготовка проекта к запуску такого подтверждения не дают. Нужно повторить то действие, которое раньше ломалось.
Этот опыт выполнен в отдельном локальном приложении с вымышленными данными. В рабочем сайте мы не ломали формы и не трогали заявки посетителей. Проверка не доказывает работу почты, платежей или всех остальных сценариев — их в учебном приложении нет.
Когда исправление уйдёт на живой сайт, понадобится ещё одна проверка: открывается ли именно новая версия. Об этом — урок про CI/CD и деплой, то есть регулярные проверки изменений и их выкладку.
Как дать задание Claude Code, Codex или Antigravity
Вставьте запрос в помощника внутри проекта. Он должен сначала собрать доказательства, а не начинать с большой переделки. Если у него нет нужного доступа или способа запуска, полезный ответ назовёт этот пробел.
Помоги найти причину одной ошибки в этом проекте. Сначала исследование и воспроизведение, затем объяснение, после этого минимальная правка.
Действие: [точные шаги и вымышленные данные].
Ожидаемый результат: [что должно произойти].
Фактический результат: [что видно и точный текст ошибки].
Наблюдения: [адрес запроса, статус, обезличенный ответ и нужный фрагмент журнала].
1. Найди связанные файлы и безопасный способ повторить сбой локально. Не обращайся к живым клиентам и рабочим данным. Если воспроизведение невозможно, назови недостающее и не объявляй причину найденной.
2. Свяжи действие пользователя, запрос браузера, ответ сервера и запись журнала. Укажи, что подтверждено, а что пока предположение. Термины объясни простыми словами.
3. Выбери одну основную гипотезу. Перед изменением кода проведи минимальную проверку, которая может её подтвердить или опровергнуть. Покажи результат.
4. Если причина подтверждена, сделай небольшое исправление по существующему устройству проекта. Не убирай проверку данных и не скрывай сообщение об ошибке ради зелёного результата.
5. Повтори исходное действие и один близкий сценарий, который правка могла затронуть. Для сохранения данных прочитай полученную учебную запись отдельно.
6. Оформи итог: причина и свидетельство → что изменено → исходный результат до и после → соседняя проверка → что осталось неизвестным. Не называй публикацию выполненной без её подтверждения.
Если вы собираете сайт в студии Нои, тот же принцип пригодится при описании задачи: назовите сломанное действие и ожидаемый результат. Сам по себе длинный список пожеланий «проверь всё» не помогает выбрать первую проверку.
Как разобрать отчёт об исправлении
Текстовый помощник полезен, когда разработчик или ИИ уже прислал отчёт, а вы хотите понять его смысл. Он может проверить рассуждение по тексту. Самостоятельно открыть проект по такой переписке он не сможет.
Ты помогаешь начинающему разбирать ошибки приложения и отчёты об исправлении. Используй только присланные факты. Доступа к проекту, журналам и серверу у тебя нет; не заявляй о выполненных проверках.
Вводные:
Действие и ожидаемый результат: [описание].
Что произошло: [ошибка и наблюдения].
Что предложено или изменено: [обезличенный отчёт].
Что проверено после: [точные результаты или «неизвестно»].
1. Перескажи проблему простыми словами. Объясни новые термины рядом с соответствующим действием.
2. Раздели факт, гипотезу и исправление. Для названной причины укажи свидетельство из вводных. Если его нет, причина остаётся предположением.
3. Проверь, повторено ли исходное действие после правки. Сборку, изменение файла и слова «готово» не считай доказательством результата пользователя.
4. Предложи одну ближайшую безопасную проверку и один соседний сценарий. Если данных не хватает, задай до двух точных вопросов. Не придумывай ответы сервера, имена файлов и доступы.
5. Если правка только скрывает сообщение или отключает проверку данных, объясни, какой исходный результат остался неподтверждённым. Рабочие данные, доступы и услуги не предлагай менять.
6. Выведи: «Что известно», «Насколько объяснена причина», «Чем проверить результат». Ответ держи коротким и привязывай к конкретному сбою.
Ответ не длиннее 1200 знаков, без вложенных списков. Для формы с сохранением ближайшая проверка включает исходную отправку и отдельное чтение новой записи. Соседний случай должен проверять осмысленный отказ, например пустое обязательное поле. Не считай исчезновение прежней ошибки доказательством сохранения.
Создайте в Ное помощника для разбора ошибок с этой инструкцией. Приносите ему очищенные от секретов наблюдения и отчёты: он поможет сформулировать вопрос к разработке и заметить пропущенную проверку. Это разбор текста, поэтому результат нужно подтвердить отдельным действием в вашем приложении.
В учебной пробе помощник связал отказ с разными именами поля и предложил проверить создание записи, а затем отправку пустого имени. Во второй пробе он не принял зелёную сборку и скрытое сообщение за доказательство ремонта формы. Именно такие вопросы полезно задать к отчёту о правке.
Если программа жалуется на отсутствующее поле в базе, одной правки формы может быть недостаточно. В уроке про миграции базы данных показываем, как связаны код и устройство хранения, как проверить старые записи и что выяснить до запуска изменения.
С чего начать прямо сейчас
Выберите один повторяемый сбой. Запишите действие, ожидание и фактический результат в трёх коротких строках. Затем найдите один относящийся к нему запрос. Уже с этими вводными разговор с ИИ станет предметнее.
Частые вопросы
Нужно ли сразу читать весь код проекта?
Начните с пути одного сломанного действия. Связанные файлы обычно полезнее случайного обзора всех папок. Если наблюдение укажет на другую часть, расширите поиск по этой связи.
Если в консоли красная ошибка, она и есть причина?
Не обязательно. Консоль — часть инструментов браузера, где видны сообщения и ошибки кода страницы. Красная запись может относиться к другой функции или внешнему сервису. Свяжите её по времени и действию с вашим сбоем.
А если запрос формы вообще не появился?
Сначала смотрите, выполнилось ли нажатие и сработал ли код отправки. Пока запрос не ушёл из браузера, искать его отказ на сервере преждевременно. Убедитесь также, что Network был открыт до действия и нужные строки не скрыты фильтром.
Можно ли поменять сразу всё, что предложил ИИ?
При большой правке труднее понять, что устранило сбой и что сломало соседнее. Для первой проверки выберите подтверждённую причину и небольшое изменение. Дальнейшую переделку обсуждайте отдельно, если она действительно нужна.
Что делать, если ошибка пока не повторяется?
Сохраните условия и доступные наблюдения, не объявляйте её исправленной. Полезно сравнить удачную и неудачную попытки: вход, данные, версию, время и ответ. Это даст следующую проверяемую гипотезу.
Вывод
Хорошее задание ИИ начинается с того, что вы увидели сами. Повторите сбой, найдите одно подходящее свидетельство, проверьте причину. Тогда у исправления появится понятное доказательство: то же действие стало работать, нужная проверка рядом сохранилась.
