Найкращі практики формулювання промптів для GitHub Copilot

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

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

Дайте автодоповненню коду локальний контракт

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

Реалізуйте парсер для заголовка retry-after.

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

Контракт спрямовує автодоповнення без потреби в довгому архітектурному брифі.

Описуйте роботу з тестами через поведінку

Уникайте такого:

Напишіть тести для хука налаштувань.

Натомість використовуйте:

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

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

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

Тепер асистент має контракт, видимий для користувача, зокрема важливий негативний випадок.

Додавайте до промптів рефакторингу правила збереження поведінки

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

Виділіть повторюване представлення статусу з цих двох карток.

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

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

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

Налагоджуйте за симптомами й доказами

Симптом: Сторінка пошуку показує застарілі результати після того, як користувач
змінює фільтри.

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

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

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

Це не дає загальній відповіді «виправити стан гонитви» перетворитися на непотрібну міграцію керування станом.

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

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

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

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

Просіть документацію, що ґрунтується на коді

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

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

Фраза «перевірте за репозиторієм» важлива. Вона повідомляє Copilot, що точна документація є завданням читання коду, а не генерування прози.

Завершуйте кожен значущий промпт критеріями прийняття

Використовуйте фінішну межу, яку зможе перевірити інша людина:

Готово означає:
- повідомлена поведінка користувача змінюється, як описано;
- захищена поведінка лишається без змін;
- цільові тести доводять новий і старий шляхи;
- перевірка типів і відповідна команда лінтера проходять;
- diff не містить не пов’язаного із завданням очищення.

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

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