TL;DR
Когда вы просите LLM исправить что-то в коде или тексте, формат ответа, который вы требуете, — не мелочь, а рычаг, который может утроить шанс на успех. Исследователи прогнали три модели через три способа выдачи правки — полная перезапись файла, точечный патч (список конкретных изменений) и diff (построчные изменения) — и обнаружили: у каждой модели свой любимый формат, и универсального победителя нет.
Главная находка: модели правильно понимают, что нужно исправить, но при формате «перепиши всё целиком» иногда меняют слишком много — даже если требовалась правка одной строки, модель переписывает весь файл на 271 строку. Диагноз верный, масштаб исполнения — избыточный. Это классическая слабость LLM: если формат ответа разрешает «переписать всё», модель этим воспользуется, даже когда не нужно.
Решение простое: формат ответа нужно подбирать под конкретную модель и явно ограничивать масштаб правки в промпте — просить не «перепиши файл», а «покажи только изменённый фрагмент, не трогай остальное».
Схема метода
ШАГ 1: Определи тип задачи — точечная правка или масштабная переработка
ШАГ 2: Выбери формат ответа: полная замена / список конкретных изменений / diff-подобный текст
ШАГ 3 (опционально): протестируй 2-3 формата на одной задаче и сравни точность результата
ШАГ 4: Явно ограничь масштаб в промпте — "не переписывай остальное"
Все шаги — в одном промпте, без отдельных запросов.
Пример применения
Задача: У вас Python-скрипт для парсинга Excel-отчётов (часто пишут в Claude/ChatGPT для автоматизации отчётности). Скрипт падает с ошибкой на одной строке при обработке пустых ячеек.
Промпт (рискованный вариант — полная перезапись):
Вот скрипт: [код]
Ошибка: TypeError: unsupported operand type(s) for +: 'NoneType' and 'int' в строке 47
Перепиши файл с исправлением.
Промпт (рекомендуемый вариант — ограничение масштаба):
Вот скрипт: [код]
Ошибка: TypeError: unsupported operand type(s) for +: 'NoneType' and 'int' в строке 47
Не переписывай весь код. Покажи только строки, которые нужно изменить,
в формате "было → стало". После каждой правки — одно предложение,
почему это исправляет ошибку. Остальной код не трогай.
Результат: В первом варианте модель может «заодно» переписать соседние функции, поменять стиль кода или ввести случайные изменения в несвязанных местах — риск тем выше, чем крупнее файл. Во втором варианте вы получите короткий, сфокусированный ответ: 1-2 строки правки и объяснение, что резко снижает шанс незаметных побочных изменений.
Почему это работает
Слабость LLM: если формат ответа разрешает «переписать всё», модель охотно этим пользуется — даже когда правильно понимает, что менять нужно только маленький кусок. Диагноз точный, а масштаб исполнения — избыточный, потому что формат не ограничивает её "аппетит".
Сильная сторона LLM: модель хорошо следует явному формату, если вы его чётко задали. Попросите «только изменённые строки» — получите только их. Попросите «diff» — получите построчные +/- изменения.
Метод использует это простым способом: явное сужение формата в промпте заставляет модель фокусироваться на нужном фрагменте, а не «улучшать» всё вокруг заодно.
Рычаги управления: - Формат ответа (полная версия / список правок / diff) → для точечных задач сужай формат, для масштабной переработки — можно оставить полную версию. - Явное ограничение scope ("не трогай остальное") → снижает риск лишних изменений в несвязанных местах текста/кода. - Тестирование формата на конкретной модели → то, что хорошо работает в одной LLM, может провалиться в другой — стоит проверить 2-3 варианта перед тем как выбрать привычный формат для регулярных задач.
Шаблон промпта
Вот текущий {текст/код}: {контент}
Нужно исправить: {проблема}
Важно: не переписывай {текст/код} целиком. Покажи только конкретные
изменения в формате "было → стало" для каждого фрагмента.
Остальные части не трогай.
Подставь: {текст/код} — что редактируешь, {контент} — сам материал, {проблема} — что не так и что нужно исправить.
Ограничения
⚠️ Формат-специфичность зависит от модели: нет универсального совета "всегда проси diff" или "всегда проси список правок" — то, что даёт 94% точности у одной модели, у другой даёт 27%. Нужно проверять формат под конкретную модель, которой вы пользуетесь.
⚠️ Успех — это "прошло тесты", не "качественно": в исследовании успех означал, что код прошёл автоматическую проверку. Это не гарантирует, что результат идеально хорош — для текстов и документов аналог "проверки" у вас не автоматизирован, придётся проверять глазами.
⚠️ Структура материала важнее формата: если текст/код — монолитный, сильно связанный кусок (как один большой файл без разделения на модули), даже правильный формат ответа может не спасти — модель склонна переписывать всё целиком.
Как исследовали
Исследователи взяли три языковые модели (DeepSeek, Doubao, Qwen) и прогнали их через три формата вывода на реальных open-source проектах — больше 4000 попыток правки кода. Сравнивали, сколько попыток заканчивались успехом (код проходил тесты), и проверяли результат строгими статистическими тестами.
Любопытная деталь: из четырёх протестированных проектов только один вообще давал успешные решения — на остальных трёх (2551 попыток) успех был нулевым, независимо от модели и формата. Это говорит, что структура проекта — насколько код разбит на независимые модули — важнее формата ответа модели.
На проекте, где успех был, разница между форматами оказалась огромной: одна модель показала рост с 27% до 94% успеха просто от смены формата вывода — без единого изменения в самой модели или задаче. Это и есть главный вывод: формат ответа — это скрытый переключатель качества, который стоит проверить перед тем как доверять модели рутинную правку.
Ресурсы
Yang Yang, «Output Format × Model Identity: Interaction Effects in Single-Round Coding Agent Performance», июль 2026. Данные и шаблоны опубликованы авторами для воспроизводимости.