Давно минули часи, коли можна було дивуватися, коли ШІ викидає рядки й рядки коду, які справді виконуються. На цьому етапі ШІ може прийняти запит, заглибитися в проект, внести зміни, які я просив, і залишити мені щось, що принаймні працює.
Однак щось робити і щось справді робити — це дві дуже різні речі. Клод Код може бути напрочуд зрозумілим, але я виявив, що часто необхідно визначити, чи виконується другорядне завдання, яке виконує основна функція.
Ось чому я не дозволив Клоду Коду прийняти рішення після того, як усе закінчилося. Натомість я дав йому більш чітку фінішну лінію та довів, що вона справді перетнула її ще до виклику завдання!
Тепер я даю Клоду контрольний список, який він має спочатку пройти
Клод повинен отримати зелене світло
Скажімо, у вас іспит, який ви зубрили. Найкращий спосіб оцінити, чи справді ви готові, це, мабуть, переглянути свої нотатки, вирішити, що вони достатньо знайомі, і зупинити це. Вам потрібен якийсь конкретний спосіб визначити, чи справді ви охопили все, що вам потрібно.
Тому в першу чергу ми виготовляємо контрольні листи. Щоразу, коли у мене є купа дрібниць, я зазвичай записую їх і відзначаю галочками одну за одною, тому що інакше надзвичайно легко щось забути і переконати себе, що я закінчив, перш ніж я справді закінчив.
Ось так я почав лікувати Клода Коду! Замість того, щоб вважати, що завдання виконано лише тому, що основна функція запущена, я тепер надаю йому контрольний список речей, які потрібно виконати, перш ніж завдання можна буде запустити. Залежно від того, що я будую, це може означати переконатися, що проект все ще успішно будується, запустити відповідні тести, перевірити наявність помилок консолі, перевірити фактичний потік користувачів і повернутися до мого початкового запиту, щоб переконатися, що нічого несвідомо скинуто.
Замість того, щоб бути додатковими інструкціями, яких Клод повинен дотримуватися під час роботи, контрольний список, по суті, є набором умов, які необхідно виконати, перш ніж він зможе зупинитися. Тож, наприклад, я міг би завершити запит чимось таким:
-
Переконайтеся, що проект успішно будується.
-
Виконайте всі необхідні тести та виправте все, що не вдається.
-
Переконайтеся, що функція дійсно працює від початку до кінця.
-
Перевірте консоль на наявність помилок або очевидних регресій.
-
Перечитайте мій оригінальний запит і переконайтеся, що всі вимоги виконано.
-
Якщо будь-яка з цих перевірок не вдасться, виправте проблему та спробуйте ще раз викликати контрольний список, перш ніж виконувати завдання.
Це дуже просте доповнення, але воно змінює поведінку Клода Коду більше, ніж я очікував. Замість того, щоб ця функція технічно працювала і негайно повертала мені контроль, у неї є причина продовжувати роботу з тими дрібницями, які інакше залишилися б позаду!
Коли контрольного списку недостатньо, я використовую /goal
/goal дає Клоду фінішну пряму
Іноді надання Клоду контрольного списку не працює ідеально, або це просто занадто багато для поточного завдання. Не для кожної роботи потрібен довгий список умов, перш ніж Клода можна буде звільнити, особливо якщо те, що мене справді хвилює, — це дуже конкретний результат. Саме тут у /target з’являється вбудована команда Claude Code.
Я вже кілька разів писав про /target, і найбільше, чого я дізнався, використовуючи його, це те, що він працює набагато краще, коли я зупиняю його як інший спосіб давати інструкції Клоду. Натомість я використовую його, щоб визначити умову, яка має бути істинною, перш ніж дозволити Клоду виконати завдання.
Тож замість того, щоб пропонувати Клоду послідовність кроків і сподіватися, що він у потрібний момент вирішить, що все виконано, я можу поставити для нього мету, наприклад переконатися, що певна функція працює від початку до кінця, або щоб проект досяг певного стану без жодних невдалих тестів. Тоді Клод може продовжити роботу, щойно він вважатиме, що зробив достатньо, замість того, щоб повертати контроль мені.
Це також корисно для типів завдань, де я не обов’язково знаю, що кожен крок Клода потрібно виконувати заздалегідь. Контрольний список працює найкраще, коли я точно знаю, що хочу перевірити. Мета працює найкраще, коли я знаю, яким має бути кінцевий результат, але я радий дозволити Клоду зрозуміти, як її досягти.
Попросити Клода зробити його власну справу творить чудеса
Вірте, але підтверджуйте, Клод
Порада, якої я вірно дотримуюся, — це порада творця Claude Code Бориса Черні: дозвольте Клоду перевірити ваш результат. Ідея полягає в тому, що якщо Клод дійсно зможе побачити, чи працює те, що він створив, замість того, щоб писати код і припускати, що все йде за планом, він матиме шанс виявити свої помилки та виправити їх, перш ніж передати завдання назад вам.
Це може відрізнятися залежно від того, над чим я працюю. Якщо є тести, я попрошу Клода виконати їх після того, як це буде зроблено, і виправити все, що не вдається. Якщо я створив щось за допомогою інтерфейсу користувача, я змушую його відкрити програму в браузері та взаємодіяти з тим, що вона щойно створила, замість того, щоб припускати, що якщо код виглядає правильно, кінцевий результат також буде.
Я виявив, що це має величезну різницю. Було багато випадків, коли Клод впевнено казав мені, що щось закінчено, а я відкривав це сам і одразу бачив щось, що працює не так, як я просив. Надання Клоду такого самого циклу зворотного зв’язку означає, що він може вирішити багато з цих проблем до того, як я їх побачу.
Я також спеціально попросив Клода повернутися після того, як мій початковий запит буде виконано, і порівняти те, що він знайшов, із тим, що я просив. Це здається надто очевидним, але довші запити – це саме те місце, де я помітив, що маленькі запити мають звичку тихо зникати. Зрештою, тестування — це лише ще один спосіб визначити, чи виконана робота Клодом!
Незалежно від того, чи використовую я контрольний список, /goal, чи просто прошу Клода ще раз перевірити свою роботу, я вирішую, як зараз виглядає «зроблено». Ця невелика зміна в тому, як я працював із Клодом Кодом, значно покращила результат. Звичайно, воно все ще допускає помилки, але дуже мало з них повертаються до мене.
