1 คะแนน โดย GN⁺ 2026-01-24 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • มีการขอเพิ่มฟีเจอร์ให้ Gemini CLI รู้จัก JetBrains IDE แบบเนทีฟ
  • ปัจจุบัน CLI อนุญาตเฉพาะค่าของ ตัวแปรสภาพแวดล้อมบางตัว (TERM_PROGRAM) เช่น VS Code ทำให้ผู้ใช้ JetBrains ต้องปลอมค่าตัวแปรสภาพแวดล้อมเพื่อเปิดใช้งานฟีเจอร์
  • มีรายงานปัญหา การตรวจจับโปรเซสล้มเหลว บน Windows และ Linux จึงระบุว่าจำเป็นต้องมีการตรวจจับ IDE แบบอิงตัวแปรสภาพแวดล้อม
  • การเปลี่ยนแปลงที่เสนอคือ เพิ่มซีรีส์ JetBrains ลงใน IDE_DEFINITIONS และรวมตรรกะการรู้จำ TERMINAL_EMULATOR=JetBrains-JediTerm
  • นี่เป็นคำขอปรับปรุงสำคัญเพื่อ ขยายขอบเขตการผสานรวม IDE ของ Gemini CLI และปรับปรุงประสบการณ์ผู้ใช้ JetBrains

ข้อเสนอฟีเจอร์ตรวจจับ JetBrains IDE

  • มีการเปิด issue เพื่อขอเพิ่ม ความสามารถในการรู้จักสภาพแวดล้อม JetBrains IDE ให้กับ Gemini CLI
    • เดิมทีค่า TERM_PROGRAM ถูกจำกัดไว้ที่ vscode เป็นต้น ทำให้ฟีเจอร์ไม่ถูกเปิดใช้งานอัตโนมัติใน JetBrains IDE
    • เพื่อหลีกเลี่ยงข้อจำกัดนี้ ผู้ใช้ปลั๊กอินสำหรับ JetBrains ต้อง เลียนแบบตัวแปรสภาพแวดล้อมของ VS Code
  • ข้อเสนอคือ เพิ่มชุด JetBrains IDE ลงใน IDE_DEFINITIONS และ
    ปรับให้รู้จักค่า TERMINAL_EMULATOR=JetBrains-JediTerm ในฐานะ สภาพแวดล้อมที่รองรับอย่างเป็นทางการ

ความจำเป็นและที่มาของปัญหา

  • มีปัญหา ฟีเจอร์ตรวจจับโปรเซสทำงานไม่ถูกต้อง บน Windows และ Linux
    • กรณีที่เกี่ยวข้องสามารถดูได้จากหน้า JetBrains Plugin Review และ issue #9273 ของ Gemini CLI
    • จากฟีดแบ็กของผู้ใช้หลายรายและรายงานทางอีเมล จึงมี ความจำเป็นต่อการใช้ตรรกะตรวจจับแบบอิงตัวแปรสภาพแวดล้อม

การพูดคุยและความเคลื่อนไหวที่เกี่ยวข้อง

  • ข้อเสนอนี้ได้รับแรงบันดาลใจจาก PR #16083 ก่อนหน้านี้

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

 
roxie 2026-02-02

ตอนแรกก็งงอยู่นานว่าคอมเมนต์ Hacker News ที่แปลมาแล้วมันกำลังพูดเรื่องอะไรกันแน่

พอเข้าไปดู PR ในลิงก์อย่างละเอียดก็ได้คำตอบเลยนะ ดูเหมือนว่าจะเป็นประเด็นที่หนักมือไปหน่อยสำหรับ GN+ 555

 
GN⁺ 2026-01-24
ความคิดเห็นจาก Hacker News
  • มีข้อความ "4609 remaining items" อยู่กลางหน้า
    เป็นสถานการณ์ที่บอต gemini-cli สองตัวต่างเข้าใจผิดว่าอีกฝ่ายหนึ่งที่ไม่ใช่ตัวเองเป็นคนเพิ่ม/ลบ label เลยพยายามแก้กลับไปกลับมาจนติดลูปไม่รู้จบ
    รีโปนี้มีผู้มีส่วนร่วมระยะยาวราว 10 คน ถ้าสมมติว่าทุกคนเปิดรับอีเมลแจ้งเตือน ก็เท่ากับว่ามีการส่งอีเมล 46,000 ฉบับ ภายในวันเดียว
    อีกอย่าง เมื่อดูที่ หน้าแอป gemini-cli จะเห็นว่านักพัฒนาเป็นบัญชีส่วนบุคคล จึงดูเหมือนจะไม่ใช่โปรเจกต์ทางการของ Google
    ถ้าอย่างนั้นก็อดสงสัยไม่ได้ว่าใครเป็นคนจ่าย ค่า inference ทั้งหมดนี้

    • เรื่องแบบนี้ไม่ใช่ครั้งแรก เกิดซ้ำค่อนข้างบ่อย และมี issue ที่เกี่ยวข้องหลายรายการ
      #16723, #16725, #16732, #16734
    • เจ้าของรีโปเป็นพนักงาน Google แต่เพื่อความปลอดภัยควรย้ายไปอยู่ใต้ บัญชีองค์กร Google อย่างเป็นทางการ
      ตอนนี้กระบวนการสร้างแอปของ GitHub ยังทำได้จากบัญชีส่วนบุคคลเท่านั้น จึงเกิดปัญหาแบบนี้ขึ้น
      กำลังมีการปรับปรุงให้สมาชิกองค์กรมีสิทธิ์สร้างแอปได้ และวางไว้เป็นงานลำดับความสำคัญภายใน 6 เดือน
      ส่วนเรื่องการชำระเงิน แต่ละองค์กรจะใส่ API key ของตัวเองไว้ใน secrets ของ GitHub Actions เพื่อใช้งาน ดังนั้นค่า inference จึงเป็นภาระของแต่ละองค์กรเอง
    • event-driven agent ตัวแรกที่ฉันทำก็เคยมีบั๊กแบบนี้เหมือนกัน
      บอตรู้ชื่อของตัวเอง แต่ไม่รู้ว่าชื่อนั้นอาจถูกแสดงเป็น user ID ได้ด้วย เลยจำตัวเองไม่เจอ
      ต้องออกแบบ โมเดลการรับรู้ตัวเอง ของเอเจนต์ในการทำความเข้าใจโลกอย่างรอบคอบ
    • เท่ากับมีข้อความ “Thank you for your understanding!” × 4609 ถูกโพสต์ซ้ำอยู่แบบนั้น
    • “ทุกคนได้โปรดอย่ากด Reply-All
      เรื่องแบบนี้ไม่ใช่ปัญหาของบอตอย่างเดียว มนุษย์ก็ติดกับดักนี้กันบ่อย
  • เมื่อก่อนที่บริษัทเรา มี “ผู้เชี่ยวชาญ Salesforce” คนใหม่เข้ามาแล้วสร้างกฎขึ้นมาโดยบอกว่าจะปรับปรุงคิวซัพพอร์ต
    พอทีมซัพพอร์ตได้รับอีเมลใหม่ Salesforce ก็จะสร้าง ticket และพอ ticket ถูก assign ก็จะส่งอีเมลออกไปอีก
    สุดท้ายก็เกิด ลูปการแจ้งเตือนไม่รู้จบ และเจ้าตัวก็ไม่ยอมรับว่าทำพลาด เลยใช้เวลานานมากกว่าจะหาสาเหตุเจอ

    • ฉันก็เคยเจอคล้ายกัน ฝั่ง helpdesk ของลูกค้ากับ helpdesk ของเราเปิดส่งข้อความตอบกลับอัตโนมัติหากันจนเกิด ticket ถล่ม
      ภายในหนึ่งชั่วโมงมี ticket ถูกสร้างขึ้นหลายร้อยใบ
    • ฉันเคยใช้ Salesforce ครั้งหนึ่ง แล้วไม่เข้าใจเลยว่าทำไมใครถึงชอบมัน
      ตอนนั้นรู้สึกว่าเอาไปจัดการใน Excel ยังจะดีกว่า
    • ตอนเป็นนักเรียน ฉันเคยแกล้งตั้งกฎบนเซิร์ฟเวอร์อีเมลแล้วเกิด เหตุการณ์ทำเซิร์ฟเวอร์ทั้งโรงเรียนล่ม
      กฎตอบกลับอัตโนมัติไปเกี่ยวกันเองจนมีอีเมลสะสมเป็นพันฉบับ และสุดท้ายระบบล็อกอินก็ใช้การไม่ได้ไปด้วย
      ฉันถูกห้ามใช้คอมพิวเตอร์ 6 เดือน และหลังจากนั้นฝ่ายไอทีก็คอยเฝ้าหน้าจอฉันแบบเรียลไทม์
      หนึ่งปีต่อมา พอเกิดปัญหาอีกครั้ง ทีมไอทีก็วิ่งมาที่ห้องเรียนแล้วลากฉันออกไป มีเรื่องเล่าแบบนั้นอยู่
    • ประโยคที่ว่า “ใช้เวลาเป็นนิรันดร์กว่าจะหาว่ากฎนั้นซ่อนอยู่ที่ไหน” นี่โดนใจมาก
      Salesforce เป็น ระบบสัตว์ประหลาด จริง ๆ
    • เรื่องพวกนี้ทั้งตลก และในเวลาเดียวกันก็ทำให้รู้สึกแบบ สองจิตสองใจ ว่า “มันเกิดขึ้นได้ยังไง?” แต่ก็ “ก็พอเข้าใจได้อยู่”
  • เมื่อสัปดาห์ก่อนก็มีเหตุการณ์ บอต AI เถียงกับตัวเอง คล้ายกันในรีโปเดียวกันนี้
    มีคนแซวว่า “นี่แหละเหตุผลที่ RAM ราคา 800 ดอลลาร์”

  • ฉันเป็นคนเขียนสคริปต์นี้เอง :-)
    GitHub Action workflow สองตัวชนกัน
    (1) workflow ที่ลบ label need-triage เมื่อเข้าเงื่อนไขบางอย่าง
    (2) workflow ที่จะเพิ่มกลับหากมีผู้ใช้ที่ไม่ใช่ผู้ดูแลโปรเจกต์ลบ label ออก
    ฉันส่งมันขึ้นไปราว 4-5 ทุ่มแล้วก็เข้านอน พอตื่นเช้ามาก็พบว่ามีข้อความถูกสร้างขึ้นหลายพันรายการ
    สาเหตุคือในข้อ (2) ต้องยกเว้น บอตหรือระบบอัตโนมัติอื่น ๆ ด้วย และพอรู้ก็รีบแก้ทันที

    • ท่อนที่ว่า “ส่งตอน 4-5 ทุ่มแล้วไปนอน” นี่ relatable มาก
      โชคดีที่ไม่ได้เกิดความเสียหายใหญ่โต และตอนเห็นครั้งแรกก็ หลุดขำออกมา
  • นี่คือเหตุการณ์ที่ Gemini-cli[bot] ทะเลาะกับตัวเอง พร้อมกับเพิ่มแล้วลบ label ซ้ำไปซ้ำมา มากกว่า 4600 ครั้ง

    • ฉันไม่เสียดายที่เราไม่มีรถบินได้ แต่ผิดหวังกับ ความโง่เขลาแห่งอนาคต แบบนี้
  • ในที่สุดก็มีตัวอย่างที่ AI ทำ งานที่มีประโยชน์
    ถ้าลองคิดว่ามนุษย์ต้องมานั่งติดแล้วถอด label เอง 4500 ครั้งก็น่ากลัวเหมือนกัน

    • ตอนนี้อาชีพ คนติด label บน GitHub ได้หายไปแล้ว
      ถือเป็นการพิสูจน์ประโยชน์ใช้สอยของ AGI ได้เลย (พูดเล่นครึ่งจริงครึ่ง)
  • สงสัยว่าในกรณีนี้ AI เข้ามาเกี่ยวจริงหรือเปล่า
    มันดูเหมือนแค่กฎ automation สองตัวชนกันมากกว่า เป็น บั๊กที่เกิดได้ตั้งแต่ปี 2015

    • น่าขันตรงที่ถึงจะชอบบอกว่า AI ฉลาด แต่ก็ยังไม่รู้จักลูปแบบนี้
      ยัง อีกไกลกว่าจะถึง AGI จริง ๆ แล้วแม้แต่ AI เองก็ยังต้องไปอีกไกล
  • เป็นตัวอย่างของ บั๊ก CI แบบคลาสสิกที่มีกลิ่นอายของ LLM ปนอยู่
    เมื่อไม่กี่สัปดาห์ก่อน ฝั่งเราก็เจออะไรคล้ายกันใน custom merge queue

    • บอกว่าเป็น “บั๊ก CI แบบคลาสสิก” แต่เรื่องบอตมาติดลูปคุยกันเองไม่รู้จบนี่ฉันเพิ่งเคยได้ยิน
      สมัยก่อนตอนทำบอต IRC ขั้นตอนที่สองก็คือ “อย่าให้มันตอบตัวเอง”
      เพราะงั้นนี่เลยดูใกล้เคียงกับ ความผิดพลาดด้านการออกแบบ มากกว่าจะเป็นบั๊ก CI
  • มันดูเหมือน PR แต่จริง ๆ แล้วเป็น issue report
    ตอนแรกฉันยังหา patch ที่แก้ไม่เจอ จนมารู้ว่ารีโปนี้บังคับให้ทุก PR ต้องมี issue ที่เชื่อมโยงอยู่
    แต่คราวนี้ทั้งสองอย่างกลับไม่ได้เชื่อมกันด้วยซ้ำ

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