03. Задания, контекст и планы
← Предыдущий модуль · Оглавление · Следующий модуль →
Если сейчас только читаете: русский разбор ситуации без запуска программ. После него ответьте на вопросы самопроверки модуля; практическое упражнение можно отложить.
Результат модуля: вы умеете заменить расплывчатую просьбу проверяемым заданием и понять, когда сначала нужен план.
Официальная документация рекомендует описывать нужный результат, добавлять полезный контекст и обозначать границы. Жёсткий шаблон не обязателен: короткой просьбы достаточно для простой работы. Для сложных изменений полезно предварительное планирование; CLI поддерживает /plan. Как писать запросы, планирование сложных задач.
Ниже — учебная форма инженерного задания:
Цель: какое наблюдаемое поведение должно измениться.
Контекст: с каких файлов, ошибки или примера начать.
Ограничения: совместимость, область изменений, запрещённые действия.
Готово, когда: что запустить и какой результат получить.
Сравните «сделай обработку CSV надёжнее» с конкретным вариантом:
Цель: при пустом обязательном поле CSV возвращать понятную ошибку строки.
Контекст: начни с модуля импорта и существующих тестов CSV;
найди их сам, прежде чем предлагать новый код.
Ограничения: сохрани публичный формат ошибок, не добавляй зависимости,
не меняй обработку корректных файлов.
Готово, когда: есть пример входа с пустым полем, проверка ожидаемой ошибки
и успешный запуск существующих тестов импорта.
Этот пример не утверждает, что в вашем проекте существует конкретный файл или команда. Прежде чем записать пути в окончательное задание, найдите их. Если команды тестов пока неизвестны, сделайте их поиск первым этапом. В противном случае красивый критерий готовности может оказаться невыполнимым.
План нужен, когда ещё не определены требования, затрагиваются несколько подсистем, меняется схема данных или есть важная граница совместимости. Для понятной правки комментария большой план обычно увеличит объём чтения без пользы. Оценивайте план по тому, помогает ли он избежать неверной реализации, а не по количеству пунктов.
Хороший план отвечает на пять практических вопросов: что подтверждено, что требуется уточнить, какие интерфейсы затронуты, как проверить каждый этап и как вернуть рабочее состояние. Не принимайте неопределённое «добавить тесты» как готовый критерий: нужно назвать поведение и ожидаемый исход. При этом точное имя ещё не существующего теста можно выбрать позднее.
Для Windows прямо указывайте оболочку и рабочий каталог. «Выполни проверки проекта в PowerShell; используй уже установленное окружение» полезнее требования вручную воспроизвести Unix-команду. Если проект использует Python, путь к виртуальному окружению должен быть реальным. Если npm, команду следует взять из package.json, а при необходимости вызвать через npm.cmd. Нельзя выдумывать npm.cmd test, когда у проекта вообще нет такого script.
Контекст подавайте по связям. Начните с ошибки, затронутой функции, существующего теста и похожей реализации. Пусть Codex изучит вызывающий код или схему, если без этого нельзя проверить контракт. Полная выгрузка репозитория в сообщение затрудняет понимание того, какие файлы действительно важны.
Отдельно определите, что делать при неполной проверке. Например, локальные тесты могут пройти, а доступ к тестовому серверу отсутствовать. В таком случае исполнитель должен закончить доступную часть и назвать оставшийся шаг с необходимыми условиями. Он не должен превращать отсутствие доступа в положительный результат проверки. Хорошее задание заранее допускает такой честный отчёт: «Перечисли, что проверено автоматически, что рассмотрено вручную и что требует другого окружения». Это особенно полезно при совместной работе на разных компьютерах.
Практика. Сформулируйте намеренно неполную идею и попросите сначала выяснить требования:
Хочу импортировать CSV из интерфейса приложения.
Пока не реализуй. Изучи существующий импорт и задай вопросы,
без которых нельзя определить формат, обязательные поля, ограничения
размера, ошибки и повторную загрузку.
Затем составь небольшой план: подтверждённое, открытые вопросы,
этапы, проверки, затронутые контракты и возврат к исходному состоянию.
Примеры команд должны подходить для PowerShell в Windows.
Отвечайте только на вопросы, которые меняют результат. Например, разделитель, кодировка и допустимый размер файла влияют на реализацию; предпочитаемое имя внутренней переменной можно оставить исполнителю. После уточнений проверьте, что план изменился вместе с требованиями. Сохранённый документ с устаревшими ответами опаснее отсутствия документа.
Критерий проверки: другой разработчик может выполнить задание без угадывания пользовательского поведения. Каждому этапу плана соответствует наблюдаемый результат; предположения не выданы за согласованные требования; реализация ещё не начата, если вы просили только план.
Самопроверка:
- Какие слова в задании описывают результат, а какие лишь пожелание к процессу?
- Как понять, что уточняющий вопрос действительно нужен до реализации?
- Что нужно изменить в плане после обнаружения отсутствующей команды тестов?
Структурная основа: upstream, модуль 03. Проверено 24 октября 2026 года.