Як писати кращі промпти для ШІ: відсутній контекст, що робить пропозиції ШІ справді корисними

Кращі промпти для ШІ не обов’язково мають бути довшими. Вони містять контекст, потрібний асистенту, щоб прийняти правильне рішення, а не лише запропонувати правдоподібну зміну. Для інженерної роботи це зазвичай означає назвати межі завдання, припущення, бажаний результат, обмеження та причину важливості зміни.

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

Асистент може написати коректний код на основі короткої інструкції, але коротка інструкція часто приховує продуктовий вибір. «Приберіть бічну панель на мобільних пристроях» пояснює асистенту, що змінити. Вона не пояснює, чи має лишитися незмінною поведінка на настільних комп’ютерах, чому нинішня поведінка заважає людям або як оцінити успіх.

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

Сприймайте промпт як стислий інженерний бриф, а не як команду.

Почніть із цих шести частин інформації:

1. Межі завдання: Який екран, файли, сценарій або поведінка входять до завдання?
2. Проблема: Що є складним, зламаним, повільним або незрозумілим для людини, яка користується продуктом?
3. Припущення: Що, на вашу думку, спричиняє проблему?
4. Бажаний результат: Що має бути правдою після завершення роботи?
5. Обмеження: Що має залишитися без змін і які підходи неприпустимі?
6. Запит на докази: Попросіть асистента поставити припущення під сумнів і пояснити, що він спершу перевірив би.

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

Ось слабкий промпт:

Зробіть мобільну навігацію узгодженішою та приберіть бічну панель.

Він задає дію, але не визначає межі рішення. Асистент може прибрати бічну панель усюди, бо не знає, що користувачі настільних комп’ютерів від неї залежать.

Ось кращий промпт:

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

Припущення: Мобільний шаблон навігації полегшить перемикання між уроками,
не змінюючи робочий процес на настільних комп’ютерах.

Результат: На малих екранах учні можуть перемикатися між уроками й повертатися
до поточної вправи, не втрачаючи контексту. Користувачі настільних комп’ютерів
зберігають наявну бічну панель і робочий процес із клавіатурою.

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

Перед реалізацією перевірте, хто зараз володіє навігацією, і поставте припущення
під сумнів, якщо проблему розв’яже менша зміна компонування.

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

Запит на розташування може мати ту саму проблему:

Перемістіть кнопку теми до бічної панелі та впишіть її в компонування.

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

Натомість спробуйте так:

Проблема: Перемикач тем у панелі навігації конкурує з глобальною навігацією,
але люди використовують його, порівнюючи уроки в межах поточного курсу.

Бажаний результат: Розмістіть перемикач тем поруч із навігацією курсу, щоб його
призначення було зрозумілим і до нього було легко дістатися під час перегляду уроку.

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

Спершу перевірте поточну модель маршрутизації та стану. Поясніть, чи є бічна панель
правильним місцем призначення, перш ніж змінювати компонування.

Центральна зміна — не «більше деталей». Це краще визначення успіху.

ШІ найкорисніший, коли може вказати на хибне припущення до того, як напише патч. Додайте одне пряме запитання:

Які докази спростували б це припущення і яку меншу зміну
нам варто розглянути спершу?

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

Це зміщує роботу з «згенерувати код зараз» до «прийняти обґрунтоване рішення, а потім реалізувати його».

Використовуйте цей шаблон, коли завданню потрібен продуктовий і технічний контекст:

Завдання: [Опишіть зміну одним реченням.]

Проблема: [На кого це впливає і що йде не так?]
Межі завдання: [Файли, екрани, робочий процес або підсистема в межах завдання.]
Припущення: [Що, на вашу думку, спричиняє проблему або яке рішення може допомогти.]
Бажаний результат: [Спостережний результат для користувача та системи.]
Обмеження: [Поведінка, яку потрібно зберегти, сумісність, продуктивність, доступність,
безпека, розгортання та цілі поза межами завдання.]
Відповідний контекст: [Архітектура, потік даних, нещодавні зміни, журнали або приклади.]
Критерії прийняття: [Як ми дізнаємося, що роботу завершено.]
Перевірка: [Тести, ручні перевірки або вимірювання, які потрібно виконати.]

Перед зміною коду дослідіть відповідну область. Поставте припущення під сумнів, якщо
докази вказують на безпечніше або менше рішення.

Шаблон також полегшує перевірку: колега бачить очікуваний результат і може вирішити, чи відповідає йому запропонована реалізація.

Доречний контекст є вибірковим. Додайте тест, що падає, повідомлення про помилку, поточну межу компонента, корисне навантаження запиту або короткий шлях користувача. Не вставляйте тисячі не пов’язаних рядків у надії, що асистент знайде важливу частину.

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

Використовуйте посібник для конкретного інструмента, коли контекст репозиторію змінює промпт: формулювання промптів для Cursor AI, найкращі практики формулювання промптів для GitHub Copilot або як отримувати кращі результати від Claude Code.

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

Використовуйте посібник з ухвалення рішень, коли ризик полягає у процесі, а не в синтаксисі: помилки ШІ-асистентів для програмування та як їх уникати і як досвідчені розробники використовують ШІ по-іншому.

Ті самі звички, що роблять промпти для ШІ корисними, роблять зрозумілішими завдання, pull request-и та нотатки про інциденти: пояснюйте проблему, визначайте результат, зберігайте важливу поведінку та перевіряйте результат.

Коли завдання стосується команди оболонки або виводу термінала, конкретизуйте поведінку, перш ніж просити асистента її змінити. Практикуйте робочі процеси командного рядка в браузері, щоб навчитися розпізнавати введення, виведення та сценарій збою, які має обробити реалізація.