ฉันใช้ Claude Code มากว่าครึ่งปีแล้ว และเจอหลุมพรางมากกว่าจำนวนโค้ดที่เขียนเสียอีก
ตอนแรกฉันคิดว่า Claude Code ก็แค่ "Copilot ที่เก่งขึ้น"—พิมพ์ในเทอร์มินัล มันเขียนโค้ดให้ แล้วก็จบ ต่อมาฉันถึงได้รู้ว่า ขีดจำกัดของเครื่องมือนี้สูงกว่าที่คิดไว้มาก แต่ต้องรู้วิธีใช้ถึงจะได้ผล
บทความนี้รวบรวมจากเอกสารทางการและประสบการณ์จริง จัดเรียงเคล็ดลับการใช้งานที่ฉันคิดว่าสำคัญที่สุด บางอย่างเป็นบทเรียนที่เจอมากับตัว บางอย่างเป็นฟีเจอร์ซ่อนเร้นที่เพิ่งรู้จากตอนอ่านเอกสาร
1. CLAUDE.MD: ฟีเจอร์ที่ถูกมองข้ามมากที่สุด
ถ้าคุณจำได้แค่สิ่งเดียวจากบทความนี้ จำสิ่งนี้ไว้: เขียน CLAUDE.md ให้ดี
CLAUDE.md คือไฟล์คำแนะนำที่ Claude Code อ่านโดยอัตโนมัติทุกครั้งที่เริ่มการสนทนาใหม่ มันเหมือนเอกสารแนะนำตัวที่คุณเขียนให้เพื่อนร่วมงานใหม่—อะไรที่อยากให้รู้ ก็เขียนไว้ตรงนั้น
หลายคนไม่เขียน CLAUDE.md หรือเขียนแค่ไม่กี่บรรทัด ผลลัพธ์คือต้องอธิบายโครงสร้างโปรเจกต์ มาตรฐานการเขียนโค้ด และเหตุผลที่เลือกเทคสแต็กต่างๆ ตั้งแต่ต้นทุกครั้งที่คุย เหมือนต้องแนะนำบริษัทให้เพื่อนร่วมงานฟังใหม่ทุกเช้า
สิ่งที่ CLAUDE.md ที่ดีควรมี:
1# ชื่อโปรเจกต์23## คำสั่ง Build และ Test4- ติดตั้ง dependencies: npm install5- รันเทส: npm test6- เทสเดี่ยว: npm test -- --grep "ชื่อเทส"7- จัดรูปแบบโค้ด: npm run format89## มาตรฐานการเขียนโค้ด10- Python: ใช้ ruff จัดรูปแบบ, ความกว้างบรรทัด 8811- การเทส: ใช้ pytest, หนึ่งไฟล์เทสต่อหนึ่งบริการ12- API Routes: ใช้ชื่อไฟล์เป็นพหูพจน์: users.py, orders.py13- ข้อความ commit: ภาษาอังกฤษ, รูปแบบ: type(scope): description1415## การตัดสินใจด้านสถาปัตยกรรม16- เลือก Tailwind แทน CSS Modules เพราะทีมตกลงกันให้ใช้มาตรฐานเดียวกัน17- การตรวจสอบสิทธิ์ผู้ใช้ทำใน middleware; ไม่ต้องทำซ้ำในทุก route18- คำนำหน้า Redis cache key: app:v1:1920## ข้อผิดพลาดที่พบบ่อย21- ขีดจำกัด connection pool ของ DB คือ 20; อย่าเปิด connection ใหม่ในลูป22- อย่า mock ฐานข้อมูล; ครั้งที่แล้ว mock ผ่านแต่ migration จริงล้มเหลว
หลักการสำคัญ:
อย่างแรก เขียนสิ่งที่ Claude ไม่สามารถอนุมานจากโค้ดได้ "ทำไม" ของโปรเจกต์สำคัญกว่า "อะไร" คุณไม่ต้องอธิบายวิธีใช้ React แต่ต้องบอกมันว่า "เราเลือก Tailwind เพราะทีมตกลงกันให้ใช้มาตรฐานเดียวกัน"
อย่างที่สอง เก็บให้ต่ำกว่า 200 บรรทัด เอกสารทางการบอกชัดเจนว่าถ้า CLAUDE.md ยาวเกินไป Claude อาจไม่สนใจกฎ ใช้หัวข้อ markdown และลิสต์เพื่อให้สแกนง่าย
อย่างที่สาม อย่าใส่เนื้อหาที่เปลี่ยนแปลงบ่อย รายละเอียด API หรือคำอธิบายทีละไฟล์ไม่ควรอยู่ใน CLAUDE.md แค่ใส่ลิงก์ก็พอ
สี่ระดับของ CLAUDE.md
Claude Code รองรับ CLAUDE.md สี่ระดับ เรียงจากลำดับความสำคัญสูงสุดไปต่ำสุด:

ใน CLAUDE.md ระดับโลกของฉัน ฉันมักจะเขียน:
1- ฉันเป็นฟูลสแต็กเอ็นจิเนียร์; ไม่ต้องอธิบายแนวคิดพื้นฐานมากเกินไป2- ตอบให้กระชับ; ข้ามคำทักทายที่ไม่จำเป็น3- อย่าสรุปสิ่งที่ทำหลังแก้โค้ด; ฉันจะตรวจสอบ diff เอง4- ให้ความสำคัญกับวิธีแก้ปัญหาง่ายๆ; หลีกเลี่ยงการออกแบบที่ซับซ้อนเกินจำเป็น
สี่บรรทัดนี้ช่วยประหยัดการแก้ไขซ้ำๆ ได้เป็นร้อยครั้ง
ขั้นสูง: จัดระเบียบกฎด้วย .claude/rules/
เมื่อโปรเจกต์โตขึ้น ไฟล์ CLAUDE.md เดียวจะเก็บทุกอย่างไม่ไหว วิธีแก้ปัญหาจากทางการนั้นหรูหรากว่า: แยกกฎไปไว้ในไดเรกทอรี .claude/rules/
1.claude/rules/2├── testing.md # มาตรฐานการเทส3├── api-style.md # รูปแบบการเขียน API4└── frontend.md # ข้อตกลงฟร้อนท์เอนด์
ยิ่งไปกว่านั้น คุณสามารถใช้ YAML frontmatter เพื่อจำกัดกฎให้ใช้กับไฟล์เฉพาะ:
1---2paths: ["src/api/**/*.ts", "src/routes/**/*.ts"]3---45API routes ต้องมีการตรวจสอบอินพุตและการจัดการข้อผิดพลาด6endpoint ใหม่ทั้งหมดต้องมี integration tests ใน tests/api/
วิธีนี้ กฎจะโหลดก็ต่อเมื่อ Claude เข้าถึงไฟล์ที่ตรงกัน ช่วยประหยัดพื้นที่ context
2. คุณภาพของ Prompt กำหนดคุณภาพของผลลัพธ์
ฟังดูเหมือนคำพูดซ้ำซาก แต่ฉันเห็นคนใช้ Claude Code แบบนี้บ่อยเกินไป:
"ช่วยเขียนฟีเจอร์ล็อกอินหน่อย"
แล้วก็กังวลกับโค้ดจำนวนมากที่ถูกสร้างขึ้น—นี่ไม่ใช่สิ่งที่ฉันต้องการ
คำแนะนำที่ดีควรมีสามองค์ประกอบ: เป้าหมาย ข้อจำกัด และบริบท
คำแนะนำที่ไม่ดี vs คำแนะนำที่ดี
ไม่ดี: "เพิ่มฟีเจอร์ค้นหาในรายชื่อผู้ใช้"
ดี: "เพิ่มช่องค้นหาเหนือตารางใน @src/pages/UserList.tsx การค้นหาควรใช้ API ฝั่งแบ็คเอนด์ /api/users?search=xxx ไม่ต้องกรองฝั่งฟร้อนท์ ใช้ดีเลย์ 300ms และรักษารูปแบบให้สอดคล้องกับคอมโพเนนต์ Filter ที่มีอยู่"
ต่างกันยังไง? คำแนะนำที่ดีลดความคลุมเครือ Claude Code ไม่ต้องเดาว่าคุณต้องการค้นหาฝั่งฟร้อนท์หรือแบ็คเอนด์ ระยะดีเลย์เท่าไหร่ หรือมาตรฐานการจัดสไตล์แบบไหน
เคล็ดลับการเขียน Prompt ที่แนะนำโดยทางการ
1. ใช้ @ เพื่ออ้างอิงไฟล์เฉพาะ
Claude Code รองรับการใช้ @filepath เพื่อดึงเนื้อหาไฟล์เข้าสู่ context โดยตรง แทนที่จะพูดว่า "โค้ดที่เกี่ยวกับ auth" การเขียน @src/auth/login.ts แม่นยำกว่ามาก คุณ甚至可以ระบุช่วงบรรทัด: @src/auth/login.ts#5-30
2. วางภาพหน้าจอและรูปภาพ
ใช้ Ctrl+V เพื่อวางรูปภาพโดยตรง เมื่อดีบักปัญหาที่เกี่ยวกับ UI ภาพหน้าจอ "ตอนนี้เป็นยังไง" vs "อยากให้เป็นยังไง" มีประสิทธิภาพมากกว่าคำอธิบายเป็นข้อความถึงสิบเท่า
3. ให้เกณฑ์การตรวจสอบ
อย่าแค่พูดว่า "ช่วยแก้บั๊กนี้หน่อย" แต่ให้พูดว่า:
"แก้ไขปัญหาที่การยืนยันตัวตนซ้ำล้มเหลวหลังจากหมดเวลา login หลังจากแก้ไขแล้ว การคลิกปุ่มใดๆ หลังจาก token หมดอายุควรเปลี่ยนเส้นทางไปยังหน้า login โดยอัตโนมัติ เทสเคสอยู่ใน @tests/auth.test.ts; รันเพื่อยืนยันว่าผ่านหลังจากแก้ไข"
ให้มาตรฐานที่ Claude สามารถตรวจสอบได้ด้วยตัวเอง—เทสเคส ภาพหน้าจอ ผลลัพธ์ที่คาดหวัง—เพื่อให้มันตรวจสอบคุณภาพงานของตัวเองได้ และลดการกลับไปกลับมา
4. บอกให้ชัดเจนว่าอะไรที่ไม่ควรทำ
บางครั้ง Claude Code ก็กระตือรือร้นเกินไป—คุณบอกให้แก้บั๊ก มันก็รีแฟกเตอร์โค้ดรอบข้างด้วย การบอกชัดๆ ว่า "เปลี่ยนแค่ฟังก์ชันนี้ อย่าแตะโค้ดอื่น" ช่วยประหยัดปัญหาได้มาก
เมื่อไหร่ที่คำแนะนำคลุมเครือมีประโยชน์
ไม่ใช่ทุกสถานการณ์ที่ต้องการความแม่นยำ คำแนะนำคลุมเครือเหมาะกับงานสำรวจมากกว่า:
- "มีอะไรที่ปรับปรุงได้ในไฟล์นี้?"
- "ช่วยให้ฉันเข้าใจสถาปัตยกรรมของโมดูลนี้"
- "มีปัญหาที่อาจเกิดขึ้นกับโค้ดนี้ไหม?"
แต่เมื่อถึงขั้นตอนการนำไปใช้ ให้กลับมาใช้โหมดแม่นยำ
3. PLAN MODE: คิดให้ชัดก่อนลงมือทำ
Claude Code มี Plan Mode ซึ่งฉันคิดว่าเป็นเวิร์กโฟลว์ที่ถูกมองข้ามมากที่สุด
วิธีเข้า Plan Mode
สามวิธี:
1# เริ่มต้นใน plan mode โดยตรง2claude --permission-mode plan34# สลับระหว่างการสนทนา (กด Shift+Tab สองครั้ง)5Shift+Tab Shift+Tab67# พูดใน prompt8"อย่าเพิ่งเปลี่ยนโค้ด ช่วยวางแผนให้หน่อย"
ใน Plan Mode, Claude Code อ่านได้แค่ไฟล์และค้นหาโค้ดเท่านั้น มันไม่สามารถแก้ไขอะไรได้เลย มันสำรวจโค้ดเบส วิเคราะห์ความต้องการของคุณ และให้แผนการนำไปใช้โดยละเอียด
วิธีใช้ Plan Mode ที่ถูกต้อง
การดำเนินการสำคัญ: กด Ctrl+G เพื่อเปิดและแก้ไขแผนในเอดิเตอร์ของคุณ
หมายความว่าคุณสามารถ:
- ให้ Claude สร้างแผนเริ่มต้น
- กด Ctrl+G เพื่อเปิดแผน ลบส่วนที่ไม่เห็นด้วย และเพิ่มไอเดียของคุณเอง
- สลับกลับไปยังโหมดปกติ (Shift+Tab) และให้ Claude ดำเนินการตามแผนที่แก้ไขแล้ว
การเปลี่ยนแผนใช้แค่ประโยคเดียว; การเปลี่ยนโค้ดที่เขียนแล้วใช้เวลานานกว่าสิบเท่า
เวิร์กโฟลว์ที่แนะนำสำหรับงานที่ซับซ้อน
กระบวนการมาตรฐานทางการมีสี่ขั้นตอน: สำรวจ → วางแผน → นำไปใช้ → ตรวจสอบ
11. เข้า Plan Mode22. ให้ Claude อ่านโค้ดที่เกี่ยวข้อง: "อ่านโค้ดใน src/auth/ เพื่อเข้าใจตรรกะ session"33. ขอแผน: "พัฒนาแผนการย้ายไปใช้ OAuth2"44. กด Ctrl+G เพื่อตรวจสอบและแก้ไขแผน55. สลับกลับไปยังโหมดปกติ66. "ดำเนินการตามแผน รันเทสหลังจากเขียนเสร็จ"77. ให้ Claude ตรวจสอบตัวเองกับความต้องการ
เมื่อไหร่ที่ไม่ต้องใช้ Plan Mode
- เปลี่ยนชื่อตัวแปร
- แก้ไขคำผิดที่ชัดเจน
- เพิ่ม log หนึ่งบรรทัด
เกณฑ์ง่ายๆ: ถ้ามีวิธีเดียวในการทำงานนั้น ให้ทำเลย ถ้ามีหลายทางเลือก ให้วางแผนก่อน
4. SUB-AGENTS: พลังการทำงานหลายอย่างพร้อมกันของ Claude Code
Sub-agents เป็นกลไกที่ทรงพลัง—Claude Code สามารถเปิดกระบวนการ AI อิสระเพื่อจัดการงานแบบขนานได้ แต่ละ sub-agent มี context window ของตัวเอง และไม่รกการสนทนาหลักของคุณ
ประเภท Sub-agent ในตัว
คุณค่าที่ใหญ่ที่สุดของ Sub-agents: การแยก Context
เมื่อคุณขอให้ Claude รันเทส วิเคราะห์ log หรือค้นหาหลายไฟล์ การดำเนินการเหล่านี้สร้างผลลัพธ์จำนวนมากที่เต็ม context window ของคุณ ใช้ sub-agents สำหรับงานเหล่านี้; ผลลัพธ์จะอยู่ใน context ของ sub-agent และมีเพียงสรุปสั้นๆ ที่ส่งกลับมาหาคุณ
ตัวอย่าง:
"ใช้ sub-agent รันเทสทั้งหมดและแสดงรายการเคสที่ล้มเหลว"
"ใช้ sub-agent ค้นหาไฟล์ทั้งหมดที่ใช้ API ที่เลิกใช้แล้ว"
รันในเบื้องหลัง: Ctrl+B
กด Ctrl+B เพื่อส่ง sub-agent ไปรันในเบื้องหลัง คุณสามารถคุยกับ Claude เรื่องอื่นต่อได้ และจะได้รับการแจ้งเตือนเมื่องานเบื้องหลังเสร็จ
เหมาะสำหรับ:
- รันชุดเทส (ปกติใช้เวลาเป็นนาที)
- ค้นหาโค้ดขนาดใหญ่
- รีวิวโค้ดที่ไม่เร่งด่วน
Sub-agents แบบกำหนดเอง
คุณสามารถสร้าง agent แบบกำหนดเองในไดเรกทอรี .claude/agents/:
1---2name: code-reviewer3description: ผู้เชี่ยวชาญรีวิวโค้ด ถูกเรียกใช้โดยอัตโนมัติหลังการเปลี่ยนแปลงโค้ด4tools: Read, Grep, Glob, Bash5model: sonnet6---78คุณเป็นผู้รีวิวโค้ดอาวุโส ตรวจสอบในมิติต่อไปนี้:9- ความชัดเจนและความอ่านง่ายของโค้ด10- ความครบถ้วนของการจัดการข้อผิดพลาด11- การเปิดเผยข้อมูลที่ละเอียดอ่อน12- การตรวจสอบอินพุต13- ข้อผิดพลาดด้านประสิทธิภาพ
จากนั้นเรียกใช้ในการสนทนาด้วย @"code-reviewer (agent)"
5. การจัดการ Context: กุญแจสำคัญที่ถูกมองข้ามมากที่สุด
แม้ว่า Claude Code จะมี context window ขนาดใหญ่ (สูงสุด 1M tokens) แต่มันก็ไม่จำกัด และการจัดการ context ส่งผลโดยตรงต่อคุณภาพของผลลัพธ์
อะไรอยู่ใน context?
- ประวัติการสนทนาของคุณ
- เนื้อหาไฟล์ทั้งหมดที่ Claude อ่าน
- ผลลัพธ์จากการรันคำสั่ง
- ไฟล์ CLAUDE.md (โหลดทุกครั้ง)
- ไฟล์ Memory (200 บรรทัดแรก)
- คำจำกัดความของ Skill และ MCP tool ที่โหลดไว้
ห้ากลยุทธ์ที่ใช้ได้จริง
1. /clear: ล้างเมื่องานเสร็จ
อย่าแก้บั๊ก เพิ่มฟีเจอร์ และรีแฟกเตอร์ในการสนทนาเดียวกัน /clear จะล้าง context แต่คง CLAUDE.md ไว้ เหมือนเริ่มต้นใหม่ฟรี
2. /compact: บีบอัด context ด้วยตนเอง
เมื่อการสนทนายาวขึ้น ให้ใช้ /compact เพื่อให้ Claude สรุปและบีบอัดบทสนทนาก่อนหน้าโดยอัตโนมัติ วิธีที่ดีกว่าคือ เพิ่มโฟกัสในการบีบอัด:
/compact focus on API changes and test results
วิธีนี้ Claude จะให้ความสำคัญกับการเก็บเนื้อหาที่คุณสนใจระหว่างการบีบอัด
3. /context: ดูว่าอะไรกินพื้นที่ context
พิมพ์ /context เพื่อดูการใช้งานปัจจุบัน—ไฟล์ไหนใช้กี่ tokens และคำจำกัดความ MCP tool ใช้พื้นที่เท่าไหร่ ฉันมักจะพบ MCP server ที่ไม่ได้ใช้กินพื้นที่มหาศาล
4. ใช้ Sub-agents เพื่อแยกสัญญาณรบกวน
การรันเทสและวิเคราะห์ log สร้างผลลัพธ์จำนวนมาก ให้ sub-agents ทำเพื่อรักษา context การสนทนาหลักให้สะอาด
5. เขียนคำแนะนำการเก็บข้อมูลระหว่างบีบอัดใน CLAUDE.md
คุณสามารถบอก Claude ว่าอะไรที่ต้องเก็บไว้ระหว่างการบีบอัด:
1# คำแนะนำการบีบอัด2เมื่อบีบอัด context ให้เก็บสิ่งเหล่านี้เสมอ:3- รายการไฟล์ที่แก้ไขทั้งหมด4- คำสั่งเทสและผลลัพธ์5- การตัดสินใจด้านสถาปัตยกรรมที่สำคัญ
Memory vs CLAUDE.md

Memory ใช้สำหรับ: ความชอบของคุณ ("คนนี้ชอบคำตอบสั้นๆ"), ข้อตกลงของโปรเจกต์ ("การ deploy มีขั้นตอนพิเศษ"), การตัดสินใจในอดีต ("ครั้งที่แล้วเราเลือกตัวเลือก A เพราะ X")
Memory ไม่ใช่สำหรับ: รายละเอียดโค้ด, ประวัติ Git, สถานะชั่วคราว—สิ่งเหล่านี้ดึงจากโค้ดและ Git ได้แม่นยำกว่า
ใช้คำสั่ง /memory เพื่อดูและจัดการ Memory ที่โหลดทั้งหมด
6. การจัดการสิทธิ์: สร้างสมดุลระหว่างความปลอดภัยและประสิทธิภาพ
Claude Code มีโหมดสิทธิ์ห้าโหมด สลับด้วย Shift+Tab ในการสนทนา:

การกำหนดค่ากฎสิทธิ์
ใน .claude/settings.json คุณสามารถควบคุมสิทธิ์ของแต่ละ tool ได้อย่างละเอียด:
1{2 "permissions": {3 "allow": [4 "Bash(npm run *)",5 "Bash(git commit *)",6 "Edit(src/**/*.ts)",7 "Read(*.md)"8 ],9 "deny": [10 "Bash(rm -rf *)",11 "Edit(.env)"12 ]13 }14}
ลำดับความสำคัญของกฎ: deny → ask → allow (deny มีความสำคัญสูงสุด)
หมายความว่าคุณสามารถอนุญาตคำสั่งทั่วไปอย่างกล้าหาญ ในขณะที่ใช้ deny เพื่อปกป้องไฟล์ที่ละเอียดอ่อน เช่น ไฟล์ .env ไม่ควรถูกแก้ไข
ลำดับชั้นของไฟล์ตั้งค่า
คล้ายกับ CLAUDE.md, settings มีหลายระดับ:
1นโยบายองค์กร (ความสำคัญสูงสุด)2 ↓3อาร์กิวเมนต์ CLI4 ↓5.claude/settings.local.json (ระดับท้องถิ่น, ไม่ถูก commit ไปยัง Git)6 ↓7.claude/settings.json (ระดับโปรเจกต์, แชร์กับทีม)8 ↓9~/.claude/settings.json (ระดับโลก, ส่วนตัว)10 ↓11ค่าเริ่มต้น (ความสำคัญต่ำสุด)
คำแนะนำของฉัน: ใส่กฎที่แชร์กับทีมใน .claude/settings.json, ความชอบส่วนตัวใน ~/.claude/settings.json, และ config ที่ละเอียดอ่อนใน .claude/settings.local.json (อย่าลืมเพิ่มใน .gitignore)
7. HOOKS: เปลี่ยนกฎให้เป็นกฎเหล็ก
คำแนะนำใน CLAUDE.md เป็น "ข้อเสนอ"—Claude ปฏิบัติตามส่วนใหญ่ แต่บางครั้งก็ลืม Hooks คือ "กฎเหล็ก"—มันทำงานไม่ว่าจะเกิดอะไรขึ้น
Hooks คือคำสั่ง shell ที่ถูกเรียกใช้โดยอัตโนมัติตามเหตุการณ์ในวงจรชีวิตเฉพาะ กำหนดค่าใน settings.json
ประเภทเหตุการณ์สำคัญ

ตัวอย่างที่ใช้ได้จริง
จัดรูปแบบอัตโนมัติ—รัน Prettier หลังทุกการแก้ไข:
1{2 "hooks": {3 "PostToolUse": [{4 "matcher": "Edit|Write",5 "hooks": [{6 "type": "command",7 "command": "jq -r '.tool_input.file_path' | xargs npx prettier --write"8 }]9 }]10 }11}
ปกป้องไฟล์สำคัญ—ป้องกันการแก้ไข config การผลิต:
1{2 "hooks": {3 "PreToolUse": [{4 "matcher": "Edit|Write",5 "hooks": [{6 "type": "command",7 "command": ".claude/hooks/protect-files.sh"8 }]9 }]10 }11}
คำสั่ง hook ที่คืนค่า exit code 0 หมายถึงอนุญาต; exit code 2 หมายถึงถูกบล็อก หมายความว่าคุณสามารถเขียนตรรกะที่ซับซ้อนได้ตามต้องการ
แทรกข้อมูลสำคัญอีกครั้งหลังการบีบอัด context:
1{2 "hooks": {3 "SessionStart": [{4 "matcher": "compact",5 "hooks": [{6 "type": "command",7 "command": "echo 'ใช้ Bun, ไม่ใช่ npm. รัน bun test ก่อน commit.'"8 }]9 }]10 }11}
วิธีนี้แก้ปัญหาที่พบบ่อย: เมื่อการสนทนายาวถูกบีบอัด คำแนะนำสำคัญที่พูดไว้ก่อนหน้านี้อาจหายไป Hooks สามารถแทรกกลับเข้าไปโดยอัตโนมัติหลังทุกการบีบอัด
Hooks สี่ประเภท
8. GIT WORKFLOW: ใช้ WORKTREE ให้เป็นประโยชน์
Claude Code สามารถรันคำสั่ง Git ซึ่งเป็นดาบสองคม แต่เครื่องมือทางการมีตาข่ายนิรภัยที่ดี: Worktree
Git Worktree: พื้นที่ทำงานแยก
1# เริ่ม Claude ใน worktree ที่แยก2claude --worktree feature-auth3claude --worktree bugfix-12345# สร้างชื่ออัตโนมัติ6claude --worktree
Worktree สร้างสำเนาสาขา Git อิสระภายใต้ .claude/worktrees/ สิ่งที่ Claude ทำข้างในจะไม่ส่งผลต่อสาขาหลักของคุณ เมื่อออก:
- ถ้าไม่มีการเปลี่ยนแปลง → ล้างอัตโนมัติ
- ถ้ามีการเปลี่ยนแปลง → ถามว่าต้องการเก็บหรือลบ
สิ่งนี้มีประโยชน์มากสำหรับงานสำรวจ ไม่แน่ใจว่าแผนรีแฟกเตอร์จะใช้ได้? ลองใน worktree; ถ้าไม่ได้ผลก็ทิ้งไปโดยไม่มีความเสี่ยง
กฎเหล็ก Git สองสามข้อ
1. อย่าให้ Claude Code auto-push
มัน commit ได้ แต่การ push ควรให้คุณยืนยัน เมื่อ push ไปยัง remote แล้ว ค่าใช้จ่ายในการย้อนกลับเพิ่มขึ้นอย่างมาก
2. Commit บ่อยๆ
Commit หลังจากทำฟีเจอร์เล็กๆ เสร็จ ใช้ /rewind เพื่อกลับไปยัง checkpoint ใดๆ ก็ได้ ถ้าคุณมีบันทึก commit
3. ระวังการดำเนินการที่ทำลายล้าง
ถ้า Claude Code ต้องการรัน git reset --hard, git push --force, หรือ rm -rf คิดถึงผลลัพธ์ก่อนอนุมัติ การดำเนินการเหล่านี้ไม่สามารถยกเลิกได้ คุณสามารถปฏิเสธคำสั่งเหล่านี้ในกฎสิทธิ์ได้เช่นกัน
4. กู้คืน context จาก PR
วิธีนี้จะโหลดการเปลี่ยนแปลง PR และการสนทนาเป็น context โดยอัตโนมัติ เหมาะสำหรับการรีวิวโค้ดหรือทำงานต่อจากคนอื่น
1claude --from-pr 123
9. ทางลัดและคำสั่งอ้างอิง
ฉันใช้ทางลัดเหล่านี้ทุกวัน แนะนำให้จำให้ขึ้นใจ:
ทางลัดที่ใช้บ่อยที่สุด

คำสั่ง Slash ที่ใช้บ่อยที่สุด
1/compact [focus] # บีบอัด context, สามารถระบุโฟกัสได้2/clear # ล้างการสนทนา, เริ่มใหม่3/context # ดูการใช้งาน context4/memory # ดูและจัดการ Memory5/rewind # ย้อนกลับไปยัง checkpoint6/resume [name] # กลับไปยังการสนทนาก่อนหน้า7/model # สลับโมเดล8/effort [level] # ตั้งค่าระดับการใช้เหตุผล: low/medium/high/max9/init # สร้าง CLAUDE.md อัตโนมัติ10/mcp # จัดการ MCP servers11/permissions # ดูกฎสิทธิ์12/cost # ดูการใช้งาน token
/init มีประโยชน์มากสำหรับโปรเจกต์ใหม่—มันวิเคราะห์โค้ดเบสของคุณโดยอัตโนมัติและช่วยสร้าง CLAUDE.md ฉบับร่าง แม้ปกติจะต้องปรับด้วยตนเอง แต่ก็เร็วกว่าเริ่มจากศูนย์มาก
10. EXTENDED THINKING: ให้ Claude คิดลึกขึ้น
สำหรับปัญหาที่ซับซ้อน คุณสามารถเปิดใช้งานโหมด Extended Thinking เพื่อให้ Claude ใช้เวลาในการใช้เหตุผลมากขึ้นก่อนตอบ
วิธีใช้
1# ทางลัดสลับ2Option+T (Mac) / Alt+T (Windows/Linux)34# หรือผ่านคำสั่ง5/effort high # การใช้เหตุผลลึกขึ้น6/effort max # ระดับการใช้เหตุผลสูงสุด7/effort low # งานง่ายๆ, ประหยัด tokens
เมื่อไหร่ควรใช้
- การตัดสินใจด้านสถาปัตยกรรมที่ซับซ้อน
- การดีบักที่ยุ่งยาก (มีสาเหตุที่เป็นไปได้หลายอย่างที่ต้องกำจัด)
- การออกแบบรีแฟกเตอร์หลายขั้นตอน
- การชั่งน้ำหนักข้อดีข้อเสียของหลายวิธีแก้ปัญหา
เมื่อไหร่ที่ไม่ต้องใช้
- การเปลี่ยนแปลงโค้ดง่ายๆ
- การจัดรูปแบบ, การเปลี่ยนชื่อ
- การแก้บั๊กที่ชัดเจนอยู่แล้ว
เคล็ดลับมือโปร: การเขียน "ultrathink" ใน prompt สามารถบังคับระดับการใช้เหตุผลสูงสุดโดยไม่ต้องปรับการตั้งค่า effort ด้วยตนเอง
11. MCP SERVER: เชื่อมต่อ Claude กับโลกภายนอก
MCP (Model Context Protocol) ช่วยให้ Claude Code สื่อสารกับเครื่องมือภายนอก—GitHub, ฐานข้อมูล, Slack, Notion ฯลฯ
เพิ่มอย่างรวดเร็ว
1claude mcp add github -- npx @anthropic-ai/mcp-server-github2claude mcp add postgres -- npx @anthropic-ai/mcp-server-postgres postgresql://localhost:5432/mydb
ไฟล์การกำหนดค่า
MCP ถูกกำหนดค่าใน .mcp.json:
1{2 "mcpServers": {3 "github": {4 "type": "stdio",5 "command": "npx",6 "args": ["@modelcontextprotocol/server-github"],7 "env": {8 "GITHUB_TOKEN": "$GITHUB_TOKEN"9 }10 }11 }12}
ข้อควรระวังเรื่องค่าใช้จ่ายของ Context
MCP server แต่ละตัวกิน tokens เพิ่มอีก 100-500+ สำหรับคำจำกัดความของ tool ใช้คำสั่ง /mcp เพื่อตรวจสอบค่าใช้จ่ายของแต่ละ server และปิดการใช้งานตัวที่ไม่ใช้
ประสบการณ์ของฉัน: อย่าโลภ MCP server ที่ใช้บ่อย 2-3 ตัวก็พอ การติดตั้งมากเกินไปกินพื้นที่ context ด้วยคำจำกัดความของ tool ซึ่งอาจลดคุณภาพการวิเคราะห์โค้ดได้
12. การรวม IDE: มากกว่าแค่เทอร์มินัล
VS Code
หลังจากติดตั้งส่วนขยาย Claude Code คุณสามารถใช้ Claude ใน VS Code ได้โดยตรง โดยไม่ต้องสลับไปยังเทอร์มินัล
ฟีเจอร์ที่มีประโยชน์:
- มุมมอง diff แบบเคียงข้าง: การเปลี่ยนแปลงของ Claude แสดงเป็น diff, เห็นชัดเจน
- Option+K / Alt+K: แทรก @references ไปยังไฟล์ปัจจุบันอย่างรวดเร็ว
- การสนทนาหลายแท็บ: เปิดการสนทนาอิสระหลายรายการในแท็บต่างๆ
- Cmd+Shift+Esc: เปิดแท็บการสนทนาใหม่อย่างรวดเร็ว
JetBrains
IntelliJ, PyCharm, WebStorm และ IDE JetBrains อื่นๆ ก็มีปลั๊กอิน Claude Code เช่นกัน แค่ค้นหา "Claude Code" ในตลาดปลั๊กอินเพื่อติดตั้ง
13. การรีวิวโค้ด: ไว้ใจแต่ตรวจสอบ
คุณภาพโค้ดของ Claude Code โดยทั่วไปดี แต่คุณไม่ควรเชื่อใจมันแบบสุ่มสี่สุ่มห้า
ปัญหาที่พบบ่อย
1. การออกแบบที่ซับซ้อนเกินจำเป็น
คุณขอฟังก์ชันยูทิลิตี้ง่ายๆ แต่มันให้เลเยอร์นามธรรมเต็มรูปแบบพร้อม generics, interfaces และ factory patterns ใช้ปืนใหญ่ยิงยุง
วิธีแก้ไข: เขียน "ให้ความสำคัญกับวิธีแก้ปัญหาง่ายๆ" ใน CLAUDE.md หรือบอกชัดๆ ว่า "ไม่ต้องมี abstraction" ในคำแนะนำ
2. API ที่หลอน
บางครั้งมันใช้ API ที่ไม่มีอยู่จริง หรือ syntax ที่ล้าสมัย โดยเฉพาะสำหรับไลบรารี niche เวอร์ชันใหม่
วิธีแก้ไข: รันเทส นี่คือสาเหตุที่คำแนะนำควรมีมาตรฐานการตรวจสอบ
3. การขยายขอบเขต
คุณขอให้เปลี่ยนฟังก์ชันหนึ่ง แต่มันรีแฟกเตอร์ทั้งไฟล์
วิธีแก้ไข: บอกชัดๆ ว่า "เปลี่ยนแค่ X, อย่าแตะโค้ดอื่น" หรือใช้คำสั่ง /freeze เพื่อจำกัดขอบเขตการแก้ไขไปยังไดเรกทอรีเฉพาะ
โหมด Writer/Reviewer
โหมดขั้นสูงที่แนะนำโดยทางการ: ใช้สองเซสชันอิสระเพื่อเล่นบทบาท "Writer" และ "Reviewer"
สองเซสชันมี context อิสระ; Reviewer ไม่ได้รับอิทธิพลจากตรรกะของ Writer และสามารถหาจุดบอดได้
1เซสชัน A (Writer): "Implement API rate-limiting middleware"2เซสชัน B (Reviewer): "Review the rate-limiting implementation in @src/middleware/rateLimiter.ts,3 focusing on edge cases, race conditions, and consistency"4เซสชัน A: "Fix review feedback: [วางผลลัพธ์ของ B]"
14. สิ่งที่ไม่ควรทำกับ Claude Code
พูดถึง "สิ่งที่ควรทำ" มาหมดแล้ว มาพูดถึง "สิ่งที่ไม่ควรทำ" กันบ้าง
1. อย่าให้มันทำสิ่งที่คุณไม่เข้าใจเลย
ถ้าคุณไม่รู้เรื่อง Kubernetes เลย อย่าให้ Claude Code เขียน config deployment ให้คุณใช้โดยตรง คุณไม่สามารถรีวิวสิ่งที่คุณไม่เข้าใจ
2. อย่าใช้ในสภาพแวดล้อมที่ไม่มีระบบควบคุมเวอร์ชัน
ไม่มี Git หมายถึงไม่มีความสามารถในการย้อนกลับ การเปลี่ยนแปลงของ Claude Code อาจเขียนทับไฟล์ของคุณ การใช้โดยไม่มีระบบควบคุมเวอร์ชันเหมือนเดินไต่เชือกโดยไม่มีตาข่ายนิรภัย
3. อย่าโยนงานใหญ่โตให้มันทำทีเดียว
"ย้ายทั้งโปรเจกต์จาก JavaScript ไป TypeScript"
คำแนะนำนี้ให้อิสระแก่ Claude Code เต็มที่ ทำให้ผลลัพธ์ควบคุมไม่ได้ แบ่งเป็นขั้นตอนเล็กๆ และยืนยันแต่ละขั้นตอนก่อนไปต่อ
4. อย่าคาดหวังความสมบูรณ์แบบในครั้งแรก
การทำซ้ำเป็นเรื่องปกติ ใช้ /rewind เพื่อย้อนกลับ และใช้ข้อเสนอแนะที่แม่นยำเพื่ออธิบาย "อะไรที่ผิด"
สรุป
ปรัชญาหลักของการใช้ Claude Code นั้นง่าย:
มันเป็นผู้ร่วมงานที่มีความสามารถอย่างยิ่ง แต่ไม่ใช่ระบบขับเคลื่อนอัตโนมัติ พวงมาลัยอยู่ในมือคุณเสมอ
เรียงตามความสำคัญ คำแนะนำของฉันคือ:
- เขียน CLAUDE.md ให้ดี — ลงทุนครั้งเดียว ได้ประโยชน์ทุกครั้งที่สนทนา
- ให้คำแนะนำที่แม่นยำ — เป้าหมาย + ข้อจำกัด + มาตรฐานการตรวจสอบ
- ใช้โหมด Plan — วางแผนก่อน แล้วค่อยลงมือทำสำหรับงานที่ซับซ้อน
- จัดการบริบท — /clear, /compact, Sub-agents
- ควบคุมสิทธิ์ — ปฏิเสธการดำเนินการที่อันตราย อนุญาตคำสั่งทั่วไป
- Commit บ่อยๆ — รักษาความสามารถในการย้อนกลับ
ทำตามนี้ แล้ว Claude Code จะช่วยเพิ่มประสิทธิภาพของคุณได้หลายเท่า หากไม่ทำตาม มันจะช่วยให้คุณสร้างความวุ่นวายได้เร็วขึ้นเท่านั้น
คุณค่าของเครื่องมือขึ้นอยู่กับผู้ใช้เสมอ
เนื้อหาข้างต้นเป็นการผสมผสานระหว่างเอกสารทางการของ Claude Code และประสบการณ์จริง หากคุณมีแนวทางปฏิบัติที่ดีกว่า ยินดีแบ่งปันได้เลย



![กลยุทธ์ AI สุดอัจฉริยะของ Mark Zuckerberg: การผสาน AI เข้ากับชีวิตและธุรกิจ [พร้อมชุดคำสั่ง]](/cdn-cgi/image/width=1920,quality=90,format=auto,metadata=none/https%3A%2F%2Fcms-assets.youmind.com%2Fmedia%2F1783879071532_p6yioz_HM62kqza8AAOydz.jpg)

