Если вы искали сам чат: с чего разработчику начать первый запрос
Вы искали окно, куда можно вписать вопрос и получить ответ, а открылась то статья про устройство моделей, то страница с абстрактными обещаниями. Для первого вечера это лишнее. Нужна переписка: вы описываете ошибку словами, показываете крошечную функцию и просите объяснить, о чём кричит стек. Ниже именно этот старт. Без боевых ключей, без выгрузки чужих заказов и без попытки притвориться, что веб-страница и программный доступ для разработчика — одна и та же дверь.
Снимок привычек здесь относится к сентябрю 2026 года. Имена режимов к этому месяцу уже не обязаны совпадать с теми, что обсуждали раньше, а ограничения по вызовам лучше не заучивать из старых пересказов. В начале 2025 года разработчики отдельно говорили о быстром диалоге и о более медленном режиме рассуждения. Для разбора конкретной ошибки чаще хватает обычного обмена репликами: вам нужен следующий вопрос к своему коду, а не длинная лекция. Если вы ещё выбираете между Cursor, ChatGPT, Claude и Gemini, начните со сравнения ИИ для программирования.
Вы искали поле, а не доклад
Поле узнаётся делом. Щелчок ставит курсор, ваша фраза остаётся на экране отдельным блоком, под ней появляется текст, которого минуту назад не было. Доклад устроен иначе: авторы, аннотация, сплошные абзацы, писать некуда. Если вы попали в доклад, не вытаскивайте из него «главную мысль о будущем отрасли». Вернитесь к поиску окна и начните с ошибки, которую можете рассказать коллеге вслух.
Первый запрос не должен содержать секрет, даже если кажется, что так «модель поймёт контекст». Ключ доступа, пароль базы, строка подключения, токен оплаты, почта покупателя — это не контекст. Это то, что вы не продиктовали бы человеку в соседнем кресле. Если нужно именно живое окно, а не обзор статей, имеет смысл попробовать нейросеть на куске, который и так можно показать на обычном разборе кода.
Баг словами: двойное нажатие «Оплатить»
Рабочий пример, очищенный от лишнего. В учебном магазине кнопка «Оплатить» остаётся нажимаемой, пока первый запрос ещё идёт. На медленной сети вы успеваете нажать второй раз. В журнале появляются два заказа с одним и тем же номером корзины, для примера пусть это будет C-1842. На быстрой сети повтор поймать трудно. Визуально кнопка не серая. Ожидание: второй клик ничего не создаёт. Факт: создаёт.
Так и напишите, почти дословно. Добавьте, чего вы уже не делали: не смотрели серверные журналы, не отключали сеть специально, не трогали настоящие платежи. Попросите не чинить весь магазин, а задать вам три вопроса, на которые должен ответить код. Например: уходит ли на сервер один запрос или два; кто должен запрещать повтор — обработчик кнопки или место, где создаётся заказ; какой локальный признак вы можете посчитать руками, не оплачивая ничего настоящего.
Плохое сообщение выглядит как пачка из боевого окружения: целиком вставленный файл настроек, длинная строка ключа, адрес внутренней машины, список реальных заказов с фамилиями. Такое сообщение не делает ответ умнее. Оно только раздаёт чужие данные. Если рука уже потянулась вставить «ну хоть кусок» ключа, остановитесь и замените кусок словом «скрыто». Номер корзины в рассказе оставьте учебным, не сегодняшним боевым.
Что попросить и чего не ждать в ответ
Хороший ответ на этот баг — не готовый патч на сто строк, а развилка. Либо кнопка шлёт два запроса, и тогда вы смотрите обработчик нажатия и признак «запрос уже ушёл». Либо запрос один, а два заказа рождаются на стороне создания заказа, и тогда двойной клик ни при чём, вы наблюдали совпадение. Попросите модель явно сказать, какое наблюдение разводит эти две ветки. Наблюдение должно быть вашим: вы смотрите журнал или счётчик и сами видите единицу или двойку.
Не принимайте фразу «скорее всего, гонка» как завершение. Гонка — имя класса проблем, а не место в вашем коде. Уточните: «Назови файл и функцию, которые я должен открыть первыми, если второй клик ещё не запрещён на кнопке. Код не пиши длиннее объяснения». Если в ответ прилетает новый каркас приложения, отложите его. Вы пришли разобрать C-1842, а не переселять магазин на другую основу за вечер.
Отдельно запретите смешивать этот баг с другими, которые вы упомянули вскользь. Одна переписка — одна неисправность. Иначе вам соберут историю, где двойной заказ, кривое количество и пустая корзина лечатся одной выдуманной причиной.
Разбор маленькой функции, не всего репозитория
Вторая реплика вечера может быть про количество в строке заказа. Функция короткая, в ней нет адресов и нет секретов. Она нарочно хрупкая, чтобы было что обсуждать:
- def normalize_qty(raw):
- text = str(raw).strip()
- text = text.replace(«,», «.»)
- return float(text)
Просьба о разборе: «Это четыре строки. Не переписывай проект. Скажи, что будет с пустой строкой, со строкой из пробелов, с текстом „1,5“ и с текстом „1.2.3“. Где здесь нет проверки, и какой один тест мне запустить у себя. Готовый класс не предлагай».
Свои проверки сделайте до того, как согласитесь с ответом. «1,5» после замены запятой становится «1.5», и float от этого обычно даёт полтора. Пустая строка и «1.2.3» должны споткнуться: это не одно число. Если модель спокойно говорит, что «1.2.3» превратится в 1.2, она придумала лишнее отсечение. Верьте запуску у себя, не абзацу. Четыре строки легко выполнить в том интерпретаторе, который уже стоит на машине, без всякой переписки.
Имеет смысл спросить, связана ли эта функция с двойным заказом. Честный ответ: сама по себе не связана. Она про разбор количества, кнопка «Оплатить» про повтор запроса. Если модель всё равно склеивает их в один сюжет, напишите: «Это разные темы. Вернись только к normalize_qty». Умение развести два разговора важнее, чем длинный совет.
Что стек пытается сказать
Представьте, что пустое количество уже дошло до float, и вы видите короткую трассировку. Перед вставкой вымарите из неё всё, что похоже на ключ, почту или внутреннее имя машины. Учебный остаток может быть таким:
- ValueError: could not convert string to float
- File «qty.py», line 4, in normalize_qty
- File «cart.py», line 22, in add_item
Просьба: «Объясни порядок чтения. Не предлагай ловить ошибку молча. Скажи, какая строка моя, а какая просто сообщает тип сбоя. Не выдумывай файлы, которых здесь нет».
Смысл, который вы должны узнать в ответе и проверить по строкам глазами. ValueError говорит, что строку не удалось сделать числом. Ближняя к сбою ваша строка — это return внутри normalize_qty, четвёртая строка файла qty.py. Выше по стеку add_item в cart.py на строке 22: оттуда количество принесли. Трассировка не говорит, какой товар, какой пользователь и упала ли база. Если ответ добавляет «покупатель не авторизован» или «нет связи с оплатой», это уже фантазия: в трёх строках этого нет.
Читать удобно с типа ошибки, затем с самой нижней вашей функции, затем вверх, к тому, кто её вызвал. Длинные кадры библиотек, если они есть в полном стеке, на первом проходе пропускают, пока не ясно, какое ваше место упало. В окно не тащите полный боевой стек на сотни строк: вырежьте свои два-три кадра и одну строку ошибки. Остальное замените пометкой, что посередине были чужие кадры.
Веб-окно и программный доступ — разные двери
Веб-окно — это место, где сидите вы. Набрали реплику, прочитали ответ, скопировали к себе только то, что проверили. Программный доступ устроен иначе: ваша программа сама отправляет текст и сама забирает ответ, без того, что вы каждый раз смотрите в поле. Для этого программе нужен ключ. Ключ хранят там, где проект уже хранит секреты, а не в сообщении чата и не внутри функции, которую вы принесли на разбор.
Имена узлов и пути вызовов в эту статью не входят специально. Их легко запомнить неверно, а к сентябрю 2026 года они могли смениться так же, как имена режимов. Если вам нужен программный доступ, берите описание у того места, где выдают ключ, и сверяйте его в день работы, а не по памяти из чужого пересказа начала 2025 года. Цену и дневной потолок отсюда тоже не берите: их не стоит выдумывать, они меняются.
Для бага с двойным нажатием программный доступ не нужен. Вы ещё не автоматизируете толпу запросов. Вы пытаетесь понять одну кнопку. Окно для разговора закрывает этот вечер целиком. Подключать вызовы из кода имеет смысл позже, когда есть ясный маленький текст запроса, который вы уже прогнали руками и готовы повторять без своего участия. До этого ключ только увеличивает поверхность, где секрет можно случайно вставить не туда.
Как превратить ответ в проверку у себя
Заведите на бумаге три строки наблюдения, до любых правок. Первая: один медленный клик по «Оплатить» создаёт сколько заказов с учебным номером корзины. Вторая: два быстрых клика создают сколько. Третья: пустое количество в normalize_qty падает или молча становится нулём. Модель может подсказать, что именно считать. Считать должны вы, на данных, которые не жалко показать.
Если второе наблюдение даёт два заказа, вы возвращаетесь в окно с фактом, а не с ощущением: «Два быстрых клика, два заказа, кнопка не серела. Куда смотреть сначала, если сервер я ещё не открывал?» Факт сужает ответ. Ощущение «кажется, двоится» раздувает его.
Правку в коде делаете вы, маленьким шагом. Например, запрещаете второе нажатие, пока нет ответа, и повторяете те же два наблюдения. Если двойной заказ остался, гипотеза про кнопку ослабла, и вы честно пишете об этом в следующем сообщении. Не просите «теперь почини наверняка». Просите следующую развилку.
Шаблон первой реплики, который не раздувается
Если в голове каша, не пишите «посмотри мой проект». Заполните короткий каркас и отправьте его как есть. «Где: учебный магазин, кнопка „Оплатить“. Что делаю: два быстрых клика, пока первый запрос не закончился. Что жду: один заказ. Что вижу: два заказа с одним номером корзины C-1842. Когда проявляется: на медленной сети. Чего не делал: не открывал серверные журналы и не платил по-настоящему. Не вставляю ключи. Задай три вопроса к коду, не пиши новый каркас».
Каркас хорош тем, что в нём некуда приткнуть секрет незаметно для вас самих. Каждая строка — наблюдение или запрет. Если рука хочет дописать «вот ссылка на бой» или «вот ключ на всякий случай», для этой строки в каркасе нет места: сотрите её до отправки. Учебный номер корзины оставьте, живой номер сегодняшнего покупателя замените на C-1842 или уберите.
После ответа перепишите три вопроса модели своими словами на бумаге. Если не можете переписать, ответ был туманом. Попросите сузить: «Оставь один вопрос, на который я отвечу числом: сколько запросов ушло». Число потом добываете вы, не модель.
Что сказать коллеге после сеанса
Коллеге не пересылают простыню из окна. Ему хватает пяти фраз, которые вы произносите сами. Кнопка не сереет на время запроса. Два быстрых клика дают два заказа с одним номером корзины. Ещё не смотрели, один ли запрос уходит с браузера. Функция количества из четырёх строк спотыкается на пустой строке и на «1.2.3», это отдельная тема, не причина двойного заказа. Следующий шаг ваш: посчитать запросы, не меняя весь магазин.
Если коллега просит «скинь, что тебе написали», скиньте свой пересказ, а не сырой ответ. В сыром ответе легко застревает выдуманный файл или совет про ключ. Пересказ вы уже отфильтровали фактами, которые видели. Так окно остаётся черновиком вопросов, а не вторым автором ваших изменений.
Локальный счёт без настоящей оплаты
Заведите учебную корзину с одним товаром и нулевой ценой или с ценой, которую ваш стенд и так умеет проводить без банка. Нажмите один раз, запишите, сколько строк заказа появилось. Обновите стенд, нажмите дважды быстро, запишите снова. Это и есть наблюдение, которое можно принести обратно в окно. Настоящую карту, боевой ключ платёжного сервиса и почту живого клиента в стенд не подставляйте даже «на один раз».
Если на стенде двойной заказ не ловится, а на медленной сети ловится, так и напишите: «Локально один заказ, при искусственно медленном ответе два». Не просите модель угадать прод. Попросите, какой признак в интерфейсе вы можете добавить временно, чтобы видеть, ушёл ли повторный клик, и уберите этот признак после проверки. Временная пометка в учебной кнопке честнее, чем уверенный абзац про архитектуру.
Вопросы перед первым запросом
Чем разговор в окне отличается от программного доступа?
В окне текст читаете вы и вы решаете, что забрать в проект. При программном доступе текст ходит между вашей программой и сервисом по ключу, без вашего взгляда на каждую реплику. Для разбора одной ошибки ключ не нужен. Его не вставляют в сообщение «для примера».
Что вырезать из описания бага обязательно?
Ключи, пароли, строки подключения, настоящие почты, номера карт, внутренние имена машин и сегодняшние заказы живых людей. Оставьте действие, ожидание, факт и учебный номер вроде C-1842. Если строка секрета уже попала в черновик, не отправляйте черновик: начните сообщение заново, без этой строки.
Зачем ограничивать функцию четырьмя строками?
Так видно, что ответ говорит именно о них, а не о воображаемом проекте вокруг. Четыре строки вы способны запустить сами. Длинный фрагмент прячет место, где модель додумала проверку, которой у вас нет. Восемь строк — уже верх, за которым разбор вечера расползается.
Стек указывает на строку. Это и есть причина?
Это место, где сбой стал видимым, а не обязательно место, где в данные попала пустота. ValueError на float говорит о плохой строке. Кто принёс строку, видно кадром выше, add_item. Почему поле оказалось пустым, стек из трёх строк не сообщает. Не достраивайте причину, которой в трассировке нет.
Можно ли одним запросом отдать весь репозиторий?
Даже если объём пройдёт, ответ будет общим. Вы не отличите совет по вашей кнопке от совета «вообще про магазины». Принесите одну неисправность и одну маленькую функцию. Остальные файлы откроете сами, когда появится конкретное имя, которое стоит проверить.
Ответ предлагает новый каркас приложения. Брать?
В первый вечер нет. Каркас не объясняет, один запрос ушёл или два. Верните разговор к наблюдению, которое можно повторить руками. Большую смену основы обсуждают отдельно, когда текущая кнопка уже описана фактами, а не вместо этого описания.