4 月 13 日 abmedia เคยรายงานว่า Forrest Chang ได้เอาการบ่นของ Karpathy ในเดือนมกราคมที่เขียนขึ้นกับ Claude มาเรียบเรียงเป็น “กฎ CLAUDE.md 4 ข้อ” โดยในตอนนั้นมีสะสม 15,000 สตาร์บน GitHub และต่อมาในวันที่ 5 月 12 จำนวนสตาร์ของ repo นั้นก็ทะลุ 126,000 แล้ว ภายในไม่ถึง 1 เดือนเติบโตถึง 8 เท่า ชุมชนจึงตามมาด้วย “เวอร์ชันขยาย” จำนวนมาก ซึ่งในนั้นวิศวกร Mnilax (@Mnimiy) ได้โพสต์เมื่อวันที่ 5 月 9 เรื่อง “เพิ่มอีก 8 ข้อบนพื้นฐาน 4 ข้อ รวมเป็นฉบับเต็ม 12 ข้อ” โดยโพสต์ดังกล่าวได้รับไลก์ 5,968 ครั้ง และเป็นหนึ่งในคอนเทนต์เดี่ยวที่ถูกพูดถึงมากที่สุดในช่วงนี้ของชุมชน Claude Code
การทบทวนกฎ 4 ข้อ: Forrest Chang แปลงคำบ่นของ Karpathy ให้กลายเป็นเทมเพลตที่นำไปใช้ได้
Forrest Chang แก่นกฎเดิม 4 ข้อ (แต่ละข้อสอดคล้องกับ “รูปแบบความล้มเหลว” ที่ Karpathy เอ่ยถึงบน X ในเดือนมกราคม):
Think Before Coding（คิดก่อนเขียน）：อย่าทำสมมติฐานโดยนัย ต้องพูดให้ชัดว่า “สมมติอยู่บนพื้นฐานอะไร” เผื่อให้มองเห็น trade-off ให้ถกกัน ไม่แน่ใจก็ถามตรงๆ อย่าคาดเดา ถ้ามีวิธีที่ง่ายกว่าให้คัดค้านแนวทางที่ซับซ้อน
Simplicity First（เริ่มจากความเรียบง่าย）：เขียนโค้ดที่ “น้อยที่สุด” เพื่อแก้ปัญหา ไม่เขียนฟังก์ชันเชิงคาดเดา ไม่สร้างเลเยอร์นามธรรมให้โค้ดที่เป็นงานครั้งเดียว วิศวกรอาวุโสจะบอกว่าถ้าออกแบบซับซ้อนเกินไปต้องทำให้เรียบง่ายลง
Surgical Changes（แก้แบบผ่าตัด）：แก้แค่ส่วนที่ควรแก้ ห้าม “ปรับปรุงข้างเคียงไปด้วย” เช่น โค้ดที่อยู่ใกล้ๆ คอมเมนต์ หรือฟอร์แมต อย่ารีแฟกเตอร์สิ่งที่ยังไม่พัง ต้องสอดคล้องกับสไตล์ที่มีอยู่
Goal-Driven Execution（ลงมือให้ขับเคลื่อนด้วยเป้าหมาย）：กำหนดมาตรฐานความสำเร็จ แล้ววนทำจนตรวจสอบได้ อย่าบอก Claude เป็นขั้นตอน แต่บอกว่า “ความสำเร็จหน้าตาเป็นแบบไหน” ให้มันวนทำเอง
เอกสารทางการของ Anthropic ระบุชัดเจนจริงๆ ว่า CLAUDE.md เป็นไฟล์ “เชิงคำแนะนำ” (advisory) และ Claude จะปฏิบัติตามประมาณ 80% เมื่อจำนวนเกิน 200 บรรทัด อัตราการปฏิบัติตามจะลดฮวบ เพราะกฎสำคัญถูกกลบด้วยเสียงรบกวน Forrest Chang จึงย่อกฎให้เหลือ 65 บรรทัด 4 ข้อ เพื่อไปถึง “floor” (เกณฑ์ขั้นต่ำ)
Mnilax เติมอีก 8 ข้อ: เติมรูปแบบความล้มเหลวใหม่ยุค agent ใน 2026/5
Mnilax โต้แย้งว่า คำบ่นของ Karpathy ในเดือนมกราคมเน้นอยู่ที่ “บริบทการเขียนโค้ดด้วย Claude” แต่ในเดือนพฤษภาคมระบบนิเวศ Claude Code ได้พัฒนาไปสู่การทำงานร่วมกันหลาย agent, การเชื่อม hook, ความขัดแย้งในการโหลด skill, เวิร์กโฟลว์หลายขั้นที่ข้าม session ฯลฯ ซึ่งต้องมีการเติมกฎ เขาเพิ่ม 8 ข้อนี้ (จัดตามลำดับในต้นฉบับ):
Rule 5：ใช้ Claude เฉพาะงานที่ต้องใช้การตัดสินใจ (การจัดประเภท การร่าง การสรุป การสกัด) ส่วนการตัดสินใจแบบแน่นอน (เช่น รีเทรย์ 503, การทำ routing, การจัดการ status code, การแปลงแบบแน่นอน) ให้จัดการด้วยโค้ดทั่วไป
Rule 6：Token budget ไม่ใช่คำแนะนำ—กำหนดเป็นเพดานต่อ “งานเดี่ยว 4,000 tokens” และต่อ “session 30,000 tokens” เมื่อเริ่มเข้าใกล้ budget ต้องสรุปแล้วเริ่มใหม่อย่าง主动 อย่าให้หลุดเกินเงียบๆ
Rule 7：เมื่อมีแพตเทิร์นโค้ดที่ขัดกัน 2 แบบ ให้ “ระบุให้ชัดว่าเลือกอันไหน” (เลือกที่ใหม่กว่า หรือมีเทสต์มากกว่า) อธิบายว่าทำไมถึงเลือก และทำเครื่องหมายอีกอันว่า “รอการทำความสะอาด/แก้ทีหลัง” การผสมสองแพตเทิร์นคือทางเลือกที่แย่ที่สุด
Rule 8：ก่อนเขียนโค้ดต้องทำความเข้าใจให้ครบก่อน—อ่าน exports, เรียกโดยตรงที่ caller, ใช้ utility ที่ใช้ร่วมกัน คำพูดที่ว่า “ดูเหมือนไม่เกี่ยวกัน (looks orthogonal)” เป็นคำที่อันตรายที่สุด ถ้าไม่แน่ใจก็ต้องถาม
Rule 9：การทดสอบต้องยืนยัน “เจตนา” ไม่ใช่แค่ “พฤติกรรม”—ถ้าเขียนได้เฉพาะเทสต์ที่พิสูจน์ว่าพฤติกรรมปัจจุบันถูกต้องแต่ไม่ครอบคลุมว่า “เมื่อเปลี่ยนตรรกะทางธุรกิจแล้วจะล้มเหลว” ก็ยังไม่ถือว่าครบ หากไม่เช่นนั้นก็แค่ทำให้ Claude มั่นใจ แต่การปกป้องความถูกต้องจริงๆ เป็นศูนย์
Rule 10：งานหลายขั้นต้องมี checkpoint—หลังทำแต่ละขั้นให้สรุปว่า “ทำอะไร ไปทำการตรวจสอบอะไรแล้ว และเหลืออะไร” ถ้าอธิบายสถานะที่ทำได้ไม่ชัด ห้ามไปต่อ
Rule 11：ทำตามขนบของ codebase ที่มีอยู่ แม้คุณจะไม่เห็นด้วย—snake_case ก็ต้องเป็น snake_case, component แบบ class ก็ต้องเป็น class component ถ้าไม่เห็นด้วยให้ย้ายไปคุยกันอีกเวที อย่าแยกสายออกฝ่ายเดียว
Rule 12：ความล้มเหลวต้องประกาศดังๆ—“migration เสร็จแล้ว” ไม่ถูก ถ้าข้ามมา 30 รายการ, “ทดสอบผ่านแล้ว” ไม่ถูกถ้าข้ามเทสต์ไปแม้แต่รายการเดียว โดยค่าเริ่มต้น “ต้องเปิดเผยความไม่แน่ใจอย่างเชิงรุก” อย่า “ซ่อนความไม่แน่ใจ”
Mnilax อ้างว่าทดสอบกฎ 12 ข้อนี้ใน 30 codebase ภายใน 6 สัปดาห์ โดยอัตราข้อผิดพลาดลดจาก 41% เหลือ 3% และอัตราการปฏิบัติตามลดลงเพียงเล็กน้อย (78% → 76%) สื่อฉบับนี้สังเกต: ตัวเลขเหล่านี้เป็นผลการทดสอบที่ผู้เขียนระบุเอง และยังไม่ได้รับการยืนยันแบบอิสระ แต่เนื้อหาของ 8 ข้อเองมีความแน่น และสอดคล้องกับปัญหาที่พบในบริบทการใช้ Claude Code แบบหลายเอเจนต์ในปัจจุบัน (เช่น การจัดการหลาย session ของ Agent View, และ Multi-Agent Layer ในสถาปัตยกรรมระดับ 6 ชั้น)
สถานการณ์ที่ใช้ได้และคำแนะนำเชิงปฏิบัติ
Mnilax ก็ชี้ตรงๆ ว่าไม่ควรลองทำแบบไหนบ้าง:
กฎมากกว่า 14 ข้อ: อัตราการปฏิบัติตามตกเหลือ 52% (จาก 76% ตกหนัก), และมีเพดานเชิงปฏิบัติที่ 200 บรรทัด
ใช้ตัวอย่างแทนกฎ: ต้นทุน token ของตัวอย่าง 3 ชิ้นเท่ากับกฎ 10 ข้อ และ Claude มีแนวโน้มโอเวอร์ฟิตกับตัวอย่างเดียวนั้น
คำสั่งเชิงนามธรรม เช่น “Be careful / think hard / really focus”: ตรวจสอบได้ต่ำ อัตราการปฏิบัติตามอยู่ที่เพียง 30%
สั่งให้ Claude “เป็นวิศวกรอาวุโส”: identity prompt ไม่มีผลต่อการเปลี่ยนพฤติกรรม เพราะคำสั่งแบบกฎเกณฑ์ชัดเจนเท่านั้นที่ใช้ได้
พึ่งพาเครื่องมือเฉพาะ: “ใช้ eslint ตลอด” เมื่อไม่ได้ติดตั้ง eslint ระบบจะล้มเหลวแบบเงียบๆ ให้เปลี่ยนเป็นถ้อยคำที่เป็นกลางด้านความสามารถ เช่น “ทำให้สอดคล้องกับสไตล์ที่มีอยู่ใน codebase”
สื่อฉบับนี้แนะนำวิธีใช้เชิงปฏิบัติ: CLAUDE.md คือ “สัญญาพฤติกรรม (behavior contract)” ไม่ใช่ลิสต์ความหวัง—ทุกกฎต้องตอบว่า “กฎนี้ช่วยหลีกเลี่ยงความผิดพลาดเฉพาะเจาะจงอะไร” หากงานของคุณไม่ได้เกี่ยวกับ pipeline หลายขั้น Rule 10 (checkpoint) ก็แทบไม่เกี่ยว หาก codebase มี lint บังคับสไตล์เอกพจน์อยู่แล้ว Rule 11 (ทำตามแนวปฏิบัติ) ก็อาจเป็นเรื่องเกิน ต่อจากนั้นหลังอ่านครบ 12 ข้อ ให้เก็บเวอร์ชันที่ “ตรงกับกับดักที่คุณเจอจริง” ส่วนที่เหลือค่อยลบทิ้งได้
เหตุการณ์ที่ติดตามต่อได้ ได้แก่: Anthropic จะทำให้กฎของ CLAUDE.md เป็นมาตรฐานเชิงรูปแบบหรือไม่ (ตอนนี้เป็นเพียง “advisory”), repo ของ Forrest Chang จะเข้าสู่เทมเพลตที่ทางการแนะนำหรือไม่, ชุมชนจะเกิดเวอร์ชันปรับแต่งเฉพาะสายงาน (เช่น front-end / back-end / data engineering) หรือไม่ และเมื่อมีการอัปเดตเวอร์ชันของโมเดล Claude แล้วอัตราการปฏิบัติตามตามกฎจะเปลี่ยนไปหรือไม่
บทความนี้ Karpathy CLAUDE.md ทะลุ 126K สตาร์: สรุปกฎขั้นสูง 12 ข้อ เวอร์ชันชุมชน เผยแพร่ครั้งแรกใน 鏈新聞 ABMedia
