บทความนี้มีลักษณะใกล้เคียงกับงานวิจัยเชิง "การทดลอง"

ดังนั้น ตัวเลขทั้งหมดที่อยู่ในบทความนี้จึงมุ่งเน้นให้ผู้อ่านทุกคนสามารถ "ทำซ้ำ" การทดลองได้

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

โดยเนื้อหาจึงมุ่งเน้นไปที่การให้ข้อมูลเพื่อให้ผู้ทดลองทุกคนสามารถได้ผลลัพธ์เดียวกัน

จากบรรยากาศของคอมเมนต์ต่าง ๆ ที่ผมได้เห็นและรู้สึก

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

ถ้าช่วยบอกได้ว่าส่วนไหนของบทความนี้ที่รู้สึกว่าซับซ้อนเกินไป หรือยืดยาวเกินไป
ก็น่าจะช่วยผมได้มากในการเขียนบทความครั้งต่อ ๆ ไป

3. จำเป็นต้องมีการทดลองที่หลากหลายมากขึ้น

เห็นด้วยอย่างยิ่งครับ ผมยินดีต้อนรับคำวิจารณ์ในลักษณะนี้อย่างมาก

โลกนี้ไม่ได้มีใครใช้ชีวิตอยู่เพียงลำพัง และความสามารถหรือสถานการณ์ของแต่ละคนก็แตกต่างกัน

ตัวผมเองก็เป็นเพียงนักพัฒนาคนหนึ่งเท่านั้น และไม่สามารถออกค่าใช้จ่ายส่วนตัวเพื่อทำการทดสอบทุกอย่างได้

หวังว่าบทความนี้จะเป็นเมล็ดพันธุ์ที่ส่งผลดีต่อผู้คนจำนวนมาก และเป็นจุดเริ่มต้นของงานวิจัยอีกมากมายที่ตามมา

2. มีความจำเป็นต้องเปรียบเทียบซอร์สโค้ดก่อนและหลังการพรีโปรเซส

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

มีหลายส่วนในเนื้อหานี้ที่ผมเห็นด้วย อย่างไรก็ตาม ลักษณะของบทความนี้มีองค์ประกอบของการ "เสนอวิธีนำไปใช้จริงให้กับผู้ที่อ่านบทความนี้" อยู่ด้วย

อันที่จริง แค่ดูคอมเมนต์ที่ติดอยู่กับบทความนี้ก็น่าจะพอมองเห็นบรรยากาศได้ และแม้จะเป็นเรื่องที่ผมเพิ่งทราบเมื่อไม่นานมานี้ แต่ก็คาดว่าท่ามกลางผู้ใช้ AI นั้นมีคนที่ไม่ใช่นักพัฒนาและเป็นสาย vibe coder อยู่มากเช่นกัน

หากผู้เขียนสร้างผลลัพธ์ที่ยอดเยี่ยมจากโค้ดที่ปรับแต่งด้วยตนเองโดยไม่ผ่าน AI

สิ่งนี้ก็อาจถูกมองได้ง่ายว่าเป็นการอวดทักษะการพัฒนาของผู้เขียน และเป็นการลดคุณค่าความสามารถของ AI

ดังนั้น จึงได้หยิบยกตัวอย่างที่ทำให้ทุกคนสัมผัสผลลัพธ์ได้จริง โดยใช้ปัจจัยอย่าง "พรอมป์ต์" ซึ่งเหล่า vibe coder ทั่วไปก็สามารถนำไปใช้ได้

หวังว่าต่อยอดจากงานศึกษานี้ จะมีงานวิจัยที่แยกย่อยปัจจัยต่าง ๆ ที่ส่งผลต่อปริมาณการใช้โทเคนของ AI ออกมาอย่างละเอียดมากขึ้นต่อไป

1. เกี่ยวกับการเปรียบเทียบอย่างเป็นธรรม

• Vibe coding ไม่ได้ทำให้งานเสร็จสมบูรณ์จากพรอมป์ต์เพียงครั้งเดียว
  หากการปรับโครงสร้าง 1 ครั้งทำให้ลดอัตราการใช้โทเค็นของพรอมป์ต์จำนวน n ครั้งลงได้ ปริมาณโทเค็นที่ลดลงนั้นก็จะสะท้อนตลอดการทำงาน n ครั้งเดียวกัน
  n เป็นค่าที่ถูกกำหนดโดยวัตถุประสงค์ของโปรเจกต์ จำนวนฟังก์ชัน ตลอดจนปริมาณและความซับซ้อนของโค้ดที่ต้องใช้ และ
  นอกจากนี้ เมื่อไม่นานมานี้ cursor / claude code agent ก็มีการอัปเดตที่ทำให้หน่วยการทำงานเล็กลง เพื่อแก้ปัญหาการวนซ้ำไม่สิ้นสุดหรือการใช้โทเค็นอย่างไร้การควบคุมของ AI ด้วย

ผมคิดว่าการศึกษาค่า n ที่เกี่ยวข้องกับความซับซ้อนของโปรเจกต์ควรถูกแยกไปทำต่างหาก

• เพื่อช่วยให้เข้าใจได้มากที่สุด ผมจึงยกตัวอย่างการปรับปรุงโค้ดจากโค้ดที่ AI เขียนขึ้นซึ่งมีปัญหาเชิงโครงสร้าง ในกรณีที่ไม่มีคำสั่งเพิ่มเติมเป็นพิเศษ
  ประเด็นที่ไม่ควรมองข้ามในส่วนนี้คือ การปรับปรุงโครงสร้างนั้นไม่ใช่สิ่งที่เกิดขึ้นโดยแยกขาดจากการพัฒนาโค้ดโดยสิ้นเชิง
  มันเป็นส่วนที่สามารถส่งผลในฐานะ base context ได้ผ่านพรอมป์ต์แรกเริ่ม หรือผ่านข้อกำหนดอย่าง AI ruleset (.cursorrules)
  และระหว่างวงจรการพัฒนาโปรเจกต์ การปรับปรุงโครงสร้างเพียง 1 ครั้งก็ไม่สามารถแก้ได้ทุกเรื่อง
  กล่าวคือ แทนที่จะวางแผนปรับปรุงโค้ดเป็นรอบ ๆ การชี้นำให้เกิดโครงสร้างที่ถูกต้องในฐานะ base context เป็นแนวทางที่ดีกว่า

นอกจากนี้ การศึกษากรณีมีและไม่มีชุดกฎคำสั่งชี้นำโครงสร้างในฐานะ base context ก็ควรถูกแยกไปทำต่างหากเช่นกัน

สรุปในข้อ 1 คือ

• อาจมีความเป็นไปได้ว่าการมีชุดกฎคำสั่งชี้นำโครงสร้างในฐานะ base context จะช่วยลดการใช้โทเค็นโดยรวมได้ และ
• เนื่องจากมีตัวแปรเรื่องการได้มาซึ่งผลลัพธ์สุดท้ายผ่านคำสั่งพรอมป์ต์จำนวน n ครั้ง
  ดังนั้น ข้ออ้างที่ว่าต้องนำปริมาณการใช้โทเค็นของคำสั่งพรอมป์ต์เพื่อปรับปรุงโครงสร้าง 1 ครั้งมาบวกคำนวณด้วยนั้นจึงไม่ตรงนัก.

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

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

ถ้าจะสรุปเฉพาะส่วนที่ผมเข้าใจเกี่ยวกับการทดลอง ก็ประมาณนี้ครับ

1. เตรียม source code 2 ชุด คือ source code ที่จะใช้ถาม AI และ source code ที่ผ่านการ preprocess ด้วยพรอมป์ต์(?) แล้ว
2. รัน source code ทั้งสองชุดกับ GPT5 และ Sonnet อย่างละ 5 ครั้ง แล้วเปรียบเทียบปริมาณการใช้โทเคน
   น่าจะประมาณนี้ครับ
   และถ้าสิ่งที่ผมเข้าใจถูกต้อง ข้อสรุปก็น่าจะเป็นว่า source code ที่ผ่านการ preprocess ด้วยพรอมป์ต์ โดยรวมแล้วใช้โทเคนน้อยกว่า

เป็นข้อสรุปที่น่าสนใจครับ แต่ความเห็นของผมต่อการทดลองมีดังนี้

1. ไม่ใช่การเปรียบเทียบที่ยุติธรรม
   ในเชิงตัวเลขมันอาจดูเหมือนลดลง แต่ผมคิดว่าควรเปรียบเทียบด้วยจำนวนโทเคนรวมทั้งหมดที่ใช้ในการจัดการ source code จะถูกต้องกว่า
   พูดอีกอย่างคือ ควรนับรวมจำนวนโทเคนที่ใช้ไปเพื่อการ preprocess ด้วยครับ
   ถ้าจำนวนโทเคนที่ใช้ในการ preprocess สูงเกินไป จริง ๆ แล้วมันก็เท่ากับใช้โทเคนมากกว่าเดิมจนไม่มีความหมาย และถึงจะใช้น้อย ความต่างของการใช้โทเคนจริงก็น่าจะน้อยกว่าที่บทความสื่อไว้มากครับ

2. จำเป็นต้องเปรียบเทียบ source code ก่อนและหลัง preprocess
   ถ้าไม่นับโทเคนที่ใช้ในการ preprocess ปริมาณโทเคนที่ใช้ตอน query ก็ดูเหมือนจะลดลงอย่างมีนัยสำคัญครับ
   แต่ถ้าวิเคราะห์ได้ว่าความแตกต่างนี้เกิดจากความต่างส่วนไหนของ source code อย่างชัดเจน ความหมายของบทความก็น่าจะมากขึ้นครับ
   เพราะนั่นหมายความว่าสามารถ optimize พรอมป์ต์สำหรับ preprocess เพื่อขยายความแตกต่างนั้นให้มากขึ้นได้
   ผู้เขียนบอกว่าการ refactor โครงสร้างโค้ดเป็นสาเหตุของผลลัพธ์นี้ แต่ผมยังไม่เห็นด้วย และคิดว่ายังสรุปไม่ได้ครับ
   เพราะต่อให้ไม่ใช่การ refactor แต่เป็นการปรับปรุงส่วนอื่นให้ AI ก็อาจทำให้การใช้โทเคนลดลงได้เหมือนกัน

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

ของขวัญไร้ประโยชน์กำลังเป็นที่นิยมอยู่เหมือนกัน.. น่าจะเหมาะดีสำหรับค้นหาของขวัญไร้ประโยชน์ชิ้นใหม่ๆ

ขอสรุปเพิ่มเติมเกี่ยวกับพรอมป์ต์ที่ใช้เพิ่มเข้ามาไว้ดังนี้

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

แต่ก็ไม่ได้หมายความว่าสาย vibe coder ที่ไม่ใช่นักพัฒนาจะใช้วิธีนี้ไม่ได้ แม้ประสิทธิภาพอาจแตกต่างกันอยู่บ้าง แต่เพียงใช้คำสั่งง่าย ๆ อย่าง "ช่วยจัดระเบียบโค้ดโปรเจกต์ให้หน่อย ลบโค้ดที่ไม่ได้ใช้ออก" AI ก็สามารถแยกไฟล์และคลาสรวมถึงจัดระเบียบให้ได้

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

ถ้าคุณต้องใช้งานข้อมูลเชิงพื้นที่ นี่ก็เป็นตัวเลือกที่ดีครับ

ขอบคุณทุกท่านที่ให้ความสนใจกับบทความนี้เป็นอย่างมาก เนื่องจากมีเป้าหมายหลักเพื่อเผยแพร่ในต่างประเทศ จึงเขียนบทความเป็นภาษาอังกฤษ และดูเหมือนว่าสิ่งนี้จะทำให้เกิดปัญหาหลายอย่าง

ด้วยเหตุนี้ จึงขอแชร์โพสต์ที่สรุปเป็นภาษาเกาหลีไว้

https://modgo.org/tokeun-sayongryang-37-91-reul-gamsosikin-dan-hanjuly…

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

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

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

ซ้อนเกินจำเป็น

ผู้เขียนเองครับ ขอบคุณสำหรับคำติชม จะนำไปอ้างอิงในการเขียนบทความครั้งถัดไปครับ

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

จู่ๆ จุดทั้งหมดก็หายไป

บทสรุป
การใช้ AI ช่วยเพิ่มผลิตภาพได้
และช่วยลดต้นทุนได้
แต่ตัวมันเองไม่ได้สร้างรายได้โดยตรง

อะไรอย่าง nodejs เวลาจะ bind เข้ากับแอปพลิเคชันอื่นค่อนข้างยุ่งยากพอสมควร ถ้าง่ายกว่านี้หน่อยก็คงดีนะครับ

ตัว Web Codecs API เองก็มีประสิทธิภาพดีอยู่แล้ว เลยทำให้ไลบรารีสื่อบนเว็บแทบทั้งหมดมีประสิทธิภาพยอดเยี่ยมกันหมด จะมองว่าเป็น pure ts ก็ดูจะก้ำกึ่งอยู่นิดหน่อย

ดูจากเบนช์มาร์กแล้ว น่าแปลกที่ประสิทธิภาพไม่ได้แย่เลย

ว้าว ตอนนี้แม้แต่ Delphi กับ C++Builder ก็มีคอมโพเนนต์สำหรับพัฒนา AI เข้ามาแล้วสินะ
Delphi ให้ความรู้สึกเหมือนบ้านเกิดทางใจอะไรสักอย่าง พอมีข่าวใหม่ออกมาทีไรก็ต้องกดเข้ามาดูทุกครั้งเลย