Cursor Rules Generator: สร้างไฟล์ .cursor/rules แบบ MDC ที่กำกับ AI editor ได้จริง

AI coding assistant จะทำงานได้สม่ำเสมอแค่ไหน ขึ้นอยู่กับว่าคุณบอกแบบแผนให้มันฟังมากแค่ไหน ถ้าโปรเจกต์ไม่มี rules เลย editor จะเดาโครงสร้างไฟล์ แต่ง pattern ของตัวเอง และแก้โค้ดที่คุณจัดรูปแบบไว้แล้วอย่างเงียบ ๆ Cursor Rules Generator ช่วยแก้ปัญหานี้ตั้งแต่ต้นทาง โดยสร้างไฟล์ .cursor/rules รูปแบบ MDC พร้อม frontmatter ครบทั้ง description, globs และ alwaysApply บวก curated presets ที่ชี้ให้เห็นว่า rule ที่ดีเขียนกันแบบไหน

ประเด็นสำคัญคือ AI editors follow rules you write once — a good rules file is the difference between an assistant and a nuisance เขียนแบบแผนของทีมลงไฟล์เดียว scope ให้ตรงไฟล์ที่เกี่ยวข้อง แล้วทุก request ในอนาคตจะเริ่มจากพื้นฐานเดียวกัน แทนที่จะเริ่มจากหน้าจอว่างเปล่า

บทความนี้อธิบายรูปแบบ MDC ว่าอะไรควรอยู่ในไฟล์ rules (และอะไรไม่ควร) พร้อมวิธีเปลี่ยนผลลัพธ์จาก generator ให้เป็นชุด rules ที่ทั้งทีมใช้ร่วมกันได้

ทำไมต้องใช้ Cursor Rules Generator?

• Frontmatter ถูกต้องตั้งแต่ครั้งแรก — generator ประกอบฟิลด์ description, globs และ alwaysApply ให้ syntax ถูกต้อง ไม่ต้องไล่หาสาเหตุว่าทำไม Cursor ถึงเมิน rule ของคุณ
• Curated presets เป็นจุดเริ่มต้น — มี preset สำเร็จรูปสำหรับ TypeScript, React, Tailwind, Vitest, conventional commits และสไตล์เอกสาร ให้เริ่มจากของที่ใช้ได้จริงแล้วค่อยปรับให้เข้ากับโปรเจกต์
• Scope ด้วย globs — ผูกแต่ละ rule กับไฟล์ที่เกี่ยวข้องเท่านั้น เช่น rule ภาษา TypeScript โหลดเฉพาะตอนแก้ไฟล์ **/*.ts
• ตรวจสอบสดขณะพิมพ์ — เตือนเมื่อลืมใส่ description ลืมตั้งชื่อ rule หรือตั้ง alwaysApply: true จน globs ถูกละเว้นโดยไม่รู้ตัว
• คัดลอกหรือดาวน์โหลดทันที — กด copy เนื้อหา MDC หรือดาวน์โหลดเป็นไฟล์ แล้ววางลง .cursor/rules/ ได้เลยไม่ต้องเก็บกวาด
• เป็นส่วนตัวโดยดีไซน์ — ทำงานฝั่ง client ทั้งหมดในเบราว์เซอร์ ข้อมูลโปรเจกต์ของคุณไม่ถูกส่งออกไปไหน

ฟีเจอร์หลัก (Key Features)

สามเรื่องนี้ควรดูใกล้ ๆ:

• ตรวจชื่อซ้ำ — เตือนเมื่อสอง rule จะได้ชื่อไฟล์เดียวกัน เพราะไฟล์ใน .cursor/rules/ เขียนทับกันอย่างเงียบ ๆ
• คำเตือนเรื่อง alwaysApply — ย้ำว่า rule ที่ alwaysApply: true จะถูกฉีดเข้าทุก request และ globs จะถูกละเว้น ช่วยให้คุณตัดสินใจอย่างมีสติ
• ปุ่ม preset แก้ไขได้ทุกบรรทัด — preset แค่เติมค่าเริ่มต้นให้ฟอร์ม เนื้อหาสุดท้ายอยู่ในมือคุณเสมอ

วิธีใช้งาน

1. เปิด generator ที่ /th/tools/cursor-rules-generator ไม่ต้องติดตั้งและไม่ต้องสมัครบัญชี
2. เลือก preset หรือเริ่มจากว่าง เช่น preset TypeScript จะเติม description, globs และเนื้อหา conventions ให้แก้ได้ทีละบรรทัด
3. ตั้งชื่อ rule และปรับฟิลด์ — ชื่อจะกลายเป็นชื่อไฟล์ เช่น typescript-conventions.mdc ใส่ description สั้น ๆ ระบุ globs และเลือกว่า rule ควร apply เสมอหรือไม่
4. เขียนเนื้อหา — เก็บให้สั้น ใช้คำสั่งที่ model ลงมือทำได้จริง ระบุ command ที่ควรรัน และ pattern ที่ไม่อยากเห็นอีก
5. คัดลอกหรือดาวน์โหลด — ตรวจคำเตือนแล้ว copy หรือดาวน์โหลดไฟล์ไปวางใน .cursor/rules/ ของโปรเจกต์ แล้ว commit ให้ทั้งทีมได้ประโยชน์

Frontmatter คือระบบกำกับเส้นทางของ editor

ไฟล์ .cursor/rules ใช้รูปแบบ MDC คือ frontmatter แบบ YAML ที่บอก Cursor ว่า ควรโหลด rule เมื่อไหร่ ตามด้วย markdown ที่บอก model ว่า ต้องทำอะไร สามฟิลด์นี้คือระบบควบคุมทั้งหมด:

• description — สิ่งที่ Cursor อ่านเพื่อตัดสินว่า rule เกี่ยวข้องกับ request ปัจจุบันหรือไม่ คำอธิบายกำกวม rule จะไม่ถูกใช้เลย คำอธิบายชัดเจน เช่น "รูปแบบ commit message แบบ conventional ของ repo นี้" จะถูกใช้ตรงจังหวะพอดี
• globs — จำกัดขอบเขต rule ตาม pattern ของไฟล์ rule ที่ตั้ง globs: ["**/*.test.ts", "**/*.test.tsx"] จะถูก attach เฉพาะตอนทำงานกับไฟล์ทดสอบ ช่วยให้ context กระชับและตรงประเด็น
• alwaysApply — เปลี่ยน rule เป็นบริบทถาวรที่ฉีดเข้าทุก request ใช้อย่างระมัดระวัง เพราะเป็น rule ที่แพงที่สุด และเมื่อตั้งเป็น true แล้ว globs จะถูกละเว้นทั้งหมด

ตัวอย่างผลลัพธ์จาก generator พร้อมคำอธิบาย:

---
# Cursor อ่านบรรทัดนี้เพื่อตัดสินว่า rule เกี่ยวข้องไหม
description: Enforce strict TypeScript conventions
# pattern ของไฟล์ที่ rule นี้ attach เข้าไป
globs: ["**/*.ts", "**/*.tsx"]
# ถ้าเป็น true rule นี้จะถูกฉีดเข้าทุก request
alwaysApply: false
---

# TypeScript conventions

- Prefer readonly parameters for object arguments.
- Never use any in exported signatures; narrow from unknown instead.
- Run npm run typecheck before declaring a change complete.

อะไรควรอยู่ในไฟล์ rules: แบบแผน (naming, โครงสร้าง, pattern), คำสั่ง (typecheck, lint, test) และสไตล์ (การจัดรูปแบบ น้ำเสียงของ docs และคอมเมนต์) อะไรไม่ควรอยู่: secrets และ credentials เพราะไฟล์ rules ถูก commit ขึ้น repo และคำว่า "ทุกอย่าง" — หนังสือ handbook สี่พันคำจะถูก model ข้าม ๆ และทำให้ context window อึดอัด rule เดียวจับหนึ่งเรื่อง scope ให้แคบ ชนะ rule รวมศูนย์เสมอ

curated presets ทั้งหกยึดหลักนี้ แต่ละอันเป็น seed ขนาดเล็กที่มีทัศนคติชัด — TypeScript strictness, React component patterns, Tailwind class ordering, Vitest standards, รูปแบบ commit แบบ conventional และสไตล์ markdown สำหรับ docs — ออกแบบให้ตัดแต่งต่อ ไม่ใช่กดยอมรับทั้งชุด

ตัวอย่างการใช้งานจริง

ฝังแบบแผนของโปรเจกต์

ทุกทีมมีกติกาที่ไม่เคยเขียนไว้ ว่า helper อยู่ที่ไหน error ของ API มีรูปร่างแบบไหน state management แบบไหนคือรุ่นปัจจุบัน เขียนลง rule เดียว scope ด้วย **/*.ts, **/*.tsx แล้วโค้ดใหม่จะไม่เลี้ยวออกนอกกรอบของโค้ดเดิม

Rules เฉพาะ framework

แยกไฟล์ตาม framework: rule React scope **/*.tsx, rule Tailwind scope **/*.tsx, **/*.css, rule Vitest scope ไฟล์ทดสอบ Cursor จะโหลดเฉพาะสิ่งที่เกี่ยวกับไฟล์ตรงหน้า คำตอบจึงตรงงานมากขึ้น

Onboarding ทีมที่จำได้จริง

มือใหม่อ่าน README ครั้งเดียว แต่ Cursor อ่าน rules ทุก request เมื่อ commit โฟลเดอร์ .cursor/rules/ ที่มี conventions หลักของทีม editor จะกลายเป็นเครื่องมือ onboarding ที่บังคับมาตรฐาน แทนที่จะเป็นแค่เอกสารบันทึกข้อยกเว้น

สไตล์ส่วนตัวโดยไม่รบกวนทีม

ไม่ใช่ทุกอย่างควรอยู่ใน repo ร่วม rule ส่วนตัวอย่าง "ชอบ arrow function และ early return" หรือ "เพิ่ม JSDoc ให้ exported function เสมอ" เก็บไว้ในเครื่องได้ ให้ editor เข้ากับนิสัยของคุณโดยไม่แตะไฟล์ของทีม

แนวทางปฏิบัติที่ดี

• เก็บ rule ให้สั้นและลงมือได้ — ต่อหนึ่ง rule ใช้ imperative ไม่กี่ข้อ ยาวเกินไปทั้ง model และคนดูแลจะข้าม
• Scope ด้วย globs ก่อนพูดถึง alwaysApply — rule ที่ scope ดียังตรงงาน ส่วน always-on คือภาษีประจำทุก request
• ทบทวน rules ทุกไตรมาสเหมือน dependencies — แบบแผนเปลี่ยนเสมอ rule ที่ขัดกับของจริงแย่กว่าไม่มี rule เลย
• หนึ่ง rule จับหนึ่งเรื่อง — แยก TypeScript conventions กับรูปแบบ commit เป็นคนละไฟล์ เพื่อแก้และ scope ได้อิสระ
• ระบุ command ไม่ใช่แค่ความตั้งใจ — "รัน npm run lint:fix ก่อนจบงาน" ใช้งานได้จริง ส่วน "ทำให้โค้ดสะอาด" ฟังดีแต่ทำอะไรไม่ได้
• ห้ามใส่ secrets ใน rules — ไฟล์ rules ถูก commit และแชร์ key, token และ internal endpoint ต้องอยู่ใน secret manager

เริ่มกำกับ Cursor ของคุณวันนี้

ไฟล์ rules คือ config ที่คุ้มค่าที่สุดใน workflow แบบ AI-assisted เขียนครั้งเดียว ใช้กับทุก request ข้างหน้า เปิด Cursor Rules Generator เริ่มจาก preset scope ด้วย globs แล้ว commit ผลลัพธ์ เซสชันถัดไปของคุณจะเริ่มจากแบบแผน ไม่ใช่การเดา

เครื่องมือที่เกี่ยวข้องที่คุณอาจสนใจ:

• AGENTS.md Generator — เขียนไฟล์ AGENTS.md ที่ใช้ได้กับ AI coding tools หลายตัว ไม่ใช่แค่ Cursor
• ESLint Config Generator — จับคู่ AI rules กับ linter จริงที่บังคับใช้แบบแผนแทนคุณ
• Markdown Preview — ดูตัวอย่างและปัดเกลาเนื้อหา markdown ของไฟล์ rules ระหว่างเขียน

ขอให้สนุกกับการเขียน rules — ขอให้ AI editor ของคุณฟังแบบแผนที่คุณใช้อยู่จริงเสียที!

คำถามที่พบบ่อย

ถ: ควรวางไฟล์ rules ที่สร้างแล้วไว้ที่ไหน?

ตอบ: บันทึกไฟล์ .mdc ที่ดาวน์โหลดไว้ในโฟลเดอร์ .cursor/rules/ ของโปรเจกต์ (สร้างขึ้นใหม่ถ้ายังไม่มี) แล้ว commit ไว้ เพื่อให้ทั้งทีมได้พฤติกรรมเดียวกัน

ถ: globs กับ alwaysApply ต่างกันอย่างไร?

ตอบ: globs ผูก rule ให้ทำงานเฉพาะเมื่อมีไฟล์ที่ตรง pattern เกี่ยวข้อง ส่วน alwaysApply: true จะฉีด rule เข้าทุก request โดยไม่สน globs — generator จะเตือนเมื่อสองค่านี้ขัดกัน

ถ: แก้ไขไฟล์ MDC หลังดาวน์โหลดได้ไหม?

ตอบ: ได้ ไฟล์ MDC เป็น plain text คือ frontmatter ตามด้วย markdown แก้ไขด้วย editor อะไรก็ได้ และกลับมา generate ใหม่เมื่อต้องการอัปเดตฟิลด์

ถ: generator อัปโหลด rules หรือโค้ดของฉันไปไหนหรือเปล่า?

ตอบ: ไม่ เครื่องมือทำงานฝั่ง client ทั้งหมดในเบราว์เซอร์ ไม่มีการส่ง เก็บ หรือ log สิ่งที่คุณพิมพ์

ถ: โปรเจกต์หนึ่งควรมีกี่ rule?

ตอบ: เริ่มจากสองถึงสาม — หนึ่ง always-on rule สำหรับ conventions หลัก และหนึ่งถึงสอง rule แบบ glob-scoped สำหรับ framework หรือไฟล์ทดสอบ เพิ่มเมื่อเห็นการแก้ซ้ำ ๆ เท่านั้น