В этом материале
Смешанному процессу нужны правильные трактовка, реализация и объяснение, а не только хороший патч.
Процесс с требованиями, изменением кода и объяснениями может требовать другого выбора модели, чем процесс создания только патчей. Mistral Small 4 и Devstral 2 дают конкретное сравнение общего и специализированного подходов.
Прочитайте области моделей
Карточка Small 4 описывает объединённую модель инструкций, рассуждения и кода с управлением reasoning отдельного запроса. Карточка Devstral 2 описывает специализированный кодовый checkpoint инструкций для инженерной работы.
Объявление Small 4 и релиз Devstral объясняют назначение кандидатов. Слово unified не доказывает одинакового качества любых задач, а специализация не гарантирует верного понимания частного требования. Обе модели остаются проверяемыми кандидатами.
Используйте смешанный результат работы
Подготовьте вымышленное изменение API с одной неоднозначной фразой и одним явным требованием совместимости. Для оценки задайте уточнённую эталонную трактовку, затем запросите реализацию и краткую заметку миграции.
Модель должна отличать реализуемое условие от нуждающегося в уточнении. Технически допустимый патч с необоснованной трактовкой не обязательно принимается. Заметка миграции должна описывать доставленное поведение вместо того, которое модель только предполагала реализовать.
Оценивайте этапы независимо
| Результат | Доказательство приёмки |
|---|---|
| Трактовка требования | Неоднозначность обнаружена без придуманной политики |
| Предложенное изменение | Соответствует уточнённой задаче |
| Реализация | Применяется и сохраняет защищённое поведение |
| Заметка миграции | Точно описывает принятый diff |
| Сообщение завершения | Использует реальные наблюдения проверок |
Таблица не позволяет хорошему объяснению скрыть неправильный патч или правильному патчу скрыть вводящее в заблуждение уведомление последующих пользователей.
Сохраните effort и исходные сведения
Если Small 4 использует reasoning_effort high, зафиксируйте такое условие. Сравнение со стандартным режимом другой модели не должно незаметно превращаться в утверждение превосходства архитектуры. Обоим кандидатам нужны корректные форматы и одинаковые переданные факты.
Если один ответ просит уточнить, а другой угадывает, примените объявленное правило неоднозначности. Эталон может требовать вопрос или задавать допустимое стандартное решение. Без правила оценщики способны по личному предпочтению поощрять противоположное поведение.
Выберите для полного рабочего процесса
Храните ревизии исходников, уточнённые требования, diff, наблюдения тестов и итоговые заметки. Сравните принятую работу каждого этапа и определите, какой этап ограничивает полезность модели для приложения.
Доказательства могут поддержать одного кандидата целому смешанному процессу, разных кандидатов отдельным этапам либо показать непригодность обоих при текущей постановке. Они не устанавливают универсального превосходства программирования, фиксированной стоимости или одинакового поведения каждого агентного клиента. Предметом остаётся конкретный результат с проверяемыми трактовкой, реализацией и объяснением. Сохраняйте эти части раздельно при последующих изменениях модели и условий эксперимента.