Глава 70. Промт-инжиниринг как новый навык

Эта глава раскроет, почему старые ритуалы промптинга больше не работают с reasoning-моделями и какой “новый протокол” общения действительно дает результат, который можно сразу компилировать, тестировать и внедрять. Здесь обнаружите, как заменить «театр ролей» на точное ТЗ — и сократить количество итераций в разы.

4 опоры современного промпта (контекст, цель, требования, ограничения), 3 типа запросов (A/B/C) и техники уровня профи: декомпозиция 1 промпт = 50–200 строк, «Покажи–Повтори–Расширь», явный запрет deprecated API.

Не пропустите: после этой главы станет очевидно, почему “просто попросить код” — это путь к техдолгу.

И да — чтобы сразу повторить всё на практике: по ссылке ниже доступен архив со всеми исходниками промптов (готовыми к использованию) и 16 бесплатных глав книги.

Самопроверка по главе

Почему reasoning-модели больше не нуждаются в подсказках вроде «думай шаг за шагом» или ролевом промптинге?Ответ
Правильный ответ: Reasoning-модели автоматически строят внутренние рассуждения и обладают встроенной экспертизой, поэтому такие подсказки не добавляют знаний, а лишь расходуют токены и могут даже мешать работе модели.
Какие четыре опоры составляют анатомию современного промпта для reasoning-моделей?Ответ
Правильный ответ: Технологический контекст (стек технологий), ясная и однозначная цель, технические требования (потокобезопасность, производительность) и ограничения (рамки качества результата).
Почему спецификационный промпт типа A требует больше времени на формулировку, но при этом считается более эффективным?Ответ
Правильный ответ: Детальная спецификация с контекстом, целью, требованиями и примерами API дает предсказуемый результат, который можно интегрировать в проект почти без правок с первой попытки.
В каких ситуациях следует использовать промпт типа B (контекстно-диалоговый) вместо типа A?Ответ
Правильный ответ: Когда нужно доработать существующий проект: рефакторинг, улучшение архитектуры разросшихся классов, точечные доработки и итеративная разработка.
Что будет, если при отладке многопоточного кода не предоставить модели полный контекст ошибки (вывод Valgrind, стеки вызовов, журналы Qt)?Ответ
Правильный ответ: Анализ будет менее точным, модель не сможет выявить конкретные причины утечек памяти или гонок потоков, и решение проблемы займет больше времени.
Почему техника декомпозиции предполагает разбивку задачи на промпты по 50-200 строк кода каждый?Ответ
Правильный ответ: Один промпт = одна четкая цель обеспечивает высокое качество каждого компонента, сохраняет контроль над архитектурой и упрощает тестирование, избегая потери фокуса при слишком объемных задачах.
Как техника «Покажи – Повтори – Расширь» помогает избежать повторения инструкций при создании серии похожих компонентов?Ответ
Правильный ответ: Сначала показываете эталонный компонент, затем определяете общие правила, после чего модель генерирует серию компонентов по этому шаблону без необходимости повторять детальные инструкции для каждого.
Зачем в промпте явно запрещать использование устаревших API вроде QDesktopWidget или QApplication::desktop()?Ответ
Правильный ответ: ИИ может использовать устаревшие или удаленные API из старых версий Qt, обнаруженные в обучающих данных; явный запрет направляет модель на использование современных эквивалентов вроде QGuiApplication::screens().
Почему ограничительная техника (лимиты на размер файла, сложность, использование указателей) не мешает ИИ, а улучшает качество кода?Ответ
Правильный ответ: Ограничения направляют модель к созданию чистого, эффективного и качественного кода, задавая четкие рамки и предотвращая появление раздутых, небезопасных или неоптимальных решений.
Что произойдет, если систематически делегировать задачи ИИ без анализа сгенерированного кода?Ответ
Правильный ответ: Произойдет деградация инженерного мышления: разработчик потеряет способность проектировать архитектуру, отлаживать сложные проблемы и взвешивать инженерные компромиссы.
Какие юридические риски возникают при использовании кода, сгенерированного ИИ, в коммерческих проектах?Ответ
Правильный ответ: Код может оказаться похожим на проприетарные решения с несовместимыми лицензиями (например, GPL), что может повлечь судебные иски, требования раскрыть исходники или блокировку продукта.
Почему использование облачных ИИ-сервисов создает риски утечки интеллектуальной собственности даже при заявлениях о неиспользовании данных для дообучения?Ответ
Правильный ответ: Техническая возможность утечки остается через логи, кеши и промежуточные хранилища; корпоративные секреты, клиентская информация и уникальные решения оказываются за пределами вашего контроля.
Для каких задач рефакторинга локальные модели (LM Studio, Ollama) требуют обязательного использования reasoning-моделей, а не обычных?Ответ
Правильный ответ: Для любых задач рефакторинга кода, поскольку обычные модели не справляются должным образом — они не могут провести глубокий анализ кода и его структуры, в отличие от reasoning-моделей типа GPT-OSS, DeepSeek-R1 или QwQ.
Что означает принцип «ИИ-ассистенты — это усилители возможностей разработчика, а не замена»?Ответ
Правильный ответ: ИИ берет на себя рутину и генерирует шаблоны, но архитектурные решения, критический анализ, понимание последствий и ответственность за результат остаются за человеком-инженером.

Практические задания

Простой уровень

Библиотека промптов для рефакторинга
Создайте персональную библиотеку из 5 промптов для типичных задач рефакторинга вашего Qt-проекта. Выберите реальные проблемные участки кода (разросшиеся классы, сложная вложенная логика, устаревшие API) и адаптируйте шаблоны из главы под конкретный технологический стек вашего проекта. Протестируйте каждый промпт с reasoning-моделью и зафиксируйте результаты.
Подсказки: Начните с промптов типа B из раздела «Промпты для рефакторинга». Обязательно укажите точный стек (версии Qt, C++, компилятор). Сохраните успешные промпты в отдельный файл с пометками о контексте использования. Для тестирования используйте Claude Sonnet 4.5 или ChatGPT (GPT-4). Сравните результаты до и после рефакторинга: количество строк, цикломатическую сложность, читаемость.

Средний уровень

Автоматизированное ревью с детекцией проблем
Разработайте систему автоматизированного code review на основе ИИ для вашего Qt-проекта. Создайте набор из 3-4 специализированных промптов типа C (аналитических): один для проверки потокобезопасности, второй для поиска утечек памяти, третий для граничных случаев и четвертый для соблюдения Qt best practices. Интегрируйте эти промпты в процесс ревью через скрипт или CI/CD pipeline, который автоматически проверяет критичные участки кода перед коммитом.
Подсказки: Используйте промпты из раздела «Промпты для ревью кода». Для автоматизации можно создать bash/Python-скрипт, который отправляет код в API Claude или ChatGPT. Обязательно предоставляйте полный контекст: вывод Valgrind, sanitizer’ов, логи Qt. Настройте QT_LOGGING_RULES и QT_DEBUG_PLUGINS для детальной диагностики. Результаты ревью сохраняйте в структурированном формате (JSON/Markdown) для анализа паттернов ошибок.

Сложный уровень

Миграционный фреймворк Qt5→Qt6 с ИИ
Создайте полноценный фреймворк для автоматизированной миграции Qt5-проекта на Qt6 с использованием reasoning-моделей. Фреймворк должен: (1) анализировать кодовую базу и выявлять все несовместимости; (2) генерировать промпты типа A для портирования модулей; (3) автоматически применять изменения с сохранением резервных копий; (4) конвертировать .pro в CMakeLists.txt; (5) генерировать unit-тесты для проверки эквивалентности поведения до и после миграции; (6) создавать отчет о миграции с детализацией всех изменений. Протестируйте на реальном Qt5-проекте средней сложности (5000+ строк).
Подсказки: Начните с промптов из раздела «Промпты для портирования». Используйте техники декомпозиции и «Покажи-Повтори-Расширь» для обработки больших проектов. Для автоматизации создайте Python-инструмент с использованием API Claude/ChatGPT. Критично важно: перед применением изменений создавайте git-ветку для отката. Генерируйте тесты с помощью промптов типа A из раздела тестирования. Используйте QTest::qCompare для проверки эквивалентности. Документируйте все архитектурные решения и известные ограничения. Помните о юридических рисках — проверяйте лицензионную совместимость сгенерированного кода.

💬 Присоединяйтесь к обсуждению!

Уже успели протестировать reasoning-модели для рефакторинга? Столкнулись с неожиданными результатами при портировании Qt5 на Qt6?

Поделитесь своими промптами, которые дали выдающиеся результаты, расскажите о подводных камнях работы с ИИ-ассистентами в продакшене, или задайте вопросы о техниках эффективного взаимодействия с Claude и ChatGPT!

🎯 Обсудим вместе: Как вы балансируете между скоростью разработки с ИИ и сохранением инженерного мышления? Какие меры безопасности применяете при работе с облачными моделями?

Leave a Reply

Your email address will not be published. Required fields are marked *