TL;DR
Когда просишь LLM исправить баг в коде, модель часто переписывает куда больше, чем нужно — это называется over-editing (избыточное редактирование). Простая добавка к промпту — явно попросить сохранить оригинальный код и поменять только то, что нужно — заметно снижает эту привычку модели «улучшать заодно».
Пример из статьи наглядный: в функции была однострочная ошибка (сдвиг на единицу), и её действительно можно исправить, поменяв одну строку. Но GPT-5.4 вместо этого удалил 5 строк и добавил 60 — валидацию входных данных, приведение типов, обработку пропущенных значений, пересчёт кривой. Все тесты прошли — то есть корректность не гарантирует минимальность: модель ведёт себя так, будто её попросили написать «надёжный продакшн-код», а не точечно починить конкретную строку.
Добавление одной фразы в промпт — «сохрани как можно больше оригинального кода, меняй только необходимое» — снижает объём избыточных изменений почти на треть и даже слегка повышает точность исправления.
Схема метода
Это не многошаговая техника — это одна добавка к обычному промпту:
ШАГ 1: Формулируешь задачу как обычно — "вот код, вот баг, исправь"
ШАГ 2: Добавляешь явное условие — "сохрани максимум оригинального кода, меняй только то, что необходимо" → модель переключается в режим точечной правки вместо переписывания
Пример применения
Задача: У тебя есть Python-скрипт, который парсит выгрузку заказов с Wildberries и считает скидку. В одной строке ошибка — сравнение через < вместо <=, из-за чего товары с максимальной скидкой не попадают в отчёт.
Промпт:
Вот функция на Python. В ней баг: товары с максимальной скидкой (100%)
не попадают в итоговый отчёт.
def calculate_discount_report(orders):
result = []
for order in orders:
if order['discount'] < 100:
result.append(order)
return result
Исправь этот баг, но сохрани как можно больше оригинального кода —
меняй только то, что необходимо для исправления. Не добавляй
дополнительную валидацию, обработку ошибок или новую логику,
если тесты этого не требуют.
Результат: Модель поменяет < на <= в одной строке и оставит остальную функцию без изменений. Без второй части инструкции есть высокий риск, что модель «заодно» добавит проверку на пустой список, обработку None, логирование и переименует переменные — то есть превратит патч в рефакторинг, который придётся долго вычитывать.
Почему это работает
По умолчанию LLM воспринимает задачу «исправь баг» не как «сделай минимальное точечное изменение», а как «напиши хороший, надёжный код». Увидев баг, модель по пути замечает и другие потенциальные слабости — отсутствие проверок, неаккуратную обработку краевых случаев — и правит их «заодно», хотя её об этом не просили.
При этом сама находка бага у модели работает правильно — проблема не в том, что она не видит ошибку, а в том, что она не ограничивает себя рамками задачи.
Модели хорошо реагируют на явные, конкретные ограничения в тексте промпта. Фраза про сохранение кода меняет то, что исследователи называют «настройкой задачи» (task framing): модель начинает воспринимать существующий код как то, что нужно беречь, а не как черновик, который можно улучшить.
Рычаги управления: - Хочешь видеть, что именно изменила модель и почему → попроси добавить короткий комментарий к каждой изменённой строке - Работаешь не с кодом, а с текстом (договор, статья, письмо) → та же фраза работает: «исправь только эту ошибку, не переписывай остальной текст» - Если правка правда должна быть масштабной (рефакторинг, а не багфикс) → эту инструкцию не добавляй, она будет мешать
Шаблон промпта
Вот {код/текст}: {вставить содержимое}
Проблема: {описание бага или ошибки}
Исправь эту проблему, но сохрани как можно больше оригинального
{кода/текста} — измени только то, что необходимо для исправления.
Не добавляй дополнительную логику, проверки или улучшения,
если задача этого не требует.
Подставь в {код/текст} то, с чем работаешь — скрипт, формулу, абзац договора. В {описание бага} — что именно идёт не так.
Ограничения
⚠️ Проверено только на коде: исследование тестировало короткие функции (в среднем 10 строк). Для больших файлов или сложных многофайловых правок эффект не изучали.
⚠️ Снижает, но не убирает проблему: избыточное редактирование остаётся, просто становится меньше — это не полное решение.
⚠️ Новее и «умнее» ≠ аккуратнее: более сильные reasoning-модели не всегда делают меньшие правки — эффект зависит от конкретной модели, а не от её мощности.
⚠️ Обучение модели делать это само (без промпта) через reinforcement learning требует кода и инфраструктуры — это не применимо в обычном чате, в отличие от простой добавки к промпту.
Как исследовали
Исследователи взяли 400 задач из BigCodeBench и намеренно «испортили» правильные эталонные решения — внесли контролируемый баг на уровне синтаксического дерева кода. Благодаря этому для каждой задачи точно известен минимальный патч, который вернёт код к рабочему состоянию: это просто отмена внесённой порчи.
Прогнали больше 20 топовых моделей (GPT-5.5, Claude Opus, Gemini, DeepSeek и другие) в двух режимах — обычный запрос «исправь баг» и запрос с добавкой про сохранение кода. Замеряли три вещи: проходят ли тесты, насколько велика правка по сравнению с минимальной (считали расстояние между версиями кода на уровне токенов) и насколько усложнилась логика кода после правки. Разработчики-люди отдельно подтвердили, что эта метрика избыточности совпадает с их собственной оценкой «удобно ли это ревьюить» и «сохранён ли оригинальный замысел» — совпадение почти 95%.
Удивил результат: высокий процент прохождения тестов не гарантирует аккуратность правки. GPT-5.5 в усиленном режиме чинит баги отлично, но объём лишних изменений у неё в четыре раза больше, чем у Claude Opus при похожем качестве. Добавление одной фразы про сохранение кода сократило избыточность почти на треть и слегка повысило точность — эффект держался при повторных прогонах и разных формулировках той же просьбы.
Ресурсы
When Models Edit Too Much: On the Fidelity of Minimal Code Edits. Tongyao Zhu, Wei Hern Lim, Min-Yen Kan — National University of Singapore. Код: github.com/nreHieW/over-editing