Люди часто підходять до мене і запитують: «Чи може Codex це зробити?»
А потім наступні дві-три хвилини пояснюють, що саме означає «це»: проблему, яку вони хочуть вирішити, що має робити застосунок і як виглядав би хороший результат. Іноді вони розповідають, що вже пробували, що спрацювало, а що ні.
І я думаю: вам варто просто сказати все це Codex.
Все це пояснення вже було запитом.
Промпт-інжиніринг мертвий. І не мертвий.
Якщо промпт-інжиніринг означає вивчення таємної мови перед тим, як попросити про допомогу, то я вважаю, що він здебільшого мертвий. Особливо з моделями міркувань, зазвичай немає магічного ключового слова, яке відкриває правильну відповідь. Я не думаю, що варто витріщатися на порожній екран годину, намагаючись створити ідеальний запит.
Але він також не мертвий, тому що чіткість все ще має значення. Неоднозначність ускладнює роботу для Codex так само, як і для будь-кого іншого. Якби я переплутав абзаци в цій статті або перейшов на мову, якої ви не розумієте, її було б важче сприймати. Навіть час має значення: «Я спробував це» — це не те саме, що «Я хочу, щоб ти спробував це».
Чого ви насправді хочете? Який контекст важливий? Які обмеження повинен знати Codex? Як виглядав би хороший результат?
Говоріть з Codex так, як ви б говорили з кимось, з ким працюєте.
Я люблю починати з результату: яка моя мета? Це також ширший зсув з агентами. Замість того, щоб прописувати кожен крок і запитувати кожен проміжний результат, я можу пояснити, чого хочу досягти, встановити межі та дозволити Codex допомогти знайти шлях.
Скажіть неохайну версію
Більшість ідей не приходять у вигляді чистих специфікацій. Вони звучать більше так:
«Гаразд, у мене є всі ці файли. Формати трохи відрізняються. Мені потрібен звіт до п'ятниці. Я думаю, що більшість даних там є, але цей один експорт трохи дивний…»
Це нормально. Просто скажіть це.
Коли ви базікаєте, ви часто даєте Codex більше сигналів. Ви згадуєте деталь, яку б вилучили з відшліфованого запиту. Ви передумуєте на півдорозі. Ви кажете: «Взагалі-то, ні, я цього не хочу».
Зміна думки розкриває те, чого ви не хочете. Відхилення може виявити приховане обмеження. Роздуми вголос допомагають і вам, і Codex зрозуміти завдання.
За допомогою голосового набору ви натискаєте мікрофон, проговорюєте бриф, перевіряєте транскрипт і надсилаєте його.
Якщо це доступно у вашій системі, голосовий режим йде далі. Ви можете уточнювати, перебивати, змінювати напрямок або починати нову лінію думки. Ви також можете використовувати його для координації роботи: почати інше завдання, перевірити існуюче, запитати, що заблоковано, або спрямувати роботу, яка вже виконується.
Буду чесним: розмовляти з комп'ютером все ще трохи дивно. В офісі я тримаю в руці мікрофон DJI. Навушники з мікрофоном теж підходять.
Але це краще, ніж дозволити гарній ідеї залишитися застряглою у вашій голові, тому що ви не знайшли ідеального способу записати її.
Задайте безглузде питання
Існує знайома мемна версія цього:
«Codex, зроби мені мільярдний B2B SaaS. Не помились. Зроби це з одного разу.»
Ви не створите мільярдну компанію з одного разу. Але розмова може виявити щось реальне: проблему, яку ви розумієте, когось, хто з нею стикається, і перший крок, який варто зробити. Це старе добре вирішення проблем: розбити складну проблему на менші, досяжні кроки.
Цінність полягає в самій розмові. Вона може перевести вас від безглуздого питання до чогось, що ви можете реально запустити сьогодні.
Кілька практичних способів почати
Якщо ідея все ще розмита, попросіть Codex взяти у вас інтерв'ю:
«Я все ще розбираюся з цим. Став мені по одному питанню за раз. Натискай на все нечітке, потім допоможи перетворити це на щось конкретне.»
Або будьте дуже прямолінійними:
- Які мої сліпі зони?
- Через що це може провалитися?
- Про що я занадто багато думаю?
- Яка найменша корисна версія?
- Що тобі потрібно знати, перш ніж почати?
Режим планування Codex корисний, коли вам потрібна більша структура. Він може ставити уточнюючі питання, пропонувати варіанти та опрацьовувати підхід до реалізації.
Але я не думаю, що кожна ідея повинна починатися там. Іноді відкрита розмова протікає краще. Ми не ділимо кожну розмову з колегою на планування та виконання. Спочатку поговоріть. Дозвольте формі проблеми проявитися. Переходьте до плану, коли робота цього потребує.
Запитайте Codex про Codex
Є друге значення фрази «говорити з Codex»: ставте йому питання про нього самого.
Запитайте, що він може бачити. Запитайте, який режим має сенс. Запитайте, які інструменти доступні. Запитайте, як він планує перевіряти свою роботу.
Якщо доступний навик OpenAI Docs, попросіть Codex перевірити документацію. Ви також можете переглянути публічний репозиторій Codex або клонувати його та попросити Codex пояснити, як він працює.
Якщо Codex не влучає в ціль, запитайте чому
«Ти зробив це, але я насправді хотів те. Де ми помилилися?»
Можливо, ваш запит був неоднозначним. Можливо, файл AGENTS.md або навик спрямували роботу в іншому напрямку. Можливо, плагін, дозвіл або інструмент були недоступні. Можливо, Codex зробив неправильне припущення.
Запитайте, що він зрозумів, які інструкції виконав, що не спрацювало і що ви могли б пояснити чіткіше. Codex часто може використовувати все ще доступний контекст, щоб допомогти перевірити саму співпрацю.
Там, де це доступно, ви можете відкрити бічний чат за допомогою /side, поки Codex працює, не перериваючи основний чат. Запитайте, що зроблено, що залишилося, що заблоковано і як ви можете допомогти. Ви, по суті, його менеджер на щоденній нараді.
Якщо ви хочете, щоб щось пояснили простою мовою, виділіть текст у транскрипті та виберіть «Запитати в бічному чаті».
Витягніть ідею зі своєї голови
Під час автомобільної подорожі я почав говорити з Codex про презентацію. Це стало структурою для виступу та цієї статті. Я проговорив сиру ідею, кілька разів передумав і продовжив.
Часто найбільшим блоком є не модель. Це ми. Ми думаємо, що ідея ще не готова. Ми не знаємо правильного запиту. Ми хвилюємося, що не пояснили її належним чином.
Інтерфейс стане кращим. І якщо у вас є ідеї, як має відчуватися розмова з Codex, я щиро хотів би їх почути.
Просто запитайте Codex.
