จาก AI ทำงานทีละคำสั่ง สู่การใช้ Claude หลายตัวทำงานพร้อมกันอย่างเป็นระบบ เมื่อเริ่มใช้ Claude Code หรือ Claude Cowork ใหม่ ๆ รูปแบบการทำงานของคนส่วนใหญ่มักเป็นแบบเส้นตรง
เราเปิดโปรเจกต์ขึ้นมา มอบหมายงานหนึ่งชิ้นให้ Claude จากนั้นรอให้ Claude วิเคราะห์ แก้ไขไฟล์ ทดสอบ และส่งผลลัพธ์กลับมา เมื่อเสร็จแล้วจึงเริ่มงานถัดไป
วิธีนี้ใช้งานง่ายและควบคุมได้ไม่ยาก แต่เมื่อเราเริ่มใช้ Claude กับงานจริงที่มีหลายฟีเจอร์ หลายเอกสาร หรือหลายโปรเจกต์ การทำงานทีละงานจะกลายเป็นคอขวดทันที
เพราะต่อให้ AI ทำงานเร็วแค่ไหน หากเรายังจัดคิวให้ AI ทำงานทีละเรื่อง ความเร็วโดยรวมก็ยังถูกจำกัดด้วยรูปแบบการทำงานแบบเดิม
แนวคิดสำคัญจึงไม่ใช่เพียงการสั่ง Claude ให้เก่งขึ้น แต่คือการออกแบบระบบให้ Claude หลาย Session สามารถทำงานพร้อมกัน โดยไม่แก้ไฟล์ชนกัน ไม่แย่ง Context กัน และไม่สร้างความสับสนตอนนำผลงานกลับมารวมกัน
ปัญหาของการเปิด Claude Code หลาย Session ในโปรเจกต์เดียวกัน
สมมติว่าคุณกำลังพัฒนาเว็บแอปพลิเคชัน และมีงานที่ต้องทำพร้อมกันหลายเรื่อง เช่น
- เพิ่มระบบ Authentication
- แก้ปัญหาหน้าชำระเงิน
- เขียน Automated Test
- ปรับปรุงหน้า Dashboard
- อัปเดตเอกสารสำหรับนักพัฒนา
ในทางทฤษฎี เราสามารถเปิด Terminal หลายหน้าต่าง แล้วเปิด Claude Code หลาย Session ได้ทันที
แต่ถ้าทุก Session ทำงานอยู่ในโฟลเดอร์โปรเจกต์เดียวกัน ปัญหาที่อาจเกิดขึ้นคือ Claude สอง Session แก้ไฟล์เดียวกัน Session หนึ่งลบโค้ดที่อีก Session เพิ่งเขียน หรือผลการทดสอบเปลี่ยนไปเพราะมีอีก Session กำลังแก้โปรเจกต์อยู่
แม้แต่กรณีที่แต่ละ Session แก้คนละไฟล์ ก็ยังอาจชนกันได้ หากทั้งสองงานแก้ไฟล์ส่วนกลาง เช่น package.json, routes, database schema, configuration หรือไฟล์ shared component
ทางเลือกแบบเดิมคือใช้ Git Branch แล้วสลับไปมาด้วยการ commit หรือ git stash แต่กระบวนการนี้ทำให้เรายังทำงานได้ทีละ Branch ใน Working Directory เดิม
อีกทางเลือกคือ Copy โปรเจกต์ออกเป็นหลายโฟลเดอร์ แต่วิธีนี้ทำให้เปลืองพื้นที่ จัดการ Dependency ยาก และมีโอกาสสับสนว่าโฟลเดอร์ใดเป็นเวอร์ชันล่าสุด
Claude Worktree ทำให้แต่ละ Session มีพื้นที่ทำงานของตัวเอง
Git Worktree คือความสามารถของ Git ที่ทำให้ Repository เดียวมี Working Directory ได้หลายชุด
แต่ละ Worktree สามารถอยู่คนละ Branch มีไฟล์แยกจากกัน แต่ยังใช้ประวัติ Commit และ Remote Repository ร่วมกัน
Claude Code นำแนวคิดนี้มาใช้งานผ่านคำสั่งง่าย ๆ ดังนี้
claude --worktree feature-auth
หรือเขียนแบบสั้นได้ว่า
claude -w feature-auth
Claude Code จะสร้าง Worktree แยกสำหรับงานนี้ พร้อมสร้าง Branch ใหม่ให้อัตโนมัติ โดยค่าเริ่มต้นจะมีโครงสร้างประมาณนี้
.claude/worktrees/feature-auth
และ Branch จะมีชื่อประมาณนี้
worktree-feature-auth
จากนั้น Claude Session ที่เปิดขึ้นมาจะทำงานภายใน Working Directory ชุดนี้ ไม่ได้แก้ไฟล์ในโฟลเดอร์หลักโดยตรง
หมายความว่าใน Terminal แรก คุณอาจให้ Claude พัฒนาระบบ Authentication
claude -w feature-auth
ขณะที่ Terminal ที่สองกำลังแก้ปัญหาหน้าชำระเงิน
claude -w fix-checkout
และ Terminal ที่สามกำลังเขียนชุดทดสอบ
claude -w add-api-tests
แต่ละ Session มีไฟล์และ Branch ของตัวเอง การแก้ไขจาก Session หนึ่งจึงไม่ไปทับไฟล์ของอีก Session
นี่คือจุดที่ Claude Code เปลี่ยนจาก “ผู้ช่วยเขียนโค้ดหนึ่งตัว” ไปเป็น “ทีมพัฒนาซอฟต์แวร์หลายตัวที่ทำงานพร้อมกัน”
Worktree ไม่ได้ป้องกัน Merge Conflict ทุกกรณี
การใช้ Worktree ป้องกันไม่ให้ Session ต่าง ๆ แก้ไฟล์ใน Working Directory เดียวกันโดยตรง แต่ไม่ได้หมายความว่าจะไม่มี Merge Conflict เกิดขึ้นเลย
ถ้า Session สองตัวแก้โค้ดส่วนเดียวกัน เมื่อเรานำ Branch ทั้งสองกลับมา Merge ก็ยังมีโอกาสเกิด Conflict ได้
ความแตกต่างคือ Conflict จะไม่เกิดขึ้นระหว่างที่ Claude กำลังทำงาน แต่จะถูกเลื่อนไปอยู่ในขั้นตอน Review และ Integration ซึ่งเป็นจุดที่เราสามารถตรวจสอบและตัดสินใจได้อย่างเป็นระบบมากกว่า
ดังนั้น งานที่เหมาะกับการทำแบบขนานควรเป็นงานที่มีขอบเขตค่อนข้างแยกจากกัน เช่น
- Frontend กับ Backend
- Feature ใหม่กับ Bug Fix
- การเขียนโค้ดกับการเขียน Test
- การพัฒนา Feature กับการอัปเดต Documentation
- การวิเคราะห์ปัญหากับการทดลองสร้าง Prototype
ถ้างานสองชิ้นต้องแก้ Architecture หรือไฟล์แกนกลางชุดเดียวกันจำนวนมาก การทำตามลำดับอาจมีประสิทธิภาพมากกว่า
วิธีจัด Claude Code ให้ทำงานเหมือนทีม
การเปิดหลาย Session ไม่ได้ทำให้การทำงานเร็วขึ้นเสมอไป หากทุก Session ได้รับคำสั่งที่คลุมเครือหรือทำงานทับซ้อนกัน
หัวใจสำคัญคือการแบ่งงานให้แต่ละ Session มีความรับผิดชอบที่ชัดเจน
กำหนดผลลัพธ์ของแต่ละ Session
แทนที่จะสั่งว่า
ช่วยปรับปรุงระบบ Login
ควรกำหนดผลลัพธ์ให้ชัดเจน เช่น
เพิ่มระบบ Login ด้วยอีเมลและรหัสผ่าน ขอบเขตงาน: - แก้เฉพาะส่วน Authentication - เพิ่ม Validation - เพิ่ม Unit Test - ห้ามแก้ Payment และ Admin Module - รัน Test ที่เกี่ยวข้องก่อน Commit - สรุปไฟล์ที่แก้และสิ่งที่ต้องตรวจสอบตอน Merge
คำสั่งลักษณะนี้ทำหน้าที่เหมือน Brief งานของสมาชิกในทีม ช่วยลดโอกาสที่ Claude จะขยายขอบเขตงานเกินความจำเป็น
แบ่งงานตามขอบเขตของระบบ
ตัวอย่างการแบ่ง Session อาจเป็นดังนี้
Session: feature-auth รับผิดชอบ Authentication และ User Session Session: fix-checkout รับผิดชอบ Checkout และ Payment Validation Session: api-tests รับผิดชอบ Integration Test ของ API Session: update-docs รับผิดชอบ README และ Developer Documentation
แต่ละ Session ควรรู้ทั้งสิ่งที่ต้องทำและสิ่งที่ไม่ควรแตะต้อง
ให้แต่ละ Session Commit งานของตัวเอง
เมื่อ Claude ทำงานเสร็จ ควรให้ตรวจสอบผลลัพธ์ รัน Test และ Commit การเปลี่ยนแปลงไว้ใน Branch ของ Worktree
ตัวอย่างคำสั่งคือ
ตรวจสอบการเปลี่ยนแปลงทั้งหมด รัน test และ lint ที่เกี่ยวข้อง แก้ปัญหาที่พบ จากนั้น commit ด้วยข้อความที่อธิบายสิ่งที่เปลี่ยนแปลงอย่างชัดเจน
เมื่อทุก Branch มี Commit ที่สะอาด การ Review และ Merge จะทำได้ง่ายกว่าการนำไฟล์ที่ยังค้างอยู่มารวมกัน
สิ่งที่ต้องระวังเกี่ยวกับไฟล์ Environment
Worktree เป็น Working Directory ชุดใหม่ ดังนั้นไฟล์ที่ไม่ได้อยู่ใน Git เช่น .env, .env.local หรือไฟล์ Configuration ส่วนตัว อาจไม่ได้ตามไปอยู่ใน Worktree ใหม่โดยอัตโนมัติ
Claude Code รองรับไฟล์ .worktreeinclude สำหรับกำหนดว่าไฟล์ใดควรถูกคัดลอกเข้า Worktree ใหม่
ตัวอย่างเช่น
.env .env.local config/secrets.json
ควรเลือกเฉพาะไฟล์ที่จำเป็นและถูก Ignore จาก Git อยู่แล้ว ไม่ควรนำ Secret หรือ Credential ไป Commit ลง Repository
นอกจากนี้ควรเพิ่มรายการต่อไปนี้ไว้ใน .gitignore
.claude/worktrees/
เพื่อไม่ให้เนื้อหาภายใน Worktree ปรากฏเป็น Untracked Files ในโปรเจกต์หลัก
เมื่อทำเสร็จแล้วนำงานกลับมารวมอย่างไร
หลังจากแต่ละ Session ทำงานเสร็จ อย่ารีบ Merge ทุก Branch เข้าด้วยกันทันที
ควรมีกระบวนการ Integration ที่ชัดเจน
ขั้นแรก ให้ตรวจสอบ Commit และ Diff ของแต่ละ Branch ว่าแก้เฉพาะขอบเขตที่กำหนดหรือไม่
ขั้นที่สอง ให้ Merge Branch ทีละ Branch เพื่อให้ระบุได้ง่ายว่าปัญหาเกิดจากงานใด
ขั้นที่สาม ให้รัน Test ทั้งระบบหลังจาก Merge แต่ละครั้ง เพราะแม้แต่ละ Branch จะผ่าน Test ของตัวเอง แต่เมื่อนำมารวมกันอาจเกิดปัญหาด้าน Dependency หรือ Business Logic ได้
ขั้นสุดท้าย ให้ Claude อีก Session ทำหน้าที่เป็น Reviewer โดยไม่ใช่ผู้เขียนโค้ดชุดเดียวกัน เช่น
Review การเปลี่ยนแปลงจาก Branch feature-auth ตรวจสอบ: - Bug และ Edge Case - Security - Breaking Change - Test Coverage - ผลกระทบต่อ Module อื่น ยังไม่ต้องแก้โค้ด ให้สรุปสิ่งที่ควรแก้ก่อน
แนวทางนี้ทำให้ Claude ไม่ได้ทำหน้าที่เพียงผู้สร้าง แต่ยังทำหน้าที่เป็นผู้ตรวจสอบคุณภาพของงานจาก Claude ตัวอื่นด้วย
จาก Claude Code Worktree สู่แนวคิดของ Claude Cowork
Claude Worktree เป็นตัวอย่างในโลกของการพัฒนาซอฟต์แวร์ แต่หลักการเดียวกันสามารถนำไปใช้กับ Claude Cowork และงานธุรกิจทั่วไปได้
Claude Cowork ถูกออกแบบมาให้รับเป้าหมายของงาน แล้วดำเนินกระบวนการหลายขั้นตอนผ่านไฟล์ โฟลเดอร์ เอกสาร และแอปพลิเคชันบนคอมพิวเตอร์
แม้งานเอกสารจะไม่มี Git Branch เหมือนงานเขียนโค้ด แต่ก็ยังต้องการ “พื้นที่ทำงานที่แยกจากกัน” เช่นเดียวกัน
ตัวอย่างเช่น ทีมการตลาดอาจเปิดงานหลายชุดพร้อมกัน
Cowork Session 1 วิเคราะห์ความคิดเห็นลูกค้าจากไฟล์แบบสอบถาม Cowork Session 2 สร้างร่างแผนการตลาดไตรมาสหน้า Cowork Session 3 ตรวจสอบและจัดหมวดหมู่ Creative ที่ใช้ไปแล้ว Cowork Session 4 สรุปผลการแข่งขันและข้อเสนอของคู่แข่ง
แต่ละ Session ควรมีโฟลเดอร์ต้นทาง โฟลเดอร์ผลลัพธ์ รูปแบบไฟล์ และเกณฑ์ความสำเร็จของตัวเอง
ตัวอย่างโครงสร้างคือ
AI-Workspace/
├── customer-insight/
│ ├── input/
│ └── output/
├── campaign-plan/
│ ├── input/
│ └── output/
├── creative-audit/
│ ├── input/
│ └── output/
└── competitor-research/
├── input/
└── output/
แนวคิดนี้ทำหน้าที่คล้าย Worktree ในโลกของงานเอกสาร แต่แทนที่จะแยกด้วย Git Branch เราแยกด้วย Task, Folder, Input และ Output
หลัก One Task, One Workspace, One Outcome
ไม่ว่าจะใช้ Claude Code หรือ Claude Cowork หลักการสำคัญคือ
หนึ่งงาน หนึ่งพื้นที่ทำงาน หนึ่งผลลัพธ์หลัก หนึ่งผู้รับผิดชอบในการตรวจสอบ
การเปิด Claude หลาย Session โดยไม่มีโครงสร้าง อาจทำให้เราได้งานจำนวนมากขึ้น แต่ต้องเสียเวลามากกว่าเดิมในการตรวจสอบ จัดระเบียบ และแก้ความไม่สอดคล้องกัน
ตรงกันข้าม หากแต่ละ Session มีขอบเขตและผลลัพธ์ที่ชัดเจน Claude หลายตัวจะทำหน้าที่เหมือนทีมที่แบ่งงานกันอย่างเป็นระบบ
Claude Cowork เหมาะกับการทำงานขนานแบบใด
งานที่เหมาะกับการแยกเป็นหลาย Session ได้แก่ งานที่ใช้ข้อมูลต้นทางร่วมกัน แต่สามารถผลิตผลลัพธ์แยกจากกันได้
ตัวอย่างเช่น จากไฟล์รายงานยอดขายชุดเดียวกัน เราอาจแยกงานเป็น
- Session หนึ่งวิเคราะห์แนวโน้มยอดขาย
- Session หนึ่งค้นหาสินค้าที่กำไรลดลง
- Session หนึ่งแบ่งกลุ่มลูกค้า
- Session หนึ่งสร้าง Executive Summary
- Session หนึ่งออกแบบแผนปฏิบัติการสำหรับเดือนถัดไป
หลังจากนั้นจึงเปิด Session สุดท้ายทำหน้าที่รวบรวม ตรวจสอบความสอดคล้อง และสร้างรายงานฉบับสมบูรณ์
นี่คือโครงสร้างแบบ Map and Reduce
ช่วง Map คือการกระจายงานให้ Claude หลาย Session วิเคราะห์คนละมุม
ช่วง Reduce คือการนำผลลัพธ์กลับมารวม สังเคราะห์ และตรวจสอบอีกครั้ง
อย่าวัดความเร็วจากจำนวน Session ที่เปิด
การเปิด Claude พร้อมกันสิบ Session ไม่ได้หมายความว่างานจะเร็วขึ้นสิบเท่า
ยิ่งมี Session มาก ต้นทุนในการประสานงานก็ยิ่งสูงขึ้น ทั้งการเขียน Brief การเตรียมไฟล์ การติดตามสถานะ การตรวจสอบคุณภาพ และการนำผลลัพธ์กลับมารวมกัน
จุดเริ่มต้นที่เหมาะสมจึงอาจเป็นเพียงสองหรือสาม Session เช่น
Builder สร้างหรือแก้ไขงานหลัก Tester ตรวจสอบ ทดสอบ และหา Edge Case Reviewer ตรวจคุณภาพ ความถูกต้อง และความสอดคล้อง
เมื่อ Workflow นี้เริ่มนิ่ง จึงค่อยเพิ่มจำนวน Session ตามความซับซ้อนของงาน
จาก Prompt Engineer สู่ AI Workflow Architect
ในยุคแรก ทักษะสำคัญคือการเขียน Prompt ให้ AI ตอบได้ดี
แต่เมื่อ AI สามารถแก้ไฟล์ ใช้เครื่องมือ และทำงานหลายขั้นตอนได้ ทักษะที่สำคัญกว่าจะกลายเป็นการออกแบบ Workflow
ผู้ใช้งานต้องตัดสินใจว่า
- งานใดควรทำพร้อมกัน
- งานใดต้องรอผลจากงานอื่น
- แต่ละ Agent ควรเข้าถึงไฟล์ใด
- Agent ใดเป็นผู้สร้าง
- Agent ใดเป็นผู้ตรวจสอบ
- จุดใดต้องมีมนุษย์อนุมัติ
- ผลลัพธ์จากหลาย Agent จะถูกรวมกันอย่างไร
คนที่ใช้ AI ได้เร็วที่สุดจึงอาจไม่ใช่คนที่เขียน Prompt ยาวที่สุด แต่คือคนที่สามารถแบ่งงาน กำหนดขอบเขต และจัดการ Agent หลายตัวให้ทำงานร่วมกันได้
Claude Worktree เป็นมากกว่าคำสั่งสำหรับแยก Branch
มันคือตัวอย่างของวิธีคิดใหม่ที่เปลี่ยนจากการถามว่า
“ฉันจะสั่ง Claude ทำงานนี้อย่างไร”
ไปเป็นคำถามว่า
“ฉันจะแบ่งงานนี้ให้ Claude หลายตัวทำพร้อมกัน โดยยังควบคุมคุณภาพได้อย่างไร”
เมื่อเปลี่ยนวิธีคิดจากการใช้ AI เป็นผู้ช่วยรายบุคคล ไปสู่การออกแบบ AI ให้ทำงานเป็นทีม ความเร็วที่เพิ่มขึ้นจะไม่ได้มาจากโมเดลที่ตอบเร็วกว่าเดิมเพียงอย่างเดียว
แต่มาจากระบบงานที่สามารถเดินหน้าได้หลายทางพร้อมกัน โดยแต่ละทางไม่ชนกัน และสามารถนำกลับมารวมเป็นผลลัพธ์เดียวที่ตรวจสอบได้
