KDE bắt đầu soạn thảo quy tắc về AI: "Đừng làm một cỗ máy trung gian cho có lệ"
Cộng đồng KDE Plasma đang thảo luận về bộ quy tắc mới đối với việc sử dụng AI và LLM trong phát triển phần mềm. Dự thảo nhấn mạnh nguyên tắc "đừng lười biếng", yêu cầu lập trình viên phải chịu trách nhiệm hoàn toàn về mã nguồn và tuyệt đối không lạm dụng AI để tạo nội dung hoặc vượt qua khâu kiểm duyệt.
Dù các mô hình ngôn ngữ lớn (LLM) và công cụ lập trình AI rất phổ biến trong phát triển phần mềm, cộng đồng mã nguồn mở vẫn còn chia rẽ sâu sắc về chủ đề này. Một mặt, có những dự án như GIMP cấm hoàn toàn AI khỏi mã nguồn của họ, trong khi các dự án khác như Nobara Linux và Omarchy lại hoàn toàn ủng hộ việc lập trình bằng AI. Tuy nhiên, vẫn có một con đường trung lập, chẳng hạn như dự án Linux Kernel, cho phép mã nguồn được hỗ trợ và tạo ra bởi AI nhưng yêu cầu mọi mã nguồn phải được con người kiểm tra và có mô tả yêu cầu gộp (merge request) thể hiện sự hiểu biết về đoạn mã được gửi lên. Đây có vẻ là hướng đi mà KDE Plasma sẽ hướng tới, dựa trên các quy tắc LLM gần đây được đề xuất cho KDE.
Dự thảo quy tắc LLM của KDE đã được đệ trình để thảo luận bởi trưởng nhóm dự án Nate Graham, và nó phác thảo các quy tắc được tổng kết gọn gàng bằng quy tắc vàng: "Đừng lười biếng". Trong bài viết thảo luận về quy tắc LLM của KDE, bản nháp đề xuất giải thích rằng "các đóng góp có việc sử dụng LLM một cách rõ ràng và lười biếng có thể bị phớt lờ hoặc đóng lại", và rằng "không ai nên biết nếu bạn sử dụng LLM", bởi vì đầu ra phải không thể phân biệt được với những gì bạn có thể tự làm mà không cần LLM. Dự thảo cũng đặt ra các quy tắc đối với văn bản do AI tạo ra, cấm sử dụng văn bản do AI tạo ra cho các yêu cầu gộp, thông điệp commit, hoặc trả lời câu hỏi và bình luận. Bản nháp hiện tại cũng tìm cách ngăn chặn việc tạo thêm gánh nặng cho các maintainer (người bảo trì) bằng cách giới hạn các thay đổi được tạo cảm hứng mơ hồ ("vibe-coded") mà các maintainer phải tự tay dọn dẹp và triển khai - một vấn đề mà những người bảo trì Godot từng gặp phải cách đây không lâu.
KDE dường như cũng kỳ vọng các nhà phát triển phải chịu trách nhiệm về mã nguồn do LLM tạo ra của họ, với bản nháp quy tắc cấm cụ thể việc thêm các tuyên bố tiết lộ dùng AI như một cách để ngụy biện cho công việc kém chất lượng. Dự thảo vẫn chưa được hoàn thiện và các cuộc thảo luận xung quanh quy tắc LLM dự kiến sẽ tiếp tục trong những ngày tới, sau đó phiên bản hoàn chỉnh sẽ được đưa vào tài liệu của KDE. Toàn bộ quy tắc LLM của KDE như sau:
Sử dụng LLM
Quy tắc vàng cho việc sử dụng LLM trong KDE là Đừng lười biếng: Đừng cố gắng dùng một công cụ để thay thế phán đoán của chính bạn, giao tiếp giữa người với người, hoặc quá trình học hỏi.
- Đừng chọn những lối tắt không bền vững.
- Đừng né tránh việc phát triển bản thân.
Kết quả sẽ là công việc kém chất lượng và cuối cùng trở thành rắc rối của người khác.
Không ai trong KDE nên biết nếu bạn sử dụng LLM—không phải vì bạn đang giấu giếm nó, mà bởi vì việc sử dụng nó tạo ra kết quả không thể phân biệt được với những gì bạn có thể tự làm. Các đóng góp sử dụng LLM một cách lười biếng và rõ ràng có thể bị bỏ qua hoặc từ chối.
Sử dụng LLM để tạo các đóng góp
KDE tuân theo nguyên tắc "con người trong vòng lặp" (human in the loop): bạn phải đưa ra các quyết định và điều chỉnh vượt ra ngoài việc chỉ đưa ra câu lệnh (prompt). Đầu ra phải thể hiện được tính con người độc đáo của bạn theo một cách nào đó.
Đừng làm "cỗ máy trung gian cho có lệ" ("meat proxy"). Ví dụ:
- Đừng gửi các thay đổi theo kiểu "vibe-coded" mà bạn không hiểu và không thể tự làm.
- Đừng gửi các thay đổi do LLM tạo ra mang tính chất dùng một lần như một "bản nháp đầu tiên hoặc bản chứng minh khái niệm để người bảo trì cải thiện".
- Đừng tiết lộ việc sử dụng LLM như một cách ngụy biện cho các lỗi tiềm ẩn hoặc chất lượng kém của một đóng góp mà bạn chưa bỏ nhiều công sức.
- Đừng thêm các thẻ "Assisted-by: [một LLM nào đó]" vào các commit của bạn; đó chỉ là quảng cáo miễn phí cho nhà cung cấp LLM.
Sử dụng LLM để tạo văn bản
Nói chung là không nên.
Những gì bạn sẵn sàng viết thường là giới hạn trên cho những gì người khác sẵn sàng đọc.
Mặt khác, LLM thường tạo ra những nội dung dài dòng, lan man, vô hồn, mang hơi hướng văn phong doanh nghiệp mà không ai muốn đọc; đừng làm vậy. Điều này bao gồm:
- Đừng sử dụng LLM để "tổ chức suy nghĩ của bạn" rồi sao chép-dán kết quả đi đâu đó. Hãy tự tổ chức suy nghĩ của chính mình.
- Đừng sử dụng LLM để tạo thông điệp commit và mô tả yêu cầu gộp. Hãy tự viết chúng.
- Đừng sử dụng LLM để tạo câu trả lời cho câu hỏi hoặc bình luận của ai đó, rồi sao chép-dán nó như thể đó là phản hồi của bạn. Hãy hiểu vấn đề và tự trả lời.
Một trường hợp sử dụng được chấp nhận duy nhất là viết văn bản bằng ngôn ngữ mẹ đẻ của bạn và sau đó dịch máy sang tiếng Anh, mà không có bất kỳ thay đổi nào về phong cách hay giọng điệu.
Các cách sử dụng LLM khác
Nếu bạn sử dụng LLM để gỡ lỗi các vấn đề hoặc tìm lỗi, hãy đảm bảo kết luận của nó là chính xác.
Nếu bạn sử dụng LLM để nghiên cứu, hoặc để thay thế việc đọc trực tiếp tài liệu API, hãy xác minh tính chính xác của những gì nó nói với bạn.
🖥️ KDE BẮT ĐẦU SOẠN THẢO QUY TẮC VỀ AI: "ĐỪNG LÀM MỘT CỖ MÁY TRUNG GIAN CHO CÓ LỆ"
Dù các mô hình ngôn ngữ lớn (LLM) và công cụ lập trình AI rất phổ biến trong phát triển phần mềm, cộng đồng mã nguồn mở vẫn còn chia rẽ sâu sắc về chủ đề này. Một mặt, có những dự án như GIMP cấm hoàn toàn AI khỏi mã nguồn của họ, trong khi các dự án khác như Nobara Linux và Omarchy lại hoàn toàn ủng hộ việc lập trình bằng AI. Tuy nhiên, vẫn có một con đường trung lập, chẳng hạn như dự án Linux Kernel, cho phép mã nguồn được hỗ trợ và tạo ra bởi AI nhưng yêu cầu mọi mã nguồn phải được con người kiểm tra và có mô tả yêu cầu gộp (merge request) thể hiện sự hiểu biết về đoạn mã được gửi lên. Đây có vẻ là hướng đi mà KDE Plasma sẽ hướng tới, dựa trên các quy tắc LLM gần đây được đề xuất cho KDE.
Dự thảo quy tắc LLM của KDE đã được đệ trình để thảo luận bởi trưởng nhóm dự án Nate Graham, và nó phác thảo các quy tắc được tổng kết gọn gàng bằng quy tắc vàng: "Đừng lười biếng". Trong bài viết thảo luận về quy tắc LLM của KDE, bản nháp đề xuất giải thích rằng "các đóng góp có việc sử dụng LLM một cách rõ ràng và lười biếng có thể bị phớt lờ hoặc đóng lại", và rằng "không ai nên biết nếu bạn sử dụng LLM", bởi vì đầu ra phải không thể phân biệt được với những gì bạn có thể tự làm mà không cần LLM. Dự thảo cũng đặt ra các quy tắc đối với văn bản do AI tạo ra, cấm sử dụng văn bản do AI tạo ra cho các yêu cầu gộp, thông điệp commit, hoặc trả lời câu hỏi và bình luận. Bản nháp hiện tại cũng tìm cách ngăn chặn việc tạo thêm gánh nặng cho các maintainer (người bảo trì) bằng cách giới hạn các thay đổi được tạo cảm hứng mơ hồ ("vibe-coded") mà các maintainer phải tự tay dọn dẹp và triển khai - một vấn đề mà những người bảo trì Godot từng gặp phải cách đây không lâu.
KDE dường như cũng kỳ vọng các nhà phát triển phải chịu trách nhiệm về mã nguồn do LLM tạo ra của họ, với bản nháp quy tắc cấm cụ thể việc thêm các tuyên bố tiết lộ dùng AI như một cách để ngụy biện cho công việc kém chất lượng. Dự thảo vẫn chưa được hoàn thiện và các cuộc thảo luận xung quanh quy tắc LLM dự kiến sẽ tiếp tục trong những ngày tới, sau đó phiên bản hoàn chỉnh sẽ được đưa vào tài liệu của KDE. Toàn bộ quy tắc LLM của KDE như sau:
Sử dụng LLM
Quy tắc vàng cho việc sử dụng LLM trong KDE là Đừng lười biếng: Đừng cố gắng dùng một công cụ để thay thế phán đoán của chính bạn, giao tiếp giữa người với người, hoặc quá trình học hỏi.
• Đừng chọn những lối tắt không bền vững.
• Đừng né tránh việc phát triển bản thân.
Kết quả sẽ là công việc kém chất lượng và cuối cùng trở thành rắc rối của người khác.
Không ai trong KDE nên biết nếu bạn sử dụng LLM—không phải vì bạn đang giấu giếm nó, mà bởi vì việc sử dụng nó tạo ra kết quả không thể phân biệt được với những gì bạn có thể tự làm. Các đóng góp sử dụng LLM một cách lười biếng và rõ ràng có thể bị bỏ qua hoặc từ chối.
Sử dụng LLM để tạo các đóng góp
KDE tuân theo nguyên tắc "con người trong vòng lặp" (human in the loop): bạn phải đưa ra các quyết định và điều chỉnh vượt ra ngoài việc chỉ đưa ra câu lệnh (prompt). Đầu ra phải thể hiện được tính con người độc đáo của bạn theo một cách nào đó.
Đừng làm "cỗ máy trung gian cho có lệ" ("meat proxy"). Ví dụ:
• Đừng gửi các thay đổi theo kiểu "vibe-coded" mà bạn không hiểu và không thể tự làm.
• Đừng gửi các thay đổi do LLM tạo ra mang tính chất dùng một lần như một "bản nháp đầu tiên hoặc bản chứng minh khái niệm để người bảo trì cải thiện".
• Đừng tiết lộ việc sử dụng LLM như một cách ngụy biện cho các lỗi tiềm ẩn hoặc chất lượng kém của một đóng góp mà bạn chưa bỏ nhiều công sức.
• Đừng thêm các thẻ "Assisted-by: [một LLM nào đó]" vào các commit của bạn; đó chỉ là quảng cáo miễn phí cho nhà cung cấp LLM.
Sử dụng LLM để tạo văn bản
Nói chung là không nên.
Những gì bạn sẵn sàng viết thường là giới hạn trên cho những gì người khác sẵn sàng đọc.
Mặt khác, LLM thường tạo ra những nội dung dài dòng, lan man, vô hồn, mang hơi hướng văn phong doanh nghiệp mà không ai muốn đọc; đừng làm vậy. Điều này bao gồm:
• Đừng sử dụng LLM để "tổ chức suy nghĩ của bạn" rồi sao chép-dán kết quả đi đâu đó. Hãy tự tổ chức suy nghĩ của chính mình.
• Đừng sử dụng LLM để tạo thông điệp commit và mô tả yêu cầu gộp. Hãy tự viết chúng.
• Đừng sử dụng LLM để tạo câu trả lời cho câu hỏi hoặc bình luận của ai đó, rồi sao chép-dán nó như thể đó là phản hồi của bạn. Hãy hiểu vấn đề và tự trả lời.
Một trường hợp sử dụng được chấp nhận duy nhất là viết văn bản bằng ngôn ngữ mẹ đẻ của bạn và sau đó dịch máy sang tiếng Anh, mà không có bất kỳ thay đổi nào về phong cách hay giọng điệu.
Các cách sử dụng LLM khác
Nếu bạn sử dụng LLM để gỡ lỗi các vấn đề hoặc tìm lỗi, hãy đảm bảo kết luận của nó là chính xác.
Nếu bạn sử dụng LLM để nghiên cứu, hoặc để thay thế việc đọc trực tiếp tài liệu API, hãy xác minh tính chính xác của những gì nó nói với bạn.
🗞 Nguồn: TechPowerUp
#vgsnews #vgs #tintuc
Nguồn: TechPowerUp
