# Как изкуственият интелект може да редактира код, без да генерира наново цялата програма?

Canonical HTML: https://aogavrilov.com/bg/research/discrete-latent-generation/

Document language: bg

Практическо изследователско ръководство за локализирана промяна на код с генеративни модели: какво трябва да остане фиксирано, какво може да се променя и какви доказателства са необходими, за да се определи една трансформация като запазваща структурата.

Публикувано 25 юли 2026 г. Актуализирано 30 юли 2026 г. [Alexey Gavrilov](https://aogavrilov.com/about/)

## Какъв всъщност е проблемът

Редактирането на код не е просто генериране на код с по-кратка подкана. Редакторът получава съществуващ артефакт, желана промяна и неявен договор за запазване. Затова основният въпрос има две страни: **коя област може да се променя и кои свойства на останалата част трябва да останат стабилни?**

Ръководството е предназначено за технически подготвени читатели, които навлизат в редактирането на софтуер с помощта на ИИ. То разграничава интуитивната представа за локална редакция от по-силните твърдения за синтактично, структурно, семантично и функционално запазване.

## Основна идея

Редакторът с ограничен обхват се нуждае от изрично зададена граница на запазване, а не само от цел на генерирането.

### Какво трябва да остане фиксирано

Това може да бъде текстов отрязък, граматика, сигнатура на API, област от AST, поведение при тестове, договор за зависимости или обучено грубо представяне. Всеки избор защитава различно понятие за стабилност.

### Какво може да се променя

Редактируемата област трябва да предоставя достатъчно свобода за решаване на поставената задача. Метод за контрол, който копира всичко, е стабилен, но безполезен; метод, който пренаписва всичко, предлага свобода без локалност.

## Интуитивен модел: ремонтирайте една стая, запазете сградата

Представете си ремонт на една стая, при който носещата конструкция, водопроводните връзки и съседните помещения се запазват непокътнати. Пълното повторно генериране прилича на изграждане на къщата отначало по словесно описание. При локализираното редактиране вместо това се обозначава защитената структура, обособява се ограничена работна област, извършва се промяната и резултатът се проверява, преди да бъде приет.

**Къде аналогията престава да бъде валидна.** Наученият латентен код не е сертифициран архитектурен план. Фиксирането на груб код може да повиши измерената структурна стабилност, но не гарантира, че конкретен възел в AST, поведение или интерфейс ще остане непроменен.

## По-прецизен поглед към частичното регенериране

Нека енкодер преобразува програма `x` към структурирано латентно представяне `z` . Маска за запазване избира позициите `L` които да останат фиксирани. Генераторът избира извадки само за допълващите позиции, като налага `z'l = zl` за всяка заключена позиция. След това декодер преобразува завършеното представяне `z'` обратно към изходния код.

Този механизъм създава проверима повърхност за контрол над равнището на токените. Значението ѝ тепърва трябва да се установи емпирично: изследователите следва да проверят какво запазват заключените позиции след декодиране и дали редактируемите позиции съхраняват достатъчна свобода.

## Работен процес за редактиране в четири етапа

1. Определете границата Определете защитените области или свойства и формулирайте желаната промяна.
2. Представяне на артефакта Използвайте текст, синтаксис, контекст от извличане или обучени груби и фини кодове.
3. Избирателно повторно генериране Извличайте извадки само за позициите, подлежащи на редактиране, като запазвате избраните ограничения.
4. Проверете преди приемане Измерете локалността, синтаксиса, структурата, поведението и непредвидените странични ефекти.

## Редактирането на код, поправката на програми и ограниченото генериране не са една и съща задача

| Подход | Основна цел | Типичен механизъм за запазване | Какво още трябва да се провери |
| --- | --- | --- | --- |
| Пълно генериране на код | Създаване на цялостен артефакт | Задание и контекст | Всичко извън поисканата промяна |
| Автоматизирано поправяне на програми | Отстраняване на диагностициран дефект | Локализиране на дефекти, тестове, шаблони или кръпки | Коректност отвъд наличните тестове и минималност на кръпката |
| Модели за попълване или редактиране | Промяна на избрани области от текста | Видим префикс, суфикс, разлика или контекст на редакцията | Непреднамерени структурни и поведенчески промени |
| Декодиране с граматични ограничения | Ограничете изходите в рамките на формален език | Състояния на декодиране, валидни според граматиката | Семантика на програмата, коректност на задачата и локалност |
| Йерархичен латентен контрол | Повторно генериране на избрани научени позиции | Фиксирани груби или фини латентни кодове | Какво запазват тези кодове след декодиране |

## Как да се измерват локалността и запазването на структурата

## Коя повърхност за контрол съответства на задачата за редактиране?

„Не пренаписвай цялата функция“ е изискване, а не завършен метод. Изходната точка следва да бъде резултатът, който трябва да е предвидим; след това се избират повърхност за управление и съответстващи свидетелства.

| Необходима гаранция | По-добре съгласувана повърхност за управление | Необходими доказателства |
| --- | --- | --- |
| Подпомогнато от ИИ рефакториране със запазване на поведението | Нека LLM установи или предложи преобразуване, след което, когато е възможно, то да бъде изпълнено с надежден механизъм за рефакториране. Вж. [RefactoringMirror](https://arxiv.org/abs/2411.04444) . | Компилация, тестове, статични проверки и откриване на рефакториране. [SWE-Refactor](https://arxiv.org/abs/2602.03712) задава тези проверки явно на равнището на хранилището. |
| Локализирана промяна на код без пренаписване на цялата функция | Използвайте повторно непроменените фрагменти от изходния код и генерирайте само кандидат-областите за редактиране, както при [EfficientEdit](https://arxiv.org/abs/2506.02780) . | Разлика извън областта, успешност на задачата, повторно използване на приетите токени и проверка дали пропуснатият контекст води до неотчетени промени между файлове. |
| Ограничено генериране на код за софтуерното инженерство | Наложете формално свойство по време на декодирането, както при [дифузия с граматични ограничения](https://arxiv.org/abs/2508.10111) , или да създават контролни точки за валидните префикси и да се връщат само до отговорната област, както при [Hydra](https://arxiv.org/abs/2605.15238) . | Успешна проверка от граматика, компилатор или проверка на типове, заедно с функционални тестове, локалност, латентност на поправката и количество регенериран валиден код. |
| Избирателно повторно генериране на Python функции с баланс между локалност и разнообразие | Фиксирайте избрани груби или фини латентни позиции и генерирайте извадково само останалите. | Локалност след декодиране, синтаксис, структурни инварианти, свобода на редактиране, разнообразие и неопределеност. Само по себе си заключването на латентните представяния не гарантира рефакториране. |
| Предвидимо генериране на код при изричен договор за запазване | Преди генерирането задайте наблюдаеми защитени свойства и проверки за успех или неуспех, след което изберете най-тесния механизъм, който може да ги наложи или да направи спазването им проверимо. | Измерете точно тези свойства след декодирането и отчетете дяловете на приемане, отхвърляне и неуспех при повторни изпълнения. Самото детерминирано семплиране не гарантира запазване. |

## Изследователски въпроси, на които отговаря това ръководство

Тези кратки отговори определят границите на твърденията и доказателствата, използвани в цялото ръководство.

1. Как генеративен модел може да променя код, без да пренаписва цялата функция? Преди генерирането задайте границата на редактируемата област, запазете или използвайте повторно изходния код извън нея, генерирайте само кандидат-промени и отхвърляйте резултатите, които не изпълняват задачата или изменят защитените области. Йерархичното заключване на латентните представяния е един експериментален интерфейс за контрол, но не гарантира идентични диапазони в изходния код. [Сравнете интерфейсите за контрол при локализирано редактиране](https://aogavrilov.com/bg/research/discrete-latent-generation/#control-surface) .
2. Какви данни показват, че редакцията на код е локална, а не просто синтактично валидна? Измерете разликите извън заявената област заедно с успешността на задачата, промяната в редактируемата област, структурните инварианти, тестовете или статичните проверки и изменчивостта между повторни изпълнения. Сам по себе си делът на успешно анализираните примери установява единствено синтактична коректност. [Прегледайте контролния списък с доказателства за локалност](https://aogavrilov.com/bg/research/discrete-latent-generation/#measurement) .
3. Как локалността на редакциите в кода да се балансира с разнообразието при генериране? Отчитайте устойчивостта на защитената област наред със свободата в областта за редактиране и уникалността на кандидатите. Копирането на входа може да увеличи устойчивостта до максимум, без да постигне напредък по задачата; неограниченото пренаписване може да увеличи промяната до максимум, като разруши локалността. [Вижте ограничените доказателства за баланса между стабилност и свобода](https://aogavrilov.com/bg/research/discrete-latent-generation/#evidence) .
4. По какво се различават локализираното редактиране на код, ограниченото генериране и поправянето на програми? Локализираното редактиране поставя акцент върху онова, което трябва да остане непроменено; ограниченото генериране налага формално свойство на изхода, например принадлежност към граматика; а поправянето на програми изисква промяната да удовлетворява спецификация на дефект или задача. Синтаксисът сам по себе си не доказва семантична еквивалентност, функционална коректност, успешно изпълнение на задачата или локалност. [Сравнете трите целеви функции](https://aogavrilov.com/bg/research/discrete-latent-generation/#comparison) .
5. Как избрани части от Python функция могат да се генерират наново, докато останалата част остава стабилна? Преди генерирането определете защитените и редактируемите области, променяйте само редактируемото представяне, декодирайте и отхвърляйте кандидатите, които изменят защитения код или не преминават проверките за синтаксис, тестове, статичен анализ или специфични за задачата инварианти. Представеният експеримент с йерархични латентни представяния измерва вероятностната устойчивост при функции от 64 токена; той не гарантира непроменени диапазони или поведение. [Разгледайте работния процес за избирателно повторно генериране](https://aogavrilov.com/bg/research/discrete-latent-generation/#workflow) .
6. Коя стратегия за контрол е подходяща за рефакториране със запазване на поведението и помощ от ИИ? Използвайте модела, за да разпознае или предложи трансформация, след което по възможност я изпълнете с надежден механизъм за рефакториране и проверете компилацията, тестовете, статичните проверки и предвиденото рефакториране. Правдоподобна генерирана кръпка не е достатъчно доказателство. [Отваряне на реда с решението за рефакториране](https://aogavrilov.com/bg/research/discrete-latent-generation/#control-surface) .
7. Какво прави генерирането на код предвидимо, а не просто управляемо? Формулирайте наблюдаем договор за запазване и проверки за приемане, преди да изберете генератора. Предсказуемостта зависи от това какво остава стабилно след декодирането и проверката, а не само от това дали са фиксирани подсказка, маска, граматика или латентен код. [Определете договора за запазване](https://aogavrilov.com/bg/research/discrete-latent-generation/#core-idea) .

## Какво показва настоящият експеримент — и какво не показва

В [*Контрол с възможност за проверка при регенериране на софтуер със запазване на структурата*](https://aogavrilov.com/bg/publications/inspectable-control/) , йерархичен VQ-VAE съпоставя функции на Python от 64 токена с 16 дискретни позиции от най-горното и 32 от по-ниското ниво. Заключването на четири кода от най-горното ниво повишава дела на успешно анализираните програми от **от 0.453 до 0.591** , докато отключените позиции продължават да се променят с дял **0.936** а условните извадки остават **0.998 уникални** .

Това са данни за измерен компромис между стабилност и свобода в една малка постановка. Те не гарантират точно запазване на AST, семантична еквивалентност, функционална коректност, успешна поправка или поведение в мащаба на хранилище.

Съпътстващото изследване [*Къде се влошава качеството при генериране на компресиран кратък текст*](https://aogavrilov.com/bg/publications/where-quality-breaks/) добавя важен извод за оценяването: подобрените прокси показатели в латентното пространство не водят непременно до по-добри декодирани резултати. Представянето, генерирането и поведението след декодиране следва да се проверяват като отделни етапи.

За многократно приложима процедура за вземане на решения вижте съпътстващото ръководство за [разграничаване на загубата от кодека от загубата при генератора](https://aogavrilov.com/bg/research/codec-bottleneck-diagnosis/) .

## Често срещани погрешни схващания

### „Програмата се анализира синтактично, следователно е правилна.“

Синтактичният анализ доказва единствено синтактична коректност. Програмата все още може да нарушава тестове, договори или заложения замисъл.

### „Грубият код представлява възел в AST.“

Не и без да е доказано изрично съгласуване. Научените кодове могат да смесват няколко повърхнинни и структурни фактора.

### „Заключените латентни кодове означават непроменен изходен текст.“

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

### „По-малката промяна винаги е по-добра.“

Редактор, който копира входа, постига съвършена стабилност, но никакъв напредък по задачата. Локалността и успехът на редакцията трябва да се измерват съвместно.

## Какво да прочетете след това

Сродните разработки използват различни механизми за управление; никоя не бива да се разглежда като взаимозаменяема базова линия без съгласуване със задачата.

1. [Self-Edit: Fault-Aware Code Editor for Code Generation](https://arxiv.org/abs/2305.04087) Разглежда генерирането като редактируем процес и използва откритите дефекти, за да насочва корекцията.
2. [Coeditor: Leveraging Contextual Changes for Multi-round Code Auto-editing](https://arxiv.org/abs/2305.18584) Моделира контекстуалните промени в кода между последователни редакции, вместо всеки път да генерира отначало.
3. [PAFT: Preservation Aware Fine-Tuning for Minimal-Edit Program Repair](https://arxiv.org/abs/2604.03113) Задава явно запазването и минималната промяна при обучението за поправяне на програми.
4. [Constrained Decoding of Diffusion LLMs with Context-Free Grammars](https://arxiv.org/abs/2508.10111) Показва как формалните ограничения могат да осигурят гаранции за синтаксиса при дифузионно декодиране.
5. [Neural Discrete Representation Learning](https://arxiv.org/abs/1711.00937) Представя VQ-VAE — основополагащия механизъм за научени дискретни латентни представяния.
6. [Simple and Effective Masked Diffusion Language Models](https://arxiv.org/abs/2406.07524) Представя рамката за маскирана дискретна дифузия, използвана като латентен генератор в съпътстващото диагностично изследване.
7. [Емпирично изследване на потенциала на LLM при автоматизираното рефакториране на софтуер](https://arxiv.org/abs/2411.04444) Открива небезопасни рефакторирания, предложени от LLM, и оценява повторното прилагане на установените трансформации чрез надеждни системи за рефакториране.
8. [SWE-Refactor: A Repository-Level Benchmark for Real-World LLM-Based Code Refactoring](https://arxiv.org/abs/2602.03712) Оценява рефакториране на ниво хранилище, което запазва поведението, чрез компилация, тестове и откриване на рефакторирания.
9. [EfficientEdit: Accelerating Code Editing via Edit-Oriented Speculative Decoding](https://arxiv.org/abs/2506.02780) Използва повторно непроменените фрагменти от изходния код и предсказва местата за редактиране, вместо да разглежда редакцията като цялостно авторегресивно повторно генериране.
10. [Hydra: Efficient, Correct Code Generation via Checkpoint-and-Rollback Support](https://arxiv.org/abs/2605.15238) Използва статична проверка, контролни точки и целево връщане назад, за да избегне повторното генериране на вече валидни префикси след грешка.

## Кратко обобщение

Локализираното повторно генериране на код представлява договор между **промяна** и **запазване** . Йерархичните дискретни латентни представяния предлагат един подлежащ на проверка начин за изразяване на този договор, но представянето е полезно само ако декодираните програми се оценяват по локалност, синтаксис, структура, поведение, разнообразие и неопределеност.

## Публикации в това изследователско направление

### [Where Quality Breaks in Compressed Short-Text Generation: Staged Bottleneck Localization](https://aogavrilov.com/bg/publications/where-quality-breaks/)

Къде се срива качеството при компресирано генериране на кратък текст: поетапно локализиране на тясното място

Диагностична методология FRUCT 39 2026 Основна конференция

### [Inspectable Control for Structure-Preserving Software Regeneration](https://aogavrilov.com/bg/publications/inspectable-control/)

Контрол с възможност за проверка при регенериране на софтуер със запазване на структурата

Метод за контрол в латентното пространство FSE Companion '26 2026 Съпътстващ постер