Полный production-workflow с Codex
Production-workflow объединяет все навыки трека в управляемый цикл. Его цель — не получить больше сгенерированного кода, а сократить путь от требования до доказанного, обозримого…
Краткий ответ
Production-workflow объединяет все навыки трека в управляемый цикл. Его цель — не получить больше сгенерированного кода, а сократить путь от требования до доказанного, обозримого и безопасного изменения.
Production-workflow объединяет все навыки трека в управляемый цикл. Его цель — не получить больше сгенерированного кода, а сократить путь от требования до доказанного, обозримого и безопасного изменения.
Этап 1. Подготовить задачу
До запуска агента:
1. выберите один coherent outcome; 2. запишите наблюдаемое текущее состояние; 3. назовите точку входа и релевантные материалы; 4. определите сохранённое поведение; 5. задайте автоматические и ручные критерии; 6. выберите минимальные разрешения; 7. проверьте состояние Git.
Если решение неоднозначно, начните с read-only исследования или Plan mode. Если работа долгая, превратите согласованный результат в goal с вехами.
Этап 2. Исследовать до изменения
Codex читает действующие AGENTS.md, строит путь данных, находит существующие паттерны и тесты. Внешние текущие факты проверяет по официальным источникам. Live context из GitHub, Figma или документации получает через разрешённый plugin/MCP, если он действительно нужен.
Результат исследования:
- подтверждённая причина или карта системы;
- список затронутых контрактов;
- риски и неизвестные;
- план проверки;
- вопросы владельцу.
Не начинайте необратимое действие, если ключевое решение ещё является догадкой.
Этап 3. Реализовать минимально
Агент меняет ближайшую правильную границу и сохраняет пользовательский diff. После связного шага просматривает patch и запускает узкую проверку.
При параллельной работе:
- read-heavy исследование можно делегировать подагентам;
- write-heavy части разделяются по контрактам и worktree;
- главный агент интегрирует результат;
- ни один подагент не объявляет общую цель завершённой.
Повторяемый отработанный процесс переносится в skill. Устойчивые правила репозитория — в AGENTS.md. Технически обязательная защита — в test, CI, policy или hook.
Этап 4. Доказать результат
Проверка идёт от узкого к широкому:
reproduction / failing test
→ targeted test
→ typecheck и lint
→ package or integration tests
→ production build
→ browser/API/data scenario
→ final diff review
Набор адаптируется к задаче. Для backend race важен конкурентный integration test; для layout — реальный viewport; для миграции — повторный запуск и старые данные; для auth — отрицательные сценарии.
Этап 5. Review и безопасность
Отдельный review проверяет correctness, regressions и пробелы тестов. Security-проход фокусируется на trust boundaries, authorization, input, secrets, filesystem и network.
Каждое замечание должно иметь сценарий и последствие. Принятое замечание превращается в минимальное исправление и регрессионный тест. После правок review повторяется на актуальном diff.
Публикация, commit, push, PR, deployment и изменение внешней системы выполняются только если они входят в запрос и разрешения. Локальная реализация не подразумевает автоматический deploy.
Этап 6. Передать результат
Финальный отчёт начинается с результата, а не с журнала:
- что изменилось для пользователя;
- какие ключевые решения приняты;
- какие файлы или контракты затронуты;
- какие проверки прошли;
- что не удалось проверить;
- известные ограничения;
- нужен ли следующий внешний шаг.
Не прячьте ограничение за фразой «всё готово». Если production-контекст недоступен, скажите, что локальный результат проверен, а deployment не выполнялся.
Итоговое упражнение
Возьмите реальный баг средней сложности и проведите полный цикл:
1. составьте prompt «цель / контекст / ограничения / готово»; 2. проверьте AGENTS.md и Git status; 3. запросите read-only диагностику; 4. утвердите план; 5. выполните минимальное исправление; 6. добавьте регрессионный тест; 7. запустите проверки по риску; 8. воспроизведите пользовательский сценарий; 9. проведите correctness и security review; 10. подготовьте честный handoff без публикации.
После завершения проведите retrospective: какое правило повторялось, какой контекст был лишним, чего не хватило и следует ли обновить AGENTS.md или создать skill.
Частые вопросы
Может ли Codex выполнить весь workflow автономно?
Да, внутри ясной цели, доступов и проверяемой среды он может исследовать, менять, тестировать и ревьюить. Продуктовые решения, новые полномочия и необратимые внешние действия остаются точками контроля владельца.
Где заканчивается задача Codex?
В условии «готово, когда». Если оно включает только локальный код и тесты, push или deploy не подразумеваются. Если требуется production rollout, должны быть отдельно заданы полномочия, проверка и откат.
Как понять, что процесс стал лучше?
Измеряйте не объём промптов, а число повторных исправлений, время до воспроизводимого теста, размер нерелевантного diff, долю проверенных критериев и количество дефектов после merge.
Что важно запомнить
- Production-workflow связывает задачу, контекст, минимальный patch и доказательства.
- Правильный уровень автоматизации определяется риском и разрешениями.
- Review и security — отдельные проверочные проходы, а не декоративный финал.
- Завершение означает выполненные критерии и честно описанный остаточный риск.
https://yadro-code.ru/lessons/without-university/codex-agent-workflows/codex-agent-18