Посібник із формулювання промптів для Cursor AI

Коли ШІ може досліджувати репозиторій, кращий промпт зазвичай є вужчим, а не ширшим. Надайте Cursor важливі файли, межі, обмеження та перевірку, а потім попросіть його проаналізувати відповідну область до редагування.

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

Поточна документація Cursor описує посилання на контекст для матеріалів репозиторію, зокрема файлів, папок, git-змін і помилок лінтера. Використовуйте доступні у вашій версії елементи керування контекстом, щоб спрямувати асистента до найменшого корисного набору доказів.

Наприклад, замість такого:

Виправте повільну інформаційну панель.

напишіть:

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

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

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

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

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

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

Контекст репозиторію найцінніший на початку завдання. Попросіть Cursor:

1. простежити відповідний потік даних або керування;
2. визначити код, що володіє поведінкою;
3. відокремити підтверджені факти від припущень;
4. перелічити найменші файли, які, імовірно, потрібно змінити;
5. пояснити, який тест або спостереження доведе виправлення.

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

«Оновіть функцію сповіщень» усе ще є широким запитом, якщо функція охоплює інтерфейс, збереження, воркери й налаштування. Додайте обмеження файлу або межі:

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

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

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

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

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

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

Великі запити важко перевіряти, оскільки широкий diff приховує причинно-наслідковий зв’язок. Розбивайте роботу на контрольні точки:

Спершу дослідіть і поясніть поточний шлях надсилання форми. Не редагуйте файли.

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

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

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

ШІ-асистент для програмування не повинен обирати «виглядає правильно» як правило завершення:

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

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

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

Завдання: [Однореченева інженерна ціль.]

Контекст репозиторію: [Відповідні файли, папка, diff, помилка або наявне правило.]
Проблема: [Спостережувана поведінка та кого вона зачіпає.]
Межі завдання: [Файли або межа, які слід спочатку дослідити.]
Бажаний результат: [Спостережний результат для користувача або системи.]
Обмеження: [Поведінка, сумісність, архітектура та цілі поза межами завдання.]
Критерії прийняття: [Потрібні результати.]
Перевірка: [Цільові тести, перевірка типів, ручна перевірка, вимірювання.]

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

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

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