- ใช้งาน Cursor และ Claude Code ควบคู่กัน พร้อมสะสมประสบการณ์จากงานพัฒนาจริงบนโค้ดเบสขนาดใหญ่ รวมถึงงานที่ปรึกษาด้านการประเมิน LLM
- Cursor เคยได้รับความนิยมในหมู่พาวเวอร์ยูสเซอร์จาก UI/UX ที่ใช้งานสะดวกและการเข้าถึง API แบบไม่จำกัด แต่ช่วงหลังประสบการณ์ใช้งานถูกจำกัดลงอย่างมากจากการเพิ่ม rate limit ที่เข้มงวด
- Sonnet 4 ใน Claude Code แสดงให้เห็นถึงความน่าเชื่อถือและประสิทธิภาพสูงในการทำความเข้าใจและแก้ไขโค้ด รวมถึงการจัดการคอนเท็กซ์ขนาดใหญ่ และเมื่อใช้งานร่วมกับ Opus 4 ก็สามารถช่วยแก้บั๊กยาก ๆ ได้
- มีฟีเจอร์ขั้นสูงสำหรับพาวเวอร์ยูสเซอร์ซ่อนอยู่อีกมาก เช่น สภาพแวดล้อม CLI แบบสั่งการด้วยคำสั่ง และ การใช้ sub-agent โดยประสบการณ์นี้ชี้ให้เห็นว่าการทดลองใช้อย่างต่อเนื่องและการสำรวจฟีเจอร์มีความสำคัญมาก
- ข้อที่ยังน่าเสียดาย ได้แก่ การขาด UI เชิงภาพ, การคัดลอก/วางที่ช้า, ข้อจำกัดในการใช้โมเดลอื่น ๆ และยังมีคำขอให้เพิ่มความสามารถอย่าง checkpoint
จาก Cursor สู่ Claude Code: เบื้องหลังของการเปลี่ยนแปลง
- จนถึงไม่นานมานี้ Cursor ยังเป็นที่รักของนักพัฒนาจาก การใช้งาน API แบบไม่จำกัด และเวิร์กโฟลว์ Diff review ที่เข้าใจง่าย
- ด้วยเหตุนี้จึงถูกใช้เป็นหลักในงานอย่าง Gumroad bounties และงานให้คำปรึกษาด้าน AI engineering / การประเมิน LLM ทั้งในแง่การสร้างโค้ดและการทำความเข้าใจโค้ดเบสอย่างรวดเร็ว
- แต่หลังกลางเดือนมิถุนายน มีการเพิ่ม rate limit ที่เข้มงวดอย่างฉับพลัน ทำให้ประสิทธิภาพการทำงานลดลงมาก และข้อดีของการใช้ Cursor ก็ลดลงตามไปด้วย
- ในบรรดาโมเดลต่าง ๆ เช่น Sonnet 4, Opus 4, GPT-4.1, Gemini Pro 2.5 โมเดลที่ถูกใช้งานจริงมากที่สุดกลับเป็น Sonnet 4 และ Opus 4
- ด้วยข้อจำกัดเรื่องค่าใช้จ่ายของ API และความเร็วที่ลดลง จึงถึงขั้นพิจารณา Claude Code Max subscription (200 ดอลลาร์ต่อเดือน) และเริ่มเปลี่ยนมาใช้อย่างจริงจัง
รีวิวการใช้งาน Claude Code จริง
- ใช้ Claude Code กับโค้ดเบสโอเพนซอร์สขนาดกลางถึงใหญ่ใน Python, Ruby, TypeScript (50M+ โทเค็น) และได้สัมผัสกับ feedback loop ผ่านสเปกและการทดสอบ
- ในช่วงแรกใช้เพียงการป้อนคำสั่งง่าย ๆ ก่อนจะเริ่มเรียนรู้ คำสั่งพื้นฐานและโหมด plan แล้วค่อย ๆ สำรวจวิธีใช้งานที่ลึกขึ้น
- จากการป้อนคำสั่งอย่างเดียว → เรียนรู้โหมดคำสั่ง/โหมดวางแผน → ใช้ชุดคำสั่งที่ชัดเจนเพื่อทำให้งานอัตโนมัติและเพิ่มประสิทธิภาพ
- ใช้ กระบวนการแก้ปัญหาเหมือนการปรึกษา โดยเทบริบททั้งหมดของปัญหาให้ Claude อย่างอิสระ แล้วสลับไปใช้ Opus เมื่อต้องการวางแผน (Plan mode) และให้ Sonnet 4 ทำงานหลัก เป็น กลยุทธ์แบบผสม
- สั่งให้ Claude บันทึกและจัดระเบียบข้อมูลไว้ใน ไฟล์ภายในโฟลเดอร์
.claude เพื่อช่วย จัดการคอนเท็กซ์และลดความไม่สะดวกจากการคัดลอก/วาง พร้อมแนะนำให้ใช้ Plan mode และ Auto-edit mode ควบคู่กัน
- การจัดการคอนเท็กซ์: แทนที่จะใช้การบีบอัด (compaction) จะชอบเริ่มแชตใหม่เป็นระยะ และให้จดการเปลี่ยนแปลงสำคัญไว้ในไฟล์แยกต่างหาก
การจัดการคอนเท็กซ์และการใช้ sub-agent
- Claude Code รองรับ context compression แต่เนื่องจากช้าและมีประสิทธิภาพไม่มาก จึงชอบสร้างไฟล์สรุปประเด็นสำคัญเองแล้วเริ่มแชตใหม่มากกว่า
- ให้บันทึกการเปลี่ยนแปลง โน้ต และประวัติไว้ในไฟล์ช่วยอย่าง Scratchpad เพื่อนำไปใช้ภายหลังตอนทำงานแบบแยกสาขา (branch) หรือกู้คืนเซสชันด้วย
/resume
- sub-agent: สามารถกระจายหลายงานภายในโค้ดเบส (เช่น ค้นหา วิเคราะห์ ฯลฯ) แบบขนานได้ ทำให้แบ่งงานด้วยโครงสร้างแบบมัลติเธรดได้
- ภายในจะมีการสร้างมัลติเอเจนต์บนพื้นฐานของ ToDo list เพื่อช่วยจัดการบริบท
การค้นหาและการใช้คำสั่ง
- ใน Cursor สามารถใช้เครื่องมือหลากหลาย เช่น normal / semantic search, agentic search และยังค้นหาได้รวดเร็ว
- แต่การค้นหาใน Claude Code อาจช้าได้ อย่างไรก็ตามเมื่อใช้ sub-agent ก็สามารถประมวลผลแบบขนานในโค้ดเบสขนาดใหญ่ได้
- สามารถสำรวจรีโพซิทอรีขนาดใหญ่และแบ่งงานได้ด้วยการใช้ sub-agent, task tool และคำสั่งอย่าง
/think, /ultrathink
- การกดคีย์ลัด
Shift + ? เพื่อดูรายการคำสั่งและตรวจดูฟีเจอร์ใหม่อย่างรวดเร็วเป็นเรื่องสำคัญ
- คำสั่งเทอร์มินัล (bash) สามารถรันได้ด้วย
! และยังทำงานในโหมด headless ได้ด้วย
- มีฟีเจอร์ขั้นสูงในตัวจำนวนมาก เช่น file tag (
@ไฟล์), ฟังก์ชัน memorize (system prompt แบบปรับแต่งตามผู้ใช้), การใช้ CLAUDE.md
เปรียบเทียบ Sonnet 4 vs Opus 4 และเคล็ดลับเวิร์กโฟลว์
- Sonnet 4: เร็วกว่าในสถานการณ์ส่วนใหญ่ และโดดเด่นกับงานที่ต้องใช้คอนเท็กซ์ยาว ๆ + งานแบบเอเจนต์ เหนือกว่าในการทำงานกับ Python และงานฝั่งฟรอนต์เอนด์
- Opus 4: มีแนวโน้มจะสับสนเมื่อมี Instructions สะสมหลายรอบ ในกรณีนี้แนะนำให้บันทึกลงไฟล์แล้วเริ่มแชตใหม่ และนำมาใช้แก้บั๊กยาก ๆ เมื่อ Sonnet 4 ไปต่อไม่ได้
- สำหรับปัญหาซับซ้อน แนะนำให้เริ่มด้วย Opus และใช้ Sonnet สำหรับงานเขียนโค้ดทั่วไป เป็นการทำงานแบบไฮบริดที่น่าใช้
คำสั่งปรับแต่งและเคล็ดลับอื่น ๆ
- รองรับ custom command เช่น
/pr-comments, /review โดยต้องมี Github CLI
- สามารถจัดเวิร์กโฟลว์ได้ยืดหยุ่น เช่น เริ่มบทสนทนาใหม่เมื่อเปลี่ยน branch หรือรีวิว diff กับ main
- กด
Esc สองครั้งเพื่อ fork บทสนทนาได้จากทุกจุด
- ปรับ permission ก่อนเริ่มเซสชันได้ด้วย
/permissions
- ถ้ากล้าพอ ก็ลองใช้ claude
--dangerously-skip-permissions ได้
- แนะนำวิดีโอ Cluade Code Pro TIPS
สิ่งที่อยากลองต่อจากนี้
- อยากทดลองวิธีนิยามและใช้งาน custom command ด้วยตัวเอง
- อยากลองใช้ MCP server อย่าง Playwright server เพื่อทำงานพัฒนาระบบอัตโนมัติฝั่งฟรอนต์เอนด์
- มีแผนโฟกัสที่การสร้าง feedback loop ที่ให้ Claude จับภาพหน้าจอ รับรู้ผลลัพธ์ และปรับปรุง UI แบบวนซ้ำ
- มีแผนจะลองทำตามแนวทางใช้งานขั้นสูงทั้งหมดที่แนะนำใน how-i-bring-the-best-out-of-claude-code-part-2
- ตั้งใจจะลองทำ prompt optimization
- อยากกำหนดเกณฑ์การประเมิน (
rubric.md) ให้ชัดเจน และออกแบบ ลูปสำหรับประเมิน/ปรับปรุงพรอมป์ต์ ร่วมกับไฟล์ที่เก็บคอนเท็กซ์ (เช่น pmd)
- วางแผนโครงสร้างที่พัฒนาไปสู่การมี Claude หลายอินสแตนซ์ โดยให้อินสแตนซ์หนึ่งสร้างผลลัพธ์จากพรอมป์ต์ แล้วอีกอินสแตนซ์ประเมิน ให้ฟีดแบ็ก และปรับปรุงต่อ (ระบบเอเจนต์เดี่ยวหรือหลายเอเจนต์)
- แนวทางนี้ได้แรงบันดาลใจจากโพสต์ของ Nirant
- อยากสร้าง ระบบมัลติเอเจนต์ ที่ให้ Claude Code หลายอินสแตนซ์สื่อสารกันผ่าน action log
บทสรุปและสิ่งที่อยากให้ปรับปรุง
- Cursor มีจุดแข็งมากในด้าน UI/UX แต่ Claude Code ช่วยกระตุ้นทั้งประสิทธิภาพการทำงานและจิตวิญญาณแห่งการทดลองสำหรับพาวเวอร์ยูสเซอร์ในสภาพแวดล้อมที่เป็นมิตรกับ CLI
- เป็น เครื่องมือที่ให้ผลตอบแทนสูงกับการเรียนรู้เชิงสำรวจและการทดลอง และขอแนะนำอย่างมากสำหรับสาย Nerd / พาวเวอร์ยูสเซอร์
ฟีเจอร์ที่อยากให้มีการปรับปรุง
- การผสาน UI (Claudia เป็นตัวอย่างอ้างอิง)
- รองรับ checkpoint แบบเดียวกับ Cursor แม้จะมี Git อยู่แล้ว แต่แนวทางของ Cursor สะดวกมาก
- ปรับปรุงคุณภาพการคัดลอก/วาง
- รองรับการใช้โมเดลที่หลากหลาย
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
ทุกครั้งที่เห็นคนสรรเสริญ Claude Code แบบสุดๆ ก็อดรู้สึกไม่ได้ว่าเหมือนมีแต่พวกอินฟลูเอนเซอร์หรือแฟนเครื่องมือสายดั้งเดิมอย่าง terminal, Emacs, Vim เท่านั้นที่พูดกัน ฉันเห็นคอมเมนต์บ่อยมากว่า Claude Code ดีกว่า Cursor แบบขาดลอย เลยสมัครมาลองใช้จริงกับโค้ดเบส TypeScript ขนาดใหญ่ ซึ่งกระบวนการมันทั้งช้าและเส้นโค้งการเรียนรู้ก็สูง สุดท้ายผลลัพธ์ก็เหมือน Claude ที่ฝังอยู่ใน Cursor นั่นแหละ แต่ช้ากว่า คลุมเครือกว่า และรีวิวโค้ดยากกว่า ตอนนี้เลยรู้สึกว่าพวกแฟนพันธุ์แท้ในคอมเมนต์คงไม่ก็มีสปอนเซอร์ ไม่ก็จ่าย 200 ดอลลาร์ไปแล้วเลยต้องหาเหตุผลมาสนับสนุนการตัดสินใจตัวเอง พูดตรงๆ คือ Cursor ทำให้ฉัน productive กว่ามาก ฉันเป็นโปรแกรมเมอร์มา 18 ปี เขียนโค้ดทุกวัน ใช้ทั้ง Gemini 2.5 Pro และ Claude 4.0 สลับกันไป แต่กลับได้ประโยชน์จาก Cursor มากกว่า ยังไม่มีใครสักคนที่ทำให้ฉันเชื่อได้เลย ยังมองไม่เห็นข้อดีที่เป็นรูปธรรม อนาคตอาจเปลี่ยนความคิดก็ได้ แต่ตอนนี้ยังไม่รู้สึกจริงๆ
ฉันคิดว่าคนส่วนใหญ่เข้าใจผิดอย่างลึกซึ้งว่าความยากจริงๆ ของการพัฒนาซอฟต์แวร์คืออะไร งานจริงส่วนใหญ่ไม่ได้เป็นการคิดอัลกอริทึมซับซ้อนใหม่ๆ แต่คือการเอาไอเดียที่มีอยู่มาผูกและประกอบเข้าด้วยกันให้ลงตัว แต่ทั้งหมดนั้นเกิดขึ้นหลังงานต้นน้ำอย่างการทำสเปก การออกแบบ และสถาปัตยกรรมเสร็จแล้ว การให้ AI ปั่นโปรแกรมออกมาไวๆ ดูเท่มาก และในเดโมก็ดูเหมือน “เสร็จ” อย่างรวดเร็ว แต่ปัญหาจริงคือการสร้างระบบที่ต้องใช้งานไปอีก 30 ปีให้ได้ตามมาตรฐานคุณภาพ มันยอดเยี่ยมมากสำหรับโปรโตไทป์หรือของใช้ครั้งเดียว แต่ยังมีข้อจำกัดชัดเจนเรื่องความทนทานระยะยาว
ถ้าจะรีด productivity ให้สุดจากเครื่องมือพวกนี้ หัวใจสำคัญคือลูป feedback ที่สั้นและเร็วมาก โมเดล tab autocomplete ของ Cursor เหมือนจับความตั้งใจของคนใช้ตอนกำลังจะทำอะไรได้อย่างเป็นธรรมชาติ ราวกับมีผู้ช่วยที่ฉลาดแบบบ้าคลั่งคอยแตะเบรกให้พอดี ฉันไม่ต้องมานั่งฝืนทำ macro programming เอง ถ้าไม่เอาก็กด Esc ยกเลิกได้เลย หรือไม่ก็ไล่ขยับไปสู่ agentic mode แบบค่อยเป็นค่อยไป ส่วน editor ที่ขับเคลื่อนด้วย agent เต็มตัวนั้นกินเวลา 15–30 นาทีต่อรอบ และทำให้ workflow ขาดตอนแบบสมบูรณ์ งานกลายเป็นการนั่งรีวิวผลลัพธ์ ซึ่งกินพลังมากกว่าลูปรับ/ปฏิเสธสั้นๆ เทียบกันไม่ได้ แถมยังต้องคิดอีกว่าจะให้สิทธิ์เครือข่ายไหม หรือจะรันแบบออฟไลน์ดี เลยเหมาะแค่กรณีที่ต้องรีบปั้นโค้ดซึ่งไม่ค่อยมีประเด็นด้านการบำรุงรักษา ความปลอดภัย หรือความน่าเชื่อถือ นอกเหนือจากนั้น productivity กลับลดลงเสียอีก อนาคตมันคงดีขึ้น แต่ตอนนี้ยังทำผลงานได้ดีกว่าใน Cursor อย่างชัดเจน
ฉันก็เคยรู้สึกแบบนั้น แต่พอได้ลองใช้ Claude Code จริงๆ เมื่อไม่นานมานี้ กลับรู้สึกว่ามันดีกว่า Cursor มาก แม้จะไม่แน่ใจนักว่าทำไม แต่ดูเหมือน Claude จะมองภาพรวมของโครงสร้างได้ดีกว่า และหลีกเลี่ยงการแก้ไขที่ไม่จำเป็นได้ดี แน่นอนว่าบางครั้งก็ยังต้องคอยกำหนดทิศทางให้เอง แต่ประสิทธิภาพโดยรวมดีกว่ามาก จุดเด่นอย่างหนึ่งคือมันมักแสดงให้ดูทีละไฟล์ จึงรีวิวได้ง่ายกว่ามาก ส่วน Cursor ชอบเปิดหลายไฟล์พร้อมกัน และมีการเปลี่ยนแปลงเยอะจนจับภาพได้ยาก สำหรับฉันใช้งานผ่านส่วนขยาย Claude Code ในหน้าต่าง terminal ของ VSCode โดย Claude จะเปิดแท็บไฟล์ที่มันจะแก้ แล้วเสนอการเปลี่ยนแปลงให้ดู
สิ่งที่คนยังไม่ค่อยรู้คือ Cursor ไม่ใช่ผลิตภัณฑ์ที่เสร็จสมบูรณ์ชิ้นเดียว แต่เป็นชุดความสามารถที่ทุกเครื่องมือกำลังรีบไล่ตามแล้วทยอยใส่เข้ามา บทเรียนสำคัญจริงๆ คือ นอกจาก deep interface แล้ว ยังมีแนวทางเอา best-in-class agent solution ไปผูกเข้ากับ editor ที่แต่ละคนชอบด้วย สุดท้ายประสบการณ์พวกนี้จะค่อยๆ ตกผลึกเป็น “best practice” แล้วคนก็จะเอาไปใช้แบบเป็นธรรมชาติใน editor หรือ IDE ของตัวเอง และพวก vscode fork เหล่านี้ก็คงหายไปหมด
ฉันใช้แพ็กเกจ 17 ดอลลาร์ไม่ถึงเดือน ความรู้สึกคือครึ่งหนึ่งตื่นเต้น ครึ่งหนึ่งหงุดหงิด ระหว่างนั้นเขียน Rust ไป 8,000 บรรทัด และ Markdown อีก 12,000 บรรทัด โดยแยก work spec กับ task ที่เฉพาะเจาะจงออกจากกัน คล้ายๆ test harness ในการโต้ตอบกับ AI ไม่รู้ว่าสิ่งมหัศจรรย์นี้มาจากเงินอุดหนุน VC หรืออะไร แต่ประสบการณ์ทำให้ Rust รู้สึกเหมือนภาษา scripting ไปเลย (อ้างอิง: GitHub repo คือ
knowseams)สิ่งที่ฉันชอบที่สุดเกี่ยวกับ AI คือ เวลาขี้เกียจก็แค่บอกว่า “ช่วยทำอันนี้ให้หน่อย” ผลจะดีหรือแย่ก็ไม่เป็นไร อย่างน้อยมันทำจุดเริ่มต้นให้
LLM ทำให้ความกลัวหน้ากระดาษเปล่าหายไป ไม่ต้องพยายามรื้อฟื้นบริบทซับซ้อนกลับเข้าหัวเองใหม่ แค่ถามว่า “เราทำอะไรกันอยู่?”, “โค้ดนี้คืออะไร?” AI ก็อธิบายให้ได้เร็วมาก แล้วกลับเข้าสู่ภาวะโฟกัสได้ทันที มันช่วยทั้ง rubber duck debugging และงานจุกจิกซ้ำๆ แบบ yak shaving ได้เร็วมากจนมีประโยชน์จริงๆ ฉันยังเอาไปเชื่อมกับ Slack, Notion, Linear ฯลฯ ด้วย จนสำหรับฉันมันกลายเป็นเครื่องมือจัดการงาน/โปรเจกต์ไปแล้ว
แม้ในเวลาที่อยากทำเอง ฉันก็ยังให้ AI ช่วยวางแผนแล้วเก็บไว้ใน Markdown วันนี้ก็เพิ่งให้มันช่วยวางแผน refactor แต่มันดันเข้าผิดทาง โดยพยายามเปลี่ยนโครงสร้างโปรโตไทป์ 40 ไฟล์จากล่างขึ้นบน ถ้าฉันเผลอทำตามนั้นคงเสียเวลา debug มหาศาล ถึงอย่างนั้นมันก็ยังช่วยชี้จุดให้เริ่มโจมตีปัญหาได้ และฉันก็แก้แผนแล้วนำไปใช้ได้ภายในชั่วโมงเดียว ถ้าทำคนเดียว ฉันอาจท้อกับความซับซ้อนจนไม่เริ่ม หรือไม่ก็ติดวนกับการทำเอกสารซ้ำไปซ้ำมาจนเลิกกลางทาง
พอถึงท้ายวัน เวลาที่สมาธิหมดจนสิ่งที่เขียนเพิ่มกับสิ่งที่ต้องย้อนกลับพอๆ กัน ฉันก็ส่งพวงมาลัยให้ AI รับช่วงต่อเพื่อพักหายใจ ปัญหาเล็กๆ แค่เหลือบดู diff ก็พอ ส่วนปัญหายาก ถ้ารู้ชัดแล้วว่ามีอะไรผิด ก็สามารถคอยบรีฟทิศทางและโน้มน้าว AI ได้ ฉันมักปล่อยให้มันทำไปจนงานเสร็จราว 40–60% แล้วค่อยเข้ามารับต่อเอง โดยปกติฉันจะใช้เวลาที่สมองคมที่สุดกับการคิดและพัฒนาเอง ส่วนงานดึกๆ หรืองานซ้ำๆ ก็โยนให้ AI ทำ เพื่อเตรียมงานสำหรับวันถัดไปหรือไปโฟกัสกับงานเขียน/ออกแบบระดับสูงกว่า
ฉันแค่ออกไปเดินเล่นและดื่มกาแฟ ปัญหาของมนุษย์ก็ควรแก้ด้วยวิธีแบบมนุษย์ มันรู้สึกเป็นธรรมชาติกว่า
Claude Code อธิบายยากมาก หลังจากใช้แล้วรู้สึกเหมือนเปลี่ยนอาชีพไปเลย ก่อนหน้านี้ก็เอา Claude มาใส่ใน workflow หลักอยู่แล้ว แต่ Claude Code นี่เหมือน Claude ติดสเตียรอยด์ ถ้ายังไม่เคยลอง แนะนำแบบสุดๆ นี่เป็นครั้งแรกที่ฉันรู้สึกเหมือนได้ทำงานร่วมกับวิศวกรจูเนียร์จริงๆ
ประสบการณ์ของฉันตรงกันข้ามเลย สั่งอะไรไปมันก็ใช้เวลาหลายนาทีแล้วส่งอะไรบางอย่างกลับมา แต่สุดท้ายแอปพัง พอนั่ง debug ดูก็พบว่ามันไปทำเรื่องผิดๆ จนต้องทิ้งทั้งหมด ถึงอย่างนั้นฉันก็ยังกลับไปใช้ Claude อยู่ เพราะถ้ามันทำงานได้ดีเหมือนที่คนอื่นว่า มันก็ดีมากจริงๆ แต่ในโลกจริงมันมักแค่ผลิต boilerplate และฉันยังต้อง debug เองพอสมควร แย่สุดคือเสียทั้งชั่วโมงและเปลืองโทเคนไปเปล่าๆ
วันนี้เพิ่งลองใช้ที่บริษัทเป็นครั้งแรก มันเปลี่ยนเกมมากกว่า Cursor แบบท่วมท้น ทั้งที่ใช้ foundation model เดียวกัน แต่ประสบการณ์ต่างกันโดยสิ้นเชิง เมื่อเดือนก่อน AI ยังทำให้งานฉันช้าลงอยู่เลย แต่วันนี้ Claude Code จบงานให้ใน 20 นาที โดยค่า API ยังไม่ถึง 10 ดอลลาร์ด้วยซ้ำ ฉันแทบไม่ต้องคอยจัดการบริบทเลย และ Claude Code ก็หา context ที่ต้องใช้มาเติมเอง ทำให้ทำงานได้อย่างมีประสิทธิภาพต่อเนื่องยาวนานกว่ามาก agent mode ของ Cursor ใช้ได้ดีกับงานราว 3–5 นาที แต่ Claude Code ทำงานที่นานเกิน 10 นาทีได้โดยไม่หลงทางและยังคืบหน้าเรื่อยๆ การใช้เครื่องมือของมันก็ยอดเยี่ยม และน่าทึ่งที่มันไม่ค่อยติดลูป
คุณบอกว่า “เหมือนได้ทำงานกับวิศวกรจูเนียร์” แต่สิ่งที่ฉันรู้สึกกลับเป็นว่าฉันต่างหากที่เป็นลูกน้อง และ Claude เป็นหัวหน้า อารมณ์ประมาณฉันพูดว่า “ผมทำของเจ๋งๆ นี้มาได้แล้วนะ!” แล้วอีกฝั่งตอบว่า “แต่นั่นไม่ใช่สิ่งที่ฉันสั่งนี่...”
ช่วยอธิบายให้ละเอียดกว่านี้ได้ไหมว่าใช้กับงาน ภาษา หรือโดเมนแบบไหน แต่ละเคสต่างกันมากจนอยากรู้
ฉันก็มีประสบการณ์แบบเดียวกัน Claude เก่งเกินกว่าจูเนียร์ธรรมดา มันเสนอทางเลือก ให้คำแนะนำเพื่อช่วยตัดสินใจ และมองเห็น trade-off ได้ดีมาก
มี walkthrough ที่แสดงการสร้างแอปหรือไลบรารีด้วย Claude Code จริงๆ ไม่เยอะเหรอ? ฉันอยากเห็นการพัฒนาใช้งานจริงด้วยเครื่องมือนี้มากกว่าบทความแนว “มันเจ๋งนะ” ถ้ามีการรวบรวมตัวอย่างแบบนั้นคงดีมาก
โดยรวมแล้วรู้สึกว่าสถานการณ์นี้แปลกๆ นิดหน่อย ตัว Claude Code เองชัดเจนว่าดี และใช้ค้นเอกสารหรือ Stack Overflow ได้เร็วกว่าเยอะ แต่ถ้ากระแสลือที่เกินจริงเป็นเรื่องจริง เราก็น่าจะเห็นนวัตกรรมซอฟต์แวร์พุ่งพรวดจากเครื่องมือพวกนี้แล้วไม่ใช่หรือ? CEO ของ Stripe บอกว่าเครื่องมือ AI เพิ่ม productivity ได้ 100 เท่า ถ้าผ่านมา 3–4 เดือน ตอนนี้ Stripe น่าจะยิงจรวดขึ้นฟ้าได้แล้วมั้ง? Microsoft ก็ทุ่มกับ AI coding เหมือนกัน แล้วทำไม Teams ยังดูไม่ค่อยดีอยู่? เครื่องมือพวกนี้ถูกพูดว่าเป็นการปฏิวัติมาเกินปีแล้ว แต่ความจริงดูเหมือนไม่ต่างจากเมื่อ 3–4 ปีก่อนเท่าไร
ช่วงนี้มีอยู่สองเทรนด์ที่เห็นได้ชัดคือ (1) คนที่ไม่ชำนาญใช้ AI กับโปรเจกต์เล็กๆ น้อยๆ และ (2) นักพัฒนาที่กำหนดสเปกโครงสร้างแอป ไฟล์ อินเทอร์เฟซ tech stack และ test framework ล่วงหน้าแบบละเอียดมาก แล้วค่อยให้ LLM จัดการแบบละเอียดเพื่อฝืนดึงผลลัพธ์ที่พอใช้ได้ออกมา ตัวอย่างบน YouTube เรื่องราว 80–99% ที่ได้ยินกันจาก PR/YouTube จริงๆ แล้วมาจากกลุ่มแรกแทบทั้งหมด ที่รู้สึกว่า productivity ดีขึ้นก็เพราะการคุยกับ LLM การทำเอกสาร การชี้นำ และการแก้ไข รู้สึกเหนื่อยน้อยกว่าการพัฒนาเอง ต่อให้เวลาและแรงรวมจะเท่าเดิมก็ตาม เพราะมันทำให้ความคาดหวังเบาลง
ฉันพยายามหาสตรีมหรือกรณีศึกษาหน้างานที่แสดง productivity boost จริงๆ บน YouTube แต่ยังไม่เคยเห็นเคสไหนที่ทำให้รู้สึกว่า “โห เร็วจริง!”
ความเห็นมีทั้งสุดโต่งด้านบวกและลบ แต่คนส่วนใหญ่จริงๆ กลับเงียบๆ แล้วไป commit งานของตัวเองกันอยู่ดี (ซึ่งฟังดูประชดดี) สำหรับฉันแล้ว ความเร็วเพิ่มขึ้นตั้งแต่ 1.5 ถึง 10 เท่าตามลักษณะงาน รู้สึกได้จริง ข้อดีใหญ่ที่สุดคือภาระทางความคิดลดลงมากในงานประเภทสร้างของใหม่ งานครั้งเดียว boilerplate และ refactor ทำให้รักษาผลงานสม่ำเสมอได้ ฉันยัง “เขียนโค้ดด้วยมือ” เยอะอยู่ และรีวิวแทบทุกบรรทัดจนจบ การปล่อยให้มันทำเองเป็นชั่วโมงๆ นี่คือ Nightmare และฉันก็ใช้มันกับแอป production ที่ดูแลมานานกว่า 10 ปีจริงๆ เพียงแต่ไม่มีเวลาไปเขียนบล็อกโปรโมตไว้ที่ไหน อีกอย่างคือฉันทำงานอยู่ในองค์กรที่เล็กมาก เลยถือบริบททั้งระบบไว้ในมือและจับปัญหาได้เร็วกว่า ถ้าอยู่ในสภาพแวดล้อมที่การเพิ่มประสิทธิภาพส่วนบุคคลสำคัญ มันช่วยยกระดับพื้นฐานได้ชัดเจน แต่ในองค์กรใหญ่คงยากจะได้ประสบการณ์แบบนี้
จากประสบการณ์ของฉัน ฉันจะวางไฟล์ Markdown ชื่อ Claude.md ไว้ที่รากของแต่ละโฟลเดอร์โค้ด เพื่อเพิ่มชุดกฎขั้นต่ำแบบคล้าย pipeline ระบุให้ชัดเรื่องการสร้างและจัดวาง test ให้อยู่ในโฟลเดอร์และรูปแบบที่กำหนด ห้ามสร้างไฟล์ debug และป้องกันการแตกแขนงของคลาสหรือโครงสร้างใหม่โดยไม่จำเป็น พร้อมตั้งกฎให้ reuse เว้นแต่จำเป็นจริงๆ ฉันก็ไม่ได้เขียน prompt ยาวๆ ส่วนใหญ่จะให้ทำเอกสารแผนเฉพาะจุดที่ยังไม่แน่ใจเท่านั้น แม้เจอประเด็นใหม่ๆ ที่อยู่นอกขอบเขตความรู้ของ LLM ก็ยังส่ง input เพิ่มให้น้อยที่สุด ด้วยวิธีนี้ฉันได้ผลลัพธ์แบบ 1 input–1 output อย่างสม่ำเสมอ รวมทั้งลงลึกครบด้วย ช่วงหลังฉันย้ายไปใช้โมเดลใหญ่ตัวอื่นอย่าง Opus ผ่านโหมด CLI แทน Claude Code เพราะถูกกว่า CLI นี่แหละคือพลังจริง ตอนนี้ฉันรัน agent stream พร้อมกัน 60–70 สาย และจัดการโค้ดเบสขนาด 200 ล้านโทเคน (react/typescript/golang) ได้สบายๆ แทบมีแค่ครั้งหรือสองครั้งที่ต้องสั่งเพิ่ม
พอจะลิสต์ได้ไหมว่าเอา agent stream ไปใช้ทำอะไรบ้าง สนใจมาก
อยากรู้ว่าคุณใช้โมเดลอะไรบ้างนอกจาก Anthropic ฉันลอง Kimi K2 แล้วไม่ค่อยเหมาะกับการใช้งานของฉัน
ฉันสงสัยว่า “agent stream” หมายถึงอะไรกันแน่ แล้วจัดการ 60–70 อันยังไง ภาระทางความคิดนี่นึกภาพไม่ออกเลย
บางครั้ง Claude Code ทำให้ productivity พุ่งขึ้นแบบก้าวกระโดดกับงานบางประเภท ฉันแนะนำให้ใช้ slash command โดยเอาบทสนทนาก่อนหน้าไปแปลงเป็น slash command แบบนี้จะค่อยๆ สะสมชุดคำสั่ง primitive ที่นำกลับมาใช้ได้มากขึ้น กรณีของฉันมีโพสต์ไว้บน GitHub make-command.md, improve-command.md
PSA (ข้อมูลสาธารณะ): repo นี้ ใช้เชื่อม Claude Code กับโมเดลไหนก็ได้ เห็นว่าตอนนี้ Kimi-K2 รุ่นล่าสุดทำงานได้ค่อนข้างดี
ฉันก็ลอง Kimi-K2 มาเหมือนกัน มันยังด้อยกว่า Sonnet/Opus 4.0 แต่ด้าน tool calling กลับดีกว่า Gemini 2.5 Pro ถ้ารู้สึกว่า Claude Max (100–200 ดอลลาร์/เดือน) แพงไป แนะนำมาก โมเดลนี้ดีตรงที่เรียบง่ายไม่เยิ่นเย้อ Anthropic เองถ้าโอเพนซอร์ส Claude Code ได้ ก็น่าจะกลายเป็น VSCode แห่งโลก cli coding agent เลยก็ได้ และขอแนะนำ opencode ด้วย รองรับทุกโมเดลแบบเนทีฟและมีความสามารถคล้าย Claude Code
ถ้าจะใช้หลายโมเดล ฉันแนะนำ sst/opencode ไปเลย (ฉันก็ใช้กับ Claude Pro เหมือนกัน)
เผื่อคนที่ยังไม่เคยลอง CC — สามารถติดตั้งไคลเอนต์ CC ผ่าน npm แล้วใช้ได้ฟรี
ฉันลอง “vibe coding” แอป Python ง่ายๆ ด้วย Claude Code, local LLM, Continue, VSCode แล้วมาเจอ free tier ของ Claude เลยลองเอาโค้ดที่กำลังทำอยู่กับผลลัพธ์จาก LLM ใส่เข้าไป มันช่วยสรุปและแก้ทั้ง error กับ update ได้แม่นมากในรอบเดียว สนุกดี! จากนั้นเลยขยับไปอีกขั้น โดยให้ ChatGPT ช่วยทำสเปกกับ prompt สำหรับโปรเจกต์เกม 2D บน pygame (สไตล์ Manic Miner) แล้วเอาไปใส่ Claude ปรากฏว่า Claude อ้างถึงเมธอดที่ไม่มีอยู่จริงตลอด หรือพูดจาเหลวไหลเรื่องเวอร์ชันของโค้ดเบส แม้จะชี้ด้วยเลขบรรทัดและโค้ดรอบข้างให้ชัด มันก็ยัง gaslighting อยู่ อยากรู้ว่าควรแก้ยังไง ไม่ได้หวังความสมบูรณ์แบบ แต่รู้สึกเหมือนติดกำแพงเดียวกับตอนใช้ local LLM สุขภาพฉันไม่ค่อยดีเลยทำเป็นช่วงๆ ถ้ามีคำแนะนำจะขอบคุณมาก
มีโอกาสสูงว่าคุณกำลังติดอยู่ใน “นรกของโค้ดที่เต็มไปด้วยอินเทอร์เฟซกำกวมและสมมติฐานซ่อนเร้น” ในกรณีแบบนี้ ทางที่ดีกว่าคือสรุปผลจาก ChatGPT ก่อนหน้าทั้งหมดใหม่ อธิบายว่าเกมตอนนี้ทำอะไรได้บ้าง แล้วลิสต์ฟีเจอร์ทุกอย่างแบบลงลึก จากนั้นค่อยป้อนเอกสารนี้ให้ Claude แล้วให้มันแตก requirement ใหม่ตั้งแต่ต้น แบบนี้มักได้ผลลัพธ์ที่สะอาดกว่ามาก Claude สามารถสร้างตัวอย่างที่ยอดเยี่ยมได้แม้แบบ zero-shot และอย่างแย่ที่สุดก็ยังให้มันขัดเกลางานของตัวเองซ้ำเป็นรอบๆ ได้ ถ้ามันยังสร้างฟีเจอร์เพี้ยนๆ อยู่ ก็แนะนำให้ติดตั้ง context7 MCP server แล้วระบุไปตรงๆ ให้ Claude ใช้ context7
นี่คือข้อจำกัดพื้นฐานของเทคโนโลยี LLM มันสร้างลำดับโทเคนที่ “ดูน่าจะใช่ที่สุด” ในเชิงความน่าจะเป็น แต่ถ้า “ดูน่าจะใช่” ไม่ตรงกับ “ถูกต้อง” ก็จบ แต่ละ LLM ก็มีเกณฑ์เรื่องความ “น่าจะใช่” นี้ต่างกันไปตามการฝึกและการ fine-tune
หลังตั้งค่าพื้นฐานแล้ว ฉันอยากรู้ว่าคนอื่นมีวิธีเพิ่มเติมอะไรบ้างเพื่อให้เครื่องมือนี้ทำงานได้ดีจริงๆ หมายถึงวิธีเชิงปฏิบัติในการจัดการบริบท/context และการจัดโครงสร้างโค้ดเบส เพื่อให้เครื่องมือกำหนดทิศทางเองได้อย่างแม่นยำ ฉันรวบรวมความคิดไว้ในโพสต์นี้ คิดว่าน่าจะยังมีวิธีการที่ดีกว่านี้ออกมาอีกเรื่อยๆ
ฉันได้ alpha จาก Claude Code หลายอย่าง แต่กำลังกังวลเรื่องการขยายไปใช้ทั้งทีม อยากรู้ว่ามีวิธีแชร์ทิปการใช้งานจริงหรือ best practice เพื่อให้เพื่อนร่วมทีมหรือคนที่ฉันดูแล ใช้ Claude Code ได้อย่างมีประสิทธิภาพหรือไม่