Understanding Cursor and WindSurf's Code Indexing Logic

  tr_cn        2024-12-21 20:23:54       1,403        0          English  简体中文  繁体中文  ภาษาไทย  Tiếng Việt 

พื้นหลัง: ความสำคัญของบริบทในการเขียนโปรแกรม AI

ถ้า “ความฉลาด” ของโมเดลขนาดใหญ่ เช่น Claude 3.5 Sonnet เป็นปัจจัยหลักที่ขับเคลื่อนการก้าวกระโดดแบบเป็นขั้นตอนในความสามารถในการเขียนโปรแกรม AI ปัจจัยสำคัญอีกอย่างหนึ่งคือ ความยาวของบริบท

ปัจจุบัน Claude 3.5 Sonnet มีความยาวบริบทสูงสุด 200,000 โทเค็น แม้ว่าจะมากกว่าที่เพียงพอสำหรับโมเดลการสนทนา—สามารถจัดการหนังสือที่มีคำ 50,000 หรือแม้แต่ 100,000 คำได้อย่างง่ายดาย—แต่ก็ยังน้อยเกินไปสำหรับโครงการเขียนโปรแกรมที่เกี่ยวข้องกับไฟล์โค้ดหลายสิบหรือหลายร้อยไฟล์ โดยแต่ละไฟล์มีหลายร้อยหรือหลายพันบรรทัด นอกจากนี้ ด้วยโมเดลขนาดใหญ่ที่คิดค่าใช้จ่ายตามจำนวนโทเค็นอินพุตและเอาต์พุต ต้นทุนส่วนเพิ่มจึงไม่ใช่เรื่องเล็กน้อย

ลักษณะทั้งสองนี้ได้กระตุ้นให้เครื่องมือเขียนโปรแกรม AI เช่น Cursor และ Windsurf นำการปรับให้เหมาะสมหลายอย่างมาใช้โดยมีวัตถุประสงค์ดังต่อไปนี้:

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

ภายใต้ข้อจำกัดและเป้าหมายที่กล่าวมาข้างต้น Cursor และ Windsurf ได้ใช้กลยุทธ์การปรับให้เหมาะสมที่แตกต่างกันเพื่อเพิ่มประสบการณ์ผลิตภัณฑ์ของตน อย่างไรก็ตาม “การปรับให้เหมาะสม” ดังกล่าว มักเกี่ยวข้องกับการแลกเปลี่ยน ทำให้ได้เพียงวิธีแก้ปัญหาที่ดีที่สุดในพื้นที่และหลีกเลี่ยงไม่ได้ที่จะเสียสละบางแง่มุมของประสบการณ์การใช้งาน

จุดประสงค์ของบทความนี้คือเพื่อช่วยให้ทั้งคุณและฉันเข้าใจวิธีการและตรรกะเบื้องหลัง “การปรับให้เหมาะสม” ของพวกเขา ด้วยการเข้าใจการแลกเปลี่ยนที่เกี่ยวข้องในการปรับแต่งเหล่านี้ เราสามารถใช้ประโยชน์จากจุดแข็งและจุดอ่อนของผลิตภัณฑ์ต่างๆ ได้ดีขึ้น ความเข้าใจนี้จะช่วยให้เราสามารถเปลี่ยนเครื่องมือและปรับวิธีการใช้งานในสถานการณ์ต่างๆ ได้ในที่สุดเพื่อให้ได้วิธีแก้ปัญหาที่ดีที่สุดสำหรับงานของเรา

สรุป: Windsurf สำหรับการเริ่มต้น Cursor สำหรับการปรับให้เหมาะสม

จากประสบการณ์ล่าสุดและการประเมินเชิงปฏิบัติของ Cursor 0.43.6 และ Windsurf 1.0.7 เมื่อวันที่ 15 ธันวาคม ได้ข้อสรุปดังต่อไปนี้:

1. สำหรับผู้เริ่มต้นที่ทำงานพื้นฐาน: Windsurf > Cursor Agent > Cursor Composer (โหมดปกติ)

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

Agent ของ Windsurf แสดงให้เห็นถึงความเข้าใจงานและความสามารถในการทำงานหลายขั้นตอนที่ดีกว่า Agent ของ Cursor ในโหมด Composer

2. ข้อจำกัดสำคัญของโหมด Agent: การอ่านไฟล์ไม่สมบูรณ์

ข้อจำกัดนี้ส่งผลกระทบต่อโครงการที่ซับซ้อนและไฟล์โค้ดขนาดใหญ่

  • ในโหมด Agent ของ Cursor ค่าเริ่มต้นคือการอ่าน 250 บรรทัดแรกของไฟล์ ถ้าต้องการมากกว่านั้น บางครั้งจะขยายโดยอัตโนมัติอีก 250 บรรทัด สำหรับงานที่กำหนดไว้อย่างดีบางอย่าง Cursor จะทำการค้นหา โดยแต่ละการค้นหาจะส่งคืนโค้ดสูงสุด 100 บรรทัด
  • Windsurf อ่าน 200 บรรทัดต่อไฟล์โดยค่าเริ่มต้น และถ้าจำเป็น จะลองใหม่ได้สูงสุด 3 ครั้ง อ่านได้สูงสุด 600 บรรทัด

3. Cursor มีประสิทธิภาพเหนือกว่า Windsurf สำหรับการทำงานไฟล์เดียว

ใน Cursor ถ้าคุณ @ ไฟล์เฉพาะ มันจะพยายามอ่านไฟล์ให้สมบูรณ์ที่สุดเท่าที่จะเป็นไปได้ (ทดสอบแล้วสูงสุด 2,000 บรรทัด)

ใน Windsurf การ @ ไฟล์จะช่วยในการค้นหาไฟล์ที่เกี่ยวข้อง แต่จะไม่กระตุ้นให้มีการอ่านไฟล์นั้นอย่างสมบูรณ์ นี่คือความแตกต่างที่สำคัญในตรรกะระหว่างเครื่องมือทั้งสอง

4. เมื่อคุณเข้าใจโครงสร้างโครงการ: Cursor ทำงานได้ดีขึ้นด้วยการโฟกัสไฟล์เดียว

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

3. กระบวนการทดสอบ

ข้อสรุปทั้งหมดข้างต้นนั้นมาจากการใช้งาน Cursor และ Windsurf เป็นประจำทุกวันของฉัน (500+ ชั่วโมง) และการทดสอบเฉพาะเป้าหมาย ในการทดสอบนี้ ฉันใช้ไฟล์คำบรรยายวิดีโอที่มี 1,955 บรรทัด ไฟล์คำบรรยายมีการประทับเวลาและเนื้อหาที่เชื่อมโยงกันอย่างหลวมๆ ทำให้สามารถกำหนดได้ง่ายว่าเครื่องมือเขียนโปรแกรม AI อ่านไฟล์จริงหรือไม่และอ่านมากแค่ไหน—ไม่มีที่ว่างสำหรับ “การเดา”

เพื่อให้แน่ใจว่าเครื่องมือต่างๆ กำลัง “อ่าน” จริงๆ แทนที่จะสรุปผ่าน Retrieval-Augmented Generation (RAG) ฉันได้แทรกเนื้อหาที่ไม่เกี่ยวข้องทุกๆ 500 บรรทัด การแทรกแบบสุ่มเหล่านี้รวมถึง:

• “กีฬาที่ Peanut ชื่นชอบคือเทนนิส”

• “ทีมบาสเก็ตบอลที่ Peanut ชื่นชอบคือ Lakers”

• “Peanut ชอบสวมหมวกโดมสีขาว”

• “อาหารที่ Peanut ชื่นชอบคือกุ้งมังกร”

รอบการทดสอบ:

รอบที่ 1: Cursor Composer (โหมดปกติ)

Cursor ไม่ได้ค้นหาหรืออ่านไฟล์คำบรรยายอย่างกระตือรือร้น ส่งผลให้ภารกิจล้มเหลว

รอบที่ 2: Cursor Composer (โหมด Agent)

ในโหมด Agent Cursor พบและอ่านไฟล์คำบรรยาย แต่เพียง 250 บรรทัดเท่านั้น

รอบที่ 3: Windsurf Cascade (โหมด Agent เริ่มต้น)

Windsurf พบและอ่านไฟล์คำบรรยาย พยายามอ่านสามครั้งแต่ถึงเพียง 600 บรรทัดเท่านั้น

รอบที่ 4: Cursor Compose (โหมดไฟล์เดียว @)

โดยการ @ ไฟล์อย่างชัดเจน Cursor อ่านทั้งหมด 1,955 บรรทัดอย่างสมบูรณ์ ส่งคืนผลลัพธ์ที่ถูกต้องเป็นครั้งแรก นอกจากนี้ยังผ่านคำถาม “กับดัก” แบบสุ่ม ยืนยันว่าอ่านเนื้อหาอย่างแท้จริง

รอบที่ 5: Cursor Compose (โหมด @codebase)

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

รอบที่ 6: Windsurf Cascade (โหมดไฟล์เดียว @)

การ @ ไฟล์อย่างชัดเจนใน Windsurf ยังคงส่งผลให้มีการสรุปเพียง 600 บรรทัด ยืนยันว่าไม่ได้อ่านไฟล์อย่างสมบูรณ์

คำแนะนำสำหรับการใช้ Cursor และ Windsurf ในสถานการณ์ต่างๆ

  1. เก็บแต่ละไฟล์โค้ดไว้ต่ำกว่า 500 บรรทัด สิ่งนี้จะทำให้แน่ใจว่าไฟล์ยังคงอยู่ในช่วงที่ Cursor Agent สามารถอ่านได้ในสองครั้ง
  2. บันทึกฟังก์ชันและตรรกะการใช้งานของแต่ละไฟล์โค้ดใน 100 บรรทัดแรกอย่างชัดเจน ใช้ความคิดเห็นเพื่อให้ง่ายต่อการจัดทำดัชนีและทำความเข้าใจวัตถุประสงค์ของไฟล์โดย Agent
  3. สำหรับผู้เริ่มต้นหรือโครงการง่ายๆ ในขั้นตอนเริ่มต้น Windsurf มีประสิทธิภาพมากกว่า Windsurf ทำงานได้ดีในการจัดการงานและโครงการที่ตรงไปตรงมาสำหรับผู้ใช้ใหม่
  4. สำหรับโครงการที่ซับซ้อนที่มีไฟล์มากกว่า 600 บรรทัด ถ้าคุณคุ้นเคยกับโครงการ เข้าใจงานของคุณ และรู้ว่าไฟล์โค้ดใดเกี่ยวข้อง การใช้ Cursor และการ @ ไฟล์ที่เกี่ยวข้องอย่างชัดเจนจะให้ผลลัพธ์ที่ดีที่สุด
  5. เริ่มการสนทนาใหม่บ่อยๆ ตัวอย่างเช่น หลังจากเสร็จสิ้นคุณลักษณะใหม่หรือแก้ไขข้อบกพร่อง การเริ่มต้นการโต้ตอบใหม่จะช่วยป้องกันไม่ให้บริบทที่ยาวเกินไปทำลายโครงการ
  6. บันทึกสถานะและโครงสร้างของโครงการของคุณเป็นประจำในไฟล์เฉพาะ (เช่น README.md) สิ่งนี้ช่วยให้ Cursor และ Windsurf เข้าใจสถานะของโครงการของคุณได้อย่างรวดเร็วเมื่อเริ่มการสนทนาใหม่ ลดความเสี่ยงในการนำบริบทที่มากเกินไปหรือไม่จำเป็นมาใช้

หมายเหตุ: บทความนี้ได้รับอนุญาตจาก 花叔 ให้แปลและเผยแพร่ซ้ำ ลิงก์ต้นฉบับภาษาจีน: https://mp.weixin.qq.com/s/Fl-K-tdRuhlT9I-bcLbtdg

COMPARISON  CURSOR  WINDSURF  INDEXING 

       

  RELATED


  0 COMMENT


No comment for this article.



  RANDOM FUN

Requirement changes again