Редакторська примітка: Ця стаття від Dominik Kundel, члена команди розвитку спільноти OpenAI, підсумовує досвід використання функції Codex «goal mode / /goal». Вона розглядає не звичайний підхід до формування запитів, а зміну ролі інструментів AI для програмування: Codex більше не є лише асистентом, який відповідає на одноразові команди, а починає функціонувати як виконавчий агент, що систематично працює над чітко визначеною метою.
У режимі /goal найважливішим є не те, наскільки довго й детально ви описуєте вимоги, а те, щоб встановити чіткі, перевіряні критерії завершення для Codex. Наприклад: «зменшення часу розгортання на 30%», «покриття тестами до 100% parity», «LCP нижче 2,5 секунди». Ці показники дозволяють Codex визначити, чи завдання виконано, і уникнути нескінченних спроб на основі нечітких цілей. Разом із тим, користувач повинен надати достатньо напрямків, інструментів та реальних умов, щоб Codex міг оцінювати прогрес і перевіряти результати, а не просто виконувати на локальній машині чи в гіпотетичних умовах сценарій, який здається виконуваним.
Стаття особливо підкреслює, що візуальні завдання найбільш схильні засмічувати Codex деталями. Замість вимоги «100% піксельної відтворення» краще розбити візуальну мету на список функцій, специфікації дизайн-системи та оцінювані показники. Для тривалих завдань, що тривають години або навіть дні, необхідно постійно відстежувати прогрес за допомогою комітів, чернеток PR, документів з прогресом, оновлень у Slack або побічних чатів, щоб уникнути отримання на кінці сукупності неперевірених змін.
Інформаційна цінність цієї статті полягає в тому, що вона переозначає /goal як «механізм довгострокового управління завданнями». Коли ШІ може безперервно виконувати завдання протягом десятків або навіть сотень годин, ключові навички розробників змінюються: це вже не просто генерація коду ШІ, а визначення цілей, створення системи вимірювання, налаштування середовища виконання та фінальний огляд та аналіз. Іншими словами, програмування з допомогою ШІ переходить від «написання підказок» до «управління безперервно працюючим інженерним виконавцем».
Нижче наведено оригінал:
Ми запустили режим мети (goal mode або /goal), щоб допомогти вам забезпечити постійний прогрес Codex до досягнення конкретного результату. Після встановлення мети Codex продовжує працювати, доки мета не буде досягнута — незалежно від того, чи знадобиться це кілька годин чи кілька днів. Вже є користувачі, які змусили Codex працювати безперервно більше 120 годин для однієї й тієї ж мети.
Цільовий режим дуже потужний. Щоб максимізувати його ефект, при використанні /goal зверніть увагу на 7 речей.
Встановіть чіткі, перевіряємі стандарти
Підказки, які ви вводите при активації режиму цілі, можуть слугувати початковим запитом, але важливіше те, що вони стають критерієм завершення цієї цілі. Codex перевірятиме після кожного циклу роботи: чи було досягнуто ціль.
Тому ваша цільова підказка не повинна бути надто довгою, а повинна зосереджуватися на чіткому критерії: у яких випадках вважається, що ціль досягнута.
У більшості випадків добре визначена мета повинна містити чіткий цифровий показник, за яким модель може визначити, чи завершена вона. Наприклад:
Зменшено час на побудову та розгортання на 30%.
Перенесіть цю функцію з TypeScript у Rust і досягніть 100% відповідності тестів.
Оптимізуйте каркас додатка, щоб показник Largest Contentful Paint (LCP), що вимірює швидкість завантаження основного вмісту сторінки, був нижчим за 2,5 секунди в продакшн-середовищі.
Цей підказка не завжди повинна містити цифри, але зазвичай цифри сприяють легшому просуванню на наступних етапах.
Якщо ви ще не впевнені, як визначити мету, або хочете спочатку провести мозковий штурм цього проекту разом із Codex, вам не потрібно починати діалог із використанням режиму мети.
Codex може самостійно встановлювати цілі. Ви можете спочатку звичайно розпочати діалог, а потім, коли будете готові, дати Codex завдання встановити цілі на основі попередньої обговореної інформації.
Ви також завжди можете редагувати ціль: натисніть кнопку редагування в додатку Codex або знову використайте /goal у CLI.
Надавайте якомога більше інструкцій
Підказки, такі як «зменшити час побудови та розгортання на 30%», звучать круто й можуть натхненити Codex знайти креативні рішення. Але якщо ви вже маєте приблизне уявлення про те, де може бути проблема, такі підказки можуть відвести Codex у бік.
Тож у можливих випадках краще повідомити Codex, звідки починати пошук, які інструменти можна використовувати для досягнення мети, або надати інші підказки, щоб уникнути відхилення в неправильному напрямку.
Наприклад, мій колега @reach_vb зробив це під час експерименту: він сказав Codex, що можна використовувати браузер Chrome для доступу до Google Colab, і вказав деякі прийнятні обмеження, наприклад, під час навчання моделі Codex може самостійно генерувати набір даних.
Так само, якщо ви хочете скоротити час побудови і вже знаєте, на якому етапі витрачається більшість часу, краще спочатку вказати Codex у підказці на цей регіон.
Інший підхід — спочатку дозволити Codex виконати початкове дослідження у режимі планування (plan mode) і створити файл плану, де буде зафіксовано потенційні варіанти. Потім ваша мета може посилатися на цей план.
Зробіть прогрес вимірюваним
Якщо ваша мета дуже амбітна або Codex має багато способів поступового досягнення мети, важливо надати Codex інструменти для вимірювання прогресу.
Для деяких завдань це може бути природним. Наприклад, оптимізація часу збирання або підвищення покриття тестами, оскільки Codex зазвичай вже використовує відповідні інструменти або природним чином створює їх.
Але для інших цілей краще спочатку провести мозковий штурм із Codex: які інструменти допоможуть оцінити прогрес? Або надайте йому підказки, щоб він знав, як визначити, чи наближається до цілі. Наприклад, створіть інструмент для порівняння візуальних відмінностей між двома скріншотами або набір оцінок для агента, якого ви налаштовуєте.
Я раніше просив Codex відтворити кілька компонентів за відео, і Codex створив інструмент для порівняння знімків екрана та перевірки різниць. Пізніше він продовжив ітерувати цей інструмент, додаючи різні режими порівняння різниць.
Залежно від завдання, вам також потрібно врахувати, чи існують додаткові стандарти, які потрібно виміряти або перевірити. Інакше Codex може вважати, що завдання завершено, але на вашу думку воно ще не завершене.
Наприклад, Codex може для «піксельної відтворення» певного інтерфейсу прямо вирізати зображення з дизайну та вбудовувати його на сторінку; або щоб досягти 100% прохідності тестів, навпаки, зменшувати покриття тестами. Це не той спосіб завершення, який ви справді хочете.
Створіть реальне середовище
Щоб Codex справді досягав ефективного прогресу до своєї мети, йому потрібно працювати в достатньо реалістичному середовищі.
На практиці це означає: якщо ви хочете оптимізувати час розгортання або вирішити проблеми з затримками, Codex повинен мати доступ до середовищ розгортання та тестування, і ці середовища повинні максимально точно імітувати виробниче середовище. Тобто використовуйте той самий стек технологій, ті самі конфігураційні перемикачі та схожі бази даних.
Наприклад, ми раніше оптимізували час збирання та розгортання developers.openai.com. На той момент ми вже використовували попередній перегляд, тому Codex міг використовувати ці середовища попереднього перегляду для розгортання та перегляду відповідних журналів. Проблема полягала в тому, що наші попередні розгортання вимкнули деякі шляхи збирання порівняно з повним виробничим середовищем.
Тому Codex змушений був виконати ручне розгортання, щоб розгорнути код у середовищі, більш схожому на виробниче, щоб справді виявити проблему.
Подібним чином ви також можете дозволити Codex використовувати computer use (здатність моделі керувати реальними інтерфейсами застосунків) для тестування реальних застосунків. Щоб оптимізувати деякі проблеми з продуктивністю на iOS, @dimillian навіть використовував фізичні пристрої, щоб отримати найбільш точне тестове середовище.
Обережно встановлюйте візуальні цілі
Надати Codex візуальну мету, наприклад «100% піксельно відтворити цей інтерфейс за цією зображенням», дійсно привабливо. Але залежно від конкретних умов це також може призвести до проблем.
Якщо не надати відповідних інструкцій та обмежень, Codex може занадто глибоко зануритися в деякі деталі, ігноруючи загальну мету. Наприклад, якщо у зразку зображення містяться графічні елементи, а ви очікуєте, що Codex згенерує ці елементи — чи то SVG-іконки, чи зображення — він може витратити велику кількість зусиль на «як точно відтворити ці матеріали», а не на правильне розбиття всієї задачі.
Крім того, Codex потребує інструментів для правильного візуального порівняння. Це означає більше зображень на вхід, вищий загальний витрати токенів, але не обов’язково надає Codex простого способу виявити справді цінні можливості для покращення.
Тому зображення зазвичай краще використовувати як контекст цілі, а не єдиний критерій завершення. Ви повинні шукати інші способи, щоб Codex визначив, чи досягнуто цілі, наприклад, список функцій, специфікації реалізації, відповідність дизайновій системі тощо.
Відстеження прогресу
Якщо Codex працює на тлі протягом кількох годин або навіть днів, навіть на іншому пристрої, легко забути, на якому етапі він знаходиться та які завдання вже виконані.
Залежно від мети, я виявив, що такі способи дуже допомагають:
· Нехай Codex надсилає код на ключових етапах та відправляє його у чернетку PR. Це особливо корисно, коли ви працюєте над веб-сайтом і маєте попереднє розгортання.
· Оновіть Codex, щоб створити доставний матеріал для керівництва. Це може бути HTML-файл, який ви можете завжди відкривати в ін-апі браузері; або сторінка, розгорнута через Sites для перегляду командою; зображення прогресу, або звичайний Markdown-файл.
Вкажіть Codex активно публікувати оновлення про прогрес. Ви також можете додати це до цілей: щоб Codex надсилав оновлення до каналу Slack або іншого місця, де ви хочете фіксувати прогрес, коли досягається важливий етап.
Запитайте про статус у іншому вікні чату. Якщо ви просто хочете швидко дізнатися поточний статус, виконайте /side, щоб запустити нове бічне чат-вікно і задати питання там. Оскільки воно розгалужується від поточного треду, воно має весь контекст до поточного моменту, але має короткий час життя.
Іншим варіантом у додатку Codex є: розпочати звичайний новий чат, надавши Codex доступ до іншої цільової теми, щоб він відповів на ваші запитання. Цей підхід особливо потужний, якщо ви доручите Codex налаштувати автоматизоване завдання для регулярного перевірки прогресу.
Очистити та остаточно підтвердити результат
Чудово, мету досягнуто! Тепер можна просто передати результат команді і закінчити роботу?
Зазвичай, особливо в завданнях, пов’язаних з оптимізацією, я вважаю за краще, щоб Codex переглядав і перевіряв власну роботу. Ви можете спочатку запустити локальний аудит коду за допомогою /review, але також варто дати Codex можливість глибше проаналізувати: які шляхи він випробовував для досягнення мети? Які з них виявилися ефективними, а які — ні? Потім на основі цього очистити код.
Оскільки Codex працюватиме доти, доки не досягне мети, він може спробувати деякі методи, які мають слабкий ефект або взагалі не працюють, і ці залишкові зміни можуть залишитися у фінальному коді.
Також встановіть мету для вашого наступного завдання
Цільовими функціями Codex є надзвичайно потужний інструмент, який допоможе вам вирішити деякі з найважливіших інженерних викликів. Але він зможе ефективніше досягти мети лише тоді, коли ви надасте правильне середовище та інструкції.
Що ви робили за допомогою /goal?