Инструменты: Qwen Code и OpenSpec

Пара, а не монолит

Стек из двух независимых инструментов:

Связка ничем не эксклюзивна: OpenSpec поддерживает 30+ агентов, а Qwen Code умеет работать без OpenSpec. Но вместе они закрывают полный цикл: OpenSpec отвечает за «что строим», Qwen Code — за «строй».

Шаг 1. Qwen Code CLI

npm install -g @qwen-code/qwen-code
qwen --version

Дальше — аутентификация. Важное изменение 2026 года: бесплатный Qwen OAuth отключён (с 15 апреля 2026). Рабочие варианты — через /auth внутри qwen:

• Alibaba ModelStudio / Coding Plan — подписка с фиксированной ценой, ключ вида sk-sp-…, эндпоинт https://coding-intl.dashscope.aliyuncs.com/v1 (международный);
• сторонние провайдеры — OpenRouter, DeepSeek, ModelScope и другие;
• свой OpenAI-совместимый эндпоинт — включая локальные модели через Ollama/vLLM.

Для команды удобнее один раз описать провайдера в ~/.qwen/settings.json, чтобы никто не проходил интерактивный /auth:

{
  "modelProviders": {
    "openai": [
      {
        "id": "qwen3-coder-plus",
        "baseUrl": "https://coding-intl.dashscope.aliyuncs.com/v1",
        "envKey": "BAILIAN_CODING_PLAN_API_KEY"
      }
    ]
  },
  "security": { "auth": { "selectedType": "openai" } },
  "model": { "name": "qwen3-coder-plus" }
}

Ключ — в переменной окружения или в .qwen/.env (файл в .gitignore). Проверка: qwen, внутри — /doctor.

Два режима, оба пригодятся:

• qwen — интерактивная сессия в терминале (в ней живут слэш-команды);
• qwen -p "…" — headless-режим для скриптов и CI.

Шаг 2. OpenSpec

npm install -g @fission-ai/openspec@latest
cd payments-service
openspec init --tools qwen

init делает две вещи. Во-первых, создаёт каркас спецификаций:

payments-service/
└── openspec/
    ├── specs/        # источник истины: как система ведёт себя сейчас
    │   └── <домен>/spec.md
    ├── changes/      # изменения в работе: по папке на изменение
    │   └── archive/  # завершённые — история решений
    └── config.yaml   # конфигурация (понадобится в части 5)

Во-вторых, регистрирует слэш-команды для Qwen Code — файлы в .qwen/commands/. В Qwen Code они зовутся через дефис: /opsx-propose, /opsx-apply (каноническое написание в доках OpenSpec — /opsx:propose; каждый агент спеллит по-своему, openspec init печатает правильную форму для выбранных инструментов).

Цикл

Всё взаимодействие — четыре команды в чате агента:

qwen> /opsx-explore                       # необязательно: обсудить идею
qwen> /opsx-propose limit-refund-window   # агент пишет спеку, вы ревьюите
qwen> /opsx-apply                         # агент реализует по tasks.md
qwen> /opsx-archive                       # дельта вливается в specs/

• explore — «подумать вслух»: агент читает код, взвешивает варианты, ничего не создаёт. Лучшая привычка против «уверенно построил не то».
• propose — создаёт openspec/changes/<имя>/ с четырьмя артефактами: proposal.md, specs/ (дельта требований), design.md, tasks.md. Это точка, где человек читает и правит.
• apply — реализация по чек-листу tasks.md, галочка за галочкой.
• archive — дельта сливается в основные specs/, папка изменения уезжает в changes/archive/2026-08-11-limit-refund-window/.

Терминальный CLI — для проверок вне чата: openspec list (активные изменения), openspec show <имя>, openspec validate (пригодится в CI, часть 6), openspec view (дашборд).

Кейс «Синтез». Даша поставила связку за вечер: полчаса на ключ Coding Plan, десять минут на settings.json и openspec init в одном пилотном сервисе. Первое сопротивление пришло не от инструментов, а от Олега: «у меня и так всё работает». Ответ на это возражение — не спор, а часть 4: один прогон на настоящей задаче.

Что дальше

Инструменты стоят в одном репозитории. Но у «Синтеза» их одиннадцать — и прежде чем раскатывать openspec init по всем, надо ответить на вопрос, который определит успех всей затеи: где живут спецификации. Это часть 3 — самая важная в туториале.