14 คำสั่ง Claude Code ที่เปลี่ยนวิธีทำงานไปเลย พร้อมเช็กว่าคำสั่งไหนถูกถอดออกแล้วบ้าง

มีบทความหนึ่งบน Towards AI ที่คนแชร์กันเยอะ ชื่อว่า I Wasted 6 Months Using Claude Code Wrong เขียนโดย Mouez Yazidi เล่าว่าเขาใช้ Claude Code มาหกเดือนโดยรู้จักอยู่คำสั่งเดียว จนกระทั่งเพื่อนบอกให้ลองพิมพ์ /compact แล้วบทสนทนาที่ยาว 147 ข้อความก็ถูกย่อลงเหลือสรุปสั้นๆ พื้นที่ context ว่างขึ้นมาทันที

เราหยิบ 14 คำสั่งจากบทความนั้นมาเรียบเรียงเป็นภาษาไทย แต่ไม่ได้แปลตรงตัว เพราะพอเอาไปเทียบกับเอกสารทางการของ Claude Code ฉบับปัจจุบันแล้วพบว่า มี 2 คำสั่งที่ถูกถอดออกไปแล้ว และอีกหลายคำสั่งเปลี่ยนชื่อหรือมีตัวใหม่ที่ดีกว่ามาแทน บทความนี้จึงเป็นฉบับที่ตรวจสอบกับเอกสารทางการแล้ว พร้อมบอกทางเลือกทดแทนให้ด้วย

ส่วนที่ 1 ตั้งค่าครั้งเดียว ใช้ได้ตลอด

1. /init สร้างเอกสารโปรเจกต์อัตโนมัติ

ปัญหาที่ทุกคนเจอคือเปิดโปรเจกต์ใหม่ทีไรต้องเสียเวลาชั่วโมงแรกไปกับการอธิบายว่าโปรเจกต์นี้ใช้อะไรบ้าง โครงสร้างเป็นยังไง คำสั่ง /init จะอ่านโปรเจกต์ทั้งหมดแล้วเขียนไฟล์ CLAUDE.md ให้เอง ทั้งสรุปโปรเจกต์ สถาปัตยกรรม แนวทางการเขียนโค้ด และคำสั่งสำคัญ ไฟล์นี้จะถูกโหลดทุกครั้งที่เริ่มงานใหม่

/init

2. /memory ตั้งค่าที่ใช้ข้ามทุกโปรเจกต์

พอใช้ /init ไปหลายโปรเจกต์จะพบว่ายังต้องบอกเรื่องเดิมซ้ำอยู่ดี เช่น ให้เขียน test ก่อนเสมอ หรือห้ามใช้ any ใน TypeScript คำสั่ง /memory เปิดไฟล์ที่ใช้เก็บกฎเหล่านี้ไว้ถาวร เขียนครั้งเดียวใช้ได้ทุกโปรเจกต์

- แนะนำให้เขียน test ก่อนเสมอ
- ใช้ composition แทน inheritance
- อธิบาย logic ที่ซับซ้อนด้วยคอมเมนต์
- ห้ามใช้ any ถ้าไม่ได้ขออนุญาตก่อน

ส่วนที่ 2 คำสั่งที่ใช้ทุกวัน

3. /compact บีบอัดบทสนทนาโดยไม่ต้องเริ่มใหม่

เมื่อคุยกันยาวจนคำตอบเริ่มช้าและเริ่มลืมสิ่งที่ตกลงกันไว้ตอนต้น คนส่วนใหญ่จะปิดแล้วเปิดใหม่ ซึ่งเสียงานที่ทำมาทั้งหมด /compact สรุปเฉพาะสาระสำคัญเก็บไว้แล้วคืนพื้นที่ให้ จุดที่หลายคนไม่รู้คือสั่งได้ด้วยว่าให้เก็บอะไรเป็นพิเศษ

/compact เก็บรายละเอียดโครงสร้างฐานข้อมูลกับ API ที่ตกลงกันไว้

4. /btw ถามแทรกโดยไม่ทำให้งานหลักหลุด

กำลังทำงานอยู่ดีๆ แล้วนึกสงสัยขึ้นมาว่า JWT กับ session cookie ต่างกันยังไง ถ้าถามตรงๆ ในบทสนทนาหลักก็จะทำให้เนื้อหางานปนกัน /btw ให้ถามคำถามแทรกได้โดยไม่กระทบบริบทของงานหลัก

/btw refresh token ควรเก็บที่ไหนถึงจะปลอดภัยที่สุด

5. เครื่องหมาย ! รันคำสั่ง shell ได้ในที่เดียว

เดิมต้องสลับไปเทอร์มินัล พิมพ์คำสั่ง คัดลอกผลลัพธ์ แล้วสลับกลับมาวาง เจ็ดขั้นตอนทุกครั้ง ใส่เครื่องหมายอัศเจรีย์นำหน้าแล้วรันได้เลย ผลลัพธ์เข้ามาอยู่ในบทสนทนาทันที

! git status
! npm run test

6. /usage ดูว่าใช้ token ไปเท่าไรแล้ว

ในบทความต้นทางใช้ /cost ซึ่งปัจจุบันยังใช้ได้อยู่แต่กลายเป็นชื่อเรียกแทนของ /usage ไปแล้ว คำสั่งนี้บอกจำนวน token และค่าใช้จ่ายของเซสชัน เหมือนเกจวัดน้ำมัน ทำให้รู้ว่าควร /compact ตอนไหนก่อนจะไปต่อไม่ไหว

7. /context ตัวช่วยที่บทความต้นทางยังไม่ได้พูดถึง

คำสั่งนี้ไม่ได้อยู่ในลิสต์ 14 ตัวของบทความต้นฉบับ แต่เราอยากแนะนำเพิ่มเพราะมีประโยชน์มาก มันแสดงการใช้ context เป็นตารางสีให้เห็นเลยว่าอะไรกินพื้นที่อยู่ ทั้ง system prompt เครื่องมือ ไฟล์ที่เปิดค้าง และประวัติการสนทนา ใช้คู่กับ /compact จะเห็นภาพชัดขึ้นมากว่าควรบีบอัดตอนไหน

/context

ส่วนที่ 3 ยกระดับการใช้งาน

8. /model สลับโมเดลกลางคัน

หลายคนไม่รู้ว่าเปลี่ยนโมเดลระหว่างเซสชันได้โดยไม่ต้องเริ่มใหม่ ใช้โมเดลใหญ่ตอนออกแบบสถาปัตยกรรมที่ต้องคิดเยอะ พอได้แผนแล้วสลับไปโมเดลเล็กเพื่อ generate โค้ดให้เร็ว แล้วค่อยสลับกลับมาตอนตรวจงาน วิธีนี้ทั้งเร็วขึ้นและประหยัดขึ้น

9. /fast เปิดโหมดตอบเร็ว

ตอนกำลังลองไอเดียหรือ prototype ไม่จำเป็นต้องได้คำตอบที่คิดละเอียดที่สุด เปิด /fast ไว้ตอนพัฒนาช่วงแรก แล้วปิดตอนต้องการให้ตรวจงานอย่างละเอียด

10. /review ตรวจโค้ดอย่างเป็นระบบ

ปัจจุบันคำสั่งนี้เป็นชื่อเรียกแทนของ /code-review และทำได้มากกว่าเดิม เลือกความละเอียดได้ตั้งแต่ low ถึง max และสั่งให้แก้ให้เลยด้วย --fix ได้

/code-review high
/code-review high --fix

ผลลัพธ์จะเป็นรายการปัญหาพร้อมเลขบรรทัด เช่น จุดที่อาจเป็น null reference ลูปที่ไม่มีประสิทธิภาพ หรือช่องโหว่ที่ยังไม่ได้ sanitize ข้อมูลจากผู้ใช้

ส่วนที่ 4 เมื่อมีอะไรผิดพลาด

11. /clear ล้างบทสนทนาแต่เก็บการตั้งค่าไว้

เมื่อบทสนทนาวนอยู่ที่เดิมแก้ไม่ตก อย่าเพิ่งปิดหน้าต่างทิ้ง /clear ล้างเฉพาะบทสนทนา ส่วนเครื่องมือ สิทธิ์ และบริบทของโปรเจกต์ยังอยู่ครบ เป็นการรีเซ็ตแบบเบา ไม่ใช่เริ่มจากศูนย์

12. /rewind ย้อนกลับไปจุดก่อนหน้า

อีกตัวที่ไม่ได้อยู่ในบทความต้นทางแต่ควรรู้ไว้ ใช้ย้อนทั้งโค้ดและบทสนทนากลับไปยังจุดก่อนหน้าได้ เหมาะกับตอนที่ให้ลองแนวทางหนึ่งแล้วไม่เวิร์ก จะได้ไม่ต้องแบกความพยายามที่ล้มเหลวไว้ใน context

13. /doctor ตรวจสุขภาพการติดตั้ง

ถ้ารู้สึกว่าอะไรๆ ไม่ปกติ คำสั่งไม่ทำงาน ก่อนจะลงโปรแกรมใหม่ทั้งหมดให้รันตัวนี้ก่อน มันจะตรวจ API key เวอร์ชัน Node สิทธิ์การเข้าถึง และไฟล์ตั้งค่าให้ครบ

14. /help ดูคำสั่งทั้งหมด

คำสั่งพื้นฐานที่สุดแต่มีประโยชน์เสมอ เพราะ Claude Code เพิ่มคำสั่งใหม่เข้ามาเรื่อยๆ ตามเวอร์ชัน การรัน /help เป็นระยะจะทำให้เห็นของใหม่ที่เพิ่มเข้ามา

2 คำสั่งในบทความต้นทางที่ใช้ไม่ได้แล้ว

ตรงนี้คือส่วนสำคัญที่อยากให้อ่าน เพราะถ้าไปตามบทความต้นฉบับแล้วพิมพ์สองคำสั่งนี้จะไม่เกิดอะไรขึ้น

/pr_comments ถูกถอดออกตั้งแต่เวอร์ชัน 2.1.91

เดิมใช้ดึงคอมเมนต์จาก pull request บน GitHub เข้ามาในบทสนทนา ปัจจุบันไม่มีคำสั่งนี้แล้ว ให้สั่งด้วยภาษาธรรมดาแทนได้เลย เช่น บอกให้ไปอ่านคอมเมนต์ใน PR หมายเลขนั้นแล้วสรุปมาให้ หรือถ้าทำงานกับ PR บ่อยจะใช้ /code-review ที่รับหมายเลข PR ได้โดยตรง

/code-review high 1234

/terminal-setup ไม่มีในเอกสารปัจจุบันแล้ว

เดิมใช้ตั้งค่าให้ Claude Code มองเห็นผลลัพธ์ในเทอร์มินัลได้ ปัจจุบันความสามารถนี้ทำงานให้อยู่แล้วโดยไม่ต้องตั้งค่าเพิ่ม ถ้าเจอปัญหาเรื่องการเชื่อมต่อกับเทอร์มินัลหรือ IDE ให้ใช้ /doctor ตรวจ หรือ /ide จัดการการเชื่อมต่อกับ IDE แทน

ก้าวต่อไป สร้างคำสั่งของตัวเอง

เมื่อใช้คำสั่งพื้นฐานคล่องแล้ว สิ่งที่ให้ผลตอบแทนสูงที่สุดคือการทำคำสั่งของตัวเองสำหรับงานที่ทำซ้ำทุกวัน วิธีคือสร้างไฟล์ Markdown ไว้ในโฟลเดอร์ .claude/skills/ ของโปรเจกต์ ชื่อโฟลเดอร์จะกลายเป็นชื่อคำสั่งอัตโนมัติ

ตัวอย่างไฟล์ .claude/skills/deploy/SKILL.md

---
name: deploy
description: นำโค้ดขึ้นเซิร์ฟเวอร์ production
disable-model-invocation: true
---

ทำตามขั้นตอนนี้
1. รัน test ทั้งหมด ถ้าไม่ผ่านให้หยุด
2. build โปรเจกต์
3. สำรองไฟล์เดิมบนเซิร์ฟเวอร์ก่อนทับ
4. อัปโหลดขึ้น production แล้วตรวจว่าเว็บยังเปิดได้

บันทึกแล้วเรียกด้วย /deploy ได้ทันที บรรทัด disable-model-invocation: true คือบอกว่าให้เรียกเองเท่านั้น ไม่ต้องให้โมเดลตัดสินใจเรียก ซึ่งจำเป็นมากกับคำสั่งที่มีผลกระทบจริงอย่างการ deploy

รับพารามิเตอร์ได้ด้วยตัวแปร $ARGUMENTS หรือระบุเป็นตัวๆ ด้วย $0 และ $1

---
name: review-file
description: ตรวจไฟล์ที่ระบุแบบละเอียด
---

ตรวจไฟล์ $ARGUMENTS โดยเน้นเรื่องความปลอดภัยและ SQL injection

/review-file www/search_result.php

แผน 7 วันสำหรับคนเริ่มต้น

• วันที่ 1 รัน /init กับโปรเจกต์ที่ทำอยู่
• วันที่ 2 ตั้งค่า /memory ใส่กฎการเขียนโค้ดที่ใช้ประจำสัก 5 ข้อ
• วันที่ 3 ใช้ /btw ทุกครั้งที่มีคำถามแทรก
• วันที่ 4 เมื่อ context เริ่มเต็ม ใช้ /context ดูก่อนแล้วค่อย /compact
• วันที่ 5 ลองใช้เครื่องหมาย ! รันคำสั่ง shell โดยไม่สลับหน้าต่าง
• วันที่ 6 รัน /code-review กับงานที่กำลังจะส่ง
• วันที่ 7 ลองสลับ /model ให้เหมาะกับแต่ละช่วงของงาน

สิ่งที่ทำให้ต่างกันไม่ใช่ความเก่งหรือประสบการณ์ แต่เป็นการรู้จักเครื่องมือที่มีอยู่แล้วในมือ ลองเลือกมาสักคำสั่งหนึ่งแล้วใช้จริงวันนี้

ที่มา: เรียบเรียงและตรวจสอบข้อมูลใหม่จากบทความ I Wasted 6 Months Using Claude Code Wrong โดย Mouez Yazidi เผยแพร่บน Towards AI ร่วมกับ เอกสารทางการของ Claude Code โดยทีมงาน IT Genius