Проєктування робочих процесів зі ШІ

Складність: [MEDIUM]

Час на виконання: 45–60 хв

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

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

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

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

Гіпотетичний сценарій: ваша команда хоче «використовувати ШІ для роботи над релізами», бо всі витрачають забагато часу, перетворюючи нотатки з тікетів, підсумки pull request, вихідні дані тестів та ризики розгортання на реліз-бриф. Перший тиждень здається багатообіцяльним, бо модель швидко створює чернетки плавного тексту, але кожен інженер будує інший промпт, копіює інший контекст і перевіряє інші факти перед публікацією. До п’ятниці команда не побудувала робочого процесу; вона створила кілька приватних звичок, які працюють лише доти, доки початковий автор промпту уважно стежить.

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

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

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

Від роботи з промптами до проєктування робочих процесів

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

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

Хороше проєктування робочого процесу зі ШІ починається з вихідних даних, а не з моделі. Питання не в тому, «яка модель упорається із цим завданням?», а в тому, «який результат нам потрібен, які докази роблять його прийнятним і що станеться, коли він неприйнятний?». Щойно вихідні дані та критерії прийняття стають чіткими, модель перетворюється на один компонент більшого шляху. Цей шлях може включати пошук (retrieval), валідацію схеми, тести, перевірки джерел, взаємне рецензування, людське схвалення або інструкції з відкату — залежно від ризику завдання.

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

# Приклад: самокоригувальний робочий процес для генерації інфраструктури як коду
workflow:
  nodes:
    - id: generate-manifest
      action: llm_call
      params: { model: "gpt-4o-mini", template: "k8s-deployment" }
    - id: semantic-audit
      action: llm_judge
      params: { model: "o1-preview", rubric: "sec-policies.md" }
      on_fail: { target: generate-manifest, feedback: true, retry: 3 }
  edges:
    - from: generate-manifest
      to: semantic-audit
      condition: success

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

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

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

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

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

Ще одна корисна звичка — відокремлювати стан робочого процесу від стану розмови. Стенограма чату може бути зручною під час дослідження, але це слабка система записів для повторюваної роботи. Робочий процес має називати тривкі артефакти, які він створює: бриф, патч, звіт про огляд, чекліст, коментар до тікета або структурований об’єкт JSON. Коли тривкий артефакт чіткий, команда може прикріпити валідацію, відповідальність та історію до цього артефакту, замість того щоб покладатися на пам’ять усередині приватного чату.

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

Ключовий патерн: чернетка, перевірка, доопрацювання

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

мета -> контекст -> чернетка ШІ -> перевірка -> доопрацювання -> кінцевий результат

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

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

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

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

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

# Приклад автоматизованих воріт перевірки в CLI-робочому процесі
# 1. ШІ генерує маніфест (draft.yaml)
# 2. Крок перевірки використовує пробний запуск (dry-run) і перевірку політик
kubectl apply -f draft.yaml --dry-run=server && \
kube-linter lint draft.yaml && \
echo "Verification Passed" || \
echo "Verification Failed: Feeding errors back to revision loop"

Цей блок команд навмисно простий, але він фіксує важливу операційну звичку. Модель може створити чернетку маніфесту, проте робочий процес відмовляється вважати маніфест прийнятним, доки серверний пробний запуск (dry-run) Kubernetes і перевірки лінтера не отримають шансу його відхилити. У реальній системі ви б також захопили вихідні дані відмови й передали стислий підсумок помилки в крок доопрацювання. Це сильніше, ніж просити модель «спробувати ще раз», бо виправлення прив’язане до конкретної відмови.

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

Перш ніж це запускати, які вихідні дані ви очікуєте, якщо draft.yaml має валідну схему, але порушує правило лінтера про відсутні ліміти CPU? Пробний запуск (dry-run) може пройти, бо сервер API приймає об’єкт, але крок лінтингу має провалитися й відправити робочий процес на доопрацювання. Саме ця відмінність — причина того, чому зрілі робочі процеси часто використовують кілька воріт перевірки. Різні інструменти ловлять різні класи помилок, і одна зелена позначка рідко доводить, що вихідні дані готові.

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

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

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

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

Вибір хороших і поганих цілей для робочого процесу

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

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

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

workflow:
  target: security_remediation
  schema_validation: true
  steps:
    - name: extract_vulnerability_impact
      prompt: |
        Проаналізуй наведені дані CVE.
        Визнач уражені образи контейнерів та потрібні версії патчів.
        Виведи ЛИШЕ об'єкт JSON, що відповідає 'VulnerabilitySchema'.
    - name: generate_k8s_patch
      dependency: extract_vulnerability_impact
      action: "kubectl patch deployment {{deployment_name}} --patch-file {{generated_patch}}"

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

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

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

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

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

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

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

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

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

Розміщення людей, інструментів і контрольних точок

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

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

Інструментам місце там, де критерії коректності можна виразити механічно. Серверний пробний запуск (dry-run) Kubernetes може перевірити, чи приймає маніфест сервер API. Лінтер може примусово застосовувати правила стилю та політик. Валідатор схеми може відхилити некоректний JSON. Перевіряч цитувань може підтвердити, що посилання існують і що присутні обов’язкові поля джерела. Інструменти не замінюють людське судження, але прибирають класи роботи з огляду, яку люди виконують повільно й непослідовно, коли доводиться робити це раз за разом.

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

# Приклад: ворота перевірки робочого процесу
workflow:
  name: production-resource-patching
  steps:
    - id: generate-patch
      type: llm-inference
      prompt: "Згенеруй патч розгортання K8s для оптимізації лімітів пам'яті"
    - id: validation-gate
      type: verification
      strategy: dry-run
      required_checks:
        - schema_validation: "kubernetes-1.35"
        - impact_analysis: "non-destructive"
    - id: manual-approval
      type: human-in-the-loop
      condition: "impact_score > 0.7"

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

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

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

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

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

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

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

Патерни та антипатерни

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

Патерн	Коли використовувати	Чому працює	Що врахувати при масштабуванні
Чернетка, потім перевірка	Модель створює перший прохід, який може перевірити людина чи інструмент.	Відокремлює творчість від прийняття й робить довіру умовною.	Додайте автоматичні перевірки перед людським оглядом, щоб рецензенти зосереджувалися на судженні.
Отримати, потім відповісти	Модель має підсумувати джерельний матеріал або міркувати над ним.	Обмежує непідкріплені твердження, роблячи докази видимими.	Відстежуйте свіжість джерел, покриття пошуку та запитання без відповіді.
Маршрутизувати, потім спеціалізувати	Запити варіюються настільки, що один промпт стає перевантаженим.	Маршрутизатор надсилає роботу до менших промптів із вужчим контекстом.	Стежте за помилками маршрутизації, бо хороша відповідь у хибному шляху — усе одно відмова.
Безпечна відмова з ескалацією	Робочий процес може видати непевні чи ризиковані вихідні дані.	Неоднозначні випадки зупиняються чи ескалюються замість того, щоб тихо продовжуватися.	Визначте відповідальність за ескалацію та пороги сповіщень перед запуском.

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

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

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

Антипатерн	Що йде не так	Чому команди в це потрапляють	Краща альтернатива
Купа промптів	Процес перетворюється на приватну колекцію промптів без спільного шляху.	Ранні експерименти винагороджують індивідуальну швидкість.	Перетворіть найкращий промпт на задокументований робочий процес із вхідними даними, перевірками та відповідальними.
Довіра через плавність	Вихідні дані приймають, бо вони читаються впевнено.	Плавний текст здається завершеним і знижує підозри рецензента.	Вимагайте доказів, тестів чи перевірок джерел перед прийняттям.
Прихований контекст	Модель залежить від невисловленого знання одного оператора.	Експерти забувають, скільки всього тримають у головах.	Зробіть джерела контексту явними й прикріплюйте їх до кожного запуску.
Дія перед доказами	Робочий процес змінює стан, перш ніж стане відома якість.	Команди хочуть, щоб автоматизація прибрала очікування.	Спершу генеруйте рекомендації, а потім пропускайте дії крізь перевірки та схвалення.

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

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

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

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

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

Рамка прийняття рішень

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

Старт
  |
  v
Чи завдання повторюване й цінне?
  |-- ні --> Лишіть його ручним або дослідницьким
  |
 так
  v
Чи можна специфікувати й перевірити вихідні дані?
  |-- ні --> Покращте процес, перш ніж додавати ШІ
  |
 так
  v
Чи дія високоризикова або змінює стан?
  |-- так --> Вимагайте детермінованих воріт і названого схвалення
  |
 ні
  v
Чи можна дешево виявляти й доопрацьовувати відмови?
  |-- ні --> Використайте вибірку, ескалацію або ручний робочий процес
  |
 так
  v
Побудуйте обмежений робочий процес зі ШІ з логуванням і оглядом

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

Питання для рішення	Робочий процес зі ШІ перспективний, коли	Надайте перевагу іншому підходу, коли
Форма вхідних даних	Вхідні дані різноманітні, але належать до відомої родини завдань.	Вхідні дані повністю структуровані, і детермінованих правил достатньо.
Форма вихідних даних	Вихідні дані можна визначити, оглянути й доопрацювати.	Ніхто не може дійти згоди, як виглядають хороші вихідні дані.
Перевірка	Тести, перевірки джерел, схеми чи рецензенти можуть ловити відмови.	Єдина перевірка — «модель здавалася впевненою».
Ризик	Робочий процес створює чернетки, рекомендує чи обробляє низькоризикові зміни.	Робочий процес ухвалював би рішення з великим впливом без схвалення.
Відповідальність	Названий відповідальний може підтримувати промпти, контекст і ворота.	Робочий процес запустили б і забули.

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

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

питання -> зібрати джерельний матеріал -> підсумок ШІ -> людська перевірка джерел -> доопрацювання -> публікація

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

завдання -> код/контекст -> пропозиція ШІ -> тести/лінт/збірка -> людський огляд -> злиття

Форма змінюється, а принцип — ні: жодних високодовірчих вихідних даних без відповідного кроку перевірки. У дослідницькій роботі крок перевірки запитує, чи підкріплені твердження видимими джерелами. У програмуванні він запитує, чи задовольняє патч тести, лінтинг, обмеження збірки та очікування огляду. В операційній роботі він може запитувати, чи проходить пробний запуск (dry-run), чи приймає рушій політик зміну і чи схвалює дію названий відповідальний.

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

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

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

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

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

Чи знали ви?

Серверний пробний запуск (dry-run) Kubernetes загальнодоступний починаючи з Kubernetes 1.18, а отже, робочі процеси часто можуть запитати сервер API, чи був би прийнятий об’єкт, перш ніж змінювати живий стан кластера.
Рамку управління ризиками ШІ NIST (AI Risk Management Framework) 1.0 випустили в січні 2023 року, і вона організовує роботу з ризиками навколо функцій Govern, Map, Measure та Manage, які чітко відображаються на відповідальність і перевірку робочого процесу.
Функції структурованих вихідних даних OpenAI можуть обмежувати відповіді моделі наданою схемою, що корисно, коли робочий процес зі ШІ має передати дані подальшій автоматизації, а не людині-читачу.
Kube-linter перевіряє YAML Kubernetes на поширені проблеми конфігурації та безпеки перед розгортанням, що робить його практичним прикладом детермінованих воріт після створення чернеток маніфестів за допомогою ШІ.

Поширені помилки

Помилка	Чому вона стається	Як її виправити
Почати з вибору моделі замість контракту вихідних даних	Нові інструменти створюють відчуття, що вибір моделі — головне рішення дизайну.	Визначте фінальний артефакт, критерії прийняття, відповідального та шлях відмови, перш ніж обирати налаштування моделі.
Сприймати бібліотеку промптів як робочий процес	Промпт може ховати контекст, судження та кроки огляду всередині звички однієї людини.	Задокументуйте вхідні дані, джерела контексту, крок чернетки, ворота перевірки, правило доопрацювання та фінального схвалювача.
Пропускати перевірку, бо вихідні дані плавні	Плавна проза чи охайний на вигляд код створюють хибну впевненість.	Додайте огляд джерел, валідацію схеми, тести, лінтинг, перевірки пробним запуском (dry-run) або іменне схвалення перед прийняттям.
Давати моделі забагато нефільтрованого контексту	Команди бояться пропустити інформацію, тож вставляють усе.	Отримуйте найменший релевантний пакет контексту й тримайте докази видимими для рецензентів.
Дозволяти ШІ змінювати стан, перш ніж стане відома якість	Демо автоматизації винагороджують швидкість і приховують операційні наслідки.	Спершу генеруйте рекомендації чи патчі, а потім вимагайте детермінованих воріт і схвалення для змін стану.
Не закріпити відповідальність за робочий процес	Кожен припускає, що хтось інший оновлюватиме промпти, джерела, рубрики та сповіщення.	Назвіть відповідальних за контекст, перевірку, фінальні рішення, моніторинг і відкат.
Будувати робочі процеси заради новизни для одноразових завдань	Нова можливість створює відчуття, що демо стратегічно важливе.	Надавайте пріоритет повторюваним, цінним завданням, де форма вихідних даних і перевірка стабільні.

Тест

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

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

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

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

Ваша команда пропонує `завдання -> ШІ пише код -> злиття` для дрібних виправлень багів, бо патчі зазвичай виглядають правильними. Як вам слід переспроєктувати цей шлях?

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

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

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

У вас є робочий процес «стенограма → статус-оновлення» зі стабільним шаблоном вихідних даних і оглядом менеджера. Що робить це сильним кандидатом на робочий процес зі ШІ?

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

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

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

Ви обираєте між повною автоматизацією, створенням чернеток за підтримки ШІ та ручним чеклістом для процесу винятків безпеки на продакшені. Яке правило рішення має скеровувати вибір?

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

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

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

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

Настанови до розв'язання

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

Скористайтеся цими командами перевірки, щоб підтвердити, що артефакт лабораторної роботи існує й досі відповідає вимозі робочого процесу, перш ніж переходити до наступного завдання.
Terminal window
```
mkdir -p ai-workflow-lab
cd ai-workflow-lab
pwd
```
Напишіть бриф робочого процесу, що визначає точну мету, вхідні дані, вихідні дані, відповідального та обробку відмов. Створіть файл із назвою workflow-brief.md з такими полями: Goal:, Inputs:, Output:, Verification:, Owner: та If output is weak or wrong:.

Настанови до розв'язання

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

Скористайтеся цими командами перевірки, щоб підтвердити, що артефакт лабораторної роботи існує й досі відповідає вимозі робочого процесу, перш ніж переходити до наступного завдання.
Terminal window
```
grep -E '^(Goal|Inputs|Output|Verification|Owner|If output is weak or wrong):' workflow-brief.md
```
Змапуйте робочий процес як послідовність явних кроків. Скористайтеся структурою на кшталт мета -> контекст -> чернетка ШІ -> перевірка -> доопрацювання -> кінцевий результат, а потім адаптуйте її до обраного завдання, щоб кожен крок був конкретним.

Настанови до розв'язання

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

Скористайтеся цими командами перевірки, щоб підтвердити, що артефакт лабораторної роботи існує й досі відповідає вимозі робочого процесу, перш ніж переходити до наступного завдання.
Terminal window
```
cat workflow-brief.md
```
Додайте до робочого процесу контрольні точки для людини та інструментів. Позначте, де людина визначає мету, де ШІ створює чернетку, де інструмент чи чекліст перевіряє результат і де людина схвалює чи відхиляє вихідні дані.

Настанови до розв'язання

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

Скористайтеся цими командами перевірки, щоб підтвердити, що артефакт лабораторної роботи існує й досі відповідає вимозі робочого процесу, перш ніж переходити до наступного завдання.
Terminal window
```
grep -n 'Verification:' workflow-brief.md
grep -n 'Owner:' workflow-brief.md
```
Створіть просту рубрику перевірки з перевірками «пройдено/не пройдено». Додайте щонайменше три перевірки, як-от matches requested format, uses visible source material or provided context, contains no unsupported claims та is approved by the named owner.

Настанови до розв'язання

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

Скористайтеся цими командами перевірки, щоб підтвердити, що артефакт лабораторної роботи існує й досі відповідає вимозі робочого процесу, перш ніж переходити до наступного завдання.
Terminal window
```
grep -nE 'pass|fail|format|source|owner' workflow-brief.md
```
Проведіть один пробний запуск робочого процесу з прикладовими вхідними даними. Візьміть короткі приклади вхідних даних, створіть чернетку за допомогою ШІ, оцініть її за своєю рубрикою та зафіксуйте, чи вона пройшла, чи провалилася і що слід змінити перед наступним запуском.

Настанови до розв'язання

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

Скористайтеся цими командами перевірки, щоб підтвердити, що артефакт лабораторної роботи існує й досі відповідає вимозі робочого процесу, перш ніж переходити до наступного завдання.
Terminal window
```
printf '%s\n' 'Sample run completed' >> workflow-brief.md
tail -n 10 workflow-brief.md
```
Доопрацюйте робочий процес, щоб усунути одну слабкість. Покращте одну з цих сфер: нечіткі вхідні дані, відсутня перевірка, нечітка відповідальність, відсутній шлях доопрацювання, забагато прихованого контексту або дія перед доказами.

Настанови до розв'язання

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

Скористайтеся цими командами перевірки, щоб підтвердити, що артефакт лабораторної роботи існує й досі відповідає вимозі робочого процесу, перш ніж переходити до наступного завдання.
Terminal window
```
grep -nE 'revision|verify|owner|input' workflow-brief.md
wc -l workflow-brief.md
```

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

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

Джерела

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

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