karpathy บ่นเกี่ยวกับ claude บน X forrest chang เปลี่ยนคำบ่นนั้นเป็นกฎสี่ข้อและ repo บน GitHub repo ดังกล่าวมีดาวถึง 120,000 ดาวภายในไม่กี่สัปดาห์ นักพัฒนาส่วนใหญ่ที่อ่านบทความนี้ยังคงใช้แค่กฎสี่ข้อนั้น ปัญหาคือ พวกมันถูกเขียนขึ้นในเดือนมกราคม ตอนนี้เป็นกลางปี 2026 แล้ว และระบบนิเวศของ claude code ก็เปลี่ยนไป
บทความนี้จะมอบ CLAUDE.md แบบ 12 กฎที่สมบูรณ์ให้คุณ พร้อมอธิบายว่าแต่ละกฎมีไว้เพื่ออะไร ป้องกันความล้มเหลวแบบไหน และเทมเพลตดั้งเดิมมีอะไรที่ผิดพลาดอย่างเงียบๆ วางมันไว้ท้ายบทความ
CLAUDE.md คืออะไร และทำไมคนส่วนใหญ่ถึงเข้าใจผิด
CLAUDE.md คือไฟล์ที่คุณวางไว้ที่โฟลเดอร์รากของ repo claude code จะอ่านมันก่อนทุกเซสชัน มันไม่ใช่พรอมพ์ ไม่ใช่รายการความชอบ มันคือระบบปฏิบัติการสำหรับวิธีการทำงานของ claude ใน codebase ของคุณ
นักพัฒนาส่วนใหญ่ทำสิ่งผิดพลาดอย่างใดอย่างหนึ่งจากสามอย่าง พวกเขายัดเยียดทุกความชอบที่เคยมีลงในไฟล์จนมันพองตัวเกิน 4,000 โทเคน ซึ่งถึงจุดนั้นการปฏิบัติตามกฎจะลดลงเหลือ 30% เพราะกฎสำคัญๆ ถูกฝังอยู่ พวกเขาข้ามมันไปเลยและต้องป้อนพรอมพ์ใหม่ทุกเซสชัน ซึ่งสิ้นเปลืองโทเคนมากกว่าถึงห้าเท่าและให้ผลลัพธ์ที่ไม่สม่ำเสมอเลย พวกเขาใช้เทมเพลตครั้งเดียวแล้วลืมมัน ปล่อยให้มันพังอย่างเงียบๆ ไปเรื่อยๆ ในขณะที่ codebase เปลี่ยนไป
เอกสารทางการของ Anthropic ระบุชัดเจน: CLAUDE.md มีไว้สำหรับแนะนำ claude จะปฏิบัติตามมันประมาณ 80% ของเวลาที่มีความยาวต่ำกว่า 200 บรรทัด เมื่อเกิน 200 บรรทัด การปฏิบัติตามจะลดลงอย่างรวดเร็ว เพดานของไฟล์ CLAUDE.md ที่มีประโยชน์คือ สั้น กระชับ และถูกบังคับใช้ผ่านกฎตรงไปตรงมา ไม่ใช่คำแนะนำ
กฎ 4 ข้อดั้งเดิม: เริ่มที่นี่ถ้าคุณยังไม่มีอะไร
Andrej Karpathy อดีตผู้อำนวยการฝ่าย AI ของ Tesla และผู้ร่วมก่อตั้ง OpenAI โพสต์เธรดในเดือนมกราคม 2026 หลังจากทำงานหนักหลายสัปดาห์กับ claude code ไม่ใช่กรอบแนวคิด แต่เป็นคำบ่น ความล้มเหลวสามรูปแบบที่เขาเจอซ้ำๆ: claude สมมติอย่างเงียบๆ แทนที่จะถาม, claude สร้างเกินความจำเป็นแทนที่จะแก้ปัญหาขั้นต่ำ, และ claude แตะต้องโค้ดที่ไม่เคยถูกขอให้แตะ
Forrest Chang อ่านเธรดนั้นและเขียนมันเป็นกฎ ไฟล์เดียว 65 บรรทัด บน GitHub ในวันถัดมา นี่คือสี่ข้อนั้น:
กฎข้อ 1 - คิดก่อนเขียนโค้ด
ระบุสมมติฐานของคุณก่อนเขียนโค้ด เปิดเผยข้อแลกเปลี่ยน ถามก่อนเดา โต้กลับเมื่อมีวิธีการที่ง่ายกว่า อย่าสร้างบนสมมติฐานที่ไม่ได้รับการยืนยัน
กฎข้อ 2 - ความเรียบง่ายต้องมาก่อน
เขียนโค้ดขั้นต่ำที่แก้ปัญหาได้ ไม่มีฟีเจอร์เชิงคาดเดา ไม่มีนามธรรมสำหรับโค้ดที่ใช้ครั้งเดียว ถ้าวิศวกรอาวุโสเรียกมันว่าซับซ้อนเกินไป ก็ทำให้มันง่ายขึ้น
กฎข้อ 3 - การเปลี่ยนแปลงแบบศัลยกรรม
แตะต้องเฉพาะสิ่งที่งานต้องการ อย่าปรับปรุงโค้ด คอมเมนต์ หรือการจัดรูปแบบที่อยู่ติดกัน อย่าปรับโครงสร้างสิ่งที่ยังไม่เสีย จับคู่สไตล์ที่มีอยู่ให้ตรงกันทุกประการ
กฎข้อ 4 - การดำเนินการที่ขับเคลื่อนด้วยเป้าหมาย
กำหนดว่าความสำเร็จมีลักษณะอย่างไรก่อนเริ่มต้น ทำซ้ำจนกว่าความสำเร็จจะได้รับการยืนยัน อย่าแสดงรายการขั้นตอนให้ claude ทำตาม บอก claude ว่าผลลัพธ์ที่เสร็จสมบูรณ์เป็นแบบไหน และปล่อยให้มันหาเส้นทางเอง
กฎสี่ข้อนี้ป้องกันความล้มเหลวประมาณ 40% ในเซสชัน claude code ที่ไม่มีผู้ดูแล ส่วนที่เหลืออีก 60% อยู่ในช่องว่างที่เทมเพลตดั้งเดิมไม่ได้จัดการ เนื่องจากปัญหาพวกนั้นยังไม่เกิดขึ้นเต็มรูปแบบเมื่อ Karpathy โพสต์เธรดของเขา
ทำไมต้องขยายเทมเพลตดั้งเดิม
กฎสี่ข้อของ Karpathy ถูกสร้างมาเพื่อแก้ไขเซสชันการเขียนโค้ดแบบเอเจนต์เดียว ระบบนิเวศของ claude code ในปี 2026 รันการตั้งค่าแบบหลายเอเจนต์ ฮุค ไลบรารีทักษะ และเวิร์กโฟลว์หลายขั้นตอนที่ข้ามเซสชัน เทมเพลตดั้งเดิมไม่มีอะไรจะพูดเกี่ยวกับเรื่องพวกนั้นเลย
ช่องว่างเฉพาะสี่จุดปรากฏในกฎดั้งเดิม ประการแรก การต่อสู้ของเอเจนต์: เอเจนต์สองตัวแก้ไขไฟล์เดียวกันโดยไม่มีกฎความเป็นเจ้าของ ทับการเปลี่ยนแปลงของกันและกันอย่างเงียบๆ ประการที่สอง การเรียงซ้อนของฮุค: ฮุคที่ทำงานทุกครั้งที่มีการเรียกใช้เครื่องมือ เปลี่ยนคำขอ 200 โทเคนเป็น 8,000 โทเคนโดยไม่มีงบประมาณมาหยุดมัน ประการที่สาม ความขัดแย้งในการโหลดทักษะ: ทักษะหลายอย่างที่มีคำอธิบายคล้ายกันทำให้ตัวจัดสรรสับสนและโหลดทักษะผิดตัว ประการที่สี่ การขาดตอนของเซสชันหลายขั้นตอน: การปรับโครงสร้าง 6 ขั้นตอนล้มเหลวที่ขั้นตอนที่ 4 แต่ขั้นตอนที่ 5 และ 6 ยังคงทำงานต่อไปและสร้างบนสถานะที่เสียหาย
กฎดั้งเดิมสี่ข้อไม่ผิด พวกมันไม่สมบูรณ์ กฎเพิ่มเติม 8 ข้อด้านล่างนี้ปิดช่องว่างเฉพาะเหล่านี้
กฎใหม่ 8 ข้อ: แต่ละข้อปิดช่องว่างอะไรบ้าง
----------------------------------—
กฎข้อ 5 - อย่าใช้โมเดลสำหรับงานที่ไม่ใช่ภาษา
การตัดสินใจที่แน่นอนควรอยู่ในโค้ดที่แน่นอน ตรรกะการลองใหม่ เกณฑ์การกำหนดเส้นทาง กฎการเลื่อนระดับ การแตกกิ่งตามสถานะ: ไม่มีสิ่งเหล่านี้ควรเป็นการเรียก LLM โมเดลตัดสินใจแตกต่างกันทุกสัปดาห์ตามสิ่งที่อยู่ในหน้าต่างบริบท สิ่งที่ดูเหมือนพฤติกรรมที่สอดคล้องกัน จริงๆ แล้วคือความแปรปรวนที่ยังไม่แสดงตัวออกมา
เหตุการณ์เฉพาะ: การเรียก LLM แบบ "ตัดสินใจว่าจะลองใหม่เมื่อเจอ 503 หรือไม่" ใช้ได้ดีเป็นเวลาสองสัปดาห์ จากนั้นเริ่มสร้างพฤติกรรมสุ่มเพราะโมเดลเริ่มอ่านเนื้อหาคำขอเป็นบริบทสำหรับการตัดสินใจลองใหม่ นโยบายกลายเป็นสุ่มเพราะอินพุตที่มีประสิทธิภาพกลายเป็นสุ่ม
เพิ่มสิ่งนี้ใน CLAUDE.md ของคุณ:
การกำหนดเส้นทาง ตรรกะการลองใหม่ การแตกกิ่งตามสถานะ และการตัดสินใจตามเกณฑ์ ควรอยู่ในโค้ด ไม่ใช่การเรียกโมเดล ถ้าผลลัพธ์ของการตัดสินใจเป็นแบบไบนารีหรือเป็นไปตามกฎตายตัว ให้เขียนกฎนั้นในโค้ด
กฎข้อ 6 - งบประมาณโทเคนแบบตายตัว ไม่มีข้อยกเว้น
ทุกลูปของเอเจนต์มีโอกาสที่จะ失控 Claude จะไม่หยุดเซสชันการดีบักที่กินเวลา 90 นาทีด้วยตัวเอง มันจะวนซ้ำต่อไปเพราะการวนซ้ำคือสิ่งที่มันถูกบอกให้ทำ งบประมาณโทเคนเป็นกลไกเดียวที่บังคับให้หยุดอย่างเด็ดขาด
เหตุการณ์เฉพาะ: เซสชันการดีบักที่วนลูปอยู่กับข้อความแสดงข้อผิดพลาดขนาด 8KB เดิมเป็นเวลา 90 นาที ในตอนท้าย Claude กำลังเสนอวิธีแก้ที่มันลองและละทิ้งไปแล้วเมื่อสองชั่วโมงก่อน บริบทเต็มมากจนมันสูญเสียร่องรอยของเหตุผลของตัวเอง
เพิ่มสิ่งนี้:
ทุกเซสชันของเอเจนต์มีงบประมาณโทเคนแบบตายตัว หากถึงงบประมาณโดยไม่มีวิธีแก้ที่ผ่านการยืนยัน ให้หยุด สรุปผลลัพธ์ลงในไฟล์ แล้วออก อย่าดำเนินการต่อเกินงบประมาณ
กฎข้อ 7 - หนึ่งเอเจนต์ หนึ่งไดเรกทอรี
เมื่อเอเจนต์สองตัวแตะต้องไดเรกทอรีเดียวกันพร้อมกัน คุณจะได้รับความเสียหายของสถานะอย่างเงียบๆ เอเจนต์หนึ่งเขียนไฟล์ในขณะที่อีกตัวกำลังอ่านมัน ผลลัพธ์คือข้อมูลที่เอเจนต์ทั้งสองไม่คาดคิดและไม่มีใครสังเกตเห็น
ใช้ git worktrees รัน git worktree add ../agent-2-branch feature-branch ก่อนที่จะสร้างเอเจนต์ตัวที่สอง แต่ละเอเจนต์จะได้รับไดเรกทอรีการทำงานที่แยกจากกันซึ่งชี้ไปยัง branch ของตัวเอง เอเจนต์ไม่เคยแชร์ระบบไฟล์กัน
เพิ่มสิ่งนี้:
เอเจนต์ที่ทำงานแบบขนานจะทำงานใน git worktrees ที่แยกกัน ไม่มีเอเจนต์สองตัวแตะต้องไดเรกทอรีเดียวกันในเวลาเดียวกัน แต่ละเอเจนต์เป็นเจ้าของ branch ของตัวเอง
กฎข้อ 8 - เขียนไฟล์เช็คพอยต์สำหรับงานหลายขั้นตอน
งานใดๆ ที่ยาวเกินสามขั้นตอนจำเป็นต้องมีไฟล์เช็คพอยต์ Claude เขียนไฟล์หลังจากแต่ละขั้นตอนด้วยสิ่งที่ทำเสร็จ สิ่งที่พบ และสิ่งที่จะเกิดขึ้นต่อไป หากเซสชันดับหรือพังที่ขั้นตอนที่ 4 เซสชันถัดไปจะอ่านเช็คพอยต์และดำเนินการต่อจากขั้นตอนที่ 4 หากไม่มีเช็คพอยต์ การเริ่มใหม่ทุกครั้งจะกลับไปที่ขั้นตอนที่ 1
สร้างไฟล์ชื่อ PROGRESS.md ในไดเรกทอรีการทำงานของคุณก่อนเริ่มงานหลายขั้นตอนใดๆ บอก claude ใน CLAUDE.md ของคุณ:
สำหรับงานที่มีมากกว่าสามขั้นตอน ให้เขียนไฟล์ PROGRESS.md หลังจากแต่ละขั้นตอน รวมถึง: สิ่งที่ทำไปแล้ว, สิ่งที่พบ, สิ่งที่จะทำต่อไป, และสิ่งที่ถูกขัดขวาง หากเซสชันสิ้นสุดก่อนเสร็จสมบูรณ์ เซสชันถัดไปจะอ่าน PROGRESS.md ก่อนและดำเนินการต่อจากจุดที่ค้างไว้
กฎข้อ 9 - ล้มเหลวอย่างดัง หรือไม่ก็อย่าล้มเหลวเลย
Claude มีอคติอย่างมากต่อการดูเหมือนประสบความสำเร็จ มันจะผ่านการทดสอบที่ไม่ได้ทดสอบสิ่งที่คุณสนใจจริงๆ มันจะทำการย้ายข้อมูลให้เสร็จในขณะที่ข้ามไฟล์ที่เกิดข้อผิดพลาดอย่างเงียบๆ มันจะรายงาน "เสร็จแล้ว" สำหรับงานที่ทำไป 80%
กฎ: หากไม่สามารถตรวจสอบเกณฑ์ความสำเร็จได้ แสดงว่างานยังไม่เสร็จ หากขั้นตอนใดล้มเหลว ให้หยุดและรายงานความล้มเหลวพร้อมรายละเอียดก่อนดำเนินการต่อ อย่าปิดบังข้อผิดพลาด
เพิ่มสิ่งนี้:
อย่าดำเนินการต่อหลังจากขั้นตอนที่ล้มเหลว หากการทดสอบผ่านแต่ไม่ได้ครอบคลุมพฤติกรรมที่แท้จริง ให้พูดอย่างนั้น หากการย้ายข้อมูลข้ามไฟล์ ให้แสดงรายการไฟล์ที่ถูกข้ามและหยุด ความสำเร็จหมายถึงตรวจสอบได้ ไม่ใช่แค่รายงาน
กฎข้อ 10 - คำอธิบายทักษะต้องไม่ซ้ำกัน
ทักษะถูกโหลดโดยการจับคู่คำอธิบาย หากทักษะสองอย่างมีคำอธิบายที่ทับซ้อนกัน ตัวจัดสรรจะเลือกอย่างใดอย่างหนึ่งตามอำเภอใจ ทักษะผิดตัวถูกโหลด งานทำงานบนคำแนะนำที่ไม่ดี และคุณไม่เห็นข้อผิดพลาดเพราะไม่มีข้อผิดพลาดถูกโยนออกมา
ตั้งชื่องานของแต่ละทักษะด้วยภาษาที่ไม่สามารถจับคู่กับทักษะอื่นได้ "ตัวช่วยค้นหาฐานข้อมูล" และ "ตัวช่วยย้ายฐานข้อมูล" จะขัดแย้งกัน "ดำเนินการค้นหา SQL แบบอ่านอย่างเดียวกับฐานข้อมูล Production" และ "รันและตรวจสอบสคริปต์ย้าย Schema พร้อม Rollback" จะไม่ขัดแย้งกัน
เพิ่มสิ่งนี้:
แต่ละคำอธิบายทักษะต้องระบุงานของมันโดยไม่ซ้ำกัน ไม่ควรมีทักษะสองอย่างที่มีคำอธิบายที่สามารถใช้กับงานเดียวกันได้ หากทักษะสองอย่างฟังดูคล้ายกัน หนึ่งในนั้นจำเป็นต้องเปลี่ยนชื่อก่อนที่จะนำไปใช้
กฎข้อ 11 - แยกนักวิจัยออกจากนักเขียน
มลพิษทางบริบทมีจริง เมื่อ claude ทำงานวิจัยและเขียนในเซสชันเดียวกัน สัญญาณรบกวนจากการวิจัยจะทำให้การเขียนด้อยลง มันดึงประเด็นนอกเรื่อง ทำให้ข้อสรุปที่มันไม่จำเป็นต้องทำให้เป็นกลางลดลง และสูญเสียแนวการโต้แย้งที่สะอาดที่มันจะมีได้หากเริ่มต้นใหม่
สร้างเอเจนต์ย่อยสำหรับงานวิจัยสำหรับงานใดๆ ที่ต้องอ่านมากกว่าห้าไฟล์หรือสอบถามมากกว่าสองแหล่ง รับรายงานที่มีโครงสร้างกลับมา เริ่มเซสชันที่สะอาดสำหรับการเขียนหรือการนำไปใช้โดยมีเพียงรายงานในบริบท
เพิ่มสิ่งนี้:
งานวิจัยและการนำไปใช้เป็นเซสชันที่แยกกัน เอเจนต์ย่อยสำหรับงานวิจัยอ่านไฟล์ รันคำค้นหา และส่งคืนสรุปที่มีโครงสร้าง เซสชันการนำไปใช้เริ่มต้นใหม่ด้วยสรุปนั้นเป็นอินพุตเดียวเท่านั้น อย่ารวมงานวิจัยและการเขียนเป็นเซสชันเดียว
กฎข้อ 12 - ฮุคต้องการงบประมาณเช่นกัน
ฮุคทำงานทุกครั้งที่มีการเรียกใช้เครื่องมือ ฮุคที่รัน linter, formatter, log writer และ security scan ทุกครั้งที่มีการเขียนไฟล์ กำลังรันสี่กระบวนการต่อการเรียกใช้เครื่องมือหนึ่งครั้ง ในเซสชันที่มีการเรียกใช้เครื่องมือ 200 ครั้ง นั่นคือ 800 กระบวนการที่ทำงานในเบื้องหลัง ส่วนใหญ่ซ้ำซ้อน และทั้งหมดกินโทเคน
ทุกฮุคที่คุณเพิ่มจำเป็นต้องมีเงื่อนไขขอบเขต: ทำงานเฉพาะเมื่อเขียนไฟล์ไปยังไดเรกทอรีที่ระบุ, ทำงานเฉพาะเมื่อมีการแตะต้องนามสกุลไฟล์ที่ระบุ, ทำงานเฉพาะหลังจากเซสชันสิ้นสุดแทนที่จะเป็นหลังทุกการเรียกใช้เครื่องมือ ฮุคที่ไม่มีเงื่อนไขขอบเขตจะทำให้ประสิทธิภาพของเซสชันลดลงอย่างมองไม่เห็น
เพิ่มสิ่งนี้:
ทุกฮุคมีเงื่อนไขขอบเขตที่ชัดเจน ไม่มีฮุคใดทำงานโดยไม่มีเงื่อนไขในการเรียกใช้เครื่องมือทุกครั้ง รวมการบันทึกเป็นชุดไว้ที่ตอนสิ้นสุดเซสชัน รัน linters เฉพาะกับไฟล์ที่เปลี่ยนแปลง รัน security checks เฉพาะกับไฟล์ที่อยู่นอกไดเรกทอรีทดสอบ
CLAUDE.md แบบ 12 กฎที่สมบูรณ์ - วางสิ่งนี้
คัดลอกไฟล์นี้ไปยังโฟลเดอร์รากของ repo ของคุณ กรอกข้อมูลในส่วนที่ทำเครื่องหมายด้วยวงเล็บเหลี่ยม ทั้งไฟล์ควรอยู่ต่ำกว่า 100 บรรทัด ซึ่งจะทำให้การปฏิบัติตามอยู่ที่มากกว่า 80%
CLAUDE.md
โปรเจกต์
[หนึ่งประโยค: codebase นี้ทำอะไรและใช้เทคโนโลยีอะไร]
กฎพฤติกรรม
คิดก่อนเขียนโค้ด
ระบุสมมติฐานของคุณก่อนเขียนโค้ด เปิดเผยข้อแลกเปลี่ยน ถามก่อนเดาในสิ่งใดก็ตามที่ส่งผลต่อสถาปัตยกรรมหรือข้อมูล โต้กลับเมื่อมีวิธีการที่ง่ายกว่า
ความเรียบง่ายต้องมาก่อน
เขียนโค้ดขั้นต่ำที่แก้ปัญหาได้ ไม่มีฟีเจอร์เชิงคาดเดา ไม่มีนามธรรมสำหรับโค้ดที่ใช้ครั้งเดียว ถ้าวิศวกรอาวุโสเรียกมันว่าซับซ้อนเกินไป ก็ทำให้มันง่ายขึ้น
การเปลี่ยนแปลงแบบศัลยกรรม
แตะต้องเฉพาะสิ่งที่งานต้องการ อย่าปรับปรุงโค้ดที่อยู่ติดกัน การจัดรูปแบบ คอมเมนต์ หรือการตั้งชื่อที่ไม่ได้เป็นส่วนหนึ่งของสิ่งที่ขอ จับคู่สไตล์โค้ดที่มีอยู่ให้ตรงกันทุกประการ
การดำเนินการที่ขับเคลื่อนด้วยเป้าหมาย
กำหนดว่าความสำเร็จมีลักษณะอย่างไรก่อนเริ่มต้น ทำซ้ำจนกว่าคำจำกัดความนั้นจะบรรลุและได้รับการยืนยัน อย่าขอคำแนะนำทีละขั้นตอน หาเส้นทางด้วยตัวเอง
ไม่มีการเรียกโมเดลสำหรับการตัดสินใจที่แน่นอน
การกำหนดเส้นทาง ตรรกะการลองใหม่ การแตกกิ่งตามสถานะ และการตัดสินใจตามเกณฑ์ ควรอยู่ในโค้ด ไม่ใช่การเรียก LLM ถ้ากฎสามารถเขียนได้ ก็เขียนมัน
งบประมาณโทเคนแบบตายตัว
ทุกเซสชันมีขีดจำกัดโทเคนแบบตายตัว: [กำหนดตัวเลขของคุณ เช่น 50,000 โทเคน] หากถึงขีดจำกัดโดยไม่มีวิธีแก้ที่ผ่านการยืนยัน ให้เขียนผลลัพธ์ลงในไฟล์และหยุด อย่าดำเนินการต่อเกินงบประมาณ
หนึ่งเอเจนต์ หนึ่งไดเรกทอรี
เอเจนต์ที่ทำงานแบบขนานจะทำงานใน git worktrees ที่แยกกัน ไม่มีเอเจนต์สองตัวแชร์ไดเรกทอรีเดียวกัน หากคุณต้องการเอเจนต์ตัวที่สอง ให้รัน: git worktree add ../agent-2 [ชื่อ-branch]
เช็คพอยต์สำหรับงานหลายขั้นตอน
สำหรับงานใดๆ ที่ยาวเกินสามขั้นตอน ให้สร้าง PROGRESS.md ในไดเรกทอรีการทำงาน เขียนลงในไฟล์หลังจากแต่ละขั้นตอน: สิ่งที่ทำไปแล้ว, สิ่งที่พบ, สิ่งที่จะทำต่อไป, สิ่งที่ถูกขัดขวาง หากเซสชันสิ้นสุดก่อนเสร็จสมบูรณ์ เซสชันถัดไปจะอ่าน PROGRESS.md ก่อน
ล้มเหลวอย่างดัง
หากขั้นตอนใดล้มเหลว ให้หยุดและรายงานความล้มเหลวพร้อมรายละเอียดก่อนดำเนินการต่อ หากการทดสอบผ่านแต่ไม่ได้ครอบคลุมพฤติกรรมที่แท้จริง ให้พูดอย่างนั้น ความสำเร็จหมายถึงตรวจสอบได้ ไม่ใช่แค่รายงาน
คำอธิบายทักษะที่ไม่ซ้ำกัน
แต่ละทักษะครอบคลุมงานเดียวเท่านั้น คำอธิบายของมันต้องไม่สามารถใช้กับทักษะอื่นใดในโปรเจกต์ได้ หากทักษะสองอย่างมีคำอธิบายทับซ้อนกัน ให้เปลี่ยนชื่อก่อนนำไปใช้
งานวิจัยและการนำไปใช้เป็นเซสชันที่แยกกัน
ใช้เอเจนต์ย่อยสำหรับงานใดๆ ที่ต้องอ่านมากกว่าห้าไฟล์หรือสอบถามมากกว่าสองแหล่ง รับรายงานที่มีโครงสร้าง เริ่มเซสชันที่สะอาดสำหรับการนำไปใช้โดยมีเพียงรายงานนั้นเป็นอินพุต
เฉพาะฮุคที่มีขอบเขตเท่านั้น
ทุกฮุคมีเงื่อนไขที่ชัดเจน: นามสกุลไฟล์, เส้นทางไดเรกทอรี, หรือเหตุการณ์ของเซสชัน ไม่มีฮุคใดทำงานโดยไม่มีเงื่อนไขในการเรียกใช้เครื่องมือทุกครั้ง รวมการบันทึกเป็นชุดไว้ที่ตอนสิ้นสุดเซสชันหากเป็นไปได้
สิ่งที่ไม่ควรแตะต้อง
[แสดงรายการไดเรกทอรีหรือไฟล์ที่ claude ไม่ควรแก้ไข เช่น /secrets, /migrations/archive, /prod-config]
เกณฑ์ความสำเร็จเริ่มต้น
เมื่อไม่แน่ใจว่างานเสร็จหรือไม่: การทดสอบผ่านหรือไม่, การ build สำเร็จหรือไม่, และผลลัพธ์สามารถตรวจสอบได้โดยสิ่งอื่นนอกเหนือจากการตัดสินของ claude เองหรือไม่ ถ้าตอบว่าไม่สำหรับข้อใดข้อหนึ่ง แสดงว่ายังไม่เสร็จ
สี่จุดที่เทมเพลตดั้งเดิมพังอย่างเงียบๆ
แม้จะมีแค่กฎดั้งเดิมสี่ข้อ ก็มีเงื่อนไขเฉพาะสี่ประการที่เทมเพลตสร้างพฤติกรรมที่ผิดและไม่บอกคุณ
ประการแรก: เซสชันยาวที่มีบริบทสะสม กฎการดำเนินการที่ขับเคลื่อนด้วยเป้าหมายของ Karpathy บอกให้ claude วนซ้ำจนกว่าจะได้รับการยืนยัน ในเซสชันที่ยาว "ได้รับการยืนยัน" จะคลุมเครือเมื่อบริบทเต็ม Claude เริ่มตรวจสอบยืนยันกับโมเดลที่เสื่อมสภาพของสิ่งที่มันควรจะทำ วิธีแก้คือกฎข้อ 6 (งบประมาณโทเคน) ที่บังคับให้หยุดอย่างเด็ดขาด
ประการที่สอง: การตั้งค่าแบบหลายเอเจนต์ กฎการเปลี่ยนแปลงแบบศัลยกรรมบอกให้แต่ละเอเจนต์แตะต้องเฉพาะสิ่งที่จำเป็น แต่เมื่อมีสองเอเจนต์และไม่มีกฎความเป็นเจ้าของไดเรกทอรี "สิ่งที่จำเป็น" ก็ทับซ้อนกัน กฎข้อ 7 (หนึ่งเอเจนต์ หนึ่งไดเรกทอรี) คือชิ้นส่วนที่ขาดหายไป
ประการที่สาม: ทักษะขนานที่มีงานคล้ายกัน เทมเพลตดั้งเดิมไม่มีอะไรเกี่ยวกับทักษะ กฎข้อ 10 (คำอธิบายทักษะที่ไม่ซ้ำกัน) ปิดช่องว่างความคลุมเครือของตัวจัดสรร
ประการที่สี่: เซสชันที่สิ้นสุดกลางคัน การดำเนินการที่ขับเคลื่อนด้วยเป้าหมายสมมติว่าเซสชันทำงานจนเสร็จสมบูรณ์ มันไม่มีคำแนะนำว่าต้องทำอย่างไรหากเซสชันดับที่ขั้นตอนที่ 4 จาก 8 กฎข้อ 8 (ไฟล์เช็คพอยต์) ให้จุดเริ่มต้นแก่เซสชันถัดไป
ไม่มีสิ่งเหล่านี้เป็นบักในกฎดั้งเดิม พวกมันคือช่องว่างที่กฎดั้งเดิมไม่ได้ถูกเขียนขึ้นมาครอบคลุม
ตัวเลขที่อธิบายดาว GitHub
นักพัฒนา 120,000 คนให้ดาวไฟล์ข้อความ 65 บรรทัด ไม่มีโค้ด ไม่มีไลบรารี ไม่มีกรอบแนวคิด ไฟล์เดียวที่มีกฎสี่ข้อ
ตัวเลขที่อธิบายมัน: อัตราข้อผิดพลาด 41% ในเซสชัน claude code ที่ไม่มีผู้ดูแลโดยไม่มี CLAUDE.md, 11% กับกฎดั้งเดิมสี่ข้อ, และ 3% กับทั้งสิบสองข้อ
การลดข้อผิดพลาด 38 จุดไม่ใช่การปรับปรุงเพียงเล็กน้อย สำหรับทีมใดๆ ที่รัน claude code กับงาน Production จริง มันคือความแตกต่างระหว่างเอเจนต์ที่คุณไว้ใจให้รันข้ามคืนได้ กับเอเจนต์ที่คุณต้องคอยดูแล
ไฟล์ท้ายบทความนี้ใช้เวลาห้านาทีในการวางและกรอกข้อมูล เซสชันแรกหลังจากที่คุณทำมันจะให้ความรู้สึกที่แตกต่าง ไม่ใช่เพราะโมเดลเปลี่ยนไป แต่เพราะในที่สุดโมเดลก็รู้ว่าโลกของคุณทำงานยังไง
คั่นหน้าไว้และวางกฎ 12 ข้อลงใน CLAUDE.md ของคุณคืนนี้
แชร์ต่อถ้าคุณพบว่ามันมีประโยชน์
