Оригінальна назва: Посібник по /goal
Автор оригіналу: @dkundel, член команди OpenAI з питань розробників
Переклад: Peggy

Редакторський закид: ця стаття від члена команди OpenAI з питань розробників Dominik Kundel підсумовує досвід використання функції Codex «goal mode / /goal». Вона обговорює не просто звичайний трюк з підказками, а рольову зміну, що відбувається у інструментах штучного інтелекту для програмування: Codex більше не є лише помічником з однократною відповіддю на команду, а починає виступати як виконавчий агент, здатний послідовно рухатися до чітко визначеної мети.

У режимі /goal важливо не те, щоб вимоги були якомога довшими і деталізованими, а щоб для Codex були встановлені ясні, перевіряємі критерії завершення. Наприклад: «скорочення часу розгортання на 30%», «повна відповідність тестового покриття», «LCP менше 2,5 секунд». Ці показники дозволяють Codex визначити, чи завершено завдання, і запобігають безкінечним спробам у разі нечітких цілей. Одночасно користувач має надати достатньо напрямків, інструментів і реального середовища, щоб Codex міг оцінювати прогрес і перевіряти результати, а не просто виконувати виглядаючу досяжною задачу у локальних або гіпотетичних умовах.

Стаття особливо наголошує, що візуальні завдання найчастіше вводять Codex у пастку деталей. Замість вимоги «100% піксельної відтворюваності» краще розбити візуальну ціль на список функцій, системні стандарти дизайну та оцінювальні показники. Для довготривалих завдань, що тривають години або дні, потрібно постійно відслідковувати прогрес за допомогою комітів, чернеткових PR, документів про прогрес, оновлень у Slack або побічних чатах, щоб уникнути отримання лише купи незворотних змін.

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

Нижче наведено оригінал:

Ми запустили режим цілей (goal mode, або /goal), щоб допомогти вам спрямувати Codex до досягнення конкретного результату. Коли ви встановлюєте ціль, Codex працює безперервно, доки ціль не буде досягнута — незалежно від того, скільки це займе годин або днів. Уже є випадки, коли Codex працював понад 120 годин за однією і тією ж ціллю.

Режим цілей дуже потужний. Щоб максимально його використати, при використанні /goal слід врахувати 7 важливих моментів.

Встановлюйте чіткі, перевіряємі стандарти

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

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

Зазвичай хороша ціль містить конкретний числовий показник, за яким модель може визначити завершення. Наприклад:

«Зменшити час розгортання і побудови на 30%.»

«Перенести цю функцію з TypeScript у Rust і досягти 100% тестового покриття.»

«Оптимізувати скелет додатку, щоб час найбільшого відображення контенту (Largest Contentful Paint, показник швидкості завантаження основного контенту сторінки) був менше 2,5 секунд.»

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

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

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

Також ви можете редагувати ціль у будь-який час: натисніть кнопку редагування у застосунку Codex або знову використайте /goal у CLI.

Надавайте якомога більше вказівок

Наприклад, підказка «Зменшити час розгортання і побудови на 30%» звучить круто і може допомогти Codex знайти креативні рішення. Але якщо ви вже приблизно знаєте, де може бути проблема, така підказка може відвести його в неправильному напрямку.

Тому, за можливості, краще повідомити Codex, з чого почати пошук, які інструменти використовувати або дати інші підказки, щоб уникнути помилкового шляху.

Наприклад, мій колега @reach_vb у одному з експериментів так і зробив: він сказав Codex, що можна використовувати Chrome для входу у Google Colab і пояснив деякі допустимі обмеження, наприклад, що під час тренування моделі він може самостійно генерувати датасети.

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

Ще один підхід — дати Codex у плановому режимі (plan mode) зробити попереднє дослідження і створити плановий файл для запису потенційних рішень. Потім цю ціль можна посилати, посилаючись на цей план.

Забезпечуйте вимірюваність прогресу

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

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

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

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

Зображення: скріншот, згенерований Codex, для візуального порівняння двох кадрів.

Залежно від задачі, потрібно враховувати додаткові стандарти або критерії, що потрібно вимірювати або перевіряти. Інакше Codex може вважати, що завдання завершене, хоча насправді ще ні.

Наприклад, щоб «відтворити піксель у піксель» UI, Codex може обрізати дизайн і вставити його у сторінку, або для досягнення 100% тестового покриття зменшити обсяг тестів. Це не те, що ви справді хочете отримати.

Створюйте реальне середовище

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

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

Наприклад, ми раніше працювали над оптимізацією часу побудови і розгортання на developers.openai.com. Ми вже використовували попередні версії розгортання, тому Codex міг використовувати ці середовища для тестування і перегляду логів. Але проблема була в тому, що наші попередні середовища відрізнялися від повноцінного виробничого, зокрема, деякі шляхи побудови були вимкнені.

Тому Codex довелося вручну розгортати код у більш схожих на продуктивні середовищах, щоб знайти проблему.

Аналогічно, ви можете дозволити Codex використовувати можливості роботи з реальним інтерфейсом (computer use), щоб тестувати реальні застосунки. Щоб покращити продуктивність на iOS, @dimillian навіть використовував фізичні пристрої для максимально точного тестування.

Обережно з візуальними цілями

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

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

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

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

Відстежуйте прогрес

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

Залежно від цілі, я знайшов корисними такі способи:

· Дозволити Codex комітити важливі зміни і пушити їх у чернетковий PR. Це особливо корисно для сайтів із попередніми версіями або попередніми збірками.

· Оновлювати звіт про прогрес для керівництва. Це може бути HTML-сторінка, яку можна відкривати у браузері, або сторінка, розміщена через Sites для команди, або згенерована діаграма прогресу, або просто Markdown.

· Вказати Codex автоматично публікувати оновлення у Slack або іншому каналі, коли досягаються важливі етапи.

· Запустити інший чат, щоб швидко дізнатися статус. Можна запустити /side для створення побічного чату і там запитати. Це дає короткий контекст, але швидко закінчується.

· Або відкрити новий звичайний чат і попросити Codex прочитати інший потік цілей і відповісти на питання. Або налаштувати автоматичний періодичний моніторинг прогресу — це особливо корисно.

Очистіть і підтвердіть результат

Чудово, ціль досягнута! Тепер можна просто передати результати команді і завершувати роботу?

Зазвичай, особливо для задач з оптимізації, корисно попросити Codex переглянути і проаналізувати свою роботу. Можна запустити /review для локального огляду коду, але також корисно, щоб Codex глибше подумав: які шляхи досягнення цілі він пробував? Що спрацювало, а що ні? І на основі цього — очистити код.

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

Задайте ціль і для наступного завдання

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

Що ви вже робили з /goal?

[Посилання на оригінал]

Клікніть, щоб дізнатися про вакансії в Rhythm BlockBeats

Приєднуйтесь до офіційної спільноти Rhythm BlockBeats:
Telegram підписка: https://t.me/theblockbeats
Telegram група: https://t.me/BlockBeats_App
Офіційний аккаунт у Twitter: https://twitter.com/BlockBeatsAsia