GPT-4 уже пишет ваш код. Вот как заставить его делать это без глупых ошибок
Признайтесь, вы ведь тоже прошли этот путь. Сначала — детский восторг: «Вау, он за секунды накодил то, на что у меня ушёл бы час!». Потом — лёгкое разочарование: «Стоп, а почему этот метод считается устаревшим?». И наконец — холодный пот: «Чёрт, я же чуть не закоммитил этот код с потенциальной уязвимостью!».
Я прошёл через все эти стадии. GPT-4 — это не волшебная палочка, которая сделает всю работу за вас. Это скорее невероятно быстрый, но не слишком сообразительный стажёр. Его главный плюс — скорость и знание тысяч шаблонов. Главный минус — полное отсутствие настоящего понимания, контекста вашего проекта и, что важно, ответственности.
Давайте забудем про магию и поговорим об инженерии. О том, как я научился превращать GPT-4 из источника опечаток и багов в предсказуемого и эффективного помощника. Помощника, который не думает сам, но идеально выполняет чёткие инструкции.
Так почему же он ошибается?
Чтобы научиться избегать ошибок, нужно понять, откуда они берутся. А причины — системные.
Иллюзия знания. Модель обучали на гигантских объёмах кода, включая старые форумы, примеры с ошибками и противоречивые мануалы. Она не «понимает», что var в JavaScript давно не в ходу. Она просто знает, что это слово часто встречается в связке с JS.
Ноль контекста. GPT-4 не видит структуру вашего проекта, ваши code style conventions, ваши внутренние библиотеки. Он генерирует некий «усреднённый код для всех».
Мыслит шаблонами. Он блестяще справляется с типовыми задачами («напиши функцию для парсинга JSON»). Но стоит задаче выйти за рамки шаблона, модель начинает «выдумывать» — генерировать код, который выглядит правдоподобно, но не работает или содержит скрытые баги.
Игнорирует «неочевидное». Безопасность, оптимизация, обработка крайних случаев — всё это обычно не прописано в нашем промпте, а значит, остаётся и за бортом сгенерированного решения.
Суть проблемы: Мы ошибаемся, пытаясь общаться с GPT-4 как с коллегой-человеком. На самом деле, он — инструмент, и ему нужно давать чёткие, детальные инструкции.
Инженерия промптов — это не магия, а искусство составления ТЗ
Вмерасплывчатых просьб, я начал писать для модели техническое задание. Мой промпт должен быть настолько полным, чтобы его невозможно было понять неправильно.
Вот как я просил раньше (и получал проблемный код):
«Напиши функцию для подключения к PostgreSQL».
А вот что GPT-4 в ответ мог нагенерировать:
Устаревший драйвер или синтаксис.
Пароль, жёстко зашитый в код.
Соединение, которое не закрывается.
Полное игнорирование возможных ошибок.
Теперь я формулирую запрос как взрослый инженер:
Напиши функцию на Python для подключения к PostgreSQL. Используй актуальную библиотеку `psycopg2`. Жёсткие требования: 1. Применяй `psycopg2.connect` внутри контекстного менеджера (`with`). 2. Все параметры подключения (хост, БД, пользователь, пароль) должны передаваться в функцию как аргументы. Никакого хардкода! 3. Убедись, что соединение гарантированно закрывается, даже если возникла ошибка. 4. Обязательно добавь обработку исключений `psycopg2.OperationalError` с выводом понятного сообщения. 5. Функция должна возвращать объект соединения или `None` в случае неудачи. Покажи пример вызова этой функции.
Чувствуете разницу? Второй промпт — это не просьба, а инструкция. Он закрывает большинство путей к классическим ошибкам.
Стратегия «Шерифа»: Никакого доверия, только проверка
Самый опасный миф — что GPT-4 можно доверять. Я выработал железное правило: всё, что сгенерировано, должно быть проверено. Вот моя тактика:
Статический анализ — ваш лучший друг. Перед тем как даже запустить код, я прогоняю его через линтеры (ESLint, Pylint, RuboCop). Они моментально отлавливают 80% стилевых и простых логических косяков.
Пишите тесты для сгенерированного кода. Это кажется нелогичным, но это мощнейшая практика. Вы даёте GPT-4 задачу, он генерирует код, а вы пишете к нему юнит-тесты, особенно на краевые случаи. Если тесты не проходят — вы знаете, что править.
Код-ревью как для живого коллеги. Я читаю код от GPT-4 так же придирчиво, как и пул-реквесты джуниора. Я ищу утечки памяти, проблемы с безопасностью (инъекции, неправильная валидация), сомнительные архитектурные решения.
Пример из жизни: Я попросил сгенерировать SQL-запрос. Модель выдала рабочую, но уязвимую к SQL-инъекциям строку. Линтер сразу указал на проблему. После этого я добавил в промпт уточнение: «Используй только параметризованные запросы».
Вы — архитектор, GPT-4 — строитель
Ключ к успеху — правильное распределение ролей.
Вы думаете что делать. Вы держите в голове общую архитектуру, бизнес-логику, требования к безопасности и производительности. Вы разбиваете большую задачу на мелкие, понятные модули.
GPT-4 думает как сделать. Его задача — написать конкретную функцию по вашему ТЗ, реализовать алгоритм, создать шаблон HTML-разметки, написать boilerplate-код для конфигурации.
Нельзя: «Создай мне интернет-магазин».
Можно (последовательно):
«Сгенерируй ERD-диаграмму для БД интернет-магазина с товарами, категориями, пользователями и заказами».
«Напиши SQL-скрипт для создания этих таблиц в PostgreSQL».
«Создай Express.js-роуты для REST API товаров (GET /products, GET /products/:id)».
«Напиши модель Product на Node.js с использованием Sequelize».
Резюме: Ваш новый рабочий процесс
Вот алгоритм, который позволит вам спать спокойно, используя GPT-4:
Декомпозируйте задачу. Разбейте её на мелкие, атомарные части.
Пишите детальные промпты. Представьте, что пишете ТЗ для джуниора, который склонен делать именно то, что ему сказано, и не более.
Генерируйте код небольшими порциями. Не целый модуль, а одну функцию, один класс, один метод.
Проверяйте ВСЁ. Линтеры, тесты, внимательный код-ревью. Никаких исключений.
Рефакторите и интегрируйте. Вставьте проверенный код в свою кодобазу, приведите к своим стандартам.
GPT-4 — это не конец нашей профессии. Это начало новой эры, где рутина и шаблонная работа уходят на второй план, а ценность инженерного мышления, критического анализа и архитектурных решений взлетает до небес.
Источник: habr.com
