Quy định đóng góp code từ AI vào dự án mã nguồn mở

Cần làm gì trước khi gửi code có hỗ trợ từ AI lên upstream

Các dự án mã nguồn mở hiện đã công bố chính sách về code có hỗ trợ từ AI, và các chính sách này không đồng nhất với nhau. Vì vậy, thói quen rất đơn giản: hãy tìm chính sách trước khi viết patch, và công khai chính xác khi bạn gửi nó. Một quy tắc nằm dưới cả hai điều trên. Đừng bao giờ gửi một dòng code mà bạn không thể giải thích trong quá trình review.

Một patch đúng vẫn bị đóng nếu dự án cấm code được tạo tự động, hoặc nếu bạn giấu nguồn gốc của code đó. Cái giá phải trả sẽ gắn liền với tên tuổi của bạn, vì một maintainer nếu phát hiện ra sự thiếu trung thực sau đó sẽ không còn lý do gì để tin tưởng vào lịch sử đóng góp còn lại của bạn. Cần làm rõ một số thuật ngữ trước, vì các chính sách thường sử dụng chúng. LLM (large language model) là mô hình đứng sau agent lập trình của bạn. Một PR (pull request) trên GitHub cũng tương đương với một MR (merge request) trên GitLab, và mọi điều dưới đây áp dụng cho cả hai. DCO (developer certificate of origin) là dòng sign-off ở cuối commit message, và nó hóa ra lại là tâm điểm của toàn bộ cuộc tranh luận.

Các chính sách mã nguồn mở về code AI hiện nay

Các dự án đã phân hóa thành bốn nhóm chính. Mọi ví dụ dưới đây đều có thời điểm cụ thể, vì các văn bản này thay đổi liên tục.

Cấm. Hội đồng Gentoo đã bỏ phiếu vào ngày 14 tháng 4 năm 2024 rằng "nghiêm cấm đóng góp vào Gentoo bất kỳ nội dung nào được tạo ra với sự hỗ trợ của các công cụ AI xử lý ngôn ngữ tự nhiên". Hướng dẫn commit của NetBSD gọi đầu ra từ LLM là "code bị nhiễm bẩn" và "không được phép commit nếu không có sự chấp thuận bằng văn bản từ nhóm core". Tài liệu về nguồn gốc code của QEMU, tính đến tháng 8 năm 2026, vẫn tuyên bố dự án sẽ "TỪ CHỐI mọi đóng góp được cho là bao gồm hoặc bắt nguồn từ nội dung do AI tạo ra".

Chỉ dùng để phân tích. Hầu hết các lệnh cấm đều hẹp hơn so với tiêu đề. Tài liệu của QEMU nêu rõ chính sách này "không áp dụng cho các mục đích sử dụng AI khác, chẳng hạn như nghiên cứu API hoặc thuật toán, phân tích tĩnh hoặc gỡ lỗi, miễn là đầu ra của chúng không được đưa vào các đóng góp". Bạn có thể dùng agent để đọc code. Bạn không được phép ship những gì nó viết. Sự khác biệt đó là ranh giới làm việc trong hầu hết các dự án hạn chế, và đó là điều mọi người thường bỏ lỡ.

Yêu cầu công khai. Hội đồng Fedora đã phê duyệt chính sách về các đóng góp có hỗ trợ của AI vào tháng 10 năm 2025. Chính sách này cho phép sử dụng công cụ và đặt trách nhiệm lên cá nhân: người đóng góp là tác giả, chịu hoàn toàn trách nhiệm về toàn bộ đóng góp và phải công khai khi một phần đáng kể trong đó đến từ công cụ mà không có thay đổi. Linux kernel đã bổ sung trang hỗ trợ lập trình vào tài liệu quy trình của mình vào tháng 12 năm 2025, với phần ghi chú để lưu lại công cụ đã dùng và quy định nghiêm ngặt về người được phép sign off.

Chưa có văn bản quy định. Đây vẫn là trường hợp phổ biến. Một bản preprint từ tháng 5 năm 2026 đã khảo sát 1.000 repository phổ biến trên GitHub và chỉ tìm thấy 118 dự án có chính sách AI bằng văn bản. Sự im lặng không đồng nghĩa với sự cho phép. Hãy hỏi trong issue tracker bằng một câu trước khi bạn viết patch, và câu trả lời sẽ trở thành hồ sơ công khai mà bạn có thể dẫn chứng sau này.

Tại sao các maintainer đặt ra những quy tắc này

Lý do đầu tiên là khối lượng công việc review, và bài toán số học chỉ có một chiều. Một agent có thể tạo ra một merge request dài 400 dòng trông có vẻ hợp lý chỉ trong một phút. Việc review kỹ lưỡng yêu cầu đó tiêu tốn của một maintainer cả một buổi chiều, trong khi hầu hết các maintainer đều là tình nguyện viên. Chi phí gửi PR đã giảm xuống gần bằng 0. Chi phí review thì không hề thay đổi.

curl cho thấy điểm cuối của đường cong đó. Daniel Stenberg báo cáo vào giữa năm 2025 rằng khoảng một phần năm các báo cáo bảo mật gửi qua chương trình bug bounty của dự án là thứ mà ông gọi là AI slop: các báo cáo nêu tên đúng hàm, đúng đường dẫn code, mô tả một cuộc tấn công nghe có vẻ hợp lý, nhưng bên trong lại không có gì cả. Dự án đã chấm dứt chương trình bounty vào đầu năm 2026 thay vì tiếp tục tài trợ cho làn sóng rác này. Đó là các báo cáo thay vì các bản vá, nhưng chính cơ chế đó khiến một maintainer cảm thấy mệt mỏi ngay khi mở PR của bạn.

GNOME Calendar đã ghi lại vấn đề này dưới dạng một nhãn (label). Vào tháng 6 năm 2026, dự án đã giới thiệu nhãn "Probabilistically Automated" (Tự động hóa theo xác suất) cho các merge request cho thấy "sự phụ thuộc lớn hoặc hoàn toàn vào 'trí tuệ' nhân tạo để tạo code", và chỉ ra chính xác triệu chứng: "thường đi kèm với việc thiếu kiểm thử đúng cách, và hoàn thiện các bản vá dựa trên hành vi dự kiến về mặt lý thuyết thay vì tính đúng đắn của code". Hãy đọc kỹ cụm từ cuối đó hai lần. Code trông có vẻ như sẽ chạy được. Nhưng không ai kiểm tra xem nó có thực sự chạy được hay không.

Lý do thứ hai là nguồn gốc (provenance), nghĩa là code đến từ đâu và theo giấy phép nào. QEMU nêu rõ xung đột này: việc ký xác nhận (sign-off) khẳng định rằng bạn "hiểu đầy đủ về bản quyền và tình trạng giấy phép của nội dung" mà bạn đóng góp, trong khi tình trạng bản quyền của kết quả đầu ra từ model vẫn chưa được giải quyết. Hội đồng của Gentoo cũng đưa ra lý do tương tự, cùng với các vấn đề về chất lượng và đạo đức. Bạn không nhất thiết phải đồng ý với cách hiểu về pháp lý này. Nhưng bạn phải nhận ra rằng đây là quyết định của maintainer, không phải của bạn.

Làm thế nào để tìm chính sách AI của một dự án?

Hãy tìm ở những nơi sau, theo thứ tự này.

• CONTRIBUTING.md trong thư mục gốc của repository, sau đó là .github/CONTRIBUTING.md, rồi đến bất kỳ tệp DCO nào nằm cạnh đó.
• Tài liệu dành cho nhà phát triển. QEMU lưu quy định của họ trong docs/devel/code-provenance.rst. Kernel lưu quy định của họ trong Documentation/process/coding-assistants.rst.
• Trang web hoặc wiki của dự án. Chính sách của Gentoo nằm trên trang wiki của hội đồng, còn của NetBSD nằm trong hướng dẫn commit.
• Trình theo dõi issue và kho lưu trữ mailing list. Một chính sách thường tồn tại ở đó nhiều tháng trước khi có ai đó viết nó vào repository.

Từ bên trong một bản checkout, một lệnh grep có thể bao quát hầu hết các trường hợp:

grep -rniE '(llm|copilot|chatgpt|generative|ai-generated|ai-assisted)' CONTRIBUTING.md docs/ .github/ 2>/dev/null | head -20

Sau đó, hãy đọc lịch sử của chính dự án đó, vì quy ước đã được commit luôn có giá trị hơn bất kỳ bản tóm tắt nào:

git log --format='%(trailers:key=Assisted-by,valueonly)' | grep . | sort | uniq -c
git log --format='%(trailers:key=AI-used-for,valueonly)' | grep . | sort | uniq -c

Một con số bên cạnh giá trị trailer cho bạn biết hình thức mà dự án này thực sự sử dụng. Kết quả trống nghĩa là chưa có ai công khai theo hình thức đó tại đây, đây cũng là một thông tin hữu ích. Nếu dự án nằm trên GitHub và workflow đó còn mới với bạn, cách pull request và fork hoạt động trên GitHub sẽ giải thích các cơ chế mà phần này đang giả định.

Công khai trong trailer của commit, không phải trong comment

Trailer là một dòng Key: value nằm ở đoạn cuối của thông báo commit. Git đã sử dụng định dạng này cho Signed-off-by: và Co-authored-by:, và các công cụ đều có thể phân tích nó, vì vậy đây là cách công khai duy nhất đi kèm với code vào trong cây thư mục.

net: release the buffer on the error path

The error path returned before releasing the buffer, so every failed
setup leaked one page.

Assisted-by: Claude:claude-3-opus coccinelle sparse
Signed-off-by: Your Real Name <you@example.com>

Kernel tài liệu hóa định dạng đó là Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2], và nó quy định rõ ràng về giới hạn của dòng này: "Các AI agent KHÔNG ĐƯỢC THÊM các thẻ Signed-off-by. Chỉ con người mới có thể xác nhận hợp pháp Developer Certificate of Origin (DCO)." Tên của agent sẽ nằm ở Assisted-by. Tên của bạn nằm ở Signed-off-by. Đừng bao giờ để công cụ tự viết dòng thứ hai, và đừng bao giờ để nó tự tạo ra một địa chỉ Co-authored-by không thuộc về ai cả.

Tên gọi có thể thay đổi, vì vậy hãy sao chép tên cục bộ thay vì tự bịa ra. Một bản patch gửi lên danh sách thư QEMU vào tháng 5 năm 2026 đã đề xuất nới lỏng lệnh cấm của dự án đó đối với các thay đổi cơ học, kiểm thử, tài liệu và sửa lỗi từ hai mươi dòng trở xuống, được ghi lại bằng một trailer như AI-used-for: tests, docs. Tính đến tháng 8 năm 2026, đó vẫn là một đề xuất trên danh sách thư và tài liệu đã commit vẫn từ chối nội dung được tạo tự động. Một dự án đã thay đổi quan điểm hai lần trong khoảng thời gian từ 2023 đến 2026. Bước đi tiếp theo sẽ không chờ đợi bạn, đó là lý do tại sao phương pháp quan trọng hơn danh sách.

git commit -s --trailer "Assisted-by: Claude:claude-3-opus" -m "net: release the buffer on the error path"
git log -1 --format='%(trailers:key=Assisted-by,valueonly)'

--trailer yêu cầu Git 2.32 trở lên. Lệnh thứ hai sẽ in giá trị trả về trực tiếp cho bạn. Một dòng trống nghĩa là git không phân tích được trailer, hầu như luôn luôn là do một dòng trống hoặc một câu thông thường nằm xen vào trong khối trailer ở cuối thông báo. Đối với một chuỗi commit bạn đã viết, git rebase --signoff origin/main sẽ thêm sign-off vào mọi commit, và git interpret-trailers --in-place --trailer "Assisted-by: Claude:claude-3-opus" msg.txt sẽ chỉnh sửa file thông báo.

Có hai chế độ lỗi cần lưu ý. Một bản squash merge sẽ viết lại thông báo commit, vì vậy trên một dự án thực hiện squash, hãy lặp lại việc công khai trong phần mô tả PR nơi người bảo trì (maintainer) sẽ đọc. Và một comment đánh giá không phải là một bản ghi, vì comment có thể bị chỉnh sửa và không bao giờ nằm trong lịch sử git.

Độ chính xác là con dao hai lưỡi. Assisted-by trên một commit bạn tự tay viết là nhiễu, và nó làm giảm giá trị các công bố thực sự của bạn. Bỏ qua nó trên một commit do agent viết là điều sẽ chấm dứt mối quan hệ công việc.

Signed-off-by thực sự xác nhận điều gì?

DCO là một văn bản ngắn, phiên bản 1.1, được công bố tại developercertificate.org và được sử dụng bởi kernel, QEMU cùng nhiều dự án khác. Việc thêm Signed-off-by: Your Name <you@example.com> nghĩa là bạn xác nhận nội dung đó. Hãy đọc kỹ những gì bạn đang xác nhận, vì hầu hết mọi người đều ký mà không bao giờ đọc nó.

Khoản (a) quy định rằng đóng góp "được tạo ra toàn bộ hoặc một phần bởi tôi và tôi có quyền gửi nó theo giấy phép mã nguồn mở được chỉ định trong tệp". Khoản (b) bao gồm các công việc dựa trên mã nguồn mở trước đó mà bạn có quyền truyền tải cùng với các sửa đổi. Khoản (c) bao gồm mã được chuyển cho bạn bởi một người đã xác nhận cùng nội dung đó. Khoản (d) quy định rằng bạn hiểu rằng đóng góp và thông tin cá nhân trong chữ ký của bạn là công khai và được lưu giữ vô thời hạn.

Hãy lưu ý những gì còn thiếu. DCO không bao giờ nói rằng bạn đã tự tay gõ từng ký tự. Nó nói rằng bạn có quyền gửi mã đó theo giấy phép này. Đó là lý do tại sao mã được tạo tự động (generated code) gây khó khăn ở đây: vấn đề không phải là quyền tác giả, mà là liệu bạn có thể giải trình về nguồn gốc của nó hay không. Hầu hết các dự án yêu cầu sign-off cũng yêu cầu tên thật, vì vậy bút danh sẽ không vượt qua được kiểm tra này. Hãy thêm dòng đó bằng git commit -s, lệnh này sẽ đọc user.name và user.email từ cấu hình git của bạn. Khi bot DCO từ chối PR của bạn và chỉ ra commit thiếu dòng này, git rebase --signoff origin/main và một lệnh force push vào branch của bạn sẽ khắc phục được vấn đề.

Ký một commit không giống với việc sign-off

git commit -s thêm một dòng văn bản vào commit. git commit -S tạo một chữ ký mã hóa trên đối tượng commit bằng key GPG hoặc SSH của bạn. Chúng giải quyết các vấn đề khác nhau. Chữ ký xác nhận rằng commit này đến từ người sở hữu key đó và không bị thay đổi kể từ lúc ký. Nó không nói gì về nguồn gốc của mã nguồn bên trong; vì vậy, một commit đã ký nhưng chứa mã nguồn được tạo tự động mà không khai báo vẫn là một commit đã ký, nhưng vi phạm chính sách. Sign-off là tuyên bố về nguồn gốc. Chữ ký là tuyên bố về danh tính. Các dự án yêu cầu cả hai sẽ đòi hỏi bạn thực hiện cả hai thao tác này.

Đừng bao giờ gửi code mà bạn không thể giải thích trong phần review

Đây là bài kiểm tra, và nó không thực sự nói về sự trung thực. Với mỗi dòng code: nó dùng để làm gì, và điều gì sẽ hỏng nếu thiếu nó? Nếu thiếu một trong hai câu trả lời, bản vá chưa sẵn sàng, vì bình luận review sẽ xuất hiện và câu trả lời của bạn sẽ lại là một vòng tạo code mới. Người review có thể nhận ra điều đó. Đó là khoảnh khắc một người đóng góp trở thành gánh nặng. Hãy tự hỏi câu tương tự về các trường hợp biên, input rỗng, đường dẫn lỗi, hoặc caller thứ hai.

Hãy chạy thử. Build nó, chạy bộ test suite của dự án, và viết một bản reproducer cho lỗi mà bạn khẳng định đã sửa. Tài liệu kernel đưa ra phương án dự phòng trung thực bằng những từ ngữ đơn giản: "Nếu bản sửa lỗi không thể build hoặc test, hoặc không thể tạo ra reproducer, hãy nói rõ điều đó: các maintainer hiện đang lãng phí quá nhiều thời gian để phân tích các báo cáo chưa xác minh và các bản sửa lỗi chưa được test." Viết "Tôi không thể test điều này trên phần cứng thực tế" không làm bạn mất gì cả. Ngụ ý rằng bạn đã làm điều đó sẽ khiến bạn bị loại khỏi dự án.

Hãy tự trả lời các bình luận review, bằng ngôn ngữ của chính bạn và theo thời gian của bạn. Một phản hồi xuất hiện sau bình luận ba mươi giây và lặp lại nó trong năm đoạn văn sẽ cho maintainer biết chính xác chuyện gì đã xảy ra. Hãy giữ cho diff nhỏ gọn. Bốn mươi dòng code mà bạn hiểu hoàn toàn có giá trị với dự án hơn là bốn trăm dòng refactor mà bạn chỉ giám sát. Nếu agent của bạn liên tục đưa ra nhiều hơn những gì bạn yêu cầu, một kỹ năng buộc nó thực hiện thay đổi nhỏ nhất có thể là một cách để giữ cho bản vá ở mức mà bạn vẫn có thể bảo vệ từng dòng một.

Lưu trữ hướng dẫn cho agent trong repository

Các hướng dẫn bạn cung cấp cho agent là một phần trong toolchain của bạn, vì vậy hãy coi chúng như mã nguồn. Một file nằm tại thư mục gốc của repository, thường là AGENTS.md, sẽ chứa lệnh build, lệnh test, định dạng commit message, yêu cầu sign-off và các quy tắc style mà dự án đã ghi lại. File đó được quản lý phiên bản và có thể review, đảm bảo tính nhất quán giữa hôm nay và ngày mai. Các hướng dẫn được gõ lại từ trí nhớ trong mỗi phiên làm việc sẽ tạo ra các bản patch khác nhau, và bạn sẽ không biết phiên làm việc nào đã tạo ra bản patch bị từ chối. Viết file AGENTS.md mà cả agent và con người đều có thể đọc được sẽ hướng dẫn chi tiết về file này.

Một lưu ý về repository của người khác. Đừng thực hiện đóng góp đầu tiên bằng một PR thêm file hướng dẫn agent vào dự án mà bạn không quản lý. Điều này trông giống như một nỗ lực áp đặt chính sách công cụ của dự án từ bên ngoài, và là cách nhanh nhất để tài khoản của bạn bị gắn với những thứ mà các maintainer đã quá mệt mỏi. Hãy giữ file đó trong fork của bạn cho đến khi có người yêu cầu.

Nơi bạn chạy agent cũng quan trọng vì lý do tương tự. Một agent có khả năng build dự án và chạy các bài test bên trong một sandbox mà bạn kiểm soát sẽ cung cấp cho bạn một bản patch đã được xác thực thực tế; đây là sự khác biệt giữa việc công khai sự hỗ trợ và công khai một dự đoán. Chạy coding agent trên VPS của riêng bạn đề cập đến thiết lập đó, và những khác biệt thực tế giữa Claude Code, Cursor, Codex và Copilot giải thích cách các công cụ này khác nhau trong quá trình sử dụng hàng ngày.

Quy trình sau khi chính sách thay đổi

1. Tìm chính sách đã công bố trước khi viết bất cứ thứ gì: repository, tài liệu dành cho nhà phát triển, trang web, hoặc trình theo dõi lỗi.
2. Nếu không có chính sách, hãy hỏi trong issue bằng một câu duy nhất và lưu lại câu trả lời.
3. Công khai theo biểu mẫu mà dự án sử dụng, trong commit trailer, và lặp lại trong nội dung PR nếu dự án thực hiện squash commit.
4. Ký xác nhận (sign off) bằng tên thật của bạn, với hiểu biết rằng dòng này là tuyên bố về quyền gửi mã nguồn của bạn.
5. Tự review bản vá của chính mình như thể một người lạ đã viết nó, vì thực tế là đã có người làm vậy.

Mọi dự án được nêu trên trang này sẽ thay đổi vào thời điểm bạn đọc nó. Năm bước này thì không thay đổi.

FAQ

Tôi có bắt buộc phải công khai việc sử dụng AI coding agent không?

Hãy kiểm tra dự án, vì câu trả lời được quy định tại từng nơi. Fedora yêu cầu công khai khi một phần đáng kể đóng góp đến từ công cụ mà không có sự chỉnh sửa. Linux kernel yêu cầu một trailer Assisted-by. Gentoo và QEMU, tính đến tháng 8 năm 2026, không chấp nhận loại đóng góp này. Nếu không có quy định cụ thể, bạn vẫn nên công khai trong commit trailer. Một maintainer nếu phát hiện ra sau đó sẽ phản ứng với việc bạn giấu giếm thay vì công cụ, và phản ứng đó sẽ ảnh hưởng đến tất cả những đóng góp khác của bạn.

Những dự án mã nguồn mở nào cấm code do AI tạo ra?

Dưới đây là tình hình tính đến tháng 8 năm 2026: Gentoo từ tháng 4 năm 2024, NetBSD coi kết quả từ LLM là code bị nhiễm bẩn cần sự phê duyệt từ core team, QEMU từ chối các đóng góp bắt nguồn từ nội dung được tạo tự động, và một số ứng dụng GNOME bao gồm Loupe và Calendar. Hãy đọc văn bản quy định của từng dự án thay vì dựa vào danh sách này, vì nó sẽ sớm lỗi thời. Lưu ý ngoại lệ mà hầu hết các dự án đều có: việc sử dụng model để nghiên cứu API, chạy static analysis hoặc hỗ trợ debug thường được chấp nhận, miễn là kết quả đầu ra của nó không nằm trong patch.

Sự khác biệt giữa Signed-off-by và một signed commit là gì?

Signed-off-by là một dòng văn bản thuần được thêm vào bởi git commit -s. Nó xác nhận developer certificate of origin, nghĩa là bạn có quyền gửi code này theo giấy phép của dự án. Một signed commit, được thực hiện với git commit -S, là một chữ ký mã hóa trên commit object bằng GPG hoặc SSH key của bạn. Nó chứng minh commit đến từ key của bạn và không bị thay đổi. Nguồn gốc và danh tính là hai yêu cầu riêng biệt, vì vậy một signed commit vẫn có thể vi phạm chính sách về AI.

Tôi có thể đặt thông tin công khai trong mô tả pull request thay vì commit message không?

Hãy đặt nó trong commit message, vì đó là bản ghi lưu lại trong lịch sử git và đi kèm với code cho bất kỳ ai clone repository sau này. Mô tả pull request có thể bị chỉnh sửa sau đó và chỉ tồn tại trên nền tảng lưu trữ. Hãy thêm nó vào nội dung PR nếu dự án sử dụng squash merge, vì squash sẽ viết lại commit message của bạn và có thể làm mất trailer.

Pull request của tôi bị đóng vì nó được tạo bởi AI. Tôi phải làm gì?

Đừng tranh cãi về chính sách trong thread, vì người đóng PR không phải là người duy nhất đặt ra quy tắc và thread đó không phải là nơi để thay đổi quy tắc. Hãy đọc văn bản chính sách, sau đó quyết định xem bạn có thể tuân thủ hay không. Ở những dự án cấm patch được tạo tự động, một báo cáo lỗi rõ ràng kèm theo cách tái hiện (reproducer) mà không cần patch vẫn được hoan nghênh, và đó thường là đóng góp hữu ích hơn. Nếu bạn quay lại với code, hãy mang đến một thay đổi nhỏ mà bạn có thể giải trình từng dòng một.