Tải AX Code · Miễn phíTài liệu

Trang này được dịch từ tài liệu tiếng Anh. Lệnh, định danh và ví dụ giữ nguyên. Runtime 7.24.4 · SDK 2.6.7. Bản tiếng Anh

Thay đổi đa mô hình đã xác minh

Trạng thái: Đang hoạt động Phạm vi: trạng thái hiện tại Xem xét lần cuối: 2026-08-21 Chủ sở hữu: môi trường chạy AX Code

Một trang quy trình cho việc “Tôi có một thay đổi có hệ quả, tôi muốn nhiều hơn một lần thử, và tôi muốn chính các kiểm tra của kho quyết định lần thử nào đáng giữ.”

Để xem tham chiếu chế độ — cờ, khóa cấu hình, đầu vào xếp hạng — xem Chế độ thực thi. Trang này là tác vụ từ đầu đến cuối.

Khi nào việc này đáng làm

Chạy nhiều mô hình tốn gấp nhiều lần so với chạy một mô hình. Nó đáng khi thay đổi có hệ quả và việc phát hiện lỗi sau này rất đắt: một tái cấu trúc xuyên ranh giới mô-đun, một di chuyển, một bản sửa trong mã nhạy về bảo mật, hoặc một thay đổi mà bạn thực sự không biết cách tiếp cận nào đúng.

Nó không đáng cho một sửa một dòng, một lần đổi tên, hay bất cứ thứ gì bạn có thể xác minh bằng cách đọc.

Hai công cụ khác nhau

Công cụ Nó tạo ra gì Có ghi tệp?
council ý kiến rà soát độc lập, đã tổng hợp Không
arena các triển khai ứng viên, đã xếp hạng Chỉ trong worktree tách biệt

Dùng council để quyết định làm gì — nó quạt một câu hỏi thiết kế hoặc rà soát ra nhiều nhà cung cấp đã kết nối và tổng hợp câu trả lời thành các phát hiện đồng thuận, đa số chặt, thiểu số và đơn lẻ, với các vòng tranh luận ẩn danh tùy chọn. Nó mang tính tham khảo. Sự đồng ý giữa các mô hình không phải bằng chứng đúng; đó là tín hiệu về mức tranh cãi của câu hỏi.

Dùng arena để quyết định triển khai nào nên giữ.

Quy trình triển khai trên sàn đấu

1. Chuẩn bị

Chế độ triển khai cần một dự án Git có ít nhất một commit và một worktree chính sạch. Worktree của người tranh được tạo từ một commit gốc chính xác và không thể thừa hưởng thay đổi chưa commit, nên hãy commit hoặc stash trước.

Bạn cũng cần ít nhất hai mô hình có thể chọn, khác nhau, trên các nhà cung cấp đã kết nối (một cổng dùng chung được hỗ trợ), và modes.arena.enabled: true.

2. Chạy

/arena <task description>

Mỗi người tranh có worktree Git riêng được tạo từ commit gốc đã ghi, và một tác nhân triển khai chạy trong đó. Cây làm việc chính của bạn không bị người tranh sửa.

3. AX Code làm gì với mỗi ứng viên

  • Chụp các thay đổi đã theo dõi và chưa theo dõi của người tranh vào một commit nhánh bền vững, gồm mọi commit mà chính tác nhân đã tạo.
  • Chạy các lệnh xác minh dự án đã phát hiện — kiểm tra kiểu, kiểm thử, lint — nhưng chỉ sau khi một bản vá không rỗng được ghi. Một bản vá rỗng không thể thắng.
  • Xếp hạng xác minh trước theo mặc định: chỉ các bản vá đã hoàn tất, không rỗng, vượt xác minh mới đủ điều kiện thắng. Trong các ứng viên đạt, nó ưu tiên rủi ro thấp hơn và bản vá đa dạng hơn.

4. Quyết định

Báo cáo đưa cho bạn đường dẫn worktree, tên nhánh và phạm vi commit.

AX Code không hợp nhất người thắng. Hãy tự kiểm tra, hợp nhất hoặc cherry-pick. Đó là cố ý: xác minh nghĩa là “các kiểm tra bạn đã cấu hình đã đạt trên bản vá này”, một tín hiệu thật nhưng không thay cho việc xem lại.

5. Xem lại và, nếu cần, đảo ngược

Khi một ứng viên đã ở trong cây của bạn, các lệnh bằng chứng áp dụng như bình thường:

ax-code graph <sessionID>       # what the winning run actually did
ax-code risk <sessionID>        # heuristic risk signals for the change
ax-code session rollback <sessionID> --dry-run

Xem Bằng chứng thực thi.

"Đã xác minh" ở đây nghĩa là gì, một cách chính xác

Nó nghĩa là: các lệnh kiểm tra kiểu, lint và kiểm thử đã phát hiện của dự án đã chạy đối với bản vá của ứng viên đó, và chúng đã đạt.

Nó không nghĩa là thay đổi đúng, đầy đủ, an toàn hay được thiết kế tốt. Nếu bộ kiểm thử của bạn không bao phủ hành vi đã đổi, một ứng viên đạt chỉ chứng minh rằng không có gì đã được bao phủ bị vỡ. Xác minh nâng sàn; nó không chứng nhận trần.

Nó cũng không mở rộng sang sửa tương tác thông thường. Ứng viên sàn đấu và việc áp dụng tái cấu trúc có cổng thì chạy kiểm tra; một edit hoặc write bình thường trong phiên thường không tự động làm vậy. Hãy chạy verify_project khi bạn muốn bằng chứng đó được ghi cho một lần chạy thông thường.

Chi phí và các kiểu thất bại

  • Chi phí tăng theo số người tranh. Mỗi người chạy một tác nhân triển khai đầy đủ.
  • Một worktree bẩn dừng lần chạy trước khi bất cứ việc gì khác xảy ra, theo thiết kế.
  • Ít hơn hai mô hình khác nhau làm phép so sánh vô nghĩa, và công cụ báo cáo thay vì bịa một xếp hạng.
  • Mọi ứng viên đều có thể thất bại xác minh. Đó là một kết quả hữu ích: thường nghĩa là tác vụ được mô tả chưa đủ hoặc các kiểm tra của kho chặt hơn những gì tác nhân giả định.