Rust-lang/rust đang áp dụng chính sách về mô hình ngôn ngữ lớn (LLM).

rust-lang/rust áp dụng chính sách về mô hình ngôn ngữ lớn (LLM) | Blog Inside Rust Blog Inside Rust Rust Cài đặt Tìm hiểu Công cụ Quản trị Cộng đồng Sáng Tối Hệ thống rust-lang/rust đang áp dụng chính sách về LLM Ngày 5/8/2026 · Jynn Nelson Gần đây, năm nhóm trong dự án Rust đã thông qua một chính sách do tôi soạn thảo ban đầu, quy định cách sử dụng Mô hình ngôn ngữ lớn khi đóng góp vào kho lưu trữ đơn (monorepo) rust-lang/rust. Đáng chú ý, chính sách mới không phải là lập trường chính thức về LLM và không áp dụng cho mọi nơi trong dự án Rust. Tôi đã viết nó cho một mục đích rất cụ thể, được mô tả dưới đây. Bài đăng này nói về lý do chúng tôi tạo ra chính sách đó, nội dung của nó và cách điều này sẽ ảnh hưởng đến những người đóng góp. Chính sách này ảnh hưởng đến các nhóm người sau: Những người xem xét hoặc kiểm duyệt các yêu cầu kéo (PR) trên rust-lang/rust. Những người tạo PR với mã được tạo bởi LLM trên rust-lang/rust. Những người phát hiện vấn đề bằng LLM và đăng chúng trên rust-lang/rust. Những người viết vấn đề hoặc bình luận trích dẫn trực tiếp một LLM trên rust-lang/rust. Nếu bạn không thuộc một trong các nhóm đó, bạn không phải thay đổi bất cứ điều gì về cách làm việc của mình. Tại sao chính sách này được tạo ra? Mặc dù dự án Rust là một tập hợp các tạo phẩm kỹ thuật, nhưng nó cũng là một cộng đồng những người cùng nhau xây dựng, duy trì và mở rộng các tạo phẩm đó. Khi chúng ta nói về "đóng góp vào dự án Rust", chúng ta một phần có nghĩa là làm việc trên các tạo phẩm đó, nhưng chúng ta cũng có nghĩa là tham gia vào cộng đồng đó và cộng tác với những người đã có mặt. Ngay cả trước khi chính sách này được tạo ra, mọi người đã sử dụng LLM để đóng góp vào rust-lang/rust. Một số cách sử dụng đó đã tôn trọng cộng đồng của chúng tôi: dịch tin nhắn sang tiếng Anh để mọi người có thể soạn thảo bằng ngôn ngữ mẹ đẻ của họ; tìm các chẩn đoán kém cho các đoạn mã mà những người đóng góp mới cho Rust có thể viết; phân tích các yêu cầu bình luận (RFC) để xem liệu chúng có thiếu một cuộc thảo luận về các phần khác của ngôn ngữ có thể ảnh hưởng đến thiết kế hay không. Một số cách sử dụng đó, đôi khi không cố ý, đã không như vậy. Tôi đã thấy LLM gây ra ba vấn đề chính cho cộng đồng của chúng tôi: Các sản phẩm kỹ thuật được trau chuốt không còn cho thấy nỗ lực và sự hiểu biết. Việc làm cho mã dễ viết hơn làm trầm trọng thêm các vấn đề hiện có của chúng tôi về băng thông xem xét. Việc mọi người sao chép và dán một cách máy móc từ và đến một LLM là một sự lãng phí thời gian của chúng tôi. Theo thời gian, những vấn đề này ngày càng lớn, cho đến khi chúng tôi phải tạo ra các kênh chuyên dụng và chính sách kiểm duyệt để giải quyết chúng. Tuy nhiên, các kênh đó đi ngược lại mục tiêu của chúng tôi là minh bạch và chào đón, bởi vì những người đóng góp mới không biết các quy tắc là gì. Chính sách mới chính thức hóa các quy tắc đó một cách công khai, để những người đóng góp mới biết cách tham gia cộng đồng của chúng tôi mà không bị đóng PR vì những lý do mà họ không hiểu, và để những người xem xét hiện có có thể dễ dàng chỉ ra các quy tắc như một lý do có thể hành động khi đóng các PR không tuân thủ chúng. Các sản phẩm kỹ thuật không còn cho thấy nỗ lực Trước đây, nếu một dự án mã nguồn mở nhận được một PR được trau chuốt, được kiểm thử kỹ lưỡng, chi tiết, điều đó cho thấy có một người ở đầu bên kia đã dành thời gian, nỗ lực và sự hiểu biết vào PR đó. Điều đó đã ảnh hưởng đến văn hóa của Rust theo một số cách: Chúng tôi thường miễn cưỡng đóng PR, vì chúng đại diện cho công việc khó khăn của người khác. Quy trình của chúng tôi nhấn mạnh các cuộc thảo luận tăng dần, trong đó các PR (Pull Request) được phép thay đổi thiết kế hiện có nếu chúng tôi phát hiện ra những thông tin mới trong quá trình tạo hoặc xem xét. Chúng tôi coi PR là một dấu hiệu cho thấy ai đó quan tâm đến việc tham gia cộng đồng của chúng tôi và được hướng dẫn để làm việc trên các PR trong tương lai. Với các LLM (mô hình ngôn ngữ lớn), không có tín hiệu nào trong số này đáng tin cậy. Các PR được trau chuốt không còn cho thấy sự nỗ lực; tác giả của các PR được trau chuốt không còn nhất thiết phải hiểu mã của họ—và trong trường hợp các tác nhân tự trị, không còn ai ở đầu bên kia nữa; và bởi vì việc viết mã đã trở nên dễ dàng hơn rất nhiều, một PR được trau chuốt không còn cho thấy ai đó có khả năng gắn bó lâu dài. Việc làm cho mã dễ viết hơn gây ra các vấn đề trong quá trình xem xét. Tại thời điểm viết bài, có 1.281 PR đang mở đối với rust-lang/rust. Điều này thể hiện một lượng thời gian khổng lồ được đầu tư bởi cả tác giả và người xem xét. Chúng tôi từ lâu đã gặp vấn đề là có nhiều người muốn viết mã hơn là người sẵn lòng xem xét nó. Với sự ra đời của các LLM, vấn đề này chỉ trở nên tồi tệ hơn. Hầu hết công việc xem xét không chỉ đơn thuần là tìm lỗi. Phần lớn công việc là quyết định xem hướng này có phải là một cách tiếp cận tốt không, liệu PR có phải là một ý tưởng hay không. Nói cách khác, việc xem xét được tạo thành từ các quyết định. Việc "bắn phá" PR vào người xem xét gây ra chi phí tinh thần cao cho họ. Tôi nghĩ hầu hết các tác giả của PR do LLM tạo ra đều tin rằng họ đang thực sự giúp đỡ, nhưng từ góc độ của chúng tôi, bản thân mã là phần nhỏ nhất và theo một cách nào đó là phần ít quan trọng nhất của sự thay đổi. Chúng tôi quan tâm nhiều hơn đến việc tác giả hiểu mã làm gì, lập kế hoạch cách nó sẽ thay đổi trong tương lai và quyết định nó nên trông như thế nào. Bản thân mã không thể giúp ích gì cho những điều đó. Việc sao chép-dán cơ học đầu ra của LLM là một sự lãng phí thời gian. Chúng tôi thường gặp những người phản hồi các bình luận xem xét bằng cách sao chép-dán chúng vào LLM của họ, sau đó sao chép-dán phản hồi của nó trở lại GitHub. Nói thẳng ra: đây là sự lãng phí thời gian của mọi người. Nếu chúng tôi muốn ý kiến của một LLM, chúng tôi đã có thể tự hỏi nó. Chúng tôi muốn nghe suy nghĩ của bạn, không phải của một cỗ máy. Hơn nữa, đây là sự vi phạm lòng tin giữa người xem xét và tác giả. Giả định của chúng tôi khi xem xét là chúng tôi đang nói chuyện với một người thật sự muốn làm công việc tốt nhất của họ. Việc dán văn bản từ LLM tạo ra sự nghi ngờ: liệu tác giả có thực sự quan tâm không? Có người thật ở đây không? Vậy tại sao lại có một chính sách? Trước chính sách này, chúng tôi có một cách tiếp cận "miền Tây hoang dã" đối với việc kiểm duyệt. Chúng tôi có hàng chục PR do LLM tạo ra; không có quy tắc tiết lộ; mọi người cố gắng thêm các tối ưu hóa MIR (Mid-level Intermediate Representation) rủi ro làm PR đầu tiên của họ; và mọi người đăng "Xác minh: git diff --check" trong mô tả PR của họ như thể điều đó có tác dụng gì đó.