Як перевіряти вивід ШІ

Складність: [СЕРЕДНЯ]

Час на виконання: 60-75 хв

Передумови: Модулі 1.1–1.3, базове володіння командним рядком і готовність перевіряти плавні відповіді доказами

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

Після цього модуля ви повинні вміти:

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

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

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

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

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

Основне правило: запитайте, що станеться, якщо це неправильно

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

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

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

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

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

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

Зупиніться та передбачте: припустімо, інструмент ШІ пропонує змінити маніфест Kubernetes із readOnlyRootFilesystem: true на false, щоб контейнер міг записати файл кешу. Які докази вам знадобилися б перед тим, як прийняти пропозицію, і що могло б піти не так, якби пропозицію скопіювали в продакшен без рецензування? Сильна відповідь має згадати вимогу застосунку, безпековий контекст, шлях для запису, альтернативу за принципом найменших привілеїв і політику або засоби контролю допуску, які діють у вашому кластері.

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

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

Побудуйте драбину верифікації

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

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

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

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

Рівень ризику	Типовий вивід	Ціль верифікації	Обґрунтована дія
Низький	Чернетка листа, переписування тону, підсумовування вашої нотатки	Зміст, намір, пропущені деталі	Уважно прочитайте та відредагуйте перед надсиланням
Середній	Технічне пояснення, пропозиція коду, навчальні нотатки	Документація, тести, логи, код, схеми	Перевірте твердження та виконайте безпечні перевірки
Високий	Зміна в продакшені, безпекова порада, команда видалення	Первинна документація, живий пробний запуск, експертне рецензування	Вимагайте доказів, затвердження та відкату

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

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

# Перевірте, чи запропонований ШІ прапорець справді існує у вашій поточній версії CLI
kubectl get pods --help | grep -- "--suggested-flag"

# Або запустіть пробний запуск, щоб побачити вплив без внесення змін
terraform plan -out=check.tfplan
# Потім перевірте план спеціально на деструктивні дії (наприклад, видалення)
terraform show -json check.tfplan | jq '.resource_changes[] | select(.change.actions[] == "delete")'

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

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

# Приклад: Верифікація запропонованого ШІ скрипту очищення ресурсів
# 1. Захопіть вивід, але вимкніть деструктивну дію
./ai-generated-cleanup.sh --dry-run > proposed_changes.log

# 2. Використайте 'grep' або 'wc', щоб перевірити неочікуваний масштаб
# Якщо ви очікуєте 5 видалень і бачите 500, логіка ШІ хибна
grep "Deleting" proposed_changes.log | wc -l

# 3. Виконайте серверний пробний запуск для маніфестів, щоб виявити помилки контролерів допуску
kubectl apply -f ai-suggested-config.yaml --dry-run=server

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

Перетворіть відповіді на твердження та джерела істини

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

Коли ви маєте твердження, оберіть джерело істини для кожного з них. Офіційна документація є добрим джерелом для поведінки публічного API. Реальна кодова база є джерелом для локальних допоміжних функцій і проєктних конвенцій. Логи, метрики та потоки подій є джерелом того, що сталося в системі. Локальна довідка CLI може бути джерелом для встановлених прапорців команд. Пробний запуск або набір тестів може бути джерелом того, чи запропонована зміна поводиться як задумано.

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

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

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

# Перевірте згенерований ШІ маніфест за схемою живого кластера
kubectl apply -f ai-generated-resource.yaml --dry-run=server --validate=true

# Перехресно звірте запропоновані поля з живою документацією API,
# щоб перевірити, чи ШІ не вигадує неіснуючі параметри
kubectl explain pod.spec.containers.securityContext | grep -A 5 "readOnlyRootFilesystem"

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

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

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

Корисно написати невелику нотатку верифікації, коли результат має значення. Використовуйте три стовпці: твердження ШІ, джерело істини та результат. Ця нотатка не мусить бути формальною. Це може бути чернетка під час роботи над інцидентом або короткий коментар у pull request. Сам акт записування джерела змушує поставити корисне запитання: чи я перевіряю за реальністю, чи лише прошу іншу мовну модель звучати так само впевнено?

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

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

[Обгортка верифікації]: Після відповіді на мій запит, будь ласка, надай:
1. Конкретні версійні припущення API (наприклад, policy/v1 проти v1beta1).
2. Два граничні випадки або обмеження середовища, де це рішення не спрацювало б.
3. Офіційне посилання на документацію або номер RFC, який регулює цю поведінку.
4. «Оцінку впевненості» (1-10) для фактичної точності будь-яких фрагментів коду.

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

Перевіряйте технічний вивід детермінованими перевірками

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

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

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

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

Шар верифікації	Запитання	Приклади інструментів	Що виявляє
Інтерфейс	Чи цей прапорець, поле або функція існують тут?	`--help`, `kubectl explain`, документація пакета	Вигадані параметри та дрейф версій
Обсяг	Яких об’єктів або шляхів це торкнеться?	пробні запуски, селектори, `find -print`, вивід плану	Широкі селектори та непередбачені цілі
Наслідок	Чи запропонована дія доречна?	тести, метрики, рецензування, план відкату	Дійсні, але шкідливі зміни
Підзвітність	Хто затвердив ризик?	pull request, тікет зміни, журнал інцидентів	Рішення без власника та слабкий аудиторський слід

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

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

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

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

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

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

Калібруйте верифікацію під ризик робочого процесу

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

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

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

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

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

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

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

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

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

Розібраний приклад: верифікація відповіді з діагностики

Сценарій вправи: staging-розгортання починає провалювати readiness-перевірки після зміни конфігурації. Інструмент ШІ отримує короткий промпт: «API-поди нездорові після релізу. Що мені робити?» Він відповідає, що ймовірною причиною є відсутня змінна середовища, і пропонує негайно відредагувати розгортання. Відповідь правдоподібна, оскільки відсутні змінні середовища є поширеною проблемою, але промпт не включав події подів, логи контейнерів, історію розгортань або змінений маніфест.

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

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

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

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

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

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

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

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

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

Патерн	Коли використовувати	Чому це працює	Міркування щодо масштабування
Нотатка «твердження-джерело-результат»	Пояснення середнього ризику, навчальні нотатки та pull request	Змушує кожне важливе твердження називати докази	Перетворіть нотатку на шаблон для повторюваних робочих процесів
Спочатку пробний запуск	Маніфести, інфраструктурні плани, скрипти очищення, міграції	Переглядає обсяг до зміни стану	Автоматизуйте захоплення пробного запуску в CI або тікетах змін
Перевірка живої схеми	Kubernetes та конфігурація на основі API	Закріплює синтаксис у реальному середовищі	Поєднуйте з мітками версій і перевірками політик
Шлюз людського затвердження	Продакшен-зміни високого ризику, безпека та зміни ідентичності	Залишає підзвітність із кваліфікованими рецензентами	Визначте, хто може затверджувати який рівень ризику до інцидентів

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

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

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

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

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

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

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

Фреймворк прийняття рішень

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

+-------------------------------+
| Надходить вивід ШІ             |
+-------------------------------+
              |
              v
+-------------------------------+
| Що, якщо це неправильно?       |
+-------------------------------+
      | низький        | середній/високий
      v                v
+----------------+  +-----------------------------+
| Перевірити     |  | Визначити твердження та      |
| намір і зміст  |  | ризик, обрати джерело істини |
+----------------+  +-----------------------------+
      |                |
      v                v
+----------------+  +-----------------------------+
| Відредагувати  |  | Виконати перевірки           |
| або відкинути  |  | docs/тести/пробний запуск,   |
| перед викор.   |  | схема/log/код               |
+----------------+  +-----------------------------+
                       |
                       v
                 +-----------------------------+
                 | Потрібне затвердження або    |
                 | відкат?                      |
                 +-----------------------------+
                       |
                       v
                 +-----------------------------+
                 | Діяти лише після того, як    |
                 | докази відповідають          |
                 | необхідній суворості         |
                 +-----------------------------+

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

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

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

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

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

Чи знали ви?

NIST опублікував AI RMF 1.0 у січні 2023 року: цей фреймворк розділяє роботу з надійним ШІ на функції керування, картографування, вимірювання та управління, що є корисним нагадуванням, що обробка ризиків починається до того, як відповідь моделі згенерована.
Серверний пробний запуск Kubernetes досяг стабільного статусу за роки до того, як багато команд зробили його рутиною: ця функція існує, щоб клієнти могли запитати шлях API, що сталося б без збереження зміни, — саме той тип детермінованої перевірки, якого потребує робота з маніфестами за допомогою ШІ.
OWASP перелічує дезінформацію як ризик застосунків генеративного ШІ: безпекове занепокоєння полягає не лише в зловмисному вводі, а й у надмірній довірі до правдоподібного виводу, який може призвести до небезпечних рішень.
Друга модель не є первинним джерелом: згода моделей може допомогти вам знайти альтернативи, але документація, код, логи, тести, схеми та кваліфіковані рецензенти є сильнішими доказами для технічних дій.

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

Помилка	Чому це стається	Як виправити
Довіра до відшліфованої мови	Плавні відповіді відчуваються як експертиза, особливо під тиском часу	Спочатку класифікуйте ризик, потім вимагайте докази для тверджень середнього та високого ризику
Сприйняття виводу ШІ як джерела істини	Згенеровану відповідь легше читати, ніж документацію, логи чи код	Назвіть джерело істини перед дією та порівняйте відповідь із ним
Верифікація через повторне запитання	Інша згенерована відповідь відчувається як підтвердження	Використовуйте детерміновану перевірку, первинне джерело або рецензента поза циклом моделі
Пропускання перевірок обсягу для команд	Команда виглядає знайомою, тому селектори та шляхи ігноруються	Перегляньте зачеплені об’єкти за допомогою пробних запусків, планів, `find -print` або запитів лише для читання
Ігнорування дрейфу версій	Відповідь використовує реальний синтаксис з іншого випуску, провайдера або інструменту	Перевірте встановлену довідку, живі схеми, документацію пакета та поведінку версії кластера
Дозвіл навчальним нотаткам ставати авторитетом	Корисні підсумовування повторно використовуються без оригінального контексту	Прикріплюйте джерела, позначайте невизначеність і перевіряйте повторно перед поширенням як довідкового матеріалу
Видалення засобів контролю, щоб помилка зникла	Модель оптимізує для негайного успіху, а не наміру політики	Перевірте мету контролю та шукайте виправлення за принципом найменших привілеїв
Забування відкату та володіння	Швидкі чернетки створюють враження, що дії тимчасові та з низькими зобов’язаннями	Вимагайте власника, критерії успіху, план відкату та затвердження для змін із високим ризиком

Тест

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

Відповідь

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

Відповідь

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

Відповідь

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

Відповідь

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

Відповідь

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

Відповідь

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

Відповідь

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

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

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

Нотатка щодо налаштування: виконуйте команди зі звичайної оболонки на машині зі стандартними інструментами Unix. Деякі довідкові команди трохи відрізняються між середовищами GNU та macOS, тому приклади включають резервні варіанти, де це корисно. Не використовуйте аліас оболонки для kubectl у повторно використовуваних скриптах або скопійованих прикладах; аліаси часто не розгортаються в неінтерактивних оболонках. Для цієї вправи приклади Kubernetes у модулі є концептуальними, тоді як локальні файлові команди — це команди, які ви фактично виконуватимете.

Створіть тимчасову лабораторну директорію та невеликий набір зразкових файлів для роботи.
Terminal window
```
LAB_DIR="$(mktemp -d)"
mkdir -p "$LAB_DIR"/logs
touch "$LAB_DIR"/logs/app.log "$LAB_DIR"/logs/api.log "$LAB_DIR"/logs/old.log
ls -la "$LAB_DIR"/logs
```
Попросіть інструмент ШІ переписати короткий лист про обслуговування для ясності. Порівняйте переписування з вашим оригіналом і позначте будь-які зміни в змісті, тоні або пропущені деталі.

Використовуйте ці команди верифікації, щоб тримати оригінальні факти видимими, поки ви рецензуєте згенероване переписування на предмет зміненого часу, пом’якшених попереджень або вигаданих обіцянок.
Terminal window
```
printf '%s\n' "Original email:"
printf '%s\n' "Maintenance starts at 18:00 UTC, expected duration 20 minutes, dashboards may be briefly unavailable."
```
Попросіть інструмент ШІ надати команду, яка виводить список файлів у директорії logs, відсортованих за назвою. Не запускайте пропозицію одразу. Спочатку перевірте, що команда безпечна та лише для читання.

Використовуйте ці команди верифікації, щоб перевірити вашу поточну директорію та тимчасовий лабораторний шлях, перш ніж довіряти будь-якій згенерованій команді виведення списку.
Terminal window
```
pwd
ls -la "$LAB_DIR"
ls -la "$LAB_DIR"/logs
```
Перевірте кожну частину запропонованої ШІ команди виведення списку за локальною довідковою інформацією або вбудованою документацією. Підтвердьте, що кожен прапорець існує та означає те, що ствердив вивід ШІ.

Використовуйте ці команди верифікації, щоб порівняти згенеровані прапорці з локальною документацією, приймаючи невеликі платформні відмінності, але відкидаючи непідкріплені твердження.
Terminal window
```
ls --help 2>/dev/null | head -n 20 || ls -G
man ls | col -b | head -n 30 2>/dev/null
```
Запустіть перевірену команду лише для читання та порівняйте вивід із тим, що ви очікували на основі вмісту директорії.

Використовуйте цю команду верифікації лише після того, як попередні перевірки пройдені, потім порівняйте відсортований вивід із файлами, які ви створили під час налаштування.
Terminal window
```
ls -1 "$LAB_DIR"/logs | sort
```
Попросіть інструмент ШІ пояснити, що робить команда на кшталт find "$LAB_DIR"/logs -name '*.log'. Визначте твердження в поясненні, потім перевірте їх, запустивши безпечний приклад.

Використовуйте ці команди верифікації, щоб перевірити пояснення за реальним виводом, особливо твердження про збіг назв файлів і кількість файлів.
Terminal window
```
find "$LAB_DIR"/logs -name '*.log'
find "$LAB_DIR"/logs -type f | wc -l
```
Попросіть інструмент ШІ надати команду для видалення old.log. Ставтеся до цього як до високого ризику навіть у тимчасовій директорії. Перевірте шлях, назву файлу та чи є дія оборотною, перш ніж запускати щось деструктивне.

Використовуйте ці команди верифікації, щоб довести цільовий шлях і назву файлу перед будь-якою деструктивною дією, оскільки команда видалення заслуговує на сильніші докази.
Terminal window
```
realpath "$LAB_DIR"/logs/old.log 2>/dev/null || readlink "$LAB_DIR"/logs/old.log
ls -la "$LAB_DIR"/logs
find "$LAB_DIR"/logs -maxdepth 1 -name 'old.log' -print
```
Виконайте перевірку в стилі пробного запуску, спочатку замінивши деструктивну дію переглядом лише для читання. Підтвердьте, що був би зачеплений лише призначений файл.

Використовуйте ці команди верифікації, щоб переглянути точний об’єкт і точну команду видалення, все ще тримаючи оболонку в режимі лише для читання.
Terminal window
```
find "$LAB_DIR"/logs -maxdepth 1 -name 'old.log' -print
printf '%s\n' rm "$LAB_DIR"/logs/old.log
```
Видаліть файл лише після того, як перегляд відповідає вашому очікуванню, потім перевірте результат.

Використовуйте ці команди верифікації після того, як перегляд відповідає вашому очікуванню, потім підтвердьте, що ціль зникла, а жоден інший файл логу не був видалений.
Terminal window
```
rm "$LAB_DIR"/logs/old.log
ls -la "$LAB_DIR"/logs
find "$LAB_DIR"/logs -maxdepth 1 -name 'old.log' -print
```
Напишіть коротку нотатку з трьома стовпцями: твердження ШІ, джерело істини та результат. Запишіть по одному прикладу для верифікації низького, середнього та високого ризику з цієї вправи.

Орієнтир для розв'язання

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

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

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

Джерела

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

Переходьте до Приватність, безпека та довіра, щоб дізнатися, як верифікація пов’язана з обробкою даних, межами безпеки та відповідальним використанням ШІ.