Как выбирать модель для задачи

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

То же относится к выбору модели. Одной модели уже мало.

Поведение модели меняется вместе с продуктом. Модель, которая в марте казалась точной, в мае может стать медленнее, осторожнее или громче. Название в меню остается тем же, но ассистент за ним уже другой.

Эти системы не дают один и тот же результат каждый раз. Они еще и продукты. Каждый релиз приносит новое обучение, новые правила безопасности, новое поведение инструментов и новый вкус компании. Одно обновление может сделать модель сильнее в планировании и слабее в редактировании. Другое может сделать ее аккуратнее с кодом, но многословнее в обычном разговоре.

Вопрос уже не в том, какая модель лучшая. Вопрос такой: какая модель должна делать эту задачу, с этим контекстом, сегодня?

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

Codex обычно сдержаннее. Он чаще сохраняет форму проекта и сначала делает небольшое полезное изменение. В зрелой кодовой базе это важно: самая трудная часть часто не в том, чтобы написать код, а в том, чтобы не написать лишний код.

Claude тоже отлично работает с инструментами, но слишком быстро берется писать код. Исправление на три строки может стать хелпером, потом новым модулем, потом переписанным тестом. Иногда такая энергия полезна. Часто это просто новая площадь для обслуживания.

Gemini устроен иначе. Я не всегда хочу запускать его первым внутри грязного репозитория, но часто хочу услышать его до начала работы. Он лучше помогает понять, что это за проблема: баг, не принятое продуктовое решение, плохая абстракция или тест, который проверяет не то.

Kimi меня удивил. Он менее отполирован, чем Codex, и не так чист на финише, но в широком рассуждении не сильно отстает от Gemini. Поэтому он ценен как второе мнение, особенно когда первый ответ звучит слишком гладко.

Мое текущее правило простое. Codex получает работу с репозиторием, ремонт тестов, узкие патчи и задачи, где важны местные инструкции. Claude получает быструю реализацию, когда рамки уже жестко заданы. Gemini получает архитектуру, продуктовое направление и разбор компромиссов до начала правки кода. Kimi получает вторые мнения и черновую стратегию. Локальные модели с открытыми весами получают личные заметки, дешевые черновики, простую классификацию и задачи, где цена важнее блеска.

Эти различия полезны, если назначать задачу с учетом типичного сбоя. Claude может построить лишнее. Gemini может остаться слишком далеко от файлов. Локальная модель может годиться для саммари, но быть слабой в ревью кода. Codex может быть правильным выбором, когда патч должен лечь в репозиторий и не превратиться в редизайн.

Практический прием простой: отделить планирование от исполнения. Попросите Gemini или Kimi определить проблему и риски. Потом попросите Codex или Claude внести изменение. После патча дайте результат на ревью другой модели. Ревьюер не должен переписывать работу. Он должен искать баги, пропущенные тесты, слишком широкие изменения и места, где реализация не совпадает с исходной целью.

Промпт для ревью должен быть прямым. Не спрашивайте: «Это хорошо?» Спросите, какой файл изменился сильнее, чем нужно. Спросите, какое допущение не доказано. Спросите, какой тест должен упасть, если патч неверен. Спросите, что мейнтейнер возразил бы на ревью.

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

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

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

С локальными моделями размещенной модели больше не нужно трогать все.

Командная политика

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

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

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

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

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

Именно этим во время этого черновика стал локальный файл AGENTS.md.

Avoid formulaic AI sounding contrast pairs or rhetorical reversals.

Prefer direct, plain statements grounded in specifics instead of slogan
like pivots or dramatic emphasis patterns.

Use a direct, simple style. Prefer short sentences, common words, and clear
statements over layered phrasing.

Never use hyphens in drafted prose. Rewrite the sentence if a hyphen would
otherwise be needed.

Wrap article prose to fit on screen in plain text views. Keep lines at
about 72 characters where practical.

Avoid tidy three beat lists made from repeated sentence openings, such as
"It will X. It will Y. It will Z."

Do not use rhythmic escalation when a direct statement is enough.

Avoid prophecy voice. Do not describe the future as if announcing a
manifesto. Anchor future claims in a concrete workflow, tool, cost, or user
behavior.

Replace abstract verbs with the actual action when possible: send bug fixes
to Codex, ask Gemini for the plan, use a local model for drafts.

If a sentence sounds good because of cadence alone, rewrite it until it
earns its place through information.

Avoid aphorism closers that sound like a punchline but add no detail.

Treat vague setup plus tidy verdict as a fake punchline. If a line has no
new information and mainly sounds good, cut it or replace it with a
concrete observation.

Такой файл полезнее, чем просьба «писать моим голосом». У большинства людей нет одного устойчивого голоса. У них есть привычки, темы, суждения, влияния и неприязни. Файл правил ловит неприязни. Он говорит модели, что не должно пережить редактуру.

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

Список из трех ударов это еще один сигнал тревоги. «Он направляет. Он помнит. Он улучшает». Такой стиль кажется завершенным, потому что ритм завершен. Читатель все еще не понимает, что произошло. Лучше назвать инструмент, человека, цену, файл или решение.

Правила не делают модель писателем. Они только уменьшают ее способность портить черновик до того, как к нему прикоснется человек редактор.

Для письма я бы использовал модель в основном для отбраковки слабого материала. Откажитесь от первого гладкого черновика. Откажитесь от аккуратной концовки. Откажитесь от предложения, которое подошло бы к любой статье на эту тему. Оставьте деталь, которая могла появиться только в этом тексте: Claude превращает исправление на три строки в новый модуль, Gemini находит первый шаг до правки файлов, таблица показывает, что локальная модель достаточно дешева для черновиков и слаба в финальном суждении.

После достаточного числа реальных задач заметки начинают решать за вас: ремонт тестов отправить Codex, план попросить у Gemini, Claude держать на коротком тикете, локальной модели отдать дешевый первый проход и никогда не позволять ни одной модели писать последнюю строку до того, как вы сами на нее посмотрели.