- Yêu cầu bổ sung tính năng để nhận diện JetBrains IDE theo cách native trong Gemini CLI
- Hiện tại CLI chỉ chấp nhận giá trị của một số biến môi trường cụ thể (TERM_PROGRAM) như VS Code, nên người dùng JetBrains phải giả lập biến môi trường để kích hoạt tính năng
- Đã có báo cáo về vấn đề thất bại khi phát hiện tiến trình trên Windows và Linux, vì vậy tài liệu nêu rõ sự cần thiết của cơ chế phát hiện IDE dựa trên biến môi trường
- Thay đổi được đề xuất bao gồm bổ sung dòng JetBrains vào IDE_DEFINITIONS và thêm logic nhận diện
TERMINAL_EMULATOR=JetBrains-JediTerm
- Đây là một đề xuất cải tiến quan trọng nhằm mở rộng phạm vi tích hợp IDE của Gemini CLI và cải thiện trải nghiệm cho người dùng JetBrains
Đề xuất tính năng phát hiện JetBrains IDE
- Đã có issue được tạo để yêu cầu Gemini CLI thêm khả năng nhận diện môi trường JetBrains IDE
- Trước đây, giá trị
TERM_PROGRAM chỉ được giới hạn ở vscode và một số giá trị tương tự, nên trong JetBrains IDE tính năng không được tự động kích hoạt
- Để lách giới hạn này, người dùng plugin cho JetBrains đã phải mô phỏng biến môi trường của VS Code
- Nội dung đề xuất là thêm dòng JetBrains IDE vào IDE_DEFINITIONS và
sửa để giá trị TERMINAL_EMULATOR=JetBrains-JediTerm được nhận diện là môi trường được hỗ trợ chính thức
Tính cần thiết và bối cảnh vấn đề
- Có vấn đề khiến chức năng phát hiện tiến trình không hoạt động bình thường trên môi trường Windows và Linux
- Các trường hợp liên quan có thể được xác nhận tại trang JetBrains Plugin Review và issue #9273 của Gemini CLI
- Thông qua nhiều phản hồi của người dùng và báo cáo qua email, đã cho thấy sự cần thiết của logic phát hiện dựa trên biến môi trường
Thảo luận và hoạt động liên quan
- Đề xuất này được lấy cảm hứng từ PR #16083 trước đó
2 bình luận
Tôi đã ngơ ngác khá lâu không hiểu rốt cuộc các bình luận Hacker News được dịch đang nói gì,
nhưng khi nhìn kỹ PR trong liên kết thì cuối cùng cũng có câu trả lời. Có vẻ đây là một vấn đề hơi quá sức với GN+ thôi haha
Ý kiến trên Hacker News
Có một dòng ở giữa trang ghi “4609 remaining items”
Đây là tình huống hai bot gemini-cli đều nhầm rằng bên kia chứ không phải mình đã thêm/xóa nhãn, rồi cố sửa qua lại và rơi vào vòng lặp vô hạn
Kho lưu trữ này có khoảng 10 người đóng góp lâu năm, và nếu giả định tất cả đều nhận thông báo email thì chỉ trong một ngày đã có 46.000 email được gửi đi
Ngoài ra, nhìn vào trang ứng dụng gemini-cli thì nhà phát triển hiển thị là một tài khoản cá nhân, nên có vẻ đây không phải dự án chính thức của Google
Vậy thì lại nảy ra câu hỏi là ai đã trả toàn bộ chi phí inference này
#16723, #16725, #16732, #16734
Quy trình tạo app trên GitHub hiện chỉ cho phép làm bằng tài khoản cá nhân nên mới phát sinh kiểu vấn đề này
Hiện đang có cải tiến để có thể cấp quyền tạo app cho thành viên tổ chức, và dự kiến sẽ được ưu tiên xử lý trong vòng 6 tháng
Về phần thanh toán, mỗi tổ chức tự đưa API key của mình vào secrets của GitHub Actions để dùng, nên chi phí inference do từng tổ chức tự chi trả
Bot biết tên của chính nó, nhưng lại không biết rằng tên đó cũng có thể xuất hiện dưới dạng user ID, nên không nhận ra chính mình
Cần phải thiết kế thật cẩn thận mô hình tự nhận thức của agent về thế giới
Đây không chỉ là vấn đề của bot, con người cũng rất hay sập bẫy này
Trước đây ở công ty tôi có một “chuyên gia Salesforce” mới vào, người này tạo ra một quy tắc để cải thiện hàng đợi hỗ trợ
Khi đội hỗ trợ nhận email mới thì Salesforce tạo ticket, rồi khi ticket được phân công thì lại gửi email tiếp
Kết quả là xuất hiện một vòng lặp thông báo vô hạn, và vì anh ta không chịu thừa nhận sai lầm nên phải mất rất lâu mới tìm ra nguyên nhân
Chỉ trong một giờ đã có hàng trăm ticket được tạo ra
Cảm giác còn thà quản lý bằng Excel còn hơn
Các rule trả lời tự động mắc vào nhau, hàng nghìn email chồng chất lên, cuối cùng cả hệ thống đăng nhập cũng tê liệt
Tôi bị cấm dùng máy tính trong 6 tháng, và sau đó phòng IT còn giám sát màn hình của tôi theo thời gian thực
Một năm sau lại có sự cố, đội IT chạy thẳng vào lớp học và lôi tôi đi
Salesforce đúng là một hệ thống quái vật
Ngay tuần trước cũng có một vụ AI bot tự cãi nhau tương tự trong chính kho lưu trữ này
Có người đùa rằng “đó là lý do RAM có giá 800 đô”
Tôi là tác giả của script này :-)
Hai workflow GitHub Action đã xung đột với nhau
(1) workflow xóa nhãn need-triage trong một số điều kiện nhất định
(2) workflow tự thêm lại nhãn nếu người xóa không phải là project manager
Tôi nộp lúc khoảng 10–11 giờ đêm rồi đi ngủ, sáng dậy thì thấy hàng nghìn tin nhắn đã được tạo ra
Nguyên nhân là ở (2), các bot hoặc automation khác cũng phải được đưa vào diện ngoại lệ, và tôi đã sửa ngay khi nhận ra
May là không có thiệt hại lớn nào, và lúc nhìn thấy lần đầu thì tôi đã bật cười
Đây là vụ Gemini-cli[bot] tự đánh nhau, thêm rồi xóa nhãn hơn 4600 lần
Cuối cùng cũng có một ví dụ AI làm được việc hữu ích
Nghĩ đến cảnh con người phải tự tay thêm rồi xóa nhãn 4500 lần thì thật kinh khủng
Tính thực dụng của AGI vậy là đã được chứng minh rồi (nửa đùa nửa thật)
Tôi thắc mắc không biết ở đây AI có thực sự can thiệp hay không
Trông giống đơn giản là hai quy tắc automation xung đột với nhau hơn. Có vẻ là một lỗi mà năm 2015 cũng có thể xảy ra
AGI vẫn còn xa lắm, thật ra bản thân AI cũng còn cả một chặng đường dài
Đây là một lỗi CI điển hình có thêm chút mùi vị của LLM
Bên tôi vài tuần trước cũng gặp chuyện tương tự với custom merge queue
Hồi xưa khi làm bot IRC, bước thứ hai luôn là “đừng để nó trả lời chính nó”
Vì vậy cái này giống lỗi thiết kế hơn là lỗi CI
Nhìn thì giống PR nhưng thật ra đây là issue report
Tôi còn đi tìm patch sửa ở đâu, hóa ra kho này yêu cầu mọi PR đều phải có issue liên kết
Nhưng lần này thì hai bên thậm chí còn không liên kết với nhau
Có cảm giác chẳng bao lâu nữa những chuyện như thế này sẽ xảy ra cả trong trợ cấp an sinh xã hội, kế hoạch điều trị ung thư, logistics hàng không, cấu hình định tuyến ISP
Sắp tới chắc đúng là một thời đại rất thú vị