ทำไม Workflow ของคุณถึงไม่เปลี่ยน ทั้งที่ใช้ Claude Code ทุกวัน
"ผมจำได้ว่าตอนแรกที่รัน /init แต่ไม่รู้ว่าอัปเดตล่าสุดเมื่อไหร่"
ฟังดูคุ้นๆ ไหม? คุณติดตั้ง Claude Code ใช้เวลาสองสามวันแรกในการตั้งค่า และคุณก็คุยกับมันทุกวัน แต่เมื่อเทียบกับสามเดือนก่อน โครงสร้างการทำงานของคุณก็ยังคงเหมือนเดิมเป็นส่วนใหญ่
นี่ไม่ใช่ปัญหาของการใช้งาน แต่เป็นปัญหาของการวางตำแหน่ง
ถ้าคุณยังคงใช้ Claude Code เป็นแค่ "เครื่องมือที่ตอบเมื่อถูกถาม" คุณจะต้องพิมพ์คำสั่งเดิมทุกเช้า ได้รับคำตอบที่คล้ายกัน และคัดลอกมันไปใส่ในงานของคุณ คุณอาจมีประสิทธิภาพมากขึ้น แต่วิธีที่งานของคุณดำเนินไปนั้นไม่ได้เปลี่ยนแปลงโดยพื้นฐาน
การเปลี่ยนแปลงจะเกิดขึ้นเมื่อคุณเริ่มมองว่า Claude Code เป็น "เป้าหมายของการออกแบบ" ใครรู้อะไรในบริบทไหน? งานไหนที่มอบหมายให้ใคร? อะไรที่เคลื่อนที่แม้ในขณะที่ไม่มีมนุษย์อยู่? เมื่อคุณเริ่มคิดถึงสิ่งเหล่านี้ในฐานะการออกแบบ พฤติกรรมของ Claude Code จะเปลี่ยนไปอย่างสิ้นเชิง
ฟีเจอร์ 27 อย่างที่เผยแพร่โดย @sairahul1 (https://x.com/sairahul1/status/2070428662080618607) ได้รวบรวมฟังก์ชันต่างๆ ที่ควรใช้จากมุมมองการออกแบบนี้ไว้อย่างเป็นระบบ Swarm ได้ตีความสิ่งเหล่านี้ผ่านเลนส์ของการออกแบบเอเจนต์ และจัดระเบียบให้อยู่ในรูปแบบที่สามารถนำไปใช้กับบริบททางธุรกิจจริงได้
ยี่สิบเจ็ดอย่างอาจดูเยอะ แต่จริงๆ แล้วมีหลักการสำคัญเพียงสามข้อเท่านั้น เราจะอธิบายโครงสร้างนี้ตามลำดับตั้งแต่บทถัดไป
สามวินัยที่เชื่อมโยง 27 ฟีเจอร์
เมื่อมองดูฟีเจอร์ทั้ง 27 อย่าง พวกมันอาจดูกระจัดกระจาย มีทั้งทางลัด การตั้งค่าไฟล์ การป้อนข้อมูลด้วยเสียง และการรันทดสอบ แต่เมื่อถอดรหัสแล้ว พวกมันสามารถจัดกลุ่มเพื่อตอบคำถามสามข้อได้
วินัยที่ 1: การออกแบบบริบท (Context Design) (ฟีเจอร์ที่ 1–5)
การสร้างสถานะที่ Claude รู้ว่า "โปรเจกต์นี้เป็นของใคร เพื่อจุดประสงค์อะไร และตอนนี้เข้าใจมากน้อยแค่ไหน" ถ้าสิ่งนี้พัง คุณจะต้องอธิบายทุกอย่างตั้งแต่ต้นทุกครั้ง
วินัยที่ 2: การออกแบบการมอบหมายงาน (Delegation Design) (ฟีเจอร์ที่ 6–14)
การส่งมอบงานและอำนาจให้ Claude อย่างมีโครงสร้าง แทนที่จะพูดว่า "แก้บั๊ก" คุณจัดระเบียบและส่งมอบ "อะไรที่พังและข้อจำกัดคืออะไร" ซึ่งจะเปลี่ยนความน่าจะเป็นในการแก้ไขครั้งแรกสำเร็จ
วินัยที่ 3: การออกแบบอัตโนมัติ (Autonomy Design) (ฟีเจอร์ที่ 15–27)
การออกแบบกลไกที่ Claude สามารถทำงานต่อไปได้โดยไม่ต้องมีคำสั่งจากมนุษย์ตลอดเวลา
สามขั้นตอนนี้ยังเป็นลำดับที่คุณควรใช้ด้วย ถ้าบริบทไม่ได้ถูกตั้งค่า การมอบหมายงานก็จะเลอะเทอะ ถ้าการมอบหมายงานไม่ได้ถูกออกแบบ อัตโนมัติก็จะ失控
สิ่งที่คุณต้องตระหนักคือวิธีการเปลี่ยนโครงสร้างของ "ฉันที่ต้องสั่ง Claude ทุกเช้า" ถ้าคุณยังโยนงานเดิมๆ ลงในแชททุกเช้า มนุษย์ก็ยังคงเป็นผู้กระทำ เมื่อการออกแบบเปลี่ยนไปเป็นโครงสร้างที่ขับเคลื่อน Claude สิ่งที่คุณทำในตอนเช้าก็จะเปลี่ยนไป
ก่อนอื่น มาดูฟีเจอร์ทั้งห้าของการออกแบบบริบทกัน
พื้นฐานของการออกแบบบริบท
เป้าหมายของการออกแบบบริบทคือการให้ "บริบทของโปรเจกต์นี้" แก่ Claude หากไม่มีบริบท ทุกการสนทนาจะเริ่มต้นจากศูนย์
สิ่งแรกที่ต้องรันคือ `/init`
เมื่อคุณเปิดโปรเจกต์เป็นครั้งแรก ให้รันคำสั่งนี้ก่อน Claude จะสแกนโครงสร้างโค้ดเบส ดีเพนเดนซี และคำสั่ง build เพื่อสร้าง CLAUDE.md โดยอัตโนมัติ ไฟล์นี้จะกลายเป็น "พิมพ์เขียว" ของโปรเจกต์
นี่คือจุดที่หลายคนหยุด พวกเขาจำได้ว่ารัน /init แต่ไม่รู้ว่าอัปเดตล่าสุดเมื่อไหร่ ถ้าปล่อยไว้ตามที่สร้างขึ้น เนื้อหาของ CLAUDE.md จะค่อยๆ ล้าสมัยไปตามการเปลี่ยนแปลงของโปรเจกต์ การตั้งสมมติฐานว่าควรอัปเดตทุกสัปดาห์จะทำให้ Claude สามารถทำงานภายในบริบทล่าสุดได้เสมอ
ต่อไป การตั้งค่า `/statusline` ก็มีประโยชน์
แถบสถานะจะปรากฏที่ด้านล่างของหน้าจอ คุณสามารถมองเห็นได้ว่ากำลังรันอะไรอยู่และกระบวนการใดที่กำลังทำงานอยู่ นอกจากนี้ยังสามารถรวมเข้ากับแถบสถานะที่กำหนดเองใน Vim หรือ Neovim ได้ ทำให้คุณสามารถตั้งค่าให้สอดคล้องกับสภาพแวดล้อมของเอดิเตอร์ที่มีอยู่ได้
อย่างที่สามคือการป้อนข้อมูลด้วยเสียง
คุณสามารถส่งข้อกำหนดที่ซับซ้อนได้โดยการพูดโดยใช้ ⌃⌘Space บน Mac หรือการป้อนข้อมูลด้วยเสียงแบบเนทีฟบน iOS และ Android คุณสามารถส่งคำแนะนำยาวๆ เช่น "ฉันต้องการให้คอมโพเนนต์นี้เคลื่อนที่แบบนี้ด้วยเหตุผลนี้ แต่อย่าเปลี่ยนสไตล์ที่มีอยู่" โดยไม่ต้องพิมพ์ เนื่องจากคุณสามารถส่งความคิดที่ไหลออกมาได้ จึงช่วยประหยัดเวลาที่ใช้ในการจัดระเบียบขณะพิมพ์
ใช้ `/context` เพื่อตรวจสอบสถานะของบริบท
คุณสามารถดูว่ามีอะไรอยู่ในบทสนทนาปัจจุบันและการใช้งานหน้าต่างบริบทแบบเรียลไทม์ ในเซสชันที่ยาวนาน เนื้อหาของพิมพ์เขียวเริ่มต้นมักจะจางหายไป คำสั่งนี้ช่วยให้คุณตรวจสอบสิ่งนั้นได้
การรีเซ็ตสำหรับสิ่งนั้นคือ `/compact` และ `/clear`
/compact จะบีบอัดบริบททั้งหมดให้เป็นสรุป /clear คือการรีเซ็ตอย่างสมบูรณ์ ถ้าคุณดำเนินการเซสชันที่ยาวนานต่อไป คำตอบของ Claude อาจเริ่มคลุมเครือ นี่คือสัญญาณว่าบริบทอุดตัน การใช้ /compact เป็นระยะจะช่วยรักษาคุณภาพของเอาต์พุตได้
ก่อน: ในช่วงครึ่งหลังของเซสชันที่ยาวนาน Claude ให้คำตอบที่ไม่ตรงประเด็นแม้จะพูดว่า "ตามนโยบายการออกแบบที่คุยกันไว้ก่อนหน้านี้"
หลัง: บีบอัดด้วย /compact ก่อนดำเนินการต่อ ทำให้เอาต์พุตยังคงแม่นยำตามนโยบาย
ฟีเจอร์ทั้งห้าทำสิ่งเดียว: รักษาสถานะที่ Claude "รู้" ในฐานะการออกแบบ นั่นกลายเป็นรากฐานสำหรับขั้นตอนถัดไป นั่นคือการออกแบบการมอบหมายงาน
ศิลปะแห่งการส่งต่อปัญหา
เมื่อตั้งค่าบริบทแล้ว ขั้นตอนต่อไปคือวิธีการส่งต่อปัญหา ความแม่นยำของคำตอบจะเปลี่ยนไปอย่างสิ้นเชิงขึ้นอยู่กับว่าคุณพูดว่า "แก้บั๊ก" หรือส่งต่ออย่างมีโครงสร้าง
อย่างแรก ใช้โหมดวางแผน (Plan Mode) (`Shift+Tab`)
ก่อนการเปลี่ยนแปลงครั้งใหญ่ โหมดนี้จะส่งออก "เฉพาะแผน" แทนที่จะดำเนินการ คุณสามารถตรวจสอบล่วงหน้าว่า Claude ตั้งใจจะเปลี่ยนแปลงอะไรและในลำดับใด
แทนที่จะแก้ไขข้อผิดพลาดหลังจากที่เกิดขึ้น คุณสามารถชี้ว่า "นั่นผิด" ในขั้นตอนการวางแผน การรวมขั้นตอนนี้เข้ากับการออกแบบของคุณจะเปลี่ยนความถี่ของการเปลี่ยนแปลงที่ไม่คาดคิดได้อย่างมาก เมื่อคุณใช้มันต่อไป คุณจะรู้ว่ามันช่วยลดความพยายามในการตรวจสอบ "ทำไมไฟล์นี้ถึงถูกเขียนใหม่?" หลังจากเหตุการณ์นั้น
อย่างที่สองคือการจัดโครงสร้างของปัญหา ข้อจำกัด และบริบท
ถ้าคุณแค่พูดว่า "แก้บั๊ก" Claude จะพยายามเติมสมมติฐานด้วยตัวเอง ถ้าสมมติฐานเหล่านั้นผิด วิธีแก้ไขก็จะผิดไปด้วย
รูปแบบที่แนะนำอย่างเป็นทางการคือการเขียน "อะไรที่พัง" ในบรรทัดแรก และ "สิ่งที่ลองแล้ว ข้อจำกัด และรูปแบบเอาต์พุตที่คาดหวัง" ตั้งแต่บรรทัดที่สองเป็นต้นไป แค่ส่งต่อในรูปแบบนี้ก็เปลี่ยนอัตราการแก้ไขครั้งเดียวสำเร็จได้ วิธีการส่งต่อปัญหากลายเป็นทักษะ
อย่างที่สามคือ `AskUserQuestion`
นี่คือฟีเจอร์ที่ Claude จะขอคำชี้แจงก่อนดำเนินการเมื่อพบข้อกำหนดที่ไม่ชัดเจน การทำงานซ้ำที่เกิดจากการดำเนินการตามข้อกำหนดที่คลุมเครือมักเกิดขึ้นเมื่อไม่ได้ใช้ฟีเจอร์นี้ มันคือการออกแบบที่จ่ายต้นทุนของการยืนยันก่อนดำเนินการ
อย่างที่สี่คือขั้นตอนการตรวจสอบตนเอง (Self-Verification)
ในตอนท้ายของงาน ให้บอกให้ "รันเทสและยืนยันว่า build ผ่านก่อนที่จะเสร็จ" แทนที่จะเพิ่มสิ่งนี้ด้วยตนเองทุกครั้ง การเขียนไว้ใน CLAUDE.md จะทำให้มันรันโดยอัตโนมัติเมื่อสิ้นสุดทุกงาน แทนที่ Claude จะหยุดในสถานะที่สิ่งต่างๆ ใช้งานไม่ได้หลังจากการเปลี่ยนแปลง ลูปที่รวมการตรวจสอบจะเสร็จสมบูรณ์เป็นงานเดียว
การดำเนินการเชิงรุกด้วยโหมดวางแผนและการดำเนินการเชิงรับอัตโนมัติด้วยการตรวจสอบตนเอง โครงสร้างของขั้นตอนการพัฒนาจะเปลี่ยนไปทันทีที่ทั้งสองสิ่งนี้ถูกรวมเข้ากับการออกแบบ
ในบทถัดไป เราจะดูการออกแบบการมอบหมายงานต่อเนื่องให้กับ Claude
การออกแบบการมอบหมายงาน
ในบทที่ผ่านมา เราได้จัดระเบียบวิธีการสื่อสารกับ Claude และวิธีการให้มันจดจำสิ่งต่างๆ ต่อไปคือการเปลี่ยนว่า "ใครจะเป็นผู้กระทำ"
10. ซับเอเจนต์ (Subagents)
ถ้ามนุษย์ต้องจัดการขั้นตอนระหว่างงานที่ยาวนาน พวกเขาจะติดขัดอย่างหลีกเลี่ยงไม่ได้ การพูดว่า "ทำอันนี้ต่อ แล้วทำอันนั้นเมื่อเสร็จ" ตลอดเวลาหมายความว่ามนุษย์ ไม่ใช่ Claude ที่กำลังจัดการการประสานงาน
การใช้เครื่องมือ TodoWrite หรือ Task ทำให้ Claude แบ่งงานออกเป็นงานย่อยและดำเนินการแบบขนาน ในคำศัพท์ทางการ นี่คือ "การดำเนินการซับเอเจนต์พร้อมกัน" (concurrent subagent execution) ซึ่งเป็นโครงสร้างที่ Claude หลายตัวเคลื่อนที่พร้อมกัน Claude ที่แตกต่างกันจะทำการวิจัย การนำไปใช้ และการทดสอบในเวลาเดียวกัน มนุษย์ไม่จำเป็นต้องถือครองขั้นตอน
11. ทักษะที่กำหนดเอง (Custom Skills) (ไฟล์เทมเพลต Workflow)
การวางไฟล์ Markdown ไว้ในไดเรกทอรี .claude/commands/ จะช่วยให้คุณสามารถเรียกชุดคำสั่งด้วย /command-name ในบริบทของ Swarm มันง่ายกว่าที่จะคิดถึงสิ่งเหล่านี้ว่าเป็น "SKILL.md (ไฟล์เทมเพลต Workflow)"
ก่อน: เขียน "โปรดทำการสำรวจคู่แข่ง ขั้นตอนคือ 1, 2, 3..." ทุกครั้ง
หลัง: แค่พิมพ์ /competitive-research ในบรรทัดเดียว
เวลาที่ใช้ในการเขียนคำสั่งเดิมซ้ำๆ จะหายไป ถ้าแชร์กับทีม มันจะกลายเป็นเทมเพลตที่ใครๆ ก็สามารถได้รับผลลัพธ์ที่มีคุณภาพเท่ากัน
12. การเลือกโมเดล (Model Selection)
คุณสามารถสลับโมเดลภายในเซสชันได้โดยกด Alt+P การใช้งานสามขั้นตอนที่สมจริงคือ: โมเดลที่มีความสามารถในการใช้เหตุผลสูงสำหรับเฟสการออกแบบและแนวคิด โมเดลน้ำหนักเบาสำหรับการนำไปใช้อย่างง่าย และโมเดลระดับกลางสำหรับการดีบัก
การจับคู่พลังของโมเดลกับน้ำหนักของกระบวนการช่วยเพิ่มประสิทธิภาพด้านต้นทุนและความเร็วในการตอบสนองพร้อมกัน
13. การอัปเดต CLAUDE.md อัตโนมัติ
ถ้าคุณบอก Claude ให้ "เพิ่มสิ่งที่คุณเรียนรู้ในโปรเจกต์นี้ลงใน CLAUDE.md" Claude จะอัปเดต CLAUDE.md ด้วยตัวเอง มันคือโครงสร้างที่พิมพ์เขียวเติบโตได้ด้วยตัวเอง
การเพิ่มคำสั่งนี้สัปดาห์ละครั้งจะทำให้ CLAUDE.md กลายเป็น "เอกสารที่มีชีวิต" (living document) แม้ว่ามนุษย์จะไม่ได้เขียนบันทึกสะท้อนความคิด Claude ก็จะสะสมสิ่งที่มันได้เรียนรู้
14. การลิงก์ไฟล์ภายนอก (External File Linking)
คุณสามารถส่งไฟล์ URL หรือ Issues เป็นบริบทได้โดยใช้ @{file_path} มันคือกลไกในการทำให้ "อ่านไฟล์นี้ก่อนทำงาน" เสร็จในบรรทัดเดียว
ก่อน: คัดลอกและวางเนื้อหาไฟล์ลงในพรอมพ์
หลัง: แค่เขียน "ตรวจสอบการตั้งค่าโดยอ้างอิงจาก @src/config.yaml"
การออกแบบการมอบหมายงานหมายถึงการสร้างระบบที่ส่งต่อผู้กระทำให้กับ Claude เมื่อขั้นตอน เทมเพลต การอ้างอิง และหน่วยความจำพร้อมแล้ว มนุษย์จำเป็นต้องคิดแค่ "จะสร้างอะไร"
อย่างไรก็ตาม เมื่อการมอบหมายงานเพิ่มขึ้น ความเสี่ยงที่ "Claude จะเคลื่อนที่ไปในทิศทางที่แตกต่างจากความตั้งใจ" ก็เพิ่มขึ้นเช่นกัน ในบทถัดไป เราจะดูวิธีการหยุดการเคลื่อนที่ผิดทิศทางนั้นตั้งแต่เนิ่นๆ
การหยุดการเคลื่อนที่ผิดทิศทางตั้งแต่เนิ่นๆ
เมื่อการมอบหมายงานให้ Claude เพิ่มขึ้น ปัญหาหนึ่งมีแนวโน้มที่จะเกิดขึ้นมากขึ้น: การตระหนักว่ามันไปในทิศทางที่แตกต่างไปจากที่ตั้งใจไว้โดยสิ้นเชิง เราเรียกสิ่งนี้ว่าการเคลื่อนที่ผิดทิศทาง (Drift)
การเคลื่อนที่ผิดทิศทางไม่ใช่สิ่งที่ต้องแก้ไขทีหลัง มันสามารถป้องกันได้โดยการดำเนินการออกแบบเชิงรุก
15. การหยุดทันที (Immediate Stop)
ถ้าคุณรู้สึกว่าเอาต์พุตกำลังไปในทิศทางที่ผิดอย่างเห็นได้ชัด คุณสามารถหยุดมันได้ทันทีด้วยปุ่ม Escape "เดี๋ยวค่อยแก้ไขหลังจากมันเสร็จ" เป็นความผิดพลาด ยิ่งการสร้างดำเนินไปมากเท่าไหร่ ต้นทุนการแก้ไขก็ยิ่งสูงขึ้นเท่านั้น การหยุดกลางคันและแก้ไขพรอมพ์ช่วยประหยัดทั้งเวลาและโทเค็น
ถ้าคุณรู้สึกโดยสัญชาตญาณว่ามีบางอย่างผิดปกติ ให้หยุดมันโดยไม่ลังเล ความเร็วของการตัดสินนี้ส่งผลโดยตรงต่อความแม่นยำ
16. การขอเอาต์พุตแรกเป็นหลักฐาน (Requesting the First Output as Evidence)
การออกแบบเชิงรุกคือการพูดว่า "แสดงเอาต์พุตแรกให้ฉันดูก่อน แล้วฉันจะตัดสินใจว่าจะดำเนินการต่อหรือไม่" ก่อนเริ่มงาน
แทนที่จะปล่อยให้มันใช้เวลา 10 นาทีไปในทิศทางที่ผิด ให้ยืนยันกับเอาต์พุตแรกก่อนที่จะปล่อยให้มันทำงาน นี่คือแนวคิดของการหยุดการเคลื่อนที่ผิดทิศทางตั้งแต่ยังเล็ก มันจำเป็นสำหรับงานที่ใช้เวลานานหรืองานที่เริ่มต้นด้วยทิศทางที่ไม่ชัดเจน
ก่อนที่จะพูดว่า "ฉันจะปล่อยให้คุณจัดการต่อ" ให้แทรก "ให้ฉันตรวจสอบจุดเริ่มต้นก่อน" มันเป็นแค่ขั้นตอนเดียว แต่การเคลื่อนไหวเชิงรุกนี้เปลี่ยนผลลัพธ์
17. ฮุกการแจ้งเตือน (Notification Hooks)
การจ้องหน้าจอรอให้งานยาวๆ เสร็จเป็นการเสียเวลา โดยการวางสคริปต์ไว้ใน ~/.claude/hooks/ คุณจะได้รับการแจ้งเตือนบนเดสก์ท็อปเมื่องานเสร็จสมบูรณ์
ตั้งค่ามันครั้งเดียว จากนั้น แม้ว่าคุณจะทำงานอื่นอยู่ Claude ก็จะแจ้งให้คุณทราบเมื่อมันเสร็จ มันคือการออกแบบที่ขจัดการรอคอย
18. การส่งภาพหน้าจอ (Passing Screenshots)
การอธิบายบั๊ก UI ด้วยคำพูดนั้นยากอย่างน่าประหลาดใจ แทนที่จะพูดด้วยวาจาว่า "มีข้อผิดพลาดสีแดงปรากฏที่มุมซ้ายบนและกดปุ่มไม่ได้" การส่งภาพหน้าจอจะเร็วกว่า
Claude จะรับภาพและส่งคืนเนื้อหาข้อผิดพลาด สาเหตุ และคำแนะนำในการแก้ไขตามที่เป็นอยู่ มันเสร็จสมบูรณ์ด้วย "ดูหน้าจอนี้"
ฟีเจอร์ 18 อย่างที่แนะนำมาจนถึงตอนนี้ทั้งหมดอยู่บนสมมติฐานของคนคนเดียวที่ปฏิบัติการ ในบทถัดไป เราจะเข้าสู่โครงสร้างของ "การใช้เป็นทีม" ซึ่ง Claude หลายตัวทำงานแบบขนานและบูรณาการ
การทำงานแบบขนานและการบูรณาการ
ในขณะที่ใช้ Claude Code เป็นเครื่องมือแชท คุณไม่สามารถเริ่มงานถัดไปได้จนกว่างานหนึ่งจะเสร็จ แต่ด้วยการเปลี่ยนการออกแบบ คุณสามารถสร้างโครงสร้างที่ Claude หลายตัวเคลื่อนที่พร้อมกันได้
เริ่มต้นด้วยการบูรณาการ Chrome DevTools เนื่องจากคุณสามารถส่งบันทึกข้อผิดพลาดของเบราว์เซอร์และบันทึกเครือข่ายไปยัง Claude Code ได้โดยตรง คุณจึงไม่จำเป็นต้องอธิบายสถานการณ์ด้วยวาจาอีกต่อไป เช่น "มีข้อผิดพลาดสีแดงในคอนโซล แต่ฉันไม่รู้ว่าเกิดอะไรขึ้น" เอกสารอย่างเป็นทางการมีหน้าเฉพาะสำหรับสิ่งนี้ โดยวางตำแหน่งให้เป็นประตูสู่การดีบัก
การจัดการเซสชันก็เปลี่ยนไปเช่นกัน คุณสามารถดำเนินการต่อเซสชันล่าสุดตามที่เป็นอยู่ด้วย claude --continue หรือเลือกจากรายการเซสชันด้วย claude --resume ยิ่งไปกว่านั้น โดยการตั้งชื่อเซสชันด้วย /rename คุณสามารถจัดการงานหลายอย่างแบบขนานด้วยความรู้สึกเดียวกับ Git branches การใช้เซสชันที่ชื่อว่า "Auth," "Payment," และ "Dashboard" ทำให้ต้นทุนของการสลับบริบทเกือบเป็นศูนย์
และหัวใจของการทำงานแบบขนานคือการรวมกับ git worktrees การพิมพ์ claude --worktree feature-auth จะเปิดเซสชันที่ branch ถูกแยกออกจากกันโดยสิ้นเชิงด้วย worktree ถ้าคุณรัน Auth, Payment และ Dashboard ใน worktrees ที่แยกจากกัน Claude สามตัวจะดำเนินการพัฒนาแบบขนาน เนื่องจากแต่ละตัวอยู่ในพื้นที่ทำงานอิสระ จึงไม่เกิดความขัดแย้ง โครงสร้างที่จะทำให้การพัฒนาหนึ่งสัปดาห์เสร็จในหนึ่งวันถูกสร้างขึ้นที่นี่ในฐานะการออกแบบ
นอกจากนี้ยังจำเป็นต้องจัดระเบียบความคิดเกี่ยวกับ MCP อีกด้วย เซิร์ฟเวอร์ MCP ไม่ใช่ทางออกที่ดีที่สุดเสมอไป เอกสารอย่างเป็นทางการระบุว่า "เครื่องมือ CLI เป็นวิธีที่มีประสิทธิภาพด้านบริบทมากที่สุดในการโต้ตอบกับบริการภายนอก" และเครื่องมือ CLI เช่น gh หรือ aws กล่าวกันว่ามีประสิทธิภาพด้านบริบทสูงและมีโอกาสน้อยที่จะถึงขีดจำกัดอัตรา ด้วยคำสั่ง gh เพียงอย่างเดียว Claude Code สามารถสร้าง อัปเดต และปิด GitHub Issues ได้โดยอัตโนมัติ การมีแกนการตัดสินเพื่อตรวจสอบว่าสามารถใช้เครื่องมือ CLI ได้หรือไม่ก่อนที่จะเพิ่ม MCP จะช่วยให้การออกแบบเรียบง่าย
เมื่อการออกแบบแบบขนานเป็นไปได้ มนุษย์ไม่จำเป็นต้องจัดการลำดับอีกต่อไป เนื่องจากการออกแบบเปลี่ยนไปเป็นการส่งต่อผู้กระทำหลายคนให้ Claude พร้อมกัน ต่อไป เราจะพัฒนาการประมวลผลแบบขนานที่ออกแบบนี้ให้เป็นระบบที่ยังคงเคลื่อนที่ต่อไปแม้ในขณะที่คุณไม่อยู่ที่โต๊ะทำงาน
การทำงานแบบอัตโนมัติ
คำถามถัดไปหลังจากการออกแบบแบบขนานคือ "ฉันต้องอยู่ที่ไหนในช่วงเวลานั้น?" เมื่อการทำงานแบบอัตโนมัติได้รับการออกแบบ สถานะที่งานดำเนินไปแม้ไม่มีมนุษย์อยู่ก็จะถูกสร้างขึ้น
/loop เป็นฟีเจอร์ที่รันการโพลอัตโนมัติภายในเซสชัน คำอธิบายอย่างเป็นทางการคือ "การโพลอย่างรวดเร็วในขณะที่เซสชันเปิดอยู่" และมันจะทำซ้ำการดำเนินการที่ระบุในขณะที่เซสชันเปิดอยู่ การใช้ --resume หรือ --continue ช่วยให้คุณสามารถดำเนินการต่อเซสชันที่ยังไม่หมดอายุได้ และตามรายงานประสบการณ์ในบทความต้นฉบับ มีรายงานกรณีการทำงานแบบไม่มีมนุษย์เป็นเวลาสูงสุดสามวัน แม้ว่าเราจะยังไม่ได้ยืนยันจำนวนวันนั้นโดยตรงกับแหล่งข้อมูลอย่างเป็นทางการ แต่มันก็ทำหน้าที่เป็นจุดเริ่มต้นสำหรับการทำงานแบบอัตโนมัติระยะยาวอย่างแน่นอน
Remote Control ซึ่งเพิ่มใน Q1 2026 เป็นฟีเจอร์ในการใช้งานเซสชัน Claude Code ที่รันอยู่ในเครื่องจากสมาร์ทโฟนหรือเบราว์เซอร์พีซี ในขณะที่โค้ดยังคงอยู่ในเครื่อง มีเพียงข้อความเท่านั้นที่ถูกแลกเปลี่ยนผ่านช่องทางที่เข้ารหัส มันถูกปล่อยออกมาเป็นตัวอย่างการวิจัยในเดือนกุมภาพันธ์ 2026 สถานการณ์ถูกสร้างขึ้นโดยที่ Claude Code ในเครื่องยังคงเคลื่อนที่ต่อไปเพียงแค่ส่ง "ตรวจสอบว่าการทดสอบผ่านหรือไม่" จากสมาร์ทโฟนขณะอยู่นอกสถานที่
การสืบค้นฐานข้อมูลด้วยภาษาธรรมชาติก็สามารถรวมเข้ากับการออกแบบได้เช่นกัน การเชื่อมต่อกับ SQLite, PostgreSQL หรือ MySQL ผ่าน MCP ช่วยให้คุณสามารถดึงข้อมูลโดยใช้ภาษาไทย (หรือภาษาอังกฤษ) เช่น "บอกผู้ใช้ที่ลงทะเบียนเมื่อสัปดาห์ที่แล้วให้ฉันหน่อย" คู่มืออย่างเป็นทางการแนะนำให้รัน claude mcp add เพื่อเชื่อมต่อเครื่องมือภายนอก เช่น ฐานข้อมูลของคุณ ทำให้คุณสามารถมอบหมายกิจวัตรการยืนยันข้อมูลให้ Claude โดยไม่ต้องเขียน SQL
นอกจากนี้ยังมีฟีเจอร์สี่อย่างในการควบคุมความลึกของการคิด ultrathink จะกระตุ้นการคิดแบบขยายสูงสุดถึง 31,999 โทเค็นเพียงแค่รวมคีย์เวิร์ดนั้นไว้ในพรอมพ์ มีลำดับชั้น: think คือ 4,000 โทเค็น megathink คือ 10,000 โทเค็น และ ultrathink คือ 31,999 โทเค็น วิธีใช้ที่ถูกต้องคือสำหรับ 10% ของปัญหาที่ยากจริงๆ เท่านั้น เช่น การตัดสินใจด้านสถาปัตยกรรมที่ซับซ้อน การนำไปใช้ด้านความปลอดภัย การเพิ่มประสิทธิภาพประสิทธิภาพ และการปรับโครงสร้างขนาดใหญ่ การใช้มันกับทุกคำถามจะทำให้ต้นทุนเพิ่มขึ้นอย่างไม่มีประโยชน์
/effort ultracode คือการตั้งค่าเพื่อเปิดใช้งานการใช้เหตุผลระดับ xhigh และ workflow แบบไดนามิกสำหรับทั้งเซสชัน ในขณะที่ ultrathink เป็นคีย์เวิร์ดแบบเทิร์นเดียว ultracode จะยังคงทำงานอยู่ตลอดทั้งเซสชัน มันเหมาะสำหรับ "งานหนักระดับเซสชัน" เช่น การตรวจสอบโค้ดเบสทั้งหมด การย้ายไฟล์หลายร้อยไฟล์ หรืองานที่มีความเสี่ยงสูง อย่างไรก็ตาม เนื่องจากต้นทุนโทเค็นเพิ่มขึ้นอย่างมาก การแยกแยะสถานการณ์จึงเป็นตัวกำหนดประสิทธิผล
Claude Code ซึ่งเริ่มต้นด้วยการพิมพ์ลงในแชทเพื่อขับเคลื่อนมัน ได้มาถึงประตูของระบบที่ตรวจจับเหตุการณ์และเคลื่อนที่โดยอัตโนมัติ แทนที่มนุษย์จะขับเคลื่อนมัน การออกแบบจะขับเคลื่อน Claude ต่อไป เราจะยืนยันว่าความแตกต่างในด้านผลผลิตเกิดขึ้นจากที่ใดโดยพื้นฐานผ่านฟีเจอร์ทั้งหมดเหล่านี้
ทำไมผลลัพธ์ถึงแตกต่างกับ Claude Code เดียวกัน
คนที่พัฒนาอย่างรวดเร็วไม่จำเป็นต้องมีความสามารถพิเศษ พวกเขาแค่ออกแบบอย่างเป็นระบบมากกว่า
ตัวอย่างเช่น พิจารณาสถานการณ์ของการรัน /init แม้ว่าจะพิมพ์คำสั่งเดียวกัน คุณภาพของเอาต์พุตหลายเดือนต่อมาจะแตกต่างกันอย่างสิ้นเชิงระหว่าง CLAUDE.md ที่อัปเดตทุกสัปดาห์กับอันที่ถูกปล่อยทิ้งไว้ตั้งแต่ตั้งค่า นี่เป็นเพราะความสดและความแม่นยำของบริบทที่ Claude อ่านส่งผลโดยตรงต่อคุณภาพของเอาต์พุต
การเปรียบเทียบกับห้องครัว ระดับของการทำอาหารถูกกำหนดโดยวิธีการจัดระเบียบห้องครัวมากกว่าวัตถุดิบที่ใช้ ประสิทธิภาพของโมเดล Claude นั้นมีให้กับผู้ใช้ทุกคนอย่างเท่าเทียมกัน ความแตกต่างอยู่ที่ความแม่นยำของสามจุดนี้: จัดระเบียบบริบทอย่างไร จัดระบบคำสั่งอย่างไร และออกแบบการทำงานแบบอัตโนมัติอย่างไร
ก่อนที่จะพูดถึง "ควรใช้โมเดลไหน" ลองตรวจสอบว่า CLAUDE.md ปัจจุบันของคุณอัปเดตล่าสุดเมื่อไหร่ นั่นจะบอกสถานะปัจจุบันของการออกแบบของคุณ
แล้วคุณควรเริ่มต้นจากตรงไหนจริงๆ? ในบทถัดไป เราจะจัดระเบียบลำดับการแนะนำแบบทีละขั้นตอน
จะเริ่มต้นที่ไหน: คู่มือการแนะนำแบบทีละขั้นตอน
คุณไม่จำเป็นต้องพยายามจำทั้งหมด 27 อย่างในครั้งเดียว
ในสัปดาห์แรก ให้จำกัดให้เหลือแค่สี่อย่าง
- สร้างแผนที่โปรเจกต์ด้วย
/init - บีบอัดบริบทเป็นระยะด้วย
/compact - แยกการสำรวจและการดำเนินการด้วยโหมดวางแผน (
Shift+Tab) - ส่งต่อขั้นตอนการตรวจสอบตนเอง (เทส, build) ให้ Claude
แค่สี่อย่างนี้ คุณภาพของเซสชันจะเปลี่ยนไปโดยพื้นฐาน เนื่องจาก Claude เริ่มเคลื่อนที่ด้วยความเข้าใจที่แม่นยำว่า "ควรทำอะไร" ปริมาณงานซ้ำจะลดลงอย่างเห็นได้ชัด
ตั้งแต่สัปดาห์ที่สองเป็นต้นไป ให้เพิ่มการออกแบบการมอบหมายงานบนรากฐานนี้ สรุปคำสั่งให้เป็นรูปแบบที่นำกลับมาใช้ใหม่ได้ด้วย Custom Skills ปรับน้ำหนักและความเร็วของการประมวลผลด้วยการเลือกโมเดล (Alt+P) และสร้างนิสัยในการอัปเดต CLAUDE.md ทุกสัปดาห์ นี่คือขั้นตอนที่คุณเปลี่ยนคำสั่งจาก "สิ่งที่เขียนทุกครั้ง" เป็น "สิ่งที่สะสม"
หลังจากหนึ่งเดือน ให้ดำเนินการต่อด้วยซับเอเจนต์ git worktrees และเซสชันแบบขนาน คุณจะมีระบบที่คุณสามารถมุ่งเน้นไปที่การออกแบบและการยืนยันในขณะที่พัฒนาฟีเจอร์หลายอย่างพร้อมกัน
ultrathink และ ultracode เป็นเครื่องมือที่จะใช้เป็นครั้งแรกในขั้นตอนนี้เมื่อคุณพบ "ปัญหาที่ยากจริงๆ" พวกมันไม่ใช่เครื่องมือที่จะนำออกมาใช้กับทุกปัญหา
โดยการทำตามขั้นตอนเหล่านี้ คุณจะเข้าใจผ่านประสบการณ์ว่า "ทำไมแต่ละฟีเจอร์จึงจำเป็น" โปรดเริ่มต้นด้วยสี่รายการสำหรับสัปดาห์แรก
ทุกอย่างเปลี่ยนไปทันทีที่คุณมองว่ามันเป็นเป้าหมายของการออกแบบ
ทันทีที่คุณเริ่มมองว่า Claude Code เป็นเป้าหมายของการออกแบบ คุณภาพของเซสชันจะเปลี่ยนไปโดยพื้นฐาน
ฉันจะสรุปเนื้อหาที่แนะนำในบทความนี้ในรูปแบบที่คุณสามารถบันทึกและกลับมาอ้างอิงได้
- สี่รายการ—
/init+/compact+ โหมดวางแผน + การตรวจสอบตนเอง—เป็นการออกแบบพื้นฐานที่สุด - จัดระบบการใช้คำสั่งซ้ำด้วย Custom Skills และทำให้
CLAUDE.mdเติบโตเป็น "พิมพ์เขียวที่มีชีวิต" ที่อัปเดตทุกสัปดาห์ - เมื่อคุณเริ่มใช้ซับเอเจนต์ ผลผลิตจะเปลี่ยนจากการบวกเป็นการคูณ
- กฎเหล็กคือการตรวจจับการเคลื่อนที่ผิดทิศทางตั้งแต่เนิ่นๆ และหยุดทันที ขอหลักฐานในเอาต์พุตแรกเสมอ
- คุณสามารถพัฒนาฟีเจอร์หลายอย่างพร้อมกันด้วย
git worktrees+ เซสชันแบบขนาน - ตั้งค่าการทำงานแบบอัตโนมัติด้วย
/loopและยืนยันหรือสั่งการจากสมาร์ทโฟนด้วย Remote Control ultrathinkเป็นเครื่องมือเฉพาะสำหรับ "10% ที่ยากจริงๆ" ไม่ใช่สำหรับทุกปัญหา
ถ้าคุณลองใช้แม้แต่ฟีเจอร์เดียวที่กล่าวถึงในบทความนี้ ความสัมพันธ์ของคุณกับ Claude Code จะเริ่มเปลี่ยนไปทีละน้อย
สำหรับผู้ที่สนใจ AI Agents
Swarm (@swarm_japan) แบ่งปันปรัชญาการออกแบบที่จำเป็นและกรณีการใช้งานทางธุรกิจสำหรับเอเจนต์
ติดตามเราเพื่อรับความรู้ทางธุรกิจที่จำเป็นสำหรับยุค AI Agent 👇
★ อธิบายข้อมูล AI Agent ล่าสุดจากมุมมองที่ไม่เหมือนใคร
★ แนะนำกรณีการใช้งานทางธุรกิจสำหรับเอเจนต์
★ เผยแพร่ความรู้เฉพาะทาง
ถ้าคุณสนใจ โปรดติดตามและตรวจสอบเราสิ! 👀
