VI
Nhân vật REODE gốc được tinh chỉnh: khuôn mặt kỳ giông axolotl màu kem pha hồng đang cười, đeo tai nghe xanh navy và tròng kính xanh lơ
Trở lại phòng trưng bày

REODE

Code migration

Trước khi sửa, hãy tìm nguyên nhân chung.

Một tác nhân chuyển đổi mã Java/Spring.

2026.03 — 2026.04

Dự án công việc · hệ thống chuyển đổi và kiểm chứng

  • CLIĐã hiện thực · dự án công việc

Một vòng lặp chuyển đổi giữ bằng chứng sửa lỗi tách khỏi tiêu chí chấp nhận.

Trạng thái build gốc được ghi lại và chuyển đổi dựa trên quy tắc được áp dụng, rồi bằng chứng từ mã nguồn và POM được thu thập trước khi sửa. Sau khi mô hình chỉnh sửa, build, test và tính toàn vẹn của test được kiểm tra lại, và các lượt chạy kết thúc vì giới hạn hay bị kẹt được báo cáo tách khỏi thành công.

Nó kết hợp chuyển đổi dựa trên quy tắc với sửa chữa có mô hình hỗ trợ và kiểm tra mã đã thay đổi bằng build và test. Một dự án công việc.

Công việc REODE trong kho mã; thời gian hợp tác với pinxlab March 16, 2026 đến May 26, 2026

Một công cụ CLI dùng trong công việc.

Bản đồ vòng lặp sửa lỗi · từ các bản ghi hiện thực riêng tư
Vòng lặp sửa lỗi chuyển đổi của REODETrạng thái build gốc được giữ làm baseline, chuyển đổi dựa trên quy tắc được áp dụng, và build cùng test kiểm chứng kết quả. Khi thất bại, bằng chứng từ mã nguồn, annotation và POM được thu thập trước mọi bản sửa, và các mẫu đã biết được sửa tất định rồi build lại. Nếu build lại thành công, không gọi mô hình nào; nếu thất bại, một mô hình sửa với bằng chứng đã thu thập và chỉ dẫn sửa, và kết quả được kiểm chứng lại. Các lượt chạy kết thúc vì giới hạn vòng lặp hay bị kẹt vẫn đi đến đo lường nhưng không được tính là thành công, và scorecard chỉ xếp loại khi cả năm cổng chấp nhận đều đạt.Mã nguồn · POMĐầu vào chuyển đổi riêng tưScorecard · xếp loạiKhông phải một lần triển khaiBáo cáo lỗi · bị kẹtKhông tính là thành côngKiểm tra bản gốcTrạng thái gốc · compileTrạng thái lượt chạyBaseline · giá trị chưa biết không được đoBản ghi khôi phụcCheckpoint trước khi sửaBản sửa trước đó, cùng lỗiChuyển đổiKế hoạch → chuyển đổi dựa trên quy tắcKhám phá trước khi sửaBằng chứng nguyên nhân · 3 mã nguồn · POMSửa tất địnhSửa các mẫu đã biếtKiểm tra build lạiMô hình sửa chữaSửa với bằng chứng · chỉ dẫnKiểm chứngbuild · test · vòng lặp +1Bước tiếp theoTiếp tục · đo · tối đa 3Đo lườngTỷ lệ quy tắc · test · độ bao phủ5 cổng chấp nhậnĐầu vào · baselineBản ghi khôi phụcChuyển đổi · sửa chữaKiểm chứng · lối ra1 mã nguồn · POM · Mã nguồn · POM → Trạng thái gốc · compile12compile bản gốc3 chuyển đổi theo quy tắc · Trạng thái gốc · compile → Kế hoạch → chuyển đổi dựa trên quy tắc34build · test5kết quả · số vòng lặp6đạt · giới hạn · bị kẹt7so sánh baseline8xếp loại1kết quả · số vòng lặp2 thất bại · thử lại · Tiếp tục · đo · tối đa 3 → Bằng chứng nguyên nhân · 3 mã nguồn · POM23lưu trước khi sửa4bằng chứng · lỗi được nhóm5đạt · bỏ qua LLM6build lại thất bại7 bản sửa trước · Bản sửa trước đó, cùng lỗi → Sửa với bằng chứng · chỉ dẫn78kiểm chứng lại1đạt · giới hạn · bị kẹt2so sánh baseline3xếp loại4xóa · loại trừ · thất bại5lối ra giới hạn · bị kẹt

Chuyển đổi theo quy tắc

Trạng thái gốc được giữ làm baseline; sau chuyển đổi theo quy tắc, build và test kiểm chứng, và lượt chạy đi tiếp đến đo lường.

  1. Mã nguồn · POMmã nguồn · POMTrạng thái gốc · compileKiểm tra bản gốc

    Nhận mã nguồn Java/Spring và POM cần chuyển đổi. Mã và màn hình của khách hàng không được hiển thị.

  2. Trạng thái gốc · compileKiểm tra bản gốccompile bản gốcBaseline · giá trị chưa biết không được đoTrạng thái lượt chạy

    Trước khi chuyển đổi, runtime được chọn và bản gốc được compile, nên một build vốn đã hỏng được giữ trong baseline. Các giá trị test và độ bao phủ mặc định trong baseline không phải là phép đo.

  3. Trạng thái gốc · compileKiểm tra bản gốcchuyển đổi theo quy tắcKế hoạch → chuyển đổi dựa trên quy tắcChuyển đổi

    Đồ thị lượt chạy đi theo kiểm tra bản gốc → kế hoạch chuyển đổi → chuyển đổi dựa trên quy tắc → kiểm chứng. Những chuyển đổi mà quy tắc đảm nhận được sẽ được áp dụng trước.

  4. Kế hoạch → chuyển đổi dựa trên quy tắcChuyển đổibuild · testbuild · test · vòng lặp +1Kiểm chứng

    Build và test kiểm chứng mã đã chuyển đổi và số vòng lặp tăng thêm một. Kết quả quay về trạng thái lượt chạy.

  5. build · test · vòng lặp +1Kiểm chứngkết quả · số vòng lặpTiếp tục · đo · tối đa 3Bước tiếp theo

    Build thành công hay không, tỷ lệ test đạt và số vòng lặp quyết định bước tiếp theo.

  6. Tiếp tục · đo · tối đa 3Bước tiếp theođạt · giới hạn · bị kẹtTỷ lệ quy tắc · test · độ bao phủĐo lường

    Khi build và test đều đạt, chạm giới hạn vòng lặp, hoặc phát hiện bị kẹt (sau một lần thử khôi phục nếu chưa thử), lượt chạy đi đến đo lường. Đi đến đo lường không có nghĩa là thành công.

  7. Baseline · giá trị chưa biết không được đoTrạng thái lượt chạyso sánh baselineTỷ lệ quy tắc · test · độ bao phủĐo lường

    Đo lường đọc baseline được giữ trong trạng thái lượt chạy. Đây không phải một lượt chạy baseline mới.

  8. 5 cổng chấp nhậnĐo lườngxếp loạiScorecard · xếp loại

    Build thành công, tỷ lệ test đạt 100%, thay đổi độ bao phủ từ −5 trở lên (chỉ khi biết baseline), không test nào bị xóa, không loại trừ surefire nào. Chỉ xếp loại khi cả năm đều đạt.

Sửa chữa theo nguyên nhân

Bằng chứng được thu thập trước khi sửa và các bản sửa tất định đi trước. Nếu build lại thành công, mô hình được bỏ qua; nếu không, mô hình sửa với bằng chứng và chỉ dẫn và kết quả được kiểm chứng lại.

  1. build · test · vòng lặp +1Kiểm chứngkết quả · số vòng lặpTiếp tục · đo · tối đa 3Bước tiếp theo

    Build thành công hay không, tỷ lệ test đạt và số vòng lặp quyết định bước tiếp theo.

  2. Tiếp tục · đo · tối đa 3Bước tiếp theothất bại · thử lạiBằng chứng nguyên nhân · 3 mã nguồn · POMKhám phá trước khi sửa

    Nếu build thất bại hoặc tỷ lệ test đạt dưới 100%, và chưa chạm giới hạn vòng lặp (mặc định 3), lượt chạy đi đến sửa chữa.

  3. Bằng chứng nguyên nhân · 3 mã nguồn · POMKhám phá trước khi sửalưu trước khi sửaCheckpoint trước khi sửaBản ghi khôi phục

    Một checkpoint được lưu trước khi sửa. Đây là best-effort: lưu thất bại không dừng việc sửa, và một lần lưu không phải bằng chứng thành công.

  4. Bằng chứng nguyên nhân · 3 mã nguồn · POMKhám phá trước khi sửabằng chứng · lỗi được nhómSửa các mẫu đã biếtSửa tất định

    Thu thập các tệp Java bị lỗi, các dòng đầu của tối đa ba mã nguồn, cấu hình annotation, POM và annotation processor, và các import đến độ sâu 2. Một mẫu có giới hạn, không phải sự hiểu biết toàn bộ codebase.

  5. Kiểm tra build lạiSửa tất địnhđạt · bỏ qua LLMbuild · test · vòng lặp +1Kiểm chứng

    Nếu một bản sửa tất định cho mẫu đã biết (ví dụ cấu hình Lombok) khiến build lại thành công, không gọi mô hình nào. Lượt chạy vẫn quay về kiểm chứng, nên đây không phải chấp nhận cuối cùng.

  6. Kiểm tra build lạiSửa tất địnhbuild lại thất bạiSửa với bằng chứng · chỉ dẫnMô hình sửa chữa

    Nếu build lại thất bại, bằng chứng đã thu thập và chỉ dẫn sửa được chuyển cho mô hình sửa. Đọc mã cho thấy văn bản lỗi được chuyển kèm là lỗi build ban đầu, không phải lỗi mới của lần build lại, nên không được hiểu là “chỉ chuyển các lỗi còn lại”. Đây không phải lỗi đã được tái hiện trong một lượt chạy.

  7. Bản sửa trước đó, cùng lỗiBản ghi khôi phụcbản sửa trướcSửa với bằng chứng · chỉ dẫnMô hình sửa chữa

    Các bản sửa trước đó được ghi theo cùng chữ ký lỗi được tra cứu và đính kèm. Đây là bản ghi được thêm vào đầu vào, không phải huấn luyện mô hình.

  8. Sửa với bằng chứng · chỉ dẫnMô hình sửa chữakiểm chứng lạibuild · test · vòng lặp +1Kiểm chứng

    Mô hình sửa qua đường architect/editor có cấu trúc, hoặc một prompt tool-use khi đường đó không khả dụng hay đang khôi phục, rồi build và test kiểm chứng lại. Bản sửa của mô hình tự nó không phải là một build đạt.

Đạt hay bị kẹt

Xếp hạng cần đủ năm cổng; test bị xóa hay loại trừ và lối ra do giới hạn hay bị kẹt không được tính là thành công.

  1. Tiếp tục · đo · tối đa 3Bước tiếp theođạt · giới hạn · bị kẹtTỷ lệ quy tắc · test · độ bao phủĐo lường

    Khi build và test đều đạt, chạm giới hạn vòng lặp, hoặc phát hiện bị kẹt (sau một lần thử khôi phục nếu chưa thử), lượt chạy đi đến đo lường. Đi đến đo lường không có nghĩa là thành công.

  2. Baseline · giá trị chưa biết không được đoTrạng thái lượt chạyso sánh baselineTỷ lệ quy tắc · test · độ bao phủĐo lường

    Đo lường đọc baseline được giữ trong trạng thái lượt chạy. Đây không phải một lượt chạy baseline mới.

  3. 5 cổng chấp nhậnĐo lườngxếp loạiScorecard · xếp loại

    Build thành công, tỷ lệ test đạt 100%, thay đổi độ bao phủ từ −5 trở lên (chỉ khi biết baseline), không test nào bị xóa, không loại trừ surefire nào. Chỉ xếp loại khi cả năm đều đạt.

  4. 5 cổng chấp nhậnĐo lườngxóa · loại trừ · thất bạiBáo cáo lỗi · bị kẹt

    Kết quả đạt có được nhờ xóa test hay nhờ loại trừ surefire, và build hay test thất bại, vẫn là thất bại. Kiểm tra xóa và loại trừ đếm là không khi không đọc được Git hay POM, nên chúng không chứng minh mọi vi phạm đều bị phát hiện.

  5. Tiếp tục · đo · tối đa 3Bước tiếp theolối ra giới hạn · bị kẹtBáo cáo lỗi · bị kẹt

    Một lượt chạy kết thúc vì giới hạn hay bị kẹt vẫn đi qua đo lường nhưng không được báo cáo là thành công. Điều này đánh dấu cách báo cáo; nó không phải lối tắt bỏ qua đo lường.

Mọi kết nối có cùng độ đậm. Chọn một luồng để chỉ làm nổi bật đường đi của nó, kèm các bước được đánh số.

  • Nét liền · hướng đi của đầu vào, kết quả và bản ghi
  • Nét đứt · chạy, phán định, yêu cầu
  • Chấm dài · quan sát và báo cáo, tách khỏi phán định
  • Gạch ngắn · lỗi, dừng, giới hạn
  • Nét đen đậm · luồng được chọn; số chỉ thứ tự
  • Hộp · ranh giới mã hoặc trạng thái, tên ở phần đầu
  • Chip bên trong · một thành phần của ranh giới đó
  • Hộp chấm · bên ngoài ranh giới đó
  • Viền cam · nơi một mô hình quyết định
  • Các bước pipeline · sửa chữa
  • Kiểm chứng · định tuyến · chấp nhận
  • Trạng thái · bản ghi
  • Khám phá trước khi sửa

Vẽ từ các bản ghi hiện thực và phát triển riêng tư. Tên là tên công khai chung; không hiển thị đường dẫn mã hay thông tin khách hàng.

Đầu vào sau khi build lại thất bại
Mô hình sửa nhận bằng chứng đã thu thập và chỉ dẫn sửa, nhưng văn bản lỗi được chuyển kèm là lỗi build ban đầu, không phải lỗi mới của lần build lại. Điều này được xác lập bằng cách đọc mã; không tái hiện trong lượt chạy nào, và mã nguồn không bị thay đổi.
Giới hạn của các cổng
Nếu không biết baseline độ bao phủ, cổng đó được bỏ qua. Kiểm tra surefire đếm các loại trừ trong POM hiện tại, không phải chênh lệch so với baseline. Kiểm tra xóa và loại trừ đếm là không khi không đọc được Git hay POM.
Trường hợp và các con số
Khoảng 40 lỗi setter được truy về một nguyên nhân, cấu hình Lombok và POM, là một chẩn đoán được ghi lại khi đó. Đây không phải số liệu thông lượng, độ chính xác hay bàn giao cuối cùng.