Промты для программиста: 43 готовых промта по задачам кода

Промты для программиста: где нейросеть работает, а где выдумывает

Промт для программиста работает там, где задача целиком влезает в запрос: тесты по сигнатуре, разбор трейсбэка, докстринг, схема базы. Ломается там, где нужен контекст проекта. Граница проходит не между «простым» и «сложным» кодом и не между языками. Она проходит между тем, что вы можете дописать в запрос, и тем, что живёт в головах команды: почему скидка у вас не суммируется с промокодом, зачем в модуле оплаты висит флаг с именем legacy_mode и что отвалится, если его выключить. Первое модель сделает за минуту. Второе она угадает — уверенным тоном, без оговорок, и вы заметите это в отчёте за месяц. Всё остальное на этой странице — следствие одной этой границы: под какие задачи промт стоит писать, как его собрать, чтобы ответ запускался с первого раза, и что проверять руками, прежде чем отправлять результат дальше.

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

Почему «напиши парсер на Python» не работает, а пять строк задания — работают

Классический заход: «Напиши парсер сайта на Python». Ответ приходит за десять секунд, выглядит убедительно и не запускается ни разу. Внутри будет поиск div с классом item и комментарий «замените селекторы под свой сайт» — то есть модель аккуратно вернула вам ровно ту работу, ради которой вы к ней пришли.

Смените один абзац — и всё меняется.

Разметку вашего сайта модель не знает, а вы знаете: карточка — такой-то класс, цена — такой-то, ссылка — такой-то. Дописали пять строк селекторов — получили код, который вытаскивает данные с первого прогона. Дописали строку про паузу между запросами — получили код, который не положит чужой сервер. В этом вся работа с промтом: вы не просите модель угадать, вы переносите в текст то, что уже знаете сами.

Три вещи, без которых ответ почти наверняка придётся выбросить:

• Язык и версия. «Python» и «Python 3.11, aiogram 3.x» — два разных ответа. Во втором не будет кода под aiogram второй версии, где многое называется иначе.
• Входные данные в натуральном виде. Не «CSV с продажами», а «разделитель точка с запятой, кодировка windows-1251, колонки: дата_время, номер_чека, позиция, количество, сумма». Строчка про кодировку — это тот случай, когда одно предложение в промте экономит полчаса на UnicodeDecodeError.
• Отсечка — чего делать нельзя. Самая недооценённая часть. Фраза «не давай фрагменты с пометкой „остальное по аналогии“» превращает ответ-конспект в файл, который запускается.

Все промты на этой странице устроены одинаково: подстановки в квадратных скобках уже заполнены нашими значениями. Вставили как есть — увидели формат ответа на рабочем примере. Стёрли пример, вписали своё — получили результат на своих данных. А вот пустая скобка вида «[КОД]» ответ ломает: модель дорисовывает туда что-то своё и дальше честно работает с выдумкой.

Код с нуля: когда задание целиком помещается в промт

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

Парсер — самый частый запрос из этой зоны. Промт ниже собран так, чтобы шаблон переносился на новый сайт правкой одного блока настроек, а не двадцати мест по файлу; модель прямо просят посчитать, сколько мест придётся тронуть при переносе, и вынести лишнее в настройки. Отдельно в нём прописан отказ от обхода защит: если раздел закрыт в robots.txt или страница рисуется скриптом, шаблон обязан остановиться с внятным сообщением, а не «пробовать иначе».

Напиши шаблон Python-парсера сайтов, который переносится на новый сайт правкой одного блока настроек.

Стек: requests, BeautifulSoup, lxml; Selenium не подключай. Блок настроек в начале файла: [САЙТ: региональная доска объявлений о стройматериалах, листинг вида /board/?page=N], [СЕЛЕКТОРЫ: карточка div.offer-card, заголовок h3.offer-title, цена span.price, город span.geo, ссылка a.offer-link], [ПАУЗА: 1,5 секунды между запросами], [ГЛУБИНА: 20 страниц]. Аргументы командной строки: url, max_pages, output. Сохранение — CSV или SQLite на выбор флагом. В консоль на каждой странице: её номер, сколько карточек разобрано, у скольких пусто обязательное поле.

Дай рабочий файл целиком и README рядом: что править под новый сайт по шагам и готовые блоки настроек под карточку товара, объявление и статью блога.

Отсечка. Тут модель обычно выдаёт каркас с soup.find('div', class_='item') и комментарием «замените под свой сайт» — такой шаблон не запускается ни разу. Селекторы бери из задания, они обязаны вытащить данные с первого прогона. Второе: не подставляй обход защит — капчу, подмену браузера, карусель прокси. Если раздел закрыт в robots.txt или контент рисуется только скриптом, шаблон обязан остановиться с внятным сообщением, а не «пробовать иначе».

Перед выдачей посчитай, сколько мест в файле придётся тронуть при переносе парсера на другой сайт. Вышло больше пяти — вынеси лишнее в блок настроек и пересчитай. Затем прогони по собственному коду один кусок HTML из примера настроек и покажи строкой, какая запись попадёт в CSV, и что произойдёт с карточкой, где цены нет.

Вторая по частоте задача — телеграм-бот. Здесь у моделей стойкая привычка отдавать красивый скелет с пометкой «остальное по аналогии», после которой файл не запускается. Промт для бота записи на услугу этот ход перекрывает и заодно требует показать, что произойдёт при двух одновременных запросах на один слот, — то самое место, где обычно и появляется вторая запись к одному мастеру на четырнадцать ноль-ноль.

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

Что за бизнес: [БИЗНЕС: массажный кабинет, три мастера, услуги 60 и 90 минут]
Как принимаем записи: [ПРАВИЛА: с 10 до 20, шаг 30 минут, на 14 дней вперёд, один мастер — один клиент в слот, за час до начала отменить нельзя]
Стек: [СТЕК: Python 3.11, aiogram 3.x, SQLite в файле base.db, запуск на VPS через systemd]
Что нужно администратору: [АДМИН: команда со списком записей на завтра, доступна только по моему id]

Функции бота:
1. `/start` — приветствие и кнопки услуг.
2. Выбор услуги → мастера → даты → времени, свободные слоты считаются из базы, занятые не показываются.
3. Подтверждение с итогом и запись в базу.
4. `/my` — свои записи, `/cancel` — отмена с проверкой правила про час.
5. Команда администратора со списком на завтра.

Отдай одним файлом, который можно скопировать и запустить. Токен и id администратора — из переменных
окружения, не в коде.

Отсечка. Не давай фрагменты с «# остальное по аналогии» — мне нужен файл целиком, иначе он не
запустится. Не храни состояние в глобальном словаре: при перезапуске записи потеряются, используй
базу. Не забудь про два одновременных запроса на один слот — покажи, как не допустить двойную запись.
Не оставляй токен в коде даже в примере.

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

Что ещё лежит в этой зоне:

• Телеграм-бот на n8n — если код писать не хочется вовсе: промт отдаёт схему нод с точными названиями из интерфейса, которую собирают мышкой. Рядом по теме — установка n8n на VPS.
• Парсер-конвейер под ключ — когда данные надо не только забрать, но и почистить, посчитать и положить в базу. Промт сначала требует структуру проекта не больше чем из семи файлов и только потом код, а отдельным пунктом — проверку, что повторный запуск не удвоит записи.
• Python-скрипт отчёта по выручке — тот, что каждое утро шлёт сумму за вчера в Telegram. Промт специально ловит счастливый путь: что делать, если файла нет, если за вчера ни одной продажи, если Telegram ответил не двухсоткой.
• Сайт-визитка одним промтом — единственный HTML-файл с 3D на three.js, который открывается в браузере без сборки. Больше про такие задачи — в статье промты для создания сайта.

Чужой код: прочитать то, что писали до вас

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

Важная деталь: просить надо не «объясни, что делает каждая строка» — это видно и так. Просить надо «зачем этот код существует». Промт ниже требует разобрать смысловые блоки, показать связи наружу — кеш, транзакции, поведение внешнего API — и назвать, что сломается при типичных изменениях. Последний пункт самый ценный: три вопроса к автору, ответы на которые из кода вывести нельзя в принципе.

Объясни чужой код так, как объясняют новому разработчику в команде: зачем он существует, а не что делает каждая строка.

Код (замени на свой):
[КОД: def sync_orders(since=None):
    since = since or cache.get('last_sync') or '2020-01-01'
    raw = api.fetch('/orders', updated_after=since, page_size=500)
    for chunk in chunks(raw, 100):
        with transaction.atomic():
            for o in chunk:
                Order.objects.update_or_create(ext_id=o['id'], defaults=map_order(o))
        cache.set('last_sync', chunk[-1]['updated_at'])
    return len(raw)]
Что я знаю о системе: [КОНТЕКСТ: интернет-магазин на Django, заказы приходят из внешней CRM, я в проекте второй день]

Что нужно:
1. Зачем этот код нужен бизнесу — один абзац, без терминов из самого кода.
2. Разбор по смысловым блокам, а не по строкам: что за что отвечает.
3. Скрытые связи: от чего код зависит снаружи — кеш, транзакции, поля в базе, поведение внешнего API.
4. Что сломается при типичных изменениях: если убрать транзакцию, если поменять размер чанка,
   если внешний API отдаст дубли.
5. Три вопроса, которые стоит задать автору, — такие, ответы на которые нельзя вывести из кода.

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

Проверка перед выдачей: убедись, что пункт 4 опирается на код, а не на общие рассуждения о Django —
для каждого сценария укажи строку, из которой следует последствие.

Дальше по масштабу задачи:

• Обзорный аудит всей кодовой базы — когда понять надо не файл, а проект целиком: карта модулей, дубли логики с путями к файлам, зоны, которые рискованно трогать.
• Расстановка type hints в legacy — первый шаг, после которого редактор начинает подсказывать, а не молчать.
• Миграция Python 2 на Python 3 — да, такой код ещё живёт, и обычно именно в той части системы, которую все обходят стороной.
• Код со скриншота в текст — для лекций и чужих экранов. Промт требует помечать «неразборчиво» вместо угадывания там, где не отличить единицу от строчной l.

Рефакторинг: поведение один в один

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

Поэтому главное требование в таком промте — не «сделай чище», а «сохрани поведение один в один». И второе: не чинить баги молча. Увидела модель по дороге ошибку — обязана вынести её отдельным блоком и спросить, чинить ли, а не поправить тихо, превратив рефакторинг в изменение поведения.

Отрефактори функцию ниже. Требования: поведение сохрани один в один, читаемость важнее краткости, имена переменных по смыслу, язык [ЯЗЫК: Python]. Магические числа вынеси в константы. Если видишь баг — не чини его молча: покажи отдельным блоком «НАЙДЕН БАГ» с примером входа, на котором он стреляет, и спроси, чинить ли. В конце дай список изменений в формате «было → стало → зачем», по одной строке на изменение, и предложи три тест-кейса, которые стоит покрыть в первую очередь: граничный, типовой и злой.

[КОД: вставьте функцию целиком, с импортами, которые она использует]

Для настоящего легаси — где функция называется calc, а параметры зовут u, t и d — нужен пошаговый заход: одно изменение за шаг, после каждого объяснение, почему поведение осталось прежним, и не больше шести шагов на всё.

• Рефакторинг легаси-функции пошагово — с тестами, которые доказывают эквивалентность старой и новой версии, включая края вроде «скидка больше цены».
• Рефакторинг по принципам clean code — когда с функцией всё в порядке, кроме того, что она делает три вещи сразу.

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

Промт: Рефакторинг легаси-модуля в Kimi: карта, план, код по шагам

Ты берёшь на поддержку чужой модуль. Работаем в два захода: сначала разбор текстом, потом код.

Модуль на [ЯЗЫК И ВЕРСИЯ: Python 3.11, Django 4.2], вставляю файл целиком: [КОД: вставь сюда содержимое файла от первого импорта до последней строки]. Что должно работать иначе: [ЗАДАЧА: повторный клик по кнопке «Оформить» не должен создавать второй заказ]. Рамки: [ОГРАНИЧЕНИЯ: публичный интерфейс менять нельзя, тестов в проекте нет, деплой раз в неделю].

Заход первый — без кода:
1. Карта модуля: какие сущности внутри, кто кого вызывает, где открывается и закрывается транзакция, какие функции дёргают снаружи.
2. Узкие места по одному: строка или диапазон строк — что именно ломается — при каком сценарии это замечает пользователь. Отдельно пометь те, из-за которых возникла моя задача.
3. План до 5 шагов. Каждый шаг — самостоятельный коммит, который можно выкатить отдельно: зачем он, что меняется, чем рискуем.
Дальше останавливаешься и ждёшь «ок».

Заход второй, после «ок» — по одному шагу за сообщение:
— полный код изменённых функций, без диффов и без «остальное без изменений»;
— публичные имена, сигнатуры и формат ответа сохраняешь; если шаг ломает их неизбежно — скажи прямо и предложи обходной путь;
— в конце шага строка «Проверить руками:» и 2–3 конкретные проверки: что запустить, что должно вернуться, как воспроизвести старый баг и убедиться, что он ушёл.

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

Правила игры: стиль и форматирование ради красоты не меняешь; новые зависимости — только через отдельный вопрос; функции, которых нет в файле, не выдумываешь; весь модуль одним куском не переписываешь.

Разбор заканчивай строкой «Что я не трогал и почему» — до 3 пунктов.

Открыть карточку: пример результата и разбор

Баг: от трейсбэка к причине, а не к try-except

Дежурный ответ нейросети на любое падение — обернуть в try-except и залогировать. Падение исчезнет. Отчёт станет неверным молча.

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

Отдельная история — баги, которые не воспроизводятся. Падает раз в несколько дней, только на ночном прогоне в 06:30, на локальной копии базы не повторяется ни разу. Совет «добавь логирование и дождись следующего раза» стоит здесь неделю ожидания. Промт ниже такие ответы отсекает заранее: годятся только версии, проверяемые на уже собранных данных, и каждая обязана объяснять оба факта сразу — почему падает не каждый день и почему не повторяется локально. Версию, которая объясняет один факт из двух, модель вычёркивает сама и вам не показывает.

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

Трейс из ночного лога: [ТРЕЙС:
Traceback (most recent call last):
  File "etl/daily_report.py", line 212, in build_daily
    row["revenue"] = totals[row["shop_id"]]
KeyError: 4117
]
Что вокруг: [КОД: totals собирает agg_totals() одним запросом с group by shop_id за вчерашний день; build_daily идёт по всем магазинам из справочника shops]
Когда воспроизводится: [КОГДА: раз в несколько дней, только на ночном прогоне в 06:30; на локальной копии базы не повторяется ни разу]
Что уже пробовал: [ПРОБОВАЛ: обернул в try/except и подставил ноль — итоги отчёта разъехались с бухгалтерией]

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

Отсечка. Падает раз в несколько дней, поэтому «добавь логирование и дождись следующего раза» — не ответ, это неделя ожидания: годятся только версии, проверяемые на уже собранных данных и на коде. Совет уровня «проверьте, существует ли ключ» тоже не годится — он верен для любого KeyError и не объясняет мой. Не переписывай функцию целиком и не проси прислать полный исходник: работай с тем, что дано, а чего не хватает, назови отдельной строкой как допущение.

Проверка. Каждая версия обязана объяснять оба факта разом: почему падает не каждый день и почему не воспроизводится локально. Версию, которая объясняет только один из двух, вычеркни сам и не показывай. Затем сверь список проверок с тем, что я уже пробовал: совпадений быть не должно.

• Разбор traceback Python — самый частый заход: есть трейсбэк, нужна минимальная правка без лекции о хорошем коде.
• Причина падения по стектрейсу и логам — три версии по убыванию вероятности, и к каждой проверка, дающая однозначный ответ «да» или «нет». Плюс пятый пункт, которого обычно нет нигде: что НЕ чинить — места, которые выглядят подозрительно, но к этому падению отношения не имеют.
• Профилирование медленного Python — здесь важна отсечка от советов вслепую: «используйте numpy» без опоры на cumtime — это угадывание. В примере карточки отчёт идёт 39 секунд при цели в пять, и промт требует посчитать ожидаемое время из чисел профиля, а не пообещать «станет намного быстрее».
• Разбор ошибки в n8n — с отдельным требованием не путать localhost внутри контейнера с localhost хост-машины. На этом спотыкаются все, кто поднял n8n в Docker.

Тесты: нейросеть усидчивее вас

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

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

Напиши unit-тесты для функции — такие, которые ловят реальные поломки, а не повышают процент покрытия.

Язык и фреймворк: [СТЕК: Python 3.11, pytest]
Функция (свою вставь вместо примера):
[КОД: def split_payment(total, parts, min_part=100):
    if parts <= 0:
        raise ValueError("parts must be positive")
    base = total // parts
    if base < min_part:
        parts = max(1, total // min_part)
        base = total // parts
    rest = total - base * parts
    return [base + (1 if i < rest else 0) for i in range(parts)]]
Что функция значит для бизнеса: [СМЫСЛ: разбивка суммы заказа на платежи, сумма частей обязана совпадать с исходной до копейки]

Что нужно:
1. Тесты на нормальный путь — не больше трёх, с понятными именами.
2. Тесты на края: ноль, единица, отрицательные значения, сумма меньше минимальной части, остаток
   от деления не нулевой.
3. Тесты на исключения: что именно должно упасть и с каким сообщением.
4. Один тест-инвариант: свойство, которое обязано держаться на любых входах (здесь — сумма частей
   равна total). Через `parametrize` — до 7 наборов.
5. Строкой: какие входы остались непокрытыми и почему это допустимо.

Отсечка. Не пиши тестов, которые повторяют реализацию: `assert split_payment(1000, 4) == [250]*4`
рядом с `assert base == total // parts` — это проверка кода самим кодом. Не мокай то, что можно
вызвать напрямую. Не собирай двадцать однотипных случаев вместо одного `parametrize`. Если из кода
видно поведение, которое противоречит смыслу из поля СМЫСЛ, — напиши это отдельной строкой
до тестов, а не подгоняй тест под текущий баг.

Проверка перед выдачей: убедись, что инвариант из пункта 4 падает, если в функции заменить
`rest` на ноль. Если не падает — тест бесполезен, переделай.

• Тесты на pytest одним файлом — когда нужен файл, запускающийся командой pytest без правок и дописывания. Не больше двенадцати тестов, каждое ожидаемое число пересчитано по формуле из кода, а не взято на глаз.
• TDD-цикл red-green-refactor — до пяти итераций, в каждой красный тест с точным сообщением о падении, минимальный зелёный код и объяснение, почему следующий тест именно такой.
• E2E-тест Playwright по сценарию — логин, корзина, оплата картой: описали шагами по-русски, получили одну спецификацию .spec.ts.
• Ревью и тесты одним заходом — сначала баги и граничные случаи, потом тесты ровно на них, а в конце список того, что тестами не покрыть, и почему.

Ревью и безопасность: злой коллега по вызову

Самое честное применение нейросети в разработке — прогнать через неё свой код перед коммитом, пока никто не видит. Не ради галочки, а ради вопроса «а что будет, если сюда придёт ноль».

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

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

Что за код: [КОД: функция расчёта скидки в интернет-магазине, Python, вызывается из корзины и из админки]
Где будет работать: [УСЛОВИЯ: боевой сервер, 50 заказов в минуту в пик, деньги клиента]
Что я сам подозреваю: [СОМНЕНИЯ: кажется, при нескольких скидках подряд считается неверно, но воспроизвести не смог]
Чего я НЕ хочу слышать: [БЕЗ: советов переписать на другом фреймворке и добавить типизацию везде]

Разбери в таком порядке:
1. Ломается ли: ошибки, из-за которых код даст неверный результат или упадёт. Для каждой — вход,
   на котором это видно, и правка.
2. Опасно ли: гонки, потеря денег или данных, доступ не туда, необработанные исключения на границе.
3. Подтверди или опровергни мои сомнения из поля СОМНЕНИЯ — прямым разбором, а не «возможно».
4. Что стоит поправить сейчас, пока код в руках, и что можно оставить на потом. Разделяй явно.
5. Один-два теста, которые стоит написать до коммита, — на то, что реально может отвалиться.

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

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

• Ревью пул-реквеста перед мерджем — с вердиктом одним словом: мерджить, править, переделывать. И с требованием к каждому критическому пункту приложить сценарий из трёх шагов, при котором проблема проявится; не складывается сценарий — пункт не критический.
• Дотошное ревью по пяти уровням приоритета — от блокирующего мерж до идей на обсуждение, с оценкой кода и тремя советами автору.
• Аудит по OWASP Top 10 — по каждой найденной дыре категория, строка, сценарий эксплуатации и безопасная альтернатива кодом. Если уязвимостей нет, промт прямо требует так и сказать, а не искать их через силу.

Про безопасность есть большая оговорка, и она в следующем разделе. Коротко: шаблонную инъекцию модель находит, дыру в вашей схеме прав — нет.

Документация, схемы и ТЗ: то, что вечно откладывают

Docstring, README и блок-схема — работа, которая никогда не бывает срочной и поэтому не делается вообще. У нейросети тут лучшее соотношение пользы к риску: ошибка в докстринге не уронит прод, а править текст проще, чем код.

Схемы — отдельный сюжет. Модель отдаёт код Mermaid, вы вставляете его в mermaid.live или прямо в вики — и картинка появляется сама, без графического редактора. Промт на ER-диаграмму требует не больше восьми сущностей и прогона каждого заданного сценария по связям: если сценарию нужна таблица, которой в схеме нет, модель обязана сказать об этом вслух, а не нарисовать красивое.

Спроектируй схему базы данных и отдай её кодом Mermaid erDiagram.

Что за система: [ОБЛАСТЬ: запись клиентов в клинику — врачи, кабинеты, приёмы, оплата]
Сценарии, которые база обязана выдержать: [СЦЕНАРИИ: пациент переносит приём на другого врача; приём отменяют и деньги возвращают частично; один врач принимает в двух кабинетах в разные дни]
Ограничения: [ОГРАНИЧЕНИЯ: PostgreSQL, историю изменения цен хранить не нужно]

Что нужно:
1. Код в блоке mermaid: сущности с полями и типами, помеченные PK и FK, связи с кардинальностью и подписью-глаголом.
2. Не больше восьми сущностей. Всё, что не участвует в перечисленных сценариях, в схему не берём.
3. Под кодом — по строке на сущность: что она хранит и почему это отдельная таблица, а не поле в соседней.
4. Три вопроса, ответы на которые изменят схему, — с указанием, что именно изменится: «если приём ведут двое, связь врач–приём становится многие-ко-многим и появляется таблица appointment_doctor».

Отсечка. Не выдавай схему, в которой заданные сценарии не проходят: прогони каждый по связям и скажи прямо, если сценарию нужна таблица, которой в схеме нет. Не превращай справочники в текстовые поля — город, статус, специальность живут отдельной сущностью или enum, а не строкой. Не расставляй created_at и updated_at во все таблицы подряд, пока не объяснил, зачем они в этой.

Проверка перед выдачей: убедись, что код отрисуется, — подписи связей в кавычках, у каждой сущности есть PK, у каждого FK есть цель. Схема, которая не открывается в mermaid.live, бесполезна.

• Docstring в Google-стиле по сигнатуре — со сверкой имён в Args против сигнатуры по буквам и с примером в формате doctest, а не с многоточием вместо вывода.
• README по дереву репозитория — с отсечкой от выдуманных бейджей, раздела Roadmap и папки config, которой в дереве нет.
• Блок-схема процесса по описанию и блок-схема по коду функции. Вторая рисует, как код работает сейчас, а не как задумывалось, и проверяет себя арифметикой: сколько в коде if-ов и циклов, столько ромбов на схеме; сколько return-ов, столько конечных узлов. Больше о таких задачах — нейросеть для создания схем.
• Разбор архитектуры микросервисов — где граница проведена по технической схожести вместо бизнес-возможности, и честный вопрос: не лучше ли здесь модульный монолит.
• Дизайн REST API — эндпоинты, статус-коды, версионирование с обоснованием выбора, пример успешного и ошибочного ответа.
• TypeScript-типы из JSON-ответа — с требованием различать null, undefined и отсутствие поля, а не выводить тип из единственного примера.
• ТЗ для разработчика по задаче заказчика — со сценариями, критериями приёмки и разделом «чего не делаем в этой итерации». Подробнее — как написать ТЗ через Claude.
• Объяснить технический термин продакту — когда нужно не спорить, а объяснить, почему идемпотентные ключи стоят спринта, и закончить вопросом, ответом на который будет число или дата.

SQL, Docker и CI: четыре промта на всё остальное

Оптимизация SQL — задача, где нейросеть особенно любит отвечать «добавьте индекс на нужные поля». Это не совет, это его имитация: без имён колонок и без их порядка выполнить нечего. Промт ниже требует CREATE INDEX целиком с объяснением, почему порядок колонок такой, и главное — запрос сверки, которым вы убедитесь, что результат не изменился. Переписанный запрос, возвращающий другие строки, — это не оптимизация, а другой ответ.

Разбери медленный SQL-запрос и дай переписанную версию, которая возвращает ТОТ ЖЕ результат.

СУБД: [СУБД: PostgreSQL 16]
Запрос (замени на свой, этот рабочий — с ним промпт запускается как есть):
[SQL: SELECT c.id, c.name, (SELECT COUNT(*) FROM orders o WHERE o.client_id = c.id) AS cnt FROM clients c LEFT JOIN orders o2 ON o2.client_id = c.id WHERE c.city = 'Москва' AND o2.created_at > now() - interval '30 days' GROUP BY c.id, c.name ORDER BY cnt DESC LIMIT 50]
План выполнения:
[EXPLAIN: Seq Scan on clients (cost=0.00..18234.00 rows=412 width=36); SubPlan 1 -> Aggregate; Seq Scan on orders (cost=0.00..44.12 rows=9 width=0)]
Размер таблиц: [ОБЪЁМ: clients 400 тыс. строк, orders 18 млн строк, растёт на 40 тыс. в день]

Что нужно:
1. Что именно делает запрос медленным — по строкам плана, а не по общим соображениям.
2. Индексы: `CREATE INDEX` целиком, с точным порядком колонок, и почему порядок такой.
3. Переписанный запрос.
4. Чем новый план будет отличаться: какие операции уйдут, какие останутся.
5. Как проверить, что результат не изменился — конкретный запрос сверки на своих данных.

Отсечка. Не пиши «добавьте индекс на нужные поля» — нужны имена колонок и порядок, иначе совет
бесполезен. Не меняй семантику: если в исходнике LEFT JOIN, результат с INNER JOIN — это другой
ответ, а не оптимизация. Не предлагай сменить СУБД, добавить кеш или денормализовать таблицу,
пока не исчерпаны индексы и переписывание самого запроса. Если данных в плане не хватает, скажи,
какую строку EXPLAIN нужно доснять, и не угадывай.

Проверка перед выдачей: сравни свой запрос с исходным на трёх случаях — у клиента нет заказов,
у клиента заказы только старше 30 дней, у клиента 500 заказов. Если хотя бы в одном наборы строк
расходятся, исправь и напиши, что расходилось.

• SQL-запрос из вопроса на русском — для тех, кто пишет запросы редко. Промт сначала пересказывает задачу своими словами, чтобы вы подтвердили, что поняли одинаково, и отдельным пунктом показывает, где запрос может обмануть: дубли после join, NULL в суммах, границы месяцев при переводе часового пояса.
• Многостадийный Dockerfile — с отсечкой, которая экономит вечер: не тащить alpine ради размера, если стек на Python с бинарными зависимостями, потому что musl ломает колёса numpy и psycopg, а сборка падает на pandas.
• GitHub Actions workflow — с прямым запретом выдумывать названия и версии действий: не уверена модель, что action существует под таким именем, — заменяет шаг обычной командой.

Красная зона: шесть мест, где нейросеть врёт особенно убедительно

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

1. Бизнес-логика вашей компании. Скидка, которая у вас не суммируется с промокодом, потому что так решили после убыточного ноября, из кода не выводится. Модель напишет математически безупречный расчёт и будет права ровно нигде.
2. Легаси-договорённости. Флаг, который выглядит мёртвым, а на нём висит квартальная выгрузка в бухгалтерию. Ни один промт этого не покажет — такое знание живёт в людях. Поэтому в промте на разбор чужого кода последним пунктом и стоят три вопроса к автору: они ровно про то, что из текста не выводится.
3. Безопасность за пределами шаблонов. Инъекцию в склеенной SQL-строке модель находит уверенно. А дыру в вашей схеме прав — где менеджер видит чужие заказы, потому что фильтр по компании стоит в одном эндпоинте из трёх, — не найдёт: для этого надо знать, кто у вас кем является.
4. Несуществующие библиотеки, флаги и версии. Самая коварная ошибка, потому что выглядит безобиднее всех. Модель напишет импорт пакета, которого нет в реестре, или шаг workflow с именем действия, которого никто не публиковал. Отсюда правило: любое незнакомое имя из ответа проверяется в реестре пакетов, а не на глаз.
5. Архитектурные компромиссы. Модель не знает, что у вас три бэкендера без выделенного devops, деплой раз в неделю и тестов почти нет. Она предложит решение, красивое в вакууме. Ровно поэтому в промте на архитектуру команда и нагрузка вписываются отдельными полями — без них разбор сползает в пересказ статьи про микросервисы.
6. Производительность без замера. «Добавьте кеширование», «перепишите на asyncio» — фразы, которые звучат солидно и не опираются ни на что. Без профиля модель угадывает. С профилем считает: вот строка плана, вот cumtime, вот ожидаемое время после правки.

И отдельно — то, чего делать не стоит вовсе. Промт на парсер у нас намеренно устроен так, что при закрытом в robots.txt разделе шаблон останавливается и говорит об этом, а не подбирает обход. Это не ограничение модели, это граница, за которой начинается чужой сервер и чужие правила.

Проверка — часть метода, а не оговорка в конце

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

Порядок, который экономит больше всего времени:

1. Сначала импорты. Убедитесь, что все пакеты из ответа существуют и ставятся. Тридцать секунд — и отсеивается самая частая причина, по которой «код не работает».
2. Потом запуск на пустоте. Прогоните на пустом входе, на одной строке и на строке со сломанным полем. Модель почти всегда пишет счастливый путь; ветки «файла нет», «за вчера ни одной продажи», «сервис ответил не двухсоткой» приходится требовать отдельно.
3. Потом сверка чисел руками. Возьмите три строки и посчитайте результат на калькуляторе. Средний чек — это выручка, делённая на число уникальных чеков, а не на количество позиций; такую подмену модель делает регулярно, и код при ней не падает — он просто отдаёт неверное число.
4. И только потом — граница вашего проекта. Последний вопрос к коду не «работает ли он», а «согласуется ли он с тем, как у нас принято». Здесь модель вам не помощник, и это нормально.

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

Какая нейросеть под какую задачу

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

Из России без VPN работают DeepSeek, Kimi, Qwen, YandexGPT и GigaChat — для многих это и есть главный критерий выбора. Промты на этой странице разложены по тем сетям, в которых мы их прогоняли, но переносятся между сетями почти без правок: это обычный текст на русском, без флагов и служебного синтаксиса. Нет под рукой знакомой сети — берите промт и вставляйте в ту, что открывается.

Про длину контекста. У флагманских моделей 2026 года окно около миллиона токенов: модуль на пару тысяч строк влезает в одно сообщение целиком, и это давно не проблема. Проблема в другом — большой контекст не означает понимания. Модель прочитает весь ваш файл и всё равно не узнает, почему в нём есть строка, которую нельзя трогать. Подробнее по отдельным сетям — ChatGPT против DeepSeek и что умеет Kimi.

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

Как переписать любой промпт с этой страницы под свой проект

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

• Стек с версиями. Не «Python», а «Python 3.11, Django 4.2». Не «тесты», а «pytest». Версия библиотеки решает больше, чем кажется: между мажорными релизами переименовывают половину методов.
• Рамки. Что менять нельзя: публичный интерфейс, формат ответа, имена полей в базе. Без этой строки модель улучшит ровно то, на что завязаны три соседних сервиса.
• Условия эксплуатации. Сколько данных, сколько запросов в пик, где крутится, как часто деплой. Промт на ревью без строки «боевой сервер, деньги клиента» и промт с ней дают разные списки замечаний в разном порядке.
• Чего вы слышать не хотите. Самое недооценённое поле из всех. «Без советов переписать на другом фреймворке», «без предложений добавить типизацию везде» — и ответ становится короче ровно на то, что вы всё равно пролистали бы.

Менять надо значение после двоеточия, сама квадратная скобка ни на что не влияет — это просто метка, чтобы вы не пропустили место. Вместо «[СТЕК: Python 3.11, FastAPI]» пишете «[СТЕК: Node 20, Express]», и промпт готов к работе. Если под рукой нет своего кода, оставьте наш пример: промты собраны так, чтобы запускаться без единой правки и показать формат ответа.

FAQ

Какой промт заставит нейросеть выдать рабочий код с первого раза?

Тот, в котором есть четыре вещи: язык с версией и библиотеками, входные данные в натуральном виде (разделитель, кодировка, названия колонок), требование отдать файл целиком без пометок «остальное по аналогии» и отсечка — чего делать нельзя. Запрос «напиши парсер на Python» не содержит ничего из этого, поэтому и возвращает каркас с заглушками вместо кода.

Чем промпт для кода отличается от обычного вопроса в чат?

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

Можно ли доверять коду, который написала нейросеть?

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

Что делать, если нейросеть придумала несуществующую библиотеку?

Проверить имя в реестре пакетов и вернуть модели факт: «пакета с таким именем нет, перепиши на стандартной библиотеке». Это работает заметно лучше, чем просьба «проверь ещё раз», — на неё модель часто извиняется и придумывает второе несуществующее имя. Ошибка настолько частая, что в наших промтах на CI и README стоит прямой запрет выдумывать названия и версии.

Какую нейросеть выбрать для кода, если ChatGPT и Claude не открываются?

Из России без VPN доступны DeepSeek, Kimi, Qwen, YandexGPT и GigaChat. Промты с этой страницы написаны по-русски, без служебного синтаксиса и флагов, поэтому переносятся между сетями почти без правок: скопировали и вставили в ту, что работает. Сравнения по отдельным сетям — в разборах ChatGPT против DeepSeek и в обзоре Kimi.