Приклади інженерії промптів для інженерів програмного забезпечення
Конкретні приклади інженерії промптів для налагодження, рефакторингу, тестів, архітектури, перевірки коду й документації.
Корисний інженерний промпт спонукає асистента міркувати на основі проблеми, доказів, обмежень і критеріїв прийняття, а не окремої команди. Приклади нижче показують, як це змінює роботу з налагодженням, рефакторингом, тестами, архітектурою, перевіркою коду й документацією.
Кожен кращий промпт навмисно конкретизує рішення, яке має ухвалити асистент. Його можна скоротити для невеликого завдання, але збережіть інформацію, що не дає внести зміну, яка буде неправильною для продукту.
Налагодження нестабільного оформлення замовлення
Проблема
Запит на оформлення замовлення іноді успішно виконується після повторної спроби, але інтерфейс і далі показує першу помилку.
Слабкий промпт
Виправте нестабільну помилку оформлення замовлення.
Кращий промпт
Симптом: Запит на оформлення замовлення може один раз завершитися невдачею через
тайм-аут, а потім успішно виконатися під час автоматичної повторної спроби.
Екран успіху не з’являється після повторної спроби.
Очікуване: Успішна повторна спроба має замінити стан помилки й увімкнути
наступний крок оформлення замовлення.
Спостережуване: Журнали мережі показують відповідь 200, але перший банер помилки лишається.
Межі завдання: Перевірте лише мутацію оформлення замовлення, callback повторної
спроби та стан екрана.
Обмеження: Збережіть наявну інтеграцію з платіжним провайдером і текст помилки.
Не приховуйте помилки, доки запит фактично не завершився успішно.
Спершу наведіть дві або три гіпотези, засновані на доказах, і найменший сценарій
відтворення або сигнал у журналах, який дасть змогу їх розрізнити. Потім запропонуйте
мінімальне виправлення й регресійний тест.
Чому це працює
Промпт відокремлює докази від припущення. Він просить діагностувати переходи стану до переписування коду й захищає платіжну інтеграцію від не пов’язаної зі справою зміни.
Рефакторинг повторюваної логіки форм
Проблема
Три форми налаштувань повторюють той самий код для станів завантаження, помилки та збереження.
Слабкий промпт
Виконайте рефакторинг цих форм, щоб прибрати дублювання.
Кращий промпт
Форми облікового запису, сповіщень і профілю дублюють рендеринг стану збереження.
Визначте точну повторювану поведінку та місця, де форми відрізняються.
Результат: Зменшіть дублювання рендерингу, не змінюючи публічні props форм,
час валідації, локалізовані помилки, події аналітики або поведінку клавіатури.
Межі завдання: Три форми налаштувань і їхні безпосередні тести.
Ціль поза межами завдання: Не створюйте загальний фреймворк форм і не переносіть
володіння запитами з наявних хуків функції.
Порекомендуйте найменше виділення спільного коду, покажіть контракт, що зберігається,
і додайте або оновіть тести для завантаження, помилки й успіху кожної форми.
Чому це працює
«Прибрати дублювання» — це мета, а не проєктне рішення. Кращий промпт просить асистента знайти справжню спільну точку стику та не допускає надмірної абстракції.
Написання тесту для стану гонитви
Проблема
Результати пошуку від повільного старого запиту можуть перезаписати результати нового запиту.
Слабкий промпт
Додайте тести для пошуку.
Кращий промпт
Додайте регресійне покриття для стану гонитви під час пошуку.
Сценарій: Користувач шукає "network", одразу змінює запит на
"terminal", а відповідь для network повертається останньою.
Очікуване: Інтерфейс показує лише результати для "terminal". Старіша відповідь не
має їх замінити.
Використовуйте наявний стек тестування та доступні твердження. Не перевіряйте внутрішні
назви стану. Якщо виробничий код не може чітко виразити скасування або актуальність,
поясніть найменшу необхідну зміну до написання тесту.
Чому це працює
Промпт для тесту визначає час, дію користувача та видиму поведінку. Він не дозволяє зручній деталі реалізації стати контрактом тесту.
Оцінювання архітектурної зміни
Проблема
Команда вирішує, чи додавати другий рівень кешу для конфігурації.
Слабкий промпт
Додайте кешування конфігурації, щоб зробити застосунок швидшим.
Кращий промпт
Оцініть, чи покращить кеш конфігурації на клієнті повільний екран,
не створюючи застарілих рішень щодо прав доступу або налаштувань.
Контекст: У застосунку вже є провайдер конфігурації, а екран очікує
автентифікованого користувача. Ми не вимірювали, чи вузьким місцем є
отримання даних або рендеринг.
Порівняйте: відсутність кешу, обмежений кеш у пам’яті та запропонований постійний
кеш. Оцініть актуальність, інвалідацію, приватність, роботу офлайн і
вимірювання, потрібне для обґрунтування зміни.
Нічого не реалізовуйте, доки не вкажете рекомендований варіант і його обґрунтування.
Чому це працює
Промпт робить «швидше» вимірюваним і просить асистента поставити передумову під сумнів. Кеш не є автоматичним покращенням продуктивності.
Перевірка ризикованого diff
Проблема
Pull request змінює дозволи й навігацію, видиму для користувача, в межах однієї функції.
Слабкий промпт
Перевірте цей pull request.
Кращий промпт
Перевірте цей diff на регресії авторизації, навігацію, що ламає локаль,
і зміни поведінки, приховані рефакторингом.
Простежте кожне змінене рішення щодо дозволів до його виклику. Перевірте, що внутрішні
посилання зберігають активну локаль і що стани відмови не розкривають захищені
дані.
Повідомляйте лише про висновки з доказами з diff або його безпосередніх місць виклику.
Надавайте пріоритет коректності та безпеці перед пропозиціями щодо стилю. Окремо
перелічіть відсутні тести й підтверджені дефекти.
Чому це працює
Перевірка має модель загроз і межі. Це дає менший і придатніший до дій результат, ніж запит на загальний відгук.
Оновлення документації після зміни інструмента
Проблема
Команда локального налаштування змінилася, а посібник із початку роботи тепер застарів.
Слабкий промпт
Оновіть документацію з налаштування.
Кращий промпт
Оновіть посібник із локального налаштування для поточних скриптів пакета.
Перевірте кожну задокументовану команду за package.json та інструкціями
з налаштування репозиторію. Поясніть передумови, очікуваний сигнал готовності,
поширені сигнали збою та безпечний шлях відновлення.
Не документуйте секрети, значення, скопійовані з локального середовища, або команди,
які проєкт фактично не виконує. Додайте короткий контрольний список перевірки для
нового учасника команди.
Чому це працює
Асистент має ґрунтувати текст на репозиторії, а не створювати вишуканий, але вигаданий посібник.
Використовуйте приклад, що відповідає вашому завданню
Повторюваний шаблон простий: назвіть проблему, звузьте межі, захистіть важливу поведінку, попросіть докази й визначте перевірку. Почніть із багаторазового підходу в матеріалі як писати кращі промпти для ШІ, а потім перегляньте інженерію промптів для розробників, де робочий процес організовано за інженерними ролями.
Виробничі проблеми потребують ще суворішого ланцюга доказів. Продовжте з матеріалом шаблони промптів для налагодження виробничих проблем, перш ніж просити асистента запропонувати виправлення для робочої системи. Коли помилка стосується виводу оболонки або скрипту, відтворіть робочий процес командного рядка в браузері, перш ніж автоматизувати розв’язання.
Посилання
Ці посилання на документацію надають авторитетну інформацію про команди, використані в цій статті.