Как писать промпты: попадая в самое сердце Codex
📚 Навигация по серии: Предыдущая статья 12 · Команды со слэшем и горячие клавиши научила вас правильно располагать пальцы в диалоге — переключать режимы с помощью
/, очищать контекст и проверять статус. Теперь все клавиши вам знакомы. В этой статье мы перейдем на другой уровень: пальцы знают, куда нажимать, но язык должен знать, что говорить. Для одного и того же требования разница в формулировке может привести к совершенно разным результатам работы Codex.
Говорят: «Сила инструмента программирования на базе AI зависит от модели». С этим я готов поспорить.
Скажу прямо и не очень приятно: с одной и той же моделью GPT-5 и в одном и том же репозитории тот, кто умеет формулировать запросы, решает задачу за три фразы, а тот, кто не умеет — переделывает работу по пять раз и исходит злостью. Модели уже давно достаточно сильны. В большинства случаев вас подводит не интеллект модели, а фраза, которую вы ей передаете. Если вы бросите фразу с нулевой информативностью вроде «исправь этот баг», ей придется додумывать всё самой — какой файл, какая ошибка, на что менять. Всё на основе догадок. Если она не угадает, вы будете смотреть на экран, заполненный diff, и ворчать: «Этот AI никуда не годится». Но на самом деле дело вовсе не в нем.
В прошлом году я сам попался на этом. Сервис Node выдал ошибку 500, и я просто отправил: «Интерфейс входа упал, почини», даже не прикрепив логи. Codex долго копался, выбрал баг, который показался ему наиболее вероятным, изменил три файла, но ни один из них не был настоящим источником проблемы. Настоящая ошибка крылась в переменной окружения, о которой я не упомянул, и о существовании которой он даже не подозревал. Тогда-то я окончательно понял: потолок возможностей Codex во многом ограничен тем, как я задаю вопросы.
Поэтому в этой статье я не буду учить вас заучивать шаблоны. Я научу вас понимать главное — что именно нужно знать Codex, чтобы не сбиться с пути. Поняв это, вы научитесь писать промпты сами.
После прочтения этой статьи вы получите:
- Таблицу сравнения «Плохие вопросы vs Хорошие вопросы» — следуйте ей, и количество переделок сразу снизится
- Фреймворк «Четыре элемента» для описания требований: цель, рамки, ограничения, верификация. Если какого-то элемента не хватает, Codex додумает его сам
- Способ разбиения крупных задач на мелкие шаги, с которыми Codex справится, а вам будет легко их проверить
- Официальный способ использования
/goal(режим целей) для закрепления критериев приемки в формате «работаем, пока не будет достигнут результат» (требуется предварительно включитьfeatures.goals, подробные шаги в разделе 05) - Практический эксперимент «одно требование — две формулировки», чтобы воочию увидеть разницу
⚠️ Все упоминаемые далее конкретные команды, параметры и поведение по умолчанию соответствуют официальной документации Codex. Названия моделей и тексты интерфейса могут меняться от версии к версии — ориентируйтесь на то, что отображается у вас локально, в этой статье данные не фиксируются жестко.
01 В чем именно проблема плохих вопросов
Давайте подробно разберем тот случай с неудачей. С точки зрения Codex, во фразе «Интерфейс входа упал, почини» катастрофически не хватает информации:
- Какой именно интерфейс входа? Ему придется перерыть весь проект.
- Как именно он упал? Какую ошибку выдает, при каких условиях воспроизводится? Он ничего этого не знает.
- Каким должно быть ожидаемое правильное поведение? Он может только догадываться, исходя из того, «как обычно должен работать вход».
Как рассказывалось в разделе 06 · Запуск первой задачи, работа Codex представляет собой цикл агента (agent loop) — вызов модели, чтение файлов, изменение файлов, выполнение команд, движение по кругу «мысль → действие → проверка». Официальное описание гласит, что он «в цикле запускает терминальные команды, изменяет код, выполняет проверки и пытается верифицировать свою работу». Но каким бы умным ни был этот цикл, если на первом шаге «мысль» скормить ему мусор, весь последующий цикл будет крутиться в неверном направлении.
Аналогия: адрес для курьера. Если при заказе вы напишете просто «доставить в тот жилой комплекс», курьеру придется блуждать вокруг каждого дома, он наверняка ошибется и будет вам звонить. Но если написать «ЖК XX, дом 8, подъезд 2, кв. 1503, у двери зеленый шкаф для обуви», он доставит заказ с закрытыми глазами. Чем точнее адрес, тем меньше курьер плутает. Чем более размытую фразу вы бросаете, тем больше ему приходится угадывать и тем выше вероятность ошибки. Точно так же обстоит дело с запросами к Codex: точность указанного вами «адреса» напрямую определяет, будет ли он плутать.
Давайте посмотрим на идеи сравнения, которые постоянно подчеркиваются в официальной документации. Я объединил их в таблицу (левая колонка — плохие варианты, правая — хорошие):
| Сценарий | ❌ Плохой вопрос | ✅ Хороший вопрос |
|---|---|---|
| Исправление багов | «登录接口挂了，修一下» | «用户报告会话超时后调 POST /api/login 返回 500。先写个能复现的失败测试，定位 src/auth/ 里的 token 刷新逻辑，再修，最后跑测试确认转绿» |
| Написание тестов | «给 parser.py 加测试» | «给 parser.py 的 parse_date 写测试，覆盖空字符串、非法格式两个边界，别用 mock，跑 pytest 确认通过» |
| Добавление фич | «加个导出功能» | «先看 report.py 里现有的 export_csv 怎么写的，照同样模式加个 export_json，除了已装的库别引新依赖» |
| Чтение кода | «这模块怎么写成这样» | «翻一下 transform 模块的 git 历史，总结它的接口是怎么一步步演变成现在这样的» |
Видите разницу? Хорошие вопросы делают главное: заранее снабжают Codex информацией, о которой иначе пришлось бы догадываться. Ему не нужно гадать, и он не сбивается с пути.
💡 Резюме одной фразой: плохие вопросы плохи тем, что «недостаток информации полностью воспоняется фантазией Codex», а хорошие вопросы — это когда вы заранее объясняете то, о чем ему пришлось бы догадываться.
02 Четыре элемента описания требований: цель / рамки / ограничения / верификация
В предыдущем разделе мы говорили о том, что нужно «заранее кормить его тем, о чем нужно догадываться». Но что именно скармливать? Не полагайтесь на интуицию, достаточно запомнить один фреймворк — цель, рамки, ограничения, верификация (четыре элемента). Это чек-лист, который я составил на основе бесчисленных переделок: пробегайтесь по нему в голове перед каждым запросом. Если какого-то элемента не хватает, Codex примет решение за вас.
Аналогия: техническое задание для прораба. Надежный прораб перед началом работ уточнит у вас четыре вещи: какого именно результата нужно достичь (цель), какие комнаты ремонтировать, а какие не трогать (рамки), есть ли особые требования, например, не сносить несущие стены (ограничения), и как будет приниматься работа (верификация). Если все четыре пункта ясны, он сделает всё как надо и сам завершит работу. Если упустить хоть один пункт, ему придется догадываться самому, и результат, скорее всего, вам не понравится. Формулирование требований для Codex — это передача ему такого ТЗ.
Давайте разберем, что представляет собой каждый из четырех элементов и что произойдет, если его пропустить:
| Элемент | На какой вопрос отвечает | Как задать | Что будет, если пропустить |
|---|---|---|---|
| Цель (Goal) | Что нужно сделать | «让空列表返回 0」「导出改成 JSON 格式» | Он будет угадывать ваши желания, направление работы определит случай |
| Рамки (Scope) | Что изменять, а что нет | Назовите файлы/функции: «只改 stats.py 的 average» | Он будет искать иголку в стоге сена по всему проекту и заодно изменит то, что не нужно |
| Ограничения (Constraint) | Чего нельзя касаться или нарушать | «别引新库」「保持向后兼容」「别动 migrations/» | Он сделает по-своему, и результат может вам не подойти |
| Верификация (Verification) | Как понять, что задача выполнена успешно | «写俩测试用例跑一遍」「构建退出码为 0」 | Он закончит работу, когда «покажется, что всё готово», а ловить баги придется вам |
Из этих четырех элементов «верификация» — это то, что новички упускают чаще всего, хотя именно ее нужно добавлять в первую очередь — официальные рекомендации особо выделяют этот пункт:
Codex выдает более качественный результат, когда может самостоятельно верифицировать свою работу. Указывайте шаги для воспроизведения проблемы, способы проверки функционала, команды для запуска линтера и pre-commit проверок.
Почему верификация так важна? Потому что при отсутствии выполняемых проверок сигнал «выглядит готовым» становится для Codex единственным поводом закончить работу. Если вы не зададите стандарты, он остановится на основе своего «ощущения», и принимать работу придется вам, вылавливая каждый баг вручную. Но стоит вам предоставить проверку, которая выдает четкий результат «успех / провал» — набор тестов, команду линтера, код выхода сборки — и этот цикл замкнется сам: он пишет код → запускает проверку → видит результат → если не прошел, исправляет дальше. Вам даже не нужно за этим следить.
Сейчас я пишу требования практически всегда по принципу этой «обоймы из четырех элементов». В прошлом месяце мне нужно было добавить валидацию email в проект на Python, и я написал так:
在 src/validators.py 里加一个 validate_email 函数（目标）。
只动这个文件，别碰别的（范围）。
用标准库 re 实现，别引第三方库（约束）。
写完补三个测试：user@example.com 为真、invalid 为假、user@.com 为假，
跑 pytest 确认全过（验证）。Все четыре элемента были на месте, и Codex справился с первого раза: нашел файл, написал функцию, добавил три теста, запустил их и показал мне зеленый статус прохождения. Ему не пришлось гадать ни на одном шаге, потому что я четко регламентировал все аспекты: «что сделать, где изменить, что использовать и что считать успехом».
💡 Резюме одной фразой: перед отправкой запроса прокрутите в голове четыре элемента: «цель / рамки / ограничения / верификация». Если какого-то элемента не хватает, Codex примет решение за вас. При этом «верификация» — самый важный элемент: дайте ему проверку, которая выдает результат «успех / провал», и цикл замкнется сам.
03 Рамки и ограничения: если можно прикрепить, не объясняйте словами
В рамках четырех элементов «рамки» и «ограничения» часто не требуют длинных описаний — достаточно просто прикрепить исходные данные прямо перед ним — в этом разделе мы отдельно поговорим о том, как прикреплять информацию, так как на практике это самый простой и эффективный способ.
Суть сводится к одной фразе: если информацию можно прикрепить («вставить»), никогда не описывайте ее словами. Чтение первоисточников для Codex всегда точнее, чем ваш пересказ.
Во-первых, добавляйте нужные файлы прямо в контекст. Официальное руководство по Prompting прямо советует: при отправке запроса передавайте контекст, который Codex может использовать, например ссылки на связанные файлы и изображения. Проще всего явно указать путь к файлу в запросе:
参考 src/types/user.ts 里的类型定义，给 UserService 补上类型注解Это в десять тысяч раз надежнее, чем написать: «В проекте есть файл с типом user, найди его». Для расширений IDE (IDE extension) есть бесплатный бонус: в официальной документации четко написано, что расширение IDE автоматически передает список открытых файлов и выделенный фрагмент текста в качестве контекста. Другими словами, если вы выделите несколько строк курсором в VS Code, Codex сразу поймет, о каких строках идет речь, и вам не придется описывать это словами.
Аналогия: флешка USB vs указание примерного направления для самостоятельного поиска. Указание конкретных файлов и автоконтекст в IDE похожи на подключение «флешки с данными» прямо в рабочую станцию Codex: вставил и пользуйся, нужная информация доступна мгновенно. Если же вы просто бросите: «Документы где-то в шкафу на третьем этаже, поищи сам», ему придется обыскивать весь архив, а ошибки только отнимут время. (В разделе 02 · Основные концепции аналогия с USB-портом MCP относилась к «подключению внешних возможностей», здесь же речь идет о «подключении данных» — два применения одной и той же идеи.)
Во-вторых, вставляйте ошибки целиком, не пересказывайте их. Это правило стоит довести до автоматизма: при столкновении с traceback не пишите общими словами «там упал null pointer», а вставляйте стек вызовов полностью в исходном виде:
运行测试时报了这个错，帮我定位原因：
TypeError: Cannot read properties of null (reading 'userId')
at getUserProfile (src/services/user.ts:42:18)
at async ProfileController.getProfile (src/controllers/profile.ts:15:20)Зачем вставлять его целиком? Потому что в стеке ошибок содержатся имена файлов, номера строк и цепочка вызовов. Codex сможет точно сориентироваться, перейдя по ссылке user.ts:42. Если вы перескажете ошибку своими словами, вы удалите эти ключевые координаты, и ему снова придется гадать.
В-третьих, для интерфейсных и визуальных проблем прикрепляйте скриншоты. Codex поддерживает ввод изображений: вы можете вставить или перетащить картинку прямо в область чата. В CLI также можно передавать изображения (конкретные параметры командной строки смотрите в официальной документации). Макет, скриншот ошибки или схема архитектуры — картинка всегда точнее, чем текстовое описание вроде «сдвинь кнопку немного влево».
Давайте сравним типы передаваемых данных и способы их отправки:
| Что вы хотите передать | ❌ Описание словами | ✅ Прямая передача |
|---|---|---|
| Содержимое файла | 「项目里有个处理认证的文件」 | 需求里点名 src/auth/session.ts |
| Просматриваемый код | 「就那块逻辑」 | IDE 里选中它，扩展自动带进上下文 |
| Ошибка | 「它报了个 undefined 的错」 | 把完整 traceback 原样贴进去 |
| Проблема с UI | 「按钮位置不对」 | 直接粘截图 / 设计稿 |
💡 Резюме одной фразой: рамки и ограничения чаще всего не требуют длинных описаний — указывайте конкретные файлы, выделяйте код в IDE, вставляйте ошибки целиком, прикрепляйте скриншоты. Если можно прикрепить, не объясняйте словами. Чтение оригинальных материалов для Codex всегда точнее, чем ваши интерпретации.
04 Как разбивать большие задачи: чтобы Codex мог справиться, а вы — проверить
Четыре элемента решают проблему «как понятно описать одно требование». Но некоторые задачи изначально слишком масштабны — например, «реализовать полноценную систему аутентификации пользователей» или «перевести весь проект с JavaScript на TypeScript». Если вы просто отправите такой запрос одной фразой, Codex попытается проглотить всё за раз, собьется с пути в каком-нибудь незаметном месте, и к моменту, когда вы это заметите, код превратится в кашу.
Официальное руководство высказывается на этот счет предельно ясно:
Codex справляется намного лучше, когда вы разбиваете сложную задачу на более мелкие и сфокусированные шаги. Небольшие задачи проще тестировать для Codex и легче проверять для вас. Если вы не уверены, как разбить задачу, попросите Codex предложить план (plan).
Здесь заложены две мысли, которые нужно твердо запомнить. Во-первых: разбиение на части нужно не только для Codex, но и для вас. При небольших шагах ему проще запускать тесты, а вам — изучать diff. Изменения в несколько десятков строк можно оценить одним взглядом, тогда как правку в несколько сотен строк в восьми разных файлах проверить физически невозможно (моя неудача в начале статьи произошла как раз из-за того, что я не глядя нажал «согласиться»). Во-вторых: не умеете разбивать? Не делайте это через силу, пусть Codex сначала предложит план. Это как раз перекликается с правилом из раздела 06: «для крупных задач сначала просите составить план, не позволяйте ему сразу бросаться переписывать код».
Аналогия: слона нужно есть по частям (букв. нельзя проглотить быка целиком). Даже при самом большом аппетите пищу нужно резать на кусочки: отрезал кусочек, тщательно прожевал, проглотил. Если кусок оказался плохим, его можно сразу выплюнуть. А если проглотить целиком — можно поперхнуться, даже не понимая, где именно застряло. Разбиение большой задачи на мелкие шаги — это и есть нарезание быка на кусочки: каждый кусок должен быть настолько мал, чтобы проблема была видна с первого взгляда — только тогда это безопасно.
Как разбивать? Вот готовая схема декомпозиции для «системы аутентификации», обратите внимание на уровень детализации:
大任务：实现完整的用户认证系统
拆成小步，一步一交付：
步骤 1：设计认证的数据结构（用户表 + token 表），先给方案我确认
步骤 2：实现注册功能（密码 bcrypt 加密），补测试跑通
步骤 3：实现登录功能（签发 JWT），补测试跑通
步骤 4：实现 token 校验中间件，补测试跑通
步骤 5：实现登出功能，补测试跑通Обратите внимание на два нюанса этой схемы: во-первых, каждый шаг содержит встроенную «верификацию» (дописать тесты и запустить их) — это реализация четвертого элемента из раздела 02 на каждом этапе. Во-вторых, шаг 1 — это составление плана перед началом работы. Структура данных определяет всё остальное; если ошибиться с ней, вся последующая работа пойдет насмарку. Сначала пусть он покажет чертежи, вы их оцените, ведь внести пару правок на этапе схемы гораздо дешевле, чем перестраивать уже готовую стену.
Если вы не знаете, как разбить задачу, у Codex есть два встроенных режима помощи (упоминавшихся в разделе 07), давайте разберем их разделение труда:
/plan(режим планирования): заставляет Codex сначала провести исследование и предложить решение — сначала составить план выполнения, а затем переходить к реализации. Подходит для случаев, когда вы сами не уверены, с какого бока подойти к задаче: пусть сначала распишет шаги, а вы одобрите их перед стартом.- Простая фраза «пока ничего не меняй»: если не хотите переключать режимы, можно просто добавить ограничение в обычном диалоге: «先告诉我要动哪些文件、改动思路，这一步先别改任何代码».
Какие задачи стоит разбивать и направлять в /plan, а с какими не стоит возиться? Вот критерии для принятия решения:
| Задача | Что делать |
|---|---|
| 改错别字、加一行日志、重命名变量 | 直接干，一句话能说清 diff 长啥样的，别拆别规划 |
| 给单个函数加校验、补一个测试 | 单个需求 + 四件套，一步到位 |
| 跨多文件、你不熟的代码、牵一发动全身 | 先 /plan 出方案，你审完再分步放行 |
| 「实现整个 XX 系统」「整体迁移 / 重构」 | 拆成 5~8 个自带验证的小步，逐步跑 |
Самое практичное житейское правило звучит так: «Могу ли я одной фразой описать, как должен выглядеть итоговый diff?» Если да — делайте сразу. Если запнулись — значит, задача достаточно сложная, сначала разбейте ее на части или попросите составить план. Запускать /plan ради исправления опечатки — это просто лишняя трата времени.
💡 Резюме одной фразой: не пытайтесь проглотить сложную задачу целиком — разбейте ее на небольшие шаги, каждый со своей верификацией, чтобы их можно было легко проверить с первого взгляда. Если не знаете, как разбить, используйте
/plan, чтобы Codex предложил схему. И наоборот: для простых задач, где diff понятен с одной фразы, делайте сразу без планирования.
05 Жесткое закрепление критериев приемки: режим целей /goal
В разделе 02 мы говорили, что «верификацию» нужно добавлять в первую очередь. Однако у проверки, описанной в обычном запросе, есть ограничение: она работает только в рамках текущей итерации. Codex запустит проверку один раз, и если она не пройдет, он может просто вернуть вам управление и ждать дальнейших указаний. Если же вы хотите, чтобы он «не сдавался, пока не будет достигнут результат, и итерация за итерацией вносил правки до успешного прохождения», у Codex есть специальный режим — режим целей (Goal mode).
Сначала разберем разницу с обычными вопросами. В обычном запросе критерий приемки — это «запусти и посмотри». В /goal критерий становится целью всей задачи. Официальная формулировка звучит очень прямо:
设目标时，目标文本同时充当起始提示和完成标准。Codex 用它决定下一步做什么、以及任务是不是完成了。
Другими словами, указанная вами цель — это одновременно и «что делать», и «при каких условиях считать задачу завершенной». Codex сверяется с ней после каждого шага: если цель не достигнута — продолжает работу, если достигнута — останавливается. Это отлично подходит для долгой работы с множеством шагов, где требуется четкое определение готовности, которое Codex может проверять по ходу дела.
Как использовать? Введите /goal в чате, а затем укажите вашу цель. Главное — сформулировать ее так, чтобы Codex мог сам определить, выполнена она или нет — официальное требование гласит: хорошая цель должна содержать конкретный результат, количественные показатели или тестируемые стандарты. Вот пара официальных примеров для понимания:
/goal 把这个代码库从 JavaScript 迁到 TypeScript，要求在 strict 模式下编译通过，且不出现显式的 any 类型/goal 把首页的可交互时间（TTI）降到 1 秒以内Видите разницу? «Компиляция проходит в режиме strict без any», «время TTI менее 1 секунды» — всё это стандарты, которые возвращают четкий ответ «да / нет». Если же написать абстрактное «высокое качество кода» или «более удобный интерфейс», то режим целей не сможет помочь с завершением, так как не сможет объективно оценить результат.
Несколько практических деталей работы с /goal, чтобы не наступить на грабли:
- Команда
/goalне отображается в списке? Сначала нужно включить соответствующий флаг. Официальный способ: прописатьgoals = trueв секции[features]файла~/.codex/config.tomlили просто выполнить командуcodex features enable goals(вы также можете попросить Codex выполнить её за вас).
# ~/.codex/config.toml
[features]
goals = true- Сложно сразу сформулировать цель? Официальный совет: если цель трудно определить сходу, сначала воспользуйтесь
/plan, чтобы Codex помог вам разложить всё по полочкам, а затем превратите это в цель. Вы даже можете попросить его провести для вас «интервью», чтобы помочь составить цель с четкими критериями успеха. - Цель можно скорректировать прямо во время работы. Она не фиксируется намертво: вы можете отправлять дополнительные сообщения в процессе, добавляя новые ограничения («используй эту библиотеку вместо той», «не иди по этому пути»). Если нужно узнать статус выполнения, не отвлекая его от основной задачи, используйте боковой чат (side chat), чтобы запросить отчет.
- Боитесь обрыва связи при долгой работе? Официальное предупреждение: для долгосрочных целей поставьте задачу на паузу перед отключением от сети, а затем возобновите или отредактируйте ее после восстановления соединения.
Давайте сравним верификацию в обычных вопросах и режим целей /goal, чтобы наглядно увидеть разницу:
| Верификация в обычном запросе | Режим целей /goal | |
|---|---|---|
| Продолжительность | Только на одну итерацию, после выполнения управление возвращается вам | На всю задачу целиком, не останавливается до достижения цели |
| Подходит для | Одиночных требований, простых задач в 1-2 шага | Многоэтапных сложных задач с четким определением готовности |
| Как писать критерии | «Написать пару тестов и запустить их» | Описать измеримые критерии с ответом «да / нет» |
| Требуется ли включение флага | Нет | Да, требуется features.goals = true |
💡 Резюме одной фразой: если хотите, чтобы Codex работал по принципу «не закончу, пока не добьюсь результата» и сам итеративно вносил правки до победного конца — используйте режим целей
/goal. Цель должна быть сформулирована как измеримый критерий с ответом «да / нет». Если сложно сформулировать цель сразу, воспользуйтесь сначала/plan, и не забудьте включить флагfeatures.goals.
06 Практика: одно требование — две формулировки
Теория без практики мертва. Давайте проведем небольшой эксперимент, чтобы увидеть разницу своими глазами. Нам понадобится простой тестовый файл из трех строк, никак не связанный с вашими реальными проектами.
Сразу уточним различия платформ: команду создания папки
mkdirв Mac / Linux можно использовать напрямую; в Windows введите те жеmkdir/cd, а файлstats.pyможно создать через Блокнот, вставить туда пару строк и сохранить.
Шаг 1: Создаем файл-заготовку с ошибкой (Mac / Linux)
mkdir prompt-demo
cd prompt-demo
echo 'def average(nums):
return sum(nums) / len(nums)' > stats.pyВ этой функции есть ловушка: если передавать пустой список [], то len(nums) будет равен 0, что вызовет падение из-за деления на ноль. Будем использовать ее в качестве тестового полигона.
Шаг 2: Запускаем Codex в каталоге проекта
codexОжидаемый результат: появится интерактивный интерфейс Codex с полем ввода и курсором внизу. (Если запуск не удался или запрашивается вход, вернитесь к разделу 03 · Установка и авторизация.)
⚠️ Обязательно запускайте
codexименно внутри папкиprompt-demo, не делайте этого на рабочем столе или в домашней директории. Codex считает рабочим пространством ту папку, в которой он был запущен.
Шаг 3: Сначала отправляем «плохой вопрос» и смотрим, как он будет додумывать
@stats.py 帮我改改这个函数Ожидаемый результат: Codex с большой вероятностью попытается угадать ваши намерения — возможно, добавит аннотации типов или строку документации, но он не узнает, что на самом деле вас беспокоит падение при пустом списке. Направление его работы будет зависеть исключительно от везения. Это цена отсутствия «цели / верификации»: он принимает решения за вас.
Шаг 4: Переходим к «хорошему вопросу» — задействуем все четыре элемента
@stats.py 里的 average 函数有个 bug：传入空列表时会因为除以零而崩溃。
期望行为是空列表返回 0（目标）。
只改这个函数，别动别的（范围）；用纯 Python 实现，别引库（约束）。
帮我修，并补一个测试：average([]) 应返回 0、average([2, 4]) 应返回 3，
写完跑一遍确认通过（验证）。Ожидаемый результат: на этот раз действия Codex будут предельно логичны и понятны: найдет проверку на пустой список → добавит возврат 0 в этом случае → напишет два указанных вами тест-кейса → действительно запустит тесты → покажет вам зеленый результат. Он больше не пытается гадать, чего вы хотите, потому что вы жестко зафиксировали всё: «что сделать, где изменить, что использовать и что считать успехом».
Шаг 5: Выходим и проверяем, применились ли изменения
Выйдите из Codex (клавиша выхода указана на экране) и проверьте содержимое файла в терминале:
cat stats.py(В Windows PowerShell используйте команду type stats.py)
Ожидаемый результат: в файле stats.py появится проверка на пустой список (вроде if not nums: return 0). Результат соответствует вашим требованиям из шага 4 — это значит, вы научились правильно формулировать мысли для работы с Codex.
Если сопоставить оба запроса рядом, разница будет очевидна:
| Шаг 3 ❌ Плохой вопрос | Шаг 4 ✅ Хороший вопрос | |
|---|---|---|
| Цель | Не указана, он импровизирует | Четко прописано: возвращать 0 при пустом списке |
| Рамки | Не указаны, ищет по всему файлу | Указана конкретная функция average |
| Ограничения | Не указаны, может подключать библиотеки на свое усмотрение | Чистый Python, без сторонних библиотек |
| Верификация | Нет критериев, останавливается на основе своего «ощущения» | Два конкретных тест-кейса + запуск проверки |
| Ваши ощущения | Смотрите на diff и недоумеваете: «Это не то, что мне нужно» | Всё идет по вашему сценарию с первого раза |
💡 Резюме одной фразой: для одного и того же файла и одного и того же бага плохой вопрос заставляет Codex гадать и принимать решения за вас, а хороший вопрос четко прописывает цели, рамки, ограничения и верификацию. Выполните эти два шага своими руками — эта разница нагляднее любых теоретических рассуждений.
07 Резюме в одной схеме: от требования к результату
Давайте объединить логику этой статьи на одной схеме. Путь от формулировки требования до готовой работы в исполнении Codex выглядит следующим образом:
На этой схеме следует обратить внимание на развилки. Во-первых: насколько велика задача. Сложные задачи нужно разбивать и сначала прогонять через /plan, а не пытаться проглотить целиком. Во-вторых: есть ли запускаемая верификация. Если дать ему проверку, возвращающую успех или провал, цикл замкнется сам. Если не дать — он остановится по собственному «ощущению», переложив приёмку на ваши плечи. При правильном прохождении этих развилок ваше взаимодействие с Codex станет максимально гладким.
💡 Резюме одной фразой: правильный путь работы с требованием — «разбить крупную задачу / составить
/plan→ описать требования по четырем пунктам → предоставить запускаемую проверку для замыкания цикла → проверить diff и принять код». Вам мешает не слабость модели, а то, что эти шаги не были пройдены до конца.
08 Итоги
В этой статье речь шла исключительно об одном: как сформулировать требование одной фразой так, чтобы Codex мог его точно воспринять.
В качестве заключения — если не получается запомнить всё, ориентируйтесь на эту таблицу:
| Прием | Суть одной фразой | Как применить на практике |
|---|---|---|
| Четыре элемента | Цель / рамки / ограничения / верификация. Если чего-то не хватает, он додумает сам | «Изменить average (рамки), возвращать 0 при пустом списке (цель), не импортировать библиотеки (ограничения), дописать тесты и запустить их (верификация)» |
| Прикрепляйте, а не рассказывайте | Передавайте контекст напрямую для задания рамок и ограничения | Указывайте пути к файлам, выделяйте код в IDE, вставляйте ошибки целиком, прикрепляйте скриншоты |
| Разбивайте крупные задачи | Не глотайте целиком, делите на небольшие шаги со встроенной верификацией | Если сложно разделить, используйте /plan для выработки схемы и одобряйте шаги по очереди |
| Закрепляйте критерии | Работает до тех пор, пока задача не будет выполнена | /goal + измеримая цель с результатом «да / нет» (предварительно включите features.goals) |
Теперь вы умеете: превращать размытые фразы вроде «помоги исправить» в понятные для Codex требования. Вы знаете, как описывать четыре элемента (цель, рамки, ограничения, верификация), как прикреплять исходные файлы и контекст, как разбивать сложные задачи с помощью /plan и фиксировать критерии через /goal. Эти правила общения составляют базовую «внутреннюю силу» при работе с Codex — каким бы продвинутым ни был функционал, если на входе будет плохой промпт, результат работы тоже окажется плохим.
В качестве домашнего задания подумайте над вопросом: если «четко формулировать требования» так важно, неужели вам придется каждый раз повторять правила проекта (например, «никогда не импортировать новые библиотеки в этот проект» или «тесты всегда складывать в каталог
tests/»)? Есть ли способ заставить Codex «запомнить» их раз и навсегда? (Подсказка: ответ кроется в разделе 11 · AGENTS.md.)
В следующей статье — 14 · Типовые рабочие процессы. В этой статье мы разобрали общие правила формулирования мыслей, а в следующей применим их на практике к наиболее частым сценариям работы: исследованию незнакомого кода, исправлению багов, рефакторингу, написанию тестов... Для каждого сценария вы получите готовую рабочую схему. Общие принципы ясны, теперь перейдем к конкретным приемам.