อธิบาย CLAUDE.md ของ Karpathy: ไฟล์เดียวที่อยู่เบื้องหลังการค้นหา Skills

บน Google Trends ทั่วโลก ในช่วงเจ็ดวันที่ผ่านมา และอ่านข้อมูลเมื่อวันที่ 23 ตุลาคม 2026 "karpathy skills" ปรากฏเป็นคำค้นที่กำลังมาแรงภายใต้คำค้นตั้งต้น "claude skills" ใครก็ตามที่ตามการค้นหานั้นจะไปลงเอยที่เดียวกัน: github.com/multica-ai/andrej-karpathy-skills ซึ่งเป็นรีโพซิทอรีที่แสดง 222,612 ดาวบน GitHub ณ วันที่อ่านข้อมูล 23 ตุลาคม 2026 คำอธิบายของมันไม่มีคำว่า skill เลยแม้แต่คำเดียว โดยระบุว่า: "A single CLAUDE.md file to improve Claude Code behavior, derived from Andrej Karpathy's observations on LLM coding pitfalls."

ช่องว่างระหว่างคำค้นกับออบเจ็กต์ไม่ใช่รายละเอียดทางเทคนิคเล็กน้อย สกิลกับไฟล์ CLAUDE.md เป็นกลไกที่ต่างกันซึ่งทำงานต่างกัน และเกือบทุกข้อกล่าวอ้างที่ผู้คนมีต่อที่เก็บโค้ดนี้ ล้วนขึ้นอยู่กับการรู้ว่ามันคือสิ่งไหน หรือไม่ก็แอบสมมติสิ่งที่ผิดไว้อย่างเงียบ ๆ คำแนะนำที่อยู่ข้างในนั้นเป็นไฟล์เดียว ที่เก็บโค้ดรอบ ๆ ไฟล์นั้นยังมีไฟล์ manifest ของปลั๊กอินและโฟลเดอร์ใต้ skills ซึ่งน่าจะเป็นที่มาของคำในช่องค้นหา การแยกส่วนบรรจุภัณฑ์ออกจากเนื้อหาจริงเป็นก้าวแรกที่มีประโยชน์ในที่นี้

ตัวเลขทั้งหมดมาจาก GitHub และอ่านเมื่อวันที่ 23 ตุลาคม 2026: ดาว 222,612 ดวง, ฟอร์ก 22,321 ครั้ง, สร้างเมื่อ 27 มกราคม 2026, พุชล่าสุดเมื่อ 20 เมษายน 2026, สัญญาอนุญาต MIT คู่สุดท้ายนั่นแหละที่น่าสนใจ รีโพซิทอรีนี้ไม่มีการพุชเลยเป็นเวลาประมาณหกเดือน และจำนวนดาวยังคงเพิ่มขึ้นเรื่อย ๆ อยู่ดี

ไฟล์เป็นตัวทำงาน ส่วนบรรจุภัณฑ์อธิบายคำค้นหา

เปิดรีโปซิทอรีขึ้นมา แล้วรายการไฟล์จะทำให้เห็นความไม่สอดคล้องได้ง่าย ที่รากมี CLAUDE.md และถัดจากนั้นมี CURSOR.md, EXAMPLES.md, โฟลเดอร์ .cursor/rules ที่เก็บแนวทางเดียวกันในรูปแบบกฎโปรเจกต์ของ Cursor, โฟลเดอร์ .claude-plugin และไดเรกทอรี skills/karpathy-guidelines ช่องทางติดตั้งที่ README แนะนำคือมาร์เก็ตเพลสปลั๊กอิน และอธิบายผลลัพธ์ว่าทำให้ "สกิลพร้อมใช้งานในทุกโปรเจกต์ของคุณ"

ดังนั้นคำค้นหาไม่ได้ผิดเสียทีเดียว แต่คลาดเคลื่อนมากกว่า มีโฟลเดอร์ skills อยู่ มีปลั๊กอินอยู่ สิ่งที่ไม่มีคือชุดสกิลแยกต่างหากที่แต่ละตัวทำงานต่างกัน ซึ่งเป็นรูปแบบที่คนมักหมายถึงเมื่อพูดถึง skill pack: โฟลเดอร์ที่เก็บ SKILL.md และไฟล์สนับสนุนใด ๆ ที่ความสามารถนั้นต้องใช้ เรียกใช้สำหรับงานหนึ่งงาน ในที่นี้คำแนะนำทั้งหมดเป็นเอกสารเดียวที่เป็นคำสั่งถาวร และปลั๊กอินมีอยู่เพื่อส่งเอกสารนั้นเข้าไปในโปรเจกต์

การที่ความแตกต่างนั้นจะสำคัญกับคุณหรือไม่ ขึ้นอยู่กับว่าคุณต้องการอะไรจากการค้นหา ถ้าคุณกำลังมองหากล่องเครื่องมือ สิ่งนี้ไม่ใช่กล่องเครื่องมือ แต่ถ้าคุณต้องการคู่มือกฎสั้น ๆ ที่เปลี่ยนพฤติกรรมของเอเจนต์เขียนโค้ดทั่วทั้งโปรเจกต์ นั่นคือสิ่งที่มันเป็น genau และคุ้มค่าที่จะเข้าใจว่าทำไมบางคนจึงเขียนมันเป็นไฟล์แทนที่จะเป็นสกิล

ข้อร้องเรียนที่มันถูกเขียนขึ้นมาเพื่อต่อต้าน

แหล่งที่มาที่ README ระบุไว้คือโพสต์ของ Andrej Karpathy บน X ซึ่ง README อ้างคำพูดมาเพื่อแสดงข้อร้องเรียนสามข้อเกี่ยวกับวิธีที่โมเดลเขียนโค้ด ข้อร้องเรียนเหล่านั้นคุ้มค่าที่จะอ่านให้ครบถ้วน เพราะหลักการทั้งสี่ข้อสอดคล้องกับข้อร้องเรียนเหล่านั้นเกือบหนึ่งต่อหนึ่ง

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

ข้อที่สอง: พวกเขา “ชอบทำให้โค้ดและ API ซับซ้อนเกินจำเป็นจริงๆ ทำ abstraction ให้บวมพอง ไม่เก็บกวาดโค้ดที่ตายแล้ว… สร้างโครงสร้างที่บวมเกิน 1000 บรรทัดทั้งที่ 100 บรรทัดก็เพียงพอ” เรื่องนี้คุ้นหูสำหรับใครก็ตามที่เคยขอฟีเจอร์แล้วได้เฟรมเวิร์กกลับมา

ข้อที่สามละเอียดอ่อนกว่า และสำหรับใครก็ตามที่ตรวจสอบ diff ถือว่ามีต้นทุนสูงที่สุด: พวกมัน "ยังคงบางครั้งเปลี่ยนแปลง/ลบคอมเมนต์และโค้ดที่พวกมันเข้าใจไม่เพียงพอในฐานะผลข้างเคียง แม้จะไม่เกี่ยวข้องกับงานก็ตาม" การแก้ไขคอมเมนต์หนึ่งจุดแบบที่ไม่เกี่ยวข้องกับงานนั้นเล็กน้อยในตัวเอง เมื่อคูณทั่วทั้งโค้ดเบส มันคือวิธีที่คิวรีวิวเต็มไปด้วยการเปลี่ยนแปลงที่ไม่มีใครขอ และเป็นวิธีที่คอมเมนต์ซึ่งอธิบาย workaround หายไปก่อนที่ใครจะได้เรียนรู้ว่าทำไม workaround นั้นถึงมีอยู่

สี่หลักการ และบททดสอบที่แต่ละข้อทิ้งไว้

ไฟล์นี้บรรจุหลักการไว้สี่ข้อ แต่ละข้อมาพร้อมกฎชุดสั้น ๆ และสองข้อในนั้นระบุวิธีทดสอบบรรทัดเดียวที่คุณใช้กับ diff ได้โดยไม่ต้องติดตั้งอะไรเลย กฎเหล่านี้คือจุดที่ลักษณะเฉพาะของไฟล์ปรากฏออกมา

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

คำสั่งใต้หัวข้อคือ "อย่าสันนิษฐาน อย่าปิดบังความสับสน เผยข้อแลกเปลี่ยน" ภายใต้คำสั่งนี้: ระบุสมมติฐานอย่างชัดเจนและถามแทนการเดา; นำเสนอการตีความหลายแบบเมื่อคำขอคลุมเครือ; ค้านกลับเมื่อมีวิธีที่เรียบง่ายกว่า; หยุดเมื่อสับสน ระบุว่าอะไรไม่ชัดเจน และขอคำชี้แจง สิ่งนี้มุ่งเป้าไปที่ข้อร้องเรียนแรกโดยตรง กลไกไม่ใช่ "ระวังให้มากขึ้น" — แต่คือการเปลี่ยนการเลือกแบบเงียบ ๆ ให้เป็นสิ่งที่มองเห็นได้ เพื่อให้ผู้ตรวจสอบสามารถโต้แย้งได้ก่อนที่โค้ดจะมีอยู่จริง ไม่ใช่หลังจากนั้น

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

กฎคือให้เขียนโค้ดน้อยที่สุดเท่าที่แก้ปัญหาได้ โดยไม่มีอะไรที่คาดเดาไปเอง: ไม่มีฟีเจอร์เกินกว่าที่ขอ ไม่มี abstraction สำหรับโค้ดที่ใช้ครั้งเดียว ไม่มีความยืดหยุ่นหรือความสามารถในการตั้งค่าที่ไม่มีใครขอ ไม่มีการจัดการข้อผิดพลาดสำหรับสถานการณ์ที่เป็นไปไม่ได้ และ "ถ้า 200 บรรทัดลดเหลือ 50 ได้ ก็เขียนใหม่ซะ" การทดสอบคือคำถามเดียว — วิศวกรอาวุโสจะบอกว่านี่มันซับซ้อนเกินไปไหม? — ซึ่งเป็นการตัดสินใจเชิงดุลพินิจ และยอมรับอย่างเปิดเผยว่าเป็นเช่นนั้น

การเปลี่ยนแปลงทางการผ่าตัด

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

การดำเนินการที่ขับเคลื่อนด้วยเป้าหมาย

กำหนดเกณฑ์ความสำเร็จและวนซ้ำจนกว่าจะตรวจสอบผ่าน README แสดงการเปลี่ยนแปลงในรูปแบบคู่ แทนที่จะบอกว่า "เพิ่มการตรวจสอบความถูกต้อง" ให้เขียนชุดทดสอบสำหรับอินพุตที่ไม่ถูกต้องแล้วทำให้ผ่าน แทนที่จะบอกว่า "แก้บั๊ก" ให้เขียนชุดทดสอบที่จำลองบั๊กนั้นแล้วทำให้ผ่าน แทนที่จะบอกว่า "รีแฟกเตอร์ X" ให้มั่นใจว่าชุดทดสอบผ่านทั้งก่อนและหลัง สำหรับงานหลายขั้นตอน เครื่องมือนี้ขอแผนสั้น ๆ ซึ่งแต่ละขั้นตอนระบุการตรวจสอบของตัวเอง README อ้างคำพูดของ Karpathy อีกครั้งตรงนี้ว่า "LLMs เก่งเป็นพิเศษในการวนซ้ำจนกว่าจะบรรลุเป้าหมายเฉพาะ… อย่าบอกให้มันทำอะไร ให้เกณฑ์ความสำเร็จแล้วดูมันลงมือ"

ไฟล์ ทักษะ และปลั๊กอินเป็นสามสิ่งที่แตกต่างกัน

ควรพูดถึงกลไกให้ชัดเจน เพราะพฤติกรรมในทางปฏิบัติแตกต่างกัน CLAUDE.md คือไฟล์คำสั่งระดับโปรเจกต์ ซึ่งเป็นข้อความที่ Claude Code อ่านเป็นบริบทประจำสำหรับรีโพซิทอรี และมีอยู่ไม่ว่าครั้งนี้จะมีใครขอให้ใช้หรือไม่ สกิลคือโฟลเดอร์ที่มี SKILL.md ซึ่งอธิบายว่าควรใช้ความสามารถนั้นเมื่อใด โดยจะถูกโหลดเมื่อมีงานที่ต้องใช้เท่านั้น ไม่โหลดก่อนหน้านั้น ปลั๊กอินคือแพ็กเกจสำหรับเผยแพร่ที่ติดตั้งผ่านมาร์เก็ตเพลส ซึ่งสามารถบรรจุสกิล คำสั่ง และองค์ประกอบอื่น ๆ ได้ ความแตกต่างเหล่านี้เกี่ยวกับว่าคำสั่งจะเข้าสู่บริบทเมื่อใดและใครเป็นผู้ตัดสิน ไม่ใช่เกี่ยวกับคุณภาพ

ในแง่นั้น CLAUDE.md คือสิ่งที่ตรงไปตรงมาที่สุดในสามอย่างนี้ มันเปิดใช้งานอยู่เสมอในโปรเจกต์นั้น ใช้กับทุกงานในโปรเจกต์ และกินพื้นที่บริบทในทุกเทิร์น ไม่ว่างานจะเป็นการแก้คำผิดหนึ่งบรรทัดหรือการย้ายระบบ README ของไฟล์เองยอมรับต้นทุนนี้ในส่วนที่ชื่อ Tradeoff Note ว่า แนวทางเหล่านี้เอนไปทางความระมัดระวังมากกว่าความเร็ว และสำหรับงานเล็กน้อย — การแก้คำผิดง่าย ๆ งานบรรทัดเดียวที่ชัดเจน — คุณควรใช้วิจารณญาณ โดยระบุว่าเป้าหมายคือการลดข้อผิดพลาดที่มีต้นทุนสูงในงานที่ไม่ใช่เรื่องเล็กน้อย ไม่ใช่การทำให้งานง่าย ๆ ช้าลง

นั่นเป็นคำอธิบายที่ตรงไปตรงมาว่าไฟล์คำสั่งแบบถาวรทำอะไรได้บ้าง มันไม่สามารถเพิ่มความสามารถที่โมเดลยังไม่มีได้ ทำได้เพียงทำให้พฤติกรรมที่มีอยู่แล้วของโมเดลมีแนวโน้มจะเกิดขึ้นมากขึ้นหรือน้อยลงเท่านั้น ซึ่งเป็นเหตุผลที่ไฟล์นี้เขียนเป็นข้อจำกัด — อย่าทำสิ่งนี้ ถามก่อนทำสิ่งนั้น — แทนที่จะเขียนเป็นคำกระตุ้นให้พัฒนาให้ดีขึ้น

222,612 ดวงดาววัดอะไร

สิ่งเหล่านี้วัดความสนใจ นั่นไม่ใช่การมองข้ามและไม่ใช่เรื่องเล็กน้อย: รีโพซิทอรีที่สร้างขึ้นในเดือนมกราคม 2026 และ push ครั้งล่าสุดในเดือนเมษายน มีดาวถึง 222,612 ดวงและมี fork 22,321 ครั้ง ณ วันที่ 23 ตุลาคม 2026 บน GitHub ซึ่งอ่านข้อมูล ณ วันนั้น ความหมายคือมันถูกแชร์อย่างกว้างขวางและถูก fork โดยผู้ที่ต้องการสำเนาของตัวเอง จำนวนดาวเป็นตัวชี้วัดที่สมเหตุสมผลว่ามีกี่คนที่เห็นว่าบางสิ่งควรค่าแก่การบุ๊กมาร์ก

มันไม่ใช่ตัวแทนของผลลัพธ์ และรีโพซิทอรีก็ไม่ได้แสร้งทำเป็นอย่างอื่น สิ่งที่ไม่ได้ถูกเผยแพร่ที่ใดเลยในนั้น ได้แก่ เบนช์มาร์กใด ๆ ที่เปรียบเทียบผลลัพธ์เมื่อมีไฟล์นี้กับเมื่อไม่มี ระเบียบวิธีใด ๆ สำหรับวัดว่ามันได้ผลหรือไม่ และการเปรียบเทียบกับกลุ่มควบคุมใด ๆ ไม่มีการเปรียบเทียบก่อนและหลังบนโค้ดเบสจริง ไม่มีการศึกษาผู้ตรวจทาน ไม่มีอัตราการเกิดเหตุการณ์ ไฟล์แบบนี้เป็นสมมติฐานเกี่ยวกับพฤติกรรมของโมเดลที่เขียนไว้อย่างงดงาม และยังไม่มีใครได้ทำการทดลอง

สิ่งที่ README นำเสนอแทนคือส่วนที่ชื่อ How to Know It's Working ซึ่งระบุสี่สิ่งที่คุณอาจสังเกตได้ ได้แก่ การเปลี่ยนแปลงที่ไม่จำเป็นใน diff น้อยลง การเขียนใหม่เนื่องจากการทำให้ซับซ้อนเกินไปน้อยลง คำถามที่ช่วยให้กระจ่างมาถึงก่อนการลงมือทำแทนที่จะมาหลังเกิดข้อผิดพลาด และ pull request ที่เรียบง่ายและกระชับ สิ่งเหล่านี้เป็นสัญญาณที่สมเหตุสมผล ทั้งยังเป็นสิ่งที่คุณจะเขียนพอดีถ้าคุณยังไม่ได้วัดผลอะไรเลย และเป็นการรายงานด้วยตนเองโดยใครก็ตามที่นำไฟล์นี้ไปใช้ จงอ่านสิ่งเหล่านี้เป็นรายการตรวจสอบเพื่อใช้กำกับไฟล์ในรีโปของคุณเอง ไม่ใช่เป็นหลักฐานว่าไฟล์นี้ผ่านแล้ว

สิ่งที่คุณพิมพ์จริง ๆ เพื่อติดตั้งมัน

README มีสองเส้นทาง วิธีที่แนะนำให้รันภายใน Claude Code: เพิ่มมาร์เก็ตเพลส แล้วติดตั้งปลั๊กอิน หลังจากนั้นแนวทางจะพร้อมใช้ในทุกโปรเจกต์แทนที่จะเป็นรายรีโพซิทอรี วิธีที่สองเป็นแบบรายโปรเจกต์: ดึงไฟล์ CLAUDE.md ดิบเข้าไปในรีโพซิทอรีใหม่ หรือต่อท้ายในรีโพซิทอรีที่มีอยู่แล้ว นอกจากนี้ยังมีกฎโปรเจกต์ของ Cursor ที่คอมมิตไว้ด้วย ดังนั้นแนวทางเดียวกันจึงมีผลเมื่อเปิดโฟลเดอร์ใน Cursor — รายละเอียดนี้บอกว่าไฟล์ถูกเขียนให้พอร์ตข้ามเครื่องมือที่อ่านไฟล์คำสั่งระดับโปรเจกต์ได้ ไม่ได้ผูกกับตัวโหลดของผู้จำหน่ายรายใดรายหนึ่ง

มีจุดที่ยังไม่เรียบร้อยอยู่จุดหนึ่งซึ่งควรแจ้งเตือนไว้ เพราะคุณจะเจอแน่ถ้าทำตาม README ตรง ๆ คำสั่งของ marketplace ระบุชื่อ forrestchang/andrej-karpathy-skills ขณะที่ URL ของรีโพซิทอรีที่ด้านบนของหน้าเป็น multica-ai/andrej-karpathy-skills ทั้งสองสตริงปรากฏอยู่ใน README เดียวกัน ซึ่งอ่านเมื่อ 23 ตุลาคม 2026 ฉันเห็นความไม่ตรงกันนี้และบอกไม่ได้ว่าทำไมถึงเป็นเช่นนั้น คำแนะนำที่ซื่อตรงคือให้ลองอีกเส้นทางหนึ่งถ้าเส้นทางหนึ่งใช้ไม่ได้ และให้ถือว่าหนึ่งในสองสตริงนั้นล้าสมัย

อีกสิ่งหนึ่งที่ควรสังเกตในหน้าแรก: รีโพซิทอรีนี้ดูแลโดย multica-ai และบล็อกคำพูดเปิดเรื่องใน README โฆษณา Multica ซึ่งเป็น "แพลตฟอร์มโอเพนซอร์สสำหรับการรันและจัดการเอเจนต์เขียนโค้ดด้วยทักษะที่นำกลับมาใช้ซ้ำได้" นั่นเป็นการเปิดเผยข้อมูลที่ชอบธรรม และยังเป็นเบาะแสว่าทำไมการจัดแพ็กเกจจึงมีหน้าตาเช่นนี้ โครงการที่สนใจทักษะที่นำกลับมาใช้ซ้ำได้มักจะส่งคำแนะนำของตัวเองออกมาในรูปแบบที่ติดตั้งได้ ซึ่งนั่นคือสิ่งที่ปลั๊กอินนี้เป็น

การใช้โดยไม่สืบทอดข้อสันนิษฐานของมัน

ส่วน Customization เป็นส่วนที่ผู้อ่านส่วนใหญ่ข้ามไป ไฟล์นี้ออกแบบมาเพื่อรวมเข้ากับคำแนะนำเฉพาะของโปรเจกต์ มากกว่าที่จะแทนที่คำแนะนำเหล่านั้น และตัวอย่างที่ให้ไว้ก็เป็นรูปธรรม: ใช้โหมด strict ของ TypeScript, API endpoint ทั้งหมดต้องมีการทดสอบ, ทำตามรูปแบบการจัดการข้อผิดพลาดที่มีอยู่แล้วในไฟล์ที่ระบุ นั่นไม่ใช่แค่การตกแต่ง มันคือความแตกต่างระหว่างคู่มือกฎทั่วไปกับชุดคำสั่งที่รู้ว่าโค้ดของคุณอยู่ที่ไหน

มีเหตุผลในทางปฏิบัติที่ต้องรวมเข้าด้วยกันแทนที่จะซ้อนกัน หากคุณวางไฟล์เข้าไปตามเดิมและโปรเจกต์ของคุณมีแนวปฏิบัติของตัวเอง ชุดคำสั่งสองชุดอาจขัดแย้งกัน และการที่โมเดลต้องประสานความขัดแย้งนั้นก็คือความสับสนแบบที่หลักการข้อแรกพยายามกำจัดออกไปพอดี การเขียนแนวปฏิบัติของคุณลงในไฟล์เดียวกัน ด้วยน้ำเสียงเดียวกัน ช่วยให้พื้นที่ของคำสั่งเล็กพอที่จะตรวจสอบได้

และคุณก็ควรตรวจสอบมัน ข้อความสั้น ๆ นี้เป็นคำแนะนำด้านพฤติกรรมที่จะใช้กับทุกคำขอในรีโพซิทอรี คำถามที่ถูกต้องไม่ใช่ใช่หรือไม่ที่คน 222,612 คนจะผิดได้ — การตั้งกรอบแบบนั้นไม่ได้ตัดสินอะไรเลย — แต่คือว่าแต่ละกฎตรงกับความผิดพลาดที่คุณเคยเห็นจริงหรือไม่ ถ้า diff ของคุณไม่เคยมีการเขียนคอมเมนต์ใหม่แบบแวบผ่าน ส่วน Surgical Changes ก็ทำให้คุณต้องเสีย context ไปเปล่า ๆ ลบมันทิ้งซะ ไฟล์นี้ได้รับอนุญาตแบบ MIT และตั้งใจให้แก้ไขได้

หากลงไปอีกหนึ่งชั้น ไม่มีสิ่งใดในนี้ที่เปลี่ยนว่าโมเดลใดจะเป็นผู้ตอบ ไฟล์ CLAUDE.md กำหนดวิธีจัดการคำขอเมื่อคำขอไปถึงโมเดลแล้ว แต่ไม่ได้บอก anything เกี่ยวกับโมเดลที่รับคำขอนั้น การตัดสินใจส่วนที่สองนั้นเป็นของสิ่งที่อยู่หน้าโมเดล วิธีหนึ่งในการจัดวางคือ endpoint เดียวที่เข้ากันได้กับ OpenAI ซึ่งให้บริการโมเดลมากกว่า 200 โมเดลภายใต้คีย์เดียว พร้อมการสลับไปยังผู้ให้บริการสำรองอัตโนมัติเมื่อเกิดความล้มเหลว และราคาตามรายการของผู้ให้บริการถูกส่งผ่านโดยไม่มีมาร์กอัป 0% เราให้บริการโฮสต์โมเดล เราไม่ได้สร้าง Claude Code และไม่มีสิ่งใดใน repository ของคุณที่เราเห็นได้

การค้นหาจะยังคงพูดว่า skills เพราะนั่นคือคำที่ผู้คนใช้เรียกสิ่งที่คุณติดตั้งเพื่อทำให้เอเจนต์มีพฤติกรรมแตกต่างออกไป และแพ็กเกจจิงรอบ ๆ รีโพซิทอรีนี้ก็ใช้คำนี้เช่นกัน ชิ้นงานนี้คือไฟล์: เอกสารคำสั่งประจำหนึ่งฉบับ เขียนขึ้นจากข้อร้องเรียนเฉพาะสามข้อ พร้อมหลักการสี่ข้อและชุดการทดสอบที่คุณนำไปใช้ด้วยมือได้ ตัดสินมันจากว่าข้อร้องเรียนเหล่านั้นฟังดูเหมือนรีโพซิทอรีของคุณหรือไม่ นั่นเป็นคำถามที่ดีกว่าจำนวนดาว ซึ่งเคยวัดได้เพียงว่ามีกี่คนที่มีปฏิกิริยาแบบเดียวกับที่คุณเพิ่งมี