Як формулювати запити для ChatGPT для програмування

Формулюйте запити до ChatGPT для програмування, описуючи інженерне рішення, а не лише код, який хочете отримати. Надайте відповідний контекст коду або репозиторію, поведінку, яку треба зберегти, конкретний результат і спосіб перевірити результат.

«Напишіть функцію, яка виконує X» може бути достатньо для невеликої утиліти. Цього недостатньо, коли зміна зачіпає поведінку користувача, спільний контракт або виробничу систему.

Перш ніж просити код, сформулюйте чотири речі:

• Що існує зараз: відповідний компонент, функція, API або збій.
• Що має змінитися: видимий для користувача або системи результат.
• Що не повинно змінитися: сумісність, продуктивність, доступність, контракти або публічні API.
• Як це перевірити: тести, кроки відтворення, перевірки типів або ручні критерії прийняття.

Якщо ви використовуєте довготривалий робочий простір ChatGPT, тримайте разом архітектурні нотатки, вимоги та відповідні файли. ChatGPT Projects може впорядковувати чати, довідкові файли та інструкції для конкретного проєкту; перед завантаженням вихідних матеріалів перевірте свій поточний план і елементи керування робочим простором.

Уникайте такого запиту:

Створіть компонент для завантаження файлів.

Він не визначає відповідальність, обробку помилок, обмеження файлів, доступність чи контракт із навколишнім інтерфейсом.

Натомість використовуйте обмежений запит:

У нас є сторінка налаштувань React, яка вже керує надсиланням форми та
повідомленнями про помилки. Додайте завантажувач файлів до наявної форми.

Результат: Користувач може вибрати один PNG або JPEG розміром до 5 MB, бачити
назву вибраного файлу, видалити його до надсилання та отримати наявне локалізоване
повідомлення про помилку для неприпустимих файлів.

Обмеження: Не додавайте нову бібліотеку стану, не створюйте кінцеву точку для завантаження
та залиште поточний обробник надсилання єдиним власником стану форми.

Поверніть найменший набір змінених файлів, поясніть кожну зміну та додайте
тести для неприпустимого типу, обмеження розміру, видалення й успішного вибору.

Цей запит робить компонент меншим, оскільки відсікає непотрібну архітектуру.

Для налагодження попросіть гіпотезу й шлях відтворення до того, як просити патч:

Симптом: Кнопка збереження лишається вимкненою після успішного повторного запиту API.

Очікувана поведінка: Кнопка стає доступною після успішного повторного запиту.
Спостережувана поведінка: Дані відповіді з’являються, але кнопка лишається вимкненою.

Відповідний контекст: Кнопка залежить від isPending і form.isDirty. Це почалося
після додавання повторних спроб до хука мутації.

Спершу перелічіть найімовірніші переходи стану та докази, потрібні для
підтвердження кожного. Потім запропонуйте найменше виправлення й регресійний тест.

Це безпечніше, ніж «виправте вимкнену кнопку», бо запит просить ChatGPT відрізнити помилку застарілого стану від проблеми валідації або рендерингу інтерфейсу.

Запити на рефакторинг потребують сильнішого застереження про збереження поведінки:

Виконайте рефакторинг списку карток тарифів, щоб прибрати дубльовану логіку
рендерингу планів.

Збережіть: публічні props, назви аналітичних подій, адреси оформлення замовлення, поведінку
клавіатури, стани завантаження та наявне мобільне компонування.

Межі завдання: Обмежте зміни функцією тарифів і безпосередньо пов’язаними з нею тестами.
Не вводьте абстракцію дизайн-системи, якщо наявний примітив не може виразити
спільну поведінку.

Критерії прийняття: Знімкові або інтерактивні тести покривають кожен стан плану, а
відрендерені посилання та корисні навантаження подій лишаються без змін.

Перед редагуванням визначте дублювання й будь-яку приховану поведінку, яку дві
картки зараз реалізують по-різному.

Фрази «збережіть поведінку» недостатньо самою по собі. Назвіть поведінку, яка має значення.

Не просіть «тести для цього компонента» без контракту. Назвіть сценарії:

Напишіть тести для форми скидання пароля, використовуючи наявний стек тестування.

Покрийте:
1. недійсна адреса email показує локалізоване повідомлення валідації;
2. надсилання один раз надсилає нормалізовану адресу email;
3. мережева помилка зберігає введене значення та показує наявний стан помилки;
4. успішна відповідь повідомляє про підтвердження, не розкриваючи, чи
   існує обліковий запис.

Не імітуйте деталей реалізації. Надавайте перевагу доступним ролям і міткам.

Це пояснює асистенту, що має бути доступно користувачу та яка поведінка приватності не повинна регресувати.

Промпт для пояснення має вимагати ланцюг доказів, а не короткий виклад:

Поясніть, як стан автентифікації потрапляє до екрана оплати в цьому репозиторії.

Простежте шлях від провайдера через захист маршруту до виклику оформлення замовлення. Назвіть
залучені файли й експортовані символи. Відокремте підтверджену поведінку від припущень
і перелічіть, що ви перевірили би далі, якби щось було незрозумілим.

Такий формат полегшує виявлення відсутньої залежності або вигаданого зв’язку.

ChatGPT надійніший, коли ви надаєте йому найвужчий контекст, що відповідає на запитання:

• тест, що падає, разом із кодом, який він перевіряє;
• компонент і хук, який володіє його станом;
• приклад запиту/відповіді з вилученими чутливими значеннями;
• правила проєкту, що обмежують зміну;
• короткий список файлів, які навмисно не входять до меж завдання.

Не завантажуйте секрети, токени доступу до виробничих систем, дані клієнтів або приватні журнали, якими вам не дозволено ділитися. Замініть ці значення реалістичними замаскованими даними та збережіть поведінку, яку потрібно проаналізувати.

Загальний підхід до цих промптів описано в матеріалі як писати кращі промпти для ШІ. Для набору шаблонів реалізації та перевірки за ролями продовжте з матеріалом інженерія промптів для розробників. Якщо потрібен опрацьований запит у форматі «до і після», скористайтеся прикладами інженерії промптів для інженерів програмного забезпечення, а перед дослідженням проблеми у робочій системі використовуйте шаблони промптів для налагодження виробничих проблем.

Згенерований код — це пропозиція. Запустіть відповідні тести, перегляньте різницю та самостійно виконайте зачеплений сценарій. Коли робота стосується виводу команд, помилок або скриптів оболонки, відтворення робочого процесу є частиною перевірки, а не необов’язковим доповненням. Використовуйте практичний простір командного рядка в браузері, щоб виробити цю звичку на реальному введенні команд і зворотному зв’язку.