Cursor คืออะไร ใครเป็นผู้พัฒนา?

Cursor คือ AI code editor (โปรแกรมแก้โค้ดที่มี AI ในตัว) พัฒนาโดยบริษัท Anysphere เป็น fork ของ VS Code จึงใช้ extension, keybinding และธีมของ VS Code ได้ จุดต่างคือชั้น AI ที่เข้าใจ codebase ทั้งโปรเจกต์และลงมือแก้โค้ดหลายไฟล์พร้อมรันคำสั่งได้ ฟีเจอร์หลักได้แก่ Tab (autocomplete), Cmd/Ctrl+K (inline edit), Chat และ Agent/Composer

Cursor ใช้ฟรีได้ไหม ต้องสมัครแผนอะไร?

Cursor มีแผน Hobby ให้ใช้ฟรีในระดับพื้นฐาน ส่วนแผน Pro และแผนสำหรับองค์กร (Business, Ultra) จะปลดล็อก Tab แบบไม่จำกัด เครดิตโมเดลพรีเมียม และฟีเจอร์ agent มากขึ้น รายละเอียดและราคาอาจเปลี่ยนตามช่วงเวลา ควรตรวจสอบหน้าราคาที่ cursor.com อีกครั้ง

Cursor ใช้โมเดล AI อะไร เลือกเองได้ไหม?

Cursor ไม่ได้สร้างโมเดลหลักเอง แต่เลือกใช้โมเดลจากหลายผู้ผลิตผ่าน model picker เช่น GPT ของ OpenAI, Claude ของ Anthropic, Gemini ของ Google และอื่น ๆ พร้อมโมเดล first-party ตระกูล Composer ของ Cursor เอง เลือกโมเดลเองได้ หรือใช้ Auto mode ให้ Cursor เลือกให้ และใส่ API key ของตัวเอง (BYOK) ได้

Cursor ต่างจาก VS Code และ GitHub Copilot อย่างไร?

Cursor คือ VS Code ที่ถูก fork มาแล้วเสริมชั้น AI ที่เข้าใจทั้ง codebase จึงย้ายจาก VS Code มาได้ทันทีพร้อม import settings/extensions ต่างจาก Copilot ตรงที่ Cursor ไม่ได้เป็นแค่ปลั๊กอิน autocomplete แต่มี Agent ที่วางแผนและแก้โค้ดหลายไฟล์ รันคำสั่ง และให้บริบทด้วย @-symbols ได้ครบในตัว โดยผู้ใช้ควร review โค้ดที่ AI สร้างเสมอ

วิธีใช้ Cursor ฉบับสมบูรณ์ 2026: คู่มือ AI Code Editor สำหรับนักพัฒนาไทย

เรียนรู้การใช้ Cursor ตั้งแต่ติดตั้งจนถึงสั่งงาน Agent เขียนโค้ดหลายไฟล์ ครบทุกฟีเจอร์ โมเดล AI การตั้งกฎ และเวิร์กโฟลว์จริง อัปเดตล่าสุดปี 2026

เริ่มใช้ Cursor ใน 5 ขั้นตอน (Quick Start)

ดาวน์โหลดและติดตั้ง Cursor จาก cursor.com แล้วกด Import ใน Settings เพื่อย้าย Extensions, ธีม และ Keybindings จาก VS Code มาใช้ทันที

เริ่มต้นด้วยแผน Hobby (ฟรี) หรือ Pro ($20/เดือน) ที่ให้ Tab autocomplete ไม่จำกัดและเครดิตโมเดลพรีเมียม

ลองฟีเจอร์หลักสามอย่าง: กด Tab เพื่อรับ autocomplete, Cmd/Ctrl+K เพื่อแก้โค้ดแบบ inline และ Cmd/Ctrl+L เพื่อเปิด Chat/Agent

ให้บริบทกับ AI ด้วยการพิมพ์ @ เพื่ออ้างอิงไฟล์ โฟลเดอร์ เอกสาร หรือค้นทั้ง codebase ที่ถูก index ไว้

สั่ง Agent ให้วางแผนและแก้โค้ดหลายไฟล์อัตโนมัติ พร้อมตั้งกฎสไตล์ของคุณไว้ในไฟล์ .cursor/rules เพื่อให้ผลลัพธ์ตรงใจทุกครั้ง

สารบัญ (Table of Contents)

บทที่ 1: Cursor คืออะไร และภาพรวมการใช้งาน (AI Code Editor)
บทที่ 2: การติดตั้ง ตั้งค่าเริ่มต้น และย้ายจาก VS Code + เลือกแผน
บทที่ 3: โมเดล AI ใน Cursor และการเลือกใช้ให้เหมาะกับงาน
บทที่ 4: ฟีเจอร์หลัก: Tab (Autocomplete), Cmd/Ctrl+K (Inline Edit) และ Chat
บทที่ 5: Agent และ Composer: ให้ Cursor วางแผนและแก้โค้ดหลายไฟล์
บทที่ 6: การให้บริบทด้วย @-symbols และ Codebase Indexing
บทที่ 7: Rules for AI และ .cursorrules: กำหนดกฎและสไตล์ให้ Cursor
บทที่ 8: การทำงานกับ Terminal การรันคำสั่ง และ MCP
บทที่ 9: ศิลปะการสั่งงาน Cursor สำหรับงานเขียนโค้ด (Prompting)
บทที่ 10: เวิร์กโฟลว์จริง: สร้างฟีเจอร์ใหม่ แก้บั๊ก Refactor และเขียนเทสต์
บทที่ 11: Cursor ในการทำงานจริง: เวิร์กโฟลว์ตามสายงาน
บทที่ 12: คลัง Prompt และเทคนิคสำเร็จรูปสำหรับ Cursor (Cookbook)
บทที่ 13: ความปลอดภัย ความเป็นส่วนตัว (Privacy Mode) และข้อจำกัดที่ต้องรู้
บทที่ 14: เทคนิคขั้นสูง คีย์ลัด การใช้สำหรับทีม และเทียบกับเครื่องมืออื่น
คำถามที่พบบ่อยเกี่ยวกับการใช้ Cursor (FAQ)

บทที่ 1: Cursor คืออะไร และภาพรวมการใช้งาน (AI Code Editor)

Cursor คือ AI code editor หรือโปรแกรมแก้โค้ดที่มี AI ฝังอยู่ในตัว พัฒนาโดยบริษัท Anysphere ตัวโปรแกรมถูก fork มาจาก VS Code (Visual Studio Code ของ Microsoft) โดยตรง นั่นหมายความว่าหน้าตา การใช้งาน ระบบ extension, keybinding และธีมต่าง ๆ แทบจะเหมือน VS Code ทุกประการ นักพัฒนาที่คุ้นกับ VS Code อยู่แล้วจึงย้ายมาใช้ได้ทันทีโดยแทบไม่ต้องเรียนรู้อะไรใหม่ในระดับ editor พื้นฐาน

จุดต่างที่แท้จริงอยู่ที่ ชั้น AI ที่ Anysphere สร้างครอบทับลงไป Cursor ไม่ใช่แค่ "VS Code + ปลั๊กอิน AI" แต่ออกแบบให้ AI เข้าใจ codebase ทั้งโปรเจกต์ และลงมือแก้โค้ดหลายไฟล์พร้อมรันคำสั่งได้จริง

Cursor ต่างจาก autocomplete เดิม และ chatbot อย่างไร

หลายคนเคยใช้ autocomplete แบบเดิม (เติมชื่อตัวแปร/ฟังก์ชันจาก syntax) หรือเคยถาม chatbot อย่าง ChatGPT แล้ว copy-paste โค้ดกลับมาเอง Cursor อยู่คนละระดับ:

ต่างจาก autocomplete เดิม — autocomplete แบบเก่าเดาแค่คำถัดไปจาก syntax แต่ Cursor Tab ทำนายการแก้ไขทั้งชุด อิงจากการแก้ล่าสุด โค้ดรอบข้าง และ linter errors สามารถแก้หลายบรรทัด เพิ่ม import และเสนอการแก้ข้ามไฟล์ได้
ต่างจาก chatbot ทั่วไป — คุณไม่ต้อง copy-paste ไปมา เพราะ AI ทำงาน ในบริบทของโปรเจกต์จริง: อ่านไฟล์เอง ค้น codebase เอง และเขียนการแก้ไขกลับเข้าไฟล์ให้คุณ review ก่อน apply

💡 คิดง่าย ๆ ว่า Cursor = editor ที่คุณใช้ทำงานจริงทุกวัน + ผู้ช่วยที่ "เห็น" โค้ดทั้งโปรเจกต์และลงมือแก้ให้ได้ ไม่ใช่แค่ตอบคำถามในหน้าต่างแยก

ฟีเจอร์หลัก 4 อย่างที่ต้องรู้จัก

ฟีเจอร์	คีย์ลัดหลัก	ทำอะไร	เหมาะกับ
Tab (AI autocomplete)	`Tab` เพื่อ accept	ทำนายและเติมโค้ดขณะพิมพ์ แก้หลายบรรทัด/ข้ามไฟล์	เขียนโค้ดลื่น ๆ ระหว่างพิมพ์
Inline Edit	`Cmd/Ctrl + K`	เลือกโค้ดแล้วสั่งแก้เป็นภาษาธรรมชาติ	แก้เฉพาะจุดที่เลือก
Chat	`Cmd/Ctrl + L` หรือ `Cmd + I`	คุย/ถามโดยอ้างอิง context จาก codebase	ถาม-ตอบ, อธิบายโค้ด, วางแผน
Agent / Composer	เปิดในหน้า Chat/Agent	AI วางแผน แก้หลายไฟล์ และรันคำสั่ง terminal ได้	งานใหญ่ ฟีเจอร์ใหม่ หลายไฟล์

Tab — กด Tab เพื่อยอมรับคำแนะนำทั้งชุด, Esc หรือพิมพ์ต่อเพื่อปฏิเสธ, ยอมรับทีละคำด้วย Cmd/Ctrl + → แผนบุคคลแบบเสียเงิน (Pro/Pro+/Ultra) ให้ Tab ไม่จำกัด และไม่กินเครดิตการใช้งาน
Inline Edit (Cmd/Ctrl + K) — เลือกโค้ด พิมพ์คำสั่ง แล้วกด Return เพื่อ apply เฉพาะส่วนที่เลือก
Chat — คุยกับ AI พร้อมดึง context จากไฟล์/โค้ดเข้ามาได้ด้วย @-symbols (เช่น @Files, @Code, @Docs, @Web, @Git)
Agent / Composer — โหมด agentic ที่ AI ทำงานครบวงจร: สำรวจ codebase, แก้หลายไฟล์, รันคำสั่ง terminal และทำงานต่อเนื่องได้ เอกสารทางการระบุว่า Agent ไม่มีการจำกัดจำนวน tool call ต่อหนึ่งงาน นอกจากนี้ยังมี Plan Mode ที่ให้ AI วางแผน implementation ก่อนลงมือเขียนจริง (สลับโหมดด้วย Shift + Tab) และ Composer ซึ่งเป็นโมเดล first-party ของ Cursor เองที่เน้นความเร็วสำหรับงาน agentic

flowchart TD
    A[ผู้พัฒนา] --> B{ต้องการทำอะไร?}
    B -->|เติมโค้ดขณะพิมพ์| C[Tab<br/>AI autocomplete]
    B -->|แก้เฉพาะจุดที่เลือก| D[Cmd/Ctrl+K<br/>Inline Edit]
    B -->|ถาม / อธิบาย / วางแผน| E[Chat]
    B -->|งานใหญ่ หลายไฟล์| F[Agent / Composer]
    C & D & E & F --> G[Model Picker<br/>เลือกโมเดลจากหลายผู้ผลิต]
    G --> H[AI เสนอการแก้ไข]
    H --> I{มนุษย์ review}
    I -->|ผ่าน| J[Apply เข้า codebase]
    I -->|ไม่ผ่าน| K[แก้ prompt / ปฏิเสธ]

แนวคิดสำคัญ: Cursor ไม่ได้สร้างโมเดลเอง (ส่วนใหญ่)

หัวใจที่ทำให้ Cursor ยืดหยุ่นคือ Cursor เลือกใช้โมเดล AI จากหลายผู้ผลิตผ่าน model picker ไม่ได้ผูกกับโมเดลเดียว โดยรวมโมเดลจากผู้ให้บริการหลัก ได้แก่:

OpenAI — ตระกูล GPT
Anthropic — ตระกูล Claude
Google — ตระกูล Gemini
xAI — Grok และผู้ให้บริการอื่น ๆ

นอกจากนี้ Cursor ยังมีโมเดล first-party ของตัวเองคือตระกูล Composer ที่เร็วและประหยัดกว่าโมเดล frontier ของบุคคลที่สาม

คุณเลือกโมเดลได้จาก dropdown ใน model picker ในหน้าต่าง Chat/Agent และเปิด/ปิดโมเดลได้ที่ Settings > Models หากไม่อยากเลือกเอง มี Auto mode ที่ Cursor เลือกโมเดลที่เหมาะสมให้อัตโนมัติในแต่ละคำขอ และสำหรับงานที่ต้องการ context ยาวมากมี Max mode ที่ขยาย context window ให้ใหญ่ที่สุดเท่าที่โมเดลรองรับ (แต่คิดเงินแบบ token-based ซึ่งแพงกว่าปกติ) ผู้ใช้ระดับสูงยังใส่ API key ของตัวเอง (BYOK) ได้จาก OpenAI, Anthropic, Google, Azure และ AWS Bedrock

⚠️ ชื่อรุ่นและรายชื่อโมเดลที่เปิดให้ใช้ เปลี่ยนบ่อยมาก ในบทนี้จึงเลี่ยงการระบุเลขเวอร์ชันตายตัว ให้ยึด model picker จริง ในแอปและเอกสารที่ cursor.com/docs/models เป็นหลักเสมอ

ข้อควรระวังที่สำคัญที่สุด: ตรวจสอบสิ่งที่ AI สร้างเสมอ

พลังของ Cursor มาพร้อมความเสี่ยงที่คุณต้องเข้าใจตั้งแต่วันแรก AI hallucinate ได้ คือสร้างข้อมูลหรือโค้ดที่ดู "มั่นใจ" แต่ผิดจริง รูปแบบที่พบบ่อย:

สร้างเมธอด/API ที่ไม่มีอยู่จริง — โดยเฉพาะกับไลบรารีเฉพาะทางหรือ API ใหม่ ๆ ที่มีข้อมูลน้อยในชุดเทรน
อ้างว่าแก้บั๊กสำเร็จทั้งที่รันเทสต์ผิดตัว หรือแก้ไม่ตรงจุด
ใน codebase ขนาดใหญ่มาก (เกินหลายแสนบรรทัด) AI อาจหา context ที่เกี่ยวข้องไม่เจอ ทำให้ hallucinate ง่ายขึ้น

มีกรณีจริงในปี 2025 ที่แชตบอตซัพพอร์ตของ Cursor เองยัง hallucinate นโยบายการใช้งานที่ไม่มีจริงออกมา นี่คือตัวอย่างชัดเจนว่าแม้ระบบของผู้พัฒนา AI เองก็พลาดได้

⚠️ กฎเหล็กในการใช้ Cursor: ต้องมี human review เสมอ ก่อน apply โค้ดใด ๆ ที่ AI สร้าง อ่านให้เข้าใจ รันเทสต์จริง และอย่าเชื่อคำยืนยันของ agent ว่า "แก้เสร็จแล้ว" โดยไม่พิสูจน์ด้วยตัวเอง

เพื่อลด hallucination Cursor มีเครื่องมือช่วย เช่น @Docs (อ้างเอกสารทางการที่ index ไว้) และ @Web (ค้นเว็บแบบเรียลไทม์) ซึ่งเราจะลงรายละเอียดในบทถัด ๆ ไป สรุปภาพรวมของบทนี้คือ Cursor เป็น AI code editor ที่ทรงพลังและใช้งานคุ้นมือเพราะต่อยอดจาก VS Code แต่ผู้ใช้มืออาชีพต้องมองมันเป็น "ผู้ช่วยที่ต้องกำกับ" ไม่ใช่ระบบอัตโนมัติที่เชื่อได้ 100%

บทที่ 2: การติดตั้ง ตั้งค่าเริ่มต้น และย้ายจาก VS Code + เลือกแผน

บทนี้จะพาคุณจาก "ยังไม่มี Cursor ในเครื่อง" ไปจนถึง "พร้อมเขียนโค้ดกับ AI ได้จริงในวันแรก" ครอบคลุมตั้งแต่ดาวน์โหลด ติดตั้ง ย้ายทุกอย่างจาก VS Code (extensions/settings/keybindings/ธีม) ล็อกอิน เข้าใจแผนราคาแบบ token-based ปี 2026 และเลือกแผนที่คุ้มกับ workflow ของคุณ

2.1 ดาวน์โหลดและติดตั้ง

Cursor เป็น AI code editor ที่พัฒนาโดยบริษัท Anysphere และเป็น fork ของ VS Code จึงหน้าตาและการใช้งานคุ้นมือทันทีสำหรับคนที่เคยใช้ VS Code

เข้าเว็บทางการ cursor.com แล้วกดปุ่ม Download ระบบจะตรวจ OS ของคุณให้อัตโนมัติ (macOS / Windows / Linux)
ติดตั้งตามระบบปฏิบัติการ:
- macOS: เปิดไฟล์ .dmg แล้วลาก Cursor เข้าโฟลเดอร์ Applications
- Windows: รันไฟล์ installer (.exe)
- Linux: เปิดไฟล์ .AppImage (อาจต้อง chmod +x ก่อน) หรือใช้แพ็กเกจตามดิสโทร
เปิดโปรแกรมครั้งแรก จะพบหน้า onboarding ให้ตั้งค่าเบื้องต้น

หากอยากใช้งานผ่าน terminal ด้วย สามารถติดตั้ง Cursor CLI เพิ่มได้ (มีประโยชน์สำหรับสั่ง agent จากบรรทัดคำสั่งและ cloud handoff — จะลงรายละเอียดในบทหลัง):

# macOS / Linux / WSL
curl https://cursor.com/install -fsS | bash

# Windows PowerShell
irm 'https://cursor.com/install?win32=true' | iex

💡 ควรติดตั้งคำสั่ง cursor ให้เรียกจาก terminal ได้ด้วย โดยเปิด Command Palette (Cmd/Ctrl+Shift+P) แล้วค้นหา "Install 'cursor' command" เพื่อเปิดโฟลเดอร์ด้วย cursor . ได้เหมือน code .

2.2 ย้ายจาก VS Code แบบคลิกเดียว

จุดขายสำคัญของ Cursor คือย้ายสภาพแวดล้อมเดิมมาได้เกือบทั้งหมดในไม่กี่คลิก

วิธีที่ 1 — Import อัตโนมัติ (แนะนำสำหรับคนส่วนใหญ่)

เปิด Cursor Settings ด้วย Cmd/Ctrl+Shift+J
ไปที่ General > Account
กดปุ่ม Import ภายใต้หัวข้อ VS Code Import

Cursor จะย้าย Extensions, Themes, Settings และ Keybindings มาให้อัตโนมัติ ตอน onboarding ครั้งแรกมักมีปุ่มนี้ให้กดอยู่แล้ว

วิธีที่ 2 — ผ่าน VS Code Profiles (เหมาะกับหลายเครื่อง)

ใน VS Code เปิด Command Palette แล้วเลือก "Preferences: Open Profiles (UI)" จากนั้น Export Profile เป็นไฟล์หรือ GitHub Gist แล้วนำมา Import เข้า Cursor วิธีนี้ควบคุมได้ละเอียดและทำซ้ำข้ามเครื่องได้สะดวก

⚠️ ข้อควรระวังเรื่อง extensions: Cursor ดึง extension จาก Open VSX Registry (ดูแลโดย Eclipse Foundation) ไม่ใช่ marketplace ของ Microsoft ดังนั้น extension proprietary บางตัวของ Microsoft (เช่นบางส่วนของชุด C++/C#/Remote บางรุ่น) อาจติดตั้งไม่ได้ แม้ราว 90% ของ extension จะเผยแพร่ในทั้งสอง registry หากตัวไหนหาไม่เจอ ให้มองหา extension ทางเลือกที่เทียบเท่า

2.3 ล็อกอิน

หลังติดตั้ง ให้ล็อกอินเพื่อเปิดใช้ฟีเจอร์ AI:

กดปุ่ม Sign In / Sign Up (มุมขวาบน หรือในหน้า onboarding)
ระบบจะเปิด browser ให้ยืนยันตัวตน (รองรับ Google, GitHub, อีเมล)
เมื่อยืนยันเสร็จ browser จะ redirect กลับเข้าแอปโดยอัตโนมัติ

แผน Hobby (Free) ไม่ต้องใส่บัตรเครดิต ใช้ทดลองได้ทันที ส่วนแผนเสียเงินสามารถอัปเกรดภายหลังได้จากหน้า Settings หรือ dashboard บนเว็บ

flowchart LR
    A[ดาวน์โหลดจาก<br/>cursor.com] --> B[ติดตั้งตาม OS]
    B --> C[เปิดแอปครั้งแรก]
    C --> D[Import จาก VS Code<br/>ext / settings / theme / keys]
    D --> E[Sign In]
    E --> F[เลือกแผน<br/>Free หรือ Paid]
    F --> G[ตั้งค่าวันแรก<br/>โมเดล / Privacy / Rules]

2.4 ภาพรวมและตารางเทียบแผน (ณ ปี 2026)

จุดที่ต้องเข้าใจก่อน: กลางปี 2025 Cursor เลิกคิดเงินแบบนับจำนวน request (ระบบเดิม "500 fast requests") และเปลี่ยนมาเป็นแบบ token/credit-based ตามต้นทุน API จริง โมเดลต่างชนิดกินเครดิตในอัตราต่างกัน สิ่งที่ทุกแผนเสียเงินได้เหมือนกันคือ Tab completion ไม่จำกัด (ไม่หักเครดิต)

ราคาด้านล่างเป็นราคาโดยประมาณ ณ ปี 2026 อาจเปลี่ยนแปลง ควรยืนยันที่หน้า pricing ทางการอีกครั้ง (รายปีมักลดราว 20%):

แผน	ราคา (โดยประมาณ)	เครดิตโมเดล third-party	จุดเด่นสำคัญ	เหมาะกับใคร
Hobby (Free)	$0 (ไม่ต้องใส่บัตร)	ไม่มี pool เครดิต	Agent request จำกัด, ใช้ Composer ได้, Privacy Mode ได้	ผู้เริ่มต้น / ทดลอง / ใช้เป็นครั้งคราว
Pro	~$20/เดือน	~$20/เดือน (ราคา API)	Tab ไม่จำกัด, ทุก frontier model, MCP/Cloud Agents, Bugbot (usage-based)	นักพัฒนาทั่วไปที่ใช้ประจำ
Pro+	~$60/เดือน	~$70/เดือน (ราว 3x Pro)	เหมือน Pro แต่ลิมิต Agent สูงกว่า ~3 เท่า	คนที่ใช้ Agent เป็นประจำทุกวัน
Ultra	~$200/เดือน	~$400/เดือน (ราว 20x Pro)	priority access ฟีเจอร์ใหม่, เครดิตสูงสุด	power user / งานหนักตลอดวัน
Teams (Standard)	~$40/ผู้ใช้/เดือน	~$20/ผู้ใช้/เดือน	SSO (SAML/OIDC), billing รวมศูนย์, team privacy mode, analytics, shared context	ทีม/บริษัทเล็ก-กลาง
Teams (Premium)	~$120/ผู้ใช้/เดือน	ราว 5x Standard	ลิมิต Agent สูงกว่ามาก + ฟีเจอร์ทีมครบ	ทีมที่ใช้ Agent หนัก
Enterprise	custom	ตามตกลง	SCIM, MDM deploy, audit logs, CMEK, admin policy	องค์กรที่มีข้อกำหนดความปลอดภัยสูง

หมายเหตุเพิ่มเติม:

เมื่อเครดิตรวมต่อเดือนหมด ยังใช้งานต่อได้แบบ pay-as-you-go ที่อัตรา API เดิม
Cursor แจ้งว่าผู้ที่ใช้ Agent ทุกวันโดยทั่วไปมีค่าใช้จ่ายจริงราว $60–$100/เดือน จึงแนะนำ Pro+ สำหรับผู้ใช้ Agent รายวัน และ Ultra สำหรับ power user
แผน Teams/Enterprise มี surcharge เพิ่มราว $0.25 ต่อล้าน token สำหรับคำขอโมเดล third-party
มีแผนภูมิภาคเฉพาะ เช่น 'Start' ในอินเดีย (~₹649/เดือน รวมภาษี) ที่ให้โควตาโมเดลของ Cursor เยอะแต่ไม่มีเครดิต third-party

💡 คำแนะนำการเลือกแผนแบบสั้น: เริ่มที่ Free เพื่อลองก่อน → ถ้าใช้จริงจังทุกวันขึ้น Pro → ถ้ารู้สึกว่าเครดิตหมดเร็วหรือใช้ Agent หนักขึ้น Pro+ → power user ที่รันหลาย agent ตลอดวันค่อยพิจารณา Ultra → ทำงานเป็นทีมและต้องการ SSO/สิทธิ์ควบคุมกลางไปที่ Teams

2.5 การตั้งค่าที่ควรทำในวันแรก

หลังล็อกอินและ import เสร็จ แนะนำจัดการเหล่านี้ก่อนเริ่มงานจริง:

1) เลือกและจัดการโมเดล — ไปที่ Settings > Models เพื่อเปิด/ปิดโมเดลที่จะใช้ Cursor รวมโมเดลจากหลายผู้ผลิต (OpenAI/GPT, Anthropic/Claude, Google/Gemini, xAI/Grok และอื่น ๆ) รวมถึงโมเดล first-party ตระกูล Composer ที่เร็วและประหยัด หากไม่อยากเลือกเองทุกครั้ง ให้ตั้ง Auto mode ที่ Cursor จะเลือกโมเดลเหมาะสมให้อัตโนมัติในแต่ละคำขอ

⚠️ ชื่อรุ่นและรุ่นที่เปิดให้ใช้ เปลี่ยนบ่อยมาก ให้ยึด model picker จริงในแอป เป็นหลัก (ตรวจรายชื่อล่าสุดได้ที่ cursor.com/docs/models) อย่าจำชื่อรุ่นตายตัว

2) ตั้งค่า Privacy Mode — ในหน้า settings สามารถเปิด Privacy Mode ซึ่งทำให้โค้ดของคุณ ไม่ถูกนำไปเทรนโมเดล และไม่ถูกเก็บบนเซิร์ฟเวอร์ของ Cursor (zero data retention) โค้ดยังถูกส่งไปประมวลผลคำตอบ แต่ไม่ถูกเก็บไว้หลังตอบเสร็จ ใช้ได้ทั้ง Free และ Pro หากทำงานกับโค้ดของบริษัท แนะนำเปิดไว้ตั้งแต่วันแรก

3) BYOK (ถ้าต้องการ) — ถ้าอยากใช้ API key ของตัวเอง ใส่ได้จากผู้ให้บริการ OpenAI, Anthropic, Google, Azure และ AWS Bedrock โดย key จะเก็บใน local settings ไม่ sync ข้ามเครื่อง

⚠️ BYOK ใช้ได้กับ chat models เท่านั้น ส่วน Tab completion ยังใช้โมเดล built-in ของ Cursor เสมอ และเมื่อใช้ key ตัวเอง นโยบาย Zero Data Retention ของ Cursor จะไม่มีผล (ขึ้นกับข้อกำหนดของผู้ให้บริการโมเดลที่คุณเลือก)

4) วาง Rules เริ่มต้น — สร้างโฟลเดอร์ .cursor/rules ในโปรเจกต์เพื่อเก็บ Project Rules (ไฟล์ .mdc) กำหนดสไตล์โค้ด ภาษา และข้อกำหนดของทีม รวมถึงตั้ง User Rules ระดับ global ได้ใน Settings — จะลงลึกในบทว่าด้วย Rules

5) เปิดโปรเจกต์เพื่อให้ Cursor index — เมื่อเปิดโฟลเดอร์โปรเจกต์ Cursor จะสแกนและสร้าง index สำหรับ semantic search โปรเจกต์เล็กเสร็จเกือบทันที ส่วน repo ใหญ่ใช้เวลานานกว่า ดูสถานะได้ที่ status bar และควรวางไฟล์ .cursorignore เพื่อกันไฟล์ generated/ขนาดใหญ่ออกจาก index (ไฟล์ใน .gitignore ถูกยกเว้นอัตโนมัติอยู่แล้ว)

6) ทำความคุ้นกับคีย์ลัดหลัก — ก่อนไปบทถัดไป ลองจดจำสี่ตัวนี้:

การทำงาน	macOS	Windows/Linux
ยอมรับ Tab suggestion	`Tab`	`Tab`
Inline Edit (แก้โค้ดที่เลือก)	`Cmd K`	`Ctrl K`
เปิด Chat/Agent (ส่งโค้ดที่เลือกเป็น context ได้)	`Cmd L`	`Ctrl L`
เปิด Chat/Agent (มักผูกกับ Composer/Agent)	`Cmd I`	`Ctrl I`
เปิด Cursor Settings	`Cmd Shift J`	`Ctrl Shift J`

⚠️ หมายเหตุเรื่องคีย์ลัด Chat/Agent: เอกสารทางการจัด Cmd/Ctrl I และ Cmd/Ctrl L ไว้กลุ่มเดียวกัน (ทั้งคู่เปิดหน้าต่าง Chat/Agent) โดยทั่วไป Cmd/Ctrl L มักใช้เปิดแชทพร้อมส่งโค้ดที่เลือกเป็น context ส่วน Cmd/Ctrl I มักผูกกับ Composer/Agent แต่ mapping ที่แน่นอนต่างกันได้ตามเวอร์ชัน ให้ยึดคีย์ลัดจริงในแอป (ค้นหาใน keyboard shortcuts settings หรือดูที่ cursor.com/docs/reference/keyboard-shortcuts) เป็นหลัก

เมื่อทำครบทั้งหมดนี้ คุณจะมี Cursor ที่ตั้งค่าเรียบร้อย ปลอดภัยตามนโยบายของคุณ และพร้อมใช้ฟีเจอร์ AI เต็มรูปแบบตั้งแต่วันแรก บทถัดไปจะเจาะลึกฟีเจอร์แกนหลัก ได้แก่ Tab, Inline Edit และ Chat

บทที่ 3: โมเดล AI ใน Cursor และการเลือกใช้ให้เหมาะกับงาน

หัวใจสำคัญที่ต้องเข้าใจตั้งแต่ต้นคือ Cursor ไม่ได้เป็นผู้สร้างโมเดล AI ระดับ frontier เอง แต่ทำหน้าที่เป็น "ตัวกลาง" ที่รวมโมเดลจากหลายผู้ผลิตเข้ามาไว้ในที่เดียว แล้วให้คุณเลือกใช้ผ่าน model picker พร้อมทั้งเสริมเทคโนโลยีเฉพาะของตัวเอง (เช่น การ index codebase, Tab autocomplete และโมเดล first-party ตระกูล Composer) เพื่อให้โมเดลเหล่านั้นทำงานกับโค้ดของคุณได้อย่างมีบริบท

💡 หลักคิดที่ควรจำไว้ทั้งบท: ชื่อรุ่นและรายชื่อโมเดลใน Cursor เปลี่ยนบ่อยมาก (บางเดือนมีรุ่นใหม่เข้ามา บางรุ่นถูกถอดออก) อย่ายึดชื่อรุ่นที่จำมา ให้เปิด model picker จริงในแอปและหน้า cursor.com/docs/models เป็นแหล่งอ้างอิงสุดท้ายเสมอ

3.1 Cursor เลือกใช้โมเดลจากที่ไหนบ้าง

ณ ปี 2026 Cursor รวมโมเดลจากผู้ให้บริการหลักไว้ครบ ได้แก่

OpenAI — ตระกูล GPT (เช่น รุ่น GPT-5.x)
Anthropic — ตระกูล Claude (Opus / Sonnet)
Google — ตระกูล Gemini (เช่น Gemini 3.x Pro)
xAI — ตระกูล Grok
ผู้ให้บริการอื่น ๆ ที่ทยอยเพิ่มเข้ามา เช่น Z.ai (GLM) และ Moonshot (Kimi)
โมเดล first-party ของ Cursor เอง — ตระกูล Composer (เช่น Composer 2.5) ซึ่งเป็นโมเดล agentic coding ที่เน้น เร็วและถูกกว่า โมเดล frontier ของบุคคลที่สาม งานส่วนใหญ่จบในไม่กี่วินาที

คุณเปิด/ปิดโมเดลที่ต้องการให้แสดงใน picker ได้ที่ Settings > Models เพื่อไม่ให้ dropdown รก และเหลือเฉพาะรุ่นที่คุณใช้จริง

3.2 Auto mode กับการเลือกโมเดลเอง

Cursor มีสองแนวทางหลักในการกำหนดว่าคำขอแต่ละครั้งจะใช้โมเดลอะไร

Auto mode คือให้ Cursor เลือกโมเดลที่ "เหมาะสม" ให้อัตโนมัติในแต่ละคำขอ แทนที่คุณจะต้องตัดสินใจเอง เหมาะกับคนที่ไม่อยากคิดมากเรื่องเลือกรุ่น และช่วยบริหารต้นทุนโดยไม่ต้องจับตาทีละครั้ง โดยทั่วไปตามเงื่อนไขแผน Pro ปัจจุบัน Auto มักใช้ได้แบบไม่จำกัด และไม่ตัดโควตาเครดิตแบบเดียวกับการเรียกโมเดล frontier ตรง ๆ (ผู้ใช้เดิมบางรายอาจเลือกคงวิธีคิดโควตาแบบ legacy ไว้ ทำให้เงื่อนไขต่างออกไป — ควรตรวจสอบในหน้าแผน/บิลของคุณเอง)

ในเอกสารเวอร์ชันปี 2026 มีการอธิบายว่า Auto ถูกซอยเป็นหลายโหมดย่อย (เช่น Auto Cost, Auto Balance, Auto Intelligence) ที่ต่างกันเรื่องกลยุทธ์เลือกโมเดลและวิธีคิดเงิน โดยบางโหมดจำกัดเฉพาะแผน Teams/Enterprise รายละเอียดนี้เปลี่ยนแปลงได้ ควรตรวจสอบใน Settings อีกครั้ง

การเลือกโมเดลเอง คือคุณกดเลือกรุ่นเจาะจงจาก model picker ในหน้าต่างแชท/Agent เหมาะเมื่อคุณ "รู้แล้ว" ว่างานนี้ต้องการโมเดลตัวไหน เช่น ต้องการความสามารถ reasoning สูงสุดสำหรับ refactor ที่ซับซ้อน หรือต้องการรุ่นที่เร็ว/ถูกสำหรับงานซ้ำ ๆ

3.3 Max mode คืออะไร

Max mode เป็นตัวเลือกเสริมที่ ขยาย context window ของโมเดลให้ใหญ่ที่สุดเท่าที่รุ่นนั้นรองรับ (บางรุ่นสูงถึงระดับ ~1M tokens) เหมาะกับงานที่ต้องให้โมเดลเห็นบริบทจำนวนมากพร้อมกัน เช่นไล่โค้ดข้ามหลายสิบไฟล์ในคราวเดียว

ข้อแลกเปลี่ยนคือ Max mode คิดเงินแบบ token-based ตาม API rate ของโมเดล (บวกส่วนเพิ่ม) ซึ่ง แพงกว่าคำขอปกติมาก และรองรับเฉพาะบางโมเดลที่ context ยาว เช่นตระกูล Claude Opus/Sonnet และ GPT รุ่นใหม่ ไม่ใช่ทุกรุ่นที่เลือกได้

⚠️ บางแหล่งระบุว่า Max Mode อาจมีเงื่อนไขผูกกับบางแผน (เช่น legacy request-based plans) และโครงสร้างราคาก็เปลี่ยนบ่อย ข้อมูลส่วนนี้ยังไม่ชัดเจนและอาจล้าสมัย — ปัจจุบัน Max mode มักใช้ได้บนการคิดเงินแบบ token/credit ทั่วไป โปรดตรวจสอบเงื่อนไขล่าสุดใน Settings หรือหน้าราคาของ Cursor เอง ไม่ว่ากรณีใด อย่าเปิด Max mode ทิ้งไว้เป็นค่าเริ่มต้นโดยไม่จำเป็น เพราะเครดิต/ค่าใช้จ่ายจะหมดเร็วกว่าที่คาด — เปิดเฉพาะตอนที่งานต้องการ context ขนาดใหญ่จริง ๆ

3.4 Bring Your Own Key (BYOK) — ใส่ API key ของตัวเอง

หากคุณมีบัญชี API ของผู้ให้บริการอยู่แล้ว Cursor รองรับการใส่ API key ของตัวเอง จาก OpenAI, Anthropic, Google, Azure และ AWS Bedrock จุดที่ต้องเข้าใจก่อนใช้

BYOK ใช้ได้กับ chat models เท่านั้น ส่วนฟีเจอร์ Tab completion ยังคงใช้โมเดล built-in ของ Cursor แทนด้วย key ของคุณไม่ได้
API key ถูกเก็บใน local settings ของเครื่อง ไม่ sync ข้ามเครื่อง
เมื่อใช้ key ของตัวเอง นโยบาย Zero Data Retention ของ Cursor จะไม่มีผล ความเป็นส่วนตัวของข้อมูลจะขึ้นกับข้อกำหนดของผู้ให้บริการที่คุณเลือกแทน

💡 BYOK เหมาะกับองค์กรที่มีสัญญา/เครดิต API เดิมอยู่แล้ว หรือคนที่อยากคุมบิลฝั่ง provider เอง แต่ถ้าเป้าหมายคือความสะดวกและใช้ Tab อย่างเต็มที่ การจ่ายแผน Pro ของ Cursor ตรง ๆ มักคุ้มและง่ายกว่า

3.5 หลักการเลือกโมเดลตามประเภทงาน

การเลือกโมเดลที่ดีไม่ใช่ "เลือกรุ่นที่เก่งที่สุดเสมอ" แต่คือ จับคู่ความสามารถของโมเดลกับลักษณะงานและต้นทุน ภาพรวมการตัดสินใจเป็นดังนี้

flowchart TD
    A[งานที่ต้องทำ] --> B{ประเภทงาน?}
    B -->|Autocomplete<br/>ขณะพิมพ์| C[Cursor Tab<br/>โมเดล built-in]
    B -->|แก้เล็ก ๆ<br/>รวดเร็ว| D[Composer / รุ่นเร็ว<br/>หรือ Auto]
    B -->|งาน agent<br/>ซับซ้อน หลายไฟล์| E{ต้องการ context<br/>ใหญ่มากไหม?}
    E -->|ไม่| F[Claude Opus/Sonnet<br/>GPT-5.x, Gemini 3.x Pro]
    E -->|ใช่ เกินปกติ| G[เปิด Max mode<br/>กับรุ่น context ยาว]
    C --> H[ไม่กินเครดิต usage]
    D --> I[ประหยัด เร็ว]
    F --> J[คุณภาพ reasoning สูง]
    G --> K[แพงสุด ใช้เท่าที่จำเป็น]

ตารางสรุปแนวทางเลือกใช้ (ยึด model picker จริงเป็นหลัก ชื่อรุ่นเปลี่ยนได้):

ประเภทงาน	ตัวเลือกที่เหมาะ	เหตุผล / ข้อสังเกต
Autocomplete ขณะพิมพ์ (Tab)	โมเดล built-in ของ Cursor	เร็วมาก ปรับแต่งเพื่องานนี้โดยเฉพาะ ไม่กินเครดิต และ BYOK แทนไม่ได้
งานแก้เล็ก ๆ / ทำซ้ำบ่อย	Composer (first-party) หรือ Auto	เร็ว ประหยัดเครดิต งานส่วนใหญ่จบในไม่กี่วินาที
ไม่อยากเลือกเอง / คุมต้นทุน	Auto mode	Cursor เลือกรุ่นให้ บน Pro โดยทั่วไปใช้ได้ไม่จำกัด (ตามเงื่อนไขแผนปัจจุบัน)
งาน agent ซับซ้อน หลายไฟล์ วางแผน	Claude Opus รุ่นล่าสุด	แข็งด้าน agentic/reasoning ยาว ๆ (GPT-5.x, Gemini 3.x Pro เป็นทางเลือกที่ดี)
ต้องเห็นบริบทมหาศาลพร้อมกัน	รุ่น context ยาว + Max mode	ขยาย context ถึงระดับ ~1M tokens แต่ แพงสุด
มีเครดิต API เดิม / คุมบิลเอง	BYOK (OpenAI/Anthropic/Google/Azure/Bedrock)	ใช้กับ chat เท่านั้น, ZDR ของ Cursor ไม่มีผล

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

⚠️ ไม่ว่าจะเลือกโมเดลใด ต้องมี human review เสมอ โมเดลที่เก่งที่สุดก็ยัง hallucinate ได้ เช่นสร้างเมธอด/API ที่ไม่มีจริง หรืออ้างว่าแก้บั๊กสำเร็จทั้งที่รันเทสต์ผิดตัว โดยเฉพาะในโค้ดเบสขนาดใหญ่มากหรือกับ API เฉพาะทางที่ข้อมูลเทรนมีน้อย การเลือกโมเดลให้เหมาะช่วยลดความเสี่ยงได้ แต่ไม่ได้แทนการตรวจของมนุษย์

บทที่ 4: ฟีเจอร์หลัก: Tab (Autocomplete), Cmd/Ctrl+K (Inline Edit) และ Chat

Cursor มีฟีเจอร์ AI จำนวนมาก แต่ในการทำงานจริงประจำวัน มีอยู่ 3 ตัวที่คุณจะแตะแทบทุกนาที ได้แก่ Tab (autocomplete อัจฉริยะ), Cmd/Ctrl+K (แก้/สร้างโค้ดตรงตำแหน่ง) และ Chat (ถาม-ตอบและ apply โค้ดกลับเข้าไฟล์) การเข้าใจว่าแต่ละตัวเหมาะกับงานแบบไหนและใช้คีย์ลัดให้คล่อง จะเปลี่ยนความเร็วการเขียนโค้ดของคุณอย่างเห็นได้ชัด

ก่อนอื่น ทำความเข้าใจภาพรวมว่าเมื่อไรควรใช้ตัวไหน:

flowchart TD
    A[ต้องการให้ AI ช่วย] --> B{ขนาดของงาน?}
    B -->|กำลังพิมพ์อยู่<br/>อยากให้เดาต่อ| C[Tab<br/>Autocomplete]
    B -->|แก้/สร้างโค้ด<br/>เฉพาะจุดที่เลือก| D[Cmd/Ctrl+K<br/>Inline Edit]
    B -->|ถาม-ตอบ อธิบาย<br/>งานหลายไฟล์| E[Chat / Agent]
    C --> F[กด Tab ยอมรับ<br/>Esc ปฏิเสธ]
    D --> G[พิมพ์คำสั่ง<br/>Return เพื่อ apply]
    E --> H[Apply โค้ด<br/>กลับเข้าไฟล์]

1. Tab — AI Autocomplete ที่ทำได้มากกว่าเติมคำ

Cursor Tab คือระบบ autocomplete ที่ขับเคลื่อนด้วย AI แต่ต่างจาก autocomplete แบบเดิมตรงที่มันไม่ได้เติมแค่ชื่อตัวแปรหรือฟังก์ชัน มันแนะนำโค้ดโดยอิงจาก การแก้ไขล่าสุดของคุณ, โค้ดรอบข้าง และ linter errors ทำให้สามารถ:

แก้ไข หลายบรรทัดพร้อมกัน (multi-line edit)
เพิ่ม import ที่ขาดให้อัตโนมัติ
แนะนำการแก้ไข ข้ามตำแหน่ง/ข้ามไฟล์ ตามรูปแบบที่คุณเพิ่งทำ

💡 Tab เก่งที่สุดเมื่อคุณทำงานแบบซ้ำ ๆ เช่น เปลี่ยนชื่อ property ใน object หลายจุด หรือแก้ pattern เดียวกันหลายบรรทัด พอคุณแก้จุดแรกเอง Tab มักเดาจุดถัดไปได้แม่นมาก

คีย์ลัดที่ต้องจำ:

กด Tab เพื่อยอมรับ (accept) คำแนะนำทั้งชุด
กด Escape หรือพิมพ์ต่อ เพื่อปฏิเสธ
ยอมรับ ทีละคำ (accept next word) ด้วย Cmd + → (Mac) หรือ Ctrl + → (Windows/Linux) — มีประโยชน์เมื่อคุณเห็นด้วยกับส่วนต้นของคำแนะนำแต่ไม่เอาส่วนหลัง

ฟีเจอร์ที่หลายคนพลาดคือ jump-in-file: หลังยอมรับคำแนะนำหนึ่งแล้ว ให้กด Tab อีกครั้ง Cursor จะ "กระโดด" ไปยังตำแหน่งถัดไปที่มันทำนายว่าคุณต้องแก้ต่อ ทำให้คุณไล่แก้ทั้งไฟล์ได้ด้วยการกด Tab รัว ๆ โดยไม่ต้องเลื่อนเมาส์

การควบคุม Tab: ที่มุมขวาล่างของหน้าต่างมีตัวบ่งชี้สถานะ Tab คลิกเพื่อ snooze ชั่วคราว, ปิดทั้งระบบ หรือจำกัดเฉพาะบางชนิดไฟล์ได้ หากต้องการเปลี่ยนคีย์ลัด ให้ค้นหา 'Accept Cursor Tab Suggestions' ใน keyboard shortcuts settings

⚠️ Tab completion ใช้โมเดล built-in ของ Cursor เสมอ แม้คุณจะใส่ API key ของตัวเอง (BYOK) ก็แทนที่โมเดลของ Tab ไม่ได้ — BYOK มีผลเฉพาะ chat models เท่านั้น ข่าวดีคือในทุกแผนแบบจ่ายเงิน (Pro, Pro+, Ultra) Tab ใช้ได้ไม่จำกัดและไม่กินเครดิต usage

2. Cmd/Ctrl+K — Inline Edit แก้โค้ดตรงตำแหน่ง

เมื่อคุณรู้ว่าต้องการแก้อะไร ณ จุดใดจุดหนึ่ง แต่ไม่อยากพิมพ์เอง ให้ใช้ Inline Edit วิธีใช้:

เลือก (select) โค้ดที่ต้องการแก้ (หรือวางเคอร์เซอร์ไว้เฉย ๆ ถ้าต้องการให้สร้างโค้ดใหม่)
กด Cmd+K (Mac) / Ctrl+K (Windows/Linux)
พิมพ์คำสั่งเป็นภาษาธรรมชาติ เช่น "แปลงเป็น async/await" หรือ "เพิ่ม error handling"
กด Return เพื่อ apply การแก้ไขกับโค้ดที่เลือก

Cursor จะแสดง diff ให้ดูก่อนว่าจะเปลี่ยนอะไรบ้าง คุณ accept หรือ reject ได้

คีย์ลัดสำคัญภายใน Inline Edit:

การกระทำ	Mac	Windows/Linux
เปิด Inline Edit	Cmd K	Ctrl K
สลับไปโหมด Quick question (ถามแทนแก้)	Opt Return	Alt Return
ยกเลิก	Cmd Shift Backspace	Ctrl Shift Backspace
สลับ focus กลับไปช่อง input	Cmd Shift K	Ctrl Shift K

💡 ถ้าคุณเลือกโค้ดแล้วกด Cmd/Ctrl+K แต่ระหว่างนั้นแค่อยาก "ถาม" ว่าโค้ดนี้ทำอะไร โดยยังไม่อยากให้แก้ ให้กด Opt/Alt Return เพื่อสลับเป็นโหมด Quick question ได้ทันที ไม่ต้องเปิด Chat แยก

ตัวอย่าง prompt สำหรับ Inline Edit ที่ใช้ได้จริง:

เขียน docstring ภาษาไทยอธิบายฟังก์ชันนี้
เปลี่ยน for loop นี้เป็น list comprehension
เพิ่ม type hints ให้พารามิเตอร์ทุกตัว
แยกส่วนนี้ออกเป็นฟังก์ชันย่อยชื่อ validateInput

Inline Edit เหมาะกับงาน เล็กถึงกลาง ในไฟล์เดียว ถ้างานเริ่มซับซ้อน แตะหลายไฟล์ หรือต้องรันคำสั่ง terminal ให้ยกระดับไปใช้ Chat/Agent แทน (ดูหัวข้อถัดไป และรายละเอียด Agent ในบทถัด ๆ ไป)

3. Chat — ถาม-ตอบ, อธิบายโค้ด และ Apply กลับเข้าไฟล์

Chat คือ sidepanel สำหรับสนทนากับ AI เกี่ยวกับ codebase ของคุณ เหมาะกับการถามคำถาม อธิบายโค้ดที่ไม่เข้าใจ วางแผน หรือให้ช่วยเขียนโค้ดชิ้นใหญ่ที่แตะหลายจุด

คีย์ลัดเปิด Chat และการส่งข้อความ:

เปิด Chat/Agent sidepanel: Cmd I หรือ Cmd L (Mac) / Ctrl I หรือ Ctrl L (Windows/Linux)
เลือกโค้ดก่อนแล้วกด Cmd L / Ctrl L เพื่อเปิด Chat โดยดึงโค้ดที่เลือกเข้าไปเป็น context ทันที — เป็นวิธีเริ่มบทสนทนาที่ตรงจุดที่สุด
ส่งข้อความด้วย Return; ในบางเวอร์ชัน Cmd Return ใช้ force send หรือค้นหา codebase (พฤติกรรมอาจต่างกันตามเวอร์ชัน — ตรวจสอบใน keyboard shortcuts)

การ Apply โค้ด: เมื่อ Chat ตอบกลับมาพร้อม code block คุณจะเห็นปุ่ม Apply เพื่อนำโค้ดนั้นเข้าไปในไฟล์ Cursor จะแสดง diff ให้ review ก่อน แล้วคุณจึง accept หรือ reject ได้ — นี่คือหัวใจของเวิร์กโฟลว์: AI เสนอ คุณตรวจ แล้วค่อยรับ

การให้ context ด้วย @-symbols: พิมพ์ @ ในช่อง Chat เพื่อดึงบริบทเข้ามา ช่วยให้คำตอบแม่นและลด hallucination รายการที่ใช้บ่อย:

@-symbol	ใช้ทำอะไร
@Files & Folders	อ้างอิงทั้งไฟล์หรือทั้งโฟลเดอร์เป็นบริบท
@Code	อ้างอิงเฉพาะ snippet/symbol — ควบคุมละเอียดกว่า @Files
@Docs	อ้างเอกสาร third-party ที่ Cursor index ไว้ (เพิ่ม custom docs ด้วย URL ได้)
@Web	ค้นเว็บแบบเรียลไทม์ สำหรับข้อมูล/ข่าวใหม่
@Git	อ้าง commit history หรือ diff เหมาะกับ review/แก้บั๊ก
@Recent Changes	การเปลี่ยนแปลงล่าสุดในไฟล์ที่เพิ่งแก้

💡 เลือกใช้ @Code แทน @Files & Folders เมื่อทำได้ เพราะการโยนทั้งไฟล์เข้าไปสร้าง noise และกิน context window โดยเปล่าประโยชน์ ยิ่งบริบทเจาะจง คำตอบยิ่งตรง

ตัวอย่าง prompt ใน Chat:

@Code อธิบายว่าฟังก์ชันนี้จัดการ race condition อย่างไร

@Files src/auth.ts เพิ่ม unit test ครอบคลุมกรณี token หมดอายุ

@Git ช่วยดู diff ล่าสุดว่าทำไม test ถึงเริ่ม fail

สรุปเปรียบเทียบ 3 ฟีเจอร์

ฟีเจอร์	เปิดด้วย	เหมาะกับ	ผลลัพธ์
Tab	พิมพ์โค้ดได้เลย	เติมโค้ดต่อ, แก้ pattern ซ้ำ ๆ	กด Tab ยอมรับทันที
Cmd/Ctrl+K	Cmd/Ctrl K	แก้/สร้างโค้ดเฉพาะจุด ไฟล์เดียว	diff ในบรรทัด, Return เพื่อ apply
Chat	Cmd/Ctrl L หรือ I	ถาม-ตอบ, อธิบาย, งานหลายจุด	ตอบในแชท + ปุ่ม Apply

แนวทางง่าย ๆ ในการเลือก: ถ้ากำลัง พิมพ์อยู่ ใช้ Tab; ถ้ารู้จุดที่จะแก้แต่ ขี้เกียจพิมพ์ ใช้ Cmd/Ctrl+K; ถ้าต้อง คิด อธิบาย หรือแตะหลายไฟล์ ใช้ Chat เมื่อคล่องทั้งสามตัวและสลับใช้ได้ลื่น คุณจะรู้สึกว่า Cursor ไม่ได้เป็นแค่ editor แต่เป็นคู่คิดที่อยู่ปลายนิ้วตลอดเวลา

⚠️ ไม่ว่าจะใช้ฟีเจอร์ไหน ให้ review diff ก่อน accept เสมอ โดยเฉพาะโค้ดที่ AI มั่นใจแต่ผิด (เช่น เรียก method ที่ไม่มีอยู่จริง) เป็นรูปแบบความผิดพลาดที่พบได้บ่อย human review คือด่านสุดท้ายที่ขาดไม่ได้

บทที่ 5: Agent และ Composer: ให้ Cursor วางแผนและแก้โค้ดหลายไฟล์

ในบทก่อนหน้าคุณได้เห็น Tab, Cmd/Ctrl+K และ Chat ซึ่งเป็นเครื่องมือระดับ "แก้ทีละจุด" แล้ว บทนี้จะพาไปสู่ความสามารถที่ทำให้ Cursor แตกต่างจาก editor ทั่วไปมากที่สุด นั่นคือ Agent ซึ่งเป็นโหมด agentic ที่ให้ AI วางแผน แก้โค้ดข้ามหลายไฟล์ รันคำสั่ง terminal และทำงานต่อเนื่องจนจบงาน โดยคุณยังคงเป็นผู้ควบคุมและยืนยันการเปลี่ยนแปลงทุกขั้น

Agent คืออะไร และทำงานแบบ agentic อย่างไร

Agent คือโหมดหลักของ Cursor ที่ให้ AI ทำงานแบบครบวงจร ไม่ใช่แค่ตอบข้อความ แต่ลงมือ "ทำ" จริง โดยเอกสารทางการระบุว่า ไม่มีการจำกัดจำนวน tool call ที่ Agent เรียกใช้ระหว่างทำงานหนึ่งงาน หมายความว่า Agent สามารถวนอ่านไฟล์ ค้น codebase แก้โค้ด แล้วรันเทสต์ซ้ำ ๆ ได้จนกว่างานจะเสร็จ

เครื่องมือหลักที่ Agent ใช้ได้แก่:

Edit files — เสนอและ apply การแก้ไขไฟล์ โดยคุณ review/apply ได้ก่อนยอมรับ
Shell commands — รันคำสั่ง terminal และอ่าน output (เช่น npm test, git diff) เพื่อตรวจผลงานตัวเอง
Semantic search / codebase — ค้นหาส่วนที่เกี่ยวข้องใน codebase ที่ index ไว้โดยอัตโนมัติ

จุดสำคัญของการทำงานแบบ agentic คือ Agent มี "loop" ในตัว: มันอ่านบริบท → ลงมือแก้ → รันคำสั่งเพื่อตรวจผล → ถ้าเจอ error ก็แก้ต่อ วนไปจนบรรลุเป้าหมายที่คุณสั่ง ต่างจาก Chat แบบเดิมที่ตอบทีเดียวแล้วรอคำสั่งถัดไป

💡 เลือกโค้ดในไฟล์แล้วกด Cmd L (Mac) / Ctrl L (Windows/Linux) เพื่อเปิด Agent พร้อมโค้ดที่เลือกเป็น context ทันที เหมาะกับงานที่รู้อยู่แล้วว่าต้องเริ่มจากตรงไหน

Plan Mode: วางแผนก่อนลงมือ

สำหรับฟีเจอร์ใหญ่หรือซับซ้อนที่มีหลายแนวทาง การปล่อยให้ Agent เขียนโค้ดทันทีมักได้ผลลัพธ์ที่หลุดจากความตั้งใจ Plan Mode ถูกออกแบบมาแก้ปัญหานี้ โดยขั้นตอนคือ:

Agent ถามคำถาม เพื่อความชัดเจนในสิ่งที่คลุมเครือ
Agent สำรวจ codebase เพื่อเข้าใจโครงสร้างจริง
Agent สร้างแผน implementation แบบละเอียด (แสดงผ่านแชทหรือไฟล์ markdown)
คุณ review และแก้ไขแผน ก่อนกดสั่งให้ build

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

ในตัว editor คุณสลับระหว่าง Agent mode กับ Plan Mode ได้ผ่าน mode picker (dropdown ในหน้าต่าง Agent) หรือกด Shift+Tab

โหมด (ในตัว editor)	เหมาะกับ	พฤติกรรม
Agent mode	งานเล็ก งานที่ทำบ่อย รู้ทางอยู่แล้ว	ลงมือแก้/รันคำสั่งได้เลย
Plan Mode	ฟีเจอร์ซับซ้อน มีหลายแนวทาง	สร้างแผนให้ review ก่อน build

💡 นอกจากสองโหมดข้างต้นในตัว editor แล้ว Cursor CLI (เครื่องมือบรรทัดคำสั่งแยกต่างหาก) ยังมี 3 โหมด คือ Agent, Plan และ Ask โดย Ask เป็นโหมด "อ่านอย่างเดียว" สำหรับสำรวจโค้ดโดยไม่แก้ไขไฟล์ ทั้งนี้ ณ ปี 2026 ยังไม่พบหลักฐานทางการว่าการกด Shift+Tab ในตัว editor จะสลับไปโหมด Ask ได้ (การสลับด้วย Shift+Tab ในตัว editor พูดถึงเฉพาะ Agent กับ Plan) — หากต้องการโหมด Ask ให้ตรวจสอบว่าใช้ผ่าน CLI หรือดูตัวเลือกจริงในแอปเวอร์ชันที่คุณใช้

ลำดับการทำงานของ Agent

sequenceDiagram
    participant U as ผู้ใช้
    participant A as Agent
    participant C as Codebase / Files
    participant T as Terminal
    U->>A: สั่งงาน (เช่น เพิ่มฟีเจอร์ auth)
    A->>C: ค้น codebase + อ่านไฟล์ที่เกี่ยว
    A-->>U: (Plan Mode) เสนอแผน + ถามคำถาม
    U->>A: review / แก้แผน / อนุมัติ
    A->>C: เสนอ Edit files หลายไฟล์
    A->>T: ขออนุมัติรันคำสั่ง (เช่น npm test)
    U->>T: ยืนยันรัน
    T-->>A: ส่ง output / error กลับ
    A->>C: แก้เพิ่มจนผ่าน
    A-->>U: สรุป diff ให้ review/apply
    U->>C: Accept หรือ Reject การเปลี่ยนแปลง

การควบคุมและยืนยันการเปลี่ยนแปลง

Agent ทรงพลัง แต่หัวใจของการใช้อย่างปลอดภัยคือ คุณยังเป็นคนกดยืนยัน ไม่ใช่ AI:

Review diff ก่อน apply — Agent แสดงการเปลี่ยนแปลงเป็น diff คุณ Accept/Reject ได้ทีละไฟล์หรือทั้งชุด
Approval ก่อนรันคำสั่ง terminal — โดยค่าเริ่มต้น คำสั่ง shell ต้องได้รับการยืนยันจากคุณก่อน และคุณตั้ง Run Modes / auto-run (allowlist) เพื่ออนุมัติเฉพาะคำสั่งที่ปลอดภัยแบบอัตโนมัติได้
ข้อความที่ queue ไว้ จะถูก execute เมื่อ Agent พร้อม และจัดลำดับใหม่ได้

⚠️ อย่าเปิด auto-run แบบเหมารวมกับคำสั่งที่เปลี่ยนสถานะถาวร (เช่น rm -rf, git push --force, migration ฐานข้อมูล จริง) ให้จำกัด allowlist ไว้เฉพาะคำสั่งอ่าน/เทสต์ที่ย้อนกลับได้ และคง approval ไว้กับส่วนที่เสี่ยง

Composer และ Cloud Agents

Composer คือโมเดล first-party ของ Cursor เอง (เช่นตระกูล Composer 2.5) ที่ถูกเทรนมาเพื่องาน agentic coding โดยเฉพาะ จุดขายคือ เร็วและประหยัดกว่า โมเดล frontier ของบุคคลที่สาม งานส่วนใหญ่เสร็จในไม่กี่วินาที เหมาะกับงานที่ทำบ่อยและต้องการรอบการทำงานสั้น ๆ สำหรับงานที่ยากเป็นพิเศษ คุณยังสลับไปใช้โมเดล frontier (เช่น Claude Opus, GPT-5.x, Gemini 3.x Pro) ผ่าน model picker ได้ตามต้องการ

สำหรับงานที่กินเวลานานหรือรันหลายงานพร้อมกัน Cloud Agents (เดิมชื่อ Background Agents ตามหมายเหตุในเอกสารทางการ) รันบน VM แยกที่ isolated ไม่ใช่บนเครื่องคุณ สามารถ build, test, โต้ตอบกับซอฟต์แวร์ที่แก้ไข และสร้าง merge-ready PR ได้ เอกสารทางการระบุว่ารัน agent แบบ parallel ได้ "มากเท่าที่ต้องการ" และรองรับสภาพแวดล้อม multi-repo (เช่นงานที่ครอบคลุมทั้ง frontend/backend/infra) รวมถึงเรียกใช้ MCP servers เพื่อเข้าถึงเครื่องมือภายนอกได้

💡 แหล่ง third-party ระบุว่า Cursor v3 เปิด "Agents Window" ที่ dispatch parallel agents แต่ละตัวใน git worktree แยก (มีรายงานว่าสูงสุด 8 ตัว) แต่ตัวเลขและวันที่นี้ ยังไม่ยืนยันจากเอกสารทางการ — ให้ยึดสิ่งที่เห็นจริงในแอปเวอร์ชันที่คุณใช้

แนวทางใช้กับงานฟีเจอร์ใหญ่อย่างปลอดภัย

การใช้ Agent กับฟีเจอร์ใหญ่ให้ได้ผลและปลอดภัย ควรทำเป็นระบบ:

เริ่มด้วย Plan Mode เสมอ สำหรับงานที่แตะหลายไฟล์ อ่านแผนให้จบก่อนกด build
ให้บริบทที่เจาะจงด้วย @-symbols — อ้าง @Files/@Folders ที่เกี่ยวข้องแทนการพึ่ง codebase ทั้งก้อน เพื่อลด noise และลดโอกาส hallucinate โดยเฉพาะใน repo ขนาดใหญ่ (เกิน ~500,000 บรรทัด AI มีแนวโน้มหา context ที่ถูกต้องไม่เจอ)
ตั้ง Rules ให้ Agent — วาง Project Rules ใน .cursor/rules (ไฟล์ .mdc) เพื่อกำหนดสไตล์โค้ด แนวทางเทสต์ และข้อห้าม ให้ Agent ทำตามทุกครั้ง
ทำงานบน branch แยกและใช้ git เป็นเซฟตี้เน็ต — commit บ่อย ๆ เพื่อให้ย้อนกลับได้ง่ายเมื่อ Agent หลุดทาง
ตรวจ output ของ terminal เอง — รูปแบบความผิดพลาดที่พบบ่อยคือ Agent "มั่นใจผิด ๆ" เช่น อ้างว่าแก้บั๊กสำเร็จทั้งที่รันเทสต์ผิดตัว หรือสร้างเมธอด/API ที่ไม่มีอยู่จริง
human review ก่อน merge เสมอ — โดยเฉพาะโค้ดที่แตะ auth, การเงิน, migration หรือ security

⚠️ อย่าถือว่าคำยืนยันของ Agent ว่า "เสร็จแล้ว/ผ่านแล้ว" เป็นความจริงเสมอไป ให้ยึด diff จริงและผลเทสต์ที่คุณเห็นด้วยตาเป็นหลัก การรวม Agent เข้ากับ workflow ที่มี branch, เทสต์ และ code review ที่ดี คือสิ่งที่เปลี่ยน Agent จาก "ของเล่นที่น่าตื่นเต้น" ให้กลายเป็น "เพื่อนร่วมทีมที่พึ่งพาได้จริง"

บทที่ 6: การให้บริบทด้วย @-symbols และ Codebase Indexing

คุณภาพของคำตอบจาก AI ขึ้นกับ บริบท (context) ที่มันเห็นเป็นหลัก โมเดลที่เก่งแค่ไหนก็ตอบผิดได้ถ้าเดาว่าโค้ดของคุณหน้าตาเป็นอย่างไร Cursor แก้ปัญหานี้ด้วยสองกลไกที่ทำงานเสริมกัน คือ @-symbols (คุณเลือกป้อนบริบทเจาะจงเอง) และ codebase indexing (Cursor สร้างดัชนีทั้งโปรเจกต์ให้ค้นหาได้อัตโนมัติ) บทนี้จะสอนใช้ทั้งสองอย่างให้แม่นและประหยัด context window

@-symbols คืออะไร

ในช่อง Chat หรือ Agent เพียงพิมพ์เครื่องหมาย @ จะมีเมนูรายการบริบทให้เลือก คุณสามารถชี้ให้ AI ดูไฟล์ โฟลเดอร์ โค้ดเฉพาะส่วน เอกสาร หรือประวัติ Git ได้แบบเจาะจง แทนที่จะปล่อยให้มันเดาหรือค้นเองทั้งโปรเจกต์

💡 หลักการทอง: เจาะจงเข้าไว้ การป้อน @Files ที่เกี่ยวข้อง 2-3 ไฟล์ มักได้คำตอบแม่นกว่าและถูกกว่าการโยนทั้ง codebase ให้ AI ไปไล่หาเอง เพราะบริบทที่ noise น้อยช่วยลด hallucination

ตารางสรุป @-symbols หลัก

@-symbol	ใช้อ้างอิงอะไร	เหมาะกับสถานการณ์
@Files	เนื้อหาไฟล์ทั้งไฟล์	อยากให้ AI แก้/อ่านไฟล์ที่ระบุชัดเจน
@Folders	ทุกไฟล์ในโฟลเดอร์	ให้เข้าใจโครงสร้างของโมดูล/ฟีเจอร์
@Code	โค้ด snippet / symbol เฉพาะส่วน	ควบคุมละเอียดกว่า @Files เน้นฟังก์ชัน/คลาสเดียว
@Docs	เอกสาร third-party ที่ Cursor index ไว้ (เช่น MDN) + custom docs ที่เพิ่มด้วย URL	อ้างอิง API ของ library ให้ตรง ลด hallucinate
@Web	ค้นเว็บแบบเรียลไทม์	ข้อมูล/ข่าว/เอกสารใหม่ที่เกินความรู้ของโมเดล
@Git	commit history / diff	แก้บั๊ก, review, เข้าใจว่าเปลี่ยนอะไรไป
@Recent Changes	การแก้ไขล่าสุดในไฟล์ที่เพิ่งแตะ	ทำงานต่อจากสิ่งที่เพิ่งทำ
@Link	เนื้อหาจาก URL ที่ระบุ	ดึงหน้าเว็บ/บทความมาเป็นบริบท
@Linter Errors	error จาก linter	ให้ AI ช่วยไล่แก้ error ที่ค้างอยู่
@Past Chats	บทสนทนาเก่า	ต่อยอดจากงานที่คุยไว้ก่อนหน้า
@Cursor Rules	rule ที่ตั้งไว้ในโปรเจกต์	บังคับให้ AI ยึด rule ที่ต้องการในงานนั้น

⚠️ รายชื่อและชื่อเรียกของ @-symbols เปลี่ยนแปลงตามเวอร์ชันของแอป ให้พิมพ์ @ แล้วดูเมนูจริงในเวอร์ชันที่คุณใช้เป็นหลักเสมอ

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

แก้ฟังก์ชัน login ใน @Files src/auth/login.ts ให้รองรับ 2FA
โดยยึดรูปแบบ error handling ตามที่มีใน @Code validateSession

มีอะไรเปลี่ยนใน 3 commit ล่าสุด? ช่วยอธิบายจาก @Git
ว่าทำไม endpoint /users ถึงเริ่ม return 500

เขียน component ใหม่โดยใช้ hook ล่าสุดของ React ตาม @Docs React
และเช็คข่าว breaking change ล่าสุดด้วย @Web

Codebase Indexing: ให้ Cursor เข้าใจทั้งโปรเจกต์

เมื่อเปิดโปรเจกต์ Cursor จะสแกนไฟล์ต้นฉบับและสร้าง searchable index โดยอัตโนมัติ เพื่อรองรับ semantic search (ค้นด้วยความหมาย ไม่ใช่แค่คำตรงตัว) กลไกทำงานคร่าว ๆ คือ:

แบ่งโค้ดเป็น chunks แล้วคำนวณ embeddings
เก็บ embeddings ไว้ใน remote vector database ของ Cursor โดยไม่เก็บซอร์สโค้ดแบบ plaintext
index จะรีเฟรชอัตโนมัติเป็นระยะ (เอกสารระบุประมาณทุก ๆ 5 นาที)

โปรเจกต์เล็ก index เกือบทันที ส่วน repo ใหญ่หลายหมื่นไฟล์อาจใช้เวลานาน โดย Cursor มีเทคนิค reuse index ของเพื่อนร่วมทีมเพื่อลดเวลา time-to-first-query

flowchart TD
    A[เปิดโปรเจกต์] --> B{อ่าน .gitignore<br/>และ .cursorignore}
    B -->|ยกเว้นไฟล์ที่ไม่ต้องการ| C[แบ่งโค้ดเป็น chunks]
    C --> D[คำนวณ embeddings]
    D --> E[เก็บใน remote<br/>vector database]
    E --> F[Semantic search<br/>พร้อมใช้งาน]
    F --> G[Agent / Chat<br/>ค้นทั้ง codebase อัตโนมัติ]
    G -.->|ทุก ~5 นาที<br/>refresh| C

การถามข้ามไฟล์ (ค้นทั้ง codebase)

เมื่อ index พร้อม คุณสามารถถามคำถามที่ AI ต้องไปหาคำตอบจากหลายไฟล์ได้ โดย Agent จะสแกน codebase ที่ index ไว้เพื่อหาส่วนที่เกี่ยวข้องเอง เช่น:

ระบบเรากำหนดสิทธิ์ (authorization) ที่ไหนบ้าง?
ช่วยไล่ให้ดูว่ามีการเช็ค role ตรงไหน และมี middleware อะไรเกี่ยวข้อง

💡 ไวยากรณ์ @Codebase แบบเดิมสำหรับสั่งค้นทั้ง codebase ในแชท อาจถูกปรับหรือควบรวมเข้ากับ semantic search ของ Agent ในเวอร์ชันปี 2026 ถ้าไม่เห็นในเมนู ให้พิมพ์คำถามตรง ๆ ใน Agent ได้เลย — มันจะค้น index เองอยู่แล้ว

จัดการ index: สถานะ, Reindex และการยกเว้นไฟล์

ดูสถานะ / Reindex: ดูสถานะการ index ได้จาก status bar และสั่ง reindex ใหม่ผ่าน command palette (Cmd/Ctrl+Shift+P แล้วค้นคำว่า Reindex) การตั้งค่า indexing อยู่ใน Cursor Settings และมีตัวเลือกดูรายการไฟล์ที่ถูกรวม (View included files)
.cursorignore: ใช้ยกเว้นไดเรกทอรี/ไฟล์ไม่ให้ถูก index เช่น ไฟล์ generated ขนาดใหญ่ ส่วนไฟล์ที่อยู่ใน .gitignore (เช่น node_modules, dist, build artifacts) จะถูกยกเว้นโดยอัตโนมัติ
.cursorindexingignore: มีไว้ควบคุมการ index แยกจาก .cursorignore แต่รายละเอียดพฤติกรรมควรตรวจสอบกับเอกสารทางการ เพราะอาจเปลี่ยน

ตัวอย่าง .cursorignore:

# ตัดไฟล์ที่ไม่จำเป็นออกจาก index
/dist
/build
*.min.js
*.generated.ts
/fixtures/large-data

⚠️ index ที่ไม่ถูกใช้งานจะถูกลบหลังไม่มี activity ประมาณ 6 สัปดาห์ (นโยบายอาจเปลี่ยน) หากกลับมาเปิดโปรเจกต์เก่าแล้วรู้สึกว่า AI "ลืม" โครงสร้าง ลองสั่ง Reindex ดูก่อน

เทคนิคจัดการโปรเจกต์ขนาดใหญ่

โค้ดเบสที่ใหญ่มาก (เกินราว 500,000–1,000,000 บรรทัด) ทำให้ AI หา context ที่เกี่ยวข้องยากขึ้นและ hallucinate ง่ายขึ้น ใช้แนวทางเหล่านี้เพื่อรักษาคุณภาพ:

ใช้ .cursorignore ตัด noise — ตัดไฟล์ generated, vendored code, ไฟล์ข้อมูลขนาดใหญ่ ออกจาก index เพื่อให้ semantic search เจอโค้ดที่สำคัญจริง ๆ
อ้าง @Files/@Folders ให้เจาะจง แทนการพึ่ง semantic search ทั้งโปรเจกต์ — เมื่อคุณรู้ว่างานอยู่โมดูลไหน ชี้ตรงเข้าไปเลย จะได้คำตอบตรงและประหยัด context window
ใช้ @Code สำหรับความละเอียดระดับฟังก์ชัน — ในไฟล์ยาว ๆ อ้างเฉพาะ symbol ที่เกี่ยวข้อง ดีกว่าโยนทั้งไฟล์
ประกอบบริบทเป็นชั้น ๆ — เริ่มจากไฟล์หลักที่แก้ (@Files) แล้วเสริมด้วยตัวอย่างรูปแบบที่ต้องยึด (@Code) และเอกสาร API (@Docs) แทนที่จะให้ AI เดาทั้งหมด
จับคู่กับ Rules — สำหรับ convention ที่ต้องยึดเสมอ ให้ตั้งเป็น Project Rules (จะกล่าวในบทถัดไป) แทนที่จะพิมพ์ซ้ำทุกครั้ง

💡 คิดถึง context window เหมือนงบประมาณจำกัด ทุก token ที่ใช้ไปกับไฟล์ที่ไม่เกี่ยวข้อง คือ token ที่ AI มีน้อยลงสำหรับการคิดแก้ปัญหาจริง การ "ให้บริบทน้อยแต่ตรง" มักชนะ "ให้บริบทเยอะแต่มั่ว" เสมอ

การใช้ @-symbols ให้คล่องคือทักษะที่แยกผู้ใช้ Cursor มือใหม่กับมืออาชีพออกจากกัน เมื่อคุณควบคุมได้ว่า AI เห็นอะไรบ้าง คุณก็ควบคุมคุณภาพของผลลัพธ์ได้โดยตรง

บทที่ 7: Rules for AI และ .cursorrules: กำหนดกฎและสไตล์ให้ Cursor

โมเดล AI ใน Cursor เก่งเรื่องเขียนโค้ด แต่มัน "ไม่รู้" ธรรมเนียมเฉพาะของโปรเจกต์คุณ เช่น ทีมคุณใช้ TypeScript strict, ห้าม any, เรียก API ผ่าน service layer เท่านั้น, หรือใช้ Tailwind ไม่ใช่ CSS Modules สิ่งเหล่านี้ถ้าต้องพิมพ์บอกซ้ำทุกครั้งใน prompt จะเสียเวลาและ AI ก็ลืมได้ Rules for AI คือกลไกที่ให้คุณ "ฝัง" กฎเหล่านี้ไว้ถาวร เพื่อให้ Agent, Chat และ Inline Edit ทำตาม coding style, สถาปัตยกรรม และข้อห้ามของโปรเจกต์โดยอัตโนมัติ

ประเภทของ Rules

ณ กลางปี 2026 Cursor รองรับ rules หลายระดับ ซึ่งครอบคลุมตั้งแต่ระดับผู้ใช้ไปจนถึงระดับองค์กร

ประเภท	ที่เก็บ	ขอบเขต	Version control	หมายเหตุ
User Rules	Settings ของ Cursor	ทุกโปรเจกต์ในเครื่องคุณ	ไม่	ตั้งค่ากลาง เช่น ภาษาที่ใช้ตอบ, สไตล์ส่วนตัว
Project Rules	`.cursor/rules/*.mdc`	ผูกกับ codebase	ใช่ (commit เข้า git)	รูปแบบหลักที่แนะนำ
Team Rules	Dashboard (Team/Enterprise)	ทั้งองค์กร	จัดการผ่าน dashboard	เฉพาะแผน Team/Enterprise
AGENTS.md	ไฟล์ markdown	โปรเจกต์/โฟลเดอร์	ใช่	รูปแบบเรียบง่าย ไม่มี metadata
.cursorrules (legacy)	ไฟล์เดียวที่ root	ทั้งโปรเจกต์	ใช่	กำลังถูก deprecated แนะนำย้าย

ลำดับความสำคัญ (precedence) เมื่อกฎขัดแย้งกัน จะเรียงเป็น Team Rules → Project Rules → User Rules โดยแหล่งที่มาก่อนหน้าจะชนะ นอกจากนี้ยังรองรับ nested rules คือวาง .cursor/rules หรือ AGENTS.md ในโฟลเดอร์ย่อยได้ ไฟล์ที่ลึกกว่า (เฉพาะเจาะจงกว่า) จะมีความสำคัญเหนือไฟล์ระดับบน เหมาะกับ monorepo ที่ frontend/backend มีกฎต่างกัน

💡 .cursorrules (ไฟล์เดียวที่ root) ยังใช้ได้เพื่อ backward compatibility แต่ถูกแทนที่ด้วย .cursor/rules ตั้งแต่เวอร์ชัน 0.45 หากเริ่มโปรเจกต์ใหม่ปี 2026 ควรใช้ .cursor/rules/*.mdc ตั้งแต่แรก

User Rules: กฎส่วนตัวข้ามทุกโปรเจกต์

User Rules ตั้งได้ที่ Cursor Settings เหมาะกับสิ่งที่ติดตัวคุณไปทุกโปรเจกต์ เช่น

- ตอบอธิบายเป็นภาษาไทย แต่คงศัพท์เทคนิคภาษาอังกฤษไว้
- อย่าเพิ่งเขียนโค้ดยาว ถ้าคำสั่งกำกวมให้ถามให้ชัดก่อน
- เวลาแก้บั๊ก อธิบายสาเหตุ (root cause) ไม่ใช่แค่ patch อาการ
- อย่าใส่คอมเมนต์ที่อธิบายสิ่งที่โค้ดบอกอยู่แล้วชัดเจน

Project Rules: หัวใจของการควบคุม

Project Rules ต้องเป็นไฟล์นามสกุล .mdc ในโฟลเดอร์ .cursor/rules (ไฟล์ .md ธรรมดาในโฟลเดอร์นี้จะถูกละเว้น เพราะไม่มี frontmatter ยกเว้นกรณี AGENTS.md) แต่ละไฟล์มีส่วนหัว frontmatter 3 ฟิลด์หลัก

description — คำอธิบายสั้น ๆ ว่ากฎนี้เกี่ยวกับอะไร ช่วยให้ Agent ตัดสินใจว่าจะดึงกฎมาใช้หรือไม่
globs — pattern ไฟล์ เช่น src/**/*.tsx สำหรับ auto-attach เมื่อทำงานกับไฟล์ที่ตรง pattern
alwaysApply — boolean ถ้า true จะแนบทุก session (และระบบจะไม่สนใจ globs/description)

จากฟิลด์เหล่านี้เกิดรูปแบบการนำ rule มาใช้ 4 แบบ

flowchart TD
    A[Rule .mdc] --> B{alwaysApply?}
    B -->|true| C[Always Apply<br/>แนบทุก session]
    B -->|false| D{มี globs<br/>ตรงไฟล์?}
    D -->|ใช่| E[Auto Attached<br/>แนบเมื่อแก้ไฟล์ตรง glob]
    D -->|ไม่| F{มี description<br/>ที่เกี่ยวข้อง?}
    F -->|Agent เห็นว่าเกี่ยว| G[Agent Requested<br/>Apply Intelligently]
    F -->|ต้องเรียกเอง| H[Apply Manually<br/>ผ่าน @rule-name]

ตัวอย่างไฟล์ Project Rule

สมมติโปรเจกต์ React + TypeScript สร้างไฟล์ .cursor/rules/frontend.mdc

---
description: มาตรฐานการเขียน React component และ TypeScript ของโปรเจกต์
globs: src/**/*.{ts,tsx}
alwaysApply: false
---

# มาตรฐาน Frontend

## TypeScript
- เปิด strict mode เสมอ ห้ามใช้ `any` — ถ้าไม่รู้ type ให้ใช้ `unknown` แล้ว narrow
- ใช้ `type` สำหรับ props และ union, ใช้ `interface` เฉพาะเมื่อจะ extend

## React
- ใช้ function component + hooks เท่านั้น ห้าม class component
- ตั้งชื่อไฟล์ component แบบ PascalCase (เช่น UserCard.tsx)
- ดึงข้อมูลผ่าน hook ใน src/hooks ห้าม fetch ตรงใน component

## ข้อห้าม
- ห้าม import จาก node_modules ตรง ๆ ให้ผ่าน barrel file
- ห้ามใช้ inline style ใช้ TailShort class ตามที่วางใน components/ui

ดู pattern ของ component มาตรฐานได้ที่ @src/components/ui/Button.tsx

และไฟล์แยกสำหรับ backend .cursor/rules/api.mdc

---
description: กฎการเขียน API endpoint และการเข้าถึงฐานข้อมูล
globs: src/server/**/*.ts
alwaysApply: false
---

# มาตรฐาน API layer

- ทุก endpoint ต้อง validate input ด้วย zod schema ก่อนเสมอ
- เข้าถึง DB ผ่าน repository ใน src/server/repositories เท่านั้น
  ห้ามเรียก Prisma client ตรงจาก route handler
- คืน error เป็นรูปแบบ { error: { code, message } } เท่านั้น
- ห้าม log ข้อมูลที่มี PII (email, เบอร์โทร, token)

แนวทางที่ดี (best practices)

สั้นและเจาะจง เอกสารแนะนำให้ rule ยาวไม่เกิน ~500 บรรทัด กฎที่ยาวเกินไป AI จะให้น้ำหนักไม่ทั่วถึง
แยกไฟล์ตามหัวข้อ อย่ายัดทุกอย่างในไฟล์เดียว แยกเป็น frontend.mdc, api.mdc, testing.mdc แล้วใช้ globs ให้แต่ละไฟล์ถูกดึงมาเฉพาะตอนที่เกี่ยว
อ้างไฟล์ด้วย @filename แทนการคัดลอกเนื้อหา เช่น @src/components/ui/Button.tsx เพื่อชี้ตัวอย่างจริง แทนที่จะแปะโค้ดยาวเข้า rule (โค้ดจริงอัปเดตเองเมื่อไฟล์เปลี่ยน)
หลีกเลี่ยงการคัดลอก style guide ทั้งฉบับ สรุปเฉพาะข้อที่ AI มักทำผิด เขียนเป็นข้อ ๆ ที่ actionable ("ใช้ X ไม่ใช้ Y") ดีกว่าคำอธิบายลอย ๆ
เขียนเป็นคำสั่งเชิงบวก/ลบที่ชัด "ห้าม fetch ตรงใน component" ดีกว่า "พยายามจัดระเบียบการดึงข้อมูล"
commit เข้า git จุดแข็งของ Project Rules คือมันเป็นส่วนหนึ่งของ repo ทั้งทีมและ Cloud Agent ได้กฎเดียวกัน review การเปลี่ยนกฎผ่าน PR ได้เหมือนโค้ด

⚠️ Rules ช่วยกำหนดทิศทาง แต่ไม่ใช่การบังคับแบบ 100% โมเดลยังอาจ "ลืม" หรือฝ่าฝืนกฎได้ในบางครั้ง โดยเฉพาะเมื่อ context ยาวมาก จึงยังต้องมี human review และควรมี linter/CI เป็นด่านบังคับจริงควบคู่กันไป

เรียกใช้และตรวจสอบ

คุณสามารถ @-mention rule เข้ามาในแชทได้โดยตรง (เช่น @frontend หรือผ่าน @Cursor Rules) เมื่ออยากบังคับให้ Agent ยึดกฎนั้นในงานปัจจุบัน และเมื่อ Agent ทำงาน คุณจะเห็นว่ามีกฎใดถูกแนบเข้า context บ้าง หากพบว่า AI ทำผิดสไตล์ซ้ำ ๆ นั่นคือสัญญาณว่าควรเพิ่ม/ปรับข้อความในไฟล์ rule ให้ชัดขึ้น มองว่า .cursor/rules เป็น "เอกสารที่มีชีวิต" ที่โตไปพร้อมโปรเจกต์ ยิ่งกฎคมและตรงจุด Cursor ก็ยิ่งเขียนโค้ดได้ตรงใจทีมโดยไม่ต้องสั่งซ้ำ

บทที่ 8: การทำงานกับ Terminal การรันคำสั่ง และ MCP

บทนี้พาคุณข้ามจาก "AI ที่แก้โค้ดในไฟล์" ไปสู่ "AI ที่ลงมือทำงานจริงในระบบของคุณ" — สั่งงานผ่าน terminal, ให้ agent รันคำสั่งและอ่านผลลัพธ์เพื่อแก้ปัญหาต่อเนื่อง และการต่อเครื่องมือภายนอก (ฐานข้อมูล, GitHub, Figma ฯลฯ) เข้ากับ Cursor ผ่าน MCP (Model Context Protocol) พร้อมข้อควรระวังด้านความปลอดภัยที่ต้องเข้าใจก่อนเปิดใช้

8.1 ใช้ Cursor ช่วยงานใน Terminal

Cursor เป็น fork ของ VS Code จึงมี integrated terminal ครบเหมือนเดิม แต่เพิ่มความสามารถ AI เข้าไป ใช้งานได้ 3 รูปแบบหลัก:

อธิบายคำสั่ง / แก้คำสั่งที่ error: เมื่อรันคำสั่งแล้วเจอ error ให้เลือกข้อความ error ในหน้า terminal แล้วส่งเข้า Chat/Agent (Cmd L / Ctrl L) หรือใช้ @-symbol อ้างอิง terminal output เพื่อถามว่าเกิดอะไรขึ้นและควรแก้อย่างไร
สั่งด้วยภาษาธรรมชาติ: บอก agent ว่า "รัน migration แล้ว restart dev server" แล้วให้มันแปลงเป็นคำสั่งจริงและรันให้
สร้างคำสั่งที่จำยาก: ถามหา syntax ของ ffmpeg, awk, หรือ git rebase แทนการเปิดหาในเว็บ

💡 เมื่อ error พาดพิงหลายไฟล์หรือหลาย stack ให้เปิดด้วย Cmd L / Ctrl L เข้า Agent แทน Inline Edit เพราะ Agent ค้น codebase ที่ index ไว้และแก้ข้ามไฟล์ได้ในคราวเดียว

8.2 ให้ Agent รันคำสั่งและอ่านผลลัพธ์

หัวใจของ Agent mode คือมันไม่ได้แค่ "เขียนโค้ดให้ดู" แต่ ลงมือทำครบวงจร: แก้ไฟล์ → รันคำสั่ง terminal → อ่าน output → ตัดสินใจขั้นถัดไป เอกสารทางการระบุว่า Agent เรียก tool ได้ไม่จำกัดจำนวนครั้งภายในหนึ่งงาน จึงวน loop "รัน–ดูผล–แก้–รันใหม่" ได้จนกว่าจะสำเร็จ

Agent รันคำสั่งผ่านเครื่องมือ shell commands (Execute terminal commands and monitor output) ซึ่งหมายความว่ามันเห็นทั้ง exit code, stdout และ stderr แล้วนำมาใช้ต่อ เช่นวนแก้จน npm test ผ่าน, อ่าน log แล้วไล่หา root cause ของ bug, หรือรัน tsc เพื่อยืนยันว่า type ถูกต้อง

ตัวอย่าง prompt ที่ใช้พลังนี้ได้จริง:

รัน test suite ทั้งหมด อ่าน output แล้วแก้เทสต์ที่ fail
จนกว่าจะผ่านหมด อย่าแก้ logic ธุรกิจโดยไม่ถามฉันก่อน
รายงานสรุปว่าแก้อะไรบ้างตอนจบ

การตั้ง terminal profile (เช่นให้ใช้ zsh หรือ PowerShell) ทำได้ผ่าน Command Palette (Cmd/Ctrl+Shift+P)

⚠️ Agent สามารถรันคำสั่งที่ ทำลายข้อมูลได้ (rm -rf, git reset --hard, DROP TABLE) รูปแบบความผิดพลาดที่พบบ่อยคือ agent "มั่นใจผิด ๆ" — อ้างว่าแก้บั๊กสำเร็จทั้งที่รันเทสต์ผิดตัว จึงควรมี human review และอ่านคำสั่งก่อนอนุมัติเสมอ โดยเฉพาะคำสั่งที่ย้อนกลับไม่ได้

Auto-run / Run Modes กับความสมดุลระหว่างความเร็วและความปลอดภัย

ค่าเริ่มต้น Cursor จะ ขออนุมัติก่อนรันคำสั่ง คุณตั้ง allowlist (auto-run เฉพาะคำสั่งที่ไว้ใจ เช่น npm test, ls) เพื่อลดการกดยืนยันซ้ำ ๆ ได้ แต่ควรกันคำสั่งกลุ่มอันตรายไว้นอก allowlist เสมอ สำหรับงานที่เสี่ยง แนวทางปลอดภัยกว่าคือใช้ Cloud Agents ที่รันในเครื่อง VM แยก (isolated virtual machine) ไม่ใช่บนเครื่องคุณ ทำให้คำสั่งอันตรายไม่กระทบระบบจริง และยังสร้าง PR ที่พร้อม merge กลับมาได้

8.3 MCP (Model Context Protocol) คืออะไร

MCP เป็นมาตรฐานเปิดที่ให้ AI ต่อเข้ากับ เครื่องมือและแหล่งข้อมูลภายนอก ได้ในรูปแบบเดียวกัน คิดง่าย ๆ ว่า MCP คือ "พอร์ต USB สำหรับ AI" — แทนที่จะเขียน integration เฉพาะตัวสำหรับแต่ละบริการ คุณต่อ MCP server เข้ากับ Cursor แล้ว agent จะเรียกใช้ความสามารถของ server นั้นได้

MCP server ให้ความสามารถหลายแบบ (primitives): Tools (ฟังก์ชันให้ agent เรียก), Prompts, Resources (ข้อมูลให้อ่าน), Roots, Elicitation และส่วนขยาย Apps สำหรับ UI แบบโต้ตอบ; server ยังส่งภาพแบบ base64 ให้ AI วิเคราะห์ได้

ตัวอย่างสิ่งที่ทำได้เมื่อมี MCP:

ให้ agent query ฐานข้อมูล Postgres จริงเพื่อดู schema ก่อนเขียน query
อ่าน/สร้าง issue และ PR บน GitHub
ดึง design token จาก Figma มาเขียนเป็น CSS
ค้นเอกสารภายในองค์กร หรือเรียก API ของระบบภายใน

8.4 ตั้งค่า MCP ใน Cursor

Cursor อ่าน config MCP จาก 2 ตำแหน่ง:

ระดับ	ไฟล์	ขอบเขตการใช้งาน
Project	`.cursor/mcp.json` (ใน project root)	เฉพาะโปรเจกต์นั้น (commit เข้า git ได้เพื่อแชร์ทีม)
Global	`~/.cursor/mcp.json` (home directory)	ทุกโปรเจกต์ในเครื่อง

Cursor รองรับ transport 3 แบบ ควรเลือกให้ตรงกับลักษณะ server:

Transport	ที่ตั้ง	ผู้ใช้	การตั้งค่า
stdio	local	single user	Cursor รัน process ให้เอง (ระบุ command/args)
SSE	local/remote	multi-user	ระบุ URL ของ endpoint
Streamable HTTP	local/remote	multi-user	ระบุ HTTP endpoint

ตัวอย่าง config แบบ stdio (รัน server ในเครื่องผ่าน command):

{
  "mcpServers": {
    "postgres": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres"],
      "env": {
        "DATABASE_URL": "postgresql://localhost/mydb"
      }
    }
  }
}

วิธีติดตั้งที่ง่ายที่สุดคือ one-click จาก Cursor Marketplace หรือใช้ "Add to Cursor" deeplink (install link) นอกจากนี้ยังมี community directory ที่ cursor.directory และ team marketplace สำหรับองค์กร การ authenticate รองรับทั้ง environment variables (API key/token) และ OAuth (มีทั้ง OAuth flow และ static credentials)

💡 เมื่อ MCP server ไม่ทำงาน ให้ดู log ที่ Output panel (Cmd+Shift+U) แล้วเลือก MCP Logs — เป็นจุดแรกที่ควร debug เสมอ; Cursor CLI ใช้ config เดียวกับ editor

หลังตั้งค่าแล้ว การเรียกใช้ MCP tool จะมี approval workflow เป็นค่าเริ่มต้น (ยืนยันก่อนรันทุกครั้ง) และตั้ง auto-run allowlist ได้เช่นเดียวกับคำสั่ง terminal

8.5 ภาพรวมลำดับการทำงาน

flowchart TD
    A[ผู้ใช้พิมพ์คำสั่งใน Agent] --> B{Agent ต้องใช้เครื่องมือใด?}
    B -->|แก้ไฟล์| C[Edit files]
    B -->|รันคำสั่ง| D[Shell command]
    B -->|เครื่องมือภายนอก| E[MCP tool]
    D --> F{อยู่ใน allowlist?}
    E --> F
    F -->|ไม่| G[ขออนุมัติจากผู้ใช้]
    F -->|ใช่| H[รันอัตโนมัติ]
    G --> H
    H --> I[อ่าน output / ผลลัพธ์]
    I --> J{งานเสร็จหรือยัง?}
    J -->|ยัง| B
    J -->|เสร็จ| K[สรุปผลให้ผู้ใช้ review]

8.6 ข้อควรระวังด้านความปลอดภัยกับ MCP

MCP เพิ่มพลังมหาศาล แต่ก็เปิด attack surface ใหม่ ควรยึดหลักเหล่านี้:

MCP server คือโค้ดที่รันด้วยสิทธิ์ของคุณ ติดตั้งเฉพาะ server จากแหล่งที่เชื่อถือได้ อ่านว่ามันขอ token/ไฟล์อะไรบ้าง
ระวัง secrets ใน .cursor/mcp.json ถ้า commit เข้า git อาจหลุด API key/connection string ควรใช้ environment variable หรือ OAuth แทนการฝัง key ตรง ๆ และเพิ่มไฟล์เข้า .gitignore เมื่อจำเป็น
Prompt injection: ข้อมูลที่ MCP server ดึงมา (เนื้อหาเว็บ, issue, row ในฐานข้อมูล) อาจแฝงคำสั่งที่พยายามหลอก agent ให้ทำสิ่งไม่พึงประสงค์ — อย่าตั้ง auto-run tool ที่มีผลข้างเคียงร้ายแรง(ลบข้อมูล, ส่งเงิน, เขียนไปยังระบบ production) ให้รันเองโดยไม่ยืนยัน
จำกัดสิทธิ์ที่ต้นทาง: ต่อฐานข้อมูลด้วย credential แบบ read-only เมื่อไม่ต้องเขียน; ใช้ token ที่ scope แคบที่สุด
สำหรับองค์กร: Cursor มี enterprise controls ได้แก่ MCP Allowlist (จำกัด server/tool ที่อนุมัติ), network controls (allow all / allowlist / deny all / no sandbox) และ denylist สำหรับ user MCP extensions ควรบังคับใช้ผ่าน admin policy

⚠️ BYOK (API key ของตัวเอง) กับความเป็นส่วนตัว — เข้าใจให้ถูก: Privacy Mode คือกลไก Zero Data Retention (ZDR) ของ Cursor เอง ซึ่งคุมได้เฉพาะ ฝั่ง Cursor เท่านั้น (ไม่นำโค้ดไปเทรน ไม่เก็บไว้ที่เซิร์ฟเวอร์ Cursor หลังตอบเสร็จ) เมื่อคุณใช้ BYOK คำขอจะถูกส่งตรงไปยังผู้ให้บริการโมเดลปลายทางภายใต้ key ของคุณ — การเปิด Privacy Mode ไม่เปลี่ยนพฤติกรรมการเก็บข้อมูลของผู้ให้บริการรายนั้น สิ่งที่เกิดกับข้อมูลฝั่งผู้ให้บริการขึ้นกับข้อกำหนด/นโยบาย retention ของเขาโดยตรง (เช่น อาจเก็บ prompt ไว้ช่วงสั้น ๆ เพื่อ trust-and-safety) ซึ่งคุณต้องตรวจสอบแยกต่างหากตาม account/ข้อตกลงที่คุณใช้ สรุป: เปิด Privacy Mode ไว้ (ใช้ได้ทุกแผน รวม Free) เพื่อคุมฝั่ง Cursor แต่ถ้าทำงานกับข้อมูลอ่อนไหวภายใต้ BYOK ต้องอ่านนโยบายของผู้ให้บริการโมเดลปลายทางเพิ่มด้วยเสมอ

สรุป

Terminal integration ทำให้ Cursor ปิด loop จาก "เสนอโค้ด" เป็น "ทำงานให้เสร็จจริง" — รันคำสั่ง อ่านผล และวนแก้จนสำเร็จ ส่วน MCP ขยายขอบเขตนั้นออกไปยังเครื่องมือและข้อมูลนอก editor รายละเอียด transport, primitives และ enterprise controls อาจเปลี่ยนตามเวอร์ชัน ให้ตรวจสอบล่าสุดที่ cursor.com/docs หลักสำคัญที่ไม่เปลี่ยนคือ: ยิ่งให้ agent ทำงานได้มาก ยิ่งต้องคุมขอบเขตและ review ให้รัดกุมมากขึ้นเท่านั้น

บทที่ 9: ศิลปะการสั่งงาน Cursor สำหรับงานเขียนโค้ด (Prompting)

Cursor จะเก่งหรือไม่เก่ง ไม่ได้ขึ้นกับโมเดลอย่างเดียว แต่ขึ้นกับ คุณภาพของ prompt และบริบทที่คุณป้อนให้ เป็นหลัก โมเดล frontier ระดับ Claude Opus หรือ GPT-5.x ก็ยังตอบผิดได้ ถ้าไม่รู้ว่าไฟล์ไหนเกี่ยวข้อง เป้าหมายคืออะไร หรือมีข้อจำกัดอะไรบ้าง บทนี้จะสรุปหลักการเขียน prompt สำหรับงานโค้ดใน Cursor ให้ได้ผลลัพธ์แม่นและแก้งานน้อยลง

หลักคิดพื้นฐาน: prompt ที่ดีคือ "สัญญางาน" ที่ชัดเจน

มองการสั่งงาน AI เหมือนการมอบงานให้เพื่อนร่วมทีมที่เก่งแต่ไม่รู้บริบทโปรเจกต์ของคุณเลย prompt ที่ดีจึงต้องมีองค์ประกอบครบ 4 อย่าง:

บริบท (Context) — ไฟล์/โค้ด/เอกสารที่เกี่ยวข้อง ป้อนด้วย @
เป้าหมาย (Goal) — ต้องการให้เกิดผลลัพธ์อะไร วัดผลได้
ข้อจำกัด (Constraints) — ห้ามแตะอะไร ต้องใช้ pattern/ไลบรารีไหน สไตล์โค้ดแบบใด
รูปแบบผลลัพธ์ (Output) — แก้ในไฟล์ไหน คืนเป็น diff, test, หรืออธิบายก่อนลงมือ

flowchart TD
    A[เขียน prompt] --> B[ให้บริบทด้วย @]
    B --> C[ระบุเป้าหมาย + ข้อจำกัด]
    C --> D[แตกงานเป็นขั้น]
    D --> E{ผลตรงไหม?}
    E -->|ตรง| F[review + apply]
    E -->|ไม่ตรง| G[iterate: ชี้จุดผิด + เพิ่ม context]
    G --> E

1. ให้บริบทด้วย @-symbols แทนการอธิบายด้วยคำพูด

จุดแข็งที่สุดของ Cursor คือระบบ @ ที่ดึงบริบทจริงเข้าแชท/agent แทนที่จะพิมพ์ว่า "แก้ฟังก์ชัน login" ให้ชี้ไปที่ของจริงเลย

@-symbol	ใช้เมื่อ	ตัวอย่าง
`@Files & Folders`	อ้างทั้งไฟล์/โฟลเดอร์	`@auth.ts` `@src/api/`
`@Code`	อ้างเฉพาะฟังก์ชัน/สัญลักษณ์ ควบคุมละเอียดกว่า	`@validateToken`
`@Docs`	อ้างเอกสารไลบรารีที่ index ไว้ (ลด hallucinate)	`@Next.js`
`@Web`	ค้นเว็บเรียลไทม์ ข้อมูลใหม่ล่าสุด	`@Web ข่าว breaking change ล่าสุด`
`@Git`	อ้าง commit/diff เหมาะกับ review/แก้บั๊ก	`@Git diff ล่าสุด`
`@Recent Changes` / `@Linter Errors`	อ้างสิ่งที่เพิ่งแก้/error ปัจจุบัน	—

💡 สำหรับโปรเจกต์ใหญ่ ให้เจาะจงด้วย @Files/@Code แทนการพึ่งให้ agent ค้นทั้ง codebase เอง จะช่วยลด noise ประหยัด context window และได้คำตอบตรงกว่า (รายชื่อ @-symbols อาจต่างกันตามเวอร์ชัน ตรวจสอบในเมนู @ จริง)

⚠️ อย่าอ้าง @Docs กับไลบรารีที่ยังไม่ได้เพิ่มเข้า index คุณเพิ่ม custom docs ด้วย URL เองได้ และถ้าเป็น API เฉพาะทาง/ใหม่มาก โมเดลมีแนวโน้ม hallucinate สูง ให้แนบเอกสารเสมอ

2. ระบุเป้าหมาย ข้อจำกัด และไฟล์ที่เกี่ยวข้องให้ครบ

โมเดลไม่รู้ว่า "อย่าแตะ schema เดิม" หรือ "โปรเจกต์นี้ใช้ Zod ไม่ใช่ Yup" เว้นแต่คุณบอก สิ่งที่ควรระบุเสมอ:

ขอบเขต — "แก้เฉพาะ @userService.ts อย่าแตะไฟล์อื่น"
มาตรฐานโค้ด — naming, error handling, pattern ที่ทีมใช้
สิ่งที่ห้าม — "อย่าเปลี่ยน public API", "อย่าเพิ่ม dependency ใหม่"
เกณฑ์ความสำเร็จ — "ต้องผ่าน test เดิมทั้งหมด และเพิ่ม test สำหรับ edge case ค่าว่าง"

💡 ข้อจำกัดที่ใช้ซ้ำ ๆ (สไตล์โค้ด, โครงสร้างโฟลเดอร์, ไลบรารีที่เลือกใช้) ไม่ควรพิมพ์ทุกครั้ง — ย้ายไปไว้ใน Project Rules (.cursor/rules/*.mdc) หรือ AGENTS.md ให้ Cursor แนบอัตโนมัติ (ดูบทเรื่อง Rules) prompt แต่ละครั้งจะได้สั้นและโฟกัสเฉพาะงานเฉพาะหน้า

3. แตกงานเป็นขั้น อย่าสั่งทีเดียวจบ

งานใหญ่ที่สั่งรวดเดียว ("สร้างระบบ auth ทั้งหมด") มักได้โค้ดที่กว้างเกิน ผิดทิศ และ review ยาก แนวทางที่ดีกว่า:

ใช้ Plan Mode ก่อนงานซับซ้อน — สลับโหมดด้วย Shift+Tab ให้ agent สำรวจ codebase สร้างแผน implementation ให้คุณ review/แก้แผนก่อน แล้วค่อยสั่ง build เหมาะกับฟีเจอร์ที่มีหลายแนวทาง
แบ่งเป็น commit ย่อย — สั่งทีละส่วน: (1) สร้าง data model (2) เพิ่ม endpoint (3) เขียน test แต่ละขั้นตรวจแล้วค่อยไปต่อ
ให้ agent อธิบายก่อนแก้ เมื่อไม่แน่ใจ: "อธิบายแนวทางก่อน อย่าเพิ่งแก้โค้ด"

4. Iterate เมื่อผลไม่ตรง — อย่าเริ่มใหม่ทั้งหมด

เมื่อผลลัพธ์เพี้ยน ปฏิกิริยาที่แย่ที่สุดคือลบแล้วพิมพ์ prompt เดิมซ้ำ ให้ทำแบบนี้แทน:

ชี้จุดผิดให้ชัด — "ฟังก์ชันนี้ throw เมื่อ input เป็น null แต่เราต้องการให้ return array ว่าง"
เพิ่มบริบทที่ขาด — แนบ error จริง (@Linter Errors), แนบไฟล์ที่โมเดลมองข้าม, แนบ test ที่ fail
เมื่อบริบทรก ให้เริ่ม chat ใหม่ — ถ้าคุยยาวจนโมเดลสับสน เปิดแชทใหม่แล้วสรุปสถานะปัจจุบัน + แนบไฟล์ที่แก้ล่าสุด บางครั้งได้ผลดีกว่าดันต่อในเธรดเดิม

⚠️ agent อาจ "มั่นใจผิด ๆ" เช่น อ้างว่าแก้บั๊กสำเร็จทั้งที่รัน test ผิดตัว หรือเรียก method ที่ไม่มีอยู่จริง จึงต้อง review ทุก diff ก่อน apply และรัน test เองเพื่อยืนยัน อย่าเชื่อคำยืนยันของ AI ล้วน ๆ

ตัวอย่าง prompt: ดี vs ไม่ดี

ตัวอย่างที่ไม่ดี — กว้าง ไม่มีบริบท ไม่มีเกณฑ์

แก้บั๊กใน login ให้หน่อย มันพัง

ตัวอย่างที่ดี — มีบริบท เป้าหมาย ข้อจำกัด เกณฑ์ความสำเร็จ

ใน @auth/login.ts ฟังก์ชัน @signIn คืน 500 เมื่อ email มีตัวพิมพ์ใหญ่
ดู error จริงใน @Linter Errors ประกอบ

เป้าหมาย: normalize email เป็น lowercase ก่อน query
ข้อจำกัด:
- แก้เฉพาะ login.ts อย่าแตะ schema ใน @db/schema.ts
- ใช้ pattern validation เดิมของโปรเจกต์ (Zod)
- อย่าเพิ่ม dependency ใหม่

เกณฑ์ผ่าน: test เดิมใน @auth/login.test.ts ต้องผ่านทั้งหมด
และเพิ่ม test เคส email ตัวพิมพ์ใหญ่
อธิบายแนวทางสั้น ๆ ก่อนแล้วค่อยแก้

ความต่างสำคัญ: ตัวอย่างที่ดี ชี้ไฟล์จริงด้วย @, บอกอาการที่วัดได้, ล้อมกรอบขอบเขตไม่ให้แก้เกิน, และกำหนดว่าอะไรคือ "เสร็จ"

เลือกเครื่องมือให้ตรงกับขนาดงาน

Cursor มีหลายช่องทางป้อน prompt เลือกให้ตรงงานจะเร็วกว่ามาก:

งาน	เครื่องมือ	คีย์ลัด (Mac / Win-Linux)
แก้จุดเล็ก ในบรรทัดที่เลือก	Inline Edit (Cmd/Ctrl+K)	`Cmd K` / `Ctrl K`
ถามสั้น ๆ ไม่แก้โค้ด	Quick question ใน Inline Edit	`Opt Return` / `Alt Return`
งานหลายไฟล์ / รันคำสั่ง	Agent/Chat	`Cmd L` / `Ctrl L`, `Cmd I`
เติมโค้ดต่อเนื่องขณะพิมพ์	Tab (autocomplete)	`Tab` ยอมรับ · `Esc` ปฏิเสธ

💡 สำหรับงานซ้ำ ๆ เร็ว ๆ ให้พึ่ง Tab และ Cmd/Ctrl+K ไม่ต้องเปิด agent ทุกครั้ง สงวน Agent/Plan Mode ไว้กับงานที่ต้องแตะหลายไฟล์หรือรัน terminal จริง

การเขียน prompt ที่ดีคือทักษะที่ฝึกได้ ยิ่งคุณป้อนบริบทตรง ระบุข้อจำกัดชัด และ iterate อย่างมีทิศทาง Cursor ก็ยิ่งกลายเป็นเพื่อนร่วมทีมที่ไว้ใจได้มากขึ้นเรื่อย ๆ

บทที่ 10: เวิร์กโฟลว์จริง: สร้างฟีเจอร์ใหม่ แก้บั๊ก Refactor และเขียนเทสต์

บทก่อนหน้าปูพื้นฐานฟีเจอร์แต่ละตัวของ Cursor แยกกันไปแล้ว — Tab, Cmd/Ctrl+K, Chat และ Agent บทนี้จะร้อยมันเข้าด้วยกันเป็น เวิร์กโฟลว์จริง สำหรับงานที่นักพัฒนาเจอทุกวัน 4 ประเภท: เพิ่มฟีเจอร์ใหม่, debug จาก error, refactor โค้ดเดิม และเขียน/รันเทสต์ แต่ละงานจะบอกชัดว่า "ใช้เครื่องมือไหน" และให้ prompt ตัวอย่างที่ก็อปไปปรับใช้ได้ทันที

เลือกเครื่องมือให้ตรงกับขนาดงาน

หัวใจของการใช้ Cursor ให้คุ้มคือการ จับคู่ขนาดงานกับเครื่องมือ อย่าใช้ Agent กับงานเติมโค้ดหนึ่งบรรทัด และอย่าใช้ Tab กับงานที่ต้องแก้ 8 ไฟล์

งาน	เครื่องมือที่เหมาะ	เหตุผล
เติมโค้ดขณะพิมพ์ ต่อบรรทัดที่เดาได้	Tab	เร็วที่สุด และบนแผน Pro ขึ้นไป Tab ไม่จำกัด ไม่ดึง usage credit อีกทั้งทำนายการแก้ถัดไปได้
แก้/เขียนโค้ดเฉพาะจุดที่เลือกไว้	Cmd/Ctrl+K (Inline Edit)	โฟกัสที่ selection เดียว เห็น diff ทันที
ถามความเข้าใจ อธิบายโค้ด วางแผน	Chat / Ask	อ่านอย่างเดียว ไม่แตะไฟล์
งานหลายไฟล์ ต้องรันคำสั่ง ทำต่อเนื่อง	Agent	แก้หลายไฟล์ + รัน terminal + review/apply ได้
ฟีเจอร์ใหญ่ที่มีหลายแนวทาง	Plan Mode (ใน Agent)	วางแผนก่อนเขียน ลดการรื้อทีหลัง

💡 ข้อดี "Tab ไม่ดึง usage credit" เป็นจริงบนแผนจ่ายเงินทุกตัว (Pro, Pro+, Ultra) ที่ให้ Tab completions ไม่จำกัด และไม่กินเครดิตโมเดล ส่วนแผน Free (Hobby) มีโควตา Agent/usage จำกัด จึงควรถือว่า Tab แบบไม่จำกัด/ไม่ดึงเครดิตเป็นสิทธิของแผน Pro ขึ้นไป (ตรวจสอบล่าสุดที่หน้า pricing เพราะโครงสร้างแผนเปลี่ยนบ่อย)

flowchart TD
    A[มีงานเข้ามา] --> B{ขอบเขตแค่ไหน?}
    B -->|ต่อบรรทัดขณะพิมพ์| C[Tab]
    B -->|จุดเดียว/selection| D[Cmd หรือ Ctrl+K]
    B -->|แค่อยากเข้าใจ/ถาม| E[Chat - Ask mode]
    B -->|หลายไฟล์ + รันคำสั่ง| F{ซับซ้อน มีหลายทางเลือกไหม?}
    F -->|ตรงไปตรงมา| G[Agent mode]
    F -->|ใหญ่ กำกวม| H[Plan Mode ก่อน แล้วค่อย build]

เวิร์กโฟลว์ที่ 1: สร้างฟีเจอร์ใหม่

ฟีเจอร์ใหม่มักกินหลายไฟล์ (route, controller, model, test) จึงเป็นงานของ Agent และถ้ากำกวมให้เริ่มที่ Plan Mode (สลับโหมดด้วย dropdown หรือ Shift+Tab)

ขั้นที่ 1 — วางแผนด้วย Plan Mode ให้ Agent สำรวจ codebase และถามคำถามก่อนลงมือ ป้อน context ด้วย @-symbols ให้เจาะจง

[Plan Mode] ฉันต้องการเพิ่มฟีเจอร์ "รีเซ็ตรหัสผ่านผ่านอีเมล"
อ้างอิงโครงสร้างเดิมใน @Folders src/auth และ @Files src/services/mailer.ts
ช่วยสำรวจว่าตอนนี้ระบบ auth ทำงานยังไง แล้วเสนอแผน implementation
เป็นขั้นตอน โดยยังไม่ต้องเขียนโค้ด ถ้ามีจุดที่ต้องตัดสินใจให้ถามฉันก่อน

Agent จะสร้างแผน (มักเป็นไฟล์ markdown หรือในแชท) ให้คุณ review และแก้ก่อนกดสั่ง build

ขั้นที่ 2 — สั่งลงมือ เมื่อพอใจกับแผนแล้ว สลับเป็น Agent mode แล้วสั่ง "ดำเนินการตามแผน" Agent จะแก้ไฟล์และเสนอ diff ให้ review/apply

ขั้นที่ 3 — เก็บรายละเอียดด้วย Tab หลังโครงสร้างหลักเสร็จ ตอนคุณเติม field หรือ import เอง Tab จะทำนายบรรทัดถัดไปให้ กด Tab เพื่อ accept หรือ Cmd/Ctrl + → เพื่อ accept ทีละคำ

💡 ตั้ง Project Rules (ไฟล์ .mdc ใน .cursor/rules) ระบุ convention ของโปรเจกต์ เช่นรูปแบบ error handling หรือ naming แล้ว Agent จะสร้างฟีเจอร์ใหม่ให้เข้ากับสไตล์เดิมโดยไม่ต้องย้ำทุกครั้ง

เวิร์กโฟลว์ที่ 2: แก้บั๊กจาก error

การ debug คือจุดที่ context สำคัญที่สุด ยิ่งป้อน error, diff และไฟล์ที่เกี่ยวข้องครบ ยิ่งลดโอกาส hallucinate

ขั้นที่ 1 — โยน error ให้ Agent พร้อม context เลือกโค้ดที่ต้องสงสัยแล้วกด Cmd/Ctrl+L เพื่อเปิด Chat/Agent พร้อม selection จากนั้นแปะ stack trace และอ้าง @Git เพื่อให้ AI เห็นว่าเพิ่งเปลี่ยนอะไร

เจอ error นี้ตอนรันเทสต์:
TypeError: Cannot read properties of undefined (reading 'id')
  at getUserCart (src/cart/service.ts:42)

ช่วยวิเคราะห์สาเหตุที่แท้จริง อ้างอิง @Files src/cart/service.ts
และ @Git ดูว่า commit ล่าสุดแตะอะไรที่เกี่ยวข้อง
เสนอแนวทางแก้ก่อน อย่าเพิ่งแก้จนกว่าฉันจะยืนยัน

ขั้นที่ 2 — ให้ Agent ยืนยันด้วยการรันจริง จุดแข็งของ Agent คือรันคำสั่ง terminal ได้ สั่งให้มันรันเทสต์ที่พังเพื่อพิสูจน์ว่าแก้ถูกจริง

แก้ตามแนวทางที่เราตกลงกัน แล้วรัน `npm test -- cart` เพื่อยืนยันว่าผ่าน
ถ้ายังพังให้วิเคราะห์ output แล้วลองใหม่

ขั้นที่ 3 — บั๊กเล็ก ใช้ Cmd/Ctrl+K ถ้าเป็นบั๊กจุดเดียวที่รู้ว่าอยู่ตรงไหน ไม่ต้องเรียก Agent เลือกบรรทัดนั้นแล้วกด Cmd/Ctrl+K พิมพ์ "แก้ null check ตรงนี้" แล้วกด Return

⚠️ Agent อาจ "มั่นใจผิด ๆ" — เช่นอ้างว่าแก้บั๊กสำเร็จทั้งที่รันเทสต์ผิดตัว หรือสร้างเมธอด/API ที่ไม่มีอยู่จริง ตรวจ diff และ output ของเทสต์ด้วยตาเสมอ อย่าเชื่อคำสรุปของ AI โดยไม่ verify

เวิร์กโฟลว์ที่ 3: Refactor โค้ดเดิม

Refactor ต้องเปลี่ยนพฤติกรรม "ให้เหมือนเดิม" ขณะปรับโครงสร้าง จึงควรมีเทสต์คุ้มหลังก่อนเริ่ม

Refactor เฉพาะจุด (เปลี่ยนชื่อตัวแปร แยกฟังก์ชันในไฟล์เดียว) → เลือกโค้ดแล้ว Cmd/Ctrl+K

แยกลอจิกการคำนวณส่วนลดในฟังก์ชันนี้ออกเป็นฟังก์ชัน `calculateDiscount`
แยกต่างหาก โดยพฤติกรรมต้องเหมือนเดิมทุกอย่าง

Refactor ข้ามไฟล์ (เปลี่ยน pattern ทั่วโมดูล ย้าย logic) → Agent พร้อม @Folders

ตอนนี้เราเรียก fetch ตรง ๆ กระจายอยู่ทั่ว @Folders src/api
ช่วย refactor ให้ทุกที่เรียกผ่าน client กลางใน @Files src/api/client.ts
แทน อย่าเปลี่ยน behavior และอย่าแตะไฟล์เทสต์
ทำทีละไฟล์แล้วสรุปให้ฉันเห็นว่าแก้อะไรบ้าง

💡 ก่อน refactor ใหญ่ สั่ง Agent (หรือใช้ Ask mode) ให้ "อธิบายว่าโมดูลนี้ทำงานอย่างไรและมีใครเรียกใช้บ้าง" ก่อน จะช่วยให้คุณเห็นผลกระทบและจับจุดที่ AI อาจพลาด

เวิร์กโฟลว์ที่ 4: เขียนและรันเทสต์

การเขียนเทสต์เป็นงานที่ Agent ทำได้ดีเป็นพิเศษ เพราะมันรันเทสต์เอง เห็นผล และแก้จนเขียว

ขั้นที่ 1 — สั่งเขียนเทสต์พร้อมกรอบชัด ยิ่งระบุ framework และ edge case ที่ต้องการ ยิ่งได้เทสต์ที่มีความหมาย ไม่ใช่แค่เทสต์ผ่าน ๆ

เขียน unit test สำหรับ @Files src/cart/service.ts ด้วย Vitest
ครอบคลุมเคส: cart ว่าง, สินค้าหมดสต็อก, และ user ไม่มีอยู่จริง
ทำตาม pattern การเขียนเทสต์เดิมใน @Files src/order/service.test.ts
แล้วรัน `npm test -- cart` ให้ผ่านทุกเคส

ขั้นที่ 2 — ให้ loop จนเขียว ปล่อยให้ Agent รันเทสต์ อ่าน failure แล้วแก้เอง — เอกสารระบุว่า Agent ไม่จำกัดจำนวน tool call ในหนึ่งงาน จึงวนแก้ได้จนผ่าน

ขั้นที่ 3 — เติมเคสด้วย Tab เมื่อคุณเขียน it('should ...') เคสถัดไปเอง Tab มักเดาโครงเทสต์ที่เหลือให้จาก pattern รอบข้าง

⚠️ ระวัง AI เขียนเทสต์ที่ "ยืนยันพฤติกรรมที่บั๊ก" — คือปรับ assertion ให้ตรงกับผลลัพธ์ผิด ๆ เพื่อให้ผ่าน อ่านทุก assertion ว่าตรวจสิ่งที่ "ควรจะเป็น" จริงหรือไม่

สรุปหลักปฏิบัติร่วม

ไม่ว่างานใด เวิร์กโฟลว์ที่ดีมีจังหวะเดียวกัน:

ให้ context เจาะจง — ใช้ @Files/@Folders/@Code/@Git แทนการพึ่งให้ AI เดาทั้ง codebase ลด noise และประหยัด context window
วางแผนก่อนงานใหญ่ — Plan Mode หรือ Ask mode สำหรับงานกำกวม/หลายทางเลือก
จับคู่เครื่องมือกับขนาด — Tab เติมบรรทัด, Cmd/Ctrl+K จุดเดียว, Agent หลายไฟล์
ให้ AI พิสูจน์ด้วยการรันจริง — สั่งรันเทสต์/คำสั่งใน terminal เสมอ ไม่ใช่แค่เชื่อคำสรุป
Human review ทุกครั้ง — ตรวจ diff และ output ก่อน accept เพราะ AI มั่นใจผิดได้

💡 บันทึก convention ที่ใช้ซ้ำ (framework เทสต์, รูปแบบ error handling, structure ของฟีเจอร์) ไว้ใน Project Rules ครั้งเดียว แล้วทุกเวิร์กโฟลว์ข้างต้นจะได้ผลลัพธ์ที่เข้ากับโปรเจกต์โดยไม่ต้องพิมพ์ซ้ำในทุก prompt

บทที่ 11: Cursor ในการทำงานจริง: เวิร์กโฟลว์ตามสายงาน

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

💡 หลักที่ใช้ได้ทุกกลุ่ม: เริ่มด้วย Auto model ถ้ายังไม่แน่ใจว่าจะเลือกโมเดลไหน, เปิด Plan Mode เมื่องานซับซ้อนหลายไฟล์, และตั้ง Project Rules (.cursor/rules/*.mdc) เพื่อไม่ต้องอธิบาย convention ซ้ำทุกครั้ง

ภาพรวม: จับคู่ฟีเจอร์กับสายงาน

flowchart TD
    A[งานที่ต้องทำ] --> B{ขอบเขตงาน?}
    B -->|แก้ไม่กี่บรรทัด| C[Cmd/Ctrl+K<br/>Inline Edit]
    B -->|เติมโค้ดขณะพิมพ์| D[Tab<br/>Autocomplete]
    B -->|หลายไฟล์ + รันคำสั่ง| E[Agent / Chat<br/>Cmd L]
    B -->|ซับซ้อน หลายแนวทาง| F[Plan Mode<br/>Shift+Tab]
    E --> G{ต้องรันเบื้องหลัง<br/>หรือทำหลายงานขนาน?}
    G -->|ใช่| H[Cloud Agents]
    G -->|ไม่| I[Agent ในเครื่อง]

1) มือใหม่หัดเขียนโค้ด

สถานการณ์: เพิ่งเริ่มเรียน อ่านโค้ดคนอื่นแล้วงง กลัวพิมพ์ผิด syntax

วิธีใช้: พึ่ง Tab ให้เติม syntax พื้นฐาน (Cursor เดาจากบริบทรอบข้างและ linter errors) และใช้ Chat เป็นติวเตอร์ ถามเป็นภาษาไทยได้ ใช้ @Code ชี้บรรทัดที่ไม่เข้าใจ อย่ารีบกด accept ทุกอย่าง ให้อ่านและถามต่อว่า "ทำไม"

@Code อธิบายฟังก์ชันนี้ทีละบรรทัดเป็นภาษาไทย ราวกับสอนคนเพิ่งเริ่มเขียน Python
แล้วบอกด้วยว่าถ้า input เป็น list ว่างจะเกิดอะไรขึ้น

⚠️ AI อาจ "มั่นใจผิด ๆ" สร้างเมธอดที่ไม่มีอยู่จริงได้ ให้รันโค้ดดูผลจริงเสมอ อย่าเชื่อคำอธิบายอย่างเดียว

2) Frontend Developer

สถานการณ์: สร้าง component, จัด layout, แก้ CSS ให้ตรง design

วิธีใช้: ใช้ Agent (Cmd L) สร้าง component ทั้งไฟล์, @Docs อ้างเอกสาร framework (เช่น React/Tailwind) ลด hallucinate, และตั้ง globs: src/**/*.tsx ใน Project Rule เพื่อบังคับ convention การตั้งชื่อ/สไตล์

สร้าง component <PricingCard> ใน src/components ตามดีไซน์ในภาพนี้
ใช้ Tailwind, รองรับ dark mode, props: title, price, features[], highlighted
ยึด @Docs Tailwind และ pattern จาก @Files src/components/Card.tsx

3) Backend Developer

สถานการณ์: เขียน API endpoint, จัดการ database, เขียน business logic ที่มี edge case

วิธีใช้: Plan Mode ก่อนลงมือ ให้ Agent สำรวจ codebase และเสนอแผนก่อน, ใช้ @Folders ชี้ทั้งโมดูล, และให้ Agent รัน test ผ่าน terminal ในตัว

[Plan Mode] เพิ่ม endpoint POST /orders ที่ตัด stock แบบ atomic
สำรวจ @Folders src/services ก่อน แล้วเสนอแผนพร้อมจุดที่ต้องจัดการ race condition
ยังไม่ต้องเขียนโค้ด รอฉัน review แผนก่อน

4) Full-Stack Developer

สถานการณ์: ฟีเจอร์เดียวแต่แตะทั้ง frontend, backend และ schema

วิธีใช้: งานข้ามหลายชั้นเหมาะกับ Agent ที่ tool call ไม่จำกัดต่อหนึ่งงาน หากมีหลาย repo (เช่น web + api แยกกัน) Cloud Agents รองรับ multi-repo และสร้าง merge-ready PR ได้

เพิ่มฟีเจอร์ "ลืมรหัสผ่าน" ครบ flow:
migration ตาราง reset_tokens, endpoint request/confirm ใน @Folders api/src,
และหน้า /reset ใน @Folders web/src พร้อมเชื่อม API
รัน test ทั้งสองฝั่งเมื่อเสร็จ

5) Data / Analytics

สถานการณ์: เขียน SQL, แปลงข้อมูลใน pandas, ทำ notebook วิเคราะห์

วิธีใช้: Inline Edit (Cmd/Ctrl+K) ปรับ query ทีละก้อนเร็วมาก, @Web ดึง syntax library เวอร์ชันล่าสุด และให้ Agent อธิบาย query ที่ซับซ้อนก่อนแก้

เขียน query หา MAU รายเดือน 12 เดือนล่าสุด จากตาราง events (คอลัมน์ user_id, ts)
เป็น PostgreSQL แล้วอธิบาย logic การนับ distinct ให้ด้วย

6) DevOps / Platform

สถานการณ์: เขียน Dockerfile, CI pipeline, Terraform, แก้ config ที่ผิดพลาดแล้วพังทั้งระบบ

วิธีใช้: ให้ Agent รันคำสั่งตรวจสอบ (เช่น terraform plan, docker build) แต่ เปิด approval workflow ไว้ อย่าให้ auto-run คำสั่งที่มีผลถาวร ใช้ MCP ต่อกับเครื่องมือ infra ได้ (config ที่ .cursor/mcp.json)

เขียน multi-stage Dockerfile สำหรับ Node app นี้ ลดขนาด image ให้เล็กสุด
รัน docker build ทดสอบ แต่อย่ารันคำสั่งที่ push หรือ deploy — หยุดให้ฉัน review ก่อน

⚠️ สำหรับงาน infra ให้ระวังเรื่อง secret อย่าวาง key จริงในแชท และตรวจ diff ทุกบรรทัดก่อน apply โดยเฉพาะไฟล์ที่กระทบ production

7) นักเรียน / นักศึกษา

สถานการณ์: ทำโปรเจกต์ส่ง อยากเข้าใจ ไม่ใช่แค่ลอก งบจำกัด

วิธีใช้: แผน Hobby (ฟรี) ใช้ได้จริงสำหรับเริ่มต้น (มี Composer + Agent จำกัด) ใช้ Chat ให้ช่วย debug พร้อมสอน และให้ช่วยเขียน test เพื่อพิสูจน์ว่าเข้าใจโจทย์

โค้ดฉันรัน error นี้: [วาง error]. อย่าเพิ่งแก้ให้
ชี้ว่าสาเหตุน่าจะอยู่บรรทัดไหนและเพราะอะไร แล้วให้ฉันลองแก้เองก่อน

8) หัวหน้าทีม / Tech Lead

สถานการณ์: อยากให้ทั้งทีมเขียนโค้ดในมาตรฐานเดียว, review เร็วขึ้น, จัดการ billing รวมศูนย์

วิธีใช้: แผน Teams ($40/user/เดือน Standard) ให้ SSO, team privacy mode, analytics และ Team Rules ที่มี precedence เหนือ Project/User Rules ใช้ Bugbot ช่วย review PR และวาง .cursor/rules ที่ commit ลง repo ให้ทุกคนได้ context เดียวกัน

สร้าง Project Rule ใน .cursor/rules/api-conventions.mdc
description: มาตรฐานการเขียน API
globs: api/src/**/*.ts
เนื้อหา: naming, error-handling pattern, และรูปแบบ response — อ้าง @Files api/src/lib/response.ts แทนการก๊อป

9) คนที่ไม่ใช่โปรแกรมเมอร์ (อยากทำ Prototype)

สถานการณ์: PM, นักออกแบบ หรือเจ้าของธุรกิจ อยากลองสร้าง prototype ให้เห็นภาพ

วิธีใช้: ใช้ Agent + Auto model สั่งเป็นภาษาธรรมชาติ ให้ Agent ตั้งโปรเจกต์ ติดตั้ง dependency และรัน dev server ให้เอง สื่อสารเป็น "ผลลัพธ์ที่อยากเห็น" ไม่ต้องพูดศัพท์เทคนิค

ฉันไม่เขียนโค้ดเป็น อยากได้เว็บหน้าเดียวเก็บอีเมลคนสนใจสินค้า
ช่วยตั้งโปรเจกต์ให้ครบ รัน server ให้ดูในเบราว์เซอร์ และบอกฉันทีละขั้นว่าต้องกดอะไร

💡 กลุ่มนี้ควรถามกลับบ่อย ๆ ว่า "อธิบายให้ฟังหน่อยว่าไฟล์นี้ทำอะไร" เพื่อค่อย ๆ เข้าใจ ไม่ใช่แค่ได้ของ

ตารางสรุป: ฟีเจอร์และแผนที่แนะนำตามสายงาน

สายงาน	ฟีเจอร์หลัก	โมเดล/โหมด	แผนที่พอเหมาะ
มือใหม่	Tab, Chat (`@Code`)	Auto	Hobby (ฟรี)
Frontend	Agent, `@Docs`, Rules	Auto / frontier	Pro
Backend	Plan Mode, terminal	frontier (งานยาก)	Pro / Pro+
Full-Stack	Agent, Cloud Agents	Auto + frontier	Pro+
Data/Analytics	Inline Edit, `@Web`	Auto	Pro
DevOps	Agent + approval, MCP	frontier	Pro+
นักเรียน	Tab, Chat	Auto	Hobby (ฟรี)
Tech Lead	Team Rules, Bugbot	Auto	Teams
Non-coder	Agent (ภาษาธรรมชาติ)	Auto	Pro

💡 ผู้ใช้ Agent รายวันมักใช้จ่ายจริงราว $60–$100/เดือน Cursor จึงแนะนำ Pro+ สำหรับคนใช้ agent หนักทุกวัน และ Ultra สำหรับ power user ราคาและรายละเอียดโมเดลอาจเปลี่ยน ให้ตรวจสอบใน Settings และ model picker จริงอีกครั้ง

สิ่งที่ทุกสายงานควรทำเหมือนกัน

ตั้ง Project Rules ตั้งแต่วันแรก เพื่อไม่ต้องอธิบาย convention ซ้ำ
ให้ context เจาะจง ด้วย @Files/@Folders/@Code แทนพึ่งการสแกนทั้ง codebase ลด noise และประหยัด context
review diff ก่อน apply เสมอ โดยเฉพาะโค้ดที่กระทบ production หรือลบข้อมูล
เปิด Privacy Mode ถ้าทำงานกับโค้ดที่เป็นความลับ (ใช้ได้ทั้งแผนฟรีและ Pro)

การจับคู่ "งาน → ฟีเจอร์ → prompt" ให้ถูกตั้งแต่ต้น คือสิ่งที่แยกคนที่ใช้ Cursor เป็นเครื่องเติมโค้ดธรรมดา ออกจากคนที่ใช้มันเป็นเพื่อนร่วมทีมที่เข้าใจบริบทงานของตนจริง ๆ

บทที่ 12: คลัง Prompt และเทคนิคสำเร็จรูปสำหรับ Cursor (Cookbook)

บทนี้คือ คลังสูตรพร้อมใช้ สำหรับงานที่คุณต้องทำซ้ำทุกวันใน Cursor ไม่ว่าจะเป็น generate, refactor, explain, debug, เขียนเทสต์, เขียน docs และ review แต่ละสูตรออกแบบมาให้ คัดลอกไปวางแล้วปรับเล็กน้อย ก็ใช้งานได้จริง โดยยึดหลักการเดียวกันตลอดทั้งบท คือ ให้บริบทที่แม่นด้วย @-symbols, ระบุเป้าหมายและ constraint ให้ชัด, และบอก AI ว่า "อย่าทำอะไร" ไม่ใช่แค่ "ทำอะไร"

💡 หลักคิดก่อนเขียน prompt ทุกสูตร: บริบทดี > prompt ยาว การแนบ @Files, @Code, @Git ที่ตรงจุดเพียงไม่กี่ชิ้น ให้ผลดีกว่าการเขียนคำอธิบายยาวเป็นย่อหน้าโดยไม่มี context อ้างอิง

หลักการเลือกเครื่องมือให้ตรงงาน

ก่อนเข้าสูตร ให้จำ mapping นี้ไว้ เพื่อเลือกช่องทางส่งงานให้เหมาะ

งาน	เครื่องมือที่เหมาะ	คีย์ลัด (Mac / Win-Linux)
แก้โค้ดที่เลือกไว้ทันที (จุดเดียว)	Inline Edit	`Cmd K` / `Ctrl K`
ถามคำถามสั้นๆ เกี่ยวกับโค้ดที่เลือก	Inline Quick question	`Opt Return` / `Alt Return`
งานหลายไฟล์ / วางแผน / รันคำสั่ง	Agent (Chat)	`Cmd L` / `Ctrl L` หรือ `Cmd I`
เติมโค้ดต่อเนื่องขณะพิมพ์	Cursor Tab	กด `Tab` เพื่อ accept
งานซับซ้อนหลายแนวทาง	Plan Mode ใน Agent	สลับโหมดด้วย `Shift+Tab`

flowchart TD
    A[มีงานที่จะทำ] --> B{ขอบเขตแค่ไหน?}
    B -->|จุดเดียว โค้ดที่เลือก| C[Inline Edit Cmd/Ctrl K]
    B -->|หลายไฟล์ ต้องสำรวจ codebase| D[Agent Cmd/Ctrl L]
    D --> E{ชัดเจนหรือยัง?}
    E -->|ซับซ้อน หลายแนวทาง| F[Plan Mode ก่อน build]
    E -->|ตรงไปตรงมา| G[Agent mode ลงมือเลย]

สูตรที่ 1: Generate — สร้างฟังก์ชัน/คอมโพเนนต์ใหม่

ใช้ใน Agent (Cmd/Ctrl L) เมื่อต้องสร้างของใหม่ที่ต้องกลืนกับสไตล์เดิมของโปรเจกต์

สร้าง [ฟังก์ชัน/คอมโพเนนต์ชื่อ ...] ที่ทำ [หน้าที่ ...]

Input: [ชนิด/รูปแบบ] · Output: [ชนิด/รูปแบบ]
ให้ยึด pattern และ naming เดียวกับ @Files (ไฟล์ตัวอย่างที่ใกล้เคียง)
ใช้ type/interface ที่มีอยู่แล้วใน @Code ห้ามสร้างซ้ำ

ข้อกำหนด:
- จัดการ edge case: [ค่าว่าง, error, ...]
- ห้ามเพิ่ม dependency ใหม่นอกจากที่มีใน package.json
ก่อนเขียนโค้ด สรุปแนวทางสั้นๆ 2-3 บรรทัดให้ผมยืนยันก่อน

วิธีปรับใช้: แนบไฟล์ที่มี pattern ใกล้เคียงเป็น @Files เสมอ เพื่อให้ผลลัพธ์เข้ากับ codebase บรรทัดสุดท้าย ("สรุปแนวทางก่อน") บังคับให้ AI ไม่รีบเขียนผิดทิศ ถ้างานใหญ่ให้สลับไป Plan Mode แทน

สูตรที่ 2: Refactor — ปรับโครงสร้างโดยไม่เปลี่ยนพฤติกรรม

Refactor โค้ดที่เลือกนี้ให้ [อ่านง่ายขึ้น / แยก responsibility / ลด duplication]
เงื่อนไขสำคัญ: พฤติกรรมภายนอก (input/output, side effects) ต้องเหมือนเดิมทุกประการ
- อย่าเปลี่ยน public API หรือชื่อฟังก์ชันที่ถูกเรียกจากที่อื่น
- ถ้าจะเปลี่ยนชื่อ ให้บอกผมก่อนพร้อมเหตุผล
อธิบายสั้นๆ ว่าแต่ละจุดที่แก้ ปรับอะไรและทำไม

วิธีปรับใช้: งาน refactor จุดเดียวใช้ Inline Edit (Cmd/Ctrl K) จะเร็วและ diff ชัด ถ้าเป็นการ rename ข้ามหลายไฟล์ให้ใช้ Agent และแนบ @Folders ของโมดูลที่เกี่ยวข้อง เน้นย้ำ "พฤติกรรมเหมือนเดิม" เพื่อกัน AI แอบเปลี่ยน logic

สูตรที่ 3: Explain — เข้าใจโค้ดที่ไม่คุ้น

อธิบายโค้ดที่เลือกนี้ให้คนที่เพิ่งเข้าโปรเจกต์เข้าใจ:
1. โดยภาพรวมทำหน้าที่อะไร (2-3 ประโยค)
2. flow การทำงานทีละขั้น
3. ส่วนที่ tricky หรือ non-obvious พร้อมเหตุผลว่าทำไมต้องเขียนแบบนี้
4. dependency/ผลกระทบกับส่วนอื่น (ดูจาก @Git หากมี commit ที่เกี่ยว)
อย่าเสนอแก้โค้ด แค่ช่วยให้ผมเข้าใจ

วิธีปรับใช้: ใช้ Inline Quick question (Opt/Alt Return) สำหรับส่วนสั้นๆ หรือ Agent สำหรับทั้งไฟล์ การเติม @Git ช่วยให้ AI เห็นประวัติว่าโค้ดส่วนนั้นถูกเพิ่มมาแก้ปัญหาอะไร

สูตรที่ 4: Debug — หาสาเหตุจาก error จริง

โค้ดนี้เกิดปัญหา: [อาการที่เห็น]
คาดหวัง: [พฤติกรรมที่ควรเป็น] · เกิดจริง: [ที่เกิดขึ้น]
Error/log:
[วาง stack trace หรือ log ตรงนี้]

ให้: (1) เสนอ 2-3 สมมติฐานของสาเหตุ เรียงตามความน่าจะเป็น
(2) บอกวิธียืนยันแต่ละสมมติฐาน (3) เสนอ fix ที่ตรงจุดที่สุด
อ้างอิง @Linter Errors และไฟล์ที่เกี่ยวข้องประกอบ

วิธีปรับใช้: วาง stack trace จริงเสมอ อย่าเล่าอาการลอยๆ การให้ AI "เสนอสมมติฐานก่อน fix" ป้องกันการแก้มั่วแบบ overconfident ซึ่งเป็นรูปแบบ error ที่พบบ่อย ให้รันเทสต์ยืนยันหลังแก้เสมอ

⚠️ AI มัก"มั่นใจผิดๆ" เช่นอ้างว่าแก้บั๊กสำเร็จทั้งที่ยังไม่ได้รันเทสต์ที่ถูกตัว หรือรัน command ผิด ให้ตรวจผลรันด้วยตาทุกครั้ง อย่าเชื่อคำสรุปของ agent เพียงอย่างเดียว

สูตรที่ 5: เขียนเทสต์ — unit test ครอบ edge case

เขียน unit test ให้ @Code (ฟังก์ชันที่เลือก)
ใช้ test framework และ pattern เดียวกับ @Files (ไฟล์เทสต์ที่มีอยู่)
ครอบคลุม: happy path, ค่าขอบ (empty/null/0/ค่าติดลบ), error path
- ตั้งชื่อ test case เป็นประโยคที่อธิบายพฤติกรรม
- อย่า mock เกินจำเป็น mock เฉพาะ dependency ภายนอกจริงๆ
หลังเขียนเสร็จ รันเทสต์ใน terminal แล้วสรุปผลให้ดู

วิธีปรับใช้: แนบไฟล์เทสต์เดิมเป็น @Files เพื่อให้ AI ใช้ framework และ convention เดียวกัน (เช่น Jest, Vitest, pytest) ใน Agent mode สามารถสั่งให้รันเทสต์เองผ่าน terminal และวนแก้จนผ่านได้

สูตรที่ 6: เขียน Docs — docstring และ README

เขียน docstring/comment ให้ฟังก์ชันที่เลือก ตามสไตล์ [JSDoc / Google-style / ...]
ระบุ: จุดประสงค์, พารามิเตอร์แต่ละตัว, ค่า return, error ที่อาจ throw, ตัวอย่างการเรียกใช้สั้นๆ
เขียนกระชับ ตรงกับสิ่งที่โค้ดทำจริง ห้ามเดา behavior ที่ไม่เห็นในโค้ด

สำหรับเอกสารระดับโปรเจกต์ ให้เพิ่มบริบทกว้างขึ้น

สร้าง README ส่วน "Getting Started" จาก @package.json และโครงไฟล์ใน @Folders
ครอบคลุม: ติดตั้ง, ตัวแปร env ที่จำเป็น, คำสั่งรัน dev/build/test
เขียนเป็น Markdown สำหรับนักพัฒนาที่เพิ่งเข้าทีม

วิธีปรับใช้: เน้น "ห้ามเดา behavior ที่ไม่เห็นในโค้ด" เพื่อลด hallucination การอ้าง @Docs ของไลบรารีที่ใช้ ช่วยให้ตัวอย่างในเอกสารถูกต้องตาม API จริง

สูตรที่ 7: Review — ตรวจ diff ก่อน commit

รีวิวการเปลี่ยนแปลงใน @Git (diff ล่าสุด / staged changes)
มองหา: bug, edge case ที่หลุด, ปัญหา security, performance, และจุดที่อ่านยาก
จัดลำดับความสำคัญเป็น: 🔴 ต้องแก้ / 🟡 ควรพิจารณา / 🟢 nitpick
สำหรับแต่ละข้อ ระบุไฟล์+บรรทัด และเสนอวิธีแก้สั้นๆ
อย่าเสนอแก้ style ที่ linter จัดการได้อยู่แล้ว

วิธีปรับใช้: @Git ให้ AI เห็นเฉพาะสิ่งที่เปลี่ยน ทำให้รีวิวโฟกัสและประหยัด context การจัดลำดับสีช่วยให้คุณเลือกแก้เฉพาะเรื่องสำคัญ ทีมที่ใช้แผนเสียเงินยังมี Bugbot ช่วยรีวิว PR อัตโนมัติเสริมได้

สูตรที่ 8: Generate จาก spec/ข้อมูลจริง

จาก @Docs (สเปค API นี้) และ type ใน @Code
สร้าง client function สำหรับเรียก endpoint [...] พร้อม type ของ request/response
จัดการ error status และ timeout ตาม pattern เดียวกับ @Files

วิธีปรับใช้: เมื่อทำงานกับ API ใหม่/เฉพาะทางที่โมเดลอาจไม่รู้จัก ให้ดึงเอกสารจริงเข้ามาด้วย @Docs (เพิ่ม custom docs ด้วย URL ได้) หรือ @Web สำหรับข้อมูลล่าสุด เพื่อกัน AI แต่งชื่อ method ที่ไม่มีอยู่จริง

สูตรที่ 9: แปลง/ย้ายเทคโนโลยี (migration)

แปลงโค้ดที่เลือกจาก [เดิม เช่น class component] เป็น [ใหม่ เช่น function component + hooks]
คงพฤติกรรมและ props interface เดิมทุกอย่าง
ทำทีละไฟล์ หลังแต่ละไฟล์หยุดให้ผม review ก่อนไปต่อ
ถ้าเจอ pattern ที่แปลงตรงๆ ไม่ได้ ให้ถามแทนการเดา

วิธีปรับใช้: งาน migration ควรใช้ Plan Mode ให้ AI สำรวจ codebase และวางแผนก่อน แล้วค่อย build เป็นชุดๆ การบอกให้ "หยุดให้ review ทีละไฟล์" ป้องกันการเปลี่ยนพรวดเดียวจนตามแก้ไม่ทัน

สูตรที่ 10: ทำให้ AI จำ context ยาวด้วย Rules

แทนการพิมพ์บริบทซ้ำทุกครั้ง ให้บันทึกเป็น Project Rule ไฟล์ .mdc ใน .cursor/rules

--- (frontmatter ของ .mdc)
description: มาตรฐานการเขียนโค้ดของโปรเจกต์นี้
globs: src/**/*.ts,src/**/*.tsx
alwaysApply: false
---
- ใช้ TypeScript strict, ห้าม any
- data fetching ใช้ [ไลบรารีที่ทีมใช้] เท่านั้น
- error handling ตาม pattern ใน @src/lib/errors.ts
- เขียนเทสต์คู่กับทุกฟังก์ชัน business logic

วิธีปรับใช้: Rule ที่ตั้ง globs จะถูก auto-attach เมื่อแก้ไฟล์ที่ตรง pattern ทำให้ทุกสูตรข้างบนสั้นลงเพราะไม่ต้องย้ำ convention เอกสารแนะนำให้ rule ยาวไม่เกิน ~500 บรรทัด และอ้างไฟล์ด้วย @filename แทนการคัดลอกเนื้อห��ทั้งฉบับ

💡 เก็บสูตรที่ใช้บ่อยของทีมไว้เป็น Project Rules แบบ Apply Manually แล้วเรียกด้วย @ชื่อ-rule ตอนต้องการ เท่ากับมี "คลัง prompt" ที่ version-controlled และแชร์กันทั้งทีมได้

เช็กลิสต์ปิดท้าย: ทำให้ทุกสูตรได้ผลจริง

แนบ context ที่ตรงจุด ด้วย @Files/@Code/@Git แทนการเล่าลอยๆ
ระบุ constraint และ "ห้ามทำ" ชัดเจน (ห้ามเปลี่ยน API, ห้ามเพิ่ม dependency)
บังคับให้สรุปแผนก่อนลงมือ สำหรับงานใหญ่ ใช้ Plan Mode
รันและตรวจผลด้วยตาเสมอ อย่าเชื่อคำสรุปว่า "แก้เสร็จแล้ว" ของ agent
ตกผลึกสิ่งที่ใช้ซ้ำเป็น Rules เพื่อไม่ต้องพิมพ์บริบทเดิมทุกครั้ง

บทที่ 13: ความปลอดภัย ความเป็นส่วนตัว (Privacy Mode) และข้อจำกัดที่ต้องรู้

Cursor เป็นเครื่องมือที่ทรงพลัง แต่การใช้งานอย่างมืออาชีพหมายถึงการเข้าใจว่า โค้ดของคุณเดินทางไปที่ไหน ถูกเก็บอย่างไร และ AI เชื่อถือได้แค่ไหน บทนี้จะปิดช่องว่างเหล่านั้น ทั้งเรื่องความเป็นส่วนตัว การรับรองด้านความปลอดภัย ข้อมูลที่ไม่ควรใส่ และวิธีรีวิวโค้ดที่ AI สร้างอย่างมีวิจารณญาณ

Privacy Mode: โค้ดของคุณถูกจัดการอย่างไร

หัวใจของเรื่องความเป็นส่วนตัวใน Cursor คือ Privacy Mode เมื่อเปิดใช้งานแล้ว:

โค้ดของคุณจะไม่ถูกนำไปเทรน (train) โมเดล ของใครทั้งสิ้น
ไม่ถูกจัดเก็บบนเซิร์ฟเวอร์ของ Cursor หลังประมวลผลเสร็จ (นโยบายแบบ Zero Data Retention / ZDR)

จุดที่ต้องเข้าใจให้ชัด: Privacy Mode ไม่ได้แปลว่าโค้ดไม่ออกจากเครื่องคุณเลย โค้ดยังคงถูกส่งไปยังโมเดล AI (เช่นเซิร์ฟเวอร์ของ OpenAI, Anthropic, Google) เพื่อประมวลผลและสร้างคำตอบ — เพียงแต่ Cursor จะไม่เก็บมันไว้ที่ฝั่งเซิร์ฟเวอร์ของตัวเองหลังจากตอบเสร็จ

💡 Privacy Mode เปิดใช้ได้กับผู้ใช้ทุกระดับ ทั้ง Free และ Pro ตั้งค่าได้ในหน้า Settings หรือถูกกำหนดจากส่วนกลางโดยผู้ดูแลระบบ (admin) สมาชิกใหม่ในทีมจะรับค่า Privacy Mode ของทีมโดยอัตโนมัติ

⚠️ ข้อควรระวังสำหรับแผนบุคคล (individual): แม้เปิด Privacy Mode ผู้ให้บริการโมเดลต้นทางบางรายอาจเก็บ prompt ไว้ช่วงสั้น ๆ (ราว 30 วัน) เพื่อการตรวจสอบ trust-and-safety ก่อนลบ รายละเอียดนี้ขึ้นกับข้อตกลงและอาจเปลี่ยนแปลง ควรตรวจสอบที่ trust.cursor.com

Codebase indexing กับความเป็นส่วนตัว

เมื่อ Cursor ทำ codebase indexing มันไม่ได้อัปโหลดซอร์สโค้ดของคุณเป็น plaintext ขึ้นเซิร์ฟเวอร์ แต่แบ่งโค้ดเป็น chunks แล้วคำนวณ embeddings เก็บไว้ใน remote vector database — เป็นตัวเลขที่ใช้ค้นหาความหมาย ไม่ใช่ไฟล์ต้นฉบับ นอกจากนี้ index ที่ไม่ถูกใช้งานจะถูกลบหลังไม่มี activity ประมาณ 6 สัปดาห์ (นโยบายอาจเปลี่ยน)

flowchart LR
    A[โค้ดในเครื่องคุณ] -->|ส่งเพื่อประมวลผล| B[Cursor Backend]
    B -->|forward prompt| C[Model Provider<br/>OpenAI / Anthropic / Google]
    C -->|คำตอบ| B --> A
    B -.->|Privacy Mode ON| D[ไม่เก็บโค้ดไว้<br/>Zero Data Retention]
    A -->|indexing| E[แบ่ง chunks + embeddings]
    E --> F[Vector DB<br/>ไม่เก็บ plaintext]

การรับรองด้านความปลอดภัยและระดับองค์กร

สำหรับองค์กรที่ต้องผ่านการประเมิน vendor security Cursor มีสิ่งเหล่านี้:

ด้าน	รายละเอียด
การรับรอง	SOC 2 Type II (ขอรายงานฉบับเต็มได้ที่ trust.cursor.com)
Penetration testing	ทำโดยบุคคลที่สามอย่างน้อยปีละครั้ง มี executive summary ให้ผ่าน trust portal
Identity	SSO (SAML/OIDC), SCIM สำหรับ provisioning
การ deploy	รองรับผ่าน MDM
การกำกับดูแล	admin policy enforcement, audit logs / compliance logging
การเข้ารหัส	ข้อมูลถูกเข้ารหัส รองรับ Customer-Managed Encryption Keys (CMEK)
Subprocessor	ไม่ใช้โครงสร้างพื้นฐานในจีน หลีกเลี่ยง subprocessor ที่มีสำนักงานใหญ่ในจีน รายชื่อเผยแพร่บน trust portal ทบทวนประจำปี

💡 ช่องทางรายงานช่องโหว่ด้านความปลอดภัยคือ security-reports@cursor.com โดยมีการตอบรับภายใน 5 วันทำการ องค์กรที่ใช้ proxy สามารถ allowlist backend domains ของ Cursor (API, indexing, update, marketplace) ได้

จุดที่ต้องระวังเป็นพิเศษ: BYOK และ MCP

BYOK (Bring Your Own Key): เมื่อคุณใส่ API key ของตัวเอง นโยบาย Zero Data Retention ของ Cursor จะไม่มีผล — การเก็บข้อมูลขึ้นกับข้อกำหนดของผู้ให้บริการที่คุณเลือกใช้ key นั้นแทน API key แบบ BYOK ถูกเก็บใน local settings ไม่ sync ข้ามเครื่อง ข้อจำกัดสำคัญที่มักเข้าใจผิด: BYOK ใช้ได้กับ chat models เท่านั้น — ส่วนฟีเจอร์ Tab completion ยังคงใช้โมเดล built-in ของ Cursor ไม่สามารถแทนด้วย key ของคุณเองได้ ดังนั้น BYOK จึงไม่ได้ครอบคลุมทุกฟีเจอร์ และไม่ได้ทำให้ทราฟฟิกทั้งหมดวิ่งผ่านบัญชีผู้ให้บริการของคุณ
MCP servers: การเชื่อม MCP server ภายนอกเท่ากับเปิดช่องให้เครื่องมือของบุคคลที่สามเข้าถึงบริบทได้ ใช้ MCP Allowlist และ approval workflow (ยืนยันก่อนรัน) อย่าเปิด auto-run กับ tool ที่ไม่ไว้ใจ

ข้อมูลและโค้ดที่ไม่ควรใส่

ไม่ว่าจะเปิด Privacy Mode หรือไม่ ให้ยึดหลัก "อย่าวางสิ่งที่คุณไม่อยากให้ออกจากเครื่องลงในบริบทของ AI":

Secrets ทุกชนิด: API keys, database credentials, private keys, tokens, .env — ใช้ .cursorignore กันไม่ให้ถูก index และอย่า paste ลงแชท
ข้อมูลส่วนบุคคล (PII) และข้อมูลลูกค้าจริง โดยเฉพาะข้อมูลที่อยู่ภายใต้ PDPA/GDPR — ใช้ข้อมูล mock แทนเมื่อ debug
โค้ดที่มีข้อผูกพันสัญญา/NDA ที่ห้ามส่งให้ third-party processor
ไฟล์ generated ขนาดใหญ่ที่ไม่จำเป็น (สิ้นเปลือง index และ context โดยเปล่าประโยชน์)

# ตัวอย่าง .cursorignore
.env
.env.*
**/secrets/**
**/*.pem
**/credentials.json

⚠️ ไฟล์ที่อยู่ใน .gitignore จะถูกยกเว้นจาก index โดยอัตโนมัติ แต่ อย่าพึ่งพาแค่นั้น — secret บางตัวอาจไม่ได้อยู่ใน .gitignore ตรวจ .cursorignore ให้ครอบคลุมเสมอ

ข้อจำกัดที่ต้องเข้าใจ: AI ไม่ได้ถูกเสมอไป

การใช้ Cursor อย่างมืออาชีพเริ่มจากการยอมรับว่า AI ผิดพลาดได้ และมักผิดแบบ "มั่นใจผิด ๆ"

Hallucination และรูปแบบความผิดพลาดที่พบบ่อย

โค้ดเบสขนาดใหญ่มาก (เกิน ~500,000–1,000,000 บรรทัด): AI อาจหา context ที่เกี่ยวข้องไม่เจอ ทำให้ hallucinate ง่ายขึ้น
API เฉพาะทาง/ใหม่ ที่ไม่ค่อยมีในข้อมูลเทรน: agent อาจ สร้างเมธอดหรือ API ที่ไม่มีอยู่จริง ขึ้นมาเอง
การอ้างว่าแก้บั๊กสำเร็จทั้งที่รันเทสต์ผิดตัว หรือ test ไม่ได้ครอบคลุมกรณีจริง

ตัวอย่างที่เกิดขึ้นจริงในปี 2025: แชตบอตซัพพอร์ตของ Cursor เอง เคย hallucinate นโยบายการใช้งานที่ไม่มีอยู่จริง — บทเรียนคือ อย่าเชื่อคำยืนยันของ AI โดยไม่ตรวจสอบ แม้จะเป็น AI ของบริษัทเทคเอง

การพึ่งพา AI มากเกินไป

การให้ agent เขียนโค้ดโดยไม่อ่าน ทำให้เกิดหนี้ทางเทคนิคเงียบ ๆ: โค้ดที่ทำงานได้แต่คุณไม่เข้าใจ, สถาปัตยกรรมที่ไม่สอดคล้องกัน, และช่องโหว่ด้านความปลอดภัยที่หลุดรอด ทักษะการอ่านและวิจารณ์โค้ดยังคงเป็นสิ่งที่ทดแทนไม่ได้

แนวทางรีวิวโค้ดที่ AI สร้างอย่างมีวิจารณญาณ

ให้ปฏิบัติต่อโค้ดจาก agent เหมือน Pull Request จากนักพัฒนาใหม่ที่เก่งแต่ไม่รู้จักโปรเจกต์คุณ:

flowchart TD
    A[AI เสนอการแก้ไข] --> B{อ่าน diff ทุกบรรทัด}
    B --> C{มี API / เมธอด<br/>ที่ไม่เคยเห็นไหม}
    C -->|มี| D[ตรวจว่ามีอยู่จริง<br/>ใช้ @Docs / @Web]
    C -->|ไม่มี| E{รัน test + lint}
    D --> E
    E -->|ผ่าน| F{ตรวจ secret / security<br/>/ edge cases เอง}
    E -->|ไม่ผ่าน| A
    F -->|ผ่าน| G[Apply / Commit]
    F -->|พบปัญหา| A

เช็กลิสต์รีวิวเชิงปฏิบัติ:

อ่าน diff เต็ม ก่อน apply — Cursor ให้ review/apply changes ทีละส่วนได้ ใช้ประโยชน์จากมัน อย่ากด accept รวด
ตรวจ API ที่น่าสงสัย ว่ามีอยู่จริงด้วย @Docs (เอกสารทางการที่ index ไว้) หรือ @Web แทนการเชื่อคำอ้างของ AI
รัน test และ linter ด้วยตัวเอง — อย่าเชื่อคำว่า "แก้เสร็จแล้ว" จนกว่าจะเห็นผลรันจริงด้วยตา และตรวจว่าเทสต์ที่รันคือตัวที่เกี่ยวข้อง
มองหา edge cases และ security ที่ AI มักมองข้าม: input validation, error handling, race conditions, SQL/command injection
ใช้ Bugbot (มีในแผน Pro บน usage-based billing) เป็นด่านรีวิวเสริม แต่ไม่ใช่ด่านสุดท้าย — human review ยังจำเป็นเสมอ
ให้ Plan Mode ทำงานหนักก่อน สำหรับฟีเจอร์ซับซ้อน: review แผนก่อนให้ build จะจับ misunderstanding ได้ตั้งแต่ต้นทาง ถูกกว่าตามแก้โค้ดทีหลังมาก

💡 ตั้ง Project Rules (.cursor/rules) ที่ระบุมาตรฐานความปลอดภัยของทีม เช่น "ห้าม hardcode secrets", "ต้อง validate input ทุก endpoint", "ใช้ parameterized query เสมอ" เพื่อให้ agent ยึดเป็นกรอบตั้งแต่ตอนสร้างโค้ด ลดภาระการรีวิวปลายทาง

สรุปหลักคิดของบทนี้: Cursor ให้เครื่องมือความปลอดภัยระดับองค์กร (Privacy Mode, ZDR, SOC 2 Type II, SSO/SCIM/CMEK) แต่ความรับผิดชอบสุดท้ายอยู่ที่คุณ — เลือกสิ่งที่ใส่เข้าไปในบริบทอย่างระมัดระวัง และอย่ายอมให้ความเร็วของ AI มาแทนที่วิจารณญาณในการรีวิว โค้ดที่ AI เขียนคือ ข้อเสนอ ไม่ใช่คำตัดสิน เสมอ

บทที่ 14: เทคนิคขั้นสูง คีย์ลัด การใช้สำหรับทีม และเทียบกับเครื่องมืออื่น

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

เทคนิคขั้นสูง

บริบทซ้ำ ๆ ด้วย Rules และไฟล์ที่อ้างอิงได้

หากคุณพบว่าตัวเองต้องพิมพ์คำอธิบายเดิม ๆ ให้ AI ทุกครั้ง (เช่น "โปรเจกต์นี้ใช้ TypeScript strict, ห้ามใช้ any") ให้ย้ายไปไว้ใน Project Rules (.cursor/rules/*.mdc) แทน วิธีนี้ทำให้บริบทถูกใส่อัตโนมัติและ version-controlled แชร์กับทั้งทีมได้ผ่าน git

💡 แทนที่จะคัดลอกเนื้อหา style guide ทั้งฉบับลงใน rule ให้ใช้ @filename อ้างอิงไฟล์จริง เอกสารแนะนำให้ rule ยาวไม่เกิน ~500 บรรทัด เพื่อให้ Agent โฟกัสได้

สำหรับข้อมูลอ้างอิงระหว่างงาน (เช่นสเปกฟีเจอร์ที่กำลังทำ) คุณสามารถเก็บเป็นไฟล์ markdown ในโปรเจกต์แล้วอ้างด้วย @Files ทุกครั้งที่คุยกับ Agent วิธีนี้ให้ผลคล้ายการเก็บบริบทซ้ำไว้ใช้งานได้ต่อเนื่อง (ชื่อเรียกฟีเจอร์อย่าง Notepads อาจต่างกันตามเวอร์ชัน ให้ตรวจสอบในแอปที่ใช้)

Background / Parallel Agents

Cursor รองรับการรัน agent หลายตัวพร้อมกัน:

Cloud Agents (เดิมชื่อ Background Agents) รันบน isolated virtual machines แยกจากเครื่องคุณ สามารถ build, test และสร้าง merge-ready PR ได้เอง โดยเครื่อง local ไม่ต้องเชื่อมต่ออินเทอร์เน็ตตลอดเวลา
เอกสารทางการระบุว่ารัน agent แบบ parallel ได้ "มากเท่าที่ต้องการ" เหมาะกับงานที่ครอบคลุมหลาย repo (frontend/backend/infra)
Cloud Agents รองรับ MCP servers เพื่อเข้าถึงเครื่องมือภายนอกและฐานข้อมูล

⚠️ แหล่งที่สาม (ไม่ใช่เอกสารทางการ) กล่าวถึง "Agents Window" ใน Cursor 3 ที่รัน parallel agents ในแต่ละ git worktree สูงสุด 8 ตัว ตัวเลขและวันที่เหล่านี้ยังไม่ยืนยัน ให้ยึด changelog ทางการเป็นหลัก

Cursor CLI

Cursor มี CLI สำหรับใช้ agent จาก terminal:

# ติดตั้ง (macOS/Linux/WSL)
curl https://cursor.com/install -fsS | bash

# Windows PowerShell
# irm 'https://cursor.com/install?win32=true' | iex

คำสั่งหลัก:

agent                 # เปิด session แบบโต้ตอบ
agent "แก้ bug ใน auth"  # เริ่มพร้อม prompt
agent ls              # ดูบทสนทนาก่อนหน้า
agent resume          # ทำต่อ session เดิม (หรือ --continue)

CLI มี 3 โหมด: Agent (เข้าถึง tool ทั้งหมด), Plan (ออกแบบแนวทาง+ถามคำถามก่อนลงมือ) และ Ask (อ่านอย่างเดียว ไม่แก้ไข) นอกจากนี้ยังรองรับ cloud handoff (นำหน้าด้วย & เพื่อส่งงานให้ Cloud Agent) และควบคุม sandbox ผ่าน /sandbox หรือ --sandbox โดย CLI ใช้ MCP config เดียวกับ editor

คีย์ลัดสำคัญ

ตารางด้านล่างสรุปคีย์ลัดหลัก (ตรวจสอบล่าสุดได้ที่ cursor.com/docs/reference/keyboard-shortcuts เพราะ URL/พฤติกรรมมีการเปลี่ยนแปลง)

การทำงาน	macOS	Windows/Linux
ยอมรับ Cursor Tab (ทั้งชุด)	`Tab`	`Tab`
ยอมรับทีละคำ (next word)	`Cmd + →`	`Ctrl + →`
ปฏิเสธ Tab	`Esc` / พิมพ์ต่อ	`Esc` / พิมพ์ต่อ
Inline Edit (Cmd K)	`Cmd K`	`Ctrl K`
Quick question (ใน Inline Edit)	`Opt Return`	`Alt Return`
ยกเลิก Inline Edit	`Cmd Shift Backspace`	`Ctrl Shift Backspace`
สลับ focus ช่อง input (Inline)	`Cmd Shift K`	`Ctrl Shift K`
เปิด Agent/Chat พร้อมโค้ดที่เลือก	`Cmd L`	`Ctrl L`
เปิด Chat sidepanel	`Cmd I` / `Cmd L`	`Ctrl I` / `Ctrl L`
สลับ mode (Agent/Plan)	`Shift + Tab`	`Shift + Tab`
Cursor Settings	`Cmd Shift J`	`Ctrl Shift J`
Command Palette (เช่น Reindex)	`Cmd Shift P`	`Ctrl Shift P`
Output panel (ดู MCP Logs)	`Cmd Shift U`	`Ctrl Shift U`

💡 หลังยอมรับคำแนะนำ Tab แล้ว กด Tab อีกครั้งเพื่อใช้ jump-in-file กระโดดไปยังตำแหน่งแก้ไขถัดไปที่ Cursor ทำนายไว้ ปรับคีย์ลัดได้โดยค้นหา "Accept Cursor Tab Suggestions" ใน keyboard shortcuts settings

การใช้ในทีมและองค์กร

Cursor แผน Teams ($40/user/mo Standard, $120/user/mo Premium) และ Enterprise เพิ่มเครื่องมือสำหรับการจัดการรวมศูนย์

ตั้ง Rules ร่วมกันทั้งทีม

Cursor รองรับ rules 4 ประเภท โดยมีลำดับความสำคัญชัดเจน (แหล่งที่มาก่อนหน้าชนะเมื่อขัดแย้ง):

flowchart TD
    A[Team Rules<br/>จัดการผ่าน dashboard<br/>Team/Enterprise] --> B[Project Rules<br/>.cursor/rules/*.mdc<br/>version-controlled]
    B --> C[User Rules<br/>global ต่อผู้ใช้]
    A -. precedence สูงสุด .-> C

Team Rules ตั้งระดับองค์กรผ่าน dashboard บังคับ convention ให้ทุกคนในทีม
Project Rules ผูกกับ codebase (commit เข้า git) ทุกคนที่ clone repo ได้ rule เดียวกันอัตโนมัติ
User Rules เป็นความชอบส่วนตัวของแต่ละคน

การจัดการสมาชิกและการตั้งค่า

SSO (SAML/OIDC), SCIM สำหรับ provisioning สมาชิก, deploy ผ่าน MDM
Centralized billing และ analytics ดู usage ของทีม
Shared team context: ฟีเจอร์ระดับทีมที่แชร์บริบทร่วมกันภายในองค์กร (มากับแผน Teams/Enterprise)
นอกจากนี้ Cursor ยังใช้เทคนิค reuse index ของเพื่อนร่วมทีม เพื่อลดเวลา time-to-first-query ใน repo ใหญ่ ซึ่งเป็นความสามารถของ codebase indexing โดยทั่วไป ไม่ได้ผูกกับแผน Teams/Enterprise โดยตรง
MCP Allowlist จำกัด server/tool ที่อนุมัติ พร้อม network controls (allow all / allowlist / deny all) และ denylist สำหรับ user MCP extensions

⚠️ แผน Teams/Enterprise มี surcharge เพิ่มประมาณ $0.25 ต่อล้าน token บนคำขอโมเดลบุคคลที่สาม ควรนำมาคำนวณต้นทุนรวมด้วย

ความปลอดภัยของข้อมูล

Privacy Mode: เมื่อเปิด โค้ดจะไม่ถูกนำไปเทรนโมเดลและไม่ถูกเก็บบนเซิร์ฟเวอร์ Cursor (zero data retention) โค้ดยังถูกส่งไปโมเดลเพื่อประมวลผล แต่ไม่ถูกเก็บหลังตอบเสร็จ เปิดใช้ได้ทุกระดับ (รวม Free) และ admin กำหนดให้ทั้งทีมได้ สมาชิกใหม่รับค่าของทีมอัตโนมัติ
Cursor ได้รับการรับรอง SOC 2 Type II (รายงานเต็มขอที่ trust.cursor.com) และทำ penetration testing โดยบุคคลที่สามอย่างน้อยปีละครั้ง
Enterprise รองรับ audit logs, การเข้ารหัส และ Customer-Managed Encryption Keys (CMEK)
Cursor ระบุว่าไม่ใช้โครงสร้างพื้นฐานในจีนและหลีกเลี่ยง subprocessor ที่มีสำนักงานใหญ่ในจีน

⚠️ บนแผนบุคคล แม้เปิด Privacy Mode ผู้ให้บริการโมเดลต้นทาง (เช่น OpenAI, Anthropic) อาจเก็บ prompt ไว้ช่วงสั้น ๆ (ราว 30 วัน) เพื่อ trust-and-safety review รายละเอียดอาจเปลี่ยนตามข้อตกลง หากใช้ BYOK นโยบาย ZDR ของ Cursor จะไม่มีผล ขึ้นกับข้อกำหนดของผู้ให้บริการที่คุณเลือก

เทียบ Cursor กับเครื่องมืออื่น

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

ประเด็น	Cursor	GitHub Copilot	Windsurf	Claude Code
รูปแบบ	AI code editor (fork ของ VS Code)	Extension ใน IDE/editor	AI code editor	CLI / terminal-based agent
ราคาเริ่มต้น (Pro)	~$20/mo (Tab ไม่จำกัด + เครดิตโมเดล)	~$10/mo (กำลังย้ายไป usage-based)	~$15–20/mo (Ultimate ~$60)	คิดตาม usage ผ่าน API หรือผ่าน subscription Claude
ราคา tier สูง	Pro+ ~$60, Ultra ~$200	ตาม usage	Pro Ultimate ~$60	~$3/M token (Sonnet), ~$15/M (Opus)
โมเดล	หลายค่าย (GPT, Claude, Gemini, Grok) + Composer ของตัวเอง	หลายค่าย	หลายค่าย	โมเดล Claude เป็นหลัก
จุดเด่นที่มักถูกกล่าวถึง	ความเร็ว, Tab autocomplete, Agent	ความคุ้มค่า/ราคา, integration กับ GitHub	editor-based agentic	คุณภาพงาน agentic

💡 บทสรุปเชิงเปรียบเทียบจากแหล่ง third-party มักกล่าวว่า Cursor เด่นด้านความเร็ว, Claude Code เด่นด้านคุณภาพ, และ Copilot เด่นด้านราคา แต่ตัวเลือกที่ดีที่สุดขึ้นกับ workflow, ขนาดทีม และข้อกำหนดความปลอดภัยของคุณมากกว่าคะแนนเบนช์มาร์ก

ข้อควรพิจารณาเพิ่มเติมสำหรับ Cursor:

Cursor ดึง extension จาก Open VSX Registry (ไม่ใช่ marketplace ของ Microsoft) ทำให้ extension proprietary บางตัวของ Microsoft ติดตั้งไม่ได้ แม้ราว 90% ของ extension จะมีในทั้งสอง registry
การย้ายจาก VS Code ทำได้แบบคลิกเดียว (Cmd/Ctrl+Shift+J > General > Account > Import) ย้าย Extensions, Themes, Settings และ Keybindings มาให้อัตโนมัติ

⚠️ ไม่ว่าจะใช้เครื่องมือใด human review เป็นสิ่งจำเป็นเสมอ เพราะ agent อาจ "มั่นใจผิด ๆ" เช่น สร้างเมธอด/API ที่ไม่มีอยู่จริง หรืออ้างว่าแก้บั๊กสำเร็จทั้งที่รันเทสต์ผิดตัว โดยเฉพาะในโค้ดเบสขนาดใหญ่มาก (เกิน ~500,000–1,000,000 บรรทัด) ที่ AI มีแนวโน้ม hallucinate สูงขึ้น

คำถามที่พบบ่อยเกี่ยวกับการใช้ Cursor (FAQ)

รวมคำถามยอดฮิตเกี่ยวกับ Cursor ที่ผู้ใช้ชาวไทยมักสงสัยก่อนตัดสินใจใช้งานจริง ตอบแบบกระชับ ตรงประเด็น อ้างอิงข้อมูล ณ กลางปี 2026 โดยชื่อรุ่นโมเดล ราคา และรายละเอียดฟีเจอร์อาจเปลี่ยนแปลงได้ ควรตรวจสอบล่าสุดที่ cursor.com/docs และ model picker ในแอปเสมอ

Cursor คืออะไร?

Cursor คือ AI code editor (โปรแกรมแก้โค้ดที่มี AI ในตัว) พัฒนาโดยบริษัท Anysphere ตัวโปรแกรมเป็น fork ของ VS Code จึงหน้าตาและการใช้งานคุ้นเคยสำหรับคนที่เคยใช้ VS Code แต่ฝัง AI เข้าไปในทุกจุดของ workflow ฟีเจอร์เด่นได้แก่:

Tab — AI autocomplete แนะนำโค้ดหลายบรรทัด ข้ามไฟล์ได้
Cmd/Ctrl+K — inline edit สั่งแก้โค้ดที่เลือกด้วยภาษาธรรมชาติ
Chat / Agent — ให้ AI วางแผน แก้หลายไฟล์ และรันคำสั่ง terminal ได้
ให้บริบทด้วย @-symbols (@Files, @Folders, @Code, @Docs, @Web, @Git) และตั้งกฎด้วย Rules for AI

ใช้ฟรีได้ไหม?

ได้ Cursor มีแผน Hobby (Free) ที่ไม่ต้องใส่บัตรเครดิต ให้ทดลอง Agent ได้จำนวนจำกัด พร้อมเข้าถึง Composer แต่ไม่มี credit pool ของโมเดลพรีเมียมแบบเสียเงิน เหมาะกับการลองใช้ก่อนตัดสินใจ ถ้าใช้จริงจังทุกวันควรอัปเป็นแผน Pro ขึ้นไป

ราคาแต่ละแผนเท่าไหร่ ต่างกันอย่างไร?

แผน	ราคา (ต่อเดือน)	จุดเด่นหลัก
Hobby	ฟรี	Agent จำกัด, ไม่ต้องใช้บัตร
Pro	~$20	Tab ไม่จำกัด + เครดิตโมเดล ~$20, Auto ไม่จำกัด
Pro+	~$60	เครดิตโมเดล ~$70 (ราว 3 เท่าของ Pro)
Ultra	~$200	เครดิต ~$400 (ราว 20 เท่า) + สิทธิ์ใช้ฟีเจอร์ใหม่ก่อน
Teams	~$40/ผู้ใช้ (Standard)	SSO, team privacy, analytics, บิลรวม
Enterprise	custom	SCIM, MDM, audit logs, CMEK

ทุกแผนเสียเงินได้ Tab ไม่จำกัด (ไม่กินเครดิต) และเข้าถึงโมเดล frontier ทั้งหมด, MCP, Cloud Agents และ Bugbot เมื่อใช้เครดิตหมด สามารถใช้ต่อแบบ pay-as-you-go ที่เรต API ได้

💡 Cursor แนะนำ Pro+ สำหรับคนใช้ Agent ทุกวัน (ผู้ใช้จริงมักใช้ราว $60–$100/เดือน) และ Ultra สำหรับ power user จ่ายรายปีลดราว 20%

ต่างจาก VS Code และ GitHub Copilot อย่างไร?

เทียบ VS Code: Cursor สร้างบน VS Code จึงใช้ extension, theme, keybinding เดิมได้ แต่เพิ่ม AI layer (ชั้น AI) ที่ทำงานระดับ Agent (แก้หลายไฟล์ + รัน terminal + วางแผน) ไม่ใช่แค่ autocomplete
เทียบ Copilot: Copilot Pro (~$10/เดือน) เน้น autocomplete และ chat เป็นหลัก ส่วน Cursor ออกแบบมาให้ AI เป็น agentic coding partner ที่ควบคุม codebase ทั้งก้อนได้ลึกกว่า พร้อม @-symbols, Rules, MCP และ Cloud Agents

โดยสรุปจากแหล่ง third-party: Cursor เด่นด้านความเร็วและ agent workflow, Copilot เด่นด้านราคา ตัวเลือกที่ดีสุดขึ้นกับ workflow และทีมของคุณ

Cursor ใช้โมเดล AI อะไร? สร้างโมเดลเองไหม?

Cursor ไม่ได้สร้างโมเดล frontier เอง แต่รวมโมเดลจากหลายผู้ให้บริการผ่าน model picker ได้แก่ OpenAI (GPT), Anthropic (Claude), Google (Gemini), xAI (Grok) และอื่น ๆ อย่างไรก็ตาม Cursor มีโมเดล first-party ของตัวเองคือตระกูล Composer (เช่น Composer 2.5) ที่เป็น agentic coding เร็วและถูกกว่าโมเดลบุคคลที่สาม

โหมดที่ควรรู้จัก:

Auto mode — Cursor เลือกโมเดลที่เหมาะสมให้อัตโนมัติ เหมาะกับคนที่ไม่อยากเลือกเอง
Max mode — ขยาย context window ให้ใหญ่สุด (บางโมเดลถึงระดับ 1M tokens) คิดเงินแบบ token-based ซึ่งแพงกว่ามาก ใช้เฉพาะงานที่ต้องอ่านโค้ดปริมาณมากจริง ๆ

💡 แนวทางเลือกโมเดลทั่วไปปี 2026: Claude Opus รุ่นล่าสุดสำหรับงาน agentic ยาก ๆ, GPT-5.x และ Gemini 3.x Pro เป็นตัวเลือกแข็งแกร่ง, Composer สำหรับงานเร็ว/ประหยัด (ชื่อรุ่นเปลี่ยนบ่อย ยึด model picker จริง)

ใส่ API key ของตัวเองได้ไหม (BYOK)?

ได้ Cursor รองรับ Bring Your Own Key จาก OpenAI, Anthropic, Google, Azure และ AWS Bedrock ข้อจำกัดที่ควรรู้:

BYOK ใช้ได้กับ chat models เท่านั้น ส่วน Tab completion ยังใช้โมเดล built-in ของ Cursor
key เก็บไว้ในเครื่อง (local) ไม่ sync ข้ามอุปกรณ์
เมื่อใช้ key ตัวเอง นโยบาย Zero Data Retention ของ Cursor จะไม่มีผล (ขึ้นกับข้อกำหนดของผู้ให้บริการที่คุณเลือก)

ย้ายจาก VS Code ยากไหม?

ง่ายมาก ทำได้แบบคลิกเดียว:

เปิด Cursor Settings (Cmd/Ctrl+Shift+J)
→ General > Account
→ กดปุ่ม Import ใต้หัวข้อ "VS Code Import"

จะย้าย Extensions, Themes, Settings และ Keybindings มาให้อัตโนมัติ หรือย้ายแบบ manual ผ่าน VS Code Profiles (Export/Import) ก็ได้

⚠️ Cursor ดึง extension จาก Open VSX Registry ไม่ใช่ marketplace ของ Microsoft ทำให้ extension proprietary บางตัวของ Microsoft (เช่นบางตัวที่ผูกลิขสิทธิ์) อาจติดตั้งไม่ได้ แม้ราว 90% ของ extension จะมีในทั้งสอง registry

flowchart LR
    A[VS Code เดิม] -->|Import คลิกเดียว| B[Cursor]
    B --> C[Extensions]
    B --> D[Themes]
    B --> E[Settings]
    B --> F[Keybindings]

โค้ดของเราปลอดภัยไหม?

Cursor มี Privacy Mode ที่เมื่อเปิดใช้ โค้ดจะไม่ถูกนำไปเทรนโมเดล และไม่ถูกเก็บบนเซิร์ฟเวอร์ ของ Cursor (zero data retention) โค้ดยังถูกส่งไปประมวลผลกับโมเดลเพื่อสร้างคำตอบ แต่ไม่ถูกเก็บไว้หลังตอบเสร็จ เปิดใช้ได้ทุกระดับ (รวม Free)

จุดที่น่าเชื่อถือสำหรับองค์กร:

ผ่านการรับรอง SOC 2 Type II (ขอรายงานได้ที่ trust.cursor.com)
ทำ penetration testing โดยบุคคลที่สามอย่างน้อยปีละครั้ง
แผนองค์กรมี SSO, SCIM, MDM, audit logs, การเข้ารหัส และรองรับ CMEK
Cursor ระบุว่าไม่ใช้โครงสร้างพื้นฐานในจีน และหลีกเลี่ยง subprocessor สัญชาติจีน

⚠️ บนแผนบุคคล แม้เปิด Privacy Mode ผู้ให้บริการโมเดลต้นทาง (เช่น OpenAI, Anthropic) อาจเก็บ prompt ไว้ช่วงสั้น ๆ (ราว 30 วัน) เพื่อการตรวจสอบ trust-and-safety ก่อนลบ รายละเอียดอาจเปลี่ยนตามข้อตกลง

ต้องเขียนโปรแกรมเป็นก่อนไหม?

ไม่จำเป็นต้องเชี่ยวชาญ แต่ ควรมีพื้นฐานพอสมควร เพื่อตรวจทานสิ่งที่ AI สร้าง เพราะ AI อาจ "มั่นใจผิด ๆ" เช่น สร้างเมธอด/API ที่ไม่มีจริง หรืออ้างว่าแก้บั๊กสำเร็จทั้งที่รันเทสต์ผิดตัว ปัญหา hallucination เกิดง่ายขึ้นในโค้ดเบสขนาดใหญ่มาก (เกิน ~500,000–1,000,000 บรรทัด) และกับ API เฉพาะทาง/ใหม่ ๆ ที่ไม่ค่อยมีในข้อมูลเทรน จึงควรมี human review เสมอ ผู้เริ่มต้นสามารถใช้ Cursor เรียนรู้ได้ แต่อย่ายอมรับโค้ดโดยไม่เข้าใจ

ใช้ภาษาไทยได้ไหม?

ได้ คุณสามารถพิมพ์ prompt เป็นภาษาไทยในช่อง Chat/Agent และสั่งงานได้ตามปกติ โมเดลหลัก ๆ (Claude, GPT, Gemini) เข้าใจภาษาไทยดี ตัวอย่าง:

ช่วยรีแฟกเตอร์ฟังก์ชันนี้ให้อ่านง่ายขึ้น และเพิ่ม error handling
สำหรับกรณีที่ input เป็น null พร้อมอธิบายเป็นภาษาไทย

💡 แม้สั่งงานภาษาไทยได้ แต่แนะนำให้เขียนชื่อตัวแปร ฟังก์ชัน และคอมเมนต์ในโค้ดเป็นภาษาอังกฤษ เพื่อความเข้ากันได้และให้ AI จับ context ได้แม่นยำ

Agent กับ Chat ต่างกันอย่างไร?

Chat เหมาะกับการถาม-ตอบและแก้ไขเล็ก ๆ ส่วน Agent เป็นโหมด agentic เต็มรูปแบบที่แก้หลายไฟล์ รัน terminal และทำงานต่อเนื่องได้โดยไม่จำกัดจำนวน tool call ต่อหนึ่งงาน นอกจากนี้ยังมี Plan Mode ที่ให้ AI สำรวจ codebase แล้วสร้างแผน implementation ให้ review ก่อนลงมือ (สลับโหมดด้วย Shift+Tab) และ Cloud Agents ที่รันบน VM แยก สร้าง merge-ready PR และรัน parallel ได้หลายตัว

จะควบคุมพฤติกรรม AI ให้ตรงสไตล์ทีมได้อย่างไร?

ใช้ Rules for AI โดยสร้างไฟล์ .mdc ในโฟลเดอร์ .cursor/rules (version-controlled ผูกกับ codebase) เพื่อกำหนด coding convention, style guide หรือข้อห้ามต่าง ๆ พร้อม frontmatter สั่งให้ apply เสมอ (alwaysApply), ตาม glob หรือให้ Agent เลือกใช้เอง ลำดับความสำคัญคือ Team Rules → Project Rules → User Rules นอกจากนี้ Cursor ยังรองรับ MCP (Model Context Protocol) เพื่อต่อเครื่องมือ/ฐานข้อมูลภายนอกผ่าน .cursor/mcp.json โดยมี approval workflow ก่อนรัน tool เป็นค่าเริ่มต้น

⚠️ ไฟล์ .cursorrules (ไฟล์เดี่ยวที่ root) เป็นรูปแบบ legacy ที่ยังรองรับเพื่อ backward compatibility แต่กำลังถูก deprecated แนะนำให้ย้ายไป .cursor/rules แทน