บรรณาธิการหมายเหตุ: ในเดือนมกราคม 2026 คำวิจารณ์ของ Andrej Karpathy เกี่ยวกับ Claude ที่เขียนโค้ด ได้นำมาสู่ไฟล์ที่ดูเหมือนเล็กน้อยแต่มีความสำคัญอย่างยิ่งในกระบวนการเขียนโปรแกรมด้วย AI: CLAUDE.md จากนั้น Forrest Chang ได้จัดระเบียบปัญหาเหล่านี้เป็นกฎพฤติกรรม 4 ข้อ เพื่อจำกัดข้อผิดพลาดทั่วไปของ Claude ในการเขียนโค้ด: การสมมติแบบเงียบ การออกแบบเกินความจำเป็น การทำลายโค้ดที่ไม่เกี่ยวข้อง และการขาดมาตรฐานความสำเร็จที่ชัดเจน
แต่หลังจากหลายเดือน การใช้งาน Claude Code ไม่ได้จำกัดอยู่แค่ “ให้โมเดลเขียนโค้ดส่วนหนึ่ง” อีกต่อไป ด้วยการที่เอเจนต์หลายขั้นตอน การเชื่อมโยงแบบฮุก การโหลดทักษะ และการทำงานร่วมกันระหว่างคลังโค้ดหลายแห่งกลายเป็นเรื่องปกติ รูปแบบความล้มเหลวใหม่ๆ ก็เริ่มปรากฏขึ้น: โมเดลสูญเสียการควบคุมในงานระยะยาว การทดสอบผ่านแต่ไม่ได้ตรวจสอบตรรกะที่แท้จริง การย้ายเสร็จสิ้นแต่ข้ามข้อผิดพลาดโดยเงียบ และการผสมผสานรูปแบบโค้ดที่แตกต่างกันอย่างผิดพลาด
ผู้เขียนบทความได้ทดสอบรหัส 30 รีโพสิทอรีภายในเวลา 6 สัปดาห์ และเพิ่มกฎอีก 8 ข้อจากกฎเดิม 4 ข้อของ Karpathy เพื่อจัดการกับปัญหาใหม่ที่เกิดขึ้นเมื่อการเขียนโปรแกรมด้วย AI เปลี่ยนจากคำแนะนำครั้งเดียวไปสู่การร่วมมือแบบเอเจนต์
ด้านล่างนี้คือข้อความต้นฉบับ:
ปลายเดือนมกราคม 2026 แอนเดรย์ คาร์พาธี ได้โพสต์ทวีตชุดหนึ่ง บ่นเกี่ยวกับวิธีการเขียนโค้ดของ Claude เขาชี้ให้เห็นปัญหาสามประเภทที่พบบ่อย: การสมมติข้อผิดพลาดโดยไม่ได้ระบุไว้ การซับซ้อนเกินจำเป็น และการก่อให้เกิดความเสียหายที่ไม่เกี่ยวข้องกับโค้ดที่ไม่ควรเปลี่ยนแปลง
ฟอร์เรสต์ ชาง เห็นทวีตชุดนี้ จึงจัดระเบียบข้อร้องเรียนเป็นกฎพฤติกรรม 4 ข้อ แล้วบันทึกไว้ในไฟล์ CLAUDE.md แยกต่างหาก และเผยแพร่บน GitHub โปรเจกต์นี้ได้รับ Star 5,828 รายการในวันแรก ถูกบันทึกไว้ 60,000 ครั้งภายในสองสัปดาห์ และปัจจุบันมี Star 120,000 รายการ กลายเป็นที่เก็บโค้ดไฟล์เดียวที่เติบโตเร็วที่สุดในปี 2026
จากนั้น ผมได้ทดสอบมันด้วยรหัสฐานข้อมูล 30 ชุดภายในเวลา 6 สัปดาห์
กฎทั้ง 4 ข้อนี้ใช้งานได้จริง ข้อผิดพลาดที่เคยเกิดขึ้นประมาณ 40% ในงานที่เหมาะสมกับกฎเหล่านี้ ลดลงเหลือต่ำกว่า 3% แต่ปัญหาคือเทมเพลตนี้ถูกสร้างขึ้นเพื่อแก้ไขข้อผิดพลาดที่ Claude เกิดขึ้นขณะเขียนโค้ดในเดือนมกราคม
ในเดือนพฤษภาคม 2026 ปัญหาที่เผชิญในระบบนิเวศ Claude Code ได้เปลี่ยนไปแล้ว: ตัวแทนขัดแย้งกันเอง การกระตุ้นแบบห่วงโซ่ของ hook ความขัดแย้งในการโหลดทักษะ และการหยุดชะงักของกระบวนการทำงานหลายขั้นตอนข้ามเซสชัน
ดังนั้น ฉันจึงเพิ่มกฎอีก 8 ข้อ ด้านล่างนี้คือเวอร์ชันเต็ม 12 ข้อของ CLAUDE.md: เหตุผลที่แต่ละข้อควรเพิ่ม และจุดที่เทมเพลตของ Karpathy เวอร์ชันเดิมจะล้มเหลวโดยไม่ได้ตั้งใจใน 4 จุด
หากคุณต้องการข้ามคำอธิบายและคัดลอกใช้งานทันที ไฟล์เต็มอยู่ที่ท้ายข้อความ
ทำไมสิ่งนี้จึงสำคัญ
CLAUDE.md ของ Claude Code เป็นไฟล์ที่ถูกมองข้ามมากที่สุดในสแต็กเทคโนโลยีการเขียนโปรแกรมด้วย AI นักพัฒนาส่วนใหญ่มักจะผิดพลาดสามประเภทหลัก:
ประการแรก ให้ถือมันเป็นถังขยะที่ชอบ แล้วใส่พฤติกรรมทั้งหมดของคุณลงไป จนขยายตัวเป็นมากกว่า 4,000 token และอัตราการปฏิบัติตามกฎลดลงเหลือ 30%
ที่สอง ไม่ใช้เลยและต้องระบุคำสั่งใหม่ทุกครั้ง ซึ่งจะทำให้สูญเปล่า token ถึง 5 เท่า และขาดความสอดคล้องระหว่างเซสชันต่างๆ
ثالثly หลังจากคัดลอกเทมเพลตแล้วก็ปล่อยไว้โดยไม่สนใจอีก มันอาจใช้งานได้สองสัปดาห์ แต่เมื่อโค้ดเบสเปลี่ยนแปลง มันจะล้มเหลวโดยที่คุณไม่รู้ตัว
เอกสารอย่างเป็นทางการของ Anthropic ระบุชัดเจนว่า CLAUDE.md เป็นเพียงข้อเสนอแนะเท่านั้น Claude จะปฏิบัติตามประมาณ 80% ของเวลา เมื่อเกิน 200 บรรทัด อัตราการปฏิบัติตามจะลดลงอย่างชัดเจน เนื่องจากกฎที่สำคัญจะถูกกลบด้วยสัญญาณรบกวน
เทมเพลตของ Karpathy แก้ปัญหานี้ได้: หนึ่งไฟล์ 65 บรรทัด 4 กฎ เป็นเกณฑ์ขั้นต่ำ
แต่ขีดจำกัดสามารถสูงกว่านี้ได้อีก หลังจากเพิ่มกฎอีก 8 ข้อด้านล่าง ระบบจะครอบคลุมไม่เพียงแค่ปัญหาการเขียนโค้ดที่ Karpathy บ่นเมื่อเดือนมกราคม 2026 แต่ยังรวมถึงปัญหาการจัดการ Agent ที่เพิ่งปรากฏในเดือนพฤษภาคม 2026 ซึ่งยังไม่มีอยู่เมื่อเทมเพลตต้นฉบับถูกเขียนขึ้น
กฎเดิม 4 ข้อ
หากคุณยังไม่ได้ดูรีพอสิทอรีของ Forrest Chang ให้ดูเวอร์ชันพื้นฐานนี้ก่อน:
กฎ 1: คิดก่อนเข้ารหัส
อย่าสมมติโดยไม่พูดออกมาระบุสมมติฐานของคุณและเปิดเผยจุดที่ต้องแลกเปลี่ยน ถามก่อนเดา เมื่อมีวิธีที่ง่ายกว่า ให้เสนอความเห็นต่อต้าน
กฎที่ 2: ความเรียบง่ายเป็นหลัก
ใช้โค้ดให้น้อยที่สุดเท่าที่จะแก้ปัญหาได้ อย่าเพิ่มฟีเจอร์ที่จินตนาการขึ้นมา อย่าออกแบบชั้นการดูดซับสำหรับโค้ดที่ใช้ครั้งเดียว หากวิศวกรผู้เชี่ยวชาญคิดว่ามันซับซ้อนเกินไป ควรทำให้เรียบง่ายลง
กฎที่ 3: การแก้ไขอย่างแม่นยำเหมือนการผ่าตัด
เปลี่ยนเฉพาะส่วนที่ต้องเปลี่ยนเท่านั้น อย่าปรับปรุงโค้ด คำอธิบาย หรือรูปแบบที่อยู่ติดกันโดยไม่จำเป็น อย่ารีแฟกเตอร์สิ่งที่ไม่เสียหาย รักษาสไตล์เดียวกับที่มีอยู่
ข้อกำหนดที่ 4: ดำเนินการให้บรรลุเป้าหมาย
กำหนดมาตรฐานความสำเร็จก่อน แล้ววนซ้ำอย่างต่อเนื่องจนกว่าจะผ่านการตรวจสอบ อย่าบอก Claude ว่าควรทำขั้นตอนใดในแต่ละขั้น แต่ให้บอกผลลัพธ์ที่ควรเป็น แล้วให้มันวนซ้ำด้วยตัวเอง
กฎ 4 ข้อนี้สามารถแก้ไขรูปแบบความล้มเหลวประมาณ 40% ที่ฉันเห็นในการสนทนา Claude Code โดยไม่มีการควบคุม ปัญหาที่เหลืออีกประมาณ 60% ซ่อนอยู่ในช่องว่างเหล่านี้
ฉันเพิ่มกฎทั้งหมด 8 ข้อ และเหตุผล
แต่ละกฎมาจากการใช้งานจริง: กฎ 4 ข้อเดิมของ Karpathy ไม่เพียงพออีกต่อไป ด้านล่างนี้ฉันจะอธิบายบริบทก่อน แล้วจึงให้กฎที่เกี่ยวข้อง
กฎที่ 5: อย่าให้โมเดลทำงานที่ไม่ใช่ด้านภาษา
กฎของ Karpathy ไม่ได้ครอบคลุมจุดนี้ ดังนั้นโมเดลจึงเริ่มตัดสินใจเรื่องที่ควรจะถูกจัดการโดยโค้ดที่มีความแน่นอน: ว่าจะลองเรียก API อีกครั้งหรือไม่ วิธีการส่งข้อความ และเมื่อใดควรอัปเกรดการประมวลผล ผลลัพธ์คือ การตัดสินใจแต่ละสัปดาห์ไม่เหมือนกัน คุณได้รับ if-else ที่ไม่มั่นคง ซึ่งคิดค่าบริการที่ 0.003 ดอลลาร์ต่อโทเค็น
เวลานั้นเป็นเช่นนี้: มีรหัสหนึ่งที่เรียก Claude เพื่อ “ตัดสินว่าควรลองใหม่เมื่อเจอ 503 หรือไม่” มันทำงานได้ดีในช่วงแรกและดำเนินไปสองสัปดาห์ แต่ต่อมาได้กลายเป็นไม่เสถียรทันที เพราะโมเดลเริ่มใช้เนื้อหาคำขอเป็นบริบทในการตัดสินใจ กลยุทธ์การลองใหม่จึงกลายเป็นแบบสุ่ม เพราะ prompt เองก็สุ่มเช่นกัน
กฎที่ 6: ตั้งงบประมาณ token แบบตายตัว ไม่มีข้อยกเว้น
CLAUDE.md ที่ไม่มีข้อจำกัดด้านงบประมาณ เท่ากับเช็คเปล่า ทุกครั้งที่วนลูปอาจสูญเสียการควบคุมและกลายเป็นการเทข้อมูลบริบท 50,000 โทเค็น โมเดลจะไม่หยุดตัวเอง
ช่วงเวลานั้นเป็นเช่นนี้: เซสชันการดีบักใช้เวลา 90 นาที โมเดลได้วนซ้ำกับข้อความข้อผิดพลาดขนาด 8KB เดิมอยู่เรื่อยๆ และค่อยๆ ลืมว่าได้ลองแก้ไขอะไรไปบ้างแล้ว สุดท้าย มันเริ่มเสนอวิธีแก้ไขที่ฉันปฏิเสธไปแล้วเมื่อ 40 ข้อความก่อนหน้า หากมีงบประมาณ token กระบวนการนี้ควรถูกหยุดที่นาทีที่ 12
กฎที่ 7: เปิดเผยความขัดแย้ง อย่าลดความรุนแรงลง
เมื่อส่วนสองส่วนในรหัสฐานข้อมูลขัดแย้งกัน Claude จะพยายามทำให้ทั้งสองฝ่ายพึงพอใจ ผลลัพธ์คือรหัสที่ไม่เชื่อมโยงกัน
เวลานั้นเป็นเช่นนี้: มีรูปแบบการจัดการข้อผิดพลาดสองแบบอยู่ในโค้ดเบส แบบหนึ่งคือ async/await พร้อม try/catch แบบชัดเจน อีกแบบคือ global error boundary Claude เขียนโค้ดใหม่โดยใช้ทั้งสองแบบ ทำให้การจัดการข้อผิดพลาดถูกดำเนินการสองครั้ง ฉันใช้เวลา 30 นาทีจึงเข้าใจว่าทำไมข้อผิดพลาดถึงถูกกลืนไปสองครั้ง
กฎที่ 8: อ่านก่อน แล้วค่อยเขียน
การแก้ไขแบบ “ศัลยกรรม” ของ Karpathy บอกให้ Claude ไม่ต้องเปลี่ยนโค้ดที่อยู่ติดกัน แต่ไม่ได้บอกให้ Claude เข้าใจโค้ดที่อยู่ติดกันก่อน ถ้าไม่มีข้อกำหนดนี้ Claude จะเขียนโค้ดใหม่ที่ขัดแย้งกับโค้ดที่มีอยู่แล้วห่างออกไป 30 บรรทัด
เวลานั้นเป็นเช่นนี้: Claude เพิ่มฟังก์ชันใหม่ที่มีฟังก์ชันเดียวกันอยู่ข้างๆ ฟังก์ชันเดิม เพราะไม่ได้อ่านฟังก์ชันเดิมมาก่อน ฟังก์ชันทั้งสองทำสิ่งเดียวกัน แต่เนื่องจากลำดับการ import ฟังก์ชันใหม่จึงทับฟังก์ชันเดิม ขณะที่ฟังก์ชันเดิมได้เป็นมาตรฐานเดียวที่ใช้จริงมาเป็นเวลา 6 เดือน
ข้อกำหนดที่ 9: การทดสอบไม่ใช่ตัวเลือก แต่การทดสอบเองก็ไม่ใช่เป้าหมาย
การดำเนินการตามเป้าหมายของ Karpathy บ่งชี้ว่าการทดสอบสามารถใช้เป็นมาตรฐานความสำเร็จได้ แต่ในทางปฏิบัติ Claude จะมองว่า “การทดสอบผ่าน” เป็นเป้าหมายเดียว จึงเขียนโค้ดที่ผ่านการทดสอบแบบผิวเผินแต่ทำลายสิ่งอื่นๆ
เวลานั้นเป็นเช่นนี้: Claude เขียนการทดสอบ 12 รายการสำหรับฟังก์ชันการตรวจสอบสิทธิ์ ซึ่งทั้งหมดผ่านการทดสอบ แต่ตรรกะการตรวจสอบสิทธิ์ในสภาพแวดล้อมการผลิตกลับพัง คำทดสอบเหล่านั้นแค่ตรวจสอบว่าฟังก์ชัน “ส่งคืนบางอย่าง” ไม่ใช่ตรวจสอบว่าส่งคืนสิ่งที่ถูกต้องหรือไม่ ฟังก์ชันผ่านการทดสอบเพราะมันส่งค่าคงที่กลับมา
กฎที่ 10: การดำเนินการที่ใช้เวลานานต้องมีจุดตรวจสอบ
เทมเพลตของ Karpathy ตั้งค่าการโต้ตอบแบบครั้งเดียวเท่านั้น แต่การทำงานจริงของ Claude Code มักเป็นขั้นตอนหลายขั้นตอน: การรีแฟกเตอร์ข้ามไฟล์ 20 ไฟล์ การสร้างฟีเจอร์ภายในเซสชันเดียว และการดีบักข้าม commit หลายครั้ง หากไม่มีจุดตรวจสอบ ความผิดพลาดเพียงขั้นตอนเดียวอาจทำให้ความคืบหน้าทั้งหมดสูญหาย
เวลานั้นเป็นเช่นนี้: งานรีแฟกเตอร์ 6 ขั้นตอนเกิดข้อผิดพลาดที่ขั้นตอนที่ 4 เมื่อฉันพบข้อผิดพลาด คลอดได้ดำเนินการขั้นตอนที่ 5 และ 6 ต่อไปบนสถานะที่ผิดพลาดแล้ว เวลาที่ใช้ในการวิเคราะห์และแก้ไขนานกว่าการเริ่มต้นใหม่ทั้งหมด หากมีจุดตรวจสอบ ข้อผิดพลาดที่ขั้นตอนที่ 4 จะถูกตรวจพบทันที
ข้อกำหนดที่ 11: สัญญาต้องมีลำดับความสำคัญเหนือความคิดใหม่
ในรหัสฐานที่มีรูปแบบที่สุกงอมอยู่แล้ว Claude ชอบนำรูปแบบการเขียนของตัวเองมาใช้ แม้ว่ารูปแบบของมันจะ “ดีกว่า” การนำรูปแบบที่สองมาใช้ก็ยังแย่กว่าการใช้รูปแบบเดียวใดๆ
เวลานั้นเป็นเช่นนี้: Claude ได้นำ hooks เข้ามาในโค้ดเบส React ที่ใช้ class component มันทำงานได้จริง แต่มันทำลายรูปแบบการทดสอบเดิมของโค้ดเบส เพราะการทดสอบเหล่านั้นพึ่งพา componentDidMount สุดท้ายต้องใช้เวลาครึ่งวันในการลบและเขียนใหม่
กฎที่ 12: ต้องล้มเหลวอย่างชัดเจน อย่าล้มเหลวแบบเงียบ
ความล้มเหลวที่แพงที่สุดของ Claude มักเป็นความล้มเหลวที่ดูเหมือนความสำเร็จ ฟังก์ชันหนึ่ง「ทำงานได้」แต่ส่งข้อมูลผิดพลาด; การอัปเดตข้อมูล「เสร็จสมบูรณ์」แต่ข้ามบันทึก 30 รายการ; การทดสอบ「ผ่าน」แต่แค่เพราะคำสั่งตรวจสอบนั้นผิด
เวลานั้นเป็นเช่นนี้: Claude กล่าวว่าการย้ายฐานข้อมูล “เสร็จสมบูรณ์แล้ว” แต่ในความเป็นจริง มันข้ามบันทึก 14% ที่มีการขัดแย้งกับข้อจำกัดการกระตุ้นโดยเงียบ พฤติกรรมการข้ามถูกบันทึกไว้ในล็อก แต่ไม่ได้ถูกเปิดเผยอย่างชัดเจน 11 วันต่อมา เมื่อข้อมูลรายงานเริ่มผิดปกติ เราจึงค้นพบปัญหา
ผลลัพธ์ข้อมูล
ฉันติดตามชุดงานตัวแทน 50 งานเดียวกันเป็นเวลา 6 สัปดาห์ ครอบคลุม 30 รีโพสิทอรี และทดสอบการตั้งค่าสามแบบ
อัตราความผิดพลาดหมายถึง: งานต้องได้รับการแก้ไขหรือเขียนใหม่เพื่อให้สอดคล้องกับเจตนาเดิม ข้อผิดพลาดที่นับรวมได้แก่: สมมติฐานผิดโดยไม่แจ้ง, การออกแบบซับซ้อนเกินไป, การทำลายที่ไม่เกี่ยวข้อง, ความล้มเหลวโดยไม่แจ้ง, การละเมิดข้อตกลง, ข้อตกลงที่ขัดแย้งกัน, และการละเลยจุดตรวจสอบ
อัตราการปฏิบัติตามหมายถึง: เมื่อกฎใดกฎหนึ่งมีผลใช้บังคับ Claude จะมีความน่าจะเป็นเท่าใดในการใช้กฎนั้นอย่างชัดเจน
ผลที่น่าสนใจจริงๆ ไม่ได้อยู่ที่อัตราความผิดพลาดลดลงจาก 41% เป็น 3% เท่านั้น แต่สำคัญกว่านั้นคือ การขยายจาก 4 กฎเป็น 12 กฎ แทบไม่ได้เพิ่มภาระในการปฏิบัติตาม โดยอัตราการปฏิบัติตามลดลงเพียงเล็กน้อยจาก 78% เป็น 76% แต่อัตราความผิดพลาดกลับลดลงอีก 8 เปอร์เซ็นต์ กฎใหม่เหล่านี้ครอบคลุมรูปแบบความล้มเหลวที่กฎ 4 ข้อเดิมไม่ได้จัดการ และไม่ได้แข่งขันกันในงบประมาณความสนใจเดียวกัน
Karpathy template จะล้มเหลวโดยไม่แจ้งให้ทราบในที่ใดบ้าง
แม้ไม่เพิ่มกฎใหม่ แม่แบบกฎเดิม 4 ข้อก็ยังไม่เพียงพออย่างน้อย 4 จุด
ประการแรก งาน Agent ที่รันเป็นเวลานาน
กฎของ Karpathy มุ่งเน้นไปที่ช่วงเวลาที่ Claude กำลังเขียนโค้ด แต่เกิดอะไรขึ้นเมื่อ Claude กำลังรัน pipeline หลายขั้นตอน? แม่แบบเดิมไม่มีกฎด้านงบประมาณ ไม่มีกฎด้านจุดตรวจสอบ และไม่มีกฎการล้มเหลวแบบเสียงดัง ดังนั้น pipeline จึงค่อยๆ เบี่ยงเบนไป
ที่สอง ความสอดคล้องของหลายรหัสฐาน
“จับคู่กับรูปแบบที่มีอยู่” โดยค่าเริ่มต้นมีเพียงรูปแบบเดียว แต่ใน monorepo ที่มีบริการ 12 รายการ Claude ต้องเลือกว่าจะจับคู่กับรูปแบบใด กฎเดิมไม่ได้บอกวิธีการเลือก ดังนั้นมันจึงอาจเลือกแบบสุ่มหรือผสมรูปแบบต่างๆ เข้าด้วยกันอย่างเท่าเทียม
Third, test quality.
การดำเนินการตามเป้าหมายจะถือว่า “ผ่านการทดสอบ” เป็นความสำเร็จ แต่ไม่ได้ระบุว่าการทดสอบเองต้องมีความหมาย ผลลัพธ์คือ Claude เขียนการทดสอบที่แทบไม่ได้ตรวจสอบอะไรเลย แต่การทดสอบเหล่านี้ทำให้มันเข้าใจผิดว่าตัวเองมั่นใจมาก
ประการที่สี่ ความแตกต่างระหว่างสภาพแวดล้อมการผลิตกับระยะต้นแบบ
กฎเดียวกัน 4 ข้อสามารถป้องกันไม่ให้โค้ดการผลิตถูกออกแบบซับซ้อนเกินไป แต่ก็อาจทำให้การพัฒนาต้นแบบช้าลง เนื่องจากในขั้นตอนต้นแบบ บางครั้งจำเป็นต้องใช้สคริปต์ทดลอง 100 บรรทัดเพื่อค้นหาทิศทางก่อน การเน้นความเรียบง่ายของ Karpathy อาจถูกกระตุ้นเกินไปในโค้ดระยะเริ่มต้น
กฎทั้ง 8 ข้อนี้ไม่ได้มีจุดประสงค์เพื่อแทนที่กฎเดิม 4 ข้อของ Karpathy แต่เป็นการเติมเต็มช่องว่างของกฎเหล่านั้น: แม่แบบเดิมถูกออกแบบมาสำหรับสถานการณ์การเขียนโค้ดแบบอัตโนมัติเติมเต็มในเดือนมกราคม 2026; แต่ในเดือนพฤษภาคม 2026 Claude Code ได้ก้าวเข้าสู่สภาพแวดล้อมที่ขับเคลื่อนโดยเอเจนต์ ซึ่งมีหลายขั้นตอนและการร่วมมือระหว่างหลายรหัสฐานข้อมูล ทั้งสองสถานการณ์จึงเผชิญกับปัญหาที่ต่างกัน
วิธีใดที่ไม่ได้ผล
ก่อนที่จะสรุปกฎทั้ง 12 ข้อนี้ ฉันยังได้ลองแนวทางอื่นๆ อีกหลายแบบ
เพิ่มกฎที่ฉันเห็นบน Reddit / X
ส่วนใหญ่ในนั้น ต่างก็แค่ซ้ำกฎ 4 ข้อเดิมของ Karpathy ด้วยถ้อยคำที่ต่างกัน หรือเป็นกฎเฉพาะโดเมนที่ไม่สามารถประยุกต์ใช้ได้ทั่วไป เช่น “ใช้ Tailwind class เสมอ” สุดท้ายจึงถูกลบออก
มากกว่า 12 ข้อกำหนด
ฉันทดสอบสูงสุดถึง 18 ข้อ หลังจากเกิน 14 ข้อ อัตราการปฏิบัติตามลดลงจาก 76% เหลือ 52% ขีดจำกัดที่ 200 บรรทัดเป็นเรื่องจริง หลังจากเกินความยาวนี้ Claude จะเริ่มจับรูปแบบว่า “ที่นี่มีกฎ” แทนที่จะอ่านกฎทีละข้ออย่างแท้จริง
กฎที่ขึ้นอยู่กับเครื่องมือบางอย่าง
ตัวอย่างเช่น “ใช้ eslint เสมอ” หากในโปรเจกต์ไม่มีการติดตั้ง eslint กฎนี้จะไม่ทำงาน และจะล้มเหลวโดยไม่มีการแจ้งเตือน ต่อมาฉันได้เปลี่ยนเป็นการใช้ถ้อยคำที่ไม่พึ่งพาเครื่องมือเฉพาะ เช่น เปลี่ยนจาก “ใช้ eslint” เป็น “ปฏิบัติตามรูปแบบที่บังคับใช้อยู่ในโค้ดเบส”
แสดงตัวอย่างใน CLAUDE.md แทนที่กฎ
ตัวอย่างมีน้ำหนักในบริบทมากกว่ากฎ ตัวอย่างสามข้อใช้บริบทประมาณเท่ากับกฎ 10 ข้อ และ Claude มักจะปรับตัวมากเกินไปกับตัวอย่าง กฎเป็นนามธรรม ตัวอย่างเป็นรูปธรรม ดังนั้นควรใช้กฎ
ระวังให้ดี คิดอย่างรอบคอบ และมุ่งมั่นมากขึ้น
เหล่านี้ล้วนเป็นเสียงรบกวน อัตราการปฏิบัติตามคำสั่งประเภทนี้ลดลงเหลือประมาณ 30% เพราะไม่สามารถตรวจสอบได้ ต่อมาฉันจึงแทนที่พวกมันด้วยกฎเชิงสั่งการที่เฉพาะเจาะจงมากขึ้น เช่น “ระบุสมมติฐานอย่างชัดเจน”
บอกให้ Claude ทำตัวเหมือนวิศวกรผู้เชี่ยวชาญ
สิ่งนี้ไม่มีประโยชน์ Claude ตั้งแต่แรกก็รู้สึกเหมือนว่าตัวเองเป็นวิศวกรผู้เชี่ยวชาญ ปัญหาที่แท้จริงไม่ได้อยู่ที่มันคิดแบบนั้นหรือไม่ แต่อยู่ที่มันปฏิบัติตามแบบนั้นหรือไม่ กฎแบบสั่งการสามารถลดช่องว่างนี้ได้ แต่การระบุตัวตนไม่สามารถทำได้
เวอร์ชันเต็ม 12 ข้อกฎของ CLAUDE.md
นี่คือเวอร์ชันเต็มที่สามารถคัดลอกและวางได้ทันที
ไม่สามารถแสดงเนื้อหานี้นอกเอกสาร Feishu ได้ชั่วคราว
บันทึกเป็นไฟล์ CLAUDE.md ที่รากของรีพอสิทอรี ด้านล่างกฎ 12 ข้อข้างต้น ให้เพิ่มกฎเฉพาะโครงการ เช่น เทคโนโลยีสแต็ก คำสั่งทดสอบ รูปแบบข้อผิดพลาด เป็นต้น รวมทั้งหมดไม่เกิน 200 บรรทัด หากเกินกว่านั้น อัตราการปฏิบัติตามกฎจะลดลงอย่างชัดเจน
วิธีการติดตั้ง
เพียงสองขั้นตอน:
1. เพิ่มกฎพื้นฐาน 4 ข้อของ Karpathy ลงในไฟล์ CLAUDE.md ของคุณ
curl https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md >> CLAUDE.md
2. วางกฎข้อ 5–12 จากบทความนี้ลงด้านล่าง
บันทึกไฟล์ไว้ที่รากของรีโพสิทอรี >> นั้นสำคัญมาก เพราะมันมีหน้าที่เพิ่มข้อมูลลงใน CLAUDE.md ที่มีอยู่แล้ว ไม่ใช่เขียนทับกฎเฉพาะโปรเจกต์ที่คุณเขียนไว้แล้ว
mental model
CLAUDE.md ไม่ใช่รายการความปรารถนา แต่เป็นสัญญาพฤติกรรมที่ใช้ปิดกั้นรูปแบบความล้มเหลวที่คุณได้สังเกตเห็นแล้ว
แต่ละกฎควรตอบคำถาม: มันป้องกันข้อผิดพลาดอะไร?
กฎ 4 ข้อของ Karpathy ป้องกันรูปแบบความล้มเหลวที่เขาเห็นในเดือนมกราคม 2026: สมมติฐานแบบเงียบ, การออกแบบเกินความจำเป็น, การทำลายที่ไม่เกี่ยวข้อง, และมาตรฐานความสำเร็จที่อ่อนแอ これらเป็นพื้นฐาน อย่าข้าม
กฎทั้ง 8 ข้อที่ฉันเพิ่มเติมมีจุดประสงค์เพื่อป้องกันรูปแบบความล้มเหลวใหม่ที่จะเกิดขึ้นหลังเดือนพฤษภาคม 2026: วงจรตัวแทนที่ไม่มีข้อจำกัดด้านงบประมาณ งานหลายขั้นตอนที่ไม่มีจุดตรวจสอบ การทดสอบที่ดูเหมือนว่าได้ทดสอบแล้วแต่แท้จริงไม่ได้ทดสอบตรรกะสำคัญ และการปิดบังความล้มเหลวแบบเงียบให้ดูเหมือนความสำเร็จแบบเงียบ これらเป็นการอัปเดตแบบค่อยเป็นค่อยไป
แน่นอน ผลลัพธ์ที่ได้อาจแตกต่างกันไปตามบุคคล หากคุณไม่ได้ใช้ pipeline หลายขั้นตอน กฎข้อ 10 ก็จะไม่สำคัญเท่าไรนัก หากโค้ดเบสของคุณมีรูปแบบเดียวเดียวเท่านั้น และถูกบังคับใช้โดย lint อยู่แล้ว กฎข้อ 11 ก็จะซ้ำซ้อน หลังจากอ่านกฎทั้ง 12 ข้อนี้แล้ว ให้เก็บกฎที่สอดคล้องกับข้อผิดพลาดที่คุณเคยทำจริง และลบส่วนที่เหลือออก
เวอร์ชัน CLAUDE.md ที่มี 6 กฎที่ปรับให้เหมาะกับรูปแบบความล้มเหลวจริง ดีกว่าเวอร์ชันที่มี 12 กฎ โดยที่ 6 กฎคุณจะไม่ได้ใช้เลย
ข้อสรุป
ทวีตของ Karpathy ในเดือนมกราคม 2026 本质上เป็นการบ่นอย่างหนึ่ง Forrest Chang ได้แปลงมันเป็น 4 ข้อกฎ สุดท้าย นักพัฒนา 120,000 คนได้ให้ Star กับผลลัพธ์นี้ แต่ส่วนใหญ่ในจำนวนนั้น วันนี้ยังคงใช้เพียง 4 ข้อกฎเท่านั้น
โมเดลได้ก้าวหน้าไปแล้ว และระบบนิเวศก็เปลี่ยนไปแล้ว เช่น Agent หลายขั้นตอน การกระตุ้นแบบเชื่อมโยงด้วย hook การโหลดทักษะ และการทำงานร่วมกันของหลายคลังรหัส—สิ่งเหล่านี้ยังไม่มีอยู่เมื่อ Karpathy เขียนทวีตนั้น กฎเดิม 4 ข้อไม่ได้แก้ปัญหาเหล่านี้ ไม่ใช่ว่าผิด แต่ไม่สมบูรณ์
เพิ่มกฎใหม่ 8 ข้อ ทดสอบใน 30 รีโพสิทอรีภายในเวลา 6 สัปดาห์ อัตราความผิดพลาดลดลงจาก 41% เหลือ 3%
บันทึกบทความนี้ไว้สำหรับคืนนี้ คัดลอกกฎ 12 ข้อนี้ลงในไฟล์ CLAUDE.md ของคุณ หากมันช่วยให้คุณประหยัดเวลาหนึ่งสัปดาห์ในการเรียนรู้ Claude โปรดแชร์ต่อ