ฉันได้ทดสอบการตั้งค่า Claude Code มากมายหลายสิบแบบ
สิ่งเดียวที่เปลี่ยนผลลัพธ์ของฉันจริงๆ คือไฟล์ขนาด 60 บรรทัดที่ชื่อว่า CLAUDE.md
บันทึกหน้านี้ไว้เลย 🔖
นี่คือวิธีการทำงานที่แท้จริง ทำไมคนส่วนใหญ่ถึงมองข้ามมันไปโดยสิ้นเชิง และเทมเพลตฉบับเต็มที่คุณสามารถคัดลอกไปใช้ได้วันนี้
สิ่งที่ไม่มีใครบอกคุณเกี่ยวกับ Claude Code
ก่อนที่คุณจะพิมพ์คำขอแรก ก่อนที่จะเขียนโค้ดแม้แต่บรรทัดเดียว ก่อนที่อะไรจะเกิดขึ้นในเซสชันของคุณ
Claude อ่านไฟล์เดียว แค่ไฟล์เดียว
CLAUDE.md.
และมันถือว่าไฟล์นี้คือความจริงสูงสุดสำหรับทั้งเซสชัน ไม่ใช่แค่คำแนะนำ ไม่ใช่บริบทหนึ่งในหลายๆ อย่าง แต่เป็นคำสั่งที่ชัดเจนที่กำหนดทุกการตัดสินใจที่มันจะทำ
นั่นคือเหตุผลที่ไฟล์นี้เป็นตัวแปรที่ถูกมองข้ามมากที่สุดในชุดเครื่องมือ Claude Code ทั้งหมด
คนส่วนใหญ่ไม่มีไฟล์นี้เลย และคนที่มีก็ทำผิดพลาดหนึ่งในสองอย่าง: ไฟล์นั้นไม่มีเนื้อหาที่เป็นประโยชน์ หรือไม่ก็เป็นไฟล์ 300 บรรทัดที่บอกว่า "จงเป็นวิศวกรอาวุโสที่มีประสบการณ์ซึ่งคิดทีละขั้นตอน"
ทั้งสองแบบไร้ประโยชน์ ด้วยเหตุผลที่แตกต่างกัน
ทำไมไฟล์ CLAUDE.md ส่วนใหญ่ถึงใช้ไม่ได้: 3 เหตุผลที่แท้จริง
เหตุผลที่ 1: ยาวเกินไป
Claude สามารถปฏิบัติตามคำสั่งได้ประมาณ 150 ถึง 200 คำสั่งต่อเซสชันอย่างน่าเชื่อถือ นี่คือข้อจำกัดเชิงโครงสร้าง ไม่ใช่เรื่องของความเต็มใจ
ปัญหา: พรอมต์ระบบภายในของ Claude Code มีคำสั่งอยู่ประมาณ 50 คำสั่งแล้ว นั่นหมายความว่า CLAUDE.md ของคุณมีช่องว่างสำหรับคำสั่ง 100 ถึง 150 คำสั่งก่อนที่ Claude จะเริ่มละเว้นคำสั่งเหล่านั้น
ถ้าไฟล์ของคุณยาว 200 บรรทัด Claude ไม่ได้จงใจละเว้นกฎของคุณ มันลืมกฎเหล่านั้นโดยอัตโนมัติ คุณไม่มีปัญหาด้านการปฏิบัติตามกฎ แต่คุณมีปัญหาด้านงบประมาณความสนใจ
เหตุผลที่ 2: เนื้อหาไม่ดี
ไฟล์ CLAUDE.md ส่วนใหญ่เต็มไปด้วยสิ่งที่ Claude สามารถสรุปได้เองหรือสิ่งที่ไม่เปลี่ยนพฤติกรรมของมันในทางที่วัดผลได้
"ทำตัวเป็นวิศวกรอาวุโส" → Claude รู้อยู่แล้วว่ามันหมายถึงอะไร และมันไม่ได้ยึดติดกับพฤติกรรมเฉพาะใดๆ
"คิดทีละขั้นตอน" → สิ่งนั้นอยู่ในข้อมูลฝึกของมันแล้ว คุณกำลังเสียบรรทัดหนึ่งไปเปล่าๆ
"เขียนโค้ดที่สะอาดและบำรุงรักษาได้" → ไม่มีเกณฑ์ที่เป็นรูปธรรม Claude ไม่รู้ว่า "สะอาด" หมายถึงอะไรในบริบทเฉพาะของคุณ
ทุกบรรทัดที่ไม่ได้ป้องกันข้อผิดพลาดเฉพาะเจาะจงและเป็นรูปธรรม คือบรรทัดที่ถูกขโมยมาจากคำสั่งที่สำคัญจริงๆ การทดสอบนั้นง่าย: ถ้าคุณลบบรรทัดนี้ Claude จะทำอะไรผิดพลาดเฉพาะเจาะจงหรือไม่? ถ้าคำตอบคือไม่ บรรทัดนั้นก็ไม่ควรอยู่ที่นั่น
เหตุผลที่ 3: ไม่มีลำดับชั้น
คนส่วนใหญ่มองข้างความจริงที่ว่ามีสามระดับของคำสั่งใน Claude Code และพวกเขายัดทุกอย่างไว้ในที่เดียวกัน
~/.claude/CLAUDE.md → ส่วนกลาง (ใช้กับทุกโปรเจกต์ของคุณ)
.claude/CLAUDE.md → โปรเจกต์ (แชร์กับทีม, อยู่ใน git)
./CLAUDE.local.md → ส่วนตัว (การตั้งค่าส่วนบุคคล, อยู่ใน gitignore)
ระดับส่วนกลางมีไว้สำหรับกฎที่คุณจะทำซ้ำในทุกโปรเจกต์ ระดับโปรเจกต์มีไว้สำหรับบริบทเฉพาะของสแตกและทีมของคุณ ระดับส่วนตัวมีไว้สำหรับความชอบส่วนบุคคลของคุณที่ไม่จำเป็นต้องแชร์
การใช้สามระดับอย่างถูกต้องคือสิ่งที่ทำให้แต่ละไฟล์สั้น ตรงประเด็น และมีประสิทธิภาพอย่างแท้จริง การใส่ทุกอย่างในไฟล์เดียวก็เหมือนกับการสร้างกรวยเพื่อกลบกฎสำคัญของคุณด้วยเสียงรบกวน
5 ส่วนที่ประกอบกันเป็น CLAUDE.md ที่มีประสิทธิภาพ
หลังจากค้นหาไฟล์ CLAUDE.md หลายสิบไฟล์ในโปรดักชัน—โปรเจกต์โอเพนซอร์ส เอกสารอย่างเป็นทางการของ Anthropic คลังแนวทางปฏิบัติที่ดีที่สุดของชุมชน—นี่คือ 5 ส่วนที่ไฟล์ที่มีประสิทธิภาพทั้งหมดมีเหมือนกัน
ส่วนที่ 1: คำสั่งที่สำคัญ
Claude เริ่มทุกเซสชันโดยไม่รู้วิธีสร้างโปรเจกต์ของคุณ รันเทส หรือแก้ไขข้อผิดพลาด lint มันจะเดา และการเดาของมันจะทำให้คุณเสียรอบ
บอกมันให้แน่ชัดว่าต้องพิมพ์อะไร:
Commands
- สร้าง:
npm run build - พัฒนา:
npm run dev - ทดสอบไฟล์เดียว:
npm test -- path/to/file - ทดสอบทั้งหมด:
npm test - ตรวจสอบโค้ด + แก้ไข:
npm run lint:fix - ตรวจสอบชนิดข้อมูล:
npx tsc --noEmit
สั้น กระชับ ใช้ได้ทันที
หากไม่มีส่วนนี้ Claude จะพยายามใช้ npm test เมื่อโปรเจกต์ของคุณทำงานบน pnpm vitest มันจะใช้เวลาสามรอบในการดีบักปัญหาคำสั่งที่ไม่มีทางทำงานได้ สามรอบที่คุณจะใช้กับงานจริงได้
ส่วนที่ 2: แผนผังสถาปัตยกรรม
Claude เริ่มทุกเซสชันโดยไม่มีความรู้เกี่ยวกับโค้ดเบสของคุณเลย ไม่รู้เลย มันไม่รู้ว่าตรรกะทางธุรกิจของคุณอยู่ที่ไหน ไม่รู้ว่าคอมโพเนนต์ของคุณควรไม่มีสถานะหรือไม่ ไม่รู้ว่าเส้นทาง API ของคุณไม่ควรมีตรรกะทางธุรกิจ
ให้แผนผังแก่มัน:
Architecture
- src/lib/services/ → ตรรกะทางธุรกิจทั้งหมด
- src/components/ → คอมโพเนนต์ UI แบบไม่มีสถานะเท่านั้น
- src/lib/store/ → สถานะส่วนกลาง (Zustand)
- src/app/api/ → เส้นทาง API, ไม่มีตรรกะทางธุรกิจที่นี่
- เข้าถึง DB ผ่าน Server Actions หรือ API routes เท่านั้น
ไม่ใช่รายการโครงสร้างต้นไม้ทั้งหมด แค่พอให้ Claude รู้ว่าสิ่งต่างๆ อยู่ที่ไหน และที่สำคัญกว่าคือ ไม่ควรไปที่ไหน
ความแตกต่างนี้... ว่ามันไปที่ไหน vs. ไม่ควรไปที่ไหน... คือสิ่งที่ป้องกันข้อผิดพลาดทางสถาปัตยกรรมที่พบบ่อยที่สุด
ส่วนที่ 3: กฎที่เข้มงวด
นี่คือส่วนที่สำคัญที่สุดของไฟล์ทั้งหมด โดยไม่มีข้อยกเว้น
ทุกกฎที่นี่ต้องตอบคำถามเดียว: "ถ้าฉันลบบรรทัดนี้ Claude จะทำผิดพลาดที่เป็นรูปธรรมหรือไม่?"
ถ้าใช่ → กฎนั้นอยู่ต่อ ถ้าไม่ใช่ → มันไม่มีเหตุผลที่จะอยู่ที่นั่น
ตัวอย่างของกฎที่มีคุณค่าสูง:
Rules
- ห้าม commit ไฟล์ .env หรือความลับเด็ดขาด
- การเรียก async ทั้งหมดต้องอยู่ใน try/catch
- ใช้ Functional components เท่านั้น, ห้ามใช้ class components
- คำนำหน้า commit ที่จำเป็น: feat:, fix:, docs:, refactor:
- ทุก PR ต้องผ่าน
npm run verifyก่อน merge - ส่งออกแบบ static เท่านั้น, ไม่มี SSR (ปรับใช้บน S3)
- IMPORTANT: ตรวจสอบชนิดข้อมูลหลังจากแก้ไขโค้ดทุกครั้ง
สองสิ่งที่ควรสังเกตเกี่ยวกับรายการนี้
ประการแรก กฎเชิงลบมีความสำคัญเท่ากับกฎเชิงบวก "ห้าม commit ไฟล์ .env" เป็นกฎที่ดูเหมือนชัดเจนจนถึงวันที่ Claude ทำมัน ใส่ไว้ในนั้น
ประการที่สอง เครื่องหมายเน้นย้ำ เช่น IMPORTANT หรือ YOU MUST ใช้งานได้จริง
นี่ไม่ใช่เรื่องเล่าลือ Anthropic ยืนยันในเอกสารของพวกเขา: การเพิ่ม IMPORTANT หรือ YOU MUST ก่อนกฎจะช่วยปรับปรุงการปฏิบัติตามกฎของ Claude ได้อย่างวัดผลได้
ใช้เท่าที่จำเป็น: สงวนไว้สำหรับกฎที่มีผลกระทบร้ายแรงที่สุดหากถูกละเลย
ให้มีกฎไม่เกิน 15 ข้อในส่วนนี้ หากเกินกว่านั้น คุณจะทำให้ความสนใจกระจายไปจากกฎที่สำคัญ
ส่วนที่ 4: ค่ากำหนดขั้นตอนการทำงาน
คุณเคยเจอแบบนี้แล้ว คุณขอให้ Claude แก้ไขหนึ่งบรรทัด มันเขียนไฟล์สามไฟล์ใหม่ เปลี่ยนชื่อฟังก์ชันของคุณ และรีแฟกเตอร์คลาสที่ไม่เกี่ยวข้องกับคำขอของคุณเลย
ส่วนนี้ป้องกันสิ่งนั้น:
Workflow
- ถามคำถามเพื่อความชัดเจนก่อนเริ่มงานที่ซับซ้อน
- เปลี่ยนแปลงให้น้อยที่สุด อย่ารีแฟกเตอร์โค้ดที่ไม่เกี่ยวข้อง
- รันเทสหลังจากทุกการเปลี่ยนแปลง แก้ไขข้อผิดพลาดก่อนดำเนินการต่อ
- สร้าง commit แยกตามการเปลี่ยนแปลงเชิงตรรกะ ไม่ใช่ commit ใหญ่ก้อนเดียว
- ในกรณีที่ไม่แน่ใจระหว่างสองแนวทาง ให้อธิบายทั้งสองแล้วให้ฉันเลือก
ทุกบรรทัดที่นี่ตอบปัญหาเจ็บปวดที่เป็นรูปธรรม commit ใหญ่ 47 ไฟล์ การเขียนใหม่ทั้งหมดโดยไม่ได้รับการร้องขอ การตัดสินใจทางสถาปัตยกรรมที่ Claude ตัดสินใจเพียงลำพังทั้งที่ควรถามคุณ
ส่วนที่ 5: สิ่งที่ไม่ควรใส่ใน CLAUDE.md ของคุณ
ส่วนนี้สำคัญเท่ากับส่วนอื่นๆ อาจจะมากกว่าด้วยซ้ำ
Do NOT include:
- คำแนะนำเกี่ยวกับบุคลิกภาพ ("เป็นวิศวกรอาวุโส")
- กฎการจัดรูปแบบที่ linter ของคุณจัดการอยู่แล้ว
- @ imports ที่ดึงเอกสารทั้งหมดเข้าสู่ทุกเซสชัน
- กฎที่ซ้ำกัน (ถ้าส่วนกลางบอกว่า "รันเทส" โปรเจกต์ไม่ต้องทำซ้ำ)
- สิ่งที่ Claude เรียนรู้ด้วยตนเองผ่านความจำอัตโนมัติ
ประเด็นสุดท้ายนี้ถูกมองข้ามอย่างกว้างขวาง
Claude เก็บโน้ตของมันเองใน ~/.claude/projects/<project>/memory/ รัน /memory ในเซสชันของคุณเพื่อดูว่ามันได้เรียนรู้อะไรเกี่ยวกับโปรเจกต์ของคุณบ้าง หลังจากไม่กี่เซสชัน คุณมักจะพบว่า Claude ได้เก็บข้อมูลที่คุณกำลังจะเขียนด้วยมือใน CLAUDE.md ของคุณแล้ว
อย่าเสียคำสั่งอันจำกัดของคุณไปกับสิ่งที่ Claude จำได้ด้วยตนเอง
เทมเพลตฉบับสมบูรณ์ใน 60 บรรทัด พร้อมใช้งาน
ลบส่วนที่ไม่เกี่ยวข้องกับโปรเจกต์ของคุณ เป้าหมายไม่ใช่การใส่ให้ครบทุกอย่าง เป้าหมายคือเก็บเฉพาะสิ่งที่เปลี่ยนแปลงพฤติกรรมของ Claude ในทางที่วัดผลได้
บรรทัดที่มีผลกระทบมากที่สุดต่อผลลัพธ์ของฉัน: ผลลัพธ์ที่เป็นรูปธรรม
หลังจากทดสอบการตั้งค่าหลายสิบแบบ นี่คือห้าบรรทัดที่สร้างความแตกต่างที่เห็นได้ชัดที่สุด
IMPORTANT: ตรวจสอบชนิดข้อมูลหลังจากแก้ไขโค้ดทุกครั้ง → ป้องกันไม่ให้ Claude ส่งโค้ดที่มีชนิดข้อมูลเสียซึ่งมันตรวจไม่พบหากไม่ได้รับการแจ้งให้ตรวจสอบอย่างชัดเจน
เปลี่ยนแปลให้น้อยที่สุด อย่ารีแฟกเตอร์โค้ดที่ไม่เกี่ยวข้อง → ป้องกันการเขียนไฟล์ทั้งหมดใหม่โดยไม่ได้รับการร้องขอ
สร้าง commit แยกตามการเปลี่ยนแปลงเชิงตรรกะ ไม่ใช่ commit ใหญ่ก้อนเดียว → ป้องกัน commit ปีศาจ 47 ไฟล์ที่อ่านไม่ได้
ในกรณีที่ไม่แน่ใจระหว่างสองแนวทาง ให้อธิบายทั้งสองแล้วให้ฉันเลือก → ป้องกันไม่ให้ Claude ตัดสินใจทางสถาปัตยกรรมเพียงลำพังซึ่งควรเป็นของคุณ
ส่งออกแบบ static เท่านั้น, ไม่มี SSR → ป้องกันไม่ให้ Claude เพิ่มโค้ดฝั่งเซิร์ฟเวอร์ในโปรเจกต์ที่ปรับใช้แบบ static บน S3
สิ่งที่ห้าบรรทัดนี้มีเหมือนกัน: แต่ละบรรทัดป้องกันข้อผิดพลาดที่เฉพาะเจาะจง บ่อยครั้ง และมีค่าใช้จ่ายสูงในเวลาดีบัก
นี่คือการทดสอบสูงสุดสำหรับทุกบรรทัดใน CLAUDE.md ของคุณ
ข้อผิดพลาดพื้นฐานและเหตุผลที่มันแพร่หลาย
ผู้คนปฏิบัติต่อ CLAUDE.md ของตนเหมือนรายการความต้องการหรือพรอมต์บุคลิกภาพ
"เป็นผู้เชี่ยวชาญ" "ทำอย่างละเอียดถี่ถ้วน" "คิดเหมือนผู้เชี่ยวชาญ"
นี่ไม่ใช่คำสั่ง มันเป็นการคิดแบบเวทมนตร์
CLAUDE.md ของคุณควรเป็นเอกสารทางเทคนิค ไม่ใช่สุนทรพจน์สร้างแรงบันดาลใจ สแตก คำสั่ง สถาปัตยกรรม กฎที่เป็นรูปธรรม ขั้นตอนการทำงาน ทุกอย่างอื่นคือเสียงรบกวนที่แข่งขันกับคำสั่งที่สำคัญจริงๆ
เก็บไฟล์ให้ต่ำกว่า 80 บรรทัด แก้ไขทุกครั้งที่ Claude ทำผิดพลาดที่คุณสามารถป้องกันได้
และเหนือสิ่งอื่นใด: เข้าใจว่าไฟล์นี้กลายเป็นอะไรเมื่อเวลาผ่านไป
CLAUDE.md ที่ดีในเดือนแรกช่วยประหยัดเวลาในทุกเซสชัน ภายในเดือนที่สาม มันได้บันทึกธรรมเนียมและสแตกของคุณอย่างแม่นยำพอที่ Claude ทำงานได้เกือบเหมือนสมาชิกในทีม
ภายในเดือนที่หก มันมีข้อผิดพลาดทุกครั้งที่ Claude เคยทำในโปรเจกต์นี้และป้องกันทั้งหมดโดยอัตโนมัติ
ไฟล์นี้เพิ่มมูลค่า มันดีขึ้นด้วยทุกการแก้ไข มันค่อยๆ กลายเป็นเอกสารปฐมนิเทศที่ดีที่สุดที่คุณเคยเขียน
ไม่ใช่เพื่อ Claude แต่เพื่อคุณ
