Не чините то, что пока не воспроизведено
Сообщение «после изменения адреса всё сломалось» не говорит, что именно произошло. Пропала кнопка, сохранился старый город, изменился только экран подтверждения или письмо пришло не по адресу? Нейросеть может быстро перечислить возможные причины, но это список гипотез. Если сразу просить её исправить код, разработчик рискует затронуть не ту часть системы и получить новую ошибку. Первый результат работы ИИ — карточка наблюдения: ожидаемое действие, фактический результат, момент сбоя, версия приложения и условия, которые ещё неизвестны. До уточнения фактов не надо описывать причину как установленную.
Снимите лишние личные данные
В обращении часто есть имя, телефон, адрес, номер заказа и снимок экрана с другими сведениями. Для технического сценария обычно достаточно условных идентификаторов и нескольких полей состояния. Сделайте копию письма, замените персональные значения и проверьте вложения. Если ошибка касается именно специальных символов в адресе, сохраните форму тестового значения, но используйте вымышленную строку. Не передавайте модели живой токен доступа, cookie или полный журнал запросов, пока не ясно, где эти данные хранятся. Сбор минимального контекста — часть диагностики, а не лишняя бюрократия.
Задайте клиенту вопросы, на которые есть короткий ответ
Попросите модель предложить не больше трёх уточнений. Хороший вопрос: «В каком экране вы увидели старый город — при оформлении, в истории заказа или в письме?» Плохой: «Опишите всё, что делали с приложением». Спросите также примерное время, устройство и произошло ли изменение после повторного входа. Если в журнале уже есть версия браузера, не просите клиента искать её вручную. Вежливая форма нужна, но главный критерий — уменьшение неопределённости. Полученные ответы добавьте к карточке как данные клиента, отдельно от собственных предположений инженера.
Соберите минимальный сценарий
На тестовом аккаунте начните с известного исходного состояния: один заказ, город А и сохранённый адрес. Измените адрес на город Б, откройте те же экраны в том же порядке и посмотрите, где остаётся старое значение. Если ошибка появляется только после обновления страницы, запишите это. Если только в письме, возможно, дело в шаблоне уведомления, а не в форме. Нейросеть может помочь оформить шаги в список, но каждый пункт должен быть реально выполнен человеком или автоматическим тестом. Формулировка «после нескольких действий» не воспроизводима. Укажите точные клики и состояние до и после.
Сверьте наблюдение с логами
Подберите лог по времени и тестовому идентификатору. Смотрите, что отправил браузер, что ответил сервер и где изменилось значение. Не копируйте в чат десятки тысяч строк: выделите относящиеся к операции события, удалите секреты и сохраните полный оригинал в защищённой среде. Модель может заметить различие между полями billing_city и shipping_city или неверный ключ кэша, но вывод должен опираться на реальные события. Если логи отсутствуют, это результат диагностики: добавьте безопасное наблюдение, а не придумывайте историю запроса.
Пишите тест до патча
Когда сценарий воспроизводится, закрепите его как тест с исходным состоянием, действием и ожидаемым результатом. Сначала убедитесь, что тест падает на текущей версии; затем внесите минимальную правку и добейтесь прохождения. Если тест сразу зелёный, он не ловит проблему. Попросите ИИ предложить крайние случаи: два адреса, возврат к старому городу, повторная отправка формы, потеря сети между сохранением и подтверждением. Не добавляйте все варианты автоматически. Выберите те, что соответствуют реальной причине и цене сбоя. В <a href="/material/kod-revyu-zavisimosti">проверке новой зависимости</a> мы разбираем похожую дисциплину: сначала доказать необходимость изменения, затем расширять код.
Примите исправление глазами пользователя
После успешного теста повторите путь в интерфейсе и проверьте письмо, историю заказа и мобильный экран. Ошибка могла исчезнуть в базе, но остаться в старом кэше. Сравните не только значение поля, но и ясность сообщения пользователю: знает ли он, что изменение сохранено, и что делать, если оно не применяется к уже отправленному заказу. Если причина была в непонятном тексте интерфейса, один кодовый патч без исправления формулировки оставит повторные обращения. Для медленных страниц есть отдельный <a href="/material/ii-dlya-diagnostiki-medlennoy-stranicy-20261025-b2">порядок измерений</a>; не смешивайте задержку загрузки с неверным состоянием данных.
Итог и FAQ
Лучшее применение ИИ в этой задаче — навести порядок в симптомах и вопросах, а не быстро угадать виновный файл. **Может ли модель сама определить причину по письму?** Только предложить гипотезы; нужна проверка на версии продукта и логах. **Зачем тест до исправления?** Он доказывает, что вы воспроизвели проблему и сможете заметить её возвращение. **Можно ли оставить номер заказа в публичном запросе?** Нет, замените его тестовым идентификатором. **Что делать, если баг не повторяется?** Сохранить факты, запросить недостающий контекст и не объявлять случай закрытым без объяснения клиенту.
Короткая проверка
- Понятны цель и человек, который примет результат.
- Исходники очищены, их версия и дата сохранены.
- Факты, числа и ограничения сверены вручную.
- Неудачный пример записан вместе с причиной.
- Есть измеримый следующий шаг и путь назад.