เปิดตัว Gemini CLI GitHub Actions
(blog.google)- Google เปิดตัว Gemini CLI GitHub Actions ที่พัฒนาจาก Gemini CLI เพื่อรองรับการทำงานร่วมกันเป็นทีมใน GitHub repository
- Gemini CLI คือ AI agent แบบโอเพ่นซอร์สที่ช่วยใช้ความสามารถ AI จากเทอร์มินัลได้
- รุ่น GitHub Actions นี้ออกแบบมาเพื่อสภาพแวดล้อมการทำงานร่วมกันเป็นทีม คิดได้ว่าเป็น AI colleague ที่อยู่ใน Repo
- เครื่องมือนี้ถูกเผยแพร่แบบฟรีและโอเพ่นซอร์ส และขณะนี้เปิดให้ใช้งานทั่วโลกในสถานะ เบต้า
- ทำงานอัตโนมัติแบบอะซิงโครนัสตามเหตุการณ์ต่าง ๆ ที่เกิดขึ้นใน GitHub repository (เช่น การเปิด issue ใหม่, การสร้าง PR) และดำเนินการอัตโนมัติโดยทำความเข้าใจ บริบททั้งหมด ของโปรเจกต์
- มีการให้ workflow โอเพ่นซอร์สที่ทรงพลัง 3 รายการ
- การคัดกรอง issue อัจฉริยะ (Intelligent issue triage)
- วิเคราะห์ issue ใหม่และกำหนดป้ายและลำดับความสำคัญโดยอัตโนมัติ
- ช่วยให้ผู้พัฒนามีสมาธิกับงานสำคัญ
- การรีวิว PR อย่างรวดเร็ว (Accelerated pull request reviews)
- ให้ข้อเสนอแนะอย่างทันทีและลึกซึ้งเกี่ยวกับการเปลี่ยนแปลงโค้ด
- ตรวจสอบคุณภาพโค้ด สไตล์ และความถูกต้อง เพื่อลดภาระของผู้รีวิว
- การร่วมมือแบบกดขอได้ตามต้องการ (On-demand collaboration)
- สามารถมอบหมายงานได้โดย mention
@gemini-cliใน issue หรือ PR - ตัวอย่าง: "เขียนการทดสอบสำหรับบั๊กนี้", "นำข้อเสนอข้างต้นไปใช้งาน", "ระดมสมองหาทางแก้ทางเลือก", "แก้ไขบั๊กที่นิยามไว้อย่างชัดเจน"
- สามารถมอบหมายงานได้โดย mention
- การคัดกรอง issue อัจฉริยะ (Intelligent issue triage)
- มอง workflow เหล่านี้เป็น launchpad และเนื่องจากเป็นโอเพ่นซอร์ส จึงสามารถสร้าง workflow ของคุณเองได้
- ช่วยอัตโนมัติการทำงานที่เกิดซ้ำและใช้เวลามาก ยกระดับ ประสิทธิภาพการพัฒนา และเพิ่มประสิทธิภาพการตรวจสอบโค้ดและการจัดการ issue เพื่อเร่งความเร็วของการทำงานร่วมกันเป็นทีม
1 ความคิดเห็น
ความคิดเห็นบน Hacker News
สถานการณ์ตอนนี้สับสนมากจนแยกไม่ออกว่าเป็น CLI, GitHub Action, หรือ GitHub Application เดิมที Jules เคยถูกเรียกว่า “coding agent” แต่ตอนนี้ไม่แน่ใจว่ามีเครื่องมืออีกตัวมาทดแทนบทบาทนั้นหรือไม่ หรือเป็นกรณีที่ Google ทำเหมือน self-cannibalization ของตัวเอง รู้สึกว่าบริษัทควรมีผู้นำที่มีวิสัยทัศน์ชัดเจนกว่านี้ ผมทำงานเขียนโค้ด Android มา 13 ปี ทำงานร่วมกับ Google เคยเป็นผู้นำในชุมชน Google Developer และการประชุมต่างๆ สื่อสารกับ GDE หลายคน และยังใช้งาน Gemini API ในโปรดักต์ของตัวเองอยู่ด้วย แต่ก็ยังเข้าใจไม่ออกว่ามันคืออะไร ในมุมลูกค้าโดยทั่วไปคงเข้าใจได้ยากมาก มี SDK เชื่อม Gemini API ถึง 2 ตัว และเอกสารกระจายอยู่มาก ทำให้ถ้าจะทำฟีเจอร์ใดฟีเจอร์หนึ่งต้องค้นหาข้อมูลเองและค่อยไล่ดู repo โค้ด ฟีเจอร์ที่ต้องการส่วนใหญ่ถูกจำกัดด้วย rate limit หรือเปิดให้เฉพาะเทสเตอร์แบบ private เท่านั้น coding agent ก็มีถึง 3 ตัว แม้จะมีสิทธิ์เข้าถึงบัญชี Google และข้อมูลโทรศัพท์แล้ว แต่ Gemini app ก็แทบไร้ประโยชน์ แม้แต่งานพื้นฐานใน Google Cloud อย่างการเพิ่ม service account ก็ยังสับสนเพราะ UX อย่างเดียวที่ค่อนข้างใช้งานได้คือ AI Studio ที่ทดลองโมเดลได้หลากหลาย และ DX การออก Gemini API key ก็ดีขึ้น โดยตรงๆ แล้ว งานเปิดตัวครั้งนี้คงลำบาก และเป็นแค่สินค้าใหมระดับ “กลางๆ” เท่านั้น
รู้สึกว่าควรมีกลุ่มแบ่งแยกระหว่างวัฒนธรรมงานวิจัยกับวัฒนธรรมซอฟต์แวร์อย่างชัดเจน ในสภาพแวดล้อมวิจัยที่หลายทีมทำการทดลองพร้อมกัน ความยุ่งเหยิงอาจมีผลเชิงบวกได้ แต่ซอฟต์แวร์และโปรดักต์ที่ลูกค้าเจอจริงต้องการแนวทางที่ต่างกัน
Google ดูเหมือนสร้างพื้นที่ “incubating” หลายที่ และถ้าบางตัวประสบความสำเร็จ มันกลับไม่ค่อยผสานเข้ากับโปรดักต์เดิมได้อย่างเป็นธรรมชาติ ทำให้ผู้ใช้สับสน มีตัวอย่างอย่าง NotebookLLM ด้วย แต่ส่วนตัวผมคิดว่าการทดลองหลากหลายแบบนี้ดีกว่า ทีม NotebookLLM ก็มีบรรยากาศที่ทำงานอย่างอิสระ
สิ่งที่ตลกที่สุดคือ มีสิทธิ์เข้าถึงบัญชี Google และข้อมูลโทรศัพท์แล้ว แต่ Gemini app กลับทำอะไรไม่ได้ เปิดแอปแล้วทักว่า “Hello, Vasco” แต่พอถามว่า “ชื่อฉันคืออะไร?” ก็ตอบว่า “ไม่สามารถเข้าถึงข้อมูลผู้ใช้ได้” รู้ว่าทำไม แต่เป็นสถานการณ์ที่ตลกมาก
Jules ทำงานแบบ asynchronous ใน VM และทำงานจากการ checkout โค้ดแยกต่างหาก Gemini CLI ทำงานแบบ synchronous กับผู้ใช้บน local (ยกเว้นโหมด YOLO) ทั้งสองอย่างต่างกันแบบสุดขั้ว
กรณี Google Workspace ก็ต่างกันอีกแบบ การเปิดใช้งาน Gemini CLI ทั่วทั้งองค์กรคือกิจกรรมที่มีทั้งความสนุกและความหงุดหงิดปะปนกัน คำอธิบายแบบละเอียด
ผมเข้าใจว่าบริษัทเห็นว่าจำเป็นต้องแข่งขัน coding AI แต่มีจุดแปลกหลายอย่าง
Gemini ยังจองตารางปฏิทินแบบง่าย ๆ ไม่ได้ เช่น นัดประชุม
ใน Google Docs แก้ไขร่วมกันไม่ได้ ทำได้แค่มาแทรกข้อมูล
ไม่มี MCP ที่ใช้ควบคุม Docs และ Sheets แบบรวมศูนย์
การช่วยเรื่องสูตรใน Sheet กลับยังทำได้แย่กว่า Google Search ทั้งที่มีโดเมนเฉพาะแบบนี้เยอะมาก แต่มันยังไม่โดดเด่นในฐานะ AI เมื่อก่อนเคยค้นหาใน Gmail ด้วยคำว่า "remarkable" แบบตรง ๆ แต่ผลลัพธ์ก็มาเจอคำที่เกี่ยวข้องแบบ "amazing" ด้วย การค้นหาของทุกโปรดักต์เหมือนแย่ลง ทำให้รู้สึกอึดอัด
ผมมีประสบการณ์จริงบน Android: เมื่อเห็นอีเมลยืนยันการจัดส่งแล้วกดปุ่ม power ค้าง ไฟล์ pop-up ของ Gemini ขึ้นมา ดึง screen context ขึ้นมาแล้วพูดว่า “ใส่สิ่งนี้ลงปฏิทินของฉัน” มันก็เพิ่มตารางเวลาให้ ไม่ได้ทำงานได้สมบูรณ์เสมอไป (เช่น ครอบคลุมหลายวันหรือข้อมูล location ผิดพลาด ทำให้หายไปบ้าง) แต่ค่อย ๆ ดีขึ้น หากเป็นลูกค้า Google Workspace จะมีการเชื่อมต่อ Gemini web app กับ Calendar และ Drive ด้วย ทำงานต่าง ๆ ได้มากมาย เช่น สรุปเอกสาร ดังนั้นประโยค “ไม่สามารถสร้างตารางได้” จึงไม่ใช่ข้อเท็จจริง
ผมคิดว่าความไม่ปล่อย Gemini ออกมาในเอกสารโดยตรงของ Google คล้ายกับเหตุผลที่ Apple ยังไม่ปล่อย AI ออกมาตามลึกบน iPhone ความน่าเชื่อถือยังไม่ถึงระดับที่พร้อมปล่อยให้ 99.99% คนทั่วไปได้ใช้งาน เหมาะกับเทคโนโลยีผู้รับแนวคิด (early adopter) เท่านั้น และไม่อยากแนะนำให้คนทั่วไป
มีการใช้งานเชิงปฏิบัติที่หลากหลายและมีประโยชน์มากมาย แต่การตลาดยังขาด ตัวอย่างเช่น ถ่ายรูปรายการช็อปปิ้งแล้วขอให้ Gemini แปลงเป็นรูปแบบที่คัดลอกไปวางได้ มันแค่ย้ายลง Google Keep เท่านั้น ไม่ได้จัดหมวดหมู่ให้ ถ้าทีมให้ความสำคัญและแก้ไขตรงนี้นิดหนึ่งคงมีประโยชน์มากขึ้น OpenAI ทำการตลาดฟังก์ชันบน TikTok เยอะมาก แต่คนอายุต่ำกว่า 30 ปีจำนวนไม่น้อยยังไม่รู้จัก Gemini เลย ส่วนตัวผมรู้สึกว่า Gemini ใช้งานได้จริงกว่า ChatGPT แต่การตลาดยังขาดอย่างชัดเจน
การรองรับ Google Docs มีข้อจำกัดมาก จนแทบไม่คาดหวังอะไร
การค้นหาดูเหมือนเปลี่ยนมาใช้เฉพาะ embedding จนใช้งานไม่ดี ในความเป็นจริงต้องใช้การค้นหาแบบ hybrid ที่ผสม embedding, text matching, และ quality vector เข้าด้วยกัน ซึ่งสร้างให้ scalable อย่างรวดเร็วค่อนข้างไม่ง่าย ถ้ามีระบบแบบนี้ รบกวนแชร์หน่อย
ต้องใช้เวลาเยอะมากในการจับให้ได้ว่าบริการนี้คืออะไรจริง เมื่อคัดข้อความโฆษณา คำอธิบายที่ยืดยาว และคำศัพท์ที่ไม่จำเป็นออกก็ถึงจะเห็นตัวตนจริง ในความเข้าใจของผม นี่คือ GitHub Action เป็น wrapper ที่ใส่ในไฟล์ GitHub workflow YAML เพื่อรัน Gemini CLI ส่ง prompt, repo context และข้อมูลอีเวนต์อย่าง issue หรือ PR diff เข้าไปเพื่อให้ตอบสนองหรือทำงานแทน ผ่าน token หรือแอปสามารถอ่าน/เขียนข้อมูล repo ผ่าน GitHub API ได้ (เช่น เพิ่ม label, แสดงความคิดเห็น, เสนอ code ฯลฯ) ใช้รูปแบบการเรียก Gemini LLM HTTPS API endpoint มาตรฐาน
มีคลิปที่ Boris Cherny กับ Catherine Wu พูดถึง semantic linting ของ AI-based CLI ในพอดแคสต์ Latent Space วิดีโอสัมภาษณ์ที่เกี่ยวข้อง ผมยังไม่เคยใช้ AI-based CLI ใน CI/CD อย่างจริงจัง แต่การทำงานแบบ semantically pass/fail น่าตื่นเต้นมาก
เอกสารบอกว่าให้ “ใช้ที่ chat interface” แต่ยังสงสัยว่าคืออะไร
Gemini plan (เช่น Google One, Workspace เป็นต้น) ใช้ได้เฉพาะโปรดักต์แบบเว็บ ส่วนของ API อย่าง Gemini CLI ไม่รวมอยู่ ถ้า Google ทำ plan รายเดือนสำหรับนักพัฒนาหนึ่งแบบ แล้วให้ใช้ได้ทั้ง CLI, github action, Gemini chat, Jules ก็จะเป็นนวัตกรรมจริงๆ ผมโหยหาระบบ subscription แบบ single-max แบบเดียวกับ Claude มานาน
ต้องใช้ AI ช่วยทำความเข้าใจโครงสร้าง subscription เอง
ชั้นฟรีของ Gemini ทำให้งงมาก ลองใช้หลาย agent แล้วแค่ 5~6 request ก็โดน rate limit ขณะที่เว็บแอปกลับดูเหมือนใช้ได้ไม่จำกัด ถึงแม้จะมีข้อความว่า “quota ฟรีค่อนข้าง generous” ให้ลอง แต่จริง ๆ มันหยุดในเวลาอันสั้น เหมาะกับการทดสอบพื้นฐาน แต่ถ้าจะใช้จริงในงานยังไม่พอ
ในสไลด์โปรโมตมีข้อความภาพประกอบหนึ่งว่า ถ้ามอบหมายงานด้วยแท็ก '@mini-cli' ก็ทำงานได้ทั้งการเขียนบักและการแก้บัก ซึ่งดูตลกมาก
ยังไม่แน่ใจว่าการเรียกสิ่งนี้ว่า “gemini cli” ถูกไหม หากใช้งานผ่าน GitHub เกือบทุกกรณี มันก็ไม่ถือว่า CLI แล้ว คงเหมาะกับการตั้งชื่อให้เข้าใจง่ายกว่า เช่น 'gemini github action' หรือ 'run gemini' แบบที่ Claude Code ใช้
อาจเป็นเพราะทีม Gemini CLI พัฒนาส่วนนี้เอง จึงอยากให้ทีมได้เครดิต หรือภายในกดดันให้ชื่อไม่ดูเป็นโปรดักต์ใช้งานทั่วไปเกินไป จึงเกิดชื่อแบบนี้
ในทางปฏิบัติคือการติดตั้ง gemini-cli ใน github action VM แล้วส่งคอมเมนต์ของ issue/PR เป็น prompt เข้า gemini-cli
ผมก็เคยตั้งคำถามเรื่อง naming แบบเดียวกัน จุดนี้เป็นจุดที่ทำให้ผมผิดหวังจริงๆ
เป็น add-on แบบทำงานกับ Gemini-CLI แบบ local อย่างแท้จริง
ปีที่แล้วผมพัฒนาแพลตฟอร์ม bounty สำหรับ GitHub PR จริงจัง เพราะแรงจูงใจทำให้ PR คุณภาพต่ำเข้ามามาก และ AI ทำร่างได้ง่าย ทำให้แนวคิดนี้แทบไร้ความหมาย ปัญหาหลักการจัดการโอเพนซอร์สจึงย้ายมาที่ทรัพยากรที่จำกัดของ reviewer/maintainer จึงมีการทดลองพัฒนา framework สำหรับสร้าง PR อัตโนมัติจาก agent หลัก ๆ เพื่อให้กระบวนการ review และ approve/revise มีประสิทธิภาพขึ้น รวบรวม case study ที่เกี่ยวข้องไว้ที่นี่
ต้องการการตั้งค่าพอสมควร เมื่อเทียบกับ GitHub Copilot Agent ที่ผู้ใช้ทุกคนใช้ได้ง่าย ทำให้ความน่าเชื่อถือแทบไม่มี ต้องให้ Gemini assistant ดีกว่าเครื่องมือเดิมแบบชัดเจนถึงจะดึงผู้ใช้ใหม่ได้บ้าง
ข้อสังเกตว่า “ฟรีจริง” ของมันยังน่าสงสัยอยู่ดี อาจเป็นการแลกด้วยการให้ข้อมูลสำหรับ training data และเพราะไม่มีตัวเลือก opt-out ทำให้ผมคิดว่าควรใช้แบบระมัดระวังใน repo ส่วนตัว/ภายใน
ได้ผลลัพธ์ที่ดีจาก Copilot Agent ค่อนข้างมาก บางครั้งต้องปิด PR แล้วปรับ issue ใหม่ หรือทำงาน local ด้วย cursor ต่อเอง แต่การเริ่มงานเร็วมากทำให้ความพึงพอใจโดยรวมสูงอยู่