RFC 406i — โปรโตคอลมาตรฐาน RAGS สำหรับปฏิเสธผลงานขยะที่สร้างโดย AI

 (406.fail)
10 คะแนน โดย GN⁺ 2026-03-08 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เอกสารที่นิยามโปรโตคอลมาตรฐานในรูปแบบ RFC เชิงล้อเลียน เพื่อใช้ ปฏิเสธผลงานคุณภาพต่ำที่สร้างโดย AI โดยอัตโนมัติ ในโอเพนซอร์สรีโพซิทอรี ชุมชน และพื้นที่ลักษณะคล้ายกัน
  • เพียงแค่เมนเทนเนอร์วาง URI นี้ ก็สามารถใช้เป็นวิธีมาตรฐานในการส่งสัญญาณปฏิเสธแบบ "ตรวจพบ AI slop" ได้ทันที
  • ระบุรายการลักษณะทั่วไปของผลงานที่สร้างโดย AI พร้อมชี้ตรง ๆ ถึง การสิ้นเปลืองทรัพยากรในการดูแลรักษา และความเสี่ยงของผลลัพธ์ที่ไม่ได้รับการตรวจสอบ
  • ชี้ชัดว่าแม้งานที่ส่งมาจาก LLM จะผ่านการทดสอบและไวยากรณ์ถูกต้อง แต่ถ้าไม่มี ความเข้าใจด้านตรรกะและสถาปัตยกรรม ก็ไร้คุณค่าโดยพื้นฐาน
  • แม้จะเป็นเอกสารเสียดสีที่ยืมรูปแบบ RFC มาใช้ แต่ก็สะท้อนความเหนื่อยล้าจริงของเมนเทนเนอร์ต่อ การใช้ AI อัตโนมัติเพื่อส่งผลงานพร่ำเพรื่อ ในระบบนิเวศโอเพนซอร์ส

Abstract - จุดประสงค์ของเอกสารนี้

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

1. Introduction - ทำไมคุณจึงถูกพามาที่หน้านี้

  • คุณถูกพามาที่หน้านี้เพราะผลงานที่คุณส่งมาได้กระตุ้น ระบบตรวจจับ AI slop แบบอัตโนมัติหรือแบบแมนนวล
  • โดยเฉพาะอย่างยิ่ง เมนเทนเนอร์หรือวิศวกรอาวุโสได้ดูสิ่งที่คุณส่งมา ถอนหายใจเชิงอัตถิภาวนิยมอย่างล้ำลึก แล้วตัดการเชื่อมต่อทันทีพร้อมวาง URI นี้
  • คีย์เวิร์ด "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL" ที่ใช้ในเอกสารนี้ ให้ตีความเป็นมาตรวัดว่า "เราไม่อยากรีวิวสิ่งที่ส่งมานี้มากแค่ไหน"

2. Diagnostic Analysis - ลักษณะที่ตรวจพบในสิ่งที่คุณส่งมา

  • จากการวิเคราะห์ด้านคำศัพท์และโครงสร้างของเนื้อหาที่คุณส่งมา สรุปได้ว่า prompt engineering ของคุณผิดพลาด และดังนั้น คุณควรรู้สึกละอายด้วยตนเอง
  • ผลจากการให้ นกแก้วเชิงความน่าจะเป็น เขียน PR การเปิดเผยช่องโหว่ คอมเมนต์ใน issue หรือโพสต์ในฟอรัมแทนคุณ ก็คือมัน โกหกพวกเราทุกคน
  • มีการ ตรวจพบ ลักษณะ ต่อไปนี้อย่างชัดเจนจนปฏิเสธไม่ได้:
    • ใช้ น้ำเสียงสุภาพเกินจริงและเป็นหุ่นยนต์
    • มี API ที่ไม่มีอยู่จริงเลยแม้แต่น้อย แต่เขียนมาด้วยความมั่นใจสูง
    • โค้ด boilerplate พองโต ที่ไม่แก้ปัญหาจริงแม้แต่นิดเดียว
    • ใช้คำว่า "delve" อย่างจริงจังในคำอธิบาย PR
    • มี เศษตกค้างจากผลลัพธ์ LLM อย่าง Certainly! Here is the revised output: หลงเหลืออยู่ใน docstring คอมเมนต์ หรือรายงานความปลอดภัย
    • แนบ commit message 600 คำ หรือบทความเชิงทฤษฎียาวเหยียด กับการแก้เพียงคำสะกดผิดเล็กน้อย
    • import ไลบรารีหลอนที่ไม่มีอยู่จริง อย่าง utils.helpers
    • เติมย่อหน้าสรุปปิดท้ายบั๊กรายงานเล็กน้อยด้วยประโยคที่ขึ้นต้นว่า "In conclusion, this robust and scalable solution..."
    • การตั้งชื่อตัวแปรและฟังก์ชันที่ประหลาดและปลอดเชื้อเกินจริง จนมนุษย์โปรแกรมเมอร์ที่ขับเคลื่อนด้วยคาเฟอีนและการอดนอนไม่มีทางทำได้
    • พึ่งพา regex หรือแนวคิดหลอน ๆ อย่างสิ้นเชิง โดยไม่เข้าใจสถาปัตยกรรมระบบจริงหรือ threat model
    • มีร่องรอยของการ วางบล็อก context ขนาดใหญ่ที่ไม่เกี่ยวข้องแบบมืดบอด ลงในพรอมป์ต์ประเภท "fix this" หรือ "find a bug"
    • ขอโทษคอมไพเลอร์ ในประวัติ commit
  • ตามทฤษฎีบทพื้นฐานของขยะอัตโนมัติ: คุณไม่ได้อ่านมัน ดังนั้นเราก็จะไม่อ่านเช่นกัน

3. The Asymmetry of Effort - ความไม่สมดุลของความพยายาม

  • เมนเทนเนอร์โปรเจ็กต์ ทีม security triage และโมเดอเรเตอร์ชุมชน ไม่ว่าจะเป็นอาสาสมัครไร้ค่าตอบแทนหรือเพื่อนร่วมงานในองค์กรที่อ่อนล้า ต่างก็ทำงานภายใต้ ข้อจำกัดด้านทรัพยากรที่เข้มงวด
  • เมื่อตรวจสอบบันทึกธุรกรรมของสิ่งที่คุณส่งมา:
    • a. มันดูฉลาดในความประทับใจแรกหรือไม่? - อาจจะ
    • b. มันแก้ปัญหาที่ตรวจสอบและทำซ้ำได้จริงหรือไม่? - ไม่
    • c. มันพยายามเผาผลาญเวลาที่มีจำกัดของผู้รีวิวที่เป็นมนุษย์หรือไม่? - ใช่
  • ตัวติดตามโปรเจ็กต์ ฟอรัม และรีโพซิทอรี ไม่ใช่ถังขยะสำหรับผลลัพธ์คัดลอกวางที่ไม่ผ่านการตรวจสอบ เพื่อใช้ปั่น GitHub grass เก็บ bug bounty แบบไร้มูลฐาน ปั้นความเร็วสปรินต์ให้ดูสูงปลอม ๆ หรือทำตาม KPI ขององค์กรแบบมุ่งร้าย
  • เพื่อนร่วมงานของคุณไม่ใช่ บริการตรวจสอบ LLM ฟรี

4. Resolution Protocol - ขั้นตอนการกู้คืน

  • เพื่อกู้คืนสิทธิ์ในการเขียนและฟื้นความไว้วางใจจากเพื่อนร่วมงาน คุณต้องดำเนินการตามขั้นตอนด้านล่าง ตามลำดับ:
    • 1. รัน rm -rf กับ local branch ไฟล์ข้อความ หรือสคริปต์ช่องโหว่หลอน ๆ ที่ใช้สร้างสิ่งที่ส่งมานี้
    • 2. ทำ hard reboot ให้สมองของสิ่งมีชีวิต
    • 3. อ่าน codebase จริง เอกสารโปรเจ็กต์ หรือ threat model แล้ว ตรวจสอบสถานะงานและตรรกะของตัวเองด้วยมือ
    • 4. ห้ามกลับมาจนกว่าจะบรรลุสติสัมปชัญญะที่พิสูจน์ได้ และพร้อม พิมพ์ด้วยนิ้วของมนุษย์ด้วยตัวเอง

5. Security Considerations

  • สถานะ: ถูกปฏิเสธ
  • การวินิจฉัย: กำลังทำงานด้วยสคริปต์ Python ที่เขียนอย่างหยาบซ่อนอยู่ใต้ trench coat
  • มาตรการ: ตัดการเชื่อมต่อ

6. Punitive Actions - มาตรการลงโทษและการลดระดับบัญชี

  • จากผลของการส่ง AI slop บัญชีของคุณถูกย้ายไปยัง Trough of Sorrow™(รางแห่งความโศกเศร้า) โดยอัตโนมัติ และอาจมีข้อจำกัดต่อไปนี้ระหว่างช่วงคุมประพฤติ:
    • สิทธิ์ในรีโพซิทอรีถูกลดระดับแบบบังคับจาก WRITE เป็น WISHFUL_THINKING
    • PR ทั้งหมดในอนาคตจะถูกส่งผ่าน โมเด็ม dial-up ความเร็ว 14.4k baud ที่ต่อกับเครื่องพิมพ์ดอตเมทริกซ์ซึ่งหมึกริบบอนสีฟ้าหมดถาวร
    • รีแมป git alias ให้เมื่อพิมพ์ git push -f จะรัน rm -rf / พร้อมเล่นเสียงทรอมโบนเศร้า
    • ฟอนต์เริ่มต้นของ IDE ถูกตรึงถาวรเป็น Comic Sans 7pt
  • ไม่สามารถติดต่อผู้ดูแลระบบได้ - ตอนนี้ผู้ดูแลระบบกำลังหัวเราะเยาะคุณอยู่ในช่อง Slack ส่วนตัว

7. FAQ

  • "นี่มันหมายความว่ายังไงกันแน่?": สรุปสั้น ๆ คือ เครื่องจักรเป็นคนเขียนสิ่งที่คุณส่งมา และตอนนี้เครื่องจักรก็กำลังปฏิเสธสิ่งที่คุณส่งมานั้นอยู่ คุณเป็นเพียง คนกลางที่ทำจากเนื้อหนัง(meat-based middleman) ที่ไม่จำเป็นเลยในการแลกเปลี่ยนครั้งนี้
  • "แต่โค้ดคอมไพล์ผ่าน / รายงานละเอียด / ไวยากรณ์ถูกต้อง": จดหมายข่มขู่ที่จัดรูปแบบดี ๆ ก็ทำแบบนั้นได้เหมือนกัน ไวยากรณ์และ syntax เป็นเพียง เกณฑ์ขั้นต่ำ ของการมีส่วนร่วม ไม่ใช่เพดานสูงสุด ตรรกะของคุณก็ยังเป็นฝันไข้หลอน ๆ(hallucinated fever dream) อยู่ดี
  • "AI คืออนาคตของเทคโนโลยี": ถ้าสิ่งที่ส่งมานี้เป็นตัวแทนของอนาคต เราก็ยินดีเร่งการหวนกลับไปสู่สังคมเกษตรกรรม
  • "ฉันแค่พยายามช่วย": "ความช่วยเหลือ" ของคุณตอนนี้คล้ายกับ การโจมตีปฏิเสธการให้บริการในเครื่อง(local denial-of-service attack) ที่ห่อด้วยคำทักทายสุภาพ หากอยากช่วยจริง ให้นำพลังสร้างสรรค์นั้นไปใช้กับรีโพซิทอรีที่คุณเป็นเจ้าของและดูแลเอง
  • "ไม่มีหลักฐานว่านี่เขียนโดย AI": ความไร้สามารถของมนุษย์ถูกจำกัดโดยกฎฟิสิกส์และความขี้เกียจ แต่สิ่งที่คุณส่งมานั้นได้บรรลุระดับของ ความวิกลจริตที่มั่นใจในตัวเองและถูกต้องตามไวยากรณ์อย่างสมบูรณ์ ซึ่งมีเพียง server farm ที่เผาไฟฟ้าระดับกิกะวัตต์เท่านั้นที่สร้างได้
  • "CI/CD ผ่านแล้วและเทสต์ขึ้นเขียว": เพราะโมเดลกำเนิดของคุณได้ เขียนชุดทดสอบใหม่ ให้ assert แค่ True == True เท่านั้น
  • "ถ้าชี้ข้อผิดพลาดให้ ฉันจะได้เรียนรู้": ไม่ได้ เมนเทนเนอร์ไม่ใช่ reverse proxy สำหรับวงจรดีบัก LLM ของคุณ ถ้าต้องการ feedback ก็ให้วาง stack trace กลับเข้าไปในหน้าต่างแชตเดิมที่สร้างหายนะนี้ขึ้นมา
  • "ฉันต้องการ GitHub grass": แนะนำให้ซื้อปากกาไวท์บอร์ดสีเขียวแล้ววาดลงบนจอโดยตรง จะใช้เวลาของพวกเราน้อยกว่ามาก และยังให้ภาพลักษณ์ความเป็นมืออาชีพต่อว่าที่นายจ้างได้พอ ๆ กัน
  • "หน้าที่ของเมนเทนเนอร์โอเพนซอร์สไม่ใช่การสร้างชุมชนที่เป็นมิตรหรอกหรือ": หน้าที่คือดูแลซอฟต์แวร์ ส่วนคำว่า "เป็นมิตร" ใช้กับ สิ่งมีชีวิตที่มีสติ ที่มีส่วนร่วมด้วยความคิดจริง ไม่ได้ใช้กับบอตเน็ตอัตโนมัติที่ทำการเคี้ยวซ้ำเชิงความน่าจะเป็นอยู่ใน issue tracker
  • "ข้อความนี้ทำให้ฉันไม่พอใจ": ดีแล้ว โปรดให้ LLM ของคุณสร้างจดหมายขอโทษเชิงเอาใจแบบเฉพาะบุคคลให้ ปัจจุบันสต็อกความเห็นอกเห็นใจหมด และ SLA สำหรับการสนับสนุนทางอารมณ์อยู่ที่ 99 ปี
  • "ฉันจะไปรายงานความเป็นศัตรูนี้ต่อผู้ดูแล": คาดการณ์ไว้แล้ว และได้ส่งจดหมายลาออก 800 คำที่ LLM ตัวโปรดของคุณสร้างให้ไปยัง HR เรียบร้อย ใช้คำว่า "delve" ถึงหกครั้ง และชมเชย "synergistic paradigm" ของผู้ดูแลด้วย
  • "นี่ละเมิด Code of Conduct": CoC มีไว้คุ้มครองผู้มีส่วนร่วมที่เป็นมนุษย์ จากการวิเคราะห์พบว่าขณะนี้คุณกำลังทำงานในฐานะ เปลือกเนื้อบาง ๆ ที่ห่อ OpenAI API key อยู่ สิทธิทั้งหลายสงวนไว้ให้สิ่งมีชีวิตคาร์บอนเบสที่สามารถรู้สึกละอายได้
  • "ฉันอุทธรณ์ได้ไหม": ได้ คำอุทธรณ์ทั้งหมดจะถูกส่งตรงไปยัง /dev/null และถูกเฝ้าดูด้วย ระดับความใส่ใจที่เท่ากันทุกประการ กับที่คุณมอบให้สิ่งที่ส่งมาของตัวเอง
  • "มีวิธีขอโทษและแก้ไขไหม": มี พิมพ์ PR ต้นฉบับลงบนกระดาษหนา ๆ พับเป็นนกกระเรียนกระดาษที่คมกริบ แล้วกินมันอย่างสุภาพ เมื่อนั้นการเยียวยาจึงจะเริ่มต้นได้

Appendix A - เส้นทางการยกระดับ

  • หากละเมิด RFC 406i ซ้ำ จะถูก เพิกถอนสิทธิ์เข้าถึงทั้งหมด ต่อรีโพซิทอรี โปรเจ็กต์ เครื่องมือ และสิ่งอื่น ๆ
  • ขึ้น บัญชีดำ MAC address
  • อีเมลของคุณจะถูกสมัครรับ daily digest บทสอน regex ที่ซับซ้อนเชิงรุก โดยบังคับ
  • ขอให้เป็นวันที่ดี

Appendix B - แมโครข้อความปฏิเสธมาตรฐาน

ข้อความปฏิเสธมาตรฐานที่เมนเทนเนอร์และผู้รีวิวสามารถคัดลอกไปวางได้ทันที:

  • PR / MR:
    • PR closed. diff ของคุณอ่านแล้วเหมือนเมทริกซ์ข้อความคาดเดาที่ทำ context window หายไป เราต้องการการทดสอบด้วยมือโดยมนุษย์คาร์บอนเบสและความต่อเนื่องทางตรรกะที่แท้จริง ไม่ใช่เกมเดาสุ่มแบบอัตโนมัติ ดู: https://406.fail
    • PR 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. พารามิเตอร์ temperature ของรายงานนี้ถูกตั้งไว้สูงเกินไป เราต้องการ stack trace ดิบที่ทำซ้ำได้จากผู้ใช้ที่มีสติ ไม่ใช่เรียงความเชิงกำเนิดที่จัดรูปแบบสวยงามแต่ไม่สามารถอธิบายบั๊กที่ตรวจสอบได้ ดู: https://406.fail
    • Issue 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
  • Security / Bug bounty:
    • Report rejected. การป้อนคำเตือน linter พื้นฐานเข้า LLM เพื่อสร้างเรื่องเล่าภัยคุกคามหายนะ ไม่ถือเป็นการเปิดเผยช่องโหว่ที่ใช้ได้จริง เราไม่จ่ายค่าหัวให้กับความตื่นตระหนกสังเคราะห์ที่มีต้นทุนการคำนวณสูง ดู: https://406.fail
    • Report 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 / Discussion forum:
    • Thread locked. ชุมชนนี้ไม่ใช่ reinforcement learning sandbox สำหรับการทดลองพรอมป์ต์ที่ไม่สอดคล้องของคุณ โปรดกลับมาเมื่อคุณสามารถเขียนคำถามโดยใช้ภาระทางการรับรู้ของตัวเองได้ ดู: https://406.fail
    • Thread 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 ความคิดเห็น

 
GN⁺ 2026-03-08
ความเห็นบน Hacker News

  • ถ้าอยากช่วยจริง ๆ ก็ควรเอาพลังนั้นไปลงกับ รีโพซิทอรีที่ตัวเองเป็นเจ้าของและดูแลเอง จะดีกว่า
    คนก็ควรเรียนรู้นิสัยแบบนี้ด้วย ทุกวันนี้การเปิด fork เป็นสาธารณะทำได้ง่ายขึ้น แต่ก็ไม่ควรคาดหวังให้คนอื่นมาใช้โค้ดที่ตัวเองไม่ได้ใช้จริง
    ถ้าดูสถิติว่าบน GitHub ส่ง PR ไปกี่โปรเจกต์ต่อวัน จะเห็นว่า 99% ส่งแค่โปรเจกต์เดียว, 1% ส่งสองโปรเจกต์, 0.1% ส่งสามโปรเจกต์ ส่วนบัญชีที่ส่ง PR เกิน 5 แห่งขึ้นไปแทบทั้งหมดเป็น บอตหรือสคริปต์ ควรมี rate limit กับบอตที่ไม่ได้ลงทะเบียน

    • ถ้าเป็นแบบนี้ก็คงดีถ้ามีฟีเจอร์แนว โหมดแพตช์ถาวร ที่ให้ fork ของฉัน rebase ตามรีโพซิทอรีต้นทางเป็นระยะ ๆ เช่น ต่อให้แก้แค่บรรทัดเดียวก็ยังอัปเดตตามล่าสุดได้อัตโนมัติ

  • ฉันชอบ นโยบาย AI ของ Ghostty มากกว่า
    โดยเฉพาะประโยคที่ว่า “ถ้าคุณอธิบายไม่ได้ว่าการเปลี่ยนแปลงนี้ทำอะไร และมีผลต่อทั้งระบบอย่างไร โดยไม่ได้พึ่ง AI ก็อย่ามามีส่วนร่วมกับโปรเจกต์นี้”

    • เป็นไอเดียที่ดีนะ แต่ปัญหาคือ จะบังคับใช้อย่างไร เพราะแค่ให้ AI อธิบายแล้วเขียนใหม่เป็นคำพูดตัวเอง ก็เท่ากับเลี่ยงกติกาได้แล้ว

  • ฉันคิดว่าปัญหาคือการมีส่วนร่วมกับโอเพนซอร์สกลายเป็นเหมือน พิธีผ่านด่าน ไปแล้ว
    พอสิ่งสำคัญกลายเป็น ‘เคยมีส่วนร่วม’ มากกว่าการมีส่วนร่วมจริง ๆ PR ตื้น ๆ แบบนี้ก็เกิดขึ้น เมื่อก่อนรายงานช่องโหว่ก็คล้ายกัน — ระดับ “ใส่ null แล้วเกิด NullPointerException”
    การให้ความสำคัญกับตัวชี้วัดผิด ๆ อย่างความเร็วในการพัฒนาก็เป็นปัญหาเหมือนกัน ตอนอยู่บริษัทเก่า มีเพื่อนร่วมงานคนหนึ่งคุยว่าพัฒนาได้เร็วด้วย AI แต่พอไปดู PR แล้วเทสต์พังทั้งหมด สุดท้ายมันคือปรากฏการณ์ ทำให้ AI-assisted กลายเป็นเกมเก็บแต้ม

    • ช่วงนี้ฉันก็ได้รับ ใบสมัครงานที่เขียนด้วย AI เยอะเหมือนกัน บางส่วนก็เน้นเรื่อง GitHub contribution ด้วย ดูเหมือน PR แบบนี้อาจมีบางกรณีที่ผ่านจริง วัฒนธรรมที่ใช้ จำนวนดาว ของโปรเจกต์เป็นตัวชี้วัดการจ้างงานนี่แหละที่กระตุ้นสแปมแบบนี้
    • ให้ความรู้สึกแบบ “ฉันคำนวณเลขได้เร็วมาก” → “งั้น 137*243 เท่าไหร่?” → “132,498” → “ผิด” → “แต่ฉันตอบเร็วไง”

  • นี่ก็แค่บทความบล็อกที่เขียนเอาสนุก คนที่ ส่ง PR คุณภาพต่ำด้วย AI พวกนั้นไม่ได้มาอ่านอะไรแบบนี้หรอก
    วิธีของฉันง่ายมาก:

    1. ปิด PR
    2. ถ้าดูขอไปทีเกินไปก็แบนผู้ใช้
      ไม่นานมานี้ยังมี PR ที่ใช้ ‘’ แทน '' ในการประกาศสตริงจนทำให้ CI พังทั้งชุด ก็แบนทันที
    • เวลาปิด PR น่าจะแปะลิงก์หน้านี้ ไว้ในคอมเมนต์ ด้วย

  • ถ้าเป็นบั๊ก ก็ควรมี บรรทัดสีแดงใน diff ที่ยืนยันได้ว่ามีการแก้จริง และถ้าเป็นฟีเจอร์ อย่างน้อยก็ต้องมี เกณฑ์การยอมรับ
    ถ้าเป็นเอกสาร แค่อ่านแล้วเข้าใจก็พอ เกณฑ์ว่ามีประโยชน์หรือไม่ค่อนข้างต่ำอยู่แล้ว

  • สำหรับคำถามที่ว่า “maintainer โอเพนซอร์สไม่ควรสร้างชุมชนที่เป็นมิตรหน่อยหรือ?” คำตอบคือ มัน ไม่ใช่หน้าที่
    maintainer คือเจ้าของโปรเจกต์ และไม่จำเป็นต้องใจดีก็ได้ ถ้าไม่ชอบก็ fork ไปเองหรือไม่ก็ไปที่อื่น

    • ฉันว่าคำพูดแบบนี้จริง ๆ แล้วใกล้เคียงกับ การบงการทางอารมณ์ มากกว่า น่าจะพูดไปตรง ๆ ว่า “อย่าเสียเวลาของเราด้วยการเล่นกับอารมณ์ แต่จงทำความเข้าใจว่าทำไม PR ที่ LLM สร้างถึงไม่มีประโยชน์” จะดีกว่า พวกเราก็ใช้ LLM เป็นเหมือนกัน และรู้ดีว่าหลังจากนั้น งานจริงที่ต้องทำต่อ มันเยอะแค่ไหน

  • สะใจมาก หวังว่าบทความแบบนี้จะถูกนำไปใช้แพร่หลายเพื่อ ทำให้คนส่ง PR แบบขอไปทีรู้สึกอาย น้ำเสียงตรง ๆ จนเกือบหยาบใน FAQ กลับทำให้อ่านแล้วโล่งดี

    • แต่คนพวกนั้น ไม่ได้รู้สึกอาย หรอก เหมือนโกรธใส่มิจฉาชีพทางโทรศัพท์ — เขาก็แค่วางสายแล้วลองใหม่เท่านั้น

  • เรื่องนี้เกิดขึ้นที่บริษัท ฉันใช้ AI เขียนโค้ดเพื่อแก้ feature request เล็ก ๆ อย่างหนึ่ง แต่เพราะไม่ค่อยรู้จัก codebase ดีพอเลย ไม่มั่นใจในความถูกต้อง
    prompt 1 นาที, เก็บงาน 5 นาที, review 30 นาที อาจช่วยประหยัดเวลา engineering ไปได้ 2 วัน แต่สุดท้ายปัญหาคือความเชื่อมั่น
    หลังจากฟังความเห็นหลายด้านแล้ว ก็เลยตัดสินใจว่า จะส่งแค่ feature request โดยไม่แนบ diff
    น่าสนใจตรงที่ฝั่งสนับสนุน AI กลับแนะนำว่า “ใช้ AI ให้มากขึ้นเพื่อเพิ่มความมั่นใจ” แต่ยิ่งแก้ไปเรื่อย ๆ โค้ดก็ยิ่งพันกันจนหมดความเชื่อถือไปเลย

    • ถ้าอยากใช้โค้ดที่ LLM สร้างจริง ๆ ก็ควรทำความเข้าใจทุกการเปลี่ยนแปลง แล้ว สรุปด้วยตัวเองแนบไปกับ feature request
      ฉันเองก็เคยได้รับ PR ที่ LLM สร้างมาหลายครั้ง คุยกันไม่รู้เรื่อง แถมโค้ดก็ไม่สนแพตเทิร์นเดิม สุดท้ายเลยต้องทิ้ง
      ถ้าเป็นคน ฉันอยากให้เขาอธิบายปัญหาจากมุมมองของตัวเอง แบบนั้นช่วยได้มากกว่า
    • คุณมี สัญชาตญาณทางวิศวกรรมที่ดี อยากให้วงการนี้มีคนแบบนี้มากกว่านี้
    • ฉันไม่เข้าใจคำว่า “ประหยัดเวลา engineering ไป 2 วัน” เพราะคนที่รู้จัก codebase อยู่แล้วก็ใช้ AI แบบเดียวกันได้ไม่ใช่เหรอ ไม่เข้าใจว่าทำไมถึง พยายามให้คนอื่นมาตรวจผลลัพธ์จาก AI ทั้งที่เราก็ใช้ LLM เป็นเหมือนกัน
      บทความที่เกี่ยวข้อง: บทความเกี่ยวกับ Prompting
    • ฉันก็ใช้แนวทางคล้ายกัน เวลาเจอโค้ดที่ Claude เขียนแล้วฉันยังไม่เข้าใจทั้งหมด ฉันจะถามว่า “ตรงนี้ทำไมถึงทำแบบนี้?” “edge case จัดการยังไง?” แล้วขอให้ อธิบายอย่างเดียวไม่ต้องแก้ แบบนี้จะช่วยให้ผลลัพธ์กลายเป็นของเราเองได้
    • ถ้าคุณใช้งานไลบรารีนั้นอยู่จริง ก็ควร ทดสอบใน staging environment แล้วค่อยส่งรีวิว

  • ชอบคำว่า plonk ตอนท้ายมาก
    ดู Plonk(Usenet)

    • ถ้าเป็น BOFH Task Force ก็น่าจะทำได้ระดับนั้นอยู่แล้ว

  • ประโยคที่ว่า “ใช้ rm -rf ลบ local branch หรือสคริปต์เพ้อเจ้อทิ้งไป” นี่ตลกมาก
    คำว่า “รีบูตสมองอินทรีย์แบบฮาร์ดรีเซ็ต” ก็สมบูรณ์แบบเหมือนกัน

    • เอาจริง ๆ เหมือน LLM จะ rm -rf สมอง ของคนเขียน PR พวกนั้นไปแล้ว