В этом материале
Предложенная спецификация MiniMax должна сохранять исходное требование до приёмки полученного по ней патча.
Карточка MiniMax-M2.5 описывает склонность планировать и формулировать спецификацию перед программированием. При исправлении ошибки такой план полезен только при сохранении реального требования и получении принятого патча.
Рассматривайте планирование как проверяемое поведение
Карточка модели выделяет программирование и декомпозицию задач. Она также описывает результаты конкретных тестовых harness. Эти утверждения мотивируют ограниченный эксперимент, но не подтверждают правильности любого сгенерированного плана либо исправления.
Официальный репозиторий предоставляет артефакты и материалы развёртывания. Выберите точный checkpoint, чтобы эксперимент не смешивал метку размещённого продукта с другим локальным артефактом модели.
Определите небольшой дефект с ловушкой
Используйте вымышленный CSV-reader, где поле в кавычках может содержать разделитель. Исправление обязано сохранять экранированные кавычки и различать повреждённый вход с допустимым пустым полем. Простое разделение строки пройдёт лёгкие примеры, но нарушит требуемое поведение.
Передайте существующую реализацию, падающий пример и защищённые инварианты. До патча попросите короткую спецификацию исправления. Сопоставьте её с первоначальным требованием: план, незаметно удаляющий обработку повреждённого входа, уже отклоняется от задачи.
Защитите доказательства приёмки
| Артефакт | Назначение при исправлении |
|---|---|
| Первоначальный падающий пример | Показывает заявленный дефект |
| Пример экранированных кавычек | Защищает связанное существующее поведение |
| Пример пустого поля | Предотвращает неверное упрощение отсутствующего значения |
| Пример повреждённого входа | Сохраняет объявленное условие ошибки |
| Окончательный diff | Показывает фактически внесённое изменение |
В эксперименте держите эталонные тесты вне редактируемой области модели. Цель не в запрете любых тестовых правок настоящему инженеру: нужно исключить изменение кандидатом собственной цели приёмки во время сравнения моделей.
Отделите предложение инструмента от исполнения
Руководство вызовов инструментов объясняет предложение структурированных операций. Предложение запустить тесты не подтверждает их исполнения. Сохраните фактические наблюдения тестовой среды и свяжите их с полученным патчем реализации.
Если итог сообщает о прохождении всех случаев, хотя наблюдение содержит ошибку, отметьте неподтверждённое заявление о завершении. Если патч применяется, но ослабляет разбор входа, отметьте смысловую регрессию даже при хорошо организованном объяснении модели.
Оцените доставленное исправление
Храните предложенную спецификацию, патч, наблюдения и независимые проверки вместе. Различайте правильный план с неправильным патчем и ошибочный план, реализованный последовательно. Для этих неудач нужны разные способы исправления рабочего процесса.
Успех показывает устранение M2.5 конкретного ограниченного дефекта при сохранении защищённых случаев. Он не воспроизводит опубликованного показателя тестов, не доказывает обязательной пользы планирования и не обосновывает приёмку будущих патчей без изучения их фактического поведения. Проверяемый итог важнее уверенности или подробности предложенного объяснения работы.