Гайды

Qwen Code обучение: как освоить работу с агентом

16 октября 2026 · 16 минут чтения

Проверка фактов

Юлия Найпак

Методист по автоматизации. Сверяет паспорт инструмента с документацией вендора.

Автор Р

Редакция

Коллектив авторов, редакторов и иллюстраторов статей на сайте блога онлайн-университета «Зерокодер». Пишем…

Черновик готовит редакция с помощью ИИ. За стандарт издания отвечает главный редактор — Валерий Курземнек.

Материал редакции Зерокодера. Счёт по выдаче снят собственным прогоном 16 октября 2026 года; цитаты источников приведены дословно. Обновлено: октябрь 2026.

Qwen Code обучение: как освоить работу с агентом, начинается с официальной документации проекта и одного небольшого проекта, где вы сами читаете, правите, проверяете и откатываете изменения. Вводный материал даёт обзор и первые команды, дальше практика идёт по шагам: подготовка проекта, разбор структуры файлов, малая правка, проверка diff и теста, разрешения и откат. Ниже — порядок действий, таблицы и готовый промпт для первого упражнения.

Официальный вводный материал: где начинать обучение

Официальная точка входа — документация Qwen Code на сайте проекта. В обзоре продукта на qwenlm.github.io сказано, что Qwen Code — это агентный инструмент для программирования, который живёт в терминале и помогает превращать идеи в код. Там же приведён быстрый старт: установка одной командой и первый запуск. В документации проекта отмечено, что рекомендуемый установщик использует отдельный архив, когда он доступен для вашей платформы, а при откате к npm требуется Node.js 22 или новее с npm в PATH. После установки рекомендуется перезапустить терминал, если команда qwen не появилась в PATH сразу.

При первом запуске документация проекта описывает запрос на подключение провайдера модели: меню предлагает Alibaba ModelStudio как официальную рекомендуемую настройку, сторонние провайдеры вроде DeepSeek, MiniMax, Z.AI, Kimi и OpenRouter с подключением по API-ключу, а также Custom Provider для локального сервера, прокси или неподдерживаемого провайдера. Для Alibaba Cloud Token Plan (intl) в документации указан путь Alibaba ModelStudio → Token Plan, для API-ключа — Alibaba ModelStudio → Standard API Key. При первом использовании появится запрос на вход в систему.

Кроме обзора, у проекта есть витрина Qwen Code Showcase. В ней сказано, что материалы помогают изучать Qwen Code на примерах реальных проектов и осваивать лучшие практики программирования с ИИ. Витрина предлагает выбрать учебный маршрут по уровню опыта. Для начинающего уровня заявлена первая задача программирования с ИИ за 10 минут, для среднего — повседневные офисные задачи от организации файлов до анализа данных и презентаций, для продвинутого — сложная разработка от требований до прототипа и ревью кода.

Отдельный источник — руководство в терминале на theivansergeev.com. Оно разбивает первый вечер на пять шагов: проверить готовность компьютера, поставить помощника одной командой, выбрать вход, запустить и дать первую задачу, понять, как помощник обращается с файлами. Там же разобраны откат назад, объяснение проекта один раз и типичные спотыкания в первый день. Этот материал полезен как второй источник после официальной документации: он даёт бытовой порядок действий.

Собственный прогон редакции по этому веб-корпусу показывает: скачали подборку результатов веб-поиска по запросу «Qwen Code обучение: как освоить работу с агентом»: текст отдали 9 из 10. Медиана объёма читаемого текста топа — 3280 слов. Метку 2026 года несут 9 из 9 прочитанных страниц. Это ориентир по объёму и свежести материалов, на которые опирается обучение.

Практический вывод для старта: откройте обзор и быстрый старт в документации проекта, поставьте Qwen Code, подключите провайдера и запустите первую задачу. Витрину используйте как каталог упражнений по уровням. Руководство в терминале пригодится, когда нужен порядок «за вечер». Дальше переходите к своему небольшому проекту — на нём обучение идёт быстрее, чем на чужом коде.

Подготовка небольшого проекта для обучения

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

Порядок подготовки:

1. Создайте или выберите репозиторий с небольшим объёмом кода.
2. Убедитесь, что проект запускается и тесты проходят до вмешательства агента.
3. Откройте терминал в корневой директории проекта.
4. Запустите Qwen Code и подключите провайдера модели.
5. Дайте первую задачу на чтение, без правок.

Документация проекта советует начинать с широких вопросов и затем сужаться до конкретных областей. Для обзора кодовой базы в ней приведена формулировка give me an overview of this codebase. Для углубления — explain the main architecture patterns used here. Отдельно рекомендуется спрашивать о соглашениях по коду и паттернах, используемых в проекте, и запрашивать глоссарий терминов, специфичных для проекта.

Полезно заранее зафиксировать точку возврата. Сделайте коммит до первой правки — тогда откат сводится к возврату на этот коммит. Держите под рукой команду запуска тестов и команду сборки: они понадобятся на шаге проверки. Если проект чужой и большой, возьмите его копию или отдельную ветку, чтобы учебные эксперименты не смешивались с рабочей историей.

Таблица ниже сопоставляет цели подготовки и действия, которые описывает документация проекта.

Ошибка новичка на этом шаге — начинать с большой задачи на незнакомом репозитории. Документация проекта в разделе рефакторинга советует выполнять изменения небольшими, тестируемыми шагами. Тот же принцип применим к обучению: маленький проект, маленькая задача, видимый результат. Если проект окажется слишком большим, сузьте область до одной директории и работайте в ней.

Ещё одна частая ошибка — пропустить проверку готовности окружения. В обзоре проекта указано, что при откате установщика к npm нужен Node.js 22 или новее. Проверьте версию до установки, чтобы не разбираться с ошибками запуска на первом же шаге. После установки перезапустите терминал, если команда не находится.

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

Структура файлов: что читает агент

Понимание структуры файлов нужно, чтобы предсказывать, куда агент смотрит и что меняет. В документации проекта сказано, что Qwen Code поддерживает осведомлённость о структуре всего проекта и может находить актуальную информацию из веба, а с MCP — тянуть данные из внешних источников вроде Google Drive, Figma и Slack. Для обучения важна первая часть: агент видит проект целиком и отвечает на вопросы о нём.

Отдельный слой структуры — Skills. В документации проекта Skills описаны как модульные возможности, которые повышают эффективность модели с помощью структурированных папок с инструкциями, а при необходимости — со скриптами и ресурсами. Каждый Skill состоит из файла SKILL.md с инструкциями, которые модель загружает при необходимости, и дополнительных файлов вроде скриптов и шаблонов. Skills хранятся в виде директорий, содержащих файл SKILL.md.

Личные Skills доступны во всех ваших проектах и хранятся в ~/.qwen/skills/. Проектные Skills доступны вашей команде и хранятся в .qwen/skills/ внутри проекта. Документация проекта отмечает, что проектные Skills можно коммитить в git, и они автоматически станут доступны участникам команды. Личные Skills покрывают индивидуальные рабочие процессы и предпочтения, проектные — командные рабочие процессы и соглашения, а также специфичные для проекта экспертные знания.

Таблица сопоставляет уровни хранения и назначение.

Документация проекта описывает и обслуживание автогенерированных проектных Skills. Qwen Code отслеживает успешное использование сгенерированных проектных Skills локально, в том числе когда генерация новых Auto Skill отключена. Когда Auto Skill включён, он периодически перемещает неактивные сгенерированные Skills из активной библиотеки. Управляются только директории с именем .qwen/skills/auto-skill-*, чей фронтматер SKILL.md содержит source: auto-skill; личные, расширения, bundled и написанные вручную Skills не выбираются.

Сроки в документации проекта указаны так: через 30 дней без успешного использования или редактирования SKILL.md auto-skill помечается как устаревший, через 90 дней его полная директория перемещается в .qwen/archived-skills/. Ничего не удаляется безвозвратно. Автоматическое обслуживание запускается не чаще одного раза в 7 дней в доверенных рабочих пространствах. Закреплённый auto-skill исключается из автоматических переходов в устаревшее состояние и архивирование до тех пор, пока не будет откреплён.

Для просмотра доступных Skills документация проекта предлагает начать вводить / для автодополнения и просмотра Skills с описаниями. Команда /skills открывает панель Skills, где можно интерактивно просматривать, искать, включать и запускать Skills. Если ранее вы запускали Skill с помощью /skills , теперь этот синтаксис просто открывает панель Skills и игнорирует конечный аргумент; для прямого запуска используется /.

Ещё один элемент структуры — расширения. Документация проекта поясняет, что для Skill из установленного расширения имя включает владельца: rust:pdf, поэтому вводится /rust:pdf. Плагины Agent Plugins и Qoder, по данным витрины проекта, устанавливаются как есть: оба стандартных формата плагинов ставятся в Qwen Code напрямую, без конвертации, и навыки с MCP-серверами из пакета работают сразу после установки.

Практическое упражнение: пройдите по проекту и выпишите, какие директории агент читает при обзоре, где лежат тесты и конфигурация. Затем создайте личный Skill в ~/.qwen/skills/ и проектный в .qwen/skills/ по инструкции документации проекта. Так вы увидите разницу между личным и командным уровнем на своём коде.

Малая правка: как поставить первую задачу

Малая правка — это одна задача с одним ожидаемым результатом. Документация проекта в стандартных рабочих процессах описывает исправление ошибок так: сообщите Qwen Code команду для воспроизведения проблемы и получения stack trace, упомяните шаги для воспроизведения ошибки, дайте знать, является ли ошибка периодической или постоянной. Для правки в ней приведена формулировка update user.ts to add the null check you suggested.

Порядок малой правки:

1. Опишите проблему одной фразой.
2. Приложите команду воспроизведения и текст ошибки.
3. Попросите предложить варианты исправления.
4. Выберите вариант и попросите внести правку.
5. Остановитесь и перейдите к проверке.

Документация проекта советует запрашивать рекомендации по исправлению отдельным шагом. Пример формулировки — suggest a few ways to fix the @ts-ignore in user.ts. Так вы видите варианты до того, как файл изменится. Для поиска места правки в документации проекта приведены формулировки find the files that handle user authentication и how do these authentication files work together. Для трассировки — trace the login process from front-end to database.

Готовый промпт для первой малой правки. Задача: получить одну небольшую правку в одном файле с объяснением.

Ты работаешь в моём учебном проекте. Сначала прочитай структуру проекта и назови файл, который отвечает за [описание области]. Затем предложи три варианта правки для [описание проблемы] и объясни разницу между ними. После моего выбора внеси только один вариант, изменив один файл. Покажи, какие строки изменились, и назови команду, которой я проверю результат. Ничего не коммить.

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

Вариации той же задачи:

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

Документация проекта в разделе рефакторинга приводит формулировки find deprecated API usage in our codebase и suggest how to refactor utils.js to use modern JavaScript features. Там же указано требование убедиться, что изменения сохраняют обратную совместимость, когда это необходимо. Для обучения полезна формулировка refactor utils.js to use ES 2024 features while maintaining the same behavior: она задаёт границу правки.

Частая ошибка — просить сразу несколько правок в разных файлах. Документация проекта советует выполнять рефакторинг небольшими, тестируемыми шагами. Одна правка — один шаг проверки. Если задача расползается, разбейте её на части и выполняйте по одной.

Вторая ошибка — не фиксировать исходное состояние. Перед правкой сделайте коммит или сохраните diff. Тогда на шаге проверки вы сравните результат с известной точкой, а откат будет предсказуемым.

Проверка diff и теста после правки

Проверка состоит из двух частей: просмотр diff и запуск теста. Документация проекта в стандартных рабочих процессах относит работу с тестами к типовым сценариям. В обзоре продукта сказано, что Qwen Code может напрямую редактировать файлы, запускать команды и создавать коммиты. Это значит, что запуск тестов можно поручить агенту, а результат проверить самому.

Порядок проверки:

1. Посмотрите diff по изменённым файлам.
2. Убедитесь, что изменён только ожидаемый файл.
3. Запустите тесты проекта.
4. Сравните результат с ожиданием из задачи.
5. При расхождении вернитесь к правке или откатите её.

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

Полезная привычка — просить объяснение diff. Формулировка: объясни, что изменилось в этом diff и почему. Агент вернёт связь между задачей и строками. Если объяснение не сходится с задачей, правку стоит пересмотреть.

Таблица проверок после малой правки.

Документация проекта в разделе исправления ошибок советует сообщать команду воспроизведения и получать stack trace. Тот же приём работает при проверке: воспроизведите исходную проблему и убедитесь, что она ушла. Если проблема периодическая, отметьте это заранее, чтобы отличать случайный успех от исправления.

Частая ошибка — принимать diff без чтения. Даже при работающих тестах стоит просмотреть строки: тесты покрывают не всё. Вторая ошибка — запускать тесты до просмотра diff и считать зелёный результат достаточным. Порядок «diff, затем тест» даёт понимание, что именно проверяется.

Для длинных диалогов витрина проекта описывает команду /model —compaction: она назначает для сжатия диалога отдельную дешёвую модель, при этом основной диалог продолжает работать на хорошей модели. Это полезно, когда проверка затягивается и контекст растёт.

Разрешения и откат: как держать контроль

Разрешения и откат — часть обучения, которую стоит освоить до серьёзных задач. В документации проекта сказано, что Qwen Code может напрямую редактировать файлы, запускать команды и создавать коммиты. Контроль строится на том, что вы подтверждаете действия и держите точку возврата.

Пошаговый порядок работы с разрешениями и откатом:

1. До первой правки сделайте коммит в git.
2. Читайте запросы на подтверждение действий.
3. Подтверждайте по одному действию за раз.
4. После проверки фиксируйте результат коммитом.
5. При неудаче возвращайтесь на предыдущий коммит.

Руководство в терминале на theivansergeev.com разбирает откат назад, если помощник напортил, и объяснение проекта один раз. Оно же перечисляет типичные спотыкания в первый день. Эти разделы полезны как бытовой ориентир рядом с официальной документацией.

Документация проекта описывает режимы работы с авто-скиллами. Статус и предпросмотр dry-run доступны в безопасном режиме и недоверенных рабочих пространствах. Применение обслуживания, изменение закреплений и восстановление архивных auto-skills требуют доверенного рабочего пространства вне безопасного режима. Это пример того, как разрешения ограничивают действия в зависимости от доверия к пространству.

Для управления авто-скиллами в документации проекта приведена команда /curator: она показывает активные, устаревшие, архивные и закреплённые auto-skills. Запуск /curator run —dry-run показывает предпросмотр обслуживания, /curator run применяет его сразу, /curator pin и /curator unpin управляют обслуживанием отдельного skill, /curator restore возвращает архивный auto-skill в активную библиотеку. В английской версии документации проекта отмечено, что имена архивных директорий остаются зарезервированными, а существующее назначение архива пропускает только это совпадение, не останавливая обслуживание других skills.

Откат правок кода держится на git. Если правка не устроила, вернитесь на коммит, сделанный до неё. Если правок было несколько, откатывайте по одной, чтобы понимать причину. Документация проекта советует выполнять изменения небольшими, тестируемыми шагами — это упрощает и откат.

Таблица действий и их обратимости.

Частая ошибка — работать без коммитов и терять точку возврата. Вторая ошибка — подтверждать действия не читая. Третья — оставлять учебные эксперименты в рабочей ветке. Держите учебный проект отдельно от рабочего.

Когда база освоена, витрина проекта предлагает продвинутые сценарии. Команда /advisor запускает отдельную сессию только на чтение: она прочитывает весь контекст и выдаёт четыре пункта — выводы, риски, недостающие доказательства и рекомендации, при этом основной диалог не трогается. Команда /coordinate собирает несколько агентов: исследователи по умолчанию работают только на чтение, правки вносит один агент, а выводы автоматически сводятся ведущему. Команда /goal-draft превращает смутную идею в исполняемый Goal: сначала задаёт несколько вопросов, составляет проверяемую цель и показывает её в окне подтверждения. Для наблюдения за сессиями витрина описывает qwen sessions ps, которая выводит все сессии на машине: имя, PID, время работы и каталог, по одной на строку, с флагом —json для скриптов.

Частые вопросы

С чего начать обучение Qwen Code?

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

Нужен ли большой проект для практики?

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

Как поставить первую малую правку?

Опишите проблему одной фразой, приложите команду воспроизведения и текст ошибки. Попросите предложить варианты исправления, выберите один и попросите внести правку в один файл. Документация проекта приводит формулировку update user.ts to add the null check you suggested как пример такой задачи.

Как проверить результат правки?

Сначала просмотрите diff по изменённым файлам, затем запустите тесты. Убедитесь, что изменён только ожидаемый файл и правка соответствует задаче. Документация проекта относит работу с тестами к типовым сценариям, а запуск команд — к возможностям агента.

Как откатить неудачную правку?

Держите точку возврата: сделайте коммит до правки. При неудаче вернитесь на этот коммит. Для авто-скиллов документация проекта описывает /curator restore для возврата архивного skill в активную библиотеку и /curator unpin для снятия закрепления.