Thủ thuật
Đừng dùng nội dung AI rác để 'làm đẹp' hồ sơ GitHub nữa
(giờ Việt Nam)
Tóm tắt AI
Các nhà phát triển đang cảnh báo về làn sóng PR và báo cáo lỗi do AI tạo ra tràn lan, gây quá tải cho các dự án mã nguồn mở. Hành vi này không chỉ làm giảm chất lượng dự án mà còn làm xói mòn niềm tin trong cộng đồng lập trình.
Bản dịch AI
30 tháng 6 năm 2026 bởi Neil
Những đóng góp thành công cho các dự án mã nguồn mở giống như một loại tiền tệ. GitHub đặc biệt khuyến khích điều này theo nhiều cách: bằng cách hiển thị ảnh đại diện của những người đóng góp trên các trang repository, hiển thị các đóng góp của bạn cho người theo dõi thông qua bảng tin hoạt động (activity feed) và báo hiệu số lượng đóng góp mỗi ngày trên biểu đồ hoạt động trong hồ sơ của bạn. Các nhà quản lý tuyển dụng tiềm năng thường chú ý đến điều này. Các nhà tuyển dụng cũng thường tìm kiếm và sàng lọc ứng viên theo cách đó. Nếu bạn là một lập trình viên (đang làm việc hoặc có nguyện vọng) đang tìm kiếm cơ hội, việc tinh chỉnh những tín hiệu này thường có thể mang lại lợi thế cho bạn.
Với tư cách là người duy trì (maintainer) dự án mã nguồn mở, tôi nhận thấy mô hình đóng góp từ bên ngoài đã thay đổi rõ rệt trong năm qua. Chúng tôi nhận được nhiều pull request hơn hẳn thay vì các issue như trước. Nếu có nhận được issue, chúng thường đi kèm với các bản phân tích do AI tạo ra. Chúng tôi cũng nhận được nhiều báo cáo về lỗ hổng bảo mật hơn bao giờ hết, và thường thì chúng còn đi kèm với các đề xuất sửa lỗi do AI tạo ra.
Tôi không nghi ngờ việc một số đóng góp trong số này đến từ những người thực sự quan tâm đến công việc của chúng tôi, nhưng phần hoài nghi trong tôi tin rằng một lượng đáng kể trong đó xuất phát từ việc mọi người nhận ra AI có thể được sử dụng để "thao túng" GitHub nhằm trục lợi cá nhân. Giờ đây, thật dễ dàng để yêu cầu Claude tạo một danh sách các dự án mã nguồn mở thú vị, sau đó yêu cầu Claude tìm ra một vài vấn đề trong đó, và cuối cùng yêu cầu Claude tạo các PR để sửa chúng. Bạn thậm chí không cần phải sử dụng hay quan tâm đến các dự án đó, nhưng bạn có thể dễ dàng tạo ra ảo tưởng với người ngoài rằng bạn quan tâm, rằng bạn đã tìm ra vấn đề, hoặc bạn đã dành thời gian để khắc phục nó. Trên Internet, không ai biết bạn là một chú chó, nhưng với sự trợ giúp của các LLM, bạn có thể dễ dàng phóng đại năng lực con người của mình trên hồ sơ GitHub.
Gần đây, một người đóng góp hầu như không có hoạt động nào trên GitHub từ cuối năm 2018 cho đến vài tuần trước, và không có bất kỳ tương tác nào trước đó với dự án của chúng tôi mà chúng tôi biết, đã gửi ba PR riêng biệt để sửa lỗi chính tả và ngữ pháp trong các đoạn chú thích (comment). Claude đã thực hiện các bản sửa lỗi, có lẽ đã viết cả mô tả PR, thậm chí ký xác nhận các commit thay cho người dùng và sau đó chèn thông tin đồng tác giả vào phần cuối của thông báo commit một cách đầy "hữu ích". Biết đâu chính nó cũng là người mở các PR đó, ai mà biết được. Tôi rất tò mò muốn biết liệu câu lệnh (prompt) là "hãy đi tìm các vấn đề" hay là tập trung cụ thể vào các lỗi chính tả và ngữ pháp vì một lý do nào đó.
Những thay đổi đó vô hại và chính xác, nhưng điều đó không làm tôi cảm thấy thoải mái hơn khi chấp nhận hoặc hợp nhất (merge) chúng. Thay vào đó, tôi không thể không tự hỏi: tại sao lại là việc này, tại sao lại là lúc này? Tại sao trong tất cả các issue, các TODO và FIXME trong codebase của chúng tôi, họ lại gửi những thứ này? Và rồi tôi chợt nhận ra rằng những đóng góp này hoàn toàn không liên quan gì đến dự án của chúng tôi cả.
Tôi đã đóng cả ba PR đó mà không để lại bình luận nào.
Có lẽ điều này là vô lý, nhưng thành thật mà nói, tôi không hề muốn khuyến khích mọi người làm mất thời gian của chúng tôi bằng những công việc vô bổ kiểu này. Tôi không muốn tạo tiền lệ cho việc chấp nhận các PR không mang lại cải thiện thực chất nào, cũng như không muốn danh sách người đóng góp của chúng tôi trở thành phần thưởng cho việc nhờ một con robot sửa lỗi chính tả.
Mô hình tương tự cũng xuất hiện với các báo cáo lỗ hổng bảo mật. Các CVE theo truyền thống được ghi nhận cho người báo cáo, nhưng tất cả các báo cáo mà chúng tôi nhận được gần đây đều rõ ràng là do AI tạo ra. Tất nhiên, các bản sửa lỗi bảo mật luôn quan trọng, nhưng một lần nữa tôi lại tự hỏi liệu điều này xảy ra vì mọi người quan tâm đến các bản sửa lỗi hay vì họ đang tìm kiếm một "thành tích" dễ dàng. Gần đây, chúng tôi đã chọn lọc kỹ lưỡng hơn nhiều khi đánh giá mức độ nghiêm trọng của các báo cáo như vậy và trong một số trường hợp, từ chối cấp thông báo CVE cho các mục có mức độ nghiêm trọng thấp. Tôi có vài suy nghĩ về việc tiết lộ thông tin bảo mật riêng tư (private disclosure) đang dần biến mất, điều mà tôi có thể sẽ viết vào một dịp khác, nhưng nỗ lực cần thiết để phối hợp sửa lỗi riêng tư, thông báo tiết lộ và phát hành là đủ lớn để buộc chúng tôi phải chọn lọc.
Suy cho cùng, mã nguồn mở được xây dựng trên sự tin tưởng. Chỉ số quan trọng không phải là bạn có thể thuyết phục một LLM tạo ra bao nhiêu pull request, cũng không phải là bạn có thể tích lũy được bao nhiêu CVE, mà là liệu bạn có thể làm cho dự án trở nên tốt hơn một cách ý nghĩa hay không. Nếu bạn muốn đóng góp cho các dự án mã nguồn mở, hãy đóng góp vì bạn thực sự quan tâm. Nếu tất cả những gì bạn muốn chỉ là thêm một ô vuông màu xanh hay một huy hiệu người đóng góp, làm ơn hãy đi nơi khác.
Bài viết được AI dịch và tổng hợp tự động từ Hacker News Nổi bật (buzzing.cc bản dịch tiếng Trung). Liên kết bài gốc ở phía trên. Dữ liệu đồng bộ qua API công khai được ghi nguồn tại AI HOT (canonical) ↗. AIHOT.vn luôn dẫn nguồn đầy đủ — nếu bạn thấy điểm cần chỉnh sửa, hãy gửi ý kiến tại trang phản hồi.