Четыре типовых рабочих процесса: исследование, исправление багов, рефакторинг, написание тестов

📚 Навигация по серии: Предыдущая статья 13 · Написание промптов (Prompt) научила вас «правильно формулировать мысли» — разбивать размытые требования на точные инструкции, понятные для Codex. В этой статье мы посмотрим на практику под другим углом: 80% повседневных задач делятся на четыре категории. Для каждой категории я дам готовую схему процесса, в которую вам останется лишь подставить свои данные. Следующая статья — 15 · Права доступа, песочница и согласование.

Начнем с короткого диалога. На прошлой неделе один коллега, только что перешедший на Codex, спросил в общем чате:

«我让它修个 bug，它三下就把报错弄没了，我提交了。结果第二天同样的毛病又冒出来了，咋回事？」

我问：「你让它先找根因了吗？补回归测试了吗？」

他：「……啊？修 bug 不就是把报错弄没吗？」

В этом и кроется проблема. Он принял «исчезновение ошибки» за «решение проблемы» и не поставил на этот баг замок. На самом деле у каждой из этих четырех задач — исследования, исправления багов, рефакторинга и написания тестов — есть своя проверенная схема. Если следовать правилам, Codex выполнит работу быстро и надежно. Если ошибиться с подходом — он сдаст вам внешне готовую задачу, под которой будет заложена мина.

Предыдущая статья была посвящена общим «навыкам общения», а эта статья применит их к четырем наиболее частым сценариям. За полгода работы с Codex я выработал именно эти четыре процесса, и каждый из них учитывает особенности характера Codex: в IDE он видит открытые вами файлы, а в CLI его нужно явно направлять через символ @; он хорош в задачах, «которые может верифицировать сам», поэтому вы должны предоставить ему такую возможность.

После прочтения этой статьи вы получите:

• Готовые к использованию схемы для четырех типов задач (исследование / исправление багов / рефакторинг / написание тестов) с учетом различий работы в IDE и CLI
• Ключевые принципы «почему мы делаем именно так» для каждого процесса, чтобы не заучивать шаблоны вслепую
• Сводную таблицу по четырем типам задач (краткие таблицы в конце разделов и одна общая в конце статьи)
• Практическое руководство с ожидаемыми результатами (пройдем полный цикл исправления реального бага)

⚠️ Все упоминаемые далее конкретные команды, команды со слэшем и поведение по умолчанию соответствуют официальной документации Codex. Названия моделей и тексты интерфейса могут меняться от версии к версии — ориентируйтесь на то, что отображается у вас локально, в этой статье данные не фиксируются жестко.

---

01 Знакомство с инструментами: четыре задачи, четыре подхода

Прежде чем приступать к работе, разберитесь с «характером» каждого из четырех типов задач. Требования к Codex в них существенно различаются: если выбрать неверный подход, эффективность заметно снизится.

Аналогия: четыре кухонных ножа для разных целей. Для филе рыбы используют слайсер, для рубки ребер — тесак. Если попытаться рубить кости слайсером, лезвие просто выщербится. Исследование, исправление багов, рефакторинг и написание тестов — это четыре разных ножа. Главное — не просто «уметь пользоваться Codex», а понимать, какой нож нужен для конкретной работы.

Главное их различие лежит в одной плоскости: будет ли эта задача изменять ваш код?

Задача	Изменяет код?	Что в основном делает Codex	На что вам нужно обратить особое внимание
Исследование кодовой базы	Нет (только чтение)	Читает файлы, объясняет логику	Насколько верно он всё объясняет
Исправление багов	Да	Воспроизводит + находит первопричину + исправляет	Верно ли найдена первопричина, написан ли регрессионный тест
Рефакторинг	Да (но поведение неизменно)	Эквивалентное переписывание	Не изменилось ли поведение после правок
Написание тестов	Добавляет файлы	Генерирует тесты + покрывает граничные случаи	Все ли граничные случаи покрыты

Видите разницу? Исследование абсолютно безопасно (он только читает и не пишет), поэтому можно спрашивать смело. Исправление багов и рефакторинг требуют хирургического вмешательства, поэтому сначала заставьте его объяснить логику и лишь затем разрешайте менять код. Написание тестов находится посередине: он создает новые файлы и не трогает ваш работающий код, но вы должны следить, чтобы он не схалявил, протестировав только «успешный сценарий».

Есть также общее правило, проходящее сквозной нитью через все четыре типа задач, которое взято со страницы официальных рекомендаций по промптам — его стоит повесить на стену:

Codex 在「能验证自己工作」的时候，产出质量明显更高。给它复现步骤、验证办法、跑 lint（代码静态检查）和测试的指令——它就有据可依，而不是「看起来对」就交差。

Эта фраза — фундамент для всех четырех процессов. Последующие четыре раздела по сути отвечают на один вопрос: как предоставить Codex возможность самостоятельно верифицировать работу в каждом конкретном сценарии.

💡 Резюме одной фразой: сначала разделите четыре задачи по принципу «изменяет ли это код» — исследование безопасно и о нем можно спрашивать свободно; для изменения кода сначала требуйте объяснений, а затем разрешайте правки. И обязательно оставляйте Codex возможность для самопроверки.

На этой схеме показано сравнение всех четырех типов задач: для каждой указан ее характер (изменяет ли код), ключевой подход и главный фокус внимания. В следующих четырех разделах мы подробно разберем каждый процесс.

---

02 Исследование незнакомой кодовой базы: от общего к частному, три уровня погружения

Начнем с самого частого сценария: вы получаете совершенно незнакомый проект, и ваша первая задача — разобраться в нем.

Как это делалось раньше? Вы открывали папку, терялись среди десятков каталогов, заглядывали в каждый по очереди и через пару часов всё равно мало что понимали. Теперь в этом нет необходимости — Codex считает ваш проект рабочей областью, он может сам прочесть весь код, а вам остается лишь спрашивать.

Аналогия: визит в незнакомый торговый центр. Сначала вы смотрите на общую схему, затем находите нужный магазин и прокладываете маршрут. Вы не станете сразу бежать к случайной полке, а сначала изучите в холле: сколько в здании этажей и что где продается (общая архитектура), затем определите, где находится нужная секция товаров (поиск модуля), и наконец посмотрите, как дойти туда от входа (отслеживание процесса). От общего к частному, от плоскости к линии — таков стандартный алгоритм исследования.

Здесь важно отметить один ключевой момент, который влияет на то, как вы задаете вопросы на этих трех уровнях: расширение IDE и CLI Codex получают контекст по-разному, и в этом есть отличие от Claude Code. CLI Claude Code автоматически считывает контекст всего проекта (на основе CLAUDE.md и рабочей области), в то время как CLI Codex этого не делает — вам необходимо явно указывать файлы с помощью @, чтобы он «увидел» то, что вы хотите ему показать.

Расширение IDE автоматически добавляет открытые вами файлы и выделенный код в контекст; в CLI Codex вам обычно приходится явно прописывать пути к файлам через @ (или прикреплять конкретный файл с помощью /mention).

Проще говоря: при исследовании в IDE сначала откройте нужные файлы, выделите интересующий вас код и затем задавайте вопрос; при исследовании в CLI укажите файлы через @имя_файла. Это различие постоянно подчеркивается в официальной документации — если их перепутать, Codex просто не увидит то, что вы от него хотите.

IDE 里这么问（本地探索最快）

打开最相关的几个文件，选中你关心的那段代码（可选但强烈建议），然后问。官方给的探索提示长这样：

解释一下请求是怎么流过我选中的这段代码的。

请包含：
- 每个涉及的模块各自负责什么，简短说明
- 哪些数据被校验、在哪里校验
- 改这块时要小心的一两个「坑」

问完想快速核对它讲得对不对，再追一句让它给你可验证的清单：

把这个请求流程总结成带编号的步骤列表，然后列出涉及的文件。

CLI 里这么问（想要可滚动的文字记录 + shell 命令时）

先启动交互会话：

codex

然后用 @ 把文件点给它再问（这是 CLI 和 IDE 最大的差别——文件得你点，它不自动看）：

我要搞懂这个服务用的协议。读一下 @foo.ts @schema.ts，
讲讲它的数据结构和「请求 / 响应」流程，重点说清哪些字段必填、
哪些可选，以及向后兼容的规则。

У меня есть полезная привычка, которую я применяю при каждом знакомстве с новым проектом: на этапе исследования я ограничиваю права доступа режимом «только чтение». В разделе 12 · Команды со слэшем и горячие клавиши мы разбирали /permissions — переключитесь на Read Only (только чтение). Пусть он только изучает и объясняет, но ни при каких обстоятельствах не меняет файлы сам. Исследование должно быть абсолютно безопасным, и закрыть эту заслонку — самое надежное решение.

В прошлом году я разбирался со старым проектом на Go объемом в 30 тысяч строк и в первый же день поступил именно так: сначала в CLI через @ указал несколько входных файлов и спросил про «общую архитектуру и основные модули», чтобы понять разделение на сервисы; затем точечно выяснял «в каких файлах лежит код, отвечающий за Х»; и наконец выбрал ключевые цепочки вызовов и попросил «оформить процесс прохождения запроса в виде пронумерованного списка». Я во всем разобрался за полдня, хотя раньше на это ушло бы два-три дня.

Шаг	Расширение IDE	CLI
1. Передача контекста	Открыть связанные файлы, выделить интересующий код	Указать файлы через @имя_файла или прикрепить через /mention
2. Запрос архитектуры	«Общее описание архитектуры, за что отвечают основные модули»	То же самое (файлы уже переданы через @)
3. Поиск модуля	«В каких файлах находится код, отвечающий за [функцию Х]»	То же самое
4. Отслеживание процесса	«Проследить полный путь выполнения для [процесса Y]»	То же самое
5. Получение отчета	«Свести в пронумерованный список шагов + список файлов»	То же самое
На протяжении всей работы	Не разрешать менять код	Переключить в Read Only для блокировки изменений

💡 Резюме одной фразой: процесс исследования всегда идет по одной схеме — от общей архитектуры к конкретным файлам и затем к цепочкам выполнения (три уровня погружения). Помните особенности Codex: в IDE он видит файлы автоматически, а в CLI их нужно указывать через @. Надежнее всего держать его в режиме «только чтение» на протяжении всей работы.

---

03 Исправление багов: воспроизведение → поиск первопричины → исправление → верификация

Исправление багов — это еще один частый сценарий, и в нем легче всего допустить ошибку — коллега, о котором шла речь в начале, наступил именно на эти грабли.

Почему это происходит? Потому что новички часто просто бросают стек ошибки с фразой «исправь это», а Codex в ответ выдает решение, «которое заставляет ошибку исчезнуть». Обратите внимание: «исчезновение ошибки» не означает «решение проблемы». Зачастую это просто маскирует симптомы, в то время как первопричина остается на месте и при других условиях снова вызовет сбой.

Аналогия: течь в трубе нельзя устранить, просто подставив ведро. Если на полу лужа, спешная протирка воды или подставленное ведро (попытка скрыть ошибку) решают лишь внешнее проявление проблемы. Сначала нужно по следам воды найти поврежденный участок трубы (найти первопричину), заменить его и затем запустить воду, чтобы убедиться, что течи больше нет (верификация). С исправлением багов всё точно так же — сначала ищите место утечки, не спешите подставлять ведро.

Официальный подход к исправлению багов в Codex строится вокруг передачи ему «рецепта» воспроизведения, а не общих описаний. Официальные рекомендации говорят об этом очень четко:

由你提供的：复现步骤和约束条件——这些比一句高层描述重要得多。由 Codex 提供的：命令输出、它发现的调用点、它触发出来的堆栈信息。

Поэтому правильный процесс исправления багов состоит из четырех обязательных шагов:

1. Передача рецепта воспроизведения + подозреваемых файлов: полный стек ошибки, описание ваших действий («куда нажал, какие шаги прошел»), а также файлы, которые кажутся вам подозрительными.
2. Запуск воспроизведения и поиск первопричины: официальные рекомендации советуют прямо писать «сначала воспроизведи этот баг локально». Если он воспроизведет его, поиск первопричины будет осознанным, а не гаданием по воздуху.
3. Исправление: после подтверждения первопричины разрешайте вносить правки, напоминая о необходимости «минимизировать изменения».
4. Верификация: после внесения изменений Codex должен заново пройти шаги воспроизведения. Если есть стандартные проверки, попросите его «запустить линтер и минимальный набор связанных тестов, после чего показать команды и результаты мне».

Четвертый шаг новички упускают чаще всего, хотя именно он является самым ценным. Шаблон запроса в разделе верификации после исправления состоит всего из одной фразы:

修复之后，跑一遍 lint + 最小的相关测试套件。把用到的命令和结果报给我。

Это вешает на баг замок: после исправления тесты зеленеют, и если кто-то позже случайно вернет старый код, тесты сразу сообщат об ошибке. Баг у того коллеги ожил именно потому, что замка не было, и никто не знал, что ту строчку кода нельзя изменять.

IDE 里修 bug

打开你觉得有问题的文件，连同它最近的调用方一起打开（IDE 会自动把打开的文件当上下文），然后：

找出导致「显示已保存但没真正持久化」的 bug。
提出修复方案后，告诉我怎么在界面上验证它修好了。

CLI 里修 bug

在仓库根目录启动 Codex，给它一份完整的复现配方。这是官方给的范例结构，照着这个骨架填你自己的 bug：

codex

Bug：在设置页点「保存」，有时显示「已保存」但改动没真正生效。

复现：
1) 启动应用：npm run dev
2) 进入 /settings
3) 切换「开启提醒」开关
4) 点保存
5) 刷新页面：开关又弹回去了

约束：
- 不要改 API 的形态。
- 修复尽量小，可行的话补一个回归测试。

先在本地复现这个 bug，然后提出补丁并跑检查。

Видите, насколько детально расписан этот запрос? В нем пошагово зафиксировано, «как воспроизвести проблему», очерчены рамки («не меняй API») и явно требуется «сначала воспроизвести». Это и есть то, о чем говорит руководство: «рецепт воспроизведения важнее абстрактных описаний».

Вот готовый шаблон для исправления багов:

Bug：[一句话说清现象]
复现：[编号列出每一步，从启动到触发]
约束：[别碰什么、改动多大]
怀疑文件：[你能定位到的话，@ 点出来]
请你：先复现 → 定位根因（先别改）→ 给最小修复 → 跑 lint 和相关测试报结果。

💡 Резюме одной фразой: процесс исправления багов состоит из четырех шагов — передайте рецепт воспроизведения, воспроизведите баг локально перед поиском первопричины, примените минимальные изменения и запустите линтер с тестами для верификации. Рецепт воспроизведения намного ценнее общих слов. Без замка верификации один и тот же баг рано или поздно оживет.

---

04 Рефакторинг: сначала план → небольшие шаги → сохранение поведения → тестирование до и после

Рефакторинг — самая рискованная задача, потому что изменяется работающий код.

При исправлении бага есть четкий критерий завершения: ошибка исчезла, тесты позеленели. У рефакторинга такого критерия нет, его цель — сделать код чище, при этом внешнее поведение программы не должно измениться ни на йоту. Если поведение изменится, то под видом рефакторинга вы просто незаметно добавите баг. Это самый неприятный вид багов, так как никто не ожидает проблем от кода, который «просто привели в порядок».

Аналогия: замена деталей в поезде на полной скорости. Нельзя останавливать поезд или тревожить пассажиров. Поезд должен ехать как обычно, пассажиры не должны ничего заметить, а вы просто меняете деталь внизу на более надежную. Рефакторинг — это и есть «замена на ходу»: внешняя работа сервиса (опыт пользователей) должна оставаться абсолютно идентичной.

Рефакторинг чаще всего дает сбой по двум причинам: попытка переписать всё за один присест (слишком большие изменения не позволяют проверять их пошагово) и отсутствие страхующих тестов (проверка поведения «на глаз»). Официальный подход Codex бьет точно в цель — сначала составляем план, затем реализуем мелкими шагами.

第一步：先让它出一份重构计划

官方建议：动手前先让 Codex 产出一份重构计划。如果你装了 $plan 这个技能（skill），就显式调它（技能用 $ 前缀调用，跟切 plan 模式的 /plan 斜杠命令不是一回事）。官方将其列为内置（SYSTEM 级）技能，通常开箱即用；没出现在列表里不必强求，直接用大白话让它「先出计划别动手」也行。

官方给的计划提示长这样（看它怎么把目标和约束都写死）：

$plan

我们要重构 auth 子系统，目标：
- 拆分职责（token 解析 / 会话加载 / 权限判断分开）
- 减少循环依赖
- 提升可测试性

约束：
- 对用户可见的行为不能变
- 公开 API 保持稳定
- 给一份分步迁移计划

Получив план, не спешите соглашаться. Сначала доработайте его вместе — этот этап определяет успех всего рефакторинга:

修改一下计划：
- 明确每个里程碑具体动哪几个文件
- 加一个回滚策略

Зачем дорабатывать план? Потому что здесь работает главное правило: «разбиение сложной задачи на мелкие сфокусированные шаги позволяет Codex работать эффективнее, а вам — легче проверять diff». План с указанием файлов для каждого этапа и стратегии отката превращает масштабный рефакторинг в серию мелких безопасных изменений.

第二步：小步落地，每步都测

Когда план согласован, выполняйте его этап за этапом. После каждого шага запускайте тесты, чтобы убедиться, что поведение не изменилось. Здесь стоит придерживаться железного правила:

Никогда не доверяйте Codex рефакторинг кода, не покрытого тестами. Представьте, что вы решили быстро оптимизировать утилитарную функцию без тестов, и он «удалил» проверку граничного случая — она казалась лишней, но на самом деле обрабатывала редкий входящий запрос. Вы узнаете об ошибке только тогда, когда всё упадет в проде.

Поэтому если для кода нет тестов, первым шагом рефакторинга должно быть их написание. Сначала зафиксируйте текущее поведение с помощью тестов как снимок («snapshot»), а после рефакторинга сверьтесь с ним. Успешным признается только тот рефакторинг, при котором поведение полностью совпало. Это перекликается с логикой исправления багов: всегда давайте Codex возможность самопроверки, иначе единственным сигналом станет то, что код «выглядит правильно», а за этим как раз чаще всего и кроются проблемы.

Я сам обжегся на этом: на ранних этапах работы попросил Codex отрефакторить непокрытую тестами функцию форматирования валюты. Он мимоходом «оптимизировал» ветку обработки отрицательных чисел. Локально всё работало нормально, но при сверке в тестовой среде выяснилось, что все отрицательные значения отображаются неверно. С тех пор моё правило непоколебимо: нет тестов — сначала пишем тесты, потом рефакторим, без исключений. Пусть это немного дольше, но зато безопасно.

Шаг	Что делать	Ключевые требования
1. Получение плана	Попросить его (или навык $plan) составить план рефакторинга	Четко прописать цели и ограничения: стабильный API, неизменное поведение
2. Доработка плана	Детализировать шаги («какие файлы меняем + стратегия отката»)	Разбить на мелкие шаги, каждый из которых можно проверить отдельно
3. Написание тестов	Если тестов нет, написать их для фиксации текущей логики	Сделать снимок («snapshot») текущего поведения
4. Поэтапная правка	Реализовывать план шаг за шагом	Не разрешать переписывать всё с нуля за один раз
5. Тестирование до и после	Запускать тесты на каждом шаге, результаты должны совпадать	При малейшем изменении поведения — стоп и откат

ℹ️ Для крупного рефакторинга есть продвинутый прием: согласовать план локально, а затем отправить долгую и рутинную реализацию на параллельное выполнение в облако. Этот сценарий описан в разделе 10 · Облако Codex Cloud — локальная машина отвечает за детальное планирование и проверку, а облако выполняет основную работу. В этой статье мы сначала освоим локальный процесс, а к облачному вернемся позже.

💡 Резюме одной фразой: основа рефакторинга — «неизменность внешнего поведения». Сначала запросите пошаговый план, согласуйте файлы для каждого этапа, а затем внедряйте изменения мелкими шагами с тестированием до и после правок. Если кода нет в тестах — сначала напишите их. Попытка переписать всё разом и отсутствие тестов — главные враги рефакторинга.

---

05 Написание тестов: заставьте его покрыть граничные случаи

Написание тестов — задача, с которой Codex справляется отлично. В официальных рекомендациях прямо сказано: «следуй соглашениям, принятым в других тестах». Он изучит существующие файлы тестов и напишет новые в том же стиле и на том же фреймворке. Вам даже не придется учить его стилю. Но здесь есть ловушка: если не указать это явно, он по умолчанию будет тестировать только «успешный сценарий» (happy path — основной процесс, когда всё идет гладко).

Что значит успешный сценарий? Например, для функции разворота списка он протестирует, что [1, 2, 3] превращается в [3, 2, 1]. Это правильно, но что произойдет при пустом списке? Если в списке один элемент? Если передан null? Именно такие граничные случаи («edge cases» — экстремальные или нетипичные входные данные) чаще всего приводят к багам, и именно их тесты должны покрывать в первую очередь.

Аналогия: краш-тест автомобиля нельзя проводить, просто катаясь по прямой дороге. Настоящий тест — это лобовой удар, экстренное торможение, переворот и столкновение сзади, то есть проверка в экстремальных условиях. Проблемы всегда возникают на стыках и границах, а не при нормальной работе. Суть написания тестов — заставить Codex проверить эти границы.

В шаблонах для обоих способов работы (IDE и CLI) подчеркивается одно и то же: необходимо покрыть как happy path, так и edge cases.

IDE 里写测试（基于选区）

打开有目标函数的文件，选中定义这个函数的那几行，从命令面板选「Add to Codex Thread」（加入 Codex 线程）把这几行加进上下文，然后：

给这个函数写单元测试。遵循其他测试里已有的约定。

这里的「Add to Codex Thread」是 IDE 特有的动作——它把你选中的精确行数喂给 Codex，比用文字描述「那个函数」准得多。

CLI 里写测试（提示里点名函数 + 文件）

启动 Codex，用 @ 点出文件、说清函数名，并明确要求覆盖边界：

codex

给 @transform.ts 里的 invert_list 函数加测试。
覆盖正常路径，外加边界情况。

Сравните два варианта запросов, разница очевидна:

❌ Размытый вопрос	✅ Точный вопрос
«Напиши тесты для этой функции»	«给 @transform.ts 里的 invert_list 写测试，正常路径 + 重点覆盖空列表、单元素、null、超大列表这几种边界»
Он протестирует только успешный сценарий, показав обманчиво высокую степень покрытия	Он проверит именно те места, которые могут вызвать падение программы

Есть еще один полезный прием — попросить его найти другие упущенные сценарии. Вы можете забыть о каких-то граничных случаях, пусть он предложит их сам:

另外帮我想想还有哪些我没列到的边界情况，一并测上。

Я почти всегда добавляю эту фразу при написании тестов, и он часто находит комбинации входных данных, о которых я даже не задумывался. Однажды при написании тестов для функции интервала дат я указал пустые значения и обратный порядок дат, а он сам добавил проверки перехода на летнее/зимнее время и совпадения даты начала и конца. Я бы до этого сам не додумался.

Шаг	Расширение IDE	CLI
1. Выбор цели	Выделить строки функции → «Add to Codex Thread»	Указать файл через @имя_файла и название функции
2. Сохранение стиля	«Следуй соглашениям, принятым в других тестах»	То же самое
3. Проверка границ	«Основной сценарий + граничные случаи: [перечислить]»	То же самое
4. Поиск упущенного	«Какие еще граничные случаи я упустил? Протестируй их тоже»	То же самое
5. Запуск	Запустить тесты, при ошибках — исправлять до успешного прохождения	То же самое

💡 Резюме одной фразой: не просите просто «написать тесты» — явно заставляйте его покрывать граничные случаи (пустые значения, один элемент, null, экстремальные значения). Фраза из официального руководства «покрыв граничные случаи» имеет ключевое значение. Попросите его дополнить список упущенных проверок — успешный сценарий здесь на самом деле наименее важен.

---

06 Практика: проходим полный цикл исправления реального бага

Теория без практики мертва. Давайте проведем небольшой эксперимент, чтобы увидеть разницу своими глазами. Нам понадобится простой тестовый файл из трех строк, никак не связанный с вашими реальными проектами.

Сразу уточним различия платформ: команду создания папки mkdir в Mac / Linux можно использовать напрямую; в Windows введите те же mkdir / cd, а файл stats.py можно создать через Блокнот, вставить туда пару строк и сохранить.

Шаг 1: Создаем демонстрационный проект с багом

mkdir bug-demo
cd bug-demo

Mac / Linux 直接用 echo 写文件：

echo 'def average(numbers):
    return sum(numbers) / len(numbers)' > calc.py

Windows 用户用记事本新建 calc.py ，贴入这两行：

def average(numbers):
    return sum(numbers) / len(numbers)

Этот average расчет средних значений выглядит нормально, но при передаче пустого списка возникнет ошибка деления на ноль. Это баг, который мы должны исправить.

Ожидаемый результат: в папке bug-demo появится файл calc.py, содержащий две строки с функцией average.

Шаг 2: Запускаем Codex в корневой папке репозитория

codex

Ожидаемый результат: откроется интерактивный интерфейс Codex (TUI) с областью диалога посередине и полем ввода внизу.

Шаг 3: Используем схему исправления багов, передав рецепт воспроизведения

Введите в поле ввода (это готовый заполненный шаблон из раздела 03, учитывающий шаги воспроизведения, ограничения и требование сначала локально воспроизвести ошибку):

Bug：调用 calc.py 里的 average([]) 会崩。

复现：
1) 给 average 函数传一个空列表 []
2) 它必现 ZeroDivisionError: division by zero

约束：
- 改动尽量小，别动函数签名。

请你：先复现这个 bug，再定位根因（先别改），然后给最小修复，
最后补一个能复现这个 bug 的回归测试并跑一遍确认通过。

Ожидаемый результат: Codex сначала воспроизведет ошибку, а затем укажет на первопричину — при пустом списке len(numbers) равен 0, и деление на 0 вызывает сбой; затем он предложит diff (сравнение изменений до и после — например, возврат 0 при пустом списке или генерация более понятного исключения) и остановится в ожидании вашего одобрения. После одобрения он создаст новый файл тестов (например, test_calc.py) с тест-кейсом для проверки пустого списка.

ℹ️ Будет ли он останавливаться для запроса вашего согласия, зависит от настроек прав доступа (при авто-согласовании изменения файлов внутри рабочей области могут применяться автоматически). О логике песочницы и согласования мы подробно поговорим в следующей статье 15 · Права доступа, песочница и согласование, а пока можно следовать поведению по умолчанию.

Шаг 4: Одобряем изменения и смотрим на запуск верификации

Изучите diff и выберите «Согласиться / Yes». Codex продолжит работу и запустит только что написанные тесты — это и есть шаг «повторного запуска верификации после правок».

Ожидаемый результат: в терминале отобразятся результаты тестирования (конкретный формат зависит от используемого фреймворка):

test_calc.py::test_average_empty_list PASSED
test_calc.py::test_average_normal PASSED

Зеленый статус тестов означает, что баг успешно исправлен и на него повешен замок — если кто-то случайно вернет старый код, тесты сразу сообщат о падении.

Шаг 5: Выходим и подтверждаем, что файл действительно изменился

Выйдите из Codex (команда /exit или аналогичная) и проверьте содержимое файла в терминале:

cat calc.py

(В Windows PowerShell используйте команду type calc.py)

Ожидаемый результат: в файле calc.py появится логика обработки пустого списка для функции average, а в каталоге добавится файл тестов. Результат совпадает с одобренным вами diff — поздравляем, вы полностью прошли цикл исправления бага!

⚠️ Если на третьем шаге Codex не предложил написать тест, скорее всего, вы упустили фразу «напиши регрессионный тест» в запросе. Не пропускайте ее — проверка верификации как раз и отличает новичка от профессионала.

💡 Резюме одной фразой: пройдите полный цикл исправления бага своими руками — создайте демонстрационный файл с багом, передайте рецепт воспроизведения, дождитесь локального воспроизведения и исправления, а затем убедитесь, что тесты успешно пройдены. Освоив этот процесс, вы легко справитесь и с остальными тремя.

---

07 Итоги

В этой статье мы разделили 80% вашей повседневной работы на четыре категории и для каждой дали готовую схему процесса:

Задача	Суть процесса	Главный фокус внимания
Исследование кодовой базы	«Архитектура → где лежит код Х → отслеживание процесса»	IDE видит открытые файлы сама, в CLI их нужно указывать через @. Всегда используйте только чтение.
Исправление багов	«Рецепт воспроизведения → воспроизвести локально → минимальная правка → верификация»	Рецепт воспроизведения намного важнее общих слов, не пропускайте верификацию.
Рефакторинг	«Составление плана → доработка → пошаговые правки → тесты до и после»	Внешнее поведение должно быть неизменным, нет тестов — сначала пишем их, не переписывайте всё разом.
Написание тестов	«Основной сценарий + покрытие граничных случаев + поиск упущенного»	Обязательно требуйте покрытия граничных случаев, не ограничивайтесь только happy path.

Все четыре процесса объединены общим правилом: всегда давайте Codex возможность верифицировать свою работу самостоятельно — при исследовании просите пронумерованный список для проверки, при исправлении багов — запуск шагов воспроизведения и тестов, при рефакторинге — сверку со снимком тестов, при написании тестов — покрытие всех границ. Если у Codex есть способ проверить себя, он не сдаст работу просто потому, что она «выглядит правильно».

Теперь вы умеете: приступать к любой частой задаче без страха перед пустым экраном. Вы можете сразу запустить нужный процесс, понимая, что требовать от Codex на каждом шаге, на что обращать внимание и в чем разница работы через IDE и CLI. Эти четыре процесса станут каркасом для большинства ваших будущих задач. Со временем вы поймете, что даже самые сложные проекты состоят из комбинаций этих четырех простых сценариев.

Эти четыре схемы доказали свою эффективность при ежедневном использовании — какой бы необычной ни казалась задача, в конечном итоге она сводится к этой классике.

---

В следующей статье — 15 · Права доступа, песочница и согласование. В этой статье вы уже несколько раз столкнулись с моментами, когда Codex «останавливается в ожидании вашего одобрения» или когда мы переключали его в режим «только чтение». Но механизмы, стоящие за этим, еще не были раскрыты до конца. Как Codex определяет, в какой момент нужно спросить вашего согласия, а в какой можно действовать самостоятельно? Каковы границы его «песочницы»? В следующей главе мы подробно разберем эту триаду — права доступа, песочницу и согласование, чтобы вы могли полностью контролировать пределы его самостоятельности. И небольшой вопрос на размышление: при исправлении бага Codex останавливался перед изменением файла. Если бы вы хотели разрешить ему любые изменения внутри рабочей области и запрашивать согласие только при выходе за ее пределы, какой переключатель и в какое положение следовало бы перевести?

---

Рекомендуемое чтение

• Навыки агента (Agent Skills): упаковываем набор задач и обучаем Codex выполнять их самостоятельно
• Автоматизация и CI/CD: заставляем Codex работать в ваше отсутствие
• Облако Codex Cloud: отправляем задачу в облако и ждем результатов за чашкой кофе