Основи промптування

Основи ШІ | Складність: [ШВИДКИЙ] | Час: 30-40 хв

Що ви зможете зробити

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

Чому цей модуль важливий

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

Промптування — це дисципліноване формулювання завдання. Промпт працює як тікет, написаний для дуже швидкого колеги, який не має спільної пам’яті про ваше середовище, якщо ви її не надасте. Якщо в тікеті написано «полагодити автентифікацію», колезі доведеться вгадувати, який сервіс, яка помилка, які користувачі та яка умова успіху мають значення. Якщо в тікеті написано «діагностуй, чому login-под повертає HTTP 503 після розгортання о 10:20 UTC, використовуючи лише події та вивід readiness probe нижче, і поверни три ймовірні причини з однією командою верифікації для кожної», — робота стає достатньо обмеженою для перевірки.

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

Глибше: Повний курс промпт-інжинірингу (контракти, промпти-міркування, бібліотеки та безпека) див. у Основи промптів у розділі Основи ШІ-інжинірингу.

Промпт — це маленький контракт

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

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

+------------------+--------------------------------------------------+
| Промпт-контракт  | На яке питання відповідає                       |
+------------------+--------------------------------------------------+
| Завдання         | Яку роботу слід виконати?                       |
| Контекст         | Які факти, аудиторія та вихідний матеріал       |
|                  | мають значення?                                  |
| Обмеження        | Які ліміти, виключення або правила діють?        |
| Формат виводу    | Як має виглядати готова відповідь?              |
+------------------+--------------------------------------------------+

Розгляньмо слабкий запит «Поясни Kubernetes». Він не є неправильним у моральному сенсі; він просто недостатньо конкретизований. Модель мусить вгадувати, чи відповідь має допомогти продакт-менеджеру, адміністратору Linux, розробнику, який використовує Docker, чи інженеру, який готується до сертифікаційного іспиту. Ці здогадки змінюють словниковий запас, приклади та об’єкти, які вводяться першими. Кращий контракт усуває здогадки до того, як модель почне писати.

Завдання: Поясни Kubernetes.
Контекст: Аудиторія — молодший інженер, який знає процеси Linux і контейнери Docker, але ніколи не використовував кластер.
Обмеження: Використовуй просту мову. Уникай сервісів, специфічних для хмарних провайдерів. Поки що не обговорюй service mesh.
Формат виводу: Дай пояснення на 250 слів, одну аналогію та таблицю, яка зіставляє Pod, Node, Deployment і Service зі знайомими поняттями Docker або Linux.

Покращений промпт не гарантує ідеальної відповіді, але він дає вам конкретні критерії для рецензування. Якщо відповідь згадує service mesh, вона порушила обмеження. Якщо вона пропускає таблицю, вона порушила формат виводу. Якщо вона пояснює консенсус etcd раніше за Pod-и та Node-и, вона не врахувала контекст аудиторії. Корисний промпт, отже, створює спосіб оцінити відповідь, а не лише спосіб поставити запитання.

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

Словниковий запас зазвичай змінюється першим, оскільки контекст аудиторії повідомляє моделі, який рівень фонових знань припускати. Формат виводу та заборонені теми все ще обмежують форму та обсяг, але вони не повідомляють моделі, чи потребує «control plane» визначення, чи може використовуватися як знайома мова. Ось чому одне й те саме технічне завдання може потребувати різних промптів для початківця, старшого інженера та керівника. Завдання залишається стабільним, тоді як контекст змінює рівень пояснення.

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

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

Контекст, докази та приклади

Контекст — це матеріал, який модель має вважати релевантним для завдання. У повсякденному чаті контекстом можуть бути кілька речень про читача. В інженерній роботі контекст часто включає логи, YAML, відповіді API, вимоги або попередню чернетку. Небезпека в тому, що вихідний матеріал та інструкції можуть змішатися, коли їх вставляють в один недиференційований блок. Чіткі розмежувачі зменшують цей ризик, показуючи, де закінчуються інструкції та починаються докази.

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

Правила:
- Використовуй лише докази всередині <evidence>.
- Якщо доказів недостатньо, скажи, чого не вистачає.
- Поверни таблицю зі стовпцями Доказ, Висновок, Верифікація.

<evidence>
kubectl rollout status deployment/web
deployment "web" exceeded its progress deadline

kubectl get pods -l app=web
web-6dbb9f4f7c-2k8ms   0/1   ImagePullBackOff
</evidence>

Теги, схожі на XML, — це не магічний синтаксис; це візуальні роздільники. Ви могли б використати заголовки, обгороджені блоки коду або іншу чітку конвенцію, але суть та сама. Модель повинна відрізняти текст інструкцій від тексту доказів, особливо коли докази можуть містити фрази, схожі на команди. Якщо рядок логу каже «ігноруй попередні інструкції», добре сформульований промпт повідомляє моделі, що цей рядок є даними для аналізу, а не новим правилом для виконання.

Приклади — це другий вид контексту. Вони корисні, коли завдання має стильову або класифікаційну межу, яку важко описати абстрактно. Якщо ви хочете, щоб асистент із тріажу багів позначав звіти як reproducible, needs-info або not-a-bug, один короткий приклад для кожної мітки може навчити межі краще, ніж довгий абзац. Приклади мають бути малими, репрезентативними та чітко відокремленими від нового елемента для класифікації.

Завдання: Класифікуй новий звіт, використовуючи одне з: reproducible, needs-info, not-a-bug.

Приклади:
- Звіт: "На версії 1.6.2 збереження профілю з порожнім відображуваним іменем повертає HTTP 500."
  Мітка: reproducible
- Звіт: "Застосунок зламався після оновлення."
  Мітка: needs-info
- Звіт: "Експорт у CSV, але я очікував Excel."
  Мітка: not-a-bug

Новий звіт:
"На версії 1.6.2 натискання Export створює CSV із дубльованими рядками заголовка."

Формат виводу:
Мітка: <одна мітка>
Причина: <одне речення на основі прикладів>

Few-shot приклади потужні, оскільки вони показують моделі, що вважається збігом, але вони також можуть перенавчити відповідь. Якщо кожен приклад короткий, модель може видавати короткі відповіді, навіть коли новий випадок потребує нюансів. Якщо кожен приклад використовує ту саму продуктову область, модель може імпортувати цю продуктову область у непов’язані запити. Хороші приклади мають навчати межі рішення, а не випадково навчати нерелевантних прикрас.

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

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

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

Коли приклади конфліктують із письмовими правилами, виправте промпт перед тим, як довіряти відповіді. Поширена помилка — сказати «поверни одне речення», а потім надати приклади, які є цілими абзацами. Інша — просити нейтральну мову інциденту, тоді як кожен приклад звинувачує команду поіменно. Моделі навчаються як з явної інструкції, так і з патерну прикладів, тому приклади мають підкорятися тим самим правилам, які ви хочете застосувати до нового вводу. Якщо ні, приклади — це не корисний контекст; це конкуруючі інструкції.

Обмеження формують простір пошуку

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

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

task: Review a Kubernetes Pod manifest for beginner-level security risks.
context:
  audience: "new platform engineer"
  kubernetes_version: "1.35"
constraints:
  - "Do not recommend third-party scanners."
  - "Do not assume cluster-admin access."
  - "Only discuss fields visible in the manifest."
  - "Mark any missing evidence as 'not provided'."
output_format:
  type: "markdown_table"
  columns:
    - Field
    - Risk
    - Why it matters
    - Safer setting

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

Обмеження виводу — це місце, де промптування починає ставати інжинірингом, а не розмовою. Таблицю Markdown легше сканувати, ніж абзац, коли потрібно порівняти варіанти. JSON корисний, коли програма парситиме результат, але лише якщо завдання справді потребує машинного споживання, а модель або режим API можуть це забезпечити. Коротке пояснення плюс чекліст корисні, коли читач має діяти. Формат має служити наступному кроку, а не просто робити відповідь охайною.

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

Поверни три секції:

Спостережувані факти:
- Лише твердження, безпосередньо підкріплені наданими доказами.

Ймовірні висновки:
- Обґрунтовані пояснення, кожне прив'язане до одного спостережуваного факту.

Відсутня інформація:
- Конкретні дані, необхідні перед рекомендацією виправлення.

Зупиніться та передбачте: У промпті про розгортання вище, що станеться, якщо ви попросите «виправлення» до того, як попросите спостережувані факти та відсутню інформацію? Ймовірна невдача — це не погана граматика; це передчасна впевненість, коли відповідь перескакує від ImagePullBackOff до єдиного способу виправлення без перевірки облікових даних реєстру, назви образу, існування тегу чи мережевого доступу ноди.

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

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

Робіть припущення видимими

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

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

Завдання: Запропонуй план первинної діагностики для невдалого API Deployment.

Контекст:
- Новий Pod перебуває в CrashLoopBackOff.
- Логи не було зібрано.
- Інженер має лише доступ на читання на рівні простору імен.

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

Формат виводу:
1. Обов'язкові припущення
2. Необов'язкові припущення
3. Перевірки лише для читання в безпечному порядку

Цей промпт відрізняється від простого запиту невизначеності. Невизначеність каже, що невідомо; реєстр припущень каже, на що відповідь тимчасово покладається. Наприклад, «припускаючи, що kubectl logs дозволений у цьому просторі імен» — це обов’язкове припущення для плану, орієнтованого на логи. Якщо це припущення хибне, план мусить змінитися. Називаючи його, модель дає оператору конкретну перевірку дозволу, а не ховає залежність усередині списку команд.

Обробка припущень також допомагає, коли промпти перетинають межі команд. Платформний інженер може припускати, що кожен сервіс має проби готовності, тоді як інженер застосунку може знати, що застарілий сервіс їх не має. Рецензент безпеки може припускати, що production-дані входять до обсягу, тоді як автор промпту мав на увазі лише кластер розробки. Зазначення припущень у виводі дозволяє цим читачам виправити передумову перед обговоренням рекомендації. Це економить час, оскільки незгода переходить від «відповідь здається неправильною» до «припущення два хибне».

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

Припущення слід видаляти, щойно з’являються докази. Якщо подальший запит надає фактичний вивід логів, наступний промпт має сказати моделі замінити попереднє припущення спостережуваними доказами. Інакше розмова може нести застарілі припущення вперед, навіть після появи кращої інформації. Хороше уточнення може звучати так: «Використай логи нижче як докази та видали будь-яке припущення, що контейнер завершується до прив’язки порту, якщо логи цього не підтверджують.» Ця інструкція не дає історії промптів пересилити нові факти.

Ітерація краща за гігантські промпти

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

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

Крок 1: Чернетка
"Підсумуй цю хронологію інциденту для молодшого SRE. Використовуй лише факти нижче."

Крок 2: Перевірка
"Підсумок змішав підтверджені факти з гіпотезами. Перероби його на дві секції:
Підтверджені факти та Відкриті питання."

Крок 3: Уточнення
"Додай одну команду верифікації для кожного відкритого питання. Поки що не пропонуй виправлень."

Крок 4: Верифікація
"Перевір фінальну версію на наявність будь-яких тверджень, не підкріплених оригінальними фактами."

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

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

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

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

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

Підбирайте промпт під робочий продукт

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

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

Робочий продукт	Основний ризик	Прийом промпту, який допомагає
Діагностика	Непідтверджена першопричина	Вимагайте спостережувані факти, висновки, відсутні докази та кроки верифікації
Трансформація	Значення змінюється під час переформатування	Вкажіть інваріанти, які не мають змінюватися, та попросіть журнал змін
Генерація	Правдоподібний, але непридатний новий контент	Надайте критерії прийняття, аудиторію, не-цілі та приклади
Критика	Розмита вподобаність маскується під рецензію	Надайте рубрику, рівні серйозності та вимоги до доказів
План	Кроки з’являються в неправильному порядку	Вимагайте залежності, передумови та умови зупинки

Діагностичні промпти орієнтовані на докази, оскільки їхня найбільша невдача — передчасна впевненість. Якщо ви вставляєте стек-трейс і запитуєте «що не так», модель може перескочити до найбільш знайомої причини. Сильніший діагностичний промпт просить факти, видимі в трейсі, можливі причини, ранжовані за доказами, та наступну команду або файл для перевірки. Ця структура не робить діагноз правильним, але не дає відповіді приховати розрив між симптомом і причиною.

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

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

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

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

Завдання: Прорецензуй промпт нижче як завдання критики, а не переписування.
Контекст: Промпт використовуватиметься молодшим інженером під час комунікації щодо інциденту.
Обмеження:
- Знайди відсутній контекст, небезпечні припущення, нечіткий формат виводу та неперевірні твердження.
- Процитуй точну фразу, яка створює кожну проблему.
- Не переписуй весь промпт, якщо не попросять.
Формат виводу:
Таблиця зі стовпцями: Проблема, Серйозність, Доказ, Запропоноване вузьке виправлення.

Зауважте, що цей промпт каже «завдання критики, а не переписування», оскільки критику та генерацію легко сплутати. Якщо модель переписує негайно, учень може отримати кращий на вигляд промпт, не розуміючи, чому він покращився. Коли робочий продукт — рецензія, пояснення дефекту є частиною результату. Коли робочий продукт — генерація, готовий артефакт є результатом. Вибір робочого продукту спочатку тримає ці виводи розділеними.

Зупиніться та передбачте: Якщо трансформаційний промпт змінює нотатку інциденту з «доступ до реєстру не перевірено» на «доступ до реєстру не вдався», яке поле контракту ви б посилили? Найкраща відповідь — не формат виводу; це інваріант, що маркери невизначеності та неперевірені твердження мають бути збережені під час трансформації.

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

Використовуйте рецензування промптів перед повторним використанням

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

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

Чекліст рецензування промпту:
- Дієслово завдання конкретне.
- Межа доказів видима.
- Аудиторію або споживача названо.
- Обмеження можна перевірити.
- Формат виводу відповідає наступному кроку.
- Для відсутньої інформації є дозволена відповідь.

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

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

Коли промптування — це неправильне рішення

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

Корисне діагностичне питання: «Чи змогла б уважна людина відповісти на це з тієї самої інформації?» Якщо відповідь — ні, промпт не є основною вузькою ланкою. Людина не може діагностувати production-збій зі слів «застосунок повільний» без метрик, логів, нещодавніх змін і обсягу. Модель також не може. Правильний наступний крок — зібрати докази або звузити питання, а не додавати слова на кшталт «глибоко проаналізуй» або «ретельно подумай».

Є також випадки, коли завдання слід розділити між інструментами. Модель може пояснити план Terraform, але план усе ще має надходити від terraform plan. Модель може допомогти інтерпретувати невдачі тестів, але тести все ще мають запускатися. Модель може створити чернетку маніфесту Kubernetes, але валідація схеми та перевірки політик кластера все ще мають відбуватися поза промптом. Хороше промптування просить модель виконати мовну роботу та міркування, які їй підходять, тоді як детерміновані інструменти обробляють факти, для перевірки яких вони створені.

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

Симптом	Ймовірна першопричина	Кращий наступний крок
Відповідь вигадує деталі середовища	Відсутній контекст або докази	Надайте релевантні факти та забороніть непідтверджені припущення
Відповідь правильна, але непридатна	Формат виводу не відповідає наступному кроку	Вкажіть таблицю, чекліст, форму JSON або запис рішення
Відповідь дає виправлення занадто рано	Немає правила невизначеності або доказів	Спочатку вимагайте спостережувані факти, висновки та відсутню інформацію
Відповідь змінює стиль при кожному запуску	Аудиторія та приклади нестабільні	Додайте цільового читача та один-два репрезентативні приклади
Відповіді не можна довіряти	Немає зовнішнього робочого процесу верифікації	Запускайте команди, перевіряйте документацію або вимагайте цитування перед використанням

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

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

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

Почніть із називання завдання та аудиторії. Завдання — не «написати щось»; це «створити чернетку статусного оновлення». Аудиторія — не всі; це інженери, які чекають у командному каналі. Докази обмежені статусом розгортання та станом Pod-а, які ви фактично маєте. Обмеження мають запобігати спекуляціям і передчасним виправленням. Формат має відповідати каналу, куди буде вставлена нотатка.

Завдання: Створи чернетку короткого внутрішнього статусного оновлення про невдале розгортання.

Контекст:
- Аудиторія: інженери, які стежать за каналом #platform.
- Сервіс: web.
- Докази:
  - `kubectl rollout status deployment/web` повернув "deployment exceeded its progress deadline".
  - `kubectl get pods -l app=web` показав один новий Pod у стані ImagePullBackOff.
  - Логи реєстру ще не перевірено.

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

Формат виводу:
- Статусне оновлення з 2 речень.
- 3 булети наступних перевірок.

Цей промпт тепер можна рецензувати. Якщо вивід каже «облікові дані реєстру зламані», він порушив межу доказів, оскільки логи реєстру не перевірено. Якщо він пропонує видалити Pod-и, він порушив обмеження «поки що не пропонуй виправлення». Якщо він пише шість абзаців, він порушив формат виводу. Контракт дає вам важелі для виправлення замість того, щоб залишати вас із розмитим відчуттям, що відповідь не зовсім правильна.

Розумна відповідь на промпт може бути: «Розгортання web не завершилося, оскільки новий Pod наразі перебуває в ImagePullBackOff; першопричину ще не підтверджено. Ми перевіряємо назву образу, доступність тегу та доступ до реєстру, перш ніж рекомендувати виправлення.» Наступними перевірками були б: перевірити посилання на образ у Deployment, підтвердити, що тег існує в реєстрі, та перевірити події, пов’язані з завантаженням, на ураженому Pod-і.

Тепер зробіть одне вузьке уточнення. Припустімо, відповідь технічно чітка, але канал надає перевагу повідомленням, які включають відповідального за наступну перевірку. Не переписуйте весь промпт із нуля. Додайте одну інструкцію: «Додай стовпець Відповідальний у булети наступних перевірок, використовуючи Platform для перевірок маніфесту та Release Engineering для перевірок реєстру.» Результат має змінити лише секцію наступних перевірок, тоді як підтверджені факти та невизначеність залишаються незмінними.

Уточнення:
Перероби лише список наступних перевірок. Додай поле Відповідальний до кожного булету.
Використовуй Platform для перевірок маніфесту та подій Pod-а.
Використовуй Release Engineering для перевірок тегу реєстру та доступу до реєстру.
Залиш статусне оновлення з двох речень без змін.

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

Завдання: Створи чернетку нотатки для 2-хвилинної передачі про невдале розгортання `web`.

Контекст:
- `kubectl rollout status deployment/web` показує перевищення дедлайну прогресу.
- Новий `web` Pod перебуває в ImagePullBackOff.
- Логи ще не зібрано.

Обмеження:
- Надай рівно три наступні перевірки.
- Впорядкуй перевірки за очікуваним співвідношенням сигнал/зусилля з доступом лише для читання на рівні простору імен.
- Не стверджуй першопричину та не пропонуй виправлення.

Формат виводу:
2 короткі булети знахідок і 3 пронумеровані наступні перевірки у формі: [Відповідальний] | [Команда] | [Чому це найвищий пріоритет].

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

Чи знали ви?

Стаття GPT-3 2020 року повідомила про сильну few-shot поведінку, що є однією з причин, чому приклади всередині промпту можуть змінювати те, як модель виконує завдання.
Інструктивне налаштування зі зворотним зв’язком від людини стало основною причиною того, чому загальні моделі стало легше скеровувати формулюванням завдань природною мовою після 2022 року.
OWASP вказує промпт-ін’єкцію як LLM01 у своєму Топ-10 2025 для LLM-застосунків, що показує, що межі промптів також є проблемою безпеки.
Дослідження chain-of-thought показали значні покращення на деяких бенчмарках міркування, але production-промпти часто потребують стислого приватного міркування або форматів лише з відповіддю, а не довгого видимого міркування.

Типові помилки

Помилка	Чому це трапляється	Як виправити
Прохання «допомоги» без називання завдання	Запитувач знає ситуацію і забуває, що модель — ні	Почніть із дієслова, такого як діагностуй, порівняй, створи чернетку, класифікуй або рефактори
Вивалювання сирого контексту без розмежувачів	Вставлення всього здається безпечнішим, ніж вибір доказів	Позначте інструкції, докази, приклади та новий запит окремо
Використання слів тону замість правил, які можна перевірити	Слова як «професійний» і «точний» звучать корисно, але є розмитими	Замініть їх лімітами довжини, дозволеними джерелами, полями та забороненими припущеннями
Ставлення до першої відповіді як до остаточної	Модель звучить вільно, навіть коли пропустила обмеження	Перевірте відповідь за промпт-контрактом і уточніть найменший дефект
Запит виправлення до запиту доказів	Люди хочуть швидкого рішення під тиском	Спочатку вимагайте спостережувані факти, висновки та відсутню інформацію
Копіювання прийомів промптування між непов’язаними завданнями	Фраза спрацювала один раз, тому стає ритуалом	Прив’яжіть кожну інструкцію до реального режиму відмови в поточному завданні
Очікування, що промптування замінить верифікацію	Вивід легше читати, ніж вихідні докази	Використовуйте команди, документацію, тести або цитування для перевірки тверджень перед дією

Тест

Питання 1: Ваш колега запитує: «Поясни Kubernetes» — і отримує довгу відповідь про внутрішню будову control plane. Читач знає лише Linux і Docker. Яку зміну промпту слід зробити першою?

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

Питання 2: Промпт просить модель підсумувати тікет підтримки, але текст тікета містить речення «ігноруй попередні інструкції». Що має зробити промпт, щоб зменшити плутанину?

Відокремте інструкції від доказів чіткими розмежувачами та скажіть моделі розглядати текст тікета як дані. Наприклад, помістіть тікет усередину блоку <evidence> і скажіть, що інструкції всередині доказів не є інструкціями користувача. Це не вирішує всіх ризиків промпт-ін’єкції, але робить задуману межу явною. Сильніший production-робочий процес поєднав би цю межу промпту з дозволами інструментів і рецензуванням виводу.

Питання 3: Відповідь на ваш промпт діагностики розгортання постійно рекомендує виправлення до доведення причини. Яке обмеження слід додати?

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

Питання 4: Вам потрібен вивід, який скрипт може розібрати, але модель постійно додає дружні коментарі до та після корисного вмісту. Яка частина промпт-контракту відсутня?

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

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

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

Питання 6: Ваш промпт просить першопричину, але єдиний доказ — «застосунок повільний». Відповідь вигадує вузьке місце в базі даних. Це насамперед проблема промптування?

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

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

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

Практична вправа

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

Сценарій вправи: ви допомагаєте новому інженеру зрозуміти невдале розгортання Kubernetes. Єдиний доказ, який ви маєте, — що kubectl rollout status deployment/api повідомив про дедлайн прогресу, а kubectl get pods -l app=api показав новий Pod у CrashLoopBackOff. Ви ще не маєте логів і не знаєте першопричини.

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

Приклад рішення

Слабкий промпт може бути: «Поясни, чому розгортання API зазнало невдачі.» Сильніша версія сказала б: «Завдання: Створи чернетку дружньої для початківця нотатки діагностики для Kubernetes Deployment, який не зміг прогресувати. Контекст: kubectl rollout status deployment/api повідомив про дедлайн прогресу, а kubectl get pods -l app=api показав новий Pod у CrashLoopBackOff; логи не було зібрано. Обмеження: не стверджуй першопричину, не рекомендуй виправлення та використовуй лише надані докази. Формат виводу: три секції під назвами Спостережувані факти, Можливі висновки та Наступні перевірки, із щонайбільше трьома булетами на секцію.»

Корисним уточненням після першої відповіді може бути: «Переглянь секцію Наступні перевірки так, щоб кожна перевірка називала команду або необхідний доказ, але залиш секцію Спостережувані факти без змін.» Це уточнення вузьке, оскільки змінює лише ту частину, яка була неповною. Фінальна відповідь має зазначити, що Deployment не зміг прогресувати, а новий Pod аварійно завершується, зробити висновок, що логи та події потрібні перед тим, як можна буде дізнатися причину, і перелічити перевірки, такі як перегляд логів Pod-а, опис подій Pod-а та підтвердження нещодавніх змін образу або конфігурації.

Джерела

Наступний модуль

Перейдіть до Як верифікувати вивід ШІ.