- มีการขอเพิ่มฟีเจอร์ให้ 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 ความคิดเห็น
ตอนแรกก็งงอยู่นานว่าคอมเมนต์ Hacker News ที่แปลมาแล้วมันกำลังพูดเรื่องอะไรกันแน่
พอเข้าไปดู PR ในลิงก์อย่างละเอียดก็ได้คำตอบเลยนะ ดูเหมือนว่าจะเป็นประเด็นที่หนักมือไปหน่อยสำหรับ GN+ 555
ความคิดเห็นจาก Hacker News
มีข้อความ "4609 remaining items" อยู่กลางหน้า
เป็นสถานการณ์ที่บอต gemini-cli สองตัวต่างเข้าใจผิดว่าอีกฝ่ายหนึ่งที่ไม่ใช่ตัวเองเป็นคนเพิ่ม/ลบ label เลยพยายามแก้กลับไปกลับมาจนติดลูปไม่รู้จบ
รีโปนี้มีผู้มีส่วนร่วมระยะยาวราว 10 คน ถ้าสมมติว่าทุกคนเปิดรับอีเมลแจ้งเตือน ก็เท่ากับว่ามีการส่งอีเมล 46,000 ฉบับ ภายในวันเดียว
อีกอย่าง เมื่อดูที่ หน้าแอป gemini-cli จะเห็นว่านักพัฒนาเป็นบัญชีส่วนบุคคล จึงดูเหมือนจะไม่ใช่โปรเจกต์ทางการของ Google
ถ้าอย่างนั้นก็อดสงสัยไม่ได้ว่าใครเป็นคนจ่าย ค่า inference ทั้งหมดนี้
#16723, #16725, #16732, #16734
ตอนนี้กระบวนการสร้างแอปของ GitHub ยังทำได้จากบัญชีส่วนบุคคลเท่านั้น จึงเกิดปัญหาแบบนี้ขึ้น
กำลังมีการปรับปรุงให้สมาชิกองค์กรมีสิทธิ์สร้างแอปได้ และวางไว้เป็นงานลำดับความสำคัญภายใน 6 เดือน
ส่วนเรื่องการชำระเงิน แต่ละองค์กรจะใส่ API key ของตัวเองไว้ใน secrets ของ GitHub Actions เพื่อใช้งาน ดังนั้นค่า inference จึงเป็นภาระของแต่ละองค์กรเอง
บอตรู้ชื่อของตัวเอง แต่ไม่รู้ว่าชื่อนั้นอาจถูกแสดงเป็น user ID ได้ด้วย เลยจำตัวเองไม่เจอ
ต้องออกแบบ โมเดลการรับรู้ตัวเอง ของเอเจนต์ในการทำความเข้าใจโลกอย่างรอบคอบ
เรื่องแบบนี้ไม่ใช่ปัญหาของบอตอย่างเดียว มนุษย์ก็ติดกับดักนี้กันบ่อย
เมื่อก่อนที่บริษัทเรา มี “ผู้เชี่ยวชาญ Salesforce” คนใหม่เข้ามาแล้วสร้างกฎขึ้นมาโดยบอกว่าจะปรับปรุงคิวซัพพอร์ต
พอทีมซัพพอร์ตได้รับอีเมลใหม่ Salesforce ก็จะสร้าง ticket และพอ ticket ถูก assign ก็จะส่งอีเมลออกไปอีก
สุดท้ายก็เกิด ลูปการแจ้งเตือนไม่รู้จบ และเจ้าตัวก็ไม่ยอมรับว่าทำพลาด เลยใช้เวลานานมากกว่าจะหาสาเหตุเจอ
ภายในหนึ่งชั่วโมงมี ticket ถูกสร้างขึ้นหลายร้อยใบ
ตอนนั้นรู้สึกว่าเอาไปจัดการใน Excel ยังจะดีกว่า
กฎตอบกลับอัตโนมัติไปเกี่ยวกันเองจนมีอีเมลสะสมเป็นพันฉบับ และสุดท้ายระบบล็อกอินก็ใช้การไม่ได้ไปด้วย
ฉันถูกห้ามใช้คอมพิวเตอร์ 6 เดือน และหลังจากนั้นฝ่ายไอทีก็คอยเฝ้าหน้าจอฉันแบบเรียลไทม์
หนึ่งปีต่อมา พอเกิดปัญหาอีกครั้ง ทีมไอทีก็วิ่งมาที่ห้องเรียนแล้วลากฉันออกไป มีเรื่องเล่าแบบนั้นอยู่
Salesforce เป็น ระบบสัตว์ประหลาด จริง ๆ
เมื่อสัปดาห์ก่อนก็มีเหตุการณ์ บอต AI เถียงกับตัวเอง คล้ายกันในรีโปเดียวกันนี้
มีคนแซวว่า “นี่แหละเหตุผลที่ RAM ราคา 800 ดอลลาร์”
ฉันเป็นคนเขียนสคริปต์นี้เอง :-)
GitHub Action workflow สองตัวชนกัน
(1) workflow ที่ลบ label need-triage เมื่อเข้าเงื่อนไขบางอย่าง
(2) workflow ที่จะเพิ่มกลับหากมีผู้ใช้ที่ไม่ใช่ผู้ดูแลโปรเจกต์ลบ label ออก
ฉันส่งมันขึ้นไปราว 4-5 ทุ่มแล้วก็เข้านอน พอตื่นเช้ามาก็พบว่ามีข้อความถูกสร้างขึ้นหลายพันรายการ
สาเหตุคือในข้อ (2) ต้องยกเว้น บอตหรือระบบอัตโนมัติอื่น ๆ ด้วย และพอรู้ก็รีบแก้ทันที
โชคดีที่ไม่ได้เกิดความเสียหายใหญ่โต และตอนเห็นครั้งแรกก็ หลุดขำออกมา
นี่คือเหตุการณ์ที่ Gemini-cli[bot] ทะเลาะกับตัวเอง พร้อมกับเพิ่มแล้วลบ label ซ้ำไปซ้ำมา มากกว่า 4600 ครั้ง
ในที่สุดก็มีตัวอย่างที่ AI ทำ งานที่มีประโยชน์
ถ้าลองคิดว่ามนุษย์ต้องมานั่งติดแล้วถอด label เอง 4500 ครั้งก็น่ากลัวเหมือนกัน
ถือเป็นการพิสูจน์ประโยชน์ใช้สอยของ AGI ได้เลย (พูดเล่นครึ่งจริงครึ่ง)
สงสัยว่าในกรณีนี้ AI เข้ามาเกี่ยวจริงหรือเปล่า
มันดูเหมือนแค่กฎ automation สองตัวชนกันมากกว่า เป็น บั๊กที่เกิดได้ตั้งแต่ปี 2015
ยัง อีกไกลกว่าจะถึง AGI จริง ๆ แล้วแม้แต่ AI เองก็ยังต้องไปอีกไกล
เป็นตัวอย่างของ บั๊ก CI แบบคลาสสิกที่มีกลิ่นอายของ LLM ปนอยู่
เมื่อไม่กี่สัปดาห์ก่อน ฝั่งเราก็เจออะไรคล้ายกันใน custom merge queue
สมัยก่อนตอนทำบอต IRC ขั้นตอนที่สองก็คือ “อย่าให้มันตอบตัวเอง”
เพราะงั้นนี่เลยดูใกล้เคียงกับ ความผิดพลาดด้านการออกแบบ มากกว่าจะเป็นบั๊ก CI
มันดูเหมือน PR แต่จริง ๆ แล้วเป็น issue report
ตอนแรกฉันยังหา patch ที่แก้ไม่เจอ จนมารู้ว่ารีโปนี้บังคับให้ทุก PR ต้องมี issue ที่เชื่อมโยงอยู่
แต่คราวนี้ทั้งสองอย่างกลับไม่ได้เชื่อมกันด้วยซ้ำ
ดูเหมือนว่าอีกไม่นานเรื่องแบบนี้จะเกิดในระบบอย่าง เงินประกันสังคม, แผนการรักษามะเร็ง, โลจิสติกส์การบิน, การตั้งค่า routing ของ ISP ด้วย
ยุคสมัยที่กำลังจะมาถึงคง น่าตื่นเต้นมาก