สรุป
- รายงานผลการทดลอง (Zero-context, N=5) ระบุว่า หลังจากรีแฟกเตอร์โครงสร้างโค้ด (แพตเทิร์น Strategy·Factory, แยกไฟล์, จัดระเบียบ
.cursorrules) ด้วยพรอมต์เพียงบรรทัดเดียว แล้วรันพรอมต์เพิ่มฟีเจอร์แบบเดิมอีกครั้ง ปริมาณการใช้โทเค็นของ AI ลดลงอย่างมาก โดยเปิดเผยทั้งพรอมต์และซอร์สที่ใช้ในการทดลอง ทำให้สามารถทำซ้ำได้
ข้อมูลสำคัญ
-
Claude-4 Sonnet: เฉลี่ย 390,159 → 242,265 tokens (−37.91%)
-
GPT-5: เฉลี่ย 315,839 → 233,634 tokens (−26.03%)
-
เกณฑ์อ้างอิง: Total Tokens ที่ Cursor แสดงผล การเปรียบเทียบค่าตัวเลขแบบสัมบูรณ์ข้ามโมเดลไม่มีความหมาย (เพราะวิธีนับต่างกันในแต่ละโมเดล)
การตั้งค่า (สรุป)
-
IDE Cursor 1.6.6, โมเดล GPT-5 / Claude-4 Sonnet
-
พรอมต์ทั้งหมดเป็น Zero-context และรีสตาร์ตเอดิเตอร์ใหม่ทั้งหมดในทุกรอบ
-
การตัดสินความสำเร็จ: หากสามารถทำตามข้อกำหนดได้ด้วยพรอมต์เดียว ให้นับว่าสำเร็จ
ทำไมจึงสำคัญ
-
“โครงสร้างโค้ดที่ดี” ไม่ได้ช่วยแค่อ่านง่ายสำหรับมนุษย์เท่านั้น แต่ยังส่งผลต่อโทเค็น ต้นทุน และเวลาของ AI ด้วยอย่างมีหลักฐานเชิงปริมาณ
-
มีการเปิดเผยพรอมต์และรีโพซิทอรี จึงทำให้ตรวจสอบซ้ำได้ (นำไปใช้ในงานจริงและทดลองต่อยอดได้ทันที)
ความเห็นส่วนตัว
- ในฐานะผู้ใช้ Cursor ผมมองว่านี่เป็นแนวทางที่ยอดเยี่ยม ซึ่งเสนอวิธีการสำคัญสำหรับการประหยัดค่าใช้จ่าย
- อย่างที่มีระบุไว้ในเนื้อหา การสุ่มตัวอย่างที่ยังไม่เพียงพอเป็นจุดที่น่าเสียดายอยู่บ้าง.
34 ความคิดเห็น
ไปเรียนสถาบันตั้งพาดหัวมาหรือไง..
อ่านการทดลองได้สนุกมากครับ
ขอบคุณครับ
แยกจากเนื้อหาแล้ว ผมว่าคงยิ่งรู้สึกแบบนั้นเพราะชื่อเรื่องที่บอกว่าเป็นพรอมป์ต์แค่บรรทัดเดียว ทำให้สิ่งที่คาดว่าจะได้อ่านกับเนื้อหาในบทความจริงต่างกันนะครับ
ใช่ครับ ผมก็คิดเหมือนกัน T_T
ขออภัย;;
ขอบคุณทุกท่านที่ให้ความสนใจกับบทความนี้เป็นอย่างมาก เนื่องจากมีเป้าหมายหลักเพื่อเผยแพร่ในต่างประเทศ จึงเขียนบทความเป็นภาษาอังกฤษ และดูเหมือนว่าสิ่งนี้จะทำให้เกิดปัญหาหลายอย่าง
ด้วยเหตุนี้ จึงขอแชร์โพสต์ที่สรุปเป็นภาษาเกาหลีไว้
https://modgo.org/tokeun-sayongryang-37-91-reul-gamsosikin-dan-hanjuly…
ขอสรุปเพิ่มเติมเกี่ยวกับพรอมป์ต์ที่ใช้เพิ่มเข้ามาไว้ดังนี้
อย่างไรก็ดี วิธีนี้จะเหมาะกับนักพัฒนาที่ต้องเขียนพรอมป์ต์เพื่อปรับปรุงโครงสร้างมากกว่า เนื่องจากแต่ละโปรแกรมมีลักษณะต่างกัน จึงจำเป็นต้องมีความรู้ด้านการพัฒนาพอสมควรเพื่อให้ปรับปรุงได้อย่างมีประสิทธิภาพสูง
แต่ก็ไม่ได้หมายความว่าสาย vibe coder ที่ไม่ใช่นักพัฒนาจะใช้วิธีนี้ไม่ได้ แม้ประสิทธิภาพอาจแตกต่างกันอยู่บ้าง แต่เพียงใช้คำสั่งง่าย ๆ อย่าง "ช่วยจัดระเบียบโค้ดโปรเจกต์ให้หน่อย ลบโค้ดที่ไม่ได้ใช้ออก" AI ก็สามารถแยกไฟล์และคลาสรวมถึงจัดระเบียบให้ได้
อย่างไรก็ตาม รายละเอียดของการปรับปรุงโครงสร้างอาจทำให้ประสิทธิภาพแตกต่างกันได้ จึงต้องระมัดระวังในการอ้างอิงข้อมูล
ควรใส่เฉพาะประเด็นสำคัญลงในพรอมป์ต์อย่างเป็นเหตุเป็นผล กล่าวคือยิ่งใส่นั่นใส่นี่ลงไปในพรอมป์ต์มากเท่าไร ก็ยิ่งมี noise มากขึ้น ทำให้โค้ดที่ได้ออกมาซับซ้อนขึ้นและมี noise มากขึ้น แบบนั้นใช่ไหม?
ประเด็นสำคัญคือ หลังจากสั่งให้ AI รีแฟกเตอร์โครงสร้างโค้ดแล้ว ปริมาณโทเคนที่ใช้ก็ลดลง
ในทางกลับกัน ก็อาจอธิบายได้ว่า หากสั่งงานต่อไปทั้งที่โค้ดยังมีข้อบกพร่องเชิงโครงสร้าง การใช้โทเคนก็จะเพิ่มขึ้น
สรุปคือ เนื้อหานี้พูดถึงความจำเป็นที่ต้องปรับปรุงโครงสร้างของซอร์สโค้ด ไม่ได้หมายความว่าพรอมต์ควรถูกย่อให้เหลือแค่แกนหลักอย่างมีตรรกะเท่านั้น
ผมก็รู้สึกเหมือนกันว่าทั้งบทเกริ่นนี้และต้นฉบับเยิ่นเย้อเกินไป และอ่านยากเหมือนเขียนโดยคนที่เขียนหนังสือไม่ค่อยเก่ง
สรุปใจความคือ
"ให้เพิ่มคำสั่งหนึ่งบรรทัดที่ใส่ข้อจำกัดเชิงโครงสร้างเพื่อลดจำนวนโทเค็น"
ประมาณนี้ครับ
บทความนี้มีลักษณะใกล้เคียงกับงานวิจัยเชิง "การทดลอง"
ดังนั้น ตัวเลขทั้งหมดที่อยู่ในบทความนี้จึงมุ่งเน้นให้ผู้อ่านทุกคนสามารถ "ทำซ้ำ" การทดลองได้
ด้วยเหตุนี้ จึงได้บันทึกทั้งซอร์สโค้ดต้นฉบับที่ใช้ และทุกขั้นตอนที่ใช้ในการทดสอบเอาไว้ทั้งหมด
โดยเนื้อหาจึงมุ่งเน้นไปที่การให้ข้อมูลเพื่อให้ผู้ทดลองทุกคนสามารถได้ผลลัพธ์เดียวกัน
จากบรรยากาศของคอมเมนต์ต่าง ๆ ที่ผมได้เห็นและรู้สึก
ต่อจากนี้ผมก็คิดเหมือนกันว่า ควรแยกการเขียนเป็นสองบทความดีไหม ระหว่าง
บทความแบบสรุป 3 บรรทัดหนึ่งบทความ กับ
บทความสำหรับคนที่ต้องการรู้รายละเอียดอีกบทความหนึ่ง
ถ้าช่วยบอกได้ว่าส่วนไหนของบทความนี้ที่รู้สึกว่าซับซ้อนเกินไป หรือยืดยาวเกินไป
ก็น่าจะช่วยผมได้มากในการเขียนบทความครั้งต่อ ๆ ไป
ผมก็รู้สึกคล้ายกันครับ
ผมเข้าใจเจตนาของผู้เขียนนะ แต่เมื่อเทียบกับสิ่งที่ทำไปแล้ว เนื้อหาดูซับซ้อนเกินความจำเป็นไปหน่อยครับ
ดูเหมือนว่าคงอยากใส่รายละเอียดที่ใช้ในการทดลองลงไปในบทความให้มากที่สุด เลยเขียนออกมาแบบนี้
แต่ผมคิดว่าถ้าคัดมาเฉพาะประเด็นสำคัญแบบสั้น ๆ คนที่สนใจหัวข้อนี้ก็น่าจะเข้าใจได้ครับ
ถ้าตัดรายละเอียดออกอย่างกล้าหาญแล้วสรุปเฉพาะแก่นหลัก น่าจะดีกว่านี้ครับ
สำหรับผม เจตนาและผลลัพธ์ของผู้เขียนถือว่าน่าสนใจครับ
ประเด็นหลักน่าจะเป็นว่า source code ที่ดีกว่าสามารถนำไปสู่การใช้โทเคนน้อยลง
และดูเหมือนว่าจะได้ออกแบบและดำเนินการทดลองที่เกี่ยวข้องกับเรื่องนั้นครับ
ถ้าจะสรุปเฉพาะส่วนที่ผมเข้าใจเกี่ยวกับการทดลอง ก็ประมาณนี้ครับ
น่าจะประมาณนี้ครับ
และถ้าสิ่งที่ผมเข้าใจถูกต้อง ข้อสรุปก็น่าจะเป็นว่า source code ที่ผ่านการ preprocess ด้วยพรอมป์ต์ โดยรวมแล้วใช้โทเคนน้อยกว่า
เป็นข้อสรุปที่น่าสนใจครับ แต่ความเห็นของผมต่อการทดลองมีดังนี้
ไม่ใช่การเปรียบเทียบที่ยุติธรรม
ในเชิงตัวเลขมันอาจดูเหมือนลดลง แต่ผมคิดว่าควรเปรียบเทียบด้วยจำนวนโทเคนรวมทั้งหมดที่ใช้ในการจัดการ source code จะถูกต้องกว่า
พูดอีกอย่างคือ ควรนับรวมจำนวนโทเคนที่ใช้ไปเพื่อการ preprocess ด้วยครับ
ถ้าจำนวนโทเคนที่ใช้ในการ preprocess สูงเกินไป จริง ๆ แล้วมันก็เท่ากับใช้โทเคนมากกว่าเดิมจนไม่มีความหมาย และถึงจะใช้น้อย ความต่างของการใช้โทเคนจริงก็น่าจะน้อยกว่าที่บทความสื่อไว้มากครับ
จำเป็นต้องเปรียบเทียบ source code ก่อนและหลัง preprocess
ถ้าไม่นับโทเคนที่ใช้ในการ preprocess ปริมาณโทเคนที่ใช้ตอน query ก็ดูเหมือนจะลดลงอย่างมีนัยสำคัญครับ
แต่ถ้าวิเคราะห์ได้ว่าความแตกต่างนี้เกิดจากความต่างส่วนไหนของ source code อย่างชัดเจน ความหมายของบทความก็น่าจะมากขึ้นครับ
เพราะนั่นหมายความว่าสามารถ optimize พรอมป์ต์สำหรับ preprocess เพื่อขยายความแตกต่างนั้นให้มากขึ้นได้
ผู้เขียนบอกว่าการ refactor โครงสร้างโค้ดเป็นสาเหตุของผลลัพธ์นี้ แต่ผมยังไม่เห็นด้วย และคิดว่ายังสรุปไม่ได้ครับ
เพราะต่อให้ไม่ใช่การ refactor แต่เป็นการปรับปรุงส่วนอื่นให้ AI ก็อาจทำให้การใช้โทเคนลดลงได้เหมือนกัน
ควรมีการทดลองที่หลากหลายกว่านี้
ผมคิดว่าควรนำการทดลองแบบเดียวกันนี้ไปลองกับ codebase อื่น ๆ ด้วย ไม่ใช่เฉพาะโค้ดชุดปัจจุบัน
เพราะต้องดูว่าผลลัพธ์ออกมาดีอย่างสม่ำเสมอหรือไม่
แต่ก็เข้าใจครับว่าในทางปฏิบัติเรื่องนี้อาจทดสอบได้ยาก ดังนั้นมองไว้เป็นเพียงข้อมูลอ้างอิงก็น่าจะเหมาะกว่า
เห็นด้วยอย่างยิ่งครับ ผมยินดีต้อนรับคำวิจารณ์ในลักษณะนี้อย่างมาก
โลกนี้ไม่ได้มีใครใช้ชีวิตอยู่เพียงลำพัง และความสามารถหรือสถานการณ์ของแต่ละคนก็แตกต่างกัน
ตัวผมเองก็เป็นเพียงนักพัฒนาคนหนึ่งเท่านั้น และไม่สามารถออกค่าใช้จ่ายส่วนตัวเพื่อทำการทดสอบทุกอย่างได้
หวังว่าบทความนี้จะเป็นเมล็ดพันธุ์ที่ส่งผลดีต่อผู้คนจำนวนมาก และเป็นจุดเริ่มต้นของงานวิจัยอีกมากมายที่ตามมา
ซับไตเติลดูจะไม่สอดคล้องกับเนื้อหานัก หากจัดระเบียบใหม่ ผมคิดว่าซับไตเติลอย่าง "จำเป็นต้องวิเคราะห์ปัจจัยที่ชัดเจนยิ่งขึ้นซึ่งทำให้โทเคนลดลง" จะเหมาะกว่า
มีหลายส่วนในเนื้อหานี้ที่ผมเห็นด้วย อย่างไรก็ตาม ลักษณะของบทความนี้มีองค์ประกอบของการ "เสนอวิธีนำไปใช้จริงให้กับผู้ที่อ่านบทความนี้" อยู่ด้วย
อันที่จริง แค่ดูคอมเมนต์ที่ติดอยู่กับบทความนี้ก็น่าจะพอมองเห็นบรรยากาศได้ และแม้จะเป็นเรื่องที่ผมเพิ่งทราบเมื่อไม่นานมานี้ แต่ก็คาดว่าท่ามกลางผู้ใช้ AI นั้นมีคนที่ไม่ใช่นักพัฒนาและเป็นสาย vibe coder อยู่มากเช่นกัน
หากผู้เขียนสร้างผลลัพธ์ที่ยอดเยี่ยมจากโค้ดที่ปรับแต่งด้วยตนเองโดยไม่ผ่าน AI
สิ่งนี้ก็อาจถูกมองได้ง่ายว่าเป็นการอวดทักษะการพัฒนาของผู้เขียน และเป็นการลดคุณค่าความสามารถของ AI
ดังนั้น จึงได้หยิบยกตัวอย่างที่ทำให้ทุกคนสัมผัสผลลัพธ์ได้จริง โดยใช้ปัจจัยอย่าง "พรอมป์ต์" ซึ่งเหล่า vibe coder ทั่วไปก็สามารถนำไปใช้ได้
หวังว่าต่อยอดจากงานศึกษานี้ จะมีงานวิจัยที่แยกย่อยปัจจัยต่าง ๆ ที่ส่งผลต่อปริมาณการใช้โทเคนของ AI ออกมาอย่างละเอียดมากขึ้นต่อไป
หากการปรับโครงสร้าง 1 ครั้งทำให้ลดอัตราการใช้โทเค็นของพรอมป์ต์จำนวน n ครั้งลงได้ ปริมาณโทเค็นที่ลดลงนั้นก็จะสะท้อนตลอดการทำงาน n ครั้งเดียวกัน
n เป็นค่าที่ถูกกำหนดโดยวัตถุประสงค์ของโปรเจกต์ จำนวนฟังก์ชัน ตลอดจนปริมาณและความซับซ้อนของโค้ดที่ต้องใช้ และ
นอกจากนี้ เมื่อไม่นานมานี้ cursor / claude code agent ก็มีการอัปเดตที่ทำให้หน่วยการทำงานเล็กลง เพื่อแก้ปัญหาการวนซ้ำไม่สิ้นสุดหรือการใช้โทเค็นอย่างไร้การควบคุมของ AI ด้วย
ผมคิดว่าการศึกษาค่า n ที่เกี่ยวข้องกับความซับซ้อนของโปรเจกต์ควรถูกแยกไปทำต่างหาก
ประเด็นที่ไม่ควรมองข้ามในส่วนนี้คือ การปรับปรุงโครงสร้างนั้นไม่ใช่สิ่งที่เกิดขึ้นโดยแยกขาดจากการพัฒนาโค้ดโดยสิ้นเชิง
มันเป็นส่วนที่สามารถส่งผลในฐานะ base context ได้ผ่านพรอมป์ต์แรกเริ่ม หรือผ่านข้อกำหนดอย่าง AI ruleset (
.cursorrules)และระหว่างวงจรการพัฒนาโปรเจกต์ การปรับปรุงโครงสร้างเพียง 1 ครั้งก็ไม่สามารถแก้ได้ทุกเรื่อง
กล่าวคือ แทนที่จะวางแผนปรับปรุงโค้ดเป็นรอบ ๆ การชี้นำให้เกิดโครงสร้างที่ถูกต้องในฐานะ base context เป็นแนวทางที่ดีกว่า
นอกจากนี้ การศึกษากรณีมีและไม่มีชุดกฎคำสั่งชี้นำโครงสร้างในฐานะ base context ก็ควรถูกแยกไปทำต่างหากเช่นกัน
สรุปในข้อ 1 คือ
ดังนั้น ข้ออ้างที่ว่าต้องนำปริมาณการใช้โทเค็นของคำสั่งพรอมป์ต์เพื่อปรับปรุงโครงสร้าง 1 ครั้งมาบวกคำนวณด้วยนั้นจึงไม่ตรงนัก.
ผมยังไม่ค่อยเข้าใจนักว่าคุณกำลังพูดถึงอะไรในคอมเมนต์นั้น ความเห็นของผมคือ ถ้าจะเปรียบเทียบสองวิธีอย่างเป็นธรรม ก็ควรต้องเปรียบเทียบจำนวนโทเค็นรวมที่ใช้ไปไม่ใช่หรือ? การรีแฟกเตอร์ก็ใช้โทเค็นเหมือนกันไม่ใช่หรือครับ?
นอกจากนี้ สิ่งที่คุณตอบมาก็ดูเหมือนไม่ได้เขียนไว้ในบทความ และก็น่าจะเป็นเนื้อหาที่ยังไม่ได้มีการทดลองจริงด้วย ดูเหมือนว่าที่คุณหมายถึงไม่ใช่การเปรียบเทียบโทเค็นต่อ 1 คำถาม แต่เป็นการบอกว่าเมื่อถามหลายครั้ง overhead ของการรีแฟกเตอร์จะลดลง และเพราะจำนวนโทเค็นที่คาดว่าจะใช้ต่อคำถามลดลง จึงจะได้ประโยชน์ในแง่จำนวนโทเค็นรวม นั่นคงจะพูดได้ก็ต่อเมื่อในกรณีที่ถามหลายครั้ง การลดต้นทุนยังคงอยู่ตามที่ผู้เขียนคาดไว้ ซึ่งดูเป็นการตั้งอยู่บนสมมติฐานที่ค่อนข้างอุดมคติมาก การรับประกันไม่ได้เลยว่าการลดต้นทุนจากการรีแฟกเตอร์จะคงอยู่ต่อไปโดยไม่ขึ้นกับจำนวนคำถามถัดไป และก็ไม่ควรสมมติเอาเองโดยไม่มีการทดลอง ถ้าจะยืนยันประเด็นที่ตั้งใจจะสื่อ ก็น่าจะแสดงผลการทดลองเรื่องการลดต้นทุนในกรณีที่มีมากกว่า 1 คำถามให้เห็นได้ แต่การทดลองนี้ไม่ได้ทำเพียง 1 ครั้งแล้วนำมาเปรียบเทียบเท่านั้นหรือครับ?
ขอเสริมอีกนิดว่านี่เป็นเพียงสมมติฐานของผมเอง แต่ถ้าตั้งคำถามซ้ำไปเรื่อย ๆ อย่างไม่จำกัดเพื่อให้ได้เป้าหมายเดียวกัน (ผลลัพธ์สุดท้ายในอุดมคติ) ในสถานการณ์อุดมคติ ไม่ว่าจะมีการรีแฟกเตอร์หรือไม่ โค้ดก็น่าจะค่อย ๆ ลู่เข้าสู่รูปแบบเดียวกันอยู่ดี (โดยที่ผลลัพธ์สุดท้ายในอุดมคติมีเพียงแบบเดียว)
ถ้าสมมติฐานนี้สมเหตุสมผล ก็แปลว่าเมื่อมีการถามซ้ำมากขึ้น ความแตกต่างระหว่างกรณีมีและไม่มีการรีแฟกเตอร์จะยิ่งลดลง ดังนั้นประโยชน์จากการลดต้นทุนด้านโทเค็นก็น่าจะค่อย ๆ ลดลงด้วย เพราะฉะนั้น ถ้ามองในภาพใหญ่ หากประโยชน์จากการลดต้นทุนนี้ไม่ได้คงอยู่ได้นานเพียงพอ ความแตกต่างของจำนวนโทเค็นรวมที่ใช้กับแต่ละคำถามอาจไม่ได้มีนัยสำคัญก็เป็นได้ไม่ใช่หรือครับ
และคุณยังถามถึงประเด็นที่เกี่ยวกับการทดลองจำนวนครั้งของการเชื่อมต่อพรอมป์ต์ด้วย
ที่จริงแล้ว ในทางกลับกัน นี่เป็นองค์ประกอบที่เปิดช่องให้ผู้เขียนสามารถโกงกันแบบบ้าน ๆ ได้ง่าย
ตัวการพัฒนาเองนั้นมีทางเลือกของทิศทางการดำเนินงานอยู่มากมายอย่างยิ่ง และถ้าสะสมพรอมป์ต์ไปในทิศทางที่ทำให้ปริมาณการใช้โทเคนยิ่งห่างมากขึ้น ตัวเลขนั้นก็จะพองโตขึ้นเรื่อย ๆ ราวกับก้อนหิมะ
ในงานวิจัยมีปรัชญาที่เรียกว่า 'Cumulative Science'
อย่างน้อยตามเกณฑ์ของผม ผมยังไม่เคยพบงานวิจัยเกี่ยวกับปริมาณการใช้โทเคนต่อคำสั่ง 1 ครั้งเลยแม้แต่ครั้งเดียว
ดังนั้น แทนที่จะไปทำการวิจัย N ครั้งในทันที ผมจึงมุ่งเน้นไปที่การทดสอบและข้อสรุปเกี่ยวกับ 1 ครั้งที่ชัดเจนก่อน
ส่วนการวิจัยแบบ N ครั้งก็ให้เป็นงานวิจัยต่อเนื่องจากการทดลองนี้ในภายหลังได้
นอกจากนี้ ผมเคยเขียนอีกบทความหนึ่งว่าด้วยความแตกต่างของพฤติกรรม AI ตามความแตกต่างของ codebase ด้วย
(บทความนี้ก็เคยถูกแนะนำใน GeekNews เช่นกัน: https://modgo.org/aineun-hyeonjae-kodeu-gujoyi-byeoge-maghyeoissda/)
อธิบายสั้น ๆ คือ เป็นการทดสอบและผลลัพธ์ที่แสดงให้เห็นว่าคุณภาพของผลลัพธ์เปลี่ยนไปตาม codebase ที่ป้อนให้ AI
นั่นหมายความว่า ตามคุณภาพและทิศทางของ codebase ตั้งต้น คุณภาพของโค้ดที่ตามมาอาจคงระดับไว้ได้ หรืออาจแย่ลงต่อเนื่องก็ได้
กล่าวคือ ต้นทุนการ refactoring ในช่วงเริ่มต้นโปรเจ็กต์ กับต้นทุนการ refactoring ของโปรเจ็กต์ที่ดำเนินไปไกลแล้ว อาจแตกต่างกันมาก
ถ้าผู้ถามเป็นนักพัฒนา ก็น่าจะเคยได้ยินคำว่า 'เรือบรรทุกเครื่องบินบนเรือใบ' มาสักครั้ง
การ refactoring ควรทำเมื่อไร หรือค่าใช้จ่ายจะต่างกันมหาศาลเพียงใดตามแนวคิดและการออกแบบที่ถูกวางไว้ตั้งแต่ต้นโปรเจ็กต์ ล้วนเป็นประเด็นที่ลึกซึ้ง
แทนที่จะใส่สิ่งนี้เป็นตัวแปรจนทำให้ข้อสรุปไม่นิ่ง
จึงได้ทำการทดสอบที่สามารถอธิบายได้อย่างชัดเจนอย่างน้อยในประเด็นว่า 'ถ้า codebase มีคุณภาพดี การใช้โทเค็นก็จะลดลง'
ขออธิบายอีกครั้งครับ
ผู้ที่ทำ vibe coding มีตั้งแต่คนที่ไม่ใช่นักพัฒนาไปจนถึงนักพัฒนาที่มีประสบการณ์สูง ขึ้นอยู่กับระดับความรู้ที่พวกเขามี คุณภาพของผลลัพธ์อาจแตกต่างกันอย่างมากโดยไม่เกี่ยวกับเนื้อหาของบทความนี้เลย
บางคนอาจใช้งานได้อย่างเป็นธรรมชาติภายใต้สมมติฐานว่าต้องใช้ cursor โดยกำหนดกติกา OOP พื้นฐานและกฎการแยกคลาส/เมธอดไว้ใน
.cursorrulesจนสามารถทำงานในรูปแบบที่แทบไม่ต้องรีแฟกเตอร์เลยก็ได้ แต่สำหรับบางคน อาจกำลังสร้างโค้ดระดับต่ำจำนวนมากเพราะขาดความเข้าใจแม้แต่ประเด็นสำคัญพื้นฐานอย่างมาก
ยิ่งไปกว่านั้น ก่อนหน้านี้ก็มีบทความและประสบการณ์มากมายที่บอกโดยพื้นฐานว่า ควรรักษาคุณภาพโค้ดให้ดีผ่านการตั้งกฎของโปรเจ็กต์
สิ่งนี้ชี้ให้เห็นถึงความเป็นไปได้ว่า บางคนอาจได้รับประโยชน์ในแง่การใช้โทเค็นอยู่แล้ว แม้ไม่มีการรีแฟกเตอร์อย่างชัดเจน
อย่างไรก็ตาม กรณีข้างต้นไม่ได้สรุปอย่างเป็นระบบว่าการกำหนดกฎเหล่านั้นช่วยลดการใช้โทเค็นต่อหนึ่งรอบการทำงานได้ชัดเจนเพียงใด ดังนั้นบทความนี้จึงทดสอบความแตกต่างของการใช้โทเค็นตามคุณภาพของ codebase และสรุปผลลัพธ์ไว้
กล่าวคือ สำหรับผู้ใช้แต่ละคน จำนวนครั้งของการรีแฟกเตอร์แบบชัดเจนก็อาจกลายเป็นตัวแปรตั้งแต่ 0 ถึง n ได้อีกครั้ง และ
หากมองในเจตนาหลัก บทความนี้น่าจะกำลังอธิบายว่า ‘ทำไมการใส่ใจกับ codebase ที่มีคุณภาพดีจึงเป็นเรื่องที่ดี?’
ผู้เขียนเองครับ ขอบคุณสำหรับคำติชม จะนำไปอ้างอิงในการเขียนบทความครั้งถัดไปครับ
หมายความว่าเมื่อใส่พรอมป์ต์นี้เข้าไปด้วยแล้ว ต้นทุนก็ลดลงอย่างนั้นหรือครับ? ผมยังไม่แน่ใจว่าตัวเองเข้าใจประเด็นสำคัญถูกหรือเปล่า
ขอเสริมว่า โครงสร้างของโค้ดควรได้รับการปรับปรุงให้เป็นรูปแบบที่เหมาะกับโปรเจกต์นั้น ๆ ตามเนื้อหาในคำตอบด้านล่าง หากคุณถาม AI เกี่ยวกับการปรับโครงสร้าง มันจะบอกวิธีปรับโครงสร้างที่เหมาะสมกับโปรเจกต์นั้นให้ได้
วิธีที่ผมแนะนำเป็นการส่วนตัวคือ อย่าเพิ่งสั่งให้ AI ปรับโครงสร้างทันที แต่ให้มันเสนอแนวทางก่อน มันจะให้คำตอบกลับมา แล้วคุณค่อยคุยต่อจนได้ข้อเสนอที่มีประสิทธิภาพเพียงพอ จากนั้นค่อยให้มันนำไปใช้จริง
อีกหนึ่งเคล็ดลับเพิ่มเติมคือ ควรพยายามทำงานให้เสร็จก่อนที่จะเกิด context summarization (การรีเซ็ตบัฟเฟอร์บริบท) และหากเลี่ยงการรีเซ็ตบัฟเฟอร์บริบทไม่ได้ ก็ควรให้เพิ่มกฎการปรับปรุงไว้ล่วงหน้าใน
.cursorrulesระหว่างทำงาน หากมีการรีเซ็ตบริบทเกิดขึ้น AI จะมีโอกาสทำผิดพลาดได้สูงขึ้นเป็นที่ทราบกันดีอยู่แล้วอย่างชัดเจนว่า ยิ่งขนาดซอร์สที่ป้อนเข้ามาเล็กลง ปริมาณโทเคนที่ใช้ก็จะยิ่งลดลง นั่นจึงเป็นเหตุผลที่มีไฟล์
.cursorignoreขึ้นมาโดยทั่วไปแล้ว เมื่อให้ AI ปรับปรุงโครงสร้าง ก็มักมีแนวโน้มที่ปริมาณซอร์สโค้ดจะลดลงในแทบทุกกรณี ดังนั้นคำกล่าวที่ว่าไม่ว่าจะจัดระเบียบด้วยเหตุผลใด ต้นทุนก็จะลดลง จึงดูเป็นข้ออ้างที่น่าเชื่อถือ
บทความนี้คือการเพิ่มเติมข้ออ้างว่า หากชี้นำให้ได้โครงสร้างที่ดี ก็สามารถทำให้การใช้โทเคนลดลงได้เพิ่มเติมอีก
ถูกต้องครับ อย่างที่กล่าวไว้ในเนื้อหาหลัก หลังจากปรับปรุงโค้ดแล้ว ขนาดโค้ดของโปรเจ็กต์ลดลงจริง
อย่างไรก็ตาม ในตัวอย่างนี้มีการลดลงประมาณ 10% หากวัดตามจำนวนตัวอักษร ซึ่งเพียงเท่านี้ยังไม่สามารถอธิบายการลดลงของการใช้โทเค็น 37.91% ได้
ในเนื้อหาหลักมีลิงก์ไปยังซอร์สรีโพซิทอรี และใครก็ตามสามารถทำซ้ำเพื่อทดสอบได้
ผมยังไม่ได้ลองทดสอบแบบนี้ด้วยตัวเอง แต่
พรอมป์ต์ว่า 'วิเคราะห์โค้ดปัจจุบัน แล้วปรับโครงสร้างให้เป็นรูปแบบที่คุณจัดการได้ง่าย'
ก็น่าจะใช้ได้เหมือนกันนะครับ
ประเด็นสำคัญที่ชัดเจนคือ ดูเหมือนว่าการสื่อสารกับ AI ไม่ใช่แค่การส่งต่อข้อกำหนดด้านฟังก์ชันเท่านั้น แต่การชี้นำให้ได้โครงสร้างที่เหมาะสมและถูกต้องก็อาจช่วยลดต้นทุนได้เช่นกัน
https://modgo.org/dib-rag-gaelreogtig-modeu-seuteurimeoreul-wihan-ciji…
โหมด DeepRAGGal นี้คุณทำขึ้นมาเองโดยตรงหรือเปล่าครับ?
อันนี้ก็ทำด้วย vibe coding เหมือนกันหรือเปล่าครับ?
สวัสดีครับ ผมเป็นเจ้าของบล็อก
ใช่ครับ ผมเป็นคนสร้างโหมด DeepRAGGal เอง และตอนนี้กำลังเปิดให้บริการผ่านเซิร์ฟเวอร์ส่วนตัวอยู่ (จำเป็นเพราะการยืนยันตัวตนด้วย Chzzk OAuth)
โหมดนี้มีส่วนที่ต้องพัฒนาด้วย Unreal Engine ด้วย ซึ่งน่าเสียดายที่ฝั่ง Unreal Engine ทำ vibe coding ได้ยาก
แต่ตัววิธีการพัฒนาโหมดเองไม่ได้ยากนัก ดังนั้นถ้าสนใจ ก็สามารถเรียนรู้ได้ง่ายผ่านคู่มือพัฒนาโหมด (https://modgo.org/dib-rag-gaelreogtig-modeu-gaebal-part-1/)
ฉันเห็นคุณโพสต์โหมดนั้นในคอมมูนิตี้อื่นอยู่เหมือนกัน ที่แท้ก็เป็นบทความที่คนทำโหมดนั้นเขียนเองจริง ๆ สินะ
ไม่คิดเลยว่าคุณจะเขียนบทความสอนโหมดบลูพรินต์ด้วย ขอบคุณครับ
เดิมทีก็เป็นคนที่พัฒนาเก่งอยู่แล้วนี่ครับ!
อ๋อ ที่แท้คุณเคยเห็นโหมดของผมจากคอมมูนิตี้อื่นมาบ้างแล้วสินะ
โพสต์ที่ผมเขียนอาจยังมีส่วนที่ไม่สมบูรณ์อยู่มาก แต่ถ้าพอจะช่วยได้ก็คงยินดีมากครับ
น่าหงุดหงิดชะมัด
หากคุณบอกได้ว่าส่วนไหนที่ทำให้คุณรู้สึกรำคาญ ฉันจะตอบกลับอย่างเป็นมิตรให้ครับ
โปรดตรวจสอบหัวข้อการแสดงความคิดเห็นในวิธีใช้งานเว็บไซต์
กรุณาพูดคุยด้วยความสุภาพและนอบน้อม
หากมีข้อโต้แย้ง กรุณาเขียนเฉพาะเนื้อหานั้น