12 เคล็ดลับ Claude Code เพื่อประสิทธิภาพที่ดีขึ้น

Claude Code ตัวเดียวกัน แต่ให้ผลลัพธ์ต่างกันสิ้นเชิงขึ้นอยู่กับว่าใครเป็นคนใช้

บางคนใช้โควต้า 5 ชั่วโมงหมดอย่างรวดเร็ว ในขณะที่บางคนกลับ觉得มันเหลือเฟือ

--> ความแตกต่างอยู่ที่การตั้งค่าและพฤติกรรมการใช้งาน

⭐️ นี่คือ 12 เคล็ดลับการใช้ Claude Code อย่างถูกวิธี ⭐️

มีคำสั่งและพรอมต์ครบถ้วน คุณสามารถก๊อปปี้ไปวางได้เลย

--> เนื้อหาค่อนข้างยาวถ้าจะอ่านรวดเดียว... กดบุ๊กมาร์กเก็บไว้ก่อนดีไหม???

⚠️ ก่อนเริ่ม.. เช็คเวอร์ชันของคุณก่อน ⚠️

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

เช็คด้วยคำสั่ง claude --version ในเทอร์มินัล ถ้าตัวเลขยังต่ำอยู่ ก็แค่รัน claude update

คำสั่งในบทความนี้อ้างอิงจากเวอร์ชัน v2.1.302 ณ วันที่ 18 ตุลาคม

1. ตั้งค่า Effort ให้ต่างกันในแต่ Sub-agent

Effort คือตัวกำหนดว่า Claude จะคิดลึกแค่ไหนก่อนตอบ ตัวเลือกมีตั้งแต่ low, medium, high, xhigh ไปจนถึง max โดยระดับที่ใช้งานได้จะต่างกันเล็กน้อยตามแต่ละโมเดล

หลายคนตั้งเป็น Max หรือ XHigh แบบไม่คิดอะไร เพราะคิดว่ายิ่งสูงยิ่งดี

แต่มันไม่ใช่แบบนั้นเสมอไป

เมื่อลองสร้างแอปเดียวกันเพื่อเปรียบเทียบ ระดับ Max ใช้เวลาถึง 79 นาที ในขณะที่ระดับอื่นใช้เวลาแค่ 16 นาที

ผลลัพธ์ที่ได้แทบจะไม่ต่างกัน คุณแค่เสียเวลาและโทเค็นมากขึ้นเท่านั้นเอง

นี่คือสิ่งที่ผมสรุปได้จากประสบการณ์:

--> (หัวใจสำคัญ) 🔥 ถ้าคุณเขียนพรอมต์ได้ละเอียดพอ ผลลัพธ์สุดท้ายมักจะออกมาคล้ายกันไม่ว่าจะใช้ low หรือ max ก็ตาม 🔥

--> สำหรับการระดมสมอง ระดับ low หรือ medium กลับทำงานได้ดีกว่าด้วยซ้ำ

อย่างไรก็ตาม งานออกแบบที่ยาก บั๊กที่ซับซ้อน และการรีวิวที่สำคัญ บางครั้งก็จำเป็นต้องใช้ effort ที่สูงขึ้น

ประเด็นสำคัญไม่ใช่ "ต้องใช้ low เสมอ"

ตั้งแต่ 7 ต.ค. เป็นต้นมา.. ระบุ effort ตอนเรียก sub-agent ได้แล้ว!

เริ่มจากการอัปเดตวันที่ 7 ต.ค. (v2.1.292) Claude Code ตัวหลักสามารถระบุ effort ตอนที่เรียก sub-agent ได้แล้ว

ตอนนี้คุณสามารถสั่งงานแบบนี้ได้เลย:

แบ่งงานปัจจุบันออกเป็นสามขั้นตอน แล้วให้ sub-agent ดำเนินการ

1. ค้นหาตำแหน่งไฟล์และจัดระเบียบข้อมูล ด้วย effort ระดับ low

2. รีวิวข้อดี/ข้อเสียของแนวทางการแก้ไข ด้วย effort ระดับ medium

3. รีวิวหาบั๊กในโค้ดขั้นสุดท้าย ด้วย effort ระดับ high

แสดงให้ดูด้วยว่าแต่ละ sub-agent ได้รับ effort ระดับไหนจริงๆ

แล้วส่งกลับมาแค่ข้อสรุปและ path ของไฟล์หลักฐานให้ agent หลักเท่านั้น

ถ้าขี้เกียจพิมพ์สั่งทุกครั้ง ให้เซฟ agent เก็บเป็นไฟล์ไว้เลย

--> เช่น เซฟเป็น light-research.md ไว้ในโฟลเดอร์ .claude/agents/ ของโปรเจกต์

name: light-research

description: การค้นหาแบบเบาๆ สำหรับหาไฟล์ที่เกี่ยวข้องและตำแหน่งของหลักฐานเท่านั้น

model: haiku

effort: low

ทั้งสองวิธี—การระบุตอนเรียกใช้ (ตามพรอมต์ด้านบน) และการฟิกซ์ผ่านไฟล์—ใช้ได้ทั้งคู่!

2. การจัดการ Context และป้องกันการสูญเสียโทเค็น

🤪 สาเหตุที่ Claude Code อยู่ดีๆ ก็โง่ลง ส่วนใหญ่มาจาก context

Context คือพื้นที่ทำงานที่ Claude จดจำได้ในคราวเดียว ทั้งบทสนทนา ไฟล์ที่อ่าน และผลลัพธ์จากคำสั่ง ล้วนสะสมอยู่ในนี้ทั้งหมด

--> ปัจจุบัน Claude Code มี context ขนาด 1M (1 ล้านโทเค็น) เป็น 'ค่าเริ่มต้น'

ปัญหาคือการเติม 1M นี้จนเต็มเอี๊ยด

นี่ไม่ใช่เรื่องเฉพาะของ Claude แต่เป็นข้อจำกัดทั่วไปของ LLM ทุกตัวรวมถึง Codex ด้วย

⭐️ เคล็ดลับ: ตั้ง autocompact ไว้ที่ 500~700k ⭐️

ดังนั้นผมจึงดึงเกณฑ์ auto-compaction ให้เร็วขึ้น

/autocompact 600k

คำสั่งนี้จะลดขนาดหน้าต่างที่ใช้สำหรับ auto-compaction ลงเหลือ 600k โทเค็น

ก่อนที่ 1M จะเต็ม Claude จะสรุปบทสนทนาและคืนพื้นที่ให้อัตโนมัติ

(หากต้องการกลับไปใช้ค่าเริ่มต้น ให้พิมพ์ `/autocompact auto`)

⚠️ เรื่องที่สองที่ต้องระวัง: Cache หมดอายุ ⚠️

ถ้าคุณใช้ session เดิมนานๆ ต้องเช็คเรื่องนี้ให้ดี

Claude Code จะส่งบทสนทนาก่อนหน้าทั้งหมดไปใหม่ในทุกๆ คำขอ มันเร็วและถูกเพราะมีระบบ caching—ส่วนที่ประมวลผลไปแล้วจะไม่ถูกคำนวณซ้ำ

แต่ cache นี้ไม่ได้คงอยู่ตลอดไป

แพ็กเกจ Pro หรือ Max (การใช้งานภายในแผน): cache ของบทสนทนาหลักอยู่ได้ 1 ชั่วโมง
API key หรือเครดิตการใช้งานเพิ่มเติม: 5 นาที
Sub-agent: 5 นาที แม้จะมีแพ็กเกจสมัครสมาชิกก็ตาม

ผมเคยเห็นตัวเลข ~852k uncached บนหน้าจอของตัวเอง ในสภาวะนี้ แค่ส่งคำว่า "continue" ไปบรรทัดเดียว ก็ต้องประมวลผล ~850k โทเค็นใหม่ทั้งหมดโดยไม่มี cache ช่วย ยอดการใช้งานอาจพุ่งกระฉูดได้ในพริบตา

กรณีที่พบบ่อยซึ่งทำให้ cache พัง:

กลับมาทำ session ขนาดใหญ่ต่อหลังจากหยุดไปนาน
เปลี่ยนโมเดลกลางคัน (cache แยกกันตามแต่ละโมเดล)
เปลี่ยนการตั้งค่า MCP tool ที่เชื่อมต่ออยู่

วิธีแก้ก็ง่ายๆ:

เคลียร์ให้เรียบร้อยก่อนเลิกงาน ใช้ `/compact` ตอนที่ cache ยังมีชีวิตอยู่ หรือเริ่มใหม่เลยด้วย `/clear`
อัปเดตเป็นเวอร์ชันล่าสุด ตั้งแต่ v2.1.299 บทสนทนาที่ยาวเกิน 200k โทเค็นจะถูก บีบอัดอัตโนมัติหลังปล่อยทิ้งไว้ ~54 นาทีก่อนที่ cache 1 ชั่วโมงจะหมดอายุ (ปิดการทำงานนี้ได้ในการตั้งค่า /config หัวข้อ Idle compaction)

3. เคลียร์กฎเก่าๆ ทิ้งด้วย /doctor prompt-audit

CLAUDE.md ที่ก๊อปปี้มาจากคำแนะนำเก่าๆ กฎที่ค่อยๆ เพิ่มทีละข้อทุกครั้งที่ทำพลาด

ส่วนใหญ่เขียนขึ้นสำหรับโมเดลรุ่นเก่า

โมเดลใหม่ๆ ทำตามคำสั่งได้ดีกว่ารุ่นเก่ามาก

⚠️ ดังนั้นกฎที่เคยต้องเน้นย้ำอย่าง "ต้องทำ!!" "ห้ามเด็ดขาด!!" ในอดีต ตอนนี้อาจจะทำงานมากเกินไปจนกลายเป็นผลเสีย ⚠️

ยังมีกฎที่ขัดแย้งกับโค้ดปัจจุบันหรือขัดแย้งกันเองสะสมอยู่เต็มไปหมด

ตอนนี้คุณสามารถตรวจสอบได้ด้วยคำสั่งเดียว

markdown

1/doctor prompt-audit

ฟีเจอร์นี้เพิ่มเข้ามาในการอัปเดตช่วงปลายเดือนกันยายน (v2.1.283)

มันตรวจอะไรบ้าง?

CLAUDE.md และ CLAUDE.local.md, AGENTS.md ในโฟลเดอร์โปรเจกต์และโฟลเดอร์แม่
~/.claude/CLAUDE.md (แนวทางส่วนตัวของคุณที่ใช้กับทุกโปรเจกต์)
Rules, skills, custom commands, คำจำกัดความ sub-agent, output styles ที่อยู่ข้างใน .claude/

มันจะรายงานปัญหา แต่จะไม่แนะนำวิธีแก้สำหรับ plugin skills และ agents

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

(มันจะไม่อ่านไฟล์ที่อาจมีคีย์ลับซ่อนอยู่ เช่น ไฟล์ตั้งค่า หรือ .mcp.json)

4. แก้สภาพแวดล้อมการทำงานเมื่อ Claude ทำพลาดซ้ำๆ

⛏️ ตอนที่ AI เริ่มมั่วอีกแล้ว นั่งแก้ปัญหาเดิมอยู่เป็นชั่วโมง ⛏️

ถ้าคุณต้องแก้เรื่องเดิมเป็นครั้งที่สาม มันไม่ใช่ความผิดของโมเดลแล้ว แต่เป็นความผิดของสภาพแวดล้อมการทำงาน

ผมใช้วิธีนี้มาตั้งแต่ยุค Claude Sonnet 3.7 กว่าปีแล้ว อธิบายคร่าวๆ คือ..

--> ให้ AI วิเคราะห์ session ที่มันทำพลาด แล้วนำสาเหตุไปสะท้อนไว้ในแนวทางของโปรเจกต์และวิธีการตรวจสอบ

⭐️ ทำตามนี้เลย! "วิเคราะห์ข้อผิดพลาดโดยใช้ Session ID" ⭐️

1. พิมพ์ `/status` ใน session ที่เกิดข้อผิดพลาดซ้ำๆ เพื่อเอา Session ID มาก๊อปปี้ไว้

2. เปิด session Claude Code ใหม่ (ใช้ Codex ก็ได้) แล้ววางข้อความนี้ลงไป:

markdown

1"<Session ID>" → หาจุดที่ session Claude Code นี้ล้มเหลวตั้งแต่สองครั้งขึ้นไป
2
3หาสิ่งที่ฉันทักท้วงไปแล้วแต่ก็ยังทำผิดซ้ำ และจุดที่เป็นคอขวด
4
5จัดหมวดหมู่ว่าทำไมถึงเกิดขึ้น (สมมติฐานผิด, ขาด context, โครงสร้างโค้ด, ไม่มีเทส)
6
7แล้วเสนอวิธีแก้ไขที่เล็กที่สุดเฉพาะสำหรับ CLAUDE.md, .claude/rules, skills,
8hooks, หรือ tests เพื่อป้องกันไม่ให้เกิดซ้ำอีก

3. ตรวจสอบข้อเสนอแนะ แล้วเลือกใช้เฉพาะอันที่ดีจริงๆ

4. ทดสอบประสิทธิภาพ ลองส่งคำขอที่เคยพลาดเมื่อกี้ดูใหม่ว่าตอนนี้เวิร์กหรือยัง

⚠️ อย่าโยนทุกอย่างไปกองรวมกันใน CLAUDE.md ⚠️

ยิ่งมันยาวเท่าไหร่ ยิ่งกิน context มากเท่านั้น และกฎจะเริ่มขัดแย้งกัน!!!

กฎระดับโปรเจกต์ใส่ไว้ใน CLAUDE.md
กฎสำหรับโฟลเดอร์/ไฟล์เฉพาะเจาะจง ใส่ไว้ใน .claude/rules/ หรือ CLAUDE.md ภายในโฟลเดอร์นั้น
ขั้นตอนที่ทำซ้ำๆ ให้ทำเป็น Skills
กฎเหล็กที่ต้องทำตาม ใช้ Hooks และ permissions (เคล็ดลับ #10)
บั๊กเดิมที่เกิดซ้ำๆ ให้แก้ด้วย regression tests

หมั่นเคลียร์กฎที่สะสมไว้ด้วยเคล็ดลับ #3 `/doctor prompt-audit` เป็นระยะๆ เคล็ดลับ #4 เอาไว้สร้าง เคล็ดลับ #3 เอาไว้ล้าง

5. รักษาความจำการทำงานข้าม session ด้วย Claude-Mem

Claude Code จะลืมบทสนทนาทันทีที่ session จบลง

**"รอบที่แล้วเราทำแบบนั้นไปทำไมนะ?"

"เราแก้เออเรอร์นั้นยังไงนะ?"**

คุณต้องมานั่งอธิบายใหม่ทุกครั้งที่เปิด session

ปลั๊กอิน Claude Code ตัวเดียวที่ผมใช้ต่อเนื่องมาทั้งปีช่วยแก้ปัญหานี้ได้

--> claude-mem

⭐️ มันมียอดดาวบน GitHub กว่า 100k ดวง ⭐️

มันต่างจาก memory พื้นฐานยังไง?

Claude Code มี Auto Memory พื้นฐานอยู่แล้ว นี่คือความแตกต่าง:

Auto Memory พื้นฐานจะสรุปเนื้อหาที่ Claude คิดว่าสำคัญและสิ่งที่เรียนรู้จากโปรเจกต์เก็บเป็นโน้ต ดูได้ผ่าน /command ไม่ต้องติดตั้งอะไรเพิ่ม

claude-mem จะบันทึกอัตโนมัติว่าใน session ก่อนหน้าทำอะไรไปบ้าง แก้ไขเออเรอร์ยังไง และตัดสินใจแบบนั้นเพราะอะไร แล้วดึงบันทึกที่จำเป็นมาใช้ใน session ถัดไป

หน้าจอของผมแสดงให้เห็นว่าประหยัดโทเค็นได้สูงสุดถึง 87%

การติดตั้งใช้คำสั่งเดียวในเทอร์มินัล:

markdown

1npx claude-mem install

หรือติดตั้งเป็นปลั๊กอินใน Claude Code เลย:

markdown

1/plugin marketplace add thedotmack/claude-mem
2/plugin install claude-mem

❌ ไม่แนะนำให้ใช้ถ้า ❌

คุณใช้ Codex เป็นหลัก
คุณมีปลั๊กอิน memory ตัวอื่นหรือระบบส่งมอบงานแบบกำหนดเองอยู่แล้ว

การเพิ่มเครื่องมือที่ทับซ้อนกันจะทำให้ระบบซับซ้อนและต้นทุนสูงขึ้น

แต่ถ้าคุณใช้แค่ Claude Code ตัวเดียว ยังไงก็แนะนำอย่างยิ่ง

6. ดู Model, Effort, Context และ Usage ครบจบในแถบ Statusline

ระหว่างที่ใช้ Claude Code คุณจะสงสัยอยู่ตลอดเวลาว่า:

session นี้ใช้ Opus? Sonnet? หรือ Haiku?
ตั้ง effort ไว้ระดับไหน?
context เต็มไปเท่าไหร่แล้ว?
โควต้า 5 ชั่วโมงและรายสัปดาห์เหลืออีกเท่าไหร่?

🔥 Statusline จะแสดงข้อมูลเหล่านี้ไว้ที่ด้านล่างของเทอร์มินัลตลอดเวลา 🔥

สร้างง่ายมาก แค่พิมพ์บอก `/statusline` ว่าอยากได้หน้าตาแบบไหน แล้ว Claude จะเจนสคริปต์และนำไปใช้ให้เลย

5 ดีไซน์ที่ผมเคยแชร์ไว้

ก่อนหน้านี้ผมเคยแชร์พรอมต์ statusline แบบก๊อปปี้ไปวางได้เลย 5 แบบ

1. Minimal: โมเดล, effort, โปรเจกต์, context รวมอยู่ในบรรทัดเดียว

2. Pastel Blocks: บล็อกไฮไลท์สีพาสเทล เหมาะกับเทอร์มินัลธีมมืด

3. Nord Powerline: ขอบลูกศรโค้งมนแบ่งแต่ละส่วน

4. Limit Dot Bar: สำหรับสาย Pro/Max แสดงการใช้งาน 5 ชั่วโมงและ 7 วัน พร้อมเวลานับถอยหลังรีเซ็ตในรูปแบบ dot bar

5. Vivid Gauge: ป้ายชื่อสีเขียวมะนาวและเกจวัดแบบเฉียง มีจำนวนโทเค็น context ด้วย

พรอมต์เต็มๆ อยู่ในโพสต์ต้นทาง ก๊อปไปวางปุ๊บ Claude สร้างให้ปั๊บ

1. Minimal: https://x.com/lucian__03/status/2103173295118098750

2. Pastel Blocks: https://x.com/lucian__03/status/2103173396075065594

3. Nord Powerline: https://x.com/lucian__03/status/2103173518573916178

4. Limit Dot Bar: https://x.com/lucian__03/status/2103173612832444536

5. Vivid Gauge: https://x.com/lucian__03/status/2103173754218258607

7. ให้ Claude รันและตรวจสอบผลลัพธ์ด้วยตัวเอง

Claude บอกว่า "ทำเสร็จแล้ว!" แต่พอรันจริงกลับพัง ปุ่มกดไม่ได้ หน้าจอเละ หรือไม่มีอะไรโผล่มาเลย

เทสรันผ่านแต่แอปพัง เกิดขึ้นบ่อยกว่าที่คุณคิด

ดังนั้นให้ Claude เปิดแอปและโต้ตอบกับแอปด้วยตัวเองเลย มีคำสั่งสำหรับเรื่องนี้โดยเฉพาะ:

/run: รันแอปของโปรเจกต์จริงๆ และเข้าไปกดใช้งานเพื่อตรวจสอบการเปลี่ยนแปลง
/verify: บิลด์และรันแอปเพื่อยืนยันว่าฟีเจอร์ที่แก้ไปทำงานได้จริง ไม่ใช้แค่การรันเทสหรือเช็ค type มาหลอก
/run-skill-generator: บันทึกวิธีรันโปรเจกต์นี้ (คำสั่ง, env vars, ขั้นตอนเตรียมการ) เก็บเป็น skill ควรทำสิ่งนี้เป็นอย่างแรกสำหรับโปรเจกต์ที่ซับซ้อน
/verify จะบันทึกวิธีที่ตรวจสอบแล้วเก็บเป็น project skill (.claude/skills/verify/) เพื่อนำกลับมาใช้ซ้ำ

ลำดับการใช้งาน:

1. เขียนฟีเจอร์เสร็จ เช็คเทส/บิลด์ก่อน

2. รันแอปด้วย /run

3. คลิก/กรอกข้อมูลสำหรับเว็บ หรือใส่ input/output ตัวอย่างสำหรับ CLI

4. ยืนยันอีกครั้งว่าบรรลุเป้าหมายด้วย /verify

5. ถ้าไม่ผ่านให้แก้แล้วรันใหม่ เก็บผลลัพธ์คำสั่งจริง/ภาพหน้าจอไว้เป็นหลักฐาน

8. แยก AI สายโค้ด กับ AI สายรีวิว ออกจากกัน

คุณมักมองไม่เห็นคำผิดในงานเขียนของตัวเอง AI ก็เช่นกัน

session ที่นั่งโค้ดมาจะมีความลำเอียงเข้าข้างตัวเองว่า "แบบนี้ถูกแล้ว"

⭐️ ดังนั้นให้ใช้ reviewer ที่มี context สะอาดๆ ใหม่เอี่ยมแทน ⭐️

/code-review: หาบั๊ก/ปัญหาความแม่นยำในโค้ดที่แก้ไข, PRs, branches, paths
ตั้งระดับความเข้มข้นได้ เช่น /code-review high (มีตั้งแต่ low ถึง max)

(ค่าเริ่มต้นจะแค่รายงาน; เติม --fix เพื่อให้มันแก้ให้อัตโนมัติ)

/security-review: ตรวจปัญหาด้านความปลอดภัย (auth, input validation, info exposure) ใน diff ระหว่าง branch กับ remote default
/simplify: จัดการโค้ดซ้ำซ้อน/ไม่มีประสิทธิภาพ/ซับซ้อนเกินไป ไม่ได้มีไว้หาบั๊ก (ให้ /code-review ทำหน้าที่นั้น)

ลำดับที่แนะนำ:

1. จัดโค้ดให้สะอาดด้วย /simplify

2. ตรวจสอบการทำงานด้วย /verify (เคล็ดลับ #7)

3. หาบั๊กด้วย /code-review

4. เพิ่ม /security-review ถ้ามีการแตะต้อง login/payment/API keys/PII

ไม่ต้องรันทั้ง 4 ตัวทุกครั้งก็ได้

⚠️ การแก้เล็กๆ น้อยๆ อาจใช้แค่ /code-review ก็เพียงพอแล้ว ⚠️

ถ้าอยากรีวิวแบบเจาะลึก ให้ใช้ /code-review ultra (เหมือนกับการใช้ /ultrareview)

(เป็นการรีวิวเชิงลึกบนคลาวด์; สาย Pro/Max ได้ลองฟรี 3 ครั้ง)

9. กำหนดขอบเขตและเงื่อนไขความสำเร็จก่อนเริ่มโค้ดงานยากๆ

สำหรับงานที่ซับซ้อน ให้ขอบเขตและเงื่อนไขความสำเร็จกับ Claude ก่อน แทนที่จะยัดคำสั่งเขียนโค้ดยาวเหยียด

ถ้าไม่ทำแบบนี้ Claude จะขยายขอบเขตงานตามใจชอบ

⚠️ มันจะไปแก้ไฟล์ที่ไม่จำเป็น และทำในสิ่งที่คุณไม่ได้ขอ ⚠️

การใช้ Plan Mode:

กด Shift+Tab เพื่อเปิด plan mode หรือพิมพ์ /plan สามารถแนบงานไปได้เลย เช่น /plan fix login bug

(Plan Mode จะแค่อ่านไฟล์และวางแผน ไม่แก้โค้ดจนกว่าคุณจะอนุมัติ)

ขั้นตอน: สำรวจ → วางแผน → อนุมัติ → ลงมือทำ → ตรวจสอบ

ข้ามการวางแผนไปได้เลยถ้าแค่แก้คำผิดหรือเปลี่ยนโค้ดบรรทัดเดียว กฎจากเอกสารทางการคือ: ถ้าอธิบายการเปลี่ยนแปลงได้ในประโยคเดียว ให้ข้าม plan ไปเลย

10. บังคับใช้กฎสำคัญแบบอัตโนมัติด้วย Hooks

แม้ CLAUDE.md จะบอกว่า "ห้ามแตะไฟล์นี้" แต่บางครั้ง Claude ก็แอบทำ

🔥 CLAUDE.md เป็นแค่คำแนะนำ; แต่ Hooks คือการบังคับใช้ 🔥

3 ตัวที่ใช้บ่อยที่สุด:

PreToolUse: ทำงานก่อนแก้ไขไฟล์/รันคำสั่ง ใช้บล็อกการแก้ไขไฟล์หวงห้ามหรือคำสั่งอันตราย
PostToolUse: ทำงานทันทีหลังรันคำสั่งเสร็จ ใช้จัดรูปแบบ/lint ไฟล์ที่แก้ไขอัตโนมัติ
Stop: ทำงานเมื่อ Claude พยายามจะจบงาน ป้องกันไม่ให้หยุดถ้ายังทำเทสไม่ครบ

ตัวอย่าง: บล็อกการแก้ไข config ของ prod

สั่งให้ Claude สร้าง hooks ให้เลย:

--> "สร้าง PreToolUse hook ที่บล็อกการแก้ไข config/production.env"

กรณีที่เหมาะจะใช้งาน:

รัน formatter อัตโนมัติเมื่อมีการแก้ไขไฟล์โค้ด (PostToolUse)
บังคับให้ยืนยันก่อนแตะโฟลเดอร์สำคัญ (PreToolUse)
บล็อกไม่ให้หยุดงานถ้ายังไม่ได้รันเทส (Stop)
บล็อกคำสั่งอันตราย (PreToolUse + Bash)

11. รันหลาย Claude Sessions พร้อมกันด้วย Git Worktree

จะเกิดอะไรขึ้นถ้าเปิดหน้าต่าง Claude สองอันทำงานในโฟลเดอร์เดียวกัน?

🚫 พวกมันจะตีกันตอนแก้ไขไฟล์เดียวกัน (ปวดหัวมาก..) 🚫

Worktree จะแยก repo ออกเป็นโฟลเดอร์/branch อิสระตามแต่ละงาน

Claude Code ทำสิ่งนี้ได้ด้วยคำสั่งเดียว:

เปิดเทอร์มินัลสองอันแล้วรัน:

claude --worktree feature-auth
claude --worktree feature-dashboard

ใช้ตัวย่อ -w ก็ได้

มันจะสร้าง .claude/worktrees/feature-auth/ และทำงานบน branch worktree-feature-auth

--> ⭐️ สอง sessions จะไม่ไปยุ่งกับไฟล์ของกันและกัน ⭐️

ข้อควรรู้:

worktree ใหม่จะเริ่มจาก remote default (main) ไม่ใช่ branch ปัจจุบัน

ใส่เลข PR ไปด้วยเช่น claude --worktree "#1234" เพื่อเริ่มงานจาก PR นั้น

มันจะถามว่าจะเก็บหรือลบ work ที่ค้างไว้เมื่อคุณจบ session

ข้อควรระวัง:

Worktree แยกแค่ไฟล์/branch เท่านั้น ถ้าใช้ DB โลคอล/พอร์ต/เป้าหมาย deploy/บัญชี API ร่วมกัน ก็จะชนกันอยู่ดี
อาจเกิด merge conflict ได้ถ้ามีการแก้ไขไฟล์เดียวกัน
ควรกำหนด interface หรือเรียงลำดับงานที่ผูกพันกันแน่นหนาให้ดี
แต่ละ session กินยอดการใช้งานแยกกัน การทำขนาน ≠ ประหยัดโทเค็น

12. ตรวจสอบซ้ำจนกว่าจะบรรลุเป้าหมายด้วย /goal

Claude มักจะหยุดหลังทำจบรอบเดียว มันอาจบอกว่า "แก้เกือบหมดแล้ว" ทั้งที่เทสยังตกอยู่ 3 เคส

Goal จะบังคับให้ Claude ทำงานต่อไปเรื่อยๆ จนกว่าจะเข้าเงื่อนไขความสำเร็จ (ใช้ได้ตั้งแต่ v2.1.139)
/goal ใช้ดูเป้าหมาย/สถานะปัจจุบัน
/goal clear ใช้ยกเลิกเป้าหมาย/สั่งหยุด

หลักการทำงาน...

หลังจบแต่ละรอบ โมเดลขนาดเล็กที่ทำงานเร็วจะประเมินว่าเข้าเงื่อนไขหรือยัง ถ้ายังไม่เข้า Claude จะทำรอบถัดไปต่อ

ใส่เงื่อนไขการตรวจสอบลงไปใน goal ด้วย (เช่น "แสดงคำสั่งเทสและผลลัพธ์") เพราะโมเดลผู้ตัดสินต้องการหลักฐาน