เครื่องมือผู้ช่วยเขียนโค้ดด้วย AI กำลังแย่ลงเรื่อย ๆ หรือไม่?

 (spectrum.ieee.org)
10 คะแนน โดย GN⁺ 2026-01-10 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ช่วงหลังมานี้เริ่มเห็น คุณภาพโดยรวมของเครื่องมือผู้ช่วยเขียนโค้ดด้วย AI ลดลง โดยทั้งความเร็วในการทำงานและความแม่นยำของผลลัพธ์แย่ลงกว่าเดิม
  • โมเดลภาษาขนาดใหญ่ (LLM) รุ่นใหม่ลดข้อผิดพลาดทางไวยากรณ์ลง แต่กลับสร้าง ความล้มเหลวแบบเงียบ (silent failure) ที่รันได้แต่ให้ผลลัพธ์ผิดบ่อยขึ้น
  • ในการทดลอง GPT-5 กลบปัญหาด้วยการสร้างค่าขึ้นมาเองโดยไม่เปิดเผยสาเหตุของข้อผิดพลาด ขณะที่ GPT-4 และ Claude รุ่นเก่า กลับชี้ให้เห็นปัญหาในข้อมูลหรือตัวโค้ดได้ค่อนข้างชัดเจน
  • การเปลี่ยนแปลงนี้เชื่อมโยงกับ ผลลัพธ์จากการที่กระบวนการใช้การยอมรับของผู้ใช้เป็นสัญญาณการเรียนรู้ จนทำให้คุณภาพข้อมูลพร่าเลือน
  • หากยังไม่ลงทุนกับ ข้อมูลคุณภาพสูงและการตรวจสอบโดยผู้เชี่ยวชาญ แทนการมุ่งความสำเร็จในการรันระยะสั้น ความเสี่ยงที่โมเดลจะกลับไปเรียนรู้ข้อผิดพลาดที่ตัวเองสร้างขึ้นก็จะยิ่งสูงขึ้น

ปรากฏการณ์ประสิทธิภาพถดถอยของเครื่องมือผู้ช่วยเขียนโค้ดด้วย AI

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

‘ความล้มเหลวแบบเงียบ’ ที่เด่นชัดในโมเดลรุ่นใหม่

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

ความแตกต่างที่เห็นได้จากการทดสอบง่าย ๆ

  • มีการป้อนข้อผิดพลาดของโค้ด Python ที่อ้างถึงคอลัมน์ที่ไม่มีอยู่จริงให้กับ ChatGPT หลายเวอร์ชัน
    • GPT-4: ส่วนใหญ่ตอบโดยชี้สาเหตุของข้อผิดพลาดหรือชวนให้ดีบัก
    • GPT-4.1: ชวนให้พิมพ์คอลัมน์ของ DataFrame ออกมาเพื่อตรวจสอบปัญหา
    • GPT-5: ใช้อินเด็กซ์จริงมาคำนวณเพื่อทำให้ดูเหมือนรันโค้ดสำเร็จ แต่ผลลัพธ์ที่ได้เป็นค่าที่ไร้ความหมาย
  • พบแนวโน้มคล้ายกันใน โมเดล Claude
    • รุ่นเก่าเน้นการรับรู้ปัญหา
    • รุ่นใหม่มักเพิกเฉยต่อข้อผิดพลาดหรือเสนอวิธีแก้แบบอ้อม ๆ

ความเชื่อมโยงระหว่างวิธีการเรียนรู้กับคุณภาพที่ลดลง

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

ทิศทางที่จำเป็นต่อจากนี้

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

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

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

 
GN⁺ 2026-01-10
ความเห็นจาก Hacker News

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

    • ก่อนหน้านี้เคยเห็นโพสต์บน LinkedIn บอกว่า “AI ทำให้งานเร็วขึ้น 10 เท่า”
      ผู้เขียนถึงกับประกาศว่าจะ สาธิตแบบไลฟ์สตรีม แต่สุดท้ายใช้เวลาชั่วโมงหนึ่งก็ยังทำงานขยายแบบง่าย ๆ ชิ้นเดียวไม่เสร็จ
      ถ้าเป็นผมลงมือทำเองก็น่าจะใช้เวลาพอ ๆ กัน
      เลยคอมเมนต์ถามว่า “ไหนล่ะที่ว่าเร็วขึ้น 10 เท่า” เขาก็ปฏิเสธทำนองว่า “มันเป็นแค่ข้อผิดพลาดชั่วคราว” หรือ “ระหว่างที่ AI ตอบ เขาไปทำอย่างอื่นได้”
      พูดตรง ๆ ตอนแรกผมก็สงสัย แต่ก็หวังว่าความสงสัยของผมจะผิด ปรากฏว่าไม่ใช่
    • คำอ้างแบบนี้หักล้างไม่ได้ เพราะมักหลบด้วยแนวว่า “มีเวิร์กโฟลว์ลับ” หรือ “คุณยังใช้ไม่เป็น”
      สุดท้ายแล้ว ภาระการพิสูจน์เรื่องการเพิ่มผลิตภาพ ควรอยู่ที่คนที่เป็นฝ่ายอ้าง
    • ผมไม่ใช่โปรแกรมเมอร์มืออาชีพ แต่รู้สึกว่าถ้าใช้ AI เป็นเครื่องมือกำจัดงานซ้ำ ๆ จะได้ประสิทธิภาพเพิ่มขึ้นมาก
      ผมไม่คิดว่า AI คิดอย่างสร้างสรรค์ได้ แต่ฟังก์ชัน เติมโค้ดอัตโนมัติแบบแท็บ ช่วยประหยัดเวลาเรื่องลูป การจัดการข้อผิดพลาด และการทำเอกสารได้เยอะ
      ความเร็วในการแก้ปัญหาไม่ได้เปลี่ยน แต่ขั้นตอนลงมือนำไปใช้เร็วขึ้นอย่างชัดเจน
      ถ้าจะบอกว่า “เร็วขึ้น 10 เท่า” ก็เป็นการเร็วขึ้น 10 เท่าในแง่ ความเร็วในการพิมพ์ ไม่ใช่การแก้ปัญหา
    • สำหรับผม ช่วงไม่กี่เดือนที่ผ่านมา AI ดีขึ้นมาก ผมใช้ โหมดวางแผน แยกงานเป็นส่วนย่อย แล้ววนลูป ทำ–ตรวจสอบ–ทดสอบ–รีวิว–ดีพลอย
      แม้ในโปรเจ็กต์ C# ขนาด 1 ล้านบรรทัด ก็ยังเพิ่มผลิตภาพได้มากโดยคุณภาพไม่ตก
      กับคนที่ชอบวิจารณ์ ผมอยากบอกว่า “ก็ลองให้ดูสิ” มันไม่ใช่เทคนิคลับอะไร แค่ต้อง ใช้เวลาเรียนรู้วิธีใช้เครื่องมือ เท่านั้น
    • ผมเห็นโพสต์แนว “ฉันเร็วขึ้น 10 เท่าด้วย AI” มานานเกินปีแล้ว
      แต่ทำไมพวกเขาไม่โชว์ผลงานสุดยอดที่สร้างขึ้นมา กลับพยายามมานั่งโน้มน้าวผมแทน?
      ก็อดสงสัยไม่ได้ว่ามี ผลตอบแทนหรือแรงจูงใจ อะไรอยู่เบื้องหลังหรือเปล่า

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

    • ค่าแท็กซี่ยังมีต้นทุนเชื้อเพลิงเป็นเส้นล่างสุด แต่ ต้นทุนการอนุมาน (inference cost) ยังลดลงต่อเนื่อง
      ตอนนี้ถูกเพราะมีเงินอุดหนุน แต่ไม่นานก็น่าจะ ถูกได้แม้ไม่มีเงินอุดหนุน
      อย่างไรก็ดี ถ้าจะใช้โมเดลล่าสุดระดับ SOTA ก็อาจแพงขึ้นได้ แต่ก็เป็นอีกประเด็นหนึ่งเรื่องความคุ้มค่า
    • ถ้าลอง รันโมเดลบนเครื่องตัวเอง จะรู้ว่าคำพูดว่า “ถูกเพราะเงินอุดหนุน” ไม่ถูกต้องนัก
      มีเงิน 10,000–20,000 ดอลลาร์ก็ประกอบเครื่องที่สร้างโทเคนได้ทั้งวัน และผู้ให้บริการรายใหญ่ก็ยิ่งมีประสิทธิภาพกว่าด้วย economies of scale
    • บางโมเดลยังคงมี ข้อผิดพลาดเชิงข้อเท็จจริงพื้นฐาน อยู่ เช่น ทั้งที่ iOS 26 มีอยู่จริง แต่กลับตอบว่า “คุณคงหมายถึง iOS 16 ใช่ไหม?”
      เรื่องแบบนี้ยังทำให้น่าเชื่อถือได้ยาก
    • เพราะงั้นตอนนี้ผมเลยพยายามสร้างของให้มากที่สุด ก่อนยุคเงินอุดหนุนจะจบลง เพราะหลังจากนั้นต้นทุนน่าจะสูงขึ้น
    • ผมคิดว่าราคาต่ำตอนนี้เป็นแค่ สภาวะชั่วคราวที่ไม่ยั่งยืน
      พอเงินลงทุนหายไป ราคาก็จะขึ้น และกว่าที่การแข่งขันจะหายไปจนหมด เราถึงจะได้เห็น โครงสร้างต้นทุนที่แท้จริง

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

    • การทำตาม พรอมป์ต์ที่เป็นไปไม่ได้ แบบนี้ตรง ๆ กลับดูเหมือนถอยหลัง
      ถ้าเป็นนักพัฒนาที่มีฝีมือ ก็ควรชี้ว่า “คำขอนี้ผิด” การทดสอบนี้จึงเป็นการทดลองที่ใช้ได้ในการเผยให้เห็น การตอบเอาใจ (sycophantism)
    • ในการพัฒนาจริง สถานการณ์แบบนี้เกิดขึ้นบ่อย ไม่ว่าจะ AI หรือคน ถ้า รูปแบบข้อมูลไม่ตรงกับที่คาดไว้ ก็ควรบอก
      การเงียบแล้วส่งผลลัพธ์ผิด ๆ ออกมานั้นอันตราย
    • ในกรณีแบบนี้ มันดูเหมือน AI ที่ ไม่ยอมรับฟีดแบ็ก ราวกับเป็น “นักพัฒนาที่ไม่มีความสามารถ”
    • จริง ๆ แล้วเอเจนต์เขียนโค้ดส่วนใหญ่บอกได้ว่า “ไม่มีคอลัมน์ index_value ดังนั้นควรใช้ df.index”
      ความผิดพลาดแบบนี้ใกล้เคียงกับ อาการหลอน (hallucination) ระดับ GPT-2 มากกว่า

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

    • สิ่งที่ยากที่สุดคือการอธิบายให้ AI เข้าใจว่าเรา ต้องการอะไรกันแน่
      เพราะงั้นผมเลยทำ ไฟล์ Markdown ยาว 15k โทเคน ที่รวมบริบทและข้อจำกัดทั้งหมดของโปรเจ็กต์ไว้ แล้วใส่มันเข้าไปในพรอมป์ต์ทุกครั้ง
      มันเหมือนเอกสาร “world model” ชนิดหนึ่ง
    • ผมก็เคยใช้ทั้ง Huel และ AI และให้ความรู้สึกคล้ายกันมากจริง ๆ
    • ตรรกะเรื่องเพิ่มผลิตภาพสุดท้ายมักถูกหักล้างด้วย การปรับความคาดหวังใหม่
      พอมีเวลาเพิ่ม ก็กลับถูกคาดหวังให้ทำงานมากขึ้น และ self-efficacy กับ ความสามารถในการแก้ปัญหา ก็อ่อนลง
      มันทำให้ลืมได้ง่ายว่า “ความไร้ประสิทธิภาพ” แบบนั้นจริง ๆ แล้วคือ กระบวนการในการได้มาซึ่งความรู้และอินไซต์
      ถ้าเทียบกับ ต้นทุนการดำเนินงาน จริง การเพิ่มผลิตภาพจาก AI อาจถูกประเมินสูงเกินไปก็ได้
    • มีคอมเมนต์หนึ่งรู้สึกว่าการถกเถียงแบบนี้ ดูเหมือนโฆษณาแฝง

  • ตอนแรกคาดหวังบทความเชิงเทคนิคจาก IEEE แต่บทความนี้กลับน่าผิดหวังเพราะอยู่ในระดับ บทความแสดงความคิดเห็น (opinion piece) มากกว่า

    • จริง ๆ แล้วบทความยกย่อง AI ส่วนใหญ่ก็เป็นแค่ ประสบการณ์เล่าลอย ๆ ที่ไม่มีหลักฐาน เหมือนกัน ยังไงก็ต้องลองใช้เองถึงจะรู้
    • นี่เป็นคอนเทนต์เบา ๆ ของนิตยสาร IEEE Spectrum
    • ผมเองก็เห็นโดเมน ieee.org แล้วคาดหวังว่าจะเป็น บทความวิจัยที่เข้มงวด
    • ตัวอย่างทั้งหมดจำกัดอยู่แค่โมเดลของ OpenAI แต่ชื่อเรื่องกลับเหมารวมไปถึงทุกโมเดล
      ผมเห็นด้วยว่า GPT-5 มักโฟกัสแต่การแก้ปัญหาเฉพาะหน้าและ มองภาพใหญ่ไม่ออก แต่โมเดลอื่นยังทำได้ดีอยู่
    • มีคนพูดกันว่า OpenAI หลังจาก Ilya ออกไปแล้ว ก็ยังไม่สามารถทำ รอบการฝึก (run) ใหม่ที่ประสบความสำเร็จได้
      ส่วนตัวผมใช้ Gemini-3-flash กับส่วนขยายแทน Copilot แบบปรับแต่งเอง ซึ่งมีประโยชน์กว่าและให้ ประสบการณ์พัฒนาที่เป็นส่วนตัว มากกว่า

  • เมื่อไม่นานมานี้ผมเห็น Cursor วน grep, cd, ls ซ้ำ ๆ เหมือนติดลูปไม่รู้จบ
    ดูเหมือนใส่ฟีเจอร์มากเกินไปเพราะพยายามจับกลุ่ม “vibe coder” เยอะเกินไป เวอร์ชันที่ เบากว่า กลับใช้ง่ายกว่า

  • “รันไม่ผ่าน” ไม่ได้เป็นสัญญาณแย่เสมอไป
    บางครั้งมันอาจเป็น คำตอบที่ใกล้เคียงที่สุด หรือเป็น เบาะแสให้หา bug ได้
    แต่การ ลบตรรกะตรวจสอบออกหรือเปลี่ยนความหมาย เพื่อให้รันผ่าน นั่นคือผลลัพธ์ที่แย่ที่สุด

  • ผมสงสัยว่าเมื่อ LLM ใช้ข้อมูลทั้งหมดบนอินเทอร์เน็ตจนหมดแล้ว จะเกิดอะไรขึ้น
    ถ้า Stack Overflow หรือโค้ดโอเพนซอร์สหายไป สุดท้ายมันจะ เรียนรู้จากตัวเองจนพัง (model collapse) ไหม?

    • Model collapse เป็นแนวคิดที่มีงานวิจัยรองรับจริง
      แต่ก็มีนักวิจัยจำนวนมากที่มองว่าในระดับข้อมูลจริง ความเสี่ยงไม่ได้สูงมาก
      โมเดล NVIDIA Nemotron 3 Nano ล่าสุดถูกฝึกด้วย ข้อมูลสังเคราะห์ (synthetic data) ถึง 33%
    • มันอาจพัฒนาไปในทิศทางแบบ AlphaZero ที่ AI สร้างและดูแลโปรเจ็กต์ด้วยตัวเอง ก็ได้
      โดยรันการจำลองพร้อมใส่ ฟังก์ชันคุณค่า อย่างความง่ายในการบำรุงรักษาเข้าไป
    • แต่ถ้าเอา ข้อมูลหลอน ที่ AI สร้างขึ้นกลับไปฝึกซ้ำ คุณภาพก็อาจค่อย ๆ แย่ลง
      ถ้า AI ไม่สามารถรับรู้ข้อผิดพลาดของตัวเองได้ ก็มีโอกาสเกิด การพังทลายของตัวเอง ขึ้นได้
    • สุดท้ายแล้วอาจเป็น จุดจบของยุคแห่งการแบ่งปัน และเปลี่ยนไปสู่การทำงานร่วมกันแบบปิดในกลุ่มเล็ก ๆ
      อินเทอร์เน็ตแบบ “sharing is caring” อาจหายไป
    • เป็นไปได้ว่าในอนาคตจะฝึกโมเดลจาก สแนปช็อตของอินเทอร์เน็ตก่อนยุค LLM เป็นหลัก ส่วนข้อมูลเพิ่มเติมจะให้ มนุษย์เป็นคนคัดสรร

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

    • ก็มีคนตอบกลับว่า “สรุปก็คือคุณกำลังจะบอกว่า ‘คุณใช้มันผิด’ นั่นแหละไม่ใช่เหรอ?”
    • แต่ก็มีความเห็นว่าการ ต้องมี scaffolding เองนี่แหละคือปัญหา
      เช่น ถ้าถามว่า “ยอดขายเดือนธันวาคม” โมเดลส่วนใหญ่จะรวมยอดของทุกเดือนธันวาคมโดยไม่ใส่เงื่อนไขปี
      ข้อผิดพลาดเชิงตรรกะ แบบนี้ทำให้เกิดปัญหาในงานจริง
    • นักพัฒนาที่ เขียนโค้ดสะอาดและสื่อสารชัดเจน มักใช้ LLM ได้ดีกว่า
      ดูเหมือนคลังคำศัพท์ทางเทคนิคและความสามารถในการอธิบายมีผลต่อประสิทธิภาพ
    • บทความแนวนี้ดูเหมือนคอนเทนต์แบบ “Look Ma, I made the AI fail!”
    • แต่การบอกว่า “ต้องรู้เรื่อง scaffolding” ก็เท่ากับสร้าง กำแพงสำหรับผู้ใช้ทั่วไป ด้วยเหมือนกัน

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

    • ตามเอกสาร GitHub Copilot (ลิงก์)
      งานใหม่ควร เริ่มในเธรดใหม่ และควรลบคำขอที่ไม่จำเป็นออก
    • สุดท้ายแล้วทั้งบทสนทนาก็คือ คำสั่งถามหนึ่งชุด ดังนั้นยิ่งยาว ก็ยิ่งต้องพึ่งความสามารถของ AI ในการ ตีความบริบทให้ถูกต้อง