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

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

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

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

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

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

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

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

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

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

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

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

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

Парсер — самый частый запрос из этой зоны. Промт ниже собран так, чтобы шаблон переносился на новый сайт правкой одного блока настроек, а не двадцати мест по файлу; модель прямо просят посчитать, сколько мест придётся тронуть при переносе, и вынести лишнее в настройки. Отдельно в нём прописан отказ от обхода защит: если раздел закрыт в 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 и ИИ-агенты в n8n.
• Парсер-конвейер под ключ — когда данные надо не только забрать, но и почистить, посчитать и положить в базу. Промт сначала требует структуру проекта не больше чем из семи файлов и только потом код, а отдельным пунктом — проверку, что повторный запуск не удвоит записи.
• Python-скрипт отчёта по выручке — тот, что каждое утро шлёт сумму за вчера в Telegram. Промт специально ловит счастливый путь: что делать, если файла нет, если за вчера ни одной продажи, если Telegram ответил не двухсоткой.
• Сайт-визитка одним промтом — единственный HTML-файл с 3D на three.js, который открывается в браузере без сборки. Больше про такие задачи — в статье промты для создания сайта. Тем же приёмом нейросеть собирает и браузерную игру: две такие, от DeepSeek, запускаются прямо в статье промт для создания игры.

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

Отдельная категория боли: вы вышли в проект, а в проекте лежит модуль на полторы тысячи строк, который писал человек, уволившийся в марте. Комментарии в нём есть — ровно к тем строкам, которые понятны и без комментариев. Наверху висит 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]. Магические числа вынеси в константы. Если видишь баг — не чини его молча: покажи отдельным блоком «НАЙДЕН БАГ» с примером входа, на котором он стреляет, и спроси, чинить ли. В конце дай список изменений в формате «было → стало → зачем», по одной строке на изменение, и предложи три тест-кейса, которые стоит покрыть в первую очередь: граничный, типовой и злой.

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

Пока своей функции нет, для пробного запуска возьми пример ниже и покажи на нём формат ответа. Когда в поле КОД стоит настоящий код, пример не трогай.

def itog(summa, skidka, tip):
    if tip == "procent":
        itogo = summa - summa * skidka / 100
    else:
        itogo = summa - skidka
    if itogo < 0:
        itogo = 0
    return round(itogo * 1.2)

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

Для настоящего легаси — где функция называется 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.