- เปิดเผยสภาพแวดล้อมการทำงานและเวิร์กโฟลว์จริงของตนเอง โดยแนะนำวิธี รัน Claude แบบขนาน 5 ตัวในเทอร์มินัล และรันเพิ่มอีก 5~10 ตัวบนเว็บ
- ใช้ Opus 4.5 with thinking กับทุกงาน แม้จะใหญ่และช้ากว่า แต่ต้องปรับจูนน้อยกว่าและใช้เครื่องมือได้เก่ง จึงเร็วกว่าในภาพรวม
- ทั้งทีม แชร์ไฟล์
CLAUDE.md ไฟล์เดียวร่วมกัน และทุกครั้งที่ Claude ทำพฤติกรรมผิด ก็จะเพิ่มเนื้อหาลงไปเพื่อสะสมผลการเรียนรู้
- เริ่มเซสชันส่วนใหญ่ด้วย Plan mode ปรับแผนให้ละเอียดพอแล้วจึงสลับไปโหมด auto-accept เพื่อให้ จบงานในครั้งเดียว
- ปัจจัยสำคัญที่สุดที่ทำให้คุณภาพของผลลัพธ์สุดท้ายดีขึ้น 2~3 เท่าคือการให้ ลูปป้อนกลับที่ Claude ใช้ตรวจสอบงานได้เอง
1/ การตั้งค่าสภาพแวดล้อมสำหรับรันแบบขนาน
- รัน Claude 5 ตัวแบบขนานในเทอร์มินัล ตั้งหมายเลขแท็บ 1~5 และใช้ การแจ้งเตือนของระบบ เพื่อดูว่าตอนไหนต้องมีการป้อนข้อมูล
2/ การรันแบบขนานทั้งบนเว็บและโลคัล
- บนเว็บ claude.ai/code ก็ รัน Claude เพิ่มอีก 5~10 ตัวแบบขนาน ควบคู่กับ Claude บนเครื่อง
- ส่งต่อเซสชันโลคัลไปยังเว็บ (ใช้
&) หรือเริ่มเซสชันจาก Chrome โดยตรง แล้วสลับไปมาสองทางด้วย --teleport
- ยังใช้วิธีเริ่มหลายเซสชันทุกเช้าและระหว่างวันจากแอป iOS แล้วค่อยกลับมาตรวจภายหลัง
3/ การเลือกโมเดล: Opus 4.5 with thinking
- ใช้ Opus 4.5 with thinking กับทุกงาน
- เป็น โมเดลสำหรับเขียนโค้ดที่ดีที่สุด เท่าที่เคยใช้มา
- แม้จะใหญ่และช้ากว่า Sonnet แต่ ต้องการการชี้นำ (steering) น้อยกว่า และ ใช้เครื่องมือได้เก่งกว่า
- สุดท้ายแล้วจึงให้ผลลัพธ์ที่ เกือบจะเร็วกว่าเสมอ เมื่อเทียบกับโมเดลขนาดเล็ก
4/ การสะสมองค์ความรู้ระดับทีมผ่าน CLAUDE.md
- ดูแล ไฟล์ CLAUDE.md ไฟล์เดียวที่ทั้งทีมใช้ร่วมกัน ในรีโพซิทอรี Claude Code
- เช็กอินเข้า git และทั้งทีม ช่วยกันเพิ่มเนื้อหาหลายครั้งต่อสัปดาห์
- ทุกครั้งที่ Claude ทำพฤติกรรมผิด จะเพิ่มลงใน CLAUDE.md เพื่อ ป้องกันไม่ให้พลาดแบบเดิมอีกครั้งในอนาคต
- ทีมอื่น ๆ ก็มี CLAUDE.md ของตัวเองเช่นกัน และแต่ละทีมรับผิดชอบให้ไฟล์ของตนเป็นปัจจุบัน
5/ อัปเดต CLAUDE.md ระหว่างโค้ดรีวิว
- ระหว่างโค้ดรีวิว จะ แท็ก @.claude ใน PR ของเพื่อนร่วมทีมเพื่อเพิ่มเนื้อหาลงใน CLAUDE.md เป็นส่วนหนึ่งของ PR
- ใช้ Claude Code GitHub Action(/install-github-action)
- เป็นแนวทางที่คล้ายกับแนวคิด Compounding Engineering ของ Dan Shipper
6/ เวิร์กโฟลว์ Plan mode และการยอมรับอัตโนมัติ
- เริ่มเซสชันส่วนใหญ่ด้วย Plan mode (shift+tab สองครั้ง)
- หากเป้าหมายคือการทำ PR ก็จะคุยกับ Claude ใน Plan mode จนกว่าจะพอใจกับแผน
- เมื่อแผนชัดเจนแล้วจึงสลับไป auto-accept edits mode ซึ่งโดยมาก Claude จะ ทำเสร็จได้ในครั้งเดียว (1-shot)
- แผนที่ดีสำคัญมากจริง ๆ
7/ การทำงานซ้ำให้อัตโนมัติด้วย slash command
- ใช้ slash command กับทุก เวิร์กโฟลว์ “inner loop” ที่ทำหลายครั้งต่อวัน
- ช่วยประหยัดการพิมพ์พรอมป์ต์ซ้ำ ๆ และ Claude ก็ใช้เวิร์กโฟลว์นี้ได้เช่นกัน
- คำสั่งจะถูกเช็กอินเข้า git และเก็บไว้ในไดเรกทอรี .claude/commands/
- ตัวอย่างเช่น ใช้ slash command /commit-push-pr หลายสิบครั้งต่อวัน
8/ การใช้ sub-agent
- ใช้หลาย sub-agent เป็นประจำ
- code-simplifier: ทำให้โค้ดเรียบง่ายขึ้นหลังจาก Claude ทำงานเสร็จ
- verify-app: มีคำแนะนำละเอียดสำหรับการทดสอบ end-to-end ของ Claude Code
- คล้ายกับ slash command ในแง่ที่เป็นการทำ เวิร์กโฟลว์ที่พบบ่อยที่สุดใน PR ส่วนใหญ่ให้เป็นอัตโนมัติ
9/ ฟอร์แมตโค้ดด้วย PostToolUse hook
- ใช้ PostToolUse hook เพื่อจัดการการฟอร์แมตโค้ดของ Claude
- โดยปกติ Claude สร้างโค้ดที่ฟอร์แมตมาดีอยู่แล้ว และ hook จะ จัดการอีก 10% ที่เหลือ เพื่อป้องกันข้อผิดพลาดเรื่องฟอร์แมตใน CI ภายหลัง
10/ วิธีจัดการสิทธิ์
- ไม่ใช้ --dangerously-skip-permissions
- แต่ใช้ /permissions เพื่อ อนุญาตล่วงหน้า ให้กับคำสั่ง bash ทั่วไปที่ทราบว่าปลอดภัยในสภาพแวดล้อมนั้น
- ช่วยหลีกเลี่ยงพรอมป์ต์ขอสิทธิ์ที่ไม่จำเป็น
- ส่วนใหญ่ถูกเช็กอินไว้ใน .claude/settings.json และแชร์ร่วมกับทีม
11/ การใช้การผสานเครื่องมือของ Claude Code
- ให้ Claude Code ใช้เครื่องมือทั้งหมดแทนผู้ใช้
- ค้นหาและโพสต์ใน Slack (ใช้ MCP server)
- รันคิวรี BigQuery (ผ่าน bq CLI) เพื่อตอบคำถามเชิงวิเคราะห์
- ดึง error log จาก Sentry
- การตั้งค่า Slack MCP ถูกเช็กอินไว้ใน .mcp.json และแชร์ร่วมกับทีม
12/ วิธีจัดการงานระยะยาว
- สำหรับงานที่ยาวมาก จะเลือกหนึ่งในสามวิธีต่อไปนี้:
- ใน sandbox จะใช้ --permission-mode=dontAsk หรือ --dangerously-skip-permissions เพื่อให้ Claude โฟกัสกับงานได้โดยไม่ต้องมีพรอมป์ต์ขอสิทธิ์
13/ เคล็ดลับที่สำคัญที่สุด: ให้ลูปป้อนกลับสำหรับการตรวจสอบ
- ปัจจัยที่สำคัญที่สุด สำหรับการได้ผลลัพธ์ที่ยอดเยี่ยมจาก Claude Code คือ: ต้อง ให้วิธีที่ Claude ใช้ตรวจสอบงานของตัวเองได้
- หากมีลูปป้อนกลับนี้ คุณภาพของผลลัพธ์สุดท้ายจะ ดีขึ้น 2~3 เท่า
- การเปลี่ยนแปลงทุกอย่างที่ลงสู่ claude.ai/code จะถูก Claude ทดสอบด้วย ส่วนขยาย Chrome ของ Claude
- เปิดเบราว์เซอร์ ทดสอบ UI และวนซ้ำจนกว่าโค้ดจะทำงานได้และ UX ดีพอ
- วิธีตรวจสอบจะแตกต่างกันไปตามโดเมน
- อาจง่ายแค่รันคำสั่ง bash
- หรือรัน test suite
- หรือทดสอบแอปในเบราว์เซอร์หรือ phone simulator
- ต้อง ลงทุนในการสร้างกระบวนการตรวจสอบนี้ให้แข็งแรง
11 ความคิดเห็น
เพราะเป็นผู้สร้างเอง คงไม่โดนจำกัดลิมิตหรอกมั้ง..?
ผมเลยแอบคิดว่า API ภายในบริษัทน่าจะไม่จำกัดหรือเปล่า เพราะเคยเห็นโพสต์ที่บอกว่าตัวผลิตภัณฑ์ Claude Code เองก็เขียนด้วย Claude Code.. ฮ่าๆ;;
อย่างนั้นก็ไม่โดนคิดเงินอยู่ดีเหรอ..? แพงนะ..
ที่บริษัทไม่มีการจำกัดการใช้งาน ผมไม่ได้อยู่ Anthropic แต่เป็นบิ๊กเทค และ
sonnet 4.5ก็แทบจะใช้งานได้ไม่จำกัดฉันเป็นสมาชิก Max แค่อ่านอย่างเดียวก็รู้สึกเหมือนโทเคนถูกดูดไปแล้วนะ
เคล็ดลับการใช้งานจริงที่ผู้สร้าง Claude Code เปิดเผย
จุดร่วมของ skills..
ดูจากภาพในต้นฉบับ เหมือนเขาเปิดใช้งาน 5 ตัวบนเครื่องโลคัล และ 5 ตัวบนเว็บเพื่อทำงานนะครับ มีเหตุผลอะไรเป็นพิเศษหรือเปล่าที่แบ่งเป็น 5 กับ 5 แบบนี้ แทนที่จะใช้บนเครื่องโลคัล 10 ตัวและบนเว็บ 10 ตัวไปเลย?
บนเว็บน่าจะเอาไว้เช็กอะไรเล็ก ๆ น้อย ๆ และทำงานง่าย ๆ บน
git branchเดียวกับที่ทำงานอยู่ในเครื่อง локัล(กะจะทำงานระหว่างเดินทางด้วยเหรอ??)
เดาเอาว่าเวลาสร้างไว้ 5 อันบนเครื่องโลคัล ก็น่าจะแยก
git branchตามการใช้งานเพื่อจัดการคอนเท็กซ์และแต่ละแท็บก็อาจเป็นแบบนี้ เช่น
แท็บ 1 สร้าง DB query และวางแผน, แท็บ 2 แบ็กเอนด์, แท็บ 3 พัฒนา API, แท็บ 4 ฟรอนต์เอนด์, แท็บ 5 รีวิวโค้ด ฯลฯ แล้วน่าจะรันแบบขนานในขอบเขตที่ชนกันน้อยที่สุด
ผมเดาเอานะ แต่คงเป็นเพราะถ้าจะเข้าถึงผ่านอุปกรณ์มือถือระหว่างเดินทาง ก็น่าจะต้องเป็นเว็บเซสชันล่ะมั้ง ในสถานการณ์ที่ภาระทางความคิดรับมือได้ราว ๆ 10 อย่าง ก็คงแบ่งเป็น 5 อย่างที่ทำงานเชิงลึกบนพีซีแบบโลคัล และที่เหลือก็ทำงานแบบรวดเร็วผ่านมือถือประมาณนั้นครับ
ก็อาจจะเป็นแบบนั้นก็ได้