Код MiniMax · Урок 09

Создайте и усовершенствуйте навык MiniMax Code

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

Ручной вырезанный бумажный рабочий процесс, перемещающийся от ручного контрольного списка к карточке навыка, двухполосной оценке и одной точной починенной заплатке.
Время чтения
16 мин
Последнее обновление
Август 2026

0 из 16 завершено

Завершить & далее →

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

Этот урок проверен на MiniMax Code v3.0.67 skill-creator и skill-refiner пакеты.

Не превращайте расплывчатое стремление в навык. Сначала выполните задачу вручную, зафиксируйте важные решения и запустите снова на другом примере. Только тогда вы узнаете, что должно быть повторно используемым.

Надёжный цикл выглядит так:

Ручной запуск → второй пример → область → черновик → линтинг → с навыком против базовой оценки → доказательства → минимальное усовершенствование

Пакет v3.0.67 намеренно разделяет два встроенных навыка:

  • skill-creator создает новый навык, проверяет на пересечение, выбирает его область, делает линтинг и запускает оценку.
  • skill-refiner изменяет существующий навык только тогда, когда конкретные доказательства показывают, что инструкции неверны, устарели или отсутствует реальный крайний случай.

К концу этого урока вы разработаете безвредный practice-task-handoff навык и используете один неудавшийся крайний случай для точного улучшения.

Что содержит полезный навык

Навык нуждается в пяти частях, даже если его файл короткий:

ДетальВопрос, на который он отвечает
ТриггерКакой запрос пользователя должен активировать этот рабочий процесс?
ГраницаКакой ближайший запрос должен не его активировать?
ПроцедураКакая последовательность и правила принятия решений производят результат?
Контракт выводаКакой конкретный артефакт или ответ доказывает завершение?
Обработка сбоевЧто происходит, когда отсутствуют доказательства, доступ или требуемый ввод?

Длинный вспомогательный материал следует помещать в справочные материалы, загружаемые только при необходимости. Детерминированная повторяющаяся работа может оправдывать использование скрипта. Навык по умолчанию не требует README, журнала изменений, установщика, файла окружения, пустых папок или кучи примеров.

Пошаговый сценарий: сначала подтвердите рабочий процесс, затем закодируйте его

Шаг 1: подтвердите рабочий процесс вручную

Наш сценарий — это отчет о передаче выполненного практического задания. Он должен включать:

  1. запрашиваемый результат;
  2. измененные пути;
  3. проверки, которые были действительно выполнены, и их доказательства;
  4. известные ограничения;
  5. метод отката.

Выполните рабочий процесс вручную на одном выполненном практическом задании:

Создайте отчет о передаче для этого выполненного практического задания.

Используйте только текущий разговор, видимую панель изменений и фактический вывод проверки.
Возвращайте Результат, Изменённые пути, Проверки, Лимиты и Откат.
Не отмечайте проверку как пройденную, если её вывод отсутствует.
Не выполняйте новые команды, не редактируйте файлы, не коммитьте, не пушьте, не деплойте и не придумывайте откат.
Если доказательства отсутствуют, помечайте элемент как "не проверено".

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

Контрольный список успешного ручного теста

  • Вывод использует пять указанных разделов.
  • Изменённые пути соответствуют видимому diff.
  • Тест считается "пройденным" только когда вывод это подтверждает.
  • Отсутствие доказательств указано явно.
  • Откат соответствует реальному состоянию; это не разрушительное предположение.

Шаг 2: выберите, к чему относится навык

Аудируемый skill-creator использует этот тест охвата:

  1. Если ответ или процедура изменяются для разных пользователей, выберите навык пользователя.
  2. Если он сохраняется в разных проектах для одного агента, выберите навык агента.
  3. Если он имеет значение только в текущем репозитории, выберите навык проекта.

Соответствующие местоположения в текущем пакете:

Пользователь: [каталог данных MiniMax]/skills/<имя-навыка>/
Агент: [каталог данных MiniMax]/agents/<имя-агента>/skills/<имя-навыка>/
Проект: <репозиторий>/.minimax/skills/<имя-навыка>/

Для этого упражнения выберите навык пользователя потому что предпочтение в отчетности принадлежит вам и может следовать за вами в небольших практических заданиях. Назовите это по ответственности: practice-task-handoff.

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

Шаг 3: спросите skill-creator чтобы построить и протестировать это

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

Используйте навык создателя навыков, чтобы создать новое умение для пользователя с именем
практика-задача-передача.

Цель
Превратите доказательства выполненного локального практического задания в компактный отчет о передаче.

Триггеры
Используйте при запросе передачи задачи, журнала доказательств завершения или проверенного резюме задачи.

Границы
Не используйте для выполнения задачи, проверки кода на дефекты, коммита, пуша,
развертывания или составления общего отчета о состоянии проекта. Не выполняйте дополнительные проверки, если
запрос не допускает их отдельно.

Контракт вывода
Возвращайте Результат, Измененные пути, Проверки, Ограничения и Откат. Для каждой проверки указывайте
команду или наблюдение и его результат. Отсутствующие доказательства обозначайте как "не проверено."
Никогда не делайте вывод о прохождении проверки только на основании утверждения Агента.

Требования к созданию
1. Проверьте текущий каталог навыков на наличие перекрытий перед созданием чего-либо.
2. Покажите предлагаемый объем и краткий дизайн SKILL.md.
3. Не включайте секреты, фиксированные пути проекта, текущие логи или факты одноразовых задач.
4. Используйте платформенно-специфичный рабочий процесс для этого компьютера.
5. Проверьте навык на наличие ошибок (lint).
6. Оцените один реальный запрос с использованием навыка и тот же запрос без него.
7. Сообщите, лучше ли навык, равен ему, смешанный или хуже, с доказательствами.
8. Прекратите, если существующий навык уже выполняет эту точную задачу.

Создатель должен сначала проверить доступные на данный момент навыки. code-review рядом, но он находит дефекты; он не выполняет общую передачу завершения. Это различие должно быть отражено в границах нового навыка.

Шаг 4: понять оценку

Текущий рабочий процесс создателя сравнивает два запуска на одном и том же реальном запросе:

  • с-навыком: производитель загружает новый навык;
  • базовый уровень: другой сотрудник отвечает без использования навыка.

Сравнение должно оценивать:

  1. действительно ли навык лучше;
  2. какая процедура или правило контракта вывода сыграли роль;
  3. почему он равен или хуже, если улучшений нет;
  4. три-пять конкретных улучшений;
  5. поможет ли детерминированный скрипт или просто добавит сложности.

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

Используйте этот запрос для оценки:

Создайте отчет о передаче на основе предоставленных доказательств:

Запрошенный результат: изменить статус README с черновика на проверенный.
Видимые измененные пути: README.md
Заявление в разговоре: "npm test прошел."
Доступный вывод команды: отсутствует
Наблюдение при предварительном просмотре: заголовок README и статус отображаются корректно.
Известное ограничение: вывод автоматического теста не был зафиксирован.
Доказательства отката: отменить изменение одной строки в README на панели изменений.

Не запускать команды и не редактировать файлы. Разграничивать заявления и проверенные доказательства.

Этот запрос содержит ловушку: в разговоре говорится, что тест прошел, но нет вывода, подтверждающего это. Полезным навыком будет пометить эту проверку как не проверено.

Шаг 5: уточнять только то, что подтверждают доказательства

Предположим, что выполнение с навыком пишет npm test — passed. Это конкретное доказательство проблемы с навыком только если инструкции самого навыка позволяли ошибку. Если навык уже ясно указывает, что неподдерживаемые проверки не проверяются, а Агент это проигнорировал, это ошибка выполнения Агентом; не продолжайте раздувать навык.

Если контракт вывода действительно неоднозначен, вызовите skill-refiner:

Используйте skill-refiner на practice-task-handoff.

Проблема
Оценка отметила "npm test" как успешный, хотя единственным доказательством было
утверждение в разговоре и не существовало вывода команды.

Доказательства
Подсказка для оценки: "Утверждение в разговоре: npm test пройден. Доступный вывод команды: отсутствует."
Вывод с навыком: "npm test — пройдено."

Запрошено минимальное исправление
Требуется, чтобы каждая проверка была помечена как проверенная, только отчёт или не выполнена.
«Проверенная» требует наличия вывода команды или названного прямого наблюдения для задачи.
Не переписывайте несвязанные разделы и не добавляйте общую защитную лексику.

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

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

Шаг 6: запустите крайний случай и регрессионный случай

После доработки выполните два теста:

ТестВходПроходящее поведение
Пограничный случайПроверка заявлена, но не имеет выводаМаркирует это reported-only или not verified, никогда passed
РегрессияНастоящий вывод команды показывает успехМаркирует это как проверенное и называет доказательства, не скрывая их

Также выполните тест триггера: запросите обычный код-ревью. practice-task-handoff должен не Активируйте. Лучший вывод на успешном пути недостаточен, если навык перехватывает соседние задачи.

Когда объединять скрипт

Объединяйте скрипт только когда одна и та же детерминированная операция повторяется, и код безопаснее, чем проза — например, проверка, что у каждого отчета есть пять обязательных заголовков. Не пишите скрипт для определения, насколько доказательства надежны; для этого нужно суждение.

Текущий создатель явно спрашивает, появилось ли повторяющееся детерминированное действие в процессе производителя. "Скрипт мог бы существовать" — это недостаточное оправдание.

Граница безопасности

  • Никогда не размещайте учетные данные, приватные ключи, личные токены доступа, куки, данные клиентов или временные приватные логи внутри навыка или его артефактов оценки.
  • Не кодируйте одобрение на отправку, публикацию, покупку, удаление, развертывание или изменения в аккаунте. Окончательные действия требуют текущего и точного подтверждения.
  • Оценки могут выполняться одновременно. Держите их временные выводы изолированными и запрещайте использование производственных файлов, внешних действий и общих изменяемых целей.
  • Не создавайте пересекающиеся навыки лишь для изменения формулировок. Улучшайте существующего владельца, когда есть доказательства.
  • Встроенные копии времени выполнения навыков не являются средой для начинающих редакторов. Предлагайте изменения в проекте/рабочем дереве под управлением версии и обычным образом их просматривайте.

Публичные отчеты: сигналы, а не распространенность

Один пользователь Сообщено о повреждении локального хранилища разрешений при одновременной работе. Этот отдельный отчет не устанавливает частоту, и это не является конкретно дефектом. skill-creator Это важно для оценки дизайна, потому что eval творцов может запускать работников параллельно: держите их только для чтения или изолированными, остановитесь, если появляются ошибки разрешений, проверьте текущее состояние и не «исправляйте» проблему, предоставляя более широкий доступ.

Устранение неполадок

СимптомВероятная причинаВосстановление
Творец отказывается создавать навыкСуществующий навык уже покрывает триггерИспользуйте этот навык или уточните его с конкретными доказательствами; не создавайте дубликат
Lint продолжает давать сбойТитульный лист, имя, ссылки, размер или ненужные каркасы неправильныУпростите навык и следуйте текущему маршруту для создателей, специфичному для платформы
Результат с навыком не лучше базовогоРабочий процесс очевиден, слишком широк или обременён инструкциямиСузьте его, уменьшите размер основной части или удалите навык
Навык работает только на исходном примереФиксированные значения просочились в процедуруЗамените имена проектов, пути и результаты на явные входные данные и правила принятия решений
Рефайнер хочет переписать весь навыкДоказательства указывают на небольшой дефект, но запрос широкийПереформулируйте точный след ошибки и требуйте минимальное исправление плюс проверку на регрессию
Параллельная оценка сталкивается с ошибками доступаРаботники используют изменяемую среду выполнения или цельОстановитесь, проверьте разрешения и результаты, изолируйте цели и безопасно выполните заново, вместо того чтобы расширять доступ

FAQ

Сколько ручных запусков мне следует выполнить сначала?

По крайней мере два разных ввода: один обычный пример и один неудобный случай. Суть в том, чтобы отделить повторно используемый метод от значений первой задачи.

Является ли хороший запрос автоматически навыком?

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

Должен ли каждый навык включать сценарии?

Нет. Добавляйте сценарий только для повторяющейся детерминированной работы. Большая часть суждений в рабочем процессе принадлежит кратким инструкциям.

Могу ли я уточнить навык, потому что предпочитаю другую формулировку?

Нет с skill-refiner. Его проверяемая граница требует конкретной функциональной проблемы, подтвержденной доказательствами.

Что, если Агент проигнорировал правильные инструкции по навыку?

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

Официальные источники

Что дальше

Дайте повторяющейся работе четкого владельца — и решите, нужен ли один Агент или команда — в L10: Пользовательские Агенты и Команда Агентов.