แนวทางการส่งโค้ดที่เขียนโดย AI เข้าโปรเจกต์ Open Source

สิ่งที่ควรทำก่อนส่งโค้ดที่ช่วยเขียนโดย AI ไปยัง upstream

โครงการโอเพนซอร์สในปัจจุบันมีการประกาศนโยบายเกี่ยวกับการใช้ AI ช่วยเขียนโค้ด ซึ่งนโยบายแต่ละแห่งมีความแตกต่างกัน ดังนั้นแนวทางปฏิบัติจึงเรียบง่าย คือให้ค้นหานโยบายดังกล่าวก่อนเริ่มเขียน patch และเปิดเผยข้อมูลอย่างถูกต้องเมื่อส่งงาน โดยมีกฎข้อหนึ่งที่ครอบคลุมทั้งสองกรณี คือห้ามส่งโค้ดบรรทัดใดก็ตามที่คุณไม่สามารถอธิบายได้ในระหว่างการรีวิว

แม้จะเป็น patch ที่ถูกต้อง แต่ก็อาจถูกปิดได้หากโครงการนั้นห้ามใช้โค้ดที่สร้างโดย AI หรือหากคุณปกปิดที่มาของโค้ดนั้น ผลกระทบจะตกอยู่กับชื่อเสียงของคุณและจะคงอยู่ตลอดไป เนื่องจากผู้ดูแลโครงการที่มาพบการปกปิดในภายหลังย่อมไม่มีเหตุผลที่จะเชื่อถือประวัติการทำงานส่วนที่เหลือของคุณ ต่อไปนี้คือคำนิยามเบื้องต้นเนื่องจากนโยบายต่างๆ มักใช้คำเหล่านี้ LLM (large language model) คือโมเดลที่อยู่เบื้องหลังเครื่องมือช่วยเขียนโค้ดของคุณ PR (pull request) บน GitHub มีความหมายเดียวกับ MR (merge request) บน GitLab และทุกสิ่งที่กล่าวถึงด้านล่างนี้มีผลบังคับใช้กับทั้งสองแพลตฟอร์ม DCO (developer certificate of origin) คือบรรทัดการลงชื่อรับรองที่ส่วนท้ายของข้อความ commit ซึ่งกลายเป็นประเด็นสำคัญของข้อถกเถียงทั้งหมดในเรื่องนี้

สถานะปัจจุบันของนโยบาย Open Source เกี่ยวกับโค้ดที่สร้างโดย AI

โครงการต่างๆ ได้แบ่งกลุ่มนโยบายออกเป็น 4 ระดับ โดยตัวอย่างทั้งหมดด้านล่างนี้มีระบุวันที่ไว้ เนื่องจากข้อกำหนดเหล่านี้มีการเปลี่ยนแปลงอยู่ตลอดเวลา

ห้ามใช้ (Banned) สภาของ Gentoo ได้ลงมติเมื่อวันที่ 14 เมษายน 2024 ว่า "ห้ามมิให้มีการส่งเนื้อหาใดๆ ที่สร้างขึ้นโดยได้รับความช่วยเหลือจากเครื่องมือปัญญาประดิษฐ์ประเภท Natural Language Processing เข้าสู่ Gentoo โดยเด็ดขาด" แนวทางการ commit ของ NetBSD เรียกผลลัพธ์จาก LLM ว่าเป็น "โค้ดที่ปนเปื้อน" (tainted code) ซึ่ง "ห้ามนำมา commit โดยไม่ได้รับอนุญาตเป็นลายลักษณ์อักษรจากทีม core เสียก่อน" เอกสารที่มาของโค้ดของ QEMU ณ เดือนสิงหาคม 2026 ยังคงระบุว่าโครงการจะ "ปฏิเสธการมีส่วนร่วมใดๆ ที่เชื่อว่ามีเนื้อหาที่สร้างโดย AI หรือดัดแปลงมาจากเนื้อหาดังกล่าว"

ใช้เพื่อการวิเคราะห์เท่านั้น (Analysis only) นโยบายห้ามส่วนใหญ่มีขอบเขตแคบกว่าที่พาดหัวไว้ เอกสารของ QEMU ระบุว่านโยบายนี้ "ไม่ครอบคลุมถึงการใช้ AI ในด้านอื่น เช่น การค้นคว้า API หรืออัลกอริทึม, การทำ static analysis หรือการดีบั๊ก โดยมีเงื่อนไขว่าผลลัพธ์จากเครื่องมือเหล่านั้นจะต้องไม่ถูกรวมอยู่ในส่วนที่ส่งมอบ" คุณสามารถใช้ AI เพื่ออ่านโค้ดได้ แต่คุณไม่สามารถส่งมอบสิ่งที่ AI เขียนขึ้นมาได้ ความแตกต่างนี้คือเส้นแบ่งการทำงานภายในโครงการที่มีข้อจำกัดส่วนใหญ่ และเป็นจุดที่ผู้คนมักมองข้าม

ต้องเปิดเผยข้อมูล (Disclosure required) สภาของ Fedora ได้อนุมัตินโยบายเกี่ยวกับการมีส่วนร่วมที่ได้รับความช่วยเหลือจาก AI ในเดือนตุลาคม 2025 โดยอนุญาตให้ใช้เครื่องมือดังกล่าวและเน้นความรับผิดชอบไปที่ตัวบุคคล: ผู้มีส่วนร่วมถือเป็นผู้เขียนและต้องรับผิดชอบต่อสิ่งที่ส่งมอบทั้งหมดอย่างเต็มที่ อีกทั้งต้องเปิดเผยเมื่อส่วนสำคัญของงานนั้นมาจากเครื่องมือโดยไม่มีการแก้ไข Linux kernel ได้เพิ่มหน้าเกี่ยวกับผู้ช่วยเขียนโค้ดลงในเอกสารกระบวนการในเดือนธันวาคม 2025 โดยมีส่วนสำหรับบันทึกเครื่องมือที่ใช้และกฎที่เข้มงวดว่าใครเป็นผู้มีสิทธิ์ sign off

ยังไม่มีการกำหนดเป็นลายลักษณ์อักษร (Nothing written down) นี่เป็นกรณีที่พบได้บ่อยที่สุด งานวิจัยฉบับร่างจากเดือนพฤษภาคม 2026 ได้สำรวจ repository ยอดนิยมบน GitHub จำนวน 1,000 แห่ง และพบว่ามีเพียง 118 แห่งที่มีนโยบายเกี่ยวกับ AI เป็นลายลักษณ์อักษร การนิ่งเฉยไม่ได้หมายความว่าได้รับอนุญาต ให้สอบถามใน issue tracker ด้วยประโยคสั้นๆ ก่อนที่คุณจะเขียน patch แล้วคำตอบนั้นจะกลายเป็นบันทึกสาธารณะที่คุณสามารถอ้างอิงได้ในภายหลัง

เหตุผลที่ผู้ดูแลโครงการกำหนดกฎเหล่านี้

เหตุผลประการแรกคือภาระในการตรวจสอบ ซึ่งคำนวณได้เพียงทิศทางเดียว เอเจนต์สามารถสร้าง merge request ที่ดูสมเหตุสมผลยาว 400 บรรทัดได้ในเวลาเพียงหนึ่งนาที การตรวจสอบคำขอดังกล่าวอย่างถูกต้องต้องใช้เวลาของผู้ดูแลโครงการถึงครึ่งวัน และผู้ดูแลโครงการส่วนใหญ่เป็นอาสาสมัคร ต้นทุนในการส่งคำขอจึงลดลงจนเกือบเป็นศูนย์ ในขณะที่ต้นทุนในการตรวจสอบไม่ได้ลดลงเลย

curl แสดงให้เห็นถึงผลกระทบที่ปลายทางของเส้นกราฟนี้ Daniel Stenberg รายงานในช่วงกลางปี 2025 ว่าประมาณหนึ่งในห้าของรายงานช่องโหว่ที่เข้ามาผ่านโครงการ bug bounty เป็นสิ่งที่เขาเรียกว่า AI slop ซึ่งเป็นรายงานที่ระบุชื่อฟังก์ชันและเส้นทางโค้ดที่มีอยู่จริง อธิบายการโจมตีที่ดูเป็นไปได้ แต่กลับไม่มีเนื้อหาที่เป็นประโยชน์ใดๆ โครงการจึงยุติโครงการ bounty ในช่วงต้นปี 2026 แทนที่จะสนับสนุนการไหลบ่าของข้อมูลเหล่านี้ต่อไป แม้จะเป็นรายงานแทนที่จะเป็น patch แต่นี่คือกลไกเดียวกันที่ทำให้ผู้ดูแลโครงการรู้สึกเหนื่อยล้าตั้งแต่ก่อนจะเปิดดู PR ของคุณ

GNOME Calendar ได้ระบุปัญหานี้ไว้เป็นป้ายกำกับ ในเดือนมิถุนายน 2026 โครงการได้นำป้ายกำกับ "Probabilistically Automated" มาใช้สำหรับ merge request ที่แสดงให้เห็นถึง "การพึ่งพา 'ปัญญาประดิษฐ์' อย่างมากหรือทั้งหมดในการสร้างโค้ด" และระบุอาการไว้อย่างชัดเจนว่า: "มักมาพร้อมกับการขาดการทดสอบที่เหมาะสม และการสรุป patch โดยอิงจากพฤติกรรมที่ตั้งใจไว้ตามทฤษฎี แทนที่จะเป็นความถูกต้องของโค้ด" โปรดอ่านประโยคสุดท้ายนั้นซ้ำอีกครั้ง โค้ดดูเหมือนจะทำงานได้ แต่ไม่มีใครตรวจสอบว่ามันทำงานได้จริงหรือไม่

เหตุผลประการที่สองคือที่มาของโค้ด (provenance) ซึ่งหมายถึงโค้ดมาจากที่ใดและอยู่ภายใต้ใบอนุญาตใด QEMU ระบุถึงความขัดแย้งนี้ไว้อย่างชัดเจนว่า การลงชื่อรับรอง (sign-off) เป็นการยืนยันว่าคุณ "เข้าใจสถานะลิขสิทธิ์และใบอนุญาตของเนื้อหา" ที่คุณนำเสนออย่างถ่องแท้ แต่สถานะลิขสิทธิ์ของผลลัพธ์จากโมเดลยังคงไม่มีความชัดเจน สภาของ Gentoo ให้เหตุผลเดียวกันนี้ รวมถึงประเด็นด้านคุณภาพและจริยธรรม คุณไม่จำเป็นต้องเห็นด้วยกับการตีความทางกฎหมาย แต่คุณต้องตระหนักว่านี่เป็นการตัดสินใจของผู้ดูแลโครงการ ไม่ใช่ของคุณ

ฉันจะค้นหานโยบาย AI ของโครงการได้อย่างไร

ให้ตรวจสอบตามลำดับสถานที่ดังต่อไปนี้

• CONTRIBUTING.md ใน root ของ repository จากนั้นตรวจสอบ .github/CONTRIBUTING.md และไฟล์ DCO ใดๆ ที่อยู่ถัดจากนั้น
• เอกสารสำหรับนักพัฒนา โดย QEMU เก็บกฎไว้ใน docs/devel/code-provenance.rst ส่วน kernel เก็บไว้ใน Documentation/process/coding-assistants.rst
• เว็บไซต์หรือ wiki ของโครงการ นโยบายของ Gentoo อยู่บนหน้า wiki ของสภา ส่วนของ NetBSD อยู่ในแนวทางการ commit
• ระบบติดตามปัญหา (issue tracker) และคลังจดหมายของ mailing list โดยปกติแล้วนโยบายมักจะปรากฏอยู่ในนั้นหลายเดือนก่อนที่จะมีการเขียนลงใน repository

หากคุณอยู่ใน checkout ให้ใช้คำสั่ง grep เพียงคำสั่งเดียวเพื่อครอบคลุมข้อมูลส่วนใหญ่:

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

จากนั้นให้อ่านประวัติของโครงการ เพราะธรรมเนียมปฏิบัติที่ถูกบันทึกไว้มีความสำคัญเหนือกว่าบทสรุปใดๆ:

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

จำนวนที่ปรากฏถัดจากค่า trailer จะบอกให้คุณทราบถึงรูปแบบที่โครงการนี้ใช้งานจริง หากผลลัพธ์ว่างเปล่าหมายความว่าไม่มีใครเปิดเผยข้อมูลในรูปแบบนั้นที่นี่ ซึ่งถือเป็นข้อมูลสำคัญเช่นกัน หากโครงการอยู่บน GitHub และคุณยังไม่คุ้นเคยกับ workflow วิธีการทำงานของ pull request และ fork บน GitHub จะครอบคลุมกลไกการทำงานที่ส่วนนี้อ้างถึง

เปิดเผยข้อมูลในส่วนท้ายของ commit (commit trailer) แทนการเขียนในคอมเมนต์

ส่วนท้าย (trailer) คือบรรทัดรูปแบบ Key: value ที่อยู่ในย่อหน้าสุดท้ายของข้อความ commit ซึ่ง Git ใช้รูปแบบนี้สำหรับ Signed-off-by: และ Co-authored-by: อยู่แล้ว และเครื่องมือต่างๆ ก็สามารถประมวลผลได้ จึงเป็นวิธีเดียวที่ข้อมูลการเปิดเผยจะติดไปกับโค้ดใน 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>

เคอร์เนลได้ระบุรูปแบบดังกล่าวไว้ใน Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2] โดยมีข้อกำหนดชัดเจนเกี่ยวกับขอบเขตของบรรทัดว่า: "AI agents ห้ามเพิ่มแท็ก Signed-off-by โดยเด็ดขาด มีเพียงมนุษย์เท่านั้นที่สามารถรับรอง Developer Certificate of Origin (DCO) ได้ตามกฎหมาย" ชื่อของเอเจนต์ต้องระบุไว้ที่ Assisted-by ส่วนชื่อของคุณต้องระบุที่ Signed-off-by ห้ามให้เครื่องมือเขียนชื่อในส่วนที่สอง และห้ามให้เครื่องมือสร้างที่อยู่ Co-authored-by ที่ไม่มีตัวตนขึ้นมาเอง

ชื่อเรียกอาจแตกต่างกันไป ดังนั้นให้คัดลอกชื่อที่ใช้ในพื้นที่นั้นๆ แทนการตั้งชื่อขึ้นเอง ในเดือนพฤษภาคม 2026 มีการเสนอแพตช์ไปยังรายการอีเมลของ QEMU เพื่อผ่อนปรนข้อห้ามของโครงการสำหรับการเปลี่ยนแปลงเชิงกลไก, การทดสอบ, เอกสาร และการแก้ไขบั๊กที่มีความยาวไม่เกินยี่สิบบรรทัด โดยบันทึกไว้ด้วยส่วนท้ายรูปแบบ AI-used-for: tests, docs อย่างไรก็ตาม ณ เดือนสิงหาคม 2026 ข้อเสนอดังกล่าวยังคงอยู่ระหว่างการพิจารณาในรายการอีเมล และเอกสารที่ถูก commit ยังคงปฏิเสธเนื้อหาที่สร้างโดยอัตโนมัติ มีโครงการหนึ่งที่เปลี่ยนจุดยืนถึงสองครั้งระหว่างปี 2023 ถึง 2026 การเปลี่ยนแปลงครั้งต่อไปจะไม่รอคุณ นี่คือเหตุผลว่าทำไมวิธีการจึงสำคัญกว่ารายการที่กำหนดไว้

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 ต้องการ Git เวอร์ชัน 2.32 หรือใหม่กว่า คำสั่งที่สองควรแสดงค่ากลับมาให้คุณโดยตรง หากได้ค่าว่างเปล่าหมายความว่า git ไม่สามารถแยกส่วนท้ายได้ ซึ่งมักเกิดจากการที่มีบรรทัดว่างหรือประโยคทั่วไปแทรกอยู่ในบล็อกส่วนท้ายที่ด้านล่างของข้อความ สำหรับชุด commit ที่คุณเขียนไว้แล้ว git rebase --signoff origin/main จะช่วยเพิ่มการลงชื่อกำกับในทุก commit และ git interpret-trailers --in-place --trailer "Assisted-by: Claude:claude-3-opus" msg.txt จะใช้สำหรับแก้ไขไฟล์ข้อความ

ควรวางแผนรับมือกับความล้มเหลวสองรูปแบบ: การทำ squash merge จะเขียนข้อความ commit ใหม่ ดังนั้นในโครงการที่ใช้การ squash ให้ระบุข้อมูลการเปิดเผยซ้ำในคำอธิบายของ PR ซึ่งเป็นจุดที่ผู้ดูแลโครงการจะอ่าน และคอมเมนต์ในการรีวิวไม่ใช่บันทึกถาวร เพราะคอมเมนต์สามารถแก้ไขได้และไม่เคยถูกรวมเข้าในประวัติของ git

ความถูกต้องเป็นเรื่องสำคัญทั้งสองด้าน การใส่ Assisted-by ใน commit ที่คุณเขียนด้วยมือถือเป็นสิ่งรบกวนและทำให้การเปิดเผยข้อมูลที่แท้จริงของคุณมีค่าน้อยลง แต่การละเลยไม่ใส่ใน commit ที่เอเจนต์เขียนขึ้นคือสิ่งที่ทำให้ความสัมพันธ์ในการทำงานสิ้นสุดลง

Signed-off-by รับรองอะไรกันแน่?

DCO คือข้อความสั้นๆ เวอร์ชัน 1.1 ซึ่งเผยแพร่ไว้ที่ developercertificate.org และถูกใช้งานโดย kernel, QEMU รวมถึงโครงการอื่นๆ อีกมากมาย การเพิ่ม Signed-off-by: Your Name <you@example.com> หมายความว่าคุณยืนยันที่จะปฏิบัติตามข้อกำหนดนั้น โปรดอ่านสิ่งที่คุณกำลังรับรอง เพราะคนส่วนใหญ่มักลงชื่อโดยไม่เคยอ่านเนื้อหาเลย

ข้อ (a) ระบุว่าผลงานที่นำส่ง "ถูกสร้างขึ้นโดยข้าพเจ้าทั้งหมดหรือบางส่วน และข้าพเจ้ามีสิทธิ์ที่จะนำส่งภายใต้สัญญาอนุญาตโอเพนซอร์สที่ระบุไว้ในไฟล์" ข้อ (b) ครอบคลุมถึงงานที่พัฒนาต่อจากโค้ดโอเพนซอร์สเดิมที่คุณมีสิทธิ์ส่งต่อพร้อมการแก้ไข ข้อ (c) ครอบคลุมถึงโค้ดที่ได้รับมาจากผู้อื่นซึ่งได้ให้การรับรองในลักษณะเดียวกันไว้แล้ว และข้อ (d) ระบุว่าคุณเข้าใจว่าผลงานและข้อมูลส่วนบุคคลในลายเซ็นของคุณจะถูกเปิดเผยต่อสาธารณะและถูกจัดเก็บไว้อย่างไม่มีกำหนด

สังเกตสิ่งที่ขาดหายไป DCO ไม่ได้ระบุว่าคุณต้องเป็นผู้พิมพ์ทุกตัวอักษรด้วยตนเอง แต่ระบุว่าคุณมีสิทธิ์นำส่งโค้ดภายใต้สัญญาอนุญาตนี้ นี่คือเหตุผลที่โค้ดที่สร้างขึ้นโดยอัตโนมัติ (generated code) มักเป็นประเด็นที่คลุมเครือ เพราะคำถามไม่ใช่เรื่องความเป็นผู้ประพันธ์ แต่เป็นเรื่องที่คุณสามารถยืนยันที่มาของโค้ดได้หรือไม่ โครงการส่วนใหญ่ที่ต้องการการลงชื่อรับรองมักกำหนดให้ใช้ชื่อจริง ดังนั้นการใช้ชื่อแฝงจึงไม่ผ่านการตรวจสอบ ให้เพิ่มบรรทัดดังกล่าวด้วย git commit -s ซึ่งจะอ่านค่า user.name และ user.email จาก git config ของคุณ เมื่อบอท DCO ปฏิเสธ PR ของคุณและระบุ commit ที่ขาดบรรทัดดังกล่าว การใช้ git rebase --signoff origin/main แล้ว force push ไปยัง branch ของคุณจะช่วยแก้ไขปัญหานี้ได้

การลงนามใน commit ไม่เหมือนกับการทำ sign-off

git commit -s เป็นการเพิ่มบรรทัดข้อความลงใน commit ส่วน git commit -S เป็นการสร้างลายเซ็นดิจิทัล (cryptographic signature) กำกับวัตถุ commit โดยใช้ GPG key หรือ SSH key ของคุณ ทั้งสองอย่างนี้ตอบคำถามที่แตกต่างกัน ลายเซ็นดิจิทัลเป็นการยืนยันว่า commit นี้มาจากผู้ถือครองกุญแจดังกล่าวจริงและไม่มีการแก้ไขข้อมูลหลังจากนั้น แต่ลายเซ็นไม่ได้ระบุถึงที่มาของโค้ดภายใน ดังนั้น commit ที่มีการลงนามแต่เต็มไปด้วยโค้ดที่สร้างขึ้นโดยไม่เปิดเผยที่มา ก็ถือว่าเป็นการลงนามที่ถูกต้องแต่ยังคงละเมิดนโยบายอยู่ การทำ sign-off คือการยืนยันเกี่ยวกับแหล่งที่มา ในขณะที่ลายเซ็นคือการยืนยันเกี่ยวกับตัวตน โครงการที่ต้องการทั้งสองอย่างจะกำหนดให้ผู้พัฒนาต้องดำเนินการทั้งสองขั้นตอน

ห้ามส่งโค้ดที่คุณอธิบายไม่ได้ในการรีวิว

นี่คือบททดสอบ และมันไม่ใช่เรื่องของความซื่อสัตย์เพียงอย่างเดียว สำหรับทุกบรรทัดที่คุณเขียน: สิ่งนี้มีไว้เพื่ออะไร และถ้าไม่มีมันจะเกิดอะไรขึ้น หากคำตอบใดคำตอบหนึ่งขาดหายไป แพตช์นั้นยังไม่พร้อม เพราะคอมเมนต์จากผู้รีวิวจะตามมา และคำตอบของคุณจะเป็นเพียงการสร้างเนื้อหาขึ้นมาใหม่ในรอบถัดไป ผู้รีวิวสามารถดูออก และนั่นคือช่วงเวลาที่ผู้ร่วมพัฒนาเปลี่ยนสถานะกลายเป็นภาระของโครงการ ให้ถามคำถามเดียวกันนี้กับกรณีขอบเขต (edges), อินพุตว่างเปล่า (empty input), เส้นทางเมื่อเกิดข้อผิดพลาด (failure path) และผู้เรียกใช้งานรายที่สอง

ให้รันโค้ดนั้นจริง ๆ ทำการ build, รันชุดทดสอบของโครงการ และเขียนตัวอย่างเพื่อจำลอง (reproducer) บั๊กที่คุณอ้างว่าแก้ไขได้ เอกสารของ kernel ได้ให้แนวทางที่ตรงไปตรงมาไว้ว่า: "หากการแก้ไขไม่สามารถ build หรือทดสอบได้ หรือไม่สามารถสร้างตัวอย่างจำลองได้ ให้ระบุไว้อย่างชัดเจน: ผู้ดูแลโครงการเสียเวลาไปมากเกินไปกับการวิเคราะห์รายงานที่ไม่ได้รับการยืนยันและการแก้ไขที่ไม่ได้ผ่านการทดสอบ" การเขียนว่า "ฉันไม่สามารถทดสอบสิ่งนี้บนฮาร์ดแวร์จริงได้" ไม่ทำให้คุณเสียหายอะไร แต่การทำให้เข้าใจว่าคุณได้ทดสอบแล้วจะทำให้คุณเสียความน่าเชื่อถือในโครงการนั้นไป

จงตอบคอมเมนต์การรีวิวด้วยตัวเอง ด้วยคำพูดของคุณเอง และในเวลาของคุณเอง การตอบกลับที่ส่งมาภายในสามสิบวินาทีหลังจากได้รับคอมเมนต์และเขียนอธิบายซ้ำยาวห้าพารากราฟจะบอกผู้ดูแลโครงการทันทีว่าเกิดอะไรขึ้น นอกจากนี้ให้รักษาขนาดของ diff ให้เล็กไว้ โค้ดสี่สิบบรรทัดที่คุณเข้าใจอย่างถ่องแท้มีค่าต่อโครงการมากกว่าการรีแฟคเตอร์สี่ร้อยบรรทัดที่คุณเพียงแค่ควบคุมดูแล หาก AI ของคุณยังคงส่งผลลัพธ์กลับมามากกว่าที่คุณต้องการ ทักษะในการควบคุมให้เหลือเพียงการเปลี่ยนแปลงที่เล็กที่สุดที่ใช้งานได้ คือวิธีหนึ่งที่จะช่วยให้แพตช์มีขนาดที่คุณยังสามารถปกป้องได้ทีละบรรทัด

เก็บคำสั่งของ agent ไว้ใน repository

คำสั่งที่คุณให้กับ agent ถือเป็นส่วนหนึ่งของ toolchain ของคุณ ดังนั้นควรปฏิบัติกับมันเหมือนกับโค้ด ไฟล์ที่อยู่ใน root ของ repository ซึ่งมักจะเป็น AGENTS.md จะทำหน้าที่เก็บคำสั่ง build, คำสั่งทดสอบ, รูปแบบของ commit message, ข้อกำหนดในการ sign-off และกฎเกณฑ์ด้านสไตล์ที่โปรเจกต์ได้จัดทำเอกสารไว้แล้ว ไฟล์ดังกล่าวจะถูกทำ version control และสามารถตรวจสอบย้อนหลังได้ ซึ่งจะคงความสม่ำเสมอในทุกวัน การพิมพ์คำสั่งใหม่จากความจำในแต่ละเซสชันจะทำให้ได้ patch ที่แตกต่างกันออกไป และคุณจะไม่ทราบเลยว่าเซสชันใดเป็นผู้สร้าง patch ที่ถูกปฏิเสธ การเขียน AGENTS.md ที่ทั้ง agent และมนุษย์สามารถอ่านได้ ได้อธิบายรายละเอียดเกี่ยวกับตัวไฟล์นี้ไว้

ข้อควรระวังเกี่ยวกับการมีส่วนร่วมใน repository ของผู้อื่น คืออย่าส่ง PR แรกของคุณด้วยการเพิ่มไฟล์คำสั่งสำหรับ agent เข้าไปในโปรเจกต์ที่คุณไม่ได้เป็นผู้ดูแล เพราะการกระทำดังกล่าวอาจถูกมองว่าเป็นการพยายามกำหนดนโยบายเครื่องมือของโปรเจกต์จากภายนอก และเป็นวิธีที่รวดเร็วในการทำให้บัญชีของคุณถูกเชื่อมโยงกับสิ่งที่ผู้ดูแลโปรเจกต์รู้สึกเบื่อหน่ายอยู่แล้ว ให้เก็บไฟล์นั้นไว้ใน fork ของคุณเองจนกว่าจะมีคนร้องขอ

สถานที่ที่คุณรัน agent ก็มีความสำคัญด้วยเหตุผลเดียวกัน การใช้ agent ที่สามารถ build โปรเจกต์และรันการทดสอบภายใน sandbox ที่คุณควบคุมได้ จะทำให้คุณได้ patch ที่ผ่านการตรวจสอบแล้วจริงๆ ซึ่งถือเป็นความแตกต่างระหว่างการเปิดเผยว่าได้รับความช่วยเหลือกับการเปิดเผยเพียงการคาดเดา การรัน coding agent บน VPS ของคุณเอง ครอบคลุมการตั้งค่าดังกล่าว และ ความแตกต่างในทางปฏิบัติระหว่าง Claude Code, Cursor, Codex และ Copilot ครอบคลุมถึงความแตกต่างของเครื่องมือเหล่านี้ในการใช้งานจริงในแต่ละวัน

วิธีการเมื่อนโยบายมีการเปลี่ยนแปลง

1. ค้นหานโยบายที่ระบุไว้ก่อนเริ่มดำเนินการใดๆ ไม่ว่าจะเป็นใน repository, เอกสารสำหรับนักพัฒนา, เว็บไซต์ หรือระบบติดตามปัญหา
2. หากไม่มีนโยบาย ให้สอบถามผ่าน issue ด้วยประโยคสั้นๆ เพียงประโยคเดียว และเก็บคำตอบนั้นไว้
3. เปิดเผยข้อมูลในรูปแบบที่โครงการนั้นๆ กำหนดไว้ ในส่วน commit trailer และระบุซ้ำในเนื้อหาของ PR หากโครงการมีการทำ squash commit
4. ลงชื่อกำกับด้วยชื่อจริงของคุณ โดยตระหนักว่าบรรทัดดังกล่าวคือการยืนยันสิทธิ์ของคุณในการส่งมอบโค้ดนั้น
5. ตรวจทาน patch ของคุณเองเสมือนว่าผู้อื่นเป็นผู้เขียน เพราะในความเป็นจริงแล้วมีผู้อื่นเกี่ยวข้องด้วย

ทุกโครงการที่ระบุไว้ในหน้านี้อาจมีการเปลี่ยนแปลงไปแล้วในเวลาที่คุณอ่าน แต่ขั้นตอนทั้ง 5 ประการนี้จะไม่มีการเปลี่ยนแปลง

FAQ

ฉันจำเป็นต้องเปิดเผยหรือไม่ว่าใช้ AI coding agent?

ให้ตรวจสอบโครงการนั้นๆ เนื่องจากคำตอบถูกกำหนดไว้ในระดับท้องถิ่น Fedora กำหนดให้ต้องมีการเปิดเผยเมื่อส่วนสำคัญของผลงานมาจากเครื่องมือโดยไม่มีการแก้ไข Linux kernel ร้องขอให้ใช้ Assisted-by trailer ส่วน Gentoo และ QEMU ณ เดือนสิงหาคม 2026 ไม่ต้องการผลงานดังกล่าวเลย หากไม่มีข้อกำหนดที่เป็นลายลักษณ์อักษร ให้เปิดเผยไว้ใน commit trailer เสมอ ผู้ดูแลโครงการที่มาพบภายหลังมักจะตอบสนองต่อการปกปิดข้อมูลมากกว่าตัวเครื่องมือเอง และการตอบสนองนั้นจะส่งผลต่อผลงานอื่นๆ ทั้งหมดที่คุณเคยส่งมา

โครงการโอเพนซอร์สใดบ้างที่ห้ามใช้โค้ดที่สร้างโดย AI?

ข้อมูล ณ เดือนสิงหาคม 2026: Gentoo ตั้งแต่เดือนเมษายน 2024, NetBSD ซึ่งถือว่าผลลัพธ์จาก LLM เป็นโค้ดที่ไม่น่าเชื่อถือและต้องได้รับการอนุมัติจากทีมหลัก, QEMU ซึ่งปฏิเสธผลงานที่ได้มาจากเนื้อหาที่สร้างขึ้น และแอปพลิเคชัน GNOME หลายรายการรวมถึง Loupe และ Calendar โปรดอ่านข้อกำหนดของแต่ละโครงการโดยตรงแทนการอ้างอิงรายการนี้ เนื่องจากข้อมูลอาจล้าสมัย โปรดสังเกตข้อยกเว้นที่โครงการส่วนใหญ่มีร่วมกัน คือการใช้โมเดลเพื่อค้นคว้า API, รัน static analysis หรือช่วยดีบั๊กโค้ด มักจะสามารถทำได้ตราบเท่าที่ผลลัพธ์จากโมเดลไม่ได้ถูกรวมอยู่ใน patch

Signed-off-by กับ signed commit แตกต่างกันอย่างไร?

Signed-off-by คือบรรทัดข้อความธรรมดาที่เพิ่มโดย git commit -s ซึ่งเป็นการรับรอง developer certificate of origin หมายความว่าคุณมีสิทธิ์ส่งมอบโค้ดนี้ภายใต้สัญญาอนุญาตของโครงการ ส่วน signed commit ซึ่งทำด้วย git commit -S คือการลงลายมือชื่อแบบเข้ารหัสบน commit object ด้วยกุญแจ GPG หรือ SSH ของคุณ ซึ่งเป็นการพิสูจน์ว่า commit นั้นมาจากกุญแจของคุณและไม่ได้ถูกแก้ไข แหล่งที่มาและตัวตนเป็นข้ออ้างที่แยกจากกัน ดังนั้น signed commit จึงยังคงละเมิดนโยบายเกี่ยวกับ AI ได้

ฉันสามารถใส่การเปิดเผยข้อมูลไว้ในคำอธิบาย pull request แทน commit message ได้หรือไม่?

ควรใส่ไว้ใน commit message เนื่องจากเป็นบันทึกที่ถูกจัดเก็บใน git history และติดตัวไปกับโค้ดสำหรับทุกคนที่ clone repository ในภายหลัง คำอธิบายใน pull request สามารถแก้ไขได้ในภายหลังและอยู่บนแพลตฟอร์มที่โฮสต์เท่านั้น ให้เพิ่มข้อมูลนี้ในเนื้อหาของ PR ด้วยในกรณีที่โครงการใช้การ squash merge เพราะการ squash จะเขียนทับ commit message ของคุณและอาจทำให้ trailer หายไปได้

pull request ของฉันถูกปิดเพราะเป็นสิ่งที่ AI สร้างขึ้น ฉันควรทำอย่างไร?

อย่าโต้เถียงเรื่องนโยบายในกระทู้ เพราะผู้ที่ปิด PR ไม่ได้เป็นผู้กำหนดกฎเพียงลำพัง และกระทู้ไม่ใช่สถานที่สำหรับเปลี่ยนแปลงกฎดังกล่าว ให้อ่านข้อความในนโยบายแล้วตัดสินใจว่าคุณสามารถปฏิบัติตามได้หรือไม่ ในกรณีที่โครงการห้ามใช้ patch ที่สร้างขึ้น การรายงานบั๊กที่ชัดเจนพร้อมตัวอย่างที่ทำซ้ำปัญหาได้ (reproducer) โดยไม่มี patch ยังคงเป็นสิ่งที่ยินดีรับ และมักจะเป็นผลงานที่มีประโยชน์มากกว่า หากคุณจะกลับมาส่งโค้ดอีกครั้ง ให้ส่งเป็นการเปลี่ยนแปลงขนาดเล็กที่คุณสามารถอธิบายได้ทีละบรรทัด