AI ช่วยเร่งความเร็วในการพัฒนา แต่มีบั๊กมากขึ้น 1.7 เท่า

 (coderabbit.ai)
21 คะแนน โดย GN⁺ 2025-12-26 | 5 ความคิดเห็น | แชร์ทาง WhatsApp
  • ผลการวิเคราะห์ PR โอเพนซอร์ส 470 รายการ พบว่า โค้ดที่ AI เขียนมี ปัญหาเฉลี่ยมากกว่าโค้ดที่มนุษย์เขียน 1.7 เท่า
  • ข้อบกพร่องหลักอย่าง ข้อผิดพลาดเชิงตรรกะ ความสามารถในการอ่านที่ลดลง และช่องโหว่ด้านความปลอดภัย พบมากกว่าอย่างชัดเจนในโค้ดจาก AI โดยเฉพาะปัญหาด้านการอ่านที่เพิ่มขึ้นมากกว่า 3 เท่า
  • โค้ดจาก AI มักมี การขาดหายของการจัดการข้อผิดพลาด ข้อผิดพลาดด้าน concurrency และการตั้งชื่อไม่สอดคล้องกัน ทำให้ภาระในการรีวิวและความเสี่ยงในการปฏิบัติการเพิ่มขึ้น
  • สาเหตุถูกวิเคราะห์ว่าเกิดจาก ความเข้าใจ business logic ที่ไม่เพียงพอ การ มุ่งเน้นความถูกต้องเพียงผิวเผิน และ ความชอบต่อแพตเทิร์นที่ไม่มีประสิทธิภาพ
  • รายงานเน้นย้ำถึงความจำเป็นในการ เสริมระบบบริหารคุณภาพโค้ด AI และ นำขั้นตอนรีวิวโค้ด ความปลอดภัย และการทดสอบที่รับรู้ AI มาใช้

ภาพรวมของรายงาน AI vs Human Code Generation Report

  • CodeRabbit ดำเนินการวิจัยเพื่อวิเคราะห์เชิงประจักษ์เกี่ยวกับ ความแตกต่างด้านคุณภาพของโค้ดที่เขียนโดย AI และมนุษย์
    • ตรวจสอบ GitHub PR โอเพนซอร์ส 470 รายการ โดยในจำนวนนี้ 320 รายการเป็นการร่วมเขียนกับ AI และ 150 รายการเป็นการเขียนโดยมนุษย์เพียงอย่างเดียว
    • ผลลัพธ์ทั้งหมดถูกปรับให้เป็นมาตรฐานในรูปแบบ จำนวน issue ต่อ 100 PR และวัดความถี่ของปัญหาแต่ละประเภทผ่าน การเปรียบเทียบอัตราส่วนทางสถิติ
  • โดยสรุปคือ AI เพิ่มผลิตภาพ แต่ก็เพิ่มอัตราการเกิดข้อผิดพลาดไปพร้อมกัน
    • PR ที่ AI เขียนมีปัญหาเฉลี่ย 10.83 รายการ ต่อ PR ขณะที่ PR ที่มนุษย์เขียนมี 6.45 รายการ
    • โดยเฉพาะ ข้อผิดพลาดที่มีความรุนแรงสูง ถูกพบในโค้ดจาก AI บ่อยกว่า

ข้อจำกัดของงานวิจัย

  • ไม่สามารถยืนยันได้โดยตรงว่าเขียนโดย AI หรือไม่ จึงจัด PR ที่มี สัญญาณการร่วมเขียนกับ AI (co-authored-by) เป็น PR จาก AI
    • PR ที่ไม่มีสัญญาณดังกล่าวถือว่าเป็นการเขียนโดยมนุษย์ แต่ไม่สามารถแยกได้อย่างสมบูรณ์
  • แม้มีข้อจำกัดนี้ ความแตกต่างทางสถิติของรูปแบบปัญหาระหว่างสองกลุ่ม ก็ยังปรากฏอย่างมีนัยสำคัญ
  • ระเบียบวิธีทั้งหมดเปิดเผยไว้ท้ายรายงาน

10 ข้อค้นพบสำคัญ

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

  • 1. จำนวน issue ทั้งหมดเพิ่มขึ้น 1.7 เท่า

    • PR ที่ AI เขียนมีค่าเฉลี่ย 10.83 รายการ ต่อ PR ส่วน PR ที่มนุษย์เขียนมี 6.45 รายการ
    • PR ที่มี issue กระจุกตัวสูง (outlier) พบในโค้ดจาก AI มากกว่ามาก ทำให้ภาระการรีวิวเพิ่มขึ้น

  • 2. ข้อผิดพลาดร้ายแรงเพิ่มขึ้น

    • ปัญหาระดับร้ายแรงและวิกฤต มีมากกว่า 1.4~1.7 เท่า

  • 3. ปัญหาเชิงตรรกะและความถูกต้องเพิ่มขึ้น 75%

    • รวมถึง ข้อผิดพลาดของ business logic การพึ่งพาที่ไม่ถูกต้อง ข้อบกพร่องของ control flow และข้อผิดพลาดของการตั้งค่า
    • มีต้นทุนในการแก้ไขสูง และ มีโอกาสนำไปสู่เหตุขัดข้องในการปฏิบัติการ มาก

  • 4. ปัญหาด้านการอ่านเพิ่มขึ้นมากกว่า 3 เท่า

    • กฎการตั้งชื่อ โครงสร้างโค้ด และความสม่ำเสมอของการแสดงออก แย่ลงอย่างชัดเจน
    • แม้โค้ดจะดูเป็นระเบียบภายนอก แต่ มักละเมิดแพตเทิร์นเฉพาะของระบบภายใน

  • 5. การจัดการข้อผิดพลาดและเส้นทาง exception ที่ตกหล่นเพิ่มขึ้น 2 เท่า

    • การตรวจ null, เงื่อนไข guard และ logic การจัดการ exception มักหายไป
    • เป็นประเภทที่ เชื่อมโยงโดยตรงกับเหตุขัดข้องของบริการจริง

  • 6. ปัญหาด้านความปลอดภัยเพิ่มขึ้นสูงสุด 2.74 เท่า

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

  • 7. ปัญหาด้านประสิทธิภาพมีไม่มาก แต่กระจุกอยู่ฝั่ง AI

    • การเรียก I/O มากเกินไป มีมากกว่าประมาณ 8 เท่า
    • AI มักชอบ โค้ดที่เน้นความชัดเจน จึงทำให้ประสิทธิภาพลดลง

  • 8. ข้อผิดพลาดด้าน concurrency และ dependency เพิ่มขึ้นประมาณ 2 เท่า

    • ข้อผิดพลาดด้านลำดับ การไหลของ dependency ที่ไม่ถูกต้อง และการใช้การควบคุม concurrency ผิดวิธี พบได้บ่อย

  • 9. ปัญหาการฟอร์แมตเพิ่มขึ้น 2.66 เท่า

    • มีข้อผิดพลาดเชิงรูปแบบมาก เช่น การเยื้อง ช่องว่าง และสไตล์ไม่สอดคล้องกัน
    • แม้ใช้ auto formatter และ linter ก็ยัง เพิ่ม noise ในโค้ดจาก AI

  • 10. ความไม่สอดคล้องของการตั้งชื่อเพิ่มขึ้น 2 เท่า

    • มี ชื่อที่ไม่ชัดเจน คำศัพท์ไม่สอดคล้องกัน และการใช้ identifier ทั่วไปมากเกินไป ทำให้ ภาระการรับรู้ของผู้รีวิว สูงขึ้น

สาเหตุของการเกิดปัญหา

  • AI ขาดความเข้าใจ business logic
    • สร้างโค้ดจากแพตเทิร์นเชิงสถิติ จึง พลาดกฎของระบบ
  • สร้างโดยเน้นความถูกต้องเพียงผิวเผิน
    • โค้ดดูเหมือนถูกต้องภายนอก แต่มี ข้อผิดพลาดในการป้องกัน control flow หรือการจัดลำดับ dependency
  • ไม่ปฏิบัติตามธรรมเนียมเฉพาะของ repository
    • กฎการตั้งชื่อ โครงสร้าง และรูปแบบ ถูกทำให้กลายเป็นรูปแบบทั่วไปที่ผิดเพี้ยน
  • รูปแบบความปลอดภัยอ่อนแอลง
    • หากไม่มีคำสั่งที่ชัดเจน จะสร้าง แพตเทิร์นโค้ดที่ล้าสมัยหรือมีช่องโหว่ ซ้ำ
  • ชอบความเรียบง่ายมากกว่าประสิทธิภาพ
    • มีแนวโน้มใช้ I/O แบบวนซ้ำ และโครงสร้างที่ไม่เหมาะสมที่สุด

แนวทางรับมือสำหรับทีมวิศวกรรม

  • การนำ AI มาใช้ ไม่ได้ต้องการแค่ความเร็วที่เพิ่มขึ้น แต่ยังต้อง ออกแบบระบบประกันคุณภาพใหม่

  • 1. ให้บริบทกับ AI อย่างเพียงพอ

    • ต้องระบุ กฎทางธุรกิจ แพตเทิร์นการตั้งค่า และข้อจำกัดด้านสถาปัตยกรรม เพื่อช่วยลดข้อผิดพลาด
    • รวม แนวทางเฉพาะของ repository และ schema ในพรอมป์ต์

  • 2. บังคับใช้สไตล์โค้ดตามนโยบาย

    • ป้องกันปัญหาด้านการอ่านด้วย CI formatter, linter และ style guide

  • 3. เพิ่มกลไกป้องกันด้านความถูกต้อง

    • บังคับใช้การทดสอบ, การตรวจ null/type, ทำมาตรฐานการจัดการ exception, ระบุเงื่อนไข guard ให้ชัดเจน

  • 4. เสริมค่าเริ่มต้นด้านความปลอดภัย

    • รวมศูนย์ข้อมูลรับรอง, บล็อกการใช้รหัสผ่านโดยตรง, รัน SAST และ security linter อัตโนมัติ

  • 5. ชี้นำให้ใช้แพตเทิร์นที่มีประสิทธิภาพ

    • ประมวลผล I/O แบบ batch, เลือกโครงสร้างข้อมูลที่เหมาะสม, และให้คำใบ้ด้านประสิทธิภาพ

  • 6. นำเช็กลิสต์ PR ที่รับรู้ AI มาใช้

    • ระหว่างรีวิวให้ตรวจรายการต่อไปนี้:
      • ครอบคลุมเส้นทาง error หรือไม่
      • ความถูกต้องของการควบคุม concurrency
      • มีการตรวจสอบค่าการตั้งค่าหรือไม่
      • วิธีจัดการรหัสผ่านเป็นอย่างไร

  • 7. นำระบบอัตโนมัติสำหรับรีวิวโค้ด AI มาใช้

    • เพื่อป้องกันการพลาดบั๊กจาก ความล้าจากการรีวิวที่เพิ่มขึ้น มีการเสนอให้ใช้ เครื่องมือรีวิวโค้ด AI (CodeRabbit)
      • ช่วยทำให้มาตรฐานคุณภาพการรีวิวสม่ำเสมอ และ ลดเวลาในการตรวจกับภาระการรับรู้

บทสรุป

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

บทความที่เกี่ยวข้อง

5 ความคิดเห็น

 
cshj55 2025-12-26

1.7 เท่าก็น้อยกว่าที่คิดนะ...?
 
ds2ilz 2025-12-26

ผมเองก็รู้สึกคล้าย ๆ กันตอนเขียนโค้ดด้วย AI ครับ พอดูสาเหตุที่สรุปไว้แล้วก็คิดว่าน่าจะเป็นเพราะเวลาเราคนเขียนโค้ดนั้น แพตเทิร์น กฎการตั้งชื่อ การจัดการ edge case เงื่อนไข guard ต่าง ๆ ที่ปกติเรามีเป็นความรู้พื้นฐานอยู่แล้ว ไม่ได้ถูกส่งให้เป็นบริบทอย่างเพียงพอ
เพราะงั้นผมเลยทำไฟล์กฎที่รวบรวมเรื่องพวกนี้ไว้ไฟล์หนึ่ง แล้วเวลาจะเขียนโค้ดก็สั่งให้อ่านและปฏิบัติตามไฟล์นี้ทุกครั้ง แบบนี้พอปรับปรุงแค่ไฟล์กฎ ผลลัพธ์ที่ได้ก็ดีขึ้นมากเลยครับ
 
princox 2025-12-26

กลัวว่าจะมีความเห็นประมาณว่า "ทำออกมาได้เยอะขนาดนั้น งั้นบั๊กมากขึ้น 1.7 เท่าก็เหมือนได้มาฟรีไม่ใช่เหรอ" ...
 
kimjoin2 2025-12-26

แต่มันก็เร็วใช่ไหมล่ะ? ทำให้นึกถึงมีมนี้เลย 555
 
GN⁺ 2025-12-26
ความเห็นจาก Hacker News

  • ผมคิดว่า ‘vibe coding’ มีอยู่ก่อนยุค AI แล้ว

    • ผมเคยเห็นนักพัฒนาหลายคนที่ไม่คิดเลยว่าทำไม object ถึงเป็น null แล้วก็แค่แปะ null check เข้าไปพร่ำเพรื่อ
    • วิธีแบบนี้มีประโยชน์ในบางกรณี แต่ถ้าทั้งระบบถูกสร้างแบบนี้ การดูแลรักษาจะกลายเป็นฝันร้าย
    • vibe coding ที่อิง AI ให้ความรู้สึกเหมือน เร่ง สไตล์แบบ “ไม่รู้ว่ามันทำงานได้อย่างไร แค่เห็นผลลัพธ์ที่อยากได้บนหน้าจอ”
    • ผมเคยทำงานในบริษัทแบบนี้มาก่อน ที่ซึ่งมีการกลืน exception ทิ้งด้วย null check ทำให้ข้อผิดพลาดถูกฝังเงียบ ๆ
      • ทีมชอบชมตัวเองว่าฉลาด แต่จริง ๆ แล้วระบบมันขับเคลื่อนด้วย โค้ดที่ก๊อบจาก StackOverflow และโครงสร้าง MVP เก่า ๆ
      • ในสภาพแวดล้อมแบบนี้แทบเป็นไปไม่ได้เลยที่จะคิดอย่างอิสระ
      • ถึงอย่างนั้น เครื่องมืออย่าง Claude Code ก็ช่วยเพิ่มผลิตภาพได้มากบน codebase ที่ออกแบบมาดี
    • การก๊อบจาก StackOverflow แล้วหยุดแค่ระดับ “พอทำงานได้ก็พอ” นั่นแหละคือ vibe coding
      • AI แค่ ทำกระบวนการนั้นให้เป็นอัตโนมัติ เท่านั้น
    • แทนที่จะพูดว่า “เห็นในสิ่งที่อยากเห็น” คำที่แม่นกว่าคือ “แสดง อะไรก็ได้ ขึ้นมาบนหน้าจอ”
      • null-check ที่ใส่แบบไม่คิดจะก่อให้เกิด data error แบบละเอียดอ่อน ในภายหลัง ทำให้ตามหาต้นตอได้ยากมาก
    • ผมก็เห็นด้วย แต่ vibe coding ทำให้นักพัฒนาสายพึ่งพา StackOverflow เร็วขึ้นกว่าเดิม
      • นักพัฒนาประเภทที่ไม่แก้ปัญหาด้วยตัวเองจะยิ่งเพิ่มขึ้น
      • แถม ความน่าเชื่อถือก็ต่ำลงกว่าเดิม
    • สิ่งที่น่าอึดอัดที่สุดเวลาใช้ AI คือมันมักตาม สไตล์โค้ดระดับกลาง ๆ ของแต่ละภาษาแบบตรงไปตรงมา
      • ผมยึดหลักว่า “ถ้าไม่สร้างข้อมูลผิด ก็ไม่ต้องมานั่งจัดการทีหลัง” แต่ AI ชอบทำผิดหลักนี้
      • มันแทบไม่ค่อยทำ type definition หรือ รักษา invariant และพยายามจัดการทุกอย่างด้วย string กับ integer
      • เพราะงั้นผมเลยใช้ AI แบบคอยรับ tab-complete เป็นช่วง ๆ แล้วแก้ข้อผิดพลาดเชิงโครงสร้างเอง
      • พอแก้แล้ว AI ก็จะตามทิศทางที่ถูกต้องได้เหมือนกัน ดังนั้นถ้า การผสานกับ IDE และ LSP ดีขึ้น มันน่าจะมีประโยชน์มากขึ้นอีก

  • คำวิจารณ์เรื่อง vibe coding นั้นสมเหตุสมผล แต่จริง ๆ แล้ว ก่อนมี AI คุณภาพโค้ดก็แย่อยู่แล้ว

    • โค้ดส่วนใหญ่ถูกปล่อยขึ้นระบบช้าและคุณภาพก็ต่ำ
    • ถ้าการปล่อยได้เร็วช่วยให้ทดสอบไอเดียได้ไวขึ้น ก็มีคนที่มองว่ายอมรับข้อผิดพลาดได้ระดับหนึ่ง
    • ทุกวันนี้ผู้บริหารมักถามกันมากขึ้นว่า “ฟีเจอร์แค่นี้ทำไมต้องใช้เวลาตั้งหลายเดือน”
    • แต่สาเหตุที่ “ฟีเจอร์เล็ก ๆ ใช้เวลานาน” ไม่ใช่เรื่องอัลกอริทึม แต่เป็นเรื่อง โครงสร้างพื้นฐานและกระบวนการทำงานร่วมกัน
      • AI แก้ปัญหารากฐานพวกนี้ไม่ได้
    • ต้นทุนการดูแลรักษาและความซับซ้อนจะ สะสมแบบดอกเบี้ยทบต้น เมื่อเวลาผ่านไป
      • vibe coding อาจโอเคสำหรับโปรเจกต์ระยะสั้น แต่ไม่เหมาะกับระบบระยะยาว
    • ผมคิดว่าสมดุลระหว่าง นักพัฒนาแบบมีเจตนา กับ นักพัฒนาแบบ vibe สำคัญมาก
      • AI ไปเสริมฝั่ง vibe มากเกินไปจนทำให้สมดุลของระบบเสีย
    • สิ่งที่สำคัญกว่าคุณภาพโค้ดคือ ความเข้าใจร่วมกันระหว่างปัญหาทางธุรกิจกับวิธีแก้ทางเทคนิค
      • ต่อให้คุณภาพต่ำ ก็สำคัญกว่าว่ารู้ชัดไหมว่าทำไปเพราะอะไร และมี trade-off อะไรบ้าง
    • แต่การที่คนซึ่งไม่เข้าใจซอฟต์แวร์มาบอกนักพัฒนาว่า “คุณกำลังทำผิด” นั้นยากจะมองว่าเป็นเรื่องดี

  • คำพูดที่ว่า “โค้ด AI สร้างปัญหามากกว่า 1.7 เท่า” จริง ๆ คือแค่ จำนวนบั๊กที่ถูกค้นพบ

    • ในความเป็นจริงเพราะ PR review มักทำกันไม่ดี ปัญหาในโค้ด AI ก็เลยถูกมองข้ามไปเยอะเหมือนกัน
    • ยังมีงานวิจัยที่บอกว่าการรีวิวโค้ดควรโฟกัสที่ ความเข้าใจและการแชร์โครงสร้าง มากกว่าการหาบั๊ก
    • ในทางกลับกันก็มีความเห็นว่าโค้ด AI มีคอมเมนต์เยอะและอ่านง่ายกว่า เลยกลับถูกรีวิวละเอียดกว่า
      • ส่วนโค้ดที่มนุษย์เขียนมักมีคอมเมนต์แนว “ไม่รู้ว่านี่คืออะไร แต่ถ้าลบแล้วมันพัง” มากกว่า

  • ไม่นานมานี้ใน .NET, Copilot เสนอ การ implement IComparable ให้ผม ทำให้ประหยัดเวลาไปได้ไม่กี่นาที

    • แต่ดันสลับใช้ชื่อตัวแปร x กับ y เลยทำให้ผมต้อง debug อยู่เป็นชั่วโมง
    • ถ้าผมเขียนเองคงไม่พลาดแบบนั้น
    • ถึงอย่างนั้นผลลัพธ์สุดท้ายก็แทบไม่ต่างจากโค้ดที่ผมจะเขียนเอง

  • เมื่อก่อนก็เคยมีสถานการณ์คล้าย ๆ กัน

    • ถ้ามองข้าม error handling และ edge case ก็ปล่อยขึ้นระบบได้เร็วขึ้นมาก แต่สุดท้ายมันก็กลายเป็น ระเบิดบั๊ก
    • AI ให้ความรู้สึกเหมือนกำลังผลักเรื่องนี้ไปจนสุดทาง
    • เลยมีมุกว่า “ถ้าอย่างนั้นก็ย้ายไปใช้ Erlang หรือ Elixir เลยไม่ดีกว่าเหรอ”

  • ผมว่ามันน่าสนใจที่บริษัทสาย LLM ออกมาบอกว่า “AI มั่วน้อยกว่าที่คิด”

    • แต่ Coderabbit เป็นบริษัทรีวิวโค้ดด้วย LLM ดังนั้นยิ่งมีแรงจูงใจจะพูดว่า “AI มั่วมาก เลยต้องใช้ AI มารีวิว AI”
    • ผมเองก็ใช้ Copilot เป็นเครื่องมือรีวิว และ AI review ก็แทบจะแม่นเสมอ จนช่วยได้มากก่อนถึงรอบรีวิวโดยคน

  • ผมใช้ CodeRabbit บ่อย แต่ก็ยังมี false positive อยู่เยอะ

    • บางครั้งทั้งที่เป็นโค้ดที่ตรวจสอบแล้ว มันก็ยังชี้ว่า “ไม่มี data validation”
    • แต่ถึงอย่างนั้น พอเราบอกว่ามัน “ผิด” เครื่องมือก็เรียนรู้และยอมรับสิ่งนั้น

  • “มากกว่า 1.7 เท่า” กับ “เพิ่มขึ้น 1.7 เท่า” ไม่ใช่ความหมายเดียวกัน

    • แต่การเถียงกันเรื่องตัวเลขแบบนี้สุดท้ายก็ให้ความรู้สึกเหมือนเป็น การทะเลาะที่ไร้สาระ

  • Agentic AI coding ก็เป็นแค่เครื่องมือ ถ้าใช้ผิด ผลลัพธ์ผิดก็เป็นเรื่องธรรมดา

    • ถ้าอยากดูกรณีใช้งานที่สำเร็จ ขอแนะนำตัวอย่าง justhtml ของ Python
    • แต่ตรรกะแบบขาวดำที่ว่า “ถ้าใช้ไม่เป็นก็ไร้ความสามารถ” นั้นมีปัญหา
      • ไม่ว่าคุณจะรู้สึกว่า AI มีประโยชน์หรือไม่ สุดท้ายมันก็เป็นแค่ ความต่างของประสบการณ์

  • พาดหัวบทความที่ว่า “โค้ด AI สร้างปัญหามากกว่า 1.7 เท่า” เป็นถ้อยคำที่ไม่แม่นยำ

    • ในความเป็นจริง “ปัญหา” นั้นรวมถึง เรื่อง formatting และ naming ไม่ใช่แค่บั๊ก
    • ส่วนตัวเลขบั๊กจริง ๆ บทความไม่ได้ระบุไว้