# Làm thế nào để AI chỉnh sửa mã mà không phải sinh lại toàn bộ chương trình?

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

Document language: vi

Hướng dẫn nghiên cứu thực tiễn về sửa đổi mã cục bộ bằng mô hình sinh: phần nào cần giữ cố định, phần nào có thể thay đổi và cần bằng chứng gì trước khi gọi một phép biến đổi là có bảo toàn cấu trúc.

Đã công bố Ngày 25 tháng 7 năm 2026 Đã cập nhật Ngày 30 tháng 7 năm 2026 [Alexey Gavrilov](https://aogavrilov.com/about/)

## Bản chất thực sự của bài toán

Chỉnh sửa mã không đơn thuần là sinh mã với lời nhắc ngắn hơn. Bộ chỉnh sửa nhận một sản phẩm hiện hữu, một thay đổi dự kiến và một hợp đồng bảo toàn ngầm định. Vì vậy, câu hỏi trọng tâm có hai vế: **vùng nào có thể thay đổi và những thuộc tính nào của phần còn lại phải giữ ổn định?**

Hướng dẫn này dành cho độc giả có nền tảng kỹ thuật mới tiếp cận chỉnh sửa phần mềm có AI hỗ trợ. Hướng dẫn phân biệt trực giác về một chỉnh sửa cục bộ với các tuyên bố mạnh hơn về bảo toàn cú pháp, cấu trúc, ngữ nghĩa và chức năng.

## Ý tưởng cốt lõi

Một trình biên tập có giới hạn cần ranh giới bảo toàn tường minh, chứ không chỉ cần mục tiêu sinh.

### Nội dung phải được giữ cố định

Đó có thể là một đoạn văn bản, ngữ pháp, chữ ký API, vùng AST, hành vi kiểm thử, hợp đồng phụ thuộc hoặc biểu diễn thô được học. Mỗi lựa chọn bảo vệ một quan niệm khác nhau về tính ổn định.

### Nội dung có thể thay đổi

Vùng có thể chỉnh sửa cần đủ mức tự do để giải quyết tác vụ được yêu cầu. Một phương pháp điều khiển sao chép mọi thứ thì ổn định nhưng vô dụng; phương pháp viết lại mọi thứ đem lại tự do nhưng không có tính cục bộ.

## Mô hình trực quan: cải tạo một phòng, bảo toàn cả tòa nhà

Hãy hình dung việc cải tạo một căn phòng mà vẫn giữ nguyên kết cấu chịu lực, các điểm nối hệ thống cấp thoát nước và những phòng liền kề. Sinh lại toàn bộ giống như xây lại ngôi nhà từ một mô tả bằng lời. Trái lại, chỉnh sửa cục bộ đánh dấu cấu trúc được bảo vệ, mở một vùng thao tác có giới hạn, thực hiện thay đổi rồi kiểm tra kết quả trước khi chấp nhận.

**Giới hạn của phép loại suy.** Mã tiềm ẩn học được không phải là bản thiết kế kiến trúc đã được chứng nhận. Cố định một mã thô có thể làm tăng độ ổn định cấu trúc đo được, nhưng không bảo đảm rằng một nút AST, hành vi hoặc giao diện cụ thể sẽ không đổi.

## Góc nhìn chính xác hơn về tái sinh từng phần

Cho phép bộ mã hóa ánh xạ một chương trình `x` sang một biểu diễn tiềm ẩn có cấu trúc `z` . Một mặt nạ bảo toàn lựa chọn các vị trí `L` cần giữ cố định. Bộ sinh chỉ lấy mẫu tại các vị trí bù, đồng thời cưỡng chế `z'l = zl` đối với mọi vị trí bị khóa. Sau đó, bộ giải mã ánh xạ biểu diễn đã hoàn chỉnh `z'` trở lại mã nguồn.

Cơ chế này tạo ra một bề mặt điều khiển có thể kiểm tra ở tầng trên token. Ý nghĩa của nó vẫn phải được xác lập bằng thực nghiệm: nhà nghiên cứu cần kiểm tra các vị trí bị khóa bảo toàn điều gì sau giải mã và liệu các vị trí có thể chỉnh sửa còn đủ độ tự do hay không.

## Quy trình chỉnh sửa gồm bốn giai đoạn

1. Xác định ranh giới Xác định các vùng hoặc thuộc tính cần bảo vệ và định nghĩa thay đổi dự kiến.
2. Biểu diễn sản phẩm Sử dụng văn bản, cú pháp, ngữ cảnh truy xuất hoặc các mã thô và tinh được học.
3. Tái sinh có chọn lọc Chỉ lấy mẫu tại các vị trí có thể chỉnh sửa, đồng thời duy trì các ràng buộc đã chọn.
4. Xác minh trước khi chấp nhận Đo lường tính cục bộ, cú pháp, cấu trúc, hành vi và các tác dụng phụ ngoài ý muốn.

## Chỉnh sửa mã, sửa chữa chương trình và sinh có ràng buộc không phải là cùng một tác vụ

| Phương pháp | Mục tiêu chính | Cơ chế bảo toàn điển hình | Nội dung vẫn cần xác minh |
| --- | --- | --- | --- |
| Sinh toàn bộ mã | Tạo ra một sản phẩm hoàn chỉnh | Câu lệnh và ngữ cảnh | Mọi nội dung nằm ngoài thay đổi được yêu cầu |
| Sửa chữa chương trình tự động | Loại bỏ lỗi đã được chẩn đoán | Định vị lỗi, kiểm thử, mẫu hoặc bản vá | Tính đúng đắn vượt ngoài phạm vi các kiểm thử hiện có và tính tối thiểu của bản vá |
| Mô hình điền khuyết hoặc chỉnh sửa | Sửa đổi các vùng văn bản được chọn | Tiền tố, hậu tố, diff hoặc ngữ cảnh chỉnh sửa nhìn thấy được | Những thay đổi ngoài ý muốn về cấu trúc và hành vi |
| Giải mã có ràng buộc ngữ pháp | Giữ đầu ra trong phạm vi một ngôn ngữ hình thức | Các trạng thái giải mã hợp lệ về ngữ pháp | Ngữ nghĩa chương trình, tính đúng đắn của tác vụ và tính cục bộ |
| Điều khiển tiềm ẩn phân cấp | Tái sinh các vị trí biểu diễn đã học được chọn | Các mã tiềm ẩn thô hoặc tinh đã khóa | Những gì các mã đó bảo toàn sau giải mã |

## Cách đo tính cục bộ và mức độ bảo toàn cấu trúc

## Bề mặt điều khiển nào phù hợp với tác vụ chỉnh sửa?

“Không viết lại toàn bộ hàm” là một yêu cầu, không phải một phương pháp hoàn chỉnh. Hãy bắt đầu từ kết quả cần có khả năng dự đoán, sau đó chọn bề mặt điều khiển và bằng chứng tương ứng.

| Bảo đảm bắt buộc | Bề mặt điều khiển tương thích hơn | Bằng chứng cần đòi hỏi |
| --- | --- | --- |
| Tái cấu trúc có AI hỗ trợ và bảo toàn hành vi | Cho phép một LLM xác định hoặc đề xuất phép biến đổi, sau đó thực thi bằng công cụ tái cấu trúc đáng tin cậy khi có thể. Xem [RefactoringMirror](https://arxiv.org/abs/2411.04444) . | Biên dịch, kiểm thử, kiểm tra tĩnh và phát hiện tái cấu trúc. [SWE-Refactor](https://arxiv.org/abs/2602.03712) biểu đạt tường minh các phép kiểm tra này ở cấp kho mã nguồn. |
| Sửa đổi mã cục bộ mà không viết lại toàn bộ hàm | Tái sử dụng các đoạn mã nguồn không thay đổi và chỉ sinh các vùng chỉnh sửa dự kiến, như trong [EfficientEdit](https://arxiv.org/abs/2506.02780) . | Phần sai khác ngoài vùng, mức độ hoàn thành tác vụ, việc tái sử dụng token đã được chấp nhận và khả năng ngữ cảnh bị lược bỏ làm bỏ sót thay đổi liên tệp. |
| Sinh mã có ràng buộc cho kỹ nghệ phần mềm | Áp đặt một thuộc tính hình thức trong quá trình giải mã, như trong [khuếch tán có ràng buộc ngữ pháp](https://arxiv.org/abs/2508.10111) , hoặc tạo điểm kiểm tra cho các tiền tố hợp lệ và chỉ quay lui đến vùng gây lỗi, như trong [Hydra](https://arxiv.org/abs/2605.15238) . | Mức thành công qua ngữ pháp, trình biên dịch hoặc trình kiểm tra kiểu, kết hợp với kiểm thử chức năng, tính cục bộ, độ trễ sửa chữa và lượng mã hợp lệ được tái sinh. |
| Sinh lại có chọn lọc hàm Python với sự cân bằng giữa tính cục bộ và tính đa dạng | Khóa các vị trí tiềm ẩn thô hoặc tinh đã chọn và chỉ lấy mẫu phần còn lại. | Tính cục bộ sau giải mã, cú pháp, bất biến cấu trúc, mức tự do chỉnh sửa, tính đa dạng và độ bất định. Chỉ khóa biến tiềm ẩn không thể bảo đảm việc tái cấu trúc. |
| Sinh mã có thể dự đoán theo một hợp đồng bảo toàn tường minh | Trước khi sinh, hãy xác định các thuộc tính được bảo vệ có thể quan sát cùng các phép kiểm tra đạt/không đạt; sau đó chọn cơ chế hẹp nhất có thể thực thi hoặc làm lộ rõ các thuộc tính đó. | Sau khi giải mã, hãy đo chính xác các thuộc tính đó và báo cáo tỷ lệ chấp nhận, từ chối và thất bại qua nhiều lần chạy. Chỉ lấy mẫu tất định không thể bảo đảm khả năng bảo toàn. |

## Các câu hỏi nghiên cứu mà hướng dẫn này giải đáp

Các câu trả lời ngắn gọn này xác định ranh giới của tuyên bố và bằng chứng được sử dụng xuyên suốt hướng dẫn.

1. Làm thế nào mô hình sinh có thể sửa đổi mã mà không viết lại toàn bộ hàm? Trước khi sinh, hãy xác định ranh giới có thể chỉnh sửa; bảo toàn hoặc tái sử dụng mã nguồn bên ngoài ranh giới đó, chỉ sinh các thay đổi ứng viên và loại bỏ đầu ra không hoàn thành tác vụ hoặc làm biến đổi vùng được bảo vệ. Khóa biến tiềm ẩn phân cấp là một giao diện điều khiển thực nghiệm, nhưng không bảo đảm các khoảng mã nguồn hoàn toàn giống nhau. [So sánh các giao diện điều khiển chỉnh sửa theo vùng](https://aogavrilov.com/vi/research/discrete-latent-generation/#control-surface) .
2. Bằng chứng nào cho thấy một chỉnh sửa mã có tính cục bộ chứ không chỉ hợp lệ về cú pháp? Đo phần sai khác bên ngoài vùng được yêu cầu cùng với mức độ hoàn thành tác vụ, thay đổi trong vùng có thể chỉnh sửa, các bất biến cấu trúc, kiểm thử hoặc kiểm tra tĩnh và độ biến thiên qua nhiều lần chạy. Riêng tỷ lệ phân tích cú pháp chỉ xác nhận tính hợp lệ về mặt cú pháp. [Xem lại danh mục kiểm tra bằng chứng về tính cục bộ](https://aogavrilov.com/vi/research/discrete-latent-generation/#measurement) .
3. Nên cân bằng tính cục bộ của chỉnh sửa mã với tính đa dạng khi sinh như thế nào? Báo cáo độ ổn định của vùng được bảo vệ cùng với mức độ tự do trong vùng có thể chỉnh sửa và tính độc nhất của các phương án. Sao chép đầu vào có thể tối đa hóa độ ổn định nhưng không tạo ra tiến triển nào cho tác vụ; viết lại không hạn chế có thể tối đa hóa mức thay đổi nhưng phá hủy tính cục bộ. [Xem bằng chứng có giới hạn về độ ổn định và mức tự do](https://aogavrilov.com/vi/research/discrete-latent-generation/#evidence) .
4. Chỉnh sửa mã cục bộ, sinh có ràng buộc và sửa chữa chương trình khác nhau như thế nào? Chỉnh sửa cục bộ nhấn mạnh những gì phải giữ nguyên; sinh có ràng buộc cưỡng chế một thuộc tính hình thức của đầu ra, chẳng hạn tính thuộc về một ngữ pháp; còn sửa chữa chương trình đòi hỏi thay đổi phải đáp ứng đặc tả lỗi hoặc nhiệm vụ. Chỉ riêng cú pháp không chứng minh được tính tương đương ngữ nghĩa, tính đúng đắn chức năng, mức độ hoàn thành nhiệm vụ hay tính cục bộ. [So sánh ba mục tiêu](https://aogavrilov.com/vi/research/discrete-latent-generation/#comparison) .
5. Làm thế nào để sinh lại các phần được chọn của một hàm Python trong khi phần còn lại vẫn ổn định? Trước khi sinh, hãy xác định vùng được bảo vệ và vùng có thể chỉnh sửa; chỉ sửa biểu diễn có thể chỉnh sửa, tiến hành giải mã và loại bỏ ứng viên làm thay đổi mã được bảo vệ hoặc không đạt yêu cầu về cú pháp, kiểm thử, kiểm tra tĩnh hay bất biến riêng của tác vụ. Thực nghiệm tiềm ẩn phân cấp được báo cáo đo độ ổn định theo xác suất trên các hàm dài 64 token; thực nghiệm này không bảo đảm khoảng mã hoặc hành vi được giữ nguyên. [Kiểm tra quy trình sinh lại có chọn lọc](https://aogavrilov.com/vi/research/discrete-latent-generation/#workflow) .
6. Chiến lược điều khiển nào phù hợp với tái cấu trúc bảo toàn hành vi có AI hỗ trợ? Dùng mô hình để nhận diện hoặc đề xuất một phép biến đổi, sau đó, nếu có thể, thực thi bằng công cụ tái cấu trúc đáng tin cậy và xác minh quá trình biên dịch, kiểm thử, kiểm tra tĩnh cùng phép tái cấu trúc dự kiến. Một bản vá được sinh ra trông có vẻ hợp lý chưa phải là bằng chứng đầy đủ. [Mở hàng quyết định tái cấu trúc](https://aogavrilov.com/vi/research/discrete-latent-generation/#control-surface) .
7. Điều gì khiến quá trình sinh mã trở nên dự đoán được, thay vì chỉ có thể điều khiển? Xác lập một hợp đồng bảo toàn có thể quan sát cùng các bước kiểm tra chấp nhận trước khi chọn bộ sinh. Khả năng dự đoán phụ thuộc vào những gì vẫn ổn định sau khi giải mã và kiểm chứng, chứ không chỉ vào việc prompt, mặt nạ, ngữ pháp hay mã ẩn có được cố định hay không. [Xác định hợp đồng bảo toàn](https://aogavrilov.com/vi/research/discrete-latent-generation/#core-idea) .

## Những gì thí nghiệm hiện tại cho thấy — và không cho thấy

Trong [*Cơ chế điều khiển có thể kiểm tra trong tái sinh phần mềm bảo toàn cấu trúc*](https://aogavrilov.com/vi/publications/inspectable-control/) , một VQ-VAE phân cấp ánh xạ các hàm Python dài 64 token sang 16 vị trí rời rạc cấp cao nhất và 32 vị trí cấp thấp hơn. Việc khóa bốn mã cấp cao nhất làm tăng tỷ lệ phân tích cú pháp từ **từ 0.453 đến 0.591** , trong khi các vị trí không khóa vẫn thay đổi với tỷ lệ **0.936** và các mẫu có điều kiện vẫn đạt **0.998 là duy nhất** .

Đây là bằng chứng về sự đánh đổi đã đo được giữa tính ổn định và độ tự do trong một bối cảnh nhỏ. Kết quả không bảo đảm bảo toàn AST chính xác, tương đương ngữ nghĩa, tính đúng đắn chức năng, sửa lỗi thành công hay hành vi ở quy mô kho mã.

Nghiên cứu đồng hành [*Nơi chất lượng suy giảm trong quá trình sinh văn bản ngắn có nén*](https://aogavrilov.com/vi/publications/where-quality-breaks/) bổ sung một bài học đánh giá quan trọng: chỉ báo thay thế trong không gian tiềm ẩn được cải thiện không nhất thiết làm đầu ra đã giải mã tốt hơn. Cần kiểm tra riêng biệt các giai đoạn biểu diễn, sinh và hành vi sau giải mã.

Để tham khảo một quy trình ra quyết định có thể tái sử dụng, xem hướng dẫn đi kèm về [phân tách tổn thất codec khỏi tổn thất của bộ sinh](https://aogavrilov.com/vi/research/codec-bottleneck-diagnosis/) .

## Các ngộ nhận thường gặp

### “Phân tích cú pháp được, nên nó đúng.”

Phân tích cú pháp chỉ chứng minh tính hợp lệ về cú pháp. Chương trình vẫn có thể vi phạm kiểm thử, hợp đồng hoặc ý định ban đầu.

### “Một mã thô chính là một nút AST.”

Không, trừ khi đã chứng minh được sự căn chỉnh tường minh. Các mã học được có thể pha trộn nhiều yếu tố bề mặt và cấu trúc.

### “Biến tiềm ẩn bị khóa đồng nghĩa với văn bản nguồn không đổi.”

Phép giải mã có tính toàn cục và được học từ dữ liệu. Việc cố định các vị trí tiềm ẩn có thể tăng độ ổn định nhưng không bảo đảm khoảng văn bản hoàn toàn giống nhau.

### “Thay đổi càng ít thì luôn càng tốt.”

Một trình biên tập chỉ sao chép đầu vào đạt độ ổn định tuyệt đối nhưng không hoàn thành chút nào nhiệm vụ. Phải đo đồng thời tính cục bộ và mức độ chỉnh sửa thành công.

## Tài liệu nên đọc tiếp

Các công trình liên quan sử dụng những bề mặt điều khiển khác nhau; khi chưa căn chỉnh theo tác vụ, không nên xem bất kỳ công trình nào là đường cơ sở có thể thay thế lẫn nhau.

1. [Self-Edit: Fault-Aware Code Editor for Code Generation](https://arxiv.org/abs/2305.04087) Xem quá trình sinh như một quy trình có thể chỉnh sửa và dùng các lỗi được phát hiện để định hướng việc hiệu chỉnh.
2. [Coeditor: Leveraging Contextual Changes for Multi-round Code Auto-editing](https://arxiv.org/abs/2305.18584) Mô hình hóa các thay đổi mã theo ngữ cảnh qua nhiều vòng chỉnh sửa, thay vì tái sinh từ đầu.
3. [PAFT: Preservation Aware Fine-Tuning for Minimal-Edit Program Repair](https://arxiv.org/abs/2604.03113) Biểu đạt tường minh yêu cầu bảo toàn và thay đổi tối thiểu trong huấn luyện sửa chữa chương trình.
4. [Constrained Decoding of Diffusion LLMs with Context-Free Grammars](https://arxiv.org/abs/2508.10111) Cho thấy các ràng buộc hình thức có thể bảo đảm cú pháp trong quá trình giải mã khuếch tán như thế nào.
5. [Neural Discrete Representation Learning](https://arxiv.org/abs/1711.00937) Giới thiệu VQ-VAE, cơ chế nền tảng cho các biểu diễn tiềm ẩn rời rạc được học.
6. [Simple and Effective Masked Diffusion Language Models](https://arxiv.org/abs/2406.07524) Trình bày khung khuếch tán rời rạc có che mặt nạ được dùng làm bộ sinh tiềm ẩn trong nghiên cứu chẩn đoán đi kèm.
7. [Nghiên cứu thực nghiệm về tiềm năng của LLM trong tái cấu trúc phần mềm tự động](https://arxiv.org/abs/2411.04444) Phát hiện các phép tái cấu trúc không an toàn do LLM đề xuất và đánh giá việc áp dụng lại những phép biến đổi đã phát hiện thông qua các công cụ tái cấu trúc đáng tin cậy.
8. [SWE-Refactor: A Repository-Level Benchmark for Real-World LLM-Based Code Refactoring](https://arxiv.org/abs/2602.03712) Đánh giá hoạt động tái cấu trúc ở cấp kho mã có bảo toàn hành vi bằng biên dịch, kiểm thử và phát hiện phép tái cấu trúc.
9. [EfficientEdit: Accelerating Code Editing via Edit-Oriented Speculative Decoding](https://arxiv.org/abs/2506.02780) Tái sử dụng các đoạn mã nguồn không thay đổi và dự đoán vị trí chỉnh sửa, thay vì xem một chỉnh sửa là quá trình tái sinh tự hồi quy toàn bộ.
10. [Hydra: Sinh mã hiệu quả và chính xác nhờ hỗ trợ điểm kiểm tra và quay lui](https://arxiv.org/abs/2605.15238) Sử dụng kiểm tra tĩnh, checkpoint và hoàn tác có mục tiêu để tránh tái sinh những tiền tố vốn đã hợp lệ sau khi xảy ra lỗi.

## Tóm lược ngắn

Sinh lại mã cục bộ là một giao ước giữa **thay đổi** và **bảo toàn** . Các biến tiềm ẩn rời rạc phân cấp cung cấp một cách có thể kiểm tra để biểu đạt hợp đồng đó, nhưng biểu diễn này chỉ hữu ích khi các chương trình đã giải mã được đánh giá về tính cục bộ, cú pháp, cấu trúc, hành vi, độ đa dạng và tính bất định.

## Các công bố thuộc hướng nghiên cứu này

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

Chất lượng suy giảm ở đâu trong quá trình sinh văn bản ngắn có nén: định vị nút thắt theo từng giai đoạn

Phương pháp luận chẩn đoán FRUCT 39 2026 Hội nghị chính

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

Cơ chế điều khiển có thể kiểm tra trong tái sinh phần mềm bảo toàn cấu trúc

Phương pháp điều khiển trong không gian tiềm ẩn FSE Companion '26 2026 Áp phích đi kèm