กฎ CLAUDE.md 4 ข้อของ Karpathy ช่วยลดข้อผิดพลาดของ Claude จาก 41% เหลือ 11% และหลังจากทดสอบกับ codebase 30 แห่ง ผมได้เพิ่มเข้าไปอีก 8 ข้อ

ในปลายเดือนมกราคม 2026 Andrej Karpathy โพสต์กระทู้บ่นเกี่ยวกับวิธีที่ Claude เขียนโค้ด สามรูปแบบความล้มเหลว: การตั้งสมมติฐานผิดอย่างเงียบๆ, การทำให้ซับซ้อนเกินความจำเป็น, ความเสียหายข้างเคียงกับโค้ดที่ไม่ควรแตะต้อง

Forrest Chang อ่านกระทู้ดังกล่าว รวบรวมข้อร้องเรียนเป็นกฎพฤติกรรม 4 ข้อในไฟล์ CLAUDE.md ไฟล์เดียว และอัปโหลดบน GitHub มันได้รับ 5,828 ดาวในวันแรก 60,000 บุ๊กมาร์กในสองสัปดาห์ 120,000 ดาวในวันนี้ ที่เก็บไฟล์เดียวที่เติบโตเร็วที่สุดในปี 2026

จากนั้นฉันทดสอบบน 30 โค้ดเบสเป็นเวลา 6 สัปดาห์

กฎ 4 ข้อใช้ได้ผล ข้อผิดพลาดที่เคยเกิดขึ้นประมาณ 40% ของเวลาลดลงเหลือต่ำกว่า 3% สำหรับงานที่สอดคล้องกับจุดแข็งของมัน แต่เทมเพลตถูกสร้างขึ้นเพื่อแก้ไขข้อผิดพลาดในการเขียนโค้ดจากเดือนมกราคม

ระบบนิเวศของ Claude Code ในเดือนพฤษภาคม 2026 มีปัญหาที่แตกต่างกัน — การต่อสู้ของเอเจนต์, ฮุคแบบลูกโซ่, ความขัดแย้งในการโหลดสกิล, เวิร์กโฟลว์หลายขั้นตอนที่พังข้ามเซสชัน

ดังนั้นฉันจึงเพิ่มกฎอีก 8 ข้อ ด้านล่างนี้: กฎ CLAUDE.md ครบ 12 ข้อ, เหตุผลที่แต่ละข้อมีที่มา, และ 4 จุดที่เทมเพลต Karpathy ดั้งเดิมพังอย่างเงียบๆ

หากคุณต้องการข้ามคำอธิบายและวางโค้ดเลย ไฟล์เต็มอยู่ท้ายบทความ

เหตุใดสิ่งนี้จึงสำคัญ

CLAUDE.md ของ Claude Code คือไฟล์ที่ถูกใช้งานน้อยที่สุดในสแต็กการเขียนโค้ด AI ทั้งหมด นักพัฒนาส่วนใหญ่มักจะ:

• ปฏิบัติต่อมันเหมือนที่ทิ้งทุกความชอบที่เคยมี ทำให้บวมถึง 4,000+ โทเคน การปฏิบัติตามกฎลดลงเหลือ 30%
• ข้ามมันไปเลยและใช้พรอมต์ทุกครั้ง — สิ้นเปลืองโทเคน 5 เท่า ไม่มีความสม่ำเสมอระหว่างเซสชัน
• คัดลอกเทมเพลตครั้งเดียวแล้วลืม ใช้ได้สองสัปดาห์ จากนั้นพังอย่างเงียบๆ เมื่อโค้ดเบสของพวกเขาเปลี่ยนไป

เอกสารทางการของ Anthropic ระบุชัดเจน: CLAUDE.md เป็นเพียงคำแนะนำ Claude ปฏิบัติตามประมาณ 80% ของเวลา เกิน 200 บรรทัด การปฏิบัติตามลดลงอย่างรวดเร็วเพราะกฎสำคัญถูกฝังอยู่ในสัญญาณรบกวน

เทมเพลตของ Karpathy แก้ปัญหานี้ในไฟล์เดียว 65 บรรทัด 4 กฎ นั่นคือพื้น

เพดานสูงกว่านั้น ด้วยกฎอีก 8 ข้อ ที่ฉันจะอธิบายด้านล่าง คุณครอบคลุมไม่เพียงแต่ปัญหาการเขียนโค้ดในเดือนมกราคม 2026 ที่ Karpathy บ่น แต่ยังรวมถึงปัญหาการจัดระเบียบเอเจนต์ในเดือนพฤษภาคม 2026 ที่ยังไม่มีอยู่ตอนที่เขียนเทมเพลต

กฎดั้งเดิม 4 ข้อ

หากคุณยังไม่ได้อ่านที่เก็บของ Forrest Chang พื้น:

กฎข้อ 1 — คิดก่อนเขียนโค้ด

**ไม่มีการตั้งสมมติฐานอย่างเงียบๆ ระบุสิ่งที่คุณกำลังสมมติ แสดงข้อแลกเปลี่ยน ถามก่อนเดา ทักท้วงเมื่อมีแนวทางที่ง่ายกว่า

กฎข้อ 2 — ความเรียบง่ายต้องมาก่อน

**โค้ดขั้นต่ำที่แก้ปัญหาได้ ไม่มีฟีเจอร์ที่คาดเดา ไม่มีนามธรรมสำหรับโค้ดที่ใช้ครั้งเดียว หากวิศวกรอาวุโสจะบอกว่ามันซับซ้อนเกินไป — ทำให้ง่ายขึ้น

กฎข้อ 3 — การเปลี่ยนแปลงแบบผ่าตัด

**แตะเฉพาะสิ่งที่ต้องแตะ อย่า "ปรับปรุง" โค้ดข้างเคียง คอมเมนต์ หรือการจัดรูปแบบ อย่ารีแฟกเตอร์สิ่งที่ยังไม่เสีย จับคู่สไตล์ที่มีอยู่

กฎข้อ 4 — การดำเนินการตามเป้าหมาย

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

กฎสี่ข้อนี้ปิด ~40% ของรูปแบบความล้มเหลวที่ฉันเห็นในเซสชัน Claude Code ที่ไม่มีผู้ดูแล ส่วนที่เหลือ ~60% อยู่ในช่องว่างด้านล่าง

กฎ 8 ข้อที่ฉันเพิ่ม (และเหตุผล)

แต่ละข้อมาจากช่วงเวลาจริงที่กฎ 4 ข้อของ Karpathy ไม่เพียงพอ ฉันจะแสดงช่วงเวลา จากนั้นจึงแสดงกฎ

กฎข้อ 5 — อย่าให้โมเดลทำงานที่ไม่ใช่ภาษา

กฎของ Karpathy เงียบในเรื่องนี้ โมเดลตัดสินใจในสิ่งที่ควรเป็นโค้ดที่กำหนดได้ เช่น จะลองเรียก API อีกครั้งหรือไม่ จะกำหนดเส้นทางข้อความอย่างไร จะยกระดับเมื่อใด การตัดสินใจต่างกันทุกสัปดาห์ if-else ที่ไม่เสถียรในราคา $0.003 ต่อโทเคน

1## กฎข้อ 5 — ใช้โมเดลเฉพาะสำหรับการตัดสินใจที่ต้องใช้ดุลยพินิจ
2ใช้ Claude สำหรับ: การจำแนกประเภท, การร่าง, การสรุป, การแยกข้อมูลจากข้อความที่ไม่มีโครงสร้าง
3ห้ามใช้ Claude สำหรับ: การกำหนดเส้นทาง, การลองใหม่, การจัดการรหัสสถานะ, การแปลงที่กำหนดได้
4หากรหัสสถานะตอบคำถามได้อยู่แล้ว โค้ดธรรมดาก็ตอบคำถามได้

ช่วงเวลา: โค้ดที่เรียก Claude เพื่อ "ตัดสินใจว่าควรลองใหม่เมื่อเจอ 503" ทำงานได้ดีเป็นเวลาสองสัปดาห์ จากนั้นเริ่มมีปัญหาที่ไม่แน่นอนเพราะโมเดลเริ่มอ่านเนื้อหาคำขอเป็นบริบทสำหรับการตัดสินใจ นโยบายการลองใหม่กลายเป็นแบบสุ่มเพราะพรอมต์สุ่ม

กฎข้อ 6 — งบประมาณโทเคนที่เข้มงวด ไม่มีข้อยกเว้น

CLAUDE.md ที่ไม่มีงบประมาณคือเช็คเปล่า ทุกการวนซ้ำมีโอกาสที่จะกลายเป็นดัมพ์บริบท 50,000 โทเคน โมเดลจะไม่หยุดเอง

1## กฎข้อ 6 — งบประมาณโทเคนไม่ใช่คำแนะนำ
2งบประมาณต่องาน: 4,000 โทเคน
3งบประมาณต่อเซสชัน: 30,000 โทเคน
4หากงานใกล้ถึงงบประมาณ ให้สรุปและเริ่มใหม่ อย่าฝืนทำต่อ
5การแจ้งว่าเกินงบ > การเกินอย่างเงียบๆ

ช่วงเวลา: เซสชันการดีบักใช้เวลา 90 นาที โมเดลยินดีที่จะวนซ้ำกับข้อความแสดงข้อผิดพลาด 8KB เดิม ค่อยๆ สูญเสียการติดตามว่าการแก้ไขใดที่ลองไปแล้ว ในตอนท้าย มันเสนอการแก้ไขที่ฉันปฏิเสธไปแล้ว 40 ข้อความก่อนหน้านี้ งบประมาณโทเคนจะหยุดมันได้ในนาทีที่ 12

กฎข้อ 7 — แสดงความขัดแย้ง อย่าหาค่าเฉลี่ย

เมื่อสองส่วนของโค้ดเบสไม่เห็นด้วย Claude พยายามทำให้ทั้งคู่พอใจ ผลลัพธ์คือไม่สอดคล้องกัน

1## กฎข้อ 7 — แสดงความขัดแย้ง อย่าหาค่าเฉลี่ย
2หากสองรูปแบบที่มีอยู่ในโค้ดเบสขัดแย้งกัน อย่าผสมผสาน
3เลือกหนึ่งรูปแบบ (ที่ใหม่กว่า / ที่ผ่านการทดสอบมากกว่า) อธิบายเหตุผล และทำเครื่องหมายอีกรูปแบบเพื่อทำความสะอาด
4โค้ด "ค่าเฉลี่ย" ที่พึงพอใจทั้งสองกฎคือโค้ดที่แย่ที่สุด

ช่วงเวลา: โค้ดเบสมีรูปแบบการจัดการข้อผิดพลาดสองแบบ — แบบ async/await พร้อม try/catch ที่ชัดเจน และแบบ global error boundary Claude เขียนโค้ดใหม่ที่ทำ ทั้งสองอย่าง ตัวจัดการข้อผิดพลาดซ้ำซ้อน ฉันใช้เวลา 30 นาทีเพื่อหาว่าทำไมข้อผิดพลาดถึงถูกกลืนสองครั้ง

กฎข้อ 8 — อ่านก่อนเขียน

กฎ "การเปลี่ยนแปลงแบบผ่าตัด" ของ Karpathy บอก Claude อย่าแตะต้องโค้ดข้างเคียง มันไม่ได้บอกให้ Claude เข้าใจ โค้ดข้างเคียงก่อน หากไม่มีสิ่งนี้ Claude จะเขียนโค้ดใหม่ที่ขัดแย้งกับโค้ดที่มีอยู่ห่างออกไป 30 บรรทัด

1## กฎข้อ 8 — อ่านก่อนเขียน
2ก่อนเพิ่มโค้ดในไฟล์ ให้อ่าน exports ของไฟล์ ผู้เรียกโดยตรง และยูทิลิตี้ที่ใช้ร่วมกันที่ชัดเจน
3หากคุณไม่เข้าใจว่าเหตุใดโค้ดที่มีอยู่จึงมีโครงสร้างแบบนั้น ให้ถามก่อนเพิ่มเติม
4"ดูเหมือนไม่เกี่ยวข้องกัน" เป็นวลีที่อันตรายที่สุดในโค้ดเบสนี้

ช่วงเวลา: Claude เพิ่มฟังก์ชันถัดจากฟังก์ชันที่เหมือนกันที่มีอยู่ซึ่งมันไม่ได้อ่าน ฟังก์ชันทั้งสองทำสิ่งเดียวกัน ฟังก์ชันใหม่มีความสำคัญกว่าตามลำดับการ import ฟังก์ชันเก่าเป็นแหล่งความจริงมา 6 เดือน

กฎข้อ 9 — การทดสอบไม่ใช่ทางเลือก แต่ไม่ใช่เป้าหมาย

กฎ "การดำเนินการตามเป้าหมาย" ของ Karpathy บอกเป็นนัยว่าการทดสอบเป็นเกณฑ์ความสำเร็จ ในทางปฏิบัติ Claude ถือว่า "การทดสอบผ่าน" เป็นเป้าหมาย เดียว และเขียนโค้ดที่ผ่านการทดสอบแบบตื้นๆ แต่ทำลายทุกอย่างอื่น

1## กฎข้อ 9 — การทดสอบยืนยันเจตนา ไม่ใช่แค่พฤติกรรม
2ทุกการทดสอบต้องเข้ารหัสว่าเหตุใดพฤติกรรมจึงสำคัญ ไม่ใช่แค่สิ่งที่ทำ
3การทดสอบเช่น `expect(getUserName()).toBe('John')` ไร้ค่าหากฟังก์ชันใช้ ID แบบฮาร์ดโค้ด
4หากคุณไม่สามารถเขียนการทดสอบที่จะล้มเหลวเมื่อตรรกะทางธุรกิจเปลี่ยนไป ฟังก์ชันนั้นผิด

ช่วงเวลา: Claude เขียน 12 การทดสอบสำหรับฟังก์ชัน auth ทั้งหมดผ่าน Auth ใช้งานไม่ได้ในโปรดักชัน การทดสอบกำลังทดสอบว่าฟังก์ชันคืนค่า บางอย่าง ไม่ใช่คืนค่าที่ถูกต้อง ฟังก์ชันผ่านเพราะมันคืนค่าคงที่

กฎข้อ 10 — การดำเนินการระยะยาวต้องมีจุดตรวจสอบ

เทมเพลตของ Karpathy สมมติการโต้ตอบแบบครั้งเดียว งาน Claude Code จริงเป็นหลายขั้นตอน — การรีแฟกเตอร์ข้าม 20 ไฟล์ การสร้างฟีเจอร์ตลอดเซสชัน การดีบักข้ามหลายคอมมิต หากไม่มีจุดตรวจสอบ การเลี้ยวผิดครั้งเดียวจะสูญเสียความคืบหน้าทั้งหมด

1## กฎข้อ 10 — จุดตรวจสอบหลังจากทุกขั้นตอนสำคัญ
2หลังจากเสร็จสิ้นแต่ละขั้นตอนในงานหลายขั้นตอน: สรุปสิ่งที่ทำ สิ่งที่ยืนยันแล้ว และสิ่งที่เหลือ
3อย่าดำเนินการต่อจากสถานะที่คุณไม่สามารถอธิบายกลับมาให้ฉันฟังได้
4หากคุณหลงทาง ให้หยุดและบอกสถานะใหม่

ช่วงเวลา: การรีแฟกเตอร์ 6 ขั้นตอนผิดพลาดในขั้นตอนที่ 4 เมื่อฉันสังเกตเห็น Claude ก็ทำขั้นตอนที่ 5 และ 6 ต่อจากสถานะที่พังแล้ว การแยกออกใช้เวลานานกว่าการทำใหม่ทั้งหมด จุดตรวจสอบจะจับได้ในขั้นตอนที่ 4

กฎข้อ 11 — ธรรมเนียมปฏิบัติสำคัญกว่าความแปลกใหม่

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

1## กฎข้อ 11 — จับคู่ธรรมเนียมปฏิบัติของโค้ดเบส แม้ว่าคุณจะไม่เห็นด้วย
2หากโค้ดเบสใช้ snake_case และคุณชอบ camelCase: ใช้ snake_case
3หากโค้ดเบสใช้ class-based components และคุณชอบ hooks: ใช้ class-based
4ความไม่เห็นด้วยเป็นอีกการสนทนาหนึ่ง ภายในโค้ดเบส การปฏิบัติตาม > รสนิยม
5หากคุณคิดว่าธรรมเนียมปฏิบัตินั้นเป็นอันตรายจริงๆ ให้แจ้งออกมา อย่าแยกออกไปอย่างเงียบๆ

ช่วงเวลา: Claude แนะนำ React hooks ในโค้ดเบสที่ใช้ class components พวกมันทำงานได้ แต่ก็ทำให้รูปแบบการทดสอบของโค้ดเบสเสีย ซึ่งสมมติว่าใช้ componentDidMount ใช้เวลาครึ่งวันในการลบและเขียนใหม่

กฎข้อ 12 — ล้มเหลวอย่างเห็นได้ชัด ไม่ใช่เงียบๆ

ความล้มเหลวของ Claude ที่แพงที่สุดคือสิ่งที่ดูเหมือนความสำเร็จ ฟังก์ชัน "ทำงาน" แต่คืนค่าผิด การย้ายข้อมูล "เสร็จสมบูรณ์" แต่ข้าม 30 เรกคอร์ด การทดสอบ "ผ่าน" แต่เพียงเพราะการยืนยันผิด

1## กฎข้อ 12 — ล้มเหลวให้ดัง
2หากคุณไม่แน่ใจว่าบางอย่างทำงานได้ ให้พูดอย่างชัดเจน
3"การย้ายข้อมูลเสร็จสมบูรณ์" ผิดหาก 30 เรกคอร์ดถูกข้ามอย่างเงียบๆ
4"การทดสอบผ่าน" ผิดหากคุณข้ามการทดสอบใดๆ
5"ฟีเจอร์ทำงาน" ผิดหากคุณไม่ได้ตรวจสอบกรณีขอบที่ฉันถามถึง
6ค่าเริ่มต้นคือการแสดงความไม่แน่นอน ไม่ใช่ซ่อนมัน

ช่วงเวลา: Claude บอกว่าการย้ายฐานข้อมูล "เสร็จสมบูรณ์" มันข้าม 14% ของเรกคอร์ดที่เจอการละเมิดข้อจำกัดอย่างเงียบๆ การข้ามถูกบันทึกแต่ไม่ถูกแสดง ค้นพบปัญหา 11 วันต่อมาเมื่อรายงานเริ่มดูผิด

ตัวเลข

ฉันติดตามชุดงาน 50 งานที่เป็นตัวแทนเดียวกันใน 30 โค้ดเบสเป็นเวลา 6 สัปดาห์ สามการกำหนดค่า:

อัตราข้อผิดพลาด = งานที่ต้องการการแก้ไขหรือเขียนใหม่เพื่อให้ตรงกับเจตนา นับ: การตั้งสมมติฐานผิดอย่างเงียบๆ, วิศวกรรมเกินความจำเป็น, ความเสียหายข้างเคียง, ความล้มเหลวอย่างเงียบๆ, การละเมิดธรรมเนียมปฏิบัติ, การหาค่าเฉลี่ยความขัดแย้ง, จุดตรวจสอบที่พลาด

การปฏิบัติตาม = ความถี่ที่ Claude ใช้กฎที่เกี่ยวข้องอย่างเห็นได้ชัดเมื่อมันเกี่ยวข้อง

ผลลัพธ์ที่น่าสนใจไม่ใช่การลดลงจาก 41% เป็น 3% แต่คือการเพิ่มจาก 4 กฎเป็น 12 กฎแทบไม่เพิ่มค่าใช้จ่ายในการปฏิบัติตาม (78% -> 76%) แต่ลดอัตราข้อผิดพลาดลงอีก 8 จุด กฎใหม่ครอบคลุมรูปแบบความล้มเหลวที่กฎเดิม 4 ข้อไม่ได้จัดการ — พวกมันไม่แข่งขันเพื่องบประมาณความสนใจเดียวกัน

จุดที่เทมเพลตของ Karpathy พังอย่างเงียบๆ

สี่จุดที่เทมเพลตกฎ 4 ข้อดั้งเดิมไม่เพียงพอ แม้ก่อนเพิ่มกฎใหม่:

1. งานเอเจนต์ระยะยาว

*กฎของ Karpathy กำหนดเป้าหมายช่วงเวลาที่ Claude กำลังเขียน โค้ด พวกมันเงียบเกี่ยวกับสิ่งที่เกิดขึ้นเมื่อ Claude กำลังรัน* ไพพ์ไลน์หลายขั้นตอน ไม่มีกฎงบประมาณ ไม่มีกฎจุดตรวจสอบ ไม่มีกฎ "ล้มเหลวให้ดัง" ไพพ์ไลน์ล่องลอย

2. ความสอดคล้องข้ามหลายโค้ดเบส

**"จับคู่สไตล์ที่มีอยู่" สมมติว่ามีสไตล์เดียว ใน monorepo ที่มี 12 บริการ Claude ต้องเลือกสไตล์ กฎดั้งเดิมไม่ได้บอกวิธี มันเลือกแบบสุ่มหรือหาค่าเฉลี่ย

3. คุณภาพการทดสอบ

*"การดำเนินการตามเป้าหมาย" ถือว่า "การทดสอบผ่าน" เป็นความสำเร็จ ไม่ได้บอกว่าการทดสอบต้อง มีความหมาย* ผลลัพธ์คือการทดสอบที่ไม่ทดสอบอะไรที่มีประโยชน์แต่ทำให้ Claude มั่นใจ

4. โปรดักชันกับต้นแบบ

**กฎ 4 ข้อเดียวกันที่ปกป้องโค้ดโปรดักชันจากวิศวกรรมเกินความจำเป็นยังทำให้ต้นแบบช้าลงซึ่งจำเป็นต้องมีโครงนั่งร้านเชิงคาดเดา 100 บรรทัดเพื่อหาแนวทาง "ความเรียบง่ายต้องมาก่อน" ของ Karpathy ยิงเกินเป้าบนโค้ดระยะแรก

กฎ 8 ข้อที่เพิ่มไม่ได้แทนที่กฎ 4 ข้อของ Karpathy พวกมันปิดช่องว่างที่โมเดลของเขา การเขียนโค้ดแบบ autocomplete ในเดือนมกราคม 2026 ไม่ตรงกับงานที่ขับเคลื่อนด้วยเอเจนต์ หลายขั้นตอน และหลายโค้ดเบสในเดือนพฤษภาคม 2026

สิ่งที่ใช้ไม่ได้ผล

สิ่งที่ฉันลองก่อนที่จะตัดสินใจใช้ 12 กฎ:

• เพิ่มกฎที่ฉันเห็นบน Reddit / X ส่วนใหญ่เป็นการกล่าวซ้ำกฎ 4 ข้อของ Karpathy ด้วยคำต่างกัน หรือกฎเฉพาะโดเมน ("ใช้ Tailwind classes เสมอ") ที่ไม่สามารถสรุปทั่วไปได้ ตัดออก
• มากกว่า 12 กฎ ฉันทดสอบถึง 18 กฎ การปฏิบัติตามลดลงจาก 76% เป็น 52% เมื่อเกิน 14 กฎ เพดาน 200 บรรทัดมีจริง เมื่อเกินไป Claude เริ่มจับคู่รูปแบบกับ "มีกฎอยู่" โดยไม่อ่านจริงๆ
• กฎที่ขึ้นอยู่กับเครื่องมือที่อาจไม่มี "ใช้ eslint เสมอ" พังเมื่อไม่ได้ติดตั้ง eslint กฎล้มเหลวอย่างเงียบๆ แทนที่ด้วยวลีที่ไม่ขึ้นกับความสามารถ: "จับคู่สไตล์ที่บังคับใช้ของโค้ดเบส" แทน "ใช้ eslint"
• ตัวอย่างใน CLAUDE.md แทนกฎ ตัวอย่างหนักกว่ากฎ ตัวอย่างสามตัวอย่างใช้บริบทมากพอๆ กับ ~10 กฎ และ Claude over-fit กับตัวอย่าง กฎเป็นนามธรรม ตัวอย่างเป็นรูปธรรม ใช้กฎ
• "ระวัง" / "คิดหนัก" / "โฟกัสจริงๆ" สัญญาณรบกวนล้วนๆ การปฏิบัติตามกฎเหล่านี้ลดลงเหลือ ~30% เพราะไม่สามารถทดสอบได้ แทนที่ด้วยคำสั่งที่เป็นรูปธรรม ("ระบุสมมติฐานอย่างชัดเจน")
• บอก Claude ให้เป็น "อาวุโส" ใช้ไม่ได้ Claude คิดว่ามันอาวุโสอยู่แล้ว ช่องว่างการปฏิบัติตามคือระหว่างความคิดและการทำ กฎที่เป็นคำสั่งปิดช่องว่าง พรอมต์อัตลักษณ์ไม่

CLAUDE.md ครบ 12 กฎ (พร้อมคัดลอกและวาง)

1# CLAUDE.md — เทมเพลต 12 กฎ
2
3กฎเหล่านี้ใช้กับทุกงานในโปรเจกต์นี้เว้นแต่จะถูกแทนที่อย่างชัดเจน
4อคติ: ระมัดระวังมากกว่าความเร็วในงานที่ไม่สำคัญ ใช้ดุลยพินิจในงานเล็กน้อย
5
6## กฎข้อ 1 — คิดก่อนเขียนโค้ด
7ระบุสมมติฐานอย่างชัดเจน หากไม่แน่ใจ ให้ถามมากกว่าเดา
8นำเสนอการตีความหลายแบบเมื่อมีความคลุมเครือ
9ทักท้วงเมื่อมีแนวทางที่ง่ายกว่า
10หยุดเมื่อสับสน ระบุสิ่งที่ยังไม่ชัดเจน
11
12## กฎข้อ 2 — ความเรียบง่ายต้องมาก่อน
13โค้ดขั้นต่ำที่แก้ปัญหาได้ ไม่มีอะไรที่คาดเดา
14ไม่มีฟีเจอร์เกินกว่าที่ขอ ไม่มีนามธรรมสำหรับโค้ดที่ใช้ครั้งเดียว
15ทดสอบ: วิศวกรอาวุโสจะบอกว่านี่ซับซ้อนเกินไปหรือไม่? ถ้าใช่ ทำให้ง่ายขึ้น
16
17## กฎข้อ 3 — การเปลี่ยนแปลงแบบผ่าตัด
18แตะเฉพาะสิ่งที่ต้องแตะ ทำความสะอาดเฉพาะสิ่งที่คุณทำ
19อย่า "ปรับปรุง" โค้ดข้างเคียง คอมเมนต์ หรือการจัดรูปแบบ
20อย่ารีแฟกเตอร์สิ่งที่ยังไม่เสีย จับคู่สไตล์ที่มีอยู่
21
22## กฎข้อ 4 — การดำเนินการตามเป้าหมาย
23กำหนดเกณฑ์ความสำเร็จ วนซ้ำจนกว่าจะยืนยัน
24อย่าทำตามขั้นตอน กำหนดความสำเร็จและทำซ้ำ
25เกณฑ์ความสำเร็จที่แข็งแกร่งช่วยให้คุณวนซ้ำได้อย่างอิสระ
26
27## กฎข้อ 5 — ใช้โมเดลเฉพาะสำหรับการตัดสินใจที่ต้องใช้ดุลยพินิจ
28ใช้ฉันสำหรับ: การจำแนกประเภท, การร่าง, การสรุป, การแยกข้อมูล
29ห้ามใช้ฉันสำหรับ: การกำหนดเส้นทาง, การลองใหม่, การแปลงที่กำหนดได้
30หากโค้ดสามารถตอบได้ โค้ดตอบ
31
32## กฎข้อ 6 — งบประมาณโทเคนไม่ใช่คำแนะนำ
33ต่องาน: 4,000 โทเคน ต่อเซสชัน: 30,000 โทเคน
34หากใกล้ถึงงบประมาณ ให้สรุปและเริ่มใหม่
35แจ้งว่าเกินงบ อย่าเกินอย่างเงียบๆ
36
37## กฎข้อ 7 — แสดงความขัดแย้ง อย่าหาค่าเฉลี่ย
38หากสองรูปแบบขัดแย้งกัน ให้เลือกหนึ่งรูปแบบ (ที่ใหม่กว่า / ที่ผ่านการทดสอบมากกว่า)
39อธิบายเหตุผล ทำเครื่องหมายอีกรูปแบบเพื่อทำความสะอาด
40อย่าผสมผสานรูปแบบที่ขัดแย้งกัน
41
42## กฎข้อ 8 — อ่านก่อนเขียน
43ก่อนเพิ่มโค้ด ให้อ่าน exports, ผู้เรียกโดยตรง, ยูทิลิตี้ที่ใช้ร่วมกัน
44"ดูไม่เกี่ยวข้องกัน" เป็นอันตราย หากไม่แน่ใจว่าเหตุใดโค้ดจึงมีโครงสร้างแบบนั้น ให้ถาม
45
46## กฎข้อ 9 — การทดสอบยืนยันเจตนา ไม่ใช่แค่พฤติกรรม
47การทดสอบต้องเข้ารหัสว่าเหตุใดพฤติกรรมจึงสำคัญ ไม่ใช่แค่สิ่งที่ทำ
48การทดสอบที่ไม่สามารถล้มเหลวเมื่อตรรกะทางธุรกิจเปลี่ยนไปถือว่าผิด
49
50## กฎข้อ 10 — จุดตรวจสอบหลังจากทุกขั้นตอนสำคัญ
51สรุปสิ่งที่ทำ สิ่งที่ยืนยันแล้ว และสิ่งที่เหลือ
52อย่าดำเนินการต่อจากสถานะที่คุณไม่สามารถอธิบายกลับมาได้
53หากคุณหลงทาง ให้หยุดและบอกสถานะใหม่
54
55## กฎข้อ 11 — จับคู่ธรรมเนียมปฏิบัติของโค้ดเบส แม้ว่าคุณจะไม่เห็นด้วย
56การปฏิบัติตาม > รสนิยมภายในโค้ดเบส
57หากคุณคิดว่าธรรมเนียมปฏิบัตินั้นเป็นอันตรายจริงๆ ให้แจ้งออกมา อย่าแยกออกไปอย่างเงียบๆ
58
59## กฎข้อ 12 — ล้มเหลวให้ดัง
60"เสร็จสมบูรณ์" ผิดหากมีอะไรถูกข้ามอย่างเงียบๆ
61"การทดสอบผ่าน" ผิดหากมีการข้ามการทดสอบใดๆ
62ค่าเริ่มต้นคือการแสดงความไม่แน่นอน ไม่ใช่ซ่อนมัน

บันทึกเป็น CLAUDE.md ที่รากของ repo ของคุณ เพิ่มกฎเฉพาะโปรเจกต์ด้านล่างกฎ 12 ข้อ (สแต็ก, คำสั่งทดสอบ, รูปแบบข้อผิดพลาด) อย่าเกิน 200 บรรทัดรวม เกินกว่านั้น การปฏิบัติตามลดลง

วิธีติดตั้ง

สองขั้นตอน:

1# 1. ต่อท้ายกฎพื้นฐาน 4 ข้อของ Karpathy ไปยัง CLAUDE.md ของคุณ
2curl https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md >> CLAUDE.md
3
4# 2. วางกฎข้อ 5-12 จากบทความนี้ด้านล่าง

บันทึกที่รากของ repo ของคุณ >> มีความสำคัญ มันต่อท้ายไฟล์ CLAUDE.md ที่มีอยู่ของคุณแทนที่จะเขียนทับกฎเฉพาะโปรเจกต์ที่คุณมีอยู่แล้ว

กรอบความคิด

CLAUDE.md ไม่ใช่รายการความปรารถนา มันคือ สัญญาทางพฤติกรรม ที่ปิดรูปแบบความล้มเหลวเฉพาะที่คุณสังเกตเห็น

ทุกกฎควรตอบ: ข้อผิดพลาดอะไรที่กฎนี้ป้องกัน?

กฎ 4 ข้อของ Karpathy ป้องกันรูปแบบความล้มเหลวที่เขาเห็นในเดือนมกราคม 2026: การตั้งสมมติฐานอย่างเงียบๆ, วิศวกรรมเกินความจำเป็น, ความเสียหายข้างเคียง, เกณฑ์ความสำเร็จที่อ่อนแอ พวกมันเป็นพื้นฐาน อย่าข้าม

กฎ 8 ข้อที่ฉันเพิ่มป้องกันรูปแบบความล้มเหลวที่เกิดขึ้นในเดือนพฤษภาคม 2026: การวนซ้ำของเอเจนต์ที่ไม่มีงบประมาณ, งานหลายขั้นตอนที่ไม่มีจุดตรวจสอบ, การทดสอบที่ไม่ทดสอบ, ความสำเร็จที่เงียบซ่อนความล้มเหลวที่เงียบ พวกมันเป็นส่วนเสริม

ผลลัพธ์ของคุณอาจแตกต่าง หากคุณไม่รันไพพ์ไลน์หลายขั้นตอน กฎข้อ 10 ไม่สำคัญ หากโค้ดเบสของคุณมีสไตล์ที่สอดคล้องกันเดียวที่บังคับใช้โดย linting กฎข้อ 11 ซ้ำซ้อน อ่าน 12 ข้อ เก็บข้อที่ตรงกับข้อผิดพลาดที่คุณเคยทำจริง ทิ้งที่เหลือ

CLAUDE.md 6 กฎที่ปรับให้เหมาะกับรูปแบบความล้มเหลวจริงของคุณ ดีกว่า CLAUDE.md 12 กฎที่มี 6 กฎที่คุณไม่ต้องใช้

จ บ บ ท ค ว า ม

กระทู้เดือนมกราคม 2026 ของ Karpathy เป็นการบ่น Forrest Chang เปลี่ยนมันเป็น 4 กฎ นักพัฒนา 120,000 คนให้ดาวกับผลลัพธ์ ส่วนใหญ่ยังคงใช้ 4 กฎในวันนี้

โมเดลดีขึ้นแล้ว ระบบนิเวศเปลี่ยนไป เอเจนต์หลายขั้นตอน, ฮุคแบบลูกโซ่, การโหลดสกิล, งานหลายโค้ดเบส — ไม่มีสิ่งเหล่านี้อยู่ตอนที่ Karpathy เขียนกระทู้ กฎ 4 ข้อไม่ได้จัดการกับสิ่งเหล่านี้ พวกมันไม่ผิด พวกมันไม่สมบูรณ์

เพิ่มอีก 8 กฎ ทดสอบ 6 สัปดาห์ใน 30 โค้ดเบส อัตราข้อผิดพลาดจาก 41% เป็น 3%

บุ๊กมาร์กสิ่งนี้และวางกฎ 12 ข้อลงใน CLAUDE.md ของคุณคืนนี้ แชร์ต่อหากมันช่วยคุณประหยัดเวลาหนึ่งสัปดาห์จากความผิดพลาดของ Claude

Telegram สำหรับเคล็ดลับการปรับแต่ง Claude รายวัน:

*https://t.me/+_ZWrQN7GuDA3ZDEy*