Cursor (AI IDE) ทำงานอย่างไร

• การเข้าใจกลไกการทำงานภายในของเครื่องมือโค้ดดิ้ง AI อย่าง Cursor, Windsurf และ Copilot ช่วยให้ เพิ่มประสิทธิภาพการทำงานและรักษาความสม่ำเสมอของผลลัพธ์ ได้ในโค้ดเบสที่ซับซ้อน
• หลายคนไม่เข้าใจข้อจำกัดของ AI IDE และใช้งานมันเหมือน เครื่องมือแบบดั้งเดิม จนทำให้ พบปัญหาด้านประสิทธิภาพ
• บทความนี้อธิบาย วิธีทำงานภายในของ Cursor, system prompt และวิธีปรับแต่งการเขียนโค้ดรวมถึงกฎของ Cursor ให้เหมาะสม

จาก LLM สู่เอเจนต์สำหรับการเขียนโค้ด

โมเดลภาษาขนาดใหญ่ (LLM)

• โดยพื้นฐานแล้ว LLM ทำงานด้วยการคาดเดาคำถัดไป
• เมื่อให้ พรอมป์ต์ แล้ว LLM จะสร้างคำตอบในลักษณะการเติมข้อความอัตโนมัติ
  • LLM แบบ decoder ยุคแรก (เช่น GPT-2) จำเป็นต้องมีการเขียนพรอมป์ต์เฉพาะเพื่อให้ได้ผลลัพธ์ที่ต้องการ
  • Prompt engineering คือเทคนิคในการ 'หลอก' โมเดลให้ตอบในแบบที่ต้องการ
• หลังการนำ Instruction Tuning มาใช้ ความสะดวกในการใช้งานก็ดีขึ้น
  • คำสั่งอย่าง “ช่วยเขียน PR สำหรับรีแฟกเตอร์เมธอด Foo ให้หน่อย” สามารถทำงานได้ทันที
  • ในความเป็นจริงมันคือเวอร์ชันขยายของกระบวนการ autocomplete
• มีการเพิ่ม Tool Calling
  • ทำให้โมเดลสามารถทำงานอย่างการอ่านไฟล์ เขียนไฟล์ และรันคำสั่งได้
  • ตัวอย่าง: read_file('index.py') → ไคลเอนต์ส่งเนื้อหาไฟล์ให้ → โมเดลดำเนินงานต่อ

การเขียนโค้ดแบบเอเจนต์

AI IDE อย่าง Cursor ถูกสร้างขึ้นด้วยโครงสร้าง wrapper ที่ซับซ้อน:

• ฟอร์กของ VSCode → เริ่มจากฐานโอเพนซอร์ส
• เพิ่ม UI แชตและเลือก LLM ที่เหมาะสม (เช่น Sonnet 3.7)
• ติดตั้งใช้งานเครื่องมือสำหรับเอเจนต์เขียนโค้ด
  • read_file(full_path: str)
  • write_file(full_path: str, content: str)
  • run_command(command: str)
• ปรับแต่งพรอมป์ต์
  • เพิ่มคำสั่งอย่าง "คุณคือโปรแกรมเมอร์ผู้เชี่ยวชาญ", "อย่าคาดเดา ให้ใช้เครื่องมือ" เป็นต้น
    → หากทำเพียงขั้นตอนข้างต้น จริง ๆ แล้วมันก็ใช้งานได้ แต่ก็อาจเกิดปัญหา syntax error, อาการหลอน, และ ความไม่สม่ำเสมอ

กลยุทธ์และเคล็ดลับในการปรับแต่งการเขียนโค้ดแบบเอเจนต์

• การสร้าง AI IDE ที่ดีต้องเข้าใจก่อนว่า LLM ทำงานใดได้ดี และต้อง ออกแบบพรอมป์ต์กับเครื่องมืออย่างระมัดระวังให้สอดคล้องกับข้อจำกัดของ LLM
  • วิธีที่มีประสิทธิภาพคือทำให้งานหลักเรียบง่าย และใช้โมเดลขนาดเล็กกว่าสำหรับงานย่อย
  • การกระจายงานที่ซับซ้อนช่วยปรับปรุงทั้งประสิทธิภาพและความสม่ำเสมอได้

• เพิ่มบริบทจากผู้ใช้ (ใช้ @file)

  • ผู้ใช้อาจรู้อยู่แล้วว่าไฟล์หรือบริบทใดเหมาะสม
  • เพิ่มไวยากรณ์ @file → ใส่เนื้อหาของไฟล์หรือโฟลเดอร์ทั้งหมดเพื่อส่งมอบบริบท
  • เคล็ดลับ: แนะนำให้ใช้ @folder/@file อย่างจริงจัง → การให้บริบทที่ชัดเจนช่วยเพิ่มทั้งความเร็วและความแม่นยำของคำตอบ

• ปรับแต่งการค้นหาโค้ด

  • การค้นหาโค้ดอาจซับซ้อน โดยเฉพาะการค้นหาเชิงความหมาย (เช่น "โค้ดยืนยันตัวตนอยู่ตรงไหน")
  • ทำดัชนีโค้ดเบสลงใน Vectorstore → เมื่อค้นหา LLM จะกรองและจัดอันดับใหม่โดยอัตโนมัติ
  • เคล็ดลับ: คอมเมนต์และเอกสารของโค้ดมีความสำคัญ → ช่วยเสริมประสิทธิภาพของ embedding model
    • เพิ่มคำอธิบายไว้ด้านบนของไฟล์ว่าไฟล์นี้มีไว้ทำอะไร มีความหมายอย่างไร และแก้ไขเมื่อใด

• ปรับแต่งการเขียนไฟล์

  • การเขียนโค้ดที่สมบูรณ์แบบเป็นเรื่องยากและมีต้นทุนสูง
  • แทนที่จะสร้างทั้งไฟล์ ให้สร้าง Semantic Diff → ส่งเฉพาะส่วนโค้ดที่แก้ไข
  • จากนั้นโมเดลแยกต่างหากจะนำ semantic diff ไปเขียนลงไฟล์จริง → แก้ไข syntax error
  • เคล็ดลับ: ไม่สามารถส่งคำสั่งพรอมป์ต์ให้โมเดลที่ทำหน้าที่ apply ได้โดยตรง → การส่งทั้งไฟล์ช่วยเพิ่มการควบคุม
  • เคล็ดลับ: โมเดล apply อาจช้าลงและเกิดข้อผิดพลาดเมื่อต้องแก้ไฟล์ขนาดใหญ่ → ควรรักษาขนาดไฟล์ไว้ที่ ไม่เกิน 500 LoC
  • เคล็ดลับ: ฟีดแบ็กจาก linter เป็นสัญญาณที่สำคัญมาก → ควรใช้ linter ที่เข้มงวด
    • ยังสามารถใช้ประโยชน์จากฟีดแบ็กที่ได้จากการคอมไพล์และภาษาที่มีระบบ type
  • เคล็ดลับ: ใช้ชื่อไฟล์ที่มีเอกลักษณ์ → แทน page.js ด้วย foo-page.js, bar-page.js เป็นต้น
    • ระบุพาธเต็มของไฟล์ในเอกสาร → ลดความกำกวมของเครื่องมือแก้ไข

• ใช้โมเดลที่ออกแบบมาสำหรับเอเจนต์โดยเฉพาะ

  • แนะนำให้ใช้ โมเดลที่ออกแบบมาสำหรับเอเจนต์ แทนโมเดลเขียนโค้ดทั่วไป
  • นี่คือเหตุผลที่โมเดลของ Anthropic ทำผลงานได้โดดเด่นใน IDE อย่าง Cursor
  • เคล็ดลับ: อย่ามองแค่ว่าเป็นโมเดลเขียนโค้ด แต่ให้เลือก โมเดลที่เหมาะกับ IDE แบบเอเจนต์
    • สามารถดูประสิทธิภาพของโมเดลได้จากลีดเดอร์บอร์ด WebDev Arena

• ใช้เครื่องมือแก้ไขตัวเอง (กลยุทธ์ขั้นสูง)

  • apply_and_check_tool → รัน linter ที่มีต้นทุนสูง พร้อมเก็บ console log และสกรีนช็อตจากเบราว์เซอร์แบบ headless
  • MCP(Model Context Protocol) → เพิ่มทั้งความเป็นอิสระของเอเจนต์และการส่งบริบท

การวิเคราะห์ system prompt ของ Cursor แบบละเอียด

• พรอมป์ต์ล่าสุดของ Cursor (March 2025) ถูกดึงออกมาด้วยเทคนิค prompt injection บนพื้นฐาน MCP
  • วิศวกร prompt ของ Cursor มีความสามารถด้านการเขียนพรอมป์ต์โดดเด่นแม้เทียบกับ AI IDE อื่น ๆ
  • การวิเคราะห์โครงสร้างพรอมป์ต์ช่วยพัฒนาทั้งประสิทธิภาพการสร้างโค้ดและความสามารถในการออกแบบสถาปัตยกรรมเอเจนต์ได้

• องค์ประกอบสำคัญของพรอมป์ต์และความหมาย

  • ใช้แท็กอย่าง "<communication>", "<tool_calling>"
    • ผสมการใช้ Markdown และแท็ก XML → มนุษย์อ่านง่ายและ LLM ประมวลผลง่าย
  • "powered by Claude 3.5 Sonnet"
    • เสริมความสม่ำเสมอของโมเดล → ป้องกันไม่ให้ LLM ให้ข้อมูลผิดเกี่ยวกับโมเดลที่กำลังรัน
  • "the world's best IDE"
    • ป้องกันไม่ให้ LLM แนะนำผลิตภัณฑ์อื่นเมื่อเกิดข้อผิดพลาด
  • "we may automatically attach some information…follow the USER's instructions…by the <user_query> tag."
    • ไม่ส่งพรอมป์ต์ของผู้ใช้โดยตรง แต่ห่อไว้ในแท็กพิเศษเพื่อลดความสับสน
  • "Refrain from apologizing"
    • ป้องกันการขอโทษที่ไม่จำเป็น (ช่วยชดเชยลักษณะเฉพาะของโมเดล Sonnet)
  • "NEVER refer to tool names when speaking"
    • เพิ่มคำสั่งไม่ให้กล่าวถึงชื่อเครื่องมือ → แต่ในโมเดลจริงก็มีกรณีที่ถูกเพิกเฉย
  • "Before calling each tool, first explain"
    • ให้อธิบายสถานะก่อนเรียกใช้เครื่องมือ → ปรับปรุงประสบการณ์ผู้ใช้
  • "partially satiate the USER's query, but you're not confident, gather more information"
    • ป้องกันการตอบเร็วเกินไปจากความมั่นใจเกินจริง → กระตุ้นให้หาข้อมูลเพิ่ม
  • "NEVER output code to the USER"
    • ห้ามแสดงโค้ดโดยตรงแก่ผู้ใช้ → อนุญาตให้สร้างโค้ดผ่านเครื่องมือเท่านั้น
  • "If you're building a web app from scratch, give it a beautiful and modern UI"
    • กระตุ้นให้สร้างเว็บแอปที่สวยงามและทันสมัยด้วยพรอมป์ต์เดียว (เพื่อการเดโม)
  • "you MUST read the the contents or section of what you're editing before editing it"
    • บังคับให้อ่านบริบทก่อนแก้โค้ด → เสริมการรับรู้บริบท
  • "DO NOT loop more than 3 times on fixing linter errors"
    • จำกัดลูปการแก้ไข → ป้องกันลูปไม่สิ้นสุด
  • "Address the root cause instead of the symptoms."
    • ชี้นำให้แก้ที่สาเหตุรากแทนการแก้แค่อาการ
  • "DO NOT hardcode an API key"
    • คำสั่งเพื่อเสริมความปลอดภัย → ป้องกันการ hardcode
  • "codebase_search", "read_file", "grep_search", "file_search", "web_search"
    • มีเครื่องมือค้นหาหลายแบบเพื่อให้ได้บริบทที่ถูกต้องก่อนเขียนโค้ด
  • มีข้อกำหนด "One sentence explanation…why this command needs to be run…"
    • เสริมตรรกะระหว่างการประมวลผลอาร์กิวเมนต์ของเครื่องมือ → ใช้เทคนิคปรับปรุงพรอมป์ต์
  • เครื่องมือ "reapply" คือ "Calls a smarter model to apply the last edit"
    • นำการแก้ไขล่าสุดไปใช้ซ้ำด้วยโมเดลที่ฉลาดกว่า → เพิ่มคุณภาพของการแก้ไข
  • เครื่องมือ "edit_file" คือ "represent all unchanged code using the comment of the language you're editing"
    • แสดงโค้ดที่ไม่เปลี่ยนด้วยคอมเมนต์ของภาษาที่กำลังแก้ไข → เพิ่มความแม่นยำของโมเดลแก้ไข
• การใช้ prompt caching
  • system prompt และคำอธิบายเครื่องมือถูกคงไว้เป็น สถานะคงที่
  • ไม่มีการปรับแต่งตามโค้ดเบสหรือผู้ใช้ → จึงสามารถใช้ prompt caching เพื่อลดต้นทุนและเพิ่มความเร็วในการประมวลผลได้

การเขียนและใช้งานกฎของ Cursor อย่างมีประสิทธิภาพ

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

• แนวคิดหลักของการเขียนกฎ

  • LLM จะเรียก fetch_rules(…) โดยอิงจากชื่อและคำอธิบายของรายการกฎ
  • กฎจะไม่ถูกเพิ่มเข้าไปใน system prompt แต่จะถูกอ้างอิงเมื่อจำเป็น
  • เพราะฉะนั้นรูปแบบคำอธิบายเชิงสารานุกรมจึงมีประสิทธิภาพกว่าการสั่งตรง ๆ

• สิ่งที่ควรหลีกเลี่ยงเมื่อเขียนกฎ

  • ห้ามกำหนดอัตลักษณ์ (identity)
    • ห้ามใช้คำอธิบายอย่าง "คุณคือผู้เชี่ยวชาญ TypeScript"
    • LLM รู้ตัวตนของตัวเองจากพรอมป์ต์ที่ฝังอยู่แล้ว → เสี่ยงต่อการขัดแย้ง
  • ห้ามพยายามเขียนทับ system prompt
    • คำสั่งอย่าง "อย่าเพิ่มคอมเมนต์", "ให้ถามก่อนแล้วค่อยเขียนโค้ด" → ทำให้การใช้เครื่องมือภายในสับสน
  • หลีกเลี่ยงคำสั่งเชิงลบ
    • คำสั่งเชิงบวกอย่าง "ให้ทำ" มีประสิทธิภาพกับ LLM มากกว่า "ห้ามทำ"
    • ตัวอย่างคำสั่งเชิงบวก: "เมื่อต้องแก้ไฟล์ ให้อ่านบริบททั้งหมดก่อนแล้วค่อยแก้"

• สิ่งที่แนะนำเมื่อเขียนกฎ

  • ตั้งชื่อและคำอธิบายกฎให้ชัดเจนและเข้าใจง่าย
    • ควรทำให้กฎถูกใช้งานได้แม้มีข้อมูลเกี่ยวกับโค้ดเบสเพียงเล็กน้อย
    • สามารถสร้างกฎที่ซ้ำกันได้ → ช่วยเพิ่มความแม่นยำของการค้นหา
  • เขียนกฎในรูปแบบสารานุกรม
    • ให้คำอธิบายสถานการณ์และวัตถุประสงค์ มากกว่าคำสั่งเฉพาะเจาะจง
    • หากจำเป็นสามารถแนบไฟล์โค้ดเพื่อเพิ่มบริบทได้
  • ใช้ Cursor ช่วยร่างกฎ
    • LLM เก่งในการเขียนบริบทให้ LLM ตัวอื่น
    • ตัวอย่าง: "@folder/ สร้างไฟล์ Markdown เกี่ยวกับพาธโค้ดและคำนิยามที่ถูกแก้ไขบ่อย"
  • อย่าเขียนกฎมากเกินไป
    • การมีกฎมากเกินไปไม่มีประสิทธิภาพ และอาจสะท้อนว่าโค้ดเบสไม่เป็นธรรมชาติ
    • โค้ดเบสที่ดีควรทำให้เอเจนต์ทำงานได้ด้วยกฎเพียงเล็กน้อย

• ตัวอย่างการเขียนกฎที่มีประสิทธิภาพ

  • ✅ คำสั่งกฎ:
    • "อ่านบริบททั้งหมดก่อนแก้ไฟล์"
    • "เมื่อต้องแก้โค้ดฝั่งเซิร์ฟเวอร์ ให้ตรวจสอบตรรกะของโค้ดยืนยันตัวตน"
    • "เมื่อเกิดข้อผิดพลาด ให้แก้ที่สาเหตุก่อน"
  • ❌ คำสั่งกฎ (ควรหลีกเลี่ยง):
    • "ห้ามลบคอมเมนต์"
    • "ให้ถามฉันก่อนแก้ไข"
    • "ห้ามแก้โค้ดที่ไม่จำเป็น"

• กลยุทธ์หลักของการเขียนกฎ

  • เขียนกฎเป็น คำอธิบายสถานการณ์ ไม่ใช่ คำสั่ง
  • ใช้ชื่อและคำอธิบายที่เข้าใจง่าย → ให้ได้ประสิทธิภาพสูงสุดด้วยกฎให้น้อยที่สุด
  • เน้นคำอธิบายสถานการณ์และการเชื่อมโยงโค้ด มากกว่าคำสั่งที่เฉพาะเจาะจง

บทสรุป

• การที่ Cursor ซึ่งเริ่มต้นจากการฟอร์ก VSCode แล้วใช้พรอมป์ต์บนฐานโอเพนซอร์สและ public model API ได้รับการประเมินมูลค่าเกือบ 1 หมื่นล้านดอลลาร์สหรัฐ (ราว 13 ล้านล้านวอน) ถือว่าน่าทึ่งมาก
  • ปัจจุบัน Cursor ถูกประเมินมูลค่าที่ 6 เท่า ตามเกณฑ์ "wrapper multiple"
• Cursor มอบประสิทธิภาพที่ทรงพลังด้วย พรอมป์ต์ที่ถูกปรับแต่งอย่างเหมาะสม และ ระบบ tool calling ที่แข็งแกร่ง
• ความเป็นไปได้ที่ Cursor จะพัฒนา agent model ของตัวเองนั้นมีน้อย
  • ในทางกลับกัน มีแนวโน้มสูงที่ Anthropic จะออกผลิตภัณฑ์คู่แข่งที่ใช้ Claude Code และ Sonnet เป็นฐาน

• อินไซต์สำคัญ

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

"ถ้า Cursor ทำงานไม่ได้ คุณควรกลับไปทบทวนวิธีใช้งานของตัวเอง"

[bluekai17]

คงต้องลองนำไปใช้ดูนะ

[ohyecloudy]

ใช้ Cursor เพื่อร่างกฎ
LLM เก่งในการเขียนคอนเท็กซ์ให้ LLM อื่น

น่าสนใจดีนะ หรือว่าเพราะดื่มน้ำสายเดียวกัน?

[linker]

มีมุมมองที่ลึกซึ้งอยู่ในนั้นเลย ขอบคุณครับ

[nicewook]

• การวิเคราะห์เชิงลึกของ system prompt ของ Cursor น่าประทับใจมาก
• แค่คิดว่า Anthropic อาจเปิดตัว AI IDE ก็เริ่มตั้งตารอแล้ว