3 คะแนน โดย GN⁺ 2025-08-08 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Google ของ ตัวแทน AI เขียนโค้ดแบบอะซิงโครนัส Jules ได้ยุติช่วง beta และเปิดตัวอย่างเป็นทางการ
  • การนำ Gemini 2.5 Pro มาใช้ช่วยให้สามารถ สร้างโค้ดที่มีความซับซ้อนมากขึ้น และจัดทำแผนงานได้ดีขึ้น
  • ใน ช่วง beta นักพัฒนาทำงานหลายหมื่นรายการและแบ่งปันผลลัพธ์การปรับปรุงโค้ดมากกว่า 14 แสนรายการ
  • อิงตามฟีดแบ็กผู้ใช้ มีการปรับปรุง UI แก้ไขบั๊ก และเพิ่มฟีเจอร์ใหม่ เช่น การใช้การตั้งค่าเดิมซ้ำ , การเชื่อมต่อ GitHub Issues และ การรองรับอินพุตมัลติโหมด
  • การใช้ความสามารถคิดขั้นสูงของ Gemini 2.5 Pro ช่วยให้สามารถวางแผนการเขียนโค้ดได้ละเอียดขึ้นและสร้างโค้ดคุณภาพสูงขึ้น
  • มีการเพิ่ม ระดับการสมัครสมาชิกใหม่: Introductory (ทดลองใช้งานพื้นฐาน), Pro (จำกัด 5 เท่า), Ultra (จำกัด 20 เท่า), และให้อีก 1 ปีฟรี AI Pro สำหรับนักศึกษา

การเปิดตัวอย่างเป็นทางการของ Jules และการปรับปรุงหลัก

  • ตัวแทน AI เขียนโค้ดแบบอะซิงโครนัส Jules ของ Google ได้ผ่านการทดสอบ beta และเปิดตัวอย่างเป็นทางการ
  • Jules ใช้ความสามารถการคิดขั้นสูง (Advanced Thinking) ของ Gemini 2.5 Pro เพื่อจัดทำ แผนการเขียนโค้ด (Plan) ล่วงหน้า ทำให้สร้างโค้ดได้คุณภาพสูงขึ้น
  • ระหว่างช่วง beta นักพัฒนาหลายพันคนได้ทำงานหลายหมื่นรายการและแชร์ผลลัพธ์การปรับปรุงโค้ดมากกว่า 14 แสนรายการ

การออกแบบประสบการณ์ผู้ใช้ตามฟีดแบ็ก

  • ฟีดแบ็กจากนักพัฒนา ถูกนำมาใช้เพื่อปรับปรุงโครงร่างอินเทอร์เฟซผู้ใช้ (UI) และแก้ไขบั๊กนับร้อยรายการ
  • การเพิ่มฟังก์ชัน การใช้การตั้งค่าเดิมซ้ำ ทำให้รันงานแบบซ้ำๆ ได้เร็วขึ้น
  • การเชื่อมต่อ GitHub Issues เพื่อผสานการไหลของงานพัฒนาซอฟต์แวร์
  • การรองรับ การป้อนข้อมูลแบบมัลติโหมด ช่วยประมวลผลรูปแบบข้อมูลที่หลากหลาย

ระดับการสมัครสมาชิกและวิธีการใช้งาน

  • Jules ให้บริการในรูปแบบ ระดับการสมัครสมาชิกแบบมีโครงสร้าง (Introductory, AI Pro, Ultra) ให้เลือกได้ตามวัตถุประสงค์การใช้งาน
    • Introductory: เน้นการแนะนำและเริ่มต้นใช้งานสำหรับผู้ใช้ทั่วไป
    • Google AI Pro: โควต้า 5 เท่าของพื้นฐาน เหมาะกับการเขียนโค้ดประจำวัน
    • Google AI Ultra: โควต้า 20 เท่าของพื้นฐาน เหมาะสำหรับเวิร์กโฟลว์ multi-agent ขนาดใหญ่
  • สำหรับผู้ใช้แพ็คเกจ Google AI Pro และ Google AI Ultra จะเริ่มนำไปใช้แบบค่อยเป็นค่อยไปตั้งแต่วันนี้ และ นักศึกษามีสิทธิ์รับ AI Pro ฟรี 1 ปี

Jules สามารถเริ่มต้นได้ทันทีผ่าน jules.google

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

 
GN⁺ 2025-08-08
ความคิดเห็นจาก Hacker News
  • ผมสงสัยว่าทำไมโมเดลการสมัครสมาชิกของ Google ถึงซับซ้อนขนาดนี้ เมื่อดูที่ “Google AI Ultra” จะมีทั้ง Jules, Gemini App และ Notebook ครบ แต่ถ้าต้องการใช้ Gemini CLI ต้องสร้างการสมัครสมาชิก/บัญชีเรียกเก็บเงินแยกใน GCP และซื้อ Google Code Assist ด้วย จึงเป็นขั้นตอนที่ยุ่งยาก และในกรณีนั้น Gemini App ก็ยังไม่ให้บริการอยู่ด้วย และสิ่งที่น่าประหลาดใจคือเมื่อสมัคร Google AI จะได้ YouTube Premium มาด้วย ผมไม่เข้าใจเลยว่าทำไมถึงผูกกัน

    • ดูเหมือน Google จะมีสองกลุ่มที่แยกกันชัดเจนในการให้บริการ AI หลายชุด โดยองค์กรที่ผมใช้งานอยู่มี Workspaces subscription ที่รวม Gemini, Veo 3, Jules ไว้ครบ และด้วยการสมัครเดียวก็ใช้ได้ค่อนข้างไม่อั้นแต่มีข้อจำกัดบางอย่าง จุดเข้าหลักคือ gemini.google.com ในทางกลับกัน หากต้องการใช้ API ต้องเข้า GCP แยก ซึ่งที่นั่นใช้โมเดลขั้นสูงอย่าง Veo3 และฟีเจอร์เพิ่มเพิ่มได้ แต่มีการคิดค่าบริการตามปริมาณใช้งาน ช่องทางเข้าถึงคือ GCP Vertex AI ดูเหมือนทั้งสองหน่วยงานค่อนข้างแยกกัน และเหมือนกันทั้งสองฝ่ายไม่ค่อยรู้ว่ากันและกันกำลังทำอะไร
    • ถ้าคุณเป็นผู้ใช้ที่เคยสร้าง Workspace ด้วย Google for Domains มาก่อน คงเจอปัญหายุ่งยากมาก เพราะบางอย่างไม่ทำงานถูกต้อง
    • ระหว่างที่ AI เขียนโค้ดให้ ผมยังสามารถดูวิดีโอบน YouTube ได้พร้อมกันได้
    • ธุรกิจหลักของ Google คือการขายโฆษณาและการรักษาอำนาจครองตลาด (Analytics, Chrome, Chromebook, Android, Google SSO ฯลฯ) ส่วนผลิตภัณฑ์สำหรับนักพัฒนาเป็นธุรกิจเสริมของหลายฝ่ายภายใน Google จึงไม่อาจเป็นแกนหลักหรือความสำคัญสูงสุดได้
    • แตกต่างจากบางอย่างในแพ็กเกจ Ultra, YouTube Premium ไม่รองรับการแชร์แบบ Family ในท้ายที่สุดจึงต้องใช้คนละราย และ Google ก็มีการแจ้งเตือนหลายครั้งว่าอย่าทำแบบนี้
  • ผมเพิ่งลองใช้ Jules พัฒนางาน side project (แอป React Native) มาสักพัก โดยขณะเดินทางไปกลับและเดินเล่นก็คิดไอเดียหรือฟีเจอร์ใหม่ วางแผน แล้วใช้แอป GitHub แก้โค้ด และให้ Jules ทำงานบางส่วน ผมทำงานเสร็จแล้วกลับบ้านตอนเย็นก็เห็นว่า PR ถูกสร้างไว้แล้ว โค้ดไม่ได้สมบูรณ์แบบเสมอ แต่ส่วนใหญ่ก็รันได้ จึงสามารถทดสอบทันทีและแก้เองได้ ทำให้ทำรอบซ้ำได้เร็วขึ้น แผนถัดไปคือเพิ่มการ build อัตโนมัติให้ทุก PR เพื่อจะได้ดู branch แต่ละอันบนมือถือระหว่างทางกลับบ้าน

    • ใน React Native จะเป็นแบบเดียวกันไหมไม่แน่ใจ แต่เมื่อ deploy ด้วย Vercel และใช้ Neon เป็น DB สิ่งที่สะดวกมากคือสามารถดู preview เป็นเว็บสดได้ทันทีจากทุก branch/commit/PR ชุดเครื่องมือ commit-to-deploy แบบนี้ใน ecosystem ของ Python ช่วยลดความขัดข้องในการโค้ดเชิงสำรวจ/ทดลองอย่างมาก ตอนนี้การตัดสินใจว่าจะทำอะไรจึงเปลี่ยนเป็นทำก่อนแล้วค่อยเลือกจากสิ่งที่เกิดขึ้นจริง ส่วนนี้ทำงานลื่นไหลเฉพาะฟีเจอร์ที่ LLM ทำได้จบในรอบเดียว
    • การเขียนโค้ดแบบสำรวจแบบไม่ซิงค์ (asynchronous exploratory coding) คือแนวโน้มในตอนนี้ และผมแนะนำ GitHub Copilot Coding Agent (ตัวเอเจนต์แยก ไม่ใช่ปลั๊กอิน VSCode ของ GitHub Copilot)
    • เคยเชื่อมกับ GitHub repo ที่ไม่ค่อยได้ดูแล แล้วให้มันดูแลงานเล็กๆ—การอัปเดต dependency, รีแฟกเตอร์โค้ด, เพิ่มฟีเจอร์เล็ก, เปลี่ยนสไตล์ ฯลฯ—ได้ใช้ได้ค่อนข้างดีในเคสแบบนั้น แต่คงไม่ให้มันทำงานสำคัญจริงๆ
    • นี่เองที่ทำให้ผมสร้าง superconductor.dev ขึ้นมา โดยมี live preview ของแอปจริงสำหรับเอเจนต์แต่ละตัว รองรับ Claude Code, Gemini, Codex, Amp และหากสนใจสมัครสมาชิกแล้วบอกชื่อ HN มา ผมจะเชิญเป็นรายแรก
  • ในช่วง preview ของ Jules ผมใช้มาแล้วหลายครั้ง และนับเป็นตัวช่วย cloud coding assistant ที่ใช้งานแย่ที่สุดในบรรดาที่เคยลองมา ผมเคยคิดว่าจะหยุดใช้งานหลังทดลองชั่วคราว และไม่เคยคาดว่าจะมีตัว product จริง จนมีบางอย่างคล้าย GH Copilot Spaces ที่ค่อยๆ กลายเป็น Copilot Agent; Jules มักทำตามใจตนเอง พูดว่า "เสร็จแล้ว" แล้วเมื่อถามต่อก็พูดพังๆ, บางครั้งก็ไม่คงสภาพบริบทและบางทีหยุดทำงานไปเลย จาก PR ที่ merge ผ่านจริงแทบมีแค่หนึ่งครั้ง ส่วนที่เหลือเกือบทั้งหมดถูกยกเลิกแล้ว assign ใหม่ให้เอเจนต์คนอื่น ผมจัดอันดับเอเจนต์ของตัวเองว่า Claude Code (ใช้ gh action)>ChatGPT Codex>GitHub Copilot Agent>Jules ตอนนี้ Google ให้โอกาสทดลองใหม่อีก 3 เดือน ผมจะลองอีกครั้งวันนี้ แต่ถ้ายังเป็นแบบนี้ ผมคงไม่เสียเวลาและเงินกับ Jules ต่อไป และแนะนำ Codex หรือ GitHub Agent ครับ ขออภัยที่พูดตรง ๆ

    • วันนี้ผมลอง Jules อย่างยุติธรรมอีกครั้ง แต่ยังคงไม่ดีขึ้น
      • ผมส่งแผนพร้อม feedback และอนุมัติไว้แล้ว ไม่กี่นาทีต่อมามันบอกอีกครั้งให้ป้อนคำสั่งว่า "เมื่ออนุมัติแผนแล้วฉันจะเริ่ม" ผมต้องป้อนเพิ่มอีกทีถึงจะเริ่มทำ
      • ในการตั้งค่าวาง bun ไว้แล้ว แต่ Jules หา bun command ไม่เจอและวนรันเฉพาะการติดตั้งซ้ำๆ หลังให้ feedback แล้ว bun ก็หายไปอีก ทุกคำสั่งจะเรียก install_bun.sh ซ้ำๆ
      • งานที่สั่งทำเสร็จแล้ว แต่การเทสต์พัง มันปฏิเสธว่า "ไม่เกี่ยวกับการเปลี่ยนแปลงของเรา" และแม้สั่ง "แก้ให้ทุกอย่าง" ก็ยังแก้ไม่เสร็จ ในเซตติ้งเดียวกัน Codex, Copilot Agent, Claude Code ทำงานได้ดี แต่ Jules ล้มเหลว
      • ผมพยายามรับงานเอง แต่เพราะไม่ได้รับสถานะ "เสร็จ" จึงไม่สร้าง branch; เมื่อขอ push branch ก็รอค้างนานและวนทดสอบ/ลินท์ซ้ำๆ จนกว่าจะสร้าง branch ได้
      • งานเล็กน้อยต้องใช้เวลานานผิดปกติ และทุกครั้งที่ให้ feedback ก็เสียเวลาเกินไป ส่วนเหตุ bun หรือตัวรันเทสต์ล่มก็ยังไม่รู้สาเหตุ ต้องบอกว่ามันยังคงพัฒนาไปได้ แต่ตอนนี้ผมวางแผนใช้แค่สามเอเจนต์นี้
  • ได้ประสบการณ์ใกล้เคียงกัน ผมให้ความสำคัญกับ Codex ที่มี rate limit ผ่อนเผื่อมากกว่า Claude เพราะ Jules กระจัดกระจายและไม่สะดวกที่ทำงานแบบสร้างเฉพาะ git pull request, ส่วน Codex มีตัวเลือกคัดลอก git patch แล้วแก้ตามที่ต้องการก่อนคอมมิตซึ่งใช้งานได้มากกว่า

  • ผมยังไม่เคยลอง Jules โดยตรงมาก่อน แต่มีคำถามว่ารูปแบบ asynchronous agent จะมีประโยชน์เทียบเท่าการรัน Claude Code บน local หรือไม่ เพราะต้องคอยแทรกดูว่าทำงานจริงหรือไม่และ async agent ต้องมีรอบ pull โค้ด> build> run> test ทั้งหมด ซึ่งดูยุ่งยาก; ในทางกลับกัน local environment ที่ร้อนและตอบสนองทันทีน่าจะมีประสิทธิภาพกว่ามาก

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

    • จำนวนงานฟรีต่อวันลดจาก 60 เหลือ 15 ในแผนฟรี สไตล์ผมแก้หลายอย่าง จึงแทบไม่เคยถึงขีดจำกัด หากอยากติดต่อทีม Jules สามารถแจ้งผ่าน discord.gg/googlelabs
    • ในกรณีผมจำนวนงานขึ้นเป็น 100 ขึ้นอยู่กับว่าจะเป็น Google Pro หรือฟรี รายการที่ผมทำเองบนสุดสัปดาห์ก็เกือบไม่เกิน 10 ตัว แผนฟรี 15 ก็ค่อนข้างพออยู่แล้ว และคงไม่ต้องใช้ 100 รายการตลอดชีวิต
  • ผมลอง prompt "เขียน raytracer พื้นฐานด้วย Rust" สองช่วงเวลา ตั้งแต่หนึ่งถึงสองเดือนก่อนจนถึงตอนนี้อีกครั้งกับ Jules; ตอนก่อนหน้าแม้โค้ดจะน้อยแต่ก็ทำให้ compile ได้ แต่ครั้งนี้ไม่ยอม push branch เลย ขอโตะทีไรก็ปฏิเสธ ทำให้ไม่สามารถเช็กว่าโค้ดรันได้จริงหรือไม่ ในครั้งนี้ทำ main.rs สองไฟล์ในโฟลเดอร์ต่างกันและกระจายโค้ดแบบสุ่ม เมื่ออธิบายปัญหา มันวนสำรวจไฟล์ระบบไปเรื่อยๆ แล้วทิ้งท้ายด้วยความพ่ายแพ้

    • แบบจำลองการโต้ตอบเรื่อง push commit สับสนจนแทบทำความเข้าใจไม่ทัน
    • มันไม่ใช่ zero-shot tool ทำไมทุกคนถึงลองใช้เป็น zero-shot
  • ผมดีใจที่ดูเหมือน Codex จะอยู่ในสายแข่งขันกับ Jules; ผมคิดว่าคลาวด์เอเจนต์แบบ async อย่าง Codex และ Jules ดีกว่าแนว local integration ของ Claude Code/Aider/Cursor ในหลายมุม เพราะมันแยกจาก local environment อย่างสมบูรณ์ ทำให้ปลอดภัยกว่า และการส่งคำสั่งแค่เดียวแล้วทำงานบางอย่างบนเครื่องอื่นก่อน แล้วกลับมาดู PR ตอนหลัง รู้สึกสะดวกกว่าออก sandbox เองหรือใช้ git worktree

    • Codex/Jules ต่างจาก CC/Cursor อย่างชัดเจนเหมือนการโต้แย้ง Cathedral and Bazaar ในซอฟต์แวร์คือ 1) Cathedral คือสภาพแวดล้อมควบคุมง่าย, deploy สะดวก, upside จำกัด ซึ่ง OpenAI เป็นตัวอย่าง 2) Bazaar คือเอเจนต์ในสภาพแวดล้อมผู้ใช้, โต้ตอบกับแอปและตัวแปรนับไม่ถ้วน เพิ่มระดับความยากสูงกว่า แต่ payoff สูงกว่า, ปัญหาการตั้งค่าสภาพแวดล้อมเป็นเรื่องชั่วคราวและแก้ได้
    • แยกขอบเขตทั้งหมดทำให้ปลอดภัย แต่มักช้าและมีค่ามากกว่า; เมื่อ CC ทำงานผิดปกติสามารถหยุดทันทีได้ แต่ async ต้องรอเป็นชั่วโมงแล้วค่อยพบผลเสีย และอาจเผาผลาญ token ได้มาก
    • ใน codebase เดิม การนำเสนอผ่าน PR เป็นจุดเริ่มที่คุ้นเคยที่สุดกับนักพัฒนาเพราะชินกับการรีวิวดโค้ดอยู่แล้ว แต่การบังคับ workflow แบบมนุษย์เป็นหลักให้รับข้อเสนอแบบสตรีมหนักๆ จากเอเจนต์จำนวนมากอาจถึงขีดจำกัดเร็ว จึงต้องมี workflow review อัตโนมัติที่มีประสิทธิภาพมากขึ้นเพื่อคัดกรองข้อเสนอจำนวนมาก ดังนั้น CLI อย่าง Claude, Aider จึงเป็นทางเดียวที่ใช้ async/parallel agent ได้เต็มประสิทธิภาพ ที่นี่ผมยังพัฒนา ไลบรารีเสริมสำหรับ aider/claude เอง และเชื่อว่าโครงสร้าง dev นี้ควรคงเป็นโอเพ่นซอร์สเพื่อหลุดพ้นการผูกติดกับโครงสร้างพื้นฐานของ MS, OpenAI และอื่นๆ ผมกำลังจัดทำ ตัวอย่างเอกสารตามกรณีใช้งาน สำหรับเทคนิครีวิวผ่าน CLI
    • นอกจากนี้ Claude code ยังทำงานแบบ async ได้เมื่อรวมกับ GitHub actions และรองรับการตั้งค่าอัตโนมัติผ่านคำสั่ง slash ของ Claude code
    • ผมเห็นว่าการผสมโหมด async agent บนคลาวด์กับโหมด local แบบ active (Claude Code, Cursor, Aider) ให้ผลดีที่สุด เหมือนใช้ Codex UI กับงานที่ซ้ำๆ และตรงๆ เท่านั้น และทำงานอื่นๆ ด้วยตัวเองทาง local; อย่างไรก็ตามเครื่องรัน Codex ค่อนข้างช้า ทำให้การ compile, rebuild และการ cache dependency ต้องทำซ้ำมาก หาก UI/tool/state ควบคุมบน local และแค่ออกแบบการอนุมาน LLM เป็น remote น่าจะได้ workflow ที่เร็วกว่านี้
  • ผมลองใช้ Jules ทำ side project แล้วพบว่าโค้ดคุณภาพต่ำกว่าสำหรับ GH Copilot (Claude Sonnet), Gemini CLI, Claude Code ชัดเจน โดยเฉพาะเหตุการณ์ใน monorepo ที่การย้าย directory logic มักติดขัด อยู่แล้วในโฟลเดอร์ backend ก็ยังพิมพ์ cd ซ้ำๆ และปรับ logic ไม่ได้อย่างถูกต้อง

    • ล่าสุด Jules โฆษณาว่าใช้ความสามารถทำแผนขั้นสูงของ Gemini 2.5 Pro จึงลองอีกครั้ง
    • เป็นการใช้งานครั้งแรก แต่เปลี่ยน data layer ได้ดีมากเกินคาด และน่าพึงพอใจ; ตอน Copilot ก็เคยทำได้ดีเช่นกัน แต่เมื่อใช้งานนานๆ AI มักช้าลงและสับสน ทำให้เสียเวลา ซึ่งเป็นภาพรวมของ coding agent ในตอนนี้
    • ผมให้ Jules ทำงานเล็กๆ ใน side project อย่างการเพิ่ม output สีสันใน terminal และผล PR ที่ได้ดูยอดเยี่ยม, LLM coding agent แสดงจุดเด่นในงานบางอย่างและจุดอ่อนในบางงาน ทำให้ผลลัพธ์ค่อนข้างสุ่ม แต่อย่างน้อย PR โผล่มาแค่ prompt เดียวและหากล้มเหลว การเริ่มใหม่ทำได้ง่าย
  • ผมชอบคำและแนวคิดเรื่อง "asynchronous coding agent" รวมถึงอ่าน บทความแนะนำ Open-source async agent ของ LangChain และเจอ กรณีศึกษาของ coding agent สำหรับ Copilot เป็นอ้างอิงหวังว่าทิศทางนี้จะหยุดนิ่ง

    • ถ้าคำนี้เป็นคำที่ Simon (ผู้เขียนคอมเมนต์ด้านบน) ใช้ ผมว่าอาจกลายเป็นมาตรฐานได้
  • เชื่อว่าในปี 2025 มี Claude Code เป็นเอเจนต์ตัวจริงเพียงรายเดียว แม้ Gemini จะทำงาน context ยาวได้ดีมาก ตัวอย่างเช่น ลิงก์อภิปรายบน Reddit

    • เห็นด้วย, Google ทำ benchmark ได้ดีและประกาศ World Models Genie 3 แต่อัลกอริทึมของ Gemini CLI ในส่วนแนะนำ/แก้โค้ดยังค่อนข้างคงรูป มักยึดกับ tab และ space มากเกินไป ราวกับเป็น OCD coder มากกว่าโฟกัสฟีเจอร์ใช้งานจริง ตัวอย่างล่าสุดในโปรเจกต์เดียวกัน ผมใช้โควต้า token ทั้งวันไปกับการตั้ง ESLint กับการโมดูลาร์โค้ดที่ไม่จำเป็น ส่วน Claude Code เข้าใจความต้องการผมได้ตรงกว่าและช่วยสร้างฟังก์ชันใช้งานจริงได้ดีขึ้น อาจเพราะ prompt ของผม แต่ดูเหมือน Claude Code จะเข้าใจผมดีกว่า
    • ความคิดเห็นของผมก็ตรงกันเอง— workflow ทบทวน PR ตรงกลางไม่ใช่สิ่งที่อยากได้ ความสามารถหลักของ Claude Code คือการปรับทิศทางได้ทันทีเมื่อเริ่มหลงทาง และยังสามารถแทรกการเขียนโค้ดเองได้บ่อยๆ ได้ง่าย คล้ายกับการที่ไม่ควรให้ junior รับงาน full feature โดยไม่คุมและพอคืบถึงปัญหาแล้วค่อยเช็คเท่านั้น
    • Sourcegraph Amp ก็ดูดีไม่น้อย แม้จะไม่สมบูรณ์แบบเท่ากับ Claude code ในบางแง่มุม แต่ในการ review โค้ดผมมักเรียก o3 ผ่านเครื่องมือ 'oracle' ช่วยอยู่เสมอ
  • ไม่เข้าใจว่าทำไมข้อมูลราคาถึงถูกซ่อน ต้องถาม Grok ถึงหาได้; เว็บไซต์ Google ต้องยอมรับข้อกำหนดจึงจะเห็นภาพรวมแผนเบื้องต้นได้ โดยข้อมูลแผน/ราคาอยู่ใน gemini.google/subscriptions (อาจต้องล็อกอิน)

    • ผมเห็นด้วยว่าควรห้ามการแสดงข้อความแบบ "> Highest task limits" หรือการเปลี่ยนเงื่อนไขการใช้งานภายหลังแบบ Claude/Cursor เพราะมันน่าจะขัดต่อกฎหมาย
    • อยากรู้ว่าหมายถึงการใช้ Grok คืออะไร ถ้าพูดได้ ช่วยอธิบายหน่อยว่าคุณลองโมเดลอื่นแล้วล้มเหลวหรือใช้งาน grok บ่อยอยู่