Есть ли у Qwen аналог Codex

  • Автор темы Автор темы Sysadmin
  • Дата начала Дата начала
S ТС

Sysadmin

Administrator
Команда форума
Есть ли у модели Qwen аналог Codex от open AI. Не могу найти, Если есть, какие преимущества от Codex и минусы.
 
Коротко: у Qwen есть кодовые модели Qwen-Coder / Qwen2-Coder; это ближайший аналог Codex по назначению, но обычно это модель, а не готовый агент/IDE.

Плюсы Qwen-Coder: открытые/локальные варианты, приватность, дообучение, self-host, часто дешевле при своем сервере.

Минусы Qwen-Coder: нужно самому собирать инфраструктуру, меньше готовых интеграций, поддержка и стабильность зависят от версии и вендора.

Плюсы Codex: облачный API/агент, готовые инструменты, документация, enterprise-поддержка, меньше усилий на запуск.

Минусы Codex: закрытый вендор, данные/зависимость от OpenAI, цена, ограничения по приватности.

Уточните: вы про старый Codex API или про текущий Codex agent/CLI? Тогда смогу сравнить точнее.
 
Коротко: у Qwen есть кодовые модели Qwen-Coder / Qwen2-Coder; это ближайший аналог Codex по назначению, но обычно это модель, а не готовый агент/IDE.

Плюсы Qwen-Coder: открытые/локальные варианты, приватность, дообучение, self-host, часто дешевле при своем сервере.

Минусы Qwen-Coder: нужно самому собирать инфраструктуру, меньше готовых интеграций, поддержка и стабильность зависят от версии и вендора.

Плюсы Codex: облачный API/агент, готовые инструменты, документация, enterprise-поддержка, меньше усилий на запуск.

Минусы Codex: закрытый вендор, данные/зависимость от OpenAI, цена, ограничения по приватности.

Уточните: вы про старый Codex API или про текущий Codex agent/CLI? Тогда смогу сравнить точнее.
Qwen-Coder же не может напрямую заходить на сервер и там кодить как Codex? Правильно ли я понимаю ,что для этого нужно скачать Visual Studio Code, далее скачать расширение Qwen Code и тогда уже можно полноценно работать.
 
В целом верно, но с оговоркой: Qwen-Coder — это модель, она сама не заходит на сервер и не редактирует файлы. Нужен слой-агент, который даёт ей инструменты: терминал, файловую систему, SSH/MCP и т.п.

VS Code — удобный вариант, но не обязательный. Если расширение «Qwen Code» умеет только чат/автодополнение, это не полноценная работа. Для сервера нужно либо VS Code Remote - SSH + агентское расширение с доступом к файлам/терминалу, либо CLI-агент на сервере с поддержкой Qwen через API.

Итог: модель не работает на сервере напрямую; заход и выполнение команд делает агент/расширение. Проверьте, есть ли у него инструменты терминала/файлов/SSH, иначе это просто подсказки кода.
 
Коротко: у Qwen есть Qwen-Coder — линейка моделей для программирования. Это ближайший аналог Codex как модели для кода. Но если под Codex вы имеете в виду современный агент (CLI/IDE, автономные правки в репозитории), то прямого «в один клик» аналога я бы не утверждал: экосистема и официальные интеграции обычно слабее, чем у OpenAI.

Плюсы Qwen-Coder:
- открытые веса/локальное развертывание;
- контроль данных, меньше vendor lock-in;
- можно встроить в свой пайплайн/IDE;
- сильный код и поддержка китайского/мультиязычного кода.

Минусы:
- меньше зрелых агентных инструментов «из коробки»;
- repo-wide правки, тесты, PR workflow часто нужно собирать самому;
- интеграции/поддержка/документация могут уступать Codex;
- качество зависит от версии, контекста и настроек.

Уточните: вам нужен аналог именно агента Codex (автономные правки в проекте) или просто кодовая модель?
 
Как я понял нужен полноценный IDE для работу? Объясни что такое IDE и когда в планах у Qwen сделать это в декстопе как в codex?
 
Нет, полноценный IDE не обязателен.

IDE — это редактор с встроенными инструментами разработки: подсветка, автодополнение, терминал, отладчик, git, расширения. Примеры: VS Code, JetBrains, Cursor, Zed.

Для Qwen-Coder важнее не IDE, а agent layer: программа, которая даёт модели доступ к файлам, терминалу, git, SSH. Это может быть:

- CLI-агент на сервере или локально, например aider, opencode, cline;
- расширение VS Code/JetBrains с доступом к файлам и терминалу;
- свой скрипт: API Qwen + запуск команд/чтение файлов;
- VS Code Remote-SSH, если нужен удалённый сервер.

То есть «полноценная работа» получается не потому, что есть IDE, а потому что у агента есть инструменты: читать/писать файлы, запускать команды, применять патчи.

По поводу «когда Qwen сделает десктоп как Codex»: я не знаю. В обсуждении нет такой информации, и я бы не утверждал, что у Qwen есть официальный десктоп-агент уровня Codex CLI/IDE. Скорее всего, работа с Qwen-Coder будет через сторонние клиенты, расширения или локальные агенты.

Уточни: тебе нужен агент для локальной разработки или для правок на удалённом сервере?
 
Нет, полноценный IDE не обязателен.

IDE — это редактор с встроенными инструментами разработки: подсветка, автодополнение, терминал, отладчик, git, расширения. Примеры: VS Code, JetBrains, Cursor, Zed.

Для Qwen-Coder важнее не IDE, а agent layer: программа, которая даёт модели доступ к файлам, терминалу, git, SSH. Это может быть:

- CLI-агент на сервере или локально, например aider, opencode, cline;
- расширение VS Code/JetBrains с доступом к файлам и терминалу;
- свой скрипт: API Qwen + запуск команд/чтение файлов;
- VS Code Remote-SSH, если нужен удалённый сервер.

То есть «полноценная работа» получается не потому, что есть IDE, а потому что у агента есть инструменты: читать/писать файлы, запускать команды, применять патчи.

По поводу «когда Qwen сделает десктоп как Codex»: я не знаю. В обсуждении нет такой информации, и я бы не утверждал, что у Qwen есть официальный десктоп-агент уровня Codex CLI/IDE. Скорее всего, работа с Qwen-Coder будет через сторонние клиенты, расширения или локальные агенты.

Уточни: тебе нужен агент для локальной разработки или для правок на удалённом сервере?
Получается я могу использовать Qwen-Coder, например полноценно кодить на фреймворке Laravel , изменять файлы, читать , точечные патчи делать и это не хуже буедт чем IDE?
 
Да, можно. Но сравнение «не хуже чем IDE» неверное — IDE и агент это разные слои.

IDE — редактор, где ты сам открываешь файлы, нажимаешь кнопки. Агент — программа, которая по запросу модели читает файлы, применяет патчи, запускает команды. Они не конкурируют, а дополняются: агент может работать внутри VS Code, а может и без него, через CLI.

По Laravel конкретно: Qwen-Coder хорошо знает PHP, Blade, Eloquent, роуты, миграции. Но качество правки зависит не столько от модели, сколько от агентного слоя:

- aider — умеет читать контекст репозитория, делать точечные патчи, запускать тесты;
- cline / opencode — аналогично, с доступом к терминалу и файлам;
- свой скрипт через API Qwen — если хочешь полный контроль.

Главное при работе с Laravel: агент должен видеть структуру проекта (routes, controllers, models, migrations, Blade-шаблоны) и уметь запускать php artisan для проверки. Без этого он будет гадать и ломать контекст.

Итог: да, полноценно кодить можно. Но «как в IDE» — это не про IDE, а про то, насколько агент понимает проект и может запускать команды. На голой модели без агентного слоя ты получишь только куски кода в чате, без применения к файлам.

Уточни: ты хочешь работать локально на своей машине или править на удалённом сервере с Laravel? От этого зависит, какой агентный слой удобнее ставить.
 
Уточни: ты хочешь работать локально на своей машине или править на удалённом сервере с Laravel? От этого зависит, какой агентный слой удобнее ставить.
Я хочу кодить с локально компа на удаленном сервере с laravel. Поэтому думаю как лучше поступить.
Поэтому как я понимаю Qwen должен понимать структуру, находить ошибки и исправлять прям на проекте.

Ниже я тебе написал что сделал ИИ внутри Visual Studio Code используя Qwen code.
Готово. Ночная цель достигнута: тестовый контур согласован, падений нет, офлайн-старт отказывает корректно.

1. B33 — согласованный тестовый контур (без временных обходов)​

Проверил все реализации YooKassaGateway (grep -rln "implements YooKassaGateway" → 4 файла + анонимный класс):

файлчто добавленоитог SHA256
app/Services/Payments/YooKassa/FakeYooKassaGateway.php (live-код, не tests/)getPaymentMethod() + registerPaymentMethod / registerMissingPaymentMethod / setMethodReadIndeterminate, очистка в reset()2c2b1b71d2ab6ce0…
tests/Support/StubYooKassaGateway.phpgetPaymentMethod() по настройке теста: methodAnswer, methodReadIndeterminate, счётчик getMethodCalls496f102adeeef6a3…
tests/Feature/YooKassaUnlinkRaceTest.phpделегирование анонимным классом внутреннему двойникуa493a82b05650320…
tests/Feature/YooKassaGatewayContractTest.php (новый, 9 тестов / 27 утверждений)контроль полноты интерфейса + поведения двойниковb80858479cb1bb46…
Поведение выведено из назначения двойника, а не копированием файла из копии: свой магазин → активная bank_card с holder_account_id = настроенный магазин; отсутствие метода у провайдера → PaymentGatewayException; нечитаемый ответ → PaymentGatewayIndeterminateException; пустой id → отказ. Http::assertNothingSent() закрепляет, что HTTP-запросов нет. Первый тест файла требует, чтобы каждый класс, объявивший интерфейс, реализовывал его целиком — именно этого контроля не было при публикации v3. Приёмка: обходов B33 в прогоне больше нет.

2. Семь падений — устранены, с честным разбором​

  • 5 падений (IotControllerAdminPanelTest, RideAdminPanelTest) — PDOException: ambiguous column name: ride_id. Причина: DeviceCommand::scopeWithConsistentOwnership() использовал неквалифицированные origin/ride_id, а ofMany-связь Ride::latestDeviceCommand() несёт derived table с ride_id. Правка — $this->getTable() (4b3e7745d12e717c…), ограничения владения и парка сохранены.
  • 1 падение — устаревшее ожидание текста «Данные не поступают в BIWLS» (заменён намеренно 2026-10-03 на «Заряд по телеметрии»). Ожидание приведено к публикуемым строкам, которые я нашёл в коде (VehicleInfolist.php:147, IotDiagnostics.php:171) — не подгонкой под вывод. Итог 1347ca959ba0b393… совпал с заранее подготовленным комплектом six-failures-sql.
  • 1 падение (YooKassaUnlinkRaceTest) создал мой же вчерашний обход: я подменил файл версией из копии, а она проверяет правило неопубликованного комплекта A и открытого вопроса Q5/B5. После возврата к версии основного дерева — зелено. Публиковать это поведение не переносил.
  • Попутно нашёл дефект собственной фикстуры: customers.phone уникален, а random_int(10,99) давал коллизию в совместном прогоне (файл поодиночке был зелёный). Исправлено детерминированным счётчиком в свободном диапазоне +7999321xxxx; стабильность подтверждена двумя прогонами подряд (67 тестов / 671 утверждение каждый).

3. B32 — корректный отказ офлайн-старта​

app/Services/Rides/ClientRideActionService.php (c777770f9ee00cae…): перед requestStart() и перед dispatch():

  • 409 + reason=controller_offline при availability='offline' (это состояние контроллера: пишется из hardware_online=false);
  • 409 + reason=start_vehicle_unavailable при fault / maintenance / rented (состояния машины);
  • unknown отказом не считается — это отсутствие данных, а не известная недоступность (ограничение описано в коде, тесте и справочнике);
  • vehicle_unavailable не переиспользован: его отдаёт путь завершения, и одна фраза на два смысла соврала бы клиенту;
  • поездку в starting повторный пресс не отклоняет — воспроизводит ту же команду (иначе ломается «Проверить открытие»); дублей команд нет;
  • переход, started_at, оплата, возвраты, отмены, новые попытки — не тронуты.
Admission-гейт целиком в старт не переносил: vehicleVerdict() включает park_unavailable/тариф/заряд/свежесть, а фикстуры стартового пути не имеют строк controllers — перенос отказывал бы легальные старты. Controller::isReachableForRental() как отдельный признак не использовал: у большинства машин строки контроллера нет.

Контракт и клиент: contracts/openapi.yaml (409 старта с enum причин, YAML валиден парсером), docs/architecture/ride-billing.md §3, web-app/src/api/http.ts (59001123e8f14bcb…) с текстом «Машина недоступна. Запуск не выполнен. Обратитесь в поддержку.», проверка в rental-recovery-entry.ts (00ba4100e6197a9c…). AppRideOfflineVehicleGateTest (2bc7dac0b80d779e…, 7 тестов / 56 утверждений) закрывает: отказ без перехода и без команды, 3 нажатия → 0 команд, machine-состояния со своим кодом, «unknown ≠ отказ», сохранность оплаты, и штатный сценарий на симуляторе после восстановления доступности (200 → одна команда → доставка → unlocked → active + started_at).

4. Проверки без обходов​

проверкарезультат
полный backend-прогон кода основного дерева (~/biwls-night-testenv, код = побайтово основное дерево, vendor — только dev-зависимости, sqlite :memory:)OK (890 тестов, 5744 утверждения), rc=0
целевые наборы дваждыOK (67 / 671) ×2
php -l (8 файлов) / pint --test (8 файлов)0 ошибок / PASS
frontendtsc -b exit 0; юнит ok=306 / 0; браузерные экраны 21/21; сборка exit 0
три артефактаотдаваемое = web-app/dist = dist стенда: index-DS16szDL.js, 36 файлов, 40b474609fce7021ac4ee28f50435188
MySQL (изолированный невозможен) — только чтение на рабочем сервереформа «до» → SQLSTATE[23000] 1052 Column 'ride_id' … is ambiguous; та же форма с реальным скоупом и путь ofMany → OK; счётчики не изменились (device_commands 2, rides 0)
post-публикация/, entry, CSS, sw.js, манифест, иконка, logo, webp, PDF — 200; граф 23 модуля, 0 ошибок; API: public 200, приватные 401/404; сервисы active; денежных и IoT-записей не появилось; laravel.log с 2026-10-05 не пополнялся

5. Backup и откат​

~/biwls-backup/night-20261007-011703-pre/ — копии «до» (app/, tests/, web-app/, docs/, hashes.txt), снимок отдачи served-public-before-night/; frontend-откат: releases/20261007-013938-night-previous/previous-public + ROLLBACK.md (один mv, после отката 87addfb0577f1a17c3307cc87b76382e). Миграций нет, config-кэша нет, fpm не перезапускал (opcache с валидацией по времени).

6. Остались открытыми​

  • backend/vendor — production-установка: phpunit/pint отсутствуют, 38 пакетов packages-dev в lock не развернуты. Перенос dev-зависимостей в боевое дерево — ваше решение; пока прогоны идут в изолированной копии кода.
  • Изолированный MySQL на хосте недоступен (AppArmor закрепляет datadir) — диалект проверен только чтением; данных в рабочую БД не записывал.
  • Живой платёжный контур выключен (yookassa.driver пуст, live_enabled=false, webhooks_enabled=false), физический запуск машины не проверялся и не объявлен проверенным.
  • Вопросы владельца без изменений: Q5/B5 (подмена отвязанного метода), B28, B20, B18/B29, комплекты A/B/C/D/F.

7. Документы и комплект синхронизации​

Обновлены: docs/STATUS.md (§2, §3.12, §6, строки B31/B32/B33), docs/BACKLOG.md (S1f/S1g закрыты), HANDOFF.md (§24), PROJECT_CHANGES.md (запись 2026-10-07 ночь), contracts/openapi.yaml, docs/architecture/ride-billing.md, docs/history/README.md; отчёт docs/history/NIGHT-2026-10-07-TEST-CONTOUR-AND-OFFLINE-START.md.

Комплект для локальной синхронизации: ~/biwls-dev/biwls-night-20261007-0203.tar.gz, 10 035 997 байт, SHA256 1eaa2972498a203b70b4827cf403ee5b27d0ff2c23816adbf55561abe2ecf0f3, манифест 179 файлов сверен после распаковки. Внутри: changed/ (10 файлов дельты + хеши «до»/«после»), web-app/, dist/, docs/, checks/ (все прогоны, MySQL-лог, контроль, ROLLBACK-frontend.md, скрипты среды). Без .env*, ключей, vendor, node_modules, дампов; обратный скан 12 значений ключей-секретов из боевого .env — 0 совпадений; тестовые номера +7999321xxxx/+7999000099xx — 0 записей в customers. Промежуточные …-0148, …-0150, …-0151 удалены (пустой README из-за неэкранированной backtick-и в here-doc; затем без манифеста) — об этом записано в отчёте; хеш записан после упаковки, копии документов в архиве отличаются ровно строками с этим хешем (проверено diff: удалённых строк нет).





по итогу Qwen Coder декстопная версия хуже сработала бы или лучше?
 
Коротко: лучше, если Qwen Coder desktop работает как агент с доступом к файлам и терминалу. Хуже, если это просто чат в окошке.

Твой VS Code-сценарий уже показывает главное: успех там был не от “умного Qwen”, а от того, что агент мог:

- читать структуру Laravel-проекта;
- править конкретные файлы;
- запускать тесты и линтеры;
- видеть ошибки;
- делать бэкапы;
- сверять хеши;
- не выдумывать, а опираться на код и прогоны.

Если desktop Qwen Coder умеет примерно то же самое — локальный доступ к проекту, терминал, патчи, тесты, git diff — он, скорее всего, будет удобнее, чем “Qwen в браузере/чат-интерфейсе”.

Но есть важный момент для твоей задачи: локальный desktop не должен “кодить на удалённом сервере” напрямую, если у него нет нормального доступа к серверу.

Для Laravel на удалённом сервере лучше схема:

1. Проект лежит локально или смонтирован/синхронизирован.
2. Qwen Coder работает с локальной копией.
3. Тесты/проверки запускаются либо локально, либо через SSH.
4. На сервер уходят только проверенные патчи/артефакты.

Или второй вариант:

1. Qwen Coder/агентный слой ставится на сервер.
2. Он видит реальные файлы Laravel.
3. Может запускать php artisan, тесты, composer, git.
4. Локальный VS Code просто подключается к серверу.

Второй вариант обычно честнее для удалённого продакшн-проекта, потому что меньше рассинхрона между “кодом на сервере” и “кодом, который видел ИИ”.

Итог: desktop Qwen Coder может сработать лучше, но только если он реально агент, а не болталка. Для твоего Laravel-проекта критично не “какая версия Qwen”, а есть ли у него безопасный доступ к проекту, терминалу и тестам.

Ты планируешь запускать Qwen Coder на локальной машине, а потом синхронизировать файлы на сервер, или хочешь, чтобы он сразу работал внутри удалённого Laravel-проекта через SSH?
 
Назад
Сверху