ใช่ครับ ผมก็คิดเหมือนกัน T_T

อ่านการทดลองได้สนุกมากครับ

ไปเรียนสถาบันตั้งพาดหัวมาหรือไง..

ในแง่ที่ว่าโซเชียลมีเดียเป็นการเสียเวลา ความรู้สึกแบบ 'เสียดาย' หรือ 'อับอาย' ก็อาจจะตรงกว่า เหมือนกับการพนันหรือยาเสพติด

น่าสนใจดีนะ ฟังดูมีเหตุผลเหมือนกัน

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

k9s - เครื่องมือสำหรับจัดการ Kubernetes cluster ผ่าน Terminal UI

ลิงก์แนะนำรายละเอียด SDD ตรงกลางบทความนี่เนื้อหาดีมากครับ ด้านล่างนี้คือสิ่งที่ลองสรุปด้วย AI มาให้ครับ

การพัฒนาแบบขับเคลื่อนด้วยสเปก (Specification-Driven Development, SDD)

The Power Inversion

• เป็นการกลับด้านจากแนวทางที่มีโค้ดเป็นศูนย์กลางและให้ PRD·เอกสารออกแบบเป็นตัวเสริม โดยให้ สเปกเป็นต้นฉบับ และโค้ดเป็น ผลลัพธ์ที่แสดงออก ซึ่งถูกนำไปพัฒนาบนภาษา·เฟรมเวิร์กเฉพาะ
  • เสนอการวินิจฉัยว่าช่องว่าง ถาวรระหว่างสเปกกับการพัฒนา นั้นยากจะปิดได้ด้วยการเพิ่มเอกสารหรือเพิ่มกระบวนการ
  • หาก สเปกที่รันได้ และ แผนการพัฒนา เป็นตัวสร้างโค้ด ช่องว่างนั้นก็จะหายไปและจะเหลือเพียง การแปลง เท่านั้น
• AI ทำให้การตีความสเปกที่ซับซ้อนและการวางแผนการพัฒนาเป็นไปได้ แต่ การสร้างแบบไร้โครงสร้างจะก่อให้เกิดความสับสน ดังนั้น SDD จึงใช้ โครงสร้างที่แม่นยำและราวกันตก เพื่อคุมคุณภาพ
• การบำรุงรักษาคือการทำให้สเปกวิวัฒน์ต่อไป โดยเจตนาของการพัฒนาถูกแสดงผ่าน ภาษาธรรมชาติ·ทรัพย์สินด้านดีไซน์·หลักการแกนกลาง และโค้ดอยู่ในตำแหน่งของ ไมล์สุดท้าย
• การดีบักให้ความสำคัญกับ การแก้สเปก·แผนการพัฒนา ก่อนการแก้โค้ดที่ผิด และรีแฟกเตอร์ถูกนิยามใหม่ให้หมายถึง การจัดโครงสร้างความชัดเจนขึ้นใหม่

The SDD Workflow in Practice

• กลั่นไอเดียให้เป็น PRD ผ่าน การโต้ตอบแบบสนทนากับ AI และ AI จะช่วยทำให้ คำถาม·เคสขอบเขต·เกณฑ์การยอมรับ ชัดเจนขึ้น
  • เปลี่ยนความต้องการและการออกแบบให้เป็น กิจกรรมต่อเนื่อง รองรับ การทำงานกับสเปกบนพื้นฐาน branch ระดับทีม พร้อมการรีวิวและการจัดเวอร์ชัน
• รีเสิร์ชเอเจนต์ จะสำรวจความเข้ากันได้ของไลบรารี ประสิทธิภาพ ความปลอดภัย และ ข้อจำกัดขององค์กร (มาตรฐาน DB·การยืนยันตัวตน·นโยบายการ deploy) แล้วสะท้อนเข้าไปในสเปกโดยอัตโนมัติ
• สร้าง แผนการพัฒนา จาก PRD เพื่อแมปความต้องการกับการตัดสินใจทางเทคนิคแบบ ตรวจสอบย้อนกลับได้ และให้ AI คอยตรวจสอบ ความขัดแย้ง·ความกำกวม·สิ่งที่ตกหล่น อย่างต่อเนื่อง
• เมื่อสเปกและแผนมีความเสถียรมากพอจึงเริ่ม สร้างโค้ด โดยในช่วงแรกจะใช้ การสร้างเชิงสำรวจ เพื่อตรวจสอบความเป็นไปได้
  • แนวคิดของโดเมนจะถูกแปลงเป็น โมเดลข้อมูล ยูสเซอร์สตอรีเป็น API endpoint และสถานการณ์การยอมรับเป็น เทสต์
• เมตริก·อินซิเดนต์ จากช่วงปฏิบัติการจะอัปเดตสเปกเพื่อสะท้อนในการสร้างรอบถัดไป โดยคอขวดด้านประสิทธิภาพจะถูกยกระดับเป็น ข้อกำหนดที่ไม่ใช่เชิงฟังก์ชัน และช่องโหว่จะถูกยกระดับเป็น ข้อจำกัดส่วนกลาง

Why SDD Matters Now

• จุดเปลี่ยนด้านความสามารถของ AI: ตอนนี้สามารถสร้าง โค้ดที่ทำงานได้ จากสเปกภาษาธรรมชาติอย่างน่าเชื่อถือ และการทำส่วนที่เป็น งานเชิงกลของการแปลไปสู่การพัฒนา ให้เป็นอัตโนมัติ ช่วยหนุน การสำรวจ·การเพิ่มพลังความคิดสร้างสรรค์
• ความซับซ้อนที่พุ่งสูง: เมื่อมีบริการ เฟรมเวิร์ก และ dependency จำนวนมาก การรักษา ความสอดคล้องระหว่างเจตนากับการพัฒนา จึงยากขึ้น ทำให้ต้องมี การจัดแนวแบบขับเคลื่อนด้วยสเปก ของ SDD
• การเปลี่ยนแปลงที่เร็วขึ้น: ในสถานการณ์ที่ pivot บ่อย SDD จัดการการเปลี่ยนแปลงด้วย การสร้างใหม่อย่างเป็นระบบ แทน การไล่แก้เอกสาร-ดีไซน์-โค้ดด้วยมือ
  • ตัวอย่างเช่น ทำให้ what-if simulation และการพัฒนาแบบขนานทำได้ จึงเพิ่ม ความคล่องตัวในการตัดสินใจ

Core Principles

• สเปก=ภาษากลางร่วมกัน: สเปกคือผลลัพธ์ระดับชั้นหนึ่ง โค้ดคือ การแสดงออก ของสแตกเฉพาะ และการบำรุงรักษาคือการ ทำให้สเปกวิวัฒน์
• สเปกที่รันได้: ใช้สเปกที่มีระดับ ถูกต้อง·ครบถ้วน·ไม่กำกวม เพื่อสร้าง ระบบที่ทำงานได้
• การขัดเกลาอย่างต่อเนื่อง: ไม่ใช่เกตแบบครั้งเดียวจบ แต่เป็น การตรวจสอบความสอดคล้องตลอดเวลา
• บริบทจากการวิจัย: รวบรวม ข้อมูลด้านประสิทธิภาพ ความปลอดภัย และข้อจำกัดขององค์กรอย่าง ต่อเนื่อง แล้วฉีดกลับเข้าไปในสเปก
• ฟีดแบ็กสองทาง: ความเป็นจริงในการปฏิบัติการจะกลายเป็น อินพุตสำหรับอัปเดตสเปก
• การแตก branch เพื่อการสำรวจ: รองรับการสร้าง หลายแนวทางการพัฒนา จากสเปกเดียวกันตามเป้าหมายการปรับให้เหมาะสม เช่น ประสิทธิภาพ·การบำรุงรักษา·UX·ต้นทุน

Implementation Approaches

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

Streamlining SDD with Commands

• /specify: แปลงคำอธิบายฟีเจอร์ให้เป็น สเปก แบบมีโครงสร้าง และทำ การใส่หมายเลขอัตโนมัติ, การสร้าง branch, การจัดโครง ไดเรกทอรีตามเทมเพลต โดยอัตโนมัติ
• /plan: วิเคราะห์สเปก → ตรวจ การปฏิบัติตามรัฐธรรมนูญ → แปลเป็นเทคนิค → จัดทำเอกสาร โมเดลข้อมูล·สัญญา API·สถานการณ์การทดสอบ → สร้าง การตรวจสอบ quickstart
• /tasks: อ่าน plan.md และดีไซน์ที่เกี่ยวข้องเพื่อสร้าง รายการงานที่นำไปปฏิบัติได้ พร้อม การระบุงานที่ทำขนานกันได้ และการจัดกลุ่มขนานที่ปลอดภัย
• ตัวอย่าง: ฟีเจอร์แชต
  • ยกตัวอย่างโฟลว์ที่ลดงานทำเอกสารราว ~12 ชั่วโมงของแนวทางดั้งเดิม ให้เหลือการจัดองค์ประกอบประมาณ 15 นาที ด้วยการทำ สเปก·แผน·งาน แบบอัตโนมัติ
  • ผลลัพธ์ประกอบด้วย สเปก, แผนการพัฒนาและเหตุผล, สัญญา API·โมเดลข้อมูล, สถานการณ์ quickstart, tasks.md ที่ถูก จัดการเวอร์ชันไว้ใน branch

The Power of Structured Automation

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

Template-Driven Quality

• ป้องกันการแทรกเข้ามาเร็วเกินไปของรายละเอียดการพัฒนา: รักษาระดับนามธรรมด้วยกฎที่เน้น WHAT/WHY และตัด HOW ออก
• บังคับการทำเครื่องหมายความไม่แน่นอน: ใช้ marker [NEEDS CLARIFICATION] เพื่อ ห้ามการเดา และกระตุ้นให้ ตั้งคำถามอย่างชัดเจน
• การตรวจทานตนเองด้วยเช็กลิสต์: ใช้การยืนยัน ความครบถ้วน·ความชัดเจน·เกณฑ์การยอมรับที่วัดได้ เป็น เกตคุณภาพ
• Constitution gate: ใช้การตรวจล่วงหน้าใน ขั้นก่อนหน้า (-1) เช่น เกตความเรียบง่าย (≤3 โปรเจ็กต์), เกตต่อต้าน abstraction (ใช้เฟรมเวิร์กโดยตรง), เกตให้ความสำคัญกับการอินทิเกรตก่อน (ทำสัญญา·contract test ก่อน)
• การจัดการรายละเอียดแบบแบ่งชั้น: แยกรายละเอียดหรือโค้ดที่มากเกินไปไปไว้ใน implementation-details/ เพื่อ รักษาความอ่านง่าย
• ความมาก่อนของการทดสอบ: รับประกัน ความสามารถในการตรวจสอบได้ ด้วยกฎ สร้างไฟล์และทดสอบก่อน ตามลำดับ contract→integration→E2E→unit
• ยับยั้งฟีเจอร์ที่เกิดจากสมมติฐาน·การคาดเดา: เสริมการควบคุมขอบเขตด้วย การห้ามฟีเจอร์เชิงคาดเดา และการระบุ เงื่อนไขล่วงหน้าในแต่ละขั้น

The Constitutional Foundation

• ใช้ รัฐธรรมนูญการพัฒนา ที่ทำให้ทุกการพัฒนา สม่ำเสมอ·เรียบง่าย·คุณภาพสูง ด้วยหลักการที่เปลี่ยนไม่ได้ใน memory/constitution.md
  • Article I: Library-First — ทุกฟีเจอร์เริ่มจาก ไลบรารีอิสระ เพื่อให้ได้ ความเป็นโมดูล
  • Article II: CLI Mandate — ทุกไลบรารีต้องเปิดเผย CLI interface ที่รองรับ อินพุต/เอาต์พุตแบบข้อความ·JSON เพื่อรับประกัน การสังเกตได้ และ ความง่ายต่อการทดสอบ
  • Article III: Test-First — ห้ามพัฒนา ก่อนการอนุมัติเทสต์และการยืนยันความล้มเหลว (red) โดยยึดหลัก นิยามพฤติกรรมก่อน
  • Articles VII & VIII: ความเรียบง่าย·ต่อต้าน abstraction — ลดจำนวนโปรเจ็กต์ให้ต่ำสุด และ เชื่อใจการใช้เฟรมเวิร์กโดยตรง เพื่อ ยับยั้ง over-engineering
  • Article IX: ทดสอบการอินทิเกรตก่อน — ให้ความสำคัญกับการทดสอบที่ ใกล้เคียงสภาพแวดล้อมจริง และบังคับให้ contract test มาก่อนการพัฒนา
• ใช้ Phase -1 gate ของเทมเพลตเพื่อทำเช็กลิสต์การปฏิบัติตามรัฐธรรมนูญ และหากมีข้อยกเว้นให้บันทึก เหตุผลอย่างชัดเจน ใน Complexity Tracking
• ผ่าน กระบวนการแก้ไขเพิ่มเติม วิธีการประยุกต์ใช้หลักการสามารถพัฒนาได้ แต่ ปรัชญาแกนกลาง ยังคงอยู่

The Transformation

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

ซอร์สโค้ด Big Brother รั่วไหล!

และคุณยังถามถึงประเด็นที่เกี่ยวกับการทดลองจำนวนครั้งของการเชื่อมต่อพรอมป์ต์ด้วย

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

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

ในงานวิจัยมีปรัชญาที่เรียกว่า '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 จนสามารถทำงานในรูปแบบที่แทบไม่ต้องรีแฟกเตอร์เลยก็ได้ แต่
สำหรับบางคน อาจกำลังสร้างโค้ดระดับต่ำจำนวนมากเพราะขาดความเข้าใจแม้แต่ประเด็นสำคัญพื้นฐานอย่างมาก

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

• รักษาขนาดไฟล์ให้เล็ก: https://medium.com/realworld-ai-use-cases/…
• วิธีรักษาความเร็วในการรันของ codebase ให้เร็ว: https://forum.cursor.com/t/…
• แนวปฏิบัติและไกด์ไลน์ที่ดีของ Windsurf: https://gist.github.com/muratkeremozcan/…

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

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

กล่าวคือ สำหรับผู้ใช้แต่ละคน จำนวนครั้งของการรีแฟกเตอร์แบบชัดเจนก็อาจกลายเป็นตัวแปรตั้งแต่ 0 ถึง n ได้อีกครั้ง และ

หากมองในเจตนาหลัก บทความนี้น่าจะกำลังอธิบายว่า ‘ทำไมการใส่ใจกับ codebase ที่มีคุณภาพดีจึงเป็นเรื่องที่ดี?’

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

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

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

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

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

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

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

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

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

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