Інженерія промптів для розробників

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

Ставтеся до запиту до ШІ так само, як до сильного завдання на реалізацію: він має пояснювати проблему, захищати важливу поведінку та вказувати, як команда дізнається, що зміна спрацювала.

Контракт промпту для розробника

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

Проблема: Що не працює або є складним для користувача чи фахівця з супроводу?
Межі завдання: Яку функцію, файли або межу асистент має дослідити?
Результат: Яка спостережна поведінка має змінитися?
Обмеження: Що має залишитися істинним?
Критерії прийняття: Що доводить завершеність реалізації?
Перевірка: Які тести, перевірки або ручні кроки слід виконати?

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

Промпти для реалізації: назвіть точку стику

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

Додайте порожній стан до наявного компонента результатів пошуку.

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

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

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

Промпти для налагодження: спершу просіть докази

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

Докази: Запити після оновлення токена один раз повертають 401, а потім успішно
повторюються. Інтерфейс усе ще показує банер про вихід з облікового запису.

Очікуване: Банер зникає після успішної повторної спроби.
Спостережуване: Дані завантажуються, але банер лишається.

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

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

Архітектурні промпти: захищайте рішення, а не лише файли

Для архітектурної роботи потрібні чіткі цілі поза межами завдання:

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

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

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

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

Промпти для перевірки коду: запитуйте ризики, а не компліменти

Перевірка ШІ корисніша, коли має ціль:

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

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

Це допомагає уникнути загальної перевірки, яка породжує довгий список малокорисних пропозицій щодо форматування.

Промпти для документації: зберігайте операційну правду

Документацію потрібно звіряти з кодом:

Оновіть посібник із налаштування для нової команди локального середовища.

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

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

Промпти для тестування: перетворюйте критерії прийняття на сценарії

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

Додайте регресійне покриття для виправлення фільтра пошуку.

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

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

Звичка, що робить промпти безпечнішими

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

Чи зрозуміє інший розробник, чому ця зміна важлива?
Чи зможе він визначити, що не повинно зламатися?
Чи знає він, де шукати насамперед?
Чи зможе він довести результат за критеріями прийняття?

Якщо відповідь «ні», промпту потрібен контекст, а не більше прикметників.

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