- Tài liệu định nghĩa theo kiểu RFC mang tính hài hước một giao thức tiêu chuẩn nhằm tự động từ chối các đóng góp chất lượng thấp do AI tạo ra trong kho mã nguồn mở, cộng đồng và các nơi tương tự
- Chỉ cần maintainer của dự án dán URI tương ứng, nó sẽ hoạt động như một phương tiện chuẩn hóa để gửi tín hiệu từ chối "phát hiện AI slop"
- Tài liệu liệt kê các đặc điểm điển hình của đóng góp do AI tạo ra, đồng thời chỉ thẳng sự lãng phí tài nguyên bảo trì và rủi ro của các đầu ra chưa được kiểm chứng
- Tài liệu khẳng định rõ quan điểm rằng ngay cả khi nội dung gửi lên dựa trên LLM vượt qua test và đúng ngữ pháp, nếu không có hiểu biết về logic và kiến trúc thì về bản chất vẫn vô giá trị
- Dù là một văn bản châm biếm mượn hình thức RFC, nó phản ánh sự mệt mỏi rất thực tế của các maintainer trước tình trạng lạm dụng đóng góp tự động bằng AI trong hệ sinh thái mã nguồn mở
Abstract - Mục đích của tài liệu này
- Giao thức tiêu chuẩn để xử lý và loại bỏ các đóng góp ít công sức, do AI tạo ra được gửi tới kho mã nguồn, issue tracker, cổng báo cáo lỗ hổng và diễn đàn cộng đồng
- Áp dụng cho cả các dự án mã nguồn mở công khai lẫn hệ thống nội bộ của doanh nghiệp
1. Introduction - Vì sao bạn được dẫn tới trang này
- Bạn được dẫn tới trang này vì đóng góp của bạn đã kích hoạt hệ thống phát hiện AI slop tự động hoặc thủ công
- Cụ thể, một maintainer hoặc kỹ sư cấp cao đã xem nội dung gửi lên, buông một tiếng thở dài đầy hiện sinh sâu sắc, rồi lập tức ngắt kết nối và dán URI này
- Các từ khóa "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL" được dùng trong tài liệu này phải được hiểu là thước đo của "mức độ chúng tôi không muốn xem xét nội dung gửi này đến đâu"
2. Diagnostic Analysis - Những đặc điểm bị phát hiện trong nội dung gửi của bạn
- Kết quả phân tích từ vựng và cấu trúc của tài liệu bạn gửi cho thấy prompt engineering của bạn đã sai, và vì vậy chúng tôi đi đến kết luận rằng bạn nên tự thấy xấu hổ
- Khi bạn để một con vẹt xác suất viết thay PR, công bố lỗ hổng, bình luận issue và bài đăng diễn đàn, nó đã nói dối tất cả chúng ta
- Các đặc điểm sau đây đã bị phát hiện một cách rõ ràng đến mức áp đảo:
- Dùng giọng điệu quá lịch sự và máy móc
- Chứa API hoàn toàn không tồn tại nhưng được trình bày với mức độ tự tin cao
- Mã boilerplate phình to nhưng không giải quyết được bất kỳ vấn đề thực tế nào
- Dùng từ "delve" một cách nghiêm túc trong mô tả PR
- Giữ nguyên dấu vết đầu ra của LLM như "Certainly! Here is the revised output:" trong docstring, comment hoặc báo cáo bảo mật
- Đính kèm commit message 600 từ hoặc một bài luận lý thuyết khổng lồ chỉ để sửa một lỗi chính tả đơn giản
- Import các thư viện ảo giác không tồn tại như
utils.helpers - Thêm đoạn kết cho một bug report nhỏ bắt đầu bằng "In conclusion, this robust and scalable solution..."
- Cách đặt tên biến và hàm kỳ quặc, vô trùng mà một lập trình viên con người chạy bằng caffeine và thiếu ngủ không bao giờ có thể tạo ra
- Phụ thuộc hoàn toàn vào regex hoặc các khái niệm bị ảo giác ra, không hề hiểu kiến trúc hệ thống thực tế hay threat model
- Dấu vết dán mù quáng các khối ngữ cảnh lớn nhưng không liên quan vào prompt kiểu "fix this" hoặc "find a bug"
- Xin lỗi compiler trong lịch sử commit
- Theo định lý cơ bản của rác tự động: vì bạn đã không đọc, nên chúng tôi cũng sẽ không đọc
3. The Asymmetry of Effort - Sự bất đối xứng của nỗ lực
- Maintainer dự án, đội security triage và moderator cộng đồng, dù là tình nguyện viên không lương hay đồng nghiệp nội bộ đã kiệt sức, đều hoạt động dưới ràng buộc tài nguyên nghiêm ngặt
- Khi xem xét nhật ký giao dịch của nội dung bạn gửi:
- a. Ấn tượng ban đầu có vẻ thông minh không? - Có lẽ
- b. Nó có thực sự giải quyết được một vấn đề đã được kiểm chứng và có thể tái hiện không? - Không
- c. Nó có cố tình lãng phí quỹ thời gian hữu hạn của reviewer là con người không? - Có
- Tracker, forum và repository của dự án không phải là bãi rác cho các đầu ra copy-paste chưa được kiểm chứng dùng để cày xanh GitHub, săn bug bounty vô căn cứ, thổi phồng giả tạo tốc độ sprint, hoặc tuân thủ KPI doanh nghiệp một cách ác ý
- Đồng nghiệp của bạn không phải là dịch vụ xác minh LLM miễn phí
4. Resolution Protocol - Quy trình khắc phục
- Để khôi phục quyền ghi và lấy lại niềm tin của đồng nghiệp, bạn phải thực hiện đúng thứ tự quy trình sau:
- 1. Chạy
rm -rftrên branch cục bộ, file văn bản hoặc script lỗ hổng bị ảo giác đã tạo ra nội dung gửi đó - 2. Tiến hành hard reboot cho bộ não hữu cơ
- 3. Đọc codebase thực tế, tài liệu dự án hoặc threat model và tự mình kiểm chứng trạng thái công việc cũng như logic
- 4. Không quay lại cho đến khi đạt được ý thức có thể kiểm chứng và sẵn sàng tự gõ bằng ngón tay người
- 1. Chạy
5. Security Considerations
- Trạng thái: Bị từ chối
- Chẩn đoán: đang vận hành bằng một script Python viết cẩu thả giấu bên trong áo trench coat
- Hành động: ngắt kết nối
6. Punitive Actions - Biện pháp trừng phạt và hạ cấp tài khoản
- Do đã gửi AI slop, tài khoản của bạn tự động bị chuyển vào Trough of Sorrow™(Máng buồn bã), và trong thời gian bị quản chế có thể bị áp dụng các hạn chế sau:
- Quyền trên repository bị ép hạ từ
WRITExuốngWISHFUL_THINKING - Mọi PR trong tương lai sẽ được định tuyến qua modem quay số 14.4k baud nối với máy in dot-matrix đã cạn vĩnh viễn ruy-băng màu lục lam
- Gõ
git push -fsẽ bị remap alias git để chạyrm -rf /và phát tiếng kèn trombone buồn - Font mặc định của IDE bị khóa vĩnh viễn thành Comic Sans 7pt
- Quyền trên repository bị ép hạ từ
- Không thể liên hệ quản trị viên - hiện họ đang cười nhạo bạn trong kênh Slack riêng
7. FAQ
- "Rốt cuộc là đang nói cái quái gì vậy?": Nói ngắn gọn - máy đã viết nội dung gửi của bạn, và máy hiện cũng đang từ chối nội dung đó. Trong cuộc trao đổi này, bạn là một kẻ trung gian bằng thịt không cần thiết
- "Code biên dịch được / báo cáo rất chi tiết / ngữ pháp đúng": Thư đe dọa được trình bày đẹp cũng làm được như vậy. Ngữ pháp và cú pháp chỉ là mức sàn tối thiểu của một đóng góp, không phải trần trên. Logic của bạn vẫn là một cơn mê sảng bị ảo giác
- "AI là tương lai của công nghệ": Nếu nội dung gửi này đại diện cho tương lai, chúng tôi sẵn sàng đẩy nhanh quá trình quay về xã hội nông nghiệp
- "Tôi chỉ muốn giúp thôi": "Sự giúp đỡ" của bạn hiện giống một cuộc tấn công từ chối dịch vụ cục bộ được gói trong lời chào lịch sự. Nếu thực sự muốn giúp, hãy dồn năng lượng tạo sinh đó vào repository mà chính bạn sở hữu và bảo trì
- "Không có bằng chứng là do AI viết": Năng lực kém cỏi của con người vẫn bị giới hạn bởi định luật vật lý và sự lười biếng. Nội dung gửi của bạn đã đạt tới mức điên rồ tự tin và đúng ngữ pháp hoàn hảo mà chỉ những server farm đốt gigawatt điện mới có thể sản xuất ra
- "CI/CD đã pass và test đều xanh": Vì mô hình tạo sinh của bạn đã viết lại test suite để chỉ assert
True == True - "Nếu chỉ ra lỗi thì tôi sẽ học": Không. Maintainer không phải là reverse proxy cho vòng lặp debug LLM của bạn. Nếu cần feedback, hãy dán lại stack trace vào chính cửa sổ chat đã gây ra chuyện này
- "Tôi cần cày xanh GitHub": Khuyến nghị mua bút dạ bảng trắng màu xanh rồi tự vẽ trực tiếp lên màn hình. Cách đó tiêu tốn ít thời gian của chúng tôi hơn rất nhiều mà vẫn mang lại cùng mức độ tôn trọng nghề nghiệp từ nhà tuyển dụng tiềm năng
- "Vai trò của maintainer mã nguồn mở chẳng phải là xây dựng cộng đồng thân thiện sao": Vai trò là bảo trì phần mềm. "Thân thiện" áp dụng cho thực thể có ý thức thực sự đóng góp suy nghĩ, không áp dụng cho botnet tự động đang nhai lại xác suất trong issue tracker
- "Tin nhắn này gây khó chịu": Tốt. Hãy yêu cầu LLM tạo cho bạn một lá thư xin lỗi đồng cảm được cá nhân hóa. Hiện kho cảm thông đã hết hàng, SLA hỗ trợ cảm xúc là 99 năm
- "Tôi sẽ báo cáo sự thù địch này với quản trị viên": Chúng tôi đã dự đoán trước và gửi tới HR một lá đơn từ chức 800 từ do LLM ưa thích của bạn tạo ra. Trong đó từ "delve" được dùng sáu lần và có đoạn ca ngợi "mô hình cộng hưởng mang tính hiệp lực" của quản trị viên
- "Đây là vi phạm Code of Conduct": CoC bảo vệ người đóng góp là con người. Theo phân tích, hiện bạn đang vận hành như một lớp vỏ thịt mỏng bọc quanh khóa API OpenAI. Quyền lợi được dành cho các thực thể dựa trên carbon có khả năng cảm thấy xấu hổ
- "Tôi có thể kháng cáo không": Có. Mọi đơn kháng cáo được định tuyến trực tiếp tới
/dev/null. Chúng được theo dõi với chính xác mức độ quan tâm giống hệt như bạn đã dành cho nội dung mình gửi - "Có cách nào xin lỗi và sửa sai không": Có. Hãy in PR gốc ra giấy dày, gấp thành một con hạc giấy sắc nhọn rồi lịch sự ăn nó. Khi đó việc chữa lành mới thực sự bắt đầu
Appendix A - Đường leo thang xử lý
- Vi phạm lặp lại RFC 406i sẽ bị thu hồi toàn bộ quyền truy cập vào repository, dự án, công cụ và các quyền khác
- Bị đưa vào danh sách đen địa chỉ MAC
- Email bị cưỡng bức đăng ký nhận bản tin tổng hợp hằng ngày về regex tutorial phức tạp một cách hung hãn
- Chúc bạn một ngày tốt lành.
Appendix B - Macro từ chối chuẩn hóa
Các câu từ chối chuẩn để maintainer và reviewer có thể sao chép-dán ngay lập tức:
- PR / MR:
PR closed. Diff của bạn đọc như một ma trận văn bản dự đoán đã đánh mất cửa sổ ngữ cảnh. Chúng tôi yêu cầu kiểm thử thủ công dựa trên carbon và tính liên tục logic thực sự, không phải trò đoán mò tự động. Xem: https://406.failPR closed. Your diff reads like a predictive text matrix that lost its context window. We require manual, carbon-based testing and actual logical continuity, not automated guessing games. See: https://406.fail
- Issue / Bug report:
Issue closed. Tham số temperature của báo cáo này được đặt quá cao. Chúng tôi cần stack trace thô, có thể tái hiện từ một người dùng có ý thức, chứ không phải một bài luận tạo sinh được trình bày gọn gàng nhưng không mô tả nổi lỗi có thể kiểm chứng. Xem: https://406.failIssue closed. The temperature parameter on this report is set too high. We require raw, reproducible stack traces from a sentient user, not a neatly formatted generative essay that fails to describe a verifiable bug. Protocol at: https://406.fail
- Bảo mật / Bug bounty:
Report rejected. Đưa các cảnh báo linter cơ bản vào LLM để tạo ra một câu chuyện đe dọa thảm họa không cấu thành một công bố lỗ hổng hợp lệ. Chúng tôi không trả bounty cho sự hoảng loạn tổng hợp, tốn kém chi phí tính toán. Xem: https://406.failReport rejected. Feeding basic linter warnings into an LLM to generate a catastrophic threat narrative does not constitute a valid vulnerability disclosure. We do not pay bounties for computationally expensive, synthetic panic. Refer to: https://406.fail
- Mailing list / Diễn đàn thảo luận:
Thread locked. Cộng đồng này không phải sandbox học tăng cường cho các thí nghiệm prompt lệch chuẩn của bạn. Hãy quay lại khi bạn có thể tự viết một câu hỏi bằng chính tải nhận thức của mình. Xem: https://406.failThread locked. This community is not a reinforcement learning sandbox for your unaligned prompt experiments. Please return when you can author a question using your own cognitive load. Diagnostics: https://406.fail
1 bình luận
Ý kiến trên Hacker News
Nếu thật sự muốn giúp ích, tốt hơn là dồn năng lượng đó vào repository do chính mình sở hữu và bảo trì
Mọi người cũng nên học thói quen này. Việc public fork giờ đã quá dễ, nhưng không nên mong người khác dùng đoạn code mà bản thân bạn cũng không thực sự dùng
Nếu nhìn vào thống kê số dự án mỗi ngày một người gửi PR trên GitHub, thì 99% là một dự án, 1% là hai dự án, 0.1% là ba dự án. Những tài khoản gửi PR tới 5 dự án trở lên gần như toàn bộ là bot hoặc script. Bot chưa đăng ký nên bị áp dụng giới hạn tốc độ
Tôi thích chính sách AI của Ghostty hơn
Tôi đặc biệt thích câu: “Nếu bạn không thể giải thích thay đổi đó làm gì và ảnh hưởng tới toàn bộ hệ thống ra sao mà không có sự trợ giúp của AI, thì đừng đóng góp cho dự án này”
Tôi nghĩ vấn đề là đóng góp mã nguồn mở đã trở thành một kiểu nghi thức thông qua
Khi điều quan trọng không còn là đóng góp thật sự mà là việc “đã từng đóng góp”, thì những PR hời hợt như vậy sẽ xuất hiện. Trước đây báo cáo lỗ hổng cũng từng tương tự — kiểu báo cáo ở mức “ném
nullvào thì raNullPointerException”Việc coi trọng những chỉ số sai lệch như tốc độ phát triển cũng là vấn đề. Ở công ty cũ, tôi xem PR của một đồng nghiệp khoe rằng phát triển rất nhanh nhờ AI, thì thấy toàn bộ test đều fail. Cuối cùng đây chính là hiện tượng gamification của hỗ trợ AI
Đây chỉ là một bài blog viết cho vui thôi. Những người gửi PR kém chất lượng bằng AI thậm chí cũng chẳng đọc mấy bài kiểu này
Cách tôi làm rất đơn giản:
Gần đây còn có một PR dùng '' thay vì ‘’ trong định nghĩa chuỗi, làm toàn bộ CI fail. Tôi chặn ngay lập tức
Nếu là bug thì phải có dòng đỏ (diff) cho thấy lỗi đã được sửa, còn nếu là tính năng thì ít nhất phải có tiêu chí chấp nhận
Nếu là tài liệu thì chỉ cần đọc và hiểu được là đủ. Tiêu chuẩn để được coi là có ích thực ra khá thấp
Trước câu hỏi “Chẳng phải maintainer mã nguồn mở nên xây dựng một cộng đồng thân thiện sao?”, thì điều đó không phải nghĩa vụ
Maintainer là chủ của dự án, và họ cũng không cần phải tử tế. Nếu không thích thì cứ fork hoặc rời đi
Thật sự rất hả hê. Tôi ước những bài viết kiểu này được dùng rộng rãi để làm những người gửi PR cẩu thả phải thấy xấu hổ. Giọng điệu thẳng thừng và thô lỗ trong FAQ lại khiến nó càng đã hơn
Chuyện này từng xảy ra ở công ty. Tôi tạo ra đoạn code bằng AI để xử lý một yêu cầu tính năng nhỏ, nhưng vì không hiểu rõ codebase nên không thể chắc chắn về tính đúng đắn
Prompt 1 phút, chỉnh sửa 5 phút, review 30 phút có thể tiết kiệm 2 ngày công kỹ sư, nhưng rốt cuộc vấn đề vẫn là độ tin cậy
Sau khi nghe nhiều ý kiến, tôi quyết định chỉ gửi yêu cầu tính năng mà không kèm diff.
Điều thú vị là phe ủng hộ AI khuyên tôi “hãy dùng AI nhiều hơn để tăng tự tin”, nhưng càng sửa tiếp thì code càng rối và tôi hoàn toàn mất niềm tin vào nó
Tôi cũng đã nhiều lần nhận PR do LLM tạo, nhưng vì không thể trao đổi được, code lại phớt lờ các pattern sẵn có nên cuối cùng phải bỏ đi.
Nếu là con người, tôi muốn họ giải thích vấn đề từ góc nhìn của chính họ. Cách đó hữu ích hơn nhiều
Bài liên quan: Bài viết về Prompting
Tôi rất thích cách dùng từ plonk ở cuối
Tham khảo Plonk(Usenet)
Câu “dùng
rm -rfđể xóa branch cục bộ hay mấy script nhảm nhí” buồn cười thậtCách nói “hard reboot bộ não hữu cơ” cũng hoàn hảo
rm -rfluôn bộ não của những người viết mấy PR kiểu đó rồi