GLM или Qwen: кто лучше превращает пожелания в требования к приложению?

«Сделай удобное согласование заявок» звучит понятно, пока разработка не упирается в первый вопрос: кто согласует, что может менять автор и куда возвращается отклонённая заявка? GLM и Qwen могут помочь разобрать пожелание, но качество видно по найденным развилкам, а не по объёму технического задания.

В Чатиуме удобно сделать конструктор требований: исходная идея, список состояний, открытые вопросы и подтверждённая версия. Он пригодится ещё до генерации самого приложения.

Почему сравнивать нужно конкретные версии

В примере участвуют GLM 5.3 Flash и Qwen3.8 Flash. По каталогу OpenRouter обе работают с текстом и изображениями, поддерживают видео-вход и структурированные ответы. При этом наличие формата в каталоге не означает, что любой интерфейс автоматически передаст его правильно.

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

Пример: согласование покупки оборудования

Исходное пожелание: «Сотрудник подаёт заявку на оборудование, руководитель одобряет или возвращает на доработку». Из него можно уверенно вывести две роли и несколько переходов. Но нельзя вывести лимит суммы, второго согласующего и интеграцию с бухгалтерией.

Даже эта схема содержит вопросы. Может ли автор редактировать отправленную заявку? Нужен ли комментарий при возврате? Можно ли отменить одобренную заявку? Хороший результат явно выделит их, а не спрячет собственные решения в длинном описании.

Что считать более полезным ответом

Сначала проверьте покрытие явного пожелания. Если модель забыла возврат на доработку, она не решила задачу, сколько бы дополнительных возможностей ни предложила. Затем проверьте границы: не появились ли платежи, склад и закупочная аналитика без запроса.

После этого оцените проверяемость. Фраза «интерфейс должен быть интуитивным» не объясняет приёмку. Формулировка «автор видит статус своей заявки и комментарий руководителя после возврата» уже описывает наблюдаемое поведение.

Удобно принимать результат в три корзины: подтверждено исходником, требует ответа, необязательная идея. Тогда смелые предложения модели не теряются, но и не превращаются автоматически в объём первой версии.

Как использовать результат в Чатиуме

Выбранные требования становятся заданием встроенному помощнику Чатиума. Он собирает приложение с интерфейсом, данными и серверной логикой. Для первой версии достаточно пройти один полный цикл: черновик, отправка, возврат, исправление, одобрение.

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

Ниже — серверный фрагмент для одинакового задания двум моделям. ctx даёт Чатиум, sourceText содержит один и тот же проверенный исходник. done и failed — зарегистрированные обработчики app.function, которые проверяют источник вызова: caller.type === 'plugin' && caller.appSlug === 'start'.

import { startCompletion } from '@start/sdk'

const jobs = []
for (const model of ['z-ai/glm-5.3-flash', 'qwen/qwen3.8-flash']) {
  const { completionId } = await startCompletion(ctx, {
    model,
    system: 'Разбери пожелание к приложению: роли, состояния, переходы и вопросы. Отдели явные требования от предположений. Не добавляй интеграции без основания.',
    messages: [{ role: 'user', content: [{ type: 'text', text: sourceText }] }],
    onCompletionCompleted: done,
    onCompletionFailed: failed,
  })
  jobs.push({ model, completionId })
}

В jobs лежат идентификаторы задач, а не готовые ответы. Приложение сохраняет соответствие модели и completionId, принимает результаты позже через обработчики и показывает отдельное состояние каждого запуска. Полный интерфейс и хранение в этот короткий пример не входят.

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