Как дать Codex несколько задач и не смешать результаты в одну кашу
Когда Codex получает одну небольшую задачу, все выглядит просто. Но настоящая работа редко идет одной линией. Нужно одновременно проверить старую статью, подготовить правку сайта, собрать отчет, попробовать новую идею, не сломав текущую версию. Если все это делать в одном потоке, результат быстро превращается в кашу: непонятно, какая правка к какой задаче относится и что вообще можно принимать.
В официальной документации OpenAI по Worktrees Codex app описывает worktree как отдельную рабочую копию репозитория, созданную из local checkout. В документации отдельно есть понятие handoff: Codex берет на себя Git-операции, нужные для безопасного переноса работы между Local и Worktree. А в разделе Review показано, как смотреть изменения, оставлять комментарии и решать, что сохранить.
Для программиста это звучит как Git. Для владельца проекта - как способ не смешивать ответственность.
Worktree - это отдельный стол для рискованной идеи
Представьте офисный стол. На одном лежит текущий договор, который уже почти готов к отправке. На втором - черновик новой версии. На третьем - рискованный эксперимент. Если смешать все бумаги, потом невозможно понять, что было финальным документом, а что пробой.
Worktree делает похожую вещь для проекта. Codex может пробовать изменение отдельно от основного рабочего места. Это полезно, когда задача может затронуть много файлов, когда результат еще не точно нужен или когда параллельно идет другая работа.
Простое правило:
| Режим | Когда использовать | Что проверяет человек |
|---|---|---|
| Local | маленькая понятная правка рядом с текущей работой | что изменилось прямо в рабочей папке |
| Worktree | эксперимент, отдельная задача, риск смешивания | принять ли изолированный результат |
| Handoff | нужно перенести поток между Local и Worktree | не потерялся ли контекст и код |
Это не значит, что каждый пользователь должен знать Git-команды. Важно понимать принцип: Codex не должен сваливать разные задачи в одну корзину.
Review превращает результат в приемку
Даже если Codex сделал работу в отдельном worktree, ее все равно нужно принять. Здесь важен review pane. OpenAI описывает его как место, где можно понять, что Codex изменил, дать точную обратную связь и решить, что оставить.
Для не-программиста review - это не обязательно чтение каждой строки кода. Это приемочная карта:
- Какая задача была поставлена?
- Какие файлы или разделы изменились?
- Есть ли изменения, которые не относятся к задаче?
- Есть ли риск для публикации, данных, доступа или клиента?
- Что принять, что вернуть на доработку, что отклонить?
Если Codex не может объяснить изменения простым языком, результат не готов. Даже хороший diff должен быть сопровожден смыслом: "я изменил это, потому что задача была такая; вот что проверить; вот где риск".
Как ставить параллельные задачи
Плохая постановка:
Сделай все правки по проекту, заодно проверь сайт, перепиши статью и улучши визуал.
Хорошая постановка:
Создай отдельный поток для проверки статьи. Не трогай публикацию. Верни список изменений и риск. Второй поток - только для сайта: проверь главную страницу и карточки. Третий поток - только идея новой обложки, без Ghost и соцсетей.
Чем точнее разделены задачи, тем легче принимать результат.
Рабочая карточка параллельной задачи
Перед тем как запускать несколько потоков Codex, заполните короткую карточку:
| Поле | Пример |
|---|---|
| Название потока | "проверка статьи", "эксперимент с layout", "SEO-обновление" |
| Что можно менять | только draft.md, только CSS, только таблицу источников |
| Что нельзя менять | публикацию, очередь, доступы, платежи, клиентские данные |
| Критерий результата | diff, список рисков, preview, отчет |
| Проверка | кто смотрит и по каким пунктам |
| Решение | принять, вернуть, закрыть, перенести в основной контур |
Эта карточка особенно полезна, когда Codex работает долго или параллельно. Она не дает агенту смешать "исследовал", "изменил", "проверил" и "опубликовал" в одно слово "готово".
Что остается человеком
Codex может открыть отдельный worktree, сделать изменения, показать diff, помочь с review и даже ответить на inline comments. Но человек решает, что входит в основной контур. Это принципиально.
Если вы не отделяете эксперимент от принятого результата, вы начинаете управлять проектом по ощущениям. Кажется, что агент "что-то сделал", но непонятно, что именно вошло в работу. Worktrees и review возвращают простую дисциплину: каждая задача живет отдельно, каждое изменение видно, каждое решение фиксируется.
Поэтому worktrees - это не техническая роскошь. Это способ сказать Codex: "Пробуй здесь. Покажи результат. А я решу, что попадет в проект".
