Qwen Code Plan помогает изучить репозиторий и составить план изменения до правок: режим Plan разрешает анализ с операциями чтения, но исключает редактирование файлов и запуск команд оболочки. Разработчик задаёт границы задачи, сверяет предложенные файлы и риски, затем явно выходит из режима планирования и отдельно согласует выполнение. Такой маршрут полезен при изменении кода, где важны прозрачность намерения и проверяемый итоговый diff.
Границы режима
В официальной документации Qwen Code Plan Mode описан как режим чтения: анализ доступного кода разрешён, редактирование файлов и команды оболочки исключены.
После обычной просьбы «составь план» режим доступа инструмента остаётся прежним. Перед началом разработчик вводит /plan и проверяет индикатор активного режима. Документация также описывает переключение через клавиатурное сочетание; явная команда удобна для инструкции команды, потому что её можно повторить и проверить. При переходе в Plan Qwen Code рассматривает доступные материалы и предлагает последовательность работ. Составленный текст остаётся предложением: его пункты ждут утверждения, рабочее дерево сохраняет прежнее состояние.
Выберите конкретную задачу в разрешённом репозитории: например, скорректировать обработку ошибки в модуле импорта. Укажите наблюдаемый сбой, ожидаемое поведение, границу затрагиваемых компонентов и условия приёмки. Секреты, закрытые выгрузки и посторонние каталоги исключают на уровне доступа к рабочей среде. Обещание в запросе соблюдать границы служит подсказкой модели, тогда как права чтения и записи задаются настройками среды и проверяются исполнительным контуром.
Здесь предметом служит подготовка изменения через Plan Mode. Общий обзор Qwen Code охватывает применение инструмента шире; выбор coding model относится к отдельному решению. Вопрос этой статьи уже: какие сведения собрать перед правкой, кто принимает план и как зафиксировать переход от чтения к выполнению.
Материал для плана
Хороший запрос содержит воспроизводимое описание проблемы без клиентских данных. Дайте путь к модулю, ожидаемый результат функции и ссылку на существующий тест внутри проекта. Если точное место ошибки пока неизвестно, попросите перечислить возможные точки входа и объяснить связь каждой с симптомом. План должен отделять наблюдения в файлах от предположений модели. Для каждого предлагаемого изменения полезны путь, причина, ожидаемый эффект и способ проверки; общие фразы о «повышении качества» здесь мало помогают.
Для крупного репозитория инженер может заранее подготовить разрешённую выборку файлов и структурированный перечень через отдельный скрипт. Такой скрипт запускается вне Plan Mode по правилам команды. Он фиксирует состав данных и помогает избежать неполного пересказа длинной выгрузки. Языковая модель объясняет связи между найденными файлами и предлагает гипотезы. Разработчик открывает исходники, сверяет вызовы и проверяет, хватает ли контекста для вывода. Такой же подход нужен при анализе вычислений: парсер или скрипт обрабатывает полный набор, модель формулирует объяснение, человек сверяет результат.
Попросите назвать затрагиваемые контракты: входные данные, формат результата, обработку ошибки и смежные тесты. Если модель предлагает менять публичное поведение, зафиксируйте это отдельно для владельца компонента. Для опасного участка запросите варианты с их рисками и условия, при которых каждый вариант уместен. Отдельным пунктом попросите указать неизвестные сведения. Пустота в контексте должна стать вопросом к разработчику, поскольку уверенный тон ответа сам по себе лишён доказательной силы.
План пригоден к рассмотрению, когда каждое действие связано с конкретным файлом, наблюдением в коде и проверкой ожидаемого результата. Спорные допущения вынесены в явные вопросы владельцу компонента.
Согласование перехода
Рассматривайте выход из Plan Mode как отдельное решение. Команда /plan exit возвращает предыдущий режим согласования. Предыдущий режим может разрешать иной объём действий, поэтому разработчик сверяет индикатор режима до дальнейшей команды. Если нужны ручные подтверждения для правок и команд оболочки, документация описывает выбор Ask Permissions через /approval-mode default. Это настройка поведения клиента; доступ к репозиторию, секретам и внешним сервисам дополнительно ограничивает среда исполнения.
- Откройте разрешённый репозиторий и задайте цель изменения вместе с критерием приёмки. Введите
/planи убедитесь, что показан режим Plan. - Попросите изучить относящиеся к задаче файлы и составить план с перечнем правок, зависимостей, неизвестных сведений и проверок. Сверьте каждый путь с исходным кодом.
- Передайте спорные пункты владельцу компонента. Запишите утверждённый вариант плана и границы допустимых действий в рабочей задаче.
- Введите
/plan exit, проверьте восстановленный режим и при необходимости выберите Ask Permissions. Подтверждайте конкретные действия по одному маршруту команды. - После разрешённой правки изучите diff, запустите предусмотренные проверки в подходящем режиме и передайте результат разработчику на окончательное решение.
Подтверждение плана и подтверждение конкретного действия имеют разный смысл. Утверждённый текст задаёт направление, но объём каждой фактической правки виден только в запросе на действие и в diff. Исполнительный контур должен проверять права и подтверждения при выполнении; одного системного промпта для такой проверки недостаточно. Если инструмент предлагает выйти за согласованный перечень файлов, вернитесь к плану и разберите причину расширения.
Хотите согласовать такой маршрут для своего репозитория?
Проверка правки
После выхода из режима чтения сверяйте результат с утверждённым планом по файлам и по поведению. Просмотрите добавленные и удалённые строки, новые зависимости, изменение интерфейсов и обработку ошибок. Запрос модели о готовности работы показывает её оценку, а основание для приёмки дают проверенный diff и тесты. Если правка затронула соседний модуль, выясните причину и обновите согласование. Даже маленькое текстовое изменение способно менять контракт вызова, поэтому для подтверждения качества одного размера diff недостаточно.
Проверки подбирают к задаче: существующий тест сценария, тест отказа, статический анализ и ручной просмотр важных веток. Для примера с импортом данных полезно сравнить результат на корректном файле и на заранее подготовленном ошибочном входе. Разработчик проверяет утверждения модели о причине сбоя по фактическим сообщениям программы. Если тест выявил расхождение, зафиксируйте его как новую информацию и уточните план. Такой порядок помогает отделить ошибку исходной гипотезы от ошибки исполнения.
Для полной выгрузки тестовых результатов нужен скрипт, который соберёт статусы и укажет пропуски. Модель может кратко объяснить найденные различия и предложить очередность разбора, а человек сверяет её вывод с журналом тестов. Страница о проверке ИИ-агентов раскрывает сценарии и откат шире; здесь проверка служит условием перехода от плановой записи к принятой правке. В журнале задачи сохраняйте ссылку на утверждённый план, просмотренный diff и исход проверки без секретов.
При отказе на тесте восстановите исходное состояние средствами принятого в команде процесса и разберите причину отдельно. Ответственный разработчик решает, возвращать ли задачу на уточнение плана или менять реализацию в рамках уже утверждённой цели. Модель может перечислить вероятные причины, но окончательное решение опирается на код, поведение программы и правила проекта.
Пилот и критерии
Для будущего пилота предложите обезличенную задачу с понятным ожидаемым поведением и доступным тестовым репозиторием. До запуска зафиксируйте эталон: перечень допустимых файлов, ожидаемый результат и случаи отказа. Затем предложите участнику пройти маршрут от входа в Plan Mode до просмотра diff. Такое описание задаёт будущую проверку и сохраняет статус предложения. Сравнивайте фактический план с эталоном по полноте затронутых компонентов, ясности допущений и проверяемости шагов.
Критерий успешного плана состоит в том, что разработчик видит основания каждой предлагаемой правки и может отклонить лишние действия. Критерий безопасного перехода состоит в подтверждённом режиме клиента и отдельной проверке прав исполнителя. Критерий результата состоит в diff по согласованным файлам и проверках, которые подтверждают ожидаемое поведение. Если любой критерий остался открытым, зафиксируйте причину и предложите уточнить задачу до расширения доступа. Пилот должен дать команде материал для решения по проверенным критериям.
При оценке затрат смотрите на выбранный способ доступа к Qwen Code, правила хранения контекста, потребность в проверке кода и объём работы команды. Тарифные условия зависят от выбранного поставщика и меняются; решение о покупке принимайте по актуальным условиям и результату собственной проверки. Если команде нужен маршрут с ролями, подтверждениями и журналом, его можно обсудить в рамках внедрения ИИ. Для решения о внедрении полезнее предъявить согласованный план и проверенный diff, чем оценивать работу по одному убедительному ответу модели.