00. Как устроена работа с Codex
Оглавление · Следующий модуль →
Если сейчас только читаете: русский разбор ситуации без запуска программ. После него ответьте на вопросы самопроверки модуля; практическое упражнение можно отложить.
Результат модуля: вы умеете выбрать интерфейс и сформулировать задание, завершение которого можно проверить.
В этом руководстве Codex рассматривается как участник рабочего процесса: он получает цель, изучает доступный контекст, вызывает инструменты, предлагает или вносит изменения и проверяет результат. В CLI это работа с файлами и программами установленного окружения. IDE помогает работать рядом с открытым кодом. В настольном приложении удобнее вести несколько задач и рассматривать результаты. Для облачного запуска отдельно выясняют, где находится рабочая копия и какие зависимости доступны. Возможности и ограничения одного интерфейса не следует автоматически переносить на другой. Официальное описание CLI, Windows и поддерживаемые интерфейсы.
Полезный учебный цикл:
Понять задачу → изучить факты → при необходимости составить план →
внести изменение → проверить → рассмотреть diff → сообщить результат.
Это рекомендуемый способ организации работы, а не обещание, что любая модель сама выполнит все этапы без ошибок. Человек задаёт границы и оценивает доказательства. Например, ответ «исправление готово» слабее ответа «воспроизвёл ошибку командой X, исправил условие в Y, проверка Z завершилась успешно». Убедительная формулировка ещё не заменяет запуск программы.
Представим ситуацию: пользователь сообщает, что после загрузки файла таблица пустая. Самый быстрый ответ может предложить изменить компонент таблицы. Более надёжное исследование сначала выяснит, дошёл ли запрос до сервера, появился ли ответ и соответствует ли он ожидаемой схеме. Причина может находиться в другом месте. Поэтому в учебных заданиях оценивайте не скорость появления первого изменения, а связь между наблюдением, объяснением и исправлением. Просите показать исходный симптом и его исчезновение на тех же данных.
Для начала выберите небольшой знакомый репозиторий. Запишите, что уже знаете о нём: язык, точку входа, способ запуска, одну команду проверки. Затем попросите Codex самостоятельно найти подтверждение. Совпадение результата с вашими знаниями поможет оценить качество исследования; расхождение даст конкретный вопрос для проверки. Не начинайте обучение с неограниченного «улучши весь проект»: у такого задания нет очевидного конца и допустимого размера изменений.
Разделяйте сведения по сроку жизни:
| Сведения | Куда поместить |
|---|---|
| Цель сегодняшнего изменения | В текущее задание |
| Общие правила репозитория | В AGENTS.md |
| Проверенный повторяемый процесс | В skill |
| Актуальные данные из внешней системы | Получать через подходящий инструмент или MCP |
| Большое объяснение архитектуры | В отдельный документ со ссылкой из правил |
Эта таблица — методическая рекомендация. Она помогает не превращать каждое сообщение в полную копию проектной документации. Если вы исправляете одну фразу, достаточно одной фразы задания. Если меняете публичный контракт, потребуются источники, ограничения и проверка совместимости.
Практика. Откройте PowerShell в корне учебного репозитория. Следующие команды только показывают местоположение и состояние Git:
Get-Location
git rev-parse --show-toplevel
git branch --show-current
git status --short
Если Git сообщает, что каталог не является репозиторием, сначала найдите нужную рабочую копию. Не инициализируйте новый репозиторий поверх незнакомой папки ради продолжения упражнения.
Передайте Codex задание:
Подготовь карту проекта для нового участника.
Укажи язык, систему зависимостей, точки входа и команды запуска и проверки.
Для каждого вывода приведи файл, который его подтверждает.
Отдельно перечисли предположения и то, что проверить не удалось.
Не изменяй файлы, не устанавливай зависимости и не запускай приложение.
Сравните карту с реальными файлами. Команда из package.json — подтверждённая команда проекта, но её наличие ещё не означает, что она успешно запускается на вашем компьютере. Различайте «нашёл команду», «выполнил команду» и «получил ожидаемое поведение». Это три разных результата.
Критерий проверки: в карте нет неподтверждённых точек входа, ссылки действительно ведут к нужным файлам, Git не показывает новых изменений относительно исходного состояния. Вы можете своими словами объяснить, почему для следующего шага выбрали CLI, IDE или desktop.
Самопроверка:
- Чем успешный запуск проверки отличается от правдоподобного объяснения исправления?
- Почему вывод о возможностях desktop нельзя делать только по справке CLI?
- Какие сведения в вашем последнем задании нужны один раз, а какие стоит закрепить в проекте?
Структурная основа: upstream, модуль 00. Проверено по официальной документации 24 октября 2026 года.