Как максимально эффективно использовать Codex: инструменты, потоки и автоматизация (англо-китайская версия)

*Как получить максимум из Codex*

Источник: Официальное руководство OpenAI Codex | англо-китайская версия

Most developers first use coding agents for code: inspect a repository, make a diff, run tests, and open a pull request. That's still the center of gravity for Codex. But much of the work on a computer is already mediated by code: executing shell commands, browsing web pages, calling APIs, exporting documents, responding to events, and triggering automations. As those surfaces become available to Codex, it starts to feel less like a coding assistant in the narrow sense and more like a system for getting computer work done.

Большинство разработчиков сначала используют код-агентов для работы с кодом: проверяют репозиторий, создают diff, запускают тесты и открывают pull request. Для Codex это по-прежнему остаётся центром внимания. Но большая часть работы на компьютере уже опосредована кодом: исполнение shell-команд, просмотр веб-страниц, вызовы API, экспорт документов, реагирование на события и запуск автоматизаций. По мере того как эти поверхности становятся доступными для Codex, он всё меньше выглядит как узконаправленный помощник по коду и всё больше — как система для выполнения вычислительной работы.

Codex app makes that shift concrete. A thread can keep context, use tools, surface artifacts, and continue across prompts instead of resetting after each exchange.

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

Getting more out of Codex means using these capabilities together:

Полностью использовать Codex значит сочетать эти возможности вместе:

• durable threads that preserve context
• voice, steering, and queuing while the user is still in the loop
• browser, computer-use, MCP servers, and connectors that let Codex act beyond a repo
• thread automations and Goals that continue the work while the user is away
• the side panel, where users can review code, documents, decks, and other artifacts

• устойчивые потоки, которые сохраняют контекст
• голосовой ввод, корректировка хода и постановка задач в очередь, пока пользователь остаётся вовлечённым
• браузерные инструменты, управление компьютером, MCP-серверы и коннекторы, которые позволяют Codex работать за пределами репозитория
• автоматизации потоков и Goals, которые продолжают работу, когда пользователя нет рядом
• боковая панель, где пользователи могут просматривать код, документы, презентации и другие артефакты

1. Устойчивые потоки / Durable Threads

Durable threads: Long-running Codex threads that preserve working context across repeated sessions.

Устойчивые потоки: долгоживущие потоки Codex, сохраняющие рабочий контекст между повторными сессиями.

Pinned threads are one way to keep durable threads close at hand. They're useful for recurring work streams such as:

Закреплённые (pinned) потоки — один из способов держать устойчивые потоки под рукой. Они полезны для повторяющихся цепочек задач, например:

• a Chief of Staff thread
• a release thread
• a documentation review thread
• a thread dedicated to external monitoring

• поток Chief of Staff
• поток релизов
• поток обзора документации
• поток для внешнего мониторинга

These are persistent workspaces, not short chats. Codex can revisit them over time, preserving prior decisions, preferences, and working context that would otherwise need to be rebuilt from scratch.

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

Pinned-thread shortcuts make this practical. Command-1 through Command-9 jump directly into saved threads.

Сокращения для закреплённых потоков делают это практичным. Команды Command-1 ... Command-9 сразу переключают на сохранённые потоки.

2. Голосовой ввод / Voice Input

Voice input is valuable because it captures the rough version of a thought before it's compressed into polished prose.

Голосовой ввод ценен тем, что фиксирует черновую форму мысли до того, как она превращается в выверенный текст.

Codex has built-in voice input. It works especially well for vague starting points that are natural to say but awkward to type:

У Codex есть встроенный голосовой ввод. Он особенно хорошо работает для расплывчатых начальных формулировок, которые естественно произнести вслух, но неудобно набрать:

I think someone named Ben mentioned this in Slack.

I do not remember the details.

Please go look.

Я думаю, что некий Бен упоминал это в Slack.

Я не помню деталей.

Проверь, пожалуйста.

For an agent that can search, gather context, and report back, that's often enough.

Для агента, который может искать, собирать контекст и отчитываться, этого часто бывает достаточно.

It also works well for a two- or three-minute thought dump before the task is fully formed.

Это также хорошо подходит для двух- или трёхминутного «вылета мысли», когда задача ещё не оформлена до конца.

Transcripts work the same way. A raw meeting transcript or dictated planning note often provides better source material than a short summary because it preserves uncertainty, emphasis, and unfinished lines of thought.

То же относится и к расшифровкам. Черновой стенограмме встречи или продиктованной заметке по плану часто лучше, чем краткое резюме, потому что она сохраняет неопределённость, акценты и незаконченные мысли.

3. Корректировка хода и постановка в очередь / Steering and Queuing

Voice becomes even more useful when paired with explicit control over an active task.

Голос становится ещё полезнее, когда его используют вместе с явным контролем над активной задачей.

Steering: Interrupting an in-flight Codex task with new direction before the current step finishes.

Steering (корректировка хода): прерывание выполняемой задачи Codex новым указанием до завершения текущего шага.

Steering is useful when the agent is heading the wrong way and needs a correction before it finishes. During a website review, for example, the user can interrupt the work while annotating the surface in the side panel:

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

make this smaller

the spacing between these two elements feels off

this copy is wrong

Сделай это меньше

Расстояние между этими двумя элементами кажется неправильным

Этот текст написан неверно

Queuing: Adding work for Codex to do after the current step completes.

Queuing (постановка в очередь): добавление следующей задачи для Codex после завершения текущего шага.

Queuing is different. It doesn't interrupt the task in progress. It adds the next task to the line. A user might say:

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

Once the work is done, send the preview link to the reviewer in Slack.

Когда работа будет завершена, отправь ссылку на предпросмотр ревьюеру в Slack.

Steering changes what Codex is doing now. Queuing changes what should happen next. Both keep the user close to the work while it's unfolding.

Steering меняет то, что Codex делает прямо сейчас. Queuing меняет то, что должно произойти дальше. Оба подхода удерживают пользователя в процессе в реальном времени.

4. Инструменты и охват / Tools and Reach

Once a thread has continuity, the next question is what it can act on. Codex can move outward in layers:

Когда поток стал непрерывным, следующий вопрос — на чём именно он может действовать. Codex может расширять охват по слоям:

• $browser for the in-app browser in the side panel, where Codex can inspect and annotate web surfaces
• @chrome for signed-in browser state and Chrome-based workflows
• @computer for work that only exists through a desktop GUI

• $browser для встроенного браузера в боковой панели, где Codex может просматривать и аннотировать веб-интерфейсы
• @chrome для задач, зависящих от состояния вошедшего в систему Chrome и его рабочих процессов
• @computer для задач, существующих только в графическом интерфейсе настольной среды

$browser fits side-panel browser review. @chrome fits signed-in browser work that depends on the user's Chrome context. @computer fits tasks that only exist through a desktop GUI.

$browser подходит для ревью веб-страниц в боковой панели; @chrome — для задач со сессиями и авторизацией в браузере Chrome; @computer — для задач, которые можно выполнить только через настольный GUI.

MCP servers and connectors extend the same idea into the rest of a workflow. Slack, Gmail, and Calendar matter because many important tasks first appear as messages, inbox items, or scheduling problems before they ever become code.

MCP-серверы и коннекторы расширяют ту же идею на остальную часть рабочего процесса. Slack, Gmail и Calendar важны потому, что многие значимые задачи сначала появляются как сообщения, элементы почтового ящика или вопросы с расписанием, и только потом превращаются в код.

Skills make repeated workflows reusable. Once a workflow proves useful, package it as a skill so Codex can run it again without relearning the routine from scratch.

Skills делают повторяющиеся рабочие процессы повторно используемыми. Если рабочий процесс оказался полезным, его стоит оформить как skill, чтобы Codex мог запускать его снова без полного переобучения маршрута с нуля.

5. Работать везде / Work from Anywhere

The Codex mobile app changes when the user has to be at the desk. A task can start on a Mac where the files, permissions, and local setup already live, then continue while the user checks in from a phone.

Мобильное приложение Codex меняет ситуацию, когда пользователь не должен находиться за своим компьютером. Задача может стартовать на Mac, где уже есть файлы, разрешения и локальная конфигурация, а затем продолжаться, когда пользователь подключается с телефона.

That matters in small moments. Someone can leave the desk while Codex runs a longer task, answer a question from outside, approve the next step, or redirect the thread before they get back. The local environment stays in place; the user doesn't have to.

Это особенно важно в коротких промежутках времени. Пользователь может уйти от рабочего места, пока Codex выполняет длительную задачу, ответить на вопрос снаружи, утвердить следующий шаг или перенаправить поток ещё до возвращения. Локальная среда остаётся на месте; пользователю не нужно переподготавливать всё заново.

6. Автоматизация задач / Automations

Automations run Codex work on a schedule. Use a scheduled automation when the recurring job should start fresh from a workspace, such as a daily report or a regular repository check. Use a thread automation when the schedule should return to an active conversation with its running context.

Автоматизации запускают работу Codex по расписанию. Используйте плановую автоматизацию, когда повторяющаяся задача должна стартовать заново из рабочего пространства, например ежедневный отчёт или регулярную проверку репозитория. Используйте автоматизацию потока, когда по расписанию нужно возвращаться в активный диалог с сохранённым контекстом выполнения.

Thread automations: Heartbeat-style recurring wake-up calls that return to the same Codex thread on a schedule.

Потоковые автоматизации: периодические «heartbeat»-срабатывания по расписанию, которые возвращают Codex в один и тот же поток.

Pinned threads are useful, but they still wait for the user to return. A thread automation can check on something every few minutes or every few hours, continue until it meets a condition, and adjust the cadence over time.

Закреплённые потоки полезны, но всё равно ждут возвращения пользователя. Потоковая автоматизация может проверять что-то каждые несколько минут или часов, продолжать до выполнения условия и со временем корректировать частоту.

A Chief of Staff thread might run every 30 minutes:

Поток «Chief of Staff» может выполняться каждые 30 минут:

Every 30 minutes, check Slack and Gmail for unanswered messages that need my attention.

Help me prioritize what matters most.

If someone asks me a question, research the answer as deeply as you can and draft a reply for me, but do not send it.

Каждые 30 минут проверяй Slack и Gmail на предмет непрочитанных сообщений, требующих моего внимания.

Помоги расставить приоритеты по важности.

Если кто-то задаст мне вопрос, как можно глубже изучи ответ и подготовь черновик ответа, но не отправляй его.

When the user returns, the expensive part of gathering context is often done. The human still decides what gets sent.

Когда пользователь возвращается, трудоёмкая часть сбора контекста уже обычно сделана. Человеческое решение остаётся за тем, что именно отправлять.

Thread automations also fit feedback loops. A thread automation can watch pull request comments, Google Docs comments, or Slack replies and keep the surrounding work moving while the user is away.

Потоковые автоматизации также подходят для циклов обратной связи. Они могут отслеживать комментарии к pull request, комментарии в Google Docs или ответы в Slack и поддерживать развитие связанной работы, пока пользователь отсутствует.

Consider an animation workflow where a reviewer shares a video in Slack. A thread automation can check the thread on a schedule, render an updated version when comments arrive, and reply in the same thread tagging the reviewer. If one integration can't complete the final upload, desktop automation can finish the step through the GUI.

Представьте рабочий процесс анимации, где рецензент делится видео в Slack. Потоковая автоматизация может по расписанию проверять эту ветку, при появлении комментариев собирать обновлённую версию и отвечать в той же ветке, упоминая рецензента. Если какая-то интеграция не может завершить финальную загрузку, настольная автоматизация доведёт шаг до конца через GUI.

The loop spans Slack for feedback, the codebase for rendering, and desktop automation for the final upload.

Контур охватывает Slack для обратной связи, кодовую базу для рендеринга и настольную автоматизацию для финальной загрузки.

7. Цели / Goals

Goals are most powerful when the task has a real finish line that the agent can keep pushing toward. A weak goal is:

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

Goals: Longer-running Codex tasks with a finish line the agent can keep working toward over time.

Goals: долгосрочные задачи Codex с достижимой контрольной целью, к которой агент может последовательно двигаться со временем.

Implement the plan in this Markdown file.

Реализуйте план, описанный в этом Markdown-файле.

A stronger goal has a measurable success criterion.

Более сильная цель имеет измеримый критерий успеха.

For example, an engineer might migrate an internal tool from Python to Rust by setting up the new directory, defining the goal, and making the finish line explicit: the new implementation isn't done until the unit tests pass.

Например, инженер может мигрировать внутренний инструмент с Python на Rust, создав новый каталог, определив цель и явно обозначив финишную точку: новая реализация считается незавершённой, пока не пройдут unit-тесты.

A goal combines ongoing execution with a verifier. The user defines the outcome, the stopping condition, and the signal that says whether Codex is getting closer.

Цель объединяет непрерывное выполнение с валидацией. Пользователь задаёт ожидаемый результат, условие остановки и сигнал, показывающий, приближается ли Codex к цели.

Useful verifiers include:

Полезные верификаторы включают:

• a test suite
• a benchmark
• a bug reproduction
• a validation matrix
• an end-to-end workflow that must keep passing

• тестовый набор
• бенчмарк
• воспроизведение бага
• матрица валидации
• end-to-end workflow, который должен стабильно проходить

Ambition matters, but without verification it's just a wish.

Амбиции важны, но без верификации это остаётся просто желанием.

8. Боковая панель / The Side Panel

The side panel keeps the work beside the conversation that produced it. Instead of exporting an artifact and switching contexts, the user can review it in place. The output might be code, but it might also be a deck, a PDF, a browser page, a table, or another artifact created along the way.

Боковая панель держит результат рядом с тем диалогом, в котором он был создан. Вместо экспорта артефакта и переключения контекста пользователь может сразу его просмотреть. Выходные данные могут быть кодом, но также и презентацией, PDF, веб-страницей, таблицей или другим артефактом, созданным в процессе.

It supports four jobs especially well:

Она особенно хорошо подходит для четырёх задач:

• Inspect artifacts
• Annotate what needs to change
• Operate web surfaces
• Review changes

• Просмотр артефактов
• Аннотация того, что нужно изменить
• Работа с веб-интерфейсами
• Ревью изменений

The side panel lets users review Markdown, spreadsheets, data tables, documents, and slides in place. They can inspect, mark up, and revise artifacts without breaking the loop.

Боковая панель позволяет просматривать Markdown, таблицы, документы и слайды прямо на месте. Пользователь может проверять, помечать и дорабатывать артефакты без разрыва рабочего цикла.

Annotations

The deck or PDF can stay open beside the thread that produced it, ready for direct review and repair.

Презентация или PDF могут оставаться открытыми рядом с потоком, который их создал, для непосредственного просмотра и правок.

Sheets in Codex

The in-app browser lets Codex inspect a rendered page, control it, and respond to annotations directly on the surface under review. Comments on a page or artifact stay inside the working loop instead of becoming a separate handoff.

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

The web becomes both output and control surface. Codex can build an artifact, open it in the side panel, inspect it, debug it, and keep refining the same object in place.

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

These surfaces work especially well:

Эти поверхности особенно хорошо работают для:

• index.html for lightweight static artifacts
• Storybook for UI review
• Remotion Studio for programmatic animation
• browser-based slide decks for presentations
• data apps for analysis workflows

• index.html для лёгких статических артефактов
• Storybook для UI-ревью
• Remotion Studio для программной анимации
• браузерные слайды для презентаций
• data-приложения для рабочих процессов анализа

A single index.html file can become a durable interactive artifact with no server required. Thread automations can also refresh static artifacts over time so a thread has something new waiting when the user returns.

Единичный файл index.html может стать долговечным интерактивным артефактом без сервера. Потоковые автоматизации также могут периодически обновлять статические артефакты, чтобы к моменту возвращения пользователя там уже было новое содержание для проверки.

9. Общая память / Shared Memory

Long-running threads become more useful when they share memory outside any one conversation.

Долгоживущие потоки становятся полезнее, когда они разделяют память вне рамок одного диалога.

Shared memory: Durable context stored outside a single thread so future work can resume from something explicit and reviewable.

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

One durable pattern is to anchor persistent threads in an Obsidian vault. In practice, that means a folder of plain files that stays straightforward to inspect, edit, move, and keep for a long time. Teams can store that folder in cloud storage, Git, Dropbox, Google Drive, or another sync layer that fits their workflow.

Один практичный паттерн — привязывать устойчивые потоки к хранилищу Obsidian. На практике это означает папку с обычными текстовыми файлами, которую легко просматривать, редактировать, перемещать и долго хранить. Команды могут держать эту папку в облаке, Git, Dropbox, Google Drive или любом другом слое синхронизации, подходящем под их процесс.

A vault might look like this:

Пример структуры такого хранилища:

vault/
├── TODO.md
├── people/
├── projects/
├── agent/
└── notes/

At the top level, AGENTS.md can define how Codex should update that workspace as it learns more about people, projects, decisions, and open loops.

На верхнем уровне файл AGENTS.md может задавать, как Codex должен обновлять это пространство по мере накопления знаний о людях, проектах, решениях и открытых задачах.

Don't copy one exact vault structure. Teach the agent where durable context should live, what context to preserve, and when not to create churn.

Не копируйте одну фиксированную структуру хранилища. Научите агента, где должен жить устойчивый контекст, какой контекст сохранять и когда лучше не создавать лишнюю churn.

A practical AGENTS.md might say:

Практичный AGENTS.md может выглядеть так:

- Treat ~/vault as durable work memory.
- Prefer canonical notes over note sprawl.
- Route TODOs, people, projects, daily summaries, and scratch notes explicitly.
- Preserve decisions, blockers, owners, dates, and useful links.
- If nothing meaningful changed, do not churn the vault.

Repositories hold code. The vault holds rolling context: the people involved, what changed, what's blocked, what needs follow-up, and what would otherwise disappear between sessions.

Репозитории хранят код. Хранилище памяти хранит текущее состояние контекста: участников, изменения, блокеры, что требует продолжения и что могло бы потеряться между сессиями.

Important context shouldn't live only inside a conversation transcript. Write it down somewhere the next thread can pick back up.

Важный контекст не должен существовать только в стенограмме диалога. Его нужно записывать туда, где следующий поток сможет его продолжить.

Codex also has first-party memory features in Settings > Personalization > Memories. They provide a local recall layer for preferences, recurring workflows, and known pitfalls. They complement explicit written context rather than replacing it. Chronicle pushes in the same direction by helping Codex build memory from recent screen context.

У Codex также есть собственные возможности памяти в Settings → Personalization → Memories. Они дают локальный слой напоминаний для предпочтений, повторяющихся процессов и известных проблемных мест. Это дополняет явный письменный контекст, а не заменяет его. Chronicle работает в том же направлении, помогая Codex формировать память по недавнему экранному контексту.

10. От кода к более широким задачам / From Code Outward

Codex still starts from code. But more of the work around code is now reachable through the same system: MCP servers, browser surfaces, desktop controls, thread automations, and reviewable artifacts.

Codex по-прежнему начинается с кода. Но всё больше задач вокруг кода теперь достижимы через ту же систему: MCP-серверы, веб-интерфейсы, управление через компьютер, автоматизации потоков и артефакты, доступные для проверки.

That changes the control model. Steering interrupts the work in progress. Queuing lines up the next task. Thread automations keep a thread active when the user steps away. Goals add a concrete finish line that Codex can keep working toward.

Это меняет модель управления. Steering прерывает задачу по ходу выполнения. Queuing ставит в очередь следующую работу. Потоковые автоматизации держат поток активным, когда пользователь уходит. Goals добавляют конкретную финишную цель, к которой Codex может последовательно двигаться.

Codex can now carry a workflow from instruction to execution to artifact review, even when the work leaves the repo.

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

*Материал взят из официального руководства OpenAI Codex; англо-китайскую версию подготовил и перевёл Lamjin.*

Если вы хотите стабильно использовать регистрацию и верификацию Codex внутри Китая, можно обратиться к статье «Руководство по использованию физического номера giffgaff в Великобритании». Если вы хотите использовать бесплатные модели OpenRouter как базу для экспериментов с заменой Codex, см. «Рекомендованные бесплатные модели OpenRouter».

Часто задаваемые вопросы

Чем Codex отличается от Claude Code?

Codex — это продукт-агент от OpenAI для работы с кодом, Claude Code — соответствующий инструмент от Anthropic; по концепции оба похожи (агент выполняет задачи в реальной среде), но отличаются экосистемой и способами интеграции. Codex делает акцент на интеграции с GitHub и облачном исполнении, тогда как Claude Code больше ориентирован на локальные CLI-процессы.

Что такое «устойчивый поток» в Codex?

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

Как работает Automations (автоматизация задач) в Codex?

Automations позволяют Codex продолжать выполнение задач, когда пользователь не в сети (например, регулярно проверять репозиторий, реагировать на события, запускать тесты), что делает его по сути фоновым рабочим потоком. Goals дают Codex чёткую цель, поэтому он продвигает задачу к конкретному результату, а не ждёт каждого ручного триггера.

Какие внешние инструменты подключает Codex?

На данный момент Codex поддерживает браузер, MCP-серверы и различные Connectors (коннекторы), может вызывать внешние API, работать с документами, выполнять shell-команды и взаимодействовать с системами вне репозитория.

Источники

• Getting the Most Out of Codex (поделиться оригинальным постом)