Polisi Kod Bantuan AI dalam Projek Sumber Terbuka
Setiap projek sumber terbuka mempunyai polisi berbeza mengenai kod bantuan AI. Semak garis panduan sebelum menghantar pull request dan buat pendedahan dalam commit trailer.
Perkara yang perlu dilakukan sebelum menghantar kod bantuan AI ke hulu (upstream)
Projek sumber terbuka kini menerbitkan polisi mengenai kod bantuan AI, dan polisi tersebut tidak seragam antara satu sama lain. Oleh itu, tabiatnya mudah: cari polisi tersebut sebelum anda menulis patch, dan buat pendedahan yang tepat apabila anda menghantarnya. Satu peraturan terpakai untuk kedua-duanya. Jangan sekali-kali menyerahkan baris kod yang anda tidak dapat jelaskan semasa semakan.
Patch yang betul masih akan ditutup jika projek tersebut melarang kod yang dijana, atau jika anda menyembunyikan asal-usul kod tersebut. Kosnya akan ditanggung oleh nama anda dan kekal di situ, kerana penyelenggara yang mendapati peninggalan tersebut kemudiannya tidak mempunyai sebab untuk mempercayai sejarah sumbangan anda yang lain. Beberapa istilah perlu dijelaskan terlebih dahulu, kerana polisi menggunakan istilah tersebut. LLM (large language model) ialah model di sebalik ejen pengekodan anda. PR (pull request) di GitHub adalah sama dengan MR (merge request) di GitLab, dan segala yang dinyatakan di bawah terpakai untuk kedua-duanya. DCO (developer certificate of origin) ialah baris pengesahan di bahagian bawah mesej commit, dan ia ternyata menjadi pusat kepada keseluruhan perdebatan ini.
Kedudukan dasar sumber terbuka mengenai kod AI
Projek-projek telah menetap dalam empat kategori. Setiap contoh di bawah mempunyai tarikh, kerana teks ini sentiasa berubah.
Dilarang. Majlis Gentoo mengundi pada 14 April 2024 bahawa "adalah dilarang secara nyata untuk menyumbang kepada Gentoo sebarang kandungan yang dicipta dengan bantuan alat kecerdasan buatan Pemprosesan Bahasa Semulajadi". Garis panduan komit NetBSD menggelar output daripada LLM sebagai "kod tercemar" yang "tidak boleh dikomit tanpa kelulusan bertulis terlebih dahulu daripada pihak teras". Dokumen asal-usul kod QEMU, setakat Ogos 2026, masih menyatakan bahawa projek tersebut akan "MENOLAK sebarang sumbangan yang dipercayai mengandungi atau berasal daripada kandungan yang dijana AI".
Analisis sahaja. Kebanyakan larangan adalah lebih sempit daripada tajuk utamanya. Dokumen QEMU menyatakan bahawa dasar tersebut "tidak terpakai kepada kegunaan AI yang lain, seperti menyelidik API atau algoritma, analisis statik, atau penyahpepijatan, dengan syarat outputnya tidak disertakan dalam sumbangan". Anda boleh menggunakan ejen untuk membaca kod. Anda tidak boleh menghantar apa yang ditulisnya. Perbezaan itu adalah garis panduan kerja di dalam kebanyakan projek yang ketat, dan ia adalah perkara yang sering terlepas pandang oleh orang ramai.
Pendedahan diperlukan. Majlis Fedora meluluskan dasar mengenai sumbangan bantuan AI pada Oktober 2025. Ia membenarkan penggunaan alat tersebut dan meletakkan tanggungjawab kepada individu: penyumbang adalah pengarang, bertanggungjawab sepenuhnya ke atas keseluruhan sumbangan, dan mesti mendedahkan apabila sebahagian besar daripadanya datang daripada alat tanpa perubahan. Kernel Linux menambah halaman pembantu pengekodan dalam dokumentasi prosesnya pada Disember 2025, dengan lampiran untuk merekodkan alat yang digunakan dan peraturan tegas tentang siapa yang boleh memberikan sign-off.
Tiada peraturan bertulis. Ini masih merupakan kes yang biasa. Satu pracetak dari Mei 2026 meninjau 1,000 repositori GitHub yang popular dan mendapati 118 daripadanya mempunyai sebarang dasar AI bertulis. Ketiadaan peraturan bukan bermakna kebenaran. Bertanyalah dalam penjejak isu (issue tracker) dalam satu ayat sebelum anda menulis patch, dan jawapannya akan menjadi rekod awam yang boleh anda rujuk kemudian.
Mengapa penyenggara menulis peraturan ini
Sebab pertama ialah beban semakan, dan pengiraannya hanya menjurus ke satu arah. Ejen boleh menghasilkan merge request sepanjang 400 baris yang kelihatan munasabah dalam masa seminit. Menyemak permintaan tersebut dengan betul memakan masa setengah hari bagi seorang penyenggara, dan kebanyakan penyenggara adalah sukarelawan. Kos untuk menghantar sumbangan telah jatuh hampir kepada sifar. Kos untuk menyemak pula tidak berubah langsung.
curl menunjukkan hujung ekstrem bagi keluk tersebut. Daniel Stenberg melaporkan pada pertengahan 2025 bahawa kira-kira satu perlima daripada laporan keselamatan yang diterima melalui program bug bounty projek tersebut adalah apa yang beliau panggil sebagai AI slop: laporan yang menamakan fungsi sebenar dan laluan kod sebenar, menerangkan serangan yang munasabah, tetapi tidak mengandungi apa-apa isi yang berguna. Projek itu menamatkan program bounty tersebut pada awal 2026 daripada terus membiayai lambakan laporan tersebut. Itu adalah laporan dan bukannya patch, tetapi ia adalah mekanisme yang sama yang menyebabkan penyenggara sudah berasa letih sebaik sahaja membuka PR anda.
GNOME Calendar mencatatkan masalah ini sebagai satu label. Pada Jun 2026, projek tersebut memperkenalkan label "Probabilistically Automated" untuk merge request yang menunjukkan "pergantungan besar atau sepenuhnya kepada 'kecerdasan' buatan untuk menjana kod", dan menamakan simptom tersebut dengan tepat: "biasanya disertai dengan kekurangan ujian yang sewajarnya, dan memuktamadkan patch berdasarkan jangkaan tingkah laku teori dan bukannya ketepatan kod". Baca frasa terakhir itu dua kali. Kod itu kelihatan seperti ia sepatutnya berfungsi. Tiada sesiapa yang memeriksa sama ada ia benar-benar berfungsi.
Sebab kedua ialah asal usul (provenance), iaitu dari mana kod itu datang dan di bawah lesen apa. QEMU menyatakan konflik tersebut dengan jelas: menandatangani (signing off) bermaksud anda "memahami sepenuhnya status hak cipta dan lesen kandungan" yang anda sumbangkan, dan status hak cipta bagi output model masih belum diputuskan. Majlis Gentoo memberikan alasan yang sama, di samping isu kualiti dan etika. Anda tidak perlu bersetuju dengan tafsiran undang-undang tersebut. Anda perlu sedar bahawa keputusan itu terletak di tangan penyenggara, bukan anda.
Bagaimanakah cara mencari polisi AI sesuatu projek?
Cari di lokasi berikut, mengikut urutan ini.
CONTRIBUTING.mddi dalam root repositori, kemudian.github/CONTRIBUTING.md, seterusnya mana-mana failDCOyang bersebelahan dengannya.- Dokumentasi pembangun. QEMU menyimpan peraturannya di dalam
docs/devel/code-provenance.rst. Kernel pula menyimpannya di dalamDocumentation/process/coding-assistants.rst. - Laman web atau wiki projek. Polisi Gentoo terletak pada halaman wiki majlis mereka, manakala polisi NetBSD terletak di dalam garis panduan commit.
- Penjejak isu (issue tracker) dan arkib senarai mel (mailing list). Polisi biasanya wujud di sana selama berbulan-bulan sebelum sesiapa menuliskannya ke dalam repositori.
Dari dalam checkout, satu arahan grep merangkumi kebanyakan perkara tersebut:
grep -rniE '(llm|copilot|chatgpt|generative|ai-generated|ai-assisted)' CONTRIBUTING.md docs/ .github/ 2>/dev/null | head -20Kemudian, baca sejarah projek itu sendiri, kerana konvensyen yang telah di-commit mengatasi sebarang ringkasan mengenainya:
git log --format='%(trailers:key=Assisted-by,valueonly)' | grep . | sort | uniq -c
git log --format='%(trailers:key=AI-used-for,valueonly)' | grep . | sort | uniq -cKiraan di sebelah nilai trailer memberitahu anda bentuk yang sebenarnya digunakan oleh projek ini. Hasil yang kosong bermakna tiada sesiapa yang mendedahkan maklumat dalam bentuk tersebut di sini, yang mana ia juga merupakan satu maklumat. Jika projek tersebut berada di GitHub dan aliran kerja itu sendiri baharu bagi anda, cara pull request dan fork berfungsi di GitHub merangkumi mekanik yang diandaikan oleh bahagian ini.
Dedahkan dalam trailer komit, bukan dalam ulasan
Trailer ialah baris Key: value dalam perenggan terakhir mesej komit. Git sudah menggunakan bentuk ini untuk Signed-off-by: dan Co-authored-by:, dan alatan menghuraikannya, jadi ia merupakan satu-satunya pendedahan yang dibawa bersama kod ke dalam pepohon (tree).
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 mendokumenkan format tersebut sebagai Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2], dan ia menyatakan dengan jelas tentang had baris tersebut: "Ejen AI TIDAK BOLEH menambah tag Signed-off-by. Hanya manusia yang boleh memperakui Developer Certificate of Origin (DCO) secara sah." Nama ejen diletakkan pada Assisted-by. Nama anda diletakkan pada Signed-off-by. Jangan sekali-kali membiarkan alat menulis yang kedua, dan jangan sekali-kali membiarkannya mencipta alamat Co-authored-by yang tidak dimiliki oleh sesiapa.
Nama berbeza-beza, jadi salin nama tempatan dan bukannya mencipta nama anda sendiri. Satu patch yang disiarkan ke senarai QEMU pada Mei 2026 mencadangkan kelonggaran larangan projek tersebut bagi perubahan mekanikal, ujian, dokumentasi dan pembetulan pepijat sebanyak dua puluh baris atau kurang, yang direkodkan dengan trailer seperti AI-used-for: tests, docs. Sehingga Ogos 2026, itu hanyalah cadangan dalam senarai mel dan dokumen yang dikomitkan masih menolak kandungan yang dijana. Satu projek menukar pendiriannya sebanyak dua kali antara 2023 dan 2026. Perubahan seterusnya tidak akan menunggu anda, itulah sebabnya kaedah lebih penting daripada senarai.
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 memerlukan Git 2.32 atau lebih baharu. Perintah kedua sepatutnya mencetak nilai tersebut kembali kepada anda. Baris kosong bermakna git tidak menghuraikan trailer tersebut, biasanya kerana baris kosong atau ayat biasa terletak di dalam blok trailer di bahagian bawah mesej. Bagi siri yang telah anda tulis, git rebase --signoff origin/main menambah sign-off pada setiap komit, dan git interpret-trailers --in-place --trailer "Assisted-by: Claude:claude-3-opus" msg.txt menyunting fail mesej.
Dua mod kegagalan perlu dirancang. Squash merge menulis semula mesej komit, jadi pada projek yang melakukan squash, ulangi pendedahan tersebut dalam perihalan PR di mana penyelenggara membacanya. Ulasan semakan bukanlah rekod, kerana ulasan boleh disunting dan tidak akan masuk ke dalam sejarah git.
Ketepatan berfungsi dua hala. Assisted-by pada komit yang anda taip dengan tangan adalah gangguan, dan ia menjadikan pendedahan sebenar anda kurang bernilai. Meninggalkannya daripada komit yang ditulis oleh ejen adalah perkara yang menamatkan hubungan tersebut.
Apakah yang sebenarnya disahkan oleh Signed-off-by?
DCO ialah satu teks ringkas, versi 1.1, yang diterbitkan di developercertificate.org dan digunakan oleh kernel, QEMU, serta banyak lagi. Menambah Signed-off-by: Your Name <you@example.com> bermakna anda memperakui perkara tersebut. Baca apa yang anda perakui, kerana kebanyakan orang menandatanganinya tanpa membacanya langsung.
Klausa (a) menyatakan bahawa sumbangan tersebut "dicipta sepenuhnya atau sebahagiannya oleh saya dan saya mempunyai hak untuk menyerahkannya di bawah lesen sumber terbuka yang dinyatakan dalam fail tersebut". Klausa (b) meliputi kerja yang berasaskan kod sumber terbuka terdahulu yang anda mempunyai hak untuk menyebarkannya dengan pengubahsuaian. Klausa (c) meliputi kod yang diserahkan kepada anda oleh seseorang yang telah memperakui perkara yang sama. Klausa (d) menyatakan bahawa anda memahami bahawa sumbangan dan maklumat peribadi dalam sign-off anda adalah awam dan disimpan selama-lamanya.
Perhatikan apa yang tiada. DCO tidak pernah menyatakan bahawa anda menaip setiap aksara. Ia menyatakan bahawa anda mempunyai hak untuk menyerahkan kod tersebut di bawah lesen ini. Itulah sebabnya kod yang dijana menimbulkan masalah di sini: persoalannya bukanlah tentang kepengarangan, tetapi sama ada anda boleh menjelaskan asal-usulnya. Kebanyakan projek yang memerlukan sign-off juga memerlukan nama sebenar, jadi penggunaan nama samaran akan gagal dalam pemeriksaan tersebut. Tambahkan baris tersebut dengan git commit -s, yang membaca user.name dan user.email daripada konfigurasi git anda. Apabila bot DCO menolak PR anda dan menamakan commit yang tidak mempunyai baris tersebut, git rebase --signoff origin/main dan force push ke cawangan anda akan membetulkannya.
Menandatangani komit tidak sama dengan menandatangani (sign-off)
git commit -s menambah satu baris teks. git commit -S membuat tandatangan kriptografi ke atas objek komit menggunakan kunci GPG atau SSH anda. Kedua-duanya menjawab soalan yang berbeza. Tandatangan tersebut mengesahkan bahawa komit ini datang daripada pemegang kunci tersebut dan tidak diubah sejak itu. Ia tidak menyatakan apa-apa tentang asal-usul kod di dalamnya, jadi komit yang ditandatangani yang penuh dengan kod janaan yang tidak didedahkan tetap merupakan satu tandatangan yang sah tetapi masih melanggar polisi. Sign-off adalah tuntutan tentang asal-usul. Tandatangan adalah tuntutan tentang identiti. Projek yang mahukan kedua-duanya akan meminta kedua-duanya.
Jangan serahkan kod yang anda tidak boleh jelaskan dalam semakan
Ini adalah ujiannya, dan ia bukan sekadar tentang kejujuran. Bagi setiap baris: apakah tujuannya, dan apakah yang akan rosak tanpanya? Jika salah satu jawapan tiada, patch tersebut belum sedia, kerana komen semakan pasti akan tiba dan jawapan anda akan menyebabkan satu lagi pusingan penjanaan kod. Penyemak boleh mengetahuinya. Itulah saat seorang penyumbang menjadi beban. Tanya soalan yang sama tentang bahagian pinggir, input kosong, laluan kegagalan, dan pemanggil kedua.
Jalankan kod tersebut. Bina kod itu, jalankan suite ujian projek, dan tulis pengeluar semula (reproducer) untuk pepijat yang anda dakwa telah dibaiki. Dokumentasi kernel memberikan sandaran jujur dalam kata-kata mudah: "Jika pembaikan tidak dapat dibina atau diuji, atau jika tiada pengeluar semula dapat dihasilkan, nyatakan secara jelas: penyelenggara kini membuang terlalu banyak masa menganalisis laporan yang tidak disahkan dan pembaikan yang tidak diuji." Menulis "Saya tidak dapat menguji ini pada perkakasan sebenar" tidak merugikan anda. Memberi gambaran bahawa anda telah melakukannya akan menyebabkan anda disingkirkan daripada projek.
Jawab komen semakan sendiri, dengan kata-kata anda sendiri dan mengikut masa anda sendiri. Balasan yang sampai tiga puluh saat selepas komen dan mengulanginya dalam lima perenggan memberitahu penyelenggara dengan tepat apa yang berlaku. Pastikan diff juga kecil. Empat puluh baris yang anda fahami sepenuhnya lebih bernilai kepada projek berbanding refaktor empat ratus baris yang anda selia. Jika ejen anda terus memberikan lebih daripada yang anda minta, kemahiran yang mengekalkannya kepada perubahan terkecil yang berfungsi adalah satu cara untuk memastikan patch tersebut kekal pada tahap yang anda masih boleh pertahankan baris demi baris.
Simpan arahan ejen di dalam repositori
Arahan yang anda berikan kepada ejen anda adalah sebahagian daripada rantaian alat (toolchain) anda, jadi layanlah ia seperti kod. Satu fail di dalam direktori akar repositori, biasanya AGENTS.md, menyimpan arahan binaan, arahan ujian, format mesej komit, keperluan sign-off dan peraturan gaya yang telah didokumenkan oleh projek tersebut. Fail itu mempunyai versi dan boleh disemak, serta kekal sama pada hari esok seperti hari ini. Arahan yang ditaip semula daripada ingatan bagi setiap sesi akan menghasilkan patch yang berbeza setiap sesi, dan anda tidak akan tahu sesi mana yang menghasilkan patch yang ditolak. Menulis AGENTS.md yang boleh dibaca oleh ejen dan manusia membincangkan tentang fail tersebut.
Satu peringatan mengenai repositori orang lain. Jangan jadikan sumbangan pertama anda sebagai PR yang menambah fail arahan ejen kepada projek yang tidak anda selenggara. Ia dilihat sebagai percubaan untuk menetapkan polisi peralatan projek dari luar, dan ia merupakan cara pantas untuk akaun anda dikaitkan dengan perkara yang sudah membebankan penyelenggara. Simpan fail tersebut di dalam fork anda sehingga seseorang memintanya.
Lokasi anda menjalankan ejen juga penting atas sebab yang sama. Ejen yang boleh membina projek dan menjalankan ujiannya di dalam sandbox yang anda kawal memberikan anda patch yang telah anda sahkan sendiri, yang merupakan perbezaan antara mendedahkan bantuan dan mendedahkan tekaan. Menjalankan ejen pengekodan pada VPS anda sendiri membincangkan persediaan tersebut, dan perbezaan praktikal antara Claude Code, Cursor, Codex dan Copilot membincangkan bagaimana alatan tersebut berbeza dari hari ke hari.
Kaedah ini, sebaik sahaja polisi berubah
- Cari polisi yang dinyatakan sebelum anda menulis apa-apa: repositori, dokumentasi pembangun, laman web, atau penjejak.
- Jika tiada polisi, tanya dalam isu tersebut dengan satu ayat, dan simpan jawapannya.
- Dedahkan dalam bentuk yang digunakan oleh projek, dalam commit trailer, dan ulangi dalam badan PR jika projek tersebut melakukan squash.
- Sign off dengan nama sebenar anda, dengan memahami bahawa baris tersebut adalah tuntutan mengenai hak anda untuk menyerahkan kod tersebut.
- Semak patch anda sendiri seolah-olah orang asing yang menulisnya, kerana memang ada orang asing yang menulisnya.
Setiap projek yang dinamakan pada halaman ini akan berpindah menjelang masa anda membacanya. Lima langkah ini tidak akan berubah.
FAQ
Adakah saya perlu mendedahkan bahawa saya menggunakan ejen pengekodan AI?
Semak projek tersebut, kerana jawapannya ditetapkan secara setempat. Fedora mewajibkan pendedahan apabila sebahagian besar sumbangan datang daripada alat tanpa sebarang perubahan. Kernel Linux meminta Assisted-by trailer. Gentoo dan QEMU, setakat Ogos 2026, tidak mahu sumbangan tersebut sama sekali. Jika tiada apa-apa yang tertulis, dedahkan juga dalam commit trailer. Penyelenggara yang mengetahui perkara itu kemudiannya akan bertindak balas terhadap peninggalan tersebut dan bukannya terhadap alat itu, dan reaksi itu akan melekat pada semua perkara lain yang telah anda hantar.
Projek sumber terbuka manakah yang mengharamkan kod janaan AI?
Sebagai gambaran setakat Ogos 2026: Gentoo sejak April 2024, NetBSD yang menganggap output LLM sebagai kod tercemar yang memerlukan kelulusan teras, QEMU yang menolak sumbangan yang diperoleh daripada kandungan janaan, dan beberapa aplikasi GNOME termasuk Loupe dan Calendar. Baca teks setiap projek itu sendiri dan bukannya senarai ini, kerana ia akan menjadi lapuk. Perhatikan pengecualian yang dikongsi oleh kebanyakan mereka: menggunakan model untuk menyelidik API, menjalankan analisis statik atau membantu anda menyahpepijat biasanya dibenarkan, selagi outputnya tidak berada dalam patch tersebut.
Apakah perbezaan antara Signed-off-by dan commit yang ditandatangani?
Signed-off-by ialah baris teks biasa yang ditambah oleh git commit -s. Ia memperakui sijil asal pembangun, bermakna anda mempunyai hak untuk menyerahkan kod ini di bawah lesen projek tersebut. Commit yang ditandatangani, yang dibuat dengan git commit -S, ialah tandatangan kriptografi ke atas objek commit dengan kunci GPG atau SSH anda. Ia membuktikan bahawa commit itu datang daripada kunci anda dan tidak diubah. Asal usul dan identiti adalah tuntutan yang berasingan, jadi commit yang ditandatangani masih boleh melanggar polisi AI.
Bolehkah saya meletakkan pendedahan dalam perihalan pull request dan bukannya mesej commit?
Letakkannya dalam mesej commit, kerana itulah rekod yang akan masuk ke dalam sejarah git dan dibawa bersama kod tersebut kepada sesiapa sahaja yang mengklon repositori itu kemudian. Perihalan pull request boleh disunting selepas itu dan hanya wujud pada platform pengehosan. Tambahkannya pada badan PR juga apabila projek melakukan squash merge, kerana squash akan menulis semula mesej commit anda dan boleh menggugurkan trailer tersebut.
Pull request saya ditutup kerana ia dijana oleh AI. Apa sekarang?
Jangan berhujah tentang polisi tersebut dalam thread, kerana orang yang menutupnya tidak menulis peraturan itu secara bersendirian dan thread tersebut bukanlah tempat untuk mengubahnya. Baca teks polisi, kemudian tentukan sama ada anda boleh mematuhinya. Di mana projek mengharamkan patch janaan, laporan pepijat yang jelas dengan reproducer dan tanpa patch masih dialu-alukan, dan ia sering menjadi sumbangan yang lebih berguna. Jika anda kembali dengan kod, kembalilah dengan perubahan kecil yang boleh anda pertahankan baris demi baris.